I am a lifelong learner. I am constantly seeking out new knowledge and experiences, and am always looking for ways to
I am a lifelong learner. I am constantly seeking out new knowledge and experiences, and am always looking for ways to

Subscribe to offtotheether

Subscribe to offtotheether
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers


Bahagi ng isa sa mga Fault Proof Deep Dive Series sa Coinbase explores ang FPVM smart kontrata MIPS.sol at kung paano ito gumagana sa loob ng OP Stack ni Fault Proof System.
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, kami ay sumasaklaw sa Fault Proof Virtual Machine (FPVM) smart contract MIPS.sol.
Ang MIPS.sol smart contract ay isang onchain na pagpapatupad ng isang virtual machine (VM) na sumasaklaw sa 32 bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). Ang smart contract na ito ang katapat sa off chain MIPSEVM golang pagpapatupad ng parehong ISA. Magkasama, ang onchain at off chain VM pagpapatupad bumubuo ng Cannon, OP ng unang FPVM.
Ang Cannon ay isang halimbawa ng isang FPVM, na ginagamit bilang bahagi ng Fault Dispute Game para sa optimistikong rollup L2 blockchains na gumagamit ng OP Stack. Ang dispute game mismo ay modular, na nagpapahintulot sa anumang FPVM na magamit; gayunpaman, ang Cannon ay kasalukuyang ang tanging FPVM na ipinatupad at dahil dito ay gagamitin sa lahat ng mga hindi pagkakaunawaan.
Sa pagkuha ng isang hakbang pabalik, hayaan ang focus maikling sa kung saan ang MIPS.sol kontrata ay naninirahan sa proseso ng Fault Proof.
Sa diagram sa itaas na muling nilikha mula sa video ng Fault Proof Walkthrough ni Clabby, makikita natin na ang kontrata ng MIPS.sol ay nakikipag ugnayan sa dalawa pang kontrata: FaultDisputeGame.sol at PreimageOracle.sol. FaultDisputeGame.sol ay ang deployed instance ng isang Fault Dispute Game para sa isang aktibong hindi pagkakaunawaan. Ang PreimageOracle.sol ay ang deployed instance ng isang Pre image Oracle na mag iimbak ng mga Pre image para sa lahat ng Dispute Games na gumagamit ng parehong FPVM. Kaya, sa aming kaso, mayroong isang solong kontrata ng PreimageOracle.sol para sa lahat ng mga laro na gumagamit ng MIPS.sol bilang FPVM.
Ang kontrata ng MIPS.sol ay tinatawag sa pamamagitan ng isang running instance ng isang laro ng pagtatalo, at tinatawag lamang sa sandaling ang isang laro ng pagtatalo ay umaabot sa isang node ng dahon sa puno ng paglipat ng estado na kasalukuyang pinagtatalunan. Ang isang node ng dahon ay kumakatawan sa isang solong pagtuturo ng MIPS (sa kaso na ginagamit namin ang Cannon bilang FPVM) na pagkatapos ay maaaring patakbuhin sa kadena. Given ang pre estado, na kung saan ay ang dati nang napagkasunduan L2 estado hanggang sa pagtuturo na ito, at ang pagtuturo estado upang tumakbo sa MIPS.sol kontrata, ang fault dispute laro ay maaaring matukoy ang tunay na post estado. Ang tunay na post state na ito ay gagamitin pagkatapos upang malutas ang laro ng alitan sa kasalanan sa pamamagitan ng paghahambing ng pinagtatalunan na estado ng post sa node ng dahon sa post state na iminungkahi ng kalaban sa dispute game instance.
Mayroong isang solong entry point sa MIPS.sol smart contract: ang hakbang () function. Ito ay ang function na ay tinatawag na sa pamamagitan ng tumatakbo pagtatalo laro, na kung saan ay isagawa ang isang solong MIPS pagtuturo onchain. Sa isang mataas na antas, ang mga sumusunod na operasyon ay isasagawa:
Ang VM execution state data input ay parsed at na load sa memorya. Ang datos na ito ay nabuo ng katapat na Cannon golang na ang mga kalahok sa laro ay tumatakbo sa labas ng kadena sa pamamagitan ng OP Challenger.
Ang memory proof input ay binabasa at na verify. Ang memory proof na ito ay tumuturo sa isang lokasyon sa memorya kung saan ang susunod na pagtuturo ng MIPS ay dapat na mai load mula sa at patakbuhin.
Ang susunod na pagtuturo ng MIPS ay isinasagawa. Ang karamihan ng lohika sa kontrata ng MIPS.sol ay humahawak ng pagpapatupad ng isang tagubilin sa MIPS ayon sa pagtutukoy ng MIPS III. Kapag hinahawakan ang mga tagubilin ng MIPS, ang tanging tagubilin na hindi sumusunod sa isang mahigpit na pagtutukoy ay ang SYSCALL (system call) na pagtuturo. Ang pag uugali ng mga tawag sa system ay natatangi sa operating system, at sa kaso ng MIPS.sol, ang mga tawag sa system na maaaring isagawa ay isang bahagi lamang ng kabuuang mga tawag sa system. Ang pangunahing layunin ng mga tawag sa sistema ay upang mahawakan ang mga babasahin mula sa kontrata ng PreimageOracle.sol at simulate sumulat sa kontrata.
Ang mga resulta ng tagubilin ay maaaring isulat pabalik sa isang rehistro o sa memorya. Sa kaso ng pagsulat sa memorya, ang pangalawang patunay ng memorya ay ibinigay bilang input ng laro ng pagtatalo. Ang pangalawang memory proof ay dapat na sumasabay sa lokasyon sa memorya na inaasahang nakasulat sa, at ang MIPS.sol smart contract ay gagamitin ang bagong halaga at ang memory proof upang makalkula ang bagong memory merkle root.
Sa pagkumpleto ng pagtuturo ng MIPS, isang hash ng estado ang ibabalik sa dispute game instance. Ang hash ng estado ay ang keccak256 hash ng estado ng pagpapatupad ng VM kung saan ang unang byte ay hindi tumutugma sa hash ngunit sa halip ay napapawi na may halaga upang ipahiwatig ang katayuan ng VM. Ang laro ng pagtatalo ay gagamitin ang hash ng estado at katayuan ng VM upang malutas ang hindi pagkakaunawaan.
Tulad ng nabanggit dati, ang kontrata ng MIPS.sol ay nakikipag ugnayan sa dalawang iba pang mga matalinong kontrata: FaultDisputeGame.sol at PreimageOracle.sol. Ang kontrata ng FaultDisputeGame.sol ay nagbibigay ng kasalukuyang estado ng pagpapatupad ng VM, at hanggang sa dalawang patunay ng memorya. Ang kontrata ng PreimageOracle.sol ay nagbibigay ng mga Pre image na maaaring magamit ng MIPS.sol upang makatulong na matukoy ang tunay na estado ng L2. Ang nilalaman na nakuha sa isang Pre image ay maaaring magsama ng data mula sa parehong L1 at L2, na maaaring maging mga header ng block, transaksyon, resibo, estado ng kontrata, at marami pa.
Magkasama, ang dalawang kontratang ito ay nagbibigay ng lahat ng kaugnay na impormasyon na kinakailangan upang maisagawa ang isang solong pagtuturo sa MIPS. Ang kontrata ng MIPS.sol ay hindi nag iimbak ng anumang impormasyon tungkol sa isang pagpapatupad ng pagtuturo sa imbakan. Sa ganitong paraan, ang kontrata ay maaaring gamitin ng anumang Fault Dispute Game nang hindi na kailangang i reset ang anumang mga halaga. Dahil dito, tinitiyak lamang ng kontrata ng MIPS.sol na ang kinakalkula na ugat ng merkle mula sa ibinigay na mga patunay ng memorya ay katumbas ng ugat ng merkle sa estado ng pagpapatupad ng VM. Kung hindi man, nasa kontrata ng FaultDisputeGame.sol upang matiyak ang kawastuhan ng impormasyong ibinigay at mga aksyon na kinuha ng isang kalahok sa laro ng pagtatalo.
Ito ay nagtatapos sa aming malalim na pagsisid ng MIPS.sol smart contract. Bilang karagdagan sa post na ito sa blog, ang Coinbase ay lumikha ng malalim na dokumentasyon na nagbibigay ng mga detalye sa bawat function sa smart contract, nakalista ang mga tagubilin ng MIPS na suportado ng FPVM, at marami pa. Tingnan ito sa Fault Proofs - MIPS.sol | Optimism Docs.
Bahagi ng isa sa mga Fault Proof Deep Dive Series sa Coinbase explores ang FPVM smart kontrata MIPS.sol at kung paano ito gumagana sa loob ng OP Stack ni Fault Proof System.
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, kami ay sumasaklaw sa Fault Proof Virtual Machine (FPVM) smart contract MIPS.sol.
Ang MIPS.sol smart contract ay isang onchain na pagpapatupad ng isang virtual machine (VM) na sumasaklaw sa 32 bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). Ang smart contract na ito ang katapat sa off chain MIPSEVM golang pagpapatupad ng parehong ISA. Magkasama, ang onchain at off chain VM pagpapatupad bumubuo ng Cannon, OP ng unang FPVM.
Ang Cannon ay isang halimbawa ng isang FPVM, na ginagamit bilang bahagi ng Fault Dispute Game para sa optimistikong rollup L2 blockchains na gumagamit ng OP Stack. Ang dispute game mismo ay modular, na nagpapahintulot sa anumang FPVM na magamit; gayunpaman, ang Cannon ay kasalukuyang ang tanging FPVM na ipinatupad at dahil dito ay gagamitin sa lahat ng mga hindi pagkakaunawaan.
Sa pagkuha ng isang hakbang pabalik, hayaan ang focus maikling sa kung saan ang MIPS.sol kontrata ay naninirahan sa proseso ng Fault Proof.
Sa diagram sa itaas na muling nilikha mula sa video ng Fault Proof Walkthrough ni Clabby, makikita natin na ang kontrata ng MIPS.sol ay nakikipag ugnayan sa dalawa pang kontrata: FaultDisputeGame.sol at PreimageOracle.sol. FaultDisputeGame.sol ay ang deployed instance ng isang Fault Dispute Game para sa isang aktibong hindi pagkakaunawaan. Ang PreimageOracle.sol ay ang deployed instance ng isang Pre image Oracle na mag iimbak ng mga Pre image para sa lahat ng Dispute Games na gumagamit ng parehong FPVM. Kaya, sa aming kaso, mayroong isang solong kontrata ng PreimageOracle.sol para sa lahat ng mga laro na gumagamit ng MIPS.sol bilang FPVM.
Ang kontrata ng MIPS.sol ay tinatawag sa pamamagitan ng isang running instance ng isang laro ng pagtatalo, at tinatawag lamang sa sandaling ang isang laro ng pagtatalo ay umaabot sa isang node ng dahon sa puno ng paglipat ng estado na kasalukuyang pinagtatalunan. Ang isang node ng dahon ay kumakatawan sa isang solong pagtuturo ng MIPS (sa kaso na ginagamit namin ang Cannon bilang FPVM) na pagkatapos ay maaaring patakbuhin sa kadena. Given ang pre estado, na kung saan ay ang dati nang napagkasunduan L2 estado hanggang sa pagtuturo na ito, at ang pagtuturo estado upang tumakbo sa MIPS.sol kontrata, ang fault dispute laro ay maaaring matukoy ang tunay na post estado. Ang tunay na post state na ito ay gagamitin pagkatapos upang malutas ang laro ng alitan sa kasalanan sa pamamagitan ng paghahambing ng pinagtatalunan na estado ng post sa node ng dahon sa post state na iminungkahi ng kalaban sa dispute game instance.
Mayroong isang solong entry point sa MIPS.sol smart contract: ang hakbang () function. Ito ay ang function na ay tinatawag na sa pamamagitan ng tumatakbo pagtatalo laro, na kung saan ay isagawa ang isang solong MIPS pagtuturo onchain. Sa isang mataas na antas, ang mga sumusunod na operasyon ay isasagawa:
Ang VM execution state data input ay parsed at na load sa memorya. Ang datos na ito ay nabuo ng katapat na Cannon golang na ang mga kalahok sa laro ay tumatakbo sa labas ng kadena sa pamamagitan ng OP Challenger.
Ang memory proof input ay binabasa at na verify. Ang memory proof na ito ay tumuturo sa isang lokasyon sa memorya kung saan ang susunod na pagtuturo ng MIPS ay dapat na mai load mula sa at patakbuhin.
Ang susunod na pagtuturo ng MIPS ay isinasagawa. Ang karamihan ng lohika sa kontrata ng MIPS.sol ay humahawak ng pagpapatupad ng isang tagubilin sa MIPS ayon sa pagtutukoy ng MIPS III. Kapag hinahawakan ang mga tagubilin ng MIPS, ang tanging tagubilin na hindi sumusunod sa isang mahigpit na pagtutukoy ay ang SYSCALL (system call) na pagtuturo. Ang pag uugali ng mga tawag sa system ay natatangi sa operating system, at sa kaso ng MIPS.sol, ang mga tawag sa system na maaaring isagawa ay isang bahagi lamang ng kabuuang mga tawag sa system. Ang pangunahing layunin ng mga tawag sa sistema ay upang mahawakan ang mga babasahin mula sa kontrata ng PreimageOracle.sol at simulate sumulat sa kontrata.
Ang mga resulta ng tagubilin ay maaaring isulat pabalik sa isang rehistro o sa memorya. Sa kaso ng pagsulat sa memorya, ang pangalawang patunay ng memorya ay ibinigay bilang input ng laro ng pagtatalo. Ang pangalawang memory proof ay dapat na sumasabay sa lokasyon sa memorya na inaasahang nakasulat sa, at ang MIPS.sol smart contract ay gagamitin ang bagong halaga at ang memory proof upang makalkula ang bagong memory merkle root.
Sa pagkumpleto ng pagtuturo ng MIPS, isang hash ng estado ang ibabalik sa dispute game instance. Ang hash ng estado ay ang keccak256 hash ng estado ng pagpapatupad ng VM kung saan ang unang byte ay hindi tumutugma sa hash ngunit sa halip ay napapawi na may halaga upang ipahiwatig ang katayuan ng VM. Ang laro ng pagtatalo ay gagamitin ang hash ng estado at katayuan ng VM upang malutas ang hindi pagkakaunawaan.
Tulad ng nabanggit dati, ang kontrata ng MIPS.sol ay nakikipag ugnayan sa dalawang iba pang mga matalinong kontrata: FaultDisputeGame.sol at PreimageOracle.sol. Ang kontrata ng FaultDisputeGame.sol ay nagbibigay ng kasalukuyang estado ng pagpapatupad ng VM, at hanggang sa dalawang patunay ng memorya. Ang kontrata ng PreimageOracle.sol ay nagbibigay ng mga Pre image na maaaring magamit ng MIPS.sol upang makatulong na matukoy ang tunay na estado ng L2. Ang nilalaman na nakuha sa isang Pre image ay maaaring magsama ng data mula sa parehong L1 at L2, na maaaring maging mga header ng block, transaksyon, resibo, estado ng kontrata, at marami pa.
Magkasama, ang dalawang kontratang ito ay nagbibigay ng lahat ng kaugnay na impormasyon na kinakailangan upang maisagawa ang isang solong pagtuturo sa MIPS. Ang kontrata ng MIPS.sol ay hindi nag iimbak ng anumang impormasyon tungkol sa isang pagpapatupad ng pagtuturo sa imbakan. Sa ganitong paraan, ang kontrata ay maaaring gamitin ng anumang Fault Dispute Game nang hindi na kailangang i reset ang anumang mga halaga. Dahil dito, tinitiyak lamang ng kontrata ng MIPS.sol na ang kinakalkula na ugat ng merkle mula sa ibinigay na mga patunay ng memorya ay katumbas ng ugat ng merkle sa estado ng pagpapatupad ng VM. Kung hindi man, nasa kontrata ng FaultDisputeGame.sol upang matiyak ang kawastuhan ng impormasyong ibinigay at mga aksyon na kinuha ng isang kalahok sa laro ng pagtatalo.
Ito ay nagtatapos sa aming malalim na pagsisid ng MIPS.sol smart contract. Bilang karagdagan sa post na ito sa blog, ang Coinbase ay lumikha ng malalim na dokumentasyon na nagbibigay ng mga detalye sa bawat function sa smart contract, nakalista ang mga tagubilin ng MIPS na suportado ng FPVM, at marami pa. Tingnan ito sa Fault Proofs - MIPS.sol | Optimism Docs.
No activity yet