Hoje, enquanto eu lia a parte sobre a finalidade “rolling” do whitepaper do @Dusk , eu só ia dar uma olhada rápida; mas acabou travando por quase duas horas sem eu continuar a leitura.
A maioria das pessoas entende de forma bem superficial a “confirmação de blocos”: uma vez que o bloco foi publicado na cadeia (on-chain), então estaria seguro; no máximo, esperar mais alguns números de confirmação para ter mais tranquilidade. Eu mesmo pensava assim antes, até eu calcular as regras específicas da Rolling Finality da Dusk e perceber que essa intuição de “esperar mais confirmações” pode estar errada nesta rede.
A Dusk divide o estado de um bloco em quatro níveis: accepted, attested, confirmed e final. Parece uma hierarquia comum, mas o diabo mora nos detalhes — se um bloco não alcança consenso na ausência de “falhas iterativas de predecessores” (isto é, n>0, e houve falhas de iteração antes), ele só pode ser marcado primeiro como accepted, e não como attested, que seria mais estável. O estado accepted significa que, teoricamente, ainda pode ser substituído por um bloco candidato com um índice de iteração mais baixo.
Para se tornar confirmed, quantas confirmações de blocos subsequentes são necessárias? A resposta não é um número fixo como 1 ou 3; é 2×n. n é a quantidade de falhas de iteração que ocorreram antes. O exemplo dado no whitepaper é o caso de índice de iteração 5, com 2 falhas prévias: nessa situação, é preciso esperar por 4 blocos subsequentes attested/confirmed para que fique realmente “estável”.
Eu li essa regra três vezes antes de ter certeza de que não entendi errado.
Isso significa que dois blocos que “já foram para a cadeia” não têm o mesmo nível de risco — um bloco em que houve um sucesso na primeira tentativa, sem falhas iterativas anteriores, entra quase imediatamente em um estado attested mais estável; já um bloco que passou por várias falhas de iteração até conseguir, precisa esperar por mais blocos subsequentes para atingir a mesma força de resistência à substituição. À primeira vista, ambos parecem “já confirmados”, mas por baixo a fragilidade é em camadas.
Então, agora meu procedimento é este: quando preciso avaliar “se esta transação está realmente estável”, eu não olho apenas para um número de confirmações. Eu vou verificar quantas falhas de iteração o bloco que contém essa transação atravessou. Quanto maior o número de iterações, mais confirmações eu estou disposto a esperar, especialmente em cenários de liquidação de valores altos.
Se você só faz transferências pequenas e frequentes, esses detalhes não têm tanta importância; a janela de risco já é naturalmente curta. Mas se você está fazendo liquidação DvP em nível institucional ou negociando OTC com valores altos, esse valor de n vale a pena você mesmo consultar nos dados do nó da Dusk. #dusk $DUSK @Dusk
A maioria das pessoas entende de forma bem superficial a “confirmação de blocos”: uma vez que o bloco foi publicado na cadeia (on-chain), então estaria seguro; no máximo, esperar mais alguns números de confirmação para ter mais tranquilidade. Eu mesmo pensava assim antes, até eu calcular as regras específicas da Rolling Finality da Dusk e perceber que essa intuição de “esperar mais confirmações” pode estar errada nesta rede.
A Dusk divide o estado de um bloco em quatro níveis: accepted, attested, confirmed e final. Parece uma hierarquia comum, mas o diabo mora nos detalhes — se um bloco não alcança consenso na ausência de “falhas iterativas de predecessores” (isto é, n>0, e houve falhas de iteração antes), ele só pode ser marcado primeiro como accepted, e não como attested, que seria mais estável. O estado accepted significa que, teoricamente, ainda pode ser substituído por um bloco candidato com um índice de iteração mais baixo.
Para se tornar confirmed, quantas confirmações de blocos subsequentes são necessárias? A resposta não é um número fixo como 1 ou 3; é 2×n. n é a quantidade de falhas de iteração que ocorreram antes. O exemplo dado no whitepaper é o caso de índice de iteração 5, com 2 falhas prévias: nessa situação, é preciso esperar por 4 blocos subsequentes attested/confirmed para que fique realmente “estável”.
Eu li essa regra três vezes antes de ter certeza de que não entendi errado.
Isso significa que dois blocos que “já foram para a cadeia” não têm o mesmo nível de risco — um bloco em que houve um sucesso na primeira tentativa, sem falhas iterativas anteriores, entra quase imediatamente em um estado attested mais estável; já um bloco que passou por várias falhas de iteração até conseguir, precisa esperar por mais blocos subsequentes para atingir a mesma força de resistência à substituição. À primeira vista, ambos parecem “já confirmados”, mas por baixo a fragilidade é em camadas.
Então, agora meu procedimento é este: quando preciso avaliar “se esta transação está realmente estável”, eu não olho apenas para um número de confirmações. Eu vou verificar quantas falhas de iteração o bloco que contém essa transação atravessou. Quanto maior o número de iterações, mais confirmações eu estou disposto a esperar, especialmente em cenários de liquidação de valores altos.
Se você só faz transferências pequenas e frequentes, esses detalhes não têm tanta importância; a janela de risco já é naturalmente curta. Mas se você está fazendo liquidação DvP em nível institucional ou negociando OTC com valores altos, esse valor de n vale a pena você mesmo consultar nos dados do nó da Dusk. #dusk $DUSK @Dusk