Vitalik: Paglilinaw sa Iba't Ibang Uri ng L2

Ang mga L2 na proyekto ay lalong magiging heterogeneous.

Orihinal na Pamagat: 《Different types of layer 2s》

May-akda: Vitalik Buterin

Pagsasalin: BlockBeats

Mabilis na lumawak ang ecosystem nitong nakaraang taon. Tradisyonal na kinakatawan ng StarkNet, Arbitrum, Optimism, at Scroll ang ZK-EVM rollup ecosystem na mabilis ang pag-unlad at patuloy na pinapabuti ang kanilang seguridad. Ang L2beat page ay mahusay na nagbubuod ng estado ng bawat proyekto.

Bukod dito, nakikita rin natin ang ilang mga team na bumubuo ng sidechains habang nagsisimula ring bumuo ng mga rollup solution (tulad ng Polygon), ilang L1 na proyekto na sumusubok lumipat patungo sa validity proofs (tulad ng Celo), at mga bagong eksperimento (tulad ng Linea, Zeth…).

Isa sa mga hindi maiiwasang resulta nito ay nakikita natin ang mga L2 na proyekto na nagiging mas heterogeneous (ibig sabihin, "heterogeneous". Tala ng tagasalin: Sa larangan ng crypto, ang "heterogeneous" ay tumutukoy sa sitwasyon kung saan magkasamang umiiral o naghahalo ang iba't ibang uri o katangian ng mga bagay. Karaniwan itong ginagamit upang ilarawan ang iba't ibang blockchain, protocol, teknolohiya, o asset na may kanya-kanyang katangian, patakaran, o katangian). Inaasahan kong magpapatuloy ang trend na ito, dahil sa mga sumusunod na dahilan:

Sa kasalukuyan, ang ilang mga independenteng L1 na proyekto ay naghahangad na mas mapalapit sa Ethereum ecosystem, at posibleng mag-transform bilang L2 na proyekto. Maaaring nais ng mga proyektong ito na gawin ang transition nang paunti-unti. Ang agarang kabuuang transition ay magpapababa ng usability, dahil hindi pa handa ang teknolohiya upang ilagay ang lahat sa rollup solution. Samantalang kung huli na ang kabuuang transition, maaaring mawala ang momentum at hindi na ito maging makabuluhan.

Ang ilang centralized na proyekto ay nais magbigay ng mas mataas na seguridad para sa kanilang mga user, at nagsasaliksik ng mga blockchain-based na paraan. Sa maraming kaso, maaaring dati nilang pinag-aralan ang "permissioned consortium chains". Sa katunayan, maaaring kailanganin lang nila ang antas ng "semi-centralized". Bukod pa rito, kadalasan ay may napakataas silang throughput, na hindi angkop para sa rollup solution kahit sa panandaliang panahon.

Ang mga non-financial na application, tulad ng gaming o social media, ay nais maging decentralized, ngunit nangangailangan lamang ng tiyak na antas ng seguridad.

Sa kaso ng social media, aktuwal na may iba't ibang paraan ng paghawak sa iba't ibang bahagi ng application: Ang mga bihira at mataas ang halaga na aktibidad tulad ng username registration at account recovery ay dapat gawin sa rollup solution, ngunit ang mga madalas at mababa ang halaga na aktibidad tulad ng pagpo-post at pagboto ay nangangailangan ng mas kaunting seguridad; kung mawala ang iyong post dahil nagka-aberya ang blockchain, katanggap-tanggap iyon; ngunit kung mawala ang iyong account, mas malaki ang problema.

Isang mahalagang tema ay, bagaman ang mga application at user na kasalukuyang nasa Ethereum L1 ay handang magbayad ng maliit ngunit kapansin-pansing rollup fees sa panandaliang panahon, ang mga user mula sa non-blockchain world ay hindi ganoon kadaling tanggapin ito: kung dati kang nagbabayad ng $1, mas madaling tanggapin ang $0.10, ngunit kung dati kang $0, mahirap tanggapin.

Naaangkop ito sa mga application na nananatiling centralized ngayon, at maging sa maliliit na L1 na proyekto na may napakababang fees dahil maliit pa ang user base.

Isang natural na tanong: Para sa partikular na application, sa mga komplikadong trade-off sa pagitan ng rollup solution, validiums (validity proofs), at iba pang system, alin ang pinakaangkop?

Rollups vs Validiums vs Disconnected Systems

Ang unang dimensyon ng seguridad at scalability na ating tatalakayin ay maaaring ilarawan ng ganito: Kung mayroon kang asset na inilabas sa L1, pagkatapos ay ideposito ito sa L2, at pagkatapos ay ilipat sa iyong kamay, gaano kataas ang garantiya na maaari mong maibalik ang asset sa L1?

May kaugnay ding tanong: Ano ang mga teknikal na pagpipilian na nagdudulot ng ganitong antas ng garantiya, at ano ang mga trade-off ng mga pagpipiliang iyon?

Maaari nating ilarawan ang problemang ito gamit ang isang simpleng chart:

Karapat-dapat banggitin na ito ay isang pinasimpleng scenario, at mayroong maraming intermediate na opsyon. Halimbawa:

Sa pagitan ng rollup at validium: Sa validium, maaaring magbayad on-chain ang sinuman para sa transaction fees, at sa puntong iyon, mapipilitang magbigay ng operator ng ilang data sa chain, kung hindi ay mawawala ang kanilang deposit.

Sa pagitan ng plasma at validium: Ang isang Plasma system ay nagbibigay ng rollup-like na seguridad, na may off-chain data availability, ngunit limitado lamang sa ilang application. Maaaring magbigay ang isang system ng full EVM, at para sa mga user na hindi gumagamit ng mas komplikadong application, magbigay ng Plasma-level na garantiya, at para sa mga gumagamit ng mga application na iyon, magbigay ng validium-level na garantiya.

Ang mga intermediate na opsyon na ito ay maaaring ituring na spectrum sa pagitan ng rollup at validium. Ngunit ano ang nagtutulak sa application na pumili ng partikular na punto sa spectrum na ito, sa halip na mas kaliwa o kanan? Dito, may dalawang pangunahing salik:

1. Ang halaga ng Ethereum native data availability, na bababa habang umuunlad ang teknolohiya. Ang susunod na hard fork ng Ethereum, Dencun, ay magpapakilala ng EIP-4844 (kilala rin bilang "proto-danksharding"), na magbibigay ng humigit-kumulang 32 kB/segundo ng on-chain data availability.

Inaasahan na sa susunod na mga taon, habang inilulunsad ang full danksharding, unti-unting tataas ang data availability na ito, na may layuning umabot sa humigit-kumulang 1.3 MB/segundo. Kasabay nito, ang mga pagpapabuti sa data compression ay magpapahintulot sa atin na makagawa ng mas marami gamit ang parehong dami ng data.

2. Ang sariling pangangailangan ng application: Gaano kalala ang epekto ng mataas na fees sa user, kumpara sa epekto ng pagkakaroon ng problema sa application? Ang mga financial application ay mas malaki ang mawawala kapag nagka-aberya ang application; ang mga laro at social media ay may maraming user activity ngunit mababa ang halaga ng bawat aktibidad, kaya para sa kanila, makabuluhan ang iba't ibang security trade-off.

Ang trade-off na ito ay mukhang ganito sa pangkalahatan:

Isa pang uri na dapat banggitin ay ang pre-confirmations. Ang pre-confirmation ay isang mensahe na nilagdaan ng grupo ng mga kalahok sa rollup o validium, na nagsasabing "pinapatunayan namin na ang mga transaksyong ito ay kasama sa pagkakasunod na ito, at ang post-state root ay ito." Maaaring pumirma ang mga kalahok ng pre-confirmation na hindi tumutugma sa realidad, ngunit kung gagawin nila ito, masisira ang kanilang deposito.

Napakakapal nito para sa mga low-value application (tulad ng consumer payments), habang ang mga high-value application (tulad ng multi-million dollar financial transfers) ay maaaring maghintay ng "regular" confirmation na suportado ng full system security.

Maaaring ituring ang pre-confirmations bilang isa pang halimbawa ng hybrid system, katulad ng nabanggit na "plasma/validium hybrid", ngunit sa pagkakataong ito ay pinaghalo ang rollup (o validium) na may full security ngunit mataas ang latency, at isang system na may mas mababang security ngunit mababa ang latency. Ang mga application na nangangailangan ng mababang latency ay makakakuha ng mas mababang security, ngunit maaaring mag-coexist sa parehong ecosystem kasama ng mga application na handang magtiis ng mas mataas na latency para sa maximum security.

Trustless Reading of Ethereum

Isa pang uri ng koneksyon na hindi gaanong napag-uusapan ngunit napakahalaga, ay may kinalaman sa kakayahan ng system na magbasa ng Ethereum blockchain. Partikular, kabilang dito ang kakayahan ng system na mag-rollback kapag nag-rollback ang Ethereum. Upang maunawaan kung bakit ito mahalaga, isaalang-alang ang sumusunod na sitwasyon:

Ipagpalagay na gaya ng nasa larawan, nagkaroon ng rollback ang Ethereum blockchain. Maaaring ito ay pansamantalang pagkaantala sa loob ng isang epoch, kung saan hindi pa finalized ang blockchain; o maaaring dahil sa sobrang daming validator na offline, na nagdulot ng non-finality leak period na mas matagal bago mag-finalize ang blockchain.

Ang pinakamasamang maaaring mangyari ay ito: Ipagpalagay na ang unang block ng top chain ay nagbasa ng ilang data mula sa pinakakaliwang block ng Ethereum chain. Halimbawa, may nagdeposito ng 100 ETH sa top chain mula sa Ethereum. Pagkatapos ay nagkaroon ng rollback ang Ethereum, ngunit hindi nag-rollback ang top chain. Ang resulta, ang mga susunod na block ng top chain ay sumusunod sa bagong, tamang Ethereum blockchain, ngunit ang maling transaksyon (ang 100 ETH deposit) ay nananatili sa top chain. Ang bug na ito ay maaaring magdulot ng over-issuance ng currency, na ginagawang fractional reserve ang bridged ETH sa top chain.

May dalawang paraan upang solusyunan ito:

1. Ang top chain ay maaari lamang magbasa ng mga finalized na block ng Ethereum, kaya hindi kailanman kailangang mag-rollback;

2. Kung mag-rollback ang Ethereum, maaari ring mag-rollback ang top chain. Pareho nitong pinipigilan ang problema. Mas madaling ipatupad ang una, ngunit kung pumasok ang Ethereum sa non-finality leak period, maaaring mawalan ng functionality ang system nang matagal. Mas mahirap ipatupad ang pangalawa, ngunit tinitiyak ang pinakamahusay na functionality sa lahat ng oras.

Pansinin na may espesyal na kaso sa unang paraan. Kung magkaroon ng 51% attack sa Ethereum na magdudulot ng dalawang bagong hindi compatible na block na parehong finalized, maaaring pumili ang top chain ng maling block (yung hindi sinusuportahan ng Ethereum social consensus), at kailangang mag-rollback para lumipat sa tamang block. Maaring hindi na kailangang isulat ang code para dito nang maaga; maaaring i-hard fork ang top chain upang ayusin ito.

May dalawang mahalagang dahilan kung bakit mahalaga ang kakayahan ng blockchain na magbasa ng Ethereum nang trustless:

Una, pinapababa nito ang security risk ng pag-bridge ng mga token na inilabas sa Ethereum (o ibang L2 solution) papunta sa chain na iyon;

Pangalawa, pinapayagan nito ang account abstraction wallets na gumagamit ng shared key storage structure na ligtas na maghawak ng asset sa chain na iyon.

Bagaman may debate, malawak nang kinikilala ang kahalagahan ng unang paraan. Gayundin, mahalaga ang pangalawa, dahil nangangahulugan ito na maaari kang magkaroon ng wallet na madaling magpalit ng key at maghawak ng asset sa maraming chain.

Maaaring Maging Validium ba ang Pagkakaroon ng Bridge?

Ipagpalagay na ang top chain ay orihinal na inilunsad bilang isang independent chain, pagkatapos ay may nag-deploy ng bridge contract sa Ethereum. Ang bridge contract ay isang contract na tumatanggap ng block headers mula sa top chain, at tinitiyak na ang anumang block header na isusumite dito ay may valid na certificate na nagpapatunay na tinanggap ito ng consensus ng top chain, at idinadagdag ito sa listahan.

Maaaring magtayo ng mga application sa ibabaw nito, tulad ng deposit at withdrawal ng token. Kapag naitayo na ang ganitong bridge, nagbibigay ba ito ng anumang asset security guarantee na nabanggit natin kanina?

Sa ngayon, hindi pa! Dalawang dahilan:

1. Tinitiyak lang natin ang signature ng block, pero hindi kung tama ang state transition. Kaya kung magdeposito ka ng asset na inilabas sa Ethereum sa top chain, at naging dishonest ang mga validator ng top chain, maaari silang pumirma ng invalid state transition at nakawin ang mga asset na iyon;

2. Hindi pa rin makabasa ng Ethereum ang top chain. Kaya hindi mo mailalagay ang Ethereum native asset sa top chain maliban kung aasa ka sa ibang (maaaring hindi secure) na third-party bridge.

Ngayon, gawin nating verification bridge ang bridge: hindi lang nito tinitiyak ang consensus, kundi tinitiyak din na ang anumang bagong block na na-compute gamit ang ZK-SNARK proof ay tama ang state.

Kapag nagawa na ito, hindi na maaaring nakawin ng mga validator ng top chain ang iyong pondo. Maaari silang mag-publish ng block na may unavailable data at pigilan ang lahat na mag-withdraw, pero hindi nila maaaring nakawin ang pondo (maliban kung susubukan nilang hingin ang ransom mula sa user para ibunyag ang data na magpapahintulot sa withdrawal). Ito ay kapareho ng security model ng validium.

Gayunpaman, hindi pa rin natin nasosolusyunan ang pangalawang problema: hindi pa rin makabasa ng Ethereum ang top chain. Para magawa ito, kailangan nating gawin ang isa sa dalawang paraan:

1. Maglagay ng bridge contract sa top chain na nagva-validate ng finalized Ethereum blocks;

2. Isama sa bawat block ng top chain ang hash ng pinakabagong Ethereum block, at gumamit ng fork choice rule para pilitin ang hash link. Ibig sabihin, ang top chain block na naka-link sa Ethereum block na wala sa main chain ay magiging non-main chain din. Kung ang Ethereum block na naka-link sa top chain block ay nasa main chain noong una pero naging non-main chain, dapat maging non-main chain din ang top chain block.

Ang mga purple na link na ito ay maaaring hash link o bridge contract na nagva-validate ng Ethereum consensus

Sapat na ba ito? Sa katunayan, hindi pa, dahil may ilang maliit na edge cases:

1. Ano ang mangyayari kung magkaroon ng 51% attack sa Ethereum?

2. Paano haharapin ang hard fork upgrade ng Ethereum?

3. Paano haharapin ang hard fork upgrade ng iyong chain?

Ang 51% attack sa Ethereum ay magdudulot ng katulad na epekto sa 51% attack sa top chain, ngunit kabaligtaran. Ang hard fork ng Ethereum ay maaaring magdulot ng failure ng Ethereum bridge sa loob ng top chain. Ang isang social commitment, na kung magre-revert ang Ethereum ng finalized block ay magre-revert din, at kung mag-hard fork ang Ethereum ay magha-hard fork din, ay ang pinakamalinis na solusyon.

Maaring hindi kailanman kailanganin talagang ipatupad ang ganitong commitment: kung makita ng governance body ng top chain na may ebidensya ng posibleng attack o hard fork, maaaring i-activate ang governance body, at kung mag-fail ito, saka lang mag-hard fork ang top chain.

Para sa ikatlong problema, ang tanging praktikal na sagot ay mag-set up ng governance body sa Ethereum na magpapabatid sa bridge contract sa Ethereum tungkol sa hard fork upgrade ng top chain.

Buod: Ang bidirectional verification bridge ay halos sapat na para gawing validium ang isang blockchain. Ang pangunahing natitirang elemento ay isang social commitment na kung magkaroon ng abnormal na sitwasyon sa Ethereum na magdudulot ng failure ng bridge contract, magha-hard fork ang kabilang blockchain bilang tugon.

Konklusyon

May dalawang pangunahing dimensyon ang "pagkonekta sa Ethereum":

1. Seguridad ng pag-withdraw sa Ethereum;

2. Seguridad ng pagbabasa mula sa Ethereum.

Pareho itong napakahalaga, at may kanya-kanyang konsiderasyon. Sa parehong kaso, mayroong spectrum:

Pansinin na bawat dimensyon ay may dalawang magkaibang paraan ng pagsukat (sa katunayan, apat na dimensyon): Ang withdrawal security ay maaaring sukatin sa pamamagitan ng (i) antas ng seguridad, at (ii) gaano karaming user o use case ang nakikinabang sa pinakamataas na antas ng seguridad;

Samantalang ang read security ay maaaring sukatin sa pamamagitan ng (i) gaano kabilis makabasa ng Ethereum blocks ang chain, lalo na ang pagkakaiba ng finalized blocks at anumang block, at (ii) antas ng social commitment ng chain sa paghawak ng mga edge case tulad ng 51% attack at hard fork.

May halaga ang mga proyekto sa maraming bahagi ng design space na ito. Para sa ilang application, napakahalaga ng mataas na seguridad at mahigpit na koneksyon. Para sa iba, para makamit ang mas mataas na scalability, maaaring tanggapin ang mas maluwag na kondisyon. Sa maraming kaso, maaaring pinakamainam na magsimula ngayon gamit ang mas maluwag na kondisyon, at unti-unting lumipat sa mas mahigpit na coupling habang umuunlad ang teknolohiya sa susunod na dekada.