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: 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. Slot: Ang isang kapanahunan ay binubuo ng 32 na mga puwang, na may kabuuang . Epoch: 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 , pagkatapos nito ay halos imposible nang ibalik ang mga block. ng 2 epochs (~12.8 min) Mga komite ay may malaking bilang ng mga Validator sa network. Sa oras ng pagsulat, mayroong 1,051,349 na aktibong validator ayon sa 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 upang mahusay na patunayan ang mga transaksyon at patunayan na harangan ang bisa. Ang Ethereum beaconcha.in mga komite 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 Committee na nakatalaga sa bawat slot at sabihin na may Validator sa bawat Committee(kung saan >128). Nangangahulugan ito na mayroong mga pagpapatunay para sa bawat slot. Tulad ng naiintindihan mo, maaari itong mabilis na maging napakalaki para sa network na tsismis ang maraming pagpapatunay na ito. N M M NxM 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 Validator. mayroon lamang 1 panghuling sa halip na . M Aggregated Attestation M Kaya sa bawat slot, may final ng 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 pagpapatunay na ito. N N 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 na Komite bawat slot ie 64 N=64 Proposer Lookahead Ang beacon chain shuffling ay idinisenyo upang magbigay ng hindi bababa sa lookahead sa paparating na mga assignment ng komite ng validator para sa pagpapatunay na idinidikta ng shuffling at slot. na ang lookahead na ito ay hindi nalalapat sa pagmumungkahi, na dapat suriin sa panahon na pinag-uusapan. 1 Epoch (32 slots) Tandaan ay maaaring tawagan sa simula ng bawat panahon para makuha ang assignment para sa susunod na panahon ( ). Pinapayagan din nito ang mga validator na kalkulahin ang subnet id, sumali sa kani-kanilang komite, at maging handa para sa kanilang mga tungkulin. get_committee_assignment current_epoch + 1 Bukod pa rito, maaaring italaga ang isang Validator bilang ng isang partikular na komite. Kung gayon, dapat din silang mag-subscribe sa kani-kanilang paksa. Aggregator Mga Pananagutan ng Nagmumungkahi Sa loob ng bawat puwang, isang ang pipiliin bilang na lumikha at magsumite ng isang bloke. validator mula sa kani-kanilang komite nagmumungkahi 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 sa network. SignedBeaconBlock 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: : 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. Front-running : Pagsasagawa ng transaksyon pagkatapos mismo ng isang partikular na kaganapan (hal., mga arbitrage bot). Back-running : Isang kumbinasyon ng front-running at back-running, lalo na sa DeFi trades. Sandwich attacks Sino ang Nag-extract ng MEV? : 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 Validator (Pre-PBS) : Mga independiyenteng aktor na nag-scan sa mempool para sa mga pagkakataon sa MEV at nagsusumite ng mga transaksyon nang naaayon. Mga Naghahanap : 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. Mga Tagabuo (Post-PBS) Block Building Pre-PBS: Validator-Centric MEV Bago lumipat ang Ethereum sa PBS, ang nagmumungkahi (dating minero sa PoW) ay may . Lumikha ito ng isang ecosystem kung saan ang MEV ay direktang kinuha ng mga validator o na-outsource sa mga dalubhasang naghahanap. ganap na kontrol sa pag-order ng transaksyon Paano Ito Nagtrabaho Pre-PBS: : Ang mga transaksyon ay ibino-broadcast gaya ng dati at pumasok sa mempool. Transaction Pool Pinipili ng mga validator ang mga transaksyon mula sa mempool. Ang mga ito ay maaaring i-order ng isang bagay na tinatawag na 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).. priority_fee Binubuo ng Validator ang block batay sa paggamit ng mga transaksyong kanilang pinili. : Ang pinirmahang block ay ibino-broadcast sa network. Block Propagation 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 : Ang malalaking validator ay nagkaroon ng pang-ekonomiyang kalamangan sa mas maliliit dahil sa kanilang kakayahang kunin ang MEV nang mas mahusay. Sentralisasyon ng MEV Power : Maaaring piliin ng mga validator na ibukod ang mga transaksyon na hindi naaayon sa kanilang mga insentibo sa pananalapi. Tumaas na Panganib sa Censorship : 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. Pagsisikip sa Network at Mataas na Bayarin sa Gas 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 . Hinahati ng PBS ang mga responsibilidad ng block production sa pagitan ng dalawang magkahiwalay na entity: ang Proposer-Builder Separation (PBS) : Mga entity na nagdadalubhasa sa pagbuo ng mga na-optimize na bloke, kadalasang nagsasama ng mga diskarte sa MEV. Block Builders : Ang mga validator ay hindi na mismo ang bumuo ng mga block; pinipili lang nila ang pinaka kumikitang bloke na inaalok ng mga tagabuo. Block Proposers (Validators) Paano Ito Gumagana Post-PBS: : Ang mga block builder ay nakikipagkumpitensya upang bumuo ng pinaka-pinakinabangang bloke, na isinasaalang-alang ang mga pagkakataon sa pagkuha ng MEV. Mga Builders Construct Blocks : Nagbi-bid ang mga Builder na imungkahi ang kanilang block sa mga validator, tinitiyak na matatanggap ng mga validator ang pinakakumikitang opsyon. Pag-bid para sa Pagsasama ng Block : 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. Pinili ng Mga Validator ang Pinakamataas na Bid Paano gumagana ang Ethereum block building ngayon Nagsusumite ang user ng transaksyon sa pamamagitan ng JSON-RPC na konektadong wallet. Ang transaksyong ito ay isinumite sa pampublikong mempool. Ang lahat ng mga transaksyon ay itinatapon dito bago sila kunin at ma-validate. Kamakailan, 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 para sa higit pang mga insight. ang Private Orderflows Dune → na mga panlabas na entity na patuloy na nag-scan sa mempool upang makahanap ng mga pagkakataon sa MEV ( ). 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 na tawag. Mga naghahanap higit pa dito sa ibaba eth_sendBundle : Ang mga naghahanap ay mga external na entity at nakakaimpluwensya sa pag-order ng transaksyon ngunit hindi nakikilahok sa pagpapatunay ng block o pinagkasunduan. Tandaan →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. Mga Tagabuo Pinupuno nila ang mga bloke ng: Mga bundle na ipinadala ng mga Naghahanap. Mga transaksyong may mataas na priyoridad. Mag-order ng mga pangkalahatang transaksyon na isinasaisip upang i-maximize ang kita. Itinakda din nila ang field 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. feeRecipient : Ang mga Builder ay mga panlabas na entity at hindi direktang nakikipag-ugnayan sa blockchain. Tandaan → 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 at 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 . Mga Relay BeaverBuild Titan. 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 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 . Nagpapadala na ngayon ang Relay ng na naglalaman ng hash ng katawan, bid, at lagda ng tagabuo. feeRecipient eth_getPaylaodHeader PayloadHeader Ang nagmumungkahi ay may 2 opsyon sa puntong ito: Upang piliin ang (tinatawag ding ) 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 gamit ang na tawag. Ngayon ang Relay ay nagpapatupad ng na tawag na nagbabalik ng buong sa nagmumungkahi. Iminumungkahi lang ng Proposer ang block na ito sa Ethereum Validator network o mas partikular sa komite kung saan sila nakatalaga. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload Maaaring piliin ng Proposer na huwag tanggapin ang 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. PayloadHeader Ngunit sa Case 1, paano kung hindi ipadala ng Proposer ang block na ipinadala ng Relay? Well, ang nagmumungkahi ay kinakailangang lagdaan ang para sa eksaktong dahilan na ito. Bago ipadala ang Header, ipinapadala ng Relay ang sa isang para sa pag-iingat. Kapag natanggap na ng Relay ang nilagdaang mula sa nagmumungkahi, ibe-verify nito ang lagda at ipapadala ang 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. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Tandaan Ito ay isang slashable na pagkakasala na pumirma sa dalawang magkaibang Header para sa parehong nagmumungkahi na puwang. 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 blocks na binuo ng Builders ay kinabibilangan lang ng 0-7% OFAC sanctioned transactions. Censorship.pics Paano natin ito malulutas? Isa sa mga pinakakilalang solusyon sa pag-censor ng transaksyon sa pagsulat nito ay . Inclusion 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. Ang Inclusions Lists 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. : Mayroon ding ideya para sa na gumagawa ng IL para sa kasalukuyang Block N mismo. Ngunit ang disenyong ito ay may mga kakulangan sa ekonomiya na humahantong sa Tandaan Mga Listahan ng Pagsasama ng Spot Mga Listahan ng Pagpasa ng Pagsasama. 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 ay isang bagong disenyo na iminungkahi noong 2024 na bumubuo at nagpapahusay sa Mga Listahan ng Pagsasama upang mapataas ang mapagkakatiwalaang neutralidad. Ang Fork Choice enforced Inclusion Lists (FOCIL) 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." : Hindi magagarantiya ng mga miyembro ng komite ng IL ang anumang anyo ng pag-order ng transaksyon dahil maaaring isama ang mga transaksyon sa IL sa anumang order. Ginagarantiya lamang nila ang pagsasama ng transaksyon. Tandaan Mga benepisyo ng PBS para sa MEV Management : 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. Desentralisasyon ng MEV Extraction : Ang mga validator ay kumikita pa rin mula sa MEV nang hindi direktang nakikibahagi sa pagkuha, na ginagawang mas patas ang block production. Patas na Pamamahagi ng Kita : Ang kumpetisyon sa mga builder ay humahantong sa mga na-optimize na bloke na may mas mahusay na gas efficiency. Mas Mahusay na Block Space Utilization Mga hamon ng PBS : Habang ang mga validator ay desentralisado, ang ilang nangingibabaw na tagabuo ay maaari pa ring isentro ang pagkuha ng MEV. Panganib sa Sentralisasyon sa Mga Tagabuo : 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. Magtiwala sa Mga Off-Chain MEV Relay 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 Salamat sa , at para sa pagsusuri at pagbibigay ng mga mungkahi. @mteam @Gajpower @unnawut
