Kamakalawian ng mga developer ng Ethereum, may bagong pag-unlad sa disenyo ng EIP-8141. Sinusubok ng propuesta na isulat ang ilang mga transaksyon bilang mga tawag sa programmable na contract, o “frames”, kaysa i-modify ang format ng Ethereum transaction bawat pagdaragdag ng isang bagong kakayahan.
I-update ang trading function para sa programmable call
Ang mga tampok na sakop ng ideyang ito ay ang pagtatapos ng transaksyon,聚合签名, Merkle root na may kaugnayan sa privacy pool, at ang pag-check ng assertion pagkatapos ng pagpapatupad ng transaksyon. Naniniwala ang mga developer na kung sapat na pangkalahatan ang set na ito ng interface, hindi kailangang mag-adjust ang mga wallet, browser, device ng pag-sign, at Layer 2 bawat beses na magdagdag ang Ethereum ng bagong paraan ng pag-verify.
Ang EIP-8141 draft ay nagtataglay ng isang Frame Transaction bilang isang hanay ng sequence ng contract calls. Ang iba’t ibang frame ay maaaring magtago ng pag-verify ng mga kondisyon ng transaksyon, pagpapahintulot sa pagbabayad ng gas, o pagpapatupad ng mga user action.
Kasalukuyang nakalista sa draft ang tatlong mode: DEFAULT, VERIFY, at SENDER. Ang VERIFY frame ay ginagamit upang i-check kung natutugunan ang isang kondisyon, habang ang SENDER frame ay kumakatawan sa pagpapatakbo bilang tagapagpadala ng transaksyon. Maaari ring mag组成 ng atomic batch ang maraming frame, kung saan o lahat ay matagumpay o bumabalik sa orihinal.
Mabawasan ang gastos sa pagkoordinasyon ng wallet at infrastraktura
Ang pangunahang pananaw ni Developer Derek Chiang ay ang mga bagong tampok sa hinaharap ay hindi kailangang magkaroon ng bagong disenyo ng trading wrapper. Maaaring palawakin ang kakayahan habang pinapanatili ang katatagan ng pangunahing istruktura sa pamamagitan ng paggamit ng mga bagong frame target at pagtawag na modelo.
Ang bawat pagbabago sa pagpapakilos ng transaksyon sa Ethereum ay hindi lang nakakaapekto sa execution clients. Ang mga wallet, Layer 2, mga blockchain explorer, mga hardware at software na pang-sign, at iba’t ibang serbisyong pang-impormasyon ay kailangang maintindihan at suportahan ang bagong format.
Sinabi ni Chiang na ang pag-update ng Ethereum ay nagpapalabas tuwing apat na buwan, at kung madalas baguhin ang pagpapakilos ng transaksyon, mataas ang gastos sa koordinasyon. Sa kumpara sa iyan, kung ang frame format ay maging mas matatag na interface, maaaring isauli sa kontrata o mga tukoy na komponente ng protokolo ang paggamit ng mga bagong paraan ng pag-verify.
Gayunpaman, hindi ito nangangahulugan na lahat ng mga function sa hinaharap ay maaaring iwasan ang pag-update ng network. Ang EIP-8141 ay patuloy na magbabago sa mga patakaran ng consensus ng Ethereum at nangangailangan ng implementasyon ng client. Kung kasali ang mga bagong opcode, precompiled contracts, o mga patakaran sa gas, maaaring kailanganin pa rin ang hard fork.
EIP-8130 at direksyon ng parallel verification
Acknowledge rin ng mga developer na mas mahirap ang pag-analyze ng mga transaksyon ng wallet at sorter bago ang pagpapatupad kapag ang antas ng abstraction ng transaksyon ay tumaas. Para dito, tinutuklasan ng team kung paano i-coordina ang EIP-8141 at ang ibang draft ng account abstraction na EIP-8130.
Ang EIP-8130 ay nagmumungkahi ng isang on-chain keystore structure na nagpapahintulot sa mga account na mag-pre-register ng mga participant at authentication contract, at magmark ng paraan ng pag-verify sa bawat transaksyon. Sa ganitong paraan, maaari ng mga node na matukoy ang uri ng proseso ng pag-verify na kailangan ng transaksyon bago sila patakbuhin ang anumang wallet code. Para sa Layer 2, nakakatulong ito sa paglimita sa isang set ng mas makabuluhan at mas maipagpalagay na mga paraan ng pag-verify.
Isinagawa ni Vitalik Buterin ang paliwanag tungkol sa direksyon sa isang iba pang post. Ibinahagi niya ang transaksyon bilang dalawang bahagi: "aksyon" at "mga kondisyon ng pagkakasunod-sunod". Ang unang bahagi ang responsable sa pagbabago ng estado ng Ethereum, habang ang pangalawa ay naglalaman ng mga panimulang kondisyon tulad ng pag-sign, Merkle proof, o zero-knowledge proof. Kung ang mga dependensyang ito ay magkakalayon, posibleng i-parallel na suriin sa hinaharap, na magdudulot ng pagbaba sa gastos sa pagproseso ng ilang transaksyon.
Nakalista na sa Hegotá, ngunit ang oras ng pagpapagana ay hindi pa nakatakda
Ang opisyal na Hegotá Meta EIP ay nakalista ang Frame Transactions bilang isa sa mga inaasahang pagpapabuti, na nangangahulugan na ang estado nito ay mas malapit na sa pagpapatupad kaysa dati. Gayunpaman, ang EIP-8141 ay kasalukuyang isang pangunahing draft, at ang mga teknikal na detalye ay hindi pa nagtatapos.
Ang mga susunod na gagawin ay kasama ang pag-update ng mga spesipikasyon, pagkumpleto ng implementasyon ng execution client, pagbuo ng development network, at pagpapagana ng interoperability test kasama ang wallet at Layer 2 systems. Kailangan din ng mga developer na suriin ang panganib ng memory pool denial-of-service dahil maaaring tumaas ang computational cost ng paghihiwalay ng invalid transactions dahil sa programmable verification.
Kasalukuyan, ang mga oras ng pag-activate ng Sepolia, Hoodi, at mainnet ng Hegotá ay patuloy na walang laman. Ang EIP-8141 ay nasa plano para sa upgrade, ngunit mayroon pa ring mahabang proseso ng pagpapatupad at pagsubok bago ito maging tapos.