Isang Ethereum prototype na nagbabahagi ng mga gawain sa pag-recover ng blob sa mga node ay nagraport ng 11–18× na pagbawas sa inaasahang kompyutasyonal na gawain sa pag-reconstruct sa mga simulasyon ng 1,000-node. Ang mga resulta ay nagmumungkahi na ang mga operator ay maaaring bawasan ang duplicated na gawain sa pamamagitan ng mas maliit na pagbabago kaysa sa buong RowDAS networking proposal.
Ang report noong Sept. 3 ni Researcher Csaba Kiraly ay naglalarawan sa nabawasan na disenyo bilang posibleng unang hakbang patungo sa RowDAS. Ipinagkakaloob nito ang mga tungkulin sa pagpapalikod nang hindi ipinakilala ang mga bagong row-networking channels sa buong propuesta.
Ang mga blob ay nagdadala ng data na ginagamit ng layer-2 rollups. PeerDAS, ang sistema ng Ethereum para suriin kung available ang blob data, ay nagpapahintulot sa mga node na i-download ang bahagi lamang nito. Ang mga high-custody node ay may hawak na kahit anong 64 sa 128 na data columns, sapat upang mabuo ang nawawalang blob data; ang mga supernode ay may hawak lahat ng 128.
Maraming mataas na node na may kustodiya na maaaring ulitin ang parehong pagbuo. Ang pinababaw na disenyo ay nagtatalaga ng mga partikular na blob sa kanila muna, na nagpapahintulot sa iba na tanggapin ang narecover na data kesa agad na muling buuin ito.
Ano ang ipinapakita ng mga simulasyon ng Ethereum blob-recovery
Sa isang konfigurasyon na may apat na blob, 10% supernodes, at walang kolum na pinigil, bumaba ang inaasahang gastos sa pag-reconstruct ng buong network mula sa 48.6 CPU-sekundo sa ilalim ng PeerDAS model sa 2.75 CPU-sekundo sa ilalim ng pinababawas na disenyo. Sa 20% na bahagi ng supernodes, ang mga kaugnay na numero ay 91 at 6.6 CPU-sekundo.
Ang mga kabuuang ito ay naglalarawan sa nakumpol na pagkikilos ng kompyuter sa simulated na network, hindi sa natagal na panahon ng pagbabalik. Ang pagsasapamantalan ay gumagamit ng tukoy na gastos na 162-millisecond bawat pagbabalik ng blob sa isang Ryzen 9 8945HS processor. Ang bilis ng transaksyon at mga savings sa bayarin ay nasa labas ng mga inilapag na pagsusukat.
Ang PeerDAS baseline ay kasalungat na naglalaman ng randomized na paghintay at mga pag-check na nagpapalabas ng duplicate na pagbuo. Kaya ang paghahambing ay nagbibigay ng kredito sa umiiral na pag-uugali ng client para sa trabaho na iniiwasan ng mga paghihintay na iyon.
Sa mas maliit na bersyon, ang mga nakatakdang node ay nagbabahagi ng mga narecover na cell sa pamamagitan ng mga umiiral na channel ng column-distribution. Ang mga high-custody node ay nananatili sa papel ng delayed recovery para sa anumang patuloy na nawawala, na nagpapanatili ng PeerDAS-style na backstop.
Ang Full RowDAS, na nakasaad sa draft na EIP-8371, ay magdaragdag ng isa pang paraan ng pagkakabawi: ang mga row channel ay nagpapahintulot sa mga mas maliit na node na mag-ugnay ang kanilang data at muling buuin nang kolektibo kapag ang kanilang pinagsamang pagkakaroon ay lalampas sa threshold ng pagkakabawi. Ang pinababawang disenyo ay nananatiling nakadepende sa mga mataas na custodial node at hindi kayang magbigay ng karagdagang katatagan.
Ang mga pagsusukat ay patuloy na limitado sa mga sinimulang, sa-prosesong network na gumagamit ng totoong kriptograpiya. Walang resulta ang Kiraly mula sa devnet, at ang 128-row-subnet configuration ng buong disenyo ay isang ekstrapolasyon mula sa mas maliit na bilang ng subnet. Mas malalaking simulasyon at mga pagsubok sa totoong network ay nasa harap pa.
Hindi binabago ng EIP-8371 ang mga limitasyon ng blob, at ang propong paghihiwalay sa pagkakatanggol at row networking ay hindi pa nakalagay sa kanilang draft text. Ang agwat na pagkakataon ay mas maliit: pagbawas sa paggawa ng processor para sa pagpapalit, na ang mas malawak na benepisyo sa katatagan ay nakadepende sa susunod na row layer.
Ang post Ethereum ay maaaring may mas simpleng paraan upang mapabawasan ang presyon sa pagcompute ng patuloy na paglalawak ng kanyang ecosystem ang unang lumabas sa CryptoSlate.