GH GambleHub

Compartilhamento de carga

1) Por que uma distribuição «compartilhada»

Em uma rede multibilionária, os recursos (nódulos, sequenciadores, bridges, DA, POP/edge, GPU/CPU, canais egress) pertencem a diferentes entidades. A distribuição de carga compartilhada (SRN) faz com que a demanda seja tratada cooperativamente sob regras gerais de qualidade, custo e risco:
  • estabiliza o SLO em casos de picos e falhas locais;
  • reduz o custo de uma unidade de processamento (
  • aumenta a justiça e a previsibilidade para os papéis;
  • minimiza os «vizinhos barulhentos» e a arbitragem entre os domínios.

2) Objetos e papéis

Provedores de potência: validadores/nódulos, sequenciadores, pulos DA, clusters GPU/CPU, POP/edge.
Consumidores: operadores de serviços, criadores/estúdios, afiliados/agregadores, analista/ML.
Coordenadores: balançadores, roteadores, Policy/Compliance Gate, Rewards & Billing.
Supervisão: Comitê.


3) Taxonomia de carga (classes QoS)

Q4 - comandos de deadline: ordem crítica/finalidade (bridges, pagamentos, risco).
Q3 - fluxo ordenado: causalidade por chave (user/sessions/asset).
Q2 - exactly-once é eficaz: billing/snapshots/transferência de direitos.
Q1/Q0 - efeitos de massa/best: telemetria, índices, analista off-line.

Cada classe registra SLO/SLA, janelas de retais, limites in-flight, prioridades.


4) Políticas de CPN: que otimizamos

A decisão de colocar o trabalho em um provedor/rota específico é tomada por uma função utilitária com invariantes rígidos (ordem, complacência, quotas):

Utility(route    provider) =
wL·Latency_p95 + wQ·QueueDepth + wC·Cost_per_unit
+ wF·FinalityLag  + wR·RiskScore + wA·AvailabilityPenalty
+ wG·Geo/PolicyPenalty
Perfis de balança - diferentes para QoS:
  • Q4 ↑wL, ↑wF, ↑wR; Q1 ↑wC, ↓wF.

Invariantes: Strict-order per key (Q3/Q4), idempotação, limites RNFT/complacência.


5) Algoritmos de partilha

O Consent Hasing per Key com Hot-Shard Relief (adensamento temporário de chaves quentes).
Percentile-aware routing: solução para p95/p99, em vez de p50, para não esconder as caudas.
Capacity-aware cotas: Tocks per classe QoS/provedor/região.
EDF/LLF для Q4: Earliest Deadline First / Least Laxity First.
Probing & Half-open: provas rápidas de «recuperação» das rotas retiradas.
Backpressure: shakers, max-in-flight, degradação política (graceful).
Dual-write/Replay briers (Q3/Q2): para transferência segura entre os provedores.


6) Justiça e anti- «noisy neighbor»

Fair-share é alcançado por uma combinação:
  • Jain Fairness Index по CPU/GPU/IO/egress; o corredor de destino é suportado por quotas;
  • Weighted fair queuing (WFQ/DRR) em filas gerais;
  • Limites Budet em valor e volume;
  • Aumentos de superfície em direções sobrecarregadas (dinamic wC);
  • Multas por excesso sistemático de cauda/erro.

7) Economia e estímulos

Unidades de tarifação: vCPU-segundos, GiB-hora RAM, GPU-minuto, GB-armazenamento-m, GB-egress, DA-byte.

O modelo de pagamento dos provedores é taxa básica x qualidade x volume - multas:
[
P_i = \sum_t \underbrace{\text{Rate}i \cdot U{i,t}}{\text{объем}}
\ cdot\underbrace\QF
-\underbrace a.Penalty
]

onde (QF) é multiplicador por SLO (sucesso, p95, DLQ = 0, finality lag).

Bónus de qualidade: domínios com SLO estável recebem ↓take -rate ou ↑obyem de tráfego.
Fundo de seguro/slashing: cobre compensações; é gerido por fianças S no RNFT.


8) RNFT contratos e direitos

RNFT (Relationship NFT): contrato de participação do provedor/operador na CPN:
  • `role_bindings` (Provider/Operator/Oracle/Sequencer), `shares/fees`, `QoS-классы`;
  • `quotas/limits`, `S-stake`, `slashing_rules`, `SLA/KPI`;
  • 'region/compliance' (listas brancas), 'egress/DA' tetos;
  • `dispute/escrow`, `governance_version`, `sunset`.

9) Ordem, Idempotidade, finalidade

Strict-order per key na rota selecionada; failover - «pausa» + barreira replay.
Outbox/Inbox + idempotency _ key e tabela seen (TTL).
Finalidade X-chain - contabilidade das janelas de challenge; as operações críticas seguem o mínimo «FinalityLag».


10) Complaens e regras geo

Fail-closed: quando questionado, bloqueio, quórum manual.
Omissões ZK: verificação de idade/geo/sanções sem divulgação de PDN.
Impostos/retenção: no caminho de pagamento pela Rewards Router.
Políticas de exportação de dados: DA/egress por região, prazo de armazenamento.


11) Observabilidade e telemetria

Traçado de passagem: 'x _ msg _ id', 'road _ id', 'provider _ id', fase de bridge/DA.
Métricas (per QoS/provedor): p50/p95/p99, retry%, timeout%, duplicate ratio, out-of-order%, queue depth, finality lag, cost/req.
Дашборды: Shared Load Live, Tail Heatmap, Provider Quality, Cost-per-Route, Fairness Panel.
Alerts: error-budget burn, flap-rate, DLQ depth, preços de surge, blocos de compliance.


12) Incidentes e degradação

1. p95/p99, filas, finality lag, erros de complacência.
2. Isolamento: trip circuito, redistribuição de participações, redução de quotas a fluxos ruidosos.
3. Compensação: pagamentos do fundo de seguro/esboço RNFT.
4. Pós-mortem: RCA, atualização de pesos/limites/assinaturas de risco, rehearsal.


13) Fórmulas e orientações

SuccessRate = 1 − (timeouts+errors)/requests

TailAmplification = p99/p50 (↓, corredores per QoS)

(Jain) = ( x) ²/( n ²) por quotas/recursos

Costa/Req = (recurso x aposta )/pedidos de sucesso _

Headroom = (cap − current)/cap

Provedor de serviços: (QF = f (\text se), p95, DLQ, finality)

Utility_min при `Order=true ∧ Compliance=true ∧ Quotas=true`

Referências SLO (exemplo):
  • Q4: success ≥ 99. 99%, p95 ≤ 200 ms, DLQ = 0, MTTR ≤ 15 min.
  • Q3: perturbação da ordem ≤ 10⁻⁶/soobshch, p95 ≤ 500 ms.
  • DA: finalidade ≤ 3 x T _ block em Throughput ≥ X GB/h.

14) 治理 (peso, quotas, preços)

Propozais: variação de balança (w), limites, tarifas e bônus de qualidade.
R-modificador: vozes em quórum qualitativo são ponderadas pela reputação de R.
Edição sunset - Mudanças temporárias → reversão automática sem nova votação.
Relatórios públicos, relatórios trimestrais sobre qualidade dos provedores e justiça.


15) Playbook de implementação

1. Mapeamento de fluxo e chaves de causalidade (QoS/região/complacência).
2. Definição dos provedores e seus marcos RNFT (quotas, fianças S, KPI).
3. Telemetria e amostras (OWD/PTT/jitter/queue/cost/finality; EWMA+p95/p99).
4. Políticas Utility (peso per QoS, orçamento de custo, corredores de surge).
5. Garantias de entrega (outbox/inbox, idempotidade, barreiras de ordem).
6. Backpressure e fairness (WFQ/DRR, toquetes, anti-noise).
7. Observabilidade (dashboards, alertas, orçamentos errados).
8. Chaos/game-days (queda do provedor/ponte/DA, picos, blocos geo).
9. Economia e retalhos (bônus QF, multas/slashing, escrow).
10. 治理 e relatórios (propozais, sunset, métricas públicas).
11. Escala (novos provedores/regiões, otimização de rotas).


16) Programa de CPN KPI

Entrega: sucess (per QoS), DLQ = 0 (Q4/Q3), duplicate/out-of-order ↓.
Atraso: p95/p99 e TailAmplification nos corredores de destino.
Justiça: Jain ≥ alvo, redução de incidentes «noisy neighbor».
Economia: Costa/Req, com o SLO inalterado, crescimento da proporção de rotas «baratas».
Sustentabilidade: MTTR mediana ≤ alvo, flap-rate estável.
Complaens: 100% geo/age/sanções, violações nulas.
Provedores: proporção do volume dos provedores com alto QF ↑, taxa de multas ↓.


17) Folha de cheque pred pronto

  • As classes QoS, chaves de causalidade e SLO/SLA foram definidas
  • Políticas de Utility configuradas, quotas e toquetes per road/provider
  • Implementados consent hasing, hot-shard relief, EDF/LLF para Q4
  • Ativado outbox/inbox, idempotação e barreiras de ordem
  • Telemetria e dashboard conectados (latency/tail/queue/cost/finality)
  • No trabalho backpressure e fairness (WFQ/DRR, anti-noise)
  • Configurados bônus QF/multas, esbox e slashing S
  • Saques passados/game-days e pós-mortem
  • Funciona o Compliance Gate e retenção fiscal
  • Utverzhden治理 -exposição de balanças/limites/preços (com sunset)

18) Glossário

SRN: compartilhamento de carga (cooperative load distribuição).
RNFT: Contrato de relacionamento/direitos/limites não ajustados e KPI.
QF (Quality Factor): multiplicador de pagamento/volume pela qualidade do provedor.
Tail Amplificação: p99/p50 - a força da cauda.
WFQ/DRR: Família de planejadores de justiça ponderada.
Outbox/Inbox: pattern de entrega garantida e idempotação.
Surge-praising: aumento dinâmico na sobrecarga.


19) Resultado

A distribuição de carga compartilhada transforma a rede em um pool de processamento cooperativo, onde políticas (QoS, fairness, complance) e economia (bônus QF, multas, fianças) direcionam o tráfego para onde ele será tratado rapidamente, honestamente e de baixo custo - sem perda de ordem e finalidade. Este tipo de circuito oferece SLO previsível, incentivos transparentes para os provedores e resistência a picos, falhas e choques de preços.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.