Protocolo Criptográfico

Commit / Reveal

Para el Round (ronda) t, el usuario i con secreto privado s_i ∈ {0,1}^128 elige la respuesta b_i ∈ {0,1} y publica:

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

Donde ‖ denota concatenación y round_t es un identificador público único del Round.

Durante la fase de Reveal, el usuario i transmite (s_i, b_i). El Motor del Round y cualquier verificador externo calculan HMAC-SHA256(s_i ‖ round_t, b_i) y verifican que coincida con el c_i previamente publicado. Los reveals que no coinciden son rechazados; los que no revelan son eliminados del Round, pero sus commits permanecen en la Merkle Root (raíz de Merkle) para auditoría.

Por qué HMAC y no un hash simple

Un commit simple H(s_i ‖ b_i) es vulnerable a dos ataques:

1. Precomputación Rainbow. Si s_i es corto (la UX móvil nos limita a ≤16 bytes de aleatoriedad vinculada al dispositivo), una tabla precomputada de H(s ‖ 0) y H(s ‖ 1) en todo el espacio de secretos puede descifrar los commits antes del reveal.
2. Replay entre Rounds. Sin vinculación al Round, un commit válido en el Round t podría reutilizarse como evidencia en el Round t' ≠ t.

HMAC con una clave de tamaño adecuado (aquí, 128 bits) y vinculación al Round (concatenando round_t en el mensaje con clave) elimina ambos. La seudorandomicidad de la construcción HMAC bajo supuestos estándar garantiza que, sin s_i, la ventaja de un adversario para distinguir b_i = 0 de b_i = 1 es insignificante.

De dónde proviene s_i

Cada dispositivo de usuario genera s_i al entrar al Round mediante crypto.getRandomValues(new Uint8Array(16)) del navegador. Se almacena en el almacenamiento de sesión de la WebApp solo durante la duración del Round. Después del Reveal, se descarta. No interviene ningún secreto escrito por el usuario.

Para los usuarios que borran su sesión a mitad del Round, el Round se pierde (no pueden revelar un commit cuya clave ya no poseen). El Reputation Score (puntaje de reputación) recibe una pequeña actualización negativa.

Merkle Root del Round

En la fase de Liquidación, el Motor calcula:

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

La raíz se encola para liquidación por lotes en TON cada 24 horas. Una sola transacción en TON puede comprometer ~5,760 raíces de Round (una por cada 60 segundos × 86,400 / 60 / 15 de amortización).

Cualquier participante puede obtener una prueba Merkle del Motor y verificar su inclusión contra la raíz en cadena, sin confiar en el Motor.

Ventana de disputa

Una ventana de disputa de 24 horas permite desafíos en cadena: un usuario envía una prueba Merkle que demuestra que la raíz en cadena no coincide con la afirmación del Motor fuera de cadena. Si el desafío tiene éxito, el Round se anula y se vuelve a liquidar; el operador paga una penalización de 1,000 $POP (POP) al Treasury (tesorería). Las raíces no impugnadas se finalizan.

Reputation Score

r_i ∈ [0, 1] es una estimación bayesiana de la honestidad del usuario, actualizada cada 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)}))}$$

Donde λ(o_i^{(t)}) es una función de verosimilitud sobre las observaciones (participación, revelación a tiempo, desviación de la probabilidad minoritaria, marcadores de anomalía). r_i inicial = 0.5 (prior no informado).

La reputación decae con la inactividad a una tasa δ = 0.01 / día. La reputación no puede exceder 0.99 (humildad epistémica) ni caer por debajo de 0.01 (permite recuperación).

El Reputation Score multiplica el multiplicador del Trust Ladder (escalera de confianza) en la liquidación:

$${\text{peso efectivo}}_i=r_i\times {\alpha }_{T(i)}$$

Argumento de seguridad formal

Bajo el supuesto de que HMAC-SHA256 es una función seudorandom (PRF) y que s_i es uniformemente aleatorio y desconocido para el adversario, ningún adversario eficiente puede:

1. Distinguir el commit c_i = HMAC(s_i ‖ round_t, b_i) para b_i = 0 vs b_i = 1 con ventaja no insignificante. (Ocultamiento.)
2. Encontrar (s'_i, b'_i) ≠ (s_i, b_i) tal que HMAC(s'_i ‖ round_t, b'_i) = c_i. (Vinculación, bajo la resistencia a colisiones de HMAC.)
3. Predecir la semilla del siguiente Round sin coludir con ambos conjuntos de validadores de DRAND y TON-VRF. (Ver Oracle & Randomness.)

Estas son las tres propiedades requeridas para un juego de coordinación Commit / Reveal justo. El protocolo no requiere ningún supuesto criptográfico adicional.

Auditoría y código abierto

El Motor del Round y la lógica de verificación son de código abierto bajo licencia MIT. El repositorio está en github.com/cashpop-protocol/round-engine. Una auditoría completa por Trail of Bits está prevista para la Fase 2 (Q4 2026).