Automatically merged updates to draft EIP(s) 1702

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

@@ -9,6 +9,11 @@ category: Core
 created: 2017-12-30
 ---
 
+## Simple Summary
+
+Introduce account versioning for smart contracts so upgrading the VM
+or introducing new VMs can be easier.
+
 ## Abstract
 
 This defines a method of hard forking while maintaining the exact
@@ -125,6 +130,42 @@ Precompiled contracts and externally-owned addresses do not have
 or a non-existing precompiled contract address, it is always created
 with `version` field being `0`.
 
+## Rationale
+
+This introduces account versioning via a new RLP item in account
+state. The first design above gets account versioning by making the
+contract *family* always have the same version. In this way, versions
+are only needed to be provided by contract creation transaction, and
+there is no restrictions on formats of code for any version. If we
+want to support multiple newest VMs (for example, EVM and WebAssembly
+running together), then this requires alternative design in contract
+creation transaction section
+
+The second design above requires new versions of VMs follow a
+formatting -- that it always has a prefix. In this way, the version
+can be derived from the prefix, thus allowing a contract *family* to
+have multiple versions. It also makes it so that we can pin contract
+creation transaction using only one VM version, and it can deploy
+other VM versions.
+
+Alternatively, account versioning can also be done through:
+
+* **EIP-1707** and **EIP-1712**: This makes an account's versioning
+  soly dependent on its code header prefix. If with only EIP-1707, it
+  is not possible to certify any code is valid, because current VM
+  allows treating code as data. This can be fixed by EIP-1712, but the
+  drawback is that it's potentially backward incompatible.
+* **EIP-1891**: Instead of writing version field into account RLP
+  state, we write it in a separate contract. This can accomplish the
+  same thing as this EIP and potentially reduces code complexity, but
+  the drawback is that every code execution will require an additional
+  trie traversal, which impacts performance.
+
+## Backwards Compatibility
+
+Account versioning is fully backwards compatible, and it does not
+change how current contracts are executed.
+
 ## Discussions
 
 ### Performance
@@ -141,3 +182,7 @@ This scheme can also be helpful when we deploy on-chain WebAssembly
 virtual machine. In that case, WASM contracts and EVM contracts can
 co-exist and the execution boundary and interaction model are clearly
 defined as above.
+
+## Test Cases and Implementations
+
+To be added.