Blockchains modulares: acompanhe execução, dados e liquidação
Um blockchain modular divide as responsabilidades entre componentes, em vez de solicitar a um sistema que execute todas as tarefas. Isto pode fazer com que a descrição da rede pareça simples: a execução acontece aqui, os dados vão para lá e a liquidação ocorre noutro local. A questão importante é o que cada componente realmente garante.
Este artigo compara funções arquitetónicas, e não preços simbólicos ou uma classificação de projetos. Um design modular não implica automaticamente menor risco, maiores retornos de investimento ou segurança idêntica em todas as implementações.
Separe as funções antes de comparar sistemas
A execução aplica regras de transação e calcula uma mudança de estado proposta. A disponibilidade de dados diz respeito à disponibilização da informação necessária para verificar o sistema. A liquidação define como o protocolo aceita compromissos criptográficos sobre o estado da cadeia (state commitments), provas ou contestações. O consenso determina a ordem acordada ou o historial aceite dentro de um sistema.
Estas funções podem sobrepor-se ou ser distribuídas de diferentes formas. Os rótulos dos projetos não são suficientes: uma rede pode auto-intitular-se de modular, mantendo ao mesmo tempo um controlo significativo num sequenciador, chave de atualização ou comité de dados. Desenhe o mapa de dependência real em vez de assumir que todas as redes modulares partilham um modelo de confiança.
A documentação de disponibilidade de dados do Ethereum explica porque é que a verificação depende do acesso aos dados de transação e porque é que os clientes leves e os rollups necessitam de garantias apropriadas. O acesso aos dados é uma questão diferente de saber se uma computação executada está correta.
Siga uma transação hipotética
Imagine que um utilizador envia uma transação para uma rede de execução. Um sequenciador inclui-o num lote. O sistema disponibiliza os dados necessários utilizando a camada de dados escolhida e submete um compromisso criptográfico sobre o estado da cadeia (state commitment), com o mecanismo de verificação exigido pelo seu design, a uma camada de liquidação.
O utilizador poderá ver uma confirmação antecipada antes de cada etapa atingir o seu estado final. Registe o que cada estado significa: recebido, sequenciado, executado, dados publicados, prova aceite ou janela de disputa concluída. Não rotule o reconhecimento mais antigo como liquidação final, a menos que o protocolo apoie esta interpretação.
Este exemplo descreve funções em vez de prescrever uma sequência universal. Diferentes rollups e sistemas modulares podem combinar passos ou utilizar diferentes disposições de prova e finalidade.
Pergunte o que acontece quando um componente falha
Se um sequenciador parar, os utilizadores poderão enviar transações de outra forma e em que condições? Se um serviço de dados retém informação, quem a deteta e o que podem os utilizadores verificar? Se uma camada de liquidação estiver congestionada, como serão afetados os compromissos ou as retiradas?
Responda a estas questões a partir da documentação atual, incluindo os procedimentos de emergência e os controlos administrativos. Um substituto descrito num guião não é necessariamente operacional. Uma rede que continue a exibir saldos pode ainda ter uma capacidade reduzida de aceitar transações ou concluir levantamentos.
Reveja as dependências da ponte separadamente. Um token que aparece em duas redes não significa que a rota de transferência herde todas as propriedades de segurança de ambas as cadeias.
Compare o custo completo e a experiência do utilizador
Uma baixa taxa de execução é apenas parte do custo da transação. As operações de publicação, liquidação, ponte e retirada de dados podem acrescentar encargos ou atrasos. Compare ações equivalentes durante o mesmo período e explique quem paga que custo.
Meça toda a rota relevante para o utilizador: entrada, execução, confirmação, retirada e retorno ao ativo ou rede desejada. Um valor de referência que abranja apenas um passo não deve ser apresentado como o preço de uma viagem completa de ida e volta. A poupança de custos também pode variar de acordo com a procura e as condições da camada de dados.
Utilize uma lista de verificação de dependências
Para cada sistema, registe as regras de execução, a autoridade ordenante, a localização dos dados, o mecanismo de verificação, o destino de liquidação, os controlos de atualização e o procedimento de saída. Assinale quais as reivindicações que estão ativas e quais estão planeadas. Inclua as fontes e a data verificada, pois as definições arquitetónicas podem sofrer alterações.
Para um problema relacionado, mas distinto, leia a comparação de mensagens entre cadeias: segue instruções entre cadeias, enquanto este guia segue a divisão do trabalho dentro de uma arquitetura.
O projeto de engenharia de um protocolo e os direitos económicos do seu token são questões de investigação distintas. Verifique a utilidade do token e a disponibilidade real do mercado de forma independente através da documentação oficial e da página de mercados OrangeX, em vez de tratar uma afirmação de escala como uma conclusão comercial.
