이더리움 최대 퍼프 DEX인 Lighter가 OpenVM과의 협업을 통해 Lighter EVM 체인 런칭 계획을 발표했습니다. Lighter E

이더리움 최대 퍼프 DEX인 Lighter가 OpenVM과의 협업을 통해 Lighter EVM 체인 런칭 계획을 발표했습니다. Lighter EVM은 - Lighter와 네이티브하게 상호운용되며 - EVM 동등성을 갖고 - OpenVM 기술로 증명이 생성되는, Lighter와는 구분된 별도의 ZK 롤업입니다. Lighter EVM은 Lighter의 유동성을 EVM 환경에서 활용할 수 있도록 하는 레이어로 사용될 예정이며, HyperEVM과 그 역할이 거의 동일하다고 볼 수 있습니다. [주요 특징] - Lighter EVM과 Lighter는 이더리움에서 공동 정산 - 증명 집계를 통해 두 실행 환경이 함께 검증되며, L1 파이널리티를 기다리지 않고도 수 초 내 이동 가능 - Lighter EVM에서는 Lighter 상태에 대한 sync read, 주문·자산 이동 등의 fast async write 지원 - write 레이턴시를 더욱 줄이거나 sync 옵션을 제공하는 방향도 연구 중 여기서 중요한 지점은 Lighter ↔️ Lighter EVM 상호운용 구조에서 개발자 경험(DX)이 어떠하냐로 보입니다. Lighter EVM은 HyperEVM을 상당 부분 벤치마킹한 구조에 가까워 보이는데, HyperEVM에서의 개발자 경험은 그리 긍정적인 평가를 받지는 못했기 때문입니다. 예를 들어, HyperEVM 위에서 레버리지 토큰 프로젝트를 진행한 Bounce.tech의 파운더는 트위터에 HyperEVM 개발 경험에 대한 긴 피드백을 남긴 적이 있습니다. 핵심 내용은 다음과 같습니다. 1. 동기(EVM) vs 비동기(CoreWriter) 구조 충돌 하이퍼리퀴드는 HyperEVM에서 오더북으로 트랜잭션을 전송하는 CoreWriter 컨트랙트를 두고 있는데, 이 컨트랙트의 액션은 모두 비동기적으로 처리됩니다. 즉, EVM 트랜잭션은 성공했더라도 실제 코어 상태 변경은 다음 블록에서 처리되거나 실패할 수 있습니다. 이로 인해 구현 복잡성이 크게 증가하며, 잘못된 view 값에 의존하는 로직이 생길 경우 컨트랙트 해킹 위험도 높아질 수 있습니다. 2. 프리컴파일/RPC 제약으로 인한 데이터 신뢰성 문제 과거 블록 기준의 하이퍼리퀴드 오더북 데이터를 온체인에서 완전하게 조회할 수 있는 구조가 아니기 때문에, 결국 별도의 실시간 오프체인 인프라를 직접 구축해야 하는 불편함이 존재합니다. 3. 툴링·문서·프로토콜 기능의 미성숙 Foundry 등에서 CoreWriter 관련 로직을 제대로 테스트하기 어렵고, 문서와 개발자 지원도 부족해 개발 경험에 상당한 제약이 있다는 지적이 있었습니다. HyperEVM과 하이퍼리퀴드가 사실상 서로 다른 두 체인이 CoreWriter 및 프리컴파일로 연결된 구조인 것처럼, Lighter와 Lighter EVM 역시 유사한 방식으로 구현될 가능성이 높아 보입니다. 그렇다면 위와 같은 문제들에 대해 Lighter는 어떤 접근을 취할지 궁금해지는 지점입니다. 한편, L2Beat 리서처 Donnoh는 이를 두고 “최초의 공유 시퀀서 및 증명 집계 기반 빠른 상호운용성”이라고 표현하며 기대감을 드러냈습니다. 2024년에는 공유 시퀀서가 주요 버즈워드로 떠오르며 많은 팀들이 관련 인프라를 구축했지만, 체인들이 시퀀싱 주권을 포기하지 않으려 했고, 결과적으로 뚜렷한 PMF를 찾는 데에는 어려움을 겪었습니다. 그러나 Lighter와 같이 체인의 시퀀서를 동일 주체가 운영하는 구조라면, 충분히 공유 시퀀서 구조를 쓸 유인이 있다고 볼 수 있을 거 같네요. Lighter 외 다른 대형 L2 역시도, 타당한 목적(e.g. 가스 마켓 분리)이 있다면 공유 시퀀서 구조를 실용적으로 활용할 수도 있지 않을까 하는 생각도 듭니다. 출처