Eclipse Mainnet é uma Camada 2 universal que combina as melhores partes da arquitetura modular:
Camada de liquidação: Ethereum - Eclipse irá liquidar com Ethereum (ou seja, a ponte de validação estará em Ethereum) e usará ETH como seu token de gás.
Camada de Execução: Solana Virtual Machine (SVM) - O Eclipse executará um SVM de alto desempenho como ambiente de execução.
Disponibilidade de dados: Celestia - O Eclipse publicará seus dados no Celestia para disponibilidade de dados (DA) escalável.
Prova: RISC Zero - O Eclipse usará RISC Zero para provas de fraude de conhecimento zero (sem a necessidade de serialização de estado intermediário!)
A maioria dos destaques do Eclipse gira em torno da implantação de rollups específicos de aplicativos para vários projetos, mas agora, mais do que nunca, está claro que o Ethereum precisa de uma Camada 2 universal que possa atingir a verdadeira escala. A maioria dos aplicativos não se beneficiará da personalização de cadeias específicas de aplicativos, e o isolamento e a complexidade resultantes podem, na verdade, levar a uma pior experiência do usuário e do desenvolvedor.
Freqüentemente, há uma falsa dicotomia entre a visão de rollups modulares e a capacidade de ter uma cadeia única com escalabilidade massiva, execução paralela e estado compartilhado. "Modular" é frequentemente confundido com "específico da aplicação", o que leva a pensar que rollup significa um mundo de muitas cadeias fragmentadas e de baixo rendimento.
Camada de Execução: Velocidade e Escala de Solana
Eclipse Mainnet usará o melhor ambiente de execução semelhante ao Solana. Isto traz enormes vantagens:
Execução paralela otimizada
SVM e seu tempo de execução Sealevel são famosos por seu suporte à execução paralela de transações. As transações que não tocam em estados sobrepostos podem ser executadas em paralelo, em vez de serialmente.
Isso permite que o SVM seja dimensionado diretamente com o hardware à medida que o processador continua a adicionar mais núcleos a um custo menor. Os tempos de execução de thread único (como o EVM atual) inerentemente não se beneficiam do menor custo por núcleo. Ao longo da última década, as melhorias de desempenho de thread único têm diminuído constantemente. Quase todas as melhorias ainda vêm do aumento da contagem de núcleos, por isso é fundamental aproveitar esta tendência para paralelização da carga de trabalho:
Embora tenha havido algumas tentativas iniciais de paralelizar o EVM, adicioná-lo mantendo a compatibilidade acarreta compromissos fundamentais, incluindo um desempenho abaixo do ideal sem resolver outros gargalos (como o crescimento do estado). Contratos que declaram dependências de estado antecipadamente (como no SVM) alcançam a paralelização ideal.
Mercado de taxas nativo
A maioria dos mercados de taxas hoje são globais, o que significa que um aplicativo popular aumentará as taxas para todos os usuários da rede. A cunhagem de um NFT não deve tornar toda a cadeia inútil para todo o resto. O incrível trabalho de Solana em um mercado de taxas nativo resolve esse problema de contenção de estado entre aplicações. Na sua implementação atual, o escalonador prioriza transações sem conflitos, permitindo que transações sem conflitos prossigam com uma taxa mais baixa. No longo prazo, os mercados de taxas nativas serão implementados ao nível do protocolo. Isso garante que os aumentos nas taxas para um único aplicativo não afetem outras partes da cadeia.
O mercado de taxas nativo se beneficia do tempo de execução de paralelização exclusivo do Solana. A tentativa de implementar um mercado de taxas nativo para hotspots estaduais no EVM usando heurística (ou seja, não declarar o acesso estatal antecipadamente) introduziria ineficiências e possíveis vetores de ataque.
Há também algumas pesquisas iniciais em andamento para que os aplicativos possam internalizar facilmente o valor nativo do próprio aplicativo, o que hoje muitas vezes exige mais criatividade no design no nível do aplicativo.
Gerenciamento do Crescimento do Estado
Antes mesmo de o EVM atingir a execução sequencial como um gargalo, o crescimento do estado é o seu gargalo mais premente.
Como os estados não possuem árvores Merkle, Solana não introduz a sobrecarga de atualização da árvore Merkle para cada atualização de estado. Em vez disso, após cada época (2,5 dias), todo o estado é arquivado. Isto é mais barato que o arquivamento ao vivo (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 todos os estados necessários para execução.
Portanto, o tamanho do estado não afeta a execução do SVM. Supondo que os validadores atualizem seus discos de armazenamento a cada dois anos, a rede poderá duplicar com segurança o tamanho do snapshot a cada dois anos sem encontrar grandes problemas.
Além disso, equipes como a Helius estão melhorando ativamente a acessibilidade dos dados históricos e reduzindo o tamanho do estado por meio da compactação.
Compatibilidade EVM
Neon EVM é um contrato inteligente de máquina virtual Ethereum que pode ser implantado em qualquer cadeia SVM. Isso traz compatibilidade total com EVM (incluindo suporte a bytecode EVM e Ethereum JSON-RPC) para Eclipse Mainnet, com maior rendimento do que EVM de thread único. Como cada instância Neon EVM tem seu próprio mercado de taxas nativo, os aplicativos podem simplesmente implantar seus próprios contratos para colher os benefícios da cadeia de aplicativos sem interromper a experiência do usuário, a segurança ou a liquidez.
Além disso, o compilador Solang pode compilar o código do contrato inteligente Solidity em bytecode SVM.
Instantâneos da MetaMask
Orientar os usuários de EVM a usar cadeias não-EVM tem sido historicamente uma barreira significativa, mas os recentemente anunciados MetaMask Snaps quebrarão essa barreira. Os usuários de EVM podem continuar a usar o MetaMask sem trocar de carteira. Graças às contribuições de código aberto do Drift para a construção de uma excelente implementação de MetaMask Snaps, a experiência é semelhante à interação com qualquer cadeia EVM. Os usuários do Eclipse Mainnet poderão interagir com aplicativos nativamente no MetaMask ou usar carteiras nativas Solana, como Salmon.
Firedancer
Firedancer é o cliente Solana altamente esperado que está sendo desenvolvido pela Jump e foi projetado para melhorar significativamente o rendimento, a resiliência e a eficiência da rede. No lançamento, ficaremos o mais próximo possível do cliente Solana principal, mas planejamos adotar o Firedancer assim que o código estiver ativo e estável.
segurança
Solana funciona com uma superfície de ataque significativamente reduzida, evitando os ataques de reentrada que vimos muitas vezes. Especificamente, o tempo de execução do Solana permite apenas a auto-recursão do programa e não permite chamadas reentrantes arbitrárias entre programas. Além disso, a separação entre estado e código resulta em código sem estado, que geralmente é mais fácil de testar com eficácia.
Prova mais simples
O SVM é baseado em registradores e o conjunto de instruções é muito menor que o EVM, o que torna a execução do SVM mais fácil de provar em ZK. Para rollups otimistas, um design baseado em registro permite pontos de verificação mais simples.
Camada de Liquidação: Segurança e Liquidez no Ethereum
Como o grande rollup de hoje, o Eclipse Mainnet será liquidado com Ethereum. Especificamente, isso significa que nossa ponte de verificação no Ethereum será integrada diretamente no Eclipse. O nó Eclipse examinará esta ponte para determinar a "cadeia canônica". Esta 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 e evitará que estados inválidos sejam confirmados. Além disso, imporá vitalidade final e resistência à censura em certos casos de falha. Mesmo que o ordenante L2 pare de funcionar ou inicie a censura, os usuários poderão forçar a inclusão de suas transações através da ponte.
Devido a essas propriedades de segurança, bibliotecas válidas e ideais são frequentemente chamadas de "Ethereum L2". L2BEAT define L2 como “uma cadeia que deriva total ou parcialmente sua segurança da Camada 1 do Ethereum, para que os usuários não precisem confiar na honestidade dos validadores L2 para manter os fundos seguros”.
A liquidação do Ethereum reflete a importância dos ativos nativos do Ethereum nas economias DeFi e NFT da Eclipse Mainnet. ETH é a melhor moeda descentralizada preferida pela maioria dos usuários, portanto, 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). Atualmente, a Eclipse Mainnet não tem planos de emitir seus próprios tokens.
Disponibilidade de dados: largura de banda e verificabilidade do Celestia
Eclipse Mainnet usará Celestia para disponibilidade de dados (também conhecido como publicação de dados ou publicação de dados). Celestia é parceira do ecossistema de longa data do Eclipse.
Infelizmente, a taxa de transferência e as taxas alvo do Eclipse Mainnet não são suportadas pelas atuais limitações de largura de banda do Ethereum. Isso é verdade mesmo após o EIP-4844 (também conhecido como "Proto-danksharding"), que fornece aproximadamente 0,375 MB de blobspace por bloco (com um limite por bloco de aproximadamente 0,75 MB).
Para transferências ERC-20 com compactação básica (~154 bytes por transação), isso equivale a ~213 TPS para todos os Rollups.
Para trocas compactadas (~400 bytes por transação), isso equivale a ~82 TPS, todos agregados.
Em comparação, a Celestia lançará blocos de 2 MB até o final deste ano. Assim que nós leves de Amostragem de Disponibilidade de Dados (DAS) suficientes ficarem online e a rede se mostrar estável, espera-se que o espaço de blob aumente para 8 MB logo após o lançamento. O nó de luz DAS desempenha duas funções principais:
Permitir que os usuários verifiquem por si próprios se os dados do bloco Eclipse estão disponíveis;
Ajuda a dimensionar toda a rede com segurança porque, à medida que mais nós leves DAS ficam on-line, a camada DA pode aumentar com segurança seu rendimento.
Espera-se que Celestia seja a primeira camada DA a habilitar DAS em produção. Isto contrasta com os Comitês de Disponibilidade de Dados (DACs) tradicionais, que reintroduzem a suposição de honestidade do comitê sem verificação do usuário (semelhante aos blockchains monolíticos existentes).
Existem suposições de segurança inerentes para usuários que conectam fundos da rede principal Ethereum a qualquer cadeia usando DA fora da cadeia. Em particular, os validadores da Celestia podem tecnicamente rejeitar dados de transação, mas alegar que os dados estão disponíveis na ponte Ethereum. Na verdade, o consenso de prova de participação da Celestia significa que a retenção de dados pela própria Celestia é punível, fazendo-nos acreditar que este risco não é realista.
No geral, o suporte ao nó leve DAS da Celestia, as propriedades de segurança criptoeconômicas e a taxa de transferência DA altamente escalável desde o primeiro dia fazem dela a escolha certa para o Eclipse Mainnet hoje.
Também pretendemos monitorar o progresso do Ethereum no dimensionamento de DA após EIP-4844. Estão surgindo novas pesquisas interessantes que podem fornecer DA de alto rendimento mais cedo do que se pensava anteriormente (a última usando tabelas de hash distribuídas mais avançadas). Caso o Ethereum proporcione maior escala para nossos usuários, avaliaremos a possibilidade de migração para o Ethereum DA.
Prova: prova de fraude RISC Zero ZK (não é necessária serialização de estado intermediário!)
Nossa prova será semelhante ao SIMD à prova de fraude SVM de Anatoly, que por si só é semelhante à percepção de John Adler de que a serialização de estado é cara e pode ser evitada.
Especificamente, queremos evitar a reintrodução de árvores Merkle no SVM. Tentamos inserir uma árvore Merkle esparsa após cada transação no SVM, mas a atualização da árvore Merkle resultou em perda significativa de desempenho. Não usar árvores Merkle exclui estruturas de rollup de uso geral existentes (como pilha OP) como base para rollup SVM e também requer arquiteturas mais criativas à prova de falhas.
Em suma, a prova de falhas requer:
Compromisso com a entrada da transação,
a transação em si, e
Prove que a reexecução da transação resulta em uma saída diferente daquela especificada na cadeia.
Os compromissos de entrada normalmente são realizados fornecendo uma raiz Merkle da árvore de estados de rollup. Nosso executor publicará uma lista de entradas e saídas (incluindo hashes de conta e estado global associado) para cada transação, bem como um índice da transação que produziu cada entrada. As transações são publicadas no Celestia, portanto, qualquer nó completo pode extrair automaticamente a conta em seu próprio estado, calcular a conta de saída e confirmar se o compromisso no Ethereum está correto.
Existem dois tipos principais de falhas possíveis:
Saída de erro – Neste caso, o verificador fornece prova de conhecimento zero na cadeia da saída correta da execução do SVM. Usamos RISC Zero para criar uma prova de conhecimento zero de execução de SVM, que é uma continuação de nossa prova anterior de execução de bytecode BPF. Isso permite que nosso contrato de liquidação garanta a correção sem a necessidade de executar essas transações na rede.
Bad Input – Neste caso, o validador publica uma referência aos dados históricos na cadeia, mostrando que o estado de entrada não corresponde ao que foi reivindicado. Usando a Ponte de Gravidade Quântica da Celestia, nosso contrato de liquidação garante que esses dados históricos realmente comprovem fraude.
Estamos sobre ombros de gigantes. O rollup de hoje avançou o estado da pesquisa em nossa indústria e oferece aos usuários do Ethereum taxas mais baixas do que L1.
Contudo, não aproveitam ao máximo as tecnologias mais recentes que exigem grande escala. Avanços recentes incríveis eliminaram a necessidade de fazer essas concessões que os rollups anteriores faziam, colocando-os efetivamente em desvantagem:
VM paralela de alto desempenho (como SVM);
Extensão DA com suporte a nó de luz DAS (como Celestia);
Avanços na infraestrutura de prova que a tornam prática em qualquer lugar (por exemplo, RISC Zero);
Melhor portabilidade entre ecossistemas de código (por exemplo, Neon e Solang) e usuários (por exemplo, MetaMask Snaps)
Podemos aprender com as limitações enfrentadas por outras cadeias e escolher as melhores peças para expansão a longo prazo.
Freqüentemente ouvimos falar de um milhão de rollups específicos de aplicativos no futuro.
A personalização em nível de consenso pode ser muito valiosa para determinados aplicativos (como dYdX v4), e estamos felizes em ajudar a equipe a lançar rollups específicos de aplicativos.
No entanto, essas situações são raras. É por isso que a maioria dos novos rollups ainda são apenas garfos EVM simples. Os problemas dos desenvolvedores não serão resolvidos fragmentando a experiência do usuário em mais cadeias. O principal caso de uso encontrado para milhões de redes hoje muitas vezes parece ser apenas o lançamento de mais moedas. Para a grande maioria dos casos de uso, a necessidade de personalização completa da pilha de tecnologia não existe hoje.
Mesmo que exista uma procura real, a infraestrutura necessária para suportar muitas cadeias de aplicações com UX competitiva demorará anos (se existir). Superchain do Optimism (pilha OP), Hyperchains do zkSync (pilha ZK), cadeia Orbit da Arbitrum, etc., todos têm a visão de muitas cadeias com infraestrutura compartilhada. O objetivo é fornecer uma UX mais suave para operações entre cadeias dentro do mesmo ecossistema (por exemplo, entre duas cadeias dentro de uma Superchain), em vez de cadeias completamente isoladas (por exemplo, entre Ethereum e Solana).
Contudo, os planos actuais (se existirem) estão longe de prometer competir com um único Estado partilhado. Além disso, eles não abordam questões de interoperabilidade entre ecossistemas (por exemplo, Superchain para Hyperchain). Construir modularidade não deve significar construir silos.
É mais complicado para os usuários manter contas em muitas redes. Cruzar correntes constantemente e se preocupar com os tokens de gás necessários é uma experiência pior para o usuário. Depender de fornecedores de infraestrutura para operar e manter tantas cadeias também é mais complexo e caro.
Sempre admiramos a simplicidade da visão de Solana. Uma máquina de estado compartilhada altamente otimizada com escala para suportar os casos de uso mais valiosos. Isso geralmente é visto como incompatível com roteiros centrados em rollup, mas na verdade não é o caso. Queríamos combinar o melhor dos dois mundos.
Esse mal-entendido se deve ao fato de que os rollups atuais executam em grande parte o EVM original de thread único, que permaneceu praticamente inalterado para aproveitar os primeiros efeitos de rede. Portanto, frequentemente vemos o "espaço de bloco privado" citado como o motivo para a implantação de rollups específicos de aplicativos. Outros aplicativos em sua rede não deveriam ter seus preços aumentados por causa de alguma cunhagem maluca de NFT, mas a resposta não é construir sua própria rede. Você faz compensações dolorosas e desnecessárias (complexidade, custo, pior experiência do usuário, liquidez fragmentada, etc.). A melhor solução é clara: basta usar uma VM paralela com um mercado de taxas nativo para hotspots estaduais. É exatamente isso que o SVM traz.
Ethereum é o centro intelectual, social e econômico da criptografia. Seu calcanhar de Aquiles sempre foi a expansão. A expansão da disponibilidade de dados ainda é um trabalho em andamento e os ambientes de execução L2 existentes não podem competir com inovações mais recentes, como os SVMs. Estamos preocupados que, se o status quo atual continuar, o ecossistema Ethereum será pego de surpresa no caso de qualquer aumento dramático na atividade. EVMs de thread único e disponibilidade restrita de dados podem levar rapidamente ao ressurgimento de custos elevados, só que desta vez em rollups.
Acreditamos que o Eclipse Mainnet é a solução óbvia: combinar o desempenho do Solana com a segurança, verificabilidade e efeitos de rede de um roteiro centrado em rollup.
Conclusão
A beleza do Ethereum é que ele está constantemente inovando. Os roteiros centrados em rollup exemplificam isso, delegando execução e inovação ao mercado livre. L2 tem a incrível capacidade de aproveitar os efeitos de rede e as garantias de liquidação do Ethereum enquanto experimenta os melhores novos ambientes de execução. Eclipse Mainnet é uma implementação natural desta visão.
Se algum dia surgisse uma camada de execução de maior desempenho, ficaríamos muito entusiasmados em vê-la implementada como um Ethereum L2 competitivo. Até então, o SVM continua sendo o padrão.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Eclipse Mainnet: Uma Camada 2 modular com segurança Ethereum e velocidade Solana que aproveita os pontos fortes de outros
Escrito por: Eclipse
Compilado por: Deep Wave TechFlow
Eclipse Mainnet é uma Camada 2 universal que combina as melhores partes da arquitetura modular:
A maioria dos destaques do Eclipse gira em torno da implantação de rollups específicos de aplicativos para vários projetos, mas agora, mais do que nunca, está claro que o Ethereum precisa de uma Camada 2 universal que possa atingir a verdadeira escala. A maioria dos aplicativos não se beneficiará da personalização de cadeias específicas de aplicativos, e o isolamento e a complexidade resultantes podem, na verdade, levar a uma pior experiência do usuário e do desenvolvedor.
Freqüentemente, há uma falsa dicotomia entre a visão de rollups modulares e a capacidade de ter uma cadeia única com escalabilidade massiva, execução paralela e estado compartilhado. "Modular" é frequentemente confundido com "específico da aplicação", o que leva a pensar que rollup significa um mundo de muitas cadeias fragmentadas e de baixo rendimento.
Camada de Execução: Velocidade e Escala de Solana
Eclipse Mainnet usará o melhor ambiente de execução semelhante ao Solana. Isto traz enormes vantagens:
Execução paralela otimizada
SVM e seu tempo de execução Sealevel são famosos por seu suporte à execução paralela de transações. As transações que não tocam em estados sobrepostos podem ser executadas em paralelo, em vez de serialmente.
Isso permite que o SVM seja dimensionado diretamente com o hardware à medida que o processador continua a adicionar mais núcleos a um custo menor. Os tempos de execução de thread único (como o EVM atual) inerentemente não se beneficiam do menor custo por núcleo. Ao longo da última década, as melhorias de desempenho de thread único têm diminuído constantemente. Quase todas as melhorias ainda vêm do aumento da contagem de núcleos, por isso é fundamental aproveitar esta tendência para paralelização da carga de trabalho:
Embora tenha havido algumas tentativas iniciais de paralelizar o EVM, adicioná-lo mantendo a compatibilidade acarreta compromissos fundamentais, incluindo um desempenho abaixo do ideal sem resolver outros gargalos (como o crescimento do estado). Contratos que declaram dependências de estado antecipadamente (como no SVM) alcançam a paralelização ideal.
Mercado de taxas nativo
A maioria dos mercados de taxas hoje são globais, o que significa que um aplicativo popular aumentará as taxas para todos os usuários da rede. A cunhagem de um NFT não deve tornar toda a cadeia inútil para todo o resto. O incrível trabalho de Solana em um mercado de taxas nativo resolve esse problema de contenção de estado entre aplicações. Na sua implementação atual, o escalonador prioriza transações sem conflitos, permitindo que transações sem conflitos prossigam com uma taxa mais baixa. No longo prazo, os mercados de taxas nativas serão implementados ao nível do protocolo. Isso garante que os aumentos nas taxas para um único aplicativo não afetem outras partes da cadeia.
O mercado de taxas nativo se beneficia do tempo de execução de paralelização exclusivo do Solana. A tentativa de implementar um mercado de taxas nativo para hotspots estaduais no EVM usando heurística (ou seja, não declarar o acesso estatal antecipadamente) introduziria ineficiências e possíveis vetores de ataque.
Há também algumas pesquisas iniciais em andamento para que os aplicativos possam internalizar facilmente o valor nativo do próprio aplicativo, o que hoje muitas vezes exige mais criatividade no design no nível do aplicativo.
Gerenciamento do Crescimento do Estado
Antes mesmo de o EVM atingir a execução sequencial como um gargalo, o crescimento do estado é o seu gargalo mais premente.
Como os estados não possuem árvores Merkle, Solana não introduz a sobrecarga de atualização da árvore Merkle para cada atualização de estado. Em vez disso, após cada época (2,5 dias), todo o estado é arquivado. Isto é mais barato que o arquivamento ao vivo (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 todos os estados necessários para execução.
Portanto, o tamanho do estado não afeta a execução do SVM. Supondo que os validadores atualizem seus discos de armazenamento a cada dois anos, a rede poderá duplicar com segurança o tamanho do snapshot a cada dois anos sem encontrar grandes problemas.
Além disso, equipes como a Helius estão melhorando ativamente a acessibilidade dos dados históricos e reduzindo o tamanho do estado por meio da compactação.
Compatibilidade EVM
Neon EVM é um contrato inteligente de máquina virtual Ethereum que pode ser implantado em qualquer cadeia SVM. Isso traz compatibilidade total com EVM (incluindo suporte a bytecode EVM e Ethereum JSON-RPC) para Eclipse Mainnet, com maior rendimento do que EVM de thread único. Como cada instância Neon EVM tem seu próprio mercado de taxas nativo, os aplicativos podem simplesmente implantar seus próprios contratos para colher os benefícios da cadeia de aplicativos sem interromper a experiência do usuário, a segurança ou a liquidez.
Além disso, o compilador Solang pode compilar o código do contrato inteligente Solidity em bytecode SVM.
Instantâneos da MetaMask
Orientar os usuários de EVM a usar cadeias não-EVM tem sido historicamente uma barreira significativa, mas os recentemente anunciados MetaMask Snaps quebrarão essa barreira. Os usuários de EVM podem continuar a usar o MetaMask sem trocar de carteira. Graças às contribuições de código aberto do Drift para a construção de uma excelente implementação de MetaMask Snaps, a experiência é semelhante à interação com qualquer cadeia EVM. Os usuários do Eclipse Mainnet poderão interagir com aplicativos nativamente no MetaMask ou usar carteiras nativas Solana, como Salmon.
Firedancer
Firedancer é o cliente Solana altamente esperado que está sendo desenvolvido pela Jump e foi projetado para melhorar significativamente o rendimento, a resiliência e a eficiência da rede. No lançamento, ficaremos o mais próximo possível do cliente Solana principal, mas planejamos adotar o Firedancer assim que o código estiver ativo e estável.
segurança
Solana funciona com uma superfície de ataque significativamente reduzida, evitando os ataques de reentrada que vimos muitas vezes. Especificamente, o tempo de execução do Solana permite apenas a auto-recursão do programa e não permite chamadas reentrantes arbitrárias entre programas. Além disso, a separação entre estado e código resulta em código sem estado, que geralmente é mais fácil de testar com eficácia.
Prova mais simples
O SVM é baseado em registradores e o conjunto de instruções é muito menor que o EVM, o que torna a execução do SVM mais fácil de provar em ZK. Para rollups otimistas, um design baseado em registro permite pontos de verificação mais simples.
Camada de Liquidação: Segurança e Liquidez no Ethereum
Como o grande rollup de hoje, o Eclipse Mainnet será liquidado com Ethereum. Especificamente, isso significa que nossa ponte de verificação no Ethereum será integrada diretamente no Eclipse. O nó Eclipse examinará esta ponte para determinar a "cadeia canônica". Esta 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 e evitará que estados inválidos sejam confirmados. Além disso, imporá vitalidade final e resistência à censura em certos casos de falha. Mesmo que o ordenante L2 pare de funcionar ou inicie a censura, os usuários poderão forçar a inclusão de suas transações através da ponte.
Devido a essas propriedades de segurança, bibliotecas válidas e ideais são frequentemente chamadas de "Ethereum L2". L2BEAT define L2 como “uma cadeia que deriva total ou parcialmente sua segurança da Camada 1 do Ethereum, para que os usuários não precisem confiar na honestidade dos validadores L2 para manter os fundos seguros”.
A liquidação do Ethereum reflete a importância dos ativos nativos do Ethereum nas economias DeFi e NFT da Eclipse Mainnet. ETH é a melhor moeda descentralizada preferida pela maioria dos usuários, portanto, 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). Atualmente, a Eclipse Mainnet não tem planos de emitir seus próprios tokens.
Disponibilidade de dados: largura de banda e verificabilidade do Celestia
Eclipse Mainnet usará Celestia para disponibilidade de dados (também conhecido como publicação de dados ou publicação de dados). Celestia é parceira do ecossistema de longa data do Eclipse.
Infelizmente, a taxa de transferência e as taxas alvo do Eclipse Mainnet não são suportadas pelas atuais limitações de largura de banda do Ethereum. Isso é verdade mesmo após o EIP-4844 (também conhecido como "Proto-danksharding"), que fornece aproximadamente 0,375 MB de blobspace por bloco (com um limite por bloco de aproximadamente 0,75 MB).
Em comparação, a Celestia lançará blocos de 2 MB até o final deste ano. Assim que nós leves de Amostragem de Disponibilidade de Dados (DAS) suficientes ficarem online e a rede se mostrar estável, espera-se que o espaço de blob aumente para 8 MB logo após o lançamento. O nó de luz DAS desempenha duas funções principais:
Espera-se que Celestia seja a primeira camada DA a habilitar DAS em produção. Isto contrasta com os Comitês de Disponibilidade de Dados (DACs) tradicionais, que reintroduzem a suposição de honestidade do comitê sem verificação do usuário (semelhante aos blockchains monolíticos existentes).
Existem suposições de segurança inerentes para usuários que conectam fundos da rede principal Ethereum a qualquer cadeia usando DA fora da cadeia. Em particular, os validadores da Celestia podem tecnicamente rejeitar dados de transação, mas alegar que os dados estão disponíveis na ponte Ethereum. Na verdade, o consenso de prova de participação da Celestia significa que a retenção de dados pela própria Celestia é punível, fazendo-nos acreditar que este risco não é realista.
No geral, o suporte ao nó leve DAS da Celestia, as propriedades de segurança criptoeconômicas e a taxa de transferência DA altamente escalável desde o primeiro dia fazem dela a escolha certa para o Eclipse Mainnet hoje.
Também pretendemos monitorar o progresso do Ethereum no dimensionamento de DA após EIP-4844. Estão surgindo novas pesquisas interessantes que podem fornecer DA de alto rendimento mais cedo do que se pensava anteriormente (a última usando tabelas de hash distribuídas mais avançadas). Caso o Ethereum proporcione maior escala para nossos usuários, avaliaremos a possibilidade de migração para o Ethereum DA.
Prova: prova de fraude RISC Zero ZK (não é necessária serialização de estado intermediário!)
Nossa prova será semelhante ao SIMD à prova de fraude SVM de Anatoly, que por si só é semelhante à percepção de John Adler de que a serialização de estado é cara e pode ser evitada.
Especificamente, queremos evitar a reintrodução de árvores Merkle no SVM. Tentamos inserir uma árvore Merkle esparsa após cada transação no SVM, mas a atualização da árvore Merkle resultou em perda significativa de desempenho. Não usar árvores Merkle exclui estruturas de rollup de uso geral existentes (como pilha OP) como base para rollup SVM e também requer arquiteturas mais criativas à prova de falhas.
Em suma, a prova de falhas requer:
Os compromissos de entrada normalmente são realizados fornecendo uma raiz Merkle da árvore de estados de rollup. Nosso executor publicará uma lista de entradas e saídas (incluindo hashes de conta e estado global associado) para cada transação, bem como um índice da transação que produziu cada entrada. As transações são publicadas no Celestia, portanto, qualquer nó completo pode extrair automaticamente a conta em seu próprio estado, calcular a conta de saída e confirmar se o compromisso no Ethereum está correto.
Existem dois tipos principais de falhas possíveis:
Estamos sobre ombros de gigantes. O rollup de hoje avançou o estado da pesquisa em nossa indústria e oferece aos usuários do Ethereum taxas mais baixas do que L1.
Contudo, não aproveitam ao máximo as tecnologias mais recentes que exigem grande escala. Avanços recentes incríveis eliminaram a necessidade de fazer essas concessões que os rollups anteriores faziam, colocando-os efetivamente em desvantagem:
Podemos aprender com as limitações enfrentadas por outras cadeias e escolher as melhores peças para expansão a longo prazo.
Freqüentemente ouvimos falar de um milhão de rollups específicos de aplicativos no futuro.
A personalização em nível de consenso pode ser muito valiosa para determinados aplicativos (como dYdX v4), e estamos felizes em ajudar a equipe a lançar rollups específicos de aplicativos.
No entanto, essas situações são raras. É por isso que a maioria dos novos rollups ainda são apenas garfos EVM simples. Os problemas dos desenvolvedores não serão resolvidos fragmentando a experiência do usuário em mais cadeias. O principal caso de uso encontrado para milhões de redes hoje muitas vezes parece ser apenas o lançamento de mais moedas. Para a grande maioria dos casos de uso, a necessidade de personalização completa da pilha de tecnologia não existe hoje.
Mesmo que exista uma procura real, a infraestrutura necessária para suportar muitas cadeias de aplicações com UX competitiva demorará anos (se existir). Superchain do Optimism (pilha OP), Hyperchains do zkSync (pilha ZK), cadeia Orbit da Arbitrum, etc., todos têm a visão de muitas cadeias com infraestrutura compartilhada. O objetivo é fornecer uma UX mais suave para operações entre cadeias dentro do mesmo ecossistema (por exemplo, entre duas cadeias dentro de uma Superchain), em vez de cadeias completamente isoladas (por exemplo, entre Ethereum e Solana).
Contudo, os planos actuais (se existirem) estão longe de prometer competir com um único Estado partilhado. Além disso, eles não abordam questões de interoperabilidade entre ecossistemas (por exemplo, Superchain para Hyperchain). Construir modularidade não deve significar construir silos.
É mais complicado para os usuários manter contas em muitas redes. Cruzar correntes constantemente e se preocupar com os tokens de gás necessários é uma experiência pior para o usuário. Depender de fornecedores de infraestrutura para operar e manter tantas cadeias também é mais complexo e caro.
Sempre admiramos a simplicidade da visão de Solana. Uma máquina de estado compartilhada altamente otimizada com escala para suportar os casos de uso mais valiosos. Isso geralmente é visto como incompatível com roteiros centrados em rollup, mas na verdade não é o caso. Queríamos combinar o melhor dos dois mundos.
Esse mal-entendido se deve ao fato de que os rollups atuais executam em grande parte o EVM original de thread único, que permaneceu praticamente inalterado para aproveitar os primeiros efeitos de rede. Portanto, frequentemente vemos o "espaço de bloco privado" citado como o motivo para a implantação de rollups específicos de aplicativos. Outros aplicativos em sua rede não deveriam ter seus preços aumentados por causa de alguma cunhagem maluca de NFT, mas a resposta não é construir sua própria rede. Você faz compensações dolorosas e desnecessárias (complexidade, custo, pior experiência do usuário, liquidez fragmentada, etc.). A melhor solução é clara: basta usar uma VM paralela com um mercado de taxas nativo para hotspots estaduais. É exatamente isso que o SVM traz.
Ethereum é o centro intelectual, social e econômico da criptografia. Seu calcanhar de Aquiles sempre foi a expansão. A expansão da disponibilidade de dados ainda é um trabalho em andamento e os ambientes de execução L2 existentes não podem competir com inovações mais recentes, como os SVMs. Estamos preocupados que, se o status quo atual continuar, o ecossistema Ethereum será pego de surpresa no caso de qualquer aumento dramático na atividade. EVMs de thread único e disponibilidade restrita de dados podem levar rapidamente ao ressurgimento de custos elevados, só que desta vez em rollups.
Acreditamos que o Eclipse Mainnet é a solução óbvia: combinar o desempenho do Solana com a segurança, verificabilidade e efeitos de rede de um roteiro centrado em rollup.
Conclusão
A beleza do Ethereum é que ele está constantemente inovando. Os roteiros centrados em rollup exemplificam isso, delegando execução e inovação ao mercado livre. L2 tem a incrível capacidade de aproveitar os efeitos de rede e as garantias de liquidação do Ethereum enquanto experimenta os melhores novos ambientes de execução. Eclipse Mainnet é uma implementação natural desta visão.
Se algum dia surgisse uma camada de execução de maior desempenho, ficaríamos muito entusiasmados em vê-la implementada como um Ethereum L2 competitivo. Até então, o SVM continua sendo o padrão.