Repost the original title: Sharded L2? “=nil;” How to give a new solution to L2 state fragmentation?

A mudança do Ethereum para um roadmap centrado em rollups induziu um crescimento explosivo em designs modulares de escalonamento. Este crescimento foi inicialmente um sucesso, eliminando taxas de gás de mais de $100 e desbloqueando designs de aplicativos completamente novos. Mas apenas alguns anos depois, o Ethereum e seus rollups enfrentam um novo problema crítico: fragmentação de estado.

Fundamentalmente, a fragmentação do estado é um problema de dimensionamento. Recentemente, a comunidade modular tem impulsionado soluções de middleware que fundem rollups existentes em um único sistema, aparentemente alcançando o Santo Graal do dimensionamento da blockchain - escalabilidade horizontal. No entanto, essas soluções vêm com compensações significativas. Uma nova geração de Ethereum L2s está repensando a escalabilidade a partir de primeiros princípios, aplicando técnicas verticais e horizontais para fornecer desempenho de fim de jogo.

Duas Direções de Dimensionamento de Blockchain

Existem dois frameworks para dimensionar uma blockchain:

• Escalabilidade verticalaumenta os recursos disponíveis para um único nó. Esta é a filosofia de escalonamento da Solana de maximizar a utilização de hardware, bem como o movimento de VM (máquina virtual) paralelizado.
• Escalonamento horizontaldistribui a carga de trabalho entre vários servidores. Esta é a filosofia de escalonamento de blockchains L1 fragmentados, como Near e Ethereum (Danksharding).

Rollups são frequentemente considerados erroneamente uma solução de escalonamento horizontal para o Ethereum. No entanto, cada rollup, e cada blockchain, é definido pelo livro-razão que mantém, ou seja, rollups são sistemas separados do Ethereum. Essa supervisão fundamental dos princípios básicos de escalonamento de bancos de dados deixou o ecossistema do Ethereum com um desafio existencial a ser resolvido: fragmentação de estado.

Desafio pela frente

Fragmentação do estado em vários L2s se transformou em um grande problema para o Ethereum. A fragmentação é definida por três novos problemas.

• Os efeitos de rede comprometidos do estado global, incluindo liquidez e distribuição de usuários, estão enraizados nas dezenas (se não centenas) de L2s adjacentes ao Ethereum que buscam infraestrutura específica do aplicativo.
• Complexidade crescente de padrões de interoperabilidade e coordenação social, que tem sido o catalisador de mais de $2.8 bilhões de hacks de ponte.
• Objetivamente piorou as experiências dos desenvolvedores e dos usuários. Os desenvolvedores precisam trabalhar com abstrações de rede complicadas para oferecer uma experiência de usuário perfeita, ouos usuários são obrigados a gerenciar a complexidade da interação entre cadeias, incluindo a ponte de ativos, o gerenciamento da rede da carteira e múltiplos tokens de gás.

E esses problemas estão piorando dia após dia. Limitadas pela infraestrutura existente, as aplicações sensíveis ao preço são forçadas a se isolar para manter taxas de transação confiavelmente baixas. Conforme o próximo ciclo se aproxima, um efeito bola de neve vicioso está prestes a acontecer; à medida que as taxas de congestionamento da L2 aumentam, mais desenvolvedores são forçados a optar por infraestrutura específica do aplicativo, exacerbando os problemas pervasivos associados à fragmentação de estado (já existentes). Em poucos anos, não seria surpresa se a incapacidade das L2s de resolver a fragmentação de estado levasse à queda da dominância de aplicativos no ecossistema Ethereum.

Resolvendo Fragmentação de Estado

A fragmentação do estado é fundamentalmente um problema de dimensionamento em que a responsabilidade permanece no L2 para dimensionar sem fraturar a composabilidade. Existem duas abordagens que os L2s podem adotar para resolver a escalabilidade.

• Unificar rollups existentes em um único sistema, alcançando assim a “escalabilidade horizontal”.
• Comece do zero e projete um L2 escalável.

Trabalhando de Trás para Frente

A primeira abordagem é bastante popular entre os L2s incumbentes. A fusão de rollups é alcançada usando um middleware para estabelecer uma noção de um único sistema. Efetivamente, essas soluções facilitam a comunicação entre rollups por meio de garantias de consenso compartilhadas. Tais soluções incluem sequenciadores compartilhados, provadores compartilhados e várias arquiteturas L3.

Embora as equipes e projetos que trabalham nessas soluções sejam fortes, uma abordagem centrada em middleware para resolver a escalabilidade L2 vem com grandes compensações, incluindo:

• Vulnerabilidades da cadeia mais fraca: a segurança e propriedades da rede são herdadas da pior parte do conjunto.
• Um ambiente de desenvolvedor fragmentado: ambientes diferentes ligados por middleware ainda resultam em uma experiência de desenvolvimento fragmentada.
• Coordenação social global de padrões de rollup cruzado: para mesclar rollups existentes, centenas (potencialmente milhares) de partes interessadas precisam concordar sobre as melhores práticas.

Mais criticamente, isso distrai as equipes L2 de resolver os problemas abertos de precificação de taxas de congestionamento e censura de único ator, que exigem esforços significativos de engenharia e pesquisa.

Um Novo Começo

As camadas 2 do Ethereum podem ser escaladas verticalmente alterando o ambiente de execução de um nó de rollup para aumentar a utilização de hardware; tais projetos incluem Eclipse e Movement Labs, que estão construindo rollups utilizando o SVM e MoveVM, respectivamente. Esta abordagem oferece grande promessa para melhorias de escalabilidade a curto prazo; no entanto, requer que os desenvolvedores do Ethereum adotem um novo conjunto de tecnologias.

Alternativamente, L2s podem escalar horizontalmente por meio da (re)introdução do particionamento de execução, o que permitiria que a rede escalasse adicionando novos nós. Esta abordagem promove a descentralização, possui limites de escalonamento teóricos mais altos e permite otimizações de escalonamento vertical, se necessário. Dadas essas vantagens, a =nil; Foundation projetou um L2 particionado chamado =nil;.

=nil; otimiza para preservar os valores fundamentais do Ethereum de descentralização, resistência à censura e permissão. =nil; é a primeira arquitetura de fragmentação verificável com base em um design inovador, zkSharding. Ele permite as propriedades de dimensionamento dos frameworks de dimensionamento horizontal pós-fato acima, com o benefício adicional de um ambiente de desenvolvimento integrado único. Isso dá aos desenvolvedores acesso à escala de 1000s de rollups de uma única rede. Mais importante ainda, =nil; garante taxas de transação baixas e confiáveis mesmo em meio a cargas de transação de pico.

Além disso, =nil; resolve as taxas de congestionamento dividindo e mesclando dinamicamente o estado entre shards com base na demanda de acesso ao estado. Esse comportamento dinâmico permite que =nil; mantenha as taxas de transação de forma confiável baixas (<$0.01). No geral, a missão da Fundação =nil; é oferecer um caminho alternativo para a escalabilidade da camada 2 do Ethereum que está mais alinhado com os valores centrais do Ethereum e a demanda por execução da camada 2.

Considerações Finais

Apesar dos muitos desafios pela frente, o futuro para os L2s do Ethereum parece mais promissor do que nunca. À medida que os designs L2 amadurecem e entramos na próxima geração de soluções de escalonamento, existem duas divisões predominantes: trabalhar retroativamente vs. começar do zero e escalonamento horizontal vs. vertical.

Sharding está morto, viva o sharding.

Declaração:

1. Este artigo é reproduzido de [foresightnews], the copyright belongs to the original author [Avi Zurlo,=nil; Fundação], se você tiver alguma objeção à reimpressão, entre em contato Equipe Gate Learn, a equipe lidará com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. Isenção de responsabilidade: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões do artigo são traduzidas pela equipe Gate Learn e não são mencionadas emGate.ioO artigo traduzido não pode ser reproduzido, distribuído ou plagiado.