Goals of AA Gas sponsorship: Where a different account (which can be a smart contract) pays for the fees of a transaction initiated by a different account Transaction batching: Easy one-to-many transactions that does a bunch of DeFi things at once Signer-Account split: Separate the funds from the private key to make key rotation/revocation easier Custom validation logic: Natively support multisigs, threshold signatures, different signature schemes, etc. but also things like "a single signature is enough to transfer under $x per day, but for larger amounts a 2-of-2 signature is needed", or force a delay for large transfers and have them be cancellable by an alternate private key Signature aggregation: Allowing the bundling of many transactions that can be verified by a single signature (e.g. with BLS signatures) Consensus is that we want all of these (and more), but it would be nice to have the first two on the short term. There are still questions/doubts:
3/12/20242024-02-28 Relevant links Call agenda and recording Execution Layer Meeting #182 which had a lot of AA discussion as well ERC-4337 - Account Abstraction Using Alt Mempool ERC-7562 - Account Abstraction Validation Scope Rules RIP-7560 - Native Account Abstraction EIP-3074 - AUTH and AUTHCALL opcodes
3/3/2024Significantly increase (or get rid of?) MAX_EFFECTIVE_BALANCE, allow large stakers to consolidate Limit active validator count to $2^{19}$ or $2^{20}$, or however many attestations per slot the beacon chain can handle for SSF When the count is reached, activate harberger tax/auction: Each operator decides how much their spot as a validator is worth, in ETH Anyone can take over an operator's validator spot by paying them their listed price Each operator pays a % of their spot's self-valuation as a recurring fee to keep their spot active (the fee gets burned, of course) Results:
6/5/2023How can you burn MEV? The first step is quantifying the amount of MEV, and the conceptually simplest way to do this is with Proposer/Builder Separation (PBS), where builders compete against each other and offer bribes to proposers for their block to be included, then the proposer simply has to pick the top bid. Here is a simple example to visualize this auction process: if there is 1 ETH of extractable value in a block, then a rational builder will not bid more than 1 ETH. With multiple builders competing over the same block, the top bid quickly approaches 1 ETH. For example, the winning bid might be 0.99 ETH: The proposer collects 0.99 ETH, and the builder collects this "delta" of 0.01 ETH as profits. Today, such auctions happen out of protocol via MEV-Boost. The first (and hardest) step in burning MEV is to enshrine Proposer/Builder Separation directly in the protocol. This has multiple benefits, but the most relevant one here is that the protocol itself will become aware of MEV bids. After this, actions can be taken in response to these bids broadcasted by builders, such as send the money nowhere – similar to how EIP-1559's base fees are subtracted from account balances with no equivalent balance increase anywhere else, a process colloquially understood as burning ETH. Another, less direct alternative to burn MEV would be to combine two distinct design proposals: first by smoothing it across validators and then adjusting the yield curve so that issuance becomes negative past a certain number of validators. MEV would go to validators, but they would effectively be paying for their spot as a validator via a negative issuance. What's the incentive for builders to extract value that just gets burned?
5/25/2023