Um item técnico importante que esqueci de mencionar é a proposta de troca do Casper FFG pelo Minimmit como gadget de finalidade.
Para resumir, o Casper FFG fornece finalidade em duas rodadas: exige que cada atestador assine uma vez para "justificar" o bloco e depois novamente para "finalizá-lo". O Minimmit exige apenas uma rodada. Em contrapartida, a tolerância a falhas do Minimmit (na nossa parametrização) cai para 17%, em comparação com os 33% do Casper FFG.
Dentro das discussões de consenso do Ethereum, sempre fui o defensor mais rigoroso das suposições de segurança: insisti em atingir o limite teórico de 49% de tolerância a falhas sob sincronia, continuei pressionando por gadgets de recuperação contra ataques de 51%, desenvolvi o DAS para tornar as verificações de disponibilidade de dados resistentes a maioria desonesta, etc. Mas estou confortável com as propriedades do Minimmit — na verdade, até entusiasmado em alguns aspectos. Nesta postagem, explicarei por quê.
Vamos listar as propriedades exatas de segurança tanto do 3SF (não a cadeia de baliza atual, que é desnecessariamente fraca de muitas maneiras, mas o 3SF ideal) quanto do Minimmit.
“Rede síncrona” significa “latência da rede inferior a cerca de 1/4 de slot”; “rede assíncrona” significa “latência potencialmente muito alta, até mesmo alguns nós ficam offline por horas seguidas”. As porcentagens (“atacante tem <33%”) referem-se a porcentagens de ETH stakeado ativo.
## Propriedades do 3SF
Caso de rede síncrona:
* Atacante tem p < 33%: nada de ruim acontece
* 33% < p < 50%: o atacante pode impedir a finalidade (ao custo de perder fundos massivos via inactivity leak), mas a cadeia continua progredindo normalmente
* 50% < p 67%: o atacante pode finalizar coisas à vontade, tornando muito mais difícil para os bons atores realizarem uma fork minoritária
Caso de rede assíncrona:
* Atacante tem p 33%: pode reverter a finalidade, ao custo de perder fundos massivos via slashing
## Propriedades do Minimmit
Caso de rede síncrona:
* Atacante tem p < 17%: nada de ruim acontece
* 17% < p < 50%: o atacante pode impedir a finalidade (ao custo de perder fundos massivos via inactivity leak), mas a cadeia continua progredindo normalmente
* 50% < p 83%: o atacante pode finalizar coisas à vontade, tornando muito mais difícil para os bons atores realizarem uma fork minoritária
Caso de rede assíncrona:
* Atacante tem p 17%: pode reverter a finalidade, ao custo de perder fundos massivos via slashing
Na verdade, acho que este último é um melhor compromisso. Eis minha razão:
* O pior tipo de ataque não é na verdade a reversão de finalidade, mas a censura. A razão é que a reversão de finalidade cria evidência publicamente disponível massiva que pode ser usada para custar imediatamente ao atacante milhões de ETH (ou seja, bilhões de dólares), enquanto a censura exige coordenação social para contornar
* Em ambos os casos acima, um ataque de censura exige 50%
* Um ataque de censura torna-se *muito mais difícil* de contornar quando o atacante censurador pode finalizar unilateralmente (ou seja, >67% no 3SF, >83% no Minimmit). Se ele não puder, então, se os bons atores contra-coordenarem, você terá duas cadeias não-finalizadas disputando por alguns dias, e os usuários poderão escolher. Se ele puder, então não há um ponto Schelling natural para coordenação da fork
* No caso de um bug no cliente, o pior que pode acontecer é finalizar algo com bug. No 3SF, você precisa apenas que 67% dos clientes compartilhem o bug para que ele seja finalizado; no Minimmit, você precisa de 83%
Basicamente, o Minimmit maximiza o conjunto de situações em que “o padrão é duas cadeias disputando entre si”, e isso é na verdade um resultado muito mais saudável e muito mais recuperável do que “a coisa errada sendo finalizada”.
Queremos que finalidade signifique definitivo. Portanto, em situações de incerteza (seja ataques ou bugs de software), devemos estar mais dispostos a aceitar períodos de horas ou dias em que a cadeia não finaliza e em vez disso progride com base na regra de escolha da fork. Isso nos dá tempo para refletir e garantir qual cadeia está correta.
Além disso, acho que o “33% slashing para reverter finalidade” do 3SF é excessivo. Se houver mesmo que 15 milhões de ETH stakeados, isso representa 5 milhões ($10 bilhões) slashing para reverter a cadeia uma única vez. Se você tivesse $10 bilhões e estivesse disposto a cometer caos do tipo que viola as leis de hacking de muitos países, existem MUITO MELHORES maneiras de gastá-los do que atacar uma cadeia. Mesmo que seu objetivo seja quebrar o Ethereum, existem vetores de ataque muito melhores.
E assim, se tivermos a garantia básica de pelo menos 17% slashing para reverter finalidade (que o Minimmit fornece), devemos julgar os dois sistemas a partir daí com base em suas outras propriedades — onde, pelas razões descritas acima, acho que o Minimmit se sai melhor.