No começo, eu assumi que o tom da “finalidade determinística” da Dusk significava que um bloco é simplesmente final ou não, binário, no momento em que é produzido. Lendo os próprios estados de finalidade da rede, esse enquadramento simplifica demais o que realmente está acontecendo. Um bloco na Dusk passa por quatro estágios distintos antes de ser de fato travado: Aceito uma vez que ele ultrapassa as três fases de consenso da rodada atual; Confirmado quando os blocos posteriores começam a ser construídos sobre ele; Estável quando fica enterrado o bastante para se tornar probabilisticamente irreversível; e só então Final, o ponto em que a reversão se torna criptograficamente garantida como impossível, em vez de apenas extremamente improvável. Então “finalidade instantânea” faz muito trabalho nessa frase. O bloco é Aceito de forma rápida, genuinamente rápida — essa parte do discurso está certa. Mas Aceito e Final não são a mesma garantia, e a lacuna entre eles é exatamente onde uma liquidação financeira regulamentada se importaria mais. Existe também uma segunda camada que a maioria das pessoas ignora. O consenso roda por comitês selecionados por ordenação determinística (deterministic sortition), e se um provisionador acaba sendo selecionado para um comitê de votação em uma rodada enquanto também é o gerador do bloco na próxima, eles ficam incentivados a simplesmente pular o voto, na esperança de serem escolhidos como proponente em seguida. A própria documentação de engenharia da Dusk trata isso como um padrão de comportamento esperado, não como um cenário hipotético, e a correção é excluir essa entidade daquele comitê se isso acontecer. Assim, a camada de liquidação que é comercializada como determinística e instantânea, na verdade, é um processo graduado com uma particularidade de incentivo incorporada na seleção dos comitês — ambas as coisas são verdadeiras — e, ao mesmo tempo, é silenciosamente mais complicada do que a proposta em uma linha.
$DUSK #dusk @Dusk