Skip to content

Commit

Permalink
Update eip-7612.md
Browse files Browse the repository at this point in the history
  • Loading branch information
DeVikingMark authored Jan 6, 2025
1 parent d96625a commit ad7528b
Showing 1 changed file with 11 additions and 7 deletions.
18 changes: 11 additions & 7 deletions EIPS/eip-7612.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,7 @@ And the state access functions are modified as such:

```python3
def get_account_optional(state: State, address: Address) -> Optional[Account]:
account = verkle_get_account(state._overlay_tree, get_tree_key_for_version(addr))
account = verkle_get_account(state._overlay_tree, get_tree_key_for_version(address))
if account is not None:
return account

Expand Down Expand Up @@ -170,15 +170,19 @@ No backward compatibility issues found.

## Security Considerations

<!--
All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
The overlay tree approach introduces several security considerations that need to be carefully addressed:

The current placeholder is acceptable for a draft.
1. Data Availability: During the transition period, nodes need to maintain both MPT and VKT structures. This ensures that historical state can still be accessed while new state changes are recorded in the VKT overlay.

TODO: Remove this comment before submitting
-->
2. State Root Integrity: The switch from MPT root to VKT root in block headers at `FORK_TIME` must be handled carefully to maintain chain integrity. All clients must implement the exact same transition logic to avoid consensus failures.

3. Read Path Security: The implementation must ensure that the read path (checking overlay tree first, then falling back to MPT) is atomic and cannot be interrupted between reads, which could lead to inconsistent state views.

4. Storage Space Considerations: While internal MPT nodes can be deleted after finalization of the fork block, implementations must ensure this deletion process cannot corrupt the remaining leaf data needed for historical state access.

5. Reorg Handling: During chain reorganizations crossing the `FORK_TIME` boundary, implementations must correctly handle the transition between MPT and VKT root usage in block headers.

Needs discussion.
These considerations require careful testing and implementation by client teams to ensure a secure transition.

## Copyright

Expand Down

0 comments on commit ad7528b

Please sign in to comment.