A maioria das cadeias de prova de participação faz uma coisa depois que um bloco é proposto: um comitê vota e, se votos suficientes chegarem, o bloco conta.
@Dusk faz isso duas vezes, e a segunda rodada é a que ninguém explica.
A Attestation Succinta (Succinct Attestation) executa cada rodada em três etapas. Um provisionador propõe um bloco candidato. Um comitê aleatoriamente selecionado o valida. Depois, um segundo comitê ratifica — e o que ele confirma não é o bloco. Ele confirma o resultado da validação.
Essa diferença levou um tempo para eu enxergar direito.
Validação responde "este bloco é válido?" Ratificação responde "a rede realmente concordou que ele foi validado?" São perguntas diferentes, e a segunda é onde existe a finalização determinística. Sem isso, você tem a opinião de um comitê, propagada por uma rede, chegando a nós diferentes em tempos diferentes. Com isso, você tem um registro atestado de que o acordo em si aconteceu.
Essa é a diferença entre "este bloco é muito provavelmente final" e "este bloco é final". Para uma cadeia que mira liquidação de valores mobiliários, essa lacuna não é filosófica. É a diferença entre uma garantia de liquidação e uma estimativa de liquidação.
O custo também é real. Dois comitês significam duas rodadas de assinaturas, duas chances de a participação falhar e divisões de recompensa que refletem isso — validação e ratificação cada uma recebe uma fatia da recompensa do bloco, separada do gerador do bloco.
Se essa rodada extra vale a latência e o overhead de coordenação é exatamente o tipo de coisa que uma auditoria não consegue te dizer. A revisão da Oak Security considerou o protocolo bem projetado. “Bem projetado” e “adequado a carga real” são reivindicações diferentes.
Uma pergunta genuína para os operadores de nós aqui: alguém mediu com que frequência a etapa que trava é a ratificação, e não a validação?

#dusk $DUSK #block