Block Building är en avgörande aspekt av Ethereums livscykel bestående av olika rörliga delar. Det bestämmer vilka transaktioner som inkluderas i ett block och i vilken ordning, vilket direkt påverkar nätverkets effektivitet, decentralisering och rättvisa. Med tiden har Ethereums blockproduktionsprocess utvecklats, särskilt med MEVs växande roll och skiftet från validatordrivet urval till specialiserade byggare. Det här inlägget kommer att diskutera hur Ethereum Block Building har utvecklats tillsammans med introduktionen av Proposer Builder Separation och framtida forskning. Primer på Ethereum Block Building Components Slots och epoker Ethereum organiserar tid i diskreta enheter: En slot är en 12-sekundersperiod under vilken ett enda block kan föreslås. Om ingen validator skickar ett block inom en lucka, hoppas det över. Slot: En epok består av 32 platser, totalt . Epok: 6,4 minuter I slutet av varje epok blandas valideringsuppgifterna för att säkerställa decentralisering och säkerhet. Ethereum uppnår ekonomisk slutgiltighet efter , varefter det är nästan omöjligt att återställa blocken. 2 epoker (~12,8 min) kommittéer har ett stort antal validatorer i nätverket. I skrivande stund finns det 1 051 349 aktiva validerare enligt Det skulle vara omöjligt om så många validerare var tvungna att verifiera varje block var 12:e sekund. Validatorer är därför indelade i för att effektivt validera transaktioner och intyga blockets giltighet. Ethereum beaconcha.in kommittéer Varje kommitté: Består av en delmängd av validerare slumpmässigt tilldelade i början av en epok med hjälp av RANDAO. Säkerställer att ingen enskild validator har oproportionerligt inflytande. Deltar i att rösta (attestera) på block och bekräfta deras giltighet. Storleken på en kommitté beror på det totala antalet aktiva validerare i nätverket, men i allmänhet har varje kommitté minst 128 validatorer. I varje plats: Det finns låt oss säga kommittéer tilldelade per plats och låt oss säga att det finns Validatorer i varje kommitté (där >128). Det betyder att det finns intyg för varje slot. Som ni förstår kan det snabbt bli överväldigande för nätverket att skvallra så här många intyg. N M M NxM Samlare i varje kommitté har till uppgift att sammanställa intygen från respektive kommitté. Detta betyder från en kommitté av Validatorer. det finns bara 1 slutgiltigt istället för . M Aggregated Attestation M Så i varje lucka finns det en final av intyg (1 för varje kommitté i den luckan) som skvallras om det globala ämnet. Förslagsställaren för nästa lucka plockar upp dessa intyg. N N Några punkter att tänka på Under en epok är varje aktiv validerare medlem i exakt en kommitté, så alla epokens kommittéer är osammanhängande. Protokollet justerar det totala antalet kommittéer i varje epok efter antalet aktiva validerare. Nuvarande design är att ha kommittéer per plats, dvs 64 N=64 Förslagsställare Lookahead Beacon chain shuffling är utformad för att ge minst framåtblick på validatorns kommande kommittéuppdrag för attestering som dikteras av shuffling och slot. att denna framtidsutsikt inte gäller för att föreslå, vilket måste kontrolleras under den aktuella epoken. 1 epok (32 platser) Observera kan anropas i början av varje epok för att få uppdraget för nästa epok ( ). Detta gör det också möjligt för validerare att beräkna subnät-ID, gå med i respektive kommitté och vara förberedda på sina uppgifter. get_committee_assignment current_epoch + 1 Dessutom kan en validator tilldelas som för en specifik kommitté. Om så är fallet måste de också prenumerera på respektive ämne. Aggregator Förslagsställarens ansvar Inom varje lucka väljs en som för att skapa och skicka in ett block. enda validator från respektive kommitté förslagsställare Förslagsställarens roll är avgörande eftersom de: Konstruera ett block genom att inkludera väntande transaktioner och attester. Signera och sända till nätverket. SignedBeaconBlock Tjäna belöningar för att framgångsrikt föreslå giltiga block. Short Primer på MEV MEV är den extra vinsten som utvinns av validerare (tidigare gruvarbetare) genom att omordna, inklusive eller censurera transaktionerna inom ett block. Några vanliga MEV-strategier är: : Placera en affär strax före en känd lönsam transaktion. Frontrunning anses också vara giftigt MEV eftersom det överraskar användaren med en negativ effekt. Front-running : Exekvera en transaktion direkt efter en specifik händelse (t.ex. arbitragebots). Back-running : En kombination av front-running och back-running, särskilt i DeFi-affärer. Smörgåsattacker Vem extraherar MEV? : När validerare kontrollerade blockproduktionen hade de fullt utrymme för beställning av transaktioner och kunde extrahera MEV direkt. Validatorer (Pre-PBS) : Oberoende aktörer som skannar mempoolen efter MEV-möjligheter och skickar in transaktioner därefter. Sökare : Efter PBS tar blockbyggare rollen att konstruera MEV-optimerade block, medan validerare helt enkelt väljer block från högstbjudande. Byggare (Post-PBS) Block Building Pre-PBS: Validator-Centric MEV Innan Ethereum övergick till PBS hade förslagsställaren (tidigare gruvarbetare i PoW) . Detta skapade ett ekosystem där MEV extraherades direkt av validerare eller outsourcades till specialiserade sökare. full kontroll över transaktionsbeställning Hur det fungerade före PBS: : Transaktioner sänds som vanligt och går in i mempoolen. Transaktionspool Validatorer handplockade transaktioner från mempoolen. Dessa kan beställas av något som kallas vilket är avgifter som användaren är villig att betala för att bli inkluderad först. Det kan också beställas på ett sätt som Validatorn ger mer intäkter (genom sandwich/frontrunning). priority_fee Validatorn bygger blocket baserat på de transaktioner de valt. : Det signerade blocket sänds till nätverket. Blockpropagation Detta är något löst abstrakt för att förenkla. Men detta var det allmänna flödet. Detta kan betecknas som Vanilla Block Building Problem med Pre-PBS Block Building : Stora validatorer hade en ekonomisk fördel jämfört med mindre på grund av deras förmåga att extrahera MEV mer effektivt. Centralisering av MEV Power : Validatorer kunde välja att utesluta transaktioner som inte överensstämde med deras ekonomiska incitament. Ökad censurrisk : Budkrigen för MEV-transaktioner ledde till ineffektivt blockutrymmesutnyttjande, vilket ökade kostnaderna för vanliga användare. Nätverksöverbelastning och höga gasavgifter Block Building Post-PBS: Separation of Proposers & Builders För att ta itu med centraliseringsriskerna och ineffektiviteten med valideringskontrollerad blockkonstruktion introducerades . PBS delar upp ansvaret för blockproduktion mellan två separata enheter: Proposer-Builder Separation (PBS) : Enheter som specialiserar sig på att konstruera optimerade block, ofta med MEV-strategier. Blockbyggare : Validatorer bygger inte längre block själva; de väljer helt enkelt det mest lönsamma blocket som erbjuds av byggare. Blockförslagsställare (validatorer) Så fungerar det efter PBS: : Blockbyggare tävlar om att konstruera det mest lönsamma blocket, och tar hänsyn till MEV-utvinningsmöjligheter. Builders Construct Blocks : Byggare lägger bud för att föreslå sin blockering för validerare, vilket säkerställer att validerare får det mest lönsamma alternativet. Budgivning för blockinkludering : Istället för att välja enskilda transaktioner väljer validerare helt enkelt det högstbjudande byggblocket, vilket maximerar deras belöningar. Validatorer väljer det högsta budet Hur Ethereum-blockbyggnad fungerar nu Användaren skickar transaktionen via JSON-RPC-ansluten plånbok. Denna transaktion skickas in i den offentliga mempoolen. Alla transaktioner dumpas här innan de hämtas och valideras. Nyligen har hamnat i centrum med de flesta stora aktörer som väljer detta eftersom det är en lösning för att sända dina transaktioner till allmänheten genom att använda behöriga/privata kanaler. Kolla in instrumentpanelen på för fler insikter. privata orderflöden Dune → som är externa enheter som skannar mempoolen kontinuerligt för att hitta MEV-möjligheter ( ). De hämtar respektive transaktioner och lägger in sina egna om och när det behövs för att göra vinst. Skapa sedan en bunt av dessa transaktioner, vars ordning måste bibehållas genomgående för att den som söker ska kunna göra en vinst. Buntar är ordnade transaktioner som måste utföras atomärt. Tillsammans med detta paket kan de lägga till en transaktion i slutet av paketet som betecknar en "muta" till byggaren. Denna bunt skickas till Builder genom anropet . Sökare mer om detta nedan eth_sendBundle : Sökare är externa enheter och påverkar transaktionsbeställning men deltar inte i blockvalidering eller konsensusbeslut. Obs →Nästa enhet är Builder, som faktiskt bygger blocket. De försöker maximera både avgiftsintäkterna och MEV-intäkterna. De inkluderar de paketerade transaktionerna som skickas av Sökarna (förhoppningsvis i ordning) och accepterar betalningen (mutan) som skickas av Sökarna. Builders konstruerar exekveringsnyttolaster med hjälp av mottagna transaktioner. Builders De fyller blocken med: Buntar skickade av Sökarna. Högprioriterade transaktioner. Beställ allmänna transaktioner med tanke på att maximera intäkterna. De ställer också in fältet till sin egen adress, vilket betyder att de kommer att få både Sökarens mutor och alla avgifter från transaktionerna i deras inlämnade block. Byggare skickar in en transaktion i slutet av deras blockering som fungerar som en muta till förslagsställaren liknande vad Sökaren gjorde för Byggaren. feeRecipient : Byggare är externa enheter och interagerar inte direkt med blockkedjan. Obs → Byggmästarmarknaden är en konkurrensutsatt marknad med olika byggare som vill att deras nyttolaster ska bli klara för att tjäna in avgifterna. De flesta block är dock byggda av ett fåtal välkända Block Builders, nämligen och För att förenkla denna process för den faktiska förslagsställaren, är reläer mellanliggande enheter som validerar nyttolasten som skickas av de olika byggarna och väljer den med maximal vinst/bud. Kommunikationen Relay-Proposer använder ett snyggt trick som liknar en Commit and Reveal för att säkerställa att förslagsställaren inte fuskar varje entitet tills nu. Mer . Reläer BeaverBuild Titan. här Att sätta ihop det Relä Förslagsställare meddelande Det är fullt möjligt att förslagsställaren vid mottagandet av blocknyttolasten packar upp blocket, infogar sina transaktioner och ändrar beställningen efter eget tycke samt ställer in till sin egen adress. Detta skulle innebära att varje enskild enhet som arbetat med blockbyggnadsprocessen fram till nu (Searcher → Builder → Relay) kommer att bli lurad eller göra "MEV-stöld". För att förhindra detta skickar reläet endast rubriken för den valda blocknyttolasten. Detta händer när förslagsställaren gör anropet . Reläet skickar nu en som innehåller hashen för kroppen, budet och byggarens signatur. feeRecipient eth_getPaylaodHeader PayloadHeader Förslagsställaren har två alternativ vid denna tidpunkt: För att välja (även kallad ) som tillhandahålls av reläet. Om så är fallet måste förslagsställaren signera rubriken med sin nyckel och skicka tillbaka den till reläet och följaktligen begära med anropet . Nu kör reläet anropet som returnerar hela till förslagsställaren. Förslagsställaren föreslår sedan helt enkelt detta block till Ethereum Validator-nätverket eller mer specifikt till kommittén de har tilldelats. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload Förslagsställaren kan välja att inte acceptera som skickas av reläet, i vilket fall de måste bygga blocket själva. Detta inkluderar att hitta MEV-möjligheter och beställa transaktioner därefter. Naturligtvis, i det här fallet, får förslagsställaren behålla hela intäkterna från avgifterna + MEV. Detta är dock inte så enkelt som det verkar. Att hitta MEV och optimera intäkter är en ganska beräkningstung uppgift och det finns möjlighet att förslagsställaren kanske inte kan bygga blocket i tid (12 sekunder), därför kommer det att finnas en missad lucka. I det här scenariot kan förslagsställaren skäras bort från nätverket. PayloadHeader Men i fall 1, vad händer om förslagsställaren inte skickar blocket som skickats av reläet? Tja, förslagsställaren måste signera av denna anledning. Innan headern skickas skickar reläet till en för förvaring. När reläet tar emot den signerade från förslagsställaren, verifierar den signaturen och skickar lagrad i depositionen till förslagsställaren. Låt oss nu säga att förslagsställaren inte inkluderar detta block. Den bygger sitt eget block och ignorerar beställningen som gjorts hittills. I det här fallet kommer signaturen inte att matcha eftersom rubrikerna har ändrats. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Obs Det är ett slashable-brott att signera två olika Headers för samma förslagsplats. Byggaren kan nu sända dessa motstridiga signerade rubriker till nätverket och förslagsställaren kan skäras bort från nätverket. Vad hindrar byggare från att censurera transaktioner? Nåväl, ingenting. Den vanligaste anledningen till att Builders censurerar en transaktion är att den interagerar med . OFAC-adresser För att förenkla, adresserar OFAC interagerande transaktioner som kan få juridiska konsekvenser, vilket uppenbarligen ingen skulle vilja ha på sina huvuden. Enligt innehåller block byggda av Builders endast 0-7 % OFAC-sanktionerade transaktioner. Censorship.pics Hur löser vi detta? En av de mest välkända lösningarna för transaktionscensurering när detta skrivs är . Inclusion Lists är en lista över transaktioner (tillsammans med något som kallas Sammanfattning) som läggs upp av förslagsställaren av Slot N tillsammans med förslag till Block av Slot N. Inklusionslistor Inklusionslistor tvingar fram att transaktionerna i listan måste inkluderas antingen i Block N eller Block N+1, annars kommer N+1-blocket att vara ogiltigt. Dessa kallas framåtriktade inkluderingslistor. : Det finns också ett begrepp för som gör IL för det aktuella blocket N själv. Men den här designen hade ekonomiska brister som ledde till Notera punktinkluderingslistor framåtriktade inkluderingslistor. Naturligtvis kommer denna design av IL inte att möjliggöra 100 % censurmotstånd, men det pågår aktiv forskning för att hårdna dessa förslag och många snygga optimeringar som kan tillämpas för att förbättra incitamentsstrukturen. FOCIL är en ny design som föreslås 2024 som bygger och förbättrar inkluderingslistor för att öka trovärdig neutralitet. Fork Choice enforced Inclusion Lists (FOCIL) FOCIL tillåter flera validatorer att ge förslag på inkluderingslistan för en specifik plats. För att vara mer exakt väljs 16 validatorer ut slumpmässigt vid varje plats för att bilda en inkluderingslista. Dessa medlemmar bildar var sin egen lokala IL och skvallrar runt det till nätverket. Förslagsställaren samlar in och sammanställer tillgängliga lokala inkluderingslistor till en slutlig IL. IL-designerna är lätta eftersom det inte finns något behov av att bygga om blocket för att inkludera dessa transaktioner; de kan bara läggas till blocket. Villkoret för att ett block ska uppfylla IL-valideringskravet är " Blocket är giltigt om det innehåller alla transaktioner från alla IL:er tills blocket är fullt." : IL-kommittémedlemmarna kan inte garantera någon form av transaktionsbeställning eftersom IL-transaktionerna kan inkluderas i vilken beställning som helst. De garanterar bara transaktionsinkludering. Notera Fördelar med PBS för MEV Management : Blockbyggare, snarare än några få stora validatorer, hanterar MEV-extraktion, vilket minskar riskerna för centralisering av validatorer. Det här är dock ett tveeggat svärd eftersom vi i processen för att minska centraliseringen av Validator har introducerat Builder Centralization där endast ett fåtal Builders bygger en stor andel av Blocks. Decentralisering av MEV-extraktion : Validatorer tjänar fortfarande på MEV utan att direkt engagera sig i utvinning, vilket gör blockproduktionen mer rättvis. Rättvisare inkomstfördelning : Konkurrens mellan byggare leder till optimerade block med bättre gaseffektivitet. Effektivare blockutrymmesutnyttjande PBS utmaningar : Även om validerare är decentraliserade, kan ett fåtal dominerande byggare fortfarande centralisera MEV-extraktion. Centraliseringsrisk bland byggare : PBS förlitar sig för närvarande på MEV-Boost-reläer, som fungerar utanför kedjan, vilket utgör potentiella säkerhetsrisker som en punkt för misslyckande. Förtroende för MEV-reläer utanför kedjan Referenser: Ethereums separation mellan förslagsställare och byggare: löften och realiteter Forskningens läge: censurmotstånd under PBS Byggarcensur: ethereums ruttna kärna EPF Wiki - PBS Anmärkningar om PBS Framåt inkluderingslista Vem vinner Ethereum Block Building Auctions och varför? FOCIL Erkännanden Tack till , och för att du granskar och ger förslag. @mteam @Gajpower @unnawut
