Ajudar meu filho com o dever até onze da noite. Ele soltou uma frase — “se o computador travar, o que acontece?” — e eu fiquei sem resposta.
No impulso, pensei em responder “é só reiniciar”, mas de repente lembrei de um trecho do white paper do Dusk que eu estava vasculhando estes dias — eles chamam isso de “modo de emergência”. Em condições normais, para cada bloco acontecer o processo é sempre em três etapas: proposta, validação e aprovação. Se 2/3 das pessoas derem “ok”, passa. Mas se, por alguma razão, a maior parte dos nós cair ou travar, com 16 falhas consecutivas, o sistema muda automaticamente para o modo de emergência. A lógica de timeout simplesmente é desligada, e ele continua rodando até sair o bloco de verdade.
Em outras palavras: não é “reinicia e acabou porque travou”; é “troca o método e aguenta até o fim”.
Essa configuração, em dias comuns, ninguém se preocupa. Ninguém liga se a cadeia está suave ou se o mecanismo de consenso é quão rigoroso. Só que, em cenários financeiros, é diferente. As instituições querem, basicamente, “mesmo em situações extremas, não pode parar”. Isso pesa muito mais do que TPS.
Os incentivos por bloco também foram desenhados com bastante cuidado: 80% para o proponente que faz o bloco, 10% para quem vota e 10% para o próprio protocolo. É tudo pensado para evitar que alguém propositalmente faça as rodadas iniciais falharem para tentar se aproveitar do prêmio.
Eu normalmente não escrevo esse tipo de detalhe, mas quanto mais eu aprofundo, mais acho que, em um projeto, saber explicar claramente “o que fazemos no pior caso” vale mais do que todo o material de marketing com promessas bonitas. Agora, o DuskEVM ainda está na testnet; então o desempenho desse consenso aguentando um cenário extremo ainda não passou por validação em larga escala.
Se vai dar certo ou não, eu não sei. Mas quando um projeto tem planos de contingência expostos abertamente, eu fico disposto a olhar mais de perto.
@Dusk $DUSK
#dusk
No impulso, pensei em responder “é só reiniciar”, mas de repente lembrei de um trecho do white paper do Dusk que eu estava vasculhando estes dias — eles chamam isso de “modo de emergência”. Em condições normais, para cada bloco acontecer o processo é sempre em três etapas: proposta, validação e aprovação. Se 2/3 das pessoas derem “ok”, passa. Mas se, por alguma razão, a maior parte dos nós cair ou travar, com 16 falhas consecutivas, o sistema muda automaticamente para o modo de emergência. A lógica de timeout simplesmente é desligada, e ele continua rodando até sair o bloco de verdade.
Em outras palavras: não é “reinicia e acabou porque travou”; é “troca o método e aguenta até o fim”.
Essa configuração, em dias comuns, ninguém se preocupa. Ninguém liga se a cadeia está suave ou se o mecanismo de consenso é quão rigoroso. Só que, em cenários financeiros, é diferente. As instituições querem, basicamente, “mesmo em situações extremas, não pode parar”. Isso pesa muito mais do que TPS.
Os incentivos por bloco também foram desenhados com bastante cuidado: 80% para o proponente que faz o bloco, 10% para quem vota e 10% para o próprio protocolo. É tudo pensado para evitar que alguém propositalmente faça as rodadas iniciais falharem para tentar se aproveitar do prêmio.
Eu normalmente não escrevo esse tipo de detalhe, mas quanto mais eu aprofundo, mais acho que, em um projeto, saber explicar claramente “o que fazemos no pior caso” vale mais do que todo o material de marketing com promessas bonitas. Agora, o DuskEVM ainda está na testnet; então o desempenho desse consenso aguentando um cenário extremo ainda não passou por validação em larga escala.
Se vai dar certo ou não, eu não sei. Mas quando um projeto tem planos de contingência expostos abertamente, eu fico disposto a olhar mais de perto.
@Dusk $DUSK
#dusk