Si Derek Chiang ng Ethlabs, na nagtatag ng ZeroDev, ay sinabi na natapos ang kolaborasyon upang pagkaisahin ang Base-led na EIP-8130 at ang Ethereum’s EIP-8141 Frame Transactions noong nakaraang linggo, nananatiling naghihiwalay ang dalawang panig sa pagpursige ng magkakaibang native na account-abstraction standards.
Ang opisyal na rehistro ng Ethereum Improvement Proposal ay listahan ang EIP-8130 at EIP-8141 bilang mga draft. Sinuportahan ng Ethlabs ang Frame Transactions para sa Hegotá, na itinuturing niya bilang isang darating na Ethereum hard fork, at sinasabi na handa siyang magtrabaho kasama ang Layer 2 at mga wallet sa pagpapalabas.
Sa praktikal na mga termino, ang hindi kompatibleng mga uri ng transaksyon ay magpapalipat ng higit pang integrasyon na trabaho sa mga developer ng wallet at application. Sabi ni Chiang na ang nabigo na pagsisikap ay “pagsasalot sa wallets upang harapin ang fragmentation na nangyayari,” bagaman sinabi niya na ang software ay maaari pa ring itago ang mga pagkakaiba na iyon mula sa mga user.
Paano nagkakaiba ang mga disenyo
Ang account abstraction ay nagpapahintulot sa mga smart-contract account na magtukoy ng kanilang sariling validation logic替代 sa pagtitiyak lamang sa mga fixed na patakaran para sa externally owned accounts. Ang huling ERC-4337 standard ay nagbibigay ng account abstraction nang hindi nagbabago sa mga consensus rules ng Ethereum: ang mga user ay nagpapadala ng `UserOperation` objects sa isang hiwalay na mempool, at ang mga bundler ay pinapakete ang mga ito sa mga transaksyon para sa isang EntryPoint contract.
Lumilipat ang parehong bagong draft ang mga punsiyon ng account abstraction sa native na pagtrato ng transaksyon, ngunit gumagamit sila ng iba’t ibang mga control point.
Ang EIP-8130 ay nagtatagpo ng isang bagong typed transaction kasama ang onchain keystore at account-configuration system. Ito ay sumusuporta sa custom authentication, batched calls, at gas sponsorship. Dahil bawat transaction ay nagdeklara ng kanyang authenticator, ang mga node ay makakakilala ng kinakailangang validation work at tatanggihan ang mga hindi kilalang authenticator bago ipagpatuloy ang arbitrary wallet code.
Ang draft na 8130 ay nagtataglay ng L1 profile na may permissive authenticator acceptance at isang L2 profile na limitado ang native transaction path nito sa isang canonical authenticator set. Ang istrukturang ito ay naglalayong bigyan ng maayos at makabuluhang gastos sa pagpapatotoo ang mga mataas na throughput na chain habang pinapanatili ang karaniwang baseline para sa mga wallet.
Ang EIP-8141 ay naghihiwalay sa isang transaksyon sa isang hanay ng mga “frame,” o mga pagtawag sa contract na nagpapatotoo sa transaksyon, nagpapahintulot sa pagbabayad ng gas at nagpapatakbo ng mga user operation. Ang disenyo nito ay nagpapahintulot sa mga account na gamitin ang EVM code upang tukuyin ang mga patakaran sa pagpapatotoo at pagbabayad ng gas, kasama ang suporta sa mga tampok tulad ng pagbabago ng key, batched calls at alternatibong pagbabayad ng bayad.
Nilikha ng Ethlabs ang pangunahing tradeoff: ang permissionless, EVM-based na pagpapatotoo ay nagbibigay ng flexibility sa Frame Transactions para sa privacy at mga hinaharap na sistema ng signature, ngunit ang mga dinamikong gastos sa pagpapatotoo ay maaaring magdulot ng mga hamon para sa mga high-throughput Layer 2. Pinapahalagahan ng EIP-8130 ang mas maayos na pagpapatotoo sa pamamagitan ng paggawa ng authenticator na eksplisito bago ang pagpapatupad.
Ang Portability ay Lumilipat Pataas sa Stack
Ang draft ng EIP-8130 ay patuloy na itinuturing ang portability bilang pangunahing pag-aalala. Sinasabi nito na ang mga account ay maaaring magtrabaho sa mga EVM chains na hindi sumusuporta sa uri ng transaksyon na 8130 gamit ang ERC-4337 o ibang transport mechanism. Kinakailangan rin nito na tanggapin ng mga kompliyanteng chains ang isang shared canonical authenticator set.
Kaya ang inihayag na paghahati ay hindi nangangahulugang gagawing hindi gamit ang isang 8130 account sa ibang EVM chain. Gayunpaman, ito ay hihinto sa pagpupursige na magtatag ng isang karaniwang native na anyo ng transaksyon para sa ethereum at Base kung magkakaroon ng hiwalay na pag-unlad ang dalawang draft. Kailangan ng mga wallet at apps na pumili ng angkop na transport at pagsusuri ng mga panuntunan para sa bawat chain.
Ipinakita ni Chiang ang dalawang posibleng tugon: palawigin ang koordinasyon sa mga mapagkukunan na ibinabahagi ng Ethereum at Layer 2, o tanggapin ang pagkakaiba ng protokolo at buuin ang mga wallet at aplikasyon na nag-aabstrak sa kanila mula sa mga gumagamit. Sa kasalukuyan, listahan ng opisyal na EIP registry ang parehong disenyo bilang mga draft.