Vitalik Buterins argument för att flytta en stor del av Ethereums kryptografiska arbete utanför kedjan handlar om skillnaden mellan beräkning och data. En så kallad precompile kan göra en viss kryptografisk kontroll billigare att utföra, men Ethereum måste fortfarande ta emot datan som ska kontrolleras. EIP-8288 föreslår i stället att stora kryptografiska underlag hålls utanför blocken när det går och att verifieringen samlas i rekursiva STARK-bevis. Förslaget har fortfarande statusen Draft, alltså utkast.
4
16
Varför inte bara lägga till fler precompiles?
Precompiles är inbyggda funktioner som kan göra särskilda kryptografiska beräkningar billigare. Men de löser inte i sig kostnaden för att föra in signaturerna, bevisen eller andra indata som beräkningen kräver. Buterin menar att datakapaciteten – inte bara gasen som går åt till verifiering – begränsar hur mycket kryptografiskt material Ethereum kan hantera. Han uppskattade den praktiska gränsen för dataflödet till omkring 8 MB per sekund, även med PeerDAS och block som innehåller blob-data. Det är hans uppskattning, inte en formell gräns för calldata.
4
12
Det finns också en avvägning kring flexibilitet. Om varje kryptografiskt system får en egen precompile blir protokollet mer komplext, och varje klientimplementation behöver stödja den. EIP-8288 siktar i stället på en gemensam väg för att verifiera olika kryptografiska system.
7
16
Utkastet visar varför frågan kan spela roll med ett exempel: hashbaserade signaturer på omkring 2–3 kB och en direkt verifieringskostnad på 150 000–200 000 gas. Det är uppskattningar för ett exempel i förslaget, inte en generell kostnad för alla signaturer eller implementationer.
10
Så är EIP-8288 tänkt att fungera
Den officiella EIP-texten anger Vitalik Buterin och Thomas Coratger som författare och beskriver förslaget som en utvidgning av transaktioner med så kallade frame-ramar enligt EIP-8141. Upplägget har tre huvuddelar:
16
- Transaktioner anger kompakta beroenden. Varje beroende pekar ut ett system, en hash för datan och en hash för verifieringsnyckeln. Enligt förslaget kodas varje sådan trippel på 96 byte.
16
13
- Det fullständiga kryptografiska underlaget skickas medan transaktionerna sprids. De större signaturerna eller bevisen följer med transaktionerna genom nätverket, men blocket behöver inte innehålla hela originalunderlaget. Deltagare i mempoolen – där transaktioner väntar på att tas med i block – kan samordna verifieringen.
15
16
- Verifieringen slås ihop. Den avsedda lösningen använder rekursiva STARK-bevis för att samla flera kontroller. I stället för varje enskilt kryptografiskt underlag skulle blocket innehålla ett samlat bevis. Syftet är att minska mängden data som blocken behöver bära, inte att höja nätverkets grundläggande bandbreddsgräns.
6
15
16
Användare skulle också kunna utföra krävande kryptografiska beräkningar på sina egna enheter och lämna in STARK-bevis för resultatet. Målet är att Ethereum ska kunna stödja fler kryptografiska system utan att behöva bygga en separat inbyggd precompile för varje system.
3
6
Vad kan förändras – och vad kan inte det?
Om metoden fungerar som tänkt kan kompakta beroenden och samlad verifiering minska mängden ursprunglig signatur- och bevisdata som behöver finnas i blocken. Vinsten handlar alltså inte bara om ”snabbare kryptografi”. En del arbete flyttas till användare och deltagare i mempoolen, samtidigt som mängden data som Ethereum måste ta med på kedjan begränsas.
1
13
16
Det innebär inte att kryptografins kostnader försvinner. Användare och nätverksdeltagare behöver fortfarande skapa, sprida och verifiera relevanta data och bevis. De tillgängliga källorna visar inte att EIP-8288 kommer att ge en viss minskning av gasförbrukningen eller lösa Ethereums bredare skalningsbegränsningar.
Det här är fortfarande osäkert
Säkerheten i bevis och hashfunktioner. Utkastet pekar ut säkerheten i verifieringskretsarna och funktionerna som skapar beroendehashar som antaganden lösningen bygger på. En senare uppdatering band även blockets beroendehash till aggregeringskretsen. Det är skyddsåtgärder som behöver granskas – inte bevis för att systemet har verifierats fullständigt eller visat sig säkert i drift.
32
Risk för överbelastningsattacker mot mempoolen. Aggregering innebär mer arbete och datahantering i mempoolen. Risken för överbelastningsattacker finns med bland områdena som behöver bedömas, men det tillgängliga underlaget visar inte att alla skydd är färdiga eller tillräckliga.
25
Utkastets parametrar är inga regler för huvudnätet. En officiell version av utkastet sätter gränser på 16 signaturberoenden och ett STARK-beroende per transaktion. Det är förslagets parametrar i en utkastversion, inte regler som har införts på Ethereums huvudnät.
32
Säkerheten hos gitterbaserade signaturer är fortfarande en fråga. Enligt rapportering har Buterin lämnat öppet för gitterbaserade precompiles för exempelvis konton och plånböcker, om säkerheten kan visas. En rapporterad oro för möjliga AI-assisterade attacker är något att undersöka – inte ett belägg för att gitterbaserade signaturer har knäckts.
17
24
Den officiella EIP:n har fortfarande statusen Draft. Rapporteringen beskriver arbete med simuleringar och testnät, inte ett godkänt införande på huvudnätet. De tillgängliga källorna visar inte att ett beslut om införande har fattats eller att ett datum är bestämt.
15
16