Integrate review feedback

EIPS/eip-overlay_tree.md → EIPS/eip-2584.md

@@ -19,16 +19,17 @@ This EIP describes a four phase process to complete the conversion.
 
   * In the first phase, all new state writes are made to an overlay binary trie, while the hexary trie is being converted to binary. The block format is changed to have two storage roots: the root of the hexary trie and the root of the binary trie.
   * The second phase starts when miners are done with the conversion and replace the hexary root with the newly calculated root.
-  * The third phase begins when a sufficient number of consecutive blocks report the same value for `binary_trie_root`: the overlay tree is progressively merged back into the newly converted binary base trie. A constant number of entries are deleted from the overlay and inserted into the base trie.
+  * The third phase begins when a sufficient number of consecutive blocks report the same binary trie root value: the overlay tree is progressively merged back into the newly converted binary base trie. A constant number of entries are deleted from the overlay and inserted into the base trie.
   * The fourth and final phase begins when the overlay trie is empty. The field holding its root is removed from the block header.
 
 ## Motivation
 
 There is a long running interest in switching the state trie from a hexary format to a binary format, for reasons pertaining to proof and storage sizes. The conversion process poses a catch-up issue, caused by the sheer size of the full state: it can not be translated in a reasonable time (i.e. on the same order of magnitude as the block time). 
 
 ## Specification
-The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).
+
 This specification follows the notation introduced by the [Yellow Paper](https://ethereum.github.io/yellowpaper). Prior to reading it is advisable to be familiar with the Yellow Paper.
+
 ### Binary tries
 
 This EIP assumes that a binary trie is defined like the MPT, except that:
@@ -40,41 +41,32 @@ This EIP assumes that a binary trie is defined like the MPT, except that:
 
 ### Phase 1
 
-Let _H₁_ be the previously agreed-upon block height at which phase 1 starts. For each block of height H₁ ≤ _h_ < H₂:
+Let _h₁_ be the previously agreed-upon block height at which phase 1 starts, and _h₂_ the block at which phase 2 starts. For each block of height h₁ ≤ _h_ < h₂:
 
-  * Block headers contain a new Hₒ field, which is the _root of the overlay binary trie_;
-  * Hᵣ ≡ P(H)ᵣ, i.e. the hexary trie root is the same as that of the block parent's. The hexary trie is referred to as the _hexary base trie_.
+  0. A conversion process is started in the background, to turn the hexary trie into its binary equivalent. The end goal of this process is the calculation of the _root hash of the converted binary trie_, denoted Hᵣ². The root of the hexary trie is hereafter called Hᵣ¹⁶.
+  1. Block headers contain a new Hₒ field, which is the _root of the overlay binary trie_;
+  2. Hᵣ² = ∅ ⇒ Hᵣ ≡ P(H)ᵣ¹⁶, i.e. as long as the conversion from hexary to binary is not complete, the hexary trie root is the same as that of the block parent's. The hexary trie is referred to as the _hexary base trie_;
+  3. Hᵣ² ≠ ∅ ⇒ Hᵣ ≡ Hᵣ², i.e. once a client has has calculated Hᵣ², it signals his vote for its converted value by setting its value for Hᵣ² as the Hᵣ value of each block that it seals. The converted binary trie is referred to as the _binary base trie_.
 
 The following is changed in the execution environment:
 
-  * Upon executing a _state read_, ϒ first searches for the address in the overlay trie. If the key can not be found there, ϒ then searches the hexary base trie as it did at block heights h' < H₁;
+  * Upon executing a _state read_, ϒ first searches for the address in the overlay trie. If the key can not be found there, ϒ then searches the base trie as it did at block heights h' < h₁;
   * Upon executing a _state write_, ϒ will insert or update the value into the overlay tree.
 
-A conversion process occurs in the background to turn the hexary trie into its binary equivalent. The end goal of this process is the calculation of the _root hash of the converted binary base trie_, denoted Hᵣ². The root of the hexary base trie is hereafter called Hᵣⁱ⁶.
-
-When a miner has calculated Hᵣ², it proceeds to phase 2.
+Phase 1 ends when a sufficient number of subsequent blocks have reported the same value for Hᵣ². 
 
 ### Phase 2
 
-Phase 2 is the same as phase 1, except for the following:
-
-  * Hᵣ' ≡ Hᵣ²
-
-
-Phase 2 ends when a sufficient number of subsequent blocks have reported the same value for Hᵣ².
-
-### Phase 3
-
-The following changes occur in phase 3:
+The following changes occur in phase 2:
 
   * N accounts are being deleted from the binary overlay trie and inserted into the binary base trie.
-  * Upon executing a _state write_, ϒ will insert or update the value into the _base_ tree. If the search key exists in the overlay tree, it is deleted.
+  * Upon executing a _state write_, ϒ will insert or update the value into the _base_ trie. If the search key exists in the overlay trie, it is deleted.
 
-When the overlay trie is empty, phase 3 ends and phase 4 begins.
+When the overlay trie is empty, phase 2 ends and phase 3 begins.
 
-### Phase 4
+### Phase 2
 
-Phase 4 is the same as phase 3, except for the following changes:
+Phase 3 is the same as phase 2, except for the following change:
 
   * Hₒ is dropped from the block header