Ethereum själv måste klara walkaway-testet. Ethereum är tänkt att vara ett hem för förtroendelösa och förtroendeminimerade applikationer, vare sig det gäller finans, styrning eller någon annanstans. Den måste stödja applikationer som är mer som verktyg – hammaren som, när du köper den, är din – än som tjänster som förlorar all funktionalitet när leverantören tappar intresset för att underhålla dem (eller ännu värre, blir hackad eller värdeutvinningsinriktad). Även när applikationer har funktionalitet som är beroende av en leverantör kan Ethereum hjälpa till att minska dessa beroenden så mycket som möjligt och skydda användaren så mycket som möjligt i de fall där beroendena misslyckas. Men att bygga sådana applikationer är inte möjligt på ett baslager som i sig är beroende av löpande uppdateringar från en leverantör för att fortsätta vara användbart – även om den "leverantören" är hela kärnutvecklarnas process. Ethereum som blockkedja måste ha de egenskaper vi strävar efter i Ethereums applikationer. Därför måste Ethereum själv klara walkaway-testet. Detta innebär att Ethereum måste nå en punkt där vi _can förstena om vi vill to_. Vi behöver inte sluta göra ändringar i protokollet, men vi måste nå en punkt där Ethereums värdeerbjudande inte strikt beror på några funktioner som inte redan finns i protokollet. Detta inkluderar följande: * Full kvantresistens. Vi bör motstå fällan att säga "låt oss skjuta upp kvantresistens till sista möjliga stund i syfte att få fram fler effektiviseringar lite längre". Enskilda användare har den rätten, men protokollet borde inte göra det. Att kunna säga "Ethereums protokoll, som det ser ut idag, är kryptografiskt säkert i hundra år" är något vi bör sträva efter att nå så snart som möjligt och insistera på som en stolthet. * En arkitektur som kan expandera till tillräcklig skalbarhet. Protokollet måste ha de egenskaper som gör att det kan expandera till många tusen TPS över tid, särskilt ZK-EVM-validering och dataprovtagning via PeerDAS. Idealiskt kommer vi till en punkt där ytterligare skalning sker genom "endast parameter"-ändringar – och idealiskt är _dessa_ ändringar inte BPO-liknande forks, utan görs med samma validatorröstningsmekanism som vi använder för gasgränsen. * En statsarkitektur som kan bestå i årtionden. Detta innebär att besluta och implementera vilken form av delvis tillståndslöshet och tillståndsutgång som gör att vi känner oss bekväma med att låta Ethereum köras med tusentals TPS i årtionden, utan att bryta synkronisering, hårddisk- eller I/O-krav. Det innebär också att framtidssäkra träd- och lagringstyperna för att fungera väl i denna långsiktiga miljö. * En kontomodell som är allmän (detta är "full account-abstraktion": gå bort från inskriven ECDSA för signaturvalidering) * Ett gasschema som vi är säkra på är fritt från DoS-sårbarheter, både för genomförande och för ZK-prov * En PoS-ekonomisk modell som, med allt vi lärt oss under det senaste halvdecenniet av proof of stake i Ethereum och ett helt decennium därefter, vi är övertygade om kan bestå och förbli decentraliserade i årtionden, och som stöder användbarheten av ETH som förtroendelös säkerhet (t.ex. i styrningsminimerade ETH-backade stablecoins) * En blockbyggarmodell som vi är säkra på kommer att motstå centraliseringstryck och garantera censurmotstånd även i okända framtida miljöer Idealiskt sett gör vi det hårda arbetet under de kommande åren för att nå en punkt där nästan all framtida innovation i framtiden kan ske genom kundoptimering och återspeglas i protokollet genom parameterändringar. Varje år borde vi bocka av minst en av dessa kriterier, och helst flera. Gör det rätta en gång, baserat på kunskap om vad som verkligen är rätt (och kompromissa inte halvvägs-lösningar), och maximera Ethereums teknologiska och sociala robusthet på lång sikt. Ethereum går hårt. Det här är gwei.