Por 15 anos, tenho desenvolvido sistemas de jogos e mecânicas de slots. Evitei interagir com departamentos de compliance o máximo possível, mas em uma ocasião, fui forçado a escrever uma descrição oficial e detalhada de um algoritmo para um laboratório de certificação. Eu a tornei tecnicamente precisa, entreguei – e percebi que ninguém a leu ou verificou. O laboratório marcou as caixas, pegou o dinheiro e emitiu um certificado em papel. Em duas horas, seria possível lançar um hotfix em produção, e o hash certificado se tornaria obsoleto – mas isso já não importava para ninguém.
A indústria opera com base em "papéis mortos", não em verificações em tempo real. Isso não se aplica apenas a cassinos: qualquer sorteio, loteria, banner de gacha, distribuição de vagas em escolas ou entrega de ingressos para eventos – todos sofrem do mesmo fracasso. Existe o "✓ Provably Fair", server seed, hash – mas quase ninguém verifica isso, e muitas vezes nem mesmo o operador consegue. Eu criei o UVS (Uncloned Verification Standard) – uma tentativa de transferir a prova de integridade de certificados de terceiros confiáveis para algo que qualquer um pode recalcular por si mesmo.
O núcleo do padrão é uma única função, deriveTier. Ela atribui um nível de confiança ao sorteio, com base nas evidências concretamente apresentadas, e não em um selo de marketing:
🔴 — sem âncora, apenas o seed;
🟡 — notário / âncora auto-atestada / ligação a um beacon sem prova de ordem de commit;
🟢 — assinatura neutra de registro, ou imutabilidade de trilha (trail-immutability), ou vinculação de resultado (outcome-binding) com commit provado.
Sem evidência, não há verde. O código decide, não a promessa.
UVS prova que as regras publicadas foram executadas com as entradas publicadas e a aleatoriedade publicada. Ele NÃO prova que as próprias entradas são justas: o operador ainda pode inserir bilhetes fantasmas ou anunciar um prêmio em dinheiro que não corresponde ao prometido aos jogadores. UVS fecha um elo – o resultado – e o fecha completamente; a proteção das entradas (assim como KYC, licenças) é um controle separado. É melhor dizer isso imediatamente do que prometer demais.
Existem duas ramificações porque a aleatoriedade se comporta de maneiras diferentes.
uvLottery (sorteios / gacha) — alcança 🟢
Este é um sistema de permutação com seed. Pegamos o server seed, fazemos o hash com o beacon público do round drand (rede quicknet, tick de 3 segundos), calculamos o score de cada participante, ordenamos e distribuímos o prêmio com base na ordem obtida:
combinedSeed = SHA-256( serverSeed : drandRandomness )
score(id) = SHA-256( combinedSeed : id ) // para cada participante
Ordenação por score (decrescente, com desempate por id) → distribuição de prêmios de cima para baixo. Entradas idênticas produzem a mesma lista – em qualquer máquina, em qualquer idioma, sempre. Não há estado oculto.
Para que o operador não possa escolher um seed que gere um resultado específico, ele faz um commit a um round futuro do drand – um cuja aleatoriedade ainda não existe. O round é calculado deterministicamente a partir do tempo:
round = floor((now − genesis) / 3) + 1 // genesis quicknet = 1692803367
Para 🟢, isso não é suficiente: é necessária a "âncora de commit §5.4". O commitmentHash é carimbado em dois RFC-3161 TSA independentes (FreeTSA + DigiCert, diferentes jurisdições, requisições em paralelo), e o genTime do token deve ser estritamente anterior ao tempo de publicação do round:
genTime < timeOfRound(R)
Esta é a prova de que o seed foi fixado antes que o resultado se tornasse conhecido. Não há nada para escolher.
"Mas o TSA também é uma terceira parte confiável." Sim – mas é neutro, e dois em diferentes jurisdições tornam um conluio silencioso improvável. E o mais importante: toda a cadeia é publicamente recalculável – qualquer um pode verificar o round do drand, executar a permutação novamente em qualquer idioma e verificar o token com a equipe padrão:
openssl ts -verify -digest <commitmentHash> -in token.tsr -CAfile <ca>
Você não é solicitado a acreditar – você recebe as entradas.
uvGame (física interativa, PADDLA) — teto justo 🟡
Aqui, usamos commit-reveal com aleatoriedade "input-seeded": o resultado depende do serverSeed commitado mais as entradas do jogador em tempo real. Não há um beacon externo no ciclo físico final, portanto, o outcome-binding (e, consequentemente, 🟢) é impossível por construção. O motor não clonável: WASM compilado sob demanda. A palavra "Uncloned" no nome vem daqui. A lógica de verificação do PADDLA não é codificada estaticamente: para cada sessão, o registro fornece um regSeed, e o cliente compila um módulo WASM único diretamente no navegador, byte a byte.
buildWasm(regSeed) executa um LCG determinístico, semeado com regSeed, e constrói uma cadeia de 4 a 7 passos aritméticos (shifts + operações binárias com constantes aleatórias). Em seguida, emite manualmente um binário WASM válido – cabeçalho mágico 00 61 73 6d, seções type/function/export/code, números em LEB128 – exportando a função compute(i32) -> i32:
javascriptfunction buildWasm(regSeed) { const lcg = new LCG(regSeed); // LCG, semeado com o seed do registro const n = lcg.range(4, 7); const steps = Array.from({ length: n }, () => ({ shiftOp: SHIFT_OPS[lcg.range(0, SHIFT_OPS.length)], shiftAmt: 8 + lcg.range(0, 8), binOp: BINARY_OPS[lcg.range(0, BINARY_OPS.length)], constVal: (lcg.next() | 1) | 0, })); // ...emite seções WASM e corpo da função em LEB128... return { bytes: new Uint8Array([0x00,0x61,0x73,0x6d, 0x01,0x00,0x00,0x00, /* ... */]) }; }
Após a partida, o jogador clica em ANCHOR – o log final é enviado para um contorno de backend isolado "3A" e notariado pelos mesmos dois carimbos RFC-3161. Este é um registro pós-fato imutável da gravação, marcado honestamente com amarelo. O caminho para 🟢 via trail-immutability (OpenTimestamps / Bitcoin) está escrito, mas atualmente desativado – com uma única linha no Dockerfile – pois não há demanda por ele. Importante: os quatro verificadores de referência (JS/Python/Java/C++), que reproduzem o resultado byte a byte, são para o sorteio. O determinismo do jogo físico é verificado de outra forma: por replay determinístico do log de entradas no servidor.
Arquitetura: contorno isolado
A criptografia pesada é realizada por um backend separado "3A" (Docker no Render), completamente desacoplado do registro de produção e dos servidores de jogo. Endpoints: /commit (server seed → round futuro R → commitmentHash → ×2 RFC-3161 em paralelo), /reveal (puxa o round, calcula o sorteio, retorna registro 🟢 + serverSeed + drand + âncora), /anchor-record (notário para registro de jogo). Internamente, há um host componível e um plugin de loteria; deriveTier deriva o nível dos fatos.
Sobre o atraso – honestamente
O reveal ancorado leva cerca de 10 segundos, e quero ser preciso: isso não é criptografia. Duas chamadas ao TSA levam cerca de um segundo. Dez segundos é uma espera consciente pela publicação do round futuro exato do drand, e é essa espera que protege contra a escolha do seed. Um recurso avaliado em segundos, não em sobrecarga.
Sobre "isso foi escrito por uma LLM" Sou um desenvolvedor Java core; conheço HTML/JS superficialmente e me baseei em LLMs para a parte do navegador e da nuvem. Geralmente, isso é um motivo para não confiar em uma ferramenta de segurança – mas todo o sentido do UVS é que a implementação não precisa ser confiada: o resultado é recalculado independentemente a partir de entradas públicas em quatro idiomas. Quem escreveu o front-end – LLM ou eu – não afeta se o sorteio é justo. O produto é o protocolo, o código é apenas uma de suas expressões.
Para experimentar
Tudo vivo, aberto e desacoplado:
Especificação + verificadores (JS/Python/Java/C++): github.com/constarik/uvs (vive em uvs.uncloned.work)
/draw — uma página: modo in-browser 🟡 contra ancorado 🟢 via backend 3A: uvs.uncloned.work/draw
PADDLA — arcade interativo baseado em física: paddla.uncloned.work. Jogue, clique em ANCHOR, verifique o token RFC-3161 via openssl ts -verify.
A próxima barreira Jogos single-player e sorteios assíncronos estão puramente resolvidos. O próximo passo é escalar uvGame para multiplayer em tempo real sem perda de determinismo: manter um log UVS reproduzível através de lag de rede, perda de pacotes, injeção de entrada e netcode autoritativo de rollback/tick. Este sim é um quebra-cabeça.
Ficarei feliz em receber análises sobre deriveTier, o esquema com dois TSA – e especialmente sua visão sobre netcode multiplayer determinístico sob a restrição rigorosa de reprodutibilidade.