-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Account abstraction EIP #2938
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
EIPS/eip-2938.md
Outdated
|
||
## Motivation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
**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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be "Starting with FORK_BLOCK
" I guess?
EIPS/eip-2938.md
Outdated
|
||
### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed one required change in my previous review.
EIPS/eip-2938.md
Outdated
|
||
#### `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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
EIPS/eip-2938.md
Outdated
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
EIPS/eip-2938.md
Outdated
|
||
#### `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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious: why a version and what future versions are envisioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- EIP 1559
- Escalator
- Block hash and block number dependencies
Co-authored-by: Micah Zoltu <micah@zoltu.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.