Update EIP-8141: add support for guarantors#11555
Update EIP-8141: add support for guarantors#11555derekchiang wants to merge 4 commits intoethereum:masterfrom
Conversation
github-actions
Bot
added
c-update
|
✅ All reviewers have approved. |
github-actions
Bot
added
w-ci
| return keccak(rlp(tx_copy)) | ||
| ``` | ||
|
|
||
| A frame signature hash elides only the data of that frame, identified by index: |
There was a problem hiding this comment.
If we don't elide the data in VERIFY frames, doesn't this mean we will struggle to aggregate and elide the frames themselves in the future?
There was a problem hiding this comment.
This is a good point -- maybe one solution is that blocker builder (who aggregates) can include the frame signature hashes (for each frame who accesses the hash via TXPARAM) in the block. After all, we are still not letting frames access signatures directly; we are just letting them access frame hashes that hash over signatures.
| if (_frameMode(nextFrame) != MODE_DEFAULT) revert InvalidBumpNonceFrame(); | ||
| if (_frameGasLimit(nextFrame) < MIN_BUMP_NONCE_GAS) revert InvalidBumpNonceFrame(); | ||
| if (_frameDataLen(nextFrame) != BUMP_NONCE_DATA_LEN) revert InvalidBumpNonceFrame(); | ||
|
|
There was a problem hiding this comment.
Should we have something along the lines of:
uint256 bumpFlags = _frameFlags(nextFrame);
if (bumpFlags & ATOMIC_BATCH_FLAG != 0) revert InvalidBumpNonceFrameBatch();
to make sure the nonce bump cannot be tied with a different frame?
Upd: I see now that nonce bump is a DEFAULT frame - but still, in case we ever need to add flags we don't know about yet?
|
The commit 2edb6b5 (as a parent of b40bb00) contains errors. |
4 participants
We are still iterating on this idea but wanted to share it for early feedback.
The idea is to introduce the concept of a "guarantor," which is a payer that pays for the transaction even if sender validation fails. As long as a transaction has a guarantor, mempool nodes do not need to check if the sender validation succeeds, and can skip simulation for sender validation altogether.
As a result, transactions with a guarantor can use any sender validation logic, including access to shared state, environmental opcodes, etc., and still safely pass through the public mempool.
In practice, we expect guarantors to be either other accounts that the user owns, or third-parties who are willing to take on the risks of guaranteeing transactions for the user because 1) they have some sort of commercial or trust relationship with the user, or 2) they have some out-of-protocol knowledge that assures them that the transactions will not revert.