EIP-7044, addresses a significant limitation in the existing Ethereum network related to the validity period of signed voluntary exits. Currently, these exits are only valid for the next two network upgrades, which imposes complex challenges, particularly in scenarios where staking operators differ from fund owners.
This proposal seeks to motivate the adoption of "perpetual validity" for signed voluntary exits on the Capella blockchain, ensuring that they remain valid indefinitely, regardless of any future upgrades.
The primary objectives of this proposal are to simplify the design of staking operations and enhance the user experience.
What is a Voluntary Exit?
A voluntary exit, refers to the act of a validator in the Capella blockchain voluntarily choosing to leave the validation network. The uniqueness of this proposal lies in making these voluntary exits valid indefinitely.
Image-Voluntary Exit
EIP-7044 aims to improve staking operations on Ethereum by allowing validators to voluntarily exit the chain, with minimal protocol changes and two different types of credentials.
There are two sets of credentials in Ethereum staking: evaluated credentials for signing blocks and withdrawals Credentials for controlling funds, with the latter being more secure and often held by different entities, allowing for delegation of validating credentials.
Image - (Withdrawal Entities: Enabling the Recalling of Funds with Precision)
The ideal situation is for the withdrawal credential to have control of the funds and the authority to claim them back, and currently, it is not easy to do this.
EIP-7044 allows for voluntary exits to be triggered from the exhibition layer and withdrawal credentials, addressing complications and providing a solution for Legacy BLS credentials.
Image - (Voluntary Exit : Epoch specified message, validator can be withdrawn)
Why are Signed Voluntary Exits not perpetually valid today?
Voluntary exits are not perpetually valid today due to the current limitations of the Beacon Chain's state management. At present, the validity of signed voluntary exits extends only to the next two network upgrades. This constraint is in place because the Beacon Chain state takes into account only the current and previous fork versions.
This limitation poses a challenge, particularly in staking operations where the staking operator (the entity holding the active key) is distinct from the owner of the funds (the entity holding the withdrawal credential). Because voluntary exits can only be signed by the active key, it necessitates the exchange of signed exits ahead of time to accommodate the potential for an unbounded number of future forks or upgrades. To maintain their ability to exit securely, they must pre-sign exits for each forthcoming fork.
Complexity in Staking Operations
In the context of the Capella blockchain and its handling of voluntary exits, a notable limitation arises in the complexity of staking operations, particularly for scenarios where staking operators (the entities responsible for validating transactions and maintaining the network) are distinct from the owners of the staked funds (those who have deposited cryptocurrency for staking purposes).
The primary challenge stems from the fact that, currently, voluntary exits can only be signed by the active key, which is typically held by the staking operator. However, the actual ownership of the staked funds may belong to a different entity, and this creates a need for a complex coordination mechanism.
Here are the key points that contribute to this complexity:
Two-Party Involvement:
Staking often involves two distinct parties - the staking operator and the fund owner. The staking operator is responsible for validating transactions and actively participating in the network's consensus mechanism, while the fund owner may be more passive, providing the financial resources.
Active Key Requirement:
Voluntary exits, which allow validators to withdraw from the staking pool, can only be signed using the active key. This means that the staking operator, who possesses the active key, is in control of initiating exits.
Need for Pre-Signed Exits:
To accommodate the distinct roles of staking operators and fund owners, there arises a requirement for pre-signed exits. The fund owner needs to pre-arrange with the staking operator to have voluntary exits pre-signed on their behalf, covering an indefinite number of future forks.
Unbounded Pre-Signing:
The need for pre-signing voluntary exits creates an unbounded and potentially cumbersome process. Since the Capella network only considers the current and previous fork version for the validity of signed exits, these pre-signed exits must cover an unspecified number of forks in the future.
Operational Overhead:
Coordinating, maintaining, and verifying these pre-signed exits for various forks introduces operational overhead, adding complexity to the staking process.
In essence, the complexity arises from the necessity of ensuring that the active key holder (staking operator) and the fund owner can work together effectively and maintain a streamlined staking operation. This involves extensive planning, coordination, and potentially frequent updates to accommodate changes in the network's forks, making it a non-trivial task for those involved in staking on the Capella blockchain.
Technical Changes
Consensus Layer Modifications:
The proposed changes are integrated into the Consensus Specs Deneb upgrade.
A specific alteration is made to the state transition function, "process_voluntary_exit."
This function is modified to compute the signing domain and root based on CAPELLA_FORK_VERSION.
This means that when a voluntary exit is processed, it will be tied to the specific Capella fork version, ensuring that the exit is recognized and valid according to the rules of that fork.
The change to "process_voluntary_exit" ensures that the signing domain is locked to the Capella fork. This change enhances backward compatibility with the Capella fork, allowing exits to be recognized as valid, even in subsequent upgrades or forks.
Additionally, the voluntary_exit gossip conditions are implicitly modified to support this change. This adjustment ensures that the network's communication mechanisms align with the perpetual validity of voluntary exits based on the fork version.
Execution Layer:
Unlike the Consensus Layer, this proposal does not require any modifications to the Execution Layer.
This means that the execution of transactions and smart contracts remains unaffected by this change. Existing execution layer processes do not need to be altered to accommodate the perpetual validity of signed voluntary exits.
Backwards Compatibility
Implications for EIP-7044:
To ensure backwards compatibility, the proposal includes modifications to the Consensus Layer to lock the signature domain on the Capella fork. This modification allows the existing voluntary exits to continue to function as expected.
Existing tools, applications, and processes that use voluntary exits signed under the Deneb fork domain would no longer be valid under the proposed changes.
Consideration for Existing Pre-Signed Exits:
Users who have previously pre-signed voluntary exits using the Deneb fork domain with an expectation of their validity should be aware that these pre-signed exits will no longer be recognized as valid once EIP-7044 is implemented.
This change does not affect the security of funds, but it requires users to adapt to the new Capella fork domain for continued validity across forks.
Balancing Innovation and Compatibility:
Backwards compatibility is essential in blockchain networks like Ethereum to ensure that network upgrades do not disrupt the existing ecosystem. This allows users, developers, and applications to transition to new features or changes gradually.
It is a delicate balance between introducing innovation and ensuring that the network remains usable for those who rely on it. EIP-7044 aims to improve the user experience without causing undue disruption to existing processes.
Test Cases and Implementation
Test cases are crucial to ensure that the proposed change functions correctly and does not introduce vulnerabilities. EIP-7044 mentions that test cases are a work in progress within the standard Consensus Layer tests. It's important to note that these test cases need to cover various scenarios to verify the correctness and reliability of the proposed change. Some of the test cases that might be considered include:
Positive Test Cases:
These test cases would validate that voluntary exits signed using the Capella fork domain continue to be valid across multiple forks as intended.
Negative Test Cases:
These would verify that exits signed using the Deneb fork domain are no longer recognized as valid, as mentioned in the proposal.
Fork Scenarios:
Testing how the proposed change behaves in scenarios involving multiple hard forks, ensuring that voluntary exits remain valid after each fork.
Edge Cases:
These would test unusual or boundary conditions to ensure the system behaves as expected in all situations.
Replay Protection:
Test cases that consider the absence of replay protection, examining the impact on individual stakers and the overall network.
Security Implications:
EIP-7044 introduces changes to the validity and replay protection of signed voluntary exits. Here are the security implications to consider:
Replay Vulnerability:
The proposal eliminates replay protection for pre-signed exits. This means that exits signed for one fork may be replayed on another fork. While this doesn't put funds at risk, it can affect individual stakers, especially if they are operating on both forks. The absence of replay protection may require users to be more cautious with their voluntary exits.
Awareness:
Existing users who have pre-signed exits should be aware of the change. Pre-signed exits that were expected to be valid in the Deneb fork domain will no longer work. Users are advised to update their approach and ensure their exits are signed using the Capella fork domain to maintain continued validity.
Replay Protection Removal:
The primary security concern with EIP-7044 is the removal of replay protection for pre-signed voluntary exits after two hard forks. Previously, the use of divergent signature domains across forked networks prevented replay attacks. With this proposal, the replay protection no longer exists.
Implication:
Potential replay attacks could occur if users attempt to use pre-signed exits on both sides of a fork. However, it's important to note that these replays do not put the funds at risk and do not impact the overall security of the blockchain. It's more of a user experience concern than a security risk.
Consensus Layer Impact:
The proposed changes are limited to the Consensus Layer of the blockchain. This means that the impact is primarily on how the blockchain reaches consensus, and it may not affect the security of the Execution Layer (smart contracts and transactions).
Implication:
While the security of the Consensus Layer is essential, the changes proposed in EIP-7044 mainly relate to consensus mechanics. Ensuring the continued security of the Execution Layer remains crucial, but the proposal doesn't introduce specific security risks in this regard.
Compatibility and Communication:
The security implications also touch upon the need for clear communication and coordination within the community. Users and developers should be aware of the changes and the implications for pre-signed exits. Proper communication and education are essential to prevent misunderstandings.
Implication:
Maintaining transparent and effective communication about the changes is vital to ensure that users and developers understand how to adapt to the new rules and maintain the security of their staking operations.
EIP-7044, offers a substantial improvement to the Ethereum network's user experience and staking operations. By extending the perpetual validity of signed voluntary exits, this proposal simplifies staking operation designs and aligns the user experience with existing features, eliminating the need for tooling updates based on fork versions. While introducing this enhancement, the proposal also maintains backward compatibility with the Consensus Layer. Users should be aware of the change's implications on existing pre-signed exits, as they will need to ensure that exits are signed using the Capella fork domain to maintain their validity across forks.
Overall, this proposal strives to enhance the efficiency and convenience of staking activities on the Capella network.
Read More
-
scroll-successfully-launches-mainnet-for-zkevm-boosting-ethereum-scalability
-
Solutions to Scalability: Can Off-Chain Payments Scale Blockchain?
Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.
For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Donate at avarch.eth or Gitcoin
You've something to share with the blockchain community, join us on Discord!
