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-7612: сorrect variable name in get_account_optional function #9215

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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
Loading