Evolução Modular de Rollups de Layer2

Este artigo pretende discutir o desenvolvimento e evolução de Rollup de Layer2 a partir de uma perspectiva evolutiva, abordando principalmente as seguintes questões:

1. Como funciona o Rollup?
2. Evolução modular do Rollup
3. As possibilidades trazidas pelo Modular
4. Tendências tecnológicas em aplicação modular
5. Conclusão

Como funciona

O "trilema" da blockchain tem sido sempre um problema difícil no setor. Se considerarmos que uma blockchain de Layer1 deve primeiro garantir a "descentralização" e a "segurança", a migração da solução de "escalabilidade" para fora da Layer1 é uma escolha natural, daí a Layer2. O novo problema é como garantir a segurança da Layer2 através da Layer1.

Inicialmente, houve uma ideia de escrever periodicamente a raiz da árvore de estado do aplicativo de Layer2 para a Layer1, que poderia verificar o estado do aplicativo através da prova de estado, semelhante à prova de reserva do CEX. Entretanto, terceiros não podem verificar se duas transições de estado estão corretas de maneira pública usando esta abordagem.

Para explorar melhor este problema, vamos resumi-lo. O estado de qualquer programa pode ser expresso através de uma fórmula de transição de estado:

σt+1 ≡ Υ(σt, T)

Esta fórmula vem do Yellow Paper (Papel Amarelo) da Ethereum, mas pode representar qualquer programa. Aqui, Υ representa o programa, e σ representa o estado. O estado σt+1 é calculado pelo programa Y através do estado σt e da transação T. A transação T representa o input para o programa. A qualquer momento, se σt é determinístico, Y é determinístico e T é determinístico. Então σt+1 é determinístico.

Assim, para proporcionar verificabilidade pública, o importante é que Y esteja disponível ao público, que todos os históricos T estejam disponíveis ao público e que sua ordem seja determinada. Os estados intermediários podem ser recalculados através de Y e T. Podemos conseguir a disponibilidade pública do programa através de código aberto, mas como garantir a disponibilidade pública de T é outra questão, que introduz o conceito de disponibilidade de dados (DA).

A disponibilidade de dados requer um livro razão (ledger) publicamente disponível e imutável para registrar as transações do aplicativo. O livro-razão da blockchain é um sistema que vem à mente naturalmente. Portanto, escrever as transações de Layer2 de volta para Layer1 para garantir a disponibilidade de dados é a origem do nome Rollup.

Assim, é necessário uma função no sistema Layer2 para coletar as transações dos usuários, ordená-las e escrevê-las no DA. Esta função é chamada de Sequencer. A sequência de transações aqui é chamada de Canonical Transaction Chain (Cadeia de Transações Canônicas).

Com a disponibilidade de dados garantida, todos podem obter o estado final, rodando o programa para executar as transações. Entretanto, ainda não se chegou a um consenso, pois todos têm dúvidas se os resultados obtidos por eles são consistentes com os de outros, pois falhas de software ou hardware podem levar a uma inconsistência de dados. Portanto, outra função é necessária para publicar periodicamente a raiz da árvore de estado após a execução das transações, que pode ser usada por todos para verificar seu próprio estado. Esta função é chamada de Proposer. O estado submetido também forma uma sequência de estados correspondente à sequência de transações, chamada de State Commitment Chain (Cadeia de Compromisso de Estado).

Neste ponto, alcançamos a verificabilidade do aplicativo. Mas se o resultado de alguém for inconsistente com o estado apresentado pelo proponente e for determinado que o problema não está com ele mesmo, então isso significa que o proponente trapaceou ou cometeu um erro. Como os outros podem saber disso? Isto requer o papel de um Arbitrator (árbitro). O árbitro precisa ser um terceiro, confiável, que pode ser desempenhado por um contrato na cadeia.

Existem dois esquemas de arbitragem para os rollups:

1. Cada vez que o Proponente submete um estado, ele também fornece a prova de validade, que prova a validade da transição de estado entre o estado atual e o anterior e é verificada pelo contrato de arbitragem on-chain. A prova de validade é gerada usando técnicas de zero-knowledge (zero-conhecimento), que é chamada de ZK Rollup.
2. Supondo que os resultados do Proponente estejam corretos, mas se forem encontradas inconsistências, a prova de fraude é apresentada, que é julgada pelo contrato de arbitragem. Se o contrato de arbitragem determinar que o Proponente trapaceou, o Proponente será penalizado e a State Commitment Chain será revertida para o estado anterior à transação fraudulenta. Naturalmente, para garantir a segurança, um período de desafio relativamente longo é normalmente estabelecido para se chegar ao acordo final das transações on-chain. Isto é chamado de Rollup Optimistic.

Também precisamos alcançar a interoperabilidade dos ativos entre a Layer1 e a Layer2. Portanto, construímos uma ponte entre a Layer1 e a Layer2 e usamos provas de estado para a resolução de ativos entre elas. A raiz de estado da Layer2 na Layer1 é garantida pelo contrato de arbitragem da Layer1, portanto, a segurança desta ponte também é garantida pelo contrato de arbitragem.

Neste ponto, obtivemos uma solução de Rollup de Layer2 garantida pela Layer1 que permite a interoperabilidade dos ativos com a Layer1.

Naturalmente, a solução Rollup criou alguns compromissos:

Escrever transações para Layer1 significa que a escalabilidade da Layer2 ainda é limitada pelo tamanho do bloco da Layer1. Por exemplo, na Ethereum, se uma Layer2 ocupa completamente todos os blocos Ethereum, o TPS médio que ela pode fornecer é de apenas algumas centenas e sua escalabilidade é limitada pelo DA.

A fim de economizar taxas de gas, o Sequenciador fará transações em lote em DA. Antes de escrever para o DA, o Sequenciador pode trapacear ajustando a ordem das transações.

Aqui está um resumo da segurança e da finalidade das transações na Layer2:

1. Se um usuário executa um nó Layer2 e executa transações na ordem fornecida pelo DA, o usuário pode assumir que as transações são instantaneamente confirmadas e eventualmente liquidadas porque se o resultado da execução do usuário for diferente do resultado do Proponente, significa que o Proponente trapaceou e o estado na cadeia precisa ser revertido, o que eventualmente coincidirá com o resultado do próprio nó do usuário. O principal risco aqui é o mencionado anteriormente, que é o risco associado com o Sequenciador ajustando a ordem das transações que ainda não foram escritas para o DA ao sincronizar os dados em tempo real.
2. Se um usuário não pode executar ele mesmo um nó e depende de um fornecedor de RPC, o usuário precisa assumir um certo nível de risco de confiança. Entretanto, este risco é semelhante ao risco de confiar em um nó de RPC de Layer1. O risco adicional aqui é o risco de o Sequenciador descartar ou reorganizar as transações.
3. Se o Proponente estiver errado, mas nenhum nó inicia um desafio e o período de desafio expirar, o estado incorreto não pode ser revertido e o estado só pode ser reparado através de um fork rígido por consenso social.

Evolução Modular do Rollup

Com base na análise anterior, na solução Rollup, vários contratos na cadeia desempenham funções diferentes e representam módulos diferentes. É natural que se pondere se os módulos podem ser divididos em múltiplas cadeias para alcançar uma maior escalabilidade. Esta é a ideia da blockchain e do Rollup modular.

A palavra Modular possui dois significados aqui:

1. Através do projeto modular, o sistema se torna um sistema plug-and-play. Os desenvolvedores podem atender a diferentes requisitos do cenário de aplicativos através da montagem de módulos.
2. Com base na capacidade fornecida por 1, a implementação da camada modular não está vinculada à mesma Layer1, obtendo assim uma melhor escalabilidade.

Há três camadas modulares principais que podem ser consideradas:

• Camada de Disponibilidade de Dados: Assegura que os dados de transação da camada de execução possam ser obtidos de forma pública e garante a sequência da transação.
• Camada de resolução: Implementa a resolução do ativo e do estado entre a Layer1 e a Layer2. Ela inclui a State Commitment Chain e a Ponte.
• Camada de Arbitragem: Verifica as provas de fraude e faz julgamentos (optimistic) ou verifica as provas válidas (ZK). A camada de arbitragem deve ter a capacidade de manipular a State Commitment Chain.

DA Modular

Ao migrar a função DA e usar uma solução independente, o principal benefício é que a taxa de gas da transação de Layer2 é reduzida em pelo menos uma ordem de magnitude.

De uma perspectiva de segurança, mesmo que a descentralização da cadeia DA seja mais fraca que a da Ethereum, a principal garantia da segurança da camada DA são as transações durante o período do desafio. Após o período de desafio, o DA é usado principalmente para facilitar outros nós a sincronizar dados e não tem uma garantia de segurança. Portanto, a exigência de descentralização pode ser reduzida em um nível.

Uma cadeia dedicada ao DA pode fornecer maior largura de banda de armazenamento e menores custos de armazenamento e pode ser especificamente projetada para múltiplas aplicações para compartilhar o DA. Esta é também a base das correntes DA atuais como Celestia e Polygon Avail.

Após a divisão da camada DA, obtemos a arquitetura mostrada na figura abaixo:

Na figura acima, o DA é responsável por salvar a Cadeia de Transações Canônicas e a Layer1 fica com uma Fila de Transações L1ToL2 para implementar a comunicação de mensagens entre a Layer1 e a Layer2. Os usuários também podem escrever transações diretamente nesta fila para garantir que a Layer2 esteja sem permissão e que o Sequenciador não possa auditar usuários ou transações.

Entretanto, um novo problema surge aqui. Se a sequência de transações escrita pelo Sequenciador no DA e a sequência de transações executada pelo Proponente forem inconsistentes, como o juiz do contrato de arbitragem irá julgar? Uma solução é ter uma ponte entre cadeias entre a cadeia DA e a cadeia de arbitragem, que verifica a prova de dados fornecida pela cadeia da DA no contrato de arbitragem. Entretanto, esta solução depende da implementação de pontes de cadeia cruzada entre a cadeia DA e outras cadeias e a seleção da solução da DA será restrita. Outra solução é introduzir a Prova de Sequência.

Prova de Sequência

Podemos pensar no Sequenciador como parte da solução DA. Ele é equivalente a um DA específico para o aplicativo e tem as seguintes responsabilidades:

1. O Sequenciador precisa fornecer garantias de DA para o período de tempo anterior ao lote das transações na cadeia de DA.
2. O Sequenciador precisa verificar, classificar e finalmente escrever as transações no DA.

Se o Sequenciador gerar uma Prova de Sequência para cada transação, ele pode resolver dois problemas:

1. Ele fornece uma garantia para transações que não foram escritas na cadeia DA, dificultando para o Sequenciador ajustar arbitrariamente a ordem ou descartar transações.
2. Se não houver ponte entre a cadeia DA e a cadeia de arbitragem, a disponibilidade dos dados pode ser assegurada através do mecanismo de desafio da Prova de Sequência.

A Prova de Sequência tem as seguintes características:

1. Ela traz a assinatura do Sequenciador, provando que foi emitida por um Sequenciador específico.
2. Ela pode provar a posição de uma transação em toda a sequência de transações.
3. É um tipo de prova de acumulador. Cada transação gera um novo resultado de acumulação após ser acumulada, que está relacionado a todas as transações do histórico anteriores a ela. Isto dificulta a adulteração dos resultados. Uma das soluções opcionais para o acumulador é o Acumulador de Merkle e o resultado da acumulação é representado pela raiz da árvore Merkle.

Como funciona a Prova de Sequência:

Um usuário ou um nó de execução submete uma transação ao Sequenciador. O Sequenciador retorna a Prova de Sequência ao usuário e a sincroniza com outros nós. Se o Sequenciador descarta ou muda a ordem das transações antes de submetê-las ao DA, o usuário ou outros nós podem submeter a Prova de Sequência ao contrato de arbitragem para cortar o Sequenciador. O contrato de arbitragem precisa ler a raiz do acumulador de transações do contrato da State Commitment Chain para verificar a Prova de Sequência.

Vamos discutir os seguintes cenários:

1. O Sequenciador descarta ou reorganiza as transações do usuário, o que leva o Sequenciador a gerar duas Provas de Sequência na mesma posição. O usuário submete a Prova de Sequência ao contrato de arbitragem e o Sequenciador precisa fornecer a prova de que a transação está incluída na raiz do último acumulador de transações. Se ele não puder fornecer a prova, ela será cortada.
2. O Sequenciador não escreve corretamente as transações na cadeia DA e conspira com o Proponente para ocultar as transações. Se houver uma ponte entre a cadeia DA e a cadeia de arbitragem, a verificação pode ser feita através da ponte para cortar o Sequenciador. Caso contrário, o usuário pode iniciar um desafio para exigir que o Sequenciador forneça provas da posição de uma transação e informações originais. Neste caso, o contrato de arbitragem não pode julgar se o usuário está realizando um desafio malicioso. Portanto o Sequenciador não será cortado se ele fornecer os dados. Para os usuários, a realização de um desafio malicioso não é benéfica e carece de incentivos econômicos.

Ao introduzir a Prova de Sequência, os protocolos Layer2 se tornam mais seguros.

Transação Pipeline e Execução Paralela

Ao designar o Sequenciador ao DA para tratar exclusivamente da validação e classificação das transações, surge outro benefício que é a facilidade de implementar um pipeline de transações e execução paralela.

Ao validar uma transação, é necessário verificar a assinatura e se a taxa de gas é suficiente e a verificação da taxa de gas depende do estado. Se permitirmos que o Sequenciador verifique transações com um certo atraso (em segundos) entre o estado dependente e o estado mais recente para garantir que as transações de validação não sejam bloqueadas pela execução de transações, então a verificação de gas pode ser imprecisa e correr o risco de ataques DDoS.

Entretanto, acreditamos que a atribuição do Sequenciador ao DA é uma direção correta, por isso vale a pena pesquisar mais. Por exemplo, a parte do DA da taxa de transação pode ser dividida e expressa através do UTXO (Sui Move Object) para reduzir o custo da verificação da taxa de gas.

O Sequenciador ordena as transações e as gera em um pipeline de transações, que é então sincronizado com o Proponente e outros nós. Cada nó pode escolher um esquema de execução paralela com base em sua própria situação de servidor. Cada nó precisa garantir que somente transações sem relações causais sejam executadas em paralelo. As transações com relações causais devem ser executadas na ordem do Sequenciador, para que o resultado final seja consistente.

O Proponente precisa submeter periodicamente a raiz da árvore de estado e a raiz do acumulador ao contrato da State Commitment Chain sobre a cadeia.

Portanto, temos uma Layer2 modular com baixas taxas de gas, alto TPS e maior segurança. Esta é a Rooch.

• MoveOS: Inclui MoveVM e StateDB, que são os mecanismos de execução do sistema e de armazenamento do estado. O StateDB é construído com duas camadas de árvores Merkle Sparse e pode fornecer provas de estado. Como mencionado anteriormente, a árvore de estado e a prova de estado são componentes indispensáveis dos aplicativos Rollup.
• RPC (Remote Procedure Call ou Chamada de Procedimento Remoto): Fornece serviços de consulta, submissão de transações e assinatura para o mundo exterior. Pode ser compatível com a API do RPC de outras cadeias através de proxy.
• Sequencer: Verifica transações, ordena transações, fornece prova de sequência e encaminha transações para o pipeline de transações.
• Proposer: Recupera transações do pipeline de transações, o lote as executa e as submete periodicamente à State Commitment Chain na cadeia.
• Challenger: Recupera transações do pipeline de transações, o lote as executa, compara-as com a State Commitment Chain e decide se deve iniciar um desafio.
• DA & Interface de Resolução e Arbitragem: Abstrai e encapsula diferentes camadas modulares para garantir que a alternância entre diferentes implementações não afete a lógica de negócios de nível superior.

Provas Interativas de Fraudes com Suporte Multi-Chain

Na solução de Rollup Optimistic, sempre foi um desafio para os contratos de arbitragem on-chain determinar quando as transações off-chain foram executadas incorretamente. A ideia inicial era reexecutar as transações de Layer2 na Layer1, mas a dificuldade com esta abordagem é que os contratos de Layer1 teriam que simular a execução das transações de Layer2, o que seria caro e limitaria a complexidade das transações de Layer2.

A indústria, por fim, acabou por criar um esquema de prova interativo. Como qualquer transação complexa acaba se resumindo a instruções de máquina, se conseguirmos identificar as instruções divergentes, podemos simplesmente simular a execução de instruções na cadeia.

Usando a mesma fórmula de transição de estado de antes:

σt+1 ≡ Υ(σt, T)

onde Υ representa uma instrução, T representa o input de instrução e σ representa o estado de memória do qual a instrução depende. Se uma prova de estado for gerada para cada σ durante a execução, as duas partes em uma disputa podem identificar interativamente o ponto de divergência m, e submeter o estado σ m-1 e a instrução m ao contrato de arbitragem on-chain para simulação. O contrato de arbitragem pode então fornecer uma sentença após a execução.

A questão remanescente é como gerar a prova. E há principalmente duas abordagens:

1. Implementá-la diretamente na máquina virtual da linguagem do contrato, como o AVM da Arbitrum e o FuelVM da Fuel.
2. Implementar um simulador baseado em um conjunto de instruções existentes, que pode fornecer capacidades de prova dentro do simulador. Por exemplo, o cannon baseado no MIPS da Optimism, o novo Nitro baseado no WASM da Arbitrum e o OMO baseado no MIPS da Rooch.

O OMO é um simulador de bytecode geral com capacidades de prova de estado de uma única etapa, projetado para ambientes de execução multi-chain. Com suporte do OMO, a camada de arbitragem pode ser modular. Qualquer cadeia que suporte contratos Turing-completo pode simular as instruções do OMO em seus contratos e atuar como uma camada de arbitragem.

ZK + Solução de Comunicação Optimistic

A indústria tem discutido os prós e contras do Rollup Optimistic e do Rollup ZK, mas acreditamos que a combinação dos dois pode alcançar os benefícios de ambas as soluções.

Com base na solução Optimistic anterior, introduzimos um novo papel, o Prover ZK. Ele gera provas válidas em massa para os estados de transação apresentados pelo Proponente e as submete ao contrato de arbitragem. Após verificação pelo contrato de arbitragem, a transação pode ser resolvida da Layer2 para a Layer1 para finalização.

As vantagens desta solução são:

1. O rendimento global da Layer2 não será limitado em razão dos fatores de desempenho da ZK.
2. O ZK pode encurtar o período de desafio do Optimistic e melhorar a experiência do usuário.

Antes da maturidade das soluções ZK e da aceleração do hardware, podemos construir o ecossistema através do Optimistic, e a solução modular pode integrar perfeitamente o ZK no futuro.

Resolução Multi-Chain

Se, além disso, considerarmos a tendência de modularidade, isso naturalmente leva à questão de se a camada de assentamento pode ser implantada em outra cadeia, uma vez que o DA pode ser migrado para outra cadeia.

A resolução de ativos entre a Layer1 e a Layer2 depende principalmente de dois componentes, um é a Ponte e o outro é a State Commitment Chain. Ao estabelecer-se através da Ponte, é necessário confiar na State Commitment Chain para verificar a prova de estado da Layer2. A Ponte pode certamente ser implantada em várias cadeias, mas só pode haver uma versão autorizada da State Commitment Chain, que é garantida pelo contrato de arbitragem.

Este direcionamento requer mais pesquisas, mas existe uma solução preliminar. A State Commitment Chain em outras cadeias é um espelho da cadeia de arbitragem (Ethereum). Este espelho não precisa sincronizar todas as Raízes de Estado de Layer2 com outras cadeias, mas os usuários podem mapeá-las conforme necessário através da prova de estado da Ethereum.

Naturalmente, outras cadeias também precisam ser capazes de verificar a prova de estado na Ethereum. Então, é necessário conhecer a raiz de estado na Ethereum. Atualmente, existem duas soluções para sincronizar a raiz de estado da Ethereum com outros nós: 1. com base no Oracle 2. incorporação de um nó de Ethereum leve para verificar o cabeçalho de bloco da Ethereum.

Desta forma, podemos obter uma solução Layer2 que suporta o assentamento multi-chain, mas cuja segurança é garantida pela Ethereum.

A diferença entre esta solução e a solução de cadeia cruzada é:

1. Se é uma solução de cadeia cruzada que depende de uma relay chain, a Layer2 pode ser considerada como substituta da relay chain e é uma camada de relay com segurança garantida pelo contrato de arbitragem.
2. Se for uma solução de cadeia cruzada que verifica a prova de estado entre cadeias, a solução de liquidação de multi-chain compartilha a mesma solução técnica para sincronização de raiz de estado, mas é muito mais simples. A exigência de sincronização para provas de estado é de uma via na solução de liquidação multi-chain. Precisamos apenas sincronizar da cadeia de arbitragem para outras cadeias, em vez de fornecer uma sincronização bidirecional entre cada par de cadeias.

As Possibilidades trazidas pela Modular

Através do modular, os desenvolvedores podem combinar a Rooch com outros componentes para criar diferentes aplicações.

1. Rooch Ethereum Layer2 = Rooch + Ethereum (Resolução+Arbitragem) + DA. Esta é a rede na qual a Rooch irá operar inicialmente. Ela fornece uma plataforma de execução Move que é protegida pela Ethereum e pode interoperar com os ativos da rede Ethereum. Ela pode ser expandida no futuro para apoiar a liquidação em cadeias múltiplas.
2. Rooch Layer3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer2 (Resolução+Arbitragem) + DA. Se um aplicativo implantar sua resolução e arbitragem para a Layer2 da Rooch, ele se torna um aplicativo da Layer3 da Rooch.
3. XChain Rollup DApp = Rooch + DApp Move Contract + XChain (Resolução+Arbitragem) + DA. Qualquer cadeia pode fornecer aos desenvolvedores um conjunto de ferramentas DApp de Rollup baseado em Move através da Rooch. Os desenvolvedores podem escrever sua própria lógica de aplicação na linguagem Move e executar um aplicativo Rollup com segurança garantida pelo XChain e podem interoperar com ativos no XChain. Naturalmente, isto requer colaboração com os desenvolvedores de cada cadeia pública.
4. O Sovereign Rollup DApp = Rooch + DApp Move Contract + DApp. Os aplicativos também podem usar a Rooch como um Sovereign Rollup SDK, sem implantar os contratos Bridge e Arbitration. A State Commitment Chain também é salva no DA para garantir a verificabilidade, com a segurança garantida por consenso social.
5. Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave). O SCP e o Sovereign Rollup têm idéias similares, onde o SCP exige que o código do aplicativo seja salvo na camada DA. Na Rooch, a implementação e atualização do contrato são ambas transações e o código do contrato está na transação, é escrito na camada DA, portanto acreditamos que ele atende ao padrão SCP.
6. Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract. O MoveOS pode ser incorporado como um ambiente independente da execução do Move no ambiente de tempo de execução de qualquer cadeia para construir cadeias de aplicativos ou novas cadeias públicas.
7. Projetos fora das blockchains. Projetos fora das blockchains podem usar o MoveOS como um banco de dados com capacidade de verificação de dados e prova de armazenamento. Por exemplo, ele pode ser usado para construir um sistema de blog local, onde a estrutura de dados e a lógica de negócios são expressas através do Move. À medida que a infraestrutura amadurece, ela pode ser integrada diretamente no ecossistema da blockchain. Outro exemplo é usá-la para serviços FaaS na computação em nuvem, onde os desenvolvedores escrevem funções em Move e a plataforma gerencia o estado. As funções podem ser combinadas e chamadas. Há mais possibilidades a serem exploradas.

O projeto modular da Rooch pode se adaptar a aplicações de diferentes tipos e estágios. Por exemplo, os desenvolvedores podem primeiro validar suas ideias implantando contratos na Layer2 Ethereum da Rooch e depois migrar a aplicação para um rollup independente específico de App quando ele crescer.

Alternativamente, os desenvolvedores podem iniciar o aplicativo diretamente através do método Sovereign Rollup, porque nos estágios iniciais do aplicativo, não há uma alta exigência de segurança, e não há necessidade de interoperar com ativos em outras cadeias. Mais tarde, à medida que o aplicativo crescer e surgir a necessidade de interoperar com ativos e a necessidade de segurança aumentar, a modularidade de Resolução e Arbitragem pode ser habilitada para garantir a segurança dos ativos.

Tendências Tecnológicas em Aplicações Modulares

O potencial do DA ainda não foi explorado

A partir da análise anterior, pode-se ver que, independentemente do método de combinação, vai depender da camada DA. O papel da camada DA em aplicativos descentralizados é similar ao de logs de plataformas em sistemas Web2. Ela pode ser usada para auditoria, suporte a grandes análises de dados e condução de treinamento de IA. Muitos aplicativos e serviços serão construídos em torno da camada DA no futuro. Atualmente, já existem cadeias DA, tais como Celestia, Polygoin Avail (é uma rede de comunicação descentralizada que permite aos usuários conectarem-se a diferentes aplicativos blockchain de forma rápida e segura) e haverá mais no futuro, tais como EigenLayer, Ethereum danksharding e assim por diante.

De acordo com a análise anterior, concluímos que o papel do Sequenciador deve pertencer a uma parte da camada DA. Se a camada DA puder fornecer capacidades de verificação de transações para aplicativos e tiver desempenho suficiente, as responsabilidades do Sequenciador podem realmente ser totalmente assumidas pela camada DA e os usuários podem escrever transações diretamente para a camada DA. Naturalmente, se os usuários podem pagar a taxa de gas para DA com o token do aplicativo é outro problema que precisa ser resolvido.

As linguagens de programação dos DApps vão explodir

Novos formulários de inscrição promoverão a explosão de novas linguagens de programação, como já se via na era Web2. A Move se tornará a melhor linguagem para a construção de DApps Web3. Além das características da linguagem da Move, as seguintes razões são baseadas em:

1. O uso da mesma linguagem para DApps pode rapidamente acumular as bibliotecas básicas necessárias para a aplicação e formar um efeito de ecossistema. Portanto, suportar múltiplas línguas no início não é uma boa estratégia.
2. Os aplicativos descentralizados devem, pelo menos, garantir a verificabilidade e as linguagens de contratos inteligentes podem reduzir muitos esforços mentais para os desenvolvedores para garantir a verificabilidade.
3. A natureza de plataforma agnóstica da Move facilita a adaptação a diferentes plataformas e aplicativos.
4. O estado da Move é estruturado, o que é benéfico para a expressão da estrutura de dados dos DApps e para a recuperação de armazenamento.

Conclusão

Eu entrei na indústria da blockchain no final de 2017. Na época, muitos times estavam tentando construir aplicativos na blockchain. Infelizmente, a infraestrutura ainda não estava completa e a indústria ainda não havia descoberto um padrão replicável para a construção de aplicativos. A maioria dos projetos baseados em aplicativos falhou, o que foi um golpe para desenvolvedores e investidores. Como os aplicativos devem ser construídos na blockchain? Esta pergunta está em minha mente há cinco anos.

Agora, com o amadurecimento da Layer1, Layer2 e contratos inteligentes, bem como da infraestrutura modular, a resposta a esta pergunta tornou-se gradualmente mais clara.

Espero que na próxima onda de explosão do DApp Web3, a Rooch possa ajudar os desenvolvedores a construir aplicativos mais rapidamente e aterrá-los realmente.

Este artigo foi escrito por Jolestar, Co-Fundador Rooch & Arquiteto Chefe e traduzido por Fátima Lima. Seu original pode ser lido aqui.

Twitter | Telegram | Medium | Website | Blog | Reddit |