Eclipse 창립자 Neel Somani는 Airbnb에서 소프트웨어 엔지니어, Citadel에서 정량적 연구원으로 근무했으며, 2022년 Solana를 기반으로 한 스타트업인 Eclipse를 설립했으며 Solana 공동 창립자인 Anatoly Yakovenko와 Polygon(Solana 및 Polygon용)의 지원을 받았습니다. . 호환되는 롤업 블록체인을 구축하세요).
2022년 9월 28일자 CoinDesk 보고서에 따르면 Eclipse는 Polychain이 주도한 600만 달러의 Pre-Seed 라운드 자금 조달과 Tribe Capital과 Tabiya가 공동 주도한 900만 달러의 시드 라운드 자금 조달을 성공적으로 완료했으며 총 자금 조달 금액은 1,500 미국 달러로 1만 달러. 또한, Eclipse는 솔라나 가상 머신 기반 롤업을 지원하기 위해 솔라나 재단으로부터 개발 보조금을 받았습니다.
Eclipse의 창립자인 Somani는 자신의 연결과 Solana의 시카고 본사와 가까운 지리적 이점을 활용하여 Solana의 가상 머신을 사용하여 독특한 체인을 만드는 데 성공했습니다. 비전은 개발자가 Solana 가상 머신으로 구동되는 롤업을 배포할 수 있도록 하는 것입니다. 2023년 초 Cosmos 생태계에서 공개 테스트 네트워크를 출시할 계획이며 향후 Aptos의 Move 언어를 지원할 계획입니다.
솔라나의 공동 창립자이자 이클립스 엔젤 투자자인 아나톨리 야코벤코(Anatoly Yakovenko)는 "이클립스는 솔라나가 블록체인 간 통신(IBC)을 통해 코스모스와 소통할 수 있는 길을 열어줍니다."라고 말했습니다.
Polychain Capital의 파트너인 Niraj Pant는 "대기업과 정부가 블록체인 공간에 진입하기 시작하면서 Eclipse는 Web2 규모 소비자 및 금융 애플리케이션과 같은 사용 사례를 촉진하는 중요한 인프라입니다."라고 말했습니다.
Eclipse 아키텍처
다음 내용은 공식 설명을 기반으로 한 것입니다.Eclipse Mainnet은 SVM을 기반으로 구축된 Ethereum의 첫 번째 일반 L2입니다.모듈 스택의 가장 좋은 부분을 결합하고 SVM이 구동하는 가장 빠르고 가장 일반적인 Ethereum Layer 2가 되는 것을 목표로 합니다. 프로젝트 아키텍처는 이더리움을 결제 계층으로 사용하고 공식 임베디드 검증 브리지에 사용되며, Celestia는 데이터 가용성 계층으로, RISC Zero는 영지식 사기 증명 생성에 사용되며, 마지막으로 Solana의 SVM은 모듈식 레이어 2 프로젝트로 구현됩니다. 전체적으로. 이하의 내용은 공식적인 설명을 바탕으로 자세히 설명하겠습니다.
결제 계층 - 이더리움: Eclipse는 이더리움(즉, 이더리움에 내장된 검증 브리지)에 결제하고 ETH를 가스 소비로 사용하며 사기 증명도 이더리움에 제출됩니다.
실행 계층 - SVM(Solana Virtual Machine): Eclipse는 Solana Labs 클라이언트(v1.17)의 포크인 고성능 SVM을 실행 환경으로 실행합니다.
데이터 가용성 계층 - Celestia: Eclipse는 확장 가능한 데이터 가용성(DA)을 달성하기 위해 Celestia에 데이터를 게시합니다.
증명 메커니즘 - RISC Zero: Eclipse는 ZK 사기 증명을 위해 RISC Zero를 사용합니다(중간 상태 직렬화가 필요하지 않음).
통신 프로토콜 - IBC: Cosmos의 체인 간 통신 표준 IBC를 통해 비Eclipse 체인과의 브리징을 완료합니다.
크로스체인 프로토콜 - Hyperlane: Eclipse와 Hyperlane은 Hyperlane의 무허가 상호 운용성 솔루션을 SVM(Solana Virtual Machine) 기반 블록체인에 제공하기 위해 협력하고 있습니다.
출처: 이클립스 공식
결제 계층: Ethereum의 보안 및 유동성에 액세스
Eclipse는 다른 Ethereum Rollup과 마찬가지로 Ethereum을 결제 계층으로 사용합니다. 이 프로세스에서는 Ethereum의 Eclipse 검증 브리지가 Eclipse에 직접 통합되어야 합니다. 해당 노드는 검증 브리지의 정확성과 올바른 트랜잭션 순서를 감지하여 사용자가 얻을 수 있도록 해야 합니다. 이더리움 수준의 보안.
L2BEAT는 Layer2를 "이더리움의 첫 번째 레이어에서 전체 또는 부분적으로 보안을 파생하는 체인이므로 사용자가 자금 보안을 보장하기 위해 Layer2 검증자의 무결성에 의존할 필요가 없습니다."라고 정의합니다. Eclipse 검증 브리지는 특정 실패 조건에서 궁극적인 유효성과 검열 저항을 강화하여 사용자가 브리지를 통해 거래를 강제로 완료하고 시퀀서가 다운되거나 L2에서 검열이 시작되는 경우에도 이더리움을 거래 가스로 사용할 수 있도록 합니다.
실행 레이어: 솔라나의 트랜잭션 속도와 규모 파악
효율성 향상을 위해 Eclipse 메인넷은 SVM과 Sealevel을 사용하는 Solana의 실행 환경을 채택합니다(Solana는 수평 확장 기술 솔루션을 구축하는 데 사용되며 초병렬 트랜잭션 처리 엔진은 GPU와 SSD에 걸쳐 수평 확장을 위해 사용됩니다). EVM 단일 스레드에서 실행하는 것과 비교하면 순차적으로 실행하는 것이 아니라 중첩된 상태 트랜잭션을 설계하지 않고 실행할 수 있다는 장점이 있습니다.
EVM 호환성 문제와 관련하여 Eclipse 메인넷은 개발자가 이더리움 도구를 활용하고 Solana에서 Web3 애플리케이션을 구축할 수 있도록 Neon EVM과 협력했습니다. 공식 데이터에 따르면 처리량은 단일 스레드 EVM보다 크고 140TPS 수준에 도달할 수 있습니다. EVM 사용자는 MetaMask 지갑의 "Snaps" 플러그인을 통해 Eclipse 메인넷의 애플리케이션과 기본적으로 상호 작용합니다.
데이터 가용성: Celestia의 대역폭과 검증 가능한 특성 활용
Ecilpse 메인넷은 데이터 가용성과 장기적인 관계를 위해 Celestia를 활용할 것입니다. 그 이유는 Ethereum이 현재 EIP-4844 업그레이드 후에도 평균 약 0.375MB를 제공할 수 있는 Ecilpse의 목표 처리량 및 수수료를 충족할 수 없기 때문입니다. 블록 Blob 공간(블록당 약 0.75MB로 제한됨)
공식 데이터에 따르면 Rollup 확장을 기반으로 한 ERC-20 트랜잭션은 트랜잭션당 154byte로 계산되며 이는 모든 Rollup의 총합이 약 213TPS인 것과 같습니다. Compression Swap의 경우 모든 Rollup의 TPS가 약 400byte로 계산됩니다. 트랜잭션 당 바이트 약 82TPS. Celestia가 출시한 2MB 블록과 비교하여 Blobstream은 네트워크가 안정적이라는 것이 입증되고 더 많은 DAS(관련 확장은 아래에 설명되어 있음) 라이트 노드가 켜지고 꺼지면 8MB로 증가할 것으로 예상됩니다.
Ecilpse는 Celestia의 DAS 라이트 노드 지원으로 암호화 경제의 보안과 고도로 확장 가능한 DA 처리량 간의 균형으로 인해 Celestia가 현재 Eclipse 메인넷을 위한 최선의 선택이 되었다고 믿습니다. 현재 이더리움 DA를 사용하는 것이 정통 Layer 2라는 견해가 있지만, 프로젝트 팀은 EIP-4844 이후 DA 확장의 진행 상황에 계속 주목할 것입니다. DA, 이더리움 DA로의 마이그레이션 가능성을 재평가할 예정입니다.
증명 메커니즘: RISC Zero 사기 증명(중간 상태 직렬화 없음)
Eclipse의 증명 방법은 Anatoly의 SVM 사기 방지 SIMD(자세한 내용은 GitHub 확장 링크 2 참조)와 유사하며, 이는 높은 상태 직렬화 비용을 피하기 위한 John Adler의 통찰력과 일치합니다. 따라서 초기 프로젝트 당사자들은 Merkle 트리(해시 트리)가 SVM에 다시 도입되는 것을 피하기 위해 Sparse Merkle Tree를 SVM에 삽입하려고 시도했지만 트랜잭션이 발생할 때마다 Merkle 트리를 업데이트하면 성능에 큰 영향을 미칠 것입니다. 증명을 위해 머클 트리를 사용하지 않으면 기존 범용 롤업 프레임워크(예: OP 스택)는 SVM 롤업의 기초 역할을 할 수 없으며 보다 창의적인 실패 방지 아키텍처가 필요합니다.
실패 증명 요구 사항: 트랜잭션의 입력 약속, 트랜잭션 자체, 트랜잭션을 다시 실행하면 체인에 지정된 것과 다른 출력이 발생한다는 증명.
입력 약속은 일반적으로 롤업 상태 트리의 Merkle 루트를 제공하여 구현됩니다. Eclipsse의 실행자는 각 트랜잭션에 대한 입력 및 출력 목록(계정 해시 값 및 관련 전역 상태 포함)과 생성된 트랜잭션 인덱스를 게시합니다. 모든 전체 노드가 이를 따르고, 자체 상태에서 입력 계정을 가져오고, 출력 계정을 계산하고, Ethereum에 대한 약속이 올바른지 확인할 수 있도록 거래를 Celestia에 게시합니다.
여기에는 두 가지 가능한 심각한 오류 유형도 있습니다.
잘못된 출력: 유효성 검사기는 올바른 출력 체인에 ZK 증명을 제공합니다. Eclipse는 RISC Zero를 사용하여 SVM 실행의 ZK 증명을 생성합니다. 이는 BPF 바이트코드 실행을 증명하는 프로젝트의 이전 작업을 계속합니다(자세한 내용은 GitHub 확장 링크 3 참조). 이를 통해 우리의 결제 계약은 온체인 거래를 실행하지 않고도 정확성을 보장할 수 있습니다.
잘못된 입력: 유효성 검사기는 입력 상태가 요청된 상태와 일치하지 않음을 나타내는 기록 데이터를 체인에 게시합니다. Celestia의 Quantum Gravity Bridge는 Eclipse 결제 계약을 통해 과거 데이터에 사기가 있는지 확인하는 데 사용됩니다.
ETH 및 Celestia에 대한 Eclipse 연결
이미지 출처:@jon_charb
DA는 Rollup 비용 지출의 주요 부분 중 하나이며, 현재 Ethereum L2에는 Calldata와 DAC(Data Availability Committees)의 두 가지 주요 데이터 가용성 방법이 있습니다.
Calldata: Arbitrum 또는 Optimism과 같은 레이어 2 솔루션은 트랜잭션 데이터를 체인에 직접 호출 데이터로 Ethereum의 검열 저항성이 높은 블록에 게시합니다. Ethereum은 통화 데이터, 컴퓨팅 및 스토리지의 가격을 하나의 단위, 즉 Gas로 통합합니다. 이는 Rollup이 Ethereum에 지출하는 주요 비용 중 하나이기도 합니다. 효율성을 높이기 위해 EIP-4844 업그레이드에서는 호출 데이터를 대체하기 위해 Blobspace를 도입하여 모든 롤업에 대해 블록당 375KB의 목표 값을 제공했습니다.
DAC: DAC는 체인에서 직접 호출 데이터를 발행하는 것보다 처리량이 훨씬 높지만, 사용자는 악의적인 데이터 보류를 피하기 위해 소규모 위원회나 검증자 그룹을 신뢰해야 합니다. 재스테이킹 기반 솔루션도 포함하는 DAC는 L2에 상당한 신뢰 가정을 도입하여 DAC가 데이터 보류 행위를 억제하거나 처벌하기 위해 평판, 거버넌스 메커니즘 또는 토큰 투표에 의존하도록 강제하므로 어느 정도 외부 DA를 사용할 때 , DAC가 필요합니다.
Celestia는 Eclipse의 Blobstream 지분 증명 합의 네트워크를 사용하여 Layer2가 Celestia의 blobspace에 액세스할 수 있도록 하며 압축 방식에 따라 8MB blobspace에 도달합니다. 이는 대략 초당 9,000~30,000 ERC-20 전송에 해당합니다. . 그러나 프로세스에서 Blobstream의 Layer 2를 사용하는 것은 Celestia 검증자 인증에 의존하게 되며, 보안 보증 프로세스의 라이트 노드가 데이터를 유지하여 Celestia 검증자의 2/3의 악의적인 행위를 탐지하면 처벌될 수 있습니다. DAC와 네이티브 체인 DA는 여전히 신뢰 수준에 비해 부족한 부분이 있지만, 혁신과 시장 내러티브의 관점에서 생각해보면 이러한 단점은 피할 수 없습니다.
이미지 출처: Eclipse 공식 - Eclipse 모듈식 상호 작용 논리
공식 문서에 따르면 위 그림과 같이 Celestia의 Blobstream(위에서 설명한 바와 같이 DAS 확장을 기반으로 한 Ethereum 모듈러 DA 솔루션)을 통해 Ethereum에 인증된 Eclipse의 Eclipse 데이터를 테스트하고 실행하여 Bridge가 다음과 같이 작동할 수 있도록 했습니다. 사기 방지를 위해 제공된 데이터 보안을 확인하기 위해 Celestia의 서명된 데이터 루트에 접속합니다. 사용자는 기본 Ethereum 브리지를 통해 Eclipse에 자금을 입금하며 프로세스는 아래에 설명되어 있습니다.
1. 사용자는 이더리움에서 Eclipse 예금 브릿지 계약을 호출합니다(계약 주소는 확장 링크 1 참조).
2. Eclipse의 SVM 실행기(SVM 결과를 계산하여 Ecilpse의 새 상태 노드에 출력)에서 릴레이(ETH 및 Eclipse 채널)는 사용자의 송신 주소와 수신 주소 간의 크로스체인 데이터 상호작용을 완료합니다.
3. 릴레이는 사용자 예치금을 대상 주소로 보내는 일을 담당하는 SVM 브릿지 프로그램을 호출합니다.
4. 중계기는 zk-light 클라이언트(구현 예정)를 통해 입금 거래를 확인합니다.
5. 이후 입금이 포함된 최종 이체 거래 블록이 완성되어 Solana Geyser 플러그인을 통해 게시됩니다.
이 과정에서 SVM 실행자는 Geyser를 통해 각 Eclipse 슬롯을 메시지 큐에 게시하고 해당 슬롯은 데이터 블록으로 Celestia에 게시되며 Celestia의 검증자는 제출된 데이터 블록을 수락합니다.증명 트랜잭션은 Eclipse 체인에 포함됩니다. 데이터 루트에 대응하고 마지막으로 각 Celestia 데이터 블록은 Blobstream을 통해 Ethereum의 Eclipse 브리지 계약으로 전달됩니다.
사진 출처: Eclipse 공식: Celestia와 SVM 실행기 상호 작용
동시에 사기 증명을 사용하는 Ethereum의 다른 레이어 2와 유사하게 Eclipse와 Ethereum 간의 자금 인출에도 쿼리 창 기간이 필요하므로 상태 전환이 유효하지 않을 때 검증자가 사기 증명을 제출할 수 있습니다.
-SVM 실행자는 Eclipse 슬롯의 이더리움에 대한 에포크(미리 결정된 배치 번호에 따른 프로세스) 약속을 정기적으로 릴리스하고 모기지를 릴리스합니다.
-Eclipse의 브리지 계약은 게시된 데이터 형식이 손상되지 않았는지 확인하기 위해 기본 검사를 수행합니다(자세한 내용은 참조 기사 [2] 사기 방지 설계 장 참조).
-제출된 배치가 기본 검사를 통과하면 미리 정의된 창이 생성됩니다. 이 창 내에서 배치가 커밋되면 상태 전환이 유효하지 않으며 검증자가 사기 인증서를 발급할 수 있음을 의미합니다.
- 유효성 검사기가 사기 증명을 성공적으로 게시하면 실행자의 보증을 받고 게시된 배치가 거부되며 Eclipse L2의 사양 상태는 마지막 유효한 배치 커밋으로 롤백됩니다. 여기서 Eclipse 관리자는 새로운 실행자를 선출할 권리를 갖습니다.
- 단, 사기 증명 없이 이의제기 기간이 경과한 경우, 집행자는 담보와 보상을 회수합니다.
-마지막으로 Eclipse 브릿지 계약은 최종 배치에 포함된 모든 출금 거래를 완료합니다.
요약
Eclipse는 아직 초기 개발 테스트넷 단계에 있으며 Ethereum의 첫 번째 SVM Layer2입니다. 테스트넷은 현재 온라인 상태이며 메인넷은 2024년 1분기에 출시될 예정입니다. 이더리움은 현재 여전히 롤업을 핵심 개발 경로로 간주하고 있으며, 정통이라는 주제는 제쳐두고 어느 정도 이더리움이 레이어 2의 광범위한 정의를 시장에 넘겨주었기 때문에 명백한 권한 부여도 숨겨져 있다는 의미입니다. 경쟁. Eclipse는 이를 활용하고 모듈식 개발을 사용하여 Ethereum의 보안, Solana 및 Celestia DA의 고성능을 결합하여 강력한 시장 내러티브를 만듭니다.
이더리움의 개발 과정을 되돌아보면 매우 흥미로운 점은 지난 시장 상황이 DeFi Summer의 과대광고에 의해 주도되었으며, "DeFi Matryoshka" 및 "DeFi Lego"에 수많은 혁신과 추가가 이루어졌다는 점입니다. 전체 생태계의 폭발적인 발전을 일으켰습니다. 이번 라운드에서는 LSD와 Re-stake의 조합으로 다수의 "Stake Matryoshka" 및 "Stake Lego" 조합이 등장하여 BTC 생태계의 EigenLayer, Blast 및 Merlin이 단기적으로 TVL에서 새로운 최고치를 달성할 수 있었습니다. 마트료시카 인형과 레고를 시장 정서의 주요 테마로 삼는다면, 모듈화를 통해 미래에는 마트료시카 인형과 레고 멜로디도 자체적으로 재생할 수 있습니다.
모듈화의 매력은 구성 요소의 이점을 분리하여 스택의 각 계층에서 혁신을 실현함으로써 각 모듈의 최적화가 다른 모듈의 최적화를 증폭시킬 수 있다는 데 있습니다.아마도 미래에는 개발자와 사용자를 위해 모듈화 개발이 이루어질 것입니다. 프로세스는 수많은 경쟁 옵션을 생성할 수 있습니다.
모든 댓글