[Research] 레이어2, 정말 이대로 충분한가?
확장성 솔루션의 검증 체계가 가진 함정에 대하여.
사전 고지: 본 글은 단순 정보 제공을 위해 작성 되었고 투자, 법률, 자문 등 어떤 부분에서도 책임을 지지 않습니다. 특정 자산에 대한 투자를 추천하는 것이 아님을 밝히며, 본문의 내용만을 바탕으로 투자에 대한 의사결정을 내리지 마십시오.
요약
1) 확장성 솔루션의 목표는 확장성의 극대화를 추구하는 동시에 보안성과 분산화를 레이어1에 온전히 의존하는 것이다.
2) 옵티미스틱 롤업과 ZK 롤업의 검증체계는 계산 무결성(computational integrity)만을 검증하고 있으며, 오퍼레이터의 블록 생성 권한인 트랜잭션 선택과 순서 결정에 대한 감시체계가 없다.
3) 오퍼레이터가 이 권한을 남용하면 레이어2상의 트랜잭션이 검열되거나 악의적인 MEV 착취에 노출될 가능성이 매우 크다.
4) 레이어2의 참여자와 레이어1은 안전한 블록 생성에 대해 오퍼레이터의 공정성을 신뢰해야하며, 명확한 감시 체계가 만들어지지 않는 이상 레이어2 솔루션의 채택은 그 안에 보관된 자산 제어에 대한 중앙 집중화를 야기할 수 있다.
5) 한편, 오퍼레이터의 공정성을 “신뢰”가 아닌 “경제적 확보”를 위해 합의 알고리즘 혹은 PBS와 같은 경쟁 체제를 도입한다면, 확장성의 극대화가 저하되기 때문에 확장성 솔루션의 목표에 도달하기 어려우며, 선택되는 방안에 따라 레이어2의 보안성을 위협할 수 있다.
6) 필자는 완전한 확장성 솔루션이 되기 위해서는 블록 생성에 대한 공정성을 감시할 수 있는 체계가 암호학 방식으로 만들어져야 한다고 주장한다.
레이어 2의 오퍼레이터가 가진 블록 생성 권한을 감시하지 못하면, 확장성을 위한 레이어 2 솔루션의 채택은 그 안에 보관된 자산 제어에 대한 중앙 집중화를 야기할 수 있다.
1. 블록체인의 확장 솔루션
블록체인의 대표적인 논제인 블록체인 트릴레마(Blockchain Trilemma)는 2018년 비탈릭 부테린에 의해 처음 소개 되었다. 블록체인 트릴레마는 블록체인의 세가지 기본 요소인 확장성(Scalability), 보안성(Security), 분산화(Decentralization)를 하나의 블록체인 메인넷에서 모두 극대화하기 어려운 것을 의미한다. 과거부터 이를 해결하기 위해 PoS, 샤딩(Sharding), 사이드 체인(Side chain) 등 다양한 솔루션이 제안되어 왔으며, 오늘 다룰 레이어2 또한 이 문제를 해결하기 위해 고안된 솔루션이다.
레이어2는 블록체인 트릴레마에서 확장성을 극대화하기 위해 고안된 솔루션이다. 확장성 솔루션의 목표는 블록체인 상에서 일어나는 거래를 빠르고 저렴하게 처리하면서, 블록체인의 보안성과 분산화를 해치지 않는 것이다. 이를 위해, 레이어2는 보안성과 분산화를 블록체인 메인넷(이하 레이어1)에 의존하고, 확장성을 메인넷 이외의 곳에서 처리하는 방법을 선택하여, 세 가지 기본요소의 극대화를 하나의 메인넷이 가질 수 있도록 고안되었다.
레이어2에서 거래를 처리하는 방법
레이어2는 다수의 거래를 효율적으로 처리하기 위해 거래를 레이어1이 아닌 외부에서 처리한 후, 보안성과 분산화를 위해 거래의 처리 결과를 주기적으로 레이어1에 기록한다. 먼저 거래를 처리하는 방법에 대해 살펴보자.
블록체인에서 관리하는 정보는 사용자의 계좌 정보이다. 즉, 블록체인은 모든 사용자의 계좌에 현재 잔액이 얼마인 지 기록하고 있으며 이 정보를 상태(state)라고 한다. 계좌의 잔액 정보를 바꾸기 위해서는 돈을 다른 계좌에 송금하거나, 다른 계좌에서 내 계좌로 돈을 송금해야한다. 계좌의 잔액을 바꾸는 거래를 트랜잭션(transaction)이라 하며, 트랜잭션에 의해 잔액이 바뀌는 것을 상태 변화(state transition)라고 한다.
블록체인에 기록된 것은 이러한 상태 변화를 야기하는 트랜잭션과, 과거부터 현재까지 변화된 상태들이다. 블록체인의 상태 변화는 거래가 일어나는 순간에 발생하지 않으며, 합의 알고리즘에 의해 정해진 블록 생성 주기에 따라 마이너(miner)에게 선택되어진 트랜잭션에 의해 변화한다. 그 과정을 그림으로 살펴보자.
블록체인에서 관리되는 계좌를 총 3개 (A, B, C)라고 하자. 0번째 상태 (state #0)에서 A, B, C 계좌는 각각 3ETH, 0ETH, 1ETH를 잔액으로 가지고 있다. 이 계좌의 잔액은 1번 블록에 포함된 트랜잭션에 의해 바뀌며, 이 트랜잭션들은 1번 블록을 만드는 마이너에 의해 선택되어진다. 본 예시에서 1번 블록에 포함된 트랜잭션은 다음과 같이 3개이다.
- Tx1: A가 B에게 1ETH를 전송
- Tx2: A가 C에게 2ETH를 전송
- Tx3: B가 C에게 1ETH를 전송
트랜잭션은 블록에 포함되어진 순서대로 처리된다. 즉, 첫 번째로 포함된 Tx1에 의해 A와 B의 잔액이 먼저 계산된다: A(2ETH), B(1ETH). 이 후, Tx2와 Tx3가 차례대로 처리되면, 1번 블록에 의해 변화한 최종 잔액이 계산된다: A(0ETH), B(0ETH), C(4ETH). 이러한 과정으로 계좌의 최종 잔액이 반영되는 것을 상태 변화라고 하며, 상태 변화에 포함된 트랜잭션들의 계산을 거래 처리라고 한다.
레이어2는 그림 2와 같이 상태 변화를 야기하는 트랜잭션을 외부 (레이어2)에서 생성한다. 그리고 이에 대한 상태 변화 또한 레이어2에서 계산하고 레이어1에는 그 계산의 결과값만 주기적으로 기록한다. 만약 여기서 끝이라면, 레이어2는 블록체인 트릴레마를 해결하는 솔루션이 아니라, 보안성과 분산화를 포기하고 확장성만 극대화하는 것이 된다. 블록체인 트릴레마를 해결하기 위해서는 레이어1의 보안성과 분산화를 상속받을 수 있는 방법을 추가로 고안해야한다.
2. 계산 무결성(Computational Integrity) 증명
레이어1 입장에서는 레이어2 로부터 보내져온 정보는 검증되지 않은, 신뢰성이 부족한 하나의 외부 정보일 뿐이다. 따라서, 레이어1은 레이어2의 결과값을 아무런 절차없이 그대로 반영할 수 없다. 이에, 레이어2는 자신이 전송한 상태값이 레이어1에 기록해도 되는 값임을 설득하는 기능이 필요하다.
레이어2는 올바른 트랜잭션을 모아 상태값을 제대로 계산했다는 것을 레이어1에게 증명해야하며, 이를 계산 무결성(computational integrity)에 대한 증명이라고 한다. 이를 이해하기 위해, 레이어1 에서 발생한 트랜잭션과 이를 통해 변화한 상태 값을 우리가 신뢰할 수 있는 이유에 대해 알아보자.
레이어1이 해당 체인 내에서 트랜잭션과 그 상태값을 검증하는 방법은 재실행이다. 블록체인 상의 정보는 모두 공개되어있기 때문에 마이너가 블록을 만들어 다른 노드에게 전파할 때, 노드는 공개된 정보를 모두 다시 계산하여 블록에 포함된 트랜잭션의 유효성을 검증할 수 있다. 모든 연산을 재실행하여 검증하는 것은 그 만큼의 시간과 비용을 많이 발생시킨다. 하지만 이는 합의알고리즘이 의도한 바이며, 네트워크 안전성 측면에서 블록을 받은 모든 노드들은 이를 검증하는 것이 바람직하다.
레이어2에서 만들어진 트랜잭션과 그 상태 변화의 무결성을 레이어1에게 설득할 수 있는 가장 단순한 방법은, 레이어1에서의 방법과 마찬가지로, 모든 노드가 상태 변화에 포함된 트랜잭션으로 그 결과값을 다시 계산해보는 것이다. 레이어1의 노드가 재연산한 상태값이 레이어2가 전송한 값과 동일하다면, 레이어1은 레이어2의 정보를 문제없이 받아들일 수 있다. 하지만, 이 방법으로 소요되는 연산량은 레이어1에서 거래를 생성하고 처리하는 것과 다르지 않기 때문에 확장성이 저하되어 블록체인의 트릴레마는 해결되지 않는다.
레이어2 솔루션은 효율적인 설득을 위해 여러 가지 방법을 선택할 수 있다. 본 글에서는 가장 잘 알려진 방법인 옵티미스틱 롤업(optimistic rollup)과 ZK 롤업(ZK rollup)이 선택한 방법에 대해 다루고자 한다.
(1) 옵티미스틱 롤업과 ZK 롤업
본 글에서는 주제에 벗어나기 때문에 두 솔루션에 대한 비교를 다루지 않을 것이다. 하지만 필자는 옵티미스틱 롤업보다 ZK 롤업의 검증 방식이 더 유효하다고 믿으며, 이 주장의 근거 중 하나는 옵티미스틱 롤업의 검증자의 딜레마이다(이를 소개한 좋은 아티클은 남겨두겠다 [링크]). 또한, 필자는 검증자의 딜레마 이외에도 재귀적 증명(recursive zk proof)을 통한 검증 효율성 증가와 zkEVM 등에 대한 견해를 근거로 가지고 있으며, 기회가 된다면 이에 대해서는 다른 아티클에서 다루도록 하겠다.
옵티미스틱 롤업과 ZK 롤업의 동작 방법이 궁금한 독자를 위해 비탈릭의 글을 남겨두겠다. [링크]
A. 옵티미스틱 롤업
옵티미스틱 롤업은 이름 그대로 낙관적인 방식으로 레이어1을 설득한다. 즉, 옵티미스틱 롤업은 레이어2에서 전송한 값이 올바르다는 전제를 가지고 있다. 이로 인해, 레이어1은 특별한 검증 절차 없이 이 정보를 일단 기록한다. 그 이후, 정해진 기간 내에 해당 정보에 대한 어떠한 주장(challenge)도 없다면 레이어1은 이를 올바른 정보로 수용한다.
한편, 레이어2는 올바르지 않은 값을 레이어1에게 전달할 수 있기 때문에, 옵티미스틱 롤업은 위조 증명(Fraud Proof)와 분쟁조정시간(DTD, Dispute Time Delay)를 두어 이를 감시한다. 만일, 레이어2가 잘못된 상태값을 레이어1에 기록하면, 레이어2의 검증자가 DTD 이내에 상태값이 잘못되었음을 주장하여 이를 방지할 수 있다.
옵티미스틱 롤업의 작동 방법 [링크]
B. ZK 롤업
ZK 롤업은 레이어1을 설득하기 위해 보수적인 방식을 채택한다. ZK 롤업은 레이어2가 전송한 값이 올바르지 않을 수 있음을 전제로 하기 때문에, 레이어1에서 레이어2의 상태값이 올바른지 매번 검증하도록 한다. 이 때문에, 레이어2는 자신의 상태값이 제대로 계산되었음을 증명할 수 있는 어떠한 증명값을 만들어서 함께 보내야한다.
ZK 롤업은 암호학적으로 계산 무결성을 검증하는 방식이기 때문에, 검증의 결과값이 참(true)이면 레이어1상의 모든 노드가 상태값에 포함된 트랜잭션과 결과값을 다시 계산해 볼 필요 없이 이를 받아들일 수 있다. 따라서, 레이어1은 검증을 통해 레이어2가 보낸 상태값을 즉시 신뢰함으로써 항상 올바른 값만을 기록할 수 있다.
(2) 레이어1이 검증하는 항목
앞서, 레이어2는 자신이 계산한 값이 올바르다는 것을 레이어1에게 설득해야 한다고 하였다. 그렇다면, 레이어 1에서 이 정보를 받아들이기 위해 무엇을 확인해야 하는 지 ZK 롤업을 예시로 살펴보자.
앞의 예시로 돌아가서, 레이어2에서 3개의 토큰 전송 트랜잭션이 발생했고 이를 정해진 순서대로 처리하여 상태값을 계산했다고 하자. 레이어1은 위 정보를 토대로 레이어2상에서 만들어진 증명을 통해 다음과 같은 조건을 확인해야한다.
토큰 전송 트랜잭션 [참고 자료: 링크1, 링크2, 링크3]
- 전송자의 계좌가 존재하는가?
- 수신자의 계좌가 존재하는가?
- 전송자의 공개키에 대한 서명이 유효한가?
- 전송자의 계좌에 전송할 만큼의 충분한 잔액이 있는가?
- 전송자의 최종 잔액에 전송한 만큼의 금액이 차감되어 있는가?
- 수신자의 최종 잔액에 받은 만큼의 금액이 추가되어 있는가?
위 조건을 통해 레이어1이 검증하는 것을 한 문장으로 정리하면 다음과 같다.
레이어2에서 발생한 유효한 트랜잭션으로 상태 변환이 정확하게 계산되었다.
위 값을 검증할 수 있는 정보는 머클트리의 형식으로 전달되며, 레이어1의 검증 컨트랙트는 레이어2가 전송한 머클트리와 증명으로 각 트랜잭션이 위 조건을 만족하는지 모두 검증한 후, 이를 레이어1에 기록한다. 이 과정으로 레이어1은 레이어2에서 생성된 블록의 계산 무결성에 대하여 증명할 수 있다.
3. 오퍼레이터의 역할
그렇다면, 레이어2가 계산 무결성을 레이어1에게 증명하는 것만으로도, 레이어2의 확장성 솔루션의 목표를 모두 달성함과 동시에 레이어1을 설득하기 충분할까? 이를 논하기 전에, 레이어2에서 계산 무결성을 증명하는 주체와 그 역할에 대해서 알아보자.
레이어2 솔루션에서 유효한 트랜잭션을 모아 처리하고 그 결과값을 레이어1에 전송함과 동시에, 상태값에 대한 유효성을 증명하는 주체를 오퍼레이터(operator)라한다. 오퍼레이터가 레이어2에서 수행하는 것은 다음과 같이 4가지 이다.
- 트랜잭션 선택: 블록에서 처리할 거래를 멤풀(mempool)에서 선택
- 트랜잭션 처리 순서 결정: 블록에 포함된 트랜잭션의 처리 순서를 결정
- 상태 계산: 결정된 순서대로 상태값을 계산
- 상태값 전송: 상태값을 정해진 주기로 레이어1에 전송
오퍼레이터는 레이어2상의 노드의 자산과 그 거래를 모두 관리하는 유일한 참여자이기 때문에, 안전한 네트워크 유지를 위해서는 오퍼레이터의 정확한 역할 수행이 매우 중요하다. 오퍼레이터가 위 역할을 수행한다는 것은 이에 대한 권한을 가지고 있으며, 그 권한을 악의적으로 남용할 가능성이 있음을 가정할 수 있다는 것이다. 이러한 우려로 옵티미스틱 롤업과 ZK 롤업은 악의적인 오퍼레이터의 동작을 감지할 수 있는 검증 체계를 가지고 있다. 이들이 가진 검증 체계는 오퍼레이터가 생성한 블록의 계산 무결성을 검증하는 것으로 위 역할 중 3번과 4번을 정확하게 수행했는지 검증할 수 있지만, 1번과 2번의 권한에 대해서는 감시할 수 없다.
다시말해, 오퍼레이터는 상태 변환에 대한 연산만 올바르게 수행하면, 의도적인 트랜잭션의 선택과 순서 결정은 옵티미스틱 롤업상의 레이어2 검증자, 혹은 ZK 롤업상의 레이어1의 검증 컨트랙트에 의해 감시될 수 없다.
블록에 포함될 트랜잭션을 선택하고 이 처리 순서를 결정하는 작업은 철저하게 중앙 집중화되어 있지만, 이에 대한 명확한 감시체계를 만드는 것이 어렵다. 이 상황을 이해하기 위해 악의적인 오퍼레이터가 두 가지 권한을 남용했을 때 레이어2에서 발생할 수 있는 상황을 생각해보자.
(1) 트랜잭션 검열
블록에 포함되기 전의 트랜잭션은 공개된 멤풀(mempool)에서 대기하게 된다. 오퍼레이터는 멤풀에 담긴 트랜잭션의 정보를 미리 확인하여 자신의 블록에 포함시킬 트랜잭션을 선택할 수 있다. 오퍼레이터에게 이러한 선택권이 있다는 것은 악의적인 오퍼레이터에의해 트랜잭션이 검열될 수 있는 가능성이 존재함을 의미한다.
- 특정 참여자의 트랜잭션만 의도적으로 블록에 포함시키지 않는다.
- 특정 트랜잭션(예: 레이어2에서 자금 출금)을 의도적으로 블록에 포함시키지 않는다.
오퍼레이터가 트랜잭션을 선택함에 있어서 특정 트랜잭션을 검열했는지에 대한 검증 체계를 만드는 것은 매우 어려울 것이다. 만약 특정 트랜잭션의 처리가 반복적으로 지연된다면, 검증자 혹은 그 트랜잭션의 생성자가 오퍼레이터의 권한 남용을 의심할 수 있을 것이다. 하지만, 그 의심이 성립되기 위해서는 처리 지연 시간 등에 대한 명확한 기준을 세워야 한다. 만약, 모두가 동의할 수 있는 명확한 기준을 결정하더라도 이를 오퍼레이터가 악의적으로 행했다는 것을 입증하기는 매우 어려운데, 오퍼레이터가 자신의 네트워크 문제 등으로 특정 트랜잭션의 처리 지연이 악의적인 행위가 아니었음을 주장할 수 있기 때문이다.
(2) 악의적인 MEV
오퍼레이터의 트랜잭션 생성과 순서 결정의 권한 집중으로 야기되는 사례와 비슷한 것을 이미 경험하고 있다. 바로 레이어1의 마이너에 의한 악의적인 MEV이다.
Flashbot의 커뮤니티를 중심으로 정의된 MEV는 maximal extractable value로 차익 거래(arbitrage), 청산(liquidation)으로 만들어진 가치도 포함하고 있다[링크]. 멤풀의 정보는 마이너뿐만 아니라 네트워크에 참여하는 모든 참여자가 접근할 수 있기 때문에 누구나 MEV를 추출할 수 있는 트랜잭션을 미리 탐색하고, 가격 슬리피지를 이용한 차익거래를 노린 트랜잭션을 멤풀에 포함시킬 수 있다. 이러한 MEV는 생태계의 가격 안정화에 기여하기 때문에 선의의 MEV로 평가된다.
이 글에서 이야기하는 MEV는 악의적인 블록 생성자의 권한 남용으로 발생한 부가가치이다. 이들은 블록을 생성하는 권한을 가지고 차익 거래의 기회를 찾은 트랜잭션을 복사해 이를 블록에 포함시킴으로써 이익을 가로챌 수 있다. 이처럼 블록을 구성하고 처리하는 권한을 가진 참여자가 이를 남용하여 얻은 MEV는 생태계를 불안정하게 만드는 악의적인 MEV로 간주할 수 있다.
- 레이어2상의 다량의 스왑 거래를 발견하면, MEV를 위한 트랜잭션을 포함하여 이익을 얻는다.
- 멤풀에서 차익거래 트랜잭션을 발견하면, 이를 복제하고 블록에 포함하여 이익을 갈취한다.
- 멤풀에서 청산 트랜잭션을 발견하면, 이를 복제하고 블록에 포함하여 이익을 갈취한다.
레이어1상의 마이너의 경우, 블록을 성공적으로 생성하기 위해서는 네트워크상의 다른 마이너와 합의 알고리즘의 경쟁에서 승리해야한다. 이 경쟁에서 승리하기 위해서는 매우 큰 연산 힘을 가지고 있어야 하고, 그 확률도 매우 낮기 때문에 이러한 권한 남용은 네트워크 참여자들에게 비교적 덜 견제될 수 있다. 하지만, 레이어2의 상황은 매우 다르다. 블록 생성자가 많을 수록 확장성이 저하되는 블록체인 네트워크의 특성상, 레이어2는 확장성을 위해 블록 생성자를 소수로 유지되어야 하며, 현재 제공되는 레이어2 솔루션에서는 단 한명의 오퍼레이터만이 동작하고 있기 때문이다. 즉, 레이어2의 오퍼레이터는 자신이 원한다면, 언제든, 들키지 않을 권한 남용을 통해 레이터2의 네트워크의 혼란과 레이어2 사용자들의 자산을 통한 부가 수익을 얻을 수 있다.
A. Optimism의 오퍼레이터
현재 Optimism의 옵티미스틱 롤업 솔루션을 사용하여 운영되는 레이어2 서비스는 Optimism, Metis Andromeda, Boba Network이다. 이 서비스에서 발생하는 모든 트랜잭션의 처리는 Optimism에서 제공하는 단일 오퍼레이터(시퀀서, sequencer 라고도 함)에 의해서 수행되고 있다.
B. Starkware의 오퍼레이터
이와 마찬가지로, Starkware의 ZK 롤업 또한 하나의 오퍼레이터에 의해 레이어2 서비스를 유지하고 있으며, 이를 사용하는 ImmutableX, dYdX, DeversiFi, Sorare는 모두 정해진 하나의 오퍼레이터에 의해 노드의 자금과 트랜잭션을 관리되고 있다.
- Immutable X Contract
오퍼레이터 주소: 0x9B7f7d0d23d4CAce5A3157752D0D4e4bf25E927e - dYdX Contract
오퍼레이터 주소: 0x8129b737912e17212c8693b781928f5d0303390a - DeversiFi
오퍼레이터 주소: 0x8A6c80Aab6497E2DB35817817b593b79D78f6ae5 - Sorare Contract
오퍼레이터 주소: 0x63881ac44293e22f3c3183a0c4113586abb3e653
결과적으로, 이러한 검열과 악의적인 MEV에 대한 검증 체계가 만들어지지 않는다면, 레이어1과 레이어2상의 노드들은 오퍼레이터가 트랜잭션을 검열하지 않고, 자신의 추가 이익을 위해 의도적으로 처리 순서를 결정하지 않았을거라 믿음을 가져야한다. 즉, 단일 오퍼레이터에 의한 레이어2의 중앙화 문제를 해결하지 않으면, 확장성을 위한 레이어2의 채택은 그 안에 보관된 자산 제어에 대한 중앙 집중화를 야기할 수 있으며, 이는 ZK 롤업 조차도 단 한 명의 선량한 오퍼레이터에게 의존해야하는 상황을 야기하게 된다.
이러한 상황은 레이어2의 확장성 솔루션 목표를 도달하기 어렵게 만든다. 확장성 솔루션의 목표는 블록체인 상에서 일어나는 거래를 빠르고 저렴하게 처리하면서, 블록체인의 보안성과 분산화를 해치지 않는 것이다. 오퍼레이터의 계산 무결성만 검증하고, 트랜잭션 선택과 순서 결정에 대한 권한을 견제할 수 없다면, 부가적인 보안성 및 분산화의 손실을 야기하게 된다. 이러한 손실은 레이어2의 상태를 레이어1에 기록하여 보안성과 분산화에 의지하더라도 결과적으로 블록체인의 트릴레마를 해결하기 어려워지게 만든다.
4. 오퍼레이터의 권한을 상쇄시키는 방법
따라서 레이어2가 완전한 확장성 솔루션이 되기 위해서는 오퍼레이터가 가진 선택과 순서 결정에 대한 권한을 상쇄할 수 있는 방법에 대해서 고민해야한다. 이에 대해, 일반적으로 고려될 수 있는 두 가지 방식에 대해 소개하며, 결론적으로 이러한 방법으로는 오퍼레이터의 권한을 상쇄하기 어려우며 오히려 더 많은 2차 이슈를 야기할 수 있다는 것을 주장한다.
(1) 레이어1의 컨센서스 도입
레이어 2에서의 PoS 선택 by barryWhiteHat [링크]
레이어2의 오퍼레이터는 레이어1의 마이너와 유사한 역할을 수행한다. 그렇다면, 레이어1의 마이너의 권한을 분산시키기 위해 사용하는 컨센서스를 레이어2에 도입하면 오퍼레이터의 권한을 분산시킬 수 있을까?
이 질문에 대한 좋은 답은 barryWhiteHat에 의해 Ethresear.ch에서 제시되었다. 이 글에서 barryWhiteHat은 오퍼레이터의 권한 상쇄를 위해 메인넷이 취한 방식인 PoS로 권한을 분산시키는 경우 노출될 수 있는 공격 포인트와 이를 방지할 수 없는 이유에 대하여 설명한다.
본 아티클에서는 이를 간략히 다루고, 자세한 내용은 barryWhiteHat의 글에서 직접 확인하기를 바란다. PoS로 오퍼레이터를 선출할 경우 발생할 수 있는 공격 포인트는 4가지 이다.
- DOS attack: 대부분의 지분을 가진 오퍼레이터가 빈 블록만 계속 만들어 제안하는 등 의도적으로 레이어2의 운영을 방해할 수 있다.
- Fake DOS attack: 악의적인 오퍼레이터가 토큰을 다량 구매한 후 DOS attack을 한다고 공표 혹은 실제로 수행한다. 이 때 다른 오퍼레이터는 악의적인 오퍼레이터의 슬래싱으로 더 많은 보상을 취하기 위해서 스테이킹 비율을 늘리기 위해 토큰을 추가 매수한다. 이를 통해 토큰 가격이 상승하면 악의적인 오퍼레이터는 미리 매수했던 토큰을 매도하여 이익을 취할 수 있다.
- Slashing attack: 악의적인 오퍼레이터가 자신의 투표권을 이용해 다른 오퍼레이터가 블록을 생성할 수 없도록 의도적으로 방해하여, 다른 오퍼레이터가 슬래싱될 가능성을 크게 높일 수 있다.
- Coordinator takeover: 레이어 2를 탈퇴하려는 사용자에게 막대한 출금 수수료를 부과하는 등의 권한을 남용할 수 있다.
barryWhiteHat은 PoS로 선출된 오퍼레이터의 공격을 레이어 2가 방지할 수 없는 이유를 레이어2가 레이어1과 같이 하드포크가 어렵기 때문이라 주장한다. 메인넷은 PoS로 선정된 악의적인 validitor를 막기 위해서, 스테이킹된 자금을 제거하는 하드포크를 시행함으로써, 이를 프로토콜 단에서 막을 수 있다. 하지만, 레이어2는 레이어1에 상태를 기록하여 유지되기 때문에 레이어2 프로토콜 단의 하드포크가 어려워 많은 지분을 가진 오퍼레이터의 자금을 빼앗을 수 있는 원천적인 방법이 없다.
필자가 본 아티클에서 동의하는 것은 레이어 2의 오퍼레이터의 권한 상쇄를 위해 메인넷과 동일한 방식(혹은 유사한 방식)을 취하면, 보안을 위협하는 2차 이슈가 충분히 발생할 수 있으며, 레이어 2의 특성으로 이 이슈를 완전히 방지하기 힘들다는 것이다.
또한, 합의 알고리즘의 도입은 분산화 방식을 통해 오퍼레이터의 선택과 순서 결정 권한 남용을 통한 이익 창출의 가능성을 줄일 수 있지만, 그 확률을 크게 줄이기 위해서는 레이어1 만큼의 분산화를 도입해야하기 때문에 결국 레이어2의 확장성이 저하된다.
(2) PBS 방식 도입
Proof of Efficient (PoE) by David Schwartz and Jordi Baylina, Polygon Hermez [링크]
그렇다면, Miner의 MEV를 방지하기 위해 제안되어왔던 PBS(Proposer/Builder Separation)[링크] 방식을 레이어2에 도입하면 오퍼레이터의 권한을 상쇄할 수 있을까?
이 질문의 답은 최근 Polygon Hermez에 의해 소개된 PoE로 알아보고자 한다. Polygon Hermez는 최근 PoE(Proof of Efficient)라는 이름의 ZK 롤업 기반 레이어 2의 오퍼레이터의 권한 분산화를 위한 방안을 제안했다. PoE에서는 오퍼레이터의 권한 상쇄를 위해 블록에서 처리될 트랜잭션을 선택하고 순서를 정하는 참여자와 이를 실제로 처리하는 참여자를 따로 두어 권한을 분산시키는 방법을 선택했다.
- Sequencer(이하 ‘시퀀서’)
레이어 2에서 트랜잭션을 수집하여 배치(batch)로 만들고 이를 메인넷에 전송하는 참여자
시퀀서는 레이어1에 자신이 만든 배치를 전송하여, 자신의 배치에 포함될 트랜잭션과 그 처리 순서를 레이어1에 미리 기록하는 참여자이다. 시퀀서는 악의적으로 올바르지 않은 거래를 기록할 수 있기 때문에, 시퀀서의 기록은 레이어2의 새로운 상태 업데이트로 반영되지 않는다. 시퀀서로 참여하기 위해서는 레이어2에 일정량의 $MATIC 토큰을 보증금으로서 예치해야한다. 시퀀서는 레이어1에 배치를 올리기 위해서는 가스비를 지불해야하기 때문에 악의적인 정보를 올려도 처벌받지 않는다. 이 정보가 레이어2의 최종 상태로 반영되지 위해서는 어그리게이터(Aggregator)에 의해 레이어1에서 검증되어져야 한다.
- Aggregator(이하 ‘어그리게이터’)
메인넷에 기록된 배치에 대한 증명을 레이어2에서 만들어 이를 메인넷의 검증 스마트 컨트랙트에 전송하는 참여자
어그리게이터는 시퀀서 중에 한 명의 배치를 선택하여, 배치에 포함된 트랜잭션에 의한 상태값의 유효성을 검증할 수 있는 증명을 생성하고 이를 레이어1의 검증 스마트 컨트랙트에 전송하는 참여자이다. 이 증명은 유효한 트랜잭션으로 구성된 배치에 의해서만 생성된다. 어그리게이터는 자신이 선택한 배치와 증명을 새로운 상태 업데이트로 반영하기 위해서 다른 어그리게이터와 경쟁해야 한다.
이러한 권한 분산 방식은 메인넷에서 MEV 문제를 해결하기 위해 블록을 만드는 참여자(Builder)과 상태 계산 후 네트워크에 블록을 제안하는 참여자(Proposal)를 분산시키는 PBS 방식과 유사하다. 하지만 여전히 이 방식은 다음과 같은 이유로 오퍼레이터의 두 가지 권한(선택, 순서 결정)을 상쇄시키지 못한다.
- 시퀀서의 확률적인 권한 남용 가능성
시퀀서는 여전히 선택과 순서 결정 권한을 가지고 있다. 즉, 자신이 의도적으로 만든 블록이 어그리게이터에게 선택되면, 권한 남용을 성공할 수 있어 악의적인 MEV 등을 취할 수 있는 가능성이 확률적으로 존재한다. 물론, 단일 오퍼레이터에 의해 수행이 될 때보다는 그 가능성이 낮다. 하지만 이 실패 가능성은 다음 2.와 같은 경우에서 거의 무시 될 만하다. - 시퀀서와 어그리게이터의 공모 가능성
시퀀서와 어그리게이터가 공모를 한다면, 단일 오퍼레이터가 가지게 되는 권한과 그것을 실행할 수 있는 힘이 여전히 유지된다. PoE 구조상 가장 효율적인 연산이 가능한 어그리게이터가 특정 사용자와 공모하게 된다면, 아주 높은 확률로 권한을 남용하여 악의적인 이익을 취할 수 있다.
또한, 오퍼레이터의 권한의 상쇄를 위해 추가적인 참여자들의 경쟁 구조를 도입한다면, 레이어2의 확장성은 저하될 수 밖에 없다. PoE에서는 승리한 어그리게이터 이외의 다른 참여자는 증명 생성 비용을 낭비하게 된다. 이를 지적한 댓글에서 David Schwartzs는 “경쟁하는 어그리게이터의 수를 줄이면 총 계산량이 많지 않을 것”이라 답했다.
결국 이러한 경쟁 구조를 도입한 레이어2 솔루션의 채택은 오퍼레이터의 권한 남용을 확률적으로 줄일 수 있지만, 공모 가능성 등으로 여전히 레이어2의 중앙 집중화를 야기하며, 거래 처리의 확장성은 저하될 수 밖에 없다.
4. 마치며
블록체인의 트릴레마를 해결하기위한 확장성 솔루션은 확장성의 극대화를 추구하는 동시에 보안성과 분산화를 레이어1에 온전히 의존해야한다. 레이어2의 오퍼레이터가 가진 권한 중, 솔루션의 검증 체계에서 감시될 수 없는 블록 생성에 대한 권한은 오로지 오퍼레이터의 공정성에 신뢰를 해야하는 상황이다. 이 권한을 오퍼레이터의 공정성에 맡기면, 보안성과 분산화를 레이어1에 의존하더라도 레이어2의 참여자들은 자신의 자산의 중앙 집중화를 방치하게된다.
오퍼레이터의 공정성을 경제적으로 확보하기 위해 다수의 오퍼레이터에 의한 합의 알고리즘이나 경쟁체제의 도입은 확장성 솔루션의 가장 큰 목표인 “확장성 극대화”를 저하될 것이며, 선택되는 방안에 따라 보안성을 위협할 수 있다.
필자는 확장성 솔루션이 되기 위해서는 현재 솔루션의 검증체계에서 감시될 수 없는 블록 생성의 공정성을 감시할 수 있는 체계가 만들어져야 한다고 주장한다. 필자는 현재 이를 경제학의 방식이 아닌 암호학 방식으로 해결하여, 단일 오퍼레이터의 확장성을 저하시키지 않고, 그 공정성의 검증을 레이어1이 할 수 있도록 하여 분산화와 보안성을 온전히 레이어1에 의존할 수 있는 방법을 고민하고 있다.
