Este artigo tenta discutir o desenvolvimento e a evolução do Rollup Layer 2 a partir de uma perspetiva evolutiva, e responde principalmente às seguintes perguntas:
Como funcionam os rollups:
Evolução modular dos rollups
A modularidade abre possibilidades
Tendências tecnológicas em aplicações modulares
Resumo
Como funcionam os Rollups
O “trilema” do blockchain sempre foi um problema difícil para a indústria, e se acreditamos que os blockchains da Camada 1 devem primeiro garantir “descentralização” e “segurança”, então migrar a solução de “escalabilidade” da Camada 1 é uma escolha natural, daí a Camada 2. O novo desafio é como garantir a segurança da Camada 2 até a Camada 1.
Inicialmente, houve uma ideia de escrever periodicamente a raiz da árvore de estado do aplicativo de Camada 2 para a Camada 1, para que o estado do aplicativo pudesse ser verificado pela prova de estado, semelhante à prova de reserva na plataforma de negociação. No entanto, esse método não pode ser feito por terceiros para verificar se as duas transições de estado estão corretas de forma pública.
Para aprofundar este problema, vamos abstrair que o estado de qualquer programa pode ser expresso por uma fórmula de transição de estado:
t+1 (t, t)
Esta fórmula vem do Ethereum Yellow Book, mas pode representar qualquer programa. Aqui está o programa, que representa o Estado. O estado t+1 é calculado pelo programa Y a partir do estado t e da transação T. A transação T representa a entrada do programa. A qualquer momento, se t é determinista, o programa Y é determinístico e T é determinista, então t+1 é determinista.
Portanto, para fornecer verificabilidade pública, a chave é que Y esteja disponível publicamente, que todos os T historicamente estejam publicamente disponíveis e em ordem, e que o estado intermediário possa ser recalculado por Y e T. A disponibilidade pública do programa pode ser alcançada através de código aberto, e a chave é como garantir a disponibilidade pública de T, o que introduz o conceito de disponibilidade de dados (DA).
A disponibilidade de dados requer um livro-razão público e imutável para registrar as transações do aplicativo. Naturalmente, o livro-razão blockchain é um sistema desse tipo, então as transações da Camada 2 são gravadas de volta na Camada 1 para garantir a disponibilidade dos dados, que é de onde vem o nome do Rollup.
Portanto, precisa haver uma função no sistema de Camada 2 que colete as transações do usuário, classifique-as e as grave no DA, e essa função é chamada de Sequencer. A sequência de transações aqui é chamada de Cadeia de Transações Canônicas.
A disponibilidade dos dados é garantida, e todos podem obter o estado final executando o próprio programa para executar a transação. Mas não há consenso aqui, porque todos não têm certeza se seus resultados são os mesmos que os dos outros, afinal, falhas de software ou hardware também podem causar inconsistências de dados. Portanto, outra função é necessária para publicar a raiz da árvore de status depois que a transação é executada regularmente para que todos verifiquem seu status, e essa função é chamada de Proponente. O estado de cada compromisso aqui também constitui uma sequência de estados, que corresponde à sequência de transações, chamada de Cadeia de Compromisso do Estado.
Neste ponto, chegamos à verificabilidade do aplicativo. Se o resultado de alguém não corresponder ao status do envio do Proponente e for determinado que não é problema dele, então o Proponente está trapaceando ou errado, como você informa os outros sobre isso? O árbitro tem de ser um terceiro de confiança, e o contrato on-chain pode assumir esse papel.
Existem duas opções para a arbitragem:
Cada vez que o Proponente submete um estado, ele também fornece uma Prova de Validade da transição de estado do estado anterior, que é verificada pelo contrato de arbitragem na cadeia. Provas válidas são normalmente geradas usando a tecnologia de conhecimento zero, que é chamada de ZK Rollup.
Presume-se que o resultado do Proponente está correto, mas se forem encontradas inconsistências, uma Prova de Fraude é apresentada, e o contrato de arbitragem decide. Se o contrato de quórum determinar que o Proponente trapaceia, o Proponente é penalizado e a Cadeia de Compromisso do Estado é revertida para o estado em que estava antes da transação fraudulenta. É claro que, a fim de garantir a segurança, é geralmente definido um período de desafio relativamente longo para alcançar o caráter definitivo da liquidação das transações on-chain. Isso é chamado de rollup otimista.
Também precisamos implementar a interoperabilidade de ativos entre a Camada 1 e a Camada 2. Portanto, uma ponte entre a Camada 1 e a Camada 2 é construída, e a liquidação do ativo é realizada através de prova de estado. O estado da Camada 2 na Camada 1 é garantido pelo contrato de arbitragem da Camada 1, e podemos assumir que a segurança desta ponte também é garantida pelo contrato de arbitragem.
Até agora, temos uma solução de Rollup Layer 2 que é garantida pela Layer 1 e pode interoperar com a Layer 1.
É claro que existem alguns compromissos feitos pela solução Rollup:
Gravar transações na Camada 1 significa que a escalabilidade da Camada 2 ainda é limitada pelo tamanho do bloco da Camada 1. Tomando Ethereum como exemplo, uma Camada 2 ocupa completamente todos os blocos de Ethereum, e o TPS médio que pode ser fornecido é de apenas algumas centenas, e a escalabilidade é limitada por DA.
Para economizar nas taxas de gás, o Sequencer grava transações no DA em lotes e, antes de escrever no DA, é possível que o Sequencer trapaceie ajustando a ordem das transações.
Aqui está um resumo da segurança da Camada 2 e da finalidade das transações:
Se o usuário executa um nó de Camada 2 e executa fielmente a ordem de transação do DA, o usuário pode assumir que a transação é confirmada instantaneamente e finalizada, porque se o resultado da execução do usuário for diferente do do Proponente, isso significa que o Proponente trapaceia e precisa reverter o estado da cadeia, e o resultado será o mesmo do próprio nó do usuário. O principal risco aqui é o risco mencionado anteriormente de o Sequencer ajustar a ordem das transações que ainda não foram gravadas no DA se os dados forem sincronizados do Sequencer em tempo real.
Se o usuário não conseguir executar o nó por conta própria, ele precisará confiar em um provedor RPC e o usuário precisará arcar com um certo risco de confiança. No entanto, esse risco é semelhante ao risco representado pelos usuários que confiam nos nós RPC na Camada 1. O risco adicional aqui ainda é o risco de o Sequencer cair ou reordenar as transações.
Se o Proponente comete um erro, mas nenhum nó inicia um desafio, e o período de desafio é excedido, o estado errado não pode ser revertido, e o estado só pode ser corrigido através de um hard fork de consenso social.
Evolução modular dos rollups
De acordo com a análise anterior, na solução Rollup, vários contratos na cadeia assumem diferentes funções e representam diferentes módulos. O pensamento natural era se o módulo poderia ser dividido em várias cadeias para alcançar maior escalabilidade. Essa é a ideia por trás de blockchains modulares e rollups modulares.
A modularidade tem dois significados aqui:
Através do design modular, o sistema torna-se um sistema conectável. Os desenvolvedores podem montar módulos para atender às necessidades de diferentes cenários de aplicativos.
Com base nos recursos fornecidos pela 1, a implementação da camada do módulo não está vinculada à mesma camada 1, resultando em melhor escalabilidade.
Podemos pensar em três camadas de módulos principais:
Disponibilidade de dados: Garantir que os dados de transação da camada de execução possam ser obtidos de forma pública, e a sequência de transações garantidas.
Liquidação: liquidar ativos e estados entre a Camada 1 e a Camada 2. Contém a Cadeia de Compromisso do Estado e a Ponte.
Arbitragem: Verifique a prova de fraude e faça uma sentença (Otimista) ou verifique a prova válida (ZK). A camada de quórum precisa ser capaz de manipular a Cadeia de Compromisso do Estado.
Modularidade DA
O principal benefício da migração da função DA para uma solução independente é que as taxas de gás de transação da Camada 2 são reduzidas em pelo menos uma ordem de magnitude.
Do ponto de vista da segurança, mesmo que a descentralização da cadeia DA seja mais fraca do que a do Ethereum, a garantia de segurança na camada DA é principalmente a transação durante o período de desafio.
As cadeias privadas de DA podem fornecer maior largura de banda de armazenamento e menores custos de armazenamento, e são projetadas especificamente para vários aplicativos compartilharem DA. Esta é também a base das atuais cadeias DA, como Celestia e Polygon Avail.
Depois de dividir a camada DA, obtemos a arquitetura do diagrama a seguir:
Na figura acima, o DA é responsável por salvar a Cadeia de Transações Canônica, e uma Fila de Transações L1ToL2 é deixada para a Layer1 realizar a comunicação de mensagens entre a Layer1 e a Layer2, e os usuários também podem gravar transações diretamente nessa fila para garantir que a Layer2 seja Permissionless, e o Sequencer não possa auditar usuários ou transações.
Uma solução é ter uma ponte de cadeia cruzada entre a cadeia DA e a cadeia de arbitragem para verificar a prova de dados fornecida pela cadeia DA no contrato de arbitragem. No entanto, esta solução depende da implementação de pontes de cadeia cruzada entre DA e outras cadeias, e a escolha de soluções de DA será limitada. Outra opção é introduzir provas de classificação.
Prova de Sequência
Podemos pensar no Sequencer como na verdade parte de um esquema DA, e é o equivalente a um DA específico do aplicativo pelos seguintes motivos:
O Sequencer precisa fornecer garantias de DA para o período antes de gravações em massa na cadeia DA.
O Sequencer é responsável por validar transações, sequenciá-las e, finalmente, gravá-las no DA.
Se você pedir ao Sequencer para gerar uma Prova de Sequência para cada transação, poderá resolver dois problemas:
Fornece garantias para transações que ainda não foram gravadas na cadeia DA, para que o Sequencer não se atreva a ajustar arbitrariamente a ordem das transações ou descartá-las. Se não houver uma ponte de cadeia cruzada entre a cadeia DA e a cadeia de quórum, os dados podem ser garantidos como disponíveis através do mecanismo de desafio da Prova de Sequência.
A Prova de Sequência tem as seguintes características:
Ele carrega a assinatura do Sequencer, provando que foi emitido por um Sequencer. Prova a posição de uma transação em toda a sequência de transações. É um tipo de prova de acumulador. Cada transação é somada para gerar um novo resultado que se correlaciona com todas as transações históricas anteriores, dificultando a adulteração. Uma das opções para um acumulador é o Acumulador Merkle, que resulta na forma das raízes da árvore Merkle.
Como funciona a Prova de Sequência:
O usuário ou nó de execução envia uma transação para o Sequencer, e o Sequencer retorna a Prova de Sequência para o usuário e a sincroniza com outros nós. Se o Sequencer descartar ou adulterar a ordem das transações antes de enviá-las ao DA, o usuário ou outros nós podem penalizar o Sequencer enviando a Prova de Sequência ao contrato de quórum. O contrato de quórum precisa ler a raiz do acumulador de transações do contrato da Cadeia de Compromisso do Estado para verificar a Prova de Sequência.
Vamos discutir os seguintes cenários:
O Sequencer descarta ou reflui as transações do usuário. Isso faz com que o Sequencer gere duas provas de sequência no mesmo local. Quando um usuário envia uma Prova de Sequência para um contrato de arbitragem, o Sequencer precisa fornecer prova de que a transação está incluída na raiz do acumulador de transação mais recente e, se não puder, o Sequencer será penalizado.
O Sequencer não gravou corretamente as transações na cadeia DA e conspirou com o Proponente para ocultar as transações. Se a cadeia de quórum e a cadeia DA tiverem uma ponte, a ponte é usada para validá-la, penalizando o sequenciador. Caso contrário, o usuário pode desafiar o Sequencer a fornecer a prova da transação em um determinado local, juntamente com as informações originais. No entanto, neste caso, o contrato de arbitragem não pode determinar se o usuário é um desafio malicioso, portanto, se o Sequencer fornecer dados, ele não penaliza o Sequencer. Para os utilizadores, os desafios maliciosos prejudicam os outros e a si próprios, havendo também falta de motivação económica.
Tornamos o protocolo de Camada 2 mais seguro introduzindo a Prova de Sequência.
Pipeline de transações e execução paralela
Outro benefício de dividir o Sequencer em DAs, que são responsáveis apenas pela validação e ordenação das transações, é a facilidade de agilizar as transações e a execução paralela.
Ao verificar uma transação, você precisa verificar a assinatura e se há taxa de gás suficiente, e a verificação da taxa de gás precisa depender do estado. Se permitirmos que o Sequencer permita um atraso (em segundos) entre o estado do qual a transação de verificação depende e o estado mais recente, a fim de garantir que a transação de validação não seja bloqueada pela transação de execução, a validação de gás será imprecisa e haverá um risco de ataques DDoS.
Mas achamos que ser um DA é a direção certa para o Sequencer, então vale a pena olhar mais a fundo. Por exemplo, você pode dividir a parte DA da taxa de transação e expressá-la através do Sui Move Object (UTXO), o que pode reduzir o custo de deteção da taxa de gás.
O Sequencer classifica as transações e as produz em um pipeline de transações, que é então sincronizado com o Proponente e outros nós. Cada nó pode escolher um esquema paralelo de acordo com sua própria situação de servidor. Cada nó precisa garantir que apenas as transações sem relações causais sejam paralelas, e que as transações com relações causais sejam executadas na ordem do Sequencer, e que o resultado final seja consistente.
O proponente precisa comprometer periodicamente a raiz da árvore de estado, bem como a raiz do acumulador no contrato da cadeia de compromisso do Estado.
Assim, obtemos uma camada 2 modular com baixas taxas de gás, TPS alto e mais segurança: Rooch.
MoveOS: Ele contém MoveVM e StateDB, que é o mecanismo de execução e armazenamento de estado do sistema. O StateDB é construído a partir de duas camadas de árvores Merkle esparsas que fornecem prova de estado. Com base na análise anterior, pode-se concluir que árvores de estado e provas de estado são componentes indispensáveis de aplicações de rollup.
RPC: Forneça consultas externas, envie transações e assine serviços. Interfaces RPC que podem ser compatíveis com outras cadeias podem ser intermediadas.
Sequenciador: valida transações, sequencia transações, fornece provas de sequência e produz transações para o Pipeline de Transações.
Proponente: Obter transações do Pipeline de Transações, executá-las em lotes e submetê-las à Cadeia de Compromisso do Estado on-chain regularmente.
Challenger: Obtenha transações do Pipeline de Transações, execute-as em lotes e compare-as com a Cadeia de Compromisso do Estado para decidir se lança um desafio.
DA & Settlement & Arbitration Interface: Abstração e encapsulamento de diferentes camadas de módulo para garantir que a alternância entre diferentes implementações não afete a lógica de negócios da camada superior.
À prova de fraude interativa com suporte multi-cadeia
No esquema de rollup otimista, como o contrato de arbitragem on-chain determina que o erro de execução da transação off-chain sempre foi um problema difícil. A ideia original era executar novamente a transação da Camada 2 na Camada 1, mas o problema com essa solução é que o contrato da Camada 1 precisa simular a execução da transação da Camada 2, o que é muito caro e limitará a complexidade da transação da Camada 2.
Por último, a indústria explorou um sistema de provas interativo. Como qualquer transação complexa acabará sendo convertida em execução de instrução de máquina, se encontrarmos uma instrução que produza uma divergência, só precisamos simular a execução da instrução na cadeia.
Use também a fórmula de transição de estado acima:
t+1 (t, t)
Aqui T significa instrução e T significa instruction input, que representa o estado de memória do qual a instrução depende. Se durante a execução, gere um certificado de status para cada arquivo . Através da interação, a acusação e a defesa podem encontrar o ponto de desacordo m entre as duas partes, e submeter o status de m-1 e a instrução m ao contrato de arbitragem on-chain para execução simulada, e o contrato de arbitragem pode ser determinado após sua execução.
Portanto, a questão que fica é como gerar provas, e existem duas opções principais:
Ele é implementado diretamente na máquina virtual de linguagem de contrato, como o AVM da Arbitrum e o FuelVM da Fuel.
Implemente um simulador baseado em um conjunto de instruções existente e forneça recursos de prova no simulador. Exemplos incluem o canhão baseado em MIPS da Optimism, o novo Nitro baseado em WASM da Arbitrum e o OMO baseado em MIPS da Rooch.
O OMO é um simulador de bytecode de uso geral com recursos de prova de estado em uma única etapa, projetado para ambientes de execução de várias cadeias. Com o apoio do OMO, a modularidade da camada de quórum pode ser realizada. Qualquer cadeia que suporte um contrato Turing-complete pode emular as instruções do OMO no contrato como uma camada de quórum.
ZK + Esquema de combinação otimista
Tem havido muito debate na indústria sobre os méritos do Optimistic Rollup e do ZK Rollup, mas acreditamos que a combinação dos dois pode dar-lhe o melhor dos dois mundos.
Com base na solução Optimistic anterior, introduzimos um novo personagem, ZK Prover. Gera provas válidas do estado das transações apresentadas pelo Proponente em lotes e submete-as ao contrato de arbitragem. Após a verificação do contrato de arbitragem, pode-se determinar que a transação atingiu o fim na Camada 1, e a transação de retirada da Camada 2 para a Camada 1 pode ser liquidada.
Vantagens desta abordagem:
Os problemas de desempenho do ZK não limitarão a taxa de transferência geral da Camada 2. ZK pode encurtar o ciclo de desafio do Optimistic e melhorar a experiência do usuário.
Antes que a solução e a aceleração de hardware da ZK amadureçam, podemos construir um ecossistema através do Optimistic, e a solução modular pode tornar a ZK finalmente perfeitamente integrada.
Liquidação multi-cadeia
Se pensarmos mais sobre a tendência da modularidade, é natural pensar que, uma vez que o DA pode ser migrado para outras cadeias, a camada de liquidação também pode ser implantada para outras cadeias?
A liquidação de ativos entre a Camada 1 e a Camada 2 depende principalmente de dois componentes, um é a Ponte e o outro é a Cadeia de Compromisso do Estado. É claro que a Bridge pode ser implantada em várias cadeias, mas a Cadeia de Compromisso do Estado só pode ter uma versão autorizada, garantida por um contrato de quórum.
Essa direção ainda precisa ser estudada em profundidade, mas há um plano preliminar. A Cadeia de Compromisso do Estado em outras cadeias é uma imagem espelhada do Ethereum. Esta imagem não precisa sincronizar toda a raiz de estado de Layer2 com outras cadeias, mas é mapeada pelo usuário através da prova de estado sob demanda do Ethereum.
Claro, outras cadeias também precisam ser capazes de verificar a prova de estado no Ethereum, então você precisa saber a raiz do estado no Ethereum. Atualmente, existem dois cenários para sincronizar a raiz de estado no Ethereum com outros nós:1. Confie na Oracle. 2. Incorpore o nó de luz Ethereum e verifique o cabeçalho do bloco do Ethereum.
Desta forma, podemos obter uma solução de Camada 2 que suporta liquidação multi-cadeia, mas a segurança é garantida pelo Ethereum.
A diferença entre esta solução e a cadeia cruzada:
Se for uma solução de cadeia cruzada que depende da cadeia de relé, pode considerar-se que a camada 2 substitui a cadeia de relé e é uma camada de relé cuja segurança é garantida pelo contrato de arbitragem.
Se for um esquema de cadeia cruzada que verifica a prova de estado entre cadeias, o esquema de liquidação multicadeia compartilha o esquema técnico de sincronização de raiz de estado com ele, mas é muito simplificado. Porque no esquema de liquidação multicadeia, o requisito de sincronização da raiz do estado é unidirecional, e só precisa ser sincronizado da cadeia de quórum para outras cadeias, não duas por duas.
A modularidade abre as possibilidades
Através da modularidade, os desenvolvedores podem combinar diferentes aplicativos com o Rooch.
Rooch Ethereum Layer2 = Rooch + Ethereum (Liquidação + Arbitragem) + DA。 Esta é a rede que Rooch irá executar em primeiro lugar. Forneça uma plataforma de tempo de execução Move que seja garantida pela segurança Ethereum e possa interoperar com ativos no Ethereum. No futuro, pode ser alargado à liquidação em várias cadeias.
Rooch Layer3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer2 (Liquidação + Arbitragem) + DA Se um aplicativo implanta sua própria liquidação e arbitragem no Rooch Layer 2, ele é um aplicativo Rooch Layer 3.
XChain Rollup DApp = Rooch + DApp Move Contract + XChain (Liquidação + Arbitragem) + DA Qualquer cadeia pode fornecer aos desenvolvedores um conjunto de kits de ferramentas Rollup DApp baseados na linguagem Move through Rooch. Os desenvolvedores só precisam escrever sua própria lógica de aplicativo por meio da linguagem Move para executar um aplicativo cumulativo em um ambiente independente que seja seguro e protegido pelo XChain, e os ativos podem ser interoperáveis com o XChain. É claro que isso precisa ser desenvolvido em colaboração com os desenvolvedores de cada cadeia pública.
Sovereign Rollup DApp = Rooch + DApp Move Contract + DA aplicativo também pode usar Rooch como o Sovereign Rollup SDK, sem implantar contratos de Bridge e Arbitragem, e a Cadeia de Compromisso do Estado também é armazenada em DA para garantir verificabilidade e segurança por consenso social.
Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave)SCP é semelhante ao Sovereign Rollup, na medida em que o SCP requer que o código do aplicativo seja salvo no DA também. Em Rooch, a implantação e atualização do contrato são todas as transações, e o código do contrato será escrito na camada DA na transação, então acreditamos que ele atende aos padrões do SCP.
Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract O MoveOS pode ser incorporado ao ambiente de tempo de execução de qualquer cadeia como um ambiente de tempo de execução Move independente para criar uma cadeia de aplicativos ou uma nova cadeia pública.
Projetos não-blockchain Os projetos não-blockchain podem usar o MoveOS como um banco de dados com recursos de validação de dados e recursos de prova de armazenamento. Por exemplo, use-o para criar um sistema de blog local e a estrutura de dados e a lógica de negócios são expressas por meio do Move. Quando a infraestrutura amadurece no futuro, ela pode ser diretamente conectada ao ecossistema blockchain. Outro exemplo é que ele pode ser usado como um serviço FaaS em computação em nuvem, onde os desenvolvedores podem escrever funções em FaaS através do Move, a plataforma hospeda o estado, e as funções entre os usuários também podem ser combinadas e chamadas uns pelos outros. Há mais possibilidades para explorar.
A abordagem modular da Rooch pode ser adaptada a diferentes tipos e estágios de aplicação. Por exemplo, os desenvolvedores podem primeiro verificar suas ideias no Rooch Ethereum Layer 2 implantando contratos e, em seguida, migrar o aplicativo para um Rollup Específico de Aplicativo independente construído no Rooch depois que crescerem.
Ou o desenvolvedor pode iniciar o aplicativo diretamente através do método Sovereign Rollup, porque o aplicativo não tem altos requisitos de segurança no estágio inicial, e não há necessidade de trocar ativos com outras cadeias, para que possa ser verificado primeiro. Quando os aplicativos crescem e há uma demanda por interconexão de ativos, os requisitos de segurança se tornam maiores e os módulos de liquidação e arbitragem podem ser habilitados para garantir a segurança dos ativos.
Tendências tecnológicas para aplicações modulares
O potencial da camada DA ainda está por ser explorado
Como você pode ver na análise anterior, o DA é invocado independentemente da combinação. O DA desempenha um papel semelhante em aplicativos descentralizados como uma plataforma de registro para sistemas Web2, que pode ser usada para auditoria, análise de big data, treinamento de IA e muito mais. Haverá muitos aplicativos e serviços construídos em torno do DA no futuro. Existem atualmente Celestia, Polygoin avail, e no futuro, EigenLayer, Ethereum danksharding, etc.
Com base na análise anterior, concluímos que o papel do Sequencer deve fazer parte do DA, e se a camada DA pode fornecer recursos de verificação de transações para o aplicativo, e tem desempenho suficiente, de fato, o DA pode assumir a responsabilidade do Sequencer, e o usuário grava transações diretamente no DA. Claro, se você pode usar o token do aplicativo para pagar a taxa de gás da DA é outro problema que precisa ser resolvido.
As linguagens de programação DApp vão explodir
Novas formas de aplicação levarão à explosão de novas linguagens de programação, o que foi comprovado na era Web2. Move será a melhor linguagem para construir Web3 DApps. Além da natureza linguística do Move em si, existem as seguintes razões:
Os DApps podem acumular rapidamente as bibliotecas básicas necessárias para aplicações na mesma língua, formando um efeito de aglomeração ecológica. Portanto, suportar vários idiomas não é uma boa estratégia no início.
No mínimo, os aplicativos descentralizados precisam ser verificáveis, e as linguagens de contrato inteligente podem reduzir muita carga mental sobre os desenvolvedores em termos de garantir a verificabilidade.
A natureza agnóstica de plataforma do Move facilita a adaptação a diferentes plataformas e aplicativos.
O estado de uma movimentação é estruturado, o que facilita a representação da estrutura de dados do DApp, bem como a recuperação de armazenamento.
Resumo
Eu entrei no blockchain no final de '17, quando havia tantas equipes na indústria tentando construir aplicativos no espaço blockchain. Infelizmente, a infraestrutura ainda não estava completa, e a indústria ainda não tinha descoberto um modelo replicável para a criação de aplicativos, e a maioria dos projetos de aplicativos terminou em fracasso, atingindo desenvolvedores e investidores. Como um aplicativo deve ser construído em um blockchain? Esta questão vem pensando em mim há cinco anos.
Agora, com a maturidade da Camada 1, Camada 2, contratos inteligentes e infraestrutura modular, a resposta a essa pergunta está gradualmente se tornando mais clara.
Espero que na próxima explosão de Web3 DApps, Rooch pode ajudar os desenvolvedores a construir aplicativos mais rápido e realmente aterrissar.
