Plasma가 스마트 계약을 지원하지 않는 이유 분석: 데이터 보류 및 사기 증명
글: Faust, 극크 web3
왜 Plasma가 오랫동안 묻혀 있었고, Vitalik이 Rollup을 적극적으로 지지하게 된 이유는 주로 두 가지 단서에서 찾을 수 있다. 첫째, 이더리움 체인 외부에서 DA(Data Availability)를 구현하는 것은 신뢰할 수 없으며, 데이터 보류(data withholding) 문제가 쉽게 발생하고, 한번 데이터 보류가 발생하면 사기 증명(fraud proof)을 실행하기 어렵다는 점이다. 둘째, Plasma의 메커니즘 설계 자체가 스마트 계약에 매우 불편하며, 특히 Layer1으로의 계약 상태 이전을 지원하기 어렵다. 이러한 두 가지 이유로 인해 Plasma는 기본적으로 UTXO 또는 유사한 모델만 채택할 수밖에 없다.
위 두 핵심 관점을 이해하기 위해 먼저 DA와 데이터 보류 문제부터 살펴보자.DA는 Data Availability의 약자로, 직역하면 데이터 가용성인데, 현재 많은 사람들이 이를 잘못 사용하여 '과거 기록 조회 가능'과 심각하게 혼동하고 있다. 그러나 실제로 '과거 기록 조회 가능' 및 '저장 증명(proof of storage)'은 Filecoin과 Arweave 등에서 이미 해결된 문제이다.이더리움 재단과 Celestia의 설명에 따르면, DA 문제란 순수하게 데이터 보류 상황을 논의하는 것이다.
Merkle 트리와 Merkle 루트 및 Merkle 증명
데이터 보류 공격과 DA 문제의 본질을 설명하기 위해,우선 Merkle 루트와 Merkle 트리에 대해 간략히 알아야 한다. 이더리움이나 대부분의 퍼블릭 블록체인에서는 Merkle 트리라 불리는 나무 형태의 데이터 구조를 사용하여 전체 계정 상태의 요약/목차 역할을 하거나 각 블록 내에 포함된 거래들을 기록한다.
Merkle 트리의 가장 아래쪽 리프 노드는 거래나 계정 상태 등의 원시 데이터 해시로 구성되며, 이러한 해시 값들이 두 개씩 짝을 이루어 반복적으로 합산되면서 결국 하나의 Merkle 루트를 도출하게 된다.
(그림 맨 아래의 record가 리프 노드에 해당하는 원시 데이터 세트)
Merkle 루트는 다음과 같은 특성이 있다:Merkle 트리 최하단의 어느 리프 노드라도 변경되면, 계산된 Merkle 루트도 반드시 변한다. 따라서 서로 다른 원시 데이터 세트에 대응되는 Merkle 트리는 각기 다른 Merkle 루트를 가지게 되며, 마치 사람마다 다른 지문을 가지는 것과 같다. 그리고 Merkle Proof라 불리는 증명 검증 기술은 바로 이 Merkle 트리의 특성을 활용한다.
위 그림 예시에서, 이강이 알고 있는 것은 Merkle 루트의 값뿐이고, 전체 Merkle 트리가 어떤 데이터를 포함하는지는 모른다고 가정하자. 우리는 이강에게 Record 3가 그림의 루트와 실제로 연관되어 있음을, 즉 Record 3의 해시값이 해당 루트에 대응하는 Merkle 트리 위에 존재함을 입증해야 한다.
이때 우리는 전체 Merkle 트리나 모든 리프 노드를 전달하지 않고, Record 3과 회색으로 표시된 3개의 digest 데이터 블록만 이강에게 제출하면 된다.이것이 Merkle Proof의 간결성이다. Merkle 트리 최하단 리프 노드의 개수가 매우 많을 경우, 예를 들어 2의 20승 개(약 백만 개)일 때에도, Merkle Proof는 최소 21개의 데이터 블록만으로 구성될 수 있다.
(그림의 데이터 블록 30과 H2는 Merkle Proof를 구성하여, 데이터 블록 30이 H0에 대응하는 Merkle 트리에 존재함을 증명할 수 있다)
비트코인, 이더리움 또는 크로스체인 브릿지에서는 종종 Merkle Proof의 이러한 '간결성'이 사용된다. 우리가 아는 라이트 노드(light node)란 위에서 언급한 이강처럼, 풀 노드로부터 전체 블록이 아닌 블록 헤더(header)만 수신하는 노드를 말한다. 여기서 강조할 점은, 이더리움은 State Trie라 불리는 Merkle 트리를 전체 계정 상태의 요약으로 사용한다는 것이다. 특정 계정 상태가 변경되면 State Trie의 Merkle 루트—즉 StateRoot도 함께 변화한다.
이더리움 블록 헤더에는 StateRoot와 함께 거래 트리의 Merkle 루트(Txn Root)도 기록된다. 거래 트리와 상태 트리의 차이점 중 하나는 최하단 리프 노드가 나타내는 데이터의 종류이다. 만약 100번 블록에 300건의 거래가 포함되어 있다면, 거래 트리의 리프들은 바로 이 300건의 거래를 의미한다.
또 다른 차이점은 State Trie의 전체 데이터 양이 매우 크다는 점이다. 그 최하단 리프들은 이더리움 체인 상의 모든 주소(실제로는 많은 만료된 상태 해시도 포함)를 대표하므로, State Trie에 해당하는 원시 데이터 세트는 블록 내에 게시되지 않으며, 블록 헤더에는 StateRoot만 기록된다. 반면 거래 트리의 원시 데이터 세트는 각 블록 내의 Txn 데이터이며, 이 트리의 TxnRoot는 블록 헤더에 기록된다.
라이트 노드는 블록 헤더만 수신하므로 StateRoot와 TxnRoot만 알지, Root로부터 전체 Merkle 트리를 역추적할 수 없다(Merkle 트리와 해시 함수의 성질상 불가능). 따라서라이트 노드는 블록 내 거래 데이터나 State Trie 관련 계정의 변화 내용을 알 수 없다.
왕강이 라이트 노드(앞서 언급한 이강)에게 100번 블록에 특정 거래가 포함되어 있음을 증명하고자 할 때, 라이트 노드는 이미 100번 블록의 헤더와 TxnRoot를 알고 있다고 가정하면, 위 문제는 다음과 같이 바뀐다:해당 거래가 TxnRoot에 대응하는 Merkle 트리 위에 존재함을 입증하는 것. 이때 왕강은 해당 Merkle Proof만 제출하면 된다.
많은 라이트 클라이언트 기반 크로스체인 브릿지에서는 앞서 설명한 라이트 노드와 Merkle Proof의 경량성과 간결성이 자주 활용된다. 예를 들어 Map Protocol과 같은 ZK 브릿지는 ETH 체인 상에 컨트랙트를 설정하여 다른 체인의 블록 헤더(예: Polygon)를 전专门接收한다. Relayer가 ETH 체인의 컨트랙트에 Polygon의 100번째 블록 헤더를 제출하면, 컨트랙트는 헤더의 유효성을 검증한다(예: Polygon 네트워크 내 2/3 PoS 노드의 서명이 충족되었는지 여부).
헤더가 유효하고, 어떤 사용자가 자신이 Polygon에서 ETH로의 크로스체인 거래를 발송했으며, 해당 거래가 Polygon의 100번째 블록에 포함되었다고 주장할 경우, 그는 Merkle Proof를 통해 자신의 크로스체인 거래가 100번 블록 헤더의 TxnRoot와 일치함을 입증하면 된다(즉,Polygon의 100번 블록에 자신의 크로스체인 거래 기록이 있다는 것을 입증하는 것). 다만 ZK 브릿지는 제로노울리지 증명을 통해 Merkle Proof 검증에 필요한 계산량을 압축하여 크로스체인 브릿지 컨트랙트의 검증 비용을 추가로 낮춘다.
DA와 데이터 보류 공격 문제
Merkle 트리, Merkle 루트, Merkle Proof에 대해 설명한 후, 다시 본문 처음 언급한 DA와 데이터 보류 공격 문제로 돌아오자. 이 문제는 2017년 이전부터 논의되었으며, Celestia의 원시 논문에서는 DA 문제의 기원을 고찰하고 있다.Vitalik 본인도 2017~18년의 한 문서에서, 블록 생성자가 일부 데이터 조각을 고의로 숨기고 불완전한 블록을 외부에 발표할 가능성을 언급한 바 있으며, 이 경우 풀 노드는 거래 실행/상태 전환의 정확성을 확인할 수 없다.
이러한 상황에서 블록 생성자는 사용자의 자산을 도난할 수 있는데, 예를 들어 A 계정의 코인을 모두 다른 주소로 이체할 수 있다. 하지만 풀 노드는 A 본인이 실제로 그런 행위를 했는지 판단할 수 없으므로, 최신 블록에 포함된 완전한 거래 데이터를 모르기 때문이다.
비트코인이나 이더리움과 같은 Layer1 퍼블릭 체인에서는 정직한 풀 노드가 위와 같은 무효 블록을 직접 거부한다.하지만 라이트 노드는 다르다. 그들은 네트워크로부터 블록 헤더만 수신하며, StateRoot와 TxnRoot만 알고 있을 뿐, 헤더와 두 Root에 대응하는 원본 블록이 유효한지 여부는 모른다.
비트코인 백서에서는 사실 이 상황에 대해 상상력을 발휘했는데, 나카모토 사토시는 대부분의 사용자가 시스템 요구가 낮은 라이트 노드를 운영할 것으로 생각했고, 라이트 노드는 블록 헤더에 대응하는 블록이 유효한지 판단할 수 없으며, 무효 블록이 발생하면 정직한 풀 노드가 라이트 노드에게 경고를 보내야 한다고 언급했다.
하지만 나카모토 사토시는 이 방안에 대해 더 세밀한 분석을 하지 않았고, 이후 Vitalik과 Celestia 창시자 Mustafa는 이 아이디어를 기반으로 다른 선구자들의 성과를 결합하여 DA 데이터 샘플링을 도입하였으며, 이를 통해 정직한 풀 노드가 각 블록의 완전한 데이터를 복원하고 필요 시 경고를 발령할 수 있도록 하였다.
Plasma의 사기 증명(Fraud Proof)
간단히 말해,Plasma는 Layer2의 블록 헤더만 Layer1에 게시하는 확장 솔루션이며, 블록 헤더 외부의 DA 데이터(완전한 거래 데이터셋 / 각 계정 상태 변화)는 체인 외부에서만 배포된다. 즉, Plasma는 라이트 클라이언트 기반 크로스체인 브릿지와 유사하게, ETH 체인 상의 컨트랙트를 통해 Layer2의 라이트 클라이언트를 구현한 것으로, 사용자가 L2에서 L1으로 자산을 이체할 때 Merkle Proof를 제출하여 자신의 자산 소유권을 입증해야 한다.
L2에서 L1로의 자산 이체 검증 로직은 앞서 언급한 ZK 브릿지와 유사하지만, Plasma의 브릿지 모델은 ZK 증명이 아닌 사기 증명에 기반하며,所谓 '낙관적 브릿지(optimistic bridge)'에 더 가깝다. Plasma 네트워크에서 L2에서 L1로의 인출 요청은 즉시 승인되지 않고 '도전 기간(challenge period)'이 존재하는데, 이 도전 기간의 목적은 아래에서 설명하겠다.
Plasma는 데이터 게시/DA에 엄격한 요구사항이 없으며, 정렬기/Operator는 체인 외부에서 각 L2 블록을 방송하고, L2 블록을 원하는 노드가 스스로 가져간다. 이후 정렬기는 L2 블록의 헤더를 Layer1에 게시한다. 예를 들어, 정렬기가 먼저 체인 외부에서 100번 블록을 방송한 후, 블록 헤더를 체인 상에 게시한다. 만약 100번 블록에 무효 거래가 포함되어 있다면, 어떤 Plasma 노드라도 '도전 기간' 종료 전에 ETH 상의 컨트랙트에 Merkle Proof를 제출하여100번 블록 헤더가 특정 무효 거래와 연결될 수 있음을 입증할 수 있다. 이것이 사기 증명이 다루는 하나의 시나리오이다.
Plasma의 사기 증명 적용 시나리오는 다음과 같은 것들도 포함된다:
1. Plasma 네트워크가 200번 블록까지 진행된 상황에서, 사용자 A가 자신이 100번 블록 시점에 10개의 ETH를 보유했다고 인출을 주장한다고 가정하자. 하지만 실제로 A는 100번 블록 이후 계정의 ETH를 이미 사용했다.
즉, A의 행동은 10개의 ETH를 사용한 후, 과거에 10개의 ETH를 보유했다고 주장하며 이를 인출하려는 것으로, 이는 전형적인 '이중 인출(double withdrawal)', 즉 더블스펜딩(double spend)이다. 이때,누구나 Merkle Proof를 제출하여 A의 최신 자산 상태가 인출 주장과 맞지 않음을 입증할 수 있으며, 즉 A가 100번 블록 이후 주장한 금액을 가지고 있지 않았음을 입증할 수 있다.(다양한 Plasma 방식은 이런 상황에 대한 증명 방법이 일치하지 않으며, 계정 주소 모델의 더블스펜딩 증명은 UTXO 모델보다 훨씬 복잡하다.)
2. UTXO 모델 기반의 Plasma 방식(과거 대부분이 이런 방식)에서는 블록 헤더에 StateRoot가 포함되지 않으며, 오직 TxnRoot만 존재한다(UTXO는 이더리움식 계정 주소 모델을 지원하지 않으며, State Trie와 같은 전역 상태 설계도 없다). 즉, UTXO 모델을 채택한 체인은 거래 기록만 있고 상태 기록은 없다.
이 경우 정렬기 자체가 더블스펜딩 공격을 수행할 수 있는데, 예를 들어 이미 사용된 UTXO를 다시 사용하거나, 특정 사용자에게 임의로 UTXO를 증발시킬 수 있다.어떤 사용자라도 Merkle Proof를 제출하여 해당 UTXO의 사용 기록이 과거 블록에 존재했음을(즉, 이미 사용됨), 혹은 특정 UTXO의 역사적 출처에 문제가 있음을 입증할 수 있다.
3. EVM 호환/State Trie 지원 Plasma 방식의 경우, 정렬기가 무효한 StateRoot를 제출할 수 있다. 예를 들어, 100번째 블록에 포함된 거래를 실행한 후 StateRoot는 ST+로 전환되어야 하지만, 정렬기가 Layer1에 제출한 것은 ST-일 수 있다.
이런 경우의 사기 증명은 비교적 복잡하며, 이더리움 체인에서 100번째 블록의 거래를 다시 재실행해야 하고, 계산량과 필요한 입력 파라미터로 인해 많은 가스를 소비하게 된다.초기 Plasma를 채택한 팀들은 이러한 복잡한 사기 증명을 구현하기 어려웠기 때문에 대부분 UTXO 모델을 채택했으며, UTXO 기반 사기 증명은 간단하고 구현하기 쉬웠기 때문이다.(사기 증명을 최초로 론칭한 Rollup 솔루션 Fuel 역시 UTXO 기반이었다.)
데이터 보류와 Exit Game
물론 위의 사기 증명이 효과를 발휘할 수 있는 상황은 오직 DA/데이터 게시가 유효할 때에만 성립한다. 만약 정렬기가 데이터 보류를 하여 체인 외부에 완전한 블록을 게시하지 않으면, Plasma 노드는 Layer1 상의 블록 헤더가 유효한지 확인할 수 없으며, 당연히 사기 증명도 원활히 게시할 수 없다.
이때 정렬기는 사용자 자산을 도난할 수 있으며, 예를 들어 A 계정의 코인을 모두 B 계정으로 몰래 이체한 후, B 계정에서 C에게 이체하고, 마지막으로 C 명의로 인출을 시작할 수 있다. B와 C 계정은 정렬기 본인이 소유하므로, B→C 거래가 외부에 공개되더라도 별 문제가 없다.하지만 정렬기는 A→B라는 무효 이체 데이터를 보류할 수 있으며, 사람들은 B와 C의 자산 출처에 문제가 있음을 입증할 수 없다.(B의 자산 출처에 문제가 있음을 입증하려면 'B에게 이체한 특정 거래'의 디지털 서명이 잘못되었음을 지적해야 한다.)
UTXO 기반 Plasma 방식은 이에 대한 대책을 마련했는데, 누구든 인출을 요청할 때 자산의 전체 역사적 출처를 제출해야 한다. 이후 더 많은 개선 조치가 있었다. 하지만 EVM 호환 Plasma 방식의 경우 이 부분에서 매우 취약하다.왜냐하면 계약 관련 거래가 포함되는 경우, 체인 상에서 상태 전환 과정을 검증하는 데 엄청난 비용이 들기 때문이며, 따라서 계정 주소 모델과 스마트 계약을 지원하는 Plasma는 인출 유효성 검증 방안을 잘 구현할 수 없다.
또한 위 내용을 떠나서,UTXO 기반인지 계정 주소 모델 기반인지에 관계없이, 데이터 보류가 발생하면 기본적으로 사람들의 공포를 유발하게 된다. 왜냐하면 정렬기가 어떤 거래를 실행했는지 아무도 모르기 때문이다. Plasma 노드는 이상함을 감지할 수 있지만, 사기 증명에 필요한 데이터를 정렬기가 배포하지 않았기 때문에, 목표 지향적인 사기 증명을 게시할 수 없다.
이때 사람들은 대응하는 블록 헤더만 볼 수 있을 뿐, 블록 내부 내용이나 자신의 계정 자산 상태가 어떻게 변했는지 알 수 없으며, 모두 과거 블록에 대응하는 Merkle Proof를 제출하여 인출을 시도하게 된다.이러한 'Exit Game'이라 불리는 극단적 상황이 발생하게 되며, 이는 '발디딤' 현상을 초래하여 Layer1을 심각하게 혼잡하게 만들고, 여전히 일부 사람들에게 자산 피해를 줄 수 있다.(정직한 노드의 통지를 받지 못하거나 트위터를 안 보는 사람은 정렬기가 코인을 도난 중임을 전혀 모를 것이다.)
따라서,Plasma는 신뢰할 수 없는 Layer2 확장 솔루션이며, 데이터 보류 공격이 발생하면 'Exit Game'이 트리거되어 쉽게 사용자에게 손실을 초래하므로, 이것이 폐기된 주요 원인 중 하나이다.
Plasma가 스마트 계약을 지원하기 어려운 이유
Exit Game과 데이터 보류 문제를 설명한 후, 이제 Plasma가 왜 스마트 계약을 지원하기 어려운지 살펴보자. 주로 두 가지 이유가 있다:
첫째,DeFi 계약 자산의 경우, 누가 Layer1로 인출해야 하는가? 이는 본질적으로 계약 상태를 Layer2에서 Layer1로 이전하는 것이기 때문이다. 누군가 DEX의 LP 풀에 100개의 ETH를 예치했다고 가정하자. 이후 Plasma 정렬기가 악의를 품으면, 사람들은 긴급 인출을 해야 하는데, 이때 사용자의 100개 ETH는 여전히 DEX 계약이 관리하고 있다. 그러면 이 자산들을 누가 Layer1로 인출해야 하는가?
가장 좋은 방법은 사용자에게 먼저 DEX에서 자산을 환매하도록 한 후, 사용자 본인이 직접 L1으로 인출하는 것 같지만, 문제는 Plasma 정렬기가 이미 악의를 품었으며, 언제든지 사용자 요청을 거부할 수 있다는 점이다.
그렇다면 미리 DEX 계약에 Owner를 설정하여 긴급 상황에서 계약 자산을 L1으로 인출할 수 있게 허용하면 어떨까? 명백히 이는 계약 Owner에게 공공 자산의 소유권을 부여하게 되며, 그는 언제든지 자산을 L1으로 인출하고 도망칠 수 있으므로, 너무 무서운 일이 아닐까?
분명히,DeFi 계약이 지배하는 이 '공공재산'을 어떻게 처리할 것인가는 큰 지뢰이다. 이는 실질적으로 공공 권력 분배의 난제에 해당하며, 이전에 'Hsiang Ma'는 인터뷰 《고성능 퍼블릭 체인은 새로운 일을 내기 어렵다, 스마트 계약은 권력 분배를 포함한다》에서 이 점을 언급한 바 있다.
둘째, 계약이 상태를 이전하지 못하게 하면 막대한 손실을 입게 된다.계약이 자신의 상태를 Layer1로 이전할 수 있도록 허용한다면, Plasma의 사기 증명이 해결하기 어려운 이중 인출 문제가 발생한다:
예를 들어,Plasma가 이더리움의 계정 주소 모델을 채택하고 스마트 계약을 지원한다고 가정하자. 믹서(mixer)에 현재 100개의 ETH가 예치되어 있으며, 믹서의 Owner는 Bob이 통제하고 있다.
Bob이 100번째 블록 시점에 믹서에서 50개의 ETH를 인출했다고 가정하자. 이후 Bob은 인출을 선언하여 이 50개의 ETH를 Layer1으로 이체한다.
이후 Bob은 과거 계약 상태 스냅샷(예: 70번째 블록)을 이용하여 믹서의 과거 상태를 Layer1으로 이전하는데, 이로 인해 믹서가 '과거에 보유했던' 100개의 ETH도 Layer1으로 이체된다.
분명히 이것은 전형적인 '이중 인출', 즉 더블스펜딩이다.Bob은 Layer1으로 150개의 ETH를 인출했지만, Layer2 네트워크 사용자들은 믹서/Bob에게 단지 100개의 ETH만 제공했으므로, 50개의 ETH가 공중에서 사라진 것이다. 이는 쉽게 Plasma의 준비금을 바닥내 버릴 수 있다. 이론적으로는 사람들이 사기 증명을 제기하여 믹서 계약 상태가 70번째 블록 이후 변화했음을 입증할 수 있다.
하지만 70번째 블록 이후 믹서 계약과 상호작용한 모든 거래들이 계약 상태를 변경하지 않았고, Bob이 50개 ETH를 인출한 거래만 상태를 변경했다고 가정하자. 만약 증거를 제시하여 믹서 계약 상태가 70번째 블록 이후 변화했음을 입증하려면, 위에서 언급한 모든 거래를 이더리움 체인에서 다시 실행해야 하며, 비로소 Plasma 컨트랙트는 믹서 계약 상태가 실제로 변화했음을 확인할 수 있다(이처럼 복잡한 이유는 Plasma 자체의 구조에 기인한다).만약 이 거래들 수량이 매우 많다면, 사기 증명은 Layer1 상에 게시할 수조차 없다.(이더리움 단일 블록의 가스 상한을 초과하기 때문)
이론적으로 위 더블스펜딩 시나리오에서, 단순히 믹서의 현재 상태 스냅샷(StateRoot에 대응하는 Merkle 증명)만 제출하면 될 것 같지만, 실제로 Plasma는 체인 상에 거래 데이터를 게시하지 않기 때문에, 제출한 상태 스냅샷이 유효한지 계약이 판단할 수 없다.왜냐하면 정렬기 본인이 데이터 보류를 통해 무효한 상태 스냅샷을 제출하고, 임의의 인출자를 악의적으로 지목할 수 있기 때문이다.
예를 들어, 당신이 계
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
