Skip to content
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

Update EIP-7702: Proxy the storage of a delegation to its unique deleterminstic keys #8762

Closed
wants to merge 14 commits into from
6 changes: 6 additions & 0 deletions EIPS/eip-7702.md
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,12 @@

An alternative to adding chain ID could be to sign over the code the address points to. This seems to have the benefit of both minimizing the on-chain size of auth tuples while retaining specificity of the actual code running in the account. One unfortunate issue of this format though is that it imposes a database lookup to determine the signer of each auth tuple. This imposition itself seems to create enough complexity in transaction propagation that it is decided to avoid and simply sign over address directly.

#### Delegation Storage

Considering that the delegation from one contract to another contract can cause conflict and corruption of the storage with broken contract in the least and a compromized contract at the worst, it is prudent to separate the storage of each delegation in deterministic way.
g11tech marked this conversation as resolved.
Show resolved Hide resolved

To this effect, the delegated EOA's storage should be proixed and accessed/written at `keccak256(authority||address)[0:20]`. This way, if the contract is delegated back to a previous `address`, EVM will be able to _re-attach_ its old storage.
g11tech marked this conversation as resolved.
Show resolved Hide resolved

#### In-protocol revocation

Unlike previous versions of this EIP and EIPs similar, the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce. Without such action, a delegation will remain valid in perpetuity.
g11tech marked this conversation as resolved.
Show resolved Hide resolved
Expand Down Expand Up @@ -166,14 +172,14 @@

### Secure delegation

The following is a non-exhaustive list of checks/pitfalls/conditions that delegate contracts *should* be wary of and require a signature over from the account's authority:

Check failure on line 175 in EIPS/eip-7702.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Emphasis style should be consistent [Expected: underscore; Actual: asterisk]

EIPS/eip-7702.md:175:94 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk]

* Replay protection -- (ex. a nonce) should be implemented by the delegate and signed over. Without it, a malicious actor can reuse a signature, repeating its effects.
* `value` -- without it, a malicious sponsor could cause unexpected effects in the callee.
* `gas` -- without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee.
* `target` / `calldata` -- without them, a malicious actor may call arbitrary functions in arbitrary contracts.

A poorly implemented delegate can *allow a malicious actor to take near complete control over a signer's EOA*.

Check failure on line 182 in EIPS/eip-7702.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Emphasis style should be consistent [Expected: underscore; Actual: asterisk]

EIPS/eip-7702.md:182:35 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk]

### Setting code as `tx.origin`

Expand Down
Loading