EIP-8141: Bakit hindi isang pangunahing tampok ang Native Account Abstraction sa Hegota Upgrade ng Ethereum

Isinulat ni: imToken

Noong nakaraang linggo, sa pormal na pagpupulong ng mga developer ng Ethereum, tinalakay ang pagkakaroon ng EIP-8141 sa Hegota upgrade, at ang resulta ay naging hindi inaasahan: ang proposal na sinuportahan ni Vitalik mismo ay hindi isinama bilang “pangunahing tampok” ng Hegota, kundi natanggap ang katayuan na “nasa pag-iisip” (CFI).

At ang linggong ito, ang Google Quantum AI team ay naglabas ng kanilang pinakabagong white paper, na nagpapahayag na sa ilalim ng kanilang ibinigay na mga aksiyon sa hardware, ang pagtatantiya ng bilang ng physical quantum bits na kailangan upang sirain ang ECDLP-256 ay bumaba ng 20 beses kumpara sa nakaraan. Bagaman hindi ito nangangahulugan na ang quantum attack ay malapit na, ito ay isang malinaw na paalala na kung ang sistema ng account ay hindi makakapag-adjust ng logic ng pag-verify sa hinaharap, marami sa mga diskusyon tungkol sa wallet experience ngayon ay maaaring magmaliw sa mga isyu sa seguridad.

Kahit sa pananaw ng praktikal na pag-unlad ng protokolo, ang EIP-8141 ay kasalukuyang masyadong mabigat, lalo na sa pagpapatupad ng client, kaligtasan ng transaction pool, at kumplikadong pag-verify, at hindi pa nabuo ang sapat na malalim na pagkakasundo.

Ngunit sa kasalukuyang punto sa panahon, tila lalong dumarami ang mga aspeto ng EIP-8141 na dapat pag-usapan at suriin nang serio.

Ang EIP-8141, na itinataguyod ni Vitalik Buterin at iba pang pangunahing kontribyutor tulad ni timbeiko, ay may opisyal na pangalan na Frame Transactions.

Kung isasalin ito sa isang mas madaling maintindihang pangungusap, ang layunin nito ay hindi lamang dagdagan ang isang partikular na wallet function, kundi subukang gawing walang hangganan sa protokol na antas ang anumang account mula sa pagiging nakabatay sa isang solong ECDSA signature path, at bigyan ito ng mas fleksibong logic para sa pag-verify at pag-execute.

Ito ay nangangahulugan na ang multi-signature, gas sponsorship, key rotation, social recovery, at kahit pa ang pagkakonekta sa mga quantum-resistant signature scheme sa hinaharap, ay hindi na lamang mga eksternal na plugin sa labas ng wallet, kundi may pagkakataon na maging mga “pribadong miyembro” sa Ethereum account system.

Kung titingnan mo lang sa ibabaw, ang EIP-8141 ay tumatalakay sa isang set ng mga kakayahan na tila napakaspesipiko: pagbabayad ng Gas gamit ang stablecoin, pagpapagsama ng maraming hakbang sa isang transaksyon, pagtutulungan sa mas fleksibong paraan ng pag-sign, at kahit pag-iisip para sa mga susunod na quantum-resistant signatures. Maaaring sabihin na mula pa noong ERC-4337 hanggang sa EIP-7702, ang maraming pagpapabuti sa user experience ng wallet ay naghahatid sa isang account na hindi na lamang isang private key, kundi isang entry point na may kakayahang magtakda ng sariling mga patakaran.

Ang problema ay ang mga pagpapabuti na ito ay talagang ginawa ang wallet na mas mukhang smart account, ngunit hindi pa talaga nasasakop ang pinakamababang default account model ng Ethereum.

Kilala nang malawak na na sa ilalim ng umiiral na sistema, ang mga account ng Ethereum ay nahahati sa dalawang pangunahing klase. Ang isa ay ang externally owned account, o ang EOA na kilala nating lahat, na kinokontrol ng private key at makakapag-initiate ng mga transaksyon, ngunit walang kakayahang programmable; at ang isa pa ay ang contract account, o ang sarili ng smart contract, na makakapag-execute ng mga kumplikadong lohika, ngunit hindi makakapag-initiate ng transaksyon nang sarili nito.

Nagdudulot ito sa pagkakabind ng kakayahang mag-initiate ng transaksyon sa isang solong private key signature; habang nananatili ang premisang ito, mahirap gawing default na kakayahan ng account ang maraming mga kakayahan na itinuturing ng maraming user bilang karaniwan ngayon, tulad ng pagbabago ng signature rules nang flexibly, pagpapautang ng gas sa iba, pagbabalik ng kontrol sa account pagkatapos mawala ang private key, o ang malambot na paglipat sa isang bagong cryptographic system sa hinaharap.

Kung nagamit mo na ang imToken o iba pang Web3 wallet, malamang ay nakaranas ka na ng mga sumusunod na problema: halimbawa, mayroon ka ng maraming USDC sa iyong wallet ngunit wala kang ETH upang magpadala ng transaksyon (dahil ang Gas ay maaaring bayaran lamang gamit ang ETH); nawala ang iyong recovery phrase at nawala na ang lahat ng pera mo nang hindi makapag-recover; ang isang operasyong “authorization + exchange” ay nangangailangan ng dalawang pag-sign at dalawang pag-verify.

Ang mga problema na ito ay hindi dahil sa "hindi sapat na magandang" wallet product, kundi dahil sa disenyo mismo ng Ethereum account model.

Sa pananaw na ito, ang pag-unlad sa nakalipas na dalawang taon ay lubos nang malinaw: ang ERC-4337 ay nagpapatakbo ng account abstraction sa application layer nang hindi nagbabago ng protocol; habang ang EIP-7702 ay nagpatunay pa na ang EOA ay hindi ganap na hindi maaaring i-extendo, kahit pa lamang pansamantala ay maaari itong makakuha ng ilang kakayahan na katulad ng smart account.

Ibig sabihin, ang Ethereum ay hindi nag-iisip na huwag gawin ang account abstraction, kundi patuloy na umaabot dito sa mas maayos at mas konservatibong paraan. Ang pagkakaroon ng EIP-8141 ay nangangahulugan na ang path na ito ay napunta sa isang bagong punto. Hindi na ito nakakatugon sa pagdaragdag ng isang layer ng smart account capability sa palibot ng umiiral na sistema, kundi sinusubukang i-embed ang account abstraction nang direkta sa loob ng transaction model, upang maging may kakayahang programmatically verify at execute ang mga account mula sa protokol layer.

Ito ang dahilan kung bakit bumabangon muli ang EIP-8141 ngayon. Sa isang panig, ang user experience ng wallet ay nagsisigla na sa malapit sa native account abstraction, at ang protokol layer ay kailangang masundan sa isang pagkakataon; sa ibang panig, ang matagalang presyon mula sa quantum computing ay nagpapabilis na ang tanong kung “kaya bang palitan nang fleksibleng paraan ang paraan ng pag-sign ng account” mula sa isang malayong teknikal na isyu tungo sa isang real na problema na kailangang seryosong tukuyin.

Sa wakas, ang EIP-8141 ay naglalayong magdagdag ng isang bagong uri ng transaksyon—ang Frame Transaction, na may transaksyon type code na 0x06.

Kung ang pangunahang lohika ng tradisyonal na transaksyon sa Ethereum ay isang transaksyon kada isang pagtawag, ang EIP-8141 ay nagsisikap na hatiin ang isang transaksyon sa isang hanay ng mga “frame” na maaaring pagsunud-sunurin ayon sa mga patakaran, upang hiwalayin ang tatlong gawain—pag-verify, pagbabayad, at pagpapatupad—na dati ay nakabukod.

May tatlong mode ng pagpapatakbo sa bawat 「frame»:

• VERIFY (pag-verify ng frame): Nagtataglay ng pag-verify kung合法 ang transaksyon, ito ay tumataas ng custom na verification logic ng account, at kung matagumpay, ito ay tatawagin ang bagong idinagdag na APPROVE opcode upang bigyan ng pahintulot ang pagpapatupad at tukuyin ang gas limit.
• SENDER (magsend ng frame): Nagpapatupad ng mga aktwal na aksyon, tulad ng paglipat ng pondo, pagtawag sa contract, atbp. Ang address ng tagapag-imbak ay ang mismong tagapagpadala ng transaksyon.
• DEFAULT (entry frame): Gamitin ang system entry address bilang caller, para sa mga skena tulad ng deployment ng contract at pag-verify ng Paymaster;

Ang kahalagahan ng mekanismong ito ay hindi ang paggawa ng mga transaksyon na mas kumplikado, kundi ang unang pagkakataon na hihiwalayin ang "pag-verify, pagbabayad, at pagpapatupad" mula sa mga aksyon ng account at ipagkaloob sa native scheduling ng protokolo.

Sa nakaraan, ang pag-verify ng transaksyon, ang pagbabayad ng Gas, at ang pagpapatupad ng totoong aksyon ay karaniwang naka-ugnay sa iisang account action; sa ilalim ng disenyo ng EIP-8141, ang mga ito ay maaaring hiwalayin sa iba’t ibang frame at isasagawa ng protokolo sa tiyak na pagkakasunod-sunod, at dahil dito, ang account ay hindi na nakasalalay lamang sa isang pribadong key para sa “buong pag-sign,” kundi nagsisimula nang magkaroon ng hugis na mas malapit sa isang programmable execution entity.

Halimbawa, kung nais mong gamitin ang USDC para magbayad ng Gas upang makumpleto ang isang Swap, sa ilalim ng EIP-8141 framework, maaaring isama ang proseso sa isang buong frame workflow: una ay veripikahin ng account ang signature at mga pagsang-ayon sa pagpapatupad, pagkatapos ay veripikahin ng tagapagbayad o Paymaster ang kanilang pagkakasang-ayon na tanggapin ang gastos, sumunod ay maisasagawa ang pagbabayad ng bayad para sa kaugnay na asset, at huli ay maisasagawa ang tunay na swap operation.

Sa ganitong paraan, ang pagbabayad ng Gas at ang pangunahing transaksyon ay maaaring isama sa isang magkaka-ugnay na proseso, kung saan o lahat ay matagumpay o lahat ay irerevoke.

Ang pinakamadaling makita na pagbabago para sa mga user ay ang maraming mga operasyon na dati ay kailangang hatiin sa dalawa o tatlong hakbang, na may panganib ng pagkabigo sa pagitan, ay magiging mas tulad ng isang buong aksyon sa hinaharap; kaya ang atomisidad na ito ay isa sa mga pangunahing solusyon ng EIP-8141 sa problema ng pagkakabawas ng用户体验.

Ano ang ibig sabihin nito para sa mga gumagamit ng wallet? Sa resulta, ang pinakatuwid na pagbabago ay may kahit anong apat na antas:

• Ang pagbabayad ng gas ay iniiwan: ang pagkakaroon ng stablecoin sa iyong wallet ay hindi na nangangahulugan na kailangan mong maghanda ng karagdagang ETH para magamit, at sa hinaharap, ang pagbabayad ng gas ng dapp, paymaster, o iba pang tagapagbigay-suporta ay magiging mas natural;
• Nilalagay ang maraming hakbang: Ang mga proseso na kadalasang nangangailangan ng maraming pag-sign, tulad ng «pagsasang-ayon + Swap» at «pagsasang-ayon + staking», ay may posibilidad na ma-package bilang isang mas kompletong pagkilos;
• Naka-on ang mga patakaran sa seguridad ng account: ang multi-signature, social recovery, daily limits, time lock, at key rotation ay hindi na lamang mga advanced feature na ibinibigay ng isang wallet product, kundi simula nang magkaroon ng pagkakataon na mabuo sa mas native na account logic;
• Hindi na kailangang maging nakasalalay sa isang path ng ECDSA ang scheme ng pag-sign: Nagbibigay ito ng unang posibilidad sa protokolo na mag-move ang account patungo sa iba’t ibang cryptographic system, kabilang ang mga post-quantum signature scheme;

Isang mahalagang punto na madalas na nakakalimutan, ngunit mahalaga para sa mga gumagamit ng wallet: kahit na matutupad ang EIP-8141, ang umiiral na sistema ng account ay hindi bubura.

Kahit gamit mo na ang imToken o iba pang mga Web3 wallet, hindi ka kailangang mag-migrate, dahil ito ay backward compatible; ang iyong umiiral na EOA address ay maaari pa ring gamitin, at kailangan mo lang piliin ang "upgrade" sa verification logic ng iyong account sa tamang panahon.

Ngunit sa kabaligtaran, ito ay eksaktong dahil sa malalim na pagbabago nito na hindi ito direktang naging pangunahing tampok ng Hegotá sa pinakabagong bilang ng diskusyon. Gayunpaman, ayon sa proseso ng EIP champion noong 2026, ang kahulugan ng CFI (Considered for Inclusion) ay hindi isang pagtanggi, kundi isang pagpasok sa malalim na pag-aaral, ngunit hindi pa sa huling pagpapasya o paglulunsad.

Sa ibang salita, ang mga pangunahing developer ay hindi nagtatanggi sa direksyon ng EIP-8141, kundi habang nagtataas ng halaga nito, nananatili silang naniniwala na ito ay kasalukuyang masyadong “mabigat”.

Sa katotohanan, ang native account abstraction ay hindi tulad ng ERC-4337 na maaaring unang itaguyod ng ilang mga wallet, infrastructure, at aplikasyon; kapag ito ay pumasok sa protokolo layer, ibig sabihin nito ay kailangan ng lahat ng execution layer clients na mabuti nang implemntahin, subukan, at i-coordinating, na likas na itaas ang hadlang sa pagpapalaganap at gagawing mas mapagbati ang mga core developer sa pagpaplano ng fork.

Ano ang mangyayari sunod? Maaari itong i-split sa dalawang linya:

• Kasalukuyang nasa CFI status ang EIP-8141, kaya ito ay patuloy na binabawasan; ang may-akda ng proposal ay magpapatuloy sa pagpapabuti ng mga mahahalagang detalye tungkol sa seguridad ng transaction pool, mga patakaran sa pag-verify, at implementasyon ng client, at ang susunod na ACD meeting ay magrereview muli kung may sapat na kondisyon ito para sa karagdagang pag-unlad;
• Kung maaaring mapababa nang patuloy ang mga kakaibang ito, may pagkakataon itong makapasok sa mas tunay na pagsasama sa susunod na upgrade; kung hindi, maaari itong ma-extend patungo sa mas huling upgrade cycle;

Totoo naman na ang EIP-8141 ay hindi ang tanging propuesta para sa native account abstraction, at hindi rin ito isang umiiral na post-quantum signature scheme na kayang direktang lutasin ang mga problema sa quantum computing, ngunit ang kahalagahan nito ay nasa pagkakataon nito na unang nagbigay ng isang protocol-level na out para sa mga account na makalaya sa iisang path ng ECDSA.

Sa pananaw na ito, ang tunay na halaga ng EIP-8141 ay hindi nasa pagiging ito ang tanging tamang sagot, kundi sa pagpapakita nito nang buong pagkakataon sa mesa ng diskusyon ng Ethereum protocol ang tanong, “Ano ba talaga ang huling anyo ng native account abstraction?”

Hindi ito ang tanging solusyon, ngunit isa ito sa pinakamalalaking at pinakamalapit sa limitasyon ng imahinasyon ng "puno at native AA" sa kasalukuyan.

Anuman ang resulta ng EIP-8141, ang talakayan mismo ay nagpapakita ng isang bagay:

Hindi naghintay ang Ethereum sa paglalago ng mga problema, kundi naghahanda nang mabuti para sa susunod na henerasyon ng account system sa pamamagitan ng patuloy na pag-unlad.