GH GambleHub

Совместное распределение нагрузки

1) Зачем «совместное» распределение

В мультисервисной/мультичейн-сети ресурсы (узлы, секвенсеры, бриджи, DA, POP/edge, GPU/CPU, каналы egress) принадлежат разным субъектам. Совместное распределение нагрузки (СРН) делает так, чтобы спрос обрабатывался кооперативно под общими правилами качества, стоимости и риска:
  • стабилизирует SLO при всплесках и локальных сбоях;
  • снижает стоимость единицы обработки (cost-to-serve);
  • повышает справедливость и предсказуемость для ролей;
  • минимизирует «шумных соседей» и арбитраж между доменами.

2) Объекты и роли

Поставщики мощности: валидаторы/узлы, секвенсеры, DA-пулы, кластеры GPU/CPU, POP/edge.
Потребители: операторы сервисов, создатели/студии, аффилиаты/агрегаторы, аналитика/ML.
Координаторы: балансировщики, маршрутизаторы, Policy/Compliance Gate, Rewards & Billing.
Надзор: аудиторы/регуляторы,治理-комитет.


3) Таксономия нагрузок (классы QoS)

Q4 — дедлайновые команды: критичный порядок/финальность (бриджи, платежи, риск).
Q3 — упорядоченные потоки: причинность по ключу (user/session/asset).
Q2 — exactly-once эффективно: биллинг/снапшоты/перенос прав.
Q1/Q0 — массовые/бест-эффорт: телеметрия, индексы, оффлайн-аналитика.

Для каждого класса фиксируются SLO/SLA, окна ретраев, лимиты in-flight, приоритеты.


4) Политики СРН: что оптимизируем

Решение о размещении работы на конкретный провайдер/маршрут принимается по утилитарной функции с жесткими инвариантами (порядок, комплаенс, квоты):

Utility(route    provider) =
wL·Latency_p95 + wQ·QueueDepth + wC·Cost_per_unit
+ wF·FinalityLag  + wR·RiskScore + wA·AvailabilityPenalty
+ wG·Geo/PolicyPenalty
Профили весов — разные для QoS:
  • Q4 ↑wL, ↑wF, ↑wR; Q1 ↑wC, ↓wF.

Инварианты: Strict-order per key (Q3/Q4), идемпотентность, лимиты RNFT/комплаенса.


5) Алгоритмы совместного распределения

Consistent Hashing per key с Hot-Shard Relief (временная подсегментация горячих ключей).
Percentile-aware routing: решение по p95/p99, а не p50, чтобы не прятать хвосты.
Capacity-aware quotas: токен-бакеты per класс QoS/провайдер/регион.
EDF/LLF для Q4: Earliest Deadline First / Least Laxity First.
Probing & Half-open: быстрые пробы «оздоровления» выведенных маршрутов.
Backpressure: шейперы, max-in-flight, деградации по политике (graceful).
Dual-write/Replay barriers (Q3/Q2): для безопасного переноса между провайдерами.


6) Справедливость и анти-«noisy neighbor»

Fair-share достигается сочетанием:
  • Jain Fairness Index по CPU/GPU/IO/egress; целевой коридор поддерживается квотами;
  • Weighted fair queuing (WFQ/DRR) на общих очередях;
  • Budget-лимиты по стоимости и объему;
  • Surge-надбавок на перегруженных направлениях (dynamic wC);
  • Штрафов за систематическое превышение хвостов/ошибок.

7) Экономика и стимулы

Единицы тарификации: vCPU-сек, GiB-час RAM, GPU-минута, GB-storage-мес, GB-egress, DA-байт.

Модель выплат провайдерам: базовая ставка × качество × объем – штрафы:
[
P_i = \sum_t \underbrace{\text{Rate}i \cdot U{i,t}}{\text{объем}}
\cdot \underbrace{QF{i,t}}{\text{качество}}
- \underbrace{Penalty{i,t}}_{\text{SLA/инциденты}}
]

где (QF) — множитель за SLO (успешность, p95, DLQ=0, finality lag).

Бонус качества: домены со стабильным SLO получают ↓take-rate или ↑объем трафика.
Страховой фонд/слэшинг: покрывает компенсации; управляется S-залогами в RNFT.


8) RNFT-договоры и права

RNFT (Relationship NFT): контракт участия провайдера/оператора в СРН:
  • `role_bindings` (Provider/Operator/Oracle/Sequencer), `shares/fees`, `QoS-классы`;
  • `quotas/limits`, `S-stake`, `slashing_rules`, `SLA/KPI`;
  • `region/compliance` (белые списки), `egress/DA` потолки;
  • `dispute/escrow`, `governance_version`, `sunset`.

9) Порядок, идемпотентность, финальность

Strict-order per key на выбранном маршруте; при failover — «пауза» + replay-барьер.
Outbox/Inbox + idempotency_key и seen-таблицы (TTL).
X-chain финальность: учет challenge-окон; критичные операции направляются по минимальному `FinalityLag`.


10) Комплаенс и гео-правила

Fail-closed: при сомнении — блокировка, ручной кворум.
ZK-пропуски: проверка возраста/гео/санкций без раскрытия ПДн.
Налоги/удержания: на пути выплат через Rewards Router.
Политики экспорта данных: DA/egress по регионам, сроки хранения.


11) Наблюдаемость и телеметрия

Сквозная трассировка: `x_msg_id`, `route_id`, `provider_id`, стадии бриджа/DA.
Метрики (per QoS/провайдер): 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.
Алерты: error-budget burn, flap-rate, DLQ depth, surge-цены, комплаенс-блоки.


12) Инциденты и деградации

1. Детект: рост p95/p99, очереди, finality lag, ошибки комплаенса.
2. Изоляция: trip circuit, перераспределение долей, понижение квот шумным потокам.
3. Компенсация: выплаты из эскроу/страхового фонда по RNFT-правилам.
4. Пост-мортем: RCA, обновление весов/лимитов/сигнатур риска, rehearsal.


13) Формулы и ориентиры

SuccessRate = 1 − (timeouts+errors)/requests

TailAmplification = p99/p50 (цель: ↓, коридоры per QoS)

FairnessIndex (Jain) = (Σx)²/(n·Σx²) по квотам/ресурсам

Cost/Req = Σ(ресурс×ставка)/успешные_запросы

Headroom = (cap − current)/cap

QualityFactor провайдера: (QF = f(\text{success}, p95, DLQ, finality))

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

Ориентиры SLO (пример):
  • Q4: success ≥ 99.99%, p95 ≤ 200 мс, DLQ=0, MTTR ≤ 15 мин.
  • Q3: нарушение порядка ≤ 10⁻⁶/сообщ., p95 ≤ 500 мс.
  • DA: финальность ≤ 3×T_block при Throughput ≥ X GB/ч.

14)治理 (веса, квоты, цены)

Пропозалы: изменение весов (w), лимитов, тарифов и бонусов качества.
R-модификатор: голоса в качества-кворумах взвешены по репутации R.
Sunset-правки: временные изменения → авто-откат без повторного голосования.
Публичная отчетность: квартальные отчеты по качеству провайдеров и справедливости.


15) Плейбук внедрения

1. Картирование потоков и ключей причинности (по QoS/региону/комплаенсу).
2. Определение провайдеров и их RNFT-рамок (квоты, залоги S, KPI).
3. Телеметрия и пробы (OWD/RTT/jitter/queue/cost/finality; EWMA+p95/p99).
4. Политики Utility (веса per QoS, бюджет стоимости, коридоры surge).
5. Гарантии доставки (outbox/inbox, идемпотентность, порядковые барьеры).
6. Backpressure и fairness (WFQ/DRR, токен-бакеты, anti-noise).
7. Наблюдаемость (дашборды, алерты, error-бюджеты).
8. Chaos/game-days (падение провайдера/моста/DA, всплески, гео-блоки).
9. Экономика и реварды (QF-бонусы, штрафы/слэшинг, эскроу).
10. 治理 и отчетность (пропозалы, sunset, публичные метрики).
11. Масштабирование (новые провайдеры/регионы, оптимизация маршрутов).


16) KPI программы СРН

Доставка: success (per QoS), DLQ=0 (Q4/Q3), duplicate/out-of-order ↓.
Задержка: p95/p99 и TailAmplification в целевых коридорах.
Справедливость: Jain ≥ целевого, снижение инцидентов «noisy neighbor».
Экономика: Cost/Req ↓ при неизменном SLO, рост доли «дешевых» маршрутов.
Устойчивость: MTTR медиана ≤ целевого, стабильный flap-rate.
Комплаенс: 100% прохождение geo/age/санкций, нулевые нарушения.
Провайдеры: доля объема у провайдеров с высоким QF ↑, частота штрафов ↓.


17) Чек-лист прод-готовности

  • Определены QoS-классы, ключи причинности и SLO/SLA
  • Настроены Utility-политики, квоты и токен-бакеты per route/provider
  • Реализованы consistent hashing, hot-shard relief, EDF/LLF для Q4
  • Включены outbox/inbox, идемпотентность и порядковые барьеры
  • Подключены телеметрия и дашборды (latency/tail/queue/cost/finality)
  • В работе backpressure и fairness (WFQ/DRR, anti-noise)
  • Настроены QF-бонусы/штрафы, эскроу и S-слэшинг
  • Пройдены chaos/game-days и оформлены пост-мортемы
  • Работает Compliance Gate и налоговые удержания
  • Утвержден治理-процесс весов/лимитов/цен (с sunset)

18) Глоссарий

СРН: совместное распределение нагрузки (cooperative load distribution).
RNFT: невзаимозаменяемый контракт отношений/прав/лимитов и KPI.
QF (Quality Factor): множитель выплат/объема по качеству провайдера.
Tail Amplification: p99/p50 — сила «хвоста».
WFQ/DRR: семейство планировщиков взвешенной справедливости.
Outbox/Inbox: паттерн гарантированной доставки и идемпотентности.
Surge-прайсинг: динамическая надбавка при перегрузке.


19) Итог

Совместное распределение нагрузки превращает сеть в кооперативный процессинг-пул, где политика (QoS, fairness, комплаенс) и экономика (QF-бонусы, штрафы, залоги) направляют трафик туда, где он будет обработан быстро, честно и недорого — без потери порядка и финальности. Такой контур дает предсказуемые SLO, прозрачные стимулы для провайдеров и устойчивость к пикам, сбоям и ценовым шокам.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.