[Infrastructure] 왜 Sei는 더 빠른 블록체인을 지향하는가 — 확장성과 탈중앙성의 교차점에서

가장 빠른 블록체인으로 금융 경험의 혁신을 이루고자 하는 Sei의 생태계와 기술에 대해 알아보자.

24 min readAug 16, 2023

사전 고지: 본 글은 단순 정보 제공을 위해 작성되었고 투자, 법률, 자문 등 어떤 부분에 대해서도 책임을 지지 않습니다. 특정 자산에 대한 투자를 추천하는 것이 아님을 밝히며, 본문의 내용만을 바탕으로 투자에 대한 의사결정을 내리지 마십시오.

TL;DR

트레이딩에서의 최상의 사용자 경험을 위해 Sei는 자체 오더 매칭 시스템, 프론트러닝 방지 메커니즘, 그리고 네트워크단의 오라클을 제공한다.
목표하는 백엔드에서의 금융 혁신을 이루기 위해 Sei만의 Twin Turbo 합의 메커니즘과 트랜잭션 병렬 처리 시스템을 구현했다.
확장성과 보안성을 달성하기 위해 밸리데이터의 역할이 무거워져 탈중앙성을 희생했지만, 호스팅 인프라와 지리적 위치의 분산을 통해 운영 관점에서의 탈중앙성을 확보했다.
Sei는 2023년 8월 15일에 메인넷을 런칭했다. 최고의 트레이딩 경험을 제공하겠다는 비전을 토대로, 블록체인 시장에 어떠한 변화를 이룰 지 지켜보자.

1. Sei의 목표: 금융의 혁신

오늘날까지 금융의 혁신은 소위 프론트엔드 — 사용자의 사용경험 개선을 통해 이루어졌다. 이를 통해 유니콘에 도달한 기업들만 하더라도 페이팔, 토스, 로빈후드 등 수많은 기업들을 상상할 수 있다. 하지만 이는 역설적으로 오랜 기간 백엔드에서의 금융 혁신은 이루어지지 않았음을 의미한다. 흔히 블록체인 기술의 사용처와 매스 어돕션의 방향으로 금융을 꼽는 데에는 이러한 백엔드 차원의 혁신을 가져올 수 있을 것이라는 기대감에서 비롯되었다고 볼 수도 있겠다.

혁신은 파괴적이든 존속적이든 그 형태를 불문하고 기존의 사용자 경험을 적어도 악화시키지 않는 것을 전제로 이루어진다. 그렇다면, 현재 블록체인이 구축하고 있는 금융 시스템은 기존의 사용자 경험을 악화시키지 않는 전제를 지키고 있을까? 실물자산을 토큰화시켜 증권의 형태로 전통적인 거래소에서 거래할 수 있는 세상에서, 대부분의 거래는 온라인에서 이루어지고 있다. 이때 거래소의 사용자는 (1) 원하는 가격 및 수량을 (2) 유동성 등 여타 요인이 없는 한 원하는 시간에 거래하는 경우가 일반적이다. 전통금융의 사례에서 볼 수 있듯, 오더북 형태의 거래소는 이와 같은 사용자 경험을 보장하는 검증된 수단이다. 디파이의 발전 방향에 오더북이 등장하는 것은 굉장히 자연스러운 흐름으로 보인다.

하지만 오더북은 말 그대로 거래 참여자들의 주문을 기록하고, 특정 시점 집계된 주문에 대한 정보를 제공하는 역할만을 수행한다. 오더북을 프론트엔드에서 보여주더라도, 백엔드의 한계로 인해 오더북의 업데이트에 1분 이상이 소요된다면 오더북은 문제 해결 수단으로서의 의의를 상실한다. 사용자의 경험을 고려했을 때 가격 및 수량에 대한 의도를 충분히 반영할 수 있는 AMM의 알고리즘 발전도 중요하지만, 그에 못지 않게 사용자가 ‘충분히 정확한’ 정보를 인지하고 의도를 표출할 수 있는 환경이 중요하다.

CEX 수준의 사용자 경험을 제공하는 것 뿐만 아니라 사용자들이 해당 환경에서 거래를 할 실질적인 유인이 존재하는 생태계를 구축하기 위해서, Sei는 ‘탈중앙화된 나스닥’이라는 비전을 토대로 빠르게 나아가고 있다. 요컨대, 이더리움을 비롯한 기존의 환경을 탈피, 보다 혁신적인 접근을 통해 충분한 확장성을 달성하고 금융의 혁신을 이룩하는 것이 Sei가 나오게 된 배경이라고 하겠다.

2. Sei가 최고의 사용자 경험을 달성하는 방식

블록체인의 확장성(Scalability) 문제는 비트코인 백서를 통해 블록체인이 대중에 알려진 이후부터 끝없이 회자되어 온 만큼, 이를 해결하려는 수많은 시도가 존재했었다. Sei 역시도 이러한 확장성 문제를 해결하기 위해 등장한 범용(General Purpose) 레이어 1 블록체인이다. 허나 수많은 시도 중에서도 Sei는 ‘왜 이렇게 빠른 블록체인이 필요한지’에 대한 뚜렷한 방향성을 가지고 시장을 향해 나아가고 있다는 점이 인상 깊다. Sei는 금융의 진정한 혁신이라는 굉장히 명료한 가치 명제(Value Proposition) 하에서 어떠한 생태계를 구축할 것인지에 대해 깊이 고민해왔으며, 사용자들은 조만간 이러한 고민의 산물을 시장에서 만나볼 수 있을 것이라 기대된다. 특히 본 글의 끝 부분에서는 Sei가 메인넷 런칭을 앞두고 비단 확장성 뿐만 아니라 안정성을 확보하기 위해 어떠한 고민을 해왔고, 그 결과 어떠한 성과를 달성했는지 밸리데이터 운영 경험을 토대로 이야기해보려 한다. Sei가 왜 디앱이 아닌 ‘범용 앱체인’을 지향하는지와 관련해서는 이전 글로 갈음한다.

Sei has only one value prop: exchange apps — whether it’s a NFT marketplace or gaming economy- will offer the best user experience by building on Sei.

상술한 Sei의 가치 명제는 최고의 사용자 경험을 주는 것, 다시 말해 금융의 혁신을 이룩하는 것으로 요약될 수 있다. 블록체인에서 이러한 혁신이 과연 중요한 문제일지 생각해보자. 블록체인에서 금융은 온라인과 오프라인의 모든 객체 — 심지어 게임을 통한 ‘재미’나 프로토콜의 ‘효용’까지 포함한다 — 를, 토큰이나 NFT와 같은 다양한 형태로 표상한 것들을 대상으로 한다는 점에서 무한한 확장성을 가진다. 금융 백엔드의 혁신을 비로소 현실화하기 위해서, Sei와 같이 ‘최고의 사용자 경험’을 주는 것을 목표로 하는 프로덕트의 등장은 환영할 만 하다.

Sei가 달성하려는 혁신에 필수불가결한 ‘확장성’을 어떻게 달성했는지를 살펴보기 전에, Sei가 그려가고 있는 비전을 조금 더 자세히 알아본다. 아래에서는 트레이딩 오더 매칭부터 MEV 보호 시스템까지, Sei가 금융 혁신을 달성하기 위해서 어떤 인프라와 생태계를 구축하려 하는지를 살펴본다. 구체적으로는, 거래의 세 가지 요소인 (1) 가격 (2) 수량 그리고 (3) 체결 시간 각각에 대해 사용자 경험을 증진시키기 위해 어떤 솔루션을 제안했는지를 살펴본다.

2.1 자체 오더 매칭 엔진

유동성 파편화는 비단 레이어 1, 2 상호 간의 문제가 아니다. 물론 브릿징의 필요성은 유동성 파편화를 더욱 해결하기 어렵게 만들지만, 동일한 레이어 존재하는 디앱 사이에서도 유동성 파편화 문제가 존재한다. 유동성의 깊이가 얕을수록 가격의 변동성은 커지기 때문에, 사용자에게 좋은 경험을 제공하기 위해 이와 같은 파편화 문제를 해결하는 것은 중요하다. 앞서 언급했던 것처럼, Sei는 하나의 디앱이 아닌 앱체인 형태로 존재한다. 이러한 장점을 적극적으로 활용해서, Sei는 레이어 내부에서 발생하는 유동성 파편화를 해결하기 위한 방법으로 ‘자체 오더 매칭 엔진’을 구축했다. 말 그래도 사용자가 발생시키는 주문(Order)를 체인 단에서 체결시키는 방식으로, Sei 위에서 구축되는 모든 디앱은 근원적으로 한 곳에 집중된 유동성 풀을 동일하게 활용할 수 있는 것이다.

나스닥의 CLOB(Central Limit Order Books)를 예시로 위와 같은 엔진 구축의 필요성을 살펴보자. CLOB은 나스닥에서 마켓 메이킹 과정에서 활용되는 시스템이다. 새로운 오더북이 생성(사실상 마켓 메이킹 과정과 동일)된 뒤 사용자들은 각 오더북에 지정가(Limit), 시장가(Market) 주문과 같이 주문의 수량 뿐만 아니라 가격과 체결되는 조건을 설정하여 다양한 시장 전략을 구사할 수 있게 된다.

Sei의 자체 엔진은 이러한 시장 전략을 구사할 수 있는 상황을 상정하고 설계된 것으로 보인다. 따라서 해당 엔진을 활용하는 Sei 위의 디앱은 CLOB을 손쉽게 활용할 수 있을 것이다. 예컨대, DEX에서 Sei 상에 CLOB을 배포하더라도, Sei의 자체 오더 매칭 엔진은 다양한 CLOB 트랜잭션에 각 오더북의 유동성을 대응시킨다. 이때 유사하게 오더북 시스템을 구축한 세럼이 오더를 매칭 및 실행시키기 위해 서로 다른 3개의 트랜잭션이 필요한 것과는 달리, Sei에서는 상기 엔진의 DEX 모듈 및 EndBlocker와 같은 훅을 통해 단일한 블록 내에서 수행될 수 있다. 나아가 이와 같은 오더북이 수없이 확장하는 시나리오를 고려하여, Sei에서는 하나의 트랜잭션으로 여러 오더북을 업데이트할 수 있는 오더 번들링 기능도 함께 제공한다. 요컨대 사용자의 입장에서 최적의 가격, 수량, 체결 시간을 경험할 수 있게 하기 위한 기초 인프라로써 자체 오더 매칭 엔진의 필요성을 확인할 수 있겠다.

2.2 자체 오라클

블록체인에서 오라클은 오프체인과 온체인 사이의 동기화 문제를 내포하고 있는 바, 트릴레마와 더불어 해결하기 어려운 문제로 꼽힌다. 정보를 업데이트하는 오라클 모듈은 곧 사용자가 거래 과정에서 경험하는 ‘가격’과 직결된다는 점을 고려했을 때, 신뢰 가능한 정보를 가격에 반영시키는 것은 Sei의 비전을 이루기 위해 필수적인 작업일 것이다.

이를 위해 Sei는 네트워크 단에서 자체적으로 오라클 모듈을 제공한다. 다른 모듈 및 컨트랙트에서는 해당 오라클 모듈을 참조하는 방식으로 구현되는데, 이때 해당 오라클 모듈이 어떤 방식으로 신뢰 가능한 정보를 확보 및 제공하는지를 간략하게 살펴보자. 기본적으로는 검증인이 합의 과정뿐만 아니라 오라클로서도 참여하는 방식이며, 오라클에서의 악의적인 행위(불참하거나 오류가 있는 데이터를 전송하는 등)를 하는 경우 해당 검증인에게 페널티를 부과한다. 검증인이 직접 가격 정보를 수집하는 방식도 가능하고, 검증인이 아닌 사용자가 정보를 수집해 검증인에게 제공(Feeding)하는 방식도 가능하다. 요컨대, 탈중앙화된 오라클을 지향하는 체인링크 역시도 그 근간에는 검증인 간 합의 및 페널티 방식으로 동작한다는 점을 고려했을 때, 이미 Sei 네트워크 자체와 이해관계가 일치되어 있는 검증인을 활용해 신뢰 가능한 정보를 제공하는 접근법은 유의미할 것으로 사료된다. 다만 검증인에게 이러한 부하를 가하는 방식은 결과적으로 네트워크를 중앙화를 촉진할 수 있을 것이다. 허나 검증인이 아닌 주체가 해당 부하를 감수하는 방향도 구현되어 있다는 점은 위 우려를 어느정도 불식시킬 수 있을 것으로 보인다. 탈중앙성과 관련해서는 하단의 ‘4. 속도를 위한 타협, 탈중앙성을 위한 노력’에서 보다 깊게 다뤄보도록 하겠다.

2.3 프론트러닝 방지 시스템

지금까지 사용자의 거래 경험과 관련하여, 거래의 3요소 중 사용자가 의도하는 가격과 수량을 정확하게 거래에 반영하기 위한 Sei의 인프라를 살펴보았다. 나머지 요소인 체결 시점의 경우 확장성과 긴밀하게 관련되어 있으므로, 이에 대해서는 아래 ‘3. Sei가 목표하는 확장성을 달성하는 방식’에서 살펴보도록 한다.

하지만 유동성 파편화를 막고 정확한 가격 정보를 전파하는 것만으로는 사용자에게 최적의 거래 경험을 제공하지 못한다. 2019년 논문에서 하나의 현상으로 지적된 MEV는 현재 대중적으로 블록체인의 일반 사용자의 경험을 악화시키는 주범 중 하나로 꼽히고 있다. MEV는 다양한 형태로 추출되며, 추출되는 구체적인 양상에 대해서는 이전 글을 첨부한다. 본 글에서는 그 중 사용자의 경험에 부정적인 영향을 미치는 것으로 지목되는 프론트러닝을 방지하기 위해 Sei에서 제안한 솔루션을 살펴보도록 하겠다.

프론트러닝은 말 그대로 사용자의 트랜잭션을 확인한 후 ‘사전에’ 사용자로부터 이득을 추출할 수 있도록 트랜잭션을 정렬 및 처리하는 MEV 추출 기법이다. 이때 이득은 결국 가격 변동에서 파생되기 때문에, Sei에서는 자체 오더 매칭 엔진에 단일 블록 내 동일한 가격을 제공할 수 있는 배치를 형성함으로써 프론트러닝을 방지하는 시스템을 구축하였다. 이를 FBA(Frequent Batch Auctions)라고 부르는데, 어떤 방식으로 일관된 가격을 제공하는지 확인해보자.

FBA는 모든 시장가 주문을 블록 마지막에 집계한 후 동일한 청산 가격(uniform clearing price)에서 실행한다. 앞에서 Sei에 내장된 오더 매칭 엔진의 특징으로 오더 매칭과 실행을 단일 블록 내에서 수행하는 것을 언급했듯, FBA 역시 이러한 특징을 활용해 단일 블록 내 시장가 주문을 동일 가격 하에 체결시킨다. 거래 순서와 무관하게 해당 블록 시간(약 500ms) 동안 거래를 게시한 모든 사람들과 동일한 가격을 얻을 수 있다는 점을 상기하면, 가사 프론트러닝으로 트랜잭션의 순서가 뒤바뀌더라도 (1) MEV봇의 입장에서 추출할 이득이 사라질 가능성이 높고 (2) 사용자 입장에서도 가격 변동 없이 거래를 실행할 수 있을 것이다.

오더북에 단 2개의 주문이 존재하는 간단한 예시를 들어보자. 주문 A는 토큰을 $10에 팔고, B는 $12에 팔고자 한다. 해당 오더북에 서로 다른 두 명의 구매자가 나타난 상황에서, FBA가 동작하지 않는다면 첫 구매자가 주문 A를 선택, $10에 토큰을 매수하고 그 다음 구매자가 주문 B에 따라 $12에 토큰을 매수할 것이다. 구매자의 진입 순서, 다시 말해 트랜잭션의 정렬 순서에 따라 시장가에 구매하고자 하는 사용자가 손해를 볼 수 있는 상황이다. 하지만 FBA가 동작하는 상황이라면 단일 블록 내에서 동일한 청산 가격을 공유하기 때문에 (P1 + P2) / 2의 평균 가격에 주문이 체결될 것이다.

2.4 소결

지금까지 Sei가 유연한 거래 경험을 제공하기 위해 어떤 접근법을 취하고 있는지 살펴보았다. 전술한 것처럼, 거래의 필수적인 구성요소인 가격과 수량, 그리고 체결 시간에 대한 유저의 의도 및 경험을 어떻게 블록체인이라는 탈중앙화된 인프라 위에 온전하게 반영할지에 대한 깊은 고민이 드러난다. 타 체인 위의 디앱이 아닌 범용 앱체인으로 시작함으로써 Sei는 (1) 연관 없는 디앱과의 리소스 경쟁을 피하고 (2) 자체 오더 매칭 엔진, 오라클 등 설계의 자율성을 충분히 누리려 한 것으로 보인다.

하지만 아직 금융 혁신과 최상의 유저 경험이라는 Sei의 목표를 달성하기 위해서는 근원적으로 해결해야 하는 문제 — 확장성이 남아있다. CEX 수준의 거래 환경을 생각했을 때, 일반적인 수준의 확장성으로는 거래에 참여하는 다양한 층위의 참가자, 일반적인 트레이더부터 마켓 메이커 전체를 만족시키기 힘들 것으로 보인다. 더욱이 대부분 블록체인의 합의 알고리즘 특성 상 블록의 생성과 완결이 분리되어 있는데, 거래자의 입장에서 완결되지 않은 블록은 의미를 가지지 않으므로 완결되는 시간을 더 빠르게 앞당겨야 할 필요도 있을 것이다. 그러면서도 체인의 분기(Fork)가 자주 일어나는 등 안정성이 떨어진다면 해당 플랫폼을 사용할 이유가 없을 것이다. 이렇듯 Sei의 목표를 달성하기 위해서 아직 넘어야 할 산이 많은데, 아래에서 어떤 방식으로 해결하고자 했는지 살펴보도록 한다.

3. Sei가 목표하는 확장성을 달성하는 방식

우선, 확장성과 관련된 지표를 먼저 살펴보자. 블록체인에서 확장성을 논할 때 대개 TPS(Transaction Per Second)를 사용하는데, 이는 한 블록에 담긴 트랜잭션 수를 블록 생성에 걸리는 시간(Second)으로 나누어 계산한 지표이다. 하지만 TPS는 블록체인의 확장성을 표현하는 데에 있어서 적합하지 않은데, 이는 결국 트랜잭션이 완전해지기 위해서는 블록이 완결되어야 하기 때문이다. 따라서 TTF(Time To Finality), 즉 트랜잭션이 확정되기까지의 시간을 대용 지표로 고려해볼 수 있다. 트랜잭션의 생성과 더불어 완결성이 사용자의 금융 거래 경험에 중요한 역할을 하기 때문에, Sei는 완결까지의 시간을 앞당기는 것을 목표로 한다.

Sei가 선택한 텐더민트 BFT 합의 알고리즘의 경우 Liveliness보다 Safety를 중시했기 때문에, 확률적 완결성이 아닌 결정적 완결성을 가진다는 장점이 있다. Sei는 현존하는 블록체인중 가장 빠른, 500ms라는 트랜잭션 완결성을 가지고 있으며, 이는 트랜잭션 완결에 13–20분이 걸리는 이더리움이나 1–2초가 걸리는 솔라나, 0.9초가 걸리는 앱토스에 비해 엄청나게 빠른 속도이다. 이렇듯 빠른 완결성을 달성하기 위한 Sei의 전략을 살펴보자.

3.1 Twin Turbo Consensus

Twin Turbo 합의는 Sei를 차별화하는 가장 큰 기술적 진보이다. Sei의 합의 알고리즘은 인텔리전트 블록 전파(intelligent Block Propagation)와 옵티미스틱 블록 프로세싱(Optimistic Block Processing)의 방법을 동시에 구현해, Twin Turbo라고 불린다.

위 그림은 기존의 블록 생성 메커니즘을 도식화한 것인데, 최적화 할 수 있는 부분이 두가지 보인다.

(1) 각 밸리데이터가 멤풀이 있고, 트랜잭션에 대한 데이터가 해당 멤풀에 이미 존재한다. 즉, 모든 밸리데이터는 대부분의 트랜잭션에 대한 데이터를 이미 서로 공유하고 있다.

(2) 블록 합의 과정은 제안, 밸리데이터 투표, 합의, 그리고 전파로 이루어져 있다. 위의 그림에서 이 과정들은 직렬화되어있어, 병렬화 할 수 있는 부분이 있다면 더 효율적인 과정이 될 것이다.

위의 두 가지 방안을 바탕으로 Sei의 Twin Turbo 합의 알고리즘이 구성되어있다.

3.1.1 Intelligent Block Propagation

먼저 인텔리전트 블록 전파를 알아보자. 기존의 텐더민트 합의 과정에서는 블록 제안자가 블록을 다른 밸리데이터에게로 전파할 때 블록의 모든 트랜잭션 정보를 담아서 전파한다. 이는 상당히 많은 양의 정보이기도 하지만, 다른 밸리데이터들도 이미 멤풀에 같은 정보를 담고 있기 때문에 중복되는 작업 수행이기도 하다. Sei에서는 이 점을 이용해 네트워크의 블록 제안자가 블록을 전파할 때 트랜잭션을 압축해 담은 해시값만 전송을 하고, 이를 전파받은 다른 밸리데이터들은 이미 가지고있는 멤풀의 트랜잭션과 비교해 블록을 복원할 수 있다.

최근 Sei는 인텔리전트 블록 전파의 코드에서 버그를 발견해 수정했다. 이로 인해 블록 타임이 250ms까지 줄어들 수 있었다. 이는 원래도 빠른 Sei의 완결성보다 39% 가까이 빨라진 효과를 가져왔다. 하지만 너무 빨라진 블록 타임은 블록 생성에 편차를 가져왔는데, 밸리데이터들과 RPC노드같은 인프라 플레이어들이 빠른 블록 타임에, 제때 검증하지 못하는 기술적 어려움을 초래했기 때문이다. 따라서 Sei는 네트워크의 보안을 위해 보수적으로 접근하여, 블록 타임을 100ms 늘리는 작업을 했고, 빠르지만 더 안정적인 네트워크를 형성하고자 노력했다.

3.1.2 Optimistic Block Processing

인텔리전트 블록 전파와 함께 Twin Turbo 합의를 완성하는 옵티미스틱 블록 생성은 기존의 텐더민트 합의 과정을 조금 수정한 방법이다. 기존의 블록 제안은 voting period 다음에 이루어지는데, 이는 텐더민트가 BeginBlock, DeliverTx, EndBlock, 그리고 Commit을 블록 제안의 내용과 함께 실행시키는 단계이다. 다음의 그림으로 도식화 할 수 있다.

처음에 블록이 제안된 후, 사전 투표의 개념인 Prevote 및 Precommit 단계를 통해 투표가 이루어지고, 이후에 상태 변화를 연산하며 블록이 프로세싱 되면 마지막으로 Commit되며 블록이 생성된다. 하지만 위의 그림같은 직렬화는 필수가 아니여도 가능한 점이, 블록을 프로세싱하는 단계에서 필요한 정보는 이미 Prevote 단계에 밸리데이터에게 주어진다. 따라서, 해당 과정을 병렬화시켜 블록 프로세싱 단계를 압축했다.

새로운 방식에서는 Prevote 이전에 ProcessProposal을 호출하면, 투표와 관계 없이 비동기적으로 블록 프로세싱을 시작한다. 투표가 끝나고 FinalizeBlock이 호출되면, 블록 프로세싱이 끝나길 기다린 후 commit하여 블록 전파 과정이 완료된다. Sei의 블록 전파 과정에서의 비동기 방식은 33%정도의 가속화를 가져올 수 있다.

3.2 트랜잭션 병렬 처리

블록체인의 처리량을 늘리기 위해서는 합의 알고리즘을 수정해, 보다 빠른 합의에 이르게 하는 방법도 있지만, 트랜잭션 실행을 빠르게 해서 더 많이 처리하는 방법도 있다. 위에서 언급한 빠른 합의 알고리즘에 더해서 Sei는 트랜잭션의 실행을 더 효율적으로 하는 병렬 처리를 도입했다. 최근 확장성을 비전으로 나온 앱토스, 수이, 솔라나 같은 프로토콜들도 자체적으로 트랜잭션 병렬 처리 알고리즘을 도입하고, 이더리움같은 경우는 EVM이 트랜잭션을 직렬로 처리하기 때문에 Layer 2에서 병렬처리를 지원하는 추세이다.

트랜잭션의 병렬처리로 인해 초당 8000개의 트랜잭션을 처리할 수 있을 정도의 확장성을 달성했지만, 모든 트랜잭션을 병렬로 처리한다면 밸리데이터 사이에서의 “비결정론”(nondeterminism)을 초래한다. 이는 같은 코드를 여러번 실행했을 때 같은 결과값으로 도달하지 않는 현상을 의미하는데, 서로 다른 트랜잭션이 꼭 순서대로 처리되어야 할 때 일어난다. 비결정론적 트랜잭션 수행을 방지하기 위해 Sei는 코스모스 SDK의 직렬 처리를 수정하여, 트랜잭션의 모음 중 순서와 상관 없이 처리 가능한 것들을 모아 병렬로 처리하고, 그렇지 않은 트랜잭션들은 기존의 시스템처럼 직렬로 처리한다. 순서와 상관이 없다는 말은, 트랜잭션들이 서로에게 의존도가 없다는 말을 뜻한다.

트랜잭션 끼리의 의존도를 확인하기 위해 DAG(Directed Acyclic Graph)를 구성한다. DAG는 간단히 말해 화살표로 표시된 의존도인데, 트랜잭션끼리 화살표가 향하고 있으면 상호의존을 하고있다는 뜻이여서 직렬처리에 해당하고, 그렇지 않으면 병렬처리가 가능한 트랜잭션으로 분류된다. 위의 그림처럼, 모든 트랜잭션을 순서대로 처리하는 것에 비해 의존도가 있는 트랜잭션은 직렬로 처리하되 그렇지 않은 트랜잭션은 병렬로 동시에 처리하면 모든 트랜잭션을 처리하는 총 시간이 더 줄어듦을 알 수 있다.

{
    "resource_dependencies": {
        "first_blue_read": [],
        "first_red_read": [chan_msg1_first_red_write],
        "first_red_write": [chan_msg1_second_red_read],
        "first_blue_write": [chan_msg1_first_blue_read]
    },
    "completion_signals": [
        chan_msg2_last_blue_read,
        chan_msg2_last_red_read,
        chan_msg2_red_write,
        chan_msg2_blue_write
    ]
}

Sei가 트랜잭션간의 의존도를 파악하기 위해 사용하는 모듈이다. 간단히 설명하자면, 위의 “resource_dependencies”는 해당 트랜잭션의 전후로 어떤 의존성을 가지고 있는지 나타내는데, 처음의 “first_blue_read”가 실행된 후 완료됨을 chan_msg2_last_blue_read에 시그널링한다. 후에 순서대로, “first_red_read”는 “chan_msg2_red_write”의 시그널을 받고 실행이 될 것이다. Sei에서 블록 프로포절이 진행되면, 위의 모듈을 통해 트랜잭션간의 DAG를 구성하고, 병렬처리를 할 수 있는 트랜잭션을 골라낸 뒤, 더 짧은 시간 안에 모든실행을 완료한다.

확장성을 달성하기 위해서 Twin Turbo 합의와 병렬처리를 도입한 Sei의 기술적 혁신을 알아보았다. 하지만 블록체인에서는 확장성만이 중요한 것이 아니다. 블록체인을 구성하는 세가지 요소는 (1)확장성, (2)탈중앙성, 그리고 (3)보안성인데, 이 세가지 모두를 완벽하게 달성하는 것이 어렵다는 사실은 “블록체인 트릴레마”로써 널리 알려져 있다. 그렇기에 수많은 블록체인들은 각자가 추구하는 철학에 따라 위 세 가치 중 두 가지를 이룩하고, 다른 하나에 대해 조금의 희생은 감수한 뒤 종국적으로는 셋 모두를 이루기 위한 전략을 취한다. Sei는 다른 체인과의 차별점으로 “누구보다 빠름”을 강조해왔는데, 못지않게 중요한 탈중앙성과 보안성을 어떻게 달성할 수 있는 지, A41의 Sei 테스트넷에서의 경험을 토대로 서술해보려 한다.

4. 속도를 위한 타협, 탈중앙성을 위한 노력

4.1 탈중앙성을 희생해 확보한 확장성과 보안성

Sei의 목표이자 철학은 사용자들에게 최고의 트레이딩 경험을 안겨줄, “빠르고 안전한” 체인이다. 그렇기 때문에 위 세 가치 중 확장성과 보안성이 우선시되었고, 상대적으로 탈중앙성을 타협한 모습을 볼 수 있다. Sei는 금융의 혁신이라는 명확한 비전을 위해 블록 시간과 완결성을 비약적으로 짧게 가져가는 등 확장성을 달성하고, 나아가 블록체인이라는 인프라 위에서 전통 금융 수준의 거래 전략 및 경험을 제공하기 위한 체인 자체적인 장치들을 구현했다. 허나 전술한 것처럼, 이러한 확장성 및 장치는 검증인의 부담을 증가시키는 방향으로 이루어지고 있다. 다시 말해, Sei의 검증인으로 참여하기 위해 요구되는 노드 운영 사양이 굉장히 높다는 것을 의미한다.

높은 운영 사양은 결과적으로 검증인 참여의 진입 장벽으로 작용한다. 요컨대 운영 경험이 충분한 한정된 주체만 네트워크에 참여하는, 검증의 중앙화가 야기될 가능성이 높다는 것이다. 하지만, Sei 위에서 거래하는 사용자들에게 가장 편한 환경을 제공하고자 하는 것이 네트워크의 철학이고, 자체 오라클 검증과 빠른 블록 속도를 견뎌야하는 큰 역할 때문에 밸리데이터의 역할이 무거워지는 것이 불가피하다. 그렇다면, 이러한 환경에서 탈중앙성을 확보하기 위해 Sei 측은 어떤 노력을 전개하고 있는지 살펴보도록 한다.

4.2 탈중앙성을 확보하는 방법

탈중앙성의 판단기준에 관한 Messari 레포트를 인용컨대, 운영 관점에서의 탈중앙성은 노드 소프트웨어, 호스팅 인프라, 지리적 위치 3가지 요소로 판단할 수 있다고 한다. 노드 소프트웨어는 노드를 운영하는 클라이언트 프로그램을 의미하며, 모든 검증인이 동일한 프로그램을 사용하는 경우 해당 프로그램에서 발생하는 오류에 대한 저항성이 문제되므로 탈중앙성의 요소로 간주된다. 호스팅 인프라 및 지리적 위치의 경우 프로그램 자체의 오류보다는 정치, 사회, 경제적인 중앙화를 야기할 수 있는 요인이므로 이 역시도 탈중앙성의 요소로 간주된다.

이때 검증인들은 위 3가지 항목 중 ‘노드 호스팅 인프라’와 ‘지리적 위치’의 탈중앙성을 확보하는데 핵심적인 역할을 수행한다. 운영의 탈중앙성을 달성하기 위해선 검증인의 의사결정이 중요한데, 호스팅 인프라와 지리적 위치의 분산을 고려하지 않으면 단일 실패 지점을 발생시키는 결과를 초래할 수 있다.

4.3 탈중앙성을 위한 Sei 재단과 검증인의 노력

Sei의 확장성, 즉 블록 타임 및 완결성 확보를 위한 합의 과정을 고려했을 때, 네트워크의 지연 시간 조차 큰 장애물로 작용하게 된다. 네트워크 지연은 주로 지역간 거리 문제, 즉 네트워크의 근간을 구성하는 광케이블의 연결망과 관련되어 있다. 그리고 ms 단위로 표현되는 블록타임은 이러한 연결망의 거리에도 영향 받을 수 있는 수치에 해당한다. 실제 사례와 함께 알아보자.

독일에 있는 노드와 마이애미에 있는 노드간 RTT(Round Trip Time)는 100ms 이상인 데 반해, 유럽내 위치한 노드간 RTT는 25~35ms 내외이다. Sei의 경우 ms 단위로 발생하는 합의에 참여해야 하므로, 합의에 참여하는 검증인 입장에서는 자연스럽게 이와 같은 네트워크 지연이 적은 지역 및 클라우드 서비스 제공자를 선택하게 된다. 그러나 모든 검증인이 네트워크 참여에 유리한 선택만을 하게 된다면 노드의 물리적 위치가 중앙화될 것이고, 이는 상기 언급한 바와 같이 단일 실패 지점의 발생으로 이어지게 된다.

Sei 재단은 이 문제를 인지하고 밸리데이터들이 노드를 다양한 지역 및 서비스 제공자로 옮길 수 있도록 적극적으로 지원하였다. 더불어 이러한 분산 과정에서 각 검증인들의 성능이 저하되는지 확인하며 검증인의 지표뿐만 아니라 수익성이 악화되지 않도록 주의를 기울였다. 이에 발맞추어 검증인들 또한 다양한 지역 및 클라우드 서비스의 사용성 및 결과를 실험하고 공유하며 네트워크 탈중앙성 개선에 기여하였고, 그에 따라 노드를 분산하는 이주 작업이 점진적으로 이루어졌다. 이러한 모두의 노력을 바탕으로 현재는 다양한 클라우드 서비스와 국가에 노드들이 분산되어 단일 실패 지점 문제가 완화된 상황이다.

5. 마치며

본 글에서는 Sei가 현존하는 블록체인 중 가장 빠른 확장성과 완결성을 통해 달성하고자 하는 비전을 개괄적으로 살펴보았다. 더불어 목표하는 비전에 다다르기 위한 고민의 과정과 그 산출물을 기술적인 차원 및 검증인 운영 경험을 토대로 논의했으며, 블록체인의 핵심 가치 중 하나인 탈중앙성을 종국적으로 달성하기 위한 재단과 검증인의 노력을 알아보았다.

Sei는 나스닥의 탈중앙화, 금융의 온전한 혁신을 위한 첫 발을 내딛었다. 이를 위한 수많은 인프라와 확장성을 위한 노력, 그리고 탈중앙성이라는 가치를 놓치지 않기 위한 재단과 검증인의 기여가 블록체인 생태계에 새로운 매스 어돕션의 발자취를 남기기를 바라며 이 글을 마무리한다.