Automatically merged updates to draft EIP(s) 1702 (ethereum#2141)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-1702.md

@@ -48,6 +48,11 @@ items: `nonce`, `balance`, `storageRoot`, `codeHash`, and
 items. When `version` is not zero, the account is RLP-encoded with 5
 items.
 
+Account versions can also optionally define additional account state
+RLP fields, whose meaning are specified through its `version`
+field. In those cases, the parsing strategy is defined in "Additional
+Fields in Account State RLP" section.
+
 ### Contract Execution
 
 When fetching an account code from state, we always fetch the
@@ -98,6 +103,23 @@ Precompiled contracts and externally-owned addresses do not have
 `STATICCALL` / `DELEGATECALL` touches a new externally-owned address
 or a non-existing precompiled contract address, it is always created
 with `version` field being `0`.
+
+### Additional Fields in Account State RLP
+
+In the future we may need to associate more information into an
+account, and we already have some EIPs that define new additional
+fields in the account state RLP. In this section, we define the
+parsing strategy when additional fields are added.
+
+* Check the RLP list length, if it is 4, then set account version to
+ `0`, and do not parse any additional fields.
+* If the RLP list length more than 4, set the account version to the
+ integer at position `4` (counting from `0`).
+ * Check version specification for the number of additional fields
+ defined `N`, if the RLP list length is not equal to `5 + N`,
+ return parse error.
+ * Parse RLP position `5` to `4 + N` as the meaning specified in
+ additional fields.
 
 ## Extensions
 
@@ -137,6 +159,17 @@ for example, EVM and eWASM. For each of them, we define:
 * **Features**: all additional features that are enabled upon this
  version.
 
+If a meta EIP includes EIPs that provide additional account state RLP
+fields, we also define:
+
+* **Account fields**: all account fields up to the end of this meta
+ EIP, excluding the basic 5 fields (`nonce`, `balance`,
+ `storageRoot`, `codeHash` and `version`). If EIPs included that are
+ specific to modifying account fields do not modify VM execution
+ logic, it is recommended that we specify an additional version whose
+ execution logic is the same as previous version, but only the
+ account fields are changed.
+
 ## Rationale
 
 This introduces account versioning via a new RLP item in account