Skip to content

Commit

Permalink
Minor changes
Browse files Browse the repository at this point in the history
  • Loading branch information
@lucassaldanha
lucassaldanha committed Nov 27, 2024
1 parent 92fe955 commit af6d06a
Showing 1 changed file with 5 additions and 11 deletions.
16 changes: 5 additions & 11 deletions EIPS/eip-7804.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,8 @@ The introduction of execution requests that are created on the execution layer,
opened up possibilities on how validators can be managed.
Execution request can be created via smart contracts, allowing for decentralized
and on-chain mechanisms to be explored.
This also means validators will be able to move between execution and compounding
withdrawal credentials (follwoing the correct churn on the total staked amount).

For an execution request to be authorized in the consensus layer, the withdrawal
credential of the validator must be the same of the `msg.caller` when processing
Expand All @@ -45,7 +47,8 @@ creating the request (not the credential of the transaction sender), or the cont
needs to use `DELEGATECALL` to ensure the caller address matches the address in the
validator's withdrawal credential.
Validators that already have a contract address as their withdrawal credentials should
be able to update their contracts to meet this demand.
be able to update their contracts to meet this demand (assuming they have an
updatable contract).

There problems for existing validators that have their withdrawal credentials
set to an EOA account is they will never be able to use use smart contracts
Expand All @@ -58,15 +61,6 @@ experimentation and innovation.
Today, the only alternative to this is exitting the validator and creating a new
validator with different withdrawal credentials.

Being able to update their withdrawal credentials also means they could move between
execution and compounding withdrawal credentials. This is not only benefitial due to
the flexibility it provides, but also solves problem that upon a validator consolidation
[EIP-7251](./eip-7251.md), the target validator withdrawal
credential is updated to 0x02, with no way to ever going back to 0x01. But because the
authentication of the message is only concerned with the source validator, a validator
can be forced to change to 0x02. If we implement the mechanism for them to change it
back 0x01, we solve this problem as well.

## Specification

### Constants
Expand Down Expand Up @@ -122,7 +116,7 @@ The contract has three different code paths, which can be summarized at a high l
2. Excess requests getter - if the input length is zero, return the current excess requests count.
3. System process - if called by system address, pop off the withdrawal credential update requests for the current block from the queue.

<!-- TODO add sudo code / bytecode / deployment / etc_ (very similar to existing request contracts) -->
<!-- TODO add sudo code / bytecode / deployment / etc (very similar to existing request contracts) -->

Check warning on line 119 in EIPS/eip-7804.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn` 

warning[markdown-html-comments]: HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`
   --> EIPS/eip-7804.md
    |
119 | <!-- TODO add sudo code / bytecode / deployment / etc (very similar to existing request contracts) -->
    |
   ::: EIPS/eip-7804.md
    |
132 | <!-- TODO complete the specification -->
    |
   ::: EIPS/eip-7804.md
    |
195 | <!-- TODO -->
    |
   ::: EIPS/eip-7804.md
    |
199 | <!-- TODO -->
    |
   ::: EIPS/eip-7804.md
    |
203 | <!-- TODO -->
    |
    = help: see https://ethereum.github.io/eipw/markdown-html-comments/

#### Block processing

Expand Down

0 comments on commit af6d06a

Please sign in to comment.