Em uma liquidação de valores mobiliários, “pedido já foi correspondido”, “fundos já foram congelados” e “liquidação concluída juridicamente” não são a mesma coisa. O mesmo vale para a confirmação (confirmation) no blockchain. O site oficial @Dusk enfatiza a liquidação com determinismo, mas o white paper não simplifica a finalidade (finality) como “crédito em poucos segundos”; em vez disso, continua discutindo se, em situações anormais, o bloco poderia ser substituído.
Primeiro, veja o fallback. Na mesma rodada de consenso, se vários blocos candidatos chegarem ao resultado, os nós priorizam o de menor iteration e fazem rollback do ramo com maior iteration. Mesmo que um bloco tenha sido aceito pela rede, isso não significa que ele esteja absolutamente estável em todos os estados subsequentes.
O white paper também projeta um modo de emergência (emergency mode): após 16 falhas consecutivas de iteration, a etapa por tempo limite é cancelada; múltiplas open iteration podem ser executadas em paralelo, até que algum bloco candidato conclua verificação e aprovação. Se ainda assim não for possível avançar, os provisioners que detêm a maior parte da garantia (total stake) da rede podem solicitar a geração de um emergency block. Ele não contém transações; escreve principalmente um novo seed para fazer a rede voltar a avançar. #dusk
Por isso, a rolling finality de $DUSK distingue quatro estados: accepted indica que o bloco possui uma prova bem-sucedida, mas ainda pode ser substituído por uma iteration menor; attested indica que as iterations anteriores falharam e o bloco atual não pode mais ser substituído por uma iteration menor; confirmed indica que obteve suporte de blocos posteriores; final exige que o bloco pai também já esteja final. Se antes houver n iterations ainda não attestadas, o bloco accepted precisará passar por 2×n blocos attested ou confirmed consecutivos antes de entrar no estado confirmed.
Dessa forma, no meu entendimento, uma frase como “finalidade em nível de segundos” é mais honesta: ela separa a velocidade do caminho normal da estabilidade do caminho anormal e admite que atrasos, offline e bifurcações realmente podem acontecer.
Primeiro, veja o fallback. Na mesma rodada de consenso, se vários blocos candidatos chegarem ao resultado, os nós priorizam o de menor iteration e fazem rollback do ramo com maior iteration. Mesmo que um bloco tenha sido aceito pela rede, isso não significa que ele esteja absolutamente estável em todos os estados subsequentes.
O white paper também projeta um modo de emergência (emergency mode): após 16 falhas consecutivas de iteration, a etapa por tempo limite é cancelada; múltiplas open iteration podem ser executadas em paralelo, até que algum bloco candidato conclua verificação e aprovação. Se ainda assim não for possível avançar, os provisioners que detêm a maior parte da garantia (total stake) da rede podem solicitar a geração de um emergency block. Ele não contém transações; escreve principalmente um novo seed para fazer a rede voltar a avançar. #dusk
Por isso, a rolling finality de $DUSK distingue quatro estados: accepted indica que o bloco possui uma prova bem-sucedida, mas ainda pode ser substituído por uma iteration menor; attested indica que as iterations anteriores falharam e o bloco atual não pode mais ser substituído por uma iteration menor; confirmed indica que obteve suporte de blocos posteriores; final exige que o bloco pai também já esteja final. Se antes houver n iterations ainda não attestadas, o bloco accepted precisará passar por 2×n blocos attested ou confirmed consecutivos antes de entrar no estado confirmed.
Dessa forma, no meu entendimento, uma frase como “finalidade em nível de segundos” é mais honesta: ela separa a velocidade do caminho normal da estabilidade do caminho anormal e admite que atrasos, offline e bifurcações realmente podem acontecer.