Uvod: Put do provjerljivosti

Osnovna prednost Web3 je provjerljivost – korisnici mogu provjeriti kako sustavi zapravo rade. Ova značajka objašnjava zašto mnogi unutar i izvan kripto industrije opisuju web3 kao korak prema transparentnijem i provjerljivijem internetu.

Za razliku od Web2 platformi poput Facebooka ili Instagrama, gdje algoritmi i pravila ostaju neprozirni čak i kad su dokumentirani, kripto protokoli su dizajnirani za potpunu reviziju. Čak i ako se dijele, nemate mogućnost provjeriti radi li platforma kako je navedeno. Ovo je suprotno od kripto, gdje je svaki protokol dizajniran da bude što je moguće više moguće revidirati - ili se barem očekuje da bude.

Danas ćemo istražiti “The Verge”, odjeljak iz Vitalikove nedavno objavljene serije od šest dijelova o budućnosti Ethereuma , kako bismo analizirali korake koje Ethereum poduzima prema postizanju provjerljivosti, održivosti i skalabilnosti u budućnosti. Pod naslovom "The Verge", raspravljat ćemo o tome kako se blockchain arhitekture mogu učiniti provjerljivijima, inovacijama koje ove promjene donose na razini protokola i kako korisnicima pružaju sigurniji ekosustav. Počnimo!

Što znači "provjerljivost"?

Web2 aplikacije funkcioniraju kao "crne kutije" – korisnici mogu vidjeti samo svoje unose i rezultirajuće izlaze, bez uvida u to kako aplikacija zapravo radi. Nasuprot tome, protokoli za kriptovalute svoj izvorni kod obično čine javno dostupnim ili to barem planiraju učiniti. Ova transparentnost ima dvije svrhe: omogućuje korisnicima izravnu interakciju s kodom protokola ako to žele i pomaže im da razumiju kako točno sustav funkcionira i koja pravila njime upravljaju.

"Decentralizirajte što možete, provjerite ostalo."

Provjerljivost osigurava da su sustavi odgovorni i, u mnogim slučajevima, jamči da protokoli funkcioniraju kako je predviđeno. Ovo načelo naglašava važnost minimiziranja centralizacije, jer često dovodi do neprozirnih, neodgovornih struktura u kojima korisnici ne mogu provjeriti operacije. Umjesto toga, trebali bismo težiti decentralizaciji što je više moguće i učiniti preostale elemente provjerljivima i odgovornima tamo gdje decentralizacija nije izvediva.

Čini se da se zajednica Ethereuma slaže s ovom perspektivom, budući da plan uključuje prekretnicu (nazvanu "The Verge") čiji je cilj učiniti Ethereum provjerljivijim. Međutim, prije nego što zaronimo u The Verge, moramo razumjeti koje aspekte blockchaina treba provjeriti i koji su dijelovi ključni iz perspektive korisnika.

Blockchaini u biti funkcioniraju kao globalni satovi. U distribuiranoj mreži s oko 10 000 računala može proći dosta vremena da se transakcija proširi od izvornog čvora do svih ostalih čvorova. Iz tog razloga čvorovi diljem mreže ne mogu odrediti točan redoslijed transakcija – je li jedna stigla prije ili poslije druge – budući da imaju samo vlastite subjektivne perspektive.

Budući da je redoslijed transakcija važan, blockchain mreže koriste specijalizirane metode zvane " konsenzusni algoritmi " kako bi osigurale da čvorovi ostanu sinkronizirani i obrađuju sekvence transakcija istim redoslijedom. Iako čvorovi ne mogu globalno odrediti redoslijed transakcija, mehanizmi konsenzusa omogućuju svim čvorovima da se dogovore o istom slijedu, omogućujući mreži da funkcionira kao jedno, kohezivno računalo.

Osim sloja konsenzusa, postoji i izvršni sloj koji postoji u svakom blockchainu. Izvršni sloj oblikovan je transakcijama koje korisnici žele izvršiti. Nakon što su transakcije uspješno raspoređene konsenzusom, svaka se transakcija mora primijeniti na trenutno stanje na izvršnom sloju. Ako se pitate "Što je država?", vjerojatno ste vidjeli blockchaine u usporedbi s bazama podataka—ili točnije, s bankovnom bazom podataka jer blockchaini, kao i banke, održavaju evidenciju svačijih stanja.

Ako imate 100 USD u stanju koje zovemo "S" i želite poslati 10 USD nekom drugom, vaš saldo u sljedećem stanju, "S+1", bit će 90 USD. Ovaj proces primjene transakcija za prelazak iz jednog stanja u drugo je ono što nazivamo STF (State Transition Function) .

U Bitcoinu, STF je prvenstveno ograničen na promjene stanja, što ga čini relativno jednostavnim. Međutim, za razliku od Bitcoina, Ethereumov STF mnogo je složeniji jer je Ethereum potpuno programabilni blockchain s izvršnim slojem koji može pokretati kod.

U blockchainu postoje tri temeljne komponente koje trebate - ili možete - provjeriti:

1. Stanje : možda želite pročitati dio podataka na blockchainu, ali nemate pristup stanju budući da ne pokrećete puni čvor . Stoga podatke tražite putem RPC (Remote Procedure Call) pružatelja usluga kao što su Alchemy ili Infura. Međutim, morate provjeriti da RPC pružatelj nije mijenjao podatke.
2. Izvršenje : Kao što je ranije spomenuto, lanci blokova koriste STF. Morate potvrditi da je prijelaz stanja izvršen ispravno—ne na bazi po transakciji, već na bazi blok po blok.
3. Konsenzus : entiteti trećih strana, poput RPC-ova, mogu vam pružiti valjane blokove koji još nisu uključeni u blockchain. Dakle, morate potvrditi da su ti blokovi prihvaćeni putem konsenzusa i dodani u blockchain.

ja

Ako ovo djeluje zbunjujuće ili nejasno, ne brinite. Detaljno ćemo proći kroz svaki od ovih aspekata. Počnimo s time kako provjeriti stanje blockchaina!

Kako provjeriti stanje blockchaina?

“Stanje” Ethereuma odnosi se na skup podataka pohranjenih u blockchainu u bilo kojem trenutku. To uključuje stanja računa (ugovorni računi i računi u vanjskom vlasništvu ili EOA-ovi), kod pametnog ugovora, pohranu ugovora i još mnogo toga. Ethereum je stroj temeljen na stanju jer transakcije obrađene u Ethereum Virtual Machine (EVM) mijenjaju prethodno stanje i proizvode novo stanje.

Svaki Ethereum blok sadrži vrijednost koja sažima trenutno stanje mreže nakon tog bloka: stateRoot . Ova je vrijednost kompaktni prikaz cijelog stanja Ethereuma, a sastoji se od hasha od 64 znaka.

Kako svaka nova transakcija mijenja stanje, stateRoot zabilježen u sljedećem bloku ažurira se u skladu s tim. Za izračun ove vrijednosti Ethereum validatori koriste kombinaciju Keccak hash funkcije i podatkovne strukture koja se naziva Merkleovo stablo za organiziranje i sažetak različitih dijelova stanja.

Hash funkcije su jednosmjerne funkcije koje pretvaraju ulaz u izlaz fiksne duljine. U Ethereumu se hash funkcije poput Keccak koriste za generiranje sažetaka podataka, služeći kao neka vrsta otiska prsta za unos. Hash funkcije imaju četiri temeljna svojstva:

1. Determinizam : isti ulaz uvijek će proizvesti isti izlaz.
2. Fiksna duljina izlaza : Bez obzira na duljinu ulaza, duljina izlaza je uvijek fiksna.
3. Jednosmjerno svojstvo : Praktički je nemoguće izvesti izvorni ulaz iz izlaza.
4. Jedinstvenost : Čak i mala promjena u ulazu proizvodi potpuno drugačiji izlaz. Stoga se određeni ulaz preslikava u praktički jedinstven izlaz.

Zahvaljujući ovim svojstvima, Ethereum validatori mogu izvesti STF (State Transition Function) za svaki blok—izvršavajući sve transakcije u bloku i primjenjujući ih na stanje—i zatim provjeriti odgovara li stanje navedeno u bloku stanju dobivenom nakon STF-a. . Ovaj proces osigurava da je predlagatelj bloka postupio pošteno, što ga čini jednom od ključnih odgovornosti validatora.

Međutim, Ethereum validatori ne hashiraju cijelo stanje izravno kako bi pronašli njegov sažetak. Zbog jednosmjerne prirode hash funkcija, izravno raspršivanje stanja eliminiralo bi provjerljivost, budući da bi jedini način za reprodukciju hashiranja bio posjedovanje cijelog stanja.

Budući da je Ethereumovo stanje veličine terabajta, nepraktično je pohranjivati cijelo stanje na svakodnevnim uređajima poput telefona ili osobnih računala. Iz tog razloga, Ethereum koristi strukturu stabla Merkle za izračunavanje stateRoot-a, čuvajući provjerljivost stanja što je više moguće.

Merkle stablo je kriptografska struktura podataka koja se koristi za sigurnu i učinkovitu provjeru integriteta i ispravnosti podataka. Merkle stabla izgrađena su na hash funkcijama i organiziraju hashove skupa podataka hijerarhijski, omogućujući provjeru integriteta i točnosti tih podataka. Ova struktura stabla sastoji se od tri vrste čvorova:

1. Lisni čvorovi : Ovi čvorovi sadrže hashove pojedinačnih dijelova podataka i nalaze se na donjoj razini stabla. Svaki listni čvor predstavlja hash određenog podatka u Merkleovom stablu.
2. Čvorovi ogranaka : Ovi čvorovi sadrže kombinirane hashove svojih podređenih čvorova. Na primjer, u binarnom Merkleovom stablu (gdje je N=2), hashovi dva čvora djeteta se spajaju i ponovno raspršuju kako bi se proizveo hash čvora grane na višoj razini.
3. Korijenski čvor : Korijenski čvor je na najvišoj razini Merkleovog stabla i predstavlja kriptografski sažetak cijelog stabla. Ovaj čvor se koristi za provjeru integriteta i ispravnosti svih podataka unutar stabla.

Ako se pitate kako izgraditi takvo stablo, to uključuje samo dva jednostavna koraka:

• Stvaranje lisnog čvora : svaki dio podataka obrađuje se pomoću hash funkcije, a rezultirajući hashovi tvore lisne čvorove. Ovi se čvorovi nalaze na najnižoj razini stabla i predstavljaju kriptografski sažetak podataka.

• Kombinirajte i raspršite : Raspršivanja lisnih čvorova grupiraju se (npr. u parovima) i kombiniraju, nakon čega slijedi raspršivanje. Ovaj proces stvara čvorove grananja na sljedećoj razini. Isti postupak se ponavlja za čvorove grananja dok ne ostane samo jedan hash.

Konačni hash dobiven na vrhu stabla naziva se Merkleov korijen. Merkleov korijen predstavlja kriptografski sažetak cijelog stabla i omogućuje sigurnu provjeru integriteta podataka.

Kako koristimo Merkle korijene za provjeru stanja Ethereuma?

Merkleovi dokazi omogućuju Verifikatoru da učinkovito potvrdi valjanost određenih dijelova podataka pružanjem niza hash vrijednosti koje stvaraju put od ciljanih podataka (lisni čvor) do Merkleovog korijena pohranjenog u zaglavlju bloka. Ovaj lanac srednjih raspršivanja omogućuje Verifikatoru da potvrdi autentičnost podataka bez potrebe raspršivanja cijelog stanja.

Počevši od specifične podatkovne točke, Verifier ga kombinira sa svakim "bratskim" hashom navedenim u Merkle Proof-u i hashira ih korak po korak prema stablu. Ovaj proces se nastavlja sve dok se ne proizvede jedan hash. Ako se ovaj izračunati hash podudara s pohranjenim Merkleovim korijenom, podaci se smatraju važećim; u protivnom Verifikator može utvrditi da podaci ne odgovaraju navedenom stanju.

Primjer: Provjera podatkovne točke s Merkleovim dokazom

Recimo da smo primili podatke #4 od RPC-a i želimo provjeriti njihovu autentičnost koristeći Merkleov dokaz. Da bi to učinio, RPC bi osigurao skup hash vrijednosti duž putanje potrebnog za postizanje Merkleovog korijena. Za Podatke 4, ovi srodni hashovi bi uključivali Hash #3, Hash #12 i Hash #5678.

1. Započnite s podacima 4 : prvo raspršujemo podatke #4 da bismo dobili hash #4.
2. Kombinacija s braćom i sestrama : Zatim kombiniramo Hash #4 s Hash #3 (njegov brat na razini lista) i raspršujemo ih zajedno da proizvedemo Hash #34.
3. Pomicanje gore po stablu : Zatim, uzimamo Hash #34 i kombiniramo ga s Hash #12 (njegov brat na sljedećoj razini) i raspršujemo ih da dobijemo Hash #1234.
4. Završni korak : Na kraju kombiniramo hash #1234 s hashom #5678 (posljednji navedeni brat) i zajedno ih hashiramo. Rezultirajući hash trebao bi odgovarati Merkleovom korijenu (Hash #12345678) pohranjenom u zaglavlju bloka.

Ako se izračunati Merkleov korijen podudara s korijenom stanja u bloku, potvrđujemo da je podatak #4 doista valjan unutar ovog stanja. Ako nije, znamo da podaci ne pripadaju navedenom stanju, što ukazuje na potencijalno petljanje. Kao što možete vidjeti, bez davanja hashova svih podataka ili zahtjeva od Verifikatora da rekonstruira cijelo Merkleovo stablo ispočetka, Prover može dokazati da Podaci #4 postoje u stanju i da nisu promijenjeni tijekom svog putovanja—upotrebom samo tri hashovi. Ovo je glavni razlog zašto se Merkleovi dokazi smatraju učinkovitima.

Iako su Merkle Trees nedvojbeno učinkoviti u pružanju sigurne i učinkovite provjere podataka u velikim blockchain sustavima poput Ethereuma, jesu li doista dovoljno učinkoviti? Da bismo odgovorili na ovo pitanje, moramo analizirati kako izvedba i veličina Merkleovog stabla utječu na odnos Prover-Verifikator.

Dva ključna čimbenika koji utječu na performanse Merkle stabla

1. Faktor grananja : Broj podređenih čvorova po grani.
2. Ukupna veličina podataka : veličina skupa podataka koji je predstavljen u stablu.

Učinak faktora grananja:

Poslužimo se primjerom kako bismo bolje razumjeli njegov utjecaj. Faktor grananja određuje koliko grana izlazi iz svakog čvora u stablu.

• Faktor malog grananja (npr. binarno Merkleovo stablo) : Ako se koristi binarno Merkleovo stablo (faktor grananja 2), veličina dokaza je vrlo mala, što postupak verifikacije čini učinkovitijim za Verifikatora. Sa samo dvije grane na svakom čvoru, Verifier treba obraditi samo jedan srodni hash po razini. To ubrzava provjeru i smanjuje računalno opterećenje. Međutim, smanjeni faktor grananja povećava visinu stabla, zahtijevajući više operacija raspršivanja tijekom izgradnje stabla, što može biti opterećenje za validatore.
• Veći faktor grananja (npr. 4) : Veći faktor grananja (npr. 4) smanjuje visinu stabla, stvarajući kraću i širu strukturu. To omogućuje punim čvorovima da brže konstruiraju stablo budući da je potrebno manje hash operacija. Međutim, za Verifikatora to povećava broj srodnih hashova koje moraju obraditi na svakoj razini, što dovodi do veće veličine dokaza. Više hashova po koraku provjere također znači veće troškove računanja i propusnosti za Verifikatora, učinkovito prebacujući teret s validatora na verifikatore.

Učinak ukupne veličine podataka

Kako Ethereum blockchain raste, sa svakom novom transakcijom, ugovorom ili korisničkom interakcijom koja se dodaje skupu podataka, Merkleovo stablo se također mora širiti. Ovaj rast ne samo da povećava veličinu stabla, već također utječe na veličinu dokaza i vrijeme verifikacije.

• Puni čvorovi moraju redovito obrađivati i ažurirati rastući skup podataka kako bi održali Merkleovo stablo.
• Verifikatori, zauzvrat, moraju potvrditi dulje i složenije dokaze kako skup podataka raste, što zahtijeva dodatno vrijeme obrade i propusnost.

Ova rastuća veličina podataka povećava potražnju za punim čvorovima i verifikatorima, što otežava učinkovito skaliranje mreže. Ukratko, iako Merkle Trees nude određeni stupanj učinkovitosti, nisu optimalno rješenje za Ethereumov skup podataka koji neprestano raste. Iz tog razloga, tijekom faze The Verge , Ethereum ima za cilj zamijeniti Merkle stabla s učinkovitijom strukturom poznatom kao Verkle stabla . Verkle Trees imaju potencijal za isporuku manjih veličina dokaza uz zadržavanje iste razine sigurnosti, čineći proces verifikacije održivijim i skalabilnijim i za Provere i za Verifikatore.

The Verge: Revolucioniranje provjerljivosti u Ethereumu

Verge je razvijen kao prekretnica u Ethereumovu planu puta usmjerenom na poboljšanje provjerljivosti, jačanje decentralizirane strukture lanca blokova i povećanje sigurnosti mreže. Jedan od primarnih ciljeva mreže Ethereum je omogućiti svima da jednostavno pokrenu validator za provjeru lanca, stvarajući strukturu u kojoj je sudjelovanje otvoreno za sve bez centralizacije.

Pristupačnost ovog procesa verifikacije jedna je od ključnih značajki koja razlikuje blockchaine od centraliziranih sustava. Iako centralizirani sustavi ne nude mogućnosti provjere, ispravnost blockchaina u potpunosti je u rukama njegovih korisnika. Međutim, da bi se održala ova sigurnost, pokretanje validatora mora biti dostupno svima - izazov koji je, prema trenutnom sustavu, ograničen zbog zahtjeva za pohranom i računanjem.

Od prelaska na konsenzusni model Proof-of-Stake s The Merge , validatori Ethereuma imaju dvije primarne odgovornosti:

1. Osiguravanje konsenzusa : Podržavanje ispravnog funkcioniranja i probabilističkih i determinističkih protokola konsenzusa i primjena algoritma za izbor vilice.
2. Provjera točnosti bloka : Nakon izvršavanja transakcija u bloku, provjera podudara li se korijen rezultirajućeg stabla stanja s korijenom stanja koji je deklarirao predlagač.

Da bi ispunili drugu odgovornost, validatori moraju imati pristup stanju prije bloka. To im omogućuje izvršavanje transakcija bloka i izvođenje naknadnog stanja. Međutim, ovaj zahtjev nameće veliki teret validatorima, budući da moraju podnijeti značajne zahtjeve za pohranu.

Dok je Ethereum dizajniran da bude izvediv i troškovi pohrane globalno se smanjuju, problem je manje u cijeni, a više u oslanjanju na specijalizirani hardver za validatore. The Verge ima za cilj prevladati ovaj izazov stvaranjem infrastrukture u kojoj se potpuna provjera može izvršiti čak i na uređajima s ograničenom pohranom, kao što su mobilni telefoni, novčanici preglednika, pa čak i pametni satovi, omogućujući validatorima rad na tim uređajima.

Prvi korak u postizanju provjerljivosti: učinkovita provjera stanja

Prijelaz na Verkle Tree s ključni je dio ovog procesa. U početku se The Verge usredotočio na zamjenu Ethereumovih struktura Merkle Tree s Verkle Trees. Primarni razlog za usvajanje Verkleovih stabala je taj što Merkleova stabla predstavljaju značajnu prepreku provjerljivosti Ethereuma. Iako Merkleova stabla i njihovi dokazi mogu učinkovito funkcionirati u normalnim scenarijima, njihova se izvedba drastično smanjuje u najgorim scenarijima .

Prema Vitalikovim izračunima, prosječna veličina dokaza je oko 4 KB , što zvuči prihvatljivo. Međutim, u najgorem slučaju, veličina dokaza može narasti na 330 MB . Da, dobro ste pročitali—330 MB.

Ekstremna neučinkovitost Ethereumovih Merkleovih stabala u najgorem slučaju proizlazi iz dva glavna razloga:

1. Upotreba Hexary Trees : Ethereum trenutno koristi Merkle Trees s faktorom grananja 16. To znači da provjera jednog čvora zahtijeva pružanje preostalih 15 hasheva u grani. S obzirom na veličinu stanja Ethereuma i broj podružnica, to stvara značajan teret u najgorem slučaju.

2. Nemerkelizacija koda : Umjesto uključivanja koda ugovora u strukturu stabla, Ethereum jednostavno hashira kod i koristi dobivenu vrijednost kao čvor. S obzirom na to da je maksimalna veličina ugovora 24 KB , ovaj pristup predstavlja značajno opterećenje za postizanje pune provjerljivosti.

Veličina dokaza izravno je proporcionalna faktoru grananja. Smanjenje faktora grananja smanjuje probnu veličinu. Kako bi riješio te probleme i poboljšao najgore moguće scenarije, Ethereum bi se mogao prebaciti s Hexary Trees na Binary Merkle Trees i započeti merklizing kodova ugovora. Ako se faktor grananja u Ethereumu smanji sa 16 na 2, a kodovi ugovora također budu merklizirani, maksimalna veličina dokaza mogla bi se smanjiti na 10 MB .

Iako je ovo značajno poboljšanje, važno je napomenuti da se ovaj trošak odnosi na provjeru samo jednog podatka . Čak bi i jednostavna transakcija kojom se pristupa većem broju podataka zahtijevala veće dokaze. S obzirom na broj transakcija po bloku i stanje Ethereuma koji kontinuirano raste, ovo rješenje, iako bolje, još uvijek nije u potpunosti izvedivo.

Iz tih je razloga Ethereum zajednica predložila dva različita rješenja za rješavanje problema:

1. Verkle Drveće
2. STARK dokazi + binarna Merkleova stabla

Verkle stabla i vektorske obveze

Verkle stabla , kao što ime sugerira, su strukture stabala slične Merkleovim stablima . Međutim, najznačajnija razlika leži u učinkovitosti koju nude tijekom procesa verifikacije. U Merkle Trees , ako grana sadrži 16 dijelova podataka i želimo provjeriti samo jedan od njih, mora se osigurati i hash lanac koji pokriva ostalih 15 dijelova. Ovo značajno povećava računalni teret verifikacije i rezultira velikim veličinama dokaza.

Nasuprot tome, Verkleova stabla koriste specijaliziranu strukturu poznatu kao " Vektorske obveze temeljene na eliptičkoj krivulji ", točnije, vektorsku predanost temeljenu na Argumentu proizvoda (IPA) . Vektor je u biti popis elemenata podataka organiziranih u određenom nizu. Stanje Ethereuma može se smatrati vektorom: strukturom u kojoj su brojni dijelovi podataka pohranjeni određenim redoslijedom, pri čemu je svaki element ključan. Ovo stanje obuhvaća različite podatkovne komponente kao što su adrese, kodovi ugovora i informacije o pohrani, pri čemu redoslijed tih elemenata igra ključnu ulogu u pristupu i provjeri.

Vektorske obveze su kriptografske metode koje se koriste za dokazivanje i provjeru podatkovnih elemenata unutar skupa podataka. Ove metode omogućuju provjeru postojanja i redoslijeda svakog elementa u skupu podataka istovremeno. Na primjer, Merkleovi dokazi , koji se koriste u Merkleovim stablima, također se mogu smatrati oblikom predanosti vektora . Dok Merkle stabla zahtijevaju sve relevantne hash lance za provjeru elementa, struktura inherentno dokazuje da su svi elementi vektora povezani u određenom nizu.

Za razliku od Merkleovih stabala, Verkleova stabla koriste vektorske obveze temeljene na eliptičnim krivuljama koje nude dvije ključne prednosti:

• Obveze vektora temeljene na eliptičkoj krivulji eliminiraju potrebu za detaljima elemenata koji nisu podaci koji se provjeravaju . U Merkleovim stablima s faktorom grananja 16, provjera jedne grane zahtijeva pružanje ostalih 15 hasheva. S obzirom na golemu veličinu Ethereumovog stanja, koje uključuje mnoge grane, to stvara značajnu neučinkovitost. Međutim, vektorske obveze temeljene na eliptičkoj krivulji uklanjaju ovu složenost, omogućujući verifikaciju s manje podataka i računalnog napora.
• Putem višestrukih dokaza, dokazi generirani vektorskim obvezama temeljenim na eliptičkoj krivulji mogu se komprimirati u jedan dokaz konstantne veličine . Stanje Ethereuma nije samo veliko, već i kontinuirano raste, što znači da se broj grana koje trebaju provjeru za pristup Merkle Rootu s vremenom povećava. Međutim, s Verkleovim stablima možemo "komprimirati" dokaze za svaku granu u jedan dokaz konstantne veličine koristeći metodu detaljno opisanu u članku Dankrada Feista . To omogućuje Verifikatorima da provjere cijelo stablo s jednim malim dokazom umjesto da provjeravaju svaku granu pojedinačno. To također znači da Verkle stabla nisu pod utjecajem rasta stanja Ethereuma.

Ove značajke vektorskih obveza temeljenih na eliptičkoj krivulji značajno smanjuju količinu podataka potrebnih za verifikaciju, omogućujući Verkle Treesu da proizvede male dokaze konstantne veličine čak i u najgorem slučaju. Ovo minimalizira opterećenje podataka i vrijeme verifikacije, poboljšavajući učinkovitost velikih mreža poput Ethereuma. Kao rezultat toga, upotreba vektorskih obveza temeljenih na eliptičnim krivuljama u Verkleovim stablima omogućuje upravljivije i učinkovitije rukovanje stanjem širenja Ethereuma.

Kao i sve inovacije, Verkle Trees imaju svoja ograničenja. Jedan od njihovih glavnih nedostataka je to što se oslanjaju na kriptografiju eliptične krivulje, koja je ranjiva na kvantna računala . Kvantna računala posjeduju daleko veću računalnu snagu od klasičnih metoda, što predstavlja značajnu prijetnju kriptografskim protokolima temeljenim na eliptičnim krivuljama. Kvantni algoritmi potencijalno bi mogli slomiti ili oslabiti ove kriptografske sustave, izazivajući zabrinutost oko dugoročne sigurnosti Verkleovih stabala.

Iz tog razloga, iako Verkle Trees nude obećavajuće rješenje za apatridnost, oni nisu konačno rješenje. Međutim, osobe poput Dankrada Feista naglasile su da, iako je potrebno pažljivo razmatranje pri integraciji kvantno otporne kriptografije u Ethereum, vrijedi napomenuti da KZG obveze koje se trenutno koriste za blobove u Ethereumu također nisu kvantno otporne. Stoga Verkle Trees mogu poslužiti kao privremeno rješenje, pružajući mreži dodatno vrijeme za razvoj robusnijih alternativa.

STARK dokazi + binarna Merkleova stabla

Verkle stabla nude manje veličine dokaza i učinkovite procese verifikacije u usporedbi s Merkle stablima, što olakšava upravljanje stalno rastućim stanjem Ethereuma. Zahvaljujući vektorskim obvezama temeljenim na eliptičnim krivuljama , dokazi velikih razmjera mogu se generirati sa znatno manje podataka. Međutim, unatoč njihovim impresivnim prednostima, ranjivost Verkle Treesa na kvantna računala čini ih samo privremenim rješenjem.

Dok Ethereum zajednica vidi Verkle Trees kao kratkoročni alat za kupnju vremena, dugoročni fokus je na prijelazu na kvantno otporna rješenja . Ovdje STARK Proof s i Binary Merkle Trees predstavljaju snažnu alternativu za izgradnju robusnije infrastrukture provjerljivosti za budućnost.

U procesu provjere stanja Ethereuma faktor grananja Merkleovih stabala može se smanjiti (sa 16 na 2) korištenjem binarnih Merkleovih stabala . Ova je promjena ključni korak za smanjenje veličine probnih dokaza i učinkovitije procese provjere. Međutim, čak i u najgorem slučaju, veličine dokaza još uvijek mogu doseći 10 MB , što je značajno. Ovo je mjesto gdje STARK dokazi stupaju na scenu, komprimirajući ove velike binarne Merkle dokaze na samo 100-300 kB .

Ova optimizacija je osobito važna kada se uzmu u obzir ograničenja rada validatora na lakim klijentima ili uređajima s ograničenim hardverom, posebno ako uzmete u obzir da su prosječne globalne brzine preuzimanja i prijenosa s mobilnih uređaja približno 7,625 MB/s odnosno 1,5 MB/s. Korisnici mogu potvrditi transakcije s malim, prijenosnim dokazima bez potrebe za pristupom punom stanju, a validatori mogu obavljati zadatke provjere blokova bez pohranjivanja cijelog stanja.

Ovaj pristup dvostruke koristi smanjuje zahtjeve za propusnost i pohranu za validatore, dok ubrzava verifikaciju, tri ključna poboljšanja koja izravno podržavaju Ethereumovu viziju skalabilnosti.

Ključni izazovi za STARK dokaze

1. Visoko računalno opterećenje za dokaze : Proces generiranja STARK dokaza je računski intenzivan, posebno na strani dokazivača, što može povećati operativne troškove.
2. Neučinkovitost u dokazima malih podataka: Dok se STARK dokazi ističu u rukovanju velikim skupovima podataka, oni su manje učinkoviti kada dokazuju male količine podataka, što može spriječiti njihovu primjenu u određenim scenarijima. Kada se radi o programima koji uključuju manje korake ili skupove podataka, relativno velika veličina dokaza STARK-ova može ih učiniti manje praktičnim ili isplativima.

Kvantna sigurnost ima svoju cijenu: računalno opterećenje Prover-Side-a

Merkleov dokaz bloka može uključivati približno 330 000 hash-ova, a u najgorem slučaju taj broj može narasti do 660 000 . U takvim slučajevima, STARK dokaz trebao bi obraditi oko 200 000 hashova u sekundi . Ovdje na scenu stupaju zk-friendly hash funkcije poput Poseidona , posebno optimizirane za STARK dokaze kako bi se smanjilo ovo opterećenje.

Poseidon je dizajniran za besprijekoran rad sa ZK-dokazima u usporedbi s tradicionalnim hash algoritmima kao što su SHA256 i Keccak . Primarni razlog ove kompatibilnosti leži u načinu na koji funkcioniraju tradicionalni hash algoritmi: oni obrađuju ulaze kao binarne podatke (0 i 1).

S druge strane, ZK-dokazi rade s primarnim poljima, matematičkim strukturama koje su fundamentalno različite. Ova situacija je analogna računalima koja rade u binarnom sistemu dok ljudi koriste decimalni sustav u svakodnevnom životu. Prevođenje bitnih podataka u ZK-kompatibilne formate uključuje značajne računalne troškove. Poseidon rješava ovaj problem nativnim radom unutar primarnih polja , dramatično ubrzavajući svoju integraciju sa ZK-dokazima.

Međutim, budući da je Poseidon relativno nova hash funkcija, zahtijeva opsežniju sigurnosnu analizu kako bi se uspostavila ista razina povjerenja kao tradicionalne hash funkcije kao što su SHA256 i Keccak. U tu svrhu, inicijative poput Poseidon Cryptoanalysis Initiative , koju je pokrenula Zaklada Ethereum, pozivaju stručnjake da rigorozno testiraju i analiziraju sigurnost Poseidona, osiguravajući da može izdržati kontradiktornu kontrolu i postati robustan standard za kriptografske aplikacije. S druge strane, starije funkcije poput SHA256 i Keccak već su opsežno testirane i imaju dokazanu sigurnosnu evidenciju, ali nisu prikladne za ZK, što dovodi do pada performansi kada se koriste sa STARK dokazima.

Na primjer, STARK dokazi koji koriste ove tradicionalne hash funkcije trenutno mogu obraditi samo 10 000 do 30 000 hashea. Srećom, napredak u STARK tehnologiji sugerira da bi se ta propusnost uskoro mogla povećati na 100.000 do 200.000 hashiranja, značajno poboljšavajući njihovu učinkovitost.

Neučinkovitost STARK-a u dokazivanju malih podataka

Dok se STARK dokazi ističu u skalabilnosti i transparentnosti za velike skupove podataka, oni pokazuju ograničenja pri radu s malim i brojnim elementima podataka. U tim scenarijima podaci koji se dokazuju često su mali, ali potreba za višestrukim dokazima ostaje nepromijenjena. Primjeri uključuju:

1. Provjera valjanosti transakcije nakon AA : s apstrakcijom računa (AA), novčanici mogu upućivati na kod ugovora, zaobilazeći ili prilagođavajući korake kao što su nonce i provjera potpisa, koji su trenutno obvezni u Ethereumu. Međutim, ova fleksibilnost u potvrdi zahtijeva provjeru koda ugovora ili drugih povezanih podataka u državi kako bi se dokazala valjanost transakcije.
2. RPC pozivi lakog klijenta : Laki klijenti traže podatke o stanju s mreže (npr. tijekom eth_call zahtjeva) bez pokretanja punog čvora. Kako bi se zajamčila točnost ovog stanja, dokazi moraju podržati tražene podatke i potvrditi da odgovaraju trenutnom stanju mreže.
3. Popisi uključivanja : Manji validatori mogu koristiti mehanizme popisa uključivanja kako bi osigurali da su transakcije uključene u sljedeći blok, ograničavajući utjecaj snažnih proizvođača blokova. Međutim, provjera valjanosti uključivanja ovih transakcija zahtijeva provjeru njihove točnosti.

U takvim slučajevima upotrebe, STARK dokazi pružaju malu prednost. STARK-ovi, koji naglašavaju skalabilnost (što je istaknuto slovom "S" u nazivu), imaju dobre rezultate za velike skupove podataka, ali imaju problema sa scenarijima s malim podacima. Nasuprot tome, SNARK-ovi , dizajnirani za jezgrovitost (kao što je naglašeno slovom "S" u nazivu), usredotočeni su na smanjivanje veličine dokaza, nudeći jasne prednosti u okruženjima s ograničenjima propusnosti ili pohrane.

STARK dokazi obično su veličine 40–50 KB , što je oko 175 puta više od SNARK dokaza, koji imaju samo 288 bajtova . Ova razlika u veličini povećava vrijeme provjere i troškove mreže. Primarni razlog za veće dokaze STARK-a je njihovo oslanjanje na transparentnost i polinomske obveze kako bi se osigurala skalabilnost, što uvodi troškove izvedbe u scenarijima s malim podacima. U takvim slučajevima, brže i prostorno učinkovitije metode poput Merkleovih dokaza mogle bi biti praktičnije. Merkleovi dokazi nude niske računalne troškove i brza ažuriranja, što ih čini prikladnima za ove situacije.

Kao što je sažeto u tablici, Ethereum ima četiri potencijalna puta za odabir:

Verkle Drveće

1. Verkle Trees dobili su široku podršku Ethereum zajednice, sa sastancima koji su se održavali svaka dva tjedna kako bi se olakšao njihov razvoj. Zahvaljujući ovom dosljednom radu i testiranju, Verkle Trees ističu se kao najzrelije i dobro istraženo rješenje među trenutačnim alternativama. Štoviše, njihova aditivna homomorfna svojstva eliminiraju potrebu za ponovnim izračunavanjem svake grane za ažuriranje korijena stanja, za razliku od Merkleovih stabala, što Verkleova stabla čini učinkovitijom opcijom. U usporedbi s drugim rješenjima, Verkle Trees naglašavaju jednostavnost, držeći se inženjerskih načela poput "neka bude jednostavno" ili "jednostavno je najbolje". Ova jednostavnost olakšava integraciju u Ethereum i sigurnosnu analizu.

2. Međutim, Verkle stabla nisu kvantno sigurna, što ih sprječava da budu dugoročno rješenje. Ako se integrira u Ethereum, ova bi se tehnologija vjerojatno trebala zamijeniti u budućnosti kada budu potrebna kvantno otporna rješenja. Čak i Vitalik na Verkle Trees gleda kao na privremenu mjeru kojom se kupuje vrijeme za sazrijevanje STARK-ova i drugih tehnologija. Osim toga, vektorske obveze temeljene na eliptičkoj krivulji koje se koriste u Verkleovim stablima nameću veće računalno opterećenje u usporedbi s jednostavnim hash funkcijama. Pristupi koji se temelje na hash-u mogu ponuditi brže vrijeme sinkronizacije za pune čvorove. Nadalje, oslanjanje na brojne 256-bitne operacije čini Verkle Trees težim za dokazivanje pomoću SNARK-ova unutar modernih sustava za dokazivanje, komplicirajući buduće napore da se smanje veličine dokaza

   
   

Unatoč tome, važno je napomenuti da su Verkleova stabla, zbog neoslanjanja na raspršivanje, znatno dokazivija od Merkleovih stabala.

STARK-ovi + konzervativne hash funkcije

1. Kombinacija STARK-ova s dobro uspostavljenim konzervativnim hash funkcijama kao što su SHA256 ili BLAKE pruža robusno rješenje koje jača sigurnosnu infrastrukturu Ethereuma. Ove hash funkcije naširoko su korištene i opsežno testirane u akademskim i praktičnim domenama. Osim toga, njihova kvantna otpornost povećava Ethereumovu otpornost na buduće prijetnje koje predstavljaju kvantna računala. Za sigurnosno kritične scenarije ova kombinacija nudi pouzdan temelj.

2. Međutim, korištenje konzervativnih hash funkcija u STARK sustavima uvodi značajna ograničenja performansi. Računalni zahtjevi ovih hash funkcija rezultiraju velikom latencijom provjere , pri čemu generiranje dokaza traje više od 10 sekundi. Ovo je veliki nedostatak, posebno u scenarijima kao što je provjera valjanosti bloka koja zahtijeva nisku latenciju. Dok pokušaji poput višedimenzionalnih prijedloga plina pokušavaju uskladiti kašnjenje u najgorem i prosječnom slučaju, rezultati su ograničeni. Osim toga, iako pristupi koji se temelje na raspršivanju mogu olakšati brže vrijeme sinkronizacije, njihova učinkovitost možda neće biti u skladu sa širim ciljevima skalabilnosti STARK-a. Duga vremena izračuna tradicionalnih hash funkcija smanjuju praktičnu učinkovitost i ograničavaju njihovu primjenjivost.

   STARK-ovi + Relativno nove hash funkcije

• STARK-ovi u kombinaciji s novom generacijom STARK-friendly hash funkcija (npr. Poseidon) značajno poboljšavaju performanse ove tehnologije. Ove hash funkcije dizajnirane su za besprijekornu integraciju sa STARK sustavima i drastično smanjuju kašnjenje provjere . Za razliku od tradicionalnih hash funkcija, one omogućuju generiranje dokaza za samo 1-2 sekunde . Njihova učinkovitost i mali računalni troškovi povećavaju potencijal skalabilnosti STARK-ova, čineći ih vrlo učinkovitima za rukovanje velikim skupovima podataka. Ova mogućnost ih čini posebno privlačnima za aplikacije koje zahtijevaju visoke performanse.

• Međutim, relativna novost ovih hash funkcija zahtijeva opsežnu sigurnosnu analizu i testiranje. Nedostatak sveobuhvatnog testiranja predstavlja rizike pri razmatranju njihove implementacije u kritičnim ekosustavima poput Ethereuma. Osim toga, budući da ove hash funkcije još nisu široko prihvaćene, potrebni procesi testiranja i provjere valjanosti mogli bi odgoditi ciljeve provjerljivosti Ethereuma . Vrijeme potrebno da se u potpunosti osigura njihova sigurnost moglo bi učiniti ovu opciju manje privlačnom u kratkom roku, potencijalno odgađajući Ethereumove ambicije skalabilnosti i provjerljivosti.

  Merkle stabla na bazi rešetke

1. Merkle Trees temeljena na rešetki nudi napredno rješenje koje kombinira kvantnu sigurnost s učinkovitošću ažuriranja Verkle Treesa. Ove strukture rješavaju slabosti i Verkleovih stabala i STARK-ova i smatraju se dugoročnom opcijom koja obećava. Sa svojim dizajnom koji se temelji na rešetki, oni pružaju snažnu otpornost na prijetnje kvantnog računalstva, usklađujući se s fokusom Ethereuma na očuvanje njegovog ekosustava za budućnost. Štoviše, zadržavajući prednosti ažuriranja Verkle Treesa, cilj im je pružiti poboljšanu sigurnost bez žrtvovanja učinkovitosti.
2. Međutim, istraživanja Merkleovih stabala koja se temelje na rešetki još su u ranoj fazi i uglavnom su teoretska. To stvara značajnu neizvjesnost o njihovoj praktičnoj provedbi i izvedbi. Integracija takvog rješenja u Ethereum zahtijevala bi opsežna istraživanja i razvoj, kao i rigorozno testiranje kako bi se potvrdile njegove potencijalne prednosti. Zbog ovih neizvjesnosti i infrastrukturnih složenosti malo je vjerojatno da će Merkleova stabla temeljena na rešetki biti izvediv izbor za Ethereum u bliskoj budućnosti, što potencijalno usporava napredak prema ciljevima provjerljivosti mreže.

Što je s izvršenjem: dokazi o valjanosti izvršenja EVM-a

Sve o čemu smo do sada razgovarali vrti se oko uklanjanja potrebe za validatorima za pohranjivanje prethodnog stanja, koje koriste za prijelaz iz jednog stanja u drugo. Cilj je stvoriti decentraliziranije okruženje u kojem validatori mogu obavljati svoje dužnosti bez održavanja terabajta podataka o stanju.

Čak i s rješenjima koja smo spomenuli, validatori ne bi morali pohranjivati cijelo stanje, jer bi sve podatke potrebne za izvršenje dobili preko svjedoka uključenih u blok. Međutim, za prijelaz u sljedeće stanje—i time potvrditi stateRoot na vrhu bloka—validatori ipak moraju sami izvršiti STF. Ovaj zahtjev, zauzvrat, predstavlja još jedan izazov za Ethereumovu prirodu bez dopuštenja i decentralizaciju.

U početku je The Verge zamišljen kao prekretnica koja se usredotočila isključivo na prijelaz Ethereumovog stabla stanja s Merkle Trees na Verkle Tree kako bi se poboljšala provjerljivost stanja. S vremenom se, međutim, razvio u širu inicijativu usmjerenu na povećanje provjerljivosti prijelaza stanja i konsenzusa . U svijetu u kojem je trio State, Execution i Consensus potpuno provjerljiv, Ethereum validatori mogu raditi na gotovo bilo kojem uređaju s internetskom vezom koji se može kategorizirati kao Light Client . To bi Ethereum približilo ostvarenju njegove vizije "prave decentralizacije".

Koja je opet definicija problema?

Kao što smo ranije spomenuli, validatori izvršavaju funkciju pod nazivom STF (State Transition Function) svakih 12 sekundi. Ova funkcija uzima prethodno stanje i blok kao ulaze i proizvodi sljedeće stanje kao izlaz. Validatori moraju izvršiti ovu funkciju svaki put kada se predloži novi blok i potvrditi da je hash koji predstavlja stanje na vrhu bloka—obično se naziva korijen stanja —točan.

Visoki sistemski zahtjevi za postajanje validatorom prvenstveno proizlaze iz potrebe za učinkovitim izvođenjem ovog procesa.

Ako želite pretvoriti pametni hladnjak — da, čak i hladnjak — u Ethereum validator uz pomoć nekog instaliranog softvera, suočavate se s dvije glavne prepreke :

1. Vaš hladnjak najvjerojatnije neće imati dovoljno brz internet, što znači da neće moći preuzeti podatke i dokaze potrebne za izvršenje čak ni uz rješenja državne provjerljivosti o kojima smo do sada govorili.

2. Čak i kad bi imao pristup potrebnim podacima za STF, neće imati računsku snagu potrebnu za izvođenje od početka do kraja ili za izgradnju novog stabla stanja.

   
   

Kako bi se riješili problemi uzrokovani lakim klijentima koji nemaju pristup ni prethodnom stanju ni cijelom posljednjem bloku, The Verge predlaže da bi predlagač izvršio izvršenje i zatim priložio dokaz bloku. Ovaj bi dokaz uključivao prijelaz s korijena prethodnog stanja na korijen sljedećeg stanja, kao i hash bloka. Uz to, laki klijenti mogu potvrditi prijelaz stanja koristeći samo tri 32-bajtna hashiranja, bez potrebe za zk-provjerom.

Međutim, budući da ovaj dokaz radi kroz hashove, bilo bi netočno reći da potvrđuje samo prijelaz stanja . Naprotiv, dokaz priložen bloku mora potvrditi više stvari istovremeno :

Korijen stanja u prethodnom bloku = S, Korijen stanja u sljedećem bloku = S + 1, Hash bloka = H

1. Sam blok mora biti valjan, a dokaz stanja unutar njega - bilo Verkle Proof ili STARKs - mora točno potvrditi podatke koji prate blok. Ukratko: Validacija bloka i popratni dokaz stanja .
2. Kada se STF izvršava pomoću podataka potrebnih za izvođenje i uključenih u blok koji odgovara H , podaci koji bi se trebali promijeniti u stanju moraju se ispravno ažurirati. Ukratko: Validacija prijelaza stanja .
3. Kada se novo stablo stanja ponovno izgradi s ispravno ažuriranim podacima, njegova korijenska vrijednost mora odgovarati S + 1 . Ukratko: Validacija procesa konstrukcije stabla .

U analogiji Prover-Verifikator koju smo ranije spomenuli, općenito je pošteno reći da obično postoji računalna ravnoteža između dva aktera. Iako sposobnost dokaza potrebnih da se STF učini provjerljivim za provjeru više stvari istovremeno nudi značajne prednosti za Verifikatora , to također ukazuje da će generiranje takvih dokaza da se osigura ispravnost izvršenja biti relativno izazovno za Provera . Uz trenutnu brzinu Ethereuma, Ethereum blok treba dokazati za manje od 4 sekunde . Međutim, čak i najbrži EVM Prover koji danas imamo može dokazati samo prosječni blok za približno 15 sekundi .[1]

Imajući to u vidu, postoje tri različita puta kojima možemo krenuti da prevladamo ovaj veliki izazov:

1. Paralelizacija u dokazivanju i agregaciji : Jedna od značajnih prednosti ZK-dokaza je njihova sposobnost agregiranja . Sposobnost kombiniranja višestrukih probnih otisaka u jedan, kompaktni probni otisak pruža značajnu učinkovitost u smislu vremena obrade. Ovo ne samo da smanjuje opterećenje mreže, već i ubrzava procese verifikacije na decentraliziran način. Za veliku mrežu kao što je Ethereum, omogućuje učinkovitije generiranje dokaza za svaki blok.

Tijekom generiranja dokaza, svaki mali dio procesa izvršenja (npr. koraci računanja ili pristup podacima) može se pojedinačno dokazati, a ti se dokazi kasnije mogu agregirati u jednu strukturu. S ispravnim mehanizmom, ovaj pristup omogućuje da se dokazi bloka generiraju brzo i na decentraliziran način od strane mnogih različitih izvora (npr. stotine GPU-a). Time se povećava izvedba, a istovremeno pridonosi cilju decentralizacije angažiranjem većeg broja sudionika.

2. Korištenje optimiziranih sustava za provjeru : Sustavi za provjeru nove generacije imaju potencijal učiniti Ethereumove računalne procese bržim i učinkovitijim. Napredni sustavi kao što su Orion , Binius i GKR mogu značajno smanjiti vrijeme provjere za izračune opće namjene. Ovi sustavi imaju za cilj prevladati ograničenja trenutnih tehnologija, povećavajući brzinu obrade uz potrošnju manje resursa. Za mrežu usmjerenu na skalabilnost i učinkovitost kao što je Ethereum, takve optimizacije pružaju značajnu prednost. Međutim, potpuna implementacija ovih novih sustava zahtijeva sveobuhvatno testiranje i napore na kompatibilnosti unutar ekosustava.
3. Promjene troškova plina : Povijesno gledano, troškovi plina za operacije na Ethereum Virtual Machine (EVM) obično su se određivali na temelju njihovih računalnih troškova . Međutim, danas je još jedna metrika dobila na značaju: složenost dokazivača . Dok je neke operacije relativno lako dokazati, druge imaju složeniju strukturu i zahtijevaju više vremena za provjeru. Prilagodba troškova plina ne samo na temelju računalnih napora, već i na težini dokazivanja operacija ključna je za povećanje sigurnosti i učinkovitosti mreže.

Ovaj pristup može minimizirati jaz između scenarija najgoreg i prosječnog slučaja , omogućujući dosljedniju izvedbu. Na primjer, operacije koje je teže dokazati mogle bi imati veće troškove plina, dok bi one koje je lakše dokazati mogle imati niže troškove. Dodatno, zamjena Ethereumovih podatkovnih struktura (kao što je stablo stanja ili popis transakcija ) alternativama prilagođenim STARK-u mogla bi dodatno ubrzati procese dokazivanja. Takve bi promjene pomogle Ethereumu da ostvari svoje ciljeve skalabilnosti i sigurnosti dok bi njegovu viziju provjerljivosti učinila realističnijom.

Ethereumovi napori da omogući dokaze izvršenja predstavljaju značajnu priliku za postizanje njegovih ciljeva provjerljivosti. Međutim, postizanje ovog cilja zahtijeva ne samo tehničke inovacije, već i povećane inženjerske napore i kritične odluke unutar zajednice. Učiniti procese izvršenja provjerljivima na razini 1 mora pronaći ravnotežu između pristupa širokoj bazi korisnika uz očuvanje decentralizacije i usklađivanje s postojećom infrastrukturom.

Uspostavljanje ove ravnoteže povećava složenost metoda koje se koriste za dokazivanje operacija tijekom izvođenja, naglašavajući potrebu za napretkom kao što je paralelno generiranje dokaza . Dodatno, infrastrukturni zahtjevi ovih tehnologija (npr. tablice pretraživanja ) moraju se implementirati i operacionalizirati, što još uvijek zahtijeva značajno istraživanje i razvoj.

S druge strane, specijalizirani sklopovi (npr. ASIC, FPGA, GPU) dizajnirani posebno za određene zadatke imaju značajan potencijal za ubrzanje procesa generiranja dokaza. Ova rješenja pružaju puno veću učinkovitost u usporedbi s tradicionalnim hardverom i mogu ubrzati procese izvršenja.

Međutim, ciljevi decentralizacije Ethereuma na razini 1 sprječavaju da takav hardver bude dostupan samo odabranoj skupini aktera. Kao rezultat toga, očekuje se da će ova rješenja imati veću upotrebu u sustavima drugog sloja. Ipak, zajednica također mora postići konsenzus o hardverskim zahtjevima za generiranje dokaza.

Postavlja se ključno pitanje dizajna: treba li generiranje dokaza raditi na hardveru potrošačke razine kao što su vrhunska prijenosna računala ili zahtijeva industrijsku infrastrukturu? Odgovor oblikuje cjelokupnu Ethereumovu arhitekturu – dopuštajući agresivnu optimizaciju za Layer 2 rješenja dok zahtijeva konzervativnije pristupe za Layer 1.

Naposljetku, implementacija dokaza izvršenja izravno je povezana s drugim ciljevima plana Ethereuma. Uvođenje dokaza valjanosti ne samo da bi podržalo koncepte kao što je apatridnost, već bi također poboljšalo decentralizaciju Ethereuma čineći područja kao što je solo staking pristupačnijim. Cilj je omogućiti ulaganje čak i na uređajima s najnižim specifikacijama. Osim toga, restrukturiranje troškova plina na EVM-u na temelju računalnih poteškoća i dokazivosti moglo bi smanjiti jaz između prosječnog i najgoreg scenarija.

Međutim, takve bi promjene mogle prekinuti kompatibilnost s postojećim sustavom i prisiliti programere da ponovno napišu svoj kod. Iz tog razloga, implementacija dokaza izvršenja nije samo tehnički izazov – to je putovanje koje mora biti osmišljeno da održi dugoročne vrijednosti Ethereuma.

Posljednji korak za pravu potpunu provjerljivost: konsenzus

Ethereumov mehanizam konsenzusa nastoji uspostaviti jedinstvenu ravnotežu koja čuva decentralizaciju i pristupačnost uz postizanje ciljeva provjerljivosti. U ovom okviru, probabilističke i determinističke metode konsenzusa nude različite prednosti i izazove.

Probabilistički konsenzus izgrađen je na komunikacijskom modelu ogovaranja. U ovom modelu, umjesto izravne komunikacije sa svim čvorovima koji predstavljaju mrežu, čvor dijeli informacije s nasumično odabranim skupom od 64 ili 128 čvorova. Odabir lanca čvora temelji se na ovim ograničenim informacijama, što uvodi mogućnost pogreške. Međutim, tijekom vremena, kako blockchain napreduje, očekuje se da će ti odabiri konvergirati prema ispravnom lancu sa stopom pogreške od 0%.

Jedna prednost probabilističke strukture je ta da svaki čvor ne emitira svoj lanac prikaza kao zasebnu poruku, smanjujući opterećenje komunikacije. Posljedično, takva struktura može raditi s daleko više decentraliziranih čvorova bez dozvola s nižim zahtjevima sustava.

Nasuprot tome, deterministički konsenzus djeluje kroz komunikacijski model jedan prema svima. Ovdje čvor šalje svoj lančani prikaz kao glas svim drugim čvorovima. Ovaj pristup generira veći intenzitet poruka, a kako broj čvorova raste, sustav bi na kraju mogao dosegnuti svoje granice.

Međutim, najveća prednost determinističkog konsenzusa je dostupnost konkretnih glasova, što vam omogućuje da točno znate koji je čvor glasovao za koji fork. To osigurava brzu i konačnu konačnost lanca, jamči da se redoslijed blokova ne može promijeniti i čini ih provjerljivima.

Kako bi osigurao provjerljivi mehanizam konsenzusa uz očuvanje decentralizacije i strukture bez dopuštenja, Ethereum je uspostavio ravnotežu između utora i epoha. Slotovi, koji predstavljaju intervale od 12 sekundi, osnovne su jedinice u kojima je validator odgovoran za stvaranje bloka. Iako probabilistički konsenzus koji se koristi na razini utora omogućuje fleksibilniji i decentralizirani rad lanca, on ima ograničenja u smislu konačnog redoslijeda i provjerljivosti.

Epohe, koje obuhvaćaju 32 mjesta, uvode deterministički konsenzus. Na ovoj razini validatori glasuju kako bi finalizirali redoslijed lanca, osiguravajući sigurnost i čineći lanac provjerljivim. Međutim, dok ova deterministička struktura pruža provjerljivost kroz konkretne glasove na razini epohe, ona ne može ponuditi punu provjerljivost unutar samih epoha zbog probabilističke strukture. Kako bi riješio ovaj jaz i ojačao strukturu vjerojatnosti unutar epoha, Ethereum je razvio rješenje poznato kao Sync Committee.

Altairov protokol Light Client: Sync Committee

Sync Committee je mehanizam uveden s Altair nadogradnjom kako bi se prevladala ograničenja Ethereumovog vjerojatnosnog konsenzusa i poboljšala provjerljivost lanca za lake klijente. Odbor se sastoji od 512 nasumično odabranih validatora koji služe 256 epoha (~27 sati). Ovi validatori stvaraju potpis koji predstavlja glavu lanca, omogućujući lakim klijentima provjeru valjanosti lanca bez potrebe za preuzimanjem povijesnih podataka lanca. Djelovanje Sinkroniziranog odbora može se sažeti na sljedeći način:

1. Formiranje odbora : 512 validatora nasumično je odabrano od svih validatora u mreži. Ovaj se odabir redovito osvježava kako bi se održala decentralizacija i spriječilo oslanjanje na određenu skupinu.
2. Generiranje potpisa : Članovi odbora stvaraju potpis koji predstavlja posljednje stanje u lancu. Ovaj potpis je zajednički BLS potpis koji su stvorili članovi i koristi se za provjeru valjanosti lanca.
3. Lagana provjera klijenta : Laki klijenti mogu provjeriti ispravnost lanca jednostavnom provjerom potpisa Sinkronizirajućeg odbora. To im omogućuje sigurno praćenje lanca bez preuzimanja prošlih podataka lanca.

Međutim, Sync Committee je bio predmet kritika u nekim područjima. Naime, protokolu nedostaje mehanizam za smanjenje validatora za zlonamjerno ponašanje , čak i ako odabrani validatori namjerno djeluju protiv protokola. Kao rezultat toga, mnogi smatraju da je Sync Committee sigurnosni rizik i suzdržavaju se od toga da ga u potpunosti klasificiraju kao Light Client Protocol . Bez obzira na to, sigurnost Sync Committee je matematički dokazana , a dodatne pojedinosti mogu se pronaći u ovom članku o rezovima Sync Committee .

Nepostojanje mehanizma za rezanje u protokolu nije izbor dizajna, već nužnost koja proizlazi iz prirode vjerojatnosnog konsenzusa. Probabilistički konsenzus ne daje apsolutna jamstva o tome što validator opaža. Čak i ako većina validatora izvijesti da je određena vilica teža, još uvijek mogu postojati iznimni validatori koji drugu vilicu smatraju težom. Ova neizvjesnost čini izazovnim dokazivanje zlonamjerne namjere i, stoga, nemogućim kažnjavanje lošeg ponašanja.

U tom kontekstu, umjesto da Sync Committee označimo nesigurnim, točnije bi bilo opisati ga kao neučinkovito rješenje. Problem ne proizlazi iz mehaničkog dizajna ili rada Odbora za sinkronizaciju, već iz inherentne prirode vjerojatnosnog konsenzusa. Budući da probabilistički konsenzus ne može ponuditi konačna jamstva o tome što čvorovi promatraju, Sync Committee jedno je od najboljih rješenja koje se može dizajnirati unutar takvog modela. Međutim, to ne uklanja slabosti probabilističkog konsenzusa u jamčenju konačnosti lanca. Problem ne leži u mehanizmu, već unutar Ethereumove trenutne strukture konsenzusa.

Zbog ovih ograničenja, u ekosustavu Ethereuma postoje stalni napori da se redizajnira mehanizam konsenzusa i implementiraju rješenja koja pružaju determinističku konačnost u kraćim razdobljima. Prijedlozi kao što su Orbit-SSF i 3SF imaju za cilj preoblikovati konsenzusnu strukturu Ethereuma iz temelja, stvarajući učinkovitiji sustav koji će zamijeniti probabilistički konsenzus. Takvi pristupi nastoje ne samo skratiti vrijeme konačnosti lanca, već i pružiti učinkovitiju i provjerljiviju strukturu mreže. Ethereum zajednica nastavlja aktivno razvijati i pripremati ove prijedloge za buduću implementaciju.

Snarkifikacija konsenzusa

The Verge ima za cilj poboljšati Ethereumove trenutne i buduće mehanizme konsenzusa tako što će ih učiniti provjerljivijima kroz zk-proof tehnologiju, umjesto da ih u potpunosti zamijeni. Ovaj pristup nastoji modernizirati Ethereumove procese konsenzusa uz očuvanje njegovih temeljnih načela decentralizacije i sigurnosti. Optimiziranje svih povijesnih i trenutačnih procesa konsenzusa u lancu sa zk tehnologijama igra ključnu ulogu u postizanju dugoročnih ciljeva skalabilnosti i učinkovitosti Ethereuma. Temeljne operacije koje se koriste u sloju konsenzusa Ethereuma od velike su važnosti u ovoj tehnološkoj transformaciji. Pogledajmo pobliže te operacije i izazove s kojima se suočavaju.

• ECADD-ovi :
• Svrha : Ova se operacija koristi za prikupljanje javnih ključeva validatora i ključna je za osiguravanje točnosti i učinkovitosti lanca. Zahvaljujući agregatnoj prirodi BLS potpisa, više potpisa se može kombinirati u jednu strukturu. To smanjuje komunikacijske troškove i čini procese verifikacije u lancu učinkovitijima. Učinkovitije osiguravanje sinkronizacije između velikih grupa validatora čini ovu operaciju kritičnom.
• Izazovi : Kao što je prethodno spomenuto, Ethereumovi validatori glasuju o redoslijedu lanca tijekom epoha. Danas je Ethereum mreža s otprilike 1,1 milijun validatora . Kad bi svi validatori pokušali propagirati svoje glasove istovremeno, to bi stvorilo značajan pritisak na mrežu. Kako bi se to izbjeglo, Ethereum dopušta validatorima da glasaju na temelju utora tijekom epohe, gdje samo 1/32 svih validatora glasa po utoru. Iako ovaj mehanizam smanjuje troškove mrežne komunikacije i čini konsenzus učinkovitijim, s obzirom na današnji broj validatora, oko 34.000 validatora glasa u svakom utoru. To znači približno 34.000 ECADD operacija po utoru .
• Uparivanja :
• Svrha : Operacije uparivanja koriste se za provjeru BLS potpisa , osiguravajući valjanost epoha u lancu. Ova operacija omogućuje skupnu provjeru potpisa. Međutim, nije pogodan za zk , zbog čega je izuzetno skupo dokazivati korištenje zk-proof tehnologije. Ovo predstavlja veliki izazov u stvaranju integriranog procesa provjere s tehnologijama bez znanja.
• Izazovi : Operacije uparivanja u Ethereumu ograničene su na najviše 128 potvrda (agregiranih potpisa) po utoru, što rezultira manjim brojem operacija uparivanja u usporedbi s ECADD-ovima. Međutim, nedostatak zk-prijateljstva u ovim operacijama predstavlja značajan izazov. Dokazivanje operacije uparivanja sa zk-dokazima je tisuće puta skuplje od dokazivanja ECADD operacije [2]. Zbog toga je prilagodba operacija uparivanja za tehnologije bez znanja jedna od najvećih prepreka u Ethereumovim procesima provjere konsenzusa.
• SHA256 hashovi :
• Svrha : SHA256 hash funkcije koriste se za čitanje i ažuriranje stanja lanca, osiguravajući cjelovitost podataka lanca. Međutim, njihov nedostatak zk-prilagođenosti dovodi do neučinkovitosti u procesima verifikacije temeljenim na zk-proofu, što predstavlja glavnu prepreku budućim ciljevima provjerljivosti Ethereuma.
• Izazovi : SHA256 hash funkcije često se koriste za čitanje i ažuriranje stanja lanca. Međutim, njihova neprijaznost prema zk-u sukobljava se s Ethereumovim ciljevima verifikacije temeljene na zk-proof-u. Na primjer, između dvije epohe, svaki validator pokreće STF Ethereumovog sloja konsenzusa za ažuriranje stanja s nagradama i kaznama na temelju performansi validatora tijekom epohe. Ovaj se proces uvelike oslanja na hash funkcije SHA256, što značajno povećava troškove u sustavima temeljenim na zk-proof. To stvara znatnu prepreku usklađivanju Ethereumovog mehanizma konsenzusa sa zk tehnologijama.

Operacije ECADD, uparivanje i SHA256 koje se koriste u trenutnom sloju konsenzusa igraju ključnu ulogu u ciljevima provjerljivosti Ethereuma. Međutim, njihov nedostatak zk-prijateljstva predstavlja značajne izazove na putu do postizanja ovih ciljeva. ECADD operacije stvaraju skupo opterećenje zbog velikog broja glasova validatora, dok su operacije uparivanja, unatoč manjem broju, tisuće puta skuplje za dokazivanje zk-dokazima.

Osim toga, neprilagođenost zk-u SHA256 hash funkcija čini dokazivanje prijelaza stanja lanca pratilaca iznimno izazovnim. Ova pitanja naglašavaju potrebu za sveobuhvatnom transformacijom kako bi se postojeća infrastruktura Ethereuma uskladila s tehnologijama bez znanja.

Rješenje “Beam Chain”: Reimagining Ethereumovog sloja konsenzusa

Dana 12. studenog 2024., tijekom svoje prezentacije na Devconu, Justin Drake predstavio je prijedlog pod nazivom "Beam Chain " s ciljem temeljne i sveobuhvatne transformacije Ethereumovog sloja konsenzusa. Beacon Chain je u središtu Ethereumove mreže gotovo pet godina. Međutim, tijekom tog razdoblja nije bilo većih strukturnih promjena Beacon Chaina. Nasuprot tome, tehnološki napredak je brzo napredovao, daleko nadmašujući statičnu prirodu Beacon Chaina.

U svojoj prezentaciji, Justin Drake je naglasio da je Ethereum tijekom ovih pet godina naučio značajne lekcije u kritičnim područjima kao što su razumijevanje MEV-a , otkrića u SNARK tehnologijama i retrospektivna svijest o tehnološkim pogreškama . Dizajni temeljeni na ovim novim saznanjima kategorizirani su u tri glavna stupa: Block Production , Staking i Cryptography . Sljedeći vizualni prikaz sažima ove dizajne i predloženu mapu puta:

• Zeleni i sivi okviri predstavljaju inkrementalne razvoje koji se mogu implementirati jedan po jedan svake godine. Ove vrste poboljšanja, poput prethodnih nadogradnji, mogu se integrirati korak po korak bez narušavanja postojeće Ethereumove arhitekture.

• Crveni okviri , s druge strane, označavaju velike sinergije , velike i temeljne promjene koje se moraju provesti zajedno. Prema Drakeu, ove promjene imaju za cilj unaprijediti kapacitet i provjerljivost Ethereuma u jednom velikom skoku.

  
  

U ovom smo odjeljku detaljno ispitali korake The Verge Consensus, State i Execution , a jedan od najistaknutijih problema istaknutih tijekom ovog procesa je upotreba funkcije raspršivanja SHA256 u Ethereumovu Beacon Chainu. Iako SHA256 igra središnju ulogu u osiguravanju sigurnosti mreže i obradi transakcija, njegov nedostatak zk-prilagođenosti predstavlja značajnu prepreku postizanju Ethereumovih ciljeva provjerljivosti. Njegovi visoki računalni troškovi i nekompatibilnost sa zk tehnologijama čine ga kritičnim problemom koji se mora riješiti u budućem razvoju Ethereuma.

Putokaz Justina Drakea, predstavljen tijekom njegovog govora o Devconu, predviđa zamjenu SHA256 u Beacon Chainu sa zk-friendly hash funkcijama kao što je Poseidon . Ovaj prijedlog ima za cilj modernizirati Ethereumov sloj konsenzusa, čineći ga provjerljivijim, učinkovitijim i usklađenijim s tehnologijama otpornim na zk.

U tom kontekstu, vidimo da se Ethereum ne suočava samo s izazovima s hash funkcijama koje nisu prijateljske prema zk-u, već također treba ponovno procijeniti digitalne potpise koji se koriste u njegovom sloju konsenzusa za dugoročnu sigurnost. S napretkom kvantnog računalstva, algoritmi digitalnog potpisa poput ECDSA koji se trenutno koriste mogli bi se suočiti sa značajnim prijetnjama. Kao što je navedeno u smjernicama koje je objavio NIST , varijante ECDSA sa 112-bitnom sigurnosnom razinom bit će zastarjele do 2030. i potpuno zabranjene do 2035. godine . To zahtijeva prijelaz za Ethereum i slične mreže prema otpornijim alternativama kao što su kvantno sigurni potpisi u budućnosti.

U ovom trenutku potpisi temeljeni na raspršivanju pojavljuju se kao kvantno otporna rješenja koja bi mogla odigrati ključnu ulogu u podržavanju ciljeva sigurnosti i provjerljivosti mreže. Rješavanje ove potrebe također uklanja drugu veliku prepreku da se Beacon Chain učini provjerljivim: BLS potpisi . Jedan od najznačajnijih koraka koje Ethereum može poduzeti prema osiguravanju kvantne sigurnosti je usvajanje postkvantnih rješenja kao što su potpisi temeljeni na hash-u i SNARK-ovi temeljeni na hash-u .

Kao što je Justin Drake naglasio u svojoj prezentaciji Devcona , hash funkcije su inherentno otporne na kvantna računala zbog njihovog oslanjanja na otpornost prije slike, što ih čini jednim od temeljnih građevnih blokova moderne kriptografije. Ovo svojstvo osigurava da čak ni kvantna računala ne mogu učinkovito obrnuti inženjering izvornog unosa iz danog hash-a, čuvajući svoju sigurnost.

Sustavi potpisa koji se temelje na raspršivanju omogućuju validatorima i potvrđivačima da generiraju potpise koji se u potpunosti temelje na funkcijama raspršivanja, osiguravajući post-kvantnu sigurnost, a istovremeno pružajući višu razinu provjerljivosti u cijeloj mreži—posebno ako se koristi hash funkcija prilagođena SNARK-u. Ovaj pristup ne samo da povećava sigurnost mreže, već također čini Ethereumovu dugoročnu sigurnosnu infrastrukturu robusnijom i otpornijom na budućnost.

Ovaj se sustav oslanja na kombiniranje potpisa temeljenih na hash-u i SNARK-ova temeljenih na hash-u (dokazi slični STARK-u) za stvaranje shema potpisa koje se mogu agregirati . Agregabilni potpisi sažimaju tisuće potpisa u jednu strukturu, smanjujući je na samo nekoliko stotina kilobajta dokaza. Ovo sažimanje značajno smanjuje opterećenje podataka na mreži dok uvelike ubrzava procese verifikacije. Na primjer, tisuće potpisa validatora proizvedenih za jedan utor na Ethereumu mogu se predstaviti jednim skupnim potpisom, čime se štedi prostor za pohranu i računalna snaga.

Međutim, najznačajnija značajka ove sheme je njezina beskonačno rekurzivna agregacija . To jest, jedna grupa potpisa može se dalje kombinirati pod drugom grupom, a ovaj se proces može nastaviti u cijelom lancu. Uz ovaj mehanizam i s obzirom na budući tehnološki napredak, pošteno je reći da ovo otvara vrata mogućnostima koje su trenutno nedostižne s BLS-om.

Zaključak

Put Ethereuma do provjerljivosti predstavlja temeljnu promjenu u blockchain tehnologiji. Inicijativa Verge rješava ključne neučinkovitosti putem Verkleovih stabala za provjeru stanja i STARK dokaza za skalabilne prijelaze.

Jedan od najambicioznijih prijedloga je Beam Chain , sveobuhvatan redizajn sloja konsenzusa Ethereuma. Rješavanjem ograničenja Beacon Chaina i uključivanjem alternativa prilagođenih zk-u, ovaj pristup ima za cilj poboljšati skalabilnost Ethereuma uz očuvanje njegovih temeljnih načela decentralizacije i pristupačnosti . Međutim, prijelaz također naglašava izazove s kojima se Ethereum suočava u balansiranju računalnih zahtjeva sa svojim ciljem održavanja inkluzivne mreže bez dozvola.

Budući da NIST planira postupno ukinuti trenutnu kriptografiju eliptične krivulje do 2035., Ethereum mora usvojiti kvantno otporna rješenja poput potpisa temeljenih na raspršivanju i Poseidona. Ova rješenja predstavljaju vlastite kompromise učinkovitosti.

Korištenje STARK-ova u Ethereumovu planu dodatno naglašava skalabilnost i provjerljivost. Iako su izvrsni u pružanju transparentnih i kvantno otpornih dokaza, njihova integracija uvodi izazove povezane s računalnim troškovima na strani uređaja za ispitivanje i neučinkovitošću malih podataka . Te se prepreke moraju riješiti kako bi se u potpunosti ostvarila Ethereumova vizija apatridnosti i učinkovite provjere blokova, osiguravajući da mreža ostane robusna usprkos sve većoj potražnji.

Unatoč ovim naprecima, ključni izazovi ostaju. Ethereum se mora snalaziti u problemima prilagođenosti zk-u , skalabilnosti konsenzusa i složenosti integriranja kvantno otporne kriptografije . Štoviše, kompatibilnost postojeće infrastrukture unatrag postavlja praktične prepreke koje zahtijevaju pažljiva inženjerska rješenja kako bi se spriječili prekidi za programere i korisnike.

Ono što izdvaja Ethereum nisu samo njegove tehničke inovacije, već iterativni pristup rješavanju nekih od najtežih problema u blockchainu. Put naprijed - bilo kroz tehnologije kao što su Beam Chain , Verkle Trees ili STARK proofs - ovisi o zajedničkim naporima programera, istraživača i šire zajednice. Ovi napretci se ne odnose na postizanje savršenstva preko noći, već na stvaranje temelja za transparentan , decentraliziran i provjerljiv internet.

Evolucija Ethereuma naglašava njegovu ulogu kritičnog igrača u oblikovanju ere Web3. Hvatajući današnje izazove praktičnim rješenjima, Ethereum se približava budućnosti u kojoj provjerljivost , kvantna otpornost i skalabilnost postaju standard, a ne iznimka.