Fault Proof Part 2: Cannon
August 4th, 2024

Ikalawang bahagi ng Fault Proof Deep Dive Series sa Coinbase concludes ang buod ng Cannon, ang OP Stack unang Fault Proof Virtual Machine (FPVM) na ginagamit bilang bahagi ng Dispute Game.

Ang Fault Proof Deep Dive Series ay isang pakikipagtulungan sa pagitan ng koponan ng Blockchain Security (BlockSec) ng Coinbase at OP Labs upang magbigay ng malalim na impormasyon sa lahat ng mga pangunahing bahagi ng Fault Proofs. Sa pamamagitan ng pagbabahagi ng impormasyong ito, inaasahan naming hikayatin ang iba na matuto nang higit pa tungkol sa arkitektura at teknikal na aspeto ng Fault Proofs. Sama sama, maaari naming ilipat patungo sa desentralisado hinaharap ng OP Stack L2 blockchains.

Sa blog post na ito, tatalakayin natin ang pagpapatupad ng offchain Cannon Fault Proof Virtual Machine (FPVM). Tandaan na ang parehong onchain at offchain FPVM pagpapatupad magkasama gumawa ng Cannon. Gayunpaman, kami ay delineate ang dalawa sa pamamagitan ng pagkakaroon ng Cannon sumangguni lamang sa pagpapatupad ng offchain para sa blog post na ito.

Ano ang Cannon?

Sa nakaraang blog post, ipinakilala namin ang MIPS.sol, ang onchain FPVM. Cannon ang offchain counterpart ng MIPS.sol, na nakasulat sa Golang. Gayunpaman, hindi tulad ng MIPS.sol, ang pagpapatupad ng offchain Cannon ay responsable para sa malayo mas maraming mga hakbang sa isang laro ng pagtatalo. Dagdag pa, ang Cannon ay ang nag iisang FPVM na ginagamit para sa Fault Dispute Games sa OP Stack.

Daloy ng Control ng Patunay ng Fault

Minsan pa, repasuhin natin ang proseso ng Fault Proof upang maunawaan kung saan naninirahan ang Cannon.

Sa diagram sa itaas na muling ginawa mula sa video ng Fault Proof Walkthrough ni Clabby, makikita natin na nakikipag-ugnayan ang Cannon sa OP-Challenger at OP-Program. Ang OP-Challenger ay ang bahagi na humahawak ng pagsisimula ng mga hamon at pakikipag-ugnayan sa isang laro ng pagtatalo, at ang OP-Program ang humahawak ng derivation ng L2 output mula sa L1 inputs. Gayunpaman, ang diagram ay isang pagpapasimple ng mga pakikipag ugnayan sa pagitan ng OP Challenger, Cannon, at OP Program.

Sa kurso ng isang aktibong laro ng pagtatalo, ang laro ng bisection ay lilipat mula sa pivoting sa ibabaw ng L2 output roots sa mga hashes ng estado saksi. Cannon ay responsable para sa pagbuo ng estado saksi hashes, na kung saan ay ang pangako sa mga resulta ng MIPS mga tagubilin 'computation sa loob ng FPVM. Ang Cannon ay tatakbo lamang kapag naabot na ng dispute game ang puntong iyon. Ang bahaging ito ng laro ng bisection ay kilala bilang bakas ng pagpapatupad. Hanggang sa puntong ito, ang OP-Challenger ay kumunsulta sa OP-Node para sa mga ugat ng output ng estado, at hindi gumamit ng OP-Program o Cannon. Gayunpaman, sa sandaling oras na upang patakbuhin ang Cannon para sa laro ng pagtatalo, ang naipon na OP Program ay mai load sa VM sa Cannon na pagkatapos ay magsisimulang magpatakbo ng mga tagubilin sa MIPS.

Sa panahon ng execution trace portion ng bisection game, magpapatakbo si Cannon ng maraming tagubilin sa MIPS, at sa una ay magbibigay ng state witness hashes sa OP-Challenger. Sa kalaunan, ang isang solong pagtuturo ng MIPS ay makikilala bilang ugat ng hindi pagkakaunawaan sa pagitan ng mga kalahok sa aktibong pagtatalo. Ngayon, Cannon ay bumuo ng patunay ng saksi, na naglalaman ng lahat ng impormasyon na kinakailangan upang patakbuhin ang MIPS pagtuturo onchain sa MIPS.sol. Ang depinitibo post estado ng pagtuturo ng MIPS ay pagkatapos ay gagamitin upang malutas ang laro ng alitan sa pagkakamali.

Buod ng Cannon Component

Ang Cannon ay binubuo ng ilang mga file ng Golang, na magkasama ay may mas maraming pag andar kaysa sa onchain MIPS.sol. Ito ay kinakailangan, bilang Cannon ay responsable para sa higit pang mga bahagi ng laro ng pagtatalo kaysa sa MIPS.sol. Ang mga file na Golang na ito ay maaaring igrupo sa pamamagitan ng mga pangunahing bahagi ng Cannon na ipinatutupad nila, na kinabibilangan ng: ang Executable at Linkable Format (ELF) loader, memory at pamamahala ng estado, MIPSEVM, at saksi patunay henerasyon.

ELF Loader

OP-Program ay ang code na ay binuo sa isang ELF file na kung saan ay naglalaman ng MIPS mga tagubilin upang tumakbo sa loob ng Cannon. Upang makuha ang mga nilalaman ng ELF file sa Cannon upang tumakbo, kailangan itong mai load sa MIPSEVM. Ang prosesong ito ay nagsasangkot ng pag uulit sa mga header ng ELF upang matukoy ang lahat ng mga programa na kailangang i load sa 32 bit na puwang ng memorya, hanapin ang mga paunang halaga para sa Program Counter (PC) at NextPC, instantiating ang stack, bunton, at mga pointer ng segment ng data sa memorya, at pag patch out ng anumang hindi tugmang mga function. Ang pag patch out ng isang hindi tugmang function ay nagsusulat lamang sa ibabaw ng mga unang tagubilin sa loob ng isang function na may isang pagbabalik pabalik sa orihinal na pointer, at pagkatapos ay isang walang operasyon (NOP). Ang pag patch ng binary load sa MIPSEVM ay mahalaga bilang FPVM ay hindi magagawang upang maisagawa ang maraming mga tawag sa system, at hindi sumusuporta sa mga tampok tulad ng concurrency.

Memory at Pamamahala ng Estado

Iniimbak at pinapanatili ng Cannon ang buong 32 bit na espasyo ng memory address na magagamit ng MIPSEVM. Walang paghihigpit sa laki ng memorya na naka imbak offchain, ngunit para sa MIPS.sol ito ay hindi maaaring mag imbak ng buong 32 bit memory address space. Samakatuwid, ang memorya ay naka imbak sa isang binary Merkle tree data structure sa loob ng Cannon. Sa MIPSEVM, ang istraktura ng data na ito ay abstracted ang layo sa pamamagitan ng paggamit ng GetMemory (), ReadMemoryRange (), at SetMemory () function. Kapag oras na upang makabuo ng patunay ng saksi, ang Cannon ay mag encode ng hanggang sa dalawang memorya Merkle proofs para sa MIPS.sol na gagamitin kapag nagpapatakbo ng isang pagtuturo sa MIPS.

MIPSEVM

Sa loob ng Cannon ay ang MIPSEVM, na nagpapatupad ng 32-bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). Hindi tulad ng MIPS.sol, ang MIPSEVM ay magpapatakbo ng maraming mga tagubilin sa MIPS, at responsable rin para sa pagsubaybay sa pag access sa memorya na gagamitin upang i encode ang pangalawang patunay ng memorya. Gayunpaman, ang parehong mga pagpapatupad ng offchain at onchain VM ay dapat makabuo ng eksaktong parehong mga resulta na ibinigay ang parehong pagtuturo, memorya, at rehistro ng estado. Ito ay kritikal upang matiyak na ang inaasahang post state mula sa MIPSEVM ay pareho sa aktwal na post state na nabuo ng MIPS.sol, na gagamitin upang malutas ang laro ng pagtatalo.

Henerasyon ng mga Saksi na Patunay

Kapag ang isang solong pagtuturo ng MIPS ay nakilala bilang ugat ng hindi pagkakaunawaan sa pagitan ng mga kalahok sa isang laro ng pagtatalo ng pagkakamali, ang Cannon ay bubuo ng patunay ng saksi upang ang parehong pagtuturo ay maaaring patakbuhin onchain sa MIPS.sol. Naka encode sa patunay ng saksi ang sumusunod na impormasyon: ang estado ng pagpapatupad ng VM, ang patunay ng memorya para sa address ng pagtuturo na tumakbo, at isang karagdagang patunay ng memorya na kinakailangan lamang para sa pag load, tindahan, o ilang mga tagubilin sa tawag sa system. Dagdag pa, kung ang pagtuturo ng MIPS ay nangangailangan ng isang Pre imahe, ang Cannon ay makikipag usap din ng isang Pre image key at i offset sa OP-Challenger upang ito ay mai post onchain sa PreimageOracle.sol.

Dokumentasyon Para sa Cannon

Ito ang pagtatapos ng aming malalim na pagsisid ng Cannon. Bilang karagdagan sa blog post na ito, Coinbase ay lumikha ng malalim na dokumentasyon na nagbibigay ng higit pang mga detalye sa bawat isa sa mga bahagi na bumubuo ng Cannon. Tingnan ito sa Fault Proof VM - Cannon | Optimismo Docs, at kung interesado ka sa opisyal na teknikal na pagtutukoy ng Cannon ng Optimismo, maaari mong tingnan iyon sa Cannon Technical Specification.

Subscribe to offtotheether
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.
More from offtotheether

Skeleton

Skeleton

Skeleton