
Ibinahagi ng mga mananaliksik ng Ethereum na bumaba sa wala pang isang segundo ang median na pagpapalaganap para sa isang simulated na 1 MiB execution payload gamit ang segmented broadcasting design ng EIP-8411, kumpara sa humigit-kumulang limang segundo nang ipinadala ang payload bilang isang mensahe.
Inilathala ng Ethereum Research ang pinakabagong resulta ng pagsusuri noong Setyembre 17, na nagdedetalye ng isang prototype na naghahati ng execution payloads sa mas maliliit na piraso upang ma-verify at maipasa ng mga node ang bawat segment bago matanggap ang buong payload. Ang mga natuklasan ay mula sa mga simulasyon at prototype client code, hindi sa mga sukat ng Ethereum mainnet.
Ang panukala ay nananatiling isang Draft networking EIP sa repositoryo ng Ethereum EIPs. Ang kasalukuyang disenyo nito ay pinapalitan ang nag-iisang execution_payload gossip topic na ipinakilala sa pamamagitan ng EIP-7732 ng isang execution_payload_chunks topic at ikino-commit ang mga piraso sa pamamagitan ng isang Merkle root na kasama sa execution bid ng builder.
Ang umiiral na gossip model ng Ethereum ay maaaring mangailangan ng isang node na matanggap at ma-validate ang isang malaking mensahe bago ito ipasa sa mga kapwa node. Inilalarawan ng mga mananaliksik sa likod ng EIP-8411 ang nagreresultang pagkaantala bilang isang problema sa store-and-forward dahil ang kumpletong payload ay dapat dumaan sa isang network hop bago magsimula ang susunod.
Sa segmented propagation, hinahati ng isang builder ang payload sa mga nakapirming piraso. Bawat segment ay nagdadala ng Merkle inclusion proof na nakaugnay sa root na na-commit sa execution bid. Ang isang receiving node ay maaaring suriin ang isang segment at simulang ipasa ito habang ang natitirang piraso ay dumarating pa rin.
Higit pa rito, inilalarawan ng talakayan sa EIP sa Ethereum Magicians ang nakaplanong pagbabago bilang pagpapalit sa nag-iisang payload message ng EIP-7732 ng mga independiyenteng mapapatunayang chunks. Ang draft ay kasalukuyang nagmumungkahi ng 64 chunks at isang Merkle proof structure na nag-uugnay sa bawat piraso sa orihinal na payload commitment. Sinabi ng mga mananaliksik na ang Merkle commitment ang pangunahing dagdag sa antas ng konsensus na kinakailangan para sa pangunahing segmentation. Pinananatili ng pinakabagong research prototype ang umiiral na gossipsub wire format, network mesh construction, peer degree at scoring system habang binabago kung paano nilalathala at ipinapasa ang mga piraso ng payload.
Kasalukuyang inilalarawan ng dokumentasyon ng Ethereum ang execution payloads bilang data na nauugnay sa transaksyon at estado na binuo ng execution client at dinadala sa pamamagitan ng proseso ng konsensus. Ang mga validator ay tumatanggap ng mga iminungkahing bloke sa pamamagitan ng consensus gossip network bago ipadala ang data ng pagpapatupad sa kanilang execution clients para sa pagpapatunay.
Ang pinakamalakas na pigura ng pagganap sa ulat ng Setyembre 17 ay nagmula sa isang kontroladong simulasyon. Iminodelo ng mga mananaliksik ang 500 node gamit ang heograpikal na network latency, 50 Mbps upload capacity at 100 Mbps download capacity, na may 1 MiB payload na nagmumula sa isang home builder at walang high-bandwidth data-center nodes.
Sa ilalim ng setup na iyon, ang pagpapadala ng payload bilang isang kumpletong mensahe ng gossipsub ay tumagal ng humigit-kumulang limang segundo upang maabot ang kalahati ng mga tumatanggap na node at malapit sa anim na segundo sa dulo. Ang isang naka-tune na segmented na bersyon ay umabot sa isang median na malapit sa 0.75 segundo at isang dulo na malapit sa isang segundo.
Binibigyang-diin ng mga mananaliksik na ang mga sukat ay nagmula sa isang simulation harness na nagpapatakbo ng tunay na Prysm at go-libp2p-pubsub code laban sa isang simulated network at virtual na orasan. Ang bawat sukat ay gumamit ng sampung randomized network configurations. Ang mga kondisyon ng mainnet ay maaaring magkaiba mula sa iminodelong topolohiya, bandwidth at pagpapalagay sa trapiko.
Ang kanilang pangunahing Tier 1 na disenyo ay pinagsasama ang segmentation sa batch publishing. Gamit ang 16 KiB segments, sinasabi ng ulat na ang median na pagpapalaganap para sa isang 1 MiB payload ay bumaba mula limang segundo hanggang wala pang isang segundo, habang ang tail latency ay bumaba mula sa humigit-kumulang anim na segundo hanggang higit sa isang segundo.
Binabago ng batch publishing kung paano ipinapadala ng source ang mga piraso. Sa halip na ipadala ang bawat kopya ng isang segment bago simulan ang susunod, ipinamamahagi ng builder ang iba't ibang piraso sa iba't ibang peer nang maaga, na nagpapahintulot sa ilang seksyon ng payload na magsimulang gumalaw sa network nang sabay-sabay. Sinabi ng mga mananaliksik na ang Tier 1 ay nangailangan ng humigit-kumulang isang-katlo pang natanggap na bytes kaysa sa pamamaraan ng buong mensahe ngayon. Ang tradeoff ay nagmumula sa pagpapadala ng maraming independiyenteng nakilalang piraso at ang karagdagang control messages na kinakailangan upang ipahayag ang mga ito.
Ang pangalawang iminungkahing tier ay tumatalakay sa duplicate na data. Sa halip na itulak ang bawat segment sa lahat ng eligible mesh peers, maaaring itulak ng mga node ang mga piraso sa isang limitadong grupo habang ipinapahayag ang availability sa iba. Humihiling lamang ang mga peer ng nawawalang segment kapag kinakailangan.
Pinagsasama ng prototype ang sistemang iyon sa tinatawag ng mga may-akda nito na disciplined pulls. Ang isang node ay unang humihiling ng isang segment mula sa isang peer, naghihintay ng isang tinukoy na timeout at lumilipat sa ibang source kung ang unang peer ay nabigo na magbigay.
Sa sukat ng 1 MiB payload, sinasabi ng pananaliksik na binawasan ng disciplined pulls ang natanggap na trapiko sa humigit-kumulang 1.5 payload copies per node, kumpara sa mas maraming duplicate na trapiko sa mas hindi kontroladong variants. Natuklasan ng mga mananaliksik na ang pagbabawas ng duplicates ay lalong naging kapaki-pakinabang kapag limitado ang magagamit na upload bandwidth.
Ang diskarte ay lumilikha ng isa pang tradeoff. Ang isang malisyoso o sobrang kargang peer ay maaaring magpahayag ng isang segment at pagkatapos ay tumangging ibigay ito. Sinubukan ng mga mananaliksik ang isang withholding scenario kung saan ang ilang node ay nag-anunsyo ng mga segment ngunit nabigo na sagutin ang mga kahilingan. Sa mas mataas na antas ng withholding, ang naka-tune na pull-based na disenyo ay nagpakita ng tumataas na tail latency. Sinubukan ng mga may-akda ang mas maikling timeouts at maraming posibleng request source bilang mga pamamaraan para sa paglilimita sa exposure na iyon.
Ang kanilang ikatlong tier ay nagdadagdag ng Reed-Solomon erasure coding. Ang isang payload ay kinocompress, ino-encode ng karagdagang parity pieces at hinahati sa mga segment. Maaaring buuin muli ng mga node ang payload pagkatapos makakolekta ng sapat na piraso nang hindi naghihintay sa bawat orihinal na segment.
Sinabi ng mga mananaliksik na ang coded model ay may pinakamababang tail latency sa kanilang mga pagsusuri at nanatiling functional kapag ang ilang segment ay pinigil. Ang gastos ay mas mataas na bandwidth sa publishing source dahil ang parity data ay nagpapataas ng dami ng ipinapadala.
Ang EIP-8411 ay kasalukuyang hindi isang activated na tampok ng Ethereum. Ang panukala sa GitHub ay binuksan noong Setyembre 4 at nananatiling may label bilang isang Draft networking EIP na naghihintay ng pagsusuri. Ang panukala ay nangangailangan ng EIP-7732, ang enshrined proposer-builder separation design ng Ethereum.
Hiniling ng mga developer ng Ethereum na matanggap ng EIP-8411 ang PFI, o Proposed for Inclusion, status para sa Hegotá, ang network upgrade na inaasahan pagkatapos ng Glamsterdam. Sa All Core Developers Execution discussion noong Setyembre 10, sinabi ng mga developer na ang panukala ay dapat isaalang-alang ng consensus-layer developer call dahil ang pagbabago ay pangunahing nakakaapekto sa consensus networking.
Ang kahilingan ay dumating pagkatapos ng normal na deadline ng Hegotá PFI. Iminungkahi ng mga tagasuporta nito ang EIP-8411 bilang kapalit ng EIP-8142, na ginalugad ang paglalagay ng mga bloke sa mga blobs ngunit nagtaas ng mga alalahanin tungkol sa builder-side KZG proving at muling paggamit ng data-availability subnets.
Ang ACDC #187 agenda ay nagtatakda ng EIP-8411 PFI discussion para sa Setyembre 17 ng 14:00 UTC. Sa oras ng ulat na ito, hindi pa nagaganap ang tawag, kaya walang desisyon na isama ang EIP-8411 sa Hegotá ang naitala.
Pinaghihigpitan ng mga developer ang feature set ng Hegotá sa account abstraction, scaling, censorship resistance at iba pang protocol work. Ang EIP-8411 ay pumasok sa proseso na iyon nang mas huli kaysa sa maraming panukala at nangangailangan pa rin ng desisyon ng core-developer sa pagsasama.
Ang panukala sa networking ay nakatali sa trabaho ng Ethereum sa pagpapataas ng kapasidad ng Layer 1. Ang mas malalaking gas limits ay maaaring humantong sa mas malalaking execution payloads, na nagpapataas ng dami ng data na dapat matanggap ng mga validator sa loob ng nakapirming consensus deadlines. Ang gas limit ng Ethereum ay umabot sa 60 milyon noong huling bahagi ng 2025 matapos ipahiwatig ng mga validator ang suporta para sa pagtaas.
Inilarawan ni Vitalik Buterin ang mas mataas na kapasidad ng Layer 1, PeerDAS at hinaharap na ZK-EVM work bilang bahagi ng plano sa scaling ng Ethereum. Ang mas mabilis na paghahatid ng payload ay sinasaliksik kasama ng mga pagbabagong iyon dahil ang mas malalaking mensahe ng network ay nagbibigay ng mas malaking pressure sa node bandwidth at propagation deadlines.
Inilathala ng mga mananaliksik ang mga prototype na implementasyon para sa Prysm at go-libp2p-pubsub. Ang inirerekomendang variant—isang Prysm branch—ay naglalaman ng serye ng mga pagbabago sa likod ng isang –enable-segmented-payload-gossip flag, habang ang kasamang libp2p branch ay nagpapatupad ng mga patakaran sa pagpapasa at kahilingan na ginamit sa pag-aaral.
Tahasan inilalarawan ng mga may-akda ang kanilang research branch bilang "isang harness, hindi isang panukala." Ang ilang tampok na sinukat sa papel, kabilang ang mga advanced na configuration ng erasure-coding, ay nananatiling eksperimental na bahagi ng test environment at hindi kinakailangang bahagi ng minimum na detalye ng EIP-8411.
Ang mga bukas na tanong na kinilala ng mga mananaliksik ay kinabibilangan ng tumaas na control-message traffic, gastos ng CPU mula sa pagproseso ng maraming maliliit na mensahe, alternatibong pagmamapa ng segment, queue management, timer tuning at kung ang isang mas bagong QUIC-focused networking stack ay maaaring magbunga ng iba't ibang resulta.
Plano ng mga may-akda ang karagdagang paghahambing sa pagitan ng single-topic design na ginamit ng variant A, partial-message approaches at mga modelo na nagtatalaga ng magkahiwalay na gossip topics sa indibidwal na segment. Pinananatili ng kasalukuyang prototype ang 16 KiB pieces bilang inirerekomendang batayan pagkatapos ipakita ng mga simulasyon na ang mas maliliit na 8 KiB pieces ay hindi nagbunga ng karagdagang pakinabang sa latency habang pinapataas ang control traffic.








