Ethereum Block Building: Ang Nakatagong Ekonomiya sa Likod ng Bawat Transaksyon

Ang Block Building ay isang mahalagang aspeto ng lifecycle ng Ethereum na binubuo ng iba't ibang gumagalaw na bahagi. Tinutukoy nito kung aling mga transaksyon ang isasama sa isang block at sa anong pagkakasunud-sunod, direktang nakakaapekto sa kahusayan ng network, desentralisasyon, at pagiging patas. Sa paglipas ng panahon, ang proseso ng block production ng Ethereum ay umunlad, lalo na sa lumalaking papel ng MEV at ang paglipat mula sa validator-driven na seleksyon patungo sa mga dalubhasang tagabuo.

Tatalakayin ng post na ito kung paano umunlad ang Ethereum Block Building kasama ang pagpapakilala ng Proposer Builder Separation at pananaliksik sa hinaharap.

Primer sa Ethereum Block Building Components

Mga Puwang at Epoch

Inaayos ng Ethereum ang oras sa mga discrete units:

• Slot: Ang slot ay isang 12 segundong yugto kung saan maaaring imungkahi ang isang bloke. Kung walang validator na magsumite ng block sa loob ng slot, ito ay nilalaktawan.
• Epoch: Ang isang kapanahunan ay binubuo ng 32 na mga puwang, na may kabuuang 6.4 minuto .

Sa pagtatapos ng bawat panahon, ang mga tungkulin ng validator ay binabasa upang matiyak ang desentralisasyon at seguridad. Nakakamit ng Ethereum ang economic finality pagkatapos ng 2 epochs (~12.8 min) , pagkatapos nito ay halos imposible nang ibalik ang mga block.

Mga komite

Ang Ethereum ay may malaking bilang ng mga Validator sa network. Sa oras ng pagsulat, mayroong 1,051,349 na aktibong validator ayon sa beaconcha.in Ito ay hindi magagawa kung ang maraming validator na ito ay kailangang i-verify ang bawat bloke bawat 12 segundo. Samakatuwid, ang mga validator ay nahahati sa mga komite upang mahusay na patunayan ang mga transaksyon at patunayan na harangan ang bisa.

Bawat komite:

• Binubuo ng isang subset ng mga validator na random na itinalaga sa simula ng isang panahon gamit ang RANDAO.
• Tinitiyak na walang iisang validator ang may hindi katimbang na impluwensya.
• Nakikilahok sa pagboto (pagpapatotoo) sa mga bloke at pagkumpirma ng kanilang bisa.

Ang laki ng isang komite ay depende sa kabuuang bilang ng mga aktibong validator sa network ngunit sa pangkalahatan, ang bawat komite ay may hindi bababa sa 128 validator.

Sa bawat slot:

• May mga lets say N Committee na nakatalaga sa bawat slot at sabihin na may M Validator sa bawat Committee(kung saan M >128). Nangangahulugan ito na mayroong mga pagpapatunay NxM para sa bawat slot. Tulad ng naiintindihan mo, maaari itong mabilis na maging napakalaki para sa network na tsismis ang maraming pagpapatunay na ito.

• Ang mga aggregator sa bawat Komite ay may tungkulin sa pagsasama-sama ng mga pagpapatunay ng kani-kanilang Komite. Nangangahulugan ito mula sa isang Komite ng M Validator. mayroon lamang 1 panghuling Aggregated Attestation sa halip na M .

• Kaya sa bawat slot, may final ng N Attestations(1 para sa bawat komite ng slot na iyon) na pinagtsitsismisan sa pandaigdigang paksa. Ang Nagmumungkahi ng susunod na puwang ay kukuha ng mga N pagpapatunay na ito.

  
  

Ang ilang mga punto na dapat tandaan

• Sa panahon ng isang panahon, ang bawat aktibong validator ay miyembro ng eksaktong isang komite, kaya ang lahat ng mga komite ng kapanahunan ay magkakahiwalay.

• Inaayos ng protocol ang kabuuang bilang ng mga komite sa bawat panahon ayon sa bilang ng mga aktibong validator.

• Ang kasalukuyang disenyo ay dapat magkaroon ng 64 na Komite bawat slot ie N=64

  
  

Proposer Lookahead

Ang beacon chain shuffling ay idinisenyo upang magbigay ng hindi bababa sa 1 Epoch (32 slots) lookahead sa paparating na mga assignment ng komite ng validator para sa pagpapatunay na idinidikta ng shuffling at slot. Tandaan na ang lookahead na ito ay hindi nalalapat sa pagmumungkahi, na dapat suriin sa panahon na pinag-uusapan.

get_committee_assignment ay maaaring tawagan sa simula ng bawat panahon para makuha ang assignment para sa susunod na panahon ( current_epoch + 1 ). Pinapayagan din nito ang mga validator na kalkulahin ang subnet id, sumali sa kani-kanilang komite, at maging handa para sa kanilang mga tungkulin.

Bukod pa rito, maaaring italaga ang isang Validator bilang Aggregator ng isang partikular na komite. Kung gayon, dapat din silang mag-subscribe sa kani-kanilang paksa.

Mga Pananagutan ng Nagmumungkahi

Sa loob ng bawat puwang, isang validator mula sa kani-kanilang komite ang pipiliin bilang nagmumungkahi na lumikha at magsumite ng isang bloke.

Ang papel ng nagmumungkahi ay mahalaga dahil sila ay:

• Bumuo ng block sa pamamagitan ng pagsasama ng mga nakabinbing transaksyon at pagpapatunay.
• Lagdaan at i-broadcast ang SignedBeaconBlock sa network.
• Makakuha ng mga reward para sa matagumpay na pagmumungkahi ng mga wastong bloke.

Maikling Primer sa MEV

Ang MEV ay ang karagdagang kita na nakuha ng mga validator (dating minero) sa pamamagitan ng muling pag-aayos, kasama, o pag-censor ng mga transaksyon sa loob ng isang bloke.

Ang ilang karaniwang diskarte sa MEV ay:

• Front-running : Paglalagay ng trade bago ang isang kilalang kumikitang transaksyon. Ang frontrunning ay itinuring din bilang nakakalason na MEV dahil nagulat ito sa gumagamit na may negatibong epekto.
• Back-running : Pagsasagawa ng transaksyon pagkatapos mismo ng isang partikular na kaganapan (hal., mga arbitrage bot).
• Sandwich attacks : Isang kumbinasyon ng front-running at back-running, lalo na sa DeFi trades.

Sino ang Nag-extract ng MEV?

• Mga Validator (Pre-PBS) : Kapag kinokontrol ng mga validator ang pagharang sa produksyon, mayroon silang buong pagpapasya sa pag-order ng transaksyon at maaaring direktang kunin ang MEV.
• Mga Naghahanap : Mga independiyenteng aktor na nag-scan sa mempool para sa mga pagkakataon sa MEV at nagsusumite ng mga transaksyon nang naaayon.
• Mga Tagabuo (Post-PBS) : Pagkatapos ng PBS, ang mga tagabuo ng bloke ay gagampanan ang tungkulin ng pagbuo ng mga bloke na na-optimize ng MEV, habang ang mga validator ay pipili lang ng mga bloke mula sa pinakamataas na bidder.

Block Building Pre-PBS: Validator-Centric MEV

Bago lumipat ang Ethereum sa PBS, ang nagmumungkahi (dating minero sa PoW) ay may ganap na kontrol sa pag-order ng transaksyon . Lumikha ito ng isang ecosystem kung saan ang MEV ay direktang kinuha ng mga validator o na-outsource sa mga dalubhasang naghahanap.

Paano Ito Nagtrabaho Pre-PBS:

1. Transaction Pool : Ang mga transaksyon ay ibino-broadcast gaya ng dati at pumasok sa mempool.
2. Pinipili ng mga validator ang mga transaksyon mula sa mempool. Ang mga ito ay maaaring i-order ng isang bagay na tinatawag na priority_fee na kung saan ay ang mga bayarin na handang bayaran ng user upang maisama muna. Maaari rin itong i-order sa paraang kumikita ang Validator (sa pamamagitan ng sandwich/frontrunning)..
3. Binubuo ng Validator ang block batay sa paggamit ng mga transaksyong kanilang pinili.
4. Block Propagation : Ang pinirmahang block ay ibino-broadcast sa network.

Ito ay medyo maluwag na abstract upang pasimplehin. Ngunit ito ang pangkalahatang daloy. Ito ay maaaring tawaging Vanilla Block Building

Mga Problema Sa Pre-PBS Block Building

• Sentralisasyon ng MEV Power : Ang malalaking validator ay nagkaroon ng pang-ekonomiyang kalamangan sa mas maliliit dahil sa kanilang kakayahang kunin ang MEV nang mas mahusay.
• Tumaas na Panganib sa Censorship : Maaaring piliin ng mga validator na ibukod ang mga transaksyon na hindi naaayon sa kanilang mga insentibo sa pananalapi.
• Pagsisikip sa Network at Mataas na Bayarin sa Gas : Ang mga digmaan sa pag-bid para sa mga transaksyon sa MEV ay humantong sa hindi mahusay na paggamit ng block space, na nagpapataas ng mga gastos para sa mga regular na user.

Block Building Post-PBS: Separation of Proposers & Builders

Upang matugunan ang mga panganib sa sentralisasyon at kawalan ng kahusayan ng validator-controlled block construction, ipinakilala ang Proposer-Builder Separation (PBS) . Hinahati ng PBS ang mga responsibilidad ng block production sa pagitan ng dalawang magkahiwalay na entity:

1. Block Builders : Mga entity na nagdadalubhasa sa pagbuo ng mga na-optimize na bloke, kadalasang nagsasama ng mga diskarte sa MEV.
2. Block Proposers (Validators) : Ang mga validator ay hindi na mismo ang bumuo ng mga block; pinipili lang nila ang pinaka kumikitang bloke na inaalok ng mga tagabuo.

Paano Ito Gumagana Post-PBS:

1. Mga Builders Construct Blocks : Ang mga block builder ay nakikipagkumpitensya upang bumuo ng pinaka-pinakinabangang bloke, na isinasaalang-alang ang mga pagkakataon sa pagkuha ng MEV.
2. Pag-bid para sa Pagsasama ng Block : Nagbi-bid ang mga Builder na imungkahi ang kanilang block sa mga validator, tinitiyak na matatanggap ng mga validator ang pinakakumikitang opsyon.
3. Pinili ng Mga Validator ang Pinakamataas na Bid : Sa halip na pumili ng mga indibidwal na transaksyon, pinipili lang ng mga validator ang bloke ng builder na may pinakamataas na pag-bid, na pina-maximize ang kanilang mga reward.

Paano gumagana ang Ethereum block building ngayon

1. Nagsusumite ang user ng transaksyon sa pamamagitan ng JSON-RPC na konektadong wallet.
2. Ang transaksyong ito ay isinumite sa pampublikong mempool. Ang lahat ng mga transaksyon ay itinatapon dito bago sila kunin at ma-validate. Kamakailan, ang Private Orderflows ay nasa gitna ng yugto kung saan karamihan sa malalaking manlalaro ay nag-opt para dito dahil ito ay solusyon sa pagsasahimpapawid ng iyong mga transaksyon sa publiko sa pamamagitan ng paggamit ng mga pinahintulutang/pribadong channel. Tingnan ang dashboard sa Dune para sa higit pang mga insight.

3. Mga naghahanap → na mga panlabas na entity na patuloy na nag-scan sa mempool upang makahanap ng mga pagkakataon sa MEV ( higit pa dito sa ibaba ). Kinukuha nila ang kani-kanilang mga transaksyon at inilalagay ang kanilang sarili kung at kung kinakailangan upang kumita. Pagkatapos, lumikha ng isang bundle ng mga transaksyong ito, ang pagkakasunud-sunod nito ay dapat mapanatili sa kabuuan upang ang Naghahanap ay kumita. Ang mga bundle ay mga order na transaksyon na dapat isagawa nang atomically. Kasama ng bundle na ito, maaari silang magdagdag ng transaksyon sa dulo ng bundle na nagsasaad ng "suhol" sa Tagabuo. Ang bundle na ito ay ipinadala sa Tagabuo sa pamamagitan ng eth_sendBundle na tawag.

   Tandaan : Ang mga naghahanap ay mga external na entity at nakakaimpluwensya sa pag-order ng transaksyon ngunit hindi nakikilahok sa pagpapatunay ng block o pinagkasunduan.

   

   
   

4. Mga Tagabuo →Ang susunod na entity ay ang Tagabuo, na talagang bumuo ng bloke. Sinusubukan nilang i-maximize ang parehong kita sa bayad gayundin ang kita ng MEV. Kasama sa mga ito ang mga naka-bundle na transaksyon na ipinadala ng Mga Naghahanap (sana ay maayos) at tinatanggap ang bayad (suhol) na ipinadala ng Mga Naghahanap. Ang mga Builder ay gumagawa ng mga execution payload gamit ang mga natanggap na transaksyon.

   Pinupuno nila ang mga bloke ng:

   1. Mga bundle na ipinadala ng mga Naghahanap.

   2. Mga transaksyong may mataas na priyoridad.

   3. Mag-order ng mga pangkalahatang transaksyon na isinasaisip upang i-maximize ang kita.

      
      

   Itinakda din nila ang field feeRecipient sa sarili nilang address na nagsasaad na matatanggap nila ang parehong mga suhol ng Searcher pati na rin ang lahat ng mga bayarin mula sa mga transaksyon sa kanilang isinumiteng block. Nagsusumite ang mga Builder ng transaksyon sa dulo ng kanilang block na nagsisilbing suhol sa nagmumungkahi na katulad ng ginawa ng Searcher para sa Builder.

   
   

5. Mga Relay → Ang Builder market ay isang mapagkumpitensyang merkado na may iba't ibang builder na gustong ma-finalize ang kanilang mga payload para makuha ang mga bayarin. Gayunpaman, karamihan sa mga bloke ay binuo ng ilang kilalang Block Builder, katulad ng BeaverBuild at Titan. Para pasimplehin ang prosesong ito para sa aktwal na Proposer, ang Relays ay mga intermediary entity na nagpapatunay sa mga payload na ipinadala ng iba't ibang Builder at pinipili ang isa na may pinakamataas na tubo/bid. Gumagamit ang komunikasyon ng Relay-Proposer ng isang maayos na trick na katulad ng isang Commit and Reveal upang matiyak na hindi mandadaya ng Proposer ang bawat entity hanggang sa puntong ito. Higit pa dito .

Pinagsasama-sama ito

Komunikasyon ng Relay Proposer

Ito ay ganap na posible na sa pagtanggap ng block payload, ang nagmumungkahi ay i-unwrap ang block, ipasok ang kanilang mga transaksyon, at baguhin ang pag-order sa kanilang sariling gusto at itakda ang feeRecipient sa kanilang sariling address. Nangangahulugan ito na ang bawat entity na nagtrabaho sa proseso ng block-building hanggang ngayon(Searcher → Builder → Relay) ay dadayain o gagawa ng "MEV stealing". Upang maiwasan ito, ipinapadala lamang ng Relay ang Header ng napiling Block Payload. Nangyayari ito kapag tinawag ng nagmumungkahi ang eth_getPaylaodHeader . Nagpapadala na ngayon ang Relay ng PayloadHeader na naglalaman ng hash ng katawan, bid, at lagda ng tagabuo.

Ang nagmumungkahi ay may 2 opsyon sa puntong ito:

• Upang piliin ang PayloadHeader (tinatawag ding Blinded Block ) na ibinigay ng Relay. Kung gayon, dapat lagdaan ng nagmumungkahi ang header gamit ang kanilang susi at ipadala ito pabalik sa Relay at dahil dito ay humiling ng PayloadBody gamit ang eth_returnSignedHeader na tawag. Ngayon ang Relay ay nagpapatupad ng eth_sendPayload na tawag na nagbabalik ng buong ExecutionPayload sa nagmumungkahi. Iminumungkahi lang ng Proposer ang block na ito sa Ethereum Validator network o mas partikular sa komite kung saan sila nakatalaga.

  
  

• Maaaring piliin ng Proposer na huwag tanggapin ang PayloadHeader na ipinadala ng Relay, kung saan dapat silang magtayo mismo ng block. Kabilang dito ang paghahanap ng mga pagkakataon sa MEV at pag-order ng mga transaksyon nang naaayon. Syempre, sa kasong ito, ang Nagmumungkahi ay maaaring panatilihin ang buong kita mula sa mga bayarin + MEV. Gayunpaman, hindi ito kasing simple ng tila. Ang paghahanap ng MEV at pag-optimize ng kita ay isang medyo mabigat sa pag-compute at may posibilidad na ang nagmumungkahi ay maaaring hindi mabuo ang block sa oras(12 segundo), kaya magkakaroon ng hindi nakuhang slot. Sa sitwasyong ito, ang nagmumungkahi ay maaaring i-slash mula sa network.

Ngunit sa Case 1, paano kung hindi ipadala ng Proposer ang block na ipinadala ng Relay?

Well, ang nagmumungkahi ay kinakailangang lagdaan ang PayloadHeader para sa eksaktong dahilan na ito. Bago ipadala ang Header, ipinapadala ng Relay ang PayloadBody sa isang Escrow para sa pag-iingat. Kapag natanggap na ng Relay ang nilagdaang PayloadHeader mula sa nagmumungkahi, ibe-verify nito ang lagda at ipapadala ang PayloadBody na nakaimbak sa escrow sa Proposer. Ngayon, sabihin nating hindi kasama ng nagmumungkahi ang Block na ito. Bumubuo ito ng sarili nitong bloke, hindi pinapansin ang pag-order na ginawa sa ngayon. Sa kasong ito, hindi tutugma ang lagda dahil nagbago ang mga header.

Maaari na ngayong i-broadcast ng Tagabuo ang magkasalungat na Signed Header na ito sa network at ang Proposer ay maaaring i-slash mula sa network.

Ano ang pumipigil sa Mga Tagabuo sa pag-censor ng mga transaksyon?

Well, wala. Ang pinakakaraniwang dahilan kung bakit maaaring i-censor ng Mga Tagabuo ang isang transaksyon ay dahil nakikipag-ugnayan ito sa mga OFAC address . Upang pasimplehin, tinutugunan ng OFAC ang mga nakikipag-ugnayang transaksyon na maaaring may mga legal na epekto, na medyo malinaw na walang sinuman ang gusto sa kanilang mga ulo.

Ayon sa Censorship.pics blocks na binuo ng Builders ay kinabibilangan lang ng 0-7% OFAC sanctioned transactions.

Paano natin ito malulutas?

Isa sa mga pinakakilalang solusyon sa pag-censor ng transaksyon sa pagsulat nito ay Inclusion Lists .

Ang Inclusions Lists ay isang listahan ng mga transaksyon(kasama ang isang bagay na tinatawag na Summary) na nai-post ng Proposer ng Slot N kasama ng pagmumungkahi ng Block ng Slot N.

Ipinapatupad ng Mga Listahan ng Pagsasama na ang mga transaksyon sa listahan ay dapat isama alinman sa Block N o Block N+1, kung hindi ay magiging invalid ang N+1 block. Ang mga ito ay tinatawag na Forward Inclusion Lists.

Siyempre, hindi papaganahin ng disenyong ito ng mga IL ang 100% Censorship Resistance, ngunit may aktibong pananaliksik na nagpapatuloy upang patigasin ang mga panukalang ito at maraming maayos na pag-optimize na maaaring ilapat upang mas mahusay ang istruktura ng insentibo.

FOCIL

Ang Fork Choice enforced Inclusion Lists (FOCIL) ay isang bagong disenyo na iminungkahi noong 2024 na bumubuo at nagpapahusay sa Mga Listahan ng Pagsasama upang mapataas ang mapagkakatiwalaang neutralidad.

Binibigyang-daan ng FOCIL ang maraming Validator na magbigay ng mga mungkahi sa Listahan ng Pagsasama para sa isang partikular na slot. Upang maging mas tumpak, 16 na Validator ang pinipili nang sapalaran sa bawat slot para bumuo ng Inclusion List Committee. Ang mga miyembrong ito ay bumubuo ng kanilang sariling lokal na IL at tsismis ito sa network. Kinokolekta at pinagsasama-sama ng Nagmumungkahi ang mga magagamit na listahan ng lokal na pagsasama sa isang panghuling IL. Ang mga disenyo ng IL ay magaan dahil hindi na kailangang muling itayo ang bloke upang maisama ang mga transaksyong ito; maaari lamang silang idagdag sa block. Ang kundisyon para sa isang Block upang matugunan ang kinakailangan sa pagpapatunay ng IL ay " Ang block ay may bisa kung naglalaman ito ng lahat ng mga transaksyon mula sa lahat ng mga IL hanggang sa mapuno ang bloke."

Mga benepisyo ng PBS para sa MEV Management

• Desentralisasyon ng MEV Extraction : Ang mga block builder, sa halip na ilang malalaking validator, ang humahawak sa MEV extraction, na binabawasan ang mga panganib sa sentralisasyon ng validator. Gayunpaman, ito ay isang double edged sword dahil sa proseso ng pagpapagaan ng sentralisasyon ng Validator, ipinakilala namin ang Builder Centralization kung saan iilan lang ang Builder ang bumubuo ng malaking porsyento ng Blocks.
• Patas na Pamamahagi ng Kita : Ang mga validator ay kumikita pa rin mula sa MEV nang hindi direktang nakikibahagi sa pagkuha, na ginagawang mas patas ang block production.
• Mas Mahusay na Block Space Utilization : Ang kumpetisyon sa mga builder ay humahantong sa mga na-optimize na bloke na may mas mahusay na gas efficiency.

Mga hamon ng PBS

• Panganib sa Sentralisasyon sa Mga Tagabuo : Habang ang mga validator ay desentralisado, ang ilang nangingibabaw na tagabuo ay maaari pa ring isentro ang pagkuha ng MEV.
• Magtiwala sa Mga Off-Chain MEV Relay : Kasalukuyang umaasa ang PBS sa mga MEV-Boost relay, na nagpapatakbo ng off-chain, na nagpapakita ng mga potensyal na panganib sa seguridad bilang isang punto ng pagkabigo.

Mga sanggunian:

Paghihiwalay ng Proposer-Builder ng Ethereum: Mga Pangako at Realidad

State of research: censorship resistance sa ilalim ng PBS

Builder Censorship: bulok na core ng ethereum

EPF Wiki - PBS

Mga tala sa PBS

Ipasa ang listahan ng pagsasama

Sino ang Nanalo sa Ethereum Block Building Auction at Bakit?

FOCIL

Mga Pasasalamat