Quando estudava a cadeia PoS, o que eu mais me importava eram o APY e o período de lock. Depois que estudei a Succinct Attestation e o Proof-of-Blind Bid da Dusk, comecei a olhar para uma questão mais prática: quando <span>$DUSK </span> já está em estado de Blind Bid, quais condições o usuário precisa cumprir para realmente recuperá-lo.
Eu achava que participar do consenso era, basicamente, apenas fazer staking e delegar. Mas, após estudar os documentos técnicos da Dusk, descobri que isso na verdade é uma conversão de estados. No cenário normal, o usuário trava <span>#dusk </span> no Bid Contract, gera um bid que contém o valor comprometido e um secretHash, e o insere em uma Merkle Tree, junto com dois marcos fundamentais: h{eligibility} (início da participação no consenso) e h{expiration} (altura de expiração). Na fase de Generation, a rede extrai o Generator com proteção de privacidade via Proof-of-Blind Bid; a identidade do ofertante permanece sempre embaralhada. Ao mesmo tempo, o Provisioner entra no comitê por sorteio determinístico e, nas fases de Reduction e Agreement, realiza duas rodadas de votação sobre os blocos candidatos para alcançar a finalização estatística.
O que realmente me preocupa é que enviar um Bid não significa que você possa sair a qualquer momento. Porque o Bid Contract define que, antes de h{expiration} ser atingida, o usuário não consegue iniciar a operação F^{WithdrawBid}. Além disso, a Dusk separa os papéis: você pode ser um Generator (competindo por direitos de produção de bloco via Blind Bid) ou um Provisioner (participando da validação com um staking travado no Stake Contract). Se você for um Provisioner que faz dupla assinatura ou age maliciosamente, qualquer pessoa pode chamar a função F^{Slash} do Stake Contract para denunciar, e seu staking será parcialmente penalizado e confiscado. Ou seja, participar do consenso não é um botão; é uma janela de tempo condicionada às regras do protocolo — e a sua <span>@Dusk </span> está, antes da expiração, tanto protegendo a rede quanto assumindo o risco de punição.
Por isso, no meu entendimento, o que a Dusk realmente resolve é: a transparência da eleição de líderes no consenso PoS e o problema de MEV; o protocolo então “monta” esses estados usando Blind Bid, sorteio determinístico, separação de papéis e finalização estatística. O custo também é bem evidente: os usuários deixam de ser apenas “stakers de DUSK esperando os ganhos”, e passam a precisar entender a relação entre Bid, Stake, Generator, Provisioner e Slashing.
O que eu vou observar continuamente não é apenas quão fácil é fazer a entrada no staking, mas se usuários comuns realmente entendem o que estão aguardando quando participam do consenso.
Eu achava que participar do consenso era, basicamente, apenas fazer staking e delegar. Mas, após estudar os documentos técnicos da Dusk, descobri que isso na verdade é uma conversão de estados. No cenário normal, o usuário trava <span>#dusk </span> no Bid Contract, gera um bid que contém o valor comprometido e um secretHash, e o insere em uma Merkle Tree, junto com dois marcos fundamentais: h{eligibility} (início da participação no consenso) e h{expiration} (altura de expiração). Na fase de Generation, a rede extrai o Generator com proteção de privacidade via Proof-of-Blind Bid; a identidade do ofertante permanece sempre embaralhada. Ao mesmo tempo, o Provisioner entra no comitê por sorteio determinístico e, nas fases de Reduction e Agreement, realiza duas rodadas de votação sobre os blocos candidatos para alcançar a finalização estatística.
O que realmente me preocupa é que enviar um Bid não significa que você possa sair a qualquer momento. Porque o Bid Contract define que, antes de h{expiration} ser atingida, o usuário não consegue iniciar a operação F^{WithdrawBid}. Além disso, a Dusk separa os papéis: você pode ser um Generator (competindo por direitos de produção de bloco via Blind Bid) ou um Provisioner (participando da validação com um staking travado no Stake Contract). Se você for um Provisioner que faz dupla assinatura ou age maliciosamente, qualquer pessoa pode chamar a função F^{Slash} do Stake Contract para denunciar, e seu staking será parcialmente penalizado e confiscado. Ou seja, participar do consenso não é um botão; é uma janela de tempo condicionada às regras do protocolo — e a sua <span>@Dusk </span> está, antes da expiração, tanto protegendo a rede quanto assumindo o risco de punição.
Por isso, no meu entendimento, o que a Dusk realmente resolve é: a transparência da eleição de líderes no consenso PoS e o problema de MEV; o protocolo então “monta” esses estados usando Blind Bid, sorteio determinístico, separação de papéis e finalização estatística. O custo também é bem evidente: os usuários deixam de ser apenas “stakers de DUSK esperando os ganhos”, e passam a precisar entender a relação entre Bid, Stake, Generator, Provisioner e Slashing.
O que eu vou observar continuamente não é apenas quão fácil é fazer a entrada no staking, mas se usuários comuns realmente entendem o que estão aguardando quando participam do consenso.