Vitalik Buterins argument for å flytte mye kryptografisk arbeid utenfor Ethereum-kjeden handler om forskjellen mellom beregninger og data. En innebygd, forhåndsoptimalisert funksjon – en såkalt precompile – kan gjøre en kryptografisk kontroll billigere å utføre. Men Ethereum må fortsatt motta dataene som skal kontrolleres. EIP-8288 foreslår i stedet å holde store kryptografiske datapakker utenfor blokkene der det er mulig, og samle verifiseringen i rekursive STARK-bevis. Forslaget står fortsatt med statusen Draft, altså utkast.
4
16
Hvorfor ikke bare legge til flere precompiles?
Precompiles er innebygde operasjoner som kan gjøre bestemte kryptografiske kontroller rimeligere. Men de løser ikke i seg selv kostnaden ved å frakte signaturene, bevisene eller andre data som kontrollene trenger. Buterin mener datakapasiteten – ikke bare gassen som brukes til verifisering – begrenser hvor mye kryptografisk materiale Ethereum kan håndtere. Han anslo en praktisk grense på rundt 8 MB i sekundet, selv med PeerDAS og blokker som inneholder blob-data. Dette er hans anslag, ikke en formell grense for calldata.
4
12
Det er også en avveining mellom fleksibilitet og kompleksitet. Hvis hver kryptografiske metode skal få sin egen precompile, kan det gjøre protokollen mer komplisert og kreve arbeid fra klientimplementasjonene. EIP-8288 tar sikte på å tilby én felles vei for å verifisere bevis fra ulike kryptografiske metoder.
7
16
Eksemplene i utkastet viser hvorfor dette kan ha betydning: Det omtaler hashbaserte signaturer på omtrent 2–3 kB og direkte verifiseringskostnader på 150 000–200 000 gas. Dette er anslag for et eksempel i forslaget, ikke en fast kostnad for alle signaturer eller implementasjoner.
10
Slik er EIP-8288 tenkt å fungere
Den offisielle EIP-en oppgir Vitalik Buterin og Thomas Coratger som forfattere og beskriver forslaget som en utvidelse av transaksjonsrammer i EIP-8141. Opplegget har tre hoveddeler:
16
- Transaksjoner viser til kompakte avhengigheter. Hver avhengighet identifiserer en metode, en hash av dataene og en hash av verifiseringsnøkkelen. Forslaget koder hver slik gruppe på 96 byte.
16
13
- De fullstendige kryptografiske dataene sendes mens transaksjonene videresendes. Store signaturer og bevis følger transaksjonene gjennom nettverket, i stedet for å legges inn i blokken i full størrelse. Deltakere i mempoolen – køen av ubekreftede transaksjoner – kan samle verifiseringsarbeidet.
15
16
- Verifiseringen samles i ett bevis. Den planlagte løsningen bruker rekursive STARK-bevis til å slå sammen kontroller. I stedet for hver enkelt kryptografiske datapakke skal blokken inneholde et samlet bevis. Målet er å redusere datamengden i blokken, ikke å øke nettverkets underliggende båndbredde.
6
15
16
Brukere kan også utføre krevende kryptografiske beregninger på sine egne enheter og levere STARK-bevis for resultatet. Målet er at Ethereum skal kunne støtte flere kryptografiske metoder uten å måtte bygge en egen precompile for hver av dem.
3
6
Hva kan endres – og hva kan ikke endres?
Hvis løsningen fungerer som planlagt, kan kompakte avhengigheter og samlet verifisering redusere hvor mye av de opprinnelige signatur- og bevisdataene som må inn i blokker. Gevinsten handler altså ikke bare om «raskere kryptografi»: Noe av arbeidet flyttes til brukerne og deltakerne i mempoolen, samtidig som mengden data Ethereum må ta inn på kjeden begrenses.
1
13
16
Det betyr ikke at kryptografiarbeidet blir gratis eller forsvinner. Brukere og nettverksdeltakere må fortsatt produsere, sende videre og verifisere relevante data og bevis. Kildene som er tilgjengelige, dokumenterer heller ikke at EIP-8288 vil gi en bestemt reduksjon i gas-kostnader eller løse Ethereums bredere skaleringsutfordringer.
Dette er fortsatt uavklart
Sikkerheten i bevis og hashfunksjoner. Utkastet peker på sikkerheten i verifiseringskretsene og funksjonene som lager avhengighetshashene, som forutsetninger for løsningen. En senere oppdatering knytter også blokkens avhengighetshash til aggregeringskretsen. Dette er sikkerhetstiltak som må vurderes, ikke dokumentasjon på at systemet er fullstendig verifisert eller bevist sikkert i drift.
32
Risiko for tjenestenektangrep i mempoolen. Aggregering innebærer mer datahåndtering og arbeid i mempoolen. Risiko for tjenestenektangrep er nevnt som et område som må vurderes, men materialet som er tilgjengelig her, viser ikke at alle beskyttelsestiltak er ferdige eller tilstrekkelige.
25
Utkastets grenser er ikke regler på hovednettet. Én offisiell versjon av utkastet setter grensen til 16 signaturavhengigheter og én STARK-avhengighet per transaksjon. Dette er parametere i utkastet, ikke regler som er innført på Ethereum.
32
Sikkerheten til gitterbaserte signaturer er omdiskutert. Ifølge omtale har Buterin åpnet for at gitterbaserte precompiles kan være aktuelle for blant annet kontoer og lommebøker dersom sikkerheten kan dokumenteres. Bekymringer om mulige AI-assisterte angrep er spørsmål som må undersøkes – ikke bevis for at gitterbaserte signaturer er knekket.
17
24
Den offisielle EIP-en står fortsatt som Draft, og omtalen beskriver simuleringer og arbeid på testnett snarere enn en godkjent innføring på Ethereums hovednett. Kildene som er tilgjengelige, viser ingen endelig beslutning om innføring eller fastsatt dato.
15
16