저자: Shew & Noah, GodRealmX
우리 모두가 알다시피, 사기 방지는 블록체인 분야에서 널리 사용되는 기술 솔루션입니다. 이는 Ethereum 커뮤니티에서 시작되었으며 Arbitrum 및 Optimism과 같은 잘 알려진 Ethereum Layer2에서 채택되었습니다. 2023년 비트코인 생태계가 부상한 이후 로빈 리누스는 사기 방지를 핵심 아이디어로 삼고 Taproot 등 기존 비트코인 기술을 기반으로 비트코인의 두 번째 계층 또는 브리지에 대한 새로운 보안 모델을 제공하는 BitVM이라는 솔루션을 제안했습니다.
BitVM은 논리 게이트 회로를 기반으로 한 최초의 BitVM0부터 ZK 사기 방지 및 Groth16 검증 회로를 핵심으로 하는 후기 BitVM2까지 여러 이론적 버전을 출시했습니다. BitVM과 관련된 기술적 구현 경로는 끊임없이 진화하고 성숙해지면서 많은 실무자의 관심을 끌고 있습니다. Bitlayer, Citrea, BOB, Fiamma, GoatNetwork 등 모든 사람이 들어본 적이 있는 프로젝트는 모두 BitVM을 기술적 기반으로 사용하고 있으며, 이를 기반으로 다양한 버전을 구현했습니다.
BitVM을 체계적으로 설명하는 시장 정보가 비교적 부족하고 이해하기 어렵기 때문에, 우리는 BitVM에 대한 지식을 대중화하는 것을 목표로 하는 일련의 기사를 시작했습니다. BitVM과 사기 방지 사이의 긴밀한 관계를 고려하여 이 글에서는 사기 방지와 ZK 사기 방지에 초점을 맞추고 가능한 가장 이해하기 쉬운 언어로 설명하겠습니다.
Optimism의 사기 방지 방안을 자료로 활용하여 MIPS 가상 머신과 대화형 사기 방지를 기반으로 한 방안과 ZK 기반 사기 방지의 주요 아이디어를 분석해보겠습니다.
OutputRoot 및 StateRoot
Optimism은 잘 알려진 Optimistic Rollup 프로젝트로, 그 인프라는 시퀀서(op-node, op-geth, op-batcher, op-proposer를 포함하는 주요 모듈)와 Ethereum 체인의 스마트 계약으로 구성되어 있습니다.
시퀀서가 일괄 처리된 거래 데이터를 처리하면, DA 데이터가 이더리움으로 전송됩니다. Optimism 노드 클라이언트를 실행할 수 있는 능력이 있는 한, 시퀀서가 업로드한 데이터를 로컬 컴퓨터로 다운로드할 수 있습니다. 그런 다음 이러한 트랜잭션을 로컬에서 실행하고 Optimism의 현재 상태 설정 해시(각 계정의 현재 잔액 및 기타 데이터를 포함하되 이에 국한되지 않음)를 계산할 수 있습니다.
시퀀서가 잘못된 상태 설정 해시를 이더리움에 업로드하면 로컬에서 계산한 상태 설정 해시가 달라집니다. 이때 사기 방지 시스템을 통해 의문을 제기할 수 있으며, 시스템은 판단 결과에 따라 시퀀서를 제한하거나 처벌하거나 처벌하지 않습니다.
EVM 블록체인은 "상태 집합"이라는 용어를 언급할 때 종종 머클 트리 스타일의 데이터 구조를 사용하여 상태 집합을 기록하는데, 이를 World State Trie라고 합니다. 거래가 실행된 후 일부 계정의 상태가 변경되고, World State Trie가 변경되고, 최종 해시도 변경됩니다. 이더리움은 World State Trie StateRoot의 최종 해시를 호출하는데, 이는 상태 집합의 변경 사항을 나타내는 데 사용됩니다.
아래 그림은 Ethereum stateRoot의 구성을 보여줍니다. Ethereum의 다양한 계정 잔액, 스마트 계약 계정과 관련된 코드 해시 및 기타 데이터가 World State Trie에 집계되고, 이를 기반으로 stateRoot가 계산되는 것을 볼 수 있습니다.
Optimism의 계정 시스템과 데이터 구조는 Ethereum과 거의 일치하며, StateRoot 필드를 사용하여 상태 집합의 변경 사항을 반영합니다. OP 시퀀서는 OutputRoot라는 키 필드를 주기적으로 Ethereum에 업로드하고, OutputRoot 필드는 StateRoot와 다른 두 필드에 의해 계산됩니다.
원래 질문으로 돌아가 봅시다. OP의 노드 클라이언트를 실행하고 StateRoot와 현재 OutputRoot를 로컬로 계산할 때 계산한 결과가 OP 시퀀서가 업로드한 결과와 일치하지 않는 경우 사기 방지를 시작할 수 있습니다. 그렇다면 구체적인 메커니즘은 무엇일까? 아래에서는 MIPS 가상 머신 상태 검증과 대화형 사기 방지를 각각 소개합니다.
MIPS 가상 머신 및 메모리 Merkle Tree
앞서 언급했듯이 OP 시퀀서가 제출한 OutputRoot에 문제가 있는 경우 "챌린지"를 시작할 수 있습니다. 챌린지 프로세스에는 체인에서 일련의 상호 작용 작업을 완료해야 합니다. 상호 작용이 완료된 후 관련 스마트 계약은 OP 시퀀서가 잘못된 OutputRoot를 업로드했는지 여부를 판별합니다.
OutputRoot의 정확성을 확인하기 위해 체인에서 스마트 계약을 사용하려면 가장 쉬운 방법은 Ethereum 체인에 OP 노드 클라이언트를 구현하고 OP 시퀀서와 동일한 입력 매개변수를 사용하고 동일한 프로그램을 실행한 다음 계산 결과가 일관성이 있는지 확인하는 것입니다. 이 방식은 오류 방지 프로그램(Fault Proof Program)이라고 불리며, 오프체인에서 구현하기는 쉽지만 이더리움 체인에서 실행하기는 매우 어렵습니다. 두 가지 문제가 있기 때문입니다.
1. 이더리움의 스마트 계약은 사기 방지에 필요한 입력 매개변수를 자동으로 얻을 수 없습니다.
2. 이더리움의 각 블록의 가스 한도는 제한되어 있어 너무 복잡한 계산 작업을 지원하지 않습니다. 체인에서 OP 노드 클라이언트를 완전히 구현할 수 없습니다.
첫 번째 문제는 온체인 스마트 계약이 오프체인 데이터를 읽을 수 있도록 허용하는 것과 동일하며, 이는 오라클과 유사한 솔루션을 통해 해결될 수 있습니다. OP는 특별히 Ethereum 체인에 PreimageOracle 계약을 배포했으며, 사기 방지 관련 계약은 PreimageOracle에서 필요한 데이터를 읽을 수 있습니다.
이론적으로는 누구나 계약에 데이터를 업로드할 수 있지만 OP의 사기 방지 시스템은 데이터가 필요한지 여부를 식별하는 방법이 있습니다. 구체적인 프로세스는 이 기사의 핵심 주제와 관련이 없으므로 여기서는 논의하지 않습니다.
두 번째 질문에 대해 OP 개발팀은 Solidity로 MIPS 가상 머신을 작성했고, 이를 통해 OP 노드 클라이언트의 일부 기능이 구현되었으며, 이는 사기 방지 시스템에 충분합니다. MIPS는 일반적인 CPU 명령어 집합 아키텍처이며, OP 시퀀서의 코드는 Golang/Rust와 같은 고급 언어로 작성됩니다. Golang/Rust로 작성된 프로그램을 MIPS 프로그램으로 컴파일한 다음, Ethereum 체인의 MIPS 가상 머신을 통해 처리할 수 있습니다.
OP 개발팀은 사기 방지에 필요한 최소한의 프로그램을 작성하기 위해 Golang을 사용했는데, 이는 기본적으로 OP 노드의 거래 실행, 블록 생성, OutputRoot 모듈 기능과 일치합니다. 하지만 이 간소화된 절차는 아직 "완전히 구현"될 수 없습니다.
즉, 각 OP 블록에는 많은 트랜잭션이 포함됩니다. 이 일괄 트랜잭션을 처리한 후 OutputRoot를 얻습니다. OutputRoot가 잘못된 블록 높이가 어디인지 알고 있더라도, 해당 OutputRoot가 잘못되었다는 것을 증명하기 위해 체인에 있는 블록에 포함된 모든 트랜잭션을 실행하는 것은 비현실적입니다.
또한, 각 거래의 실행 프로세스에는 일련의 MIPS 명령어를 순서대로 처리하는 것이 포함됩니다. 온체인 계약에서 구현한 MIPS 가상 머신에서 이 명령어 시리즈를 실행할 수 없습니다. 컴퓨팅 오버헤드와 가스 소비가 너무 크기 때문입니다.
이러한 목적을 달성하기 위해 Optimism 팀은 OP의 거래 처리 흐름을 심층적으로 개선하는 것을 목적으로 하는 대화형 사기 방지 시스템을 설계했습니다. OutputRoot의 전체 계산 과정에서 OP 시퀀서의 MIPS 가상 머신에서 MIPS 명령어를 처리할 때 오류가 발생했음을 알 수 있습니다. 오류가 확인되면 시퀀서에서 제공한 OutputRoot가 유효하지 않다는 결론을 내릴 수 있습니다.
그러면 문제가 명확해집니다. OP 시퀀서가 트랜잭션 패키징 블록을 처리하는 프로세스는 엄청난 수의 MIPS 명령어를 순서대로 처리하는 것으로 나눌 수 있습니다. 각 MIPS 명령어가 실행된 후 가상 머신의 상태 해시가 변경되고 이러한 레코드를 Merkle 트리로 요약할 수 있습니다.
대화형 사기 방지 프로세스에서는 OP 시퀀서가 어떤 MIPS opcode를 실행하는지와 가상 머신의 상태 해시에 문제가 있는지 확인해야 합니다. 그런 다음 그 당시 MIPS 가상 머신의 상태를 체인에 재현하고 opcode를 실행한 후 후속 상태 해시가 시퀀서가 제출한 결과와 일치하는지 확인합니다. 체인에서 MIPS 명령어가 하나만 실행되므로 복잡도가 높지 않고 계산 과정은 Ethereum 체인에서 완료될 수 있습니다. 하지만 이를 위해서는 MIPS 가상 머신의 상태 정보(예: 일부 메모리 데이터)를 체인에 업로드해야 합니다.
코드 구현 수준에서 이더리움 체인의 사기 방지와 관련된 스마트 계약은 Step이라는 다음 함수를 통해 최종 MIPS 명령어 실행 프로세스를 완료합니다.
위 함수 매개변수의 _stateData와 _proof는 MIPS 가상 머신의 레지스터 상태, 메모리 상태 해시 등과 같은 단일 MIPS 명령어 실행의 종속 데이터 항목을 나타냅니다. 개략도는 다음과 같습니다.
_stateData와 _proof를 통해 이러한 MIPS 가상 머신의 환경 매개변수를 입력하고, 체인에서 단일 MIPS 명령어를 실행하여 권위 있는 결과를 얻을 수 있습니다. 체인에서 얻은 권위 있는 결과가 시퀀서가 제출한 결과와 일치하지 않으면 시퀀서가 악한 일을 하고 있다는 것을 의미합니다.
일반적으로 _stateData의 해시를 statehash라고 부르는데, 이는 대략 MIPS 가상 머신 상태의 해시로 이해할 수 있습니다. _stateData의 여러 필드 중에서 memRoot는 가장 독창적인 디자인입니다. 우리가 아는 것처럼 프로그램은 실행되는 동안 많은 양의 메모리를 차지하고, CPU는 일부 메모리 주소에 있는 데이터를 읽고 쓰는 상호작용을 합니다. 따라서 체인의 VM.Step 함수를 통해 MIPS 명령어를 실행할 때 MIPS 가상 머신의 메모리 주소에 데이터를 제공해야 합니다.
OP는 32비트 MIPS 가상 머신을 사용하는데, 그 메모리에는 총 2의 27승 주소가 들어 있으며, 이를 28계층 바이너리 머클 트리로 구성할 수 있습니다. 최하위 계층에는 2의 27승 잎이 있으며, 각 잎은 가상 머신의 메모리 주소에 데이터를 기록합니다. 모든 리프의 데이터가 집계된 후 계산된 해시는 memRoot입니다. 다음 그림은 MIPS 가상 머신의 메모리 데이터를 기록하는 머클 트리의 구조를 보여줍니다.
step 함수의 _proof 필드를 통해 Ethereum 체인에 업로드되는 메모리 주소에 있는 일부 내용을 제공해야 합니다. 여기서는 또한 메모리 머클 트리를 기반으로 한 머클 증명을 업로드하여 귀하/시퀀서가 제공한 데이터가 메모리 머클 트리에 실제로 존재하며 허구가 아니라는 것을 증명해야 합니다.
대화형 사기 방지
위에서 우리는 두 번째 문제를 해결하고 MIPS 명령어의 온체인 실행과 가상 머신 상태 검증을 완료했습니다. 하지만 챌린저와 시퀀서는 논란의 여지가 있는 MIPS 명령어 명령을 어떻게 찾을까요?
많은 사람들이 인터넷에서 상호작용 사기 방지에 대한 간단한 설명을 읽고 그 이분법에 대해 들어봤을 것이라고 생각합니다. OP팀은 Fault Dispute Game(FDG)이라는 프로토콜을 개발했습니다. FDG에는 도전자와 수비자의 두 가지 역할이 있습니다.
시퀀서가 체인에 제출한 OutputRoot에 문제가 있음을 발견하면, 우리는 FDG에서 도전자 역할을 할 수 있고 시퀀서는 방어자 역할을 하게 됩니다. 위에서 언급된 체인에서 처리해야 하는 MIPS 명령어를 찾기 위해 FDG 프로토콜은 모든 참가자가 다음과 같은 특정 구조를 갖는 GameTree라는 Merkle 트리를 로컬로 구축하도록 요구합니다.
GameTree는 실제로 매우 복잡하고, 1차 트리와 2차 서브트리로 구성된 계층적 중첩 관계가 있다는 것을 알 수 있습니다. 다시 말해, 1차 트리의 하단 리프 자체에 트리가 들어 있습니다.
앞서 언급했듯이, 시퀀서가 생성한 각 블록에는 OutputRoot가 포함되어 있으며, GameTree의 1차 트리의 리프 노드는 다양한 블록의 OutputRoot입니다. 도전자와 방어자는 OutputRoot로 구성된 머클 트리에서 상호 작용하여 어느 블록의 OutputRoot가 논란의 여지가 있는지 확인해야 합니다.
분쟁 블록을 식별한 후, GameTree의 두 번째 레벨로 들어가보겠습니다. 2차 트리도 머클 트리이고, 가장 아래의 리프는 위에서 소개한 MIPS 가상 머신의 상태 해시입니다. 사기 방지 시나리오에서 분쟁 당사자가 로컬로 구성한 GameTree의 일부 리프 노드는 일관되지 않으며, 특정 명령어를 처리한 후의 가상 머신 상태 해시는 다르게 나타납니다.
그 후 두 당사자는 체인에서 여러 차례 상호작용을 하였고, 마침내 분쟁 영역을 찾아내고 체인에서 실행해야 할 단일 MIPS 명령어를 결정했습니다.
이 시점에서 우리는 상호작용 사기 방지의 전체 과정을 완료했습니다. 요약하자면, 대화형 사기 방지에는 두 가지 핵심 메커니즘이 포함되어 있습니다.
1. FDG는 먼저 체인에서 실행되어야 하는 MIPS 명령어와 해당 시점의 VM 상태 정보를 찾습니다.
2. Ethereum 체인에 구현된 MIPS 가상 머신에서 명령어를 실행하여 최종 결과를 얻습니다.
ZK화된 사기 방지
위에서 설명한 기존 사기 방지의 상호작용은 매우 복잡하여 FDG 프로세스에서 여러 라운드의 상호작용이 필요하고 그 다음 체인에서 단일 명령을 다시 실행해야 한다는 것을 알 수 있습니다. 하지만 이 솔루션에는 여러 가지 어려움이 있습니다.
1. 이더리움 체인에서 여러 라운드의 상호작용이 트리거되어야 하며, 이를 위해 수십 번의 상호작용이 필요하고 많은 가스 비용이 발생합니다.
2. 상호작용 사기 방지 프로세스는 길다. 상호작용이 시작되면 Rollup은 정상적으로 거래를 실행할 수 없다.
3. 체인에 특정 VM을 구현하여 지침을 재생하는 것은 비교적 복잡하고 개발하기가 매우 어렵습니다.
이러한 문제를 해결하기 위해 Optimism은 공식적으로 ZK 사기 방지라는 개념을 제안했습니다. 핵심은 도전자가 도전할 때 체인에서 재생해야 한다고 생각하는 거래를 지정한다는 것입니다. Rollup 시퀀서는 도전된 거래의 ZK 증명을 제공하고, 이는 Ethereum의 스마트 계약에 의해 검증됩니다. 검증이 통과되면 거래의 처리 흐름이 정확하고 Rollup 노드가 악의적인 일을 하지 않은 것으로 간주할 수 있습니다.
위 사진의 챌린저는 챌린저이고, 디펜더는 OP 시퀀서입니다. 일반적인 상황에서 OP 시퀀서는 수신된 거래를 기반으로 블록을 생성하고 다양한 블록의 상태 커미트먼트를 이더리움에 제출하는데, 이는 간단히 블록의 해시 값으로 간주될 수 있습니다. 도전자는 블록 해시를 기준으로 도전할 수 있습니다. Defender는 도전을 수락한 후 블록 생성 결과에 오류가 없음을 증명하기 위해 ZK 증명을 생성합니다. 위 사진의 본사이는 실제로 ZK Proof 생성 도구입니다.
대화형 사기 방지와 비교했을 때 ZK 사기 방지의 가장 큰 장점은 여러 라운드의 상호작용을 한 라운드의 ZK 방지 증명 생성과 온체인 검증으로 바꾸어 많은 시간과 가스 비용을 절약한다는 것입니다. ZK 롤업과 비교했을 때, ZK 사기 증명을 기반으로 하는 OP 롤업은 각 블록에 대한 증명을 생성할 필요가 없습니다. 도전을 받을 때만 일시적으로 ZK 증명을 생성하므로 롤업 노드의 컴퓨팅 비용도 줄어듭니다.
BitVM2도 ZK 기반 사기 방지 아이디어를 채택했습니다. Bitlayer, Goat Network, ZKM, Fiama 등 BitVM2를 사용하는 프로젝트는 비트코인 스크립트를 통해 ZK Proof 검증 프로그램을 구현하고 체인에 업로드해야 하는 프로그램의 크기를 크게 단순화합니다. 공간 제한으로 인해 이 기사에서는 자세히 다루지 않습니다. BitVM2에 대한 후속 기사를 기다려 구현 경로에 대한 더 깊은 이해를 얻으세요. 계속 지켜봐 주세요!
