el resultado del dado se puede elegir antes de apostar

[leocagli]

En dice-duel, el resultado de la partida queda determinado por datos que quien
arma la transaccion conoce y controla antes de que nadie apueste.

La evidencia

contracts/dice-duel/src/lib.rs:274:

// Seed components (all deterministic and identical between sim/submit):
// 1. Session ID - unique per game
// 2. Player addresses - both players contribute
//
// Note: We do NOT include ledger sequence or timestamp because those differ
// between simulation and submission, which would cause different winners.
let mut seed_bytes = Bytes::new(&env);
seed_bytes.append(&Bytes::from_array(&env, &session_id.to_be_bytes()));
seed_bytes.append(&game.player1.to_string().to_bytes());
seed_bytes.append(&game.player2.to_string().to_bytes());
let base_seed = env.crypto().keccak256(&seed_bytes);

O sea: semilla = keccak256(session_id || player1 || player2).

Y en start_game (linea 135), el session_id es un parametro que elige quien
llama:

pub fn start_game(
    env: Env,
    session_id: u32,
    player1: Address,
    player2: Address,
    player1_points: i128,
    player2_points: i128,
) -> Result<(), Error> {

Por que eso importa

Los tres ingredientes de la semilla se conocen antes de firmar. Entonces quien arma
la partida puede, offline y gratis, calcular el resultado para cada session_id
posible y presentar a la firma solamente uno donde gana. Cada intento es un keccak;
encontrar uno favorable lleva unos pocos.

El rival firma con require_auth_for_args([session_id, points]). Ve el numero, pero
no tiene ningun motivo para sospechar que ese numero decide la partida, y para
saberlo tendria que correr el mismo keccak.

Y hay un detalle que lo hace peor: roll() (linea 208) solo marca banderas. Los
dados se generan recien en reveal_winner. O sea que tirar es teatro; el resultado
ya estaba resuelto cuando se creo la partida.

Para un contrato que sostiene apuestas, esto es la falla que importa: no es que
alguien pueda hacer trampa con esfuerzo, es que el resultado se elige en vez de
sortearse.

El comentario del codigo explica por que se llego aca

Y la razon es legitima: incluir el ledger rompia la coincidencia entre simulacion y
envio. Es un problema real de Soroban, no un descuido. Lo que hay que cambiar es la
salida, no el diagnostico.

Direccion del arreglo

El patron que resuelve esto es compromiso y revelacion, que separa el momento de
apostar del momento en que se conoce la aleatoriedad:

1. Cada jugador publica hash(su_numero_secreto + sal) junto con la apuesta.
2. Nadie puede calcular el resultado, porque le falta el secreto del otro.
3. Vencido el plazo, los dos revelan; el contrato comprueba los hashes.
4. La semilla sale de los dos secretos combinados.
5. Si uno no revela, el otro cobra por incomparecencia.

Eso mantiene la propiedad que el comentario buscaba (simulacion y envio dan lo mismo,
porque en el momento de liquidar todo es dato firme) y saca la que sobra (que el
resultado se pueda anticipar).

• Fase de compromiso: hash(secreto + sal) de cada jugador junto con la apuesta
• Fase de revelacion con plazo, y validacion del hash contra lo revelado
• La semilla se deriva de los dos secretos, no del session_id
• Camino de incomparecencia: si uno no revela, el otro cobra
• Ligar el compromiso a este contrato y a esta partida, para que no se pueda
  reusar un compromiso viejo en otra partida
• Tests del camino feo: revelar algo que no coincide con el hash, no revelar,
  revelar dos veces, reusar el compromiso de otra partida

Antes de escribir codigo

Revisar si number-guess y twenty-one tienen la misma forma. En number-guess la
semilla incluye session_id y las dos apuestas (contracts/number-guess/src/lib.rs:280),
que es mejor pero puede compartir el problema si las dos apuestas viajan en la misma
llamada. Conviene arreglar los tres con el mismo patron en vez de tres parches
distintos.

---

Como se toma este trabajo: comentá la issue con un plan concreto (que archivo, que
funcion, y como lo vas a verificar). Se asigna por la calidad de ese plan, no por
orden de llegada. La PR va despues de la asignacion, con el cambio real adentro.

[Santia2004]

Hi! I would like to work on this issue. I have solid experience with TypeScript/JavaScript, backend architectures, and Soroban/Stellar integrations, and I have recently contributed clean, merged implementations across campaign repositories. Please feel free to assign it to me. Thanks!

[safal207]

¿Sería útil que la regresión demostrara no solo que el resultado ya no puede calcularse antes de apostar, sino también que ningún jugador puede obtener ventaja eligiendo el session_id, negándose a revelar, reutilizando un compromiso antiguo o esperando para decidir si revela después de conocer el secreto rival?

Este problema encaja muy bien con mi trabajo reciente en contratos Soroban: transiciones exactamente una vez, compromisos ligados al contexto, protección contra replay, límites temporales, rutas de recuperación y conservación del valor, verificados con pruebas nativas y un modelo independiente de estados.

Mi plan concreto:

• congelar el commit exacto y revisar dice-duel, number-guess y twenty-one para distinguir el defecto común de las diferencias reales entre juegos;
• reemplazar la semilla controlable por compromisos separados de ambos jugadores, ligados al contrato, al juego, al session_id, a las direcciones y a la apuesta exacta;
• verificar cada reveal contra su compromiso antes de derivar la semilla conjunta;
• impedir reveal duplicado, compromiso reutilizado, secreto incorrecto y replay entre otra partida u otra instancia;
• introducir deadlines explícitos para commit y reveal;
• definir una única ruta de incomparecencia para que un jugador que no revela no pueda bloquear los fondos indefinidamente;
• asegurar que la liquidación, el timeout y el camino de forfeiture sean mutuamente excluyentes y no paguen dos veces.

Los tests incluirán:

• búsqueda offline de session_id contra la implementación actual como control negativo;
• reveal correcto de ambos jugadores;
• secreto o sal incorrectos;
• reveal duplicado;
• compromiso de otra partida;
• un jugador no revela;
• ambos no revelan;
• reveal exactamente antes, en y después del deadline;
• ambos órdenes de reveal;
• intento de settlement repetido;
• conservación completa de apuestas y pagos.

También compararé estas dos historias:

commit A → commit B → reveal A → reveal B

y:

commit B → commit A → reveal B → reveal A

La propiedad requerida es el mismo resultado cuando los secretos son los mismos, sin que el orden de inclusión permita elegir al ganador.

Usaré ContractGraph-QA de forma externa para modelar las fases Commit → Reveal → Settled/Forfeited, los límites temporales y los replays, sin añadirlo como dependencia de producción.

Ejecutaré cargo fmt, clippy con warnings denegados, todas las pruebas nativas y el build WASM correspondiente.

Puedo abrir el primer PR enfocado dentro de las 24 horas posteriores a la asignación. Esperaré la asignación antes de empezar a modificar el código.

[leocagli]

Asignada a @safal207.

Tu comentario es el mejor que llegó a este repositorio, y no por el largo. Tres cosas
concretas:

Ampliaste el alcance en la dirección correcta. La issue se quedaba en que el
resultado se puede calcular antes de apostar. Vos agregás las otras tres vías por las que
se puede sacar ventaja: negarse a revelar, reusar un compromiso viejo, y esperar a
conocer el secreto rival antes de decidir si revelás. Las tres son reales y ninguna estaba
escrita.

Nombraste los tres contratos. dice-duel, number-guess y twenty-one. La issue
pedía revisar si comparten la forma antes de escribir código, y eso es exactamente lo que
proponés hacer primero.

Y el punto que decide: "búsqueda offline de session_id contra la implementación
actual como control negativo". Un test que demuestra que el bug existe antes del arreglo.
Hoy auditamos este repositorio y varios tests pasaban igual con el bug adentro; el tuyo no
podría. Esa sola línea vale más que el resto del plan.

Sobre las decisiones de diseño que planteás: los deadlines explícitos y la ruta única de
incomparecencia me parecen bien. Lo que sí conviene confirmar antes de escribir mucho es
el presupuesto de recursos: si atás el compromiso al contrato, al juego, al session_id, a
las direcciones y a la apuesta, el hash crece y el contrato tiene un techo por invocación.
Vale medirlo temprano.

Cuando abras el PR, ponele Closes #1. Y si en el camino descubrís que number-guess y
twenty-one necesitan un arreglo distinto, decilo y lo partimos en tres issues en vez de
forzar una solución única.

[safal207]

Gracias por la asignación. Antes de modificar el código de producción encontré una decisión de diseño que necesito confirmar.

La revisión muestra que conviene mantener #1 enfocada en dice-duel:

• number-guess también necesita ocultar los guesses para eliminar la ventaja del segundo jugador;
• twenty-one necesita randomness secuencial, porque una semilla revelada al inicio expondría las cartas futuras.

Para dice-duel, el commit–reveal tiene cuatro resultados:

1. ambos revelan → settlement normal;
2. sólo player1 revela → player2 pierde por incomparecencia;
3. sólo player2 revela → player1 pierde por incomparecencia;
4. ninguno revela → devolución neutral de los puntos.

El Game Hub visible en este repositorio sólo expone:

end_game(session_id, player1_won: bool)

Si ninguno revela, ese bool obliga a declarar arbitrariamente un ganador. No llamar a end_game dejaría los puntos bloqueados.

¿Existe ya una operación oficial de liquidación neutral en el Game Hub real?

Si no existe, ¿podemos añadir una operación aditiva como:

cancel_game(session_id)

con esta semántica?

• sólo puede llamarla el contrato de juego registrado;
• devuelve exactamente los puntos originales de ambos jugadores;
• no registra victoria ni derrota;
• termina la sesión una sola vez como Cancelled;
• es mutuamente excluyente con end_game;
• emite un evento GameCancelled.

¿Podrías compartir el ABI o la implementación oficial del Game Hub, o confirmar esta ampliación?

Mientras se decide esto, completaré el RED reproducible del grinding de session_id y la medición local del presupuesto de recursos, sin modificar producción.

[safal207]

Actualización breve mientras espero la decisión sobre la liquidación neutral.

Ya completé las dos verificaciones que mencionaste antes de tocar producción.

RED reproducible

Sobre el commit exacto:

43a933a84c7c3133365bf56b6998a26fdf360b24

un harness independiente reconstruye el seed y los dados dentro de un contexto Soroban válido.

Con los mismos jugadores y apuestas:

• session_id = 1 produce [5, 4, 3, 2] y gana player1;
• session_id = 3 produce [4, 4, 4, 6] y gana player2.

Los valores predichos coinciden exactamente con el contrato real.

También comprobé que:

roll(P1) → roll(P2)

y:

roll(P2) → roll(P1)

producen el mismo resultado. Cambiar los ledgers donde se ejecutan los rolls tampoco cambia los dados.

Esto confirma que roll() no agrega entropía y que quien elige el session_id puede seleccionar al ganador antes de crear la partida.

Presupuesto Soroban

También medí un prototipo test-only del commitment completo, ligado por XDR canónico a:

• versión y dominio;
• contrato;
• juego;
• sesión;
• rol y dirección del jugador;
• ambos jugadores;
• ambas apuestas;
• secret aleatorio de 32 bytes.

Resultados principales:

• preimage canónico: 344 bytes;
• peor ratio observado contra el snapshot de límites del SDK: 2.25%;
• máximo CPU medido: 193,499 instrucciones;
• máximo memory medido: 42,820 bytes;
• máximo write footprint: 3 entradas / 500 bytes.

El contexto completo no se acerca peligrosamente a los límites en este subset nativo.

También comparé secret-only contra secret + salt. Con un secret uniformemente aleatorio de 256 bits, el salt separado no agrega una protección útil y sí aumenta el payload y el costo, así que propongo usar sólo BytesN<32>.

Estos números no incluyen todavía:

• ejecución WASM desplegada;
• firmas reales;
• costos del Game Hub de producción;
• rent o fees de red.

No hice cambios de producción, commits ni PR.

El único bloqueo restante sigue siendo la semántica oficial para:

ninguno de los dos jugadores revela

Cuando confirmes si existe una operación neutral o si podemos añadir cancel_game(session_id), continuaré con la implementación de dice-duel, native GREEN y después ContractGraph-QA.

[leocagli]

Respondo, y de paso: el trabajo que trajiste en estos dos mensajes es mejor que la issue
que lo pidió. El RED reproducible con los dados predichos coincidiendo exactamente con el
contrato real es la prueba que la issue debería haber traído de entrada.

La respuesta corta: no existe liquidación neutral, y podés agregarla

contracts/mock-game-hub/src/lib.rs expone exactamente lo que viste, nada más:

pub fn start_game(...)
pub fn end_game(env, session_id, player1_won: bool)

No hay operación neutral. Tu lectura es correcta.

Pero hay un matiz que cambia el alcance, y prefiero decírtelo antes

Ese hub es un mock, y lo dice él mismo en su encabezado:

/// This contract provides the same external interface that games expect
/// (start_game, end_game) but does nothing internally. It exists purely
/// for game contracts to compile and integrate during development.

Así que agregar cancel_game(session_id) al mock es barato y lo podés hacer: está en el
workspace (Cargo.toml, cuarto miembro) y es nuestro. Lo que no controlamos es el Game
Hub real, que vive fuera de este repositorio. Si el hub de producción no expone una
operación neutral, un dice-duel que dependa de cancel_game compila, testea en verde
contra el mock, y falla al desplegarse.

No te lo digo para frenarte, sino para que la decisión sea consciente.

Lo que te propongo

Agregá cancel_game(session_id) al mock con la semántica que planteaste, que me parece
correcta entera: sólo la llama el contrato de juego registrado, devuelve los puntos
originales exactos, no registra victoria ni derrota, termina la sesión una sola vez como
Cancelled, es mutuamente excluyente con end_game, y emite GameCancelled.

Y en dice-duel, aislá la dependencia: que el camino de "ninguno revela" llame a una
función del contrato de juego, no directo al hub. Si mañana el hub real no tiene
cancel_game, se cambia esa función y no hay que tocar la máquina de estados.

Documentá en el PR que el contrato ahora requiere una operación de hub que el mock tiene y
el hub real puede no tener. Esa nota es lo que evita que alguien lo despliegue sin saberlo.

Sobre el alcance, tenés razón y lo acepto

Dejamos la #1 enfocada en dice-duel. Tu argumento es sólido y lo verifico:

• number-guess necesita además ocultar los guesses, que es un problema distinto
• twenty-one necesita aleatoriedad secuencial, porque una semilla revelada al inicio
  expone las cartas futuras

Son tres arreglos, no uno. Abro dos issues separadas para esos dos citando tu análisis, en
vez de forzarlos acá.

Sobre tus mediciones

El presupuesto que reportás (preimagen de 344 bytes, 2,25% del peor límite, 193.499
instrucciones de CPU) despeja la duda que te había planteado. Y coincido con lo del salt:
con un secreto uniformemente aleatorio de 256 bits, un salt separado no agrega protección
y sí costo. BytesN<32> solo.

Una sola advertencia sobre esos números, que vos ya anticipaste: son del subset nativo. El
WASM desplegado tiene otro costo, así que vale volver a medir cuando haya un build real
antes de dar por cerrado el presupuesto.

Seguí adelante.