모듈러 블록체인으로의 진화

기존 블록체인의 확장성을 해결한 다음 세대의 구조를 제시한다?!

Monolithic vs Modular 

모듈러 블록체인이란 개념은 21년 중순부터 본격적으로 논의되기 시작하였다. 사실 ‘모듈’은 일반 프로그래밍에서 익숙한 개념이다. 예를 들면 안드로이드 같은 OS는 파일, 디스플레이, 사운드 등 특정 기능을 다루는 개별적인 모듈로 조합하여 시스템을 구성한다. 다만 이 모듈들은 하나의 물리적인 시스템 내에 리소스를 공유하며 존재할 수도 있고 아닐 수도 있다. 모듈 간 리소스를 공유하여 연결된다면 Monolithic 구조라고 하며, 독립적으로 구성되어 연결되면 모듈러가 아닌 마이크로서비스 Microservice 구조라고 부른다. 하지만 이미 모듈러 블록체인이란 용어로 통용되기에 그대로 사용하고자 한다.

현재 블록체인은 Monolithic 인가?

이더리움이나 대부분의 현존하는 블록체인은 모든 기능이 하나의 노드에서 동작한다는 측면에서 Monolithic 구조이다. 다만 이전에도 모듈러 방식을 적용한 경우가 있으며 코스모스 SDK가 대표적이다. 코스모스 SDK 에서는 합의 모듈인 텐더민트와 어플리케이션 모듈을 분리하고 두 모듈은 ABCI (Application BlockChain Interface) 라는 프로토콜로 연결된다. 

합의 모듈은 다른 노드로부터 전달받은 블록 내의 트랜잭션의 유효성(Validity) 체크를 직접하지 않는다. 이는 어플리케이션 모듈의 역할이며 합의 모듈은 트랜잭션을 ABCI를 통해 어플리케이션 모듈로 전달하고 그 결과값만 전달 받은 후 합의 여부를 결정하게 된다. 다만 이 두 모듈은 하나의 노드에서 동작하기에 여전히 Monolithic 구조라고 할 수 있다. 그렇다면 모듈러 블록체인은 어떤 기능들을 나누자고 제안되었나? 크게 세 부분인 합의(Consensus), 실행(Execution) 그리고 데이터 가용성(Data Availability) 이다.

무엇에 대한 합의인가?

결론부터 말하자면, 블록체인에 담길 트랜잭션의 순서에 대한 합의이다. 블록체인은 일종의 State Transition Machine인 분산 원장이며, 해당 원장의 State 는 간단하게는 Account Balance 이다. (누가 얼마 가지고 있는가) 이더리움은 스마트 컨트랙트내에서 개발자가 State 를 추가적으로 정의할 수 있게 되었다. 이러한 State 의 전이 (Transition)을 일으키는 것이 트랜잭션이며 최종 State 는 이전 State 에 적용되는 트랜잭션의 순서에 따라 달라지게 된다. 그래서 합의를 이룬다는 것은 분산 원장에 대한 동일한 View 를 가지도록 하는 과정이며 즉 One Single Source of Truth가 목적이다.

무엇을 실행하는가?

트랜잭션을 해석하여 State Transition을 통해 다음 State 를 계산하는 것을 실행이라고 한다. 이더리움은 EVM이라는 실행환경을 통해 스마트 컨트랙트의 트랜잭션을 해석한다. EVM 이라는 통제 가능한 환경에서 트랜잭션이 실행되기에 보안성이 높은 반면, EVM 에서 제공된는 동작만 할 수 있기에 제한적이라는 단점이 있다. 이와는 다르게 코스모스의 경우 트랜잭션의 해석을 어플리케이션 모듈 개발에 일임하기에 자유도가 높은 반면, 보안성에선 아무래도 약한 트레이트 오프가 생긴다. 모듈러 블록체인에서는 

데이터 가용성이란 무엇인가?

트랜잭션 실행에 필요한 데이터를 얻을 수 있느냐에 대한 내용이다. 즉 합의된 최신 블록을 검증하기 위해서는 1) 블록헤더와 2) 블록 내 트랜잭션들이 필요하다. 해당 트랜잭션들을 기반으로 머클 트리를 구성하고 머클 루트를 블록 헤더에 포함시킴으로써 트랜잭션들이 최신 블록에 포함되었음을 증명할 수 있다. 트랜잭션들을 공개하는 것은 선의(Altruism)에 의존할 수 없다. 이는 Attack Vector로 활용 가능하다. 비트코인에서 풀노드의 동작을 다시 되짚어보자면, 새로운 블록 n이 만들어지면 이를 네트워크에 전파하고, 전달받은 블록 n을 검증하고  블록 n+1 을 만든다. 

여기서 데이터 가용성은 전달받은 블록 n을 검증할 때 필요한 데이터인 트랜잭션들을 다 가질 수 있는지에 대한 여부다. 블록 n을 만든 마이너는 해당 데이터를 전달하지 않음으로써 다른 노드들이 검증을 못하게 되어 자신만 새로운 블록을 만들 수 있는 ‘유아독존'이 될수 있다. 비트코인에서 데이터 가용성은 경제학적 장치로 해결한다. 즉, 검증받지 못하면 새로 만든 블록이 채택받지 못하고, 채택받지 못하면 리워드를 받을 수 없으니 리워드를 위해서라도 트랜잭션들 모두를 공개할 수 밖에 없다. 데이터의 공개 여부를 파악하는 것은 최신블록의 유효성을 검증하는 데 있어서 매우 중요하다.  블록을 생성하고 검증하는 풀노드의 경우 이러한 방식으로 데이터 가용성을 쉽게 파악할 수 있다. 하지만 라이트 클라이언트 (Light Client)는 경우가 다르다. 모바일폰같이 제한적인 리소스 때문에 블록 헤더만 동기화 받기에 해당 블록이 실제로 검증되었는지 여부는 파악하기 어렵다.

그럼 Monolithic 블록체인은 왜 문제인가?

확장성(Scalability) 가 계속적인 이슈로 남아있다. Monolithic 블록체인에서 합의를 이루기 위해서는 최신 블록으로의 상태 전이를 재계산 즉 실행하는 방법밖엔 없다. 또한 실행하기 위한 트랜잭션 데이터를 확보해야 한다. 이 모든 기능이 하나의 노드에서 일어나야 하기에 확장성의 제약이 생기는 것이다. 이더리움 진영에서 최근 확장성 해결을 위해 롤업 중심(Rollup-Centric)의 Layer 2 개발이 활발하다. 롤업은 모듈러 블록체인에서 어떠한 역할을 하는지 알아보자.

롤업은 무엇을 말아올리나?

말 그대로 여러 트랜잭션들을 둘둘말아 하나의 트랜잭션에 포함시키는 오프체인(Off-chain, 이더리움을 온체인으로 본다면 그 외 환경에서 일어나는 것은 전부 Off-chain 이다.) 방식이다.

이는 여러 트랜잭션들에 대한 실행을 오프체인에서 수행하여 상태 전이를 계산하고 그 결과값, 즉 최신 State 만 온체인에 하나의 트랜잭션으로 기록하게 된다. 원래대로라면 온체인에서 수행되어야할 여러 트랜잭션들이 하나로 롤업되니 온체인에서의 블록 공간이나 연산 비용등을 절약할 수 있게 되는 것이다. 다만, 실행 기능을 오프체인으로 넘기는 것으로 확장성을 해결하는 것으로, 데이터 가용성이나 합의의 경우 여전히 Layer1 인 이더리움에 의존하게 된다. (여기서 롤업의 데이터 가용성은 최신 State를 검증하기 위한 트랜잭션 데이터에 대한 것이다.) 그렇기에 이더리움의 제한적인 블록 크기 등으로 저장할 수 있는 롤업 결과값 및 데이터가 한계가 있기에 롤업의 TPS가 제한받게 된다. 기록된 결과값에 대한 검증을 어떻게 하는지에 따라 옵티미스틱(Optimistic) 롤업과 ZK 롤업으로 나뉘게 된다. 

옵티미스틱 롤업의 경우 사기증명(Fraud Proof) 기반이다. 일단 옵티미스틱이란 용어 자체가 기록된 최신 상태에 대해 ‘잘 계산했겠지!'라고 긍정적으로 바라보는 것이다. 그래서 데이터 가용성을 위해 (1) 최신 State와 (2) 해당 State 를 계산한 트랜잭션들을 이더리움상에 기록할 당시에 상태 전이의 정확성을 검증하지 않는다. 검증은 기록된 후 제 3자인 검증자(Verifier)가 수행하며 만약 검증 실패시 Challenge 를 통해 롤업 담당자에게 페널티를 부과하게 된다. (보통 롤업 담당자가 되기 위해 일정 금액을 예치해놓게 되며 이는 페널티 부과 대상이 된다.) 다만 이 Challenge 기간이 짧을 경우 검증자가 수행할 시간이 충분치 않을 수 있기에 보통 일주일 정도 검증 기간이 주어진다. 즉 해당 블록에 담긴 트랜잭션에 대한 Finality 가 일주일 후에 주어지는 것이다. 검증자가 검증을 수행하려면 트랜잭션들의 유효성까지 파악해야하기에 사용자의 서명값등이 포함되어야하기에 이더리움에 기록할 데이터가 커진다. 옵티미스틱 롤업이 100 TPS 등으로 제한되는 것이 이러한 데이터 크기 때문이다.

ZK 롤업은 유효성 증명(Validity Proof) 기반이다. 이더리움에 기록될 데이터는 (1) 최신 State 와 (2) 상태 전이의 정확성 를 증명하는 영지식 증명(zk proof), 그리고 (3) 영지식 증명을 검증하기 위한 트랜잭션 정보들이 포함된다. 영지식 증명을 통해 최신 State 의 유효성이 검증될 수 있기에, 이더리움 상에서 이 검증 역할을 진행하게 되며 검증 통과 즉시 Finality가 주어진다. 또한 영지식 증명 생성의 동작 방식에 따라 (3)의 크기를 줄일 수 있다. 영지식 증명 생성시에 해당 트랜잭션의 유효성을 검증하기 위해 서명값을 체크한다면 (3)에서 각 트랜잭션의 서명을 없앨 수 있다. (영지식 증명이란 특정 연산이 수행되었음을 증명하는 것이다. 서명값 체크가 수행되었음을 영지식 증명으로 알 수 있다면 해당 증명만 검증하면 되기에 서명값 자체 공유는 필요 없는 것이다.) 이렇게 이더리움에 기록되는 데이터를 최소화 할 수 있기에 롤업 TPS 가 1,000까지도 이야기 되는 것이다.

이렇게 이더리움의 제한적인 상황을 해결하고자 하는 것이 모듈러 블록체인이며 셀레스티아(Celestia) 가 대표적인 리딩 프로젝트이다.

기존의 접근은 없었나?

롤업상의 데이터 가용성 문제로 TPS 확장 한계가 있다는 것을 풀고자 했던 프로젝트는 스타크웨어(Starkware)의 밸리디움(Validium) 이 있다. 검증에 필요한 데이터를 이더리움에 저장하는 롤업등과는 다르게, 밸리디움의 경우 DAC (데이터 가용성 위원회) 를 운영하여 오프체인에 해당 데이터를 저장한다. (DAC는 MPC (Multi-Party Computation) 기반으로 동작하기에 MPC 자체의 시큐리티 이슈가 항상 존재한다.) 이외에 폴리곤의 ZK-verse에서도 데이터 가용성을 위한 프로젝트인 Polygon Avail 이 있다.

셀레스티아는 어떤 점이 다른가?

먼저 셀레스티아는 Lazy Legder 라 불리던 프로젝트였다. (합의된 트랜잭션들의 실행을 즉시 하는게 아닌 Lazy하게 한다는 컨셉이다.) 실행을 제외한, 합의와 데이터 가용성 레이어만 가진 PoS 블록체인이며 트랜잭션의 실행은 다른 블록체인에서 진행하는 것이다. 즉 합의 대상인 트랜잭션의 검증은 이뤄지지 않으며 그 순서만 합의를 이루게 된다. 쉽게 말해 셀레스티아로 전달되는 데이터는 적절한 수수료만으로 무조건 저장하게 되는 것이다. 이 경우 셀레스티아의 풀노드가 가져야할 데이터가 매우 커지기 때문에 Erasure Coding 이란 방식으로 해결하고자 한다. 즉 일반 블록체인의 풀노드의 경우 블록체인에 포함된 데이터 전체를 동일하게 다 가지고 있어야 한다. Erasure Coding 은 데이터를 패리티 블록(Parity Block) 이라 불리는 일정 크기의 Chunk로 분할 하고 패리티 블록 일부만으로도 원본 데이터를 복구할 수 있는 방식이다. (실제 셀레스티아에 적용된 Erasure Coding의 방식은 Reed Solomon Code 이라 불리며 25%의 패리티 블록이 있으면 원본 데이터 복구가 가능하다. 자세한 로직은 이 아티클에서 다루지 않는다.) 

이러한 방식은 라이트 클라이언트가 최신 블록을 검증하고자 할 때 필요한 데이터를 검색할 때 25% 이상이 확보된다면 데이터 가용성에 대한 이슈가 없음을 확신할 수 있게 되기에 Monolithic 구조와 차이점이 될 수 있다. (그래서 라이트 클라이언트 수가 증가하면 데이터 가용성에 대한 체크가 더 원할히 이뤄지고 네트워크 자체의 시큐리티가 보강된다고도 이야기한다.) 

또한 하나의 데이터 가용성 레이어에서 여러 실행 레이어가 동작하기에 데이터가 뒤섞이게 된다. 효율적인 검색을 위해 ‘Namespaced’ Merkle Tree 라는 개념을 적용하여 실행 레이어 및 연관된 앱등은 관련된 데이터만 받을 수 있도록 인덱싱 기능을 지원한다.

현재까지 블록 사이즈 제한이 없다. 이더리움의 경우 블록 공간이 제한적이기에 경쟁이 발생해서 Gas fee 가 올라가게 되는데, 이 제한을 없앰으로써 데이터 저장에 대한 비용을 Constant 하게 유지할 수 있을 것이라는 주장이다. 이럴 경우 Spam Attack 의 우려, 즉 누구든 쓰레기 값을 올려서 저장공간을 낭비하는 공격을 생각해볼 수 있다. 쓰레기 값이 올라온다면 블록 공간이 낭비되고 이 공간을 공유하는 롤업같은 실행 레이어가 영향을 받게 되는데 현재는 허가된 사용자들이나 Bidding Fee 모델을 고려중이다. 하지만 이 공격으로 피해받는건 실제 데이터를 저장하는 스토리지 노드일 뿐이기에 셀레스티아 네트워크 참여자 대부분은 스팸 공격에 무관심하다. 합의 노드는 패리티 블록 형태로 데이터 가용성 관한 증명만 저장할 것이고 사용자는 Namespaced Merkle Tree 에서 데이터 받아오는 것만 할 뿐이다.

샤딩과 동일한 접근 아닌가?

비슷한 접근이긴 하다. 샤딩의 동작 방식은 이더리움의 밸리데이터를 공유하여 각 샤딩에서 발생한 트랜잭션들을 검증한다. 하지만 이경우에도 각 샤딩에서 발생한 트랜잭션들은 그 샤딩에 속한 밸리데이터들이 전부 가지고 있어야 한다. 또한 밸리데이터 수가 적을 수 있기에 Corrupt 되는 보안 저하가 발생할 수 있다. 즉 보안이 저하되는 대신 데이터를 게시할 수 있는 더 많은 블록 공간을 제공하여 데이터 가용성 문제를 해결하고자 하는 것이 샤딩이다. 하나의 실행 레이어에서 동작하는 제한점을 가진 것 또한 셀레스티아와의 차이점이다. 즉, 롤업이나 샤딩이나 둘다 데이터 가용성 문제를 완전히 해결 못한다. Security 와 Decentralization 에서의 Trade off 가 발생하는데 이를 셀레스티아는 이 Trade off 를 최소화 한다고 보면 된다.

모듈러 블록체인이 갖는 의의는?

일단 이더리움 상의 제한된 블록 사이즈의 영향에서 벗어나 더 많은 실행 레이어의 최신 State 및 트랜잭션 데이터들을 담을 수 있게 되어 확장성을 확보한다. 또한 동일한 데이터 가용성 레이어를 사용하는 실행 레이어들끼리의 상호 운용성(Interoperability)를 확보할 수 있다. 이는 예전에 비탈릭이 이야기한 멀티체인과 유사한 접근이다. 즉 각기 다른 데이터 가용성 레이어를 가진 체인들이 서로 연결되어 통신하는 크로스 체인 방식은 보안 이슈가 터질 가능성이 많다. (이전 세션인 ‘브릿지 이야기'에서도 다뤘다. 보통 크로스 체인상의 이동은 Lock & Mint 기반 인데 특정 자산을 Lock 했던 체인 A 에서 re-org나 악의적인 행동이 일어날 경우 그 자산을 Mint 했던 체인 B 에서 이를 되돌릴 수 있는 방안이 마땅히 없다. 이는 데이터 가용성 레이어가 동일하다면 이 레이어가 Settlement 역할을 하기에 대처가 가능하다.이때 이슈가 안되는 것은 롤업 케이스를 보면 알 수 있다. 롤업에서 Malicious Attack 이 일어나도 여기서의 Asset 은 DA Layer 를 벗어나지 않은 것이기에 언제든 복구 가능하다. ) 그래서 멀티체인의 ‘체인'은 데이터 가용성 레이어를 공유하는 블록체인, 실행 레이어의 집합이라고 보면된다.

Web 2.0 에 비유적으로 결론을 지어보자면, AWS 같은 클라우드 서비스는 물리적 기기를 공유하는 Virtual 기기 상에 웹사이트를 론칭하도록 한다. Web 3.0에서 셀레스티아는 합의 및 데이터 가용성 레이어를 공유하는 어플리케이션 특화된 체인 상에 여러 Dapp들을 론칭하는 걸 가능하게 해 준다.