Inilatag ng co-founder ng Ethereum na si Vitalik Buterin ang isang pangmatagalang modelo ng transaksyon noong Setyembre 6 na maaaring magpahintulot sa network na iproseso ang ilang trabaho sa pagpapatunay nang parallel.
Pinaghihiwalay ng kanyang panukala ang mga epekto na nalilikha ng mga transaksyon mula sa mga kondisyon na dapat matugunan bago maganap ang mga epektong iyon.
Inilarawan ni Buterin ang dalawang bahagi bilang “actions” at “dependencies” sa isang detalyadong post. Binabago ng mga aksyon ang estado ng Ethereum, tulad ng paglilipat ng ETH o pagtawag sa isang kontrata. Sinasaklaw ng mga dependencies ang impormasyong kinakailangan upang matukoy na ang isang transaksyon ay valid.
Ang isang digital signature ay isang halimbawa ng dependency. Kabilang sa iba pang mga halimbawa ang Merkle proofs na nagpapakita na mayroong isang hindi nagamit na output, zero-knowledge proofs, at mga kondisyon ng estado na dapat manatiling totoo kapag ang isang transaksyon ay pumasok sa isang block.
Nagtalo si Buterin na ang paggawa ng pagkakaibang ito nang malinaw ay makakatulong sa Ethereum na makapag-scale nang hindi iniiwan ang flexible nitong kapaligiran sa pagpapatupad. Gayunpaman, ang panukala ay nananatiling bahagi ng patuloy na pananaliksik sa protocol. Hindi pa inaprubahan ng mga developer ng Ethereum ang buong disenyo para sa deployment.
Kasalukuyang pinagsasama ng mga transaksyon sa Ethereum ang awtorisasyon, pagbabayad ng bayarin, at pagpapatupad sa loob ng isang karaniwang daloy ng pagpoproseso. Sinusuri ng mga node kung ang isang transaksyon ay maayos na napirmahan, kung ang nagpadala ay kayang magbayad para dito, at kung ang mga instruksyon nito ay matagumpay na naipatupad.
Ang ilan sa mga pagsusuring ito ay hindi nakasalalay sa mga huling pagbabago sa estado ng transaksyon. Sinabi ni Buterin na ang gayong mga dependency ay maaaring iproseso nang hiwalay at, sa maraming kaso, sabay-sabay.
Halimbawa, maaaring kailanganin ng isang validator na kumpirmahin ang isang pirma bago tanggapin ang isang transaksyon. Hindi kinakailangang maghintay ang verification na iyon para sa mga hindi nauugnay na pirma na nakakabit sa iba pang mga transaksyon. Kung maraming independiyenteng pagsusuri ang alam nang maaga, maaaring ipamahagi ng mga client ang trabaho sa mga available na mapagkukunan ng pagpoproseso.
Ang mga state-dependent na pagsusuri ay nangangailangan ng higit na pag-iingat. Ang isang kondisyon na nakatali sa balanse ng account o storage slot ay maaaring maging invalid kung ang isang naunang transaksyon ay nagbabago ng parehong estado. Sinabi ni Buterin na mas epektibong masusuri ng mga mempool ang mga kondisyong ito kapag ipinapahayag ng mga transaksyon kung aling bahagi ng estado ang kanilang ina-access.
Ang pamamaraan ay magbibigay ng gantimpala sa mga mahuhulaan na transaksyon. Ang mga operasyon na malinaw na tumutukoy sa kanilang mga dependency ay maaaring makatanggap ng mas mababang halaga ng gas dahil mas mahusay itong ma-verify ng mga client. Ang mga transaksyon na nangangailangan ng dynamic na tawag at hindi mahuhulaan na pag-access sa estado ay mananatiling posible ngunit maaaring mas mahal.
Tinantya ni Buterin na higit sa 90% ng aktibidad ng Ethereum ayon sa volume ay hindi nangangailangan ng buong antas ng dynamic na flexibility ng network. Ang figure na iyon ay kanyang pagtatasa sa halip na isang na-publish na pagsukat ng network sa loob ng post. Ang mas malawak na argumento ay ang karaniwang paglilipat at regular na interaksyon ng kontrata ay maaaring gumamit ng mas mahigpit na format nang hindi nililimitahan ang mga espesyal na aplikasyon.
Ang iminungkahing modelo ay magpapanatili ng flexible na sistema ng account ng Ethereum para sa mga transaksyon na nangangailangan nito. Ang mas mahuhulaan na aktibidad ay maaaring gumamit ng statically analyzable na istruktura na kahawig ng mga bahagi ng modelo ng transaksyon ng Bitcoin.
Gumagamit ang Bitcoin ng modelo ng unspent transaction output kung saan ang isang transaksyon ay tumutukoy sa mga output na balak nitong gastusin. Karaniwang gumagamit ang Ethereum ng mga account na may balanse, nonces, at programmable contract storage. Hindi iminumungkahi ni Buterin na palitan ng Ethereum ang modelo ng account nito ng arkitektura ng Bitcoin. Inilarawan niya ang isang spectrum na pinagsasama ang mga ideya mula sa parehong sistema.
Ang EIP-8141 ay isang draft na Ethereum Improvement Proposal para sa isang bagong uri ng transaksyon na kilala bilang Frame Transaction. Hinihati nito ang isang transaksyon sa contract-call frames na maaaring mag-validate ng awtoridad, aprubahan ang pagbabayad ng gas, at magsagawa ng mga operasyon ng user.
Sinasabi ng opisyal na panukala na ang bisa ng transaksyon at pagbabayad ng bayarin ay hindi na lamang nakasalalay sa isang karaniwang pirma na nakakabit sa panlabas na transaksyon. Maaaring tukuyin ng account code ang kinakailangang awtorisasyon at mga patakaran sa pagbabayad.
Maaaring suportahan ng Frame Transactions ang sponsored fees, pagbabayad sa mga token maliban sa ETH, pag-ikot ng susi, at transaction batching. Maaari din nitong pahintulutan ang mga externally owned accounts na makatanggap ng mga tampok ng account-abstraction nang hindi umaasa sa parehong contract deployment sa bawat katugmang network.
Sa ilalim ng iminungkahing istruktura, tutukuyin ng verification frames kung awtorisado ng nagpadala ang transaksyon. Ang magkahiwalay na frame ay maaaring magtatag kung sino ang magbabayad ng mga bayarin at pagkatapos ay isakatuparan ang mga hiniling na operasyon.
Ang istrukturang ito ay umaayon sa paghihiwalay ni Buterin sa pagitan ng mga dependency at aksyon. Ang mga verification frame ay humahawak ng mga kondisyon na dapat matugunan. Ang mga sender frame ay humahawak ng mga operasyon na nagbabago ng estado.
Maaari ding mapabuti ng format ang interoperability sa pagitan ng mga network ng Ethereum Virtual Machine. Ang iba't ibang chain ay maaaring sumuporta sa parehong minimal na istruktura ng transaksyon habang inilalapat ang kanilang sariling mga tool sa pagpapatunay, precompiles, o mga tampok ng account.
Inilarawan ni Buterin ang potensyal na format bilang isang pangunahing listahan ng mga tawag na may mga flag na nagtutukoy sa kanilang function. Ang isang tawag ay maaaring markahan bilang isang purong dependency, isang state-dependent na verification, o isang aksyon. Maglalaman din ang transaksyon ng karaniwang impormasyon tulad ng pinagmulan nito at nonce.
Ang EIP-8141 ay nananatiling inuri bilang isang draft na Core proposal. Ang kasalukuyang espesipikasyon nito ay naglalaman ng mga detalyadong patakaran para sa pagtanggap sa mempool, pagpapatupad ng frame, mga resibo, mga pirma, accounting ng gas, at pagpapalaganap ng transaksyon. Maaaring magbago ang mga detalyeng iyon sa panahon ng pagsusuri.
Pinagdebatihan din ng mga developer ng Ethereum ang mga teknikal na alalahanin. Kabilang dito ang mga panganib ng denial-of-service, mga panuntunan sa pagpapalit ng transaksyon, mga pagbabago sa tooling, mga limitasyon sa pending na transaksyon, at mga paghihigpit na inilagay sa verification frames.
Isang diskusyon ang nagsabi na ang iminungkahing pampublikong mempool ay karaniwang magpapanatili lamang ng isang pending na Frame Transaction para sa bawat nagpadala. Kinuwestiyon ng mga developer kung paano makakaapekto ang panuntunang iyon sa mga account na regular na nagsumite ng ilang transaksyon sa loob ng isang block.
Sinuri ng ibang mga kalahok kung nagpapakilala ang format ng karagdagang kumplikasyon para sa mga wallet, block builder, at mga interface ng remote procedure call ng Ethereum. Ang mga katanungang ito ay dapat malutas bago maipatupad ng mga client team ang isang matatag na espesipikasyon.
Ang mas pangmatagalang modelo ni Buterin ay lumalampas sa EIP-8141. Iminungkahi niya na ang mga dependency na hindi nangangailangan ng pag-access sa estado ay maaaring suriin nang isang beses sa layer ng mempool sa halip na ulitin ng bawat validator.
Maaaring kasama sa isang purong dependency ang isang cryptographic signature o patunay na ang bisa ay hindi nagbabago sa estado ng Ethereum. Pagkatapos suriin ito, maaaring palitan ng network ang maraming piraso ng trabaho sa verification ng isang recursive STARK na kumukumpirma na ang lahat ng pagsusuri ay nakumpleto nang tama.
Ang isang STARK ay isang cryptographic proof na nagpapahintulot sa isang partido na ipakita na ang isang komputasyon ay isinagawa nang tama. Maaaring i-verify ng mga recursive proof ang iba pang mga proof, na ginagawang posible na pagsamahin ang maraming pagsusuri sa isang mas maliit na gawain sa verification.
Ang iminungkahing mempool ay maaaring mag-aggregate ng mga pirma ng transaksyon, mga proof ng bisa, at iba pang mga dependency bago ang pagpapatupad ng block. Pagkatapos ay i-verify ng mga validator ang pinagsamang proof sa halip na independiyenteng ulitin ang bawat orihinal na komputasyon.
Iminungkahi ni Buterin na ang pamamaraang ito ay maaari ding magpababa ng dami ng data ng verification na inilagay on-chain. Kung ang recursive proof ay nagtatatag na ang lahat ng mga dependency ay valid, ang ilan sa orihinal na data ay posibleng maalis.
Ang kinalabasan na iyon ay hindi bahagi ng kasalukuyang espesipikasyon ng EIP-8141. Kakailanganin nito ng karagdagang pananaliksik na sumasaklaw sa pagbuo ng proof, koordinasyon ng mempool, pagkakaroon ng data, at mga proteksyon laban sa invalid na aggregation.
Ang disenyo ay nauugnay din sa paghahanda ng Ethereum para sa post-quantum cryptography. Ang mga quantum-resistant na pirma ay karaniwang mas malaki at mas mahal i-verify kaysa sa mga pirma ng ECDSA na ginagamit ng ordinaryong mga account ng Ethereum.
Maaaring pahintulutan ng EIP-8141 ang mga account na tukuyin ang mga bagong scheme ng awtorisasyon nang hindi naghihintay na palitan ng Ethereum ang isang solong nakapirming pamantayan ng pirma. Ang recursive proof aggregation ay maaaring magpababa ng halaga ng pag-verify ng malalaking post-quantum signature.
Maaaring makatulong ang EIP-8141 sa mga account ng Ethereum na gamitin ang post-quantum authorization kung magiging available ang mga praktikal na sistema ng pirma. Iyan ay nananatiling isang pangmatagalang landas sa seguridad sa halip na isang agarang tugon sa isang aktibong banta ng quantum.
Gumagamit ang mga account ng Ethereum ng sequential nonces upang maiwasan ang replay ng transaksyon. Kung ang isang account ay nagsumite ng mga transaksyon na may bilang na 10, 11, at 12, karaniwang ipinoproseso ng network ang mga ito sa pagkakasunud-sunod na iyon.
Ang sequence ay maaaring lumikha ng isang bottleneck. Kung ang transaksyon 10 ay natigil o invalid, ang mga susunod na transaksyon mula sa parehong account ay maaaring maghintay din, kahit na ang kanilang mga operasyon ay hindi nauugnay.
Ang keyed nonces ay magbibigay sa isang account ng ilang independiyenteng sequence ng nonce. Ang mga transaksyon na nakatalaga sa iba't ibang susi ay maaaring magpatuloy nang hindi naghihintay na umusad ang isa pang sequence.
Makatutulong ito sa mga smart accounts, privacy systems, at mga aplikasyon na nagsumite ng ilang independiyenteng operasyon nang sabay-sabay. Ang bawat workflow ay maaaring makatanggap ng sarili nitong nonce domain habang pinapanatili ang replay protection.
Naunang iniulat ng Crypto.news na ang keyed nonces ay maaaring maiwasan ang independiyenteng pribadong transaksyon mula sa pagharang sa isa't isa. Ang tampok na ito ay bahagi ng isang mas malawak na pagsisikap upang mapabuti ang mga transaksyon sa privacy, flexible na account, at paglaban sa censorship.
Ikinonekta din ni Buterin ang trabaho sa transaksyon sa mga alternatibong modelo ng estado, kabilang ang native na disenyo ng UTXO at proof-based na istruktura ng estado. Pinag-aaralan ng mga proyektong ito kung ang ilang mga asset o operasyon ay maaaring gumamit ng mahuhulaan na mga patakaran ng estado habang ang mga kumplikadong kontrata ay nagpapanatili ng umiiral na flexibility ng Ethereum.
Ang pamamaraan ay maaaring lumikha ng ilang antas ng pagpoproseso. Ang simple, idineklara na operasyon ay mas madaling suriin at maaaring makatanggap ng mas mababang bayarin. Ang mga dynamic na tawag sa kontrata ay patuloy na gagana ngunit gagamit ng mas maraming mapagkukunan dahil hindi maihahanda ng mga client ang kanilang pagpapatupad sa parehong paraan.
Ang ganitong differentiated na pagpepresyo ay susubukan na iayon ang mga bayarin sa aktwal na mga paghihigpit sa scaling na nilikha ng bawat transaksyon. Hindi nito ginagarantiyahan ang mas mababang bayarin para sa bawat user o aplikasyon.
Dapat dumaan ang EIP-8141 sa ilang yugto bago ito makakaapekto sa mga user ng Ethereum. Kailangan munang magkasundo ang mga core developer na ang Frame Transactions ay nag-aalok ng mas mahusay na landas kaysa sa nakikipagkumpitensyang disenyo ng account-abstraction.
Ang panukala ay mangangailangan pagkatapos ng mga implementasyon ng client, development network, interoperability testing, suporta sa wallet, at security review. Kakailanganin din ng mga developer na subukan kung paano nakikipag-ugnayan ang Frame Transactions sa mga block builder, mempool, fee market, at umiiral na mga smart contract.
Mas maaga, isinasaalang-alang ng mga developer ang EIP-8141 para sa hinaharap na Hegotá upgrade ng Ethereum. Gayunpaman, iniulat ng crypto.news na ang Frame Transactions ay nanatiling nasa ilalim ng pagsasaalang-alang sa halip na pormal na naka-iskedyul.
Ang FOCIL, isang hiwalay na panukala na nilayon upang mapabuti ang paglaban sa censorship sa pamamagitan ng transaction inclusion lists, ay tinalakay din kasama ng EIP-8141. Ang dalawang panukala ay tumutugon sa iba't ibang problema. Ang Frame Transactions ay tungkol sa istruktura ng awtorisasyon at pagpapatupad, habang ang FOCIL ay tungkol sa pagsasama ng mga karapat-dapat na transaksyon sa mga block.
Nagtalo ang mga developer na ang paggamit ng mga ito nang magkasama ay maaaring magbigay ng native na account abstraction na may mas malakas na paglaban sa censorship. Ang kombinasyong iyon ay isang iminungkahing pakete pa rin, hindi isang aprubadong pangako sa roadmap ng Ethereum.
Ang mga komento ni Buterin noong Setyembre 6 ay naglalarawan samakatuwid ng isang posibleng direksyon para sa disenyo ng transaksyon ng Ethereum. Hindi sila nagpapahayag ng isang natapos na upgrade, petsa ng activation, o kumpirmadong pagbabago sa mga bayarin sa gas ng mainnet.
Ang susunod na mapapatunayang milestones ay magiging pormal na suporta ng developer, pagsasama sa isang saklaw ng upgrade, at gumaganang implementasyon sa mga development network. Hanggang noon, ang EIP-8141 at recursive STARK mempools ay nananatiling aktibong pananaliksik at mga panukala sa engineering.
Iminumungkahi ng EIP-8141 ang Frame Transactions na naghahati ng validation, pag-apruba ng bayarin, at pagpapatupad sa magkahiwalay na contract-call frames.
Ito ay kasalukuyang isang draft na Core proposal. Maaari pa ring baguhin o tanggihan ng mga developer ng Ethereum ang espesipikasyon nito.
Ang isang aksyon ay nagbabago ng estado ng Ethereum, tulad ng pagpapadala ng ETH o pagtawag sa isang kontrata. Ang isang dependency ay isang kondisyon na dapat ay valid, tulad ng isang pirma o state proof.
Ang paghihiwalay sa mga ito ay maaaring magpahintulot sa mga independiyenteng dependency na iproseso nang sabay-sabay bago isakatuparan ang mga operasyong nagbabago ng estado.
Maaari nitong gawing mas mura ang pagpoproseso ng mga mahuhulaan na transaksyon kung ang mga developer ay magpatibay ng pagpepresyo ng gas na nagbibigay-gantimpala sa mga statically analyzable na operasyon.
Walang kumpirmadong pagbaba sa bayarin. Ang mga gastos ay depende sa huling espesipikasyon, implementasyon ng client, at mga desisyon sa upgrade sa hinaharap.
ETH