Eu estava analisando as mudanças no protocolo feitas pela #Dusk e um detalhe em Boreas chamou minha atenção.
Boreas não era um recurso.
Boreas era sobre garantir que a rede interprete as transações da maneira certa.
Boreas introduziu limites entre como transações são aceitas dos clientes representados dentro do Rusk e armazenadas no ledger.
Isso soa como engenharia.
Acho que Boreas é mais importante do que parece.
Uma transação passa por estágios antes de se tornar parte dos dados da cadeia histórica: ingresso, tratamento na mempool, produção de blocos, validação de consenso e, por fim, replay.
Se partes diferentes do nó interpretarem os bytes de forma diferente, o problema não é apenas uma transação falha.
Isso pode virar um problema de consistência.
Boreas resolve isso usando decodificação consciente de versão na fronteira de rede e canonizando transações antes de serem comprometidas em blocos.
A parte interessante é que a Dusk também mantém decodificadores para que blocos mais antigos ainda possam ser replayados corretamente.
Então o design não é simplesmente: "alterar o formato da transação."
É mais próximo de: "alterar as regras sem tornar a história antiga ambígua."
Isso é um requisito para uma rede esperada para lidar com infraestrutura financeira de longa duração.
Isso me faz olhar para atualizações de protocolo de outra forma.
Uma hard fork bem-sucedida não é apenas sobre adicionar novas capacidades.
Também é sobre garantir que cada camada concorde sobre o que a transação significa.
O que estou observando agora é se esse tipo de disciplina de protocolo permanece robusta à medida que a Dusk adiciona caminhos de execução e aplicações financeiras.
Porque a complexidade não desaparece quando você modulariza uma blockchain.
Ela só muda para as fronteiras, entre os módulos.
#dusk $DUSK @Dusk
Boreas não era um recurso.
Boreas era sobre garantir que a rede interprete as transações da maneira certa.
Boreas introduziu limites entre como transações são aceitas dos clientes representados dentro do Rusk e armazenadas no ledger.
Isso soa como engenharia.
Acho que Boreas é mais importante do que parece.
Uma transação passa por estágios antes de se tornar parte dos dados da cadeia histórica: ingresso, tratamento na mempool, produção de blocos, validação de consenso e, por fim, replay.
Se partes diferentes do nó interpretarem os bytes de forma diferente, o problema não é apenas uma transação falha.
Isso pode virar um problema de consistência.
Boreas resolve isso usando decodificação consciente de versão na fronteira de rede e canonizando transações antes de serem comprometidas em blocos.
A parte interessante é que a Dusk também mantém decodificadores para que blocos mais antigos ainda possam ser replayados corretamente.
Então o design não é simplesmente: "alterar o formato da transação."
É mais próximo de: "alterar as regras sem tornar a história antiga ambígua."
Isso é um requisito para uma rede esperada para lidar com infraestrutura financeira de longa duração.
Isso me faz olhar para atualizações de protocolo de outra forma.
Uma hard fork bem-sucedida não é apenas sobre adicionar novas capacidades.
Também é sobre garantir que cada camada concorde sobre o que a transação significa.
O que estou observando agora é se esse tipo de disciplina de protocolo permanece robusta à medida que a Dusk adiciona caminhos de execução e aplicações financeiras.
Porque a complexidade não desaparece quando você modulariza uma blockchain.
Ela só muda para as fronteiras, entre os módulos.
#dusk $DUSK @Dusk
