Apresentamos o Eclipse Mainnet: O Ethereum SVM L2

O Eclipse Mainnet é um L2 de uso geral que combina as melhores peças da pilha modular:

1. Liquidação: Ethereum - Eclipse vai liquidar com Ethereum (ou seja, a ponte de validação consagrada será no Ethereum) e usará ETH como seu token de gás.
2. Execução: Máquina Virtual Solana (SVM) - O Eclipse executará o SVM de alto desempenho como seu ambiente de execução.
3. Disponibilidade de dados: Celestia - Eclipse publicará os seus dados no Celestia para disponibilidade de dados escalável (DA).
4. Provando: RISC Zero - Eclipse usará RISC Zero para provas de fraude ZK (sem serialização de estado intermediário!)

A maioria das manchetes do Eclipse tem estado em torno do nosso trabalho para implantar rollups específicos de aplicativos para uma série de projetos, mas agora está mais claro do que nunca que o Ethereum precisa de um L2 de uso geral capaz de uma escala verdadeiramente massiva. A maioria das aplicações não se beneficia de personalizações de cadeia específicas da aplicação, e o isolamento e a complexidade resultantes podem realmente resultar numa pior experiência do utilizador e do programador.

Muitas vezes é apresentada uma falsa dicotomia entre a visão modular de rollup versus a capacidade de ter uma única cadeia com escala massiva, execução paralelizada e estado partilhado. “Modular” é muitas vezes confundido com “específico da aplicação”, o que o levaria a acreditar que os rollups significam um mundo de muitas cadeias fragmentadas e de baixo rendimento. Desafiamos essa ideia.

Execução: Escala de Velocidade & de Solana

O Eclipse Mainnet adotará o melhor ambiente de execução do Solana. Isto traz vantagens tremendas:

Execução Paralela Otimizada

O SVM e o seu tempo de execução Sealevel permitem a execução de transações paralelas. As transações que não tocam no estado de sobreposição podem ser executadas em paralelo e não sequencialmente.

Isto permite que o SVM escale diretamente com o hardware à medida que os processadores continuam a adicionar mais núcleos a um custo mais baixo. Os tempos de execução de encadeamento único (como o EVM de hoje) fundamentalmente não beneficiam da redução do custo por núcleo. Há mais de uma década que as acelerações de desempenho de encadeamento único têm vindo a diminuir continuamente. Quase todas as melhorias continuam a vir do aumento do número de núcleos, por isso é fundamental aproveitar esta tendência paralelizando as cargas de trabalho:

Existem algumas tentativas muito iniciais não comprovadas de paralelizar o EVM, mas adicionar isso enquanto mantém a compatibilidade traz compensações fundamentais, incluindo desempenho subótimo sem abordar outros gargalos (por exemplo, crescimento do estado). Os contratos que declaram as dependências de estado antecipadamente (como no SVM) permitem uma paralelização ideal.

Mercados de Taxas Locais

A maioria dos mercados de taxas hoje são globais, o que significa que uma aplicação quente aumenta as taxas para todos os utilizadores da cadeia. Uma moeda NFT não deve tornar a cadeia inútil para todo o resto. O incrível trabalho de Solana nos mercados de taxas locais resolve esta contenção estadual entre aplicativos. Na sua implementação atual, o agendador prioriza as transações sem conflitos, permitindo que as transações sem conflitos passem com taxas mais baixas. A longo prazo, os mercados de taxas locais serão implementados a nível de protocolo. Isto garante que os picos de taxas para uma única aplicação não afetem o resto da cadeia.

Os mercados de taxas locais são possíveis graças ao tempo de execução exclusivamente paralelizado de Solana. Tentar implementar mercados de taxas locais para hotspots estaduais no EVM usando heurísticas (ou seja, sem declarar o acesso do estado antecipadamente) apresentaria ineficiências e prováveis vetores de ataque.

Há também pesquisas iniciais em andamento que permitiriam que as aplicações internalizassem facilmente o valor local atribuível a elas, o que hoje em dia geralmente requer um design mais criativo no nível do aplicativo.

Gestão do Crescimento do Estado

Antes mesmo de o EVM se deparar com a execução sequencial como um gargalo, o crescimento do estado é o seu gargalo muito mais premente.

Como não existe uma árvore Merkle para o estado, Solana não incorre na sobrecarga de atualizar uma árvore Merkle para cada atualização de estado. Em vez disso, depois de cada época (~2,5 dias), todo o estado é merklizado. Isto é muito mais barato do que a merização em tempo real (como no EVM).

Mais importante ainda, o EVM tem acesso dinâmico à conta (ou seja, as transações podem tocar qualquer estado a pedido). Essa pesquisa de estado dinâmico significa que o estado não pode ser carregado na memória antes da execução. No SVM, cada transação especifica todo o estado necessário para a execução.

Como resultado, o tamanho do estado não afeta a execução do SVM. A rede poderia dobrar com segurança o tamanho do snapshot a cada 2 anos sem ter problemas graves, supondo que os validadores actualizem os seus discos de armazenamento a cada 2 anos.

Além disso, equipas como a Helius estão a melhorar ativamente a acessibilidade dos dados históricos e a reduzir o tamanho do estado com a compressão.

Compatibilidade EVM

O Neon EVM é um EVM que opera como um contrato inteligente que pode ser implementado em qualquer cadeia SVM. Isto traz compatibilidade total de EVM ao Eclipse Mainnet (incluindo suporte a bytecode EVM e o Ethereum JSON-RPC) com maior rendimento do que os EVMs de encadeamento único. Como cada instância do Neon EVM tem o seu próprio mercado de taxas local, as aplicações podem simplesmente implementar o seu próprio contrato para obter os benefícios de uma cadeia de aplicações sem fragmentar a UX, a segurança ou a liquidez.

Separadamente, o compilador Solang permite a compilação do código de contratos inteligentes Solidity em bytecode SVM.

MetaMask Snaps

A integração de utilizadores de EVM a cadeias não-EVM tem sido historicamente um grande obstáculo, mas os recentemente revelados Metamask Snaps estão definidos para quebrar essa barreira. Os utilizadores de EVM podem continuar a usar o MetaMask sem ter de trocar de carteira. O UX é comparável à interação com qualquer cadeia EVM, graças às contribuições de código aberto do Driftque construíram uma excelente implementação do MetaMask Snap. Os utilizadores do Eclipse Mainnet poderão interagir com aplicações nativamente no MetaMask ou usar uma carteira nativa da Solana como o Salmon.

Aqui está uma espiada do UX da Drift:

Bombeiro

O Firedancer é o tão esperado cliente Solana que está a ser desenvolvido pela Jump para aumentar drasticamente o rendimento, a resiliência e a eficiência da rede. No lançamento vamos ficar o mais próximo possível do cliente principal Solana, mas planeamos adotar o Firedancer assim que o código estiver ativo e estável.

Segurança

O tempo de execução do Solana tem uma área de superfície de ataque bastante reduzida que impede as infames explorações de reentrada que vimos com demasiada frequência. Especificamente, o tempo de execução Solana permite apenas que os programas se auto-recorram, em vez de permitir invocações arbitrárias entre programas reentrantes. Além disso, separar o estado e o código resulta em código sem estado, o que normalmente é mais fácil de testar eficazmente.

Prova mais fácil

O SVM é baseado em registo e tem um conjunto de instruções muito menor em relação ao EVM, tornando a execução do SVM mais fácil de provar no ZK. Para rollups otimistas, o design baseado no registo permite um checkpoint mais fácil.

Liquidação: Segurança da Ethereum & Liquidez

Tal como acontece com os principais rollups de hoje, o Eclipse Mainnet vai liquidar com o Ethereum. Concretamente, isso significa que a nossa ponte de validação no Ethereum será diretamente consagrada no Eclipse. Os nós do eclipse vão olhar para esta ponte para determinar a “cadeia canónica”. A ponte impõe a ordem correta para o Eclipse.

Isto permite que os nossos utilizadores obtenham certas propriedades de segurança do Ethereum. A ponte validará todas as transações do Eclipse, impedindo a apresentação de estados inválidos. Além disso, reforçará a eventual resistência à vida e à censura em certos casos de falha. Mesmo que o sequenciador caísse ou começasse a censurar no L2, os utilizadores poderiam forçar a inclusão das suas transações através da ponte.

Por causa destas propriedades de segurança, os validiums e os optimiums são frequentemente referidos como “Ethereum L2s”. O L2BEAT define um L2 como “uma cadeia que deriva total ou parcialmente a sua segurança da camada um Ethereum para que os utilizadores não tenham de confiar na honestidade dos validadores L2 para a segurança dos seus fundos.”

A liquidação Ethereum reconhece a importância que os ativos nativos do Ethereum provavelmente terão nas economias DeFi e NFT da Eclipse Mainnet. ETH é o melhor dinheiro descentralizado que a maioria dos utilizadores prefere claramente, por isso também usaremos ETH como nosso token de gás. A longo prazo, a abstração de taxas permitirá aos utilizadores pagar em qualquer token de sua escolha (por exemplo, USDC). Não há planos para o Eclipse Mainnet ter o seu próprio token neste momento.

Disponibilidade de dados: Largura de banda da Celestia & Verificabilidade

O Eclipse Mainnet utilizará o Celestia para disponibilidade de dados (a.k.a. publicação de dados ou publicação de dados). A Celestia é uma parceira de ecossistemas de longa data da Eclipse.

O rendimento e as taxas alvo do Eclipse Mainnet infelizmente não são suportados pela largura de banda atual do Ethereum. Isso permanecerá assim mesmo depois do EIP-4844 (a.k.a. “Proto-dankSharding”), que fornece uma média de ~0,375 MB de espaço blobspace por bloco (com um limite de ~0,75 MB por bloco).

1. Para transferências ERC-20 com compressão básica (~154 bytes por transação), isto traduz-se em ~213 TPS em todos os rollups combinados.
2. Para swaps com compressão (~400 bytes por transação), isso se traduz em ~82 TPS em todos os rollups combinados.

Em comparação, o Celestia será lançado com blocos de 2 MB ainda este ano. Espera-se que o Blobspace aumente para 8 MB logo após o lançamento, assim que os nós de luz suficientes de amostragem de disponibilidade de dados (DAS) entrarem online e a rede se mostrar estável. Os nós de luz DAS servem duas funções críticas:

1. Permitir que os utilizadores verifiquem por si próprios que os dados do bloco do Eclipse foram disponibilizados
2. Contribuir para escalar de forma segura toda a rede, uma vez que as camadas DA podem aumentar com segurança o seu rendimento à medida que mais nós de luz DAS entram online

A Celestia deverá ser a primeira camada DA a ser lançada com DAS em produção. Isto contrasta com os tradicionais comités de disponibilidade de dados (DACs), que reintroduzem os pressupostos de honestidade do comité sem verificação do utilizador (semelhante aos blockchains monolíticos existentes).

Há uma suposição de segurança inerente para os utilizadores que unem os seus fundos do Ethereum Mainnet a qualquer cadeia que utilize DA fora da cadeia. Em particular, é tecnicamente possível que os validadores Celestia retenham os dados da transação mas afirmem à ponte Ethereum que os dados estão disponíveis. Na prática, o consenso de prova de participação da Celestia significa que a retenção de dados sobre a própria Celestia é cortável, tornando este risco irrealista a nosso ver.

No geral, o suporte aos nós leves DAS da Celestia desde o primeiro dia, as propriedades de segurança criptoeconómicas e a taxa de transferência de DA altamente escalável tornam-na a escolha clara para o Eclipse Mainnet hoje.

Note que alguns vendem o Ethereum DA onchain como um requisito para ser um verdadeiro “L2” aqui pelas razões descritas acima. Vamos pela terminologia L2 mais comum citada anteriormente e queremos ser claros sobre as considerações de segurança.

Também pretendemos monitorizar o progresso do Ethereum na escalabilidade da DA após EIP-4844. Novas pesquisas empolgantes continuam a surgir, potencialmente oferecendo DA de alto rendimento mais cedo do que as ideias anteriores (que usam tabelas de hash distribuídas mais avançadas). Se o Ethereum oferecer maior escala para o Eclipse em benefício dos nossos utilizadores, avaliaríamos a possibilidade de migrar para o Ethereum DA.

Provando: RISC Zero ZK Provas de fraude (sem serialização de estado intermédio!)

A nossa prova será semelhante ao SIMD de prova de fraude SVM da Anatoly, que é em si semelhante à visão de John Adler de que a serialização do estado é cara, e é possível evitá-la.

Especificamente, queremos evitar a reintrodução de uma árvore Merkle no SVM. Experimentámos inserir uma Sparse Merkle Tree no SVM no início, mas atualizar a árvore Merkle após cada transação resulta em resultados substanciais no desempenho. Provar sem uma árvore Merkle exclui estruturas de rollup generalistas existentes como o OP Stack como base para rollups SVM, e também requer uma arquitetura à prova de falhas mais criativa.

A um nível elevado, uma prova de falhas requer:

1. Um compromisso com entradas para uma transação,
2. A transação em si, e
3. Prova de que a reexecução da transação leva a um resultado diferente do que foi especificado na cadeia.

O compromisso de entrada é normalmente feito fornecendo a raiz Merkle para a árvore de estado do rollup. Em vez disso, o nosso executor publicará uma lista de entradas e saídas (incluindo hashes de conta e estado global relevante) para cada transação, juntamente com um índice da transação que produziu cada entrada. As transações são publicadas na Celestia, para que qualquer nó completo possa acompanhar para extrair contas de entrada do seu próprio estado, calcular as contas de saída e confirmar que o compromisso no Ethereum está correto.

Existem dois tipos possíveis de falhas graves:

1. Saídas incorretas - Neste caso, o verificador fornece uma prova ZK na cadeia das saídas corretas. Estamos a usar o RISC Zero para criar provas ZK da execução do SVM, continuando o nosso trabalho anterior comprovando a execução de bytecode BPF. Isto permite que o nosso contrato de liquidação garanta a exatidão sem ter de executar as próprias transações na cadeia.
2. Entradas incorretas - Neste caso, o verificador coloca na cadeia uma referência aos dados históricos mostrando que o estado de entrada não é o reivindicado. Usando a Quantum Gravity Bridge da Celestia, o nosso contrato de liquidação garante que esses dados históricos realmente provam fraude.

Porquê Eclipse, Porquê Ethereum, Porquê Agora

Estamos nos ombros de gigantes. Os rollups de hoje avançaram o estado da pesquisa para toda a nossa indústria e forneceram aos utilizadores do Ethereum taxas mais baratas em comparação com o L1.

No entanto, não aproveitam ao máximo a tecnologia mais recente que é necessária para escalar às massas. Os primeiros rollups priorizaram amplamente a compatibilidade EVM e/ou otimizações para uma prova ZK mais eficiente. Mais recentemente, porém, vimos progressos inacreditáveis que evitam a necessidade de fazer as compensações que os primeiros rollups escolheram e, de facto, os coloca em desvantagem:

1. VMs paralelizadas de alto desempenho (por exemplo, SVM)
2. Dimensionamento DA com suporte de nó leve DAS (por exemplo, Celestia)
3. Avanços na infraestrutura de prova para torná-la prática em qualquer lugar (por exemplo, RISC Zero)
4. Maior portabilidade do código (por exemplo, Neon e Solang) e utilizadores (por exemplo, MetaMask Snaps) entre ecossistemas

O Eclipse tem o enorme benefício da retrospectiva. Aprendemos com as limitações que outras cadeias enfrentaram e depois escolhemos as melhores peças para escalar a longo prazo.

https://twitter.com/0xMert? ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680271128537726976%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2FMirror.xyz%2Feclipsemainnet.eth%2FMe7BXLWJDS177V6NL8J1UZF1MXPx6NBGolneyBawxgs

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680285353662468097%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2FMirror.xyz%2Feclipsemainnet.eth%2FMe7BXLWJDS177V6NL8J1UZF1MXPx6NBGolneyBawXGS

Ouvimos falar frequentemente de um futuro com um milhão de rollups específicos de aplicação.

As personalizações a nível de consenso podem ser incrivelmente valiosas para determinadas aplicações (por exemplo, dYdX v4), e estamos entusiasmados em ajudar as equipas a lançar rollups específicos de aplicações.

No entanto, estes casos são poucos e distantes entre si. É por isso que a maioria dos novos rollups ainda são apenas garfos EVM de baunilha. Os problemas dos desenvolvedores não são resolvidos fragmentando a UX em mais cadeias. O principal caso de uso para um milhão de cadeias hoje parece ser o lançamento de mais um milhão de tokens. A procura de personalização full-stack simplesmente não existe hoje para a grande maioria dos casos de utilização.

Mesmo que a procura real existisse, a infraestrutura necessária para suportar muitas cadeias de aplicação com UX competitiva está a anos de distância (se alguma vez chegar ao nível). Superchain do otimismo (OP Stack), Hyperchains do ZKSync (ZK Stack), cadeias Orbit da Arbitrum e assim por diante têm visões de muitas cadeias com infraestrutura partilhada. Isto destina-se a fornecer UX mais suave a operar entre cadeias no mesmo ecossistema (por exemplo, entre duas cadeias dentro da Superchain) vs. cadeias completamente isoladas (por exemplo, entre Ethereum e Solana).

No entanto, os planos atuais (onde existem) ainda estão muito longe de serem competitivos com um único estado partilhado. Além disso, não abordam a interoperabilidade entre ecossistemas (por exemplo, Superchain para uma Hyperchain). Construir modular não deve significar construir ilhas.

É mais complicado para os utilizadores manter contas em muitas cadeias. É pior a experiência do utilizador continuar a estabelecer pontes e preocupar-se com o token de gás que precisa. É mais complicado e caro depender de fornecedores de infraestruturas para operar e manter tantas cadeias.

Sempre apreciamos a simplicidade da visão da Solana. Uma máquina de estado partilhado altamente otimizada com a escala para suportar a maioria dos casos de uso valiosos. Isso é muitas vezes visto como incompatível com um roteiro centrado no rollup, mas isso simplesmente não é o caso. Queremos combinar o melhor dos dois mundos.

Este equívoco surge devido ao facto de que os rollups de hoje estão a executar em grande parte o EVM vanilla single-threaded efetivamente inalterado, a fim de recuperar os primeiros efeitos de rede. Como resultado, muitas vezes vemos o “espaço de bloco dedicado” citado como a razão para implantar um rollup específico da aplicação. Essas loucas casas da casa da casa da casa da casa da casa da NFT não devem aumentar os preços de todas as outras aplicações da sua cadeia, mas a resposta não é ir fazer a sua própria cadeia. Isto é como usar uma marreta para quebrar um amendoim. Faz compensações dolorosas e desnecessárias (complexidade, custo, pior experiência do utilizador, liquidez fragmentada, etc.). A solução ideal é incrivelmente clara - basta usar uma VM paralelizada com mercados de taxas locais para hotspots estaduais. Isso é exatamente o que o SVM traz.

O Ethereum é o centro intelectual, social e económico da cripto. O calcanhar de Aquiles tem vindo a escaldar. O dimensionamento DA ainda está em obras e os ambientes de execução L2 existentes não podem competir com inovações mais recentes como o SVM. Tememos que o ecossistema Ethereum seja pego de pé plano por qualquer aumento acentuado da atividade tal como está hoje. EVMs de encadeamento único e DA constrangido levariam rapidamente a um ressurgimento de taxas elevadas, excepto desta vez em rollups.

Acreditamos que o Eclipse Mainnet é a solução óbvia: unir o desempenho do Solana com a segurança, verificabilidade e efeitos de rede do roteiro centrado no rollup.

Pensamentos de despedida

A beleza do Ethereum é que ele come inovação. O roteiro centrado no rollup é o epítome disso, delegar execução e inovação ao mercado livre. Os L2s têm a incrível capacidade de alavancar os efeitos de rede e as garantias de liquidação do Ethereum enquanto experimentam os melhores novos ambientes de execução. O Eclipse Mainnet é a realização natural desta visão.

Se um dia surgir uma camada de execução mais eficiente, ficaremos incrivelmente entusiasmados em vê-la implementada como um Ethereum L2 competitivo. Até lá, o SVM continua a ser o padrão.

Para se envolver, contacte-nos em < a href= "http://mailto:[email protected]/" " > [email protected] para obter instruções do testnet.

Isenção de responsabilidade：

1. Este artigo foi reimpresso do [Espelho]. Todos os direitos de autor pertencem ao autor original [Eclipse]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.