Comparando Ethereum 2.0 com Near e Polkadot, interpretando o futuro do blockchain modular

“A relação entre blockchain modular e blockchain único é complementar e não conflituosa.”

Título original: “Futuro coexistente de plataformas de contratos inteligentes”

Escrito por: FF, Equipe de Pesquisa do LBank Labs

Compilado por: Sharon, BlockBeats

Nota do editor:

O blockchain modular tornou-se uma das tendências de desenvolvimento de 2024 identificadas por membros da comunidade criptográfica, incluindo instituições de investimento como a16z. Ao mesmo tempo, a atualização do Ethereum Cancun é iminente e há várias opiniões sobre blockchain modular e tecnologia de blockchain monolítica na comunidade. O LBank publicou recentemente um artigo apresentando sua própria opinião sobre isso. Depois de comparar e analisar a arquitetura técnica subjacente do Ethereum 2.0 com Near e Polkadot, o LBank acredita que blockchains modulares e blockchains únicos não devem ser considerados antagônicos, mas devem ser considerados complementares. , a cadeia modular pode servir como middleware da cadeia de monômeros, e a cadeia de monômeros pode servir como uma camada específica da cadeia modular. Eles aprendem com os pontos fortes e fracos uns dos outros e se desenvolvem juntos. BlockBeats compila o texto original da seguinte forma:

##TL; DR

Este artigo é uma continuação de nossa pesquisa anterior intitulada Oportunidades em Narrativas Modulares. Nesse artigo, nos aprofundamos na onda modular impulsionada por Ethereum e Celestia e identificamos as diversas oportunidades.

É importante notar, contudo, que as narrativas modulares não devem limitar a nossa perspectiva. Nos últimos anos, a tecnologia blockchain fez progressos significativos, com o surgimento de arquiteturas blockchain monolíticas e modulares.

Neste artigo, analisaremos primeiro essas duas abordagens arquitetônicas e compararemos o Ethereum com outros concorrentes do Ethereum do ciclo anterior. Surpreendentemente, existem mais semelhanças entre eles do que as pessoas pensam.

A seguir, exploraremos os desafios e as considerações específicas associadas a essas duas abordagens arquitetônicas enquanto olhamos para um futuro simbiótico para plataformas de contratos inteligentes. No passado, o ecossistema blockchain era dominado por blockchains monolíticos, com cada novo blockchain L1 operando de forma independente, resultando em concorrência acirrada e cooperação limitada no mercado; no entanto, estamos agora em uma conectividade cadeia a cadeia e interoperabilidade entre os estágios estão mais desenvolvidos do que nunca. Por isso, preferimos plataformas abertas, sejam elas modulares ou monolíticas.

Todas as arquiteturas blockchain levarão à expansão

Esta seção fornece uma comparação detalhada das diferenças e semelhanças entre Ethereum e outras blockchains monolíticas, destacando suas diferenças no design arquitetônico. Também discute as diferenças entre design modular e arquitetura monolítica, bem como os desafios envolvidos na obtenção de uma verdadeira escalabilidade.

Embora o próprio Ethereum tenha um design modular, ele também usa sharding como meio de alcançar escalabilidade. A fragmentação permite que transações e dados sejam processados em paralelo em vários fragmentos, aumentando o rendimento e a capacidade.

No entanto, a implementação da fragmentação também traz o seu próprio conjunto de desafios, como garantir a disponibilidade dos dados, a finalidade da transação e facilitar as transações de rollup cruzado. Superar esses desafios requer uma consideração cuidadosa e soluções inovadoras para integrar com sucesso o sharding em um blockchain monolítico. Exemplos de fragmentação incluem Ethereum, Near e Polkadot.

ETH 2.0 e próximo

O passado do Nightshade Design

A comparação do Ethereum 2.0 (ETH2.0) e do Near Protocol concentra-se nas principais diferenças em suas abordagens. A abordagem da Ethereum envolve fragmentação centrada em Rollup, onde as camadas de execução e disponibilidade de dados são dissociadas. Isso aproveita o L1 subjacente para fornecer segurança e rollup para escalabilidade.

Near decidiu construir uma rede fragmentada desde o início, considerando totalmente a existência de fragmentação de dados e fragmentação de execução em sua arquitetura integrada. Esta é a primeira diferença fundamental. O design do método central Rollup do Ethereum é relativamente simples, mas ainda requer fragmentação de disponibilidade de dados (Danksharding) para permitir que L2 opere com eficiência.

A segunda diferença principal é claramente explicada abaixo. Em comparação com a cadeia de beacon comum e a cadeia de retransmissão, Near escolheu uma solução de fragmentação diferente. Perto de si é dividido em diferentes shards, cada shard é responsável por gerar e armazenar blocos como parte do bloco.

O design chamado “Nightshade” torna possível obter leitura e gravação de contratos inteligentes contínuas entre fragmentos, embora isso imponha um limite mais alto para os desenvolvedores. Para os usuários, eles nem estarão cientes dos fragmentos com os quais estão interagindo.

Na narrativa modular do artigo anterior, discutimos soluções para os problemas de composição e interoperabilidade. No entanto, isso não é um problema para o Near porque seu sharding integrado permite essencialmente transações entre fragmentos, semelhantes às transações de rollup cruzado em L2.

O roteiro do Nightshade inclui as seguintes etapas:

• Estágio 0: Nightshade Simples, apenas um shard;
• Fase 1: Produtor somente de pedaços (Nota do editor: refere-se a um produtor que é o único responsável por gerar blocos em um shard (uma partição na rede));
• Fase 2: Full Nightshade, onde nenhum validador rastreia todos os shards;
• Fase 3: ajuste dinamicamente o número de fragmentos com base na carga.

Em termos de progresso, Near está atualmente entre a Fase 1 e a Fase 2. O produtor somente Chunk introduzido no ano passado só pode rastrear o status de um fragmento. No entanto, ainda existem validadores de nós completos responsáveis por manter o estado global.

Starsight em andamento: fragmentação centrada em ZK

Embora a Near seja líder no design de sharding, ela também aprendeu muito com a revolução Ethereum. Para atingir os objetivos da Fase 2, nenhum validador deve acompanhar todos os fragmentos. Em vez disso, o “pescador” atua como guarda de segurança, monitorando o status e gerando evidências de fraude nos desafios. O design principal é muito semelhante ao Optimistic Rollup, mas é complexo para implementar totalmente.

É por isso que muitos protocolos estão abandonando esta solução. Por exemplo, o Optimism mudou para uma solução zk e o Arbitrum não permite o envio de provas de fraude não licenciadas. Claramente, zkRollups são o futuro do Ethereum. Também podemos ver a influência do zkRollups no novo design de fragmentação do Near.

Verificação sem estado

E se houvesse uma solução melhor para eliminar o desafio por trás do jogo? É aqui que Near introduz a validação sem estado. A verificação sem estado gera verificação de estado sem entregar o estado a outros fragmentos. Com uma testemunha estatal, não há necessidade de “pescador” ou prova de fraude.

Em uma configuração de validação sem estado, existem dois tipos de validadores. Os validadores de nós completos anteriores foram agora alterados para validadores sem estado, enquanto os proponentes de blocos permanecem inalterados. Os proponentes de blocos são responsáveis por gerar blocos e testemunhas de estado, que precisam manter o estado do fragmento localmente.

Os validadores apátridas, por outro lado, recebem testemunhas estaduais para verificar a transição de estado de cada bloco. Ao introduzir a rotação do validador, é quase impossível que um validador corrompa um fragmento.

A introdução da validação sem estado traz muitos benefícios. O custo de funcionamento de validadores sem estado é muito menor do que antes, permitindo que mais validadores adiram ao consenso. Isso aumenta a descentralização de toda a rede. Para proponentes de blocos, à medida que mais fragmentos são adicionados, o estado de cada fragmento se torna menor. Como o gargalo do blockchain é principalmente a leitura e gravação de estado, o desempenho de um único fragmento pode ser significativamente melhorado se o estado for completamente mantido na memória.

A magia das provas de conhecimento zero

Antes do advento das provas de conhecimento zero (ZKP), as testemunhas estaduais eram tradicionalmente usadas no MPT. No entanto, com a maturidade e o desenvolvimento recente do ZKP, muitos protocolos, incluindo o Near, abraçaram ativamente esta transição. O ZKP se destaca pela simplicidade e recursos de privacidade que oferece, reduzindo significativamente o custo da verificação de transição de estado. Além dos dados compactados, o ZKP é pequeno e fácil de verificar. Ao aproveitar as provas recursivas, o estado de todos os fragmentos pode ser verificado coletivamente.

Uma prova de transição de estado para um fragmento consiste em três elementos básicos: garantir a exatidão do hash do bloco, confirmar a precisão do estado usado durante a execução e verificar a execução do tempo de execução. Atualmente, permanece um desafio – apesar do progresso significativo durante o ano passado, a geração de provas ainda leva mais tempo do que o esperado.

Espera-se que isto evolua ainda mais à medida que os esforços para demonstrar sistemas e capacidades de engenharia continuam. É por isso que Near se uniu à Polygon para construir o zkWASM.

Para manter a certeza rápida atual sem afetar a experiência do usuário, Near fez ajustes modulares. A Starsight dissociou consenso e execução, permitindo que o consenso seja executado de forma independente e decida quais transações serão incluídas em um bloco. Chamadas de procedimento remoto (RPC) fornecem finalidade otimista. Uma vez gerada uma prova para uma transição de estado específica, ela é submetida a um bloco e um validador posteriormente verifica a validade da prova.

Esta prova atua como confirmação da nova raiz de estado e da nova raiz de recebimento de saída. Neste caso, as provas de conhecimento zero funcionam como testemunhas estaduais. No entanto, o ZKP só pode ser confirmado ou rejeitado por consenso, eliminando a necessidade de rotação do validador. O ZKP garante correção e segurança por meio da matemática e funciona de forma muito semelhante ao Rollup, que herda os recursos de segurança do Ethereum.

O design modular pode proporcionar benefícios adicionais em cadeias monolíticas. A flexibilidade do Starsight é que ele funciona não apenas com o tempo de execução Near WASM existente, mas também com qualquer tempo de execução que possa gerar provas zk para transições de estado, como EVM e Move.

ETH 2.0 e Polkadot

Mesma filosofia de design

Existem mais semelhanças entre Ethereum 2.0 e Polkadot do que inicialmente esperado, uma confirmação destacada pela semelhança de implementações de Gavin Wood. Alguns até sugeriram que Polkadot representa o objetivo final do ETH 2.0 e, embora isso não seja totalmente preciso, a analogia captura uma verdade fundamental.

Da nossa perspectiva, Polkadot demonstra um nível mais alto de maturidade em engenharia. Antes que houvesse prova de conhecimento zero, a arquitetura centrada no Rollup do Ethereum estava intimamente integrada ao design do Polkadot. Uma comparação direta de termos pode revelar semelhanças impressionantes nos seus objetivos finais.

Corrente de farol e corrente de relé

Como camada de coordenação, a cadeia de beacon enfatiza a disponibilidade de dados de maneira centrada no rollup; a cadeia de retransmissão é responsável pela retransmissão de mensagens e pela manutenção dos dados da cadeia paralela. A segurança compartilhada vem da cadeia de retransmissão e o Ethereum se posiciona para herdar a segurança … sexo.

Rollup e Parachain

As cadeias paralelas são responsáveis por executar transações, publicar dados na cadeia de retransmissão e personalizar suas próprias transições de estado; o Rollup executa transações fora de L1, depois publica os dados em L1 e chega a um consenso.

Uma filosofia de design consistente é evidente: mantenha a camada base simples, mantenha a disponibilidade dos dados, coordene as informações e aproveite as camadas superiores para aprimorar totalmente a funcionalidade e a escalabilidade.

Diferentes estratégias e ciclos levam a resultados diferentes

Apesar de compartilharem as mesmas filosofias de design e trabalharem em prol de objetivos comuns, o status atual dos dois blockchains difere dramaticamente. De acordo com estatísticas do Etherscan e Subscan, o volume diário de transações do Ethereum ultrapassa 1 milhão, enquanto o Polkadot teve apenas 12.000 nos últimos dias. Quanto às contas ativas diariamente, vemos 395.000 no Ethereum e 8.000 no Polkadot.

A diferença em seu status atual se deve em grande parte às suas respectivas estratégias. Polkadot busca a arquitetura definitiva e desiste deliberadamente da função de contrato inteligente. Os desenvolvedores precisam construir “paletes” ou módulos de cadeia de aplicativos, o que é um fardo pesado para muitos. A combinação de estratégias agressivas e o elevado limiar para leilões de slots resulta num ecossistema que carece de dinamismo suficiente para compensar estes desafios.

Em contrapartida, Ethereum prioriza o mercado e visa atender às necessidades do mercado. Ajusta o seu roteiro em conformidade, adotando uma abordagem passo a passo.

Embora não nos aprofundemos nas razões específicas do boom do Ethereum e do declínio do Polkadot, a comparação entre o ETH 2.0 e o Polkadot nos fornece informações valiosas sobre o futuro da arquitetura blockchain e o potencial de um ecossistema aberto e colaborativo.

Conceitos abstratos e padrões de excelência

Apesar dos desafios que enfrenta atualmente, Polkadot tem muitos designs avançados que valem a pena explorar e aprender.

Uma contribuição notável do ecossistema Polkadot é a estrutura de subestado, que fornece um excelente conceito de abstração para cadeias de aplicativos. Esta estrutura permite que as partes do projeto lancem facilmente suas próprias cadeias. Fora do ecossistema Polkadot, observamos muitas cadeias ativas sendo construídas no Substrate, incluindo projetos como Polygon Avail e Starknet Madara, sem mencionar inúmeras cadeias independentes.

Embora os “paletes” possam constituir um fardo técnico para os desenvolvedores de contratos inteligentes, eles fornecem ferramentas de abstração poderosas para os desenvolvedores de protocolos. Esses “paletes” podem ser reutilizados em todas as cadeias de substratos, ajudando a promover o consenso da comunidade e os esforços de padronização. Este recurso permite especialização e otimização para aplicações específicas.

As tendências atuais em recursos como serviço (RaaS), como pilha OP e Polygon CDK, demonstram um certo nível de abstração. No entanto, estas iniciativas como repositórios de código aberto ainda não são abrangentes em comparação com o Substrate. À medida que o RaaS evolui, podemos esperar maiores melhorias na personalização e disponibilidade dos módulos da cadeia.

A segunda característica distintiva do Polkadot é a passagem de mensagens de consenso cruzado (XCMP), um protocolo de mensagens que permite que parachains troquem mensagens arbitrárias sem passar pela cadeia de retransmissão. Isso significa que os contratos inteligentes podem ligar entre si dentro do mesmo parachain, bem como entre diferentes parachains.

Em contraste, a ponte de ativos e a comutação de rede são necessárias ao interagir com diferentes Rollups no Ethereum. Este processo traz desafios como liquidez fragmentada e interoperabilidade quebrada. Para resolver estes problemas, defendemos que a Fundação Ethereum desempenhe um papel de liderança no desenvolvimento de padrões e promova ativamente a aplicação destes padrões em vários Rollups. Esta abordagem contribuirá significativamente para que o desenvolvimento futuro do Ethereum e dos seus ecossistemas relacionados seja mais integrado e interoperável.

O último grande desenvolvimento do Polkadot é a implementação de um módulo de governança on-chain, transformando efetivamente o Polkadot em um verdadeiro metaprotocolo. Este módulo dá às partes interessadas o poder de votar diretamente na cadeia e decidir o destino das atualizações da cadeia. Assim que um limite predeterminado for atingido, a cadeia realizará atualizações de tempo de execução de forma autônoma. Isto representa uma mudança considerável em relação ao principal mecanismo de consenso social do Ethereum hoje.

Desafios a serem resolvidos

A comparação acima mostra que, embora existam diferenças sutis, a essência das plataformas de contratos inteligentes permanece basicamente a mesma. Portanto, tanto os blockchains monolíticos quanto os modulares enfrentam certos desafios.

Nesta seção, exploraremos dois desafios comuns enfrentados pelas plataformas de contratos inteligentes como um todo, antes de nos aprofundarmos em questões específicas relacionadas às cadeias modulares.

Principais dilemas de inovação

Um dos principais desafios enfrentados pelas plataformas de contratos inteligentes é estabelecer um ambiente competitivo e inovador. A popularidade das soluções L1 compatíveis com EVM tornou-se um tanto monótona, até mesmo Vitalik Buterin as classificou de acordo com sua compatibilidade.

Embora reconheçamos o significado histórico do inovador EVM e do Solidity, também é fundamental reconhecer que a tecnologia evoluiu ao longo do tempo. Insistir na natureza legal e tradicional do EVM pode limitar o progresso, especialmente face aos limites de bloco do Ethereum.

A empolgação com diferentes arquiteturas, máquinas virtuais (VMs) e linguagens de contratos inteligentes decorre do desejo de escapar das limitações do EVM. A diversidade nesses aspectos atrai desenvolvedores e usuários que preferem utilizar diferentes linguagens de programação e recursos de contratos inteligentes. Por exemplo, no mercado primário, Move VM (Aptos, Sui) e Cario VM (Starknet) alcançaram valorizações elevadas devido às expectativas de inovação e possibilidades que trazem.

Ao apostar na próxima plataforma inovadora, o domínio da quota de mercado EVM deve ser reconhecido. Mas à medida que o mercado amadurece, tende a cair num duopólio, com Android & iOS e Windows & Mac sendo exemplos.

WASM é um forte concorrente da EVM, sendo Solana o maior player. Apesar das críticas, as principais inovações de Solana, como o relógio Proof-of-History (POH), o Optimistic Concurrency Control (OCC) e o protocolo de encaminhamento de transações sem mempool, diferenciam-no de outros protocolos e rompem com o limite tradicional de design de blocos.

Como construir um amplo consenso

O consenso aqui mencionado ultrapassa o estreito nível técnico e envolve o amplo campo do consenso social.

Do ponto de vista do consenso, é compreensível que muitos L1 e L2 optem pela compatibilidade EVM. Esta opção fornece a maneira mais fácil de se conectar ao ecossistema Ethereum. No entanto, à medida que o número de cadeias de EVM e Rollups aumenta, a diminuição da utilidade marginal tende a atrair desenvolvedores e usuários transitórios e desleais, que podem sair rapidamente após receber lançamentos aéreos.

Além da compatibilidade com EVM, a construção de consenso através do reestabelecimento fornece outra narrativa convincente para envolver a comunidade existente. Construir do zero está se tornando cada vez mais complexo, ressaltando a importância de escolher o ativo de rehipoteca certo. Um ponto sutil, mas crítico, é que, supondo que todas as camadas modulares usem Derivados de Segurança L1 (LSD) para garantir a segurança, a diferença entre um blockchain monolítico e um blockchain de bloco modular é reduzida.

Além disso, alguns protocolos estendem sua influência a um grupo mais amplo de usuários da Web2, especialmente na área de jogos. Embora esta abordagem seja eficaz, requer um forte esforço de desenvolvimento empresarial. Muitos intervenientes tradicionais preferem expandir a sua base de utilizadores como forma de alcançar consenso num ambiente em mudança.

Problemas específicos com cadeias modulares

Embora os blockchains modulares distribuam com eficiência as cargas de trabalho entre cadeias ou módulos conectados, resolver desafios específicos é fundamental para alcançar a verdadeira escalabilidade. As principais preocupações com cadeias modulares incluem fragmentação, fragilidade, execução cruzada e centralização.

1. Fragmentação: A fragmentação resulta da competição acirrada entre diferentes camadas. Embora os concorrentes atuais possam não colaborar imediatamente, espera-se que a evolução dos protocolos universais e das abstrações de contas forneça aos usuários uma experiência perfeita em vários produtos;

2. Vulnerabilidade: A vulnerabilidade resulta de diferentes suposições de segurança entre diferentes camadas. Numa blockchain modular, cada módulo opera de forma independente, introduzindo potenciais vulnerabilidades. Quando uma camada específica encontra um problema, ela pode afetar outras camadas integradas – uma compensação inerente ao movimento em direção à modularidade;

3. Execução de rollup cruzado: No blockchain modular, a execução de rollup cruzado é crucial para alcançar a interoperabilidade do blockchain modular. A falta de protocolos padronizados dificulta a integração perfeita entre diferentes módulos. Além disso, os problemas de execução assíncrona, inerentes à fragmentação, devem ser abordados para alcançar a verdadeira escalabilidade das blockchains modulares;

4. Centralização: Embora a descentralização do Rollup possa não ser tão crítica quanto a descentralização do L1, ainda é uma questão de segurança importante. A descentralização é necessária para garantir a vitalidade, resistir à censura e evitar vantagens monopolísticas. O protocolo está trabalhando ativamente para resolver esses problemas por meio de soluções como ordenadores de fragmentos, código padrão abstrato e exposição da lógica de negócios apenas para desenvolvedores de cadeia. A adoção dessas soluções pode ajudar a resolver problemas de execução de rollup cruzado.

Um futuro de colaboração e inclusão

Ao examinar as duas partes acima, fica claro que os blockchains modulares e monolíticos representam produtos de diferentes épocas, incorporam compensações no triângulo impossível e refletem diferentes escolhas filosóficas.

Durante anos, o espaço criptográfico ficou preso em um ciclo de blockchains monolíticos, com cada novo L1 construindo um sistema fechado, provocando intensa competição de soma zero. Este ambiente conduz frequentemente ao extremismo, à medida que as plataformas competem pelos utilizadores nos seus ecossistemas.

O surgimento da blockchain modular introduz uma abordagem colaborativa e inclusiva que enfatiza a colaboração e a interconexão entre diferentes cadeias – um desenvolvimento positivo para toda a indústria. Uma abordagem colaborativa permite que os módulos funcionem perfeitamente juntos, melhorando a funcionalidade geral e a experiência do usuário.

Além disso, a natureza colaborativa do blockchain modular facilita o desenvolvimento de módulos inovadores e especializados. A colaboração e o compartilhamento de recursos entre diferentes cadeias permitem que os desenvolvedores se concentrem em áreas específicas de especialização, resultando em módulos personalizados e de alta qualidade, adequados para casos de uso específicos. Além disso, as rupturas da cadeia monolítica podem ser desacopladas e mescladas sequencialmente em camadas modulares.

É crucial que blockchains modulares e blockchains monolíticos não sejam vistos como adversários, mas sim como complementares. Eles aprendem com os pontos fortes e fracos uns dos outros e se desenvolvem juntos. Os limites entre elas podem não ser óbvios, pois as cadeias modulares podem atuar como middleware para cadeias monolíticas, enquanto as cadeias monolíticas podem atuar como camadas específicas de cadeias modulares.

Em vez de se concentrar em distinções categóricas, o foco deve mudar para o cultivo de uma rede aberta, a adoção de inovações importantes e a construção de um amplo consenso.

Apêndice:

Introdução ao formato de mensagem de consenso cruzado (XCM) · Polkadot Wiki

Polkadot: A Fundação de uma Nova Internet | por Jack Platts | Rede Polkadot | Médio

Substrato — Pilha de tecnologia Web3

O cenário da pilha OP | Documentos ON Stack

OpenGov: O que é Polkadot Gov2 | Rede Moonbeam

NEARCON 2023 | Estágio da Camada 2 – Dia 2 – YouTube

Roteiro Ethereum | ethereum.org

Arquitetura Stateful versus Stateless: Por que a Stateless venceu | Virtasant

NEAR—A Blockchain em operação | Documentação NEAR

Provedores de implementação Polygon CDK

O cenário da pilha OP