[KOR] Fault Proof Deep-Dive Part 2: Cannon - bhlee4980

원문 링크:

https://blog.oplabs.co/fault-proof-deep-dive-part-2-cannon/?ref=the-optimistic-dev-blog-newsletter

Coinbase와 함께하는 결함 방지 심층 분석 시리즈의 2부에서는 분쟁 게임의 일부로 사용되는 OP Stack의 첫 번째 결함 방지 가상 머신(FPVM)인 Cannon에 대한 개요를 마무리합니다.

결함 증명 심층 분석 시리즈는 Coinbase의 블록체인 보안(BlockSec) 팀과 OP Labs 간의 협력으로 결함 증명의 모든 주요 구성 요소에 대한 심층적인 정보를 제공합니다. 이 정보를 공유함으로써 다른 사람들이 결함 증명의 아키텍처 및 기술적 측면에 대해 더 많이 배울 수 있기를 바랍니다. 함께, 우리는 OP Stack L2 블록체인의 분산화된 미래를 향해 나아갈 수 있습니다.

이 블로그 게시물에서는 오프체인 FPVM(Cannon Fault Proof Virtual Machine) 구현에 대해 다룰 예정입니다. 온체인과 오프체인 FPVM 구현이 함께 Cannon을 만든다는 점에 유의하세요. 그러나 우리는 이 블로그 게시물에서 Cannon이 오프체인 구현만을 참조하도록 하여 두 가지를 설명할 것입니다.

Cannon는 무엇입니까?

이전 블로그 게시물 에서는 온체인 FPVM인 MIPS.sol을 소개했습니다. Cannon은 Golang으로 작성된 MIPS.sol의 오프체인 대응물입니다. 그러나 MIPS.sol과 달리 오프체인 Cannon 구현은 분쟁 게임에서 훨씬 더 많은 단계를 담당합니다. 또한 Cannon은 OP 스택의 오류 분쟁 게임에 사용되는 유일한 FPVM입니다.

결함 방지 제어 흐름

다시 한번 Cannon이 어디에 있는지 이해하기 위해 Fault Proof 프로세스를 검토해 보겠습니다.

Clabby의 Fault Proof Walkthrough 비디오 에서 재현된 위 다이어그램에서 Cannon이 OP-Challenger 및 OP-Program과 상호 작용하는 것을 볼 수 있습니다. OP-Challenger는 챌린지 시작 및 분쟁 게임과의 상호 작용을 처리하는 구성 요소이며, OP-Program은 L1 입력에서 L2 출력 파생을 처리합니다. 그러나 이 다이어그램은 OP-Challenger, Cannon 및 OP-Program 간의 상호 작용을 단순화한 것입니다.

활성 분쟁 게임이 진행되는 동안 이분법 게임은 L2 출력 루트를 중심으로 하는 회전에서 상태 증인 해시로 이동합니다. Cannon은 FPVM 내에서 MIPS 명령어 계산 결과에 대한 약속인 상태 감시 해시 생성을 담당합니다. 대포는 분쟁 게임이 해당 지점에 도달한 후에만 실행됩니다. 이등분 게임의 이 부분을 실행 추적이라고 합니다. 지금까지 OP-Challenger는 상태 출력 루트에 대해 OP-Node를 참조해 왔으며 OP-Program이나 Cannon을 사용하지 않았습니다. 그러나 분쟁 게임을 위해 Cannon을 실행할 시간이 되면 이미 컴파일된 OP 프로그램이 Cannon의 VM에 로드되어 MIPS 명령어를 실행하기 시작합니다.

이분법 게임의 실행 추적 부분 동안 Cannon은 많은 MIPS 명령을 실행하고 처음에는 OP-Challenger에 상태 감시 해시를 제공합니다. 결국 단일 MIPS 지침이 활성 분쟁 참가자 간의 불일치의 근원으로 식별됩니다. 이제 Cannon은 MIPS.sol에서 온체인으로 MIPS 명령을 실행하는 데 필요한 모든 정보가 포함된 증인 증명을 생성합니다. 그러면 MIPS 명령어의 최종 사후 상태가 오류 분쟁 게임을 해결하는 데 사용됩니다.

Cannon 구성 요소 개요

Cannon은 온체인 MIPS.sol보다 훨씬 더 많은 기능을 갖춘 여러 Golang 파일로 구성됩니다. 이는 Cannon이 MIPS.sol보다 분쟁 게임의 더 많은 부분을 담당하기 때문에 필요합니다. 이러한 Golang 파일은 ELF(Executable and Linkable Format) 로더, 메모리 및 상태 관리, MIPSEVM 및 증인 증명 생성을 포함하여 구현하는 Cannon의 핵심 구성 요소별로 그룹화될 수 있습니다.

ELF 로더

OP-Program은 Cannon 내에서 실행하기 위한 MIPS 지침이 포함된 ELF 파일로 컴파일되는 코드입니다. ELF 파일의 내용을 Cannon으로 가져와서 실행하려면 MIPSEVM에 로드해야 합니다. 이 프로세스에는 ELF 헤더를 반복하여 32비트 메모리 공간에 로드해야 하는 모든 프로그램을 결정하고, 프로그램 카운터(PC) 및 NextPC의 초기 값을 찾고, 스택, 힙 및 데이터 세그먼트를 인스턴스화하는 작업이 포함됩니다. 메모리에 포인터를 저장하고 호환되지 않는 기능을 패치합니다. 호환되지 않는 함수를 패치 아웃하면 원래 포인터로 돌아가서 함수 내의 첫 번째 명령을 덮어쓴 다음 NOP(작업 없음)가 발생합니다. FPVM은 많은 시스템 호출을 수행할 수 없고 동시성과 같은 기능을 지원하지 않으므로 MIPSEVM에 로드된 바이너리를 패치하는 것이 중요합니다.

메모리 및 상태 관리

Cannon은 MIPSEVM에 사용 가능한 전체 32비트 메모리 주소 공간을 저장하고 유지합니다. 오프체인에 저장되는 메모리 크기에는 제한이 없지만 MIPS.sol의 경우 전체 32비트 메모리 주소 공간을 저장하는 것은 불가능합니다. 따라서 메모리는 Cannon 내에서 바이너리 머클 트리 데이터 구조로 저장됩니다. MIPSEVM의 경우 이 데이터 구조는 GetMemory(), ReadMemoryRange() 및 SetMemory() 함수를 사용하여 추상화됩니다. 증인 증명을 생성할 때가 되면 Cannon은 MIPS 명령어를 실행할 때 사용할 MIPS.sol용 메모리 머클 증명을 최대 2개까지 인코딩합니다.

MIPSEVM

Cannon에는 32비트, Big-Endian, MIPS III 명령어 세트 아키텍처(ISA)를 구현하는 MIPSEVM이 있습니다. MIPS.sol과 달리 MIPSEVM은 많은 MIPS 명령어를 실행하며 두 번째 메모리 증명을 인코딩하는 데 사용되는 메모리 액세스 추적도 담당합니다. 그러나 오프체인과 온체인 VM 구현은 모두 동일한 명령어, 메모리 및 레지스터 상태에서 정확히 동일한 결과를 생성해야 합니다. 이는 MIPSEVM에서 예상되는 사후 상태가 분쟁 게임을 해결하는 데 사용되는 MIPS.sol에서 생성된 실제 사후 상태와 동일하도록 보장하는 데 중요합니다.

증인 증거 생성

단일 MIPS 명령이 결함 분쟁 게임 참가자 간의 불일치의 근원으로 확인되면 Cannon은 동일한 명령이 MIPS.sol에서 체인에서 실행될 수 있도록 증인 증거를 생성합니다. 증인 증명에는 VM 실행 상태, 실행할 명령 주소에 대한 메모리 증명, 로드, 저장 또는 특정 시스템 호출 명령에만 필요한 추가 메모리 증명 등의 정보가 인코딩되어 있습니다. 또한 MIPS 명령에 사전 이미지가 필요한 경우 Cannon은 사전 이미지 키와 오프셋을 OP-Challenger에 전달하여 PreimageOracle.sol에 온체인으로 게시할 수 있습니다.

Cannon에 대한 문서

이것으로 Cannon에 대한 심층 분석을 마칩니다. 이 블로그 게시물 외에도 Coinbase는 Cannon을 구성하는 각 구성 요소에 대한 자세한 내용을 제공하는 심층 문서를 만들었습니다. Fault Proof VM - Cannon | Optimism Docs 및 Optimism의 공식 Cannon 기술 사양에 관심이 있다면 Cannon 기술 사양 에서 해당 내용을 볼 수 있습니다 .