Mahabang artikulo ni Vitalik: Ang exit game ng EVM Validiums at ang pagbabalik ng Plasma

Pinapayagan tayo ng Plasma na ganap na iwasan ang isyu ng data availability, na lubos na nagpapababa ng mga bayarin sa transaksyon.

May-akda: Vitalik Buterin

Pagsasalin: jk, Odaily

 

Ang Plasma ay isang uri ng blockchain scaling solution na nagpapahintulot na ang lahat ng data at computation (maliban sa deposito, withdrawal, at Merkle root) ay manatili sa off-chain. Binubuksan nito ang pinto para sa napakalaking scalability na hindi limitado ng on-chain data availability. Unang iminungkahi ang Plasma noong 2017, at dumaan ito sa maraming iterasyon noong 2018, partikular ang Minimal Viable Plasma, Plasma Cash, Plasma Cashflow, at Plasma Prime. Sa kasamaang palad, dahil sa (i) mataas na gastos sa client-side data storage at (ii) mga pangunahing limitasyon ng Plasma na nagpapahirap na i-extend ito sa mga aplikasyon bukod sa pagbabayad, malaki na ang napalitan ng rollups ang Plasma.

 

Ang pag-usbong ng validity proofs (kilala rin bilang ZK-SNARKs) ay nagbibigay sa atin ng dahilan upang muling isaalang-alang ang desisyong ito. Ang pinakamalaking hamon sa pagpapagana ng Plasma para sa mga pagbabayad, ang client-side data storage, ay maaaring epektibong malutas sa pamamagitan ng validity proofs. Bukod dito, naglalaan ang validity proofs ng hanay ng mga tool na nagpapahintulot sa ating lumikha ng mga Plasma-like chain na nagpapatakbo ng EVM. Ang mga garantiya ng seguridad ng Plasma ay hindi sumasaklaw sa lahat ng user, dahil nananatili pa rin ang mga pangunahing dahilan kung bakit mahirap i-extend ang Plasma-style exit games sa maraming komplikadong aplikasyon. Gayunpaman, sa praktika, maaari pa ring maprotektahan ang napakalaking porsyento ng mga asset.

 

Sa ibaba, ipapaliwanag ko nang detalyado kung paano ito nakakamit ng Plasma.

 

Pangkalahatang-ideya: Paano gumagana ang Plasma

Ang pinakamadaling bersyon ng Plasma na dapat maintindihan ay ang Plasma Cash. Gumagana ang Plasma Cash sa pamamagitan ng pagtrato sa bawat indibidwal na token bilang isang hiwalay na NFT, at sinusubaybayan ang isang hiwalay na kasaysayan para sa bawat token. May operator ang Plasma chain na responsable sa paggawa at regular na pag-publish ng mga block. Ang bawat transaksyon sa block ay naka-store bilang isang sparse Merkle tree: kung ang transaksyon ay naglilipat ng pagmamay-ari ng token k, ito ay lilitaw sa posisyon k ng tree. Kapag lumikha ng bagong block ang Plasma chain operator, ipo-post nila ang Merkle root sa chain, at direktang ipapadala sa bawat user ang Merkle branch na tumutugma sa token na kanilang pagmamay-ari.

 

 

Ipalagay na ito ang huling tatlong transaction tree sa Plasma Cash chain. Kung ipagpapalagay na lahat ng naunang tree ay valid, alam natin na si Eve ay kasalukuyang may-ari ng token 1, si David ng token 4, at si George ng token 6.

 

Ang pangunahing panganib sa anumang Plasma system ay ang maling pag-uugali ng operator. Maaaring mangyari ito sa dalawang paraan:

 

1. Pag-publish ng invalid block (halimbawa, isinama ng operator ang isang transaksyon na naglilipat ng token 1 mula kay Fred papunta kay Hermione, kahit na hindi pagmamay-ari ni Fred ang token na iyon sa oras na iyon);

 

2. Pag-publish ng unavailable block (halimbawa, hindi ipinadala ng operator ang isa sa kanyang Merkle branch kay Bob, na pumipigil sa kanya na patunayan sa iba na ang kanyang token ay valid at hindi pa nagagastos).

 

Kung ang kilos ng operator ay may kaugnayan sa asset ng user, responsibilidad ng user na agad na mag-exit (partikular, sa loob ng 7 araw). Kapag ang user ("exitor") ay nag-exit, magbibigay sila ng Merkle branch na nagpapatunay ng inclusion ng transaksyon na naglipat ng token mula sa dating may-ari papunta sa kanila. Magsisimula ito ng 7-araw na challenge period, kung saan maaaring hamunin ng iba ang exit sa pamamagitan ng pagbigay ng isa sa tatlong uri ng Merkle proof:

 

1. Hindi pinakabagong may-ari: Isang kasunod na transaksyon na nilagdaan ng exitor, na naglilipat ng token sa ibang tao;

 

2. Double spend: Isang transaksyon na naglilipat ng token mula sa dating may-ari sa ibang tao, na na-include bago ang transaksyon na naglipat ng token sa exitor;

 

3. Invalid history: Isang transaksyon na naglipat ng token sa nakaraang 7 araw na walang kaukulang spend. Maaaring tumugon ang exitor sa pamamagitan ng pagbigay ng kaukulang spend; kung hindi nila ito gagawin, mabibigo ang exit.

 

 

Ayon sa mga patakarang ito, sinumang may-ari ng token k ay kailangang makita ang lahat ng Merkle branch sa posisyon k ng lahat ng historical tree sa nakaraang linggo upang matiyak na tunay nilang pagmamay-ari ang token k at maaari nila itong i-exit. Kailangan nilang i-store ang lahat ng branch na naglalaman ng asset transfer upang makasagot sila sa mga hamon at ligtas na ma-exit ang kanilang token.

 

Pagpapalawak sa Fungible Tokens

Ang disenyo sa itaas ay akma para sa non-fungible tokens (NFT). Gayunpaman, mas karaniwan kaysa sa NFT ay ang mga fungible token tulad ng ETH at USDC. Isang paraan upang i-apply ang Plasma Cash sa fungible tokens ay ang pagtrato sa bawat maliit na denominasyon ng token (halimbawa, 0.01 ETH) bilang isang hiwalay na NFT. Sa kasamaang palad, kung gagawin natin ito, magiging masyadong mataas ang gas fee ng exit.

 

Isang solusyon ay ang pag-optimize sa pamamagitan ng pagtrato sa maraming magkatabing token bilang isang unit, na maaaring ilipat o i-exit nang sabay-sabay. Dalawang paraan para gawin ito:

 

1. Gamitin halos ang orihinal na Plasma Cash, ngunit gumamit ng komplikadong algorithm upang mabilis na makalkula ang Merkle tree ng maraming object, kung maraming magkatabing object ang magkapareho. Hindi ito kasing hirap ng inaakala; makikita mo ang isang Python implementation dito.

 

2. Gamitin ang Plasma Cashflow, na simpleng nire-representa ang maraming magkatabing token bilang isang solong object.

 

Gayunpaman, parehong may fragmentation issue ang dalawang paraan: kung nakatanggap ka ng 0.001 ETH mula sa daan-daang tao na bumili ng kape, magkakaroon ka ng 0.001 ETH sa maraming bahagi ng tree, kaya ang aktwal na pag-exit ng mga ETH na ito ay mangangailangan pa rin ng maraming hiwalay na exit, na magpapataas ng gas fee. May mga protocol na dinevelop para sa defragmentation, ngunit mahirap itong ipatupad.

 

Isa pang paraan ay ang muling pagdisenyo ng sistema, na isinasaalang-alang ang mas tradisyonal na "unspent transaction output" (UTXO) model. Kapag nag-exit ka ng token, kailangan mong magbigay ng kasaysayan ng token sa nakaraang linggo, at maaaring hamunin ng sinuman ang iyong exit sa pamamagitan ng pagpapatunay na na-exit na ang mga token na iyon sa kasaysayan.

 

 

Ang withdrawal ng 0.2 ETH UTXO sa kanang ibaba ay maaaring kanselahin sa pamamagitan ng pagpapakita ng withdrawal ng alinman sa mga UTXO sa kasaysayan nito, gaya ng ipinapakita sa berdeng bahagi ng larawan. Partikular na pansinin na ang UTXO sa gitnang kaliwa at ibabang kaliwa ay mga ninuno, ngunit ang UTXO sa itaas na kaliwa ay hindi. Ang pamamaraang ito ay katulad ng order-based coloring concept sa colored coin protocol noong 2013.

 

May iba't ibang teknikal na paraan upang makamit ito. Sa lahat ng kaso, ang layunin ay subaybayan ang konsepto ng "parehong token" sa iba't ibang punto ng kasaysayan upang maiwasan ang double withdrawal ng "parehong token".

 

Mga Hamon sa Pagpapalawak sa EVM

Sa kasamaang palad, mas mahirap i-extend ito sa EVM para sa mga aplikasyon bukod sa pagbabayad. Isang pangunahing hamon ay maraming state object sa EVM ang walang malinaw na "may-ari". Ang seguridad ng Plasma ay nakasalalay sa bawat object na may may-ari na responsable sa pagmo-monitor at pagtiyak ng data availability ng chain, at mag-exit ng object kung may problema. Gayunpaman, hindi ganito ang operasyon ng maraming Ethereum application. Halimbawa, ang Uniswap liquidity pool ay walang iisang may-ari.

 

Isa pang hamon ay hindi sinusubukan ng EVM na limitahan ang dependencies. Sa block N, ang ETH na hawak ng account A ay maaaring magmula sa kahit saan sa block N-1. Upang mag-exit ng consistent state, ang isang EVM Plasma chain ay mangangailangan ng exit game kung saan, sa pinakamasamang kaso, kailangang bayaran ng gustong mag-exit gamit ang impormasyon ng block N ang gastos ng pag-publish ng buong block N state sa chain: maaaring umabot ito ng milyon-milyong dolyar. Walang ganitong problema ang UTXO-based Plasma scheme: bawat user ay maaaring mag-exit ng kanilang asset mula sa pinakabagong block kung saan mayroon silang data.

 

Ang ikatlong hamon ay ang walang katapusang dependencies sa EVM na nagpapahirap magkaroon ng consistent incentive para sa validity proofs. Ang validity ng anumang state ay nakadepende sa lahat ng iba pa, kaya ang pagpapatunay ng kahit anong bagay ay nangangailangan ng pagpapatunay ng lahat. Sa ganitong sitwasyon, dahil sa data availability issue, kadalasang hindi posible na gawing incentive-compatible ang failure resolution. Isang partikular na nakakainis na problema ay nawawala ang garantiya na mayroon sa UTXO-based system na hindi maaaring baguhin ang estado ng object nang hindi pumapayag ang may-ari. Napakahalaga ng garantiya na ito dahil ibig sabihin nito ay palaging alam ng may-ari ang pinakabagong provable state ng kanilang asset, at pinapasimple nito ang exit game. Kung wala ito, mas mahirap gumawa ng exit game.

 

Paano Nakakatulong ang Validity Proofs sa mga Problemang Ito

Ang pinaka-basic na papel ng validity proofs ay ang pagpapatunay sa chain ng validity ng bawat Plasma block. Lubos nitong pinapasimple ang design space: ibig sabihin, kailangan lang nating alalahanin ang operator's unavailable block attack, hindi ang invalid block. Halimbawa, sa Plasma Cash, tinatanggal nito ang pag-aalala sa historical challenges. Binabawasan nito ang state na kailangang i-download ng user mula sa isang branch bawat block sa nakaraang linggo, pababa sa isang branch bawat asset.

 

Bukod dito, ang extraction mula sa pinakabagong state (sa karaniwang kaso ng honest operator, lahat ng extraction ay mula sa pinakabagong state) ay hindi na apektado ng non-latest owner challenge, kaya sa validity proof Plasma chain, ang ganitong extraction ay hindi na kailangang i-challenge. Ibig sabihin, sa normal na kaso, maaaring gawin agad ang withdrawal.

 

Pagpapalawak sa EVM: Parallel UTXO Graph

Sa kaso ng EVM, pinapayagan din tayo ng validity proofs na gumawa ng matatalinong bagay: maaari itong gamitin upang magpatupad ng parallel UTXO graph para sa ETH at ERC 20 tokens, at gamitin ang SNARK upang patunayan ang equivalence ng UTXO graph at EVM state. Kapag mayroon ka na nito, maaari kang magpatupad ng "regular" Plasma system sa UTXO graph.

 

 

Pinapayagan tayo nitong iwasan ang maraming komplikasyon ng EVM. Halimbawa, sa account-based system, maaaring i-edit ng iba ang iyong account nang hindi mo alam (sa pamamagitan ng pagpapadala ng token sa iyo at pagdagdag sa iyong balanse), ngunit hindi ito mahalaga dahil ang Plasma construction ay hindi sa mismong EVM state, kundi sa parallel UTXO state, kaya ang anumang token na natanggap mo ay magiging hiwalay na object.

 

Pagpapalawak sa EVM: Buong State Exit

May mas simpleng mga scheme na iminungkahi para gumawa ng "Plasma EVM", tulad ng Plasma Free, at ang artikulong ito noong 2019. Sa mga scheme na ito, maaaring magpadala ng mensahe ang sinuman sa L1 upang pilitin ang operator na isama ang isang transaksyon o gawing available ang isang partikular na state branch. Kung hindi ito magawa ng operator, magsisimulang mag-revert ang chain ng mga block. Kapag may nag-publish ng buong kopya ng state, o kahit ang lahat ng data na maaaring nawawala ayon sa user, titigil ang chain sa pag-revert. Maaaring kailanganin ang paglalagay ng bounty para sa withdrawal, na magbabayad sa sinumang maglalabas ng ganoong kalaking data ng bahagi ng gas fee ng user.

 

Ang mga scheme na tulad nito ay may kahinaan na hindi nila pinapayagan ang instant withdrawal sa normal na kaso, dahil laging may posibilidad na kailangang mag-revert sa pinakabagong state.

 

Mga Limitasyon ng EVM Plasma Scheme

Malakas ang mga scheme na ito, ngunit hindi nila kayang magbigay ng ganap na garantiya ng seguridad para sa lahat ng user. Ang pinaka-halatang failure case ay kapag ang isang partikular na state object ay walang malinaw na economic "owner".

 

Isaalang-alang natin ang kaso ng CDP (collateralized debt position), isang smart contract kung saan nagla-lock ang user ng token at maaari lamang itong i-release kapag nabayaran na ang utang. Ipagpalagay na nag-lock ang user ng 1 ETH sa CDP (halaga ay humigit-kumulang 2000 USD sa oras ng pagsulat), at may utang na 1000 DAI. Ngayon, tumigil ang Plasma chain sa pag-publish ng block, at tumanggi ang user na mag-exit. Maaari lang hindi mag-exit ang user magpakailanman. Ngayon, may free option ang user: kung bumaba ang presyo ng ETH sa ilalim ng 1000 USD, iiwanan nila ang CDP; kung nanatili sa itaas ng 1000 USD ang presyo ng ETH, kukunin nila ito balang araw. Sa average, kikita ang malicious user sa ganitong paraan.

 

Isa pang halimbawa ay ang privacy system, tulad ng Tornado Cash o Privacy Pools. Isaalang-alang ang isang privacy system na may limang depositor:

 

 

Pinananatiling lihim ng ZK-SNARKs sa privacy system ang koneksyon sa pagitan ng may-ari ng token na pumasok at ng may-ari ng token na lumabas.

 

Ipagpalagay na ang orange lang ang nakapag-withdraw, at sa puntong ito ay tumigil na ang Plasma chain operator sa pag-publish ng data. Ipagpalagay na gumagamit tayo ng UTXO graph method na may first-in-first-out rule, kaya bawat token ay tumutugma sa token sa ibaba nito. Sa ganitong kaso, maaaring i-withdraw ng orange ang kanilang pre-mix at post-mix token, at ituturing ng system na dalawang hiwalay na token ito. Kung susubukan ng blue na i-withdraw ang kanilang pre-mix token, mapapalitan ito ng updated state ng orange; kasabay nito, wala ring impormasyon ang blue para i-withdraw ang kanilang post-mix token.

 

Kung papayagan mong i-withdraw ng iba pang apat na depositor ang privacy contract mismo (na magpapalit sa deposit), at pagkatapos ay i-withdraw ang token sa L1, maaaring malutas ang problemang ito. Gayunpaman, nangangailangan ng karagdagang pagsisikap mula sa mga developer ng privacy system ang aktwal na pagpapatupad ng ganitong mekanismo.

 

May iba pang paraan upang lutasin ang privacy issue, tulad ng Intmax method, na kinabibilangan ng paglalagay ng ilang bytes sa chain sa rollup style, at isang Plasma-like operator na nagpapasa ng impormasyon sa pagitan ng mga user.

 

May katulad na problema ang Uniswap LP positions: kung nag-trade ka ng ETH para sa USDC sa Uniswap position, maaari mong subukang i-withdraw ang USDC mo bago ang trade at ang ETH mo pagkatapos ng trade. Kung makikipagsabwatan ka sa Plasma chain operator, hindi makaka-access ng post-trade state ang liquidity provider at iba pang user, kaya hindi nila mawi-withdraw ang kanilang post-trade USDC. Kailangan ng espesyal na logic upang maiwasan ito.

 

Konklusyon

Kahit noong 2023, nananatiling isang undervalued na disenyo ang Plasma. Ang rollups pa rin ang gold standard at may mga security property na hindi matutumbasan. Lalo na mula sa pananaw ng developer experience: walang tatalo sa pagiging simple na hindi na kailangang isipin ng application developer ang ownership graph at incentive flow sa kanilang application.

 

Gayunpaman, pinapayagan tayo ng Plasma na ganap na iwasan ang data availability issue, na lubos na nagpapababa ng transaction fees. Para sa mga chain na magiging validiums sana, maaaring maging malaking security upgrade ang Plasma. Sa wakas ay naabot ng ZK-EVMs ang production ngayong taon, na nagbibigay sa atin ng magandang pagkakataon upang muling tuklasin ang design space na ito, at magmungkahi ng mas epektibong mga konstruksyon upang gawing mas simple ang developer experience at maprotektahan ang pondo ng user.

Espesyal na pasasalamat kina Karl Floersch, Georgios Konstantopoulos, at Martin Koppelmann para sa kanilang kontribusyon sa feedback, review, at diskusyon.