Um ator desonesto não tem medo de ser inspecionado. O que ele mais teme é não saber onde a inspeção vai acontecer.

Essa foi a primeira ideia que me veio à mente quando encontrei os números 307–301–6 no mecanismo BABE por trás dos Trustless Bitcoin Vaults (TBV), de @BabylonLabs_io. Eu entendi os números. O que eu não entendi foi por que um protocolo criaria intencionalmente tanto trabalho extra.

Durante o peg-in, o BABE gera 307 instâncias de circuitos embaralhados. Por meio de um protocolo de cut-and-choose, 301 instâncias são abertas para verificar como os circuitos foram criados, enquanto apenas as restantes 6 são de fato usadas.

No início, isso pareceu terrivelmente ineficiente. Quase 98% dos circuitos nunca contribuem para a computação final. Se só seis são necessários, por que não gerar seis desde o começo? Porque isso só funciona se o gerador do circuito já souber quais seis vão sobreviver. O BABE remove exatamente essa vantagem.

Todas as 307 instâncias devem ser criadas antes de o protocolo selecionar aleatoriamente 301 para inspeção. O verificador não está apenas checando o resultado final, mas a integridade do próprio processo de geração. Como ninguém sabe com antecedência quais circuitos serão contestados, preparar versões separadas “honestas” e “desonestas” fica impraticável.

Foi quando os circuitos abertos de 301 pararam de parecer trabalho desperdiçado. Eles são o custo de tornar a verificação imprevisível.
Para mim, essa é a verdadeira escolha de design por trás do BABE. O protocolo não depende de os participantes serem honestos. Ele transforma a honestidade na estratégia mais segura porque ninguém consegue prever o que será inspecionado.

Portanto, os números 307–301–6 são mais do que detalhes de implementação. Eles refletem uma troca arquitetural deliberada dentro do TBV: gastar mais computação durante a verificação para reduzir suposições de confiança antes que o Bitcoin assegure uma aplicação.

@BabylonLabs_io $ON $BABY #baby