Framtiden för Ethereum-uppgraderingar, efter sammanslagningen [Del 2]

Ethereums största uppgradering någonsin – övergången till en konsensusmekanism för proof-of-stake – är precis runt hörnet. Men även om sammanslagningen borde lägga till säkerhet och hållbarhet, inkluderar den inte sharding, den efterlängtade metoden att skala nätverket. 

In Del I i vårt samtal med Ethereum Foundation (EF)-forskaren Danny Ryan, som har hjälpt till att koordinera uppgraderingsprocessen, diskuterade vi vad sammanslagningen är utformad för att ge när det gäller säkerhet och stabilitet.

I del II berättar Ryan om uppgraderingar som användare kan förvänta sig i framtiden, inklusive danksharding, statslöst Ethereum och säkerhetsuppdateringar som brottas med ökningen av gruvarbetare extraherbart värde (MEV). Han förklarar också hur detta år långa arbete resulterade i nya metoder för att undersöka och testa framtida uppgraderingar.

---

Samordning på ett decentraliserat nätverk

FRAMTID: Du anspelade på möjligheten att gruvarbetare kommer att gaffel och fortsätta att försöka använda den gamla kedjan. Men för det mesta har denna process fått alla ombord. Vad är din roll i det som en Ethereum Foundation-forskare? Hur samordnas ett så massivt drag?

DANNY RYAN: Jag började engagera mig i proof-of-stake-grejer runt 2017, och även då kändes det som en självklarhet. Det var fem år sedan. Och Ethereum-gemenskapen har varit mycket villiga att inte stagnera och att göra det rätt, och konstruera ett protokoll som inte bara fungerar idag utan fungerar, förhoppningsvis, i 100 år eller mer. 

Så tidigt i sitt etos, när det fanns en aning om att bevis på insats kunde göras säkert och bättre än bevis på arbete, var folk mycket glada över det. Och när 2016, 2017 rullar runt, är folk inte bara upphetsade över det, utan de är ängslig för att det ska hända. Det verkar som att det ligger väldigt djupt i Ethereum-gemenskapens etos att detta kommer att hända.

Det finns mer känsliga frågor. Det finns mindre förutsedda slutsatser där EF, forskarteamet och kunderna utanför EF försöker komma på lösningar på problem och hålla saker i rörelse. Ibland ligger lösningarna i en lite mer gråzon — är detta rätt lösning? Gör vi det nu? Gör vi det senare? Det slutar med att bli tufft, och EF försöker hjälpa till att samordna dessa metoder, hjälpa till med forskning och utveckling för att hjälpa veterinärlösningar, hjälpa till att underlätta samtal för att besluta om tidslinjer och prioriteringar och beställningar. 

Men i slutändan, på de flesta punkter, är EF-agendan att hjälpa till att göra protokollet mer hållbart, säkert och skalbart samtidigt som det är decentraliserat – och inte att skicka en viss funktion över den andra. Så mycket av det vi fokuserar på när det kommer till både tekniskt arbete och social samordning handlar om att underlätta bra information, bra forskning och bra dialog så att de många deltagarna som är involverade i FoU, tekniken och samhället kan behålla saker rör sig och kommer till beslut.

Under de senaste fem åren har det tillkommit mycket fler röster till samhället, och efter sammanslagningen kommer det teoretiskt att bli mer decentraliserat. Vilka tankar har du om den framtida processen för uppgraderingar? Är det möjligt att vi kommer att titta på någon sorts lager-ett DAO för att koordinera uppgraderingar?

Som jag förstår det, är Ethereum-gemenskapen inte intresserad av omröstning i kedjan – eller någon form av plutokratisk röstning och uppgraderingar – och att protokollet är det som användarna bestämmer sig för att köra. Generellt råder det bred enighet. Ibland finns det schismer - till exempel Ethereum vs Ethereum classic. Men i slutändan är det din rätt och samhällets rätt och användarnas rättigheter att ta reda på vilken programvara de vill köra. Generellt sett är vi överens eftersom människor försöker göra Ethereum bättre, och det finns inte mycket konflikter i några av kärnsakerna där. 

Så jag förväntar mig ingen formell teknisk mekanism. Jag förväntar mig att processen kommer att fortsätta växa och förändras och utvecklas i den här typen av lös styrning, där det finns forskare, det finns utvecklare, det finns community-medlemmar, det finns dapps och sådana saker. 

Jag skulle säga att – och jag tror att du anspelade på det – det är fler och fler människor vid bordet, och det blir svårare och svårare att fatta beslut och skicka saker. Jag tror personligen att det är en funktion. Jag tror att både ur tillförlitlighetssynpunkt för applikationer och användare, och för att undvika infångning i det långa loppet, att det förmodligen är viktigt för mycket av Ethereum-protokollet att förbena. Så även om det blir allt svårare att vara i förvaltningens malström och försöka skicka, och ibland känns det som att jag försöker springa med en viktväst och vikter på anklarna och nu har jag vikter på handlederna, tror att vi har några viktiga saker att göra under de närmaste åren. Men jag tror att det kommer att bli svårare och svårare att få saker gjorda. Och det tycker jag är bra.

Vitalik kallar det "funktionell flykthastighet.” Låt oss få Ethereum till en plats där den har tillräcklig skala och funktionalitet för att den kan utökas och användas på en oändlig mängd olika sätt i nästa lager av stacken. Låt EVM ha minst tillräcklig funktionalitet, har det tillräckligt med datatillgänglighet för att hantera stora mängder skala, och sedan kan applikationer utöka den i smarta kontrakt. Lager två kan experimentera med nya virtuella datorer inuti sina lager två-konstruktioner; du kan skala Ethereum och så vidare och så vidare.

Jag tror att det kommer att bli svårare och svårare att få saker gjorda. Och det tycker jag är bra.

Skugggafflar

En av sakerna som kom ut ur denna specifika testprocess var shadow forks, processen att kopiera riktig Ethereum-data till ett testnät för att simulera en mainnet-testmiljö. Var det alltid i planen? Och hur tror du att det kan förändra FoU-processen för framtida uppgraderingar?

Vi borde ha gjort skugggafflar de senaste fyra åren. De är bra; de är riktigt coola. Jag tar i huvudsak ett antal noder som vi kontrollerar - kalla det som 10, 20, 30 - och de tror att en gaffel kommer, så de är på huvudnätet eller ett av dessa testnät och sedan i något gaffeltillstånd, som blockhöjd, de alla säger "Okej, vi är på det nya nätverket." Och de delar sig och de umgås sedan i sin egen verklighet, men de har tillståndet mainnet-storlek.

Och för ett tag kan du överföra transaktioner från mainnet till denna kluven verklighet för att få en rimlig mängd av vad som ser ut som organisk användaraktivitet, vilket är riktigt bra. Det låter oss testa vad som slutade vara mycket organiska processer som är svåra att simulera. Och det har varit jättebra. Lika [Jayanthi] och andra som arbetar i DevOps-teamet på EF har orkestrerat dessa, och vi lärde oss så mycket av dem. Jag tror att om du frågar någon, skulle de vara som: "Ja, det hade varit bra om vi gjorde det här för tre år sedan, för fyra år sedan vid varje uppgradering."

Men jag säger en annan sak. Jag har sagt det [sedan] för ett år sedan och nu är vi i den långa svansen när det gäller säkerhet och testning: Det slår verkligen på den här grejen, se till att alla kantfall är korrekta, se till att det händer när det kommer. — Vi tar ett skott på det och det fungerar. Och det visar sig att det sätt som mjukvaran är konstruerad med konsensus-exekveringslagerklienter, det finns bara mycket att bygga när det gäller testning. Shadow forks är en av dem. Att använda andra simuleringsmiljöer som kan testa dessa två saker tillsammans, som Kurtosis, Antites, och andra. 

Det finns några andra saker vi behöver göra, som att koppla om Bikupa, som är vårt testramverk för integration på natten, så att det kan hantera båda dessa typer av klienter och så att du kan skriva tester där olika komplexiteter händer på båda sidor av gången. Allt som behövde hända. Först måste ramarna utvecklas eller modifieras. Sedan skulle många av proven skrivas. Så det fina med Merge är att vi verkligen har förbättrat verktygen i vårt verktygsbälte för att kunna testa uppgraderingar på ett sådant sätt att nästa uppgradering kommer att handla mycket mer om att skriva testerna snarare än att tänka på hur man ens testar det och skriva ramarna för att testa det. 

Vad är efter bevis på insats?

Eftersom detta har pågått under en lång tid, skulle skärvning till en början komma först. Men ekosystemutvecklingen innebar att du först kunde gå till bevis på insats. Fanns det andra ekosystemutvecklingar som dök upp under denna process som kan förändra ditt tillvägagångssätt mot framtida uppgraderingar?

Först och främst finns det förmodligen ett antal anledningar till att proof-of-stake-skiftet prioriterades. En var att sluta betala för mycket för säkerheten med bevis på arbete. Och den andra var att skalan började komma genom dessa lager-två-konstruktioner. Så, kanske om du har 10-100x skala som kommer från det, kan du fokusera på den här andra saken och avsluta jobbet och förena dessa två disparata system: beaconkedjan och det nuvarande huvudnätet. 

Det finns en del andra saker som har påverkat hur vi tänker kring tidslinjer och prioriteringar. Jag nämnde tidigare att hela MEV-världen har kastat en skiftnyckel i vissa saker. Det finns centralisering och andra säkerhetsproblem som dyker upp när du börjar fundera på vart MEV kan ta vägen. Och det har gjorts en hel del forskning under de senaste 12-plus månaderna om hur man kan mildra några av dessa problem med lager-ett-modifieringar. Beroende på analysen av hot som kommer från MEV-världen, kan det prioritera vissa säkerhetsfunktioner och säkerhetstillägg till L1 framför något annat som kanske förväntades vara prioritet. 

Jag tycker att något som är intressant är skärningsfärdplanen och den nuvarande förväntade konstruktionen, som kallas danksharding, uppkallad efter Dankrad [Feist], vår forskare vid EF. Hela konstruktionen förenklas faktiskt när man antar att dessa mycket incitamenterade MEV-aktörer existerar. Vissa av dessa externa aktörer har inte bara ändrat hur vi tänker kring säkerhet, utan de ändrar också hur vi kan tänka kring konstruktionen av dessa protokoll. Om du antar att MEV existerar, om du antar att dessa starkt incitamenterade skådespelare är villiga att göra vissa saker på grund av MEV, så har du helt plötsligt den här tredjepartsdeltagaren i konsensus om att du kanske kan ladda ner saker till, vilket på många sätt kan förenkla. Så det är inte bara dåliga saker som kommer, utan det finns också nya typer av design som öppnar sig.

Vi har verkligen förbättrat verktygen i vårt verktygsbälte för att kunna testa uppgraderingar på ett sådant sätt att nästa uppgradering kommer att handla mycket mer om att skriva testerna snarare än att tänka på hur man ens ska testa det.

Diskuteras och forskas statslösa Ethereum fortfarande aktivt? 

Ja. Staten – alla konton och kontrakt och saldon och sånt – det är Ethereums tillstånd. Med tanke på var du är i blockkedjan finns det ett verklighetstillstånd. Den saken växer med tiden, växer linjärt. Och ökar man gasgränsen växer den ännu snabbare. Så detta är ett bekymmer. Om det växer snabbare än minnet och hårddiskutrymmet på konsumentmaskiner, har du problem med att faktiskt kunna köra noder på hemdatorer och konsumenthårdvara, vilket har säkerhets- och centraliseringsproblem. Dessutom, om du pratar med några av de Geth [klient] teammedlemmar, det faktum att staten fortsätter att växa betyder att de måste fortsätta att optimera saker. Så det är svårt.

Stateless Ethereum och saker i den forskningsriktningen är en potentiell lösningsväg för detta, där för att exekvera ett block jag behöver faktiskt inte hela staten; det finns typ den här dolda ingången för att utföra funktionen för ett block. Jag behöver pre-state, jag behöver block, och sedan får jag post-state för att veta om blocket är giltigt. Medan med statslösa Ethereum är statens krav - konton och andra saker som du behöver för att utföra det specifika blocket - inbäddade i blocket och är bevis på att de är rätt tillstånd. Att nu köra ett block och kontrollera giltigheten av Ethereum blir att bara [måste] ha blocket, vilket är riktigt bra. Nu kan vi ha fulla noder som inte nödvändigtvis har fullt tillstånd. Det öppnar upp ett helt spektrum av hur man konstruerar noder. Så jag kanske har en nod som helt validerar och inte har tillståndet, jag kanske har en nod som bara håller tillståndet relevant för mig, eller så kanske jag har väldigt fulla noder som har alla tillstånd och den typen av grejer.

Detta arbetar man aktivt med. Det finns faktiskt, tror jag, för närvarande ett testnät med alla andra roliga saker som måste hända för att få detta att hända. Min nuvarande bedömning är att efterfrågan på skärvning och L1-skala är högre än det överhängande hotet om statlig tillväxt. Så det är mycket troligt, eftersom det ena kommer att prioriteras framför det andra, att skalan kommer att prioriteras. 

Som sagt, det är svårt att säga. Det finns "proto-danksharding, vilket är ungefär som ett stegvis sätt att få lite mer skala. Kanske händer det och så händer statslösa och sedan sker full skärning, beroende på behov och bedömning av vad som pågår och vilka hot som är inblandade. Jag tror att den allmänna tanken på statlig tillväxt är att vi måste ha en väg och vi måste fixa den, men [att] de överhängande bränderna har släckts och att detta inte är något som kommer att förlama Ethereum de närmaste åren. Men det är en sak som måste fixas.

Gå igenom uppgraderingarna som vi do vet för efter sammanslagningen. Kommer det att bli en städuppgradering? Är det skilt från Shanghai-uppgraderingen? Och när introduceras sharding?

Shanghai är sannolikt namnet på vilken gaffel som helst efter sammanslagningen. Att faktiskt ta ut dina pengar som du har satsat i nästan två år nu — [det blir] inte aktiverat vid sammanslagningen. De förväntades till en början göras, men med tanke på komplexiteten i sammanslagningen beslutades det med tiden att verkligen ta bort det och bara göra sammanslagningen och inte lägga till den extra funktionaliteten för uttag. Jag förväntar mig väldigt, väldigt, väldigt mycket att uttag är aktiverade i Shanghai – alltså den första uppgraderingen efter sammanslagningen. Detta har utlovats till många, många människor som har mycket kapital på gång och jag förväntar mig inga problem med det. Dessa är generellt specificerade, det finns tester skrivna och sånt. 

Det finns ett antal andra EVM [Ethereum Virtual Machine] förbättringar som jag tror skulle göra det i det här systemet – olika matematiska operationer, lite olika utökningsmöjligheter, lite bättre versioner inom EVM och andra funktioner. Det är lite av en tryckavlastningsventil på EVM-förbättringar, som har lagts åt sidan i flera år nu för att göra sammanslagningen och andra uppgraderingar. Och folk vill verkligen se någon form av mindre skalbarhetsuppgradering här. Så det kan vara antingen proto-danksharding, som lägger en del av grunden för full sharding och får lite mer skala, eller potentiellt calldata-gasprissänkningar, som är väldigt enkla men egentligen inte är en hållbar lösning. Så det är vad vi förhoppningsvis förväntar oss i Shanghai: uttag och lite skala.

Då är frågan: Vad händer efter det? Och det är svårt att säga. Om vi ​​får lite skala där, och det kompletterar L2:orna riktigt bra och saker och ting är ganska bra, så kanske det finns en efterfrågan på att göra statslösa vid den tidpunkten. Eller om L2s har ett omättligt behov av mer skala, så kanske det sätter upp scenen för den fullständiga danksharding.

Denna intervju har blivit redigerad och kondenserad. 

Upplagd 27 juli 2022