--- type: explanation title: Anti-trapaça de jogo summary: Como o jogo é mais do que um desafio. Um sistema de anti-trapaça em camadas que monta cada rodada no servidor, a roda em sandbox no navegador, e a reverifica por replay determinístico. --- O jogo que um visitante joga por alguns segundos é a parte que você vê. Por baixo dele está o sistema de anti-trapaça que faz o jogo valer como prova de um humano. A Caputchin pega emprestado o manual que jogos multiplayer competitivos usam contra trapaceiros: o servidor é autoritativo sobre cada rodada, o jogo roda em uma sandbox trancada, e o resultado é rederivado reexecutando as entradas do jogador. O jogo pode ser jogado, não falsificado. Este é o terceiro portão de verificação, empilhado com [proof of work](/docs/understanding-caputchin/proof-of-work) e [instrumentação](/docs/understanding-caputchin/instrumentation). Ele é configurado por chave na página de [Segurança](/docs/site-keys/security). ## O ciclo de vida Uma rodada passa por três fases: montada no servidor antes do jogo, rodada em sandbox no navegador durante o jogo, e reverificada no servidor depois do jogo. ```mermaid sequenceDiagram participant V as Navegador do visitante participant S as Servidor da Caputchin participant G as Iframe do jogo em sandbox participant R as Isolate de replay V->>S: Pede um desafio S->>V: Tíquete assinado de uso único (servidor escolhe o jogo e a semente) V->>G: Monta o jogo em um iframe isolado Note over G: Sem rede, sem alcance até sua página G->>V: Registra as entradas do jogador como um trace V->>S: Envia o tíquete e o trace S->>R: Reexecuta o trace sob a mesma semente Note over R: Selado, sem rede, com tempo limitado R->>S: Veredito e pontuação S->>V: Token assinado, só se o replay confirmar o jogo ``` ## Antes da rodada: montagem autoritativa no servidor Tudo o que decide o que a rodada *é* acontece no servidor, nunca no navegador. Este é o princípio de "nunca confie no cliente" do anti-trapaça multiplayer: o cliente envia intenção, o servidor decide a realidade. - **Um tíquete assinado, de uso único** acuna a rodada. Ele é de vida curta e só pode ser gasto uma vez. Um tíquete capturado não pode ser reexecutado em uma segunda aprovação. - **O jogo e sua semente aleatória são escolhidos no servidor** e carregados no tíquete. O navegador não pode escolher um jogo mais fácil ou uma semente mais amigável, porque ele nunca faz essa escolha. - **Um jogo diferente do pool elegível a cada vez.** Um solucionador nunca sabe qual jogo vai enfrentar, então não pode pré-treinar em um único alvo estático. Operadores podem estreitar o rodízio, mas o servidor sempre escolhe do conjunto permitido. O pool em si só contém jogos que passaram em uma checagem de conformidade no momento da indexação. Veja [construir um jogo de marketplace](/docs/marketplace-game-development/build-a-marketplace-game). ## Durante a rodada: um jogo em sandbox O jogo roda no navegador do visitante, mas dentro de uma fronteira que protege tanto o site do visitante quanto a integridade da rodada. O `` monta cada jogo em um iframe isolado sem acesso de mesma origem, então o jogo tem uma origem opaca e não consegue alcançar os cookies, o armazenamento, o DOM ou a rede de mesma origem da página anfitriã. Sua content-security-policy inline fixa o script exatamente no bundle do jogo e bloqueia chamadas de rede de saída, e o bundle é conferido contra um hash conhecido antes de rodar (um descompasso falha de forma fechada). A própria política de segurança da página anfitriã fica intocada. O formato exato da sandbox e da política está documentado em [como a Caputchin coloca os jogos em sandbox](/docs/understanding-caputchin/game-sandboxing). A conclusão: o jogo é não-confiável-por-padrão e contido. Ele não consegue exfiltrar nada, e não consegue adulterar a página em que está embutido. ## Depois da rodada: replay determinístico Quando o visitante termina, o navegador envia o trace de entradas registrado. O servidor não acredita na palavra do navegador sobre o resultado. Ele reexecuta o trace. - **A rodada é ressimulada no servidor** sob a mesma semente derivada no servidor, em um isolate selado sem acesso à rede e com um orçamento de tempo rígido. Esta é a mesma propriedade em que o lockstep determinístico se apoia nos jogos de estratégia: semente idêntica mais entradas idênticas reproduzem jogo idêntico. Um trace que não resolveu de fato o jogo não reproduz um resultado de aprovação. - **Aprova ou reprova é tirado desse replay**, nunca de um número que o navegador reportou. Um cliente não pode alegar uma pontuação que não ganhou. - **Um token assinado é emitido só se o replay confirmar o jogo.** Esse token é ele mesmo de uso único quando seu backend depois o confirma no momento da verificação. ## O que a Caputchin não faz A maioria dos CAPTCHAs de jogo e interativos se apoia em sinais comportamentais: entropia de trajeto de mouse, timing de toque, telemetria de aparelho alimentada a um classificador que adivinha bot-contra-humano. A Caputchin deliberadamente não faz isso. Ela não coleta nenhum perfil comportamental do jogador. Em vez de adivinhar *como* as entradas foram produzidas, ela rederiva *se* elas de fato resolvem o jogo a partir dos primeiros princípios. Isto é tanto uma postura de privacidade quanto de segurança: não há modelo comportamental para enganar, só física para reproduzir. ## Um limite honesto **O portão é tão forte quanto o jogo.** O maquinário de anti-trapaça prova que uma rodada foi genuinamente jogada e não falsificada, mas não consegue tornar um jogo fácil em difícil. Um jogo trivial (um tabuleiro estático, a jogada vencedora legível no DOM, "clique no ponto vermelho para passar") é barato para um script resolver, e o replay determinístico vai fielmente confirmar que essas entradas roteirizadas vencem, porque elas vencem. A resistência a bots vem do próprio jogo ser difícil de resolver programaticamente: reações rápidas, sensoriais, numa fração de segundo, sem solução parada no DOM. A camada de anti-trapaça garante que o jogo foi real; o design do jogo decide se o jogo real foi difícil de automatizar. Escolha e construa jogos com isso em mente, veja [construir um jogo de marketplace](/docs/marketplace-game-development/build-a-marketplace-game). Aprova ou reprova é decidido pela própria lógica de cada jogo; o servidor reexecuta fielmente essa lógica mas não questiona o que um dado jogo considera uma vitória. O anti-trapaça de jogo é mais forte composto com [proof of work](/docs/understanding-caputchin/proof-of-work), [instrumentação](/docs/understanding-caputchin/instrumentation) e o resto das [configurações de segurança](/docs/site-keys/security) de uma chave.