Voltei ontem à documentação do @Dusk , especificamente a seção sobre o consenso Succinct Attestation. Trata-se de uma configuração permissionless baseada em comitês para prova de participação, operada por provisioners....qualquer pessoa que bloqueie pelo menos 1000 DUSK como stake.

Uma stake é apenas o valor mais a altura do bloco em que foi incluída. A elegibilidade não é imediata. Há um período de maturidade calculado como M = 2 × epoch − (height mod epoch), e o epoch atualmente é de 2160 blocos. Só depois dessa janela de maturidade, e se o valor atender ao mínimo, é que a stake entra na loteria determinística de sortition, que escolhe o gerador do bloco e os comitês de votação para cada rodada.

O processo em si roda em rodadas e iterações. Cada iteração tem três etapas: proposta (um provisioner é selecionado para apresentar um bloco candidato), validação (um comitê vota Valid, Invalid ou NoCandidate, necessitando de uma supermaioria de 2/3 para Valid ou de maioria simples para Invalid) e ratificação (um comitê recém-formado confirma o resultado). Uma rodada pode avançar por até 50 iterações antes de falhar.

O que ainda estou pensando é como a sortition não interativa e os comitês rotativos realmente afetam a descentralização de longo prazo e o risco de captura de comitê. Os parâmetros fixos....mínimo de 1000 DUSK, epochs de 2160 blocos, limite de 50 iterações
....parecem deliberados, mas eu não encontrei uma discussão clara sobre como eles poderiam ser ajustados depois ou qual processo de governança controlaria isso.

Curioso para saber como outras pessoas interpretam as premissas de segurança em torno dos comitês de votação e do atraso de maturidade. O design parece robusto para você, ou há casos-limite que eu não esteja considerando?

#dusk $DUSK