여기서 시작하십시오
- 결함 증명 설명: 개념 모델을 익히기 위해 가장 먼저 읽으십시오. 무허가(permissionless) 제안, 무허가 이의 제기, 그리고 이 둘을 뒷받침하는 Guardian 안전장치를 다룹니다.
더 깊이 알아보기
- FP 시스템 컴포넌트: 시스템을
구성하는 세 가지 모듈(결함 증명 프로그램, 결함 증명 가상 머신,
분쟁 게임(dispute game) 프로토콜), 이들이 분리된 이유, 그리고 현재
kona-client가 기본 결함 증명 프로그램인 이유를 설명합니다. - 결함 증명 VM: Cannon: onchain
MIPS64.sol컨트랙트와 offchainmipsevmGo 구현으로 나뉘는 기본 결함 증명 가상 머신을 설명합니다. - 결함 증명 VM: MIPS64.sol: 멀티스레드 64비트 MIPS 명령어 세트의 EVM 구현인 onchain 부분을 명령어 수준에서 설명합니다.
- OP-Challenger 설명: 정직한 행위자가 결함을 감지하는 방식과, move 단위로 유효한 제안을 방어하고 유효하지 않은 claim에 대응하는 방식을 설명합니다.
직접 해 보기
- 결함 증명 challenger 실행하기: bond 예산 수립과 prestate 선택부터 인프라, 구성, 모니터링까지 체인을 방어하는 challenger를 운영하기 위한 전체 과정을 안내합니다.
- 체인에 challenger를 구성하는 방법: 위 과정의 기반이 되는 플래그별 구성 안내입니다.
- Challenger 구성 레퍼런스:
구성하는 동안 참고할 수 있는
op-challenger플래그, 환경 변수, 기본값의 전체 목록입니다. - absolute prestate 및 preimage 파일 생성하기:
체인의 모든 분쟁의 기준이 되는
kona-clientabsolute prestate를 빌드하고 검증합니다. - 무허가 결함 증명으로 마이그레이션하기: 네 단계에 걸쳐 체인을 허가형(permissioned) 분쟁 게임에서 무허가 결함 증명으로 전환합니다.
- 체인 모니터링 옵션:
지난 28일 동안의 모든 게임 상태를 추적하는 보안 모니터링 서비스인
op-dispute-mon을 실행합니다.
경제학과 인센티브
- 결함 증명 설명 FAQ: 체인 운영자가 제안을 실행하는 데 드는 비용과, 유효하지 않은 claim을 억제하기 위해 bond 크기가 정해지는 방식을 설명합니다.
- OP-Challenger 설명 FAQ: bond의 역할, 최대 깊이까지 진행되는 게임에 필요할 수 있는 ETH의 양, 그리고 승리 여부를 좌우하는 인프라 관련 질문(blob 보존 등)을 다룹니다.
규범적 명세
결함 증명 동작의 최종적인 정의는 OP Stack 명세에 있습니다.- Fault proof: 결함 증명 프로그램과 이 프로그램이 데이터를 읽어 오는 pre-image oracle입니다.
- Fault dispute game: bisection, 시계(clock), 해결을 포함한 게임 자체입니다.
- Honest challenger:
정직한 challenger가 구현해야 하는 동작이며,
op-challenger가 이를 따릅니다. - Bond incentives: 위 FAQ 답변의 기반이 되는 규범적 bond 경제학입니다.
- Multithreaded Cannon fault proof VM: Cannon이 구현하는 FPVM의 명세입니다.