O que é registrado, e quando
Uma partida de Mines começa com uma única transação on-chain (mines_start) que faz três coisas ao mesmo tempo, antes de você escolher qualquer casa:
- Registra a contribuição do operador. O backend gera uma
server_seedaleatória de 32 bytes e a transação armazena o hash SHA-256 dela, o commit. A seed em si fica oculta até o fim da partida. - Captura entropia da blockchain. O programa lê o hash de slot mais recente do sysvar
SlotHashesda Solana e o armazena na partida. - Congela as condições. A vantagem da casa, o teto de pagamento e o prazo de reembolso são registrados na sua partida; nada pode mudar o preço de um tabuleiro que você já está jogando.
Como o tabuleiro do Mines é derivado?
As 25 casas são numeradas de 0 a 24, linha por linha na grade 5×5 (index = row × 5 + column). O tabuleiro é uma máscara de 25 bits: o bit t ligado significa que a casa t esconde uma mina.
- A ordem de entrada do hash é exatamente: seed, hash de slot, endereço da conta de usuário, nonce (8 bytes little-endian), a tag ASCII
"mines"e, por fim, o contador de blocos (8 bytes little-endian, começando em 0). - Cada pedaço de 4 bytes é lido em big-endian. Um bloco rende no máximo 8 sorteios; o fluxo é reabastecido com o próximo valor do contador conforme necessário.
- O laço de amostragem por rejeição torna cada sorteio exatamente uniforme: o embaralhamento não tem nenhum viés a discutir.
Qual fórmula de pagamento o programa aplica?
Cada casa segura revelada multiplica o seu cash out pelo inverso exato da sua chance de sobreviver, com a vantagem da casa aplicada uma única vez:
O retorno esperado é
1 − vantagem para qualquer combinação de minas e casas reveladas. Os valores atuais estão em Taxas e limites.
O que o programa aplica na liquidação
A transação de liquidação (mines_settle) revela a server_seed e declara um resultado: um cash out com um conjunto de casas reveladas, ou um estouro em uma casa específica. O programa então confere tudo on-chain:
sha256(server_seed)precisa ser igual ao commit armazenado no início da partida; uma seed diferente não consegue liquidar a partida.- O tabuleiro é derivado de novo do zero com a fórmula acima. Qualquer casa revelada que na verdade seja uma mina é rejeitada; uma casa de estouro declarada que não seja mina é rejeitada; uma casa de estouro que também tenha sido declarada como revelada é rejeitada.
- O multiplicador é calculado on-chain a partir da vantagem registrada e do número real de casas que você revelou, então o pagamento não pode ser informado errado.
- O evento de liquidação publica a seed, o hash de slot, a máscara completa de minas, as casas que você revelou e o resultado, para sempre.
O que é garantido, e o que não é
Garantido pelo programa:- O tabuleiro é fixado antes da sua primeira escolha, pelo commit mais o hash de slot armazenado. As minas não podem mudar de lugar no meio da partida.
- Na liquidação, o operador não pode mentir sobre o tabuleiro: seed errada, uma mina declarada como segura ou um estouro falso fazem a transação falhar.
- As condições com que você começou (vantagem, teto de pagamento, prazo) valem até o fim da partida.
- O seu valor apostado nunca pode ficar travado: se o operador nunca liquidar, o cancelamento pode ser chamado por qualquer pessoa depois do prazo da partida, reembolsando o valor apostado. Em operação normal você nunca chega a isso: um tabuleiro abandonado recebe cash out no multiplicador atual antes do prazo (veja Mines), então você fica com os seus ganhos, e não só com o valor apostado. O cancelamento sem permissão é a garantia de base, para o caso de o operador desaparecer.
- O operador conhece o tabuleiro enquanto você joga. Isso é estrutural, não uma falha deste design em particular: as casas são reveladas instantaneamente off-chain, e quem as revela precisa saber onde estão as minas. Nenhum esquema de aleatoriedade elimina isso: mesmo um tabuleiro gerado por VRF seria conhecido pelo operador no momento em que ele revela a sua primeira casa. O que o commit garante é que esse conhecimento não pode ser usado para mudar o tabuleiro nem para informar errado o resultado.
- Momento do início. O tabuleiro depende do hash de slot capturado quando a sua partida começa, e a transação de início é enviada pelo backend, a mesma questão de timing dos outros jogos. Conhecer um tabuleiro com antecedência só ajuda se as suas escolhas forem previsíveis; variar onde você clica neutraliza qualquer seleção de tabuleiro baseada em timing.
- Anulações. O operador pode cancelar uma partida em andamento (inclusive, em princípio, uma que você está ganhando). Um cancelamento reembolsa todo o valor apostado (não existe caminho de confisco) e sempre emite um evento público, então a frequência de anulações pode ser auditada on-chain por qualquer pessoa.
- Cada partida precisa usar uma seed nova: uma seed revelada é pública, e reutilizá-la tornaria o próximo tabuleiro derivável por qualquer um. O programa rejeita on-chain a reutilização em partidas consecutivas, e o backend garante a unicidade global.
Como verificar uma partida de Mines?
O evento de liquidação (MinesGameSettled) na transação final da sua partida traz server_seed, slothash, user, nonce, mines_count, mines_mask, revealed_mask, bust_tile, multiplier_bps e is_win. Para verificar:
- Confira o commit:
sha256(server_seed)precisa ser igual aocommit_hashpublicado na transação de início da sua partida (eventoMinesGameStarted), o que prova que o tabuleiro foi travado antes da sua primeira escolha. - Derive de novo a máscara de minas com a fórmula acima e compare com o
mines_maskdo evento. - Confira o resultado contra a máscara: cada bit de
revealed_maskprecisa ser uma casa segura, e uma casa de estouro precisa ser uma mina. - Confira o multiplicador com a fórmula de pagamento.