Ethereum zajednica razmatra novi tehnički predlog koji bi mogao da promeni način na koji mreža verifikuje složene kriptografske dokaze i obračunava troškove kada više transakcija koristi zajedničku verifikaciju.
Ethereum contributor Marchhill podneo je 13. novembra nacrt predloga u Ethereum EIP repozitorijumu.
Cilj je da se omogući generička verifikacija dokaza, batch obrada i model u kojem jedan sponzor može da pokrije trošak zajedničkog dokaza, dok pojedinačne transakcije i dalje plaćaju sopstvene zahteve.
Predlog je još u ranoj fazi.
Nema dodeljen EIP broj, nema potvrđen datum aktivacije i nije usvojen kao deo buduće Ethereum nadogradnje.
Ideja je da više transakcija deli isti dokaz
Centralna ideja predloga jeste da se više pojedinačnih zahteva može grupisati u zajednički batch.
Umesto da se za svaki zahtev posebno radi kompletna verifikacija, više njih može da deli isti kriptografski dokaz.
Takav pristup potencijalno može smanjiti dupliranje rada.
Posebno je relevantan za slučajeve u kojima veliki broj transakcija koristi sličnu ili povezanu kriptografsku logiku.
Sponzor bi plaćao zajednički deo
Predlog uvodi poseban model plaćanja.
Sponzor bi mogao da pokrije trošak svakog zadržanog batch leaf-a.
Leaf predstavlja deo batch dokaza koji može sadržati više pojedinačnih zahteva.
Istovremeno bi svaka transakcija plaćala sopstveni claim.
Tako se trošak zajedničke verifikacije odvaja od troška pojedinačne transakcije.
Transakcije ne bi morale ponovo da se potpisuju
Jedna od važnijih karakteristika predloga odnosi se na fleksibilnost uključivanja transakcija u blok.
Builder bi mogao da uključi samo validan podskup transakcija iz originalnog batcha.
Ako neke transakcije iz grupe budu izostavljene, ostale ne bi morale ponovo da se potpisuju.
To znači da korisnik čija je transakcija spremna za uključivanje ne bi morao da generiše novi potpis samo zato što drugi član originalnog batcha nije uključen.
Svaka transakcija zadržava sopstveni nonce
Iako bi se deo verifikacije delio, pojedinačne transakcije ne bi izgubile svoj identitet.
Svaka bi i dalje zadržala sopstveni nonce.
Nonce određuje redosled transakcija sa određenog naloga.
To je važan deo Ethereum modela jer sprečava ponavljanje transakcija i održava njihov pravilan redosled.
Receipt takođe ostaje vezan za pojedinačnu transakciju
Predlog zadržava i individualne transaction receipte.
Receipt beleži rezultat izvršavanja određene transakcije.
To znači da deljenje kriptografskog dokaza ne bi pretvorilo više transakcija u jednu veliku neodvojivu operaciju.
Na nivou izvršavanja one bi i dalje ostale zasebne transakcije sa sopstvenim rezultatima.
Plaćanje i dokaz validnosti tretiraju se odvojeno
Jedan od zanimljivijih delova dizajna jeste razdvajanje dve stvari.
Prva je dokaz da su određeni claims validni.
Druga je potvrda da su odgovarajuća plaćanja pravilno obezbeđena.
Predlog predviđa da se payment matching proverava tokom finalizacije.
Recursive proofs bi služili za potvrdu izvora koji su korišćeni unutar batcha.
Šta su recursive proofs?
Recursive proof je kriptografski dokaz koji može da potvrdi validnost drugih dokaza.
Umesto da Ethereum proverava veliki broj zasebnih dokaza jedan po jedan, jedan viši dokaz može da potvrdi rezultate više drugih dokaza.
Ovaj koncept je važan za skaliranje verifikacije.
Posebno je koristan kada veliki broj složenih kriptografskih operacija treba svesti na manji broj provera na nivou bloka.
Predlog se oslanja na EIP-8288
Marchhillov nacrt direktno se nadovezuje na EIP-8288.
Autori tog EIP-a su Vitalik Buterin i Thomas Coratger.
EIP-8288 predlaže da se agregiranje kriptografskih potpisa i dokaza obavlja izvan glavnog Ethereum execution procesa.
Transakcije bi zatim navodile koje tvrdnje treba verifikovati.
Recursive STARK dokaz bi na nivou bloka potvrđivao da su te tvrdnje validne.
Šta je STARK dokaz?
STARK je vrsta kriptografskog dokaza koja omogućava dokazivanje da je određeni račun ili obrada pravilno izvršena.
Verifier ne mora ponovo da izvršava kompletnu originalnu računicu.
Umesto toga proverava kompaktan dokaz.
Takvi sistemi mogu biti korisni kada Ethereum treba da proveri veliki broj složenih operacija uz manju količinu direktnog računanja.
Predlog bi aktivirao rezervisani LEANSTARK_SCHEME
EIP-8288 trenutno rezerviše generički LEANSTARK_SCHEME.
Marchhillov nacrt predlaže da se taj put aktivira.
Predlog takođe menja način predstavljanja podataka.
Umesto jednostavnog data hash izraza koristio bi se stabilni digest koji predstavlja listu claims.
Cilj je da struktura bude pogodnija za zajedničku verifikaciju više zahteva.
Predlog objedinjavanja više mehanizama
Nacrt pokušava da spoji nekoliko komponenti u jedan sistem.
To uključuje:
generičku verifikaciju,
identifikaciju dokaza,
ograničenja resursa,
dependency summaries,
batch plaćanja,
i sponsorisanu obradu.
Predlog tako zamenjuje raniji pull request #12654.
Novi EIP broj i posebna diskusiona tema još nisu određeni.
Obični proofovi bi i dalje mogli preko javnog mempoola
Predlog ne znači da svaka transakcija mora koristiti batch sistem.
Obični dokazi koji pokrivaju samo jednu tvrdnju i dalje bi mogli da budu poslati preko standardnog javnog mempoola.
Mempool je prostor u kojem transakcije čekaju da budu uključene u blok.
Batch sistem bi predstavljao dodatni način obrade složenijih ili grupisanih dokaza.
Discounted claims i sponsor payments išli bi builderima
Predlog predviđa da discounted claims i sponsor payments idu direktno block builderima.
Builderi su odgovorni za sastavljanje sadržaja bloka.
Time se ekonomski model verifikacije povezuje direktno sa infrastrukturom koja odlučuje koje transakcije i dokazi ulaze u blok.
Gas troškovi još nisu konačni
Nacrt trenutno sadrži nekoliko konkretnih gas vrednosti.
Međutim, sve su označene kao privremene.
Predložena native verification cena iznosi 15.400 gas.
Ordinary generic verification navodi se na približno 572.000 gas.
Intrinsic proof share postavljen je na 5.100 gas.
Leaf payment trenutno je procenjen na 675.000 gas.
Batch claim ima predloženu cenu od 4.200 gas.
Ove brojke ne predstavljaju konačan cenovnik
Veoma je važno naglasiti da predložene gas vrednosti još nisu konačne.
One zahtevaju zajedničku kalibraciju.
Zbog toga se trenutno ne može pouzdano reći koliku bi tačno uštedu korisnici dobili.
Nacrt još ne predstavlja potvrđeni Ethereum fee model.
Brojke prvenstveno služe kao početna osnova za testiranje performansi.
Leaf payment ima poseban trošak
Predlog posebno naplaćuje leaf payment.
Razlog je to što povezivanje plaćanja sa batch dokazom zahteva dodatni fiksni rad koji ne postoji kod obične verifikacije.
Claims i payments, prema trenutnom nacrtu, ne bi imali dodatni intrinsic proof share.
Time se pokušava preciznije raspodeliti trošak između zajedničkog i individualnog dela procesa.
Predložen limit od 16.384 dependency stavki po bloku
Nacrt uključuje i ograničenja resursa.
Predloženi maksimalni broj različitih dependencies u jednom bloku iznosi 16.384.
Ovaj limit bio bi odvojen od standardnog gas limita.
To znači da blok ne bi mogao da uključi neograničen broj zavisnosti čak ni kada gas limit to tehnički dozvoljava.
Jedan leaf mogao bi imati do 256 claims
Predlog trenutno dopušta do 256 claims unutar jednog leaf-a.
Istovremeno bi jedan proof step mogao da ima do 16 inputa.
Važno je da ove brojke ne predstavljaju ukupne block-wide limite.
Odnose se na pojedinačne strukture unutar sistema.
Aktivacija zavisi od testiranja performansi
Predlog ne bi mogao jednostavno da bude aktiviran samo na osnovu trenutne specifikacije.
Pre toga su potrebna detaljna merenja performansi.
Testiranje treba da obuhvati kompletan processing schedule.
Potrebno je proveriti ponašanje sistema u uslovima punog bloka.
Takođe treba analizirati kasne promene sponsorshipa i sve dodatne troškove koji moraju stati unutar transaction gas limita.
Modelovani rezultati nisu isto što i realni benchmark
Nacrt razlikuje stvarno izmerene rezultate od modelovanih performansi.
Postoje podaci za pojedinačni node i jednu mašinu.
Pored njih postoje i modelovani rezultati za sistem sa 16 worker procesa.
Autori predloga zahtevaju da se te razlike jasno evidentiraju.
To je važno jer teorijsko paralelno ubrzanje ne mora u realnom sistemu dati iste rezultate.
Invalid sponsorship predstavlja rizik za buildera
Jedan od problema koje predlog mora da reši jeste situacija kada sponsorship postane nevažeći.
Builder je možda već potrošio resurse na obradu batcha.
Ako se sponsorship kasnije pokaže nevalidnim, taj rad može biti izgubljen.
Nacrt navodi da inclusion gas ne bi automatski nadoknadio takav trošak builderu.
Zbog toga je potrebno dodatno analizirati ekonomske rizike.
Predlog ne uvodi nove mrežne poruke
Iako menja način verifikacije i plaćanja, nacrt ne zahteva uvođenje novih networking messages.
To znači da bi promena bila fokusirana na obradu, verifikaciju i pravila uključivanja.
Mrežni komunikacioni sloj ne bi morao da dobije potpuno novi tip poruka samo zbog ovog mehanizma.
Zašto bi zajednička verifikacija bila korisna?
Kod složenih kriptografskih sistema verifikacija može biti skupa.
Ako veliki broj korisnika radi slične operacije, pojedinačno proveravanje svakog dokaza može dovesti do velikog dupliranja rada.
Batch pristup pokušava da taj posao objedini.
Umesto više kompletnih verifikacija može se koristiti zajednički dokaz koji potvrđuje više claims.
To je slična osnovna logika koja se koristi u mnogim modernim scaling sistemima.
Sponsor model otvara nove mogućnosti
Mogućnost da neko drugi plati zajednički deo dokaza može biti korisna za aplikacije koje žele da subvencionišu korisničke transakcije.
Aplikacija ili drugi učesnik mogao bi preuzeti zajednički trošak batcha.
Korisnik bi zatim plaćao samo svoj deo.
Takav model potencijalno može biti zanimljiv za wallets, rollupe i aplikacije sa velikim brojem sličnih transakcija.
Međutim, konkretni načini korišćenja tek treba da budu razrađeni.
Ne treba očekivati skoro aktiviranje na mainnetu
Trenutni status predloga posebno je važan.
Radi se o draft pull requestu.
Predlog još nema EIP broj.
Nema određenu mainnet aktivaciju.
Nije deo potvrđene Ethereum nadogradnje.
Mnoge tehničke i ekonomske vrednosti i dalje su privremene.
Zbog toga ovaj nacrt treba posmatrati kao pravac istraživanja, a ne kao završenu promenu Ethereum protokola.
Šta developeri još moraju da potvrde?
Pre eventualnog usvajanja potrebno je potvrditi nekoliko važnih stvari.
Prvo je potrebno utvrditi stvarne performanse sistema pod maksimalnim opterećenjem.
Zatim je potrebno pravilno kalibrisati gas troškove.
Mora se proveriti da ograničenja resursa sprečavaju preveliko opterećenje bloka.
Takođe treba rešiti rizike povezane sa nevažećim sponsorshipom.
Tek nakon tih koraka moglo bi se ozbiljnije razgovarati o aktivaciji.
Potencijal za efikasniju Ethereum kriptografiju
Širi cilj ovakvih predloga jeste da Ethereum može da koristi sve složenije kriptografske tehnike bez proporcionalnog povećanja troškova.
Aggregated signatures, recursive proofs i STARK sistemi mogu omogućiti da veliki broj operacija bude potvrđen sa manjim brojem direktnih verifikacija.
To može biti posebno važno kako Ethereum ekosistem nastavlja da koristi rollupe, account abstraction i druge napredne kriptografske sisteme.
Zaključak
Ethereum contributor Marchhill predložio je novi nacrt koji kombinuje generičku verifikaciju kriptografskih dokaza sa batch obradom i sponsorisanim plaćanjem.
Ideja je da više transakcija može da deli zajednički dokaz.
Sponzor bi plaćao batch leaf, dok bi pojedinačne transakcije plaćale sopstvene claims.
Builder bi mogao da uključi samo validan podskup batcha bez potrebe da korisnici ponovo potpisuju transakcije.
Svaka transakcija bi i dalje zadržala sopstveni nonce i receipt.
Predlog se nadovezuje na EIP-8288, koji su napisali Vitalik Buterin i Thomas Coratger, i predlaže aktiviranje rezervisanog LEANSTARK_SCHEME sistema.
Trenutne privremene gas vrednosti uključuju 15.400 gas za native verification, 572.000 za generic verification, 5.100 za intrinsic proof share, 675.000 za leaf payment i 4.200 gas za batch claim.
Predloženo je i ograničenje od 16.384 dependencies po bloku, do 256 claims po leaf-u i do 16 inputa po proof step-u.
Međutim, nijedna od ovih brojki još nije konačna.
Predlog zahteva dodatne benchmark testove, kalibraciju troškova i proveru ponašanja pod punim opterećenjem.
Najvažnije je da se trenutno radi samo o nacrtu.
Predlog još nema EIP broj, nije usvojen kao Ethereum nadogradnja i nema određen datum aktivacije na mainnetu.
Ako testiranja potvrde da sistem funkcioniše kako je zamišljeno, zajednička batch verifikacija mogla bi da omogući efikasnije korišćenje naprednih kriptografskih dokaza, uz fleksibilniji model plaćanja između sponzora, korisnika i block buildera.
