Криптографический протокол

Commit / Reveal

Для Round (раунда) t пользователь i с приватным секретом s_i ∈ {0,1}^128 выбирает ответ b_i ∈ {0,1} и публикует:

$$c_i=\text{HMAC-SHA256}(s_i\parallel {\text{round}}_t,b_i)$$

Где ‖ обозначает конкатенацию, а round_t — публичный уникальный идентификатор Round.

В фазе Reveal пользователь i транслирует (s_i, b_i). Round Engine и любой сторонний верификатор вычисляют HMAC-SHA256(s_i ‖ round_t, b_i) и проверяют его соответствие ранее опубликованному c_i. Несовпадающие Reveal отклоняются; участники, не выполнившие Reveal, исключаются из Round, но их Commit остаются в Merkle Root для аудита.

Почему HMAC, а не обычный хеш

Обычный Commit H(s_i ‖ b_i) уязвим для двух атак:

1. Радужное предвычисление. Если s_i короткий (мобильный UX ограничивает нас ≤16 байтами привязанной к устройству случайности), предвычисленная таблица H(s ‖ 0) и H(s ‖ 1) по всему пространству секретов может взломать Commit до Reveal.
2. Повторное использование между Round. Без привязки к Round Commit, действительный в Round t, может быть повторно предъявлен как доказательство в Round t' ≠ t.

HMAC с ключом надлежащего размера (здесь 128 бит) и привязкой к Round (конкатенация round_t в сообщение с ключом) устраняет обе проблемы. Псевдослучайность конструкции HMAC при стандартных предположениях гарантирует, что без знания s_i преимущество противника в различении b_i = 0 и b_i = 1 пренебрежимо мало.

Откуда берется s_i

Каждое устройство пользователя генерирует s_i при входе в Round через crypto.getRandomValues(new Uint8Array(16)) браузера. Он хранится в сессионном хранилище WebApp только на время Round. После Reveal он удаляется. Никакой введённый пользователем секрет не используется.

Для пользователей, которые очищают сессию в середине Round, Round считается проигранным (они не могут раскрыть Commit, для которого у них больше нет ключа). Reputation Score получает небольшое отрицательное обновление.

Merkle Root Round

На этапе Settle Engine вычисляет:

$${\text{root}}_t=\text{Merkle}(\{(i,c_i,b_i,{\text{outcome}}_i):i\in {\text{Participants}}_t\})$$

Корень ставится в очередь для пакетного расчёта в TON каждые 24 часа. Одна транзакция в TON может зафиксировать ~5 760 корней Round (один корень каждые 60 секунд × 86 400 / 60 / 15 амортизация).

Любой участник может получить Merkle proof от Engine и проверить своё включение по корню в цепочке, не доверяя Engine.

Окно оспаривания

24-часовое окно оспаривания позволяет подавать ончейн-вызовы: пользователь отправляет Merkle proof, показывающий, что корень в цепочке не соответствует утверждению Engine вне цепочки. Если вызов успешен, Round аннулируется и пересчитывается; оператор выплачивает штраф в размере 1 000 $POP в Treasury. Неоспоренные корни становятся окончательными.

Reputation Score

r_i ∈ [0, 1] — байесовская оценка честности пользователя, обновляемая каждый Round:

$$r_i^{(t+1)}=\frac{r_i^{(t)}\cdot \lambda (o_i^{(t)})}{r_i^{(t)}\cdot \lambda (o_i^{(t)})+(1-r_i^{(t)})\cdot (1-\lambda (o_i^{(t)}))}$$

Где λ(o_i^{(t)}) — функция правдоподобия по наблюдениям (участие, своевременность Reveal, отклонение от вероятности меньшинства, маркеры аномалий). Начальное r_i = 0.5 (неинформированный априор).

Reputation снижается при бездействии со скоростью δ = 0.01 / день. Reputation не может превышать 0.99 (эпистемическая скромность) или опускаться ниже 0.01 (допускает восстановление).

Reputation Score умножает множитель Trust Ladder при расчёте:

$${\text{effective weight}}_i=r_i\times {\alpha }_{T(i)}$$

Формальное обоснование безопасности

При предположении, что HMAC-SHA256 является псевдослучайной функцией (PRF) и что s_i равномерно случаен и неизвестен противнику, ни один эффективный противник не может:

1. Различить Commit c_i = HMAC(s_i ‖ round_t, b_i) для b_i = 0 и b_i = 1 с не пренебрежимо малым преимуществом. (Скрытность.)
2. Найти (s'_i, b'_i) ≠ (s_i, b_i) такие, что HMAC(s'_i ‖ round_t, b'_i) = c_i. (Связывание, при условии коллизионной стойкости HMAC.)
3. Предсказать следующее начальное значение Round без сговора с наборами валидаторов DRAND и TON-VRF. (См. Oracle & Randomness.)

Это три свойства, необходимые для честной координационной игры Commit / Reveal. Протокол не требует никаких дополнительных криптографических предположений.

Аудит и открытый исходный код

Round Engine и логика верификации имеют открытый исходный код под лицензией MIT. Репозиторий находится по адресу github.com/cashpop-protocol/round-engine. Полный аудит от Trail of Bits запланирован на Фазу 2 (Q4 2026).