이번 글에서는 최근 이슈가 되고 있는 Layer3 기반의 Fractal Scaling 에 대해서 알아보고자 한다. 이 개념은 Rollup Centric 의 최종단계라고 할 수 있는 Rollup on top of Rollup 을 통해 무한한 확장성을 지원하면서도 모든 Rollup 들이 Ethereum의 Security 를 상속받는 구조를 그리고자 한다.
먼저 Fractal 이라 함은 아래의 그림과 같이 크기만 다른 동일한 모양이 서로 연결되어 나타내는 모양을 일컫는다.
Rollup 은 Compression!!
먼저 Rollup 의 효용성에 대해서 살펴보자. Rollup 이 블록체인 상에서 Scalability 의 해결책으로 제시된 이유는 Compression 이다. 블록체인은 한정된 자원에 대해 사용 비용을 부과함으로써 Security 를 확보하는 방식이다. 즉 해당 자원의 무분별한 사용을 막기 위해 “Economic”적인 요소를 더하였고, 이를 여러 Entity가 합의를 통해 네트워크가 안정적으로 유지될 수 있는 요인을 마련한다. 그래서 한정적인 자원을 효율적으로 쓰기위한 방법이 TPS 등 Scalability 문제를 해결하는데 매우 주요하다. 대표적인 자원으로는 Data 와 Computation 이다.
Computation (feat. Optimistic and ZK)
Computation 은 이더리움상의 스마트 컨트랙트를 동작시키는 트랜잭션들에 의해 실행될, 이미 배포되어 있는 스마트 컨트랙트의 특정 함수를 일컫는다. 해당 트랜잭션에 의해 수행되는 Computation 을 미리 계산하여 한 블록 안에 포함될 수 있는 총 Computation을 제한하게 된다. 해당 함수를 실행시켜야할 노드들에게 너무 많은 부하가 주어지지 않도록 Computation 을 제한하고, 이에 대해 비용을 부과한다. 그렇다면 Scalability를 해결하기 위해서는 Computation의 한 unit 이 여러 트랜잭션들을 처리할 수 있으면 된다. 처리한다는 의미는 트랜잭션들로 인한 상태 전이 (State Transition)을 검증할 수 있게 한다는 것이다. Rollup 에서 대표적인 Optimistic 과 ZK (Zero Knowledge) Rollup 둘다 일정한 Computation 이 더 많은 트랜잭션에 대한 검증을 나타낼 수 있도록 한 방식이다. 먼저 Optimistic Rollup 은 Batch 에 포함된 트랜잭션들에 대한 처리를 Ethereum 상에서 (On-chain) 별도로 하지 않는다. 즉 Computation 을 0으로 만든 경우이다. 해당 Batch에 대한 검증은 Off-chain 즉 제 3자가 담당한다. 제 3자가 Batch를 통한 상태전이의 유효성을 검증하는데 충분한 시간을 주는 것이 필요하다. (이것이 Optimistic Rollup 이 Finality가 일주일 걸린다고 하는 부분이다.) ZK Rollup 은 zkp (zero knowledge proof)를 통해 최소한의 Computation으로 다수의 트랜잭션이 포함된 Batch의 유효성을 검증한다. 영지식 증명을 통해서 상태전이의 유효성을 증명할 수 있고 해당 영지식 증명만 이더리움의 On-chain 상에서 검증하게 된다. (On-chain 상에서 검증이 이뤄지기 때문에 Finality가 바로 주어진다.)
Data
Data 는 스마트 컨트랙트에서 저장하는 값이나 트랜잭션에 포함된 Call data 들을 일컫는다. 블록체인 상의 데이터 저장에 대해 비용을 부과함으로써 무분별한 자원 낭비를 막는 요인이 된다. 이 또한 동일한 양의 데이터가 더 많은 트랜잭션의 정보를 담고 있으면 Scalability 확보에 도움이 된다. Rollup 에서는 Batch 에 포함될 데이터를 압축시키는 것이 중요한데, Optimistic Rollup 은 압축할 수 있는 정보가 한정적이다. 왜냐하면 제 3자가 Batch 에 포함된 트랜잭션들을 제 3자가 Off-chain 에서 검증해야 하기 때문에 검증에 필요한 데이터들을 모두 포함하고 있어야 한다. 트랜잭션의 데이터 량에서 큰 부분을 차지하는 서명(Signature)가 포함되어 있어야 한다. 또한 별도의 Computation을 On-chain에서 하지 않기 때문에 압축 자체의 ‘Integrity’를 보장할 수 없다. ZK Rollup 은 영지식 증명을 이용하면 이 Integrity 를 보장할 수 있기에 필요한 만큼의 데이터 압축이 가능하다. 즉, Batch 에 대한 상태 전이의 유효성을 증명할 때 데이터 압축, 예를 들어서 트랜잭션의 서명에 대한 검증을 포함하게 되면, 트랜잭션에서 서명값을 제거할 수 있게 된다.
위 Optimistic과 ZK Rollup 의 동작방식을 통해 Rollup on top of Rollup 컨셉을 이해할 수 있다. Rollup 의 대상이 되는 Batch 내 하나의 트랜잭션이 또다른 더 많은 트랜잭션을 내포하게 된다면 무한한 Scaling 이 가능한 것이다. 다만 Computation 과 Data 의 Compression 이란 관점과 Rollup 이 이더리움으로부터 Security 를 상속받는 원리를 따져보면 그 한계가 존재한다. 먼저 Computation 관점에서 Rollup on top of Rollup 은 적용 가능하다. 최근 ZK-EVM 영역에서도 이슈가 되고 있는 Recursive SNARK/STARK 또는 Proof Aggregation를 이용하면 된다. 즉, Rollup 의 Batch 에 대한 상태 전이의 유효성을 증명하는 영지식 증명을, 그 Rollup 이 속한 부모(Parent) Rollup 의 트랜잭션에서 검증하고, 이 검증을 제대로 했다는 Integrity 를 증명하면 된다. 이를 통해서 최종적으로 이더리움에 전달된 영지식 증명을 On-chain 에서 검증하면 Ethereum의 Security를 상속받을 수 있게 된다. 다만 Data 의 경우는 이야기가 달라진다.
이더리움의 Security 를 상속받는 방법 : Data
Rollup 들의 Security 를 확인하는 방법은 간단하다. 해당 Rollup 의 Operator 가 작업을 멈추거나 악의적인 행동을 했을 경우, 이를 복구 시킬 수 있는가, 또는 Rollup 상의 자신의 자산을 이더리움으로 exit 할수 있는지를 보면 된다. 현재 Layer2 의 Rollup 에서는 해당 네트워크의 상태를 이더리움 상의 연계된 스마트 컨트랙트에 저장한다. Optimistic Rollup 의 경우 제 3자가 상태 전이를 확인할 때 필요한 트랜잭션 정보 전체, 또는 ZK Rollup 에서 영지식 증명을 검증할 때 필요한 트랜잭션 정보들이 저장되는 데이터들이다. 이 데이터들은 네트워크의 최종상태를 항상 가지고 있게 된다. 이와 같은 방식 때문에 Layer2의 Operator 가 갑작스레 작업을 멈출 경우, 사용자들은 이더리움 상의 데이터로 해당 네트워크의 최신 상태 또는 자신의 자산을 증명할 수 있다. 증명한 후 exit 를 하던지 아니면 네트워크를 재가동 시킬 수 있게 되는 것이다. 이 때 Source of truth 가 되는 것이 이더리움에 저장된 데이터이다. 이렇게 Security 를 확보하게 된다.
이 경우를 Layer3 에 대입할 경우, Layer2 대비 고려해야할 상황이 하나 더 생긴다. 즉 Fractal Scaling 또는 Rollup on top of Rollup 을 이상적으로 구축하기 위해서는 Layer3 의 데이터가 Layer2에 저장되어야 한다. 다만 이 경우, Layer2 의 Operator 가 데이터를 다 날려버린다면?? Computation 의 경우, Layer3 의 Computation 이 Layer2 의 Computation 증명 때 포함될 수 있기 때문에 (by recursive SNARK 등) Layer3 에 대한 별도의 Computation 이 이더리움에서 수행될 필요가 없다. (Layer2 의 Computation 검증이 Layer3 의 Computation 검증을 recursive 하게 포함하고 있기 때문이다.) 다만 Data 의 경우, Layer2 의 Operator를 믿지 못하기에, 이더리움의 Security 를 상속받으려면 Layer3 의 Data 또한 별도로 이더리움에 저장되어야 한다.
그렇기 때문에 이더리움의 제한된 공간을 Layer3 또한 사용하는 결과로 이어지기에 Fractal Scaling 에서 바라는 구조가 구성되지 못한다. (Fractal Scaling 이 되려면 각 Layer 는 자신의 Parent Layer 에게만 의존해야 한다.)
이러한 한계점을 이해하고 다음을 살펴보자.
Layer3 가 의미 있는 경우?!
먼저 모든 use-case 가 Layer3 로써의 가치를 지니지는 않을 것이다. Finality 등의 트레이드 오프가 존재하기 때문이다. 그렇다면 어떤 경우, Layer3 로 구축하면 좋을까?
App-specific Layer!!
먼저 특별한 기능을 지원하는 프로토콜의 경우이다. 특별한 기능이라 하면 트랜잭션 처리, 검증에 있어서 부가적인 Computation 비용이 발생하는 경우를 일컫는다. Privacy-Preserving 이 그 예로 들수 있다. Privacy 를 지원하기 위하는 하나의 방식으로 영지식 증명을 기반으로 할 수 있으며, 이 경우 트랜잭션 처리에 영지식 증명 검증 등의 추가적인 연산이 발생한다. 블록체인에서 연산은 모두 비용으로 이어지기때문에 이러한 연산은 Off-chain 에서 처리하는 것이 훨씬 이득이다. 그렇기 때문에 Layer3 에서 Privacy-Preserving Tx 를 Batch 로 처리해주고, 그 결과만 Layer2 에 저장하게 된다면 의미있는 use-case 라고 볼 수 있다.
또는 Scaling 을 확보하는 방식을 달리 할 수 있다. Layer2 가 일반적인 Scaling을 목표로 한다면 Layer3는 일종의 Customized Scaling을 타겟팅하는 것이며 이는 Storage Strcuture 나 Data Availability compression 등을 Layer3 에 특화되어 구성하는 것이다.
마지막으로 Security 의 레벨이 약한 경우 Layer3 로 구축할 수 있다. 즉 Layer2 의 경우는 Rollup 즉, 데이터를 이더리움 상에 저장함으로써 Fully Security 를 상속받게 할 수 있지만, Layer3 에서는 Data 를 이더리움이 아닌 제 3의 Data Availability Layer (Polygon 의 Avail 이나 Celestia, 또는 Starkware 의 Validium) 에 저장하는 것이다. 이더리움보다 Security 가 낮을 수 있기에 Data 손실을 감안해야한다. 그러면서도 매우 싼 비용으로 트랜잭션을 지원할 수 있는 App일 경우 Layer3 로 구축을 고려해볼 수 있다.
Layer2 as composability layer?!
Layer3 구조로 갈 경우, Rollup-Centric 에서 이점을 가져갈 수 있는 경우가 생긴다. 바로 Rollup 간의 Composability 를 확보할 수 있다. 현재 이더리움 상의 Layer2 들간에 트랜잭션을 주고받기 위해서는 이더리움을 꼭 거쳐야 한다. Rollup A 가 이더리움 상에 Rollup B 로 전달하고자 하는 트랜잭션 또는 데이터를 저장하면, Rollup B 는 이를 전달 받아 해당 네트워크 상태에 적용하게 된다. 이 경우 이더리움으로의 트랜잭션이 발생하게 되므로 매우 큰 비용을 지불하게 된다. Layer3 구조를 확보한다면 Layer2 가 기존의 이더리움처럼 Cross-rollup 의 트랜잭션 처리를 담당할 수 있다. 그것도 이더리움과 비교하여 매우 저렴한 비용으로 말이다. 그래서 Layer3 가 App-specific 하게 구성되면 이 App 들간의 Communication 이 이더리움이 아닌 Layer2 를 통해서 발생하기 때문에 Rollup 간의 Composability를 확보하는 데 비용적인 측면에서 꽤나 유용하다.
만약 모든 Rollup 이 ZK-rollup 으로 이뤄진다면 이 Composability 는 또다른 방식으로 구성될 수 있다. (Optimistic Rollup 은 Finality 가 Challenge Period 일주일 기간 때문에 아무래도 Composability 확보에 어려움이 존재한다. 이에 반해 ZK-rollup 은 Instant Finality 가 주어지므로 조금은 다른 방식으로 구성할 수 있게 된다.) 즉 Rollup A 에서 Rollup B 로 (둘 다 Layer3) 트랜잭션을 보내는 경우를 생각해보자. Rollup A 에서 트랜잭션이 발생했음을 A 의 Batch에 대한 영지식 증명으로 증명할 수 있다. 일종의 Membership proof 즉, 해당 Batch 내에 A→B 의 트랜잭션이 포함된다는 것이다. A 의 영지식 증명은 Layer2 로의 트랜잭션으로 구성되어 검증이 될것이며, 이 검증의 정확성이 Layer2 의 영지식 증명 생성 당시 증명될 수 있다. 그리고 Layer2 의 영지식 증명은 이더리움상에서 검증되어 이더리움의 새로운 블록에 포함되게 된다. 이 프로세스를 통해 (A→B 의 트랜잭션) - (Layer3의 영지식 증명) - (Layer2의 영지식 증명) - (이더리움의 최신 블록) 의 연결고리가 확보 된다. 이 연결고리의 Integrity 를 영지식 증명을 생성하여 증명할 수 있다.
Rollup B 의 경우를 살펴보면 B 가 Trustless 하게 믿을 수 있는 것은 이더리움의 최신 블록이다. 그럼 이 정보를 기반으로 연결고리의 Integrity에 대한 영지식 증명을 검증할 수 있다. 검증을 통과한다는 것은 Rollup A에서 A→B의 트랜잭션이 실제로 발생했다는 것이기에, Rollup B 에서는 해당 트랜잭션을 자신의 상태에 반영할 수 있게 되는 것이다.
Layer3의 Fractal Scaling 을 위해서?!
Layer3 는 아직 연구 초기 단계이다. 진정한 Fractal Scaling 을 구축하려면 모든 Rollup 이 이더리움의 Security 를 상속받으면서도 자신의 Parent Rollup 에게 의존하는 구조가 되어야 한다. 지금처럼 Layer3 의 데이터를 이더리움에 저장하는 방식은 지양되어야 한다.
Security 다른 관점에서 다시 보기
이를 해결하기 위해서 Security 상황을 다시한번 살펴보자. Layer3 에서의 Security 를 확보했다는 이야기는 Layer2가 동작을 멈추거나 악의적인 행동을 했을 경우 Layer3 에 있는 자산을 이더리움으로 “Trustless”하게 Exit 할 수 있어야 한다는 것이다. 기존의 방식을 말해보자면 Trustless 하게 Exit 하기 위해서 Layer3 의 데이터를 이더리움에 저장하는 방식이였고, 해당 데이터는 Layer2의 Computation과 Data 와 연계되어 저장된다.
즉, Layer2 가 오동작 했을 때 Layer3 는 이렇게 주장할 수 있다.
“내 연산과 데이터는 Layer2 에서 처리되었으며, Layer2 의 연산과 데이터를 보면 이를 증명할 수 있다.”
이를 생각해보면 결국 Layer2 의 Data Availability 문제로 귀결됨을 알 수 있다. Layer2 가 Layer3의 연산과 데이터를 처리했다는 결과 데이터를 제 때 Publish 한다면 Layer3 는 그것을 기반으로 이더리움 네트워크에게 검증 받을 수 있는 것이다.
Layer2 의 Data Availability 확보
Layer2 의 Data 가 모두 Publish 되었음을 어떻게 보장할 수 있을까? 보통 Layer2 의 Operator 를 하나가 아닌 여럿을 둠으로써 이를 해결하고자 한다. 즉 Decentralize 방식을 적용하여 하나의 Operator 가 오동작 하더라도 다른 honest 한 Operator 가 이를 커버해주는 방식이라면 Layer3 가 Layer2의 데이터를 확보할 수 있는 가능성이 높아진다. 하지만 이 경우 Layer2 의 Scalability를 일정부분 포기해야할 수 있다. 보통 Single Operator가 해당 Rollup 의 트랜잭션들을 처리함으로써 Scalability를 최대한 확보하는 방식이기에, Data Availability를 위해서 하나 이상의 Operator 간의 합의를 이룬다면 Scalability가 떨어질 수 밖에 없다.
Layer2 의 Data Availability 를 다른 방식으로 확보할 수 있다. 해당 Data 가 필요한 Layer3 들이 이를 자체적으로 검증하고 Layer3들이 투표를 통해 Majority를 통해 확실히 할 수 있다. 그렇다면 이를 투표를 프로토콜 레벨에서 강제할 수 있는 방안이 필요하다. 이는 Layer2 의 최신 상태 검증이 이더리움 상에서 일어날 때 하나의 조건을 추가함으로써 강제할 수 있다. 즉, Layer2 의 최신 상태 업데이트를 할 때 이에 대한 검증 통과 뿐만 아니라 해당 상태와 연계된 데이터들이 전부 Publish 되었음을 해당 Layer2 에 속한 Layer3들의 Majority 가 동의해줘야 상태 업데이트가 일어나게 하면 된다. Layer2 입장에서는 자신의 상태를 업데이트하기 위해서는 Layer3 들의 동의가 필요하기에 데이터를 지속적으로 Layer3 에게 Publish 할 것이다. Layer3 입장에서는 이 Layer2의 데이터를 저장하고 있다가, 만약 비상상황 발생시 이 데이터를 기반으로 Layer3 의 상태 증명을 이더리움에게 하게 된다면, exit 가 가능하게 된다.
다만, Majority 투표라는 개념에서도 알수 있듯이 Trust Assumption 이 발생하게 된다. 즉, Layer3가 실제로 Data 를 Publish 되었을 경우만 투표할 것이라는 가정이 포함되게 된다. 기존의 Trustless 과 비교되는 부분이다.
결론
Layer3 구조가 주장하는 Fractal Scaling 은 Scalability 나 Composability 관점에서 매우 Promising 한것은 사실이다. 특히 이더리움을 Base Layer 로 가지고 있기에 Security 측면에서 다른 Cross-chain 과 비교할 수 없을 장점을 가지게 된다. 더군다나 최근 심각하게 발생하는 Multi-chain간의 Bridge hacking 을 생각해본다면 더 나은 접근법인 것은 사실이다. 하지만 아직 해결해야할 문제들이 남아있으며 이는 지속적인 연구와 실험이 필요해 보인다.