#dusk $DUSK @Dusk $DUSK
Proposta, Validação, Ratificação: o caminho em três etapas de Dusk até um bloco final
Eu continuei assumindo que a finalização do bloco em Dusk funcionava como um único voto — propor, confirmar, pronto.
na verdade, são três etapas separadas, e eu tive que passar por cada uma para entender por quê.
na etapa de Proposta, escolhe-se um provedor, via sorteio determinístico, para gerar um bloco candidato e transmiti-lo. se nada chegar antes do tempo limite, essa iteração simplesmente falha — não há candidato, e, pelo que consigo ver na documentação, não existe nenhum gerador de fallback nessas etapas.
eu rastreei o que acontece em seguida. a saída alimenta a etapa de Validação: um comitê novo, também selecionado aleatoriamente, verifica o candidato em relação ao topo atual da cadeia e vota Válido ou Inválido. um quórum precisa de dois terços votando Válido, ou de maioria simples votando Inválido — qualquer um desses limiares encerra a etapa.
terceira etapa, e esta é a que eu quase não entendi: Ratificação. um outro comitê, votando especificamente se a Validação atingiu, de fato, um quórum real — não novamente com base no conteúdo do bloco. a mesma regra de dois terços ou maioria também se aplica aqui.
três comitês, três julgamentos separados — eu não consegui encontrar nenhuma etapa repetindo um trabalho que a anterior já tinha feito.
o que me chamou a atenção é o quanto essa sequência foi escrutinada antes do mainnet. A Dusk realizou dez auditorias em toda a sua pilha, com mais de duzentas páginas de relatórios. uma dessas dez, pela Oak Security, cobriu especificamente a SA, destacando problemas relacionados a incentivos de slashing e lógica de votação — todos críticos e resolvidos antes do lançamento.
então “finalizar um bloco” não é uma única decisão, pelo que entendo. são três verificações verificadas independentemente, empilhadas em sequência, e cada uma pode reiniciar o processo — até cinquenta iterações por rodada — se não passar.
esse nível de escrutínio antes do lançamento realmente reduz o risco aqui, ou significa apenas que qualquer falha que passe fica ainda mais difícil de encontrar depois?
Proposta, Validação, Ratificação: o caminho em três etapas de Dusk até um bloco final
Eu continuei assumindo que a finalização do bloco em Dusk funcionava como um único voto — propor, confirmar, pronto.
na verdade, são três etapas separadas, e eu tive que passar por cada uma para entender por quê.
na etapa de Proposta, escolhe-se um provedor, via sorteio determinístico, para gerar um bloco candidato e transmiti-lo. se nada chegar antes do tempo limite, essa iteração simplesmente falha — não há candidato, e, pelo que consigo ver na documentação, não existe nenhum gerador de fallback nessas etapas.
eu rastreei o que acontece em seguida. a saída alimenta a etapa de Validação: um comitê novo, também selecionado aleatoriamente, verifica o candidato em relação ao topo atual da cadeia e vota Válido ou Inválido. um quórum precisa de dois terços votando Válido, ou de maioria simples votando Inválido — qualquer um desses limiares encerra a etapa.
terceira etapa, e esta é a que eu quase não entendi: Ratificação. um outro comitê, votando especificamente se a Validação atingiu, de fato, um quórum real — não novamente com base no conteúdo do bloco. a mesma regra de dois terços ou maioria também se aplica aqui.
três comitês, três julgamentos separados — eu não consegui encontrar nenhuma etapa repetindo um trabalho que a anterior já tinha feito.
o que me chamou a atenção é o quanto essa sequência foi escrutinada antes do mainnet. A Dusk realizou dez auditorias em toda a sua pilha, com mais de duzentas páginas de relatórios. uma dessas dez, pela Oak Security, cobriu especificamente a SA, destacando problemas relacionados a incentivos de slashing e lógica de votação — todos críticos e resolvidos antes do lançamento.
então “finalizar um bloco” não é uma única decisão, pelo que entendo. são três verificações verificadas independentemente, empilhadas em sequência, e cada uma pode reiniciar o processo — até cinquenta iterações por rodada — se não passar.
esse nível de escrutínio antes do lançamento realmente reduz o risco aqui, ou significa apenas que qualquer falha que passe fica ainda mais difícil de encontrar depois?
Reduces the risk
50%
Harder to find later
17%
Depends on the audit
17%
Not sure yet
16%
6 Votos • Votação encerrada