Mga fraud proof at virtual machine

Ang artikulong ito ay isang buod ng research paper — SoK: Validating Bridges as a Scaling Solution for Blockchains — Isinulat ni Oasis Labs CEO at Founder Dawn Song, Patrick McCorry, Bennet Yee at orihinal na inilathala ni Chris Buckland sa kanyang blog dito.

Ang mga rollup ay nagbibigay ng blockchain scaling sa pamamagitan ng paglipat ng execution sa ibang domain. Ang data ng transaksyon ay inilalagay sa pangunahing kadena, ngunit ang mga transaksyon ay hindi naisakatuparan doon. Sa halip, isinagawa ang mga ito sa rollup network, at pana-panahon ang isang pangako sa kasalukuyang estado ng rollup ay nai-post pabalik sa pangunahing chain. Nangangahulugan ito na ang mga mainnet node ay hindi na kinakailangan upang maisagawa ang mga transaksyon, na binabawasan ang kanilang load.

Ngunit paano makumbinsi ang pangunahing kadena na tama ang nakasaad na estado ng rollup? Ang mga rollup ay may dalawang magkaibang kategorya, na lumulutas sa problemang ito sa magkahiwalay na paraan:

1. zk-rollups: Ang mga pangako ay napatunayang tama sa pamamagitan ng kasamang zero knowledge proof.
2. Mga optimistic rollup: Ang mga pangako ay tinatanggap nang positibo, ngunit sinusuri ito ng mga validator at nagsumite ng patunay ng panloloko kung nakita nilang hindi tama ang pangako. Sa kaso ng optimistic rollups ang pangako ay tinatawag ding assertion, dahil ang estado ay iginigiit at hindi napatunayan.

Ang mga optimistikong rollup ay nangangailangan ng mga validator na suriin ang mga transition ng estado at magsumite ng mga fraud proof kung nakita nila ito

Sa kanyang post, tututuon lang kami sa mga optimistikong rollup, at ang mga patunay ng panloloko na nagpapanatili sa kanila na secure. Titingnan natin kung paano sila kasalukuyang ginagamit ng dalawang sikat na optimistic rollup — Arbitrum at Optimism — at kung ano ang kasalukuyang mga direksyon sa pananaliksik na patunay ng panloloko.

Para sa higit pang mga detalye sa kung paano gumagana ang mga rollup sa pangkalahatan maaari kong irekomenda ang post sa blog na ito.

Fraud Proofs

Ang mga kasalukuyang fraud proof ay may dalawang klase:

1. Hindi interactive
2. Interactive

Ang mga non-interactive na fraud proof ay nagbibigay-daan sa isang partido na patunayan ang hindi tama ng isang pahayag nang walang paglahok ng anumang iba pang partido. Ginagawa nila ito sa pamamagitan ng pagsasagawa ng lahat ng mga transition ng estado sa pagitan ng dalawang iginiit na pangako upang ipakita na ang resultang pangako ay naiiba sa iginiit. Ang mga non-interactive na fraud proof ay may pakinabang ng pagiging simple sa pangangatuwiran at disenyo. Gayunpaman, maliban kung gumagamit ng zk-proof, ang paglipat sa pagitan ng dalawang assertion ay dapat sapat na maliit upang maisakatuparan on-chain na kung saan, kasama ang kasalukuyang mga kakayahan ng Ethereum, ay naglalagay ng matitinding limitasyon ng mga transition na maaaring epektibong ma-verify ng ganitong istilo ng patunay ng pandaraya.

Ang mga interactive na fraud proof ay nangangailangan ng dalawa o higit pang partido na magtulungan upang ipakita na ang isang pahayag ay wasto o hindi wasto. Sa pagsasagawa, ang mga kasalukuyang disenyo ay nagsasangkot ng isang tagapagtanggol (ang partido na gumagawa ng paninindigan), at isang naghahamon. Hinihiling ng naghamon na hatiin ng defender ang kanilang assertion sa mga sub assertion, kung saan maaaring piliin ng challenger ang sub assertion na hindi nila sinasang-ayunan. Nagpapatuloy sila sa pamamagitan ng paghiling ng paghahati-hati ng sub assertion, at iba pa, hanggang sa maabot nila ang isang assertion na kumakatawan sa isang maliit na sapat na operasyon na isasagawa on-chain. Ipinakikilala ng mga interactive na fraud proof ang pagiging kumplikado ng pakikipagtulungan sa pagitan ng mga partido. Ang mga insentibong kasangkot doon ay gumagawa ng mga ito na likas na mas kumplikado upang ligtas na magdisenyo. Gayunpaman, ang tanging limitasyon tungkol sa pagpapatupad ay ang isang operasyon ay dapat na maipatupad sa kadena, ibig sabihin, ang mga transaksyon at mga bloke sa rollup ay hindi pinaghihigpitan ng alinman sa mga limitasyon ng L1.

Kaya anong mga fraud proof ang ginagamit ng ilan sa mga kasalukuyang optimistikong rollup?

Optimism

Ang mga non-interactive na fraud proof ay ang pinakakaakit-akit na lugar upang magsimula, at sa katunayan ito ang direksyon na kinuha ng Optimism para sa kanilang unang bersyon. Gayunpaman, para sa V2 sila ay sumusulong sa paggamit ng mga interactive na patunay. Upang makita kung bakit tingnan natin ang mga limitasyon ng isang hindi interactive na fraud proof.

Kailangang isagawa ng mga non-interactive na fraud proof ang buong paglipat ng estado sa pagitan ng dalawang assertion. Pinili ng optimism ang antas ng transaksyon bilang granularity para sa transition ng estado, umaasang mabibigyang-daan ang mga user na makapagsagawa ng mga normal na transaksyon sa Ethereum sa kanilang rollup.

Gayunpaman, ang muling pagpapatupad ng isang transaksyon sa Ethereum na naganap sa rollup pabalik sa Mainnet Ethereum ay hindi native na sinusuportahan ng Ethereum. Ito ay dahil may access ang mga transaksyon sa pinagbabatayan na estado at mga account ng chain, na naiiba sa pagitan ng rollup at mainnet.

Upang muling maisagawa ng Optimism ang kanilang mga transaksyon sa mainnet, kailangan nilang palitan ang mga opcode na nag-a-access sa estado at mga account ng mga synthetic na tumatawag sa isang partikular na kontrata na pre-populated na may nauugnay na estado. Isang kabuuang bilang ng mga 18 opcode ang napalitan sa ganitong paraan, na may karagdagang 6 na ganap na inalis. Ang bytecode na may mga opcode na ito na pinalitan ng mga function call ay sinasabing tatakbo sa loob ng Optimistic Virtual Machine (OVM). Ang Optimism ay lumikha ng fork ng Solidity compiler upang payagan ang mga developer na i-compile ang kanilang mga kontrata para sa OVM.

Habambuhay ng isang kontrata sa Optimism

1. Ang pagpapalit ng mga tagubilin sa pag-access ng estado ng mga tawag sa kontrata ay lubhang nagpapalaki sa laki ng bytecode ng ilang kontrata. Ang Ethereum ay may ~25kB na limitasyon sa laki ng kontrata na nangangahulugang pagkatapos isalin mula sa EVM patungo sa OVM ang ilang mga kontrata ay mangangailangan ng refactoring o kailangang hatiin upang gawing posible na i-redeploy ang mga ito sa panahon ng fraud proof.
2. Ang paggawa ng mga tawag sa halip na gumamit ng native na access ng estado ay nangangailangan ng mas maraming gas, kaya ang mga transaksyon na tumatakbo sa OVM ay epektibong nagkaroon ng mas mababang limitasyon ng gas kaysa sa kanilang katumbas na pinapatakbo sa Ethereum.

Ang mga kontratang isinalin mula sa EVM patungo sa OVM bytecode ay dumaranas ng dalawang pangunahing limitasyon:

Pareho sa mga limitasyong ito ay nakakaapekto sa mga developer ng kontrata at mga user, na nangangailangan ng maraming pagsisikap para sa mga developer na muling magsulat ng mga kontrata na idinisenyo upang tumakbo sa Ethereum mainnet. Dahil ang pagbuo ng kontrata ay isang magastos, nakakaubos ng oras, at masinsinang proseso ng seguridad, ang mga limitasyong ito ay nagdudulot ng malaking hadlang sa pagpapatibay ng Optimism V1 at ito ang pangunahing dahilan ng kanilang paglipat patungo sa mga interactive na patunay ng panloloko.

Arbitrum

Ang isang rollup na kasalukuyang gumagamit ng mga interactive na fraud proof sa produksyon ay Arbitrum. Ang kanilang protocol ay nagbibigay-daan sa isang defender at challenger na hatiin ang mga pahayag ng isa’t isa hanggang sa makakita sila ng isang hakbang na hindi nila sinasang-ayunan, pagkatapos ay isagawa ito on-chain. Ang laki ng solong hakbang na pinili ng Arbitrum ay ang laki ng isang pagtuturo. Ang pagpapatupad ng isang pagtuturo ng isang virtual machine ay nangangailangan ng pagbibigay ng access sa panloob na estado ng virtual machine. Kabilang dito ang stack at memorya, pati na rin ang state at globals. Ang isang interpreter para sa virtual machine ay dapat na nakasulat na maaaring tumakbo sa Ethereum, at magsagawa ng mga iisang tagubilin.

Dahil kakailanganin nilang magsulat ng virtual machine interpreter, pinili ng Arbitrum na magsulat ng bago na naka-optimize para sa kanilang kaso ng paggamit ng pagpapatunay ng pagpapatupad ng mga solong hakbang, sa halip na magsulat ng interpreter para sa EVM. Ang isang halimbawa ng isang pag-optimize na ginawa nila ay upang baguhin ang istraktura ng memorya ng VM upang maging hindi nababago, kaya maaari itong palaging ma-access sa tuluy-tuloy na oras sa halip na logarithmic tulad ng kinakailangan ng kasalukuyang istraktura ng EVM. Tinawag nila itong rollup optimized virtual machine na AVM (Arbitrum Virtual Machine).

Habambuhay ng isang kontrata sa Arbitrum

Ang mga kontrata at transaksyon ng AVM ay walang kaparehong mga limitasyon gaya ng mga OVM, dahil ang mga transaksyon ay hindi kailanman muling isasagawa nang buo, maaari pa silang lumampas sa mga limitasyon sa Ethereum mainnet kung pipiliin ito ng mga Arbitrum node na payagan ito. Ang pagsulat ng isang bagong VM ay may iba pang mga pakinabang. Dahil ang anumang nakasulat sa AVM code ay maaaring mapatunayan sa Ethereum, ang mga developer ng Arbitrum ay maaaring magsama ng mga bagong opcode hangga’t maaari silang ma-back ng mga EVM opcode. Nagbibigay-daan ito sa kanila na madaling isama ang iba pang gawi ng node, tulad ng pagbabasa ng mga transaksyon mula sa kanilang mga kontrata sa Inbox, sa hanay ng mga operasyon na mapapatunayang tama. Maaaring gamitin ng Arbitrum ang parehong uri ng patunay ng panloloko para sa anumang pag-uugali ng kanilang node na nais nilang mapatunayan.

Ang isang malaking kawalan ng pagsusulat ng bagong VM ay maaaring hindi ito palaging tugma sa Ethereum, at kung saan posible ang pagiging tugma ay maaaring kailanganin ng karagdagang pagsisikap upang makamit ito.

Paglihis mula sa Ethereum

Pareho sa mga diskarte sa itaas ay nag-iiba mula sa EVM, na nagdudulot ng mga hamon sa engineering para sa Arbitrum, Optimism at kanilang mga user. Aasahan ng mga developer na nagsusulat ng mga kontrata para sa EVM na tatakbo ang kanilang mga kontrata sa AVM at sa OVM, aasahan nilang gagana ang mga kasalukuyang tool at ang mga JSON-RPC ay magiging pare-pareho sa Ethereum. Upang makamit ito, maaaring kailanganin ng mga rollup na i-shim ang node na JSON-RPC na mga endpoint upang kumilos nang tuluy-tuloy, na posible sa ilang mga kaso ngunit hindi sa iba.

Ang isang halimbawa kung saan nakamit ng Arbitrum ang pagkakapantay-pantay ay sa pagtanggap ng mga transaksyon sa EVM. Nagsulat ang Arbitrum ng isang EVM sa AVM compiler na mismong tumatakbo sa AVM. Nangangahulugan ito na ang mga transaksyong nilagdaan at isinumite sa EVM bytecode ay maaaring i-compile sa isang mapapatunayang paraan bilang bahagi ng kanilang pagpapatupad.

Ang isang halimbawa kung saan wala pang rollup sa ngayon ay nakakamit ng kumpletong parity ay nasa gas semantincs: Pinalitan ng optimismo ang ilang opcode na maaaring mangailangan ng mas maraming gas, at ang Arbitrum ay nag-tune ng mga gastusin upang ipakita ang halaga ng sa AVM.

Pagtatagpo sa Ethereum

Ang pagpili ng Optimism ng fraud proof ay humantong sa mga makabuluhang paghihigpit para sa kanilang mga user, at nagpapakita ng hadlang sa pag-aampon. Bumaling na sila ngayon sa mga interactive na patunay ng panloloko para alisin ang mga limitasyong iyon..

Gayunpaman, hindi tulad ng kasalukuyang bersyon ng Arbitrum, hindi nila gustong magdisenyo ng bagong virtual machine ngunit sa halip ay subukang maghanap ng representasyon ng EVM na mahusay na mapapatunayan sa chain. Ang paggawa nito ay isang pagtatangka na panatilihin ang 100% compatibility sa EVM at Ethereum. Pagkatapos ay maaari silang gumawa ng kaunting pagbabago sa mga umiiral nang Ethereum client codebase at patakbuhin sila bilang mga rollup client, na magmana ng seguridad at pagsusumikap na inilagay sa kanila. Dapat din itong mangahulugan na nakakamit nila ang pagiging tugma sa lahat ng kasalukuyang JSON-RPC na endpoint at ang mga tool na umaasa sa kanila nang walang anumang karagdagang pagsisikap.

Mukhang natanto na rin ng Arbitrum ang halaga ng diskarteng ito, at sa kanilang pinakabagong post sa blog ay nagbalangkas sila ng isang diskarte na magdadala sa kanila sa direksyong iyon.

Mayroong ilang mga paraan na ito ay maaaring lapitan:

1. Palawakin ang set ng pagtuturo upang maisama ang buong pagpapatunay ng bloke, at hatiin ang anumang malalaking hakbang sa mas maliliit na sub-steps. Ang proyekto ng Macula ay isang pagtatangka dito. Nilalayon nitong bumuo ng execution trace para sa buong execution ng Ethereum block, pagkatapos ay magsulat ng interpreter para sa execution trace na ito. Sa gayon, pinapayagan ang lahat ng mga operasyon sa isang bloke na hatiin sa isang hakbang at pagkatapos ay isagawa nang on-chain. Tinatalakay nito ang mga opcode na maaaring hindi mahusay para sa pagpapatunay, tulad ng pagkopya ng memorya, sa pamamagitan ng paghahati-hati sa mga ito sa mga sub-instruction na ang kabuuan nito ay katumbas ng pagpapatupad ng orihinal na pagtuturo.

Habambuhay ng isang kontrata sa Macula

1. Gumamit ng isang kasalukuyang arkitektura na mas madaling patunayan at ipatupad ang isang EVM interpreter para dito. Kinukuha ng proyekto ng Cannon ang mga bahagi ng Geth na ginagamit para sa pag-verify ng isang bloke. Pagkatapos ay pinagsama-sama nito ang mga bahaging iyon ng Geth sa isang set ng pagtuturo na mas madaling patunayan — gaya ng MIPS o RISC-V. Kapag ang MIPS-Geth na ito ay ginamit upang i-verify ang isang block, isang execution trace ang naitala. Ito ang execution trace na maaaring hatiin ng dalawang partido upang mahanap ang isang pagtuturo na hindi nila sinasang-ayunan, na pagkatapos ay isasagawa sa chain gamit ang on-chain MIPS interpreter . Lumilitaw din na ito ang direksyong gagawin ng plano ng Arbitrum, gayunpaman sa halip na MIPS nilalayon nilang gamitin ang pamantayan ng WASM.

Habambuhay ng isang kontrata sa Cannon

1. Gumawa ng zero knowledge proof ng solong hakbang na pagpapatupad. Sa halip na isagawa ang isang hakbang sa kadena, ang kontrata ay maaaring i-verify na ang isang patunay ng pagpapatupad ng isang hakbang na iyon ay wasto. Ang pagpapatunay ng malalaking paglipat ng estado, tulad ng mga buong transaksyon, sa zk ay kasalukuyang hindi posible sa maikling panahon, gayunpaman, ang paggawa ng mga patunay para sa isang hakbang ay dapat na magagawa. Ang diskarte na ito ay kasalukuyang sinisiyasat ng mga mananaliksik sa Oasis Labs at UC Berkeley, ngunit inilarawan din sa papel ng Arbitrum.

Habambuhay ng isang kontrata na may isang hakbang na zk

Ang bawat isa sa mga pamamaraang ito ay magbibigay ng mga fraud proof na walang mga limitasyon na humahadlang sa pag-aampon para sa mga user at magbibigay-daan sa mga rollup node na magpatakbo ng mga umiiral nang pagpapatupad ng Ethereum na nagmamana ng kanilang seguridad, kakayahang mapanatili at pagiging tugma sa Ethereum mainnet.

Ngunit lahat sila ay nangangailangan ng mas kumplikadong interactive na istilo ng fraud proof. Kaya posible bang makamit ang mga katangian sa itaas gamit ang isang hindi interactive na fraud proof?

Sa totoo lang, oo! Sa kasalukuyan ay may dalawang kilalang paraan para dito:

Mga zero knowledge proof para sa buong paglipat ng estado. Mayroon pa ring ilang mga hamon na kailangang malampasan bago magawa ang mga zk proof para sa buong transaksyon sa maikling (block time) na mga yugto ng panahon. Gayunpaman, kung ang zero knowledge proof ay ginagamit bilang fraud proof, hindi nito kailangang maging mahusay upang makagawa ng patunay. Sa kasalukuyan, ang mga fraud proof ay nagbibigay ng mahabang panahon ng hamon (~1 linggo) upang bigyan ng oras ang mga humahamon na patunayan ang kasalukuyang chain, bumuo ng fraud proof at isumite ito sa Ethereum. Kahit na ang pagbuo ng isang fraud proof ay tumatagal ng napakatagal (hal. 1–2 araw), kung gayon ang yugto ng pagsubok na ito ay maaaring pahabain nang may kaunting epekto sa pangkalahatang protocol. Tulad ng mga interactive na fraud proof, ang istilong ito ng fraud proof ay maaaring lumampas sa mga limitasyon ng L1. Ang pamamaraang ito ay kasalukuyang sinasaliksik ng Sumo, Consensys.

Habambuhay ng isang kontrata na may buong state transition zk

Mga bare metal fraud proof. Ang orihinal na layunin ng Optimism ay isagawa ang EVM code sa EVM, ngunit hindi nila magawa dahil ang mainnet EVM ay walang access sa rollup state. Ngunit posible bang magdisenyo ng isang sistema kung saan ito magiging posible?

Ito ang diskarte na kinuha ng Oasis Labs. Ang kanilang blockchain ay naghihiwalay sa pagpapatupad sa isang mabilis at mabagal na landas. Ang mga sub-committee ng consensus group ay nagsasagawa ng mga transaksyon laban sa isang ugat ng estado. Ang resultang ugat ng estado ay iniimbak sa isang base chain na na-validate ng buong consensus group. Kung sinumang miyembro ng isang sub-committee ang hindi sumasang-ayon sa nagreresultang ugat ng estado maaari nilang hilingin sa buong pinagkasunduan na muling isagawa ang anumang pinagtatalunang paglipat ng estado. Ang isang matapat na validator ay kinakailangan sa isang sub-committee upang mamana ang seguridad ng base chain — ang parehong seguridad tulad ng mga optimistic rollup.

Ang pamamaraang ito ay akma stateless client na konsepto ng Ethereum. Sa paradigm na ito, ang mga node ng consensus ay nag-iimbak lamang ng isang estadong ugat ng kadena. Ang mga transaksyon ay sinasamahan ng estado na kanilang ina-access, at isang saksi na magpapatunay na ang estado ay bahagi ng ugat ng estado. Ang mga walang estado na kliyente ay tumatanggap ng mga transaksyon na sinamahan ng estado at isinasagawa ang mga ito laban sa kanilang nakaimbak na ugat ng estado upang makabuo ng isang bagong ugat ng estado. Kung sa halip na isagawa ang mga natanggap na transaksyon laban sa kanilang naka-imbak na ugat ng estado ay ipapatupad nila ang mga ito laban sa isang ibinigay, magagawa nilang muling isagawa ang mga transaksyon para sa iba pang mga Ethereum na katugmang chain. Maaaring idagdag ang functionality na ito bilang isang bagong uri ng transaksyon na kumilos bilang sumusunod:

1. Ang data ay naglalaman ng isang bloke ng mga rollup na transaksyon na may kasamang estado at mga saksi, at isang ugat ng estado.
2. Isinasagawa ng kliyente ang bloke ng mga transaksyon laban sa ugat ng estado upang makagawa ng susunod na ugat ng estado.
3. Ang tuple ng (nakaraang ugat ng estado, hash ng block ng transaksyon, susunod na ugat ng estado) ay maiimbak sa isang pandaigdigang kontrata na nagbibigay-daan sa anumang matalinong kontrata na hanapin ang impormasyong ito at magsagawa ng pag-slash atbp. batay sa mga resulta.

Sa isang bagong uri ng transaksyon na tulad nito sa mga stateless client, magagawa ng Ethereum na ganap na muling isagawa ang mga transition ng estado para sa iba pang mga chain na katugma sa Ethereum. Maaari itong mag-alok ng simpleng hindi interactive na fraud proof para sa mga optimistic rollup na katugma sa Ethereum. Ang patunay ng panloloko na ito ay direktang tumatakbo sa EVM, sa halip na sa loob ng isang virtualized na kapaligiran na naka-host sa EVM — isang bare metal fraud proof.

Habambuhay ng isang kontrata na may bare metal fraud proof

Buod

Ang mga optimistikong rollup ay nangangailangan ng mga fraud proof upang manatiling ligtas. Tiningnan namin ang dalawang sikat na rollup at nakita kung paano nagdulot ng mga limitasyon ang kanilang pagpili ng fraud proof para sa kanilang mga user at developer ng kontrata (Optimism), o hindi napanatili ang kumpletong compatibility sa Ethereum (Arbitrum). Pareho sa mga rollup na ito ay gumagalaw patungo sa kumpletong compatibility sa Ethereum, nang walang anumang mga bagong limitasyon, at gumagamit ng mga interactive na fraud proof upang magawa ito. Gayunpaman, ang mga interactive na fraud proof ay mas kumplikado upang ligtas na bumuo, at may mga kasalukuyang paraan ng pananaliksik upang makahanap ng mahusay na hindi interactive na fraud proof na hindi nagpapataw ng mga karagdagang limitasyon at maaari pa ring manatiling tugma sa Ethereum.

Salamat kina Patrick McCorry, Dawn Song, Bennet Yee at Nicholas Liochon para sa kanilang feedback at input.

Orihinal na inilathala ni Chris Buckland sa https://medium.com noong Oktubre 22, 2021.

Abiso Ligal: Ang artikulong ito ay aking pagsasalin bilang isang Ambassador ng Pilipinas sa Oasis Labs. Upang mabasa ang orihinal na nilalaman, bisitahin ang: Fraud proofs and virtual machines