로그인/ 가입하기

BitVM 지식: 사기 방지 및 ZK 사기 방지 구현 아이디어

2025/02/27 17:10

따르다

셰우 & 노아, 페어리 로움 GodRealmX

우리 모두 알다시피 사기 증명은 블록체인 공간에서 널리 사용되는 기술 솔루션으로, 이더리움 커뮤니티에서 처음 시작되어 다음과 같이 발전해왔습니다. 2023년 비트코인 생태계가 부상한 후, 로빈 라이너스는 사기 증명을 핵심 아이디어로 사용하고 탭루트와 같은 기존 비트코인 기술을 기반으로 비트코인 레이어 2 또는 브리지를 위한 새로운 보안 모델을 제공하는 BitVM이라는 체계를 제안했습니다.

BitVM은 논리 게이트 회로를 기본으로 하는 초기 BitVM0부터 ZK 사기 증명과 Groth16 검증 회로를 핵심으로 하는 후기 BitVM2까지 여러 이론적 버전이 있으며, BitVM 관련 기술 구현 경로가 계속 발전해왔고 많은 실무자들의 관심을 끌며 성숙해지는 경향이 있습니다. 비트레이어, 시트레아, BOB, 피암마, 고트 네트워크는 모두 프로젝트의 기술적 뿌리 중 하나인 비트VM을 기반으로 하며, 이를 기반으로 다양한 버전의 구현이 이루어지고 있습니다.

시장에 BitVM에 대한 체계적인 설명이 부족하다는 점을 고려하여 BitVM 지식의 대중화를 목표로 한 시리즈 기사를 시작하게 되었습니다. 이 글에서는 BitVM과 Fraud Proof의 뿌리 깊은 관계를 고려하여 Fraud Proof와 ZK Fraud Proof를 주요 주제로 삼아 최대한 알기 쉬운 언어로 설명하고자 합니다.

옵티미즘의 사기 방지 솔루션을 소스 자료로 사용하여 MIPS VM 기반 및 대화형 사기 방지 솔루션과 ZK Fraud Proof의 주요 아이디어를 분석해 보겠습니다.

(Optimism). 대화형 사기 방지를 위한 메커니즘 원리)

출력루트와 상태루트

옵티미즘은 잘 알려진 옵티미즘 롤업 프로젝트로, 이더 체인의 시퀀서(주요 모듈에는 op-node, op-geth, op-batcher, op-proposer가 포함됨)와 스마트 콘트랙트로 구성된 인프라를 보유하고 있습니다.

시퀀서에 의해 트랜잭션 데이터 배치가 처리되면, 이 DA 데이터가 이더로 전송됩니다. 옵티미즘 노드 클라이언트를 실행할 수만 있다면 시퀀서가 업로드한 데이터를 로컬에서 다운로드할 수 있으며, 그 후 이러한 트랜잭션을 로컬에서 실행하여 옵티미즘의 현재 상태 집합 해시(각 계정의 현재 잔액과 같은 데이터를 포함하되 이에 국한되지 않음)를 계산할 수 있습니다.

시퀀서가 잘못된 상태 집합 해시를 이더리움에 업로드하면 로컬로 계산된 상태 집합 해시가 달라지며, 이는 사기를 통해 이의를 제기할 수 있습니다. 그러면 로컬 상태 집합 해시가 달라지며, 부정 증명 시스템을 통해 이의를 제기할 수 있으며, 판결에 따라 시퀀서를 제한하거나 불이익을 줄 수도 있습니다.

"상태 집합"이라는 용어와 관련하여, EVM 블록체인은 종종 머클 트리 스타일의 데이터 구조를 사용하여 월드 스테이트 트라이라고 하는 상태 집합을 기록합니다. 트랜잭션이 실행되면 특정 계정의 상태가 변경되고, 월드 스테이트 트라이가 변경되며, 최종 해시도 변경됩니다. 이더리움에서는 월드 스테이트 트라이의 최종 해시를 스테이트 루트라고 하며, 이는 상태 집합의 변경 사항을 나타냅니다.

다음 다이어그램은 이더 스테이트 루트의 구성을 보여줍니다. 이더의 여러 계정 잔액, 스마트 컨트랙트 계정과 연결된 코드의 해시, 기타 데이터가 월드 스테이트 트라이에 집계되어 스테이트 루트가 계산되는 것을 볼 수 있습니다."

옵티미즘의 계정 시스템과 데이터 구조는 대체로 이더와 상태 집합의 변화를 반영하기 위해 StateRoot 필드를 사용하는 등 이더리움과 대체로 일치합니다. OP 시퀀서는 주기적으로 출력루트라는 키 필드를 Ether에 업로드하며, 이는 StateRoot와 다른 두 개의 필드에서 계산됩니다.
원본으로 돌아가서 계속하기 OP의 노드 클라이언트를 실행하고 로컬에서 StateRoot와 현재 OutputRoot를 계산할 때, 계산한 결과가 OP의 시퀀서가 업로드한 결과와 일치하지 않는다면 부정 증명을 시작할 수 있습니다. 그렇다면 이 메커니즘은 어떻게 작동할까요? 아래에서 MIPS VM 상태 검증과 대화형 부정 증명에 대해 차례로 소개하겠습니다.
MIPS VM과 메모리 머클 트리
앞에서도 언급했듯이 OP 시퀀서가 제출한 OutputRoot에서 문제를 발견했다고 가정해 봅시다.
OP 시퀀서가 체인에 잘못된 OutputRoot를 업로드했다고 이의를 제기하려면 체인과의 일련의 상호작용을 완료해야 하며, 관련 스마트 컨트랙트가 OP 시퀀서가 잘못된 OutputRoot를 업로드했는지 여부를 결정하게 됩니다. strong>출력루트의 정확성을 스마트 컨트랙트로 온체인에서 확인하려면, 가장 쉬운 방법은 OP 노드 클라이언트에서 이더온체인을 구현하는 것입니다. OP 시퀀서에서 동일한 입력 매개변수를 사용하여 동일한 프로시저를 실행하고 계산이 일관성이 있는지 확인합니다. 이 체계를 장애 증명 프로그램이라고 하며, 오프체인에서는 구현하기 쉽지만 이더 체인에서 실행하기는 매우 어렵습니다. 두 가지 문제가 있기 때문입니다.
1. 이더의 스마트 컨트랙트는 사기 증명에 필요한 입력 매개변수를 자동으로 가져올 수 없음.
2. 이더의 블록당 가스 한도는 제한, 과도한 복잡성의 계산 작업을 지원하지 않음, 체인에서 OP 노드 클라이언트를 완전히 구현할 수 없음
첫 번째 문제는 온체인 스마트 컨트랙트가 오프체인 데이터를 읽도록 하는 것과 동일하며, 이는 예언 머신과 유사한 솔루션으로 해결할 수 있습니다. OP는 PreimageOracle 컨트랙트를 이더 체인에 특정하게 배포했습니다. 위조 증명 관련 컨트랙트는 PreimageOracle 내에서 사용할 수 있습니다. 내에서 필요한 데이터를 읽습니다.
이론적으로는 누구나 원하는 만큼의 데이터를 계약에 업로드할 수 있지만, OP의 부정 증명 시스템에는 필요한 데이터인지 여부를 식별하는 방법이 있으며, 정확한 과정은 이 글의 핵심 주제에 중요하지 않으므로 여기서는 다루지 않겠습니다.
두 번째 문제의 경우, OP 개발팀은 솔리디티를 구현하는 MIPS 가상 머신을 S에 작성하여 구현했습니다. 사기 방지 시스템에서 사용할 수 있을 만큼의 일부 기능을 구현하는 가상 머신을 개발했습니다. MIPS는 일반적인 CPU 명령어 집합 아키텍처로, OP 시퀀서 코드는 Golang/Rust와 같은 상위 언어로 작성되어 있으므로 Golang/Rust로 작성된 프로그램을 MIPS 프로그램으로 컴파일하여 이더넷 체인에서 MIPS VM을 통해 처리할 수 있습니다.
OP의 개발팀은 트랜잭션, 블록 생성, OutputRoot를 수행하는 OP 노드의 모듈과 본질적으로 동일한 기능을 하는 사기 증명에 필요한 가장 단순한 프로그램 집합을 작성하기 위해 Golang을 사용했습니다. 그러나 이 간소화된 프로세스는 여전히 "완전히 실행 가능한" 것은 아닙니다. 각 OP 블록에는 여러 트랜잭션이 포함되어 있으며, 이 트랜잭션이 처리되면 OutputRoot가 생성되고, 어느 블록 높이에서 어떤 OutputRoot가 잘못되었는지 알 수 있지만, 해당 블록의 트랜잭션을 체인 위로 실행하여 해당 OutputRoot가 잘못되었다는 것을 증명할 수는 없습니다. 해당 블록에 포함된 모든 트랜잭션을 체인에 올려놓고 이를 실행하여 해당 OutputRoot에 오류가 있음을 증명하는 것은 실용적이지 않습니다.
또한, 각 트랜잭션은 실행 과정에서 일련의 MIPS 옵코드를 포함하며, 온체인 컨트랙트로 구현된 MIPS VM에서는 연산 오버헤드와 가스 소비가 너무 크기 때문에 이 일련의 옵코드를 실행할 수 없습니다. 오버헤드와 가스 소비가 너무 크기 때문입니다.
(MIPS 명령어 집합 작동)
이를 위해 옵티미즘 팀은 OP의 트랜잭션 처리 흐름을 세밀하게 파악하는 것을 목표로 대화형 사기 증명 시스템을 설계했습니다. 출력루트의 전체 연산 흐름에서 OP 시퀀서의 MIPS 가상 머신에서 어떤 MIPS 옵코드가 오류로 처리되는지 관찰합니다. 오류가 확인되면 시퀀서에서 제공한 OutputRoot가 유효하지 않다는 결론을 내릴 수 있습니다.
그러면 문제가 명확해집니다. 트랜잭션으로 가득 찬 블록에 대한 OP 시퀀서의 처리는 엄청난 수의 MIPS 옵코드를 순서대로 처리하는 것으로 분해할 수 있으며, 각 MIPS 옵코드 실행 후 VM의 상태 해시가 변경되며, 이는 다음과 같이 요약할 수 있습니다. 머클 트리.
대화형 위변조 증명 과정에서는 OP 시퀀서가 어떤 MIPS 옵코드를 실행한 후 VM의 상태 해시가 이상하게 되었는지 파악하고, 그 시점의 MIPS VM의 상태를 체인에서 재현하여 옵코드를 실행하고 이후 상태 해시가 시퀀서가 제출한 결과와 일치하는지 관찰하는 것이 중요합니다. 시퀀서가 제출한 결과와 일치하는지 확인합니다. 체인에서 하나의 MIPS 옵코드만 실행되므로 복잡도가 높지 않고 계산 과정을 이더넷 체인에서 수행할 수 있습니다. 하지만 이를 위해서는 일부 메모리 데이터 등 MIPS VM의 상태 정보를 체인에 업로드해야 합니다.
코드 구현 수준에서. 이더 체인에서 사기 증명과 관련된 스마트 컨트랙트는 다음 함수를 통과하게 됩니다명명된 단계. 마지막 MIPS 옵코드 실행 흐름 완료:
위 함수 파라미터의 _stateData와 _proof는 MIPS VM의 레지스터 상태 등 단일 MIPS 옵코드 실행을 위한 종속 데이터 항목을 나타냅니다, 메모리 상태 해시 등 도식은 다음과 같습니다.
우리는 < code>_stateData 및 _proof 입력을 이러한 MIPS VM의 환경 파라미터에 전달하고 체인에서 단일 MIPS 명령어를 실행하여 신뢰성 있는 결과를 얻을 수 있습니다. 체인에서 도출된 권위 있는 결과가 시퀀서가 제출한 결과와 일치하지 않는 경우 시퀀서가 악을 행하고 있다고 합니다.
우리는 일반적으로 _stateData의 stateData의 해시를 일반적으로 statehash라고 부르는데, 이는 대략 전체 MIPS 가상 머신의 상태 해시로 해석할 수 있습니다. memRoot는 _stateData의 여러 필드 중 가장 미묘하게 설계된 필드입니다. 우리 모두 알다시피, 프로그램은 실행 중에 많은 양의 메모리를 차지하게 되며, CPU는 일부 메모리 주소에서 데이터와 상호 작용하게 됩니다. 따라서 VM.Step 함수를 통해 체인으로 MIPS 연산 코드를 실행할 때 MIPS VM의 일부 메모리 주소에 데이터를 제공해야 합니다.
이 연산은 32비트 아키텍처의 MIPS VM을 사용하며, 메모리는 총 2의 27승의 주소로 구성되어 있고, 28레벨로 분기된 머클 트리로 구성할 수 있으며, 가장 아래 레벨에 2의 27승의 리프가 있고 각 리프는 VM의 메모리 주소 중 하나에 데이터를 기록합니다. 데이터. 모든 리프의 데이터를 합산하여 계산된 해시가 memRoot입니다. 다음 그림은 MIPS VM의 메모리 데이터를 기록하는 머클 트리의 구조를 보여줍니다.
메모리 주소에 콘텐츠의 일부를 제공해야 하며, 이는 step 함수의 _proof 필드를 통해 이더 체인에 업로드됩니다. 인메모리 머클 트리에 기반한 머클 증명도 여기에 업로드되어, 사용자/시퀀서가 제공한 데이터가 실제로 인메모리 머클 트리에 존재하며 허공에서 만들어지지 않았음을 증명합니다.
대화형 부정 증명
위에서는 이미 VM 상태 검증으로 MIPS 연산 코드의 연쇄 실행을 완료하여 두 번째 문제를 해결했지만, 다음과 같은 문제가 있습니다. 챌린저와 시퀀서는 논란이 되고 있는 MIPS 옵코드 명령어를 어떻게 찾아야 할까요?
많은 분들이 온라인에서 대화형 부정 증명에 대한 간단한 설명을 어느 정도 읽어보셨을 것이고, 그들의 이분법적인 생각에 대해 들어보셨을 것입니다.OP 팀은 도전자와 방어자의 두 가지 역할이 있는 결함 분쟁 게임(FDG)으로 알려진 일련의 프로토콜을 개발했습니다. .
시퀀서가 체인에 제출한 OutputRoot에 문제를 발견하면 FDG에서 우리는 도전자 역할을 하고 시퀀서는 방어자 역할을 하게 됩니다. 체인에서 처리해야 하는 앞서 언급한 MIPS 연산자를 쉽게 찾기 위해, FDG 프로토콜은 참여자들이 모두 로컬에서 Merkle트리를 구성하도록 요구합니다. GameTree라고 하며 다음과 같이 구조화됩니다:
게임트리는 실제로 계층적 중첩 관계, 즉 1레벨 트리와 2레벨 하위 트리로 구성된 상당히 복잡한 구조, 즉 1레벨 트리의 하단 리프에 트리 자체가 포함되어 있음을 알 수 있습니다.
앞에서 설명했듯이 시퀀서에 의해 생성된 각 블록은 OutputRoot를 포함하며, GameTree의 1레벨 트리의 리프 노드는 다른 블록의 OutputRoot입니다.도전자와 방어자< OutputRoot로 구성된 머클 트리에서 상호 작용해야 하는 결정을 해야 합니다. 어떤 블록에 분쟁이 있는 OutputRoot가 있는지 확인합니다.
분쟁 중인 블록을 식별한 후에는 게임트리의 두 번째 레벨로 내려갑니다. 트리의 두 번째 레벨도 머클 트리이며, 맨 아래 잎 자식 은 주입니다. strong>상태해시입니다. 부정 증명 시나리오에서는 분쟁 당사자가 로컬로 구성한 게임트리의 리프 노드 중 일부가 일치하지 않으며 특정 옵코드 처리 후 VM의 상태 해시는 다음과 같습니다. 다르게 동작합니다.
그 후, 양 당사자는 체인에서 여러 번 상호 작용하고, 최종적으로 분쟁이 발생한 위치를 찾아 체인에서 실행해야 하는 단일 MIPS 옵코드를 식별합니다.
이 시점에서 저희는 대화형 사기 방지의 전체 프로세스를 완료했습니다. 요약하자면, 대화형 부정 증명은 두 가지 핵심 메커니즘으로 구성됩니다.
1. FDG가 먼저 실행을 위해 업로드해야 하는 MIPS 옵코드와 해당 시점의 VM 상태 정보를 찾습니다.
2. 이더넷 체인에 구현된 MIPS VM의 연산 코드를 실행하여취득합니다. 최종 결과를 얻습니다.
ZK 기반 사기 증명
위 전통적인 사기 증명은 매우 복잡하며, FDG 프로세스 내에서 여러 차례의 상호작용을 거친 다음 단일 인스트럭션을 체인 위로 재생해야 합니다. 그러나 이 솔루션에는 몇 가지 어려움이 있습니다.
1. 이더 체인에서 여러 차례의 상호작용이 트리거되어야 하며, 이는 거의 수십 번의 상호작용이 필요하고 많은 양의 가스 비용이 발생합니다.
2. 대화형 사기 증명 과정이 더 길어지고, 일단 상호 작용이 시작되면 상호작용이 시작되면 롤업이 트랜잭션을 제대로 실행할 수 없습니다.
3. 체인에서 특정 VM을 구현하여 명령을 재생하는 것은 더 복잡하고 개발하기가 매우 어렵습니다.
이러한 문제를 해결하기 위해, O<< Official은 ZK Fraud Proof라는 개념을 고안해냈습니다. 핵심은 챌린저가 챌린지를 할 때 체인에서 재생되어야 한다고 생각하는 트랜잭션을 지정하면 롤업 시퀀서가 챌린지된 트랜잭션에 대한 ZK 증명을 제공하고, 이를 이더의 스마트 컨트랙트로 검증하여 검증을 통과하면 트랜잭션이 오류 없이 처리되었으며 롤업 노드가 악행을 저지르지 않은 것으로 간주한다는 것입니다.
위 다이어그램에서 챌린저는 챌린저이고 디펜더는 OP 시퀀서입니다. 일반적인 상황에서 OP 시퀀서는 들어오는 트랜잭션을 기반으로 블록을 생성하고 각 블록의 상태를 이더에 커밋하는데, 이는 간단히 블록의 해시라고 생각하면 됩니다. 챌린저는 블록 해시를 기반으로 도전할 수 있고, 도전을 수락한 방어자는 블록 생성에 오류가 없음을 증명하기 위해 ZK 증명을 생성합니다. 위 이미지의 분재는 실제로 ZK 증명 생성 도구입니다.
대화형 부정 증명에 비해 ZK Fraud Proof의 가장 큰 장점은 여러 차례의 상호작용을 한 번의 ZK Proof 생성 및 온체인 검증으로 줄여 많은 시간과 에너지를 절약할 수 있다는 점입니다. 또한 ZK 롤업에 비해 ZK 사기 증명 기반 OP 롤업은 블록이 나올 때마다 증명을 생성할 필요가 없으며, 이의를 제기할 때만 일시적으로 ZK 증명을 생성하므로 롤업 노드의 계산 비용도 절감할 수 있습니다.
ZK를 사용한 사기 증명 아이디어는 BitVM2에서도 사용됩니다. 비트레이어, 고트 네트워크, ZKM, 피아마 등 BitVM2를 채택한 프로젝트 당사자들은 비트코인 스크립트를 통해 ZK 증명 검증 프로세스를 구현하고 체인에 있어야 하는 프로세스 규모를 크게 간소화합니다. 지면 관계상 이 글에서는 자세히 다루지 않겠지만, BitVM2에 대한 글에서 구현 경로에 대해 자세히 설명할 예정이니 기대해 주시기 바랍니다!