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

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

A maioria das manchetes do Eclipse gira em torno de nosso trabalho para implantar rollups específicos de aplicativos para uma variedade de projetos, mas agora está mais claro do que nunca que o Ethereum precisa de um L2 de uso geral capaz de escala verdadeiramente massiva. A maioria dos aplicativos não se beneficia de personalizações de cadeia específicas de aplicativos, e o isolamento e a complexidade resultantes podem, na verdade, resultar em uma pior experiência de experiência do usuário e do desenvolvedor.

Freqüentemente, há uma falsa dicotomia entre a visão de rollup modular e a capacidade de ter uma cadeia única com escala massiva, execução paralelizada e estado compartilhado. “Modular” é frequentemente confundido com “específico do aplicativo”, o que levaria você a acreditar que rollups significam um mundo de muitas cadeias fragmentadas e de baixo rendimento. Desafiamos essa ideia.

Execução: Velocidade e Escala de Solana

Eclipse Mainnet adotará o melhor ambiente de execução da Solana. Isto traz enormes vantagens:

Execução Paralela Otimizada

O SVM e seu tempo de execução Sealevel permitem a execução paralela de transações. As transações que não afetam o estado sobreposto podem ser executadas em paralelo, em vez de sequencialmente.

Isso permite que o SVM seja dimensionado diretamente com o hardware à medida que os processadores continuam a adicionar mais núcleos a um custo menor. Os tempos de execução de thread único (como o EVM atual) fundamentalmente não se beneficiam da redução do custo por núcleo. Há mais de uma década, as acelerações de desempenho de thread único têm diminuído 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 iniciais não comprovadas de paralelizar o EVM, mas adicionar isso e manter a compatibilidade traz compensações fundamentais, incluindo desempenho abaixo do ideal, sem abordar outros gargalos (por exemplo, crescimento do estado). Contratos que declaram antecipadamente dependências de estado (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 usuários 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 essa disputa estatal entre aplicativos. Na sua implementação atual, o escalonador prioriza transações sem conflitos, permitindo que transações sem conflitos sejam realizadas com taxas mais baixas. A longo prazo, os mercados de taxas locais serão implementados a nível de protocolo. Isso garante que os aumentos nas taxas de um único aplicativo não afetem o resto da cadeia.

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

Há também pesquisas iniciais em andamento que permitiriam que os aplicativos internalizassem facilmente o valor local que lhes é atribuído, o que hoje geralmente exige 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 há árvore Merkle para estado, Solana não incorre na sobrecarga de atualização de uma árvore Merkle para cada atualização de estado. Em vez disso, após cada época (~2,5 dias), todo o estado é mercantilizado. Isto é muito mais barato do que a comercialização em tempo real (como no EVM).

Mais importante ainda, o EVM tem acesso dinâmico à conta (ou seja, as transações podem atingir qualquer estado sob demanda). Essa pesquisa dinâmica de estado 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 execução.

Como resultado, o tamanho do estado não afeta a execução do SVM. A rede poderia duplicar com segurança o tamanho do snapshot a cada 2 anos sem enfrentar grandes problemas, assumindo que os validadores atualizassem seus discos de armazenamento a cada 2 anos.

Além disso, equipes como Helius estão melhorando ativamente a acessibilidade dos dados históricos e reduzindo o tamanho do estado com compactação.

Compatibilidade EVM

Neon EVM é um EVM que opera como um contrato inteligente que pode ser implantado em qualquer cadeia SVM. Isso traz compatibilidade total de EVM para Eclipse Mainnet (incluindo suporte a bytecode EVM e Ethereum JSON-RPC) com maior rendimento do que EVMs de thread único. Como cada instância Neon EVM tem seu próprio mercado de taxas locais, os aplicativos podem simplesmente implantar seu próprio contrato para obter os benefícios de uma cadeia de aplicativos sem fragmentar UX, segurança ou liquidez.

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

Snaps MetaMask

A integração de usuários de EVM em cadeias não-EVM tem sido historicamente um grande obstáculo, mas os recentemente revelados Metamask Snaps devem quebrar essa barreira. Os usuários de EVM podem continuar a usar o MetaMask sem precisar trocar de carteira. A UX é comparável à interação com qualquer cadeia EVM, graças às contribuições de código aberto do Drift , construindo uma excelente implementação do MetaMask Snap. Os usuários do Eclipse Mainnet poderão interagir com aplicativos nativamente no MetaMask ou usar uma carteira nativa de Solana como Salmon.

Aqui está uma prévia da UX do Drift:

Dançarino de fogo

Firedancer é o cliente Solana altamente esperado que está sendo desenvolvido pela Jump para aumentar drasticamente o rendimento, a resiliência e a eficiência da rede. No lançamento, nos manteremos o mais próximo possível do cliente principal Solana, mas planejamos adotar o Firedancer assim que o código estiver ativo e estável.

Segurança

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

Prova mais fácil

O SVM é baseado em registro e possui um conjunto de instruções muito menor em comparação ao EVM, tornando a execução do SVM mais fácil de provar em ZK. Para rollups otimistas, o design baseado em registro permite pontos de verificação mais fáceis.

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

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

Isso permite que nossos usuários obtenham certas propriedades de segurança do Ethereum. A ponte validará todas as transações do Eclipse, evitando o envio de estados inválidos. Além disso, imporá eventual vivacidade e resistência à censura em certos casos de falha. Mesmo se o sequenciador cair ou começar a censurar no L2, os usuários poderão forçar a inclusão de suas transações através da ponte.

Por causa dessas propriedades de segurança, validiums e optimiums são frequentemente chamados de “Ethereum L2s”. L2BEAT define um L2 como “uma cadeia que deriva total ou parcialmente sua segurança da camada um do Ethereum, para que os usuários não precisem confiar na honestidade dos validadores L2 para a segurança de seus fundos”.

O acordo Ethereum reconhece a importância que os ativos nativos do Ethereum provavelmente desempenharão nas economias DeFi e NFT da Eclipse Mainnet. ETH é o melhor dinheiro descentralizado que a maioria dos usuários prefere, então também usaremos ETH como nosso token de gás. No longo prazo, a abstração de taxas permitirá que os usuários paguem em qualquer token de sua escolha (por exemplo, USDC). Não há planos para o Eclipse Mainnet ter seu próprio token no momento.

Disponibilidade de dados: largura de banda e verificabilidade da Celestia

Eclipse Mainnet utilizará Celestia para disponibilidade de dados (também conhecido como publicação de dados ou publicação de dados). Celestia é parceira de longa data do ecossistema Eclipse.

Infelizmente, a taxa de transferência e as taxas alvo do Eclipse Mainnet não são suportadas pela largura de banda atual do Ethereum. Isso permanecerá assim mesmo após o EIP-4844 (também conhecido como “Proto-danksharding”), que fornece uma média de ~0,375 MB de blobspace por bloco (com um limite de ~0,75 MB por bloco).

1. Para transferências ERC-20 com compactação básica (~154 bytes por transação), isso se traduz em ~213 TPS em todos os rollups combinados.
2. Para swaps com compactaçã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, uma vez que nós leves de amostragem de disponibilidade de dados (DAS) suficientes fiquem online e a rede se mostre estável. Os nós de luz DAS atendem a duas funções críticas:

1. Permitir que os usuários verifiquem por si mesmos se os dados do bloco Eclipse foram disponibilizados
2. Contribua para o dimensionamento seguro de toda a rede, pois as camadas DA podem aumentar com segurança seu rendimento à medida que mais nós leves DAS ficam on-line

Espera-se que Celestia seja a primeira camada DA a ser lançada com DAS em produção. Isto contrasta com os Comitês de Disponibilidade de Dados (DACs) tradicionais, que reintroduzem suposições de honestidade do comitê sem verificação do usuário (semelhante aos blockchains monolíticos existentes).

Há uma suposição de segurança inerente para usuários que transferem seus fundos da Ethereum Mainnet para qualquer cadeia que use DA offchain. Em particular, é tecnicamente possível que os validadores da Celestia retenham dados de transações, 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 pode ser cortada, tornando esse risco irrealista em nossa opinião.

No geral, o suporte ao nó leve DAS da Celestia desde o primeiro dia, as propriedades de segurança criptoeconômicas e a taxa de transferência DA altamente escalável tornam-no a escolha certa para o Eclipse Mainnet hoje.

Observe que alguns veem o Ethereum DA onchain como um requisito para ser um verdadeiro “L2” aqui pelos motivos descritos acima. Seguiremos a terminologia L2 mais comum citada anteriormente e queremos deixar claro as considerações de segurança.

Também pretendemos monitorar o progresso do Ethereum no dimensionamento de DA após EIP-4844. Novas pesquisas interessantes continuam surgindo, potencialmente oferecendo DA de alto rendimento mais cedo do que ideias anteriores (que usam tabelas de hash distribuídas mais avançadas). Se o Ethereum oferecer maior escala para o Eclipse em benefício de nossos usuários, avaliaríamos a possibilidade de migrar para o Ethereum DA.

Provando: Provas de fraude RISC Zero ZK (sem serialização de estado intermediário!)

Nossa prova será semelhante ao SIMD de provas de fraude SVM de Anatoly, que é semelhante ao insight de John Adler de que a serialização de estado é cara e é possível evitá-la.

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

Em alto nível, uma prova de falha requer:

1. Um compromisso com os insumos para uma transação,
2. A transação em si e
3. Prova de que a reexecução da transação leva a uma saída diferente daquela especificada na cadeia.

O compromisso de entrada normalmente é feito fornecendo a raiz Merkle para a árvore de estados do rollup. Em vez disso, 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 no Celestia, para que qualquer nó completo possa acompanhar para extrair contas de entrada de seu próprio estado, calcular as contas de saída e confirmar se 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 usando RISC Zero para criar provas ZK de execução de SVM, continuando nosso trabalho anterior provando a execução de bytecode BPF. Isso permite que nosso contrato de liquidação garanta a correção sem ter que executar as próprias transações na cadeia.
2. Entradas incorretas - Neste caso, o verificador publica na cadeia uma referência aos dados históricos mostrando que o estado de entrada não é o reivindicado. Usando a Ponte de Gravidade Quântica da Celestia, nosso contrato de liquidação garante que esses dados históricos realmente comprovem fraude.

Por que Eclipse, por que Ethereum, por que agora

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

No entanto, eles não aproveitam ao máximo a tecnologia mais recente necessária para atingir as massas. Os primeiros rollups priorizaram amplamente a compatibilidade e/ou otimizações de EVM para uma prova de ZK mais eficiente. Mais recentemente, porém, temos visto um progresso inacreditável que evita a necessidade de fazer as compensações escolhidas pelos rollups iniciais e, na verdade, os coloca em desvantagem:

1. VMs paralelizadas de alto desempenho (por exemplo, SVM)
2. Dimensionamento DA com suporte a 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 de código (por exemplo, Neon e Solang) e usuários (por exemplo, MetaMask Snaps) entre ecossistemas

Eclipse tem o enorme benefício da retrospectiva. Aprendemos com as limitações que outras redes enfrentaram e, em seguida, escolhemos as melhores peças para dimensionar no 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%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGONLeyBAwXgs

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

Muitas vezes ouvimos falar de um futuro com um milhão de rollups específicos de aplicativos.

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

No entanto, esses casos são poucos e distantes entre si. É por isso que a maioria dos novos rollups ainda são apenas garfos EVM básicos. Os problemas dos desenvolvedores não são resolvidos com a fragmentação da UX em mais cadeias. O principal caso de uso para um milhão de cadeias hoje muitas vezes parece ser o lançamento de mais um milhão de tokens. A demanda por personalização full-stack simplesmente não existe hoje para a grande maioria dos casos de uso.

Mesmo que a demanda real existisse, a infraestrutura necessária para suportar muitas cadeias de aplicativos com UX competitiva ainda estaria a anos de distância (se algum dia chegar ao nível). Superchain do Optimism (OP Stack), Hyperchains do zkSync (ZK Stack), cadeias Orbit da Arbitrum e assim por diante, todos têm visões de muitas cadeias com infraestrutura compartilhada. O objetivo é fornecer uma operação UX mais suave entre cadeias no mesmo ecossistema (por exemplo, entre duas cadeias dentro da Superchain) versus cadeias completamente isoladas (por exemplo, entre Ethereum e Solana).

No entanto, os planos actuais (quando existem) ainda estão muito longe de serem competitivos com um único Estado partilhado. Além disso, eles não abordam a interoperabilidade entre ecossistemas (por exemplo, de Superchain para Hyperchain). Construir de forma modular não deveria significar construir ilhas.

É mais complicado para os usuários manter contas em muitas redes. É pior para a experiência do usuário continuar conectando e se preocupando com o token de gás que você precisa. É mais complicado e caro depender de fornecedores de infraestrutura para operar e manter tantas cadeias.

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

Esse equívoco surge devido ao fato de que os rollups atuais estão executando em grande parte o EVM vanilla de thread único efetivamente inalterado, a fim de aproveitar os primeiros efeitos de rede. Como resultado, muitas vezes vemos “blockspace dedicado” citado como o motivo para implantar um rollup específico do aplicativo. Essas balas NFT malucas não deveriam aumentar os preços de todos os outros aplicativos da sua rede, mas a resposta não é criar sua própria rede. É como usar uma marreta para quebrar um amendoim. Você faz compensações dolorosas e desnecessárias (complexidade, custo, pior UX, liquidez fragmentada, etc.). A solução ideal é incrivelmente clara: basta usar uma VM paralelizada com mercados de taxas locais para hotspots estaduais. É exatamente isso que o SVM traz.

Ethereum é o centro intelectual, social e econômico da criptografia. Seu calcanhar de Aquiles vem crescendo. O escalonamento DA ainda está em andamento 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 surpresa por qualquer aumento acentuado na atividade como está hoje. EVMs de thread único e DA restritos levariam rapidamente ao ressurgimento de taxas elevadas, exceto desta vez em rollups.

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

Pensamentos de despedida

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

Se algum dia surgir uma camada de execução com melhor desempenho, ficaremos extremamente entusiasmados em vê-la implantada como um Ethereum L2 competitivo. Até então, o SVM continua sendo o padrão.

Para participar, entrehttp://mailto:[email protected]/em contato conosco pelo e-mail [email protected] para obter instruções sobre testnet.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [Mirror]. Todos os direitos autorais pertencem ao autor original [Eclipse]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.