Tenho lido mais a fundo o whitepaper da Dusk ultimamente e a parte para a qual eu continuo voltando não é, na verdade, o lado da privacidade.

É o design de consenso.

@Dusk usa Succinct Attestation com um modelo PoS permissionless baseado em comitês. Você precisa de 1.000 DUSK para fazer stake, cada época dura 2.160 blocos e o poder de voto é ponderado pelo stake por meio de 64 créditos de comitê.

A última parte chamou minha atenção.

Porque, uma vez que o poder de voto é ponderado pelo stake, a questão não é apenas se a rede consegue chegar a um consenso. É como esse poder é distribuído.

Os limiares também são interessantes. O válido precisa de 2/3, enquanto o inválido, NoCandidate e NoQuorum precisam de 1/2 + 1. Após 16 iterações falhas, o protocolo pode entrar em modo de emergência.

No papel, isso parece uma forma sensata de proteger a vivacidade.

Mas isso me fez pensar sobre o outro lado desse trade-off: quanta pressão o sistema consegue absorver antes que, ao preservar a vivacidade, crie-se um risco diferente?

O desenho de incentivos também é deliberado: 80% para o gerador de blocos, 10% para o comitê de votação e 10% para #Dusk , com comportamentos sérios como votação dupla sujeitos a slashing rígido.

Depois há a camada de transações.

Moonlight é baseado em conta e público, enquanto Phoenix usa notas estilo UTXO, árvores Merkle, nullifiers e provas ZK.

Quanto mais eu olho para o design, mais a pergunta interessante não é se cada componente funciona individualmente.

É se eles ainda funcionam bem juntos sob estresse.

O crédito ponderado pelo stake cria concentração demais ao longo do tempo? E se uma grande parte do conjunto de validadores falhar, o modo de emergência é robusto o suficiente sem abrir outro caminho para forks?

Essa é a parte da arquitetura da Dusk que ainda quero entender melhor.
$DUSK $TMX $DEBIT #XRPRallies44%InAWeek #CryptoFearGreedIndexHits74 #USStocksCloseHigherNvidiaGains2% #USBitcoinETFsExtendInflowsToSixthDay