Todo mundo fala da rápida finalidade do Dusk. Eu achei a parte interessante no que acontece quando o primeiro bloco falha.@Dusk
Passei a tarde inteira cavando as regras de finalidade do Dusk no whitepaper e na documentação atual, e o caminho n=0 é o que realmente me travou.
Os blocos passam por quatro estados: Accepted, Attested, Confirmed e então Final. O número-chave é n, quantas iterações anteriores na mesma rodada já falharam.
Quando n é zero, o bloco é marcado como Attested imediatamente. Assim que tiver um único sucessor que seja ele próprio Attested ou Confirmed, ele se torna Confirmed. Esse é o caminho rápido que a documentação descreve.
Quando n é maior que zero, as regras mudam. O bloco só começa como Accepted. Em seguida, ele precisa de 2n blocos consecutivos Attested ou Confirmed depois dele para então poder chegar a Confirmed. Um bloco de iteração 5 com duas falhas anteriores, por exemplo, precisa de mais quatro blocos bons. Só depois que ele fica Confirmed e o pai dele já está Final é que ele se torna irreversível.
O design deliberadamente dá ao primeiro gerador bem-sucedido uma finalidade mais forte. Os posteriores só ganham a mesma força depois que a rede já viu mais evidências de que tentativas anteriores realmente falharam.
Essa parte confere.
O que continuou me incomodando é como raramente o caminho mais lento aparece na conversa do dia a dia. Em condições normais, a maioria dos blocos segue o caminho n=0 e alcança a finalidade forte rapidamente. As exigências extras só aparecem quando a rede já está sob estresse.
Ainda fico pensando quantas pessoas que citam “finalidade instantânea” realmente sentaram com a diferença entre os dois caminhos.
#dusk $DUSK
Passei a tarde inteira cavando as regras de finalidade do Dusk no whitepaper e na documentação atual, e o caminho n=0 é o que realmente me travou.
Os blocos passam por quatro estados: Accepted, Attested, Confirmed e então Final. O número-chave é n, quantas iterações anteriores na mesma rodada já falharam.
Quando n é zero, o bloco é marcado como Attested imediatamente. Assim que tiver um único sucessor que seja ele próprio Attested ou Confirmed, ele se torna Confirmed. Esse é o caminho rápido que a documentação descreve.
Quando n é maior que zero, as regras mudam. O bloco só começa como Accepted. Em seguida, ele precisa de 2n blocos consecutivos Attested ou Confirmed depois dele para então poder chegar a Confirmed. Um bloco de iteração 5 com duas falhas anteriores, por exemplo, precisa de mais quatro blocos bons. Só depois que ele fica Confirmed e o pai dele já está Final é que ele se torna irreversível.
O design deliberadamente dá ao primeiro gerador bem-sucedido uma finalidade mais forte. Os posteriores só ganham a mesma força depois que a rede já viu mais evidências de que tentativas anteriores realmente falharam.
Essa parte confere.
O que continuou me incomodando é como raramente o caminho mais lento aparece na conversa do dia a dia. Em condições normais, a maioria dos blocos segue o caminho n=0 e alcança a finalidade forte rapidamente. As exigências extras só aparecem quando a rede já está sob estresse.
Ainda fico pensando quantas pessoas que citam “finalidade instantânea” realmente sentaram com a diferença entre os dois caminhos.
#dusk $DUSK