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

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

@@ -43,8 +43,12 @@ might still be a good idea.
 
 Re-define account state stored in the world state trie to have 5
 items: `nonce`, `balance`, `storageRoot`, `codeHash`, and
-`version`. The newly added field `version` is a 256-bit integer. When
-`version` is zero, the account is RLP-encoded with the first 4
+`version`. The newly added field `version` is a 256-bit **scalar**. We
+use the definition of "scalar" from Yellow Paper. Note that this is
+the same type as `nonce` and `balance`, and it is equivalent to a RLP
+variable-sized byte array with no leading zero, of maximum length 32.
+
+When `version` is zero, the account is RLP-encoded with the first 4
 items. When `version` is not zero, the account is RLP-encoded with 5
 items.
 
@@ -114,7 +118,7 @@ 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`).
+  scalar 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.
@@ -148,7 +152,7 @@ Account versioning is usually applied directly to a hard fork meta
 EIP. EIPs in the hard fork are grouped by the virtual machine type,
 for example, EVM and eWASM. For each of them, we define:
 
-* **Version**: a non-zero integer less than `2^256` that uniquely
+* **Version**: a non-zero scalar less than `2^256` that uniquely
   identifies this version. Note that it does not need to be
   sequential.
 * **Parent version**: the base that all new features derived