Passei algum tempo analisando as mudanças mais recentes no protocolo da Dusk, e um detalhe pareceu mais importante do que um anúncio de nova funcionalidade:
A Dusk está tornando o tratamento de transações consciente das versões do protocolo.
A Boreas introduziu o tratamento canônico de transações, consciente de versão, junto com regras de precificação e implantação cientes de forks na VM.
Isso soa como engenharia de backend.
Mas eu acho que importa muito mais do que isso.
Uma blockchain não permanece inalterada após o lançamento. Os formatos de transação evoluem. As regras da VM mudam. A precificação de gas pode mudar. Novos hard forks introduzem novos significados.
A parte difícil é fazer com que a rede entenda a diferença entre o que era válido em um protocolo mais antigo e o que é válido no atual.
É aí que a Boreas fica interessante.
A implementação da Dusk separa os dados canônicos de transações dos envelopes do ledger usados para persistência e processamento. O código da Rusk também adiciona um tratamento explícito para diferentes formatos de transações de cada era do protocolo, em vez de tratar cada transação histórica como se tivesse vindo do mesmo conjunto de regras.
Para mim, isso tem menos a ver com adicionar funcionalidades e mais com tornar as atualizações de protocolo mais seguras de operar.
Porque infraestrutura financeira tem uma exigência diferente de uma demo chain simples:
as transações antigas não desaparecem só porque o protocolo avançou.
O teste de estresse ainda está em aberto, porém.
Mais lógica consciente de versão também significa mais estados de protocolo, regras de compatibilidade e casos de borda que desenvolvedores e operadores de nós precisam acertar.
Então a pergunta que estou acompanhando é:
A Dusk consegue continuar evoluindo suas regras de execução sem tornar a complexidade histórica e operacional difícil demais de gerenciar?
Isso talvez não seja a parte mais visível de uma blockchain.
Mas, para infraestrutura pensada em torno de mercados financeiros, eu acho que é uma das partes que vale a pena observar.
#dusk $DUSK @Dusk
A Dusk está tornando o tratamento de transações consciente das versões do protocolo.
A Boreas introduziu o tratamento canônico de transações, consciente de versão, junto com regras de precificação e implantação cientes de forks na VM.
Isso soa como engenharia de backend.
Mas eu acho que importa muito mais do que isso.
Uma blockchain não permanece inalterada após o lançamento. Os formatos de transação evoluem. As regras da VM mudam. A precificação de gas pode mudar. Novos hard forks introduzem novos significados.
A parte difícil é fazer com que a rede entenda a diferença entre o que era válido em um protocolo mais antigo e o que é válido no atual.
É aí que a Boreas fica interessante.
A implementação da Dusk separa os dados canônicos de transações dos envelopes do ledger usados para persistência e processamento. O código da Rusk também adiciona um tratamento explícito para diferentes formatos de transações de cada era do protocolo, em vez de tratar cada transação histórica como se tivesse vindo do mesmo conjunto de regras.
Para mim, isso tem menos a ver com adicionar funcionalidades e mais com tornar as atualizações de protocolo mais seguras de operar.
Porque infraestrutura financeira tem uma exigência diferente de uma demo chain simples:
as transações antigas não desaparecem só porque o protocolo avançou.
O teste de estresse ainda está em aberto, porém.
Mais lógica consciente de versão também significa mais estados de protocolo, regras de compatibilidade e casos de borda que desenvolvedores e operadores de nós precisam acertar.
Então a pergunta que estou acompanhando é:
A Dusk consegue continuar evoluindo suas regras de execução sem tornar a complexidade histórica e operacional difícil demais de gerenciar?
Isso talvez não seja a parte mais visível de uma blockchain.
Mas, para infraestrutura pensada em torno de mercados financeiros, eu acho que é uma das partes que vale a pena observar.
#dusk $DUSK @Dusk
