Ett stort tack för utmärkt input och feedback från Sacha Saint-Leger, Joseph Schweitzer, Josh Stark och protolambda.

Jag tillbringar mycket av min tid på att förklara och svara på frågor om eth2, och jag menar mycket. En del av detta på en djup och teknisk nivå när jag hjälper till att kommunicera forskning och specifikationer till tekniska bidragsgivare, men mer och mer i dessa dagar ställer jag frågor från samhället om eth2-framsteg, riktning, motivationer, designbeslut, förseningar och mer. Jag gillar verkligen dessa samtal. Jag blir super upphetsad när jag förklarar eth2, kommer med nya sätt att beskriva olika komponenter eller hitta rätt analogier beroende på publiken för att få växlarna att vrida och glödlampan att slå på.

Men denna dynamiska / konversationsmetod, även om den är värdefull, lämnar massor av samhället i mörkret. Jag får ställde samma frågor gång på gång, och närmare bestämt får jag samma frågor 6 månader senare! Det finns uppenbart ett informationsproblem. Denna information finns, men den är spridd över webben – forskningsinställningar, specifikationer, spec-förklarare, offentliga samtal, offentliga kanaler, reddit, blogginlägg. Mitt första försök efter devcon5 att överbrygga informationsgapet mellan dem som ligger djupt i eth2 och resten av samhället manifesterade sig som en ny bloggserie, ”eth2 quick update”. Det här är små utdrag för att följa med, men jag inser att de inte verkligen kommunicerar den större bilden. Den större bilden gör få kommunicerat och diskuterat på podcast, AMA: er och konferenser, men även då kommer en skriftlig form fortfarande att hjälpa dessa ansträngningar.

Så här är vi. Detta inlägg riktar sig till samhället, för att ge dig en omfattande titt på vad eth2 är idag: vart det håller på att gå, vad det kan bli, och vad det betyder för dig, Ethereum-samhället. Jag kommer att försöka tillhandahålla rätt mängd av teknisk substans för att illustrera motivationen, visionen, projektets nuvarande tillstånd och det kommande arbetet utan att fastna i för mycket matematik eller djup jargon.

Detta inlägg kan också vara användbart för de djupa Ethereum-tekniska experter som hittills har hållit eth2 på vapenavstånd. Inga bekymmer, förstår jag. Detta projekt är stort, komplicerat och verkade alltid som att det var tillräckligt långt i framtiden att du kunde ignorera det medan du löste de pressande problemen som finns. Förhoppningsvis kommer detta inlägg att hjälpa dig att bättre förstå saker som kommer.

När det gäller eth2-folket kanske du också får ut något av det här inlägget – ett bredare perspektiv på var vi befinner oss nu och hur jag tänker på saker som kommer.

Friskrivningsklausul: det är så Jag, Danny Ryan, personligen se saker i dag. Det finns många röster och åsikter som driver den ständigt växande och ständigt utvecklande etan. Detta är bara en stillbild av en bit av min tolkning.

eth2, wtf

“Eth2 är en skalbar infrastruktur för bevisning av insatser”

Om du har hört mig tala alls de senaste sex månaderna, har du hört mig säga detta gång på gång. Eth2 är byggt för Ethereum och i slutändan är Ethereum. Det syftar till att vara ett säkrare och skalbart sammanhang för den nuvarande Ethereum-mainnet, vilket ger en liten störning i hur saker och ting görs idag. Samtidigt ger det ett uppgraderat sammanhang för oss att växa till.

Sedan innan Ethereum lanserades, var det känt att ett enda blockchain-paradigm inte skulle ge tillräckligt med bandbredd för att fungera som ryggraden i ett nytt decentraliserat internet. Ethereum-relaterade bevisförsäkring och avskärmningsforskning spårar dess historia tillbaka till redan 2014. Både bevisförsäkring och avskärmning syftar till att besvara följande fråga: Med tanke på en viss mängd kapital som stöder ett krypto-ekonomiskt system, kan vi förbättra säkerheten och genomströmningen medan du fortfarande tillåter konsumentens hårdvara att delta i konsensus och följa kedjan? Medan jag inte kommer in i historien här, tog denna utforskning år och kännetecknades av många falska startar. I slutändan är svaret en rungande ja, och har manifesterat sig som eth2-projektet.

Eth2 är ett ambitiöst, flerårigt projekt som kommer att rullas ut i faser. Detta är allmänt dokumenterat och diskuterat, men jag kommer att ge dig en snabb, inte-så-teknisk titt på vad dessa innebär.

Fas 0

Fas 0, Beacon Chain, är kärnan i den nya konsensusmekanismen. Det är här all aktivitet på systemnivå och orkestrering sker. Fas 0 handlar om att komma till enighet med hundratusentals konsensusenheter (validerare), fördelade över tusentals noder runt om i världen.

På grund av de tekniska kraven för att distribuera delmängder av validatorer över skärvor i fas 1+, måste vi kunna hantera en enorm mängd validerare. Mycket av teknisk komplexitet härrör från detta krav. Andra icke-skärvda, proof-of-stake-mekanismer har 100-tal eller kanske 1000-tal validerare, men eth2 är utformad för att ha ett minimum av ~ 16 000 validerare med förväntan att denna siffra kommer att vara i hundratusentals inom ett par år .

Fas 1

Fas 0 handlar om att komma till enighet, medan fas 1 handlar om att komma till enighet om mycket av saker. Denna “grejer” kommer i form av många skärvkedjor. Du kan tänka på en skärvkedja som sin egen blockchain med ungefär samma komplexitet som Ethereum idag, men lever under eth2-konsensus (dvs lever under och byggs / kontrolleras av Beacon Chain). Validerarna från Beacon Chain får slumpmässiga kortvariga uppdrag för att bygga och validera skärvkedjor, vilket gör kryptoekonomiska åtaganden till staten, tillgänglighet och giltighet för varje kedja tillbaka till kärnsystemet.

I dag förväntar vi oss att det kommer att finnas 64 skärvor att starta, och för att den totala informationen som finns tillgänglig för systemet ska ligga inom intervallet 1 till 4 MB / s (JA, det är massor av data).

Fas 1.5

Fas 1.5 är integrationen av Ethereum mainnet i den nya eth2-konsensusmekanismen som ett skärv (existerande som en av de många skärvor som skapats i fas 1). Istället för att Ethereum vi känner och älskar byggs av en gruvalgoritm för ett arbetsprov kommer den att byggas av eth2-validerarna. För befintliga applikationer och användare kommer denna snabba byte av konsensusmekanismen till stor del att vara transparent. Program kommer att fortsätta chugga, men utvecklarna kommer nu att ha ett mycket kraftfullare system att bygga på (bättre säkerhetsegenskaper, korrekt ekonomisk slutlighet, mer lager 1-data för rollups och andra roliga applikationer).

Fas 2

Fas 2 är tillägget av tillstånd och körning på fler skärvor än bara den ursprungliga Ethereum-skärven. Det finns många former som detta kan ta. Att räkna ut vilken form, och detaljerna bakom det, är en het bädd av forskning och prototyper idag. Jag kommer att diskutera det lite mer i avsnitten nedan.

Okej, så vi har alla dessa faser som kommer och fas 0 känns som om det är precis runt hörnet. Men den färdplanen låter fortfarande lite lång. Vad ska jag faktiskt förvänta mig av eth2 under uppgraderingsfaserna?

Stor fråga! Generellt förväntar sig en våg av uppgraderingar som i allt högre grad berör mer av Ethereum och mer av samhället vid varje steg. Som användare kan du antingen engagera dig tidigt med insatser i fas 0, eller så kan du helt enkelt vänta tills Ethereum helt migrerar till eth2 i fas 1.5 (en övergång som bör vara sömlös ur såväl dapp-utvecklare som användare). Oavsett hur engagerad du väljer att vara och i vilken fas, det finns viktiga milstolpar och fördelar som är värda att vara medvetna om eftersom allt detta börjar rulla ut.

Den första är att jag vet att många av er är svåra ETH-innehavare som är angelägna om att komma in på stakes. För alla potentiella validerare där ute, särskilt hobbyarbetare, är fas 0 för dig. Fas 0 kommer med sina egna risker och tidshorisonter som gör det tilltalande för vissa deltagare, så jag hoppas personligen att denna fas är en välsignelse både för hobbyister och långsiktiga Ethereum-troende. Detta är en unik chans att komma in på marken, hjälpa till att påverka visionen över tid och få en högre ETH-belöning för att vara en tidig adopter.

Vad sägs om fas 1? Finns det något användbart med alla dessa uppgifter innan integrationen av Ethereum i eth2? Ja, glad att du frågade!

Lager 1-data är oerhört användbara även utan inhemsk beräkning. Faktum är att de mest lovande lager 2-skalningslösningarna under de senaste 12 månaderna är dessa så kallade “samla” -kedjor (både optimistiska och ZK) som skalas med tillgängligheten av lager 1-data. Eth2-dataskiktet förväntas ge Ethereum någonstans mellan 1 och 4 MB / s datatillgänglighet, vilket innebär enorma skalbarhetsförstärkningar i kombination med rollup-teknik. Men på grund av den ursprungliga osammanhanget av Ethereum och det nya skärvade universum i början, är det svårt att göra påståenden om eth2-skärvsdata. Det är en av orsakerna EIP 2537 är så viktigt för Ethereum mainnet. Med en inbyggd BLS (ny et2-signeringsalgoritm) förkompilerar kan vi skriva en effektiv eth2 light-klient som ett soliditetskontrakt, vilket öppnar upp för Ethereum-applikationer att göra anspråk på data i eth2 innan Fas 1.5-integrationen.

Som diskuterats ovan är fas 1.5 enorm. Eth2 är byggt för Ethereum och vid denna punkt, eth2 blir Ethereum. Alla applikationer som vi känner och älskar blir integrerade i den uppgraderade eth2-konsensusmekanismen, och behåller den funktionsuppsättning som vi är vana vid och samtidigt öppnar det enorma nya landskapet med en säker proof-of-stake-konsensus med ursprunglig tillgång till en mycket skalbar dataskikt. Detta är köttet i processen enligt min mening. Detta är ögonblicket med stor framgång när vi förankrar Ethereum till sin nya verklighet.

Utöver detta kommer ytterligare skalbarhetsvinster att göras över tid genom att möjliggöra tillstånd / exekvering på ytterligare skärvkedjor. Detta kan komma i form av EVM eller en ny VM som heter eWASM. Oavsett valet av VM kommer den befintliga Ethereum EVM-skärven och de nya skärvkedjorna att kunna interagera och kommunicera nativt via Beacon Chain och fullborda den multi-utförande, skärvade visionen.

Ser? Det är en resa, men det finns stora vinster att göra under vägen.

Svårigheterna med denna strategi, och varför det är värt det

Så många validerare

En nyckelkomponent för avskärning förlitar sig på slumpmässigt urval av konsensusdeltagare (validerare) i kommittéer för att validera ett underavsnitt av protokollet (t.ex. en skärva). Får tillräckligt med validerare i protokollet, och en angripare med en antagen maxstorlek (kontrollerande 1/3 av validerarna, säg) det blir matematiskt osannolikt (försvinna så, tänk sannolikhet i storleksordningen 1 / 2^40) för angriparen att köra över någon kommitté och skada systemet. Detta gör att vi kan utforma systemet så att vem som helst med en konsumentmaskin (t.ex. en bärbar dator eller kanske till och med en gammal telefon) kan bli en validerare (eftersom validerare tilldelas undersektioner i systemet, och validering av alla underavsnitt kan göras med beräkningen resurser för en enda maskin).

Det är detta som gör skärning otroligt och samtidigt svårt. För det första måste vi ha tillräckligt med validerare för att säkerställa detta slumpmässiga provtagning: vilket innebär att eth2 har mycket mer förväntade validerare än de flesta (tror jag någon) andra protokoll som visar beviset. Detta introducerar utmaningar i varje lager av processen – från forskning, till specifik samordningsmekanism, till nätverk, till resursförbrukning och optimeringar hos kunder. Varje ytterligare validator inducerar belastning på systemet som måste redovisas i varje steg i processen. Eth2-klientteam har genomfört Herculean-uppgiften att hantera konsensus från hundratusentals validerare så att vi säkert kan integrera många skärvor i fas 1.

Så många skärvor

Ett annat grundläggande designbeslut som gör det vi bygger så hårt är att vi i Ethereum väljer att få skalbarhet utan kompromissa med decentralisering.

Det är inte svårt att skala en blockchain till tiotusentals transaktioner per sekund, om vi inte bryr oss om att användare faktiskt kan validera kedjan för sig själva eller om att garantera att informationen faktiskt är tillgänglig för nätverket. Komplexiteten hos en skärvad konsensusmekanism krävs så att systemet kan brytas upp i bitstorlekar som kan valideras. Att specificera och implementera en sådan konsensusmekanism är helt enkelt en svår uppgift.

Så många klienter

En grundläggande princip för Ethereum är att Ethereum är protokoll först. Ethereum är den abstrakta uppsättningen regler som utgör protokollet snarare än något specifikt genomförande av dessa uppsättningar av regler. För detta ändamål har Ethereum-samfundet uppmuntrat många klientimplementeringar sedan dag 0. På Ethereum mainnet idag kommer detta i form av besu, ethereumJS, geth, nethermind, nimbus, open-ethereum, treenighet och turbo-geth. Och i eth2-landskapet manifesteras detta som cortex, fyr, lodestar, nimbus, prysm, teku och treenighet.

Multiklientparadigmet har många betydande fördelar:

  • Att ha många klienter möjliggör en bredare utforskning av idéer, algoritmer och arkitekturer (varje klient har sin egen inställning och synvinkel). Det finns en sund koll pollinering i denna process eftersom vi alla bygger mer robusta system.
  • Kunderna har ofta olika designmål. Detta leder till en mer mångfaldig uppsättning av användare och applikationer när tiden går. Kunder kan vara mer eller mindre fokuserade på något av följande: prestanda, säkerhet, horisontell skalning, UI / UX, lätta klienter, webbläsare, resurskontrollerade enheter, etc, etc.
  • Med många kunder i produktionskvalitet på mainnet möts en betydande attack som kan föra ner alla klienter (t.ex. en DoS-attack) med motståndskraft eftersom resten av klienterna är starka. Detta sågs mycket tidigt i Ethereums historia under “Shanghai DoS Attacks” när en serie av DoS-attacker kunde få ned geth och paritet men aldrig båda samtidigt.
  • Varje klient fungerar som en gateway till ett programmeringsspråk community. Grunden för en klient på ett visst språk öppnar och bjuder in experiment och innovation på det språket. Basverktyget runt klienten snöbollar ofta i ett robust ekosystem av verktyg och bidragsgivare på det språket. Multiklientparadigmet förstärker gravitationskällan som är Ethereum.

Med dessa distinkta fördelar kommer vissa svårigheter:

  • Specifikationerna och testerna måste vara lufttäta för att undvika oavsiktlig gaffel på mainnet. Om det bara finns en implementering av protokollet, då implementeringen blir protokollet. I fallet med en enskild klient, om det fanns någon slags konsensus “bugg” hit på mainnet, skulle det bli bakat i verkligheten i protokollet. Detta är inte bra ur ett renhetsperspektiv, men det eliminerar risken för oavsiktlig gaffel. Som en motsats till denna svårighet – om vi har en sund distribution av klienter på mainnet (t.ex. har ingen klient mer än 1/3 av totala noder / validerare), kan nätverket förbli levande även inför en enda klient som har enighet problem.
  • Samordning av N klienter ger i bästa fall en linjär omkostnad jämfört med bara en enskild klient, men i vissa fall kan det leda till en kvadratisk overhead (N^2). Det finns tekniker som vi använder för att minska denna omkostnad – t.ex. konsensus (och snart nätverk) testsviter – men det kommer alltid att finnas där i viss kapacitet.

Tillstånd för eth2-klienter och testnät

Fas 0 eth2-klienter har blivit ganska sofistikerade programvara under de senaste två åren och har kunnat hantera det distribuerade samförståndet med hundratusentals validerare över tusentals noder. Vi är för närvarande i testnätfasen och tappar närmare lanseringen varje dag. Jag förväntade mig att den sista milen skulle vara lång. Det visar sig att det är det.

Jag ber er under denna period före lansering, att komma ur din komfortzon och prova flera klienter. Det finns många avvägningar mellan dem och du måste bli smutsig för att ta reda på vilka som fungerar bäst för dig. Som diskuterats ovan verkar Ethereum i ett multiklientparadigm. För att få fördelarna med detta paradigm behöver vi användare att driva en mängd olika klienter (för att skapa en sund distribution över alla typer av klienter).

Utöver det finns det antikorrelationsincitament inbyggda i protokollet. I extrema situationer där en större klient oavsiktligt gör att validerare antingen går offline eller begår ett streckbart brott, om din validators beteende är korrelerad med den klienten, kommer du att straffas mycket mer än om du gjorde något fel men okorrelerat med andra. Med andra ord, i dessa situationer är det mycket bättre att driva en minoritetsklient snarare än en klient med en enorm del av nätverket.

För att vara helt tydligom det finns mer än en livskraftig och säker klient är det din skyldighet att driva minoritetsklientprogramvara för att främja en sund distribution av klientprogramvara i nätverket.

Var inte heller blyg. Om du stöter på problem med dokumenten, låt någon veta det. Om du ser en skrivfel, skicka in en PR. Om något kraschar eller ett fel dyker upp, snälla snälla snälla rapportera det på github eller klienten. Du är betabrukare och med din hjälp kan vi göra detta bättre för alla.

Testnets

Vi driver för närvarande små offentliga devnets, som vi startar ungefär varannan vecka. Jag säger “devnet” eftersom de först och främst är för kundteamsutvecklare att arbeta igenom buggar, optimeringar osv. De är offentliga och du är välkommen att gå med, men var medveten om att de ännu inte har levt som Goerli eller Rinkeby. Den senaste lanseringen, ledd av Afri Schoedon, är Witti testnet kör v0.11-specifikationen (kolla in LÄS här om du vill köra några noder).

Kundteam uppgraderar aktivt till v0.12 spec som integrerar den senaste versionen av IETF BLS-standarden. Därifrån överför vi devneterna till v0.12 när vi fortsätter att öka storleken på näten, vilket ger mer och mer belastning på klienterna. Efter att vi har 2-3 kunder på ett tillförlitligt sätt startar framgångsrika v0.12-nät och kör med hög belastning, gör vi ett mer offentligt testnät där du kommer att köra de flesta noder och validerare. Avsikten här är att skapa ett långvarigt multiklienttestnät som efterliknar mainnet så mycket som möjligt (där användare på ett tillförlitligt sätt kan öva på att köra noder och testa allt annat de vill). Idealet är att snurra upp detta bara en gång och sortera igenom eventuella fel samtidigt som du behåller nätet. Men beroende på misslyckades närvaro och svårighetsgrad kan vi behöva ett par körningar innan vi kommer dit.

Förutom de vanliga testnätet kommer vi också att erbjuda ett incitament “attacknät” där klientteam använder ett stabilt testnät, och vi inbjuder dig att försöka bryta det på ett antal olika sätt. För framgångsrika attacker kommer EF att ge ETH-belöningar. Mer information om detta snart – så håll dig anpassad!

Även om verktyget för eth2 är ganska nybörjande, är det en spännande och växande insats. Som nämnts ovan kommer verktyg ofta från en klientkodbas och klientteamets ansträngningar, men fler och fler händer involveras varje dag. För att bättre interagera med, förstå, säkra och förbättra eth2 måste vi som samhälle bygga ut och bygga på grundläggande eth2-verktyg.

Jag vill ge ett enormt utrop till de lag och individer som redan har gett enormt värde med sina eth2-verktyg, och jag vill välkomna alla andra att bygga nya verktyg och utvidga och förbättra det som redan finns.

Eth2-verktyg är en möjlighet på grönt område. Detta är en otrolig chans att gräva in, ge verkligt värde och sätta ditt märke.

Följande är ett exempel på det pågående arbetet, men det finns mycket mer att göra!

Och här är ett urval av några öppna verktygsidéer:

  • Eth2-validatorvarningar: tillhandahålla en tjänst som varnar nodoperatörer när deras validatorer inte fungerar optimalt
  • Validator insättningsspårning: hjälp överbrygga mellan de aktuella Ethereum och eth2 explorers genom att spåra validator insättningsprocessen
  • Validatorskydd via proxyservrar: använd ett proxy för att spåra valideringsmeddelanden för att säkerställa att din klient inte kan skicka osäkra meddelanden

Och så mycket mer – det är den typ av bidrag som inte är begränsad till en specifik. Kreativitet är viktigt. Om du vill bidra, prata med eth2-klientteam för att komma igång.

Tillståndet för eth1 + eth2-integrationer

I en Ethereum-klient idag (t.ex. geth, etc) ligger nästan all komplexitet i att hantera aktivitet på användarnivå – transaktionspool, blockering, virtuell maskinberäkning och tillstånd / lagring / återhämtning av tillstånd. Själva kärnkonsensus – proof-of-work – är ganska enkelt i protokoll. Det mesta av komplexiteten hanteras av sofistikerad hårdvara utanför kärnprotokollet.

Å andra sidan är en eth2-klient helt konsensus. När det gäller bevisning av insatser och skärning, införs många komplexiteter i protokollet för att uppnå målen för ett skalbart samförstånd.

Denna åtskillnad av oro gör det möjligt för en vacker parning av eth1- och eth2-klienter.

Det påbörjas inledande arbete med att slå samman de två av medlemmarna i geth (EF) och TXRX (ConsenSys). Arbetet innefattar (1) att definiera ett kommunikationsprotokoll mellan eth1 och eth2-klienter, (2) lägga till en konsensusmotor till eth1-klienter som kan kontrolleras via kommunikationsprotokollet, och (3) prototypning och simulering av eth2-fas 1-beteende för att testa kopplingen . Vi förväntar oss att se några konkreta resultat på dessa punkter i sommar.

Du kan läsa mer om eti + eth2-klientförhållandet på hög nivå häroch om det tekniska räckvidden för fusionen här.

Tillståndets utförande och kommunikation över skärvor

Som nämnts är den exakta vägen för att möjliggöra körning över många skärgårdar ett hett undersökt och diskuterat område. Det finns många frågor att svara på. Till exempel:

  • Hur många skärvor ska vara möjliga vid körning?
  • För ytterligare skär, använder vi EVM eller eWASM för den virtuella maskinen?
  • Hur strukturerar och bearbetar vi effektivt trans-shard-transaktioner?
  • Vilka förändringar måste vi göra i befintlig EVM för att stödja cross-shard-transaktioner?
  • Kan / bör utförande och kontostrukturer i allmänhet vara utdragbara?

Teamet eWASM (EF) och Quilt (ConsenSys) har forskat mycket på dessa områden under de senaste 12 månaderna. Det visar sig att lösningsdomänen är enorm, och även om vi nu har ett bra grepp om domänens bredd har det senaste fokuset varit att gräva i enkla, konkreta lösningar för att kunna testa, prototypa och verkligen markera konversationen. Av detta föddes eWASM: s Eth1x64-initiativ (läs om projektet på hög nivå och kolla in några senaste specifikationer som diskuteras).

Det har skett snabba framsteg när det gäller att ta med de abstrakta korsskärmsidéerna i konkreta specifikationer för diskussion och i slutändan prototyper. Håll ett öga på detta område med framsteg, särskilt om du är en dapp-utvecklare. Vi tänker ha något du kan förstå, spela med och ge feedback om under de kommande månaderna.

Förhållande mellan statslös Ethereum och eth2

Det finns en annan viktig FoU-insats som sker parallellt med eth2 som kallas ”Stateless Ethereum”. Stateless Ethereum är ett försök att lösa tillväxtproblemet för tillståndsstorlek. Det gör det möjligt för deltagarna att validera block utan måste lagra hela staten lokalt. Just nu finns det en implicit input i Ethereum-övergångsfunktionen: statens helhet. Med Stateless Ethereum kommer bevis (vittnen) om det nödvändiga tillståndet att tillhandahållas inuti blocken. Detta gör att ett block kan överföras / valideras som en ren funktion för bara blocket.

Vad detta betyder för användare är en värld där du kan följa kedjan och till och med följa delar av staten som du bryr dig om, utan lagra hela staten. Vissa nätverksdeltagare kommer sannolikt att lagra hela staten (blockproducenter, blockutforskare, tillhandahållare av statligt för en avgift), men den stora majoriteten av deltagarna kommer att bli en viss skugga (mindre än full) av tillstånd.

För eth2 är detta en viktig teknisk mekanism för att säkerställa att noder och validerare kan validera och säkra protokollet utan att börda för att lagra hela användarstatus för varje skärv. I stället kommer validerare sannolikt att välja att vara blockproducenter för vissa uppsättningar av skärvor, medan baslinjevalideraren bara kan validera statslösa block. Stateless Ethereum är ett otroligt värdefullt tillägg till eth2-visionen, vilket håller basen på det skärvade protokollet mycket tunt. Medan vi planerar att driva eth2 statelessly, har vi några alternativ i händelse av att den statslösa vägen till slut inte blir livskraftig (även om jag själv är ganska säker på statslöshet 😄).

Jag kommer inte gå djupare in i Stateless Ethereum för det här inlägget. Vet bara att det är en spännande parallell FoU-väg att säkerställa Ethereums hållbarhet på lång sikt. Om du är nyfiken på att lära dig mer, kolla in Griffins 1.x-filerna bloggserie.

tl; dr

Eth2 är ett enormt åtagande att tillhandahålla en uppgraderad, nästa generations, mycket skalbar och säker, decentraliserad konsensus till Ethereum. Det finns dussintals team och hundratals individer som arbetar varje dag för att göra detta till verklighet. Den väg vi har valt är svår, men enorma framsteg har och fortsätter att göras.

Kärnan i denna nya mekanism är precis runt hörnet.

Om du är en blivande validerare är det nu dags att gräva in. Stödja multiklientparadigmet genom att pröva flera klienter och hjälpa till att skapa en stark bas av rik klientdiversitet från eth2: s uppkomst.

Om du är en användare eller dapp-utvecklare, fortsätt att trycka på Ethereum idag medan vi fortsätter att förbereda detta säkrare och skalbara sammanhang för dig. När tiden kommer kommer bytet till eth2 att vara så sömlöst som möjligt.

Tack till de otroliga lagen och individerna som håller Ethereum levande och bra idag; tack till er alla som förbereder sig för Ethereums framtid inom eth2; och tack till alla användare och utvecklare som gör Ethereum fantastiskt 🚀

LEAVE A REPLY

Please enter your comment!
Please enter your name here