[탈중앙화 시퀀서 시리즈] #2. 탈중앙화 시퀀서 프로젝트

Published in

Decipher Media ｜디사이퍼 미디어

32 min readNov 25, 2023

--

Disclaimer: 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 탈중앙화 시퀀서를 주제로 Weekly Session에서 발표한 내용을 바탕으로 합니다. 본 아티클은 탈중앙화 시퀀서의 필요성 및 구성요소, 탈중앙화 시퀀서 프로젝트, 공유 시퀀서 등에 대한 내용을 다루고 있습니다. 이 보고서에 포함된 어떠한 내용도 투자 조언이 아니며, 투자 조언으로 해석되어서도 안 됩니다.

시리즈

Author

이현우, 장재석 of Decipher
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 디사이퍼 미디어팀

1. 탈중앙화 시퀀서 프로젝트

Metis, Astria, Espresso Systems, Fairblock, Radius, Taiko, Madara, Anoma 이렇게 총 8개 프로젝트에 대해 분석했습니다.

1.1. Metis

Metis는 이더리움 레이어 2 솔루션으로, Metis에서 개발 중인 PoS Sequencer Pool은 탈중앙화 시퀀서 구조에 가장 기본적인 형태를 띱니다. Metis만을 위한 탈중앙화 시퀀서를 구축하는 것을 목표로 개발 중입니다. Metis의 특징적인 구성 요소로는 어드민, 메티스 노드, PoS 노드가 있으며 각각의 역할은 아래와 같습니다.

1. 어드민: 잠긴 노드들의 관리 및 아래의 역할을 맡음

잠재적인 시퀀서 화이트리스팅
단일 노드 스테이킹 물량의 상한선 설정
블록 생성에 따른 보상 조정

2. 메티스 노드(시퀀서): 아래 세 가지로 구성됨

레이어 2 Geth: 트랜잭션 시퀀싱 및 블록 조합 담당
Adapter module: PoS 컨센서스 레이어와의 상호작용 담당
Batch submitter(Proposer): 배치 생성 및 레이어 1에 제출 담당

3. PoS 노드: 블록을 제출한 리더 노드가 올바른지에 대한 검증과 리더 노드가 제출한 블록에 대한 검증 등의 역할을 맡으며, 아래 세 가지 레이어와 상호작용함

레이어 1: 락업과 검증인 보상을 담당하는 레이어
컨센서스 PoS 레이어: 시퀀서 셋 관리와 블록 합의가 이루어지는 레이어
메티스 레이어: 에포크마다 블록 생성자를 선택하고 교체하는 레이어

일반적인 롤업의 작동 방식은 사용자가 롤업에 트랜잭션을 제출하면, 시퀀서가 레이어 2 블록 생성과 연산을 진행하고, 이 과정을 레이어 1에서 검증합니다. Metis의 경우도 이와 다를 것이 없지만 시퀀서를 탈중앙화하기 위한 리더 노드 선정 과정이 추가되었습니다. 간단한 작동 방식은 아래와 같습니다.

에포크마다 시퀀서 노드 중 리더 노드를 선정함
사용자는 해당 리더 노드에게 트랜잭션을 제출함
리더 노드는 트랜잭션으로 배치 / 블록을 구성함
참여 중인 시퀀서 ⅔ 이상이 동의하면 리더 노드의 배치 / 블록이 통과됨
통과된 배치 / 블록은 레이어 1에 제출함

시퀀서 노드들은 텐더민트 합의방식을 기반으로 제출된 배치 / 블록에 대한 합의를 진행합니다. 일반 사용자도 Metis 토큰을 메티스 레이어에 스테이킹 후 시퀀서에게 투표권을 위임해서, 시퀀서의 수익을 일부 분배받을 수 있다는 점이 특징입니다.

또한 현재는 최대 스테이킹 가능 물량, 블록 보상 등을 어드민이라는 중앙화된 관리자가 관리합니다. 이는 추후 거버넌스 토큰을 이용한 자체 거버넌스 투표로 대체될 예정입니다. 탈중앙화 시퀀서가 자체 거버넌스 토큰의 사용처를 제공하는 모습을 볼 수 있습니다.

1.2. Astria

Astria는 모든 lazy rollup들의 트랜잭션들을 한 번에 처리하는 탈중앙화 시퀀서를 구축하는 것을 목표로 하는 프로젝트입니다. 여기서 lazy rollup이란 이더리움 롤업 구조의 일종으로 Astria가 처음 제시한 개념입니다.

Lazy rollup이 아닌 일반적인 롤업에서는 레이어 2에서 블록 생성과 트랜잭션의 실행이 일어난 후, 블록을 데이터 가용성 레이어에 저장하는 작동 방식을 갖습니다. 반면, lazy rollup에서는 데이터 가용성 레이어에 블록이 생성되면, lazy rollup에서 이를 받아오고, 트랜잭션을 실행한 후, 상태를 업데이트하는 작동 방식을 갖습니다.

Lazy rollup은 실행을 제외한 시퀀싱 과정(블록 생성과 데이터 가용성 레이어로의 제출)을 Astria와 같은 탈중앙화 시퀀서에 맡기기 때문에 자체 시퀀서가 필요하지 않습니다. 즉 Lazy rollup은 오직 데이터 가용성 레이어에서 받아온 블록의 실행만을 담당하게 되는, 이름 그대로 가장 활동성이 적은 롤업 구조입니다. 단순하게 생각하면 블록체인의 네 가지 기능인 합의 / 연산 / Settlement / 데이터 가용성 기능 중 연산만을 담당하는 레이어라고 볼 수 있습니다.

<Lazy rollup의 Execution> 출처: Celestia Forum

Astria의 특징적인 구성 요소로는 Astria 시퀀서 노드, 데이터 가용성 레이어(셀레스티아), 롤업(Geth), Composer, Conductor, Relayer가 있으며 각각의 역할은 아래와 같습니다.

Astria 시퀀서 노드: 블록 생성 노드로, 블록 순서를 결정함
데이터 가용성 레이어(셀레스티아): 블록을 저장하고, 데이터 가용성을 보장함
롤업(Geth): 레이어 2 롤업으로 Astria에 참여함
Composer: 쓰기 경로 미들웨어(Write path middleware)로, 롤업 트랜잭션을 시퀀서 트랜잭션으로 변환함
Conductor: 읽기 경로 미들웨어(Read path middleware)로, 시퀀서가 구성한 블록(meta block)에서 단일 롤업에 대한 부분을 필터링함
Relayer: 블록을 시퀀서에서 롤업으로 전파하고 데이터 가용성 레이어에 블록을 제출함

추가로 롤업이 Astria 네트워크에 들어오기 위해서는, 롤업 노드가 Composer에 트랜잭션을 작성하고, Conductor에서 블록을 읽어올 수 있어야 합니다.

위에서 언급한 것처럼 Astria는 lazy rollup들에 대한 시퀀싱을 담당하기 때문에, Astria를 이용하는 트랜잭션의 흐름은 일반적인 롤업에서의 흐름과는 다릅니다.

Astria를 이용한 트랜잭션의 흐름은 Write Path와 Read Path로 나누어져 진행됩니다. Write Path에서 Astria 탈중앙화 시퀀서가 사용자의 트랜잭션들로 블록을 만들어 데이터 가용성 레이어에 게시한 뒤에, Read Path에서 lazy rollup들이 게시된 블록을 읽어와 실행합니다. 작동 방식을 정리하면 아래와 같습니다.

Write Path

사용자가 Metamask, Foundry 등의 툴을 사용해서 Geth 롤업에 연결하고 트랜잭션을 제출함
Composer가 롤업 멤풀에서 펜딩 트랜잭션을 가져옴
Composer는 이 트랜잭션을 Astria 트랜잭션으로 래핑 후 Astria의 CometBTF 멤풀에 제출함
Astria 네트워크는 리더 노드를 선정함
리더 노드는 하나의 크로스롤업 블록(meta block)을 생성함
시퀀서들에 의해 합의가 완료된 블록은 Relayer가 Conductor, 데이터 가용성 레이어로 전달함

→ 블록생성시간은 Astria에서 1초 이내, 셀레스티아에서 11초 이내임

Read Path

7. 각 롤업은 Conductor에서 변환된 자신의 인스턴스를 실행함

8. 필터링된 블록은 롤업으로 전달 후 실행됨

시퀀서 노드들의 합의 방식으로 DPoS와 PBFT가 결합된 텐더민트의 포크인 CometBFT를 사용합니다. 추가적으로 lazy rollup들은 Astria와 셀레스티아에서의 블록생성시간 차이를 이용해서, Astria 리더 노드가 블록을 구성하면 셀레스티아에 저장되기 전에 블록을 먼저 받아올 수 있습니다. 즉 Read Path에 앞서서 Write Path 과정 중에 블록을 먼저 수신할 수 있습니다.

Lazy rollup이 위의 방법으로 먼저 수신한 블록은, 수신한 블록의 트랜잭션 순서대로 셀레스티아에 저장될 것이라는 약한 확정(soft confirmation)을 줍니다. 이를 통해 사용자에게 실행될 트랜잭션을 미리 알려 줄 수 있으며, 이는 더 나은 사용자 경험을 제공합니다.

1.3. Espresso Systems

Espresso Systems도 Astria와 마찬가지로 lazy rollup들을 대상으로 하는 탈중앙화 시퀀서 프로젝트입니다. 따라서 Astria의 구성요소, 작동방식과 큰 차이가 존재하지는 않습니다. 하지만 Espresso Systems만의 특징이 크게 세 가지 존재합니다.

1. 시퀀서들의 합의 방식과 데이터 가용성 레이어의 차이

독자적인 합의 방식인 HotShot을 이용함
독자적인 데이터 가용성 솔루션인 Tiramisu를 이용함
Tiramisu는 Savoiardi, Mascarpone, Cocoa라는 세 가지 데이터 가용성 레이어를 병렬적으로 운영함

2. Sequencer Contract의 존재

Sequencer Contract는 레이어 1 상의 컨트랙트로, HotShot의 합의를 검증하고, 상태 체크포인트를 기록함
롤업이 블록을 실행 후 레이어 1 상의 롤업 컨트랙트로 state root를 제출하면 블록의 내용을 한번 더 검증할 수 있음

3. 시퀀서 선정 방식의 차이

시퀀서들은 아이겐레이어 리스테이커의 신청을 받아 선정됨

Espresso Systems의 특징적인 구성 요소로는 HotShot, Tiramisu, Rollup REST API, Sequencer Contract, Networking Layer가 있으며 각각의 역할은 아래와 같습니다.

1. HotShot

자체적으로 개발한 합의 프로토콜로 낙관적인 응답성을 유지하면서, 노드의 동적 참여를 가능하게 하는, HotStuff를 PoS로 확장한 방식임

아래 특징들을 바탕으로 속도적 이점을 가짐

최적의 상황에서 시퀀서 간의 통신이 선형 복잡도를 가져서 시퀀서의 수를 확장하기 쉬움
네트워크의 지연을 기다리지 않고 낙관적으로 반응함

2. Tiramisu

HotShot 노드에 의해 실행되는 데이터 가용성 솔루션으로 HotShot의 속도적 이점을 그대로 가짐

보안성과 속도의 상충 관계에 따라 아래 세 가지 개별 레이어가 병렬적으로 이루어지는 구조임

Savoiardi: 이더리움과 유사한 보안을 제공하지만 느린 속도
Mascarpone: 중간 보안성과 속도를 가지며, 80% 이상의 Committee가 뇌물을 받지 않는다면 효율적인 데이터 복구를 보장
Cocoa: 보안적으로 중앙화된 주체를 신뢰해야 하지만 데이터 분산 및 검색을 가속화

3. Rollup REST API: 롤업이 Espresso Systems와 연결하는 데 사용됨

4. Sequencer Contract

5. Networking Layer

HotShot에 참여하는 노드와 Tiramisu 데이터 가용성 레이어 노드들 간의 트랜잭션과 합의 메시지의 통신이 일어남

CDN을 사용하여 낮은 대기 시간과, 노드들 간의 효율적인 정보 라우팅을 가능하게 함

<Espresso Systems 작동 개요> 출처: Espresso Systems

Espresso Systems의 간단한 작동 방식은 아래와 같습니다.

사용자가 레이어 2에 트랜잭션을 전달함
레이어 2가 트랜잭션을 시퀀서 노드들에게 전달함
HotShot에서 리더 노드를 선발해서 블록을 구성함
리더 노드는 다른 시퀀서들의 동의(QC 인증)와 데이터 가용성 노드들의 인증을 받고 블록을 확정함
레이어 2에 블록을 전달하고 레이어 1의 Sequencer Contract로 블록에 대한 인증과 블록을 검증할 수 있는 QC를 전송함

<Espresso Systems 트랜잭션 흐름> 출처: Espresso Systems

Astria와 같이 lazy rollup들을 대상으로 하는 탈중앙화 시퀀서 프로젝트이기 때문에 리더 노드가 블록을 구성한 직후 사용자에게 데이터 가용성 레이어에 저장될 블록을 먼저 전달해서 약한 확정을 줄 수 있습니다. 이는 더 나은 사용자 경험을 제공합니다.

1.4. Fairblock

Fairblock도 Astria, Espresso Systems와 같이 lazy rollup들을 대상으로 하는 탈중앙화 시퀀싱 프로젝트입니다. Fairblock 시퀀서가 블록을 생성해서 데이터 가용성 레이어 위에 올리면 lazy rollup들이 이를 받아와서 실행합니다.

다른 탈중앙화 시퀀서 프로젝트와 다른 Fairblock만의 특징은 유저가 트랜잭션을 제출할 때 트랜잭션을 암호화하도록 해서 시퀀서의 검열 가능성을 제한한 것입니다. 또한 FairyRing이라는 독자적인 코스모스 앱체인을 구축해서 FairyRing 위에서 시퀀싱과 트랜잭션의 복호화가 일어나도록 했습니다.

Astria, Espresso Systems와 같은 lazy rollup들을 대상으로 하는 탈중앙화 시퀀서와 비교했을 때 구성 요소에 큰 차이는 없습니다. 하지만 사용자의 트랜잭션을 복호화하는 과정이 포함돼서 작동 방식이 약간 달라집니다. 아직 완벽히 구현된 것은 아니지만 Fairblock에서 구현하고자 하는 탈중앙화 시퀀서의 작동 방식을 간단히 정리하면 아래와 같습니다.

in block n

사용자는 트랜잭션을 암호화해서 코스모스 앱체인인 Fairyring에 전달함
FairyRing의 시퀀서 노드들 중 리더 노드를 선정함
리더 노드가 암호화된 트랜잭션으로 블록을 형성하고 합의를 거쳐 순서를 확정함

in block n+1

FairyRing의 검증인 들은 n번 블록의 암호화된 트랜잭션을 해독하기 위한 분할된 키인 keyshare를 n+1블록에 제출함
임계값 이상의 keyshare를 받으면 이들을 바탕으로 복호화 키를 생성함
이 복호화 키를 이용해서 n번 블록에 포함된 암호화된 트랜잭션들을 복호화함
릴레이어가 이 블록을 셀레스티아 같은 데이터 가용성 레이어로 전달함
롤업은 이 블록을 읽고 실행함

과정에서 보이듯 현재 계획된 작동 방식에서는 n번 블록에 제출된 트랜잭션이 n+1번 블록에서 복호화되어 실행되는 구조로 한 블록의 지연이 존재합니다. Fairblock에서는 추후 ABCI++의 투표 확장 기능을 사용해서 이 지연을 완벽히 제거할 수 있을 것이라고 합니다.

Fairblock의 경우 지금은 코스모스 내의 앱체인들만을 위한 자체 PEP cosmos SDK 모듈을 제공해서, 이를 사용하는 앱체인들에 대한 트랜잭션의 암호화와 해독에 집중하고 있습니다. 합의, 블록 생성, 실행 모두 Fairblock이 아닌 각 앱체인의 검증인들이 담당하며 Fairblock이 시퀀싱 과정에 직접적으로 영향을 미치지 않습니다. 아래 사진은 Fairblock이 지금 작동되는 방식이고, 탈중앙화 시퀀싱에 대한 내용은 존재하지 않습니다.

하지만 추후 탈중앙화 시퀀서로 나아가려는 계획을 갖고 있으며 지속적으로 개발 중인 단계로 보입니다.

1.5. Radius

Radius의 경우 Fairblock과 매우 비슷한 방향성을 가진 프로젝트입니다. 사용자가 트랜잭션을 암호화해서 전달하면 Radius 시퀀서가 암호화된 트랜잭션들을 시퀀싱 후 복호화하는 방식입니다. 즉 Fairblock과 마찬가지로 검열가능성을 제한한 탈중앙화 시퀀서 프로젝트입니다.

하지만 앞서 소개해드린 프로젝트들과는 다르게 lazy rollup들을 대상으로 하는 프로젝트는 아닙니다. Radius 탈중앙화 시퀀서가 블록을 만들어서 이를 롤업에 전달하면 각 롤업들이 이를 실행하고 데이터 가용성 레이어와 Settlement 레이어에 전달합니다. 정리하면 연산 후에 데이터 가용성 레이어에서 블록의 저장이 이루어집니다. Settlement 레이어에서는 Radius 탈중앙화 시퀀서와 연산 순서에 대해 비교해서 강한 확정을 얻습니다.

작동 방식을 간단하게 정리하면 아래와 같습니다.

사용자가 암호화된 트랜잭션과 증명을 Radius에 제출함
Radius에서 암호화된 트랜잭션으로 블록을 생성함
블록의 트랜잭션 복호화 후 롤업으로 전달됨
롤업에서 블록 실행 후 데이터 가용성 레이어와 Settlement 레이어에 전달하고 검증함

아직 시퀀서 선정방식이나 시퀀서 정책 등 탈중앙화 시퀀서에 필수적인 요소들에 대한 계획이 확실히 정해지지 않은 프로젝트입니다. 얼마 전 첫 번째 테스트넷인 Curie가 출시되었습니다.

1.6. Madara

Madara는 스타크넷의 앱체인들을 위한 탈중앙화 시퀀서를 구축하는 것을 목표로 개발 중인 프로젝트입니다. 폴카닷의 Substrate 프레임워크를 사용하는 것이 특징이며, 스타크넷 위의 앱체인들이 파라체인, Madara 탈중앙화 시퀀서가 릴레이체인인 구조입니다. 합의 방식도 폴카닷의 GRANPA를 차용하였으며 유효성을 레이어 1에서 zk로 검증하므로 시퀀서 부분에서 검증 로직이 제외된 것이 특징입니다.

<Madara 탈중앙화 시퀀서> 출처: Starknet community

간단한 작동 과정은 아래와 같습니다.

사용자가 Madara 시퀀서에게 트랜잭션을 제출함
리더 노드를 선정하고 블록을 구성함
투표가 통과되면 트랜잭션을 실행하고, 레이어 1 상의 시퀀서 컨트랙트로 상태를 전달함

Madara에서 앱체인이 제출한 트랜잭션의 실행까지 담당하는 형태인 점이 특징이고, 현재 아직 개발이 많이 진행되지 않은 것으로 보입니다. 후에 폴카닷의 파라체인들도 Madara를 사용할 수 있게 해서 이더리움의 보안에 의존할 수 있게 하려는 계획을 갖고 있습니다.

1.7. Taiko

Taiko는 처음 소개해 드린 Metis와 같이 자체 레이어 위에서의 탈중앙화 시퀀싱에만 집중한 탈중앙화 시퀀서 프로젝트입니다. 레이어 1 기반 시퀀싱으로 레이어 1의 검증인에게 시퀀싱을 맡김으로써 레이어 1 시퀀서의 활동성(Liveness)과 탈중앙성을 상속받는 것을 목표로 두었습니다.

지금까지의 프로젝트들이 자체적으로 시퀀서를 탈중앙화해서 문제를 해결하려고 했다면, Taiko는 레이어 1의 탈중앙화된 검증인들을 통해 시퀀싱의 탈중앙화를 이루고자 했습니다. 간단한 작동 방식은 아래와 같습니다.

레이어 2의 Proposer가 Taiko 멤풀의 트랜잭션들을 선입선출의 방식으로 모아 블록을 생성함
만들어진 블록을 레이어 1의 검증인에게 전달함
레이어 1의 검증인은 2에서 받은 Taiko 블록을 포함하는 레이어 1 상의 블록을 생성함
레이어 2의 Taiko 노드가 제출된 블록을 받아서 유효성을 확인함
아래 두 과정 중 하나로 진행됨

만약 해당 블록의 모든 트랜잭션이 유효하다면, 실행 불가능한 트랜잭션들을 건너뛰고 블록을 제작
해당 블록의 트랜잭션이 하나라도 유효하지 않다면, 레이어 2에 오직 앵커 트랜잭션만 있는 빈 블록 생성

여기서 앵커 트랜잭션(Anchor Transaction)은 Taiko가 레이어 1에서 정한 순서를 따르는 것을 결정적으로(Deterministic) 만드는 트랜잭션입니다. Taiko에서 그 순서를 따르는 것을 강제할 수 있으며, 모든 Taiko 레이어 2 블록의 첫 번째 트랜잭션으로 포함됩니다.

과정 1번에서 알 수 있듯이 레이어 2에서 블록을 생성할 때는 선입선출 정책을 따라서 시퀀서의 악의적인 검열과 같은 문제를 방지하고자 한 것도 특징입니다.

레이어 1 검증인 입장에서는 기존에 하던 작업 외의 별도의 작업이 가중되지 않은 채로 Taiko를 포함한 MEV 추출에서 추가 이득을 볼 수 있다는 장점이 있고, Taiko의 입장에서는 앞서 말씀드린 것과 같이 시퀀서의 활동성과 탈중앙화 수준을 레이어 1 급으로 개선할 수 있다는 장점이 있습니다.

하지만 레이어 1에서 블록이 제출되고, 컨트랙트에서 검증되기 이전에는 실행에 대한 확정을 줄 수 없습니다. 따라서 레이어 2의 가장 큰 장점인 확장성과 속도 부분에서의 손해가 있습니다. 또한 Taiko에서 제출한 트랜잭션이 압축 없이 그대로 레이어 1 위에 저장된다는 단점도 있습니다. 이는 트랜잭션 저장 과정에서 더 큰 가스비를 요구하게 될 가능성이 있습니다.

1.8. Anoma

Anoma는 자체 프레임워크를 활용하는 블록체인을 일컫는 Anoma 인스턴스들 간의 탈중앙화 시퀀싱을 구현하는 프로젝트입니다. Intent라는 개념을 도입했다는 점이 가장 큰 특징인데, 사용자는 트랜잭션을 제출하는 대신 거래를 통해 원하는 최종 상태에 대한 선호(intent)들을 서명과 함께 Intent Gossip Layer라는 독자적인 레이어에 제출합니다.

여기서 intent는 하나 이상의 미래 상태를 승인하는 서명된 메시지입니다. 예를 들어 [-2000 USDC, +1 ETH]라는 intent를 제출한 사용자는 ETH를 1개 얻고 USDC를 2,000개 잃는 미래의 상태를 승인하는 것입니다. Intent와 일반적인 트랜잭션의 차이는 아래 표를 통해 자세히 확인해 볼 수 있습니다.

가장 큰 차이는 기존 트랜잭션에서 승인하는 것이 사용자의 의도가 실행되는 과정이라면, intent는 사용자의 의도 자체인 결과에 대한 상태변화만을 승인합니다.

이러한 intent들을 처리하기 위한 새로운 역할이 등장하는데 바로 Solver입니다. Solver는 Intent들이 서로 상쇄되도록 묶음을 구성하고, 이는 Anoma 인스턴스들을 포괄하는 크로스체인에 대한 하나의 트랜잭션이 됩니다. intent들을 하나의 트랜잭션으로 처리하는 과정에서 관여한 모든 Solver들이 보상을 공유하는 협력 구조입니다.

<Anoma intents 상쇄 예시> 출처: Delphi Digital

이렇게 처리된 트랜잭션들을 암호화해서 멤풀에 제출하면 각 Anoma 인스턴스들의 검증인들이 동시에 참여해서 시퀀싱을 한 후 블록이 실행되는 구조입니다.

위의 대부분의 탈중앙화 시퀀서 프로젝트, 특히 lazy rollup들을 대상으로 하는 프로젝트들과는 다르게 참여하는 블록체인들의 주권(sovereignty)을 인정하는 것도 특징입니다. 참여하는 Anoma 인스턴스들도 독립적인 검증인들이 존재하고, 그럼에도 multi-chain atomic settlement를 가능하게 합니다. 이는 멤풀 / 합의 / 연산에 대해 Typhon 엔진을 차용하기 때문에 가능하다고 합니다.

<Typhon과 CometBFT의 차이> 출처: Delphi Digital

전체 작동 과정을 요약하면 아래와 같습니다.

사용자는 intent에 서명한 후 Intent Gossip Layer에 제출함
Solver들이 intent들을 서로 상쇄되도록 묶음을 구성하고 암호화하여 제출하면, 이는 하나의 크로스체인 트랜잭션이 됨
제출된 트랜잭션들의 순서를 합의 후 실행하고 검증함

사용자가 intent를 제출할 때 위 사진과 같이 암호화된 상태로 제출할 수 있고, Solver들이 트랜잭션을 제출할 때, Fairblock, Radius에서와 같이 트랜잭션을 암호화해서 전송합니다.

2. 프로젝트별 컴포넌트 및 인사이트

2.1. 프로젝트별 컴포넌트

1부에서 분석한 탈중앙화 시퀀서의 컴포넌트를 중심으로 위에서 분석한 8개의 프로젝트를 표로 정리했습니다.

2.2. 컴포넌트 분석과 인사이트

각 프로젝트를 분석하고, 분류하는 과정에서 얻은 정보와 인사이트에 대해 컴포넌트별로 정리해 보면 아래와 같습니다.

1. 시퀀서 위원회 선발(Committee selection)

대부분의 프로젝트에서 시퀀서는 시퀀서로 참여하기 위해서 자체 레이어에 스테이킹을 합니다. 하지만 Espresso Systems와 같이 레이어 1의 스테이커를 시퀀서로 사용하는 리스테이킹 기반 프로젝트도 존재합니다.

스테이킹의 경우 자체 토큰 등을 스테이킹해서 시퀀서의 권한을 얻는 구조로 네이티브 토큰이 필요한 사용처를 제공해 주고, 리스테이킹의 경우 초기 프로젝트가 시퀀서 셋을 구축하기 편리하다는 장점이 있습니다.

또한 Espresso Systems와 같이 누구나 시퀀서로 참여하여 블록 합의 과정에 참여할 수 있는 프로젝트도 있지만, Metis와 같이 활성 시퀀서의 수를 Admin이 관리하여 시퀀서 참여 가능 인원을 제한적으로 설정한 프로젝트도 있습니다.

시퀀서 참여 가능 인원을 제한적으로 설정하면 합의 과정에서의 빠른 최종성을 보장할 수 있습니다. 하지만 시퀀서 참여 가능 인원에 제한을 두지 않으면 탈중앙성이나 검열 저항 부분에서 이점을 가져갈 수 있습니다.

2. 시퀀싱 정책(Sequencing Policy)

대부분의 프로젝트에서 MEV를 추출하는 것을 목표로 이루어지고 있습니다. 이는 시퀀서의 수익 구조와 프로젝트 참여를 위해서 필요합니다.

하지만, 사용자의 입장에서 볼 때 사용자가 제출한 트랜잭션이 검열 가능하다는 면에서는 단일 시퀀서 구조와 크게 다를 것이 없습니다. 탈중앙화 시퀀서는 각 리더 라운드가 길지 않아, 사용자가 제출한 트랜잭션이 검열될 위험이 단일 시퀀서에 비해서는 적습니다. 하지만 여전히 의도적으로 시퀀서가 사용자의 트랜잭션을 포함하지 않을 수 있습니다. 이런 부분에서 검열 저항성을 보장하는 것은 탈중앙화 시퀀서에서도 중요한 부분입니다.

Fairblock, Radius, Anoma와 같이 트랜잭션이나 intent를 암호화해서 사용자의 프라이버시와 검열 저항성을 보장해 주는 프로젝트들이 이런 부분에서 인상적이었습니다. 다른 프로젝트들도 추후 트랜잭션 암호화와 같은 솔루션을 적용하여 검열 저항성을 보장하지 않을까 싶습니다.

하지만 암호화 / 복호화 과정에서의 시간소모(Fairblock의 경우 하나의 블록 지연) 또한 존재하므로 레이어 2의 최대 장점인 속도의 이점을 유지하면서도 검열 저항성을 보장하는 솔루션들에 대한 연구가 프로젝트 차원에서 계속 진행될 것입니다.

3. 합의 메커니즘(Consensus Mechanism)

합의 메커니즘의 경우 텐더민트 합의 방식을 그대로 차용한 것이 많았습니다. 하지만 텐더민트는 낙관적인 응답성(Optimistic Responsiveness)과 동적 가용성(Dynamic Availability)을 동시에 보장할 수 없습니다. 낙관적인 응답성이란 네트워크 참여자 간의 지연이 없을 경우 빠르게 합의가 진행될 수 있는 특성을 뜻하고, 동적 가용성이란 네트워크 참여자들의 온라인 / 오프라인 상태를 자유롭게 전환할 수 있는 특성을 뜻합니다.

탈중앙화 시퀀서가 탈중앙화에 있어서 이상적인 특성인 무허가형을 달성하기 위해서는 시퀀서의 수나 참여 상태가 자유롭게 변경될 수 있어야 합니다. 즉 탈중앙화 시퀀서의 탈중앙화 특성을 달성하기 위해서는 동적 가용성을 보장받아야 합니다. 이는 탈중앙화 시퀀서가 텐더민트 합의 방식을 그대로 채택한다면 낙관적인 응답성을 보장받기 힘들어진다는 것을 의미합니다.

레이어 2의 가장 큰 메리트 중 하나는 바로 속도입니다. 하지만 텐더민트 합의 방식을 이용한 탈중앙화 시퀀서는 합의 과정에서 빠른 속도에 대한 특성인 낙관적인 응답성을 보장받기 힘들고, 속도적 이점을 많이 놓치게 될 것입니다.

위의 분석을 토대로 할 때, Espresso Systems의 독자적인 합의 메커니즘인 Hotshot을 사용해서 속도를 개선하고자 하는 시도가 인상적으로 보입니다. 탈중앙화 시퀀서의 탈중앙성과 속도를 모두 보장하기 위해서 다른 프로젝트들도 합의 방식에 대한 연구와 개선이 필요할 것입니다.

4. 상호운용성(Interoperability)

분석한 프로젝트들의 상호운용성은 생태계 공유 방식과 글로벌 공유 방식으로 나누어집니다. 각 공유 방식에 대한 설명은 아래와 같습니다.

생태계 공유 방식: OP Stack이나 Anoma와 같이 자체 프레임워크로 구현된 블록체인들 간의 상호운용성만 보장함
글로벌 공유 방식: 전체적인 레이어 2 간의 상호운용성, 더 나아가 레이어 1에 대한 상호운용성까지 보장함

두 방식 모두에 대해 각 롤업들이 탈중앙화 시퀀서의 블록을 사용하기로 정책이 결정되면, 롤업의 입장에서 자체 시퀀서는 필요하지 않습니다. 이는 롤업의 주권(sovereignty)이 상실되는 문제를 끼칠 수 있습니다.

기존의 롤업들은 중앙화된 시퀀서를 통해 트랜잭션 수수료와 MEV 추출 등의 독점 수익을 얻고 있습니다. 이 때문에 기존의 롤업들이 주권과 독점 수익을 포기하고 lazy rollup과 같은 방식으로 구조를 변환할 가능성은 거의 없을 것이라는 한계도 존재합니다.

주권에 대해선 Anoma의 방식이 인상적입니다. Anoma 인스턴스들은 Typhon이라는 독자적인 엔진을 사용하여 Anoma 인스턴스들의 시퀀서 셋을 유지하면서도 트랜잭션 실행의 원자성을 보장하는 특징이 있습니다.

추가로 글로벌 공유 방식의 경우 각 체인에서 제출된 트랜잭션을 탈중앙화 시퀀서 포맷에 맞게 수정해야 시퀀싱이 가능합니다. 하지만 이를 달성하기 위해 각각의 체인에서 제출한 트랜잭션을 탈중앙화 시퀀서 트랜잭션으로 래핑 하는 방법에 대한 연구가 많이 이루어지지 않은 것으로 보입니다. 글로벌한 상호운용성에 대한 목표는 아직 많은 연구와 개발이 필요한 부분입니다.

5. 프로포저 선발(Proposer Selection)

거의 모든 탈중앙화 시퀀서가 리더 선발 기반이고, 선발된 리더가 블록 빌더, 시퀀서, 프로포저의 역할을 한 번에 맡고 있습니다. 이는 MEV 추출의 비효율을 초래하고, 리더 노드의 권한이 지나치게 강해지는 문제가 생길 수 있습니다.

이러한 문제를 해결하기 위해 블록을 구성하는 블록 빌더와 프로포저를 분리하는 PBS(Proposer / Builder Separation)를 탈중앙화 시퀀서 자체에 도입하려는 시도들이 이루어지고 있습니다. PBS 구조를 사용하면 MEV 추출의 비효율이나 리더 노드의 지나치게 강한 권한 문제를 해결할 수 있겠지만 동시에 구조의 복잡성을 초래할 수 있습니다.

더불어 PBS 구조가 도입된다고 생각했을 때 탈중앙화 시퀀서에 적용할 수 있는 미들웨어 프로젝트, 예를 들어 탈중앙화 블록 빌딩 프로젝트인 SUAVE와 같은 프로젝트들도 탈중앙화 시퀀서 프로젝트와 함께 개발 중입니다.

6. 보상 메커니즘(Reward Mechanism)

보상 메커니즘으로 네이티브 토큰을 사용하면 네이티브 토큰에 대한 사용처를 보장해 줄 수 있습니다. 또한 데이터 가용성 레이어에 트랜잭션을 제출할 때 가스비로 데이터 가용성 레이어의 자체 토큰을 사용하는 경우가 많기 때문에, 데이터 가용성 레이어 토큰에 대한 사용처도 동시에 늘려주는 긍정적인 영향도 줄 수 있습니다.

7. 데이터 가용성(Data Availability)

많은 탈중앙화 시퀀서 프로젝트들이 레이어 1이 아닌 독자적인 데이터 가용성 레이어를 사용합니다. 이는 Espresso Systems의 Tiramisu와 같이 탈중앙화 시퀀서의 속도를 개선할 수 있고, 레이어 1에 데이터를 저장하는 것에 비해 더 싼 값에 저장할 수 있기 때문입니다.

3부에서는 탈중앙화 시퀀서 중 생태계 공유나 글로벌한 상호운용성을 갖는 공유 시퀀서(Shared Sequencer)에 대해서 소개하겠습니다.

[탈중앙화 시퀀서 시리즈] #2. 탈중앙화 시퀀서 프로젝트

시리즈

Author

목차

1. 탈중앙화 시퀀서 프로젝트

2. 프로젝트별 컴포넌트 및 인사이트

참고자료

Written by 이현우