✳flâneur — a map of the web's best reading

EIP-2938: Account Abstraction

eips.ethereum.org · 4,296 words · saved by 1 readers

Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution. See also: https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020 and the links therein for historical work and motivation. Transaction validity, as of Muir Glacier, is defined rigidly by the protocol: ECDSA signature, a simple nonce, and account balance. Account abstraction extends the validity conditions of transactions with the execution of arbitrary EVM bytecode (with some limits on what state may be accessed.) To signal validity, we propose a new EVM opcode PAYGAS, which also sets the gas price and gas limit the contract is willing to pay. We split account abstraction into two tiers: single-tenant AA, which is intended to support wallets or other use cases with few participants, and multi-tenant AA, which is intended to support applications with many participants (eg. tornado.cash, Uniswap). The existing limitations preclude innov

EIP-2938: Account Abstraction 🛑 Withdrawn Standards Track: Core EIP-2938: Account Abstraction Authors Vitalik Buterin ( @vbuterin ), Ansgar Dietrichs ( @adietrichs ), Matt Garnett ( @lightclient ), Will Villanueva ( @villanuevawill ), Sam Wilson ( @SamWilsn ) Created 2020-09-04 Withdrawal Reason Very out of date; needs rewrite. Discussion Link https://ethereum-magicians.org/t/eip-2938-account-abstraction/4630 Requires EIP-2718 Table of Contents Simple Summary Abstract Motivation Specification Single Tenant Single Tenant+ Multi-Tenant & Beyond Rationale Nonces still enshrined in single-tenant

Explore this link on the map →

saved by

related reading