게임 진행 중: OP Stack의 결함 증명 시스템을 위한 모듈형 분쟁 게임 설계
작성자: clabby • 2023년 9월 19일브라우저에서 보기
OP Stack의 Fault Proof System(FPS)에서 가장 재미있는 구성 요소 중 하나가 분쟁 게임이라는 것은 우연이 아닙니다. FPS에 대한 이전 게시물에서는 OP 스택의 모듈성을 통해 FPP(결함 방지 프로그램)를 FPVM(결함 방지 가상 머신)에서 분리하여 두 구성 요소 모두에 대한 다음 단계의 구성성과 효율적인 병렬 업그레이드를 가능하게 하는 방법을 설명했습니다. 분쟁 게임의 경우에도 거의 기하급수적으로 마찬가지입니다.
이 게시물에서는 분쟁 게임이 슈퍼체인 생태계 내 분산형 오류 감지에서 수행할 역할, 분쟁 프로토콜을 기반으로 오류 방지 분쟁 게임이 구축된 방법, 분쟁 프로토콜의 확장성 덕분에 나타나는 가능성을 살펴봅니다.
분쟁 게임에 대한 더 자세한 내용을 알고 싶다면 몇 주 전에 내 개인 블로그에 이 게시물의 훨씬 긴 버전을 공유했습니다.
분쟁게임이란?
분쟁 게임은 분쟁 프로토콜의 핵심 기본 요소입니다. 이는 간단한 상태 머신을 모델로 하며 유효성이 논쟁의 여지가 있는 모든 정보에 대해 32바이트 약속으로 초기화됩니다. 여기에는 이 약속을 참 또는 거짓으로 결정하는 기능이 포함되어 있으며, 이는 기본 요소의 구현자가 정의하도록 남겨져 있습니다. OP 스택의 첫 번째 분쟁 게임 구현인 는 FaultDisputeGame에뮬레이트된 VM을 기반으로 한 결함 방지 프로그램 실행 결과에 따라 해결 기능이 결정되기 때문에 허가가 없습니다.
분쟁 게임 자체는 두 가지 기본 속성에 의존합니다.
-
인센티브 호환성 : 시스템은 공정한 참여를 보장하기 위해 허위 주장에 처벌을 가하고 진실한 주장에 보상합니다.
-
해결 : 각 게임에는 루트 주장을 확실하게 검증하거나 무효화하는 메커니즘이 있습니다.
분쟁 프로토콜에서는 를 통해 다양한 유형의 분쟁 게임을 생성, 관리 및 업그레이드할 수 있습니다 [DisputeGameFactory](<https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/dispute/DisputeGameFactory.sol>). FaultDisputeGame이는 집계 증명 시스템 및 온체인 바이너리 검증에 맞춰진 L2 상태와 별도로 논쟁을 허용하는 프로토콜 확장 기능과 같은 혁신적인 기능의 문을 열어줍니다.
이등분 게임
이는 특정 유형의 분쟁 게임이며 OP 스택의 분쟁 프로토콜에 구축된 최초의 게임입니다. 이 게임에서 플레이어는 개별 단계에 도달할 때까지 실행 추적을 나누어 앞뒤로 이동합니다. 이분법이 개별 추적 명령의 상태에 도달한 후 FaultDisputeGame일반 VM을 사용하여 체인에서 단일 명령 단계를 실행합니다. T 라고 부르는 VM의 상태 전환 함수는 T(s, i) -> s' 형식을 준수하는 한 무엇이든 될 수 있습니다. 여기서 s = 합의된 사전 상태, i = 상태 전환 입력 , s' = 게시 상태입니다.
이분법 게임에서 VM 일반의 첫 번째 전체 구현을 위해 EVM 위에 단일 MIPS 스레드 컨텍스트를 구현하여 Cannon및 에 의해 생성된 실행 추적 내에서 단일 명령을 실행했습니다 op-program.
청구
클레임은 지정된 명령에서 백엔드 VM 상태에 대한 약속을 나타냅니다. 이는 사실이거나 거짓일 수 있으며 진실성은 해결 단계 후에 결정됩니다. 반박되지 않으면 주장은 사실로 간주됩니다.
직위
클레임은 이진 트리의 위치에 존재합니다. 위치는 해당 주장이 어떤 명령과 관련되어 있는지를 나타냅니다. 포지션은 일반화된 지수로, 다음과 같이 정의할 수 있습니다.2^{depth} + index_at_depth.
체스 시계
플레이어는 움직일 수 있는 시간 제한이 있습니다. 이 게임은 허가가 없으므로 누구나 참여할 수 있습니다. 각 팀은 3.5일로 시작하여 총 7일의 게임 시간을 갖습니다. 새로운 경로를 만들거나 이미 클레임을 받은 위치에서 클레임을 하는 경우에는 조부모님의 시계를 상속받습니다.
이동
플레이어는 클레임이 단 하나의 VM 명령 상태로 커밋될 때까지 양분합니다. 그런 다음 온체인에서 해당 명령을 실행하여 주장을 확인하거나 위조합니다. 이동은 공격(부모 주장에 도전) 또는 방어(부모 주장과의 합의)일 수 있습니다. 플레이어가 관찰 중인 클레임 해시(주어진 명령에서 두 당사자의 상태가 동일함을 의미)에 동의하지만 관찰된 클레임의 상대 해시를 기반으로 추진하려는 최종 결과에 동의하지 않을 때마다 방어가 이루어집니다. 근본 주장에 동의합니다.
지시 단계
위치 트리의 리프 노드에서 각 클레임은 단 하나의 VM 명령으로 상태를 커밋합니다. 남은 유일한 조치는 해당 VM 명령을 실행하여 상위 주장을 입증하거나 반증하는 것입니다.
지침 단계에서 예상된 게시 상태가 확인되면 청구는 반박되지 않습니다. 예기치 않은 게시 상태 또는 종료 코드가 있는 경우 상위 클레임이 반박됩니다.
해결
게임은 설정된 시간(일반적으로 최대 7일, 최저 3.5일) 후에 해결됩니다. 해결 방법은 가장 왼쪽에 있는 이의가 없는 주장을 찾는 데 중점을 둡니다. 이 청구가 발견되면 해결 프로세스는 깊이를 확인하여 루트 청구와 일치하는지 확인합니다.
-
이 주장의 깊이가 짝수이면 루트 주장이 참입니다.
-
깊이가 홀수이면 루트 주장은 거짓입니다.
정직한 플레이어는 근본 주장이 정직하든 부정직하든 관계없이 추적에 대한 관점으로 인해 게임이 항상 호의적으로 해결되는 결과를 낳습니다. 부정직한 주장은 언제나 어떤 당사자에 의해 반박될 수 있지만, 동일한 위치에 중복된 주장 해시가 허용되지 않기 때문에 항상 올바른 주장은 단 하나뿐입니다.
알파벳 이등분 게임을 해보세요
FaultDisputeGame궁금한 사람을 위해 길이가 16개에 불과한 모의 실행 추적을 위한 시각화 도구도 있습니다 . 이 시뮬레이션은 MIPS 스레드 컨텍스트가 아닌 별도의 VM을 사용합니다. 이는 AlphabetVM문자가 입력으로 주어지면 단순히 알파벳의 다음 문자를 반환합니다.
더 가벼운 백엔드로 게임의 규칙을 탐색하는 데 관심이 있다면 플레이 방법은 다음과 같습니다.
Optimism 단일 저장소를 복제하고, 종속성을 설치하고, devnet 할당/대포/op-프로그램 바이너리를 만듭니다.
-
필수 종속성:
-
foundry -
Golang 툴체인
-
도커
git clone [email protected]:ethereum-optimism/optimism.git && \\
cd optimism && \\
pnpm i && \\
(cd packages/contracts-bedrock && forge install) && \\
make cannon-prestate && \\
make devnet-allocs
알파벳 게임을 실행합니다:
cd op-challenger && make alphabet
https://disputify.optimism.io/ 로 이동하거나 https://github.com/clabby/dispute-viz 를 복제하여 로컬로 시각화 프런트엔드를 실행 하고 FaultDisputeGame위의 로컬 devnet에 배포된 프록시 주소를 입력하세요 .
OP 스택의 결함 방지 시스템을 보호하도록 지원
이분법 게임에서는 위에 설명된 모든 메커니즘이 함께 작동하여 정직한 행동에 보상하고 부정직한 주장에 효과적으로 대응하는 시스템을 만듭니다.
동일한 목표를 달성하는 분쟁 게임을 구축하는 방법은 매우 많습니다. OP Stack의 FPS가 OP Goerli에 배포되면 생태계의 빌더가 자신만의 분쟁 게임을 구성하는 데 재미와 창의력을 발휘할 수 있기를 바랍니다. 생성된 각 분쟁 게임은 OP 스택의 사회적 분산화에서 역할을 할 수 있으며, 정보에 대한 특정 주장에 대해 분쟁을 해결하는 방법에 관한 옵션을 생태계 참가자에게 제공할 수 있습니다.
https://blog.oplabs.co/dispute-games/?ref=the-optimistic-dev-blog-newsletter