Voltei à documentação do Dusk ( @Dusk ) na noite passada, e quanto mais eu me aprofundava no consenso, mais interessantes os casos de falha se tornavam.
No começo, o modo de emergência parecia um simples backup. Mas por que o Dusk precisa disso se o protocolo normal já pode tentar novamente iterações que falham? A documentação explica que, após falhas repetidas, o protocolo pode manter iterações em execução até que o consenso seja alcançado. Isso me faz pensar em quanto a vivacidade está sendo priorizada em relação à eficiência durante condições extremas de rede.
Depois vem a questão do fork. Como dois blocos candidatos podem chegar a consenso no mesmo round? O Dusk usa números de iteração e fallback para resolver isso, mas um bloco com iteração maior ainda pode ser revertido. Para liquidação financeira, essa distinção parece importante.
Também reparei na estrutura de recompensas. Os geradores recebem a maior parte da recompensa do bloco, enquanto os eleitores recebem uma parcela separada. Isso fez mais sentido quando considerei o problema de incentivos: o que impede um gerador futuro de se beneficiar quando iterações anteriores falham?
O sistema de falhas adiciona outra camada. Por que separar falhas menores de maiores? Suspensão e soft slashing parecem projetados de forma diferente de hard slashing para comportamentos graves, como dupla votação ou blocos inválidos.
Por fim, Moonlight e Phoenix me fizeram repensar a camada de transações. Por que manter tanto um modelo transparente baseado em contas quanto um modelo de privacidade baseado em UTXO?
Esse design duplo cria flexibilidade útil ou apenas mais complexidade? E, à medida que o Dusk cresce, onde pode ficar mais difícil preservar a descentralização e a segurança?
@Dusk_Foundation #dusk $DUSK
No começo, o modo de emergência parecia um simples backup. Mas por que o Dusk precisa disso se o protocolo normal já pode tentar novamente iterações que falham? A documentação explica que, após falhas repetidas, o protocolo pode manter iterações em execução até que o consenso seja alcançado. Isso me faz pensar em quanto a vivacidade está sendo priorizada em relação à eficiência durante condições extremas de rede.
Depois vem a questão do fork. Como dois blocos candidatos podem chegar a consenso no mesmo round? O Dusk usa números de iteração e fallback para resolver isso, mas um bloco com iteração maior ainda pode ser revertido. Para liquidação financeira, essa distinção parece importante.
Também reparei na estrutura de recompensas. Os geradores recebem a maior parte da recompensa do bloco, enquanto os eleitores recebem uma parcela separada. Isso fez mais sentido quando considerei o problema de incentivos: o que impede um gerador futuro de se beneficiar quando iterações anteriores falham?
O sistema de falhas adiciona outra camada. Por que separar falhas menores de maiores? Suspensão e soft slashing parecem projetados de forma diferente de hard slashing para comportamentos graves, como dupla votação ou blocos inválidos.
Por fim, Moonlight e Phoenix me fizeram repensar a camada de transações. Por que manter tanto um modelo transparente baseado em contas quanto um modelo de privacidade baseado em UTXO?
Esse design duplo cria flexibilidade útil ou apenas mais complexidade? E, à medida que o Dusk cresce, onde pode ficar mais difícil preservar a descentralização e a segurança?
@Dusk_Foundation #dusk $DUSK