EIP-8032 (och EIP-2926 för den delen) levereras med en konverteringsprocess. Det kom till min kännedom att denna process är dåligt förstådd, även av kärnutvecklare. Inför nästa ACDE skriver jag en snabb förklaring.

I grunden är det inget annat än en enkel iterator, som går igenom räkenskaper och räknar blad. När alla blad har räknats läggs den räkningen till som ett fält i kontot. Varje block avancerar iteratorn med N positioner. Konverteringen avbryts när sista positionen nås.

Här betyder "position" antingen ett konto eller en plats, där iteratorn kunde "stanna". På grund av mängden data är det viktigt att iterationen slutar vid en "säker" punkt och fortsätter vid nästa block.

Låt oss titta på följande förenklade exempel. Det finns mycket mindre data i staten än i verkligheten, och trädet är ett binärt träd, men exemplet är annars korrekt. ∅-symbolen betyder ett konto utan lagring. Om det saknas har kontot ett lagringsträd.

Inledningsvis sätts iteratorn till 0, det vill säga - kontohashposition = 0 - slot hash-position = 0 Den avbildas med en röd pil.

I detta exempel tar vi iteratorsteget N = 2 (i praktiken N > 10_000). Vid gaffelblocket rör sig iteratorn två positioner. Den första positionen är ett konto utan lagring, så inget görs.

Fortfarande vid gaffelblocket flyttar iteratorn till andra positionen, vilket är en plats (dvs. iteratorn stannar vid ett kontos lagring innan den stannar vid själva kontot). Platsräknaren är inställd på 1, och eftersom iteratorn har sprungit hela sin sträcka mot gaffelblocket stannar den.

Vid nästa block täcker iteratorn återigen två positioner: - Den första är den andra platsen på det andra kontot, för vilken räknaren ökades - Den andra är det andra kontot självt. Värdet på räknaren läggs till som ett kontofält och räknaren återställs.

Vid följande block (fork + 2) går iteratorn över de två platserna på det tredje kontot, men dess steg nås innan kontot självt (nästa position) uppdateras med räknaren (som är 2).

Sista blocket i konverteringen får det tredje kontot en räknare, och sedan kontrolleras det sista kontot för tillstånd (vilket det inte har, så ingen uppdatering behövs).

Eftersom det inte finns några fler konton avslutas iteratorn och konverteringen är klar.

Vad händer om lagring läggs till på konto A efter att iteratorn har passerat konto A? Räknaren inuti A ökas helt enkelt.

Vad händer om lagringen läggs till på kontot som konverteras? - före iteratorn: inget att göra eftersom iteratorn räknar det när den kommer dit - efter att iteratorn passerat: lagra den på kontot, lägg till den i iteratorräknaren efter att platsuppräkningen avslutats

När gäller gaskostnaderna? När kontot har konverterats.

Hur länge kommer konverteringen att vara? Beroende på hur det går kan det vara upp till en månad. Värdet väljs så att den tillagda beräkningen är försumbar jämfört med vanlig blockoperation. 10_000 ärvs från Verkle och skulle ta en månad. Benchmarks skulle definitivt hitta ett snabbare värde

Och det var allt, tack för att du läste ända till slutet 🫶