Responsável: YBB Capital Researcher Ac - Core
Plano de fundo do eclipse
Fonte da imagem: site oficial do Eclipse
O fundador da Eclipse, Neel Somani, já trabalhou como engenheiro de software no Airbnb e pesquisador quantitativo na Citadel. Ele fundou a Eclipse, uma startup baseada em Solana, em 2022, e recebeu apoio do cofundador da Solana, Anatoly Yakovenko, e da Polygon (para Solana e Polygon). Construa um blockchain Rollup compatível). De acordo com um relatório da CoinDesk de 28 de setembro de 2022, a Eclipse concluiu com sucesso uma rodada de financiamento pré-semente de US$ 6 milhões liderada pela Polychain e uma rodada de financiamento inicial de US$ 9 milhões co-liderada pela Tribe Capital e Tabiya, com um valor total de financiamento de 1.500 dez mil dólares americanos. Além disso, o Eclipse recebeu uma concessão de desenvolvimento da Solana Foundation para apoiar o Rollup desenvolvido pela Solana Virtual Machine.
Somani, o fundador da Eclipse, usou suas conexões e vantagem geográfica perto da sede da Solana em Chicago para criar com sucesso uma cadeia exclusiva usando as máquinas virtuais da Solana. A visão é permitir que os desenvolvedores implantem Rollup alimentado pela máquina virtual Solana, com planos de lançar uma testnet pública no ecossistema Cosmos no início de 2023, bem como planos para oferecer suporte à linguagem Move da Aptos no futuro.
Anatoly Yakovenko, cofundador da Solana e investidor anjo da Eclipse, comentou: "O Eclipse abre caminho para que Solana se comunique com o Cosmos por meio da comunicação inter-blockchain (IBC)."
Niraj Pant, sócio da Polychain Capital, comentou: “À medida que grandes empresas e governos começam a entrar no espaço blockchain, o Eclipse é uma infraestrutura importante para facilitar seus casos de uso, como aplicações financeiras e de consumo em escala Web2”.
Arquitetura Eclipse
O conteúdo a seguir é baseado na explicação oficial. Eclipse Mainnet é o primeiro L2 de uso geral do Ethereum construído em torno do SVM. Ele combina as melhores partes da pilha modular e tem como objetivo se tornar a Camada 2 do Ethereum mais rápida e versátil conduzida pelo SVM. A arquitetura do projeto usa Ethereum como camada de liquidação e é usada para a ponte de verificação incorporada oficial Celestia como a camada de disponibilidade de dados é usada para gerar provas de fraude de conhecimento zero e, finalmente, o SVM de Solana é implementado como um projeto modular de Camada 2; um todo. O seguinte será explicado em detalhes com base nas explicações oficiais.
Camada de liquidação - Ethereum: Eclipse irá liquidar para Ethereum (ou seja, a ponte de verificação incorporada em Ethereum) e usar ETH como seu consumo de gás, e a prova de fraude também será submetida em Ethereum;
Camada de execução - Solana Virtual Machine (SVM): O Eclipse executará um SVM de alto desempenho como ambiente de execução, um fork do cliente Solana Labs (v1.17);
Camada de disponibilidade de dados - Celestia: Eclipse publicará dados no Celestia para obter disponibilidade de dados escalável (DA);
Mecanismo de prova - RISC Zero: O Eclipse usará RISC Zero para prova de fraude ZK (não é necessária serialização de estado intermediário);
Protocolo de comunicação - IBC: Ponte completa com cadeias não-Eclipse através do padrão de comunicação entre cadeias IBC do Cosmos;
Protocolo cross-chain – Hyperlane: Eclipse e Hyperlane estão fazendo parceria para trazer a solução de interoperabilidade sem permissão do Hyperlane para blockchains baseados em Solana Virtual Machine (SVM).
Fonte da imagem: oficial do Eclipse
Camada de liquidação: acesse a segurança e a liquidez da Ethereum
Eclipse usa Ethereum como camada de liquidação como outros Rollups Ethereum. Este processo requer que a ponte de verificação do Eclipse no Ethereum seja incorporada diretamente ao Eclipse. Seus nós precisam detectar a exatidão da ponte de verificação e corrigir a ordem das transações, de modo a permitir que os usuários obtenham. Segurança em nível Ethereum.
L2 BEAT define Layer2 como “uma cadeia que deriva sua segurança, no todo ou em parte, da primeira camada do Ethereum para que os usuários não precisem confiar na integridade dos validadores da Layer2 para manter seus fundos seguros”. A ponte de validação Eclipse impõe validade final e resistência à censura sob certas condições de falha, permitindo aos usuários forçar a conclusão de suas transações através da ponte e usar Ethereum como gás de transação, mesmo se o sequenciador falhar ou a censura começar na queima de execução L2.
Camada de Execução: Capturando a Velocidade e Escala de Transação de Solana
Para melhorar a eficiência, o Eclipse Mainnet adota o ambiente de execução de Solana, usando SVM e Sealevel (Solana é usado para construir soluções técnicas de expansão horizontal, e o mecanismo de processamento de transações hiperparalelo é usado para expansão horizontal entre GPUs e SSDs), que é diferente do EVM single-thread Comparado com a execução, sua vantagem é que pode ser executado sem projetar transações de estado sobrepostas, em vez de executar sequencialmente.
Em relação a questões de compatibilidade de EVM, Eclipse Mainnet fez parceria com Neon EVM para permitir que os desenvolvedores aproveitem as ferramentas Ethereum e construam aplicativos Web3 em Solana. De acordo com dados oficiais, seu rendimento é maior que o EVM de thread único, atingindo níveis de 140TPS. Os usuários EVM interagem com aplicativos nativamente no Eclipse Mainnet por meio do plug-in “Snaps” da carteira MetaMask.
Disponibilidade de dados: aproveitando a largura de banda e a natureza verificável da Celestia
A Ecilpse Mainnet aproveitará o Celestia para disponibilidade de dados e um relacionamento de longo prazo. A razão é que a Ethereum atualmente não consegue cumprir a meta de taxa de transferência e taxas da Ecilpse, que mesmo após a atualização do EIP -4844 pode fornecer uma média de aproximadamente 0,375 MB por bloco. Espaço de blobs (limite de aproximadamente 0,75 MB por bloco).
De acordo com dados oficiais, a transação ERC-20 baseada na expansão Rollup é calculada como 154 bytes por transação, o que equivale ao total de todos os Rollups como aproximadamente 213 TPS para Compression Swap, calculado como aproximadamente 400 bytes por transação, todos Rollups. TPS é aproximadamente 82 TPS. Em comparação com os blocos de 2 MB lançados pela Celestia, espera-se que o Blobstream aumente para 8 MB depois que a rede se provar estável e mais nós de luz DAS (escalonamento relevante explicado abaixo) forem ligados e desligados.
A Ecilpse acredita que, com o suporte do nó leve DA S da Celestia, a Celestia se tornou a melhor escolha para a atual Eclipse Mainnet devido ao compromisso entre a segurança da economia de criptografia e a taxa de transferência DA altamente escalável. Embora atualmente haja uma visão de que o uso do Ethereum DA é a Camada 2 ortodoxa, a equipe do projeto continuará a prestar atenção ao progresso da expansão do DA após o EIP-4844 se o Ethereum puder fornecer ao Eclipse um rendimento em maior escala e alto. DA, irá reavaliar a possibilidade de migração para Ethereum DA.
Mecanismo de prova: prova de fraude RISC Zero (sem serialização de estado intermediário)
O método de prova do Eclipse é semelhante ao SIMD à prova de fraude SVM de Anatoly (consulte o link de extensão 2 do GitHub para obter detalhes), o que é consistente com o insight de John Adler para evitar o alto custo da serialização de estado. Portanto, para evitar a reintrodução da árvore Merkle (árvore hash) no SVM, as primeiras partes do projeto tentaram inserir a árvore Merkle esparsa no SVM, mas cada atualização de transação da árvore Merkle teria um enorme impacto no desempenho. As estruturas de rollup de uso geral existentes (como pilha OP) não podem servir como base para o rollup de SVM sem usar árvores Merkle para prova, o que requer arquiteturas mais criativas à prova de falhas.
Requisitos à prova de falhas: os compromissos de entrada da transação, a transação em si e a prova de que a reexecução da transação resulta em uma saída diferente da especificada na cadeia.
Os compromissos de entrada são geralmente implementados fornecendo a raiz Merkle da árvore de estado Rollup. O executor Eclipsse publicará a lista de entradas e saídas (incluindo valores de hash da conta e estado global relacionado) de cada transação, bem como o índice da transação. gerou cada entrada e publicou a transação no Celestia para que qualquer nó completo pudesse segui-la, extrair a conta de entrada de seu próprio estado, calcular a conta de saída e confirmar se o compromisso no Ethereum está correto.
Existem também dois tipos de erros críticos possíveis aqui:
Saída incorreta: O validador fornece prova ZK na cadeia de saída correta. O Eclipse usa RISC Zero para criar provas ZK de execução de SVM, que continua o trabalho anterior do projeto de provar a execução de bytecode BPF (consulte o link de extensão 3 do GitHub para obter detalhes). Isso permite que nosso contrato de liquidação garanta a correção sem a necessidade de realizar transações na rede.
Entrada incorreta: O validador publica dados históricos na cadeia indicando que o estado de entrada não corresponde ao que é reivindicado. A Ponte de Gravidade Quântica da Celestia é usada para permitir que o contrato de liquidação do Eclipse verifique se há fraude nos dados históricos.
Conexões do Eclipse com ETH e Celestia
Fonte da imagem:@jon_charb
DA é uma das principais partes das despesas de rollup. Atualmente, existem dois métodos principais para disponibilidade de dados no Ethereum L2, Calldata e DAC (Comitês de Disponibilidade de Dados).
Calldata: soluções de camada 2, como Arbitrum ou Optimism, publicam dados de transações diretamente na cadeia como calldata nos blocos altamente resistentes à censura do Ethereum. Ethereum unifica os preços de chamadas de dados, computação e armazenamento em uma unidade: Gás, que também é um dos principais custos das despesas do Rollup no Ethereum. Para melhorar a eficiência, a atualização EIP-4844 introduziu o Blobspace para substituir calldata, fornecendo assim um valor alvo de 375 KB por bloco para todos os Rollups;
DAC: O DAC tem um rendimento muito maior do que a emissão de dados de chamada diretamente na cadeia, mas os usuários precisam confiar em um pequeno comitê ou grupo de validadores para evitar a retenção maliciosa de dados. Os DACs, que também incluem soluções baseadas em reestabelecimento, introduzem suposições de confiança significativas nos L2s, forçando os DACs a confiar na reputação, nos mecanismos de governança ou na votação simbólica para inibir ou punir o comportamento de retenção de dados, até certo ponto. , um DAC é necessário.
Como observação lateral, Celestia usa a rede de consenso de prova de aposta Blobstream no Eclipse para permitir acesso Layer2 ao blobspace do Celestia, atingindo 8 MB de blobspace com base no esquema de compactação. Isso equivale aproximadamente a 9.000 a 30.000 transferências ERC-20 por segundo. No entanto, o uso da Camada 2 do Blobstream no processo dependerá da certificação do verificador Celestia. Se o nó leve do processo de garantia de segurança detectar o comportamento malicioso de 2/3 dos verificadores Celestia ao reter dados, eles podem ser punidos. O DAC é diferente da cadeia nativa. Ainda existem deficiências no nível de confiança do DA, mas essa deficiência é inevitável quando se pensa na perspectiva da inovação e da narrativa de mercado.
Fonte da imagem: Oficial do Eclipse - Lógica de interação modular do Eclipse
De acordo com a documentação oficial, conforme mostrado na figura acima, o Eclipse passa pelo Blobstream da Celestia (conforme descrito acima, a solução DA modular Ethereum baseada na extensão DAS), e os dados do Eclipse certificados para Ethereum foram testados e executados, permitindo a ponte operar de acordo com a raiz de dados assinada pela Celestia para verificar a segurança dos dados fornecidos para fins de prova de fraude. Seus usuários depositam fundos no Eclipse por meio da ponte Ethereum nativa, e o processo é descrito abaixo:
1. O usuário chama o contrato-ponte de depósito Eclipse no Ethereum (veja o link estendido 1 para o endereço do contrato);
2. No executor SVM do Eclipse (calcula os resultados do SVM e os envia para o novo nó de estado do Ecilpse), o repetidor (canal ETH e Eclipse) completa a interação de dados de cadeia cruzada entre o endereço de envio do usuário e o endereço de recebimento;
3. O relé chama o programa bridge SVM e é responsável por enviar os depósitos do usuário para o endereço de destino;
4. O relé verifica a transação de depósito através do cliente zk-light (a ser implementado);
5. O bloco final da transação de transferência contendo os depósitos subsequentes é concluído e publicado através do plug-in Solana Geyser.
Nesse processo, o executor SVM publicará cada slot do Eclipse na fila de mensagens por meio do Geyser, e seu slot será publicado no Celestia como um bloco de dados, e o verificador do Celestia aceitará o bloco de dados enviado. As transações de prova estão incluídas na cadeia do Eclipse. e correspondem à raiz dos dados e, finalmente, cada bloco de dados do Celestia é retransmitido via Blobstream para o contrato da ponte Eclipse no Ethereum.
Fonte da imagem: oficial do Eclipse: interação entre Celestia e executor SVM
Ao mesmo tempo, semelhante a outras camadas 2 no Ethereum que utilizam provas de fraude, a retirada de fundos entre Eclipse e Ethereum também requer um período de janela de consulta, para que o verificador possa enviar uma prova de fraude quando a transição de estado for inválida.
O executor SVM liberará periodicamente uma época (processo em um número de lote predeterminado) de slots Eclipse para Ethereum para confirmar e liberar garantias;
O contrato ponte do Eclipse realiza verificações básicas para garantir que o formato dos dados publicados esteja intacto (consulte o artigo de referência [2] capítulo Design à prova de fraude para obter detalhes);
Se o lote enviado passar na verificação básica, será gerada uma janela predefinida. Dentro desta janela, se o lote for confirmado, significa que a transição de estado é inválida e o verificador pode emitir um certificado de fraude;
Se um validador publicar com sucesso uma prova de fraude, ele ganhará a garantia do executor, o lote publicado será rejeitado e o estado da especificação Eclipse L2 será revertido para o último compromisso de lote válido. Aqui os gestores do Eclipse terão o poder de eleger novos executores;
No entanto, se o período de contestação for ultrapassado sem prova de fraude, o executor recuperará as suas garantias e recompensas;
Finalmente, o contrato ponte Eclipse completa todas as transações de retirada incluídas no lote finalizado.
resumo
Eclipse ainda está no estágio inicial de desenvolvimento da testnet e é o primeiro SVM Layer2 no Ethereum. A testnet está atualmente online e a mainnet está planejada para ser lançada no primeiro trimestre de 2024. Atualmente, o Ethereum ainda considera o Rollup como sua principal rota de desenvolvimento. Deixando de lado o tema da ortodoxia, isso significa, até certo ponto, que o Ethereum entregou ao mercado a definição ampla da Camada 2, de modo que o empoderamento manifesto também está oculto. concorrência. Eclipse aproveita isso e usa desenvolvimento modular para combinar a segurança do Ethereum, o alto desempenho do Solana e do Celestia DA para criar uma forte narrativa de mercado.
Olhando para trás, para o processo de desenvolvimento do Ethereum, um ponto muito interessante é que a última rodada de condições de mercado foi impulsionada pelo hype do DeFi Summer, com um grande número de inovações e adições em “DeFi Matryoshka” e “DeFi Lego”, que causou um desenvolvimento explosivo em todo o ecossistema. Nesta rodada, um grande número de combinações de "apostar matryoshka" e "apostar Lego" apareceram sob a combinação de LSD e reapostar, permitindo que EigenLayer, Blast e Merlin do ecossistema BTC atingissem novos máximos em TVL no curto prazo. Se considerarmos as bonecas matryoshka e o Lego como o tema principal do sentimento do mercado, então a modularidade também poderá tocar sua própria boneca matryoshka e melodia de Lego no futuro.
O charme da modularidade está na dissociação dos benefícios dos componentes, realizando assim a inovação em cada camada da pilha, de modo que a otimização de cada módulo possa ampliar a otimização de outros módulos. Talvez no futuro, para desenvolvedores e usuários, a modularização O desenvolvimento. processo pode gerar um grande número de opções concorrentes.
Artigo de referência
【1】https://blog.celestia.org/introduzindo-blobstream/ Introdução ao Blobstream: Transferir DA modular para Ethereum
【2】https://mirror.xyz/eclipsemainnet.eth/0Q9NufkOPaRfCwi0yFj-_D4eONgscqpr00HGgYCwkHA?ref=twitter Explore o sistema de ponte e verificação Canonical Ethereum do Eclipse
Link de extensão
(1) https://sepolia.etherscan.io/address/0x7C9e161ebe55000a3220F972058Fb83273653a6e Endereço ponte do contrato de depósito Ecilpse
(2) https://github.com/solana-foundation/solana-improvement-documents/pull/65 SIMD: Prova de fraude de SVM
(3) https://github.com/Eclipse-Laboratories-Inc/zk-bpf comprova a execução do bytecode BPF
