Modular Blockchain: Trace Execution, Data at Settlement

Ang isang modular blockchain ay naghahati ng mga responsibilidad sa mga bahagi sa halip na humiling sa isang sistema na gawin ang bawat gawain. Na maaaring gawing simple ang isang paglalarawan ng network: nangyayari ang pagpapatupad dito, napupunta ang data doon at nangyayari ang pag-aayos sa ibang lugar. Ang mahalagang tanong ay kung ano talaga ang ginagarantiya ng bawat bahagi.

Ang artikulong ito ay naghahambing ng mga tungkulin sa arkitektura, hindi mga presyo ng token o isang pagraranggo ng mga proyekto. Ang isang modular na disenyo ay hindi awtomatikong nagpapahiwatig ng mas mababang panganib, mas mataas na pamumuhunan, o magkaparehong seguridad sa mga pagpapatupad.

Paghiwalayin ang mga trabaho bago paghambingin ang mga system

Inilalapat ng pagpapatupad ang mga panuntunan sa transaksyon at kinukuwenta ang isang iminungkahing pagbabago ng estado. Ang pagkakaroon ng data ay nag-aalala kung ang impormasyong kailangan upang i-verify ang system ay ginawang available. Ang pag-areglo ay may kinalaman sa kung paano tinatanggap ang mga cryptographic commitment sa estado ng chain (state commitments), mga patunay o mga hindi pagkakaunawaan sa ilalim ng isang partikular na protocol. Tinutukoy ng consensus ang napagkasunduang pag-order o tinanggap na kasaysayan sa loob ng isang sistema.

Ang mga tungkuling ito ay maaaring mag-overlap o maipamahagi sa iba't ibang paraan. Hindi sapat ang mga label ng proyekto: maaaring tawagin ng isang network ang sarili nitong modular habang pinapanatili ang makabuluhang kontrol sa isang sequencer, upgrade key o komite ng data. Iguhit ang aktwal na mapa ng dependency sa halip na ipagpalagay na ang lahat ng modular network ay nagbabahagi ng isang trust model.

Ipinapaliwanag ng dokumentasyon ng data-availability ng Ethereum kung bakit nakadepende ang pag-verify sa access sa data ng transaksyon at kung bakit kailangan ng mga magaan na kliyente at rollup ng naaangkop na mga katiyakan. Ang pag-access sa data ay ibang tanong sa kung tama ang isang naisagawang pagkalkula.

Sundin ang isang hypothetical na transaksyon

Isipin na ang isang user ay nagpapadala ng isang transaksyon sa isang execution network. Kasama ito sa isang sequencer sa isang batch. Ginagawang available ng system ang kinakailangang data gamit ang napili nitong layer ng data at nagsusumite ng state commitment, kasama ang mekanismo ng pag-verify na kinakailangan ng disenyo nito, sa isang settlement layer.

Maaaring makakita ang user ng maagang kumpirmasyon bago maabot ng bawat yugto ang huling katayuan nito. Itala kung ano ang ibig sabihin ng bawat status: natanggap, inutusan, naisakatuparan, nai-publish na data, tinanggap ang patunay o nakumpleto ang window ng dispute. Huwag lagyan ng label ang pinakaunang pagkilala bilang pinal na kasunduan maliban kung sinusuportahan ng protocol ang interpretasyong iyon.

Inilalarawan ng halimbawang ito ang mga tungkulin sa halip na magreseta ng isang unibersal na pagkakasunud-sunod. Maaaring pagsamahin ng iba't ibang rollup at modular system ang mga yugto o gumamit ng iba't ibang proof at finality arrangement.

Itanong kung ano ang mangyayari kapag nabigo ang isang bahagi

Kung huminto ang isang sequencer, maaari bang magsumite ang mga user ng mga transaksyon sa ibang paraan, at sa ilalim ng anong mga kundisyon? Kung ipinagkakait ng isang serbisyo ng data ang impormasyon, sino ang nakakakita nito at ano ang maaaring i-verify ng mga user? Kung masikip ang isang settlement layer, paano naaapektuhan ang mga commitment o withdrawal?

Sagutin ang mga tanong na ito mula sa kasalukuyang dokumentasyon, kabilang ang mga pamamaraang pang-emergency at mga kontrol na administratibo. Ang isang fallback na inilarawan sa isang roadmap ay hindi kinakailangang gumagana. Ang isang network na patuloy na nagpapakita ng mga balanse ay maaaring nabawasan pa rin ang kakayahang tumanggap ng mga transaksyon o kumpletong pag-withdraw.

Suriin ang bridge dependencies nang hiwalay. Ang isang token na lumalabas sa dalawang network ay hindi nangangahulugan na ang ruta ng paglipat ay nagmamana ng bawat security property ng parehong chain.

Ihambing ang kumpletong gastos at karanasan ng user

Ang mababang bayad sa pagpapatupad ay bahagi lamang ng halaga ng transaksyon. Maaaring magdagdag ng mga singil o pagkaantala ang paglalathala ng data, pag-aayos, pag-bridging at pag-withdraw. Paghambingin ang mga katumbas na aksyon sa parehong panahon at ipaliwanag kung sino ang magbabayad ng halaga.

Sukatin ang buong rutang nauugnay sa user: pagpasok, pagpapatupad, pagkumpirma, pag-withdraw at pagbalik sa gustong asset o network. Ang isang benchmark na sumasaklaw lamang sa isang yugto ay hindi dapat ipakita bilang presyo ng isang buong round trip. Ang pagtitipid sa gastos ay maaari ding mag-iba sa mga kondisyon ng demand at data-layer.

Gumamit ng checklist ng dependency

Para sa bawat system, itala ang mga panuntunan sa pagpapatupad, awtoridad sa pag-order, lokasyon ng data, mekanismo ng pag-verify, patutunguhan ng settlement, mga kontrol sa pag-upgrade at pamamaraan ng paglabas. Markahan kung aling mga claim ang live at alin ang nakaplano. Isama ang mga pinagmulan at ang petsang nasuri, dahil maaaring magbago ang mga setting ng arkitektura.

Para sa isang nauugnay ngunit natatanging problema, basahin ang cross-chain message comparison: sumusunod ito sa mga tagubilin sa pagitan ng mga chain, habang ang gabay na ito ay sumusunod sa dibisyon ng trabaho sa loob ng isang arkitektura.

Ang disenyo ng engineering ng protocol at ang mga karapatang pang-ekonomiya ng token nito ay magkahiwalay na mga katanungan sa pananaliksik. Suriin ang utility ng token at aktwal na availability ng market nang hiwalay sa pamamagitan ng opisyal na dokumentasyon at sa page ng OrangeX markets, sa halip na ituring ang isang scaling claim bilang isang konklusyon sa kalakalan.