#dusk $DUSK @Dusk
O que chamou minha atenção não foi o lado de zero knowledge de Dusk que recebe a maior parte da atenção; foi um detalhe menor sobre como um bloco de fato se torna final.
Eu queria entender como a Succinct Attestation, o protocolo de consenso de proof-of-stake baseado em comitês permissionless da DuskDS, confirma uma transação na prática, já que “instant settlement” é jogado ao ar com alguma leveza neste espaço.
Cada rodada passa por três etapas: um proponente propõe e transmite um bloco candidato, um comitê o valida e um segundo comitê ratifica essa validação e finaliza o bloco. Só depois que ambos os comitês concordam é que o bloco segue adiante.
O interessante é que @Dusk não trata a finalidade como um evento binário. Um bloco é Aceito quando passa por todas as três etapas. É Confirmado uma vez que blocos posteriores se baseiam nele. É Estável quando está suficientemente enterrado e, finalmente, Final — determinístico e garantido criptograficamente, o que significa que ele não pode ser revertido.
Para liquidação regulada, essa distinção em etapas importa mais do que a velocidade bruta. Um custodiante não precisa apenas de uma transação rápida: ele precisa de um ponto definido em que a irreversibilidade possa ser provada, não apenas assumida.
O que eu gostaria que fosse esclarecido é o comportamento sob carga sustentada. Dois comitês separados concordando adiciona uma etapa de coordenação que cadeias de um único proponente evitam. À medida que o conjunto de proponentes e a distribuição de participação crescem, a ratificação continua rápida ou a própria coordenação do comitê vira o gargalo?
A documentação descreve as fases e a divisão de recompensas 70% para o proponente e 5%/5% para os comitês de validação e ratificação. O que ela não esclarece é um teto de throughput sob congestionamento real da rede — apenas comportamento de testnet.
Alguém já viu dados de seleção de comitê ou de tempo de finalidade do Dusk sob carga real sustentada de transações, e não apenas números de rede ociosa?
$DUSK #Dusk
O que chamou minha atenção não foi o lado de zero knowledge de Dusk que recebe a maior parte da atenção; foi um detalhe menor sobre como um bloco de fato se torna final.
Eu queria entender como a Succinct Attestation, o protocolo de consenso de proof-of-stake baseado em comitês permissionless da DuskDS, confirma uma transação na prática, já que “instant settlement” é jogado ao ar com alguma leveza neste espaço.
Cada rodada passa por três etapas: um proponente propõe e transmite um bloco candidato, um comitê o valida e um segundo comitê ratifica essa validação e finaliza o bloco. Só depois que ambos os comitês concordam é que o bloco segue adiante.
O interessante é que @Dusk não trata a finalidade como um evento binário. Um bloco é Aceito quando passa por todas as três etapas. É Confirmado uma vez que blocos posteriores se baseiam nele. É Estável quando está suficientemente enterrado e, finalmente, Final — determinístico e garantido criptograficamente, o que significa que ele não pode ser revertido.
Para liquidação regulada, essa distinção em etapas importa mais do que a velocidade bruta. Um custodiante não precisa apenas de uma transação rápida: ele precisa de um ponto definido em que a irreversibilidade possa ser provada, não apenas assumida.
O que eu gostaria que fosse esclarecido é o comportamento sob carga sustentada. Dois comitês separados concordando adiciona uma etapa de coordenação que cadeias de um único proponente evitam. À medida que o conjunto de proponentes e a distribuição de participação crescem, a ratificação continua rápida ou a própria coordenação do comitê vira o gargalo?
A documentação descreve as fases e a divisão de recompensas 70% para o proponente e 5%/5% para os comitês de validação e ratificação. O que ela não esclarece é um teto de throughput sob congestionamento real da rede — apenas comportamento de testnet.
Alguém já viu dados de seleção de comitê ou de tempo de finalidade do Dusk sob carga real sustentada de transações, e não apenas números de rede ociosa?
$DUSK #Dusk