Update EIP-7748: fix namings

Merged by EIP-Bot.

EIPS/eip-7748.md

@@ -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:
     """
     The account next conversion step continues migrating the account 
     code (if any) and basic data. After processing, the account must 
@@ -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.
@@ -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
@@ -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)
@@ -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.