The real test for any network starts after the launch narrative cools down. Can builders keep building, can the network handle stress, and can usage become sustainable?
Publicar
--
AlphaLQ
·
--
Em AltaUm resultado posterior nem sempre é o resultado que deveria vencer.
Imagine dois trens saindo da mesma estação por rotas diferentes. Um parte mais cedo, mas o outro chega primeiro.
Você automaticamente decide que a chegada posterior deve substituir a anterior?
Foi isso que tornou interessante, para mim, o design de resolução de fork do @Dusk .
A Attestação Concisa funciona por iterações. Quando uma iteração não alcança o quórum exigido, o consenso pode continuar para a próxima. Se a iteração 2 e a iteração 5 produzirem candidatos que alcancem quórum, a Dusk dá prioridade à iteração mais baixa — a posição anterior no processo de consenso.
É aqui que a finalização em fluxo (rolling finality) se torna importante. Um quórum posterior não torna automaticamente o candidato mais recente decisivo; iterações anteriores ainda importam para determinar qual candidato recebe prioridade.
E há uma segunda pergunta de ordem que acho interessante: se iterações posteriores não substituem automaticamente as anteriores que ainda não foram resolvidas, os validadores poderiam ter incentivo para ajudar a resolver as iterações anteriores em vez de apenas esperar pelo candidato mais novo?
Para liquidação financeira, essa distinção importa: não basta chegar a um acordo — você precisa de uma regra determinística para definir qual acordo se torna final.
É essa a parte do design de consenso da Dusk que eu quero continuar acompanhando.
$DUSK #dusk #bullish
Imagine dois trens saindo da mesma estação por rotas diferentes. Um parte mais cedo, mas o outro chega primeiro.
Você automaticamente decide que a chegada posterior deve substituir a anterior?
Foi isso que tornou interessante, para mim, o design de resolução de fork do @Dusk .
A Attestação Concisa funciona por iterações. Quando uma iteração não alcança o quórum exigido, o consenso pode continuar para a próxima. Se a iteração 2 e a iteração 5 produzirem candidatos que alcancem quórum, a Dusk dá prioridade à iteração mais baixa — a posição anterior no processo de consenso.
É aqui que a finalização em fluxo (rolling finality) se torna importante. Um quórum posterior não torna automaticamente o candidato mais recente decisivo; iterações anteriores ainda importam para determinar qual candidato recebe prioridade.
E há uma segunda pergunta de ordem que acho interessante: se iterações posteriores não substituem automaticamente as anteriores que ainda não foram resolvidas, os validadores poderiam ter incentivo para ajudar a resolver as iterações anteriores em vez de apenas esperar pelo candidato mais novo?
Para liquidação financeira, essa distinção importa: não basta chegar a um acordo — você precisa de uma regra determinística para definir qual acordo se torna final.
É essa a parte do design de consenso da Dusk que eu quero continuar acompanhando.
$DUSK #dusk #bullish
Aviso legal: inclui opiniões de terceiros. Não constitui aconselhamento. A Binance AI pode ser utilizada sem garantia. Consulta os Termos e Condições.