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-7748: fix namings #8780

Merged
merged 5 commits into from
Aug 19, 2024
Merged
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
23 changes: 11 additions & 12 deletions EIPS/eip-7748.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,12 +64,12 @@ class StoragePhase:
The account next conversion step continues converting the
storage-slot with key greater or equal next_key.
If there isn't such storage-slot, the account must move to
BasicDataPhase.
AccountDataPhase.
"""
next_key: Bytes

@dataclass
class BasicDataPhase:
class AccountDataPhase:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With @gabrocheleau, we decided to rename it AccountDataPhase since BasicDataPhase is a bit off, considering that in VKT, it usually leaves out the code-hash (which, in case of the migration, is also moved).

We'd like at least one extra approval for this renaming (or new suggestion!) from another author.

cc @gballet @g11tech @tanishqjasoria

(Note: avoiding switching from Draft to avoid automerge)

"""
The account next conversion step continues migrating the account
code (if any) and basic data. After processing, the account must
Expand All @@ -84,7 +84,7 @@ class CurrentConvertingAccount:
Contains the state conversion next step.
"""
address: Address
phase : StoragePhase | BasicDataPhase
phase : StoragePhase | AccountDataPhase
```

These new structures allows `State` to track where we're in the conversion process.
Expand Down Expand Up @@ -191,13 +191,12 @@ def state_convert(state: State, stride: int):
# There're more storage-slots to be converted, continue in this phase.
state.conversion_curr_account.phase.next_key = next_key
else:
# No more storage-slots. Move to the code migration starting
# at chunk-number zero.
state.conversion_curr_account.phase = CodePhase(0)
# No more storage-slots. Move to the account data migration.
state.conversion_curr_account.phase = AccountDataPhase()
else:
# There's no storage trie for the account, move directly to
# migrating code (if any).
state.conversion_curr_account.phase = CodePhase(0)
state.conversion_curr_account.phase = AccountDataPhase()
# Account code and basic data.
else:
# Getting the code from the Overlay Tree is fine since promises returning
Expand All @@ -209,10 +208,10 @@ def state_convert(state: State, stride: int):
state_set_codechunk(state, address, chunk_num, chunked_code[chunk_num])
n += 1

# If the account basic data lives in MPT, get_account will pull from MPT
# and then we write to the VKT. If the account basic data already lives in
# the VKT (i.e: it was indirectly converted by a tx), then it will return
# it from the VKT and write it again (i.e: it's a noop).
# If the account data (i.e: nonce, balance, code-size, code-hash) lives in MPT,
# get_account will pull from MPT and then we write to the VKT. If the account
# data already lives in the VKT (i.e: it was indirectly converted by a tx), then
# it will return it from the VKT and write it again (i.e: it's a noop).
# Thus, this operation is correct under both scenarios. That is, it won't
# write stale data.
account = get_account(state, curr_account.address)
Expand Down Expand Up @@ -253,7 +252,7 @@ TODO: We have an estimation, but it might be worth recalculating it closer to th

The conversion logic runs at the start of each block, so missed slots don't create special situations.

### Accounts storage->code->basic-data order
### Accounts storage->account-data order

The proposed order synergizes with many EL client flat-db architectures, minimizing random disk-IO.

Expand Down
Loading