모듈러 블록체인의 보안 리스크

1. 모듈러 블록체인 - 개발에서 통합까지

2023년은 모듈러 블록체인의 "개발"의 해였다. 관련 프로젝트들을 정리한 결과에 따르면, 모듈러 블록체인의 핵심 인프라를 중심으로 100개 이상의 프로젝트가 개발되어 블록체인의 여러 계층을 다양화했다. 실행 환경과 Settlement 및 데이터 가용성 레이어에서 많은 프로젝트들이 개발을 진행중에 있다.

작년에 많은 프로젝트가 프로덕션에 출시되었고, 다양한 시도가 이루어졌다. 이는 특히 실행 레이어에서 많이 나타났는데 EVM, WasmVM, MoveVM, CairoVM, zk RISC VM, MIPS VM 등의 등장을 통해 실행환경이 올해에는 EVM에만 국한되지 않을 것임을 확인할 수 있다. 또한 증명 생성 및 검증 과정으로 인식되는 Settlement 프로세스도 프로젝트마다 다양한 방식으로 발전해왔다.

Source: The Rollup

2023년 "개발 단계"에 이어 2024년은 "통합 단계"의 해가 될 것이다. 다양한 구성 요소의 통합이 점점 더 중요해지고 있기에 어떤 프로젝트와 어떠한 방식으로 통합될지 확인하는 것이 중요해졌다. 예를 들어 "OP-Stack 실행 환경, DA로 EigenDA, 이더리움의 Settlement를 사용하면 어떠한 리스크가 있을까?" 또는 "중간에 공유 시퀀서를 추가하면 어떠한 결과를 초래할까?"와 같은 질문이 제기될 수 있다. 게다가 통합의 가능성은 아직 많이 모색되고 있지 않았으며 비용과 보안 측면에서 다양한 DA를 비교하고 어떤 롤업 프레임워크가 다른 서비스와의 통합을 더 잘 제공하는지 살펴봐야 한다.

1.1 보안 위험

현재 다양한 모듈러 블록체인 프로젝트의 통합에 대한 개발이 활발히 이루어지고 있다. 예를 들어, 셀레스티아 데이터 가용성(DA) 레이어에는 블롭스트림이라는 구성 요소가 있다. 이는 L2 컨트랙트에 추가할 수 있는 이더리움의 온체인 라이트 클라이언트로 셀레스티아에 저장된 정보를 저장하게 해준다. 이를 통해 기존 L2들은 비교적 낮은 비용으로 이더리움의 높은 DA 비용을 절감할 수 있다. 하지만 셀레스티아가 중단되면 어떠한 문제가 생길지, L2들이 중단된다면 그 위의 L3들도 중단될지 등에 대한 분석이 부족하다.

셀레스티아의 경우 현재 각 롤업 프레임워크에 대해 폴백 메커니즘을 고안했다. 셀레스티아가 실패하면 롤업은 자동으로 데이터를 이더리움에 게시한다. 그러나 이 메커니즘은 아직 개발 중이며 테스트가 필요하다. 다양한 구성 요소를 통합하는 것은 보안 조치가 마련되어 있더라도 잠재적인 위험을 수반한다.

이러한 위험은 롤업 프레임워크를 사용하여 자체 롤업을 개발하기 시작한 프로젝트에서 더 분명하게 드러난다. 이러한 프로젝트 개발자는 프레임워크 팀에 비해 코드베이스에 대한 전문 지식이 부족하기 때문에 코드베이스 업데이트를 간과하여 다른 서비스와의 통합에 문제를 초래할 수 있다. 예를 들어, 최근 이더리움 덴쿤 업그레이드로 인한 Blast가 중단된 것을 대표적인 사례로 꼽을 수 있다. 이러한 상황은 전체 생태계에 심각한 위험을 초래할 수 있다.

이번 아티클에서는 모듈러 블록체인과 관련된 잠재적 위험에 대해 자세히 살펴보자 또한 다이멘션, 이클립스, 에스프레소의 지브롤터 등 특정 프로젝트를 살펴보고 고유한 구조적 위험을 파악해보자.

2. 모듈형 블록체인의 레이어 분석하기

모듈러 블록체인은 분리된 레이어에 의해 리스크가 있으며 일반적으로 시퀀싱, 실행, 데이터 가용성, Settlement, 합의가 포함된다. 이러한 맥락에서 모놀러 블록체인은 레이어가 하나의 큰 레이어로 결합된 것으로 볼 수 있다. 레이어에 대해 자세히 알아보기 전에 먼저 이더리움과 같은 모놀리식 블록체인이 어떻게 이러한 레이어들이 어떻게 운영되는지 살펴보자.

2.1 이더리움 - 결합된 하나의 레이어

다음은 이더리움 PoS에서 블록의 생선 프로세스 및 파이널리티가 일어나는 프로세스를 단계별로 분석한 것이다. 기존 모놀리틱 블록체인에서의 과정을 이해하고 모듈러 블록체인에서는 어떻게 다른지 알아보자.

2.1.1 Execution: Block Proposal

• Ordering and Transaction: 스테이킹된 이더리움의 양에 따라 무작위로 선택된 검증자가 멤풀에서 트랜잭션 취합하고, 이를 실행한 후 이전 블록에 대한 참조와 함께 해당 거래가 포함된 새 블록을 제안하여 블록을 생성한다.

2.1.2 DA and pre-Settlement

• 데이터 가용성: 다른 검증자(증명자)는 제안된 블록을 확인하고, 트랜잭션을 검증하고, 이더리움 프로토콜 규칙을 따르는지 확인한 후 서명, 블록의 해시, 에포크를 포함하는 증명서를 게시하여 투표한다.

• 블록이 무작위로 선정된 검증자 위원회의 2/3 이상으로부터 증명을 받으면 정당한 것으로 간주되며, 이는 해당 블록에 대한 확정 직전 단계이다.

2.1.4 Consensus by the Committee

• Finality: 최소 두 개의 연속적인 에포크가 진행되고, 두 번째 에포크가 첫 번째 에포크와 직접적으로 연결될 때 최종성이 달성된다. 이 조건은 첫 번째 에포크와 아직 확정되지 않은 이전 에포크의 블록을 포함한 모든 블록의 확정으로 이어진다.

• 확정된 블록은 되돌릴 수 없다. 이는 블록체인의 불변성을 보장하고 이중 지출 및 기록 수정 공격으로부터 보호된다.

2.2 모듈러 블록체인의 프로세스와 리스크

2.2.1 Sequencing: Ordering

시퀀싱의 맥락에서, 처음에는 트랜잭션의 유효성을 확인한 후 시퀀서의 멤풀에 추가된다. 이 설정을 통해 일부 프로젝트에서는 사용자가 트랜잭션을 레이어 1(L1) 블록체인으로 직접 전송할 수 있다. 시퀀서는 트랜잭션을 정렬하고 정렬된 트랜잭션 목록이 포함된 블록을 생성한다.

올해 프로덕션으로 나올 거으로 예상되는 공유 시퀀서는 여러 개의 시퀀서가 트랜잭션 목록이 정렬된 블록을 생성하는 것을 처리하는 시퀀서이다.

잠재적 위험

• 중앙화: 현재 프로세스는 중앙화되어 있으며, 단일 주체가 시퀀서를 운영하고 스토리지를 관리한다. 이러한 중앙화에는 검열, 그리고 일반적으로 롤업에 사용되는 이더리움과 같은 레이어 1 블록체인과 같이 화이트리스트에 오른 운영자만 Settlement 레이어와 상호작용할 수 있다는 제한 등 내재된 위험이 존재한다. 그러나 공유 시퀀서(롤업 간에 공유되는 시퀀서 집합) 또는 탈중앙화 시퀀서(단일 롤업에서 사용되는 시퀀서 집합)가 이 문제를 해결하기 위해 노력하고 있지만, 아직 상용화되지는 않았다.

2.2.2 Execution: State transition

실행 레이어 트랜잭션들을 미리 정의된 로직에 따라 실행하여 현재 상태를 수정한다. 예를 들어, 이더리움 가상 머신(EVM)에서는 간단한 토큰 전송으로 발신자와 수신자 모두의 계정 잔액이 변경된다. 반면, Fuel Network는 UTXO 형식을 사용해 이러한 전송을 구현한다.

이 계층은 현재 실험이 급증하고 있으며, 세 가지 주요 방법으로 분류할 수 있다:

1. 기존 가상 머신 강화: zkSync와 같은 프로젝트는 사용자 및 개발자 경험을 개선하기 위해 AA를 체인 레이어에 통합했다. 마찬가지로, CairoVM을 기반으로 구축된 zkEVM인 Kakarot은 CairoVM의 기능을 활용하여 병렬 EVM 실행을 통합할 계획이다.

2. 새로운 가상 머신 개발: EVM이 블록체인에서 가장 많이 쓰이는 가상 머신이었지만, 현재 SVM, MoveVM, WasmVM, 일반 zkVM(MIPS, RiscV 기반)과 같은 새로운 가상 머신이 개발되고 있다.

3. 여러 VM 지원: MultiVM과 같은 프로젝트는 EVM, SVM 및 기타 VM이 단일 실행 환경 내에서 공존할 수 있는 실행 환경을 만들고 있다.

Potential Risks

• 다른 VM 사양: 현재 모든 EVM이 동일한 것은 아니며, 대부분의 EVM equivalent이기 때문에 원래 EVM과 완전히 호환되지 않는다. 일부 op-code는 특정 EVM에서 지원되지 않을 수 있습니다. 디앱은 동일한 컨트랙트 기반을 가진 다른 블록체인에 배포하여 확장하려고 하기 때문에, 일부 깨지는 구성 요소가 있을 수 있다. 예를 들어, zkSync의 한 디앱은 가스 계산 시스템이 EVM과 다르기 때문에 스마트 컨트랙트에서 921 ETH 자금이 동결된 사례가 있었다.

현재 트랜잭션은 대부분 L1에 저장되어 있어 가용성이 보장된다. 노드는 이더리움을 확인하여 시퀀스된 트랜잭션 목록을 확인할 수 있으며 디쿤 업그레이드 이후 이더리움은 훨씬 더 낮은 비용을 갖게 되었다. 그러나 이 옵션은 여전히 비싸고 롤업의 운영 비용 대부분이 트랜잭션 저장에서 발생하기 때문에, 더 저렴한 대안을 제공하기 위해 셀레스티아나 Avail과 같은 altDA 프로젝트가 등장했다.

잠재적 위험:

• altDA의 실패: 이더리움의 실패 가능성은 낮지만, altDA의 경우 프로덕션에서 운영되기 시작한지 얼마 되지 않았기 때문에 잠재적인 위험성이 있다. 그러나 셀레스티아와 같은 altDA 프로젝트는 네트워크에 장애가 발생했을 때 이더리움을 DA로 사용할 수 있는 옵션을 제공한다.

2.2.4 Settlement: proof of execution

Settlment는 실행 결과에 대한 증명이 이루어지는 곳입니다. 현재 optimistic 증명, zk 증명, 하이브리드 세 가지 유형이 있다.

• optimsitic 증명 롤업은 기본적으로 트랜잭션을 검증하며, 이의를 제기하는 경우에만 사기 증명을 요구한다.

• zk 롤업은 영지식 증명을 사용하여 완결성을 제공한다.

• 하이브리드 증명은 낙관적 증명의 빠른 소프트 파이널리티와 zk 증명을 결합하여 일반적으로 낙관적 증명과 관련된 긴 챌린지 기간을 줄인다. 현재 Fuel Network, 메티스, 크로마 등의 프로젝트를 포함해 다양한 방식으로 사용되고 있다.

2.2.5 Consensus: finalization

합의는 모듈러 블록체인 또는 롤업의 상태 변경을 최종적으로 확정되는 마지막 단계이다. 이 단계에서는 수정된 저장소의 파이널리티와 상태의 루트를 인증하는 역할을 한다. 예상치 못한 시나리오를 고려하기 위해 대부분의 프로젝트는 finality를 확정 짓기 이전에 타임 버퍼를 추가했다. 예를 들어, optimistic 롤업은 일반적으로 7일의 챌린지 기간을 가지며(각 프로젝트마나 다를 수 있음), zk 롤업도 24시간 혹은 더 짧게 타임 버퍼를 둔다.

2.3 Dissecting Use Cases

모듈러 구조는 현재 아주 많은 관심을 받고 있지만, 아직 그 생태계는 극초반에 진입해있다고 할 수 있다. 혹자는 “모듈러 블록체인이라면 여러 계층을 레고 쌓듯이 결합시키면 되는 것 아닌가?” 라고 생각할 수 있지만, 치밀하게 연결되어 있던 모놀리틱 구조의 일부를 모듈로 만들고, 이를 다시 연결하는 것은 그리 쉬운 작업이 아니다. 조사 시점에서 여러개의 모듈러 요소가 온전히 결합해 출시한 프로젝트를 찾기 힘들었던 것이 이를 반증한다. 이번 섹션에서는 시장조사를 통해 분석한 모듈러 블록체인의 몇가지 케이스에 대해 소개하고, 이들의 해결하려 했던 기존 체인의 문제점과 이들의 접근법이 가질 수 있는 잠재적인 위험 요소에 대해 소개하고자 한다.

3. 케이스 스터디 A: Espresso Sequencer

일부 L2 롤업에서 찾아볼 수 있는 중앙화된 단일 시퀀서는 다음과 같은 문제를 내재하고 있다.

• 단일 지점 취약점: 우리는 지금까지 L2 블록체인에서 시퀀서의 문제로 블록 생성이 멈춘 경우를 여러 차례 경험해왔다. 이러한 사건들의 원인으로는 소프트웨어 버그나 L1 체인을 위한 가스비 고갈 등이 있었지만, 이러한 사건들의 근본적인 원인은 시퀀서의 중앙화된 운영으로 귀결된다. 일부 L2 체인은 시퀀서가 특정 시간동안 동작하지 못할 시 강제로 트랜잭션을 실행시키고 L2 내의 자산을 출금할 수 있도록 하는 탈출 장치를 만들어 놓기도 한다. 하지만 탈출 장치가 활성화될 경우 트랜잭션의 유효성을 검증하지 못하기 때문에 L2 체인에 심각한 불안정성을 초래하게 되며, 심각할 경우 L2 체인의 포크로 이어질 가능성도 존재한다.

• 시퀀서의 MEV: 중앙화된 시퀀서는 프론트러닝 또는 백러닝을 통해 사용자의 트랜잭션으로부터 경제적 가치를 추출할 가능성이 존재한다.

• 검열 문제: 극단적인 경우, 단일 시퀀서는 사용자의 트랜잭션을 검열해 블록 생성 시 포함시키지 않을 수도 있다. 주요 L2 체인들은 사용자가 제출한 트랜잭션을 바로 확인할 수 있도록 시퀀서 피드를 제공하거나 제출한 트랜잭션이 변형되어 제출되었음이 의심될 경우 챌린지를 걸 수 있도록 사기 증명 메커니즘을 구현해두었다. 하지만 체인 수준의 어플리케이션 메타에 마주한 지금, 각 체인의 사용자는 싱글 시퀀서에 의해 트랜잭션이 처리될 경우 검열 저항성을 위한 조치가 마련되어 있는지 여부를 확인해야할 것이다.

Espresso는 이러한 문제를 지적하고, 경제적 보안성에 근거한 합의를 통해 트랜잭션에 빠르고 강력한 선승인(pre-confirmation)을 제공하는 데에 그 목적을 두고 있는 공유 시퀀서 프로토콜이다. Espresso에서의 시퀀싱은 선입선출 방식 등 간단한 방식으로 이루어지기 때문에 MEV나 검열 문제를 효율적으로 완화한다. 또한 Tiramisu라는 자체 데이터 가용성 계층을 개발해 공유 시퀀싱 방식에서 지적되어 왔던 성능 문제를 해결하고자 한다. Espresso는 이더리움 L2 체인들의 공유 시퀀싱 계층으로서 동작하기 때문에, 롤업 간 상호운용성 측면에서의 장점을 취하고 있다.

이에 더해, Espresso는 L1 밸리데이터들을 자신의 합의 과정에 참여시킴으로써 기존의 다른 롤업 시퀀서보다 강력한 보안을 제공한다. 기존의 롤업에서는 L1 밸리데이터에게 돌아가는 이득이 거의 없어 L1 밸리데이터를 매수해 L1 내 롤업 컨트랙트의 상태값을 포크시키는 공격이 발생할 수 있다는 우려가 존재했다. Espresso는 EigenLayer와의 협업을 통해 이더리움 밸리데이터들이 Espresso의 합의인 HotShot 합의의 룰을 구독하고 인센티브를 취할 수 있도록 하는 구조를 가지고 있다.

Espresso는 그동안 4개의 테스트넷을 통해 성능을 시험하고 있는데, 이들은 각각 Polygon SDK, OP Stack, Arbitrum Nitro 등 각기 다른 실행 계층을 사용했다. 이번 글에서는 각 모듈러 계층을 이루는 프로토콜들이 통합되었을 때의 구조적 리스크를 다루기 때문에, 가장 최근의 테스트넷인 Gibraltar를 분석 대상으로 결정했다. Gibraltar는 Arbitrum Nitro에 Espresso 시퀀서를 결합시켜 배포한 테스트넷이다. Caldera를 통해 Milan이라고 하는 Arbitrum Nitro 인스턴스를 배포하고, 여기에 Espresso의 시퀀서와 데이터 가용성 프로토콜을 결합했다.

Gibraltar의 구성 요소는 아래와 같다.

• Sequencing: Espresso Sequencer

• Execution: Arbitrum Nitro

• Settlement: Ethereum

• Data Availability: Ethereum / Espresso Savoiardi (적용 예정)

내용의 복잡도를 줄이기 위해 Gibraltar의 구조는 부록에서 추가적으로 설명하도록 하겠다.

3.1 Sequencing

본격적으로 문제에 대해 설명하기 이전에, Espresso에 의해 어떻게 트랜잭션의 시퀀싱과 제출이 이루어지는지 알아보자.

사용자가 RPC 서비스 등을 통해 롤업 서버에 트랜잭션을 제출하면, 롤업 서버는 트랜잭션에 자신의 롤업 식별자를 붙여 Espresso API에 전송한다. Espresso는 “view”라고 하는 매 에폭마다 사용자의 트랜잭션을 모은다. Espresso는 HotShot 합의를 통해 매 view마다 HotShot 노드 중 (스테이킹된 토큰의 양에 기반해) 랜덤하게 블록 제안자를 선출한다. 블록 제안자는 트랜잭션을 묶어 블록을 생성하는데, 이때 트랜잭션들은 선입선출 또는 비딩 기반 정렬 등 간단한 방식으로 순서가 정해진다.

블록이 생성되어 각 노드에 전파될 때, Espresso는 자체 데이터 가용성 모듈을 사용한다. Espresso는 DA 위원회라고 하는, 스테이킹된 토큰의 양이 큰 소수의 노드의 집합을 지정해 빠른 합의를 도모한다. 블록 생성 이후 블록 제안자는 DA 위원회에 블록 내에 담긴 트랜잭션과 에폭의 고유번호가 담긴 DA 제안서를 전달한다. DA 위원회의 충분한 투표를 통해 제안서가 통과되면, 블록 생성자는 데이터 가용성 증명서 (DAC, Data Availability Certificate)를 생성하고 다른 노드에게는 블록의 유효성을 보장하는 암호학적 증명인 블록 커밋을 전달한다. DA 위원회 외의 일반적인 노드는 블록 커밋에 대한 검증을 거치고, HotShot 스테이킹량의 3분의 2 이상의 득표수를 획득하면 해당 블록은 완결된다.

만약 DA 위원회를 통한 합의에 실패할 경우, Espresso는 삭제 코딩 (erasure coding)에 기반한 방식을 사용한다. DA 제안서 투표 과정 중 블록 제안자는 모든 노드에 작은 데이터 조각을 전송하는데, 이 데이터 조각들은 이론적으로 정족수 이상이 모이면 블록의 전체 데이터를 재구축할 수 있다. 데이터 조각으르 가진 노드는 데이터 가용성 증명의 유효성 검증에 투표할 수 있으며, 이는 DA 위원회의 실패에 대한 fallback으로 작용한다.

생성된 블록 커밋은 L1의 시퀀서 컨트랙트에 제출되고, 밸리데이터는 시퀀서의 동작을 검증하기 위해 시퀀서 컨트랙트에 제출된 커밋을 활용할 수 있다. Espresso 시퀀서에 의해 생성된 블록은 각기 다른 롤업 노드가 구독하게 되고, 각 노드는 자신의 식별자와 일치하는 트랜잭션을 Espresso가 생성한 블록에서 추출해 사용하게 된다.

Gibraltar 테스트넷의 구조에서 시퀀싱 계층으로 인해 발생하는 리스크는 다음과 같다.

• 스팸 트랜잭션 처리: Espresso의 시퀀서는 트랜잭션들에 대해 실행을 거치지 않은 채로 시퀀싱을 수행하며, 선입선출 방식이나 비딩을 기반으로 트랜잭션의 순서를 지정하는 Timeboost 방식을 선택하고 있다. 만약 유효하지 않은 트랜잭션이 포함되어 있다면, 실행 계층을 통해 L2 블록에 포함은 되지만 상태값 변화를 발생시키지는 않는 방식으로 대응해야한다. 하지만 이러한 방식은 invalid한 스팸 트랜잭션을 발생시키는 등의 악성 행위를 통해 체인의 부담을 가중시킬 수 있다. 이에 대해 Espresso측에서는 또한 협업 체인의 PBS (Proposer-Builder Seperation) 구조 채택과 데이터 가용성 프로토콜의 고도화를 통해 이를 방지할 것을 권고하고 있다. 다만 이는 Espresso 측이 아닌 실행 계층 등 외부 구성 요소에 의해 해결될 수 있는 문제로, 해결에 상당한 시간과 노력이 요구된다.

• 악의적인 롤업: 롤업 서버는 Espresso 시퀀서가 생성한 블록에서 자신에게 할당된 트랜잭션을 추출해갈 수 있도록 사용자의 트랜잭션에 숫자 형태의 식별자를 추가해 Espresso에 전달한다. 하지만 Espresso 측에서 중복된 롤업 식별자를 차단하는 등 검증 행위를 전혀 수행하지 않기 때문에 각 롤업은 롤업 간 재실행 공격 등을 방지하기 위해 chain ID를 추가로 검사하는 등 부가적인 보호 장치를 따로 구현해야한다.

• Stake Table 관리: Espresso의 HotShot 합의 메커니즘에서는 L1, 즉 이더리움에서 발생하는 밸리데이터의 상태값 변화를 L1에 위치한 시퀀서 컨트랙트를 통해 관리한다. 매우 드문 경우이겠지만, 시퀀서 컨트랙트가 완결되지 않은 상태에서 밸리데이터 상태에 급진적인 변화가 발생할 경우에 대한 리스크 관리가 필요하다. Espresso 측에 따르면 stake table은 아직 구현 과정 중에 있다.

• 시퀀서 동작 실패: 공식 ��서에도 설명되어 있듯이, Gibraltar는 여전히 Nitro 시퀀서를 통해 묶음 트랜잭션을 제출한다. 이는 곧 단일 시퀀서 구조에서 Arbitrum Nitro가 겪었던 시퀀서 구동 중지로 인한 블록 생성 정지 문제를 그대로 계승함을 의미한다. 가급적이면 Espresso 시퀀서가 그대로 L1에 묶음 트랜잭션을 제출하도록 해야 탈중앙적인 특징을 그대로 가져갈 수 있을 것이다.

• 중앙화 리스크: 탈중앙을 표방한다고 하더라도, 공유 시퀀서의 구조에 따라 탈중앙의 정도가 나뉠 수 있다. Gibraltar에서 Espresso 시퀀서는 외부 노드 오퍼레이터인 Blockdaemon에 의해 운영되고 있으며, 각기 다른 지역의 9개 서버에서 구동되고 있다. (링크) 이는 개념 증명 수준의 프로토콜에서 참작될 수 있는 사항으로, 향후 배포될 Espresso 메인넷에서는 충분히 해결될 문제로 보인다. 반면 검열 관련 이슈에 대해서는 구조적으로 잘 해소되어 있는데, 시퀀서 노드가 트랜잭션의 정보를 담은 증명을 레이어 1의 시퀀서 컨트랙트에 제출함으로써 롤업 실행자로 하여금 시퀀서로부터 전달받은 트랜잭션이 전부 실행되었는지 여부를 증명할 수 있도록 설계되어 있다.

3.2 Execution

Gibraltar는 Arbitrum Nitro에 Espresso 시퀀서를 결합시킨 형태이기 때문에, Arbitrum Nitro가 갖고 있는 리스크를 포함하고 있다.

• 중앙화 문제: Arbitrum에는 긴급 상황 발생시 체인의 중요 컨트랙트들을 지연 없이 업그레이드 할 수 있도록 하는 Security Council이 존재하며, 이들은 Arbitrum DAO에 의해 지정된 특수한 개체들이다. Espresso의 Gibraltar 관련 문서에 Security Council에 대한 부분을 명시하고 있지 않으나, Arbitrum Nitro의 구조를 차용한다면 이를 지정할 가능성이 있다. 물론 Gibraltar는 개념 증명(PoC, Proof of Concept) 개념의 테스트넷이기 때문에 이에 대해 논의하기에는 무리가 있지만, Arbitrum의 스택을 실행 계층으로 사용하는 프로젝트가 등장하게 된다면 이들의 거버넌스를 통해 자신만의 Security Council을 지정하게 될 것이며, 사용자들은 프로젝트 측에 대한 신뢰를 부담해야할 것이다.

3.3 Settlement

실행 계층에서 발생한 묶음 트랜잭션에 대한 증명은 이더리움의 Inbox 컨트랙트에, 그리고 Espresso 시퀀서 노드의 합의 결과에 대한 증명은 이더리움의 HotShot 컨트랙트에 저장된다. 트랜잭션에 대한 유효성 검증은 WASM VM에서의 오프체인 연산을 통해 수행된다.

• 사기 증명 구현의 어려움: 사기 증명의 구현 조건은 꽤나 까다로운 편이다. 상태값의 변화를 옵코드(opcode) 단위까지 쪼개 검증하는 연산 방식의 비용이 큰 데에 비해, 빠른 시간 내의 검증을 요구하기 때문이다. Gibraltar는 구조상 묶음 트랜잭션의 제출자와 HotShot에서 발생한 블록 커밋의 제출자가 서로 다르기 때문에, 무결성을 검증하기 위해 블록 커밋에 대한 또다른 사기 증명 메커니즘을 개발해야하는 과제가 남아 있다. 사기 증명 구현에서의 난항은 Gibraltar 뿐만 아니라 대부분의 롤업과 모듈러 체인이 겪고 있는 문제로, 옵티미즘 기반의 체인들도 사기 검증 메커니즘을 구현중에 있다.

3.4 Data Availability

Gibraltar의 현 구현체는 이더리움을 데이터 가용성 계층으로 사용하고 있으며, 장기적으로 Espresso 자체 DA 레이어인 Tiramisu를 직접적 또는 AnyTrust에 간접적으로 적용할 예정이다.

• 악의적인 DA 참여자: 데이터 가용성 프로토콜의 참여자가 의도적으로 L1 시퀀서 컨트랙트로의 DAC 전달을 지연시켜 체인 자체의 사용성을 해칠 수 있다. Espresso는 이에 대응해 DA 참여자와 HotShot 합의에 참여하는 개체를 블록 제안자로 동일하게 설정해 슬래싱을 통한 통제를 제안하고 있다. 하지만 이는 곧 Espresso 시퀀서가 Espresso DA 이외의 데이터 가용성 프로토콜과 결합할 때 불안정성이 발생할 수 있다는 것을 의미한다.

• Espresso 데이터 가용성 계층은 랜덤하게 선택된 DA 위원회에게만 전체 데이터를 전달해 검증시키는 방식을 통해 낙관적으로 데이터 가용성 문제를 처리한다. 하지만 이전에 언급했듯, 문제가 발생하더라도 fallback 메커니즘을 통해 효과적으로 이에 대응할 수 있도록 설계되어 있다. Celestia, Avail 등의 다른 데이터 가용성 프로토콜들과 마찬가지로 Espresso DA도 erasure coding 방식을 사용해 스토리지 노드로부터 전달받은 작은 데이터 조각을 통해 데이터 가용성을 증명할 수 있도록 하는 방식을 취하고 있다. 즉, Espresso DA는 대부분의 경우 랜덤하게 선출된 DA 위원회를 통해 빠르게 데이터 가용성 정보를 제공하고, 실패하는 일부 경우에 대해서는 erasure coding proof를 이용한 방식을 적용하고 있다.

3.5 Conclusion

Espresso는 Arbitrum Nitro, OP Stack 등 다양한 실행 계층을 적용해 테스트넷을 운영해왔으며, 향후 타 데이터 가용성 프로토콜의 지원 등을 통해 완성된 형태의 모듈러 체인을 출시할 것으로 예상된다. 하지만 HotShot 커밋에 대한 사기 증명 메커니즘 구현, 시퀀서의 완전한 탈중앙화, 데이터 가용성 계층 호환성 등의 문제가 해결 과제로 남아있는 것으로 보인다.

4. 케이스 스터디 B: Dymension

Dymension은 공통의 세틀먼트 계층을 롤업에 제공함으로써 롤앱 간의 상호운용성을 제공하고, 롤업 SDK를 통해 앱체인을 쉽게 개발하고 배포할 수 있도록 하는 데에 그 목적을 두고 있다.

세틀먼트 계층인 Dymension Hub는 코스모스 SDK를 기반으로 구성되어 있으며, 텐더민트를 통해 실행한 상태값을 지분증명 기반으로 합의하는 방식으로 운영된다. 특징으로는 IBC와 유사한 롤앱 간 브리지가 존재하며, 인젝티브와 같이 각 앱체인(롤앱) 간 유동성을 공유할 수 있도록 AMM이 Dymension Hub 내에 내장되어 있다는 점이 있다. Dymension은 다양한 DA 계층 호환성과 SDK 기반 롤앱 배포의 용이성을 통해 모듈러 블록체인임을 표방하고 있다.

Dymension의 각 계층은 다음의 참여자에 의해 관리된다.

• Sequencing: RollApp Sequencer

• Execution: Dymension Dymint

• Settlement: Dymension Hub

• Data Availability: Celestia / Avail

마찬가지로 Dymension의 전반적인 구조는 부록에서 추가적으로 설명하겠다.

4.1 Sequencing

• 중앙화 리스크: Dymension의 각 롤앱은 거버넌스를 통해 사용할 시퀀서를 화이트리스팅하여 사용한다. 트랜잭션 처리시 DYM 토큰의 스테이킹량에 따라 사용할 시퀀서가 확률적으로 결정되며, 트랜잭션 처리 결과는 DA 레이어와 Settlement 레이어에 전달된다. 하지만 롤앱 운영 측의 스테이킹량이 사용자에 비해 압도적인 경우 사실상 롤앱 측의 시퀀서에 의해 반 중앙화되어 운영될 가능성이 존재한다. 하지만 Dymension 측은 아비트럼과 같이 세틀먼트 계층을 통한 forced inclusion을 통해 이러한 문제를 일부 해소하고 있다.

• 악의적인 시퀀서: 시퀀서가 의도적으로 트랜잭션의 처리를 지연시킬 가능성도 존재하나, Dymension은 이를 방지하기 위해 특정 시간 내에 트랜잭션을 처리하지 못하면 시퀀서가 스테이킹한 토큰을 슬래싱하는 메커니즘을 구현했다. 또한 트랜잭션이 처리되지 못할시 세틀먼트 레이어를 통해 트랜잭션의 제출을 강제하는 방식을 채택하고 있다. 하지만 여전히 롤앱의 토큰 런칭 등으로 인해 롤앱 측의 스테이킹량에 비해 많은 자금이 모일 경우 오프체인 시퀀서에 의해 사용자의 자금이 탈취 또는 동결당할 가능성이 존재한다.

4.2 Execution

각 롤앱은 Dymint라고 하는 텐더민트 기반의 프로그램에 의해 동작하며, 각 어플의 기능적 요소는 서버라고 불리는 요소에 의해, 블록 생성과 롤앱 간 상호운용성 기능 등은 클라이언트라고 불리는 요소에 의해 처리된다. 롤앱의 실행 단계에서는 합의가 발생하지 않으며, Dymint로부터 상태루트를 전달받은 Dymension Hub가 합의를 전담하고 있다.

• Faulty Data Publication: Dymint는 데이터 가용성 계층과 세틀먼트 계층에 각각 자신의 상태값과 상태 루트, 그리고 데이터 가용성 계층에 대한 참조값을 제출한다. 트랜잭션을 배열하는 시퀀서와 밸리데이터는 스테이킹을 통해 연산의 정합성을 보증하는 반면, 실행 단계에서는 이러한 담보를 찾아볼 수 없다. 밸리데이터에 의해 준-비관적인 검증이 이루어지지 않는 한, 롤업 SDK를 수정해 특정 주소를 검열하거나 배제하는 백도어가 구현될 가능성이 있다. 또한 검증 과정에 챌린지 기간이 설정되어 있으므로, 그 안에 챌린지가 이루어지지 않으면 롤앱 내 하드포크가 발생하거나 사용성에 큰 문제가 발생할 수 있다.

• 악의적인 롤앱: Dymension은 롤앱의 보다 쉬운 개발을 위해 롤앱의 기본적인 기능이 구현된 SDK를 제공하고 있다. 하지만 롤앱의 핵심 기능에 대해 변형이 발생했는지 여부 등을 탐지할 무결성 검사 등이 이루어지지 않으면 롤앱이 의도하지 않았거나 악의적인 동작을 수행할 수 있다. 롤앱이 컨트랙트보다는 체인에 더 가까운 만큼, 사용자들은 자신의 자산을 동결시키거나 잃게 만들 백도어나 리스크를 찾는 데에 더 어려움을 겪을 수 있다.

4.3 Settlement

Dymension 롤앱은 옵티미스틱 롤업으로, Arbitrum과 같이 사기 증명을 통해 트랜잭션을 검증한다. 챌린지가 시작되면, 세틀먼트 계층 내 롤앱 가상머신이 해당 트랜잭션을 재실행해서 상태값의 정합성을 검증한다. 특이한 점은, permissionless fraud proof를 통해 누구나 챌린지를 걸 수 있도록 설계되었다는 점이다.

Dymension의 공식 문서에 따르면 Dymension의 사기 증명 시스템은 현재 테스트 단게에 있으며, EVM 롤앱에 대해서만 개발이 이루어져 있습니다.

• 사기 증명 시스템에 대한 DoS 공격 가능성: Permissionless fraud proof는 누구나 시스템에 대해 챌린지 해결을 요구할 수 있도록 하므로, DoS 공격에 대비해 강건하게 설계되어있어야 한다. Arbitrum 또한 Permissionless fraud proof인 BOLD를 구현했지만 여러 문제로 실제 메인넷에 적용하지는 못한 상황이다.

• 짧은 챌린지 기간: 현재 Dymension 메인넷의 챌린지 기간(dispute period)은 약 12만 블록으로 설정되어 있는데, Dymension이 이전 테스트넷에서 [~20000 TPS](https://docs.dymension.xyz/learn/rollapps/dymint/#:~:text=RollApps deployed to the 35-C network were able to maintain an average latency period of 0.2 second with max TPS of ~20%2C000 transactions.)(Transaction Per Second, 초당 트랜잭션 수)를 기록한 것을 고려하면 그 기간이 짧은 편이다. 사용자가 트랜잭션 처리의 이상을 감지하고 챌린지를 걸 수 있을 만큼의 충분한 기간이 필요하다.

• 경제적 리스크: Dymension의 세틀먼트, 그리고 시퀀싱에 대한 신뢰 기반은 위 과정의 참여자들이 DYM 토큰을 스테이킹함으로써 달성된다. 하지만 재단 지갑의 해킹이나 네트워크 불안정성으로 인해 토큰의 가격이 급락할 경우, 경제적 가치를 기반으로 하는 체인의 안전성이 훼손될 우려가 있다.

4.4 Data Availability

Dymension은 각 롤앱의 선택에 따라 체인의 상태값을 Celestia 또는 Avail에 제출할 수 있도록 한다. Celestia와 Avail 모두 앞서 언급한 Espresso DA와 같이 삭제 코딩 증명(erasure coding proof)을 사용해 일부의 합의로 데이터 가용성을 증명할 수 있도록 하는 방식을 취한다.

• 데이터 가용성 계층의 완결성: Celestia와 Avail의 경우 각각 하나의 체인으로 동작하며, 데이터의 완결에 15초와 20초 가량이 소요된다. 하지만 앞서 언급했듯이, Dymension의 챌린지 기간은 상대적으로 짧은 편이다. 데이터 가용성 계층이 완결되지 않은 상황에서 챌린지가 발생할 경우, 예상하지 못한 동작이 발생할 수 있음에 유의해야한다.

4.5 Conclusion

Dymension은 각 어플리케이션이 체인 단위로 배포될 수 있도록 함으로써 소규모의 어플리케이션이 낮은 비용으로 세틀먼트 계층을 제공받아 빠르게 트랜잭션을 처리하는 데에 그 의의를 두고 있다. 다만 각 롤앱이 시퀀서를 화이트리스팅하고, 세틀먼트 레이어에 상태 루트를 제출하는 등 롤앱의 사용성과 보안이 롤앱 단위로 분산된 형태를 취하고 있다. 따라서 Dymension 롤앱의 사용자는 해당 롤앱 노드와 참여 시퀀서의 스테이킹량 등을 적극적으로 확인하고, 주기적으로 사기 증명을 통해 프로토콜의 안전에 기여해야 한다.

5. 케이스 스터디 C: Eclipse

Eclipse는 Solana VM 실행환경을 통해 빠른 트랜잭션 처리 속도와 동시에 이더리움 수준의 보안을 지원하는 것을 목표로 하는 이더리움 레이어2 프로토콜이다.

Eclipse는 아래와 같은 구성요소를 포함하고 있다.

• Sequencing: Eclipse Sequencer

• Execution: Solana VM / Neon EVM

• Settlement: Ethereum

• Data Availability: Celestia

이는 현재까지의 모듈러 블록체인 중 가장 모듈러한 구조라고 할 수 있으며, Eclipse 팀 또한 이를 강조하고 있다.

5.1 Sequencing

• 중앙화 및 검열 리스크: 현재 Eclipse는 자체적으로 운영하는 단일 시퀀서를 통해 동작하고 있으며, 이는 중앙화 시퀀서의 전형적인 문제들을 수반한다. 시퀀서와 블록 생성자가 함께 동작하므로, 시퀀서가 멈출 경우 Eclipse의 블록 생성 또한 멈추게 된다. 아비트럼 등 일부 롤업과 같이, Eclipse는 이 문제에 대한 해결책으로 L1(이더리움)을 통한 강제적 포함(forced inclusion) 메커니즘을 제시하고 있다. 하지만 강제적 포함 메커니즘이 동작한다고 하더라도, 시퀀서가 선택적으로 트랜잭션을 제출해 이들을 프론트런하는 등의 악의적인 행위를 취할 가능성이 존재한다. 이에 대해 Eclipse 측은 장기적으로 시퀀서를 탈중앙화시킬 계획을 갖고 있다고 언급하고 있다.

5.2 Execution

Eclipse의 가장 큰 특징은 Solana VM과 병렬 EVM으로 구성된 실행 환경이라고 할 수 있다. Eclipse는 Solana의 병렬처리 속도, 상태값 크기 관리, 수수료 관리 메커니즘 등을 통해 보다 나은 사용성을 제공할 수 있음을 피력하고 있다. 또한 Neon EVM을 통해 Solidity로 작성된 컨트랙트를 Solang 컴파일러를 통해 SVM 바이트코드로 변환해 배포할 수 있도록 하고 있다.

• SVM과 EVM 간 호환성 문제: Solidity로 작성된 코드를 SVM 바이트코드로 변환해 솔라나에 배포하는 것은 매우 혁신적이지만, 호환성에 관련해 여러가지 문제를 수반한다.

  1) Solidity 업데이트: Solang은 근본적으로 솔리디티와 동일하게 동작해야 한다. 업데이트에 따라 없어지거나 새로 생기는 기능에 대해 완전하게 대응해야 하며, 그렇지 못할 경우 의도치 않은 버그를 발생시킬 수 있다.

  2) EVM 호환성: Eclipse는 Neon EVM이라는 병렬 EVM을 통해 SVM으로의 컨트랙트 배포를 지원한다. Neon EVM은 이더리움과 솔라나 환경 사이의 교두보 역할을 하는데, 이들의 너무나도 다른 메모리 관리와 연산 방식때문에 기술적 어려움을 겪을 수 밖에 없다. 다행히 Neon EVM 측은 꾸준한 보안 감사를 통해 취약점을 색출해내고 있는데, 가장 최근에 공개된 Neodyme 측의 보안 감사 보고서를 보면 다수의 이슈들이 EVM 표준 스펙과의 불일치 또는 메모리 관리 관련 문제인 것을 확인할 수 있다. Eclipse가 Neon EVM에 EVM 트랜잭션의 처리를 의존하고 있는 만큼, EVM 트랜잭션 처리시 호환성 관련 버그가 발생할 수 있음에 유의해야한다.

5.3 Settlement

Eclipse 노드는 검증 브리지(validating bridge)라는 이더리움 컨트랙트에 주기적으로 상태값을 제출하는데, 성능 향상을 위해 글로벌 상태 루트가 아닌 트랜잭션으로 인해 발생한 상태값의 변화만을 제출하는 방식을 선택했다.

• 악의적인 노드: Eclipse의 노드 운영자는 묶음 트랜잭션에 대한 증명을 제출하는 릴레이어의 악의적인 동작을 검열하기 위해 적극적으로 챌린지에 참여해야 하는데, 아직 노드 운영자에 대한 인센티브나 스테이킹 필요 여부 등이 공개되지 않았다.

5.4 Conclusion

Eclipse가 계획한 구조가 메인넷 배포 이전에 완성된다면 이상적인 구조와 성능을 가진 모듈러 블록체인으로 자리잡게 될 것이다. 하지만 시퀀서의 탈중앙화, Eclipse 노드에 대한 인센티브 모델 구현, RISC Zero를 통한 영지식 증명의 구현 등이 아직 과제로 남아있는 것으로 보인다.

6. Key Insights: Overview of Risks

6.1 미성숙한 생태계

모듈러 생태계를 구축하고 있는 각 프로젝트들은 보안 리스크에 대해 깊게 고려하고 있는 것을 확인할 수 있습니다. 하지만 각 계층이 통합되었을 때의 리스크에 대한 연구는 아직 부족해보입니다. 모듈러 구조를 표방하는 대부분의 체인들은 모듈러 구조에서 발생할 수 있는 미식별된 리스크를 피하기 위해 기존의 구조에 데이터 가용성 계층만을 적용하는 등 매우 보수적인 접근 방식을 취하고 있습니다.

6.2 여전히 남아있는 중앙화 문제

일부 모듈러 구조들은 각기 다른 운영 개체와 실행 환경을 가진 계층들을 통합하기 위해 중앙화된 개체를 두고 실행 결과나 증명을 다른 계층에 전달하는 방식을 취하고 있다. 이러한 구조는 오히려 실패 지점을 다수로 만들기 때문에 체인의 운영을 관리하는 데에 복잡도를 높일 수 있다. 탈중앙화된 구조라면 일부 개체가 동작에 실패해도 정상적인 동작이 가능해야 하는데, 중앙화된 다수의 개체에 의존하는 방식은 하나라도 동작에 실패하면 체인 전체의 동작을 불완전하게 만들게 될 것이다.

6.3 데이터 가용성 프로토콜 관련 리스크

데이터 가용성 계층은 체인에 무결성과 확장성을 제공해주기 때문에 모듈러 구조에서 가장 핵심적인 부분이라고 할 수 있다. 하지만 데이터 가용성 프로토콜들은 erasure coding proof와 같이 암호학적 증명에 기반하고 있기 때문에 개발에 어려움이 크다. 이를 반증하듯 모듈러 구조를 구성하는 다른 계층에 비해 데이터 가용성 프로토콜의 수는 매우 적은 편이다.

Erasure coding의 개념이 학계에 등장한지는 꽤 오랜 시간이 지났지만, 블록체인에 적용된지는 그리 오래되지 않았기 때문에 의도치 않은 동작이 발생할 가능성을 배제할 수 없다. 또한 erasure coding은 큰 사이즈의 데이터를 검증하는 데에 적합하지 않다고 알려져 있기 때문에, 큰 블록 사이즈를 가진 미래의 실행 환경이나 복잡한 사기 증명을 위해 사용하는 것은 적합하지 않을 수도 있다.

데이터 가용성 프로토콜이 오작동할 경우, 같은 프로토콜 위에서 동작하는 다수의 모듈러 체인들이 동시에 데이터 가용성 문제를 겪을 수 있다. 이에 대해서 데이터 가용성 프로토콜들은 문제 발생 시 이더리움으로 즉시 데이터를 제출하는 fallback 메커니즘을 구상하고 있으나, 이는 아직 개발 단계에 있는 방식이다.

게다가 데이터 가용성 프로토콜의 보안은 각 노드에 스테이킹된 토큰의 경제적 가치에 기반하는데, 이는 곧 각 데이터 가용성 프로토콜의 보안이 연결된 프로젝트의 활성화 정도와 크게 연관되어있다는 것을 의미한다. 따라서 데이터 가용성 계층에는 집중화 현상을 피해 적당한 수의 프로토콜들이 자리잡아야 할 것이다.

7. Looking Ahead

7.1 다양한 증명 시스템 출시 예정

과거에는 모듈러 블록체인 프로젝트의 증명 시스템이 단순했으며, 일반적으로 실행을 위해 optimistic 증명 또는 zk-증명을 사용니다. 그러나 최근의 추세는 성능 향상과 전반적인 시스템 보안 강화를 목표로 하는 증명 시스템의 접근 방식이 다양화되고 있다.

예를 들어, 옵티미즘은 fault-proof 시스템 도입하여 증명 시스템을 모듈화하고 잠재적으로 보안 강화를 위해 zk를 통합할 수 있도록 하고 있다. 또한 risczero 및 ZKM과 같은 프로젝트에서는 하이브리드 증명 시스템의 구현을 용이하게 하기 위해 zkVM 인프라를 제공하고 있다.

7.2 새로운 보안 공유 인프라

모듈러 블록체인의 전반적인 보안에 관한 주요 우려는 다른 인프라의 보안에 대한 의존성에서 비롯된다. 시스템의 한 부분(예: 데이터 가용성 레이어)에 장애가 발생하면 롤업의 작동이 중단될 수 있다. 이러한 구성 요소는 다른 모듈러 블록체인에서도 활용되기 때문에 추가적인 문제가 발생할 수 있습니다.

이러한 위험을 완화하기 위해 프로젝트는 두 가지 주요 전략을 채택하고 있다. 첫 번째는 리스테이크된 이더리움과 바빌론의 비트코인 체크포인팅을 활용하는 EigenDA와 같이 경제적 이해관계가 높은 인프라를 활용하는 것이다. 두 번째 접근 방식은 모듈러 블록체인, 특히 일부 롤업을 설계하여 사용 중인 데이터 가용성 계층에 장애가 발생할 경우 다른 데이터 가용성 계층을 자동으로 활용하는 것이다. 이와 같이 보안을 강화할 수 있는 인프라도 빠르게 발전을 이루고 있기 올해에는 이 분야에서 더욱 흥미로운 발전이 있을 것으로 예상된다.

*APPENDIX는 docs의 표현을 최대한 정확하게 전달하고자 영문으로 작성되었습니다.

부록 A. Gibraltar의 구조

Gibraltar는 2024년 1월에 출시한 Espresso 시퀀서의 4번째 테스트넷이며, Arbitrum Nitro 위에서의 적용을 실험하는 데에 그 목적을 두고 있다.

출처: Arbitrum Nitro integration - Espresso Sequencer

트랜잭션의 처리 과정은 다음과 같다.

1. 트랜잭션 제출

• 사용자와 디앱은 Arbitrum Nitro의 RPC 노드에 트랜잭션을 제출한다.

1. 시퀀싱

• Nitro 노드는 트랜잭션의 순서를 매기기 위해 Espresso 시퀀서에 트랜잭션을 전달한다.

• Espresso 시퀀서는 트랜잭션의 순서를 매기고, 네임스페이스 머클 트리 구조를 이용해 블록을 생성한다.

• 각 Espresso 시퀀서 블록은 HotShot을 통해 이더리움에 제출된다.

1. 블록 맵핑

• Espresso 시퀀서 블록은 Arbitrum Nitro 블록과 1대1 매핑이 이루어진다.

1. 블록 생성

• 새로운 Espresso 시퀀서 블록이 생성되면, Nitro 노드는 순서가 매겨진 트랜잭션을 포함하는 Nitro 블록을 생성한다.

• Espresso 시퀀서는 시퀀서 블록의 헤더와 Nitro 블록을 연결하기 위한 네임스페이스 머클트리 증명을 포함하고 있는 EspressoBlockJustification을 생성한다.

1. 검증

• 시퀀싱된 트랜잭션과 HotShot 증명을 입력값으로 받기 위해 수정된 WASM 밸리데이터를 검증에 사용한다.

• 밸리데이터는 Nitro 블록이 시퀀싱된 트랜잭션과 일치하는지를 검증한다. 유효하지 않은 트랜잭션이 블록에 포함되어있을 수 있으나, 상태값의 변화는 발생시키지 않는다.

1. 데이터 가용성

• 이더리움이 Nitro 블록에 대해 온체인 데이터 가용성을 제공한다.

• 추후 Espresso 시퀀서의 Tiramisu 데이터 가용성 프로토콜이 사용될 예정이다.

1. 선승인 (Preconfirmation)

• 사용자는 이더리움 블록이 완결되기 이전에 노드로부터 업데이트된 Nitro의 상태값을 요청하고, 이를 빠른 승인을 위해 사용할 수 있다.

부록 B. Dymension의 구조

Dymension은 탈중앙화된 위임지분증명을 사용하는 L1 블록체인이며, 롤앱에 보안, 상호운용성, 그리고 유동성을 제공하는 특징이 있다.

B.1 트랜잭션 처리 과정

1. 사용자가 시퀀서에 트랜잭션을 제출한다.

2. 시퀀서는 트랜잭션을 실행, 순서를 매기고 묶음으로 만든다.

3. 생성된 블록은 풀노드에 전달되어 온체인에 제출된다.

4. 풀노드는 상태 루트를 네트워크 데이터와 비교해 검증한다.

5. 시퀀서는 Dymension Hub에 새로운 상태 루트를 제출한다.

6. Dymension Hub는 상태 루트를 추적하고 유효하지 않은 상태값 변화를 취소할 수 있다.

출처: Dymint | Dymension Docs

B.2. 구성 요소

롤앱 구조는 몇가지의 주요 구성요소로 나뉘어있으며, 각자 자신의 고유적인 기능을 포함하고 있다.

B.2.1 시퀀서

시퀀서는 RPC 엔드포인트를 통해 제출된 트랜잭션의 검증, 순서 배치, 그리고 실행을 맡는다. 시퀀서는 트랜잭션 처리 이후 즉각적인 상태값 업데이트 내용을 제공하며, 확인 가능한 간격으로 트랜잭션을 묶어 블록을 생성한다. 이에 더해, 시퀀서는 블록을 다른 풀노드와 데이터 가용성 네트워크에 제출한다. 마지막으로, 새로운 상태 루트를 Dymension Hub에 제출한다.

시퀀서의 실행 로직은 Dymension의 RDK (RollApp Development Kit)를 통해 구축할 수 있는데, RDK는 코스모스 SDK의 포크로 롤앱이 맞춤형 기능을 구현할 수 있다.

Dymension RDK는 롤앱이 개발해 통합시킬 수 있도록 대부분의 코스모스 SDK 모듈을 지원한다. 코스모스 SDK와 IBC로부터 계승한 주요 모듈로는 Bank (토큰 전송 기능), Gov (온체인 프로포절 및 투표 기능), Upgrade (소프트웨어 업그레이트 지원 기능), IBC (브릿징 프로토콜) 등이 있다.

B.2.2 풀노드

풀노드는 시퀀서로부터 블록을 전달받는데, gossip을 통해 짧은 지연시간을 거쳐 상태값을 업데이트한다. 풀노드는 데이터 가용성 네트워크에 블록 데이터를 요청해 네트워크의 데이터와 롤앱의 상태 루트를 검증할 수 있다.

B.2.3 데이터 가용성 네트워크

데이터 가용성 네트워크는 시퀀서가 블록 데이터를 제출하는 탈중앙 네트워크이다. 풀노드는 상태 루트를 검증하기 위해 네트워크로부터 데이터를 불러올 수 있다. 데이터 가용성 네트워크는 장기간의 데이터 가용성과 무결성을 보장한다. Dymension은 현재 자체 DA를 사용하고 있으나, 다른 altDA를 지원할 예정이다.

B.2.4 Dymension Hub를 통한 합의

Dymension의 합의는 Dymension Hub를 통해 이루어진다. 롤앱은 합의를 Dymension에 아웃소싱하고 블록을 옵티미스틱하게 생성할 수 있다. Dymension Hub는 시퀀서로부터 업데이트된 옵티미스틱 상태 루트를 관장한다. 사기 증명을 통해 상태값의 변화가 유효하지 않은 것으로 판별되면, 롤앱의 상태 변화를 취소시킬 수 있다. Dymension Hub는 네트워크로부터 데이터를 불러와 사기 증명을 검증할 수 있으며, 롤앱과 라이트 클라이언트 사이에 무신뢰 기반 브릿징 기능을 제공한다.

B.3 레퍼런스

• Dymension RDK | Dymension Docs

• dymensionxyz/dymension: Dymension Hub

• dymensionxyz/dymint: Sequencing Engine for Dymension RollApps