Fortsätt att det kommer

tldr;

Runtime Verification revision och verifiering av insättningsavtal

Runtime Verification avslutade nyligen sin granskning och formell verifiering av eth2 insättningsavtal bytekod. Detta är en betydande milstolpe som leder oss närmare et2 fas 0-mainnet. Nu när detta arbete är klart ber jag om granskning och kommentar från gemenskapen. Om det finns luckor eller fel i den formella specifikationen, skicka ett problem på eth2 specifikationer repo.

Den formella semantiken som anges i K ramverk definiera de exakta beteenden som EVM-bytekoden ska exibit och bevisar att dessa beteenden gäller. Dessa inkluderar inmatningsvalideringar, uppdateringar av iterativt märle-träd, loggar och mer. Ta en titt här för en (semi) diskussion på hög nivå av vad som specificeras och gräva djupare här för fullständig formell K-specifikation.

Jag vill tacka Daejun Park (Runtime Verification) för att ha ledat ansträngningen, och Martin Lundfall och Carl Beekhuizen för mycket feedback och granskning på vägen.

Återigen, om det här är din kopp te, är det nu dags att ge input och feedback om den formella verifieringen – ta en titt.

Månadens ord är “optimering”

Den senaste månaden har handlat om optimeringar.

Även om en 10x-optimering här och en 100x-optimering där inte känns så påtaglig för Ethereum-samhället idag, är denna utvecklingsfas lika viktig som alla andra för att få oss till mållinjen.

Beacon-kedjeoptimeringar är avgörande

(varför kan vi inte bara maximera våra maskiner med fyrkedjan)

Fyrkedjan – kärnan i eth2 – är en nödvändig komponent för resten av det skärvade systemet. För att synkronisera varje skärv – oavsett om det är en enda skärm eller många, en klient måste synkronisera fyrkedjan. För att kunna driva fyrkedjan och en handfull skärvor på en konsumentmaskin är det alltså viktigt att fyrkedjan är relativt låg i resurskonsumtion även vid högt valideringsdeltagande (~ 300k + validerare).

För detta ändamål har mycket av ansträngningen från eth2-klientteam under den senaste månaden ägnats åt optimeringar – att minska resursbehovet i fas 0, fyrkedjan.

Det gläder mig att rapportera att vi ser fantastiska framsteg. Följande är inte omfattande, men är istället bara en glimt för att ge dig en uppfattning om arbetet.

Fyren kör 100k validerare som en bris

Fyren tog ner deras ~ 16k validator-testnät för ett par veckor sedan efter att en vittnar om skvaller relä loop orsakade noderna i huvudsak DoS sig själva. Sigma Prime lappade snabbt detta fel och tittade på större och bättre saker – det vill säga ett testnät på 100 k! De senaste två veckorna har ägnats åt optimeringar för att göra detta verkliga testnät till verklighet.

Ett mål för varje progressivt fyrtest är att se till att tusentals validerare enkelt kan köras på en liten VPS-utrustning med 2 CPUS och 8 GB RAM. Inledande tester med 100 000 validatorer såg kunder använda en konsekvent 8 GB RAM, men efter några dagars optimering kunde Paul reducera detta till ett stabilt 2,5 GB med några idéer för att få det ännu lägre snart. Lighthouse gjorde också 70% vinster i hashing av tillstånd som tillsammans med BLS signaturverifiering visar sig vara den viktigaste beräkningsflaskhalsen i eth2-klienter.

Den nya fyrtorns testnets lansering är nära förestående. Dyka upp deras oenighet att följa framstegen

Prysmatic testnet fortfarande chugging och synk har förbättrats massivt

För ett par veckor sedan det aktuella Prysm-testnätet firade sin 100 000: e slot med över 28 000 validerare som validerar. Idag passerade testnätet slot 180k och har över 35 000 aktiva validerare. Att hålla ett offentligt testnät igång medan du samtidigt tar bort uppdateringar, optimeringar, stabilitetspapper, etc. är ganska en prestation.

Det finns massor av påtagliga framsteg i Prysm. Jag har pratat med ett antal validerare under de senaste månaderna och ur deras perspektiv fortsätter klienten att förbättras markant. Ett särskilt spännande objekt är förbättrade synkhastigheter. Prysmatic-teamet optimerade sin klientsynkronisering från ~ 0,3 block / sekund till mer än 20 block / sekund. Detta förbättrar validator UX kraftigt, så att de kan ansluta sig och börja bidra till nätverket mycket snabbare.

Ett annat spännande tillägg till Prysm testnet är alethio s ny eth2-nodskärm – eth2stats.io. Detta är en opt-in-tjänst som tillåter noder att samla statistik på en enda plats. Detta gör att vi bättre kan förstå testnets tillstånd och i slutändan eth2 mainnet.

Lita inte på mig! Dra ner det och prova det själv.

Alla älskar proto_array

Core eth2-specifikationen specificerar ofta (medvetet) förväntat beteende icke-optimalt. Speckkoden är istället optimerad för avsiktsläsbarhet snarare än för prestanda.

En spec beskriver ett systems korrekt beteende, medan en algoritm är en procedur för att utföra ett specifikt beteende. Många olika algoritmer kan trofast implementera samma specifikation. Eth2-specifikationen möjliggör således ett brett utbud av olika implementationer av varje komponent eftersom klientteam tar hänsyn till valfritt antal olika avvägningar (t.ex. beräkningskomplexitet, minnesanvändning, implementeringskomplexitet, etc.).

Ett sådant exempel är val av gaffel – specifikationen som används för att hitta kedjan. Eth2-specifikationen specificerar beteendet med hjälp av en naiv algoritm för att tydligt visa rörliga delar och kantfall – t.ex. hur man uppdaterar vikter när en ny attest kommer in, vad man ska göra när ett nytt block slutförs osv. En direkt implementering av spec-algoritmen skulle aldrig uppfylla eth2: s produktionsbehov. Istället måste kundteam tänka djupare på beräkningsmässiga avvägningar i samband med deras klientdrift och implementera en mer sofistikerad algoritm för att tillgodose dessa behov.

Tur för klientteam implementerade Protolambda för cirka 12 månader sedan ett gäng olika algoritmer för val av gaffel, dokumentera fördelarna och avvägningarna för varje. Nyligen observerade Paul från Sigma Prime en stor flaskhals i Fyrens val av algoritm för gaffel och gick och handlade efter något nytt. Han avslöjade proto_array i protos gamla lista.

Det tog lite arbete för att hamna proto_array för att passa den senaste specifikationen, men en gång integrerad, proto_array visat sig “att köra i ordningsföljd mindre tid och utföra betydligt mindre databasläsningar.” Efter den första integrationen i Lighthouse plockades den snabbt upp av Prysmatic också och finns tillgänglig i deras senaste utgåva. Med den här algoritmens tydliga fördelar jämfört med alternativ, proto_array blir snabbt en publikfavorit, och jag räknar helt med att se några andra lag plocka upp det snart!

Pågående fas 2-forskning – Quilt, eWASM och nu TXRX

Fas 2 av eth2 är tillägget av tillstånd och exekvering i det skärvade eth2-universum. Även om vissa kärnprinciper är relativt definierade (till exempel kommunikation mellan skärvor via tvärbindningar och markle proofs), är fas 2-designlandskapet fortfarande relativt öppet. Quilt (ConsenSys forskargrupp) och eWASM (EF-forskargruppen) har använt mycket av sina ansträngningar under det gångna året på att undersöka och bättre definiera detta breda öppna designutrymme parallellt med det pågående arbetet med att specificera och bygga fas 0 och 1.

För detta ändamål har det förekommit en massa av den senaste tidens aktivitet av offentliga samtal, diskussioner och ethresear.ch-inlägg. Det finns några stora resurser för att hjälpa till att lägga marken. Följande är bara ett litet prov:

Förutom Quilt och eWASM, den nybildade TXRX (ConsenSys forskargrupp) ägnar också åt sig en del av sina ansträngningar för fas 2-forskning, och inledningsvis fokuserar de på att bättre förstå transaktionskomplexitet mellan olika skärmar samt att forska och prototypa möjliga vägar för integration av eth1 i eth2.

Alla FoU-fas 2 är ett relativt grönt fält. Här finns en enorm möjlighet att gräva djupt och påverka. Under hela detta år kan du förvänta dig mer konkreta specifikationer såväl som utvecklare lekplatser att sjunka tänderna i

Whiteblock släpper libp2p-skvattstubsresultat

Denna vecka, Whiteblock släppte libp2p testresultat för skvaller som kulminationen av ett bidrag som samfinansieras av ConsenSys och Ethereum Foundation. Detta arbete syftar till att validera skvaller-algoritmen för användning av eth2 och att ge insikt i gränserna för prestanda för att underlätta uppföljningstester och algoritmiska förbättringar.

Tl; dr är att resultaten av denna våg av tester ser solida ut, men ytterligare tester bör utföras för att bättre observera hur meddelandepropogeringskalor med nätverksstorlek. Kolla in fullständig rapport med deras metodik, topologi, experiment och resultat!

Staplad vår!

Den här våren är staplad med spännande konferenser, hackathons, eth2 bounties och mer! Det kommer att finnas en grupp eth2-forskare och ingenjörer vid vart och ett av dessa evenemang. Kom snälla! Vi skulle gärna prata med dig om tekniska framsteg, validering på testnät, vad du kan förvänta dig i år och allt annat som du kan tänka på.

Nu är det en bra tid att engagera sig! Många klienter är i testnetfasen så det finns alla möjliga verktyg att bygga, experiment att köra och roligt att ha.

Här är en glimt av de många händelserna som planeras för att ha en solid et2-representation:

🚀



LEAVE A REPLY

Please enter your comment!
Please enter your name here