Quando muita gente ouve “finalidade”, o que vem à mente é “quantos blocos já passaram, então não dá mais para mudar”, uma ideia de corte seco. Depois de ler o design de “finality” do Dusk com rolling finality, percebi que esse raciocínio é grosseiro demais.

Ele divide o estado dos blocos em quatro níveis: accepted, attested, confirmed e final. Você sobe camada por camada, não é uma divisão entre preto e branco. Blocos de rodadas mais baixas, se não conseguirem reunir “provas de falha”, podem ser substituídos por blocos das rodadas seguintes; porém, à medida que os blocos confirmados se acumulam cada vez mais, a probabilidade de bifurcação cai de forma aproximadamente exponencial, até que finalmente fique travado em um estado final, irreversível. Em essência, esse design transforma “quanto tempo é necessário para ficar tranquilo” em uma curva — e não em um número fixo.

O que eu mais me preocupa é como ele evita a oportunização — por exemplo, alguém deliberadamente fazer as votações naquele turno, esperando para “pegar” as recompensas de mineração das rodadas seguintes. O protocolo cria várias camadas de contramedidas: prêmios por votação, pontos adicionais, além de excluir a qualificação para minerar na próxima rodada. Isso é complementado por um limite para o número de iterações. Ou seja, em vez de contar apenas com punições, ele fecha as brechas uma a uma do ponto de vista de teoria dos jogos.

Mas quanto mais eu olho para os detalhes, mais eu fico com dúvidas: esse mecanismo se baseia nos pressupostos de que o tamanho do comitê é suficientemente grande e de que a comunicação de rede é suficientemente rápida. E se um dia houver partição de rede ou atrasos maiores na disseminação das mensagens? A hipótese de “acumular rapidamente blocos confirmados” pode acabar falhando primeiro. Finalidade em escala de segundos e robustez sob condições extremas de rede — dá mesmo para conciliar as duas? Até agora, não encontrei uma resposta que me deixe totalmente em paz.

@Dusk_Foundation #dusk $DUSK