Account abstraction EIP#2938
Conversation
Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.
Co-authored-by: Micah Zoltu <micah@zoltu.net>
MicahZoltu
left a comment
There was a problem hiding this comment.
Only the Abstract inclusion suggestion and the Specification section naming suggestion are required for merging as a draft. The rest is just generalized feedback that you can ignore until Last Call.
|
|
||
| ## Motivation |
There was a problem hiding this comment.
| ## Motivation | |
| ## Abstract | |
| TBD | |
| ## Motivation |
I believe the Abstract is a required section. For draft, it just needs to be present, not complete. I generally recommend it include ea human readable and very terse version of the specification (maybe a paragraph or two).
|
|
||
| ## Motivation | ||
|
|
||
| **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.** |
There was a problem hiding this comment.
| **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.** |
This is already in the header, so putting it here is redundant. Recommend removing.
|
|
||
| ## Security Considerations | ||
|
|
||
| See https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937 for an analysis of DoS issues. |
There was a problem hiding this comment.
At some point before final security considerations should be inlined into this document, but that isn't necessary for draft status.
| All AA contracts may also potentially not have replay protection, unless they build it in explicitly; this can be done with the `CHAINID (0x46)` opcode introduced in [EIP 1344](./eip-1344.md). | ||
|
|
||
| ## Test Cases | ||
| See: https://github.com/quilt/tests/tree/account-abstraction |
There was a problem hiding this comment.
Ideally, test cases will be inlined into this document, or added as an asset to ../assets/eip-2938/whatever.wat, but that isn't necessary for draft status.
There was a problem hiding this comment.
.wat, are you suggesting the introduction of WebAssembly? 🙊
|
|
||
| ## Specification (Single-tenant AA) | ||
|
|
||
| After `FORK_BLOCK`, the following changes will be recognized by the protocol. |
There was a problem hiding this comment.
This would be "Starting with FORK_BLOCK" I guess?
|
|
||
| ### New Transaction Type | ||
|
|
||
| A new EIP-2718 transaction with type `AA_TX_TYPE` is introduced. Transactions of this type are referred to as "AA transactions". Their payload should be interpreted as `rlp([nonce, target, data])`. |
There was a problem hiding this comment.
Can the "EIP-2718" mention be supplemented by the EIP title (in brackets) here for readability?
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing
MicahZoltu
left a comment
There was a problem hiding this comment.
Missed one required change in my previous review.
|
|
||
| #### `NONCE (0xAB)` Opcode | ||
|
|
||
| A new opcode `NONCE (0xAB)` is introduced, with gas cost `G_base`, which pushes the `tx.nonce` onto the stack. |
There was a problem hiding this comment.
Suggestion:
| A new opcode `NONCE (0xAB)` is introduced, with gas cost `G_base`, which pushes the `tx.nonce` onto the stack. | |
| A new opcode `NONCE (0xAB)` is introduced, with gas cost `G_base`, which pushes the `account.nonce` onto the stack. |
If tx.nonce would be used, I would suggest to name this TXNONCE. Luckily however tx.nonce == account.nonce, so changing the description is enough.
|
|
||
| A new opcode `NONCE (0xAB)` is introduced, with gas cost `G_base`, which pushes the `tx.nonce` onto the stack. | ||
|
|
||
| #### `PAYGAS (0xAA)` Opcode |
There was a problem hiding this comment.
While I see it is clever to use 0xAA and 0xAB as opcodes, I think if this is adopted these opcodes should fit into appropriate sections: which is likely 0x48 and 0x49.
As a draft the current proposed ones are fine, perhaps I should leave this comment on the discussion url.
|
|
||
| #### `PAYGAS (0xAA)` Opcode | ||
|
|
||
| A new opcode `PAYGAS (0xAA)` is introduced, with gas cost `G_base`. It takes two arguments off the stack: (top) `version_number`, (second from top) `memory_start`. In the initial implementation, it will `assert version_number == 0` and read: |
There was a problem hiding this comment.
Curious: why a version and what future versions are envisioned?
There was a problem hiding this comment.
- EIP 1559
- Escalator
- Block hash and block number dependencies
Co-authored-by: Micah Zoltu <micah@zoltu.net>
MicahZoltu
left a comment
There was a problem hiding this comment.
I recommend reviewing the feedback that has been left, but that can be applied after merging as draft.
Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.
Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.
Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.