Hoje me aprofundei no design de consenso do Dusk, e a parte que mais me chamou a atenção não foi a descrição usual de “L1 focada em privacidade”.
Foi como o Dusk decide quem realmente pode participar da produção e validação de um bloco.
O Dusk usa Attestation Succinct, em que os provedores (provisioners) são selecionados por meio de uma sortição determinística. A parte interessante é que a seleção não é simplesmente “vence o maior apostador (staker)”.
Os provedores elegíveis recebem créditos por meio de um processo de extração determinístico, com a seleção ponderada pelo stake. Aqueles selecionados então assumem funções diferentes: um provedor propõe o bloco, enquanto comitês selecionados aleatoriamente validam e ratificam.
O que acho interessante aqui é a separação de responsabilidades.
Um bloco não é aceito apenas porque um nó selecionado o propõe. Ele precisa sobreviver a outra camada de validação do comitê e então à ratificação.
E os votos não são apenas assinaturas individuais “soltas” por aí. O Dusk agrega as assinaturas do comitê em atestações (attestations), tornando a prova de consenso mais compacta e mais fácil de verificar.
Isso me dá uma forma diferente de olhar para o Dusk.
A história da privacidade recebe a maior parte da atenção, mas, por baixo disso, há um design de consenso bastante deliberado tentando equilibrar participação ponderada pelo stake, aleatoriedade, votação por comitê e finalização rápida.
Esse mecanismo subjacente provavelmente vale a pena entender antes de julgar a rede apenas pelo seu discurso em torno do token.
@Dusk_Foundation $DUSK #dusk
Foi como o Dusk decide quem realmente pode participar da produção e validação de um bloco.
O Dusk usa Attestation Succinct, em que os provedores (provisioners) são selecionados por meio de uma sortição determinística. A parte interessante é que a seleção não é simplesmente “vence o maior apostador (staker)”.
Os provedores elegíveis recebem créditos por meio de um processo de extração determinístico, com a seleção ponderada pelo stake. Aqueles selecionados então assumem funções diferentes: um provedor propõe o bloco, enquanto comitês selecionados aleatoriamente validam e ratificam.
O que acho interessante aqui é a separação de responsabilidades.
Um bloco não é aceito apenas porque um nó selecionado o propõe. Ele precisa sobreviver a outra camada de validação do comitê e então à ratificação.
E os votos não são apenas assinaturas individuais “soltas” por aí. O Dusk agrega as assinaturas do comitê em atestações (attestations), tornando a prova de consenso mais compacta e mais fácil de verificar.
Isso me dá uma forma diferente de olhar para o Dusk.
A história da privacidade recebe a maior parte da atenção, mas, por baixo disso, há um design de consenso bastante deliberado tentando equilibrar participação ponderada pelo stake, aleatoriedade, votação por comitê e finalização rápida.
Esse mecanismo subjacente provavelmente vale a pena entender antes de julgar a rede apenas pelo seu discurso em torno do token.
@Dusk_Foundation $DUSK #dusk