Suvestinių sąveikumo sprendimų būklė

Kaip į apibendrinamą ekosistemų entuziastą, mane visada domino sprendimai, kurie pagerina duomenų paketo sąveiką. Be to, vienintelė priežastis, dėl kurios sukūriau šią tyrimo ataskaitą, buvo siekis skleisti žinią apie sąveikos svarbą šioje srityje. Tada supratau, kad straipsnių rašymas yra puikus būdas sustiprinti savo supratimą apie tam tikrą temą ir padėti žmonėms ją suprasti, ir dabar aš čia.

Kadangi kiekvieną dieną kriptovaliutoje mokomasi naujų dalykų, turėtų atrodyti akivaizdu, kad šiandien vizija „Sudėtinis suderinamumas yra labai svarbus Ethereum ateičiai“ yra gana pasenusi. Remiantis filosofijos POV, aš vis dar laikausi tos pačios vizijos** – apibendrinimo sąveika yra labai svarbi Ethereum** ateičiai, ir visa ekosistema turėtų ieškoti sprendimų, kurie ją pagerintų. Tačiau iš technologijų POV sužinojau daug naujų idėjų šia tema ir pakeičiau savo nuomonę dėl kai kurių dalykų.

Norint suprasti toliau pateiktą medžiagą, pravartu turėti pagrindinį supratimą apie suvyniojimus ir jų sąveikumo problemą. Jei to nepadarysite, mano straipsnis „Dr. Dankshardas arba kaip aš išmokau nustoti jaudintis ir mylėti „rollups““ yra puiki įžanga.

Merhaba!

Lapkričio 13-osios vakaras, pirmoji „Devconnect Istanbul“ diena. Kaip didžiulis „ZkSync“ gerbėjas, nusprendžiau dalyvauti „zkSync Connect“ kaip mano pirmasis renginys šiame aukščiausiojo lygio susitikime, pirmasis mano gyvenime. Ten sutikau vaikiną ir kartu nuėjome į „Mosyo Coffee“, kaip teigiama „zkCafe“ „Luma“ puslapyje. Toje vietovėje jų buvo du, o tinkamą vietą radome tik vakare.

Buvo daug tamsesnis nei aukščiau esančioje nuotraukoje ir lijo. Apsistojęs prie stogo krašto, ant kurio buvo maisto aikštelė, ir gerdama kavą, kurią už nemokamus žetonus nusipirkome Clave , papasakojau savo naujajam draugui apie savo hakatono projekto idėją.

Yra „mini paskyros“: ERC-4337 paskyros, kurių patvirtinimo logika yra ne parašo patikrinimas, o operacijos maišos buvimas viename gautųjų tiltelyje jo L2. Maiša turi būti siunčiama iš pirminio adreso konkrečioje šaltinio grandinėje. Pirminis adresas yra jūsų pagrindinė išmanioji piniginė bet kuriame L2 arba Ethereum L1. Norėdami bendrauti su kitu L2, turite:

• Įdiekite joje mini paskyrą ir nustatykite pagrindinę piniginę kaip pagrindinį adresą. Kiekvienas gali atlikti diegimą; taigi, jį gali finansuoti protokolas arba jūsų piniginės teikėjas.

• Siųskite vartotojo operacijos, kurią norite siųsti, maišą į gautųjų tiltą savo L2 ir nustatykite paskirties grandinės ID.

• Ši maiša sujungiama su kitomis maišomis ir siunčiama į L1. Išmanioji sutartis L1 persiunčia šį paketą į paskirties vietą L2, o gautųjų tiltas atskiria maišas, kad mini paskyros galėtų jas nuskaityti.

• Siuntėjas prideda nedidelį mokestį prie maišos, kad paskatintų operacijų, susijusių su protokolo išmaniosiomis sutartimis, iniciatorius.

• Kai maiša pasiekia paskirties vietą L2, siunčiate savo vartotojo operaciją į šios L2 AA atmintinę. Naudodami ERC-4337 standartą, mes neturime iš naujo įdiegti savo mini paskyros atminties ir protokolą galima lengvai integruoti į pinigines su jau esančia kodų baze.

  
  

Trumpai tariant, ketinau sukurti L1 pagrįstą tiltą, kuris siunčia operacijas iš jūsų L2 išmaniosios piniginės į bet kurią L2, su kuria norite bendrauti. Beveik įgyvendinau jį hakatone, bet negalėjau jo užbaigti dėl mažai patirties ir darbo solo. Paaiškinęs draugui, jis manęs paklausė:

Kodėl žmogus tiesiog nepakeičia tinklo savo piniginėje ir nenaudoja žetonų tiltų, kad perkeltų reikiamas lėšas į reikiamą tinklą?

Aš atsakiau : Tai yra absoliuti galimybė, jei naudojate EOA piniginę. EOA piniginės veikia vienodai visuose EVM tinkluose ir turi tą patį adresą, todėl galite siųsti operacijas visose jose tiesiog pakeisdami tinklą savo piniginės nustatymuose.

Tačiau ši sritis pereina prie išmaniųjų paskyrų, pagrįstų abstrakcija. Šios paskyros leidžia programiškai prie savo piniginės pridėti bet kokių norimų funkcijų:

• P256 parašai leidžia mūsų telefonuose naudoti saugius lustus sandoriams pasirašyti.

• Socialinio atsigavimo dėka galime įtraukti savo artimuosius kaip globėjus, įgaliotus susigrąžinti mūsų pinigines, pašalindami nesaugias pradines frazes.

• „Paymaster“ technologija leidžia mums sumokėti mokestį už dujas bet kokiu žetonu arba netgi priversti ką nors sumokėti mokestį už mus .

• Kai kvantiniai kompiuteriai pradeda laužyti klasikines parašo schemas, mes galime tiesiog pakeisti schemą savo AA piniginėse į kvantiškai saugią, nekurdami naujos piniginės.

  
  

Šį sąrašą galima tęsti be galo, nes paskyros abstrakcija iš esmės leidžia vykdyti vykdomąsias programas kaip pilnavertes pinigines. Tačiau visa tai kainuoja: negalima lengvai perkelti savo piniginės į kitą grandinę, nes, be lėšų perkėlimo per tiltą, reikia perskirstyti visą sąskaitą su visais raktais, globėjais ir nustatymais. Kai kuriais atvejais tai gali būti per sudėtinga arba net neįmanoma; tarkim, rinkiniuose, kurie nepalaiko P256 išankstinio kompiliavimo (ši parašo schema gali būti per brangi naudoti).

Štai kodėl aš sudariau tą protokolą. Iš esmės jūs turite AA paskyras daugelyje L2. Norėdami iš jų išsiųsti operaciją, turite patvirtinti savo ketinimą išsiųsdami maišą iš pagrindinės paskyros konkrečioje L2 į tas „mini paskyras“ per L1 tilto pranešimus. Tiesą sakant, tokiu būdu neatsikratysite kelių piniginių; tiesiog perkeliate visą patvirtinimo logiką į vieną „pagrindinę“ paskyrą.

Kita įdomi tokio protokolo detalė yra ta, kad jis leidžia sąveikauti ne tik su L2, bet ir su visomis L1 (šoninėmis grandinėmis), turinčiomis tiltus su Ethereum – galiu galvoti apie „Polygon PoS“, „Ronin“, „Gnosis“ ir „Avalanche“. Tačiau jis buvo sukurtas kaip į apibendrinimą orientuotas sąveikos protokolas , todėl tai tik įdomus technologinis faktas.

Nors projekto idėja buvo gana protinga, praktinis įgyvendinimas turėjo reikšmingą trūkumą: greitis . Visas dizainas remiasi kanoniniais susukamaisiais tiltais, sujungtais su Ethereum L1. Susukamieji tiltai yra ypatingi tuo, kad jie įrodo savo būseną išmaniosiomis sutartimis Ethereum, kad paveldėtų jos saugumą. Kaip jau tikriausiai žinote, optimistinis ir ZK patvirtinimas yra du populiariausi būdai tai padaryti.

Optimistinis patikrinimas veikia atidarant „iššūkio langą“, paprastai maždaug septynias dienas, per kurį varžovai gali išsiųsti sukčiavimo įrodymą , nurodantį bet kurią netinkamą operacijų paketo dalį. Jei šis įrodymas galioja, paketas iš naujo sutvarko savo blokų grandinę, kad ištrintų šią partiją. Praėjus septynioms dienoms be jokių sukčiavimo įrodymų, partija automatiškai laikoma galiojančia, o visi pranešimai ir išėmimai užbaigiami Ethereum.

Tikriausiai jau supratote. Dėl septynių dienų vėlavimo siųsti pranešimus į L1, kryžminių grandinių operacijų siuntimas iš optimistinio paketo yra baisi idėja. Kodėl? Na, ar lauksite DEX apsikeitimo savaitę? Kas atsitiks su kaina iki to laiko?

Daug geriau siųsti transakcijas tarp grandinių į optimistinį paketą. Nors OP Stack sekvenavimo priemonė laukia keletą blokų prieš apdorodama pranešimą, kad sumažintų pertvarkymų galimybę, kai kurioms užduotims jau yra priimtina laukti kelias minutes jūsų operacijos.

Be to, „Ethereum“ bendruomenė šiuo metu dirba su vieno lizdo baigtumu , todėl kiekvienas blokas bus baigtas atskirai, o kitas blokas taps negrįžtamas. Jį įdiegus, pranešimų siuntimas iš L1 į L2 užtruks apie 12 sekundžių.

Tokių paskyrų talpinimas ZK paketuose būtų geriau, bet vis tiek nelabai tinkamas naudoti. Kaip matome iš toliau pateiktos statistikos, „ZKsync Era“ baigiasi per 21 valandą, „Linea“ – per 5 valandas, „Starknet“ – per 9 valandas ir kt.

Bet kodėl taip yra? Argi ZK generavimas nėra greitas galinguose klasteriuose? Trumpai tariant, yra dvi problemos:

• Kai kurie ZK paketai, pvz., ZKsync Era, nustato vykdymo delsą, kad saugumo taryba turėtų laiko grąžinti kai kurias partijas, jei jų tikrinimo sistemoje būtų klaida. zkEVM yra tikrai sudėtingos technologijos, todėl dėl šio sudėtingumo tikimybiškai užkirsti kelią riktams naudojant kelias tikrinimo sistemas vienu metu dar neįmanoma.
• Nors ZK patikrinimas yra labai lengvas, palyginti su skaičiavimais, kuriuos jis įrodo, jo tikrinimas grandinėje vis tiek yra gana brangus. Priklausomai nuo tikrinimo sistemos, vienam patikrinimui gali prireikti iki milijono dujų. Atsižvelgiant į vidutinę 9 gwei dujų kainą ir šiandienines ETH kainas, vienas įrodymas kainuoja apie 30 USD tik už patikrinimą L1.
  • Šiuolaikiniai ZK paketai sumažina šias išlaidas generuodami vieną įrodymą daugeliui partijų kartą per tam tikrą laiką, tačiau tai sulėtina tilto baigtumo greitį. Sugeneravus partiją ir įrodant ją kiekviename bloke, gaunama 30 USD už bloką arba 216 000 USD per dieną . Esant 100 TPS, tai yra apie 0,025 USD už vieną operaciją tik už tikrinimo išlaidas. Taip pat turime sukurti įrodymą ir paskelbti partiją tinkle!

Valandą ar dvi laukti operacijos vis dar per ilgai. Ką galime dėl to padaryti?

Visų pirma, pamirškime mano aštuonis mėnesius trukusį hakatono projektą ir pabandykime panaikinti mentalinį modelį, kad kiekvieną operaciją reikia inicijuoti iš mūsų pagrindinės išmaniosios piniginės. Kodėl kiekviename pakete turime dalytis savo išmaniosios piniginės logika? Kodėl mums tiesiog nesugeneravus laikinų EOA, nesujungus lėšų iš mūsų pagrindinės išmaniosios piniginės, neatlikus tam tikro darbo, kurį norime atlikti, ir nepadėjus to, kas liko?

„My Clave“ (arba bet kokia jūsų naudojama išmanioji piniginė) turi „Secure Enclave“ pasirašymą ir socialinį atkūrimą, todėl visada galiu būti saugus dėl savo lėšų, net jei pamesiu telefoną. Ir kam rūpi, kas atsitiks su tomis laikinomis sąskaitomis? Aš jau padariau savo reikalus su jais; visos lėšos dabar yra mano klave.

Tačiau šis metodas turi esminę problemą: prielaida, kad negalite reguliariai naudoti tos pačios piniginės kitose grandinėse, labai apriboja užduočių, kurias galite atlikti jose, skaičių. Pavyzdžiui, jūs negalite:

• Sukurkite indėlį vietinėje skolinimo platformoje, nes negalite jo perkelti į pagrindinį tinklą (šiuo atveju „ZKsync Era“)
• Gaukite žetonų, kurie neturi pakeičiamo atitikmens jūsų pagrindiniame tinkle (pvz., jei jie yra sukurti tame tinkle).
• Dalyvaukite vietiniame DAO, nes jūsų balsai turi likti toje laikinoje paskyroje.

Iš esmės viskas, ką galite padaryti kaip vartotojas, tai paskirstyti lėšas keliems gavėjams, kiekvieną kartą nesujungdami, ir gauti didesnį likvidumą, kad būtų pakeistas žetonu, kurį galima grąžinti į pagrindinę grandinę.

Taigi, kad šios piniginės būtų naudingos, turime jas pasiekti naudodami tas pačias taisykles, kurias naudojame pagrindinėse išmaniosiose piniginėse – saugūs anklavai, socialinis atkūrimas ir t. t. Taigi, grįžtame prie anksčiau pateiktos idėjos ir jos neįgyvendinamumo. Tačiau yra įmanomų palengvinančių priemonių , kurios šioms mini sąskaitoms gali suteikti tik mūsų pagrindinės piniginės atkūrimo savybes:

Kuriame tas pačias mini paskyras, aprašytas anksčiau, tačiau leidžiame vienu raktu tiesiogiai iš jų siųsti operacijas. Mūsų pagrindinė piniginė dabar gali pakeisti šį raktą per L1 pagrįstą tiltą arba priversti mažąją paskyrą nuskaityti jį iš pagrindinės L2 būsenos. Tokiu būdu, pametus laikinąjį raktą, pagrindinė piniginė gali inicijuoti rakto pakeitimą per lėtą, bet atominį L1 pagrįstą tiltą.

Atomiškumas – veiksmo savybė, neleidžianti jam žlugti vykdant. Arba tai nebuvo inicijuota, arba buvo padaryta. L1 pagrįsti tiltai yra atominiai, nes išsiųstas pranešimas negali būti prarastas. Užsakymą, prieinamumą ir autentiškumą garantuoja „Ethereum L1“.

Tai daug geriau! Dabar įprastoms operacijoms reikia laiko tik žetonų sujungimui. Kai žetonai yra paskirties vietoje, operacijos siunčiamos taip greitai, lyg tai būtų jūsų pagrindinė grandinė. Pametus raktą, teks laukti nuo kelių valandų iki septynių dienų, priklausomai nuo tėvų piniginės grandinės, tačiau juo naudositės ne itin dažnai, todėl daugeliu atvejų kompromisas yra priimtinas. Be to, tai įmanoma įdiegti piniginėse net ir šiandien. Aš netgi sukūriau savo diegimą , bet jis jokiu būdu nėra saugus ar paruoštas gamybai ir yra skirtas tik vizualizacijai.

Panaši technika naudojama Web3 ateities sandorių prekybos platformose: jūs patvirtinate žetoną poromis (dažniausiai USDC) išmaniajai kontraktei ir priskiriate laikiną išlaidų raktą, kuris saugomas platformos priekinėje dalyje. Tai leidžia vartotojams greitai atlikti veiksmus nepasirašant kiekvieno veiksmo pagrindine pinigine. Jei pakeisite įrenginį arba išvalysite duomenis naršyklėje, galite tiesiog iš naujo priskirti raktą naudodami pagrindinę piniginę.

Tačiau, kaip ir viskas kriptovaliutų atveju, šis metodas taip pat nėra tobulas. Jis turi du trūkumus:

• Nors mini paskyros gali būti suderinamos su ERC-4337 ir todėl palaiko visas jo funkcijas, pvz., paketų sudarymą, mokėjimų mokėtojus, išlaidų limitus ir kt., šios funkcijos nebėra paveldimos iš pagrindinės paskyros. Tiesą sakant, pagrindinė paskyra veikia tik kaip vienas mini paskyros socialinio atkūrimo globėjas, tačiau globėjas yra pats naudotojas.
• Žetonų tiltas turi būti atliktas naudojant išorinius tiltus. Inicijuodami kryžminę grandinę, mes galime neštis savo žetonus su pranešimu, gaudami juos praktiškai 1:1 atominiu būdu. Tačiau naudojant šį sprendimą tai nebėra galimybė, todėl išorinis tiltas yra vienintelė greita galimybė.

Nors šiuolaikiniai tiltai gali pervesti lėšas per kelias sekundes , jie a) ima siaubingai didelį mokestį už didelius pervedimus , b) nėra atominiai ir nepaveldi Ethereum saugumo savybių. Ypač svarbu atkreipti dėmesį į blokų grandinės tiltų saugumo savybes .

Išorinių tiltų naudojimas žetonams perduoti yra šiek tiek priimtinas, kitaip nei naudojant juos perduodant pranešimus mini paskyroms valdyti. Priežastis yra jų blogiausi atvejai, greičiausiai dėl išpuolio prieš juos:

• Žetonų perjungimo atveju blogiausia, kas gali nutikti, yra tai, kad negausite tų žetonų, kuriuos atsiųsite. Tokiu atveju prarasite X žetonus, kuriuos norėjote perjungti, ir pereisite prie kito tilto.
• Naudojant kelių paskyrų pranešimus, blogiausia, kas gali nutikti, yra tai, kad visos jūsų mini paskyros gali būti pavogtos per tiltą perduodant apsimetinėjančius pranešimus. Tokiu atveju jūs prarasite savo pinigines visose grandinėse su visa verte, išskyrus pagrindinę.

Taigi, pasikliauti išoriniais tiltais žetonų tiltams yra beveik galimybė tol, kol nėra veiksmingo būdo juos sujungti atominiu būdu naudojant L1. Iš tikrųjų šią parinktį naudoja daugelis vartotojų, kurie šiandien bendrauja su kaupimo grandinėmis.

Tarkime, kad norime patvirtinti visas operacijas vienoje vietoje, pavyzdžiui, norėdami savaime perkelti žetonus iš vienos paskyros į kitą arba patikrinti parašus naudodami unikalų išankstinį kompiliavimą. Tokiu atveju susiduriame su lėtu šiandieninių ZK apibendrinimų baigtumu. Trumpam grįžkime ir pagalvokime, ką galima patobulinti naudojant ankstesnę techniką.

Kodėl suvyniojimų baigtumas yra lėtas? Kaip tikslą laikysime ZK apibendrinimus, nes optimistinių atveju priežastis jau akivaizdi:

• ZK proof sistemos visavertėms VM aplinkoms yra sudėtingos, ypač jei aplinka nėra draugiška ZK (EVM). Todėl yra didelė tikimybė, kad juose bus klaidų. Kelios tikrinimo sistemos gali tam užkirsti kelią, tačiau jas įdiegti labai sudėtinga, o kelių įrodymų generavimas vienai partijai gali būti per lėtas ir brangus. Kaip išeitis, sujungimo komandos įgalina vykdymo delsą, kuri leidžia joms atšaukti grandinę kritiniu atveju. Būtent tai sulėtina tilto baigtinumą kai kuriuose sujungimuose (pvz., ZKsync Era).
• Naujos būsenos pasiūlymas ir ZK jos įrodymas L1 yra gana brangios užduotys, todėl norėdami sumažinti išlaidas, apibendrinimo sekos tai atlieka kas kelias valandas, o ne kiekvieną bloką.

Tačiau yra išimtis; Scroll siūlo būseną maždaug kas minutę , bet a) įrodymo patvirtinimas vis tiek atliekamas kas kelias valandas, todėl jis lieka nepatvirtintas, ir b) Scroll yra vienas brangiausių šiandien naudojamų rinkinių .

Jei perfrazuotume dar paprasčiau, problemos kyla dėl išlaidų įrodinėjimo ir išlaidų patikrinimo. Pažvelkime į kiekvieną problemą ir jos sprendimo būdus.

Iš esmės mūsų užduotis yra priversti mūsų išmaniąją piniginę greitai sąveikauti su kitais paketais be papildomų pasitikėjimo prielaidų, atsirandančių dėl išorinių tiltų. Išmaniosios piniginės paprastai susideda iš kelių įprastų AA funkcijų – mokėjimų, socialinio atkūrimo, saugių anklavų, išlaidų limitų ir t. t. bei pagrindinės operacijos, leidžiančios iš jos siųsti grandinines operacijas.

Kodėl mums reikia pagrindinės operacijos, jei norime naudoti kitus savo piniginės paketus? Kadangi jis tikriausiai priglobtas daugiafunkciniame pakete – „Arbitrum“, „Base“, „ZKsync Era“ – ir mes taip pat norime bendrauti su vartotojais ir išmaniosiomis sutartimis.

Šiuo konkrečiu atveju būtų prasminga tiesiog naudoti išorinius žetonų tiltus. Tiesiog pakeiskite užduotį, pavyzdžiui, sąveika su dApp tame pačiame rinkinyje ir kita.

Dėl šio daugiafunkciškumo suvestinių tikrinimo sistema tampa sudėtingesnė. Patikrinti visos virtualios mašinos būseną su daugybe išmaniųjų sutarčių ir operacijų, vykstančių kas sekundę, yra gana sudėtinga užduotis. Norime atlikti dviejų tipų užduotis, kurioms apibendrinant reikalingas visiškai skirtingas funkcijų rinkinys: grandininei operacijai tai yra greitas L2 įtraukimas, maži L2 mokesčiai ir platus VM funkcionalumas, o kelių sudėtinių operacijų atveju. , tai greitas tilto užbaigimas.

Bet ką daryti, jei tiesiog atsikratytume virtualios mašinos ir sukurtume paketą, kuris gali tvarkyti tik išmaniąsias paskyras ir pranešimus kitiems L2? Vitalikas Buterinas pasiūlė panašią techniką beveik „Devconnect Istanbul“ metu, vadinamą „raktų saugyklos suvyniojimu“. Tai aptarsime toliau.

„Keystore“ apibendrinimas

Idėja yra sukurti ZK rinkinį, kuriame būtų galima saugoti tik paskyros raktus ir juos pakeisti naudojant kitą raktą. Šis paketas nustumia Merkle medžio šaknį, kuriame yra visi šie raktai į L1. Tada, kai norite išsiųsti operaciją iš vienos iš savo išmaniųjų paskyrų L2, sugeneruokite dabartinio rakto Merkle įrodymą, o paskyra patikrins jį pagal raktų saugyklos šaknį, esančią L1. Dabar ji žino jūsų raktą ir gali jį naudoti jūsų parašams patikrinti.

Toks apibendrinimas yra labai paprastas ir gali būti lengvai įdiegtos kelios tikrinimo sistemos, todėl jame saugomi raktai iš tikrųjų yra tokie pat saugūs kaip ir L1.

Be originalaus Vitalik dizaino, yra trys pagrindiniai raktų saugyklos rinkiniai:

• Scroll metodas yra saugoti raktų saugyklos duomenis L1, bet leisti juos atnaujinti iš savo zkEVM rinkinio. Tam jie pristato L1SLOAD išankstinį kompiliavimą, leidžiantį pigiai nuskaityti L1 saugyklą. Tada AA paskyros kitose L2 gali nuskaityti šiuos duomenis, kad sinchronizuotų savo konfigūraciją – raktus, globėjus ir kt.
• Bazinė komanda tiria techniką, kai L1 saugoma tik būsenos šaknis, bet operacijos seka atliekamos naudojant skambučių duomenis, todėl medį visada galima atkurti. Tikimasi, kad L2 sąskaitos gaus dabartinius raktus naudodami Merkle įrodymus.
• „Stackr“ dizainas yra labai panašus į „Base“ ar „Vitalik“, tačiau jis naudoja savo „mikroaplinkos“ sistemą su specializuotomis minimaliomis VM.

Paprastai tariant, jie skiriasi ne grandinės apdorojimui deleguotų užduočių skaičiumi (kitaip tariant, kiek dalykų yra L2) ir jų įgyvendinimo detales.

Šią idėją galime išplėsti tvarkydami ne tik raktus , bet ir visą išmaniosios paskyros logiką . Tai taip pat nebūtų daug sudėtingiau skaičiavimo požiūriu; iš esmės mums tereikia atlikti šias užduotis:

• Duomenų siuntimas į L1: raktų saugyklos rinkinio paskyros turi turėti galimybę pranešti L1 apie savo operacijos ketinimą. Visos operacijos saugoti L1 nebūtina; pakaktų kažko panašaus į Merkle medžio šaknį su visomis vartotojo operacijų maišomis. Tada viskas, ko reikia norint išsiųsti operaciją iš mini paskyros, yra nuskaityti šaknį iš paskirties L2 ir įrodyti, kad tam tikros AA operacijos iš tikrųjų buvo paprašyta iš pagrindinės paskyros.

• Parašo patikrinimai: vartotojas pasirašo vartotojo operacijos, kurią nori atlikti tam tikrame pakete, maišą. Raktų saugyklos suvestinė patikrina parašą, kad įrodytų ketinimą, ir prideda maišą prie medžio, kad vėliau būtų perkeltas į L1. Pakanka kelių parašo schemų, tokių kaip ECDSA , P256 ir kvantiškai saugios .

• Socialinis atkūrimas: nustatykite, kad kitos, tikslingai pasirinktos paskyros, vadinamos „globėjais“, balsuotų už pagrindinį vartotojo paskyros pakeitimą. Vartotojas gali nustatyti globėjus ir slenkstį bei paprašyti jų susigrąžinti rakto praradimo atveju. Taip pat galime įdiegti veto pagrįstą atkūrimo arba alternatyvias globėjų schemas, tokias kaip ZK-Email , ZK-OTP arba Web Proofs , kad išplėstume socialinį atkūrimą už apibendrinimo naudotojų ribų.

• Išlaidų taisyklės: Jei piniginė pavogta, globėjų kontroliuojamos išlaidų taisyklės gali labai sumažinti galimus nuostolius prieš vartotojui atgaunant piniginę. Ši funkcija taip pat naudinga taupant lėšas ar, pavyzdžiui, gaminant pinigines vaikams – tėvai gali atsiųsti pašalpą ir apriboti, kiek jos gali būti išleista, kad vaikas išmoktų taupyti.

• Žetonų likučiai: tai gali atrodyti nereikalinga, tačiau galimybė saugoti kriptovaliutą raktų saugyklos pakete žymiai padidina vartotojų turto saugumą, nes jis nėra atskirtas į kelias mini paskyras. Be to, ji suteikia daug funkcijų, kurios pagerina vartotojo patirtį:

• Mokėtojai: Apibendrinimas gali pasiūlyti nemokamus sandorius, kad pritrauktų naujus vartotojus arba leisti jiems sumokėti mokestį naudojant bet kurį žetoną, o ne tik ETH. Galima įdiegti ir sudėtingesnę mokėtojų logiką – pavyzdžiui, sekvencinė priemonė gali imti mokestį iš apsikeitimo kitoje grandinėje, kai ji grąžinama atgal į raktų saugyklos paketą.

• Vidiniai prieigos raktų pervedimai: ne tik akimirksniu siunčiamos lėšos tarp apibendrintų naudotojų, bet ir tiesioginiai pervedimai taip pat yra naudingi diegiant ketinimais pagrįstus tiltus su kitais apibendrinimais, kurių baigtumas per lėtas, kad būtų galima naudoti L1 perjungimui iš mini paskyros į pagrindinę paskyrą raktų saugyklos pakete. Tokiu būdu raktų saugyklos suvestinė iš esmės gali veikti kaip centras, leidžiantis pigiai perkelti žetonus tarp mini paskyrų dešimtyse įvairių L2.

  
  

Tokia sistema yra techniškai daug paprastesnė nei visa VM apibendrinant, todėl galima vienu metu generuoti kelių tikrinimo sistemų įrodymus, o įrodymų generavimo sudėtingumas vis tiek bus daug mažesnis.

Tačiau įrodymų tikrinimas vis dar yra problema. Kaip jau skaičiavome, jo dujų kaina gali siekti iki 1M dujų arba ~25-50$, priklausomai nuo dujų kainos. Ši kaina yra fiksuota ir nepriklauso nuo operacijų skaičiaus partijoje. Tai reiškia, kad jei sandorių bus per mažai, mokestis už kiekvieną operaciją gali būti labai didelis. Yra du pagrindiniai būdai, kaip sumažinti šias išlaidas:

Išlygintas sluoksnis

„Aligned“ yra „EigenLayer AVS“, kuri naudoja pakartotinius operatorius, kad pigiai patikrintų ZK įrodymus. Jei nesate susipažinę su EigenLayer, tai yra supaprastinta suvestinė, kaip sulygiuoti įrodymai tikrinami:

• Vartotojas siunčia patvirtinimo užklausą į tinklą ir sumoka už tai mokestį;

• Suderinti operatoriai, kurių kiekvienas yra „Ethereum“ tikrintuvas su susietais indėliais, patikrina savo mazgų įrodymą ir pasirašo, kad jis galioja;

• Kai 2/3 operatorių pasirašo už įrodymą, suvestinis parašas išsiunčiamas ir patikrinamas Ethereum L1.

• Jei negaliojantis įrodymas yra baigtas, jį pasirašę tikrintojai gali būti nubraukti, patvirtinant jį grandinėje. Tokiu būdu įrodymas įgyja ekonominį saugumą, lygų 2/3 viso Aligned operatorių akcijų paketo.

  
  

Šis metodas turi akivaizdų trūkumą – „Ethereum“ nebegarantuoja įrodymų galiojimo. Jei ritinio tilto TVL yra didesnis nei 2/3 viso Aligned akcijų paketo, pulti jį tampa pelninga. Ir kadangi mes kalbame apie 1-2 blokų baigtinumo delsą, negalime optimistiškai užkirsti kelio atakai.

Tačiau tai gali būti gana saugus pasirinkimas, kol rinkinys nėra per didelis. Kai taip atsitiks, dėl operacijos poreikio jau gali būti verta patikrinti L1 įrodymą. Remiantis dokumentais, ZK įrodymo patikrinimas naudojant Aligned kainuoja apie 3000 dujų, o tai yra beveik nemokama net Ethereum L1.

Įrodinėjimo agregavimo sluoksniai

Jei jums nepatogu įvesti sistemai papildomų pasitikėjimo prielaidų arba jūsų protokolas jau tapo per didelis, bet jo operacijų poreikis nėra, yra alternatyva.

ZK ir „rollup“ komandos neseniai pradėjo aktyviai dirbti su įrodymų sujungimo protokolais. Jei nesate labai susipažinę su ZK, įrodymų apibendrinimas yra tada, kai ZK įrodymas įrodo kito ZK įrodymo galiojimą (kuris savo ruožtu gali įrodyti kitą įrodymą ir pan.), tokiu būdu „sujungiant“ juos į vieną įrodymą ir iš esmės visas savo tikrinimo išlaidas perkelia į įrodinėjimo išlaidas. Belieka patikrinti vieną ZK įrodymą grandinėje ir įsitikinti, kad visi kiti ZK įrodymai, kuriuos jis įrodo, galioja. Fu!

ZK įrodymas grandinėje.

Įrodymų sumavimas prasmingas, kai tikrinimo išlaidos yra didesnės nei įrodymų sumavimo. Tai yra, agregavimas tampa pelningas, jei dešimties įrodymų įrodymo sukūrimo ir jo patikrinimo išlaidos yra mažesnės nei šių dešimties įrodymų patikrinimo atskirai. Tai dar naudingiau naudojant Ethereum L1, kurią labai riboja skaičiavimo pajėgumai. Priklausomai nuo tikrinimo sistemos, visame bloke gali būti tik apie 100 patikrinimų , neįskaitant visos kitos grandinės veiklos.

Paprastai yra dviejų tipų įrodymų agregavimo protokolai:

• Bendrosios paskirties (universalus) agregavimas: Tokie projektai paprastai palaiko kelis populiariausius ZK protokolus (Groth16, Halo2, Plonky), ant kurių yra pastatyta dauguma ZK grandinių ir imamas mokestis už apdorojimą. Tada dApps, kurioms reikia įrodymų, atskleidžia duomenis iš protokolo ir apdoroja juos pačios. Šiuo metu kuriama „Nebra“ universaliojo įrodymo agregavimo sistema atlieka būtent tai. „Aligned“ taip pat dirba su vadinamuoju „lėto režimo“ patvirtinimu , kuris iš tikrųjų taip pat yra įrodymų kaupimo sistema.
• Bendrų apibendrinimų tiltų agregavimas: kaip ir optimistinių apibendrinimų bendrai seka, ZK apibendrinimai su jų rietuvėmis veikia bendruose tiltuose su apibendrintais kiekvieno tilto ZK apibendrinimo būsenos įrodymais. Tai ne tik leidžia sinchroniškai komponuoti dėklo viduje, bendrai naudojamą seką, bet ir sumažina įrodymo tikrinimo išlaidas. Galbūt girdėjote apie „Polygon's AggLayer“ arba „ZKsync“ „ Hyperbridge“ , kurie yra bendri apibendrinimo tiltai, kurie veikia sujungiant įrodymus tilto viduje.

Universalių agregavimo sistemų pranašumai yra tai, kad jos yra projektų agnostinės ir specializuojasi tik pačiame agregavimo procese, o tai leidžia gana greitai patikrinti įrodymus ir mažomis sąnaudomis. Be to, tikėtina, kad jis neturės treniruočių ratų, nes trūksta tilto komponento.

Savo ruožtu, apibendrinti sudėtiniai tilteliai padeda raktų saugyklos duomenų rinkiniui sinchroniškai sukomponuoti su jau esama sudėtinio dėko. Pavyzdžiui, pagal L2BEAT 13 projektų šiuo metu yra sukurti naudojant „Polygon CDK“, o 11 – naudojant „ZK Stack“. Kai jie visi prisijungia prie bendro patikrinimo sujungimo tilto, sujungus raktų saugyklos paketą su vienu iš jų, bus sukurta sklandi sąveika su daugeliu L2 net neliečiant L1. Kad tai veiktų, tiltas turi palaikyti skirtingą būsenos perėjimo logiką savo L2, nes raktų saugyklos paketo logika skiriasi nuo kitų jame esančių L2.

Tačiau šiuos tiltus paprastai galima atnaujinti ir juos kontroliuoja DAO arba saugumo taryba. „Keystore“ sukaupimo projektams gali būti nepatogu atiduoti savo suverenitetą tilto, prie kurio jie yra prisijungę, operatoriams. Be to, tiltai gali sukelti vykdymo vėlavimą kaip atsargumo priemonę, skirtą treniruotėms, panašiai kaip dabar veikia „ZKsync Era“, o tai iš esmės sumažina visą šio raktų saugyklos sudėtinio dizaino efektyvumą.

Tokiu būdu raktų saugyklos rinkiniai, kaip ir bet kurie kiti ZK rinkiniai, gali sumažinti įrodymo tikrinimo išlaidas ir netgi suderinti tai su sinchroniniu komponavimu su jau esamu apibendrinimu.

Veiksmingas tikslais pagrįstas sujungimas naudojant „Keystore+“ paketus

Kaip aptarta anksčiau, tiltas iš L2 į L1 nėra vienintelė problema. Dauguma apibendrinamųjų sekų taip pat taiko uždelsimus perduodant pranešimus iš L1 į L2. Taip yra todėl, kad kai sukuriamas Ethereum blokas, jis dar nėra galutinis ir gali būti pakeistas per šiuos ~64 blokus (dvi epochos, apie 13 minučių). Šie pertvarkymai įvyksta dėl tinklo delsos, todėl kai kurie pasiūlymai tinkle pasirodo per vėlai, kai kai kurie mazgai jau laiko juos praleistais.

Nors dauguma reorgų yra ne giliau nei du blokai (septynių blokų reorgas net pasirodė žiniose prieš dvejus metus) , apibendrinimo komandos vis tiek nenori rizikuoti dėl praleistų pranešimų ir atidėti perjungimą iš L1. Kai kuriuose paketuose ( OP Stack , ZK Stack ) šie vėlavimai yra tik maždaug 1 minutė, bet gali būti iki 6 minučių, kaip Arbitrum , arba netgi paprašyti L1 baigtumo, kaip Linea .

„Ethereum“ bendruomenė aktyviai dirba su „Single-Slot Finality“ , kuri privers kiekvieną bloką užbaigti atskirai, o ne vieną kartą per epochą. Tačiau galime tvirtai pasakyti, kad kitam „Pectra“ atnaujinimui 2025 m. pirmąjį ketvirtį tai neplanuojama , taigi praeis mažiausiai metai, kol SSF bus įdiegta.

Jei komanda, įgyvendinanti šį išplėstinį raktų saugyklos paketo dizainą, nėra patenkinta tokia operacijos delsa, ji gali įgyvendinti anksčiau aprašytą palengvinimo priemonę. Kiekviena mini paskyra turi raktą, įgaliotą siųsti operacijas arba naudoja statinį raktų saugyklos raktą (pagal originalų Vitalik dizainą), tačiau paskyros valdymas vis dar yra pagrindinėje raktų saugyklos paskyroje. Įdiegus SSF L1, apibendrinimas gali pašalinti įgaliotus išlaidų raktus, o vartotojai gaus visas AA tinkinimo funkcijas be didelio greičio pablogėjimo.

Čia aš sutinku su Aleksu; 15 sekundžių delsa yra visiškai priimtina, ypač dėl to, kad po raktų saugyklos suvestinės operacijos užbaigimo L1 operacija yra tiesioginė. Jei kalbame apie žetonų pervedimus, gavėjų piniginės gali netgi įdiegti būseną „Laukiama“ vartotojo sąsajos lygiu.

Tačiau kryžminis prieigos raktų perkėlimas vis dar kelia problemų. Jei raktų saugyklos rinkinyje įdiegsime prieigos raktų saugyklas, prieigos raktų perkėlimas iš jo užtruks nuo 1 iki 15 minučių, atsižvelgiant į gavėjo paketą. Jei to nepadarysime, naudotojų likučių padalijimas į mažas sąskaitas keliose L2 gali kelti pavojų saugumui ir netgi užblokuoti tam tikrą turtą nelikvidžiose L2, o atjungimas nuo jų gali kainuoti per daug arba užtrukti per ilgai.

Kaip alternatyvą, galime integruoti ketinimais pagrįstą tiltą į apibendrinimą ir įdiegti jį visuose kituose paketuose arba net pakartotinai panaudoti esamą infrastruktūrą, pvz., su ERC-7683 suderinamus protokolus. Kitoje dalyje trumpai aptarsime ketinimų tiltus.

Kas yra ketinimais pagrįstas tiltas?

Dauguma esamų kryžminių grandinių tiltų yra pagrįsti pranešimų protokolais. Pavyzdžiui, Stargate naudoja LayerZero , kad perduotų pranešimus apie indėlius paskirties grandinėms, pasikliaudama juo kaip pasitikėjimo šaltiniu. Kai siunčiate žetonus per tokius tiltus, jie užrakina jūsų žetonus vienoje pusėje, o kitoje pusėje siunčia pranešimą apie jūsų įnašą, o ten esantis saugykla atrakina jums atitinkamą žetonų kiekį.

Tikslais pagrįsti tiltai , savo ruožtu, nesiunčia pranešimų tarp dviejų grandinių. Vietoj to, siunčiamos lėšos yra užrakintos saugykloje kaip „kryžminis užsakymas“, o tada kiekvienas gali užpildyti užsakymą išsiųsdamas pageidaujamą žetonų kiekį paskirties grandinėje. Tas, kuris įvykdo užsakymą, gali reikalauti užrakintų žetonų iš šaltinio grandinės, kai joje esantis saugykla gauna informaciją apie galutinę paskirties grandinės būseną ir gali patvirtinti perdavimą.

Tai gali įvykti laukiant paskirties grandinės tikslo (tilto) baigtumo arba naudojant kokį nors išorinį orakulo protokolą. Pavyzdžiui, „Across“ naudoja optimistinį UMA orakulą , kad gautų dar neužbaigtų L2 būseną.

Šiame scenarijuje Ethereum L1 naudojamas kaip pasitikėjimo šaltinis. Kai kuriuose protokoluose, pvz., „Across“, naudojami išoriniai orakulai. Esamuose projektuose tikrasis dizainas gali skirtis; rodoma tik bendra idėja.

Galime naudoti tą patį dizainą šiems išplėstiniams raktų saugykloms, kad įgyvendintume patikimą, greitą ir pigų dvipusį raktų saugyklos ir visų kitų L2 sujungimą. Greitas tilto baigtumas leidžia tyčia pagrįsti užsakymai iš kitų L2 beveik nemokami, nes įvykdymo patvirtinimas L2 užtrunka vos kelias minutes.

Užsakymai iš raktų saugyklos tikriausiai taip pat bus pigūs, nes L2 likvidumas per raktų saugyklą gali būti tiekiamas gana greitai. Tokiu būdu toks raktų saugyklos sudėtinis dizainas gali tapti tikslu pagrįsto tilto centru, leidžiančiu vartotojams siųsti operacijas akimirksniu, o ne per kelias minutes, o už sujungimą beveik nieko nemokant. Surinkimo komanda taip pat gali tiekti likvidumą perjungimui per raktų saugyklą santykiu 1:1, ir tai jiems nekainuotų daug.

Vieningas ENS pavadinimas visoms grandinėms

Įsivaizduokite, kad turite vieną vartotojovardas.eth , kuris sprendžia visas jūsų mini paskyras, nesvarbu, kurioje grandinėje yra gavėjas. Šis dizainas leidžia tai padaryti. Kaip?

Kadangi jau žinome savo pagrindinės raktų saugyklos paskyros adresą, galime naudoti kelių grandžių gamyklas ir CREATE2, kad mūsų mini paskyrų adresai būtų vienodi visose baitų kodo ekvivalentinėse EVM grandinėse, net įskaitant Ethereum L1. Tada ENS sprendiklyje nustatome vieningą adresą ir mūsų vardas veiks visuose EVM L2.

Tačiau yra du išskirtiniai atvejai:

• Bytecode neekvivalentiški EVM, pvz., ZK Stack. Jiems galime sugeneruoti pasirinktinį adresą pagal jų CREATE2 taisykles ir įtraukti jį į ENS su jų grandinės identifikatoriais pagal ENSIP-11 .
• Ne EVM L2, pvz., mūsų raktų saugykla. Jų logika yra tokia pati, bet vietoj to pridedame jų pasirinktinius adresus į ENS pagal ENSIP-9 .

Nors šis metodas yra labai patogus naudoti UX, jis naudoja daug brangių skaičiavimų ir saugojimo L1 sistemoje, nes vardai ir adresai saugomi L1 sprendiniuose. Šią problemą galima išspręsti naudojant CCIP Read , bet aš sugalvojau kitą, efektyvesnę grandinės skiriamosios gebos logiką:

Kiekviena raktų saugykloje esanti paskyra yra užregistruota ir indeksuojama pagal jos ENS vardo maišą (užregistruota vienu ENS pavadinimu su pasirinktiniu sprendimu). Kai išspręstas jo padomenis, sprendiklio sutartis patikrina, ar paskyra su tokia vardo maiša egzistuoja, ir naudoja vardų maišą CREATE2 pagrįstiems mini paskyros adresams generuoti.

Kai jie bus įdiegti, jie paprašys L1 raktų saugyklos duomenų, priklausančių namehash, su kuriuo jie buvo įdiegti. Tai gali būti pats operacijos tikslas arba tik dabartinis pasirašymo raktas, atsižvelgiant į raktų saugyklos diegimą. Tokiu būdu gauname raktų saugyklos paskyras, kurių kiekviena turi ENS pavadinimą, sprendžiamą jai pačiai ir savo mini paskyroms kiekviename rinkinyje. Šios mini paskyros, savo ruožtu, taip pat remsis šiuo ENS pavadinimu, kai bus patvirtinama operacija naudojant raktų saugyklos paketą.

**

„Keystore+“ rinkinių sekos nustatymo mechanizmai

Kadangi manoma, kad išplėstinio raktų saugyklos apibendrinimo tilto baigtumas yra keli L1 blokai, taip pat galime visiškai atsikratyti centralizuotų sekvencijų, paversdami ją pagrįstu apibendravimu. Kaip jau aptarėme anksčiau, vidutiniam vartotojui priimtina ~12 sekundžių operacijų sparta, tačiau dėl pagrįstos sekos paketas būtų daug atsparesnis cenzūrai ir pavieniams gedimo taškams.

Verta atsižvelgti į tai, kad naudojant pagrįstą seką, vidinės operacijos užtruks tiek pat ilgai, kiek išorinės (neįskaitant laiko pasiekti L2). Kai kurioms komandoms tai gali būti nepriimtina, nes dėl centralizuoto sekos visos vidaus operacijos atliekamos akimirksniu.

Alternatyvūs sudėtinio suderinamumo sprendimai arba: Kodėl nepaminėjau bendros sekos

Aš parašiau visą straipsnį apie ZK paketus ir ZK technologiją. Taip yra todėl, kad optimistiniai apibendrinimai iš esmės negali turėti greito objektyvumo baigtumo, o tokia savybė pasiekiama tik naudojant ZK. Šiandienos optimistiškai nusiteikę rinkiniai supranta savo uždarą padėtį ir aktyviai tiria galimybę integruoti į galiojimą orientuotus dizainus į savo krūvas, taigi, pavyzdžiui, neseniai užsimezgė Optimism ir RISC Zero partnerystė .

Optimistiškas dizainas yra iš esmės ribojantis, nes niekada nebus suderinamas su kitais paketais. Tačiau sąveika optimistiškoje ekosistemoje sparčiai vystosi. Pagrindinė technologija, leidžianti optimizuoti apibendrinimus tarpusavyje suderinti, yra bendras sekos nustatymas . Paprasčiau tariant, tai yra mechanizmas, pagal kurį sekvencinė programa vienu metu gali sudaryti kelių paketų paketą. Jei kuri nors operacija bet kuriame iš sekvenuotų rinkinių yra neteisinga, visa paketa gali būti užginčyta ir grąžinta.

Tai suteikia visoms šios „mega-partijos“ partijoms atominę savybę – arba visos partijos galioja, arba nė viena. Tai, savo ruožtu, leidžia atlikti atominį sinchroninį komponavimą partijos viduje. Atominis – nes niekas pakete negali būti netinkamas, jei jis yra galiojantis, sinchroniškas – nes visi pranešimai yra paketo viduje, kurį vienu metu apdoroja visi jos apibendrinimo mazgai.

Ši technologija iš esmės paverčia visus tam tikro optimistinio krūvo paketus į vieną didelį, susmulkintą rinkinį. Kodėl tik vienas krūvas, o ne visi? Nes tam, kad tai veiktų, ritinėliai turi būti sujungti su vienu tiltu. Kiekvienas krūvas turi savo tiltelį, ir nėra patikimo būdo, kaip vienu metu sudaryti paketus keliuose tiltuose. Tai reiškia, kad bendras sekos nustatymas leidžia „OP Mainnet“ sklandžiai sąveikauti su „Base“ ir „Zora“, bet ne su „Arbitrum“ ar „Metis“ ir atvirkščiai.

Toks konsolidavimas sukuria pavojingą situaciją ritininėje ekosistemoje. Nauji paketai turi galimybę prisijungti prie esamo krūvos ir būti integruoti su juo, bet ne su niekuo kitu, ARBA kurti ant ZK ir būti integruoti su bet kuo, išskyrus aukščiau esančią krūvą. Dabar tokio pasirinkimo nėra, nes bendras sekų nustatymas dar nepasiekiamas, o kiekvienas OP Stack arba Arbitrum Orbit paketas yra nepriklausomas ir turi savo tiltą. Tačiau, kai jie susijungs, jie sudarys du kietus organizmus ekosistemoje, kurių kiekvienas turi apie 40% visų L2s TVL .

„Gerai. Jei jiems priklausys didžioji dalis visos TVL, kodėl mums neatsikračius ZK ir nestačius ant jų?

Visų pirma, bendri sekvenatoriai yra didžiulis centralizacijos variklis. Jei paleidžiate OP Mainnet sekvencinį įrenginį, į paketus nebus įtrauktos operacijos iš kitų krūvoje esančių paketų; uždirbsite mažiau mokesčių ir galiausiai būsite pralenkti didelių komercinių sekvencijų, galinčių apdoroti visą krūvą savo partijomis.

Tačiau pati svarbiausia problema yra ta, kad tokiu atveju ruloninė ekosistema patenka į oligopolines imperijas , kurios siekia savo interesų, siekia įtvirtinti didesnę sostinės kontrolę ir slegia technologinę pažangą ekosistemoje. Tada turėtume susidoroti su „Ethereum“ sutriuškinimu į atskirtą sritį, kur svarbiausia yra PR ir tarprūšinė kova, o ne technologijos, kurios iš tikrųjų keičia pasaulį.

„Kurkite įrankius, o ne imperijas . Imperijos bando sugauti ir įgauti vartotoją siena aptvertame sode; įrankiai atlieka savo užduotį, bet kitaip sąveikauja su platesne atvira ekosistema“, – Vitalikas Buterinas

„Kuo bendrų tiltų agregavimas ZK yra geresnis nei optimistiškas bendras sekos nustatymas?

ZK apvyniojimų bendruose tiltuose seka gali būti atliekama nepriklausomai nuo kitų tilto sujungimų. Kiekvienas apibendrinimas gali turėti savo sekvenciją arba įgyvendinti bendrą seką. Apibendrinimą atlieka siūlytojai, kurie tvirtina gautą būsenos šaknį po visų sekvenuotų paketų ir įrodo tai naudodami ZK.

Be to, dėl santykinai greito objektyvo baigtumo ZK rinkiniuose jie neuždaromi jų ekosistemoje, nesvarbu, kokia ji auga ar centralizuota. Kai ZK yra išvystytas iki tokio lygio, kai galima greitai sugeneruoti didelius zkVM įrodymus kelioms tikrinimo sistemoms, visi ZK pagrįsti stulpeliai veiks beveik sklandžiai, kaip ir anksčiau aprašytas teorinis raktų saugyklos paketas siunčia operacijas visuose kituose rinkiniuose per L1. blokai.

„Bet kodėl vis dar egzistuoja optimistiški apibendrinimai, jei jie tokie blogi, o ZK rinkiniuose yra alternatyva?

Mūsų mokslininkų ir labai techninių žmonių bendruomenėje sutariama, kad ZK yra geriausias mastelio keitimo sprendimas. Nustebsite supratę, kad paprastiems naudotojams ir kūrėjams optimistiški sujungimai yra daug geresni nei ZK! Kaip taip?

Naudotojams : yra nusistovėjusi ekosistema. Visos platformos žino, kas yra Arbitrum ir Base, dApps visada turi didelį likvidumą, o UX yra kvapnus. Pabandykite pavadinti programą „Base“ ir akimirksniu prisiminsite „Friend.tech“ , „Farcaster“ , „Daimo“ , „Time.fun“ (dabar tik „Solana“), įvairias NFT kolekcijas, ZKP2P. Net Mirror iš pradžių palaikė tik OP Stack paketus, skirtus kalti. Pabandykite pavadinti programą „ZKsync Era“. Uhhh…

Kūrėjams : yra absoliutus Ethereum lygiavertiškumas, todėl visa Ethereum ir EVM šakių infrastruktūra veikia iš karto. Be to, dokumentacijoje skrupulingai apibrėžiami ir paaiškinami visi optimistinio suvyniojimo ypatumai ir įrankiai. Yra daugybė pamokų, kursų, maratonų, ryšių su kūrėjais ir pan.

Kita vertus, yra metų senumo zkEVM, iš kurių ne visi netgi turi baitų kodo ekvivalentą. Jie visi turi ilgą skirtumų ir sunkumų sąrašą, kai juos papildo. Dažniausiai jie yra prastai dokumentuoti ir labai priklauso nuo esamos infrastruktūros, kuri vos suderinama su tinklais. „Suderinamų“ VM auditas yra labai sunkus ir brangus, todėl jūs net neturite „ChatGPT“, ko paklausti.

Vartotojams: ZK paketai neturi ekosistemos. Nėra jokių naudojamų programų, nėra socialinių tinklų, nėra populiarių NFT ar žetonų, o visa veikla susiveda į žemdirbystę. Vos nerasite likvidumo poroms, kurios nepatenka į Ethereum ekosistemos dešimtuką, o DefiLlama pradeda rodyti ZK rinkinius, kai pavargsite slinkti.

„Tačiau optimistiniai sujungimai iš tikrųjų laimi dėl suderinamumo su esama infrastruktūra. Kaip ZK rollups gali juos įveikti?

Nereikia įvesti baitinio kodo ekvivalento arba blake2f išankstinio kompiliavimo, kad pritrauktumėte kūrėjus ir veiklą į savo platformą. Manoma, kad ZK paketai nėra geresni. Vietoj to, jų greitas baigtumas ir sąveikumas, visiškai horizontalus mastelio keitimas, iš esmės didesnis saugumas ir decentralizacija. Tai turėtų būti panaudota projektuose ZK paketų ekosistemoje, kad jie būtų naudingi ekosistemoje.

Šį straipsnį parašiau norėdamas sudaryti visą vaizdą apie visas šias technologijas, įskaitant ZK paketus, kurios atsirado ir išplėtotos šioje srityje per tą laiką, ir parodyčiau, kaip jas galima panaudoti sprendžiant svarbiausią šiandienos problemą šioje srityje – sujungimo sąveiką. Turime priimti ZK ir jo neribotus privalumus. Turime juos panaudoti savo pranašumui kurdami dalykus, kurie priartintų mus prie to, kad Web3 taptų vieta visiems pasaulio gyventojams.

Tai turbūt didžiausia palyginimo lentelė, kurią kada nors padariau. Nenuostabu – per pastaruosius metus Ethereum bendruomenė sugalvojo daug naujų idėjų ir technologijų, kurias galima lanksčiai derinti ir manipuliuoti, kad būtų sukurti visiškai nauji sprendimai, kurie išspręstų opiausias problemas šioje srityje, net ir naudojant esamas technologijas.

Taip, aš vis dar esu įsitikinęs, kad apibendrinimo sąveika yra pati opiausia problema, neleidžianti visam pasauliui prisijungti prie Web3. Mastelio keitimas nebėra toks skubus – 4844 leidžia atlikti iki tūkstančio operacijų per sekundę, palyginti su finansine veikla didžiausiose pasaulio šalyse; Netrukus pasirodys PeerDAS ir tai dar labiau padidins. Tačiau susiskaidymas vis dar kelia rimtą grėsmę Ethereum ekosistemai. Kad ir kokia didelė ji augtų, ekosistema turėtų jaustis ne kaip tuzinas skirtingų imperijų, o kaip vienas didelis mechanizmas. Tokie skirtingi, bet tokie identiški.

Mes nesame anksti, ir šis straipsnis turėtų jums tai parodyti. Turime panaudoti visas savo jėgas, kad sukurtume veikiančias sistemas, kurios padėtų sąveikauti milžiniškai L2 ekosistemai. Tai įmanoma dabar. Netrukus galėsite dalyvauti bet kuriame DAO ir siųsti bet kokį turtą ENS, kurio savininkas yra keli tūkstančiai kilometrų nuo jūsų. Geografinės sienos neturėtų būti pakeistos skaitmeninėmis.

Jei jums patiko šis darbas, sutinkate su jo baigiamuoju darbu, sužinojote ką nors naujo ar norite toliau skleisti šią žinią – pasidalykite ja socialiniuose tinkluose, palikite komentarus ir daugiau pakalbėkite apie apibendrinimo sąveikos svarbą. Ačiū, kad skaitėte.

Autoriaus pastaba: anksčiau čia buvo paskelbta šio straipsnio versija.