Ethereum Block Building: Den dolda ekonomin bakom varje transaktion

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:

• Slot: 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.
• Epok: En epok består av 32 platser, totalt 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 2 epoker (~12,8 min) , varefter det är nästan omöjligt att återställa blocken.

kommittéer

Ethereum har ett stort antal validatorer i nätverket. I skrivande stund finns det 1 051 349 aktiva validerare enligt beaconcha.in 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 kommittéer för att effektivt validera transaktioner och intyga blockets giltighet.

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 N kommittéer tilldelade per plats och låt oss säga att det finns M Validatorer i varje kommitté (där M >128). Det betyder att det finns NxM 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.

• Samlare i varje kommitté har till uppgift att sammanställa intygen från respektive kommitté. Detta betyder från en kommitté av M Validatorer. det finns bara 1 slutgiltigt Aggregated Attestation istället för M .

• Så i varje lucka finns det en final av N 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 N intyg.

  
  

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 64 kommittéer per plats, dvs N=64

  
  

Förslagsställare Lookahead

Beacon chain shuffling är utformad för att ge minst 1 epok (32 platser) framåtblick på validatorns kommande kommittéuppdrag för attestering som dikteras av shuffling och slot. Observera att denna framtidsutsikt inte gäller för att föreslå, vilket måste kontrolleras under den aktuella epoken.

get_committee_assignment kan anropas i början av varje epok för att få uppdraget för nästa epok ( current_epoch + 1 ). 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.

Dessutom kan en validator tilldelas som Aggregator för en specifik kommitté. Om så är fallet måste de också prenumerera på respektive ämne.

Förslagsställarens ansvar

Inom varje lucka väljs en enda validator från respektive kommitté som förslagsställare för att skapa och skicka in ett block.

Förslagsställarens roll är avgörande eftersom de:

• Konstruera ett block genom att inkludera väntande transaktioner och attester.
• Signera och sända SignedBeaconBlock till nätverket.
• 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:

• Front-running : 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.
• Back-running : Exekvera en transaktion direkt efter en specifik händelse (t.ex. arbitragebots).
• Smörgåsattacker : En kombination av front-running och back-running, särskilt i DeFi-affärer.

Vem extraherar MEV?

• Validatorer (Pre-PBS) : När validerare kontrollerade blockproduktionen hade de fullt utrymme för beställning av transaktioner och kunde extrahera MEV direkt.
• Sökare : Oberoende aktörer som skannar mempoolen efter MEV-möjligheter och skickar in transaktioner därefter.
• Byggare (Post-PBS) : Efter PBS tar blockbyggare rollen att konstruera MEV-optimerade block, medan validerare helt enkelt väljer block från högstbjudande.

Block Building Pre-PBS: Validator-Centric MEV

Innan Ethereum övergick till PBS hade förslagsställaren (tidigare gruvarbetare i PoW) full kontroll över transaktionsbeställning . Detta skapade ett ekosystem där MEV extraherades direkt av validerare eller outsourcades till specialiserade sökare.

Hur det fungerade före PBS:

1. Transaktionspool : Transaktioner sänds som vanligt och går in i mempoolen.
2. Validatorer handplockade transaktioner från mempoolen. Dessa kan beställas av något som kallas priority_fee 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).
3. Validatorn bygger blocket baserat på de transaktioner de valt.
4. Blockpropagation : Det signerade blocket sänds till nätverket.

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

• Centralisering av MEV Power : Stora validatorer hade en ekonomisk fördel jämfört med mindre på grund av deras förmåga att extrahera MEV mer effektivt.
• Ökad censurrisk : Validatorer kunde välja att utesluta transaktioner som inte överensstämde med deras ekonomiska incitament.
• Nätverksöverbelastning och höga gasavgifter : Budkrigen för MEV-transaktioner ledde till ineffektivt blockutrymmesutnyttjande, vilket ökade kostnaderna för vanliga användare.

Block Building Post-PBS: Separation of Proposers & Builders

För att ta itu med centraliseringsriskerna och ineffektiviteten med valideringskontrollerad blockkonstruktion introducerades Proposer-Builder Separation (PBS) . PBS delar upp ansvaret för blockproduktion mellan två separata enheter:

1. Blockbyggare : Enheter som specialiserar sig på att konstruera optimerade block, ofta med MEV-strategier.
2. Blockförslagsställare (validatorer) : Validatorer bygger inte längre block själva; de väljer helt enkelt det mest lönsamma blocket som erbjuds av byggare.

Så fungerar det efter PBS:

1. Builders Construct Blocks : Blockbyggare tävlar om att konstruera det mest lönsamma blocket, och tar hänsyn till MEV-utvinningsmöjligheter.
2. Budgivning för blockinkludering : 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.
3. Validatorer väljer det högsta budet : Istället för att välja enskilda transaktioner väljer validerare helt enkelt det högstbjudande byggblocket, vilket maximerar deras belöningar.

Hur Ethereum-blockbyggnad fungerar nu

1. Användaren skickar transaktionen via JSON-RPC-ansluten plånbok.
2. Denna transaktion skickas in i den offentliga mempoolen. Alla transaktioner dumpas här innan de hämtas och valideras. Nyligen har privata orderflöden 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å Dune för fler insikter.

3. Sökare → som är externa enheter som skannar mempoolen kontinuerligt för att hitta MEV-möjligheter ( mer om detta nedan ). 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 eth_sendBundle .

   Obs : Sökare är externa enheter och påverkar transaktionsbeställning men deltar inte i blockvalidering eller konsensusbeslut.

   

   
   

4. Builders →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.

   De fyller blocken med:

   1. Buntar skickade av Sökarna.

   2. Högprioriterade transaktioner.

   3. Beställ allmänna transaktioner med tanke på att maximera intäkterna.

      
      

   De ställer också in fältet feeRecipient 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.

   
   

5. Reläer → 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 BeaverBuild och Titan. 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 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 feeRecipient 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 eth_getPaylaodHeader . Reläet skickar nu en PayloadHeader som innehåller hashen för kroppen, budet och byggarens signatur.

Förslagsställaren har två alternativ vid denna tidpunkt:

• För att välja PayloadHeader (även kallad Blinded Block ) 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 PayloadBody med anropet eth_returnSignedHeader . Nu kör reläet anropet eth_sendPayload som returnerar hela ExecutionPayload 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.

  
  

• Förslagsställaren kan välja att inte acceptera PayloadHeader 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.

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 PayloadHeader av denna anledning. Innan headern skickas skickar reläet PayloadBody till en Escrow för förvaring. När reläet tar emot den signerade PayloadHeader från förslagsställaren, verifierar den signaturen och skickar PayloadBody 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.

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 Censorship.pics innehåller block byggda av Builders endast 0-7 % OFAC-sanktionerade transaktioner.

Hur löser vi detta?

En av de mest välkända lösningarna för transaktionscensurering när detta skrivs är Inclusion Lists .

Inklusionslistor ä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 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.

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

Fork Choice enforced Inclusion Lists (FOCIL) är en ny design som föreslås 2024 som bygger och förbättrar inkluderingslistor för att öka trovärdig neutralitet.

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."

Fördelar med PBS för MEV Management

• Decentralisering av MEV-extraktion : 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.
• Rättvisare inkomstfördelning : Validatorer tjänar fortfarande på MEV utan att direkt engagera sig i utvinning, vilket gör blockproduktionen mer rättvis.
• Effektivare blockutrymmesutnyttjande : Konkurrens mellan byggare leder till optimerade block med bättre gaseffektivitet.

PBS utmaningar

• Centraliseringsrisk bland byggare : Även om validerare är decentraliserade, kan ett fåtal dominerande byggare fortfarande centralisera MEV-extraktion.
• Förtroende för MEV-reläer utanför kedjan : 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.

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