diff --git a/docs/images/IBFT2_algorithm1.png b/docs/images/IBFT2_algorithm1.png
index 5f1b59a..ef5f22f 100644
Binary files a/docs/images/IBFT2_algorithm1.png and b/docs/images/IBFT2_algorithm1.png differ
diff --git a/docs/images/IBFT2_algorithm2.png b/docs/images/IBFT2_algorithm2.png
index 9e3014a..8f05316 100644
Binary files a/docs/images/IBFT2_algorithm2.png and b/docs/images/IBFT2_algorithm2.png differ
diff --git a/docs/images/IBFT2_algorithm4.png b/docs/images/IBFT2_algorithm4.png
index 8be9ddc..1502107 100644
Binary files a/docs/images/IBFT2_algorithm4.png and b/docs/images/IBFT2_algorithm4.png differ
diff --git a/docs/images/IBFT2_algorithm5.png b/docs/images/IBFT2_algorithm5.png
index a4c7d72..2e5bc9f 100644
Binary files a/docs/images/IBFT2_algorithm5.png and b/docs/images/IBFT2_algorithm5.png differ
diff --git a/docs/images/algorithm1_pseudocode.png b/docs/images/algorithm1_pseudocode.png
index 7ad2926..bff5dd8 100644
Binary files a/docs/images/algorithm1_pseudocode.png and b/docs/images/algorithm1_pseudocode.png differ
diff --git a/docs/images/algorithm2_pseudocode.png b/docs/images/algorithm2_pseudocode.png
index 306d812..dac71ce 100644
Binary files a/docs/images/algorithm2_pseudocode.png and b/docs/images/algorithm2_pseudocode.png differ
diff --git a/docs/spec.html b/docs/spec.html
index d82e053..44d4f9d 100644
--- a/docs/spec.html
+++ b/docs/spec.html
@@ -2,7 +2,7 @@
 <html>
 <head>
 <meta charset='utf-8'>
-<title>IBFT 2.0 Consensus Algorithm Specification v1</title>
+<title>EBFT Consensus Algorithm Specification v1</title>
 
 <script
 src='https://www.w3.org/Tools/respec/respec-w3c-common'
@@ -29,14 +29,14 @@
 
 <section id='abstract'>
 
-This document, the IBFT 2.0 Consensus Algorithm Specification, describes a
+This document, the EBFT Consensus Algorithm Specification, describes a
 <a>Proof of Authority</a> (PoA) <a>Byzantine Fault Tolerant</a> (BFT) blockchain
-consensus protocol.
+consensus protocol suited for eventually synchronous networks.
 
-The Istanbul Byzantine Fault Tolerant (IBFT) 2.0 protocol builds on the IBFT
+The Enterprise Byzantine Fault Tolerant (EBFT) protocol builds on the IBFT
 blockchain consensus protocol ([[IBFT]] and [[Quorum]]), retaining all of its
 original features, plus addresses safety and liveness limitations described in a
-previous work [[IBFT-Analysis]]. 
+previous work [[IBFT-Analysis]].
 
 </section>
 
@@ -45,7 +45,7 @@
 *This section describes the status of this document at the time of its
 publication. Newer documents might supersede this document.*
 
-This is an editors' draft of the IBFT 2.0 Consensus Algorithm Specification v1.
+This is an editors' draft of the EBFT Consensus Algorithm Specification v1.
 
 </section>
 
@@ -53,7 +53,7 @@
 
   <h2>Introduction</h2>
 
-The IBFT 2.0 protocol is a <a>Proof of Authority</a> (PoA)
+The EBFT protocol is a <a>Proof of Authority</a> (PoA)
 <a>Byzantine Fault Tolerant</a> (BFT) blockchain consensus protocol enabling
 consortium networks to leverage on the capabilities of
 <a>Ethereum smart contracts</a>. The protocol:
@@ -62,39 +62,64 @@ <h2>Introduction</h2>
 - Is <a>robust</a> in an <a>eventually synchronous network</a> model.
 - Features a <a>dynamic validator set</a>.
 
-The protocol is based on the IBFT protocol that was developed in early 2017 by
-AMIS Technologies [[IBFT]], which was then fully implemented in Quorum [14] in
-November 2017. The IBFT protocol features all of the properties of the IBFT 2.0
-protocol mentioned above, except for robustness in eventually synchronous
-networks, as identified by Saltini [[IBFT-Analysis]]. The IBFT 2.0 protocol
-addresses this <a>robustness</a> issue of the IBFT protocol, while maintaining
-all of its original properties.
+The EBFT protocol builds on the IBFT protocol
+([[IBFT]] and [[Quorum]]), it inherits all its properties while addressing the following limitations
+described by Saltini [[IBFT-Analysis]]:
+
+  <ul>
+    <li>
+<a>Persistence</a> is not guaranteed:
+    <ul>
+      <li>
+One Byzantine <a>validator</a> is potentially able to remove a transaction or
+change the position of a finalized transaction.
+      </li>
+      <li>
+In a network of six <a>validators</a>, even if all <a>validators</a> are honest,
+a network partitioning can cause the blockchains maintained by two sets of three
+<a>validators</a> each to diverge. After the partitioning is resolved,
+<a>validators</a> have to choose one chain, which means removing or reordering
+transactions of the other chain.
+      </li>
+      <li>
+The IBFT protocol does not guarantee that a transaction added to the local
+blockchain of one <a>validator</a> is eventually added to the local blockchain
+of all other nodes.
+      </li>
+    </ul>
+    </li>
+    <li>
+<a>Liveness</a> is not guaranteed. Specifically, the IBFT protocol might reach a
+state where no new blocks can be added to any local blockchain, which means that
+no new transactions can be added to the distributed ledger.
+    </li>
+  </ul>
 
   </section>
 
   <section id="conformance">
 
   </section>
-  
+
 
   <section id="sec-terminology" class="informative">
 
   <h2>Terminology</h2>
 
-This section outlines the terminology used to describe the IBFT 2.0
+This section outlines the terminology used to describe the EBFT
 protocol.
 
   <dl>
     <dt><dfn data-lt="validator">Validators</dfn></dt>
 	<dd>
-Multiple nodes participating in the IBFT 2.0 protocol to finalize blocks on
+Multiple nodes participating in the EBFT protocol to finalize blocks on
 the chain.
     </dd>
 
     <dt><dfn data-lt="proposers">Proposer</dfn></dt>
 	<dd>
 A <a>validator</a> that proposes a block. Only one node acts as a proposer for
-any given <a>round</a>.
+any given <a>round</a> and <a>height</a>.
     </dd>
 
     <dt><dfn data-lt="standard nodes|node|nodes">Standard node</dfn></dt>
@@ -196,10 +221,10 @@ <h2>Terminology</h2>
 participants to propose new blocks and to participate in the consensus
 protocol.<br>
 
-PoA type consensus protocols, like IBFT 2.0, are well suited to this type of
+PoA type consensus protocols, like EBFT, are well suited to this type of
 permissioning. While not every participant can propose new blocks, some
 consortium blockchains allow any valid blockchain identity to read data from the
-blockchain. IBFT 2.0 also allows for this type of configuration.
+blockchain. EBFT also allows for this type of configuration.
     </dd>
 
     <dt><dfn>Immediate Finality</dfn></dt>
@@ -276,7 +301,7 @@ <h2>Terminology</h2>
 in the model with the weakest assumptions (asynchronous network model). This
 means that the <a>liveness</a> property introduced above would be impaired in
 this model. There exist solutions that operate in the asynchronous network
-model, but the termination is only guaranteed probabilistically. The IBFT 2.0
+model, but the termination is only guaranteed probabilistically. The EBFT
 protocol is therefore <a>robust</a> in the network model with the weakest
 assumptions coming after the asynchronous network model.
     </dd>
@@ -284,1168 +309,1188 @@ <h2>Terminology</h2>
     <dt><dfn>Dynamic validator set</dfn></dt>
     <dd>
 Compared to classic (non-blockchain) consensus protocols where the set of
-participants is known in advance and never changes, IBFT 2.0, like Clique,
+participants is known in advance and never changes, EBFT, like Clique,
 allows participants to add and remove <a>validators</a> by a voting mechanism.
 
   </section>
-  
-  <section id="sec-block-header-modifications">
-
-  <h2>Block Header Modifications</h2>
 
-This section describes changes to the block headers used in Ethereum.
+  <section id="eea-protocol-overview">
 
-    <section id="sec-block-header-structure">
+  <h2>EBFT Protocol Overview</h2>
 
-    <h3>Block Header Structure</h2>
-
-The Ethereum block header structure is maintained intact except for the 
-$\mathtt{extraData}$ field, which in the IBFT 2.0 protocol is defined as:
+As is common to any blockchain implementation, each EBFT node
+maintains a local copy of the blockchain where the first block, the
+<dfn>genesis block</dfn>, is the same for all nodes.
 
-$\mathtt{extraData:[vanityData:\mathbb{B}_{32},\;validatorList:[validator_0:\mathbb{B}_{20},\;...,\;validator_n],}$
-$\mathtt{vote:[recipient:\mathbb{B}_{20},\;voteValue:\{0x00:\;\mathbb{B}_1,\;0xFF:\;\mathbb{B}_1\}]\;\mathbf{or}}$ $nil\mathtt{, round:\mathbb{B}_4,}$
-$\mathtt{commitSeals:[commitSeal_0:\;\mathbb{B}_{65},\;...,\;commitSeal_n]]}$
+Each block $B$ added to the blockchain must be cryptographically linked to
+another block in the blockchain, $B_p$, which is defined as the
+<dfn>parent</dfn> of block $B$. Conversely, $B$ is defined as the
+<dfn>child</dfn> of $B_p$.
 
-    </section>
+In EBFT, starting from the <a>genesis block</a>, the next block to
+be added to the local blockchain maintained by a node is the <a>child</a> of the
+block that was previously added to the blockchain. In this way, the EBFT
+blockchain can be modelled as a linked list of blocks, instead of a tree,
+like in the public Ethereum blockchain. In alignment with common terminology used
+in literature, the <dfn>height</dfn> of a block in a blockchain is defined as
+the number of parent links separating the block from the genesis block.
+The geneiss block has therefore height 0.
 
-    <section id="sec-block-header-rlp-encoding">
+The EBFT protocols can be modelled as running sequential
+instances of what we call the <em>EBFT-block-finalization-protocol</em>,
+where the objective of the $h$-th instance of the
+EBFT-block-finalization-protocol is to decide which Ethereum block, and
+consequently which set of transactions, are to be added at height $h$ of the
+blockchain maintained by any EBFT node.
 
-    <h3>RLP Encoding of Block Header</h2>
+Only a subset of the entire set of EBFT nodes can participate in the
+$h$-th instance of the block finalization protocol. We call this set of nodes
+the <em><a>validators</a></em> for height/instance h</em> and
+refer to each member of this set as a
+<em><a>validator</a> for height/instance h</em>. We also refer to all of the
+nodes not included in the <a>validator</a> set for height/instance h as
+<a>standard nodes</a>. In statements about <a>validators</a> where it is clear
+from the context, we often omit <em>for height/instance h</em>. The set of
+<a>validators</a> for each instance $h$ of the
+EBFT-block-finalization-protocol is deterministically computed as a function
+of the chain of blocks from the <a>genesis block</a> to the block with height
+$h-1$.
 
-This section outlines the RLP Encoding of the IBFT 2.0 block header for block
-header hash calculations.
+Each instance of the EBFT-block-finalization-protocol is organized in
+<dfn data-lt="round">rounds</dfn>. In each round one of the <a>validators</a>
+is responsible for proposing an Ethereum block for the height associated with
+the specific instance of the EBFT-block-finalization-protocol that the
+<a>validators</a> is running. After agreement is reached, the
+EBFT-block-finalization-protocol creates a finalized block, which includes
+the Ethereum block and additional information that allows any node, even nodes
+that did not participate in the EBFT-block-finalization-protocol, to verify
+that agreement on the Ethereum block included in the finalized block was
+correctly added.
 
-The IBFT 2.0 protocol defines a slightly different formula for computing the
-hash of the block header compared to the standard formula used in Ethereum. The
-RLP encoding of the IBFT 2.0 block header used to calculate the block header
-hash should be computed by removing the $\mathtt{round}$ and
-$\mathtt{commitSeals}$ fields from $\mathtt{extraData}$. More formally,
-$\mathtt{extraData}$ must be replaced with the following
-$\mathtt{extraDataForBlockHeaderHashCalculation}$:
+In practice, each EBFT node adds finalized blocks to its local
+blockchain, not just the Ethereum blocks included in them. In this way, any node
+joining the network at any point in time, when synching its local blockchain
+with its peers, receives all the information required to verify that agreement
+was reached correctly on each block that it receives, even on those created
+before it joined the network.
 
-$\mathtt{extraDataForBlockHeaderHashCalculation:[vanityData,\;validatorList,\;vote]}$
+Each Ethereum block can carry a vote, cast by the proposer of that block, to add
+a <a>validator</a> to or remove a <a>validator</a> from the <a>validator</a>
+set. When more than half of the <a>validators</a> cast a consistent vote to add
+or remove a <a>validator</a> to or from the <a>validator</a> set, the
+<a>validator</a> is added or removed from the validator set starting from the
+next block and all of the votes targeting this <a>validator</a> are discarded.
 
-where the value of $\mathtt{vanityData}$, $\mathtt{validatorList}$, and
-$\mathtt{vote}$ must be equal to the values of the homonymous fields in
-$\mathtt{extraData}$.
+<p class="note">The exact definition of the algorithm for calculating the
+validator set is missing from the current version of this specification and
+must be added at some point before finalization of the document.</p>
 
-    </section>
+  </section>
 
-    <section id="sec-block-header-validator-set">
+  <section id="eea-protocol-specification">
 
-    <h3>Computation of the validator set</h2>
+  <h2>EBFT Protocol Specification</h2>
 
-This section describes the algorithm used by the IBFT 2.0 protocol to compute
-the set of validators for any block. Description TBD. Pseudocode TBD.
+In this section we provide a detailed specificaiton of the EBFT protocol.
 
-    </section>
-	
-    <section id="sec-block-header-validation">
+    <section id="algorithm-convensions">
 
-    <h3>Block Header Validation</h2>
+    <h3>Algorithm Conventions</h3>
 
-The IBFT 2.0 protocol modifies the standard Ethereum block header validation as
-follows. $\mathtt{H}$ identifies the block header under validation.
+The EBFT protocol algorithms are textually described in Sections
+<a href="#algorithm-1-description"></a> and
+<a href="#ibft2-block-finalization-protocol"></a>, and by the pseudocode in
+Section <a href="#algorithm-pseudocode"></a>. The following
+conventions are used:
 
   <ul>
     <li>
-$\mathtt{parentHash}$: No change
+Statements are expressed in a mathematical form, but with standard
+mathematical symbols replaced by their English equivalent. For example,
+$\mathbf{in}$ instead of $\in$, $\mathbf{and}$ instead of $\land$,
+$\mathbf{there\;exists}$ instead of $\exists$, and so on. The intent is to
+provide an unambiguous definition of the protocol that can be understood by
+people not familiar with standard mathematical notation.
     </li>
     <li>
-$\mathtt{ommersHash}$: Must be equal to the Keccak hash of the RLP encoding of
-an empty list. That is, $\mathtt{KEC(RLP([]))}$
+Comments identified by
+<code style="color:green;">text in green typewriter font</code> are used to
+provide a natural language description of pseudocode statements that might not
+be immediately obvious.
     </li>
     <li>
-$\mathtt{beneficiary}$: Must be one the validators for the header under
-validation as computed by $\mathtt{validators(H)}$.
+For brevity of notation, we avoid using individual existential quantifiers
+(for example, $\exists$ in mathematical notation and $\mathbf{there\;exists}$ in
+English notation) for message fields, but instead express existential
+quantifiers on the entire message. We use an overhead line (for example
+$\overline{var}$, to indicate message fields that, if the extensive notation was
+used, then they should be expressed using an
+existential quantifier. For example, $\mathbf{there\;exists}$
+$\langle{f_1,}\overline{f_2}\rangle$ $\mathbf{in}$ ${receivedMessages_v}$
+stands for $\mathbf{there\;exists}$ $f_2$ $\mathbf{such\;that\;there\;exists}$
+$\langle{f_1,f_2}\rangle\in{receivedMessages_v}$.
     </li>
     <li>
-$\mathtt{stateRoot}$: No change
+Each of the $\mathbf{upon}$ blocks in the pseudocode is assumed to be executed
+atomically when the condition specified after the $\mathbf{upon}$ keyword is
+satisfied.
     </li>
     <li>
-$\mathtt{transactionsRoot}$: No change
+All functions in <code>typewriter font</code> are defined in the remainder of
+this section.
     </li>
     <li>
-$\mathtt{receiptsRoot}$: No change
+All functions in ${italic\;font}$ are defined in the pseudocode.
     </li>
     <li>
-$\mathtt{logsBloom}$: No change
+${receivedMessages_v}$ corresponds to the set of all messages received by node
+$v$.
     </li>
     <li>
-$\mathtt{difficulty}$: Must be equal to 1
+$\mathtt{peers}_v$ corresponds to the set of DEVp2p Gossip protocol peers of
+$v$;
     </li>
     <li>
-$\mathtt{number}$: No change
+$\{m\in{V}$ $\mathbf{such\;that}$ $P(m)\}$ corresponds to the set of all the
+elements of $V$ for which predicate $P$ is true.
+    </li>
+    <li>
+$\{F(m)$ $\mathbf{such\;that}$ $m\in{V}$ $\mathbf{and}$ $P(m)\}$ corresponds
+to the set obtained by applying the function $F$ to all the elements of $V$ for
+which predicate $P$ is true.
     </li>
     <li>
-$\mathtt{gasLimit}$: No change
+$\mathtt{allSubSetsOf}(M)$ corresponds to the set of all of the subsets of
+$M$, which is usually called the power set of $M$. For example,
+$\mathtt{allSubSetsOf}(\{m_1,m_2,m_3\})$ corresponds to the set
+$\{\{\},\{m_1\},\{m_2\},\{m_3\},\{m_1,m_2\},\{m_1,m_3\},\{m_2,m_3\},\{m_1,m_2,m_3\}\}$.
     </li>
     <li>
-$\mathtt{gasUsed}$: No change
+The symbol $*$ denotes any value.
     </li>
     <li>
-$\mathtt{timestamp}$: Must be $\ge$ than the timestamp of the parent block
-header + $\mathtt{BLOCK\_PERIOD}$
+<span style="color:darkred">Dark red color</span> denotes messages used only
+for modelling purposes and that do not have an immediate one-to-one relationship
+with the messages of the $\texttt{eth}$ sub-protocol [[Ethereum-Wire-Protocol]].
+The mapping between the abstract model and the concrete mesages is provided in
+Section <a href="data-structures"></a>.
     </li>
     <li>
-$\mathtt{extraData}$:
+Black color when applied to messages denotes EBFT specific messages not
+included in the current $\texttt{eth}$ sub-protocol [[Ethereum-Wire-Protocol]].
+    </li>
+    <li>
+$T:(t_1,...,t_n)$ indicates a tuple $(t_1,...,t_n)$ that is thereafter referred
+to as $T$.
+    </li>
+    <li>
+${\pi_m}(T)$ corresponds to the $m$-th element of the tuple $T$ where the
+first element has index 1. For example, ${\pi_2}((t_1,t_2,t_3))$ corresponds to
+$t_2$.
+    </li>
+    <li>
+$\mathtt{blockHeight}(EB)$ is defined as the height of the Ethereum block
+$EB$.
+    </li>
+    <li>
+$\mathtt{sizeOf}(M)$ indicates the size of the set $M$. That is,
+$\mathtt{sizeOf}(M)\equiv\lVert{M}\rVert$.
+    </li>
+    <li>
+$\mathtt{EthAddressRecover}(H,signature)$ corresponds to the Ethereum address
+whose signature of the hash $H$ corresponds to $signature$.
+    </li>
+    <li>
+Each <a>validator</a> $v$ stores its local blockchain in $chain_v$.
+    </li>
+    <li>
+$chain_v[n]$ corresponds to the finalized block with height $n$, while
+$chain_v[n:m]$ corresponds to a sub-chain including all of the finalized blocks
+from height $n$ to height $m$ included.
+    </li>
+    <li>
+$chain_{EB_v}[n]$ corresponds to the Ethereum block included in the finalized
+block with height $n$, while $chain_{EB_v}[n:m]$ corresponds to a sub-chain
+including all of the Ethereum blocks included in the finalized blocks from
+height $n$ to height $m$ included.
+    </li>
+    <li>
+The blockchain height is defined as the height of the last finalized block
+added to the blockchain.
+    </li>
+    <li>
+$\mathtt{validators}(chain_v[0:h-1])$ represents the set of authorized
+<a>validators</a> for instance $h$ of the EBFT-block-finalization-protocol.
+    </li>
+    <li>
+$\mathtt{n}(chain_v[0:h-1])$ represents the number of <a>validators</a> for
+instance $h$ of the EBFT-block-finalization-protocol. That is,
+$\mathtt{n}(chain_v[0:h-1])\equiv\mathtt{sizeOf}(\mathtt{validators}(chain_v[0:h-1]))$.
+    </li>
+    <li>
+      For the purpose of this section, $\mathtt{isValidBlock}(EB,EB_p)$ is
+      defined to be true if and only if block $EB$ is a valid Ethereum block with parent $EB_p$
+      where $\mathtt{isValidBlock}(EB,EB_p)$ only verifies the following
+fields of the standard Ethereum header:
+
     <ul>
       <li>
-$\mathtt{extraData.vanityData}$: Any sequence of $\le$ 32 bytes is admitted
+parentHash
       </li>
       <li>
-$\mathtt{extraData.validatorList}$: Must match the validator list for the header
-under verification as computed by $\mathtt{validators(H)}$
+stateRoot
       </li>
       <li>
-$\mathtt{extraData.vote}$:
-      <ul>
-        <li>
-$\mathtt{extraData.vote.recipient}$: Any sequence of 20 bytes is admitted
-        </li>
-        <li>
-$\mathtt{extraData.vote.voteValue}$: Must either $\mathtt{0x00}$ or $\mathtt{0xFF}$
-        </li>
-      </ul>
+transactionsRoot
       </li>
       <li>
-$\mathtt{extraData.round}$: Any sequence of 4 bytes is admitted
+receiptsRoot
       </li>
       <li>
-$\mathtt{extraData.commitSeals}$: As described by the pseudocode in ... :
-      <ul>
-        <li>
-All the elements of the $\mathtt{extraData.commitSeals}$ list must be unique
-        </li>
-        <li>
-The number of elements in the $\mathtt{extraData.commitSeals}$ list must be
-equal to $\mathtt{ceil\biggl(\frac{2*len(extraData.validators)}{3}\biggr)}$
-        </li>
-        <li>
-Each element of $\mathtt{extraData.commitSeals}$ must be a signature over the
-block header hash, as calculated by $\mathtt{headerHashForCommitSealCalculation}$
-(defined below) generated by one of the Ethereum addresses listed in
-$\mathtt{extraData.validators}$.
-
-$\mathtt{headerHashForCommitSealCalculation}$ is defined as the Keccak hash over
-the RLP encoding of the RLP encoding of the header with the field
-$\mathtt{commitSeals}$, but not $\mathtt{round}$, removed from the
-$\mathtt{extraData}$ field. More formally, $\mathtt{extraData}$ must be replaced
-with the following $\mathtt{extraDataForBlockHeaderHashCalculationForCommitSeal}$:
-
-$\mathtt{extraDataForBlockHeaderHashCalculationForCommitSeal:[vanityData,\;validatorList,\;vote,\;round]}$
-where the value of $\mathtt{vanityData}$, $\mathtt{validatorList}$,
-$\mathtt{vote}$, and $\mathtt{round}$ must be equal to the values of the
-homonymous fields in $\mathtt{extraData}$.
-        </li>
-      </ul>
+logsBloom
+      </li>
+      <li>
+number
+      </li>
+      <li>
+gasLimit
+      </li>
+      <li>
+gasUsed.
       </li>
     </ul>
+
+    For a detailed description of the validation performed by $\mathtt{isValidBlock}$
+    see Section <a href="#sec-block-header-validation"></a>.
+    </li>
+
     <li>
-$\mathtt{mixHash}$: Must be equal to $\mathtt{0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365}$
+      Each EBFT finalized block $FB$ is modelled by the tuple $(FB_{EB},FB_{FP})$ where:
+    <ul>
+      <li>$FB_{EB}$ is the Ethereum block to be added to the blockchain.</li>
+      <li>$FB_{FP}$ is the proof that agreement was correctly reached on the position in
+        the chain of the block $FB_{EB}$.</li>
+    </ul>
     </li>
+
     <li>
-$\mathtt{nonce}$: Must be equal to 0.
+      Each finalization proof $FP$ is modelled by the tuple
+      $(FB_r,FB_{CS})$ where:
+
+      - $FB_r$ is the round number of the EBFT-block-finalization-protocol, during
+      the execution of which, agreement on the block inclusion in the blockchain was
+      reached.
+      - $FB_{CS}$ is a list of signatures on both the Ethereum block and the round
+      proving that agreement was reached by a correct execution of the
+      EBFT-block-finalization-protocol. For more information about how this list
+      of signatures, called <dfn data-lt="commit seal">commit seals</dfn>, are
+      computed, see Section 3.1.
+
     </li>
   </ul>
 
     </section>
 
-  </section>  
-  
-  <section id="issues-addressed-by-ibft2">
-
-  <h2>Limitations in IBFT Addressed by IBFT 2.0</h2>
+    <section id="algorithm-1-description">
 
-As stated previously, the IBFT 2.0 protocol builds on the IBFT protocol
-([[IBFT]] and [[Quorum]]) and addresses the following limitations of the IBFT
-protocol, as described by Saltini [[IBFT-Analysis]]:
+    <h3>Description of the EBFT protocol (Algorithm 1)</h3>
 
-  <ul>
+The overarching structure of the EBFT protocol is essentially specificed by the $\mathbf{upon}$ block at line 10 of Algorithm 1, which states that when a new finalized block
+is received by a node $v$, $v$ executes the following operations:
+  <ol>
     <li>
-<a>Persistence</a> is not guaranteed, such that:
-    <ul>
+Verifies if the finalized block received is for the next expected chain height.
+That is, $h_v$.
+    </li>
+    <li>
+If so, it verifies if the finalized block received is a valid finalized block.
+    </li>
+    <li>
+If both verifications pass, then:
+    </li>
+    <ol type="a">
       <li>
-One Byzantine <a>validator</a> is potentially able to remove a transaction or
-change the position of a finalized transaction.
+$v$ adds the finalized block to its local blockchain.
       </li>
       <li>
-In a network of six <a>validators</a>, even if all <a>validators</a> are honest,
-a network partitioning can cause the blockchains maintained by two sets of three
-<a>validators</a> each to diverge. After the partitioning is resolved,
-<a>validators</a> have to choose one chain, which means removing or reordering
-transactions of the other chain.
+If $v$ is a <a>validator</a> for the current instance of the
+EBFT-block-finalization-protocol, then $v$ stops that instance.
       </li>
       <li>
-The IBFT protocol does not guarantee that a transaction added to the local
-blockchain of one <a>validator</a> is eventually added to the local blockchain
-of all other nodes.
+$v$ advances the next expected block height, $h_v$, by 1.
       </li>
-    </ul>
-    </li>
-    <li>
-<a>Liveness</a> is not guaranteed. Specifically, the IBFT protocol might reach a
-state where no new blocks can be added to any local blockchain, which means that
-no new transactions can be added to the distributed ledger.
-    </li>
-  </ul>
+      <li>
+If $v$ is a <a>validator</a> for the EBFT-block-finalization-protocol
+instance for the new value of $h_v$, then $v$ starts that instance.
+      </li>
+    </ol>
+  </ol>
 
-  </section>
+As described by the function $isValidFinalizationBlock(FB,v)$ at line 3, an
+EBFT finalized block $FB$ is defined valid if and only if all of the
+following conditions are met:
+- It contains at least $Quorum(n)\equiv\left\lceil\frac{2n}{3}\right\rceil$ different
+commit seals, where $n$ is the number of <a>validators</a> for instance $h$ of
+the EBFT-block-finalization-protocol. That is,
+$n\equiv\mathbf{n}(chain_v[0:h-1])$.
+- Each commit seal corresponds to the signature of one of the <a>validators</a>
+over the Ethereum block and the round number included in the finalization proof.
 
-  <section id="system-model-properties">
+Finalized blocks are delivered to nodes using the standard $\texttt{eth}$ RLPx [[RLPx]]
+sub-protocol [[Ethereum-Wire-Protocol]]. In the pseudocode we abstract the actual $\texttt{eth}$ sub-protocol and
+model the reception of a finalized block $FB$ with the reception of a
+<span style="color:darkred">$\langle\mathsf{FINALIZED-BLOCK},FB\rangle$</span>
+message. No such message actually exists in the concretee EBFT protocol.
+As per the standard $\texttt{eth}$ sub-protocol, a block can be
+received either using an unsolicited NewBlock message or using the pair of
+messages GetBlockHeaders/BlockHeaders followed by the pair of messages
+GetBlockBodies/BlockBodies [[Ethereum-Wire-Protocol]].
 
-  <h2>System Model Properties</h2>
+As specified by the $\mathbf{upon}$ block at line
+19, when a node $v$ receives an EBFT message (Proposal, Prepare, Commit or Round-Change message) including a height $h_m$ with
+value $\ge$ than the next expected height $h_v$, if the sender of the message is
+one of the DEVp2p peers of $v$, then $v$ starts asking the peer for finalized
+blocks with height between the $v$'s current height $h_v$ and the height $h_m$
+included in the EBFT message received. This is modeled with the transmission
+of a
+<span style="color:darkred">$\langle\mathsf{GET-BLOCKS},h_v,h_m\rangle$</span>
+message. The peer's response to this request is modeled as a
+<span style="color:darkred">$\langle\mathsf{FINALIZE-BLOCK},FB\rangle$</span>
+message.
+As stated previously, this is not an exact description of the real messages sent
+by the implementation. It is a modelling of the DEVp2p behavior useful in this
+context for speicifying the EBFT protocol at a high level. In our modelling
+of the protocol, we use $\mathbf{expectedHeight}_v[v']$ to express that
+Get-Blocks messages are sent only the first time an EBFT message with a
+height higher than $h_v$ is received.
 
-The system model considered for the IBFT 2.0 protocol is the same as that
-considered in the analysis of the IBFT protocol [[IBFT-Analysis]]. For
-convenience, these properties are restated here.
+    </section>
 
-  <dl>
-    <dt>
-Asynchronous nodes
-    </dt>
-    <dd>
-We consider a system composed of an unbounded number of asynchronous nodes, each
-of them maintaining a local copy of the blockchain obtained by adding blocks to
-it, as specified by the IBFT 2.0 protocol. We assume that all nodes have the
-same <a>genesis block</a>.
-    </dd>
-    <dt>
-Network model
-    </dt>
-    <dd>
-The IBFT 2.0 protocol relies on the Ethereum DEVp2p protocol for delivering all
-protocol messages. We model the gossip network as an eventually synchronous
-network, as defined in Dwork et al. [[Partial-Synchrony]], where there exists a
-point in time, called <dfn data-lt="gst">global stabilisation time</dfn> (GST),
-after which the message delay is bounded by a constant, $\Delta$. Before GST
-there is no bound on the message delay and we admit messages being lost.
-    </dd>
-    <dt>
-Failure model
-    </dt>
-    <dd>
-We consider a Byzantine failure mode system, where Byzantine nodes can behave
-arbitrarily. In contrast, honest nodes never diverge from the protocol
-definition. We denote the maximum number of Byzantine nodes that an eventually
-synchronous network of $n$ nodes participating in the consensus protocol can
-tolerate as $f(n)$. As proved in Dwork et al. [[Partial-Synchrony]], the
-relationship between the total number of nodes, $n$, and the maximum number of
-Byzantine nodes can be expressed as: $$f(n)\equiv\lfloor\frac{n-1}{3}\rfloor$$
-    </dd>
-    <dt>
-Cryptographic primitives
-    </dt>
-    <dd>
-The IBFT 2.0 protocol uses the Keccak hash function variant, as per the
-[[Ethereum-Yellow-Paper]], to produce block <dfn data-lt="digest">digests</dfn>.
-We assume that the Keccak hash function is collision-resistant.
+    <section id="ibft2-block-finalization-protocol">
 
-The IBFT 2.0 protocol relies on the Elliptic Curve Digital Signature (ECDS)
-scheme already used in the Ethereum protocol to sign transactions. We assume
-that this signature scheme ensures:
+    <h3>Description of the EBFT-block-finalization-protocol (Algorithm 2)</h3>
 
-    <ul>
-      <li>
-<dfn>Uniqueness</dfn>, which means that the signatures generated for two
-distinct messages have a high probability of being different.
-      </li>
-      <li>
-<dfn>Unforgeability</dfn>, which ensures that Byzantine nodes, even if they
-collude, cannot forge digital signatures produced by honest nodes. We use
-$\langle{m}\rangle_{\sigma_v}$ to denote a message $m$ signed by
-<a>validator</a> $v$.
-      </li>
-    </ul>
-    </dd>
-  </dl>
+This section describes a generic $h$ instance of the
+EBFT-block-finalization-protocol for a <a>validator</a> $v$, as detailed in
+Algorithm 2 in Section <a href="#algorithm-pseudocode"></a>.
 
-  </section>
+The EBFT-block-finalization-protocol is organized in rounds, starting from round
+0, where <a>validators</a> progress to the next round after they suspect that in
+the current round they cannot decide on the block to be included at height $h$
+of the blockchain. Both in Algorithm 2 and in this description, the current
+round for the $h$-th instance of the EBFT-block-finalization-protocol for
+<a>validator</a> $v$ is denoted as $r_{h,v}$.
 
+For each round, one of the <a>validators</a> is selected to play the role of
+block proposer. The selection is operated by the evaluation of
+$\mathbf{proposer}(chain_v[0:h-1],r_{h,v})$ where
+$\mathbf{proposer}(\cdotp,\cdotp)$ is a deterministic function of the chain of
+blocks from the genesis block until the block with height $h-1$ and the current
+round number.
 
+The pseudocode at lines 2 to 4 introduces the following macros:
 
+- $n_{h,v}$ - The number of <a>validators</a> for the $h$-th instance of the
+EBFT-block-finalization-protocol for <a>validator</a> $v$.
+- $\mathbf{validators}_{h,v}$ - The <a>validators</a> for the $h$-th instance of
+the EBFT-block-finalization-protocol for <a>validator</a> $v$.
+- $\mathbf{proposer}_{h,v}(r_{h,v})$ - The proposer for round $r_{h,v}$ of the
+$h$-th instance of the EBFT-block-finalization-protocol for <a>validator</a>
+$v$.
 
+These macros are used both in the pseudocode and in this section to simplify the
+notation when describing the $h$-th instance of the
+EBFT-block-finalization-protocol for <a>validator</a> $v$. The term,
+<em>non-proposing <a>validators</a> for round r and instance h</em>, is used to
+indicate all of the <a>validators</a> for round $r$ and instance $h$ with the
+exclusion of the proposer for round $r$ and instance $h$.
 
-  <section id="message-structures">
+THe proposer selection function ensures that all of the <a>validators</a> for the $h$-th
+instance of the EBFT-block-finalization-protocol are selected for any
+sequence of $n_{h,v}$ consecutive rounds.
+Also, the proposer for round 0 corresponds to the
+proposer of the proposer selection sequence that comes after the proposer of the
+block included in the previous finalized block.
+
+<p class="note">The specification and description of the exact algorihtm used for the proposer
+  selection function is currently not included in this specification and must be
+  added at some point before finalization of the document..</p>
+
+As specified by the initialization block (line 9), if $v$ is the selected block
+proposer for the first round, that is, round 0, then $v$ multicasts a <a>Proposal message</a>
+$\langle\langle\mathsf{PROPOSAL},h,0,\mathbf{KEC}(PB)\rangle_{\sigma_v},PB,\bot\rangle$
+to all <a>validators</a> (including itself) that comprises the message
+$\langle\langle\mathsf{PROPOSAL},h,0,\mathbf{KEC}(PB)\rangle_{\sigma_v}$
+signed by $v$, the proposed block $PB$ and a Round-Change-Certificate, which for
+round 0 is empty (that is, $\bot$). More detail on how the
+Round-Change-Certificate is assembled is provided further down in this section
+when discussing how <a>validators</a> move to a different round.
 
-  <h2>Message Structures</h2>
+The proposed block $PB$ is modelled here as a tuple where the first element is a
+standard Ethereum block and the second element is the current round number at
+which the Ethereum block was created, which at initialization is 0.
+$\mathbf{KEC}(\cdotp)$ represents the Keccak hash function. The pseudocode uses
+$\mathbf{createNewProposedBlock}(h,v)$ to represent the creation of a new block
+with height $h$ by <a>validator</a> $v$. Honest <a>validators</a> employee a
+fair transaction selection algorithm to decide which transactions to include in
+the next block. The definition of such algorithm is outside the scope of this
+document.
 
-This section defines the structures of the BFT sub-protocol messages
-communicated between Ethereum nodes.
+As specified by lines 31 to 32, a <a>validator</a> $v$ accepts a <a>Proposal message</a>
+$\langle\langle\mathsf{PROPOSAL},h_{pp},r_{pp},H\rangle,PB:(EB,r_{EB}),*\rangle$
+if and only if all of the following conditions are met:
 
-All messages MUST be encoded using Recursive Length Prefix (RLP) encoding
-serialization, as specified in [[RLP]].
+- $v$ is currently running the EBFT-block-finalization-protocol instance
+$h_{pp}$. That is, $h_{pp}=h$.
+- $v$ is in round 0. That is, $r_{pp}=r_{h,v} = 0$.
+- The signed portion of the message, $\langle\mathsf{PROPOSAL},h_{pp},r_{pp},H\rangle$,
+is signed by the selected proposer for round $r_{h,v} = 0$ and instance $h$ of
+the EBFT-block-finalization-protocol.
+- $v$ has not already accepted a <a>Proposal message</a> for round $r_{h,v} = 0$
+in the $h$-th instance of the EBFT-block-finalization-protocol. That is,
+$acceptedPB = \bot$.
+- The Ethereum block $EB$ included in the proposed block $PB$ is a valid block
+for height $h$.
+- The round number included in the prepared block $PB$ matches the current round
+number. That is, $r_{h,v} = r_{EB} = 0$.
+- $H$ corresponds to the Keccak hash of the proposed block $PB$.
 
-For any type of message, the <dfn>signature</dfn> corresponds to the hash over
-the message using the <a>validator</a> private key:
+When a <a>validator</a> $v$ accepts a <a>Proposal message</a>, it:
 
-<code>hashForMessageSignature(message) = KEC(concatenate(message.ID, RLP(message.payload)))</code>
+- Marks the <a>Proposal message</a> as accepted by setting the state variable
+$acceptedPB$ to the proposed block included in the <a>Proposal message</a> (see
+line 16).
+- Multicasts a <a>Prepare message</a>
+$\langle\mathsf{PREPARE},h,r_{h,v},H\rangle_{\sigma_v}$ (see line 17) to all
+<a>validators</a> (including itself).
 
+The $\mathbf{upon}$ block at line 36 is executed the first time all of the
+following conditions are met by <a>validator</a> $v$:
 
-    <section id="proposal-message">
+- $v$ has accepted a <a>Proposal message</a> for the proposed block $PB$. That
+is, $acceptedPB_{h,v} = PB$.
+- $v$ has received, from non-proposing <a>validators</a> for the current round,
+at least $Quorum(n_{h,v})-1$ <a>Prepare message</a> for the current instance of
+the EBFT-block-finalization-protocol, current round, and with digest $H$
+corresponding to the Keccak hash of the accepted proposed block $PB$.
 
-    <h3>Proposal Message</h3>
+When all of the conditions listed above are met for the first time, then:
 
-The block <a>proposer</a> MUST send the
-<dfn data-lt="proposal messages|proposal|proposals">Proposal message</dfn> to
-all other <a>validators</a> at the beginning of any round.
+- $v$ multicasts a <a>Commit message</a>
+$\langle\mathsf{COMMIT},h,r_{h,v},H,CS(PB,v)\rangle_{\sigma_v}$ to all
+<a>validators</a> (including itself), where $CS(PB,v)$, called
+<em>commit seal</em>, corresponds to the signature of $v$ over the proposed
+block $PB$ and the current round number.
+- $v$ sets $latestPreparedProposedBlock_{h,v}$ to the proposed block $PB$;
+- $v$ sets $latestPC_{h,v}$ to a set including the signed portion of the
+accepted <a>Proposal message</a> and all of the <a>Prepare message</a> sent by
+non-proposing <a>validators</a> for the current round targeting the current
+instance of the EBFT-block-finalization-protocol, current round and with
+digest $H$ corresponding to the Keccak hash of the accepted proposed block $PB$.
 
-**Message content**
+The pseudocode uses the state variable $commitSent_{h,v}$ to indicate that the
+<a>Commit message</a> is sent only the first time that all of the conditions
+listed above are met. $commitSent_{h,v}$ is set to $true$ at line 39 and reset
+to $false$ in the $StartNewRound$ procedure at line 26. Borrowing from the PBFT
+terminology, when a <a>validator</a> meets the conditions indicated in the
+$\mathbf{upon}$ block at line 36, then $v$ is said to be $prepared$ at round
+$r_{h,v}$. Borrowing again from the PBFT terminology, $latestPC_{h,v}$ is the
+latest Prepared-Certificate and the protocol is designed so that
+$latestPC_{h,v}$ always holds at least the minimum number of messages required
+to prove that $v$ $prepared$ in round $r_{h,v}$ on a proposed block with Keccak
+hash $H$. We say that a Prepared-Certificate is for round $r$ and instance $h$
+if and only if the Prepared-Certificate only includes signed
+<a data-lt="proposal message">Proposal</a> and
+<a data-lt="prepare message">Prepare</a> messages for round $r$ and height $h$.
+$latestPC_{h,v}$ always holds the Prepared-Certificate for the latest round in
+the current instance $h$ where $v$ is $prepared$. $latestPC_{h,v} = \bot$ only
+if $v$ has never $prepared$ in the current instance $h$.
+
+The $\mathbf{upon}$ block at line 44 is executed the first time all of the
+following conditions are met by <a>validator</a> $v$:
+
+- $v$ has accepted a <a>Proposal message</a> for the proposed block $PB$. That
+is, $acceptedPB_{h,v} = PB$.
+- $v$ has received, from at least different $Quorum(n_{h,v})$ <a>validators</a>
+for the current instance of the EBFT-block-finalization-protocol, a
+<a>Commit message</a> for the current instance of the
+EBFT-block-finalization-protocol, current round, with digest $H$
+corresponding to the Keccak hash of the accepted proposed block $PB$ and commit
+seal signed by the sender of the <a>Commit message</a>.
+
+When all of the conditions listed above are met for the first time, then:
+
+- $v$ creates a block finalization proof modelled as a tuple comprising the
+current round number and the commit seals included in all the
+<a>Commit messages</a> that satisfy the condition on <a>Commit messages</a>
+stated above.
+- $v$ creates a finalized block modelled as a tuple comprising the Ethereum
+block included in the proposed block and the finalization proof.
+- $v$ broadcasts the finalized block to all nodes.
+
+The pseudocode uses the state variable $finalizedBlockSent_{h,v}$ to trigger the
+transmission of a finalized block only the first time the conditions listed
+above are met. $finalizedBlockSent_{h,v}$ is set at line 50 and reset in the
+$StartNewRound$ procedure at line 12.
+
+In alignment with PBFT, the EBFT protocol relies on a round change
+sub-protocol to detect whether the selected proposer might be Byzantine and
+causing the protocol to never terminate. As specified at lines 21 to 22,
+whenever a <a>validator</a> $v$ starts a new round, it starts a round timer with
+a duration exponential to the round number (see line 8).
+
+When <a>validator</a> $v$'s round timer for the current round expires (line 51),
+$v$ starts the round $r_{h,v} + 1$ and multicasts a
+$\langle\langle\mathsf{ROUND-CHANGE},h,r_{h,v} + 1,latestPC_{h,v}\rangle,latestPreparedProposedBlock_{h,v}\rangle$
+message for the new round to all <a>validators</a> (including itself). Note that
+the <a>Round Change message</a> includes the latest
+Prepared-Certificate and the proposed block associated with the latest Prepared
+Certificate.
+
+The $\mathbf{upon}$ block at line 55 describes under which conditions a
+<a>Proposal message</a> for a new round is multicast and how the
+<a>Proposal message</a> is assembled. Specifically, the
+$\mathbf{upon}$ block is executed only if $v$ has received at least
+$Quorum(n_{h,v})$ <a>Round Change messages</a> for the current
+EBFT-block-finalization-protocol instance such that:
+
+  <ul>
+    <li>
+All messages are for the same round number $r_{rc}$ and $r_{rc}$ is higher than
+the current round.
+    </li>
+    <li>
+All messages are sent by distinct <a>validators</a> for the current instance of
+the EBFT-block-finalization-protocol.
+    </li>
+    <li>
+All messages contain a valid Prepared-Certificate. A Prepared-Certificate is
+considered valid either if it is empty ($\bot$) or if it contains one
+<a>Proposal message</a> and at least $Quorum(n_{h,v}) - 1$
+<a>Prepare messages</a> for the same round $r'$ such that:
+    <ul>
+      <li>
+$r'\lt$ than the the round number of the <a>Round Change messages</a>, $r_{rc}$.
+      </li>
+      <li>
+The <a>Proposal message</a> is signed by the selected proposer for round $r'$.
+      </li>
+      <li>
+The <a>Prepare messages</a> are sent by non-proposing validators for the $h$-th
+instance of the EBFT-block-finalization-protocol and round $r'$ and they are
+all for the current instance $h$ of the EBFT-block-finalization-protocol,
+round $r'$ and same hash as the one included in the <a>Proposal message</a>.
+      </li>
+    </ul>
+    </li>
+    <li>
+The Keccak hash of the $proposedBlock$ included in each of the
+<a>Round Change messages</a> considered matches the hash included in the
+<a data-lt="proposal message">Proposal</a> and
+<a data-lt="prepare message">Prepare</a> message of the Prepared-Certificate.
+    </li>
+  </ul>
+
+Any set meeting these conditions is a valid Round-Change-Certificate for round
+$r'$ where round $r'$ is the round included in all of the
+<a>Round Change messages</a> included in the Round-Change-Certificate. When all
+of the conditions listed above are met, then:
+
+  <ul>
+    <li>
+$v$ moves to the round number included in one of the Round-Change-Certificates
+with the highest round number, lets $RCC$ be the chosen Round-Change-Certificate
+and lets $r_h$ be the round number of $RCC$.
+    </li>
+    <li>
+If $v$ was not already in $r_h$, then $v$ starts the round timer for round $r_h$.
+    </li>
+    <li>
+If $v$ is the selected proposer for round $r_h$, $v$ sends a
+<a>Proposal message</a> for the new round including the selected
+Round-Change-Certificate ($RCC$) and a proposed block calculated as follows:
+    <ul>
+      <li>
+If all of the Prepared-Certificates included in the
+<a>Round Change message</a> are empty, that is $=\bot$, then the proposed block
+must be a tuple including any valid Ethereum block for height $h$ and the
+current round number, which must match the round number of the
+<a>Proposal message</a>.
+      </li>
+      <li>
+Otherwise, the Ethereum block included in the tuple constituting the proposed
+block must match the proposed block received as part of one of the
+<a>Round Change messages</a> including a Prepared-Certificate for the highest
+round amongst the rounds of all the other Prepared-Certificates included in the
+Round-Change-Certificate.
+      </li>
+    </ul>
+    </li>
+  </ul>
+
+As specified by the $\mathbf{upon}$ block at line 71, a <a>Proposal message</a>
+$\langle\langle\mathsf{PROPOSAL},h,r_{pp},H\rangle_{\sigma_{sender}},PB;RCC\rangle$
+for a round higher than 0 is accepted only if all of the following conditions
+are met:
+
+  <ul>
+    <li>
+$v$ is currently running the EBFT-block-finalization-protocol instance
+$h_{pp}$. That is, $h_{pp}=h$.
+    </li>
+    <li>
+The round number $r_{pp}$ of the <a>Proposal message</a> is either higher than
+the current round or equal to the current round provided that $v$ has not
+accepted any <a>Proposal message</a> for the current round. That is,
+$acceptedPB = \bot$.
+    </li>
+    <li>
+$H$ corresponds to the Keccak hash of the proposed block $PB$.
+    </li>
+    <li>
+The signed portion of the message is signed by the selected proposer for round
+$r_{pp}$ and instance $h$ of the EBFT-block-finalization-protocol.
+    </li>
+    <li>
+The Round-Change-Certificate $RCC$ includes at least $Quorum(n_{h,v})$
+<a>Round Change messages</a> for round $r_pp$ and height $h$.
+    </li>
+    <li>
+If each of the <a>Round Change messages</a> included in the
+Round-Change-Certificate $RCC$ includes either an invalid Prepared-Certificate
+or an empty Prepared-Certificate, then the:
+    <ul>
+      <li>
+Ethereum block $EB$ included in the proposed block $PB$ must be a valid block
+for height $h$.
+      </li>
+      <li>
+Round number $r_{EB}$ included in the prepared block $PB$ must match the current
+round number. That is, $r_{h,v} = r_{EB}$.
+      </li>
+    </ul>
+    </li>
+    <li>
+Otherwise, the Keccak hash of the tuple composed of the Ethereum block included
+in $PB$ and the highest round number of all Prepared-Certificated included in
+$RCC$ must match the hash included in any of the messages that are part of the
+Prepared-Certificates with the highest round number amongst all of the
+Prepared-Certificates included in the Round-Change-Certificate $RCC$.
+    </li>
+  </ul>
+
+The effect of accepting a <a>Proposal message</a> for a round $r_{pp} \gt 0$ is
+essentially the same as accepting the <a>Proposal message</a> for round 0 with
+the addition of moving to round $r_{pp}$. Specifically, $v$:
+
+  <ul>
+    <li>
+Moves to round $r_{pp}$ and starts the related round timer if $v$ was not
+already in round $r_{pp}$.
+    </li>
+    <li>
+Multicasts a <a>Prepare message</a>
+$\langle\mathsf{PREPARE},h,r_{h,v},H\rangle_{\sigma_v}$ to all validators
+(including itself).
+    </li>
+    <li>
+Sets $acceptedPB_{h,v}$ to the proposed block $PB$ indicating that it
+accepted a <a>Proposal message</a> for $PB$.
+    </li>
+  </ul>
+
+From here on the protocol proceeds as described above.
 
-The Proposal message contains the following fields:
 
-  - <code>0x00</code> DATA, x? bytes – The message ID for the Proposal message
-type.
-  - <code>payload</code> – A list containing each of the following:
-  
-    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block
-being proposed, as an integer.
-    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number, as an
-integer.
-    - <code>digest</code> DATA, 32 bytes – The Keccak hash of the proposed
-block.
-  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the payload.
-  - <code>proposedBlock</code> – The content of the proposed block in Ethereum
-block format.
 
     </section>
 
-    <section id="prepare-message">
+    <section id="algorithm-pseudocode">
 
-    <h3>Prepare Message</h3>
+    <h3>Algorithm Pseudocode</h3>
 
-The <dfn data-lt="prepare messages">Prepare message</dfn> MUST be sent when a
-<a>validator</a> that is not the designated block proposer for a round receives
-a <a>Proposal message</a>.
-  
-**Message content**
+<figure id="fig-algorithm1">
+  <img src="./images/IBFT2_algorithm1.png" alt="Algorithm 1">
+  <figcaption>EBFT Protocol for EBFT node $v$ (Algorithm 1)</figcaption>
+</figure>
 
-The Prepare message contains the following fields:
+<figure id="fig-algorithm2">
+  <img src="./images/IBFT2_algorithm2.png" alt="Algorithm 2">
+  <figcaption>The EBFT-block-finalization-protocol (Algorithm 2)</figcaption>
+</figure>
 
-  - <code>0x01</code> DATA, x? bytes – The message ID for the Prepare message
-type.
-  - <code>payload</code> – An array of the following:
-  
-    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block
-being prepared, as an integer.
-    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number, as an
-integer.
-    - <code>digest</code> DATA, 32 bytes – The <a>digest</a> of the prepared
-block?
-  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the payload.
+
+<p class="note">Algorithms for the computing the validator set and for the proposer selection function must be added.</b>
 
     </section>
 
-    <section id="commit-message">
 
-    <h3>Commit Message</h3>
+  </section>
 
-The <dfn data-lt="commit messages">Commit message</dfn> MUST be sent by a
-<a>validator</a> when <em>enough</em> <a>Prepare messages</a> matching the
-<a>Proposal</a> sent by the designated <a>proposer</a> of the round are
-received.
-  
-**Message content**
+  <section id="data-structures">
 
-The Commit message contains the following fields:
+  <h2>Data Structures Encoding</h2>
 
-  - <code>0x02</code> DATA, x? bytes – The message ID for the Commit message
-type.
-  - <code>payload</code> – An array of one or more of the following:
-  
-    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block
-being prepared, as an integer.
-    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number, as an
-integer.
-    - <code>digest</code> DATA, 32 bytes – The <a>digest</a> of the prepared
-block?
-    - <code>commitSeal</code> DATA, 32 bytes – The signature of the
-<a>validator</a> over the proposed block included in the <a>Proposal message</a>
-received by the designated proposer of the round.
-  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the payload.
+<p>This section provides the  details of how data structures such as messages, block
+headers and finalisation proof, for which only an abstract model is provided in
+Section <a href="#eea-protocol-specification"></a>, are bit-wise represented and encoded.
 
-    </section>
+When it may be ambigious whether the text refers to the abstract data structures of Section <a href="#eea-protocol-specification"></a>
+or to the encoding of those data strcutures, the term "abstract data structure" is used to refer to the abstract
+data structures of Section <a href="#eea-protocol-specification"></a>, while the
+term "concrete data structure" is used to refer to actual encoding of those data
+structures.
+</p>
+      <section id="proposed-finalized-ethereum-blocks">
 
-    <section id="round-change-message">
 
-    <h3>Round Change Message</h3>
+      <h3>Proposed Blocks, Finalized Blocks and Ethereum Blocks</h3>
 
-A <dfn data-lt="round change messages">Round Change message</dfn> MUST be sent
-by a <a>validator</a> when they suspect no agreement on the block to be added to
-the blockchain with the given height will be reached in this round.
-  
-**Message content**
+From a bit representation perspective, proposed blocks, finalised blocks and
+EBFT Ethereum blocks share the same data structure.
 
-The Round Change message contains the following fields:
+The difference between them lies in how the fields of the block structure are treated
+in the block verification.
 
-  - <code>0x03</code> DATA, x? bytes – The message ID for the Round Change
-message type.
-  - <code>payload</code> – An array of one or more of the following:
-  
-    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block for
-which the <a>validator</a> is trying to reach agreement, as an integer.
-    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number to which
-the <a>validator</a> intends to move to, as an integer.
-    - <code>preparedCertificate</code> DATA – See below.
-	  
-  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the
-concatenation of the message ID and the payload.
-  - <code>latestProposedBlock</code> DATA - <code>nil</code> or the content of
-the latest prepared block in Ethereum block format. Should be <code>nil</code>
-if <code>preparedCertificate</code> is <code>nil</code>.
+The concrete data strucutre is a modification of the standard Ethereum data structure which
+hereafter is called "EBFT Block Structure".
 
-The <code>preparedCertificate</code> might be <code>nil</code> or a list of: 
 
-  - <code>signedPartOfProposalMessage</code> – The payload and signature copied
-from the latest prepared <a>Proposal message</a>.
-  - <code>signedPartOfPrepareMessages</code> – The list of payloads and
-signatures copied from the latest prepared <a>Prepare messages</a>.
+      </section>
 
-If <code>latestProposedBlock</code> is not <code>nil</code>, then the digest of
-<code>signedPartOfProposalMessage</code> and all messages included in
-<code>signedPartOfPrepareMessages</code> should match the Keccak hash of
-<code>proposedBlock</code>.
+      <section >
 
-    </section>
 
-  </section>
+      <h3>EBFT Block Structure</h3>
 
-  <section id="ibft2-protocol-description">
+The EBFT block structure is split betwen Header and Body.
 
-  <h2>IBFT 2.0 Protocol Description</h2>
+The body of the EBFT block structure is identical to the Ethereum block structure.
 
-As is common to any blockchain implementation, each IBFT 2.0 or IBFT node
-maintains a local copy of the blockchain where the first block, the
-<dfn>genesis block</dfn>, is the same for all nodes.
+The header of the EBFT block structure is identical to the Ethereum header structure
+except for the extraData field which in an EBFT block is as follows:
 
-Each block $B$ added to the blockchain must be cryptographically linked to
-another block in the blockchain, $B_p$, which is defined as the
-<dfn>parent</dfn> of block $B$. Conversely, $B$ is defined as the
-<dfn>child</dfn> of $B_p$.
+ <b>extraData</b>
 
-In IBFT 2.0 or IBFT, starting from the <a>genesis block</a>, the next block to
-be added to the local blockchain maintained by a node is the <a>child</a> of the
-block that was previously added to the blockchain. In this way, the IBFT 2.0 or
-IBFT blockchain can be modelled as a linked list of blocks, instead of a tree,
-like in the public Ethereum blockchain. In keeping with common terminology used
-in literature, the <dfn>height</dfn> of a block in a blockchain is defined as
-the number of parent links separating the block from the genesis block, which
-has height 0.
+<ul>
+  <li>vanityData DATA, 0 to 32 bytes. </li>
+  <li>validatorList LIST - A variable lenght list of Ethereum addresses (20 byte each), representing the Ethereum address associated with each validator. </li>
+  <li>vote - either
+<ul>
+  <li>
+    LIST - A list comprised of the following elements:
+</li>  <ul>
+    <li>recipient ADDRESS, 20 bytes - the address of the Ethereum node for which the vote is cast</li>
+    <li>voteValue DATA, 1 byte - either 0x00 or 0xFF</li>
+  </ul>
+</li>
+<li>or</li>
+<li>nil - if no vote is cast</li>
+</ul>
+<li>round QUANTITY, 4 bytes - The round number at which the finalized block was created</li>
+<li>commitSeals LIST - A variable list of signatures (65 bytes) representing the commit seals</li>
+</ul>
+      </section>
 
-Both the IBFT 2.0 and IBFT protocols can be modelled as running sequential
-instances of what we call the <em>IBFT-2.0-block-finalization-protocol</em>,
-where the objective of the $h$-th instance of the
-IBFT-2.0-block-finalization-protocol is to decide which Ethereum block, and
-consequently which set of transactions, are to be added at height $h$ of the
-blockchain maintained by any IBFT 2.0 or IBFT node.
+    <section id="sec-block-header-validation">
 
-Only a subset of the entire set of IBFT 2.0 or IBFT nodes can participate in the
-$h$-th instance of the block finalization protocol. We call this set of nodes
-the <em><a>validators</a></em> for height/instance h</em> and
-refer to each member of this set as a
-<em><a>validator</a> for height/instance h</em>. We also refer to all of the
-nodes not included in the <a>validator</a> set for height/instance h as
-<a>standard nodes</a>. In statements about <a>validators</a> where it is clear
-from the context, we often omit <em>for height/instance h</em>. The set of
-<a>validators</a> for each instance $h$ of the
-IBFT-2.0-block-finalization-protocol is deterministically computed as a function
-of the chain of blocks from the <a>genesis block</a> to the block with height
-$h-1$.
+    <h3>Block Header Validation</h2>
 
-Each instance of the IBFT-2.0-block-finalization-protocol is organized in
-<dfn data-lt="round">rounds</dfn>. In each round one of the <a>validators</a>
-is responsible for proposing an Ethereum block for the height associated with
-the specific instance of the IBFT-2.0-block-finalization-protocol that the
-<a>validators</a> is running. After agreement is reached, the
-IBFT-2.0-block-finalization-protocol creates a finalized block, which includes
-the Ethereum block and additional information that allows any node, even nodes
-that did not participate in the IBFT-2.0-block-finalization-protocol, to verify
-that agreement on the Ethereum block included in the finalized block was
-correctly added.
+    As mentioned in Section <a href="#proposed-finalized-ethereum-blocks"></a>,
+    while finalized blocks and proposed blocks share the same data structure, they differ
+    in how the they get validated.
 
-In practice, each IBFT 2.0 or IBFT node adds finalized blocks to its local
-blockchain, not just the Ethereum blocks included in them. In this way, any node
-joining the network at any point in time, when synching its local blockchain
-with its peers, receives all the information required to verify that agreement
-was reached correctly on each block that it receives, even on those created
-before it joined the network. Each IBFT 2.0 finalized block $FB$ can be modelled
-by the tuple $(FB_{EB},FB_{FP})$ where:
+    The next subsection describes some additional notation used in this section, the following sub-section describes the validation for the fields that share the
+    same validation rules between proposed and finalized blocks, while the last two sub-sections describe the validation
+    for the fields with different validation rules.
 
-- $FB_{EB}$ is the Ethereum block to be added to the blockchain.
-- $FB_{FP}$ is the proof that agreement was correctly reached on the position in
-the chain of the block $FB_{EB}$.
+    <section>
 
-Each finalization proof $FP$ can be in turn modelled by the tuple
-$(FB_r,FB_{CS})$ where:
 
-- $FB_r$ is the round number of the IBFT-2.0-block-finalization-protocol, during
-the execution of which, agreement on the block inclusion in the blockchain was
-reached.
-- $FB_{CS}$ is a list of signatures on both the Ethereum block and the round
-proving that agreement was reached by a correct execution of the
-IBFT-2.0-block-finalization-protocol. For more information about how this list
-of signatures, called <dfn data-lt="commit seal">commit seals</dfn>, are
-computed, see Section 3.1.
+      <h4>Notation</h4>
 
-Each Ethereum block can carry a vote, cast by the proposer of that block, to add
-a <a>validator</a> to or remove a <a>validator</a> from the <a>validator</a>
-set. When more than half of the <a>validators</a> cast a consistent vote to add
-or remove a <a>validator</a> to or from the <a>validator</a> set, the
-<a>validator</a> is added or removed from the validator set starting from the
-next block and all of the votes targeting this <a>validator</a> are discarded.
-This document does not describe this algorithm, but it might be added in a
-future revision.
+<ul>
+  <li>The following function produces an extact copy, including the content, of the data structure $\mathtt{structure}$
+      but with the field $\mathtt{field}$ removed.
+      $\mathtt{removeField}(\mathtt{structure},\mathtt{field}) $
+  </li>
+</ul>
+    </section>
 
-    <section id="algorithm-convensions">
 
-    <h3>Algorithm Conventions</h3>
+    <section id="common-validation-rules">
 
-The IBFT 2.0 protocol algorithms are textually described in Sections
-<a href="#starting-stopping-ibft2-protocol"></a> and
-<a href="#ibft2-block-finalization-protocol"></a>, and by the pseudocode in
-Section <a href="#algorithm-pseudocode"></a>. The following
-conventions are used:
+      <h4>Common Validation Rules</h4>
 
   <ul>
     <li>
-Statements are expressed in a mathematical form, but with standard
-mathematical symbols replaced by their English equivalent. For example,
-$\mathbf{in}$ instead of $\in$, $\mathbf{and}$ instead of $\land$,
-$\mathbf{there\;exists}$ instead of $\exists$, and so on. The intent is to
-provide an unambiguous definition of the protocol that can be understood by
-people not familiar with standard mathematical notation.
-    </li>
-    <li>
-Comments identified by
-<code style="color:green;">text in green typewriter font</code> are used to
-provide a natural language description of pseudocode statements that might not
-be immediately obvious.
-    </li>
-    <li>
-For brevity of notation, we avoid using individual existential quantifiers
-(for example, $\exists$ in mathematical notation and $\mathbf{there\;exists}$ in
-English notation) for message fields, but instead express existential
-quantifiers on the entire message. We use an overhead line (for example
-$\overline{var}$, to indicate message fields that, if the extensive notation was
-used, then they should be expressed using an
-existential quantifier. For example, $\mathbf{there\;exists}$ 
-$\langle{f_1,}\overline{f_2}\rangle$ $\mathbf{in}$ ${receivedMessages_v}$
-stands for $\mathbf{there\;exists}$ $f_2$ $\mathbf{such\;that\;there\;exists}$
-$\langle{f_1,f_2}\rangle\in{receivedMessages_v}$.
-    </li>
-    <li>
-Each of the $\mathbf{upon}$ blocks in the pseudocode is assumed to be executed
-atomically when the condition specified after the $\mathbf{upon}$ keyword is
-satisfied.
-    </li>
-    <li>
-All functions in <code>typewriter font</code> are defined in the remainder of
-this section.
-    </li>
-    <li>
-All functions in ${italic\;font}$ are defined in the pseudocode.
-    </li>
-    <li>
-${receivedMessages_v}$ corresponds to the set of all messages received by node
-$v$.
-    </li>
-    <li>
-$\mathtt{peers}_v$ corresponds to the set of DEVp2p Gossip protocol peers of
-$v$;
-    </li>
-    <li>
-$\{m\in{V}$ $\mathbf{such\;that}$ $P(m)\}$ corresponds to the set of all the 
-elements of $V$ for which predicate $P$ is true.
-    </li>
-    <li>
-$\{F(m)$ $\mathbf{such\;that}$ $m\in{V}$ $\mathbf{and}$ $P(m)\}$ corresponds
-to the set obtained by applying the function $F$ to all the elements of $V$ for
-which predicate $P$ is true.
-    </li>
-    <li>
-$\mathtt{allSubSetsOf}(M)$ corresponds to the set of all of the subsets of
-$M$, which is usually called the power set of $M$. For example,
-$\mathtt{allSubSetsOf}(\{m_1,m_2,m_3\})$ corresponds to the set
-$\{\{\},\{m_1\},\{m_2\},\{m_3\},\{m_1,m_2\},\{m_1,m_3\},\{m_2,m_3\},\{m_1,m_2,m_3\}\}$.
-    </li>
-    <li>
-The symbol $*$ denotes any value.
-    </li>
-    <li>
-<span style="color:darkred">Dark red color</span> denotes messages used only
-for modelling purposes and that do not have an immediate one-to-one relationship
-with the messages of the Ethereum sub-protocol.
-    </li>
-    <li>
-Black color when applied to messages denotes IBFT 2.0 specific messages not
-included in the current Ethereum sub-protocol.
+$\mathtt{parentHash}$:
+Must be equal to $\mathtt{KEC}(\mathtt{RLP}(\mathtt{removeField}(\mathtt{removeField}(FB_{p}{ },\texttt{extraData.commitSeals}),\texttt{round})))$
+where $FP_{p}$ indicates the parent finalized block.
+
+Essentially, the hash of the parent block is calculated in the same way that the
+parent hash is calculated in Ethereum, but with the fields $\texttt{extraData.round}$
+and $\texttt{extraData.commitSeals}$ removed from $\texttt{extraData}$.
+
     </li>
     <li>
-$T:(t_1,...,t_n)$ indicates a tuple $(t_1,...,t_n)$ that is thereafter referred
-to as $T$.
+$\mathtt{ommersHash}$: Must be equal to the Keccak hash of the RLP encoding of
+an empty list. That is, $\mathtt{KEC(RLP([]))}$
     </li>
     <li>
-${\pi_m}(T)$ corresponds to the $m$-th element of the tuple $T$ where the
-first element has index 1. For example, ${\pi_2}((t_1,t_2,t_3))$ corresponds to
-$t_2$.
+$\mathtt{beneficiary}$: Must be one the validators for the header under
+validation as computed by $\mathtt{validators(H)}$.
     </li>
     <li>
-$\mathtt{blockHeight}(EB)$ is defined as the height of the Ethereum block
-$EB$.
+$\mathtt{stateRoot}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-$\mathtt{sizeOf}(M)$ indicates the size of the set $M$. That is, 
-$\mathtt{sizeOf}(M)\equiv\lVert{M}\rVert$.
+$\mathtt{transactionsRoot}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-$\mathtt{EthAddressRecover}(H,signature)$ corresponds to the Ethereum address
-whose signature of the hash $H$ corresponds to $signature$.
+$\mathtt{receiptsRoot}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-Each <a>validator</a> $v$ stores its local blockchain in $chain_v$.
+$\mathtt{logsBloom}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-$chain_v[n]$ corresponds to the finalized block with height $n$, while
-$chain_v[n:m]$ corresponds to a sub-chain including all of the finalized blocks
-from height $n$ to height $m$ included.
+$\mathtt{difficulty}$: Must be equal to 1
     </li>
     <li>
-$chain_{EB_v}[n]$ corresponds to the Ethereum block included in the finalized
-block with height $n$, while $chain_{EB_v}[n:m]$ corresponds to a sub-chain
-including all of the Ethereum blocks included in the finalized blocks from
-height $n$ to height $m$ included.
+$\mathtt{number}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-The blockchain height is defined as the height of the last finalized block
-added to the blockchain.
+$\mathtt{gasLimit}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-$\mathtt{validators}(chain_v[0:h-1])$ represents the set of authorized
-<a>validators</a> for instance $h$ of the IBFT-2.0-block-finalization-protocol.
+$\mathtt{gasUsed}$: As per Ethereum Yellow Paper.
     </li>
     <li>
-$\mathtt{n}(chain_v[0:h-1])$ represents the number of <a>validators</a> for
-instance $h$ of the IBFT-2.0-block-finalization-protocol. That is,
-$\mathtt{n}(chain_v[0:h-1])\equiv\mathtt{sizeOf}(\mathtt{validators}(chain_v[0:h-1]))$.
+$\mathtt{timestamp}$: Must be $\ge$ than the timestamp of the parent block
+header + $\mathtt{BLOCK\_PERIOD}$
     </li>
     <li>
-$\mathtt{isValidBlock}(EB,EB_p)$ is defined to be true if and only if block $EB$
-is a valid Ethereum block with parent $EB_p$. For the purpose of this document,
-we consider that $\mathtt{isValidBlock}(EB,EB_p)$ only verifies the following
-fields of the standard Ethereum header:
-
+$\mathtt{extraData}$:
     <ul>
       <li>
-parentHash
-      </li>
-      <li>
-stateRoot
-      </li>
-      <li>
-transactionsRoot
-      </li>
-      <li>
-receiptsRoot
+$\mathtt{extraData.vanityData}$: Any sequence of $\le$ 32 bytes is admitted
       </li>
       <li>
-logsBloom
+$\mathtt{extraData.validatorList}$: Must match the validator list for the header
+under verification as computed by $\mathtt{validators(H)}$
       </li>
       <li>
-number
+$\mathtt{extraData.vote}$:
+      <ul>
+        <li>
+$\mathtt{extraData.vote.recipient}$: Any sequence of 20 bytes is admitted
+        </li>
+        <li>
+$\mathtt{extraData.vote.voteValue}$: Must be either $\mathtt{0x00}$ or $\mathtt{0xFF}$
+        </li>
+      </ul>
       </li>
       <li>
-gasLimit
+$\mathtt{extraData.round}$: Any sequence of 4 bytes is admitted
       </li>
       <li>
-gasUsed. 
+$\mathtt{extraData.commitSeals}$: As described by the pseudocode in ... :
+      <ul>
+        <li>
+All the elements of the $\mathtt{extraData.commitSeals}$ list must be unique
+        </li>
+        <li>
+The number of elements in the $\mathtt{extraData.commitSeals}$ list must be
+equal to $\mathtt{ceil\biggl(\frac{2*len(extraData.validators)}{3}\biggr)}$
+        </li>
+        <li>
+Each element of $\mathtt{extraData.commitSeals}$ must be a signature over the
+block header hash, as calculated by $\mathtt{headerHashForCommitSealCalculation}$
+(defined below) generated by one of the Ethereum addresses listed in
+$\mathtt{extraData.validators}$.
+
+$\mathtt{headerHashForCommitSealCalculation}$ is defined as the Keccak hash over
+the RLP encoding of the RLP encoding of the header with the field
+$\mathtt{commitSeals}$, but not $\mathtt{round}$, removed from the
+$\mathtt{extraData}$ field. More formally, $\mathtt{extraData}$ must be replaced
+with the following $\mathtt{extraDataForBlockHeaderHashCalculationForCommitSeal}$:
+
+$\mathtt{extraDataForBlockHeaderHashCalculationForCommitSeal:[vanityData,\;validatorList,\;vote,\;round]}$
+where the value of $\mathtt{vanityData}$, $\mathtt{validatorList}$,
+$\mathtt{vote}$, and $\mathtt{round}$ must be equal to the values of the
+homonymous fields in $\mathtt{extraData}$.
+        </li>
+      </ul>
       </li>
     </ul>
-
-These fields are verified as specified in the [[Ethereum-Yellow-Paper]]. The
-IBFT 2.0 and IBFT protocol implementations also verify the other fields but in a
-different way than specified in the [[Ethereum-Yellow-Paper]]. How these fields
-are verified is outside of the scope of this document, but it does not affect
-our results. These details will be discussed in a future document describing the
-implementation details of the IBFT 2.0 protocol.
+  </li>
+    <li>
+$\mathtt{mixHash}$: Must be equal to $\mathtt{0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365}$
+    </li>
+    <li>
+$\mathtt{nonce}$: Must be equal to 0.
     </li>
   </ul>
-  
-    </section>
-
-    <section id="starting-stopping-ibft2-protocol">
 
-    <h3>Starting and Stopping the IBFT 2.0 Protocol (Algorithm 1)</h3>
+    </section>
 
-As outlined by Algorithm 1 in Section <a href="#algorithm-pseudocode"></a>, the
-different instances of the IBFT-2.0-block-finalization-protocol are started and
-stopped in the same way that instances are started and stopped in the IBFT
-protocol.
+    <section>
 
-Finalized blocks are delivered to nodes using the standard ETH DEVp2p
-sub-protocol. In the pseudocode we abstract the actual Ethereum sub-protocol and
-model the reception of a finalized block $FB$ with the reception of a 
-<span style="color:darkred">$\langle\mathsf{FINALIZED-BLOCK},FB\rangle$</span>
-message. No such message actually exists in the IBFT 2.0 protocol [[Pantheon]]
-implementation. As per the standard Ethereum sub-protocol, a block can be
-received either using an unsolicited NewBlock message or using the pair of
-messages GetBlockHeaders/BlockHeaders followed by the pair of messages
-GetBlockBodies/BlockBodies [[[Ethereum-Wire-Protocol]]].
+      <h4>Validation Rules for Proposed Blocks</h4>
 
-As described by the $\mathbf{upon}$ block at line 10, when a new finalized block
-is received by a node $v$, $v$ executes the following operations:
+      The validation rules listed here together with the validation rules listed
+      in Section <a href="#common-validation-rules"></a> correspon to the $\texttt{isValid}()$
+      predicate of the pseudocode in Section <a href="#algorithm-pseudocode"></a>
 
-  <ol>
-    <li>
-Verifies if the finalized block received is for the next expected chain height.
-That is, $h_v$.
-    </li>
-    <li>
-If so, it verifies if the finalized block received is a valid finalized block.
-    </li>
     <li>
-If both verifications pass, then:
-    </li>
-    <ol type="a">
-      <li>
-$v$ adds the finalized block to its local blockchain.
-      </li>
-      <li>
-If $v$ is a <a>validator</a> for the current instance of the
-IBFT-2.0-block-finalization-protocol, then $v$ stops that instance.
-      </li>
+$\mathtt{extraData}$:
+    <ul>
       <li>
-$v$ advances the next expected block height, $h_v$, by 1.
+$\mathtt{extraData.commitSeals}$: Must be an empty list $[]$.
       </li>
+    </ul>
+  </li>
+
+    </section>
+
+    <section>
+
+      <h4>Validation Rules for Finalized Blocks</h4>
+
+      The validation rules listed here together with the validation rules listed
+      in Section <a href="#common-validation-rules"></a> correspon to the $isValidFinalisedBlock()$
+      predicate of the pseudocode in Section <a href="#algorithm-pseudocode"></a>
+
+    <li>
+$\mathtt{extraData}$:
+    <ul>
       <li>
-If $v$ is a <a>validator</a> for the IBFT-2.0-block-finalization-protocol
-instance for the new value of $h_v$, then $v$ starts that instance.
+$\mathtt{extraData.commitSeals}$: As described by line 4 of Algorithm 1 in Section <a href="#algorithm-pseudocode"></a>:
+      <ul>
+        <li>
+All the elements of the $\mathtt{extraData.commitSeals}$ list must be unique
+        </li>
+        <li>
+The number of elements in the $\mathtt{extraData.commitSeals}$ list must be
+equal to $\mathtt{ceil\biggl(\frac{2*len(extraData.validators)}{3}\biggr)}$
+        </li>
+        <li>
+Each element of $\mathtt{extraData.commitSeals}$ must be a signature, by one of
+the Ethereum addresses listed in $\mathtt{extraData.validators}$, over the
+following hash:
+$\mathtt{KEC}(\mathtt{RLP}(\mathtt{removeField}(FB{ },\texttt{extraData.commitSeals})))$
+where $FP$ indicates the finalized block to validate.
+        </li>
+      </ul>
       </li>
-    </ol>
-  </ol>
+    </ul>
+  </li>
 
-As described by the function $isValidFinalizationBlock(FB,v)$ at line 3, an 
-IBFT 2.0 finalized block $FB$ is defined valid if and only if all of the
-following conditions are met:
+    </section>
 
-- It contains at least $Quorum(n)\equiv\lceil\frac{2n}{3}\rceil$ different
-commit seals, where $n$ is the number of <a>validators</a> for instance $h$ of
-the IBFT-2.0-block-finalization-protocol. That is,
-$n\equiv\mathbf{n}(chain_v[0:h-1])$.
-- Each commit seal corresponds to the signature of one of the <a>validators</a>
-over the Ethereum block and the round number included in the finalization proof.
+    </section>
 
-Compared to IBFT, the IBFT 2.0 protocol adds the $\mathbf{upon}$ block at line
-19 to address the <a>persistence</a> issue identified in Lemma 6 of
-[[IBFT-Analysis]]. All of the IBFT 2.0-specific messages (that is, the
-<a data-lt="proposal message">Proposal</a>,
-<a data-lt="prepare message">Prepare</a>,
-<a data-lt="commit message">Commit</a>, and
-<a data-lt="round change message">Round Change</a> messages) include the height
-of the IBFT-2.0-block-finalization-protocol instance that they relate to.
+  <section id="message-structures">
 
-When a node $v$ receives one of these messages including a height $h_m$ with
-value $\ge$ than the next expected height $h_v$, if the sender of the message is
-one of the DEVp2p peers of $v$, then $v$ starts asking the peer for finalized
-blocks with height between the $v$'s current height $h_v$ and the height $h_m$
-included in the IBFT 2.0 message received. This is modeled with the transmission
-of a
-<span style="color:darkred">$\langle\mathsf{GET-BLOCKS},h_v,h_m\rangle$</span>
-message. The peer's response to this request is modeled as a
-<span style="color:darkred">$\langle\mathsf{FINALIZE-BLOCK},FB\rangle$</span>
-message.
+  <h2>EBFT Messages</h2>
 
-As stated previously, this is not an exact description of the real messages sent
-by the implementation. It is a modelling of the DEVp2p behavior useful in this
-context for analyzing the protocol. $\mathbf{expectedHeight}_v[v']$ represents
-the blockchain height that node $v$ expects node $v'$ to have. In our modelling
-of the protocol, we use $\mathbf{expectedHeight}_v[v']$ to express that
-Get-Blocks messages are sent only the first time an IBFT 2.0 message with a
-height higher than $h_v$ is received.
+This section defines how the abstract message data structures defined in Section
+<a href="#eea-protocol-specification"></a> are mapped to the concrete message data structures.
 
-    </section>
+All messages MUST be transmitted using the RLPx protocol [[RLPx]].
 
-    <section id="ibft2-block-finalization-protocol">
+For any type of message, the <dfn>signature</dfn> corresponds to the hash over
+the message using the <a>validator</a> private key:
 
-    <h3>The IBFT 2.0-block-finalization-protocol (Algorithm 2)</h3>
+<code>hashForMessageSignature(message) = KEC(concatenate(message.ID, RLP(message.payload)))</code>
 
-This section describes a generic $h$ instance of the
-IBFT-2.0-block-finalization-protocol for a <a>validator</a> $v$, as detailed in
-Algorithm 2 in Section <a href="#algorithm-pseudocode"></a>.
+<section id="EFT sub-protocol messages">
 
-  <p class="note">
-Significant portions of the IBFT-2.0-block-finalization-protocol are similar to
-the IBFT-block-finalization-protocol presented in Section 3 of
-[[IBFT-Analysis]], but for completeness sake, this section describes the full
-IBFT-2.0-block-finalization-protocol. However, for those portions of the
-IBFT-2.0-block-finalization-protocol that are identical or very similar to the
-IBFT-block-finalization-protocol, the description is taken almost verbatim from
-[[IBFT-Analysis]].
-  </p>
-
-As with the IBFT-block-finalization-protocol, the
-IBFT-2.0-block-finalization-protocol is organized in rounds, starting from round
-0, where <a>validators</a> progress to the next round after they suspect that in
-the current round they cannot decide on the block to be included at height $h$
-of the blockchain. Both in Algorithm 2 and in this description, the current
-round for the $h$-th instance of the IBFT-2.0-block-finalization-protocol for
-<a>validator</a> $v$ is denoted as $r_{h,v}$.
+  <h3>EFT Sub-Protocol</h3>
 
-For each round, one of the <a>validators</a> is selected to play the role of
-block proposer. The selection is operated by the evaluation of
-$\mathbf{proposer}(chain_v[0:h-1],r_{h,v})$ where
-$\mathbf{proposer}(\cdotp,\cdotp)$ is a deterministic function of the chain of
-blocks from the genesis block until the block with height $h-1$ and the current
-round number.
+<p>  EBFT clients must advertise the $\texttt{EFT}$ capability version 0 via the RLPx Hello
+  message [[RLPx]].
+</p>
+<p>  All messages included in this section MUST be part of the $\texttt{EFT}$ capability.
+</p>
+    <section id="proposal-message">
 
-The pseudocode at lines 2 to 4 introduces the following macros:
+    <h4>Proposal Message</h4>
 
-- $n_{h,v}$ - The number of <a>validators</a> for the $h$-th instance of the
-IBFT-2.0-block-finalization-protocol for <a>validator</a> $v$.
-- $\mathbf{validators}_{h,v}$ - The <a>validators</a> for the $h$-th instance of
-the IBFT-2.0-block-finalization-protocol for <a>validator</a> $v$.
-- $\mathbf{proposer}_{h,v}(r_{h,v})$ - The proposer for round $r_{h,v}$ of the
-$h$-th instance of the IBFT-2.0-block-finalization-protocol for <a>validator</a>
-$v$.
+The block <a>proposer</a> MUST send the
+<dfn data-lt="proposal messages|proposal|proposals">Proposal message</dfn> to
+all other <a>validators</a> at the beginning of any round.
 
-These macros are used both in the pseudocode and in this section to simplify the
-notation when describing the $h$-th instance of the
-IBFT-2.0-block-finalization-protocol for <a>validator</a> $v$. The term,
-<em>non-proposing <a>validators</a> for round r and instance h</em>, is used to
-indicate all of the <a>validators</a> for round $r$ and instance $h$ with the
-exclusion of the proposer for round $r$ and instance $h$.
+**Message content**
 
-For the purpose of this document, we do not define the proposer selection
-function, but state that it ensures all of the <a>validators</a> for the $h$-th
-instance of the IBFT-2.0-block-finalization-protocol are selected for any
-sequence of $n_{h,v}$ consecutive rounds. The IBFT 2.0 protocol retains the IBFT
-protocol capability to specify two alternative logics for selecting the proposer
-for round 0:
+The Proposal message contains the following fields:
 
-- Sticky proposer, where the proposer for round 0 corresponds to the proposer of
-the block included in the previous finalized block.
-- Round-robin proposer, where the proposer for round 0 corresponds to the
-proposer of the proposer selection sequence that comes after the proposer of the
-block included in the previous finalized block.
+  - <code>0x00</code> DATA, x? bytes – The message ID for the Proposal message
+type.
+  - <code>payload</code> – A list containing each of the following:
+
+    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block
+being proposed, as an integer.
+    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number, as an
+integer.
+    - <code>digest</code> DATA, 32 bytes – The Keccak hash of the RLP encoding of the
+    proposed block.
+  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the payload.
+  - <code>proposedBlock</code> – The content of the proposed block in Ethereum
+block format.
 
-Compared to IBFT, IBFT 2.0 has no block locking mechanism. The safety of the
-protocol is guaranteed by the round change protocol discussed below, which is
-based on the view change protocol of PBFT [[PBFT]].
+    </section>
 
-As specified by the initialization block (line 9), if $v$ is the selected block
-proposer for the first round, that is, round 0, then $v$ multicasts a <a>Proposal message</a>
-$\langle\langle\mathsf{PROPOSAL},h,0,\mathbf{KEC}(PB)\rangle_{\sigma_v},PB,\bot\rangle$
-to all <a>validators</a> (including itself) that comprises the message
-$\langle\langle\mathsf{PROPOSAL},h,0,\mathbf{KEC}(PB)\rangle_{\sigma_v}$
-signed by $v$, the proposed block $PB$ and a Round-Change-Certificate, which for
-round 0 is empty (that is, $\bot$). More detail on how the
-Round-Change-Certificate is assembled is provided further down in this section
-when discussing how <a>validators</a> move to a different round.
+    <section id="prepare-message">
 
-The proposed block $PB$ is modelled here as a tuple where the first element is a
-standard Ethereum block and the second element is the current round number at
-which the Ethereum block was created, which at initialization is 0.
-$\mathbf{KEC}(\cdotp)$ represents the Keccak hash function. The pseudocode uses
-$\mathbf{createNewProposedBlock}(h,v)$ to represent the creation of a new block
-with height $h$ by <a>validator</a> $v$. Honest <a>validators</a> employee a
-fair transaction selection algorithm to decide which transactions to include in
-the next block. The definition of such algorithm is outside the scope of this
-document.
+    <h4>Prepare Message</h4>
 
-As specified by lines 31 to 32, a <a>validator</a> $v$ accepts a <a>Proposal message</a>
-$\langle\langle\mathsf{PROPOSAL},h_{pp},r_{pp},H\rangle,PB:(EB,r_{EB}),*\rangle$
-if and only if all of the following conditions are met:
+The <dfn data-lt="prepare messages">Prepare message</dfn> MUST be sent when a
+<a>validator</a> that is not the designated block proposer for a round receives
+a <a>Proposal message</a>.
 
-- $v$ is currently running the IBFT-2.0-block-finalization-protocol instance
-$h_{pp}$. That is, $h_{pp}=h$.
-- $v$ is in round 0. That is, $r_{pp}=r_{h,v} = 0$.
-- The signed portion of the message, $\langle\mathsf{PROPOSAL},h_{pp},r_{pp},H\rangle$,
-is signed by the selected proposer for round $r_{h,v} = 0$ and instance $h$ of
-the IBFT-2.0-block-finalization-protocol.
-- $v$ has not already accepted a <a>Proposal message</a> for round $r_{h,v} = 0$
-in the $h$-th instance of the IBFT-block-finalization-protocol. That is,
-$acceptedPB = \bot$.
-- The Ethereum block $EB$ included in the proposed block $PB$ is a valid block
-for height $h$.
-- The round number included in the prepared block $PB$ matches the current round
-number. That is, $r_{h,v} = r_{EB} = 0$.
-- $H$ corresponds to the Keccak hash of the proposed block $PB$.
+**Message content**
 
-When a <a>validator</a> $v$ accepts a <a>Proposal message</a>, it:
+The Prepare message contains the following fields:
 
-- Marks the <a>Proposal message</a> as accepted by setting the state variable
-$acceptedPB$ to the proposed block included in the <a>Proposal message</a> (see
-line 16).
-- Multicasts a <a>Prepare message</a>
-$\langle\mathsf{PREPARE},h,r_{h,v},H\rangle_{\sigma_v}$ (see line 17) to all
-<a>validators</a> (including itself).
+  - <code>0x01</code> DATA, x? bytes – The message ID for the Prepare message
+type.
+  - <code>payload</code> – An array of the following:
 
-The $\mathbf{upon}$ block at line 36 is executed the first time all of the
-following conditions are met by <a>validator</a> $v$:
+    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block
+being prepared, as an integer.
+    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number, as an
+integer.
+    - <code>digest</code> DATA, 32 bytes – The Keccak of the RLP encoding of the prepared
+block.
+  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the payload.
 
-- $v$ has accepted a <a>Proposal message</a> for the proposed block $PB$. That
-is, $acceptedPB_{h,v} = PB$.
-- $v$ has received, from non-proposing <a>validators</a> for the current round,
-at least $Quorum(n_{h,v})-1$ <a>Prepare message</a> for the current instance of
-the IBFT-2.0-block-finalization-protocol, current round, and with digest $H$
-corresponding to the Keccak hash of the accepted proposed block $PB$.
+    </section>
 
-When all of the conditions listed above are met for the first time, then:
+    <section id="commit-message">
 
-- $v$ multicasts a <a>Commit message</a>
-$\langle\mathsf{COMMIT},h,r_{h,v},H,CS(PB,v)\rangle_{\sigma_v}$ to all
-<a>validators</a> (including itself), where $CS(PB,v)$, called
-<em>commit seal</em>, corresponds to the signature of $v$ over the proposed
-block $PB$ and the current round number.
-- $v$ sets $latestPreparedProposedBlock_{h,v}$ to the proposed block $PB$;
-- $v$ sets $latestPC_{h,v}$ to a set including the signed portion of the
-accepted <a>Proposal message</a> and all of the <a>Prepare message</a> sent by
-non-proposing <a>validators</a> for the current round targeting the current
-instance of the IBFT-2.0-block-finalization-protocol, current round and with
-digest $H$ corresponding to the Keccak hash of the accepted proposed block $PB$.
+    <h4>Commit Message</h4>
 
-The pseudocode uses the state variable $commitSent_{h,v}$ to indicate that the
-<a>Commit message</a> is sent only the first time that all of the conditions
-listed above are met. $commitSent_{h,v}$ is set to $true$ at line 39 and reset
-to $false$ in the $StartNewRound$ procedure at line 26. Borrowing from the PBFT
-terminology, when a <a>validator</a> meets the conditions indicated in the
-$\mathbf{upon}$ block at line 36, then $v$ is said to be $prepared$ at round
-$r_{h,v}$. Borrowing again from the PBFT terminology, $latestPC_{h,v}$ is the
-latest Prepared-Certificate and the protocol is designed so that
-$latestPC_{h,v}$ always holds at least the minimum number of messages required
-to prove that $v$ $prepared$ in round $r_{h,v}$ on a proposed block with Keccak
-hash $H$. We say that a Prepared-Certificate is for round $r$ and instance $h$
-if and only if the Prepared-Certificate only includes signed
-<a data-lt="proposal message">Proposal</a> and
-<a data-lt="prepare message">Prepare</a> messages for round $r$ and height $h$.
-$latestPC_{h,v}$ always holds the Prepared-Certificate for the latest round in
-the current instance $h$ where $v$ is $prepared$. $latestPC_{h,v} = \bot$ only
-if $v$ has never $prepared$ in the current instance $h$.
+The <dfn data-lt="commit messages">Commit message</dfn> MUST be sent by a
+<a>validator</a> when <em>enough</em> <a>Prepare messages</a> matching the
+<a>Proposal</a> sent by the designated <a>proposer</a> of the round are
+received.
 
-The $\mathbf{upon}$ block at line 44 is executed the first time all of the
-following conditions are met by <a>validator</a> $v$:
+**Message content**
+
+The Commit message contains the following fields:
+
+  - <code>0x02</code> DATA, x? bytes – The message ID for the Commit message
+type.
+  - <code>payload</code> – An array of one or more of the following:
+
+    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block
+being prepared, as an integer.
+    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number, as an
+integer.
+    - <code>digest</code> DATA, 32 bytes – The Keccak hash of the RLP encoding
+    of the  prepared block.
+    - <code>commitSeal</code> DATA, 32 bytes – The signature of the
+<a>validator</a> over the proposed block included in the <a>Proposal message</a>
+received by the designated proposer of the round.
+  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the payload.
+
+    </section>
+
+    <section id="round-change-message">
+
+    <h4>Round-Change Message</h4>
+
+A <dfn data-lt="round change messages">Round Change message</dfn> MUST be sent
+by a <a>validator</a> when they suspect no agreement on the block to be added to
+the blockchain with the given height will be reached in this round.
+
+**Message content**
 
-- $v$ has accepted a <a>Proposal message</a> for the proposed block $PB$. That
-is, $acceptedPB_{h,v} = PB$.
-- $v$ has received, from at least different $Quorum(n_{h,v})$ <a>validators</a>
-for the current instance of the IBFT-2.0-block-finalization-protocol, a
-<a>Commit message</a> for the current instance of the
-IBFT-2.0-block-finalization-protocol, current round, with digest $H$
-corresponding to the Keccak hash of the accepted proposed block $PB$ and commit
-seal signed by the sender of the <a>Commit message</a>.
+The Round Change message contains the following fields:
 
-When all of the conditions listed above are met for the first time, then:
+  - <code>0x03</code> DATA, x? bytes – The message ID for the Round Change
+message type.
+  - <code>payload</code> – An array of one or more of the following:
 
-- $v$ creates a block finalization proof modelled as a tuple comprising the
-current round number and the commit seals included in all the
-<a>Commit messages</a> that satisfy the condition on <a>Commit messages</a>
-stated above.
-- $v$ creates a finalized block modelled as a tuple comprising the Ethereum
-block included in the proposed block and the finalization proof.
-- $v$ broadcasts the finalized block to all nodes.
+    - <code>height</code> QUANTITY, 8 bytes – The <a>height</a> of the block for
+which the <a>validator</a> is trying to reach agreement, as an integer.
+    - <code>round</code> QUANTITY, 4 bytes – The <a>round</a> number to which
+the <a>validator</a> intends to move to, as an integer.
+    - <code>preparedCertificate</code> DATA – See below.
 
-The pseudocode uses the state variable $finalizedBlockSent_{h,v}$ to trigger the
-transmission of a finalized block only the first time the conditions listed
-above are met. $finalizedBlockSent_{h,v}$ is set at line 50 and reset in the
-$StartNewRound$ procedure at line 12.
+  - <code>signature</code> DATA, 65 bytes – The <a>signature</a> of the
+concatenation of the message ID and the payload.
+  - <code>latestProposedBlock</code> DATA - <code>nil</code> or the content of
+the latest prepared block in Ethereum block format. Should be <code>nil</code>
+if <code>preparedCertificate</code> is <code>nil</code>.
 
-In alignment with PBFT, the IBFT 2.0 protocol relies on a round change
-sub-protocol to detect whether the selected proposer might be Byzantine and
-causing the protocol to never terminate. As specified at lines 21 to 22,
-whenever a <a>validator</a> $v$ starts a new round, it starts a round timer with
-a duration exponential to the round number (see line 8).
+The <code>preparedCertificate</code> might be <code>nil</code> or a list of:
 
-When <a>validator</a> $v$'s round timer for the current round expires (line 51),
-$v$ starts the round $r_{h,v} + 1$ and multicasts a
-$\langle\langle\mathsf{ROUND-CHANGE},h,r_{h,v} + 1,latestPC_{h,v}\rangle,latestPreparedProposedBlock_{h,v}\rangle$
-message for the new round to all <a>validators</a> (including itself). Note that
-the <a>Round Change message</a> includes the latest
-Prepared-Certificate and the proposed block associated with the latest Prepared
-Certificate.
+  - <code>signedPartOfProposalMessage</code> – The payload and signature copied
+from the latest prepared <a>Proposal message</a>.
+  - <code>signedPartOfPrepareMessages</code> – The list of payloads and
+signatures copied from the latest prepared <a>Prepare messages</a>.
 
-The $\mathbf{upon}$ block at line 55 describes under which conditions a
-<a>Proposal message</a> for a new round is multicast and how the
-<a>Proposal message</a> is assembled. Specifically, the
-$\mathbf{upon}$ block is executed only if $v$ has received at least
-$Quorum(n_{h,v})$ <a>Round Change messages</a> for the current
-IBFT-2.0-block-finalization-protocol instance such that:
+If <code>latestProposedBlock</code> is not <code>nil</code>, then the digest of
+<code>signedPartOfProposalMessage</code> and all messages included in
+<code>signedPartOfPrepareMessages</code> should match the Keccak hash of
+<code>proposedBlock</code>.
 
-  <ul>
-    <li>
-All messages are for the same round number $r_{rc}$ and $r_{rc}$ is higher than
-the current round.
-    </li>
-    <li>
-All messages are sent by distinct <a>validators</a> for the current instance of
-the IBFT-2.0-block-finalization-protocol.
-    </li>
-    <li>
-All messages contain a valid Prepared-Certificate. A Prepared-Certificate is
-considered valid either if it is empty ($\bot$) or if it contains one
-<a>Proposal message</a> and at least $Quorum(n_{h,v}) - 1$
-<a>Prepare messages</a> for the same round $r'$ such that:
-    <ul>
-      <li>
-$r'\lt$ than the the round number of the <a>Round Change messages</a>, $r_{rc}$.
-      </li>
-      <li>
-The <a>Proposal message</a> is signed by the selected proposer for round $r'$.
-      </li>
-      <li>
-The <a>Prepare messages</a> are sent by non-proposing validators for the $h$-th
-instance of the IBFT-2.0-block-finalization-protocol and round $r'$ and they are
-all for the current instance $h$ of the IBFT-2.0-block-finalization-protocol,
-round $r'$ and same hash as the one included in the <a>Proposal message</a>.
-      </li>
-    </ul>
-    </li>
-    <li>
-The Keccak hash of the $proposedBlock$ included in each of the
-<a>Round Change messages</a> considered matches the hash included in the
-<a data-lt="proposal message">Proposal</a> and
-<a data-lt="prepare message">Prepare</a> message of the Prepared-Certificate.
-    </li>
-  </ul>
+    </section>
+</section>
 
-Any set meeting these conditions is a valid Round-Change-Certificate for round
-$r'$ where round $r'$ is the round included in all of the
-<a>Round Change messages</a> included in the Round-Change-Certificate. When all
-of the conditions listed above are met, then:
 
-  <ul>
-    <li>
-$v$ moves to the round number included in one of the Round-Change-Certificates
-with the highest round number, lets $RCC$ be the chosen Round-Change-Certificate
-and lets $r_h$ be the round number of $RCC$.
-    </li>
-    <li>
-If $v$ was not already in $r_h$, then $v$ starts the round timer for round $r_h$.
-    </li>
-    <li>
-If $v$ is the selected proposer for round $r_h$, $v$ sends a
-<a>Proposal message</a> for the new round including the selected
-Round-Change-Certificate ($RCC$) and a proposed block calculated as follows:
-    <ul>
-      <li>
-If all of the Prepared-Certificates included in the
-<a>Round Change message</a> are empty, that is $=\bot$, then the proposed block
-must be a tuple including any valid Ethereum block for height $h$ and the
-current round number, which must match the round number of the
-<a>Proposal message</a>.
-      </li>
-      <li>
-Otherwise, the Ethereum block included in the tuple constituting the proposed
-block must match the proposed block received as part of one of the
-<a>Round Change messages</a> including a Prepared-Certificate for the highest
-round amongst the rounds of all the other Prepared-Certificates included in the
-Round-Change-Certificate.
-      </li>
-    </ul>
-    </li>
-  </ul>
 
-As specified by the $\mathbf{upon}$ block at line 71, a <a>Proposal message</a>
-$\langle\langle\mathsf{PROPOSAL},h,r_{pp},H\rangle_{\sigma_{sender}},PB;RCC\rangle$
-for a round higher than 0 is accepted only if all of the following conditions
-are met:
+<section id="ethereum-sub-protocol-messages">
 
-  <ul>
-    <li>
-$v$ is currently running the IBFT-2.0-block-finalization-protocol instance
-$h_{pp}$. That is, $h_{pp}=h$.
-    </li>
-    <li>
-The round number $r_{pp}$ of the <a>Proposal message</a> is either higher than
-the current round or equal to the current round provided that $v$ has not
-accepted any <a>Proposal message</a> for the current round. That is,
-$acceptedPB = \bot$.
-    </li>
-    <li>
-$H$ corresponds to the Keccak hash of the proposed block $PB$.
-    </li>
-    <li>
-The signed portion of the message is signed by the selected proposer for round
-$r_{pp}$ and instance $h$ of the IBFT-2.0-block-finalization-protocol.
-    </li>
-    <li>
-The Round-Change-Certificate $RCC$ includes at least $Quorum(n_{h,v})$
-<a>Round Change messages</a> for round $r_pp$ and height $h$.
-    </li>
-    <li>
-If each of the <a>Round Change messages</a> included in the
-Round-Change-Certificate $RCC$ includes either an invalid Prepared-Certificate
-or an empty Prepared-Certificate, then the:
-    <ul>
-      <li>
-Ethereum block $EB$ included in the proposed block $PB$ must be a valid block
-for height $h$.
-      </li>
-      <li>
-Round number $r_{EB}$ included in the prepared block $PB$ must match the current
-round number. That is, $r_{h,v} = r_{EB}$.
-      </li>
-    </ul>
-    </li>
-    <li>
-Otherwise, the Keccak hash of the tuple composed of the Ethereum block included
-in $PB$ and the highest round number of all Prepared-Certificated included in
-$RCC$ must match the hash included in any of the messages that are part of the
-Prepared-Certificates with the highest round number amongst all of the
-Prepared-Certificates included in the Round-Change-Certificate $RCC$.
-    </li>
-  </ul>
+  <h3>Eth Sub-Protocol Messages</h3>
 
-The effect of accepting a <a>Proposal message</a> for a round $r_{pp} \gt 0$ is
-essentially the same as accepting the <a>Proposal message</a> for round 0 with
-the addition of moving to round $r_{pp}$. Specifically, $v$:
+<p>  This section describes message used by the EBFT protocol whcih are already Included
+  in the $\texttt{eth}$ capability of the RLPx protocol [[RLPx]].
+</p>
+    <section id="finalized-block-message">
 
-  <ul>
-    <li>
-Moves to round $r_{pp}$ and starts the related round timer if $v$ was not
-already in round $r_{pp}$.
-    </li>
-    <li>
-Multicasts a <a>Prepare message</a>
-$\langle\mathsf{PREPARE},h,r_{h,v},H\rangle_{\sigma_v}$ to all validators
-(including itself).
-    </li>
-    <li>
-Sets $acceptedPB_{h,v}$ to the proposed block $PB$ indicating that it
-accepted a <a>Proposal message</a> for $PB$.
-    </li>
-  </ul>
-  
-From here on the protocol proceeds as described above.
+      <h4>Finalized-Block Message</h4>
 
+As mentioned in Section <a href="#eea-protocol-specification"></a>, the abstract
+Finalized-Block message is mapped to the
+messages NewBlock, GetBlockHeaders, BlockHeaders, GetBlockBodies and BlockBodies which are already
+specified by the $\texttt{eth}$ sub-protocol [[Ethereum-Wire-Protocol]].
 
+A Finalized-Block message represents the reception of a finalized block which
+by definition of the standard $\texttt{eth}$ sub-protocol, it can happen either by means of
+an unsolicited NewBlock message or by means of the pair of
+messages GetBlockHeaders/BlockHeaders followed by the pair of messages
+GetBlockBodies/BlockBodies [[Ethereum-Wire-Protocol]].
 
     </section>
-	
-    <section id="algorithm-pseudocode">
 
-    <h3>Algorithm Pseudocode</h3>
+    <section id="get-block-message">
 
-<figure id="fig-algorithm1">
-  <img src="./images/IBFT2_algorithm1.png" alt="Algorithm 1">
-  <figcaption>IBFT 2.0 Protocol for IBFT node $v$ (Algorithm 1)</figcaption>
-</figure>
+      <h4>Get-Block Message</h4>
 
-<figure id="fig-algorithm2">
-  <img src="./images/IBFT2_algorithm2.png" alt="Algorithm 2">
-  <figcaption>The IBFT 2.0-block-finalization-protocol (Algorithm 2)</figcaption>
-</figure>
+The abstract message Get-Block is mapped to the GetBlockHeaders, BlockHeaders, GetBlockBodies and BlockBodies which are already
+specified by the $\texttt{eth}$ sub-protocol [[Ethereum-Wire-Protocol]] as these are
+the messages that allow a node to retreive a block from its peers.
 
     </section>
 
+  </section>
 
   </section>
+  </section>
 
 
   <section id="improvements">
 
   <h2>Improvements</h2>
 
-This section specifies a series of possible improvements to the IBFT 2.0
-protocol, based on analytical review. 
+This section specifies a series of possible improvements to the EBFT
+protocol, based on the analysis performed in the [[IBFT2-Gray-Paper]].
+
+For the reasoning supporting the proposed improvements see Section 5 of the
+[[IBFT2-Gray-Paper]].
 
     <section id="reduce-number-assuptions">
 
@@ -1458,16 +1503,15 @@ <h3>Reduce the Number of Assumptions</h3>
 
       <h4>Remove the Fair Network Behavior Assumption</h4>
 
-**Modification**
-
 To remove the dependency on the robustness proof in the Fair Network Behaviour
-Assumption it is sufficient to require that the proposer selection function for
+Assumption described in Section 4.4 of the [[IBFT2-Gray-Paper]]
+it is sufficient to require that the proposer selection function for
 height $h$ only selects validators that did not propose any of the latest
 $f(n_h)$ blocks where $n_h$ is the number of validators for the block with
 height $h$.
 
 This modification corresponds to replacing the $\mathbf{proposer}(\cdotp,\cdotp)$
-function in the IBFT 2.0-block-finalization-protocol (introduced at line 4) with
+function in the EBFT-block-finalization-protocol (introduced at line 4) with
 the $FairProposer$ function, shown below.
 
 <figure id="fig-algorithm3">
@@ -1475,22 +1519,6 @@ <h4>Remove the Fair Network Behavior Assumption</h4>
   <figcaption>FairProposer (Algorithm 3)</figcaption>
 </figure>
 
-**Justification**
-
-This modification reduces the number of possible proposers for the next block
-from $n_h$ to $n_h - f(n_h)$. This implies that the minimum number of honest
-proposers for the next block is reduced from $n_h - f(n_h)$ to
-$n_h - 2 \cdot f(n_h)$. It is easy to prove that $n_h - 2 \cdot f(n_h) > 0$,
-which means that this modification guarantees that at least one of the possible
-proposers for the next block is honest. This in turn implies that this
-modification does not affect the validity of the Weak-Liveness and Liveness
-properties of the protocol.
-
-For any finalized block $FB$ with height $h$, provided there is no change to the
-validator list in the next $f(n_h)+1$ blocks, since we assume that no more than
-$f(n_h)$ validators are Byzantine, this modification ensures that at least one
-out of the next $f(n_h) + 1$ finalized blocks includes an Ethereum block created
-by an honest validator.
 
       </section>
 
@@ -1505,17 +1533,15 @@ <h3>Reduce Block Finalization Latency</h3>
 
       <section id="reduce-number-of-communication-phases">
 
-      <h4>Reduce the Minimum Number of Communication Phases</h4>
-
-**Modification**
+      <h4>Reduce the Minimum Number of Communication Phases From Three Down to Two</h4>
 
-In the IBFT 2.0 protocol the minimum number of communication phases required to
-finalize a block is three, even if all validators are honest and the message
+In the EBFT protocol the minimum number of communication phases required to
+finalize a block is three, even if all validators happens to be honest and the message
 transmission latency is less than $\frac{\mathbf{timeoutForRoundZero}}{3}$.
-These phases are as follows:
 
+These phases are as follows:
 1. The proposer for round 0 and instance $h$ of the
-IBFT-2.0-block-finalization-protocol sends a
+EBFT-block-finalization-protocol sends a
 <a>Proposal message</a> to all validators.
 2. All validators of height $h$, excluding the proposer for round 0, reply by
 sending a <a>Prepare message</a> to all validators.
@@ -1532,7 +1558,7 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
 follows:
 
 1. The proposer for round 0 and instance $h$ of the
-IBFT-2.0-block-finalization-protocol sends a <a>Proposal message</a> to all
+EBFT-block-finalization-protocol sends a <a>Proposal message</a> to all
 validators.
 2. All validators of height $h$, excluding the proposer for round 0, reply by
 sending a <a>Prepare message</a> to all validators. After a validator for height
@@ -1540,24 +1566,21 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
 0, and $n_h - 1$ <a>Prepare messages</a> from all the non-proposing validators
 for round 0, it creates a finalized block.
 
-Block finalization in only two communication phases can be accomplished only if
-the following conditions are met:
-
-- All validators are honest;
-- The network latency is less than $\frac{\mathbf{timeoutForRoundZero}}{2}$.
-
-Assuming the same latency for the different communication phases, when the
-conditions listed above are met, this modification reduces the block
-finalization latency by 33%. Note that when the conditions listed above are not
-achieved, the protocol degrades back to the performance of the original IBFT 2.0
+Whith this modification, if all validators behave honestly and the network latency
+is less than $\frac{\mathbf{timeoutForRoundZero}}{2}$, then a block is finalized
+with only two communication phases.
+In the case that the conditions listed above are not met, then the protocol
+gracefully degrades back to the performance of the original EBFT
 protocol with no overhead.
 
-This improvement requires the following modifications to the IBFT 2.0 protocol:
+This modification can reduces the block finalization latency by 33%.
+
+This improvement requires the following modifications to the EBFT protocol:
 
   <ul>
     <li>
 If the improvement outlined in Section
-<a href="#remove-commit-seal-from-commit-message"></a> is not applied, then a 
+<a href="#remove-commit-seal-from-commit-message"></a> is not applied, then a
 <em>Prepare seal</em> must be added to the <a>Prepare messages</a>. If the
 improvement applied, the <a>Prepare messages</a> do not need to be modified.
     </li>
@@ -1582,7 +1605,7 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
 received a valid <a>Proposal message</a> for round 0, but it has never prepared,
 then it must include the <a>Proposal message</a> in the
 <a>Round Change message</a>. After the first time a validator prepares while
-running instance $h$ of the IBFT-2.0-block-finalization-protocol, the validator
+running instance $h$ of the EBFT-block-finalization-protocol, the validator
 only includes the latest Prepared-Certificate in any <a>Round Change message</a>
 it sends.
     </li>
@@ -1606,7 +1629,7 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
 
 If the conditions listed above are not met, the Ethereum block to be included in
 a <a>Proposal message</a> with height higher than 0 must be determined as
-specified by the original IBFT 2.0 protocol.
+specified by the original EBFT protocol.
     </li>
     <li>
 On reception of a <a>Proposal message</a> for a round higher than 0, the
@@ -1616,7 +1639,7 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
 
 As described above, this modification allows reducing the minimum number of
 communication phases from three to two for round 0 only. While it is possible to
-modify the IBFT 2.0 protocol to reduce the minimum number of communication
+modify the EBFT protocol to reduce the minimum number of communication
 phases to two for any round, because of the following reasons, this optimisation
 should be applied only to round 0:
 
@@ -1646,33 +1669,6 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
     </li>
   </ul>
 
-**Justification**
-
-Because any valid <a>Proposal message</a> for rounds higher than 0 includes
-$Quorum(n_h)$ <a>Round Change messages</a>, if the Ethereum block $EB$ is 
-finalized in two phases, then at least $Quorum(n_h) - f(n_h)$ of the
-<a>Round Change messages</a> included in the Round-Change-Certificate included
-in the <a>Proposal message</a> for round 1 were sent by honest validators and
-therefore they include the <a>Proposal message</a> received by the proposer of
-round 0. Because $Quorum(n_h) - f(n_h)\;\ge\;f(n_h) + 1$ (quite easy to prove),
-the number of <a>Proposal messages</a> for Ethereum block $EB$ is
-$\ge\;f(n_h) + 1$.
-
-Also, because all honest validators will include the <a>Proposal message</a> for
-the Ethereum block $EB$ in the <a>Round Change message</a> they send for round
-1, and there are at most $f(n_h)$ Byzantine validators, it is impossible that
-there exists another Ethereum block $EB'$, different from $EB$, for which
-$f(n_h) + 1$ <a>Round Change messages</a> including matching
-<a>Proposal messages</a> are sent.
-
-These two considerations imply that the only Ethereum block that a valid
-<a>Proposal message</a> for round 1 can include is $EB$. Because honest
-validators can only prepare on the Ethereum block included in a valid
-<a>Proposal message</a>, the only block that any honest validator can prepare on
-in round 1 is $EB$. Therefore, any <a>Round Change message</a> for round 2 sent
-by honest validators either includes a <a>Proposal message</a> for the Ethereum
-block $EB$, or a Prepared-Certificate for the same Ethereum block $EB$. This
-argument can be generalized to any round by induction on the round number.
 
       </section>
 
@@ -1680,14 +1676,12 @@ <h4>Reduce the Minimum Number of Communication Phases</h4>
 
       <h4>Reduce Latency for Validators</h4>
 
-**Modification**
-
-This improvement reduces the latency for validators to be in the same round long 
+This improvement reduces the latency for validators to be in the same round long
 enough to create a finalized block and requires the following modifications to
-the IBFT 2.0 protocol.
+the EBFT protocol.
 
 When a validator running the $h$-th instance of the
-IBFT-2.0-block-finalization-protocol receives $f(n_h) + 1$
+EBFT-block-finalization-protocol receives $f(n_h) + 1$
 <a>Round Change messages</a> for height $h$ and round number higher than the
 current round number, it:
 
@@ -1696,18 +1690,6 @@ <h4>Reduce Latency for Validators</h4>
 higher than the current one.
 - Sends a <a>Round Change messages</a> for this round number.
 
-**Justification**
-
-Because there are no more than $f(n_h)$ Byzantine validators, if a validator $v$
-receives $f(n_h) + 1$ <a>Round Change messages</a> for height $h$ and round
-number higher than the current round number, then at least one honest validator
-is in a round higher than the current one. Specifically, at least one honest
-validator is in a round equal to or higher than the lowest round number amongst
-the set of $f(n_h) + 1$ <a>Round Change messages</a> received. Therefore moving
-to this round allows validator $v$ to start this higher round sooner than in
-the original IBFT 2.0 protocol. This modification does not effect the
-<a>robustness</a> of the IBFT 2.0 protocol.
-
       </section>
 
     </section>
@@ -1722,8 +1704,6 @@ <h3>Decrease Message Size</h3>
 
       <h4>Replace Round-Change Messages with Hashes of Round Change Messages</h4>
 
-**Modification**
-
 This improvement replaces the <a>Round Change messages</a> in the
 Round-Change-Certificate included in <a>Proposal messages</a> with hashes of the
 <a>Round Change messages</a>. We call the set of hashes of
@@ -1738,10 +1718,10 @@ <h4>Replace Round-Change Messages with Hashes of Round Change Messages</h4>
 the <a>Proposal message</a> and the proposed block field can be moved inside the
 signed portion of the message.
 
-The reason why <a>Proposal messages</a> in the original IBFT 2.0 protocol
+The reason why <a>Proposal messages</a> in the original EBFT protocol
 include the block hash in the signed portion of the message is to reduce the
 size of <a>Proposal messages</a> with a round higher than 0. This because in the
-original IBFT 2.0 protocol a signed <a>Proposal message</a> with enough
+original EBFT protocol a signed <a>Proposal message</a> with enough
 information to match it to a proposed block must be included in
 <a>Proposal messages</a> for rounds higher then 0 as part of the
 Prepared-Certificates included in the Round-Change-Certificate.
@@ -1754,35 +1734,6 @@ <h4>Replace Round-Change Messages with Hashes of Round Change Messages</h4>
 between a signed portion and an unsigned portion and all message fields can be
 moved within the signed portion of the message.
 
-**Justification**
-
-The justification for this modification is based on how the Gossip protocol
-works. Specifically, when a validator receives a message from one of its peers,
-it transmits that message to all other peers. This is similar to how the
-transmission of a message works. That is a message is sent to all peers.
-
-The only difference between the reception and the transmission is that when a
-message is received the message is not transmitted to the peer that sent it
-because that peer already has the message. Therefore, in the IBFT 2.0 protocol,
-when a validator sends a <a>Proposal message</a> for a round higher than 0,
-the <a>Round Change messages</a> included in the Round-Change-Certificate were
-already transmitted to the same peers that the <a>Proposal message</a> will be
-transmitted to. Because a validator sends a <a>Proposal message</a> as soon as
-it receives $Quorum(n_h)$ <a>Round Change messages</a>, the
-<a>Round Change messages</a> included in the <a>Proposal message</a> are
-transmitted to the peers not long before the <a>Proposal message</a> is
-transmitted as well.
-
-Note that the Round-Change-Certificate cannot be removed from the
-<a>Proposal message</a> because validators receiving a <a>Proposal message</a>
-must be able to determine whether any valid block or only a prepared block could
-have been included as the proposed block in the <a>Proposal message</a>. If the
-Round-Change-Certificate is completely removed, the only way for validators to
-validate <a>Proposal messages</a> is to receive a <a>Round Change message</a>
-from each of the $n_h$ validators, which could impair the <a>liveness</a> of the
-protocol because $f(n_h)$ of the validators might be Byzantine and never send a
-<a>Round Change message</a>.
-
       </section>
 
       <section id="remove-commit-seal-from-commit-message">
@@ -1790,12 +1741,11 @@ <h4>Replace Round-Change Messages with Hashes of Round Change Messages</h4>
       <h4>Remove the Commit Seal from the Commit Message and Replace the Commit
 Seals Included in a Block with the Signatures of the Commit Messages Received</h4>
 
-**Modification**
 
 This improvement removes the commit seal from a <a>Commit message</a> and
 replaces the commit seals included in a block with the signatures of the
 <a>Commit messages</a> received. It requires the following modifications to the
-IBFT 2.0 protocol:
+EBFT protocol:
 
 - Remove the commit seal from the <a>Commit message</a>.
 - When composing a finalization proof, collate the signatures of $Quorum(n_h)$
@@ -1806,122 +1756,46 @@ <h4>Remove the Commit Seal from the Commit Message and Replace the Commit
 valid signature of the reconstructed <a>Commit message</a> by one of the
 validators. This can be done using the Elliptic Curve Signature Recovery
 function.
-
-**Justification**
-
-Finalized blocks include all of the information required to reconstruct the body
-of the <a>Commit message</a> sent for that specific block. That is, the block
-height, the round number at which the $Quorum(n_h)$ <a>Commit messages</a> where
-received, and the hash of the block.
-
       </section>
 
       <section id="reduce-number-of-messages-in-prepared-certificates">
 
       <h4>Reduce the Number of Messages Included in Prepared-Certificates</h4>
 
-**Modifications**
-
 This improvement reduces the number of messages included in
 Prepared-Certificates as well as the number of commit seals included in
 finalization proofs to the minimum required to guarantee robustness of the
-protocol. It requires the following modifications to the IBFT 2.0 protocol. For
+protocol. It requires the following modifications to the EBFT protocol. For
 any:
 
 - Prepared-Certificate included in a <a>Round Change messages</a>, include only
 $Quorum(n_h)-1$ <a>Prepare messages</a> for the current round, instance of the
-IBFT-2.0-block-finalization-protocol, and block hash matching the accepted
+EBFT-block-finalization-protocol, and block hash matching the accepted
 <a>Proposal message</a>, even if more <a>Prepare messages</a> with the same
 characteristics were received.
 - Finalization proof, include only $Quorum(n_h)$ commit seals included in valid
 <a>Commit messages</a> for the current round, instance of the
-IBFT-2.0-block-finalization-protocol, and block hash matching the accepted
+EBFT-block-finalization-protocol, and block hash matching the accepted
 Proposal, even if more commit seals included in valid <a>Commit messages</a>
 were received.
 
-**Justification**
-
-All of the received <a>Prepare messages</a> for the current round, instance of
-the IBFT-2.0-block-finalization-protocol, and block hash matching the accepted
-<a>Proposal message</a> are included in a Prepared-Certificate.
-
-Similarly, all of the available commit seals received as part of
-<a>Commit messages</a> for the current round, instance of the
-IBFT-2.0-block-finalization-protocol, and block hash matching the accepted
-<a>Proposal message</a> are included in a finalization proof. 
-
-Analysis in Section 4 of the [[IBFT2-Gray-Paper]] shows that the number of
-messages included in Prepared-Certificates and the number of commit seals
-included in finalization proofs can safely be reduced as indicated without
-affecting the <a>robustness</a> of the protocol.
-
       </section>
 
       <section id="remove-proposal-message-from-prepared-certificate">
 
       <h4>Remove the Proposal Message from the Prepared-Certificate</h4>
 
-**Modification**
-
 The <a>Proposal message</a> included in the Prepared-Certificates can be removed
-without impacting the <a>robustness</a> of the IBFT 2.0 protocol. While this
+without impacting the <a>robustness</a> of the EBFT protocol. While this
 improvement reduces message size only marginally, it simplifies the
 Prepared-Certificate validation logic.
 
-**Justification**
-
-Provided here is a sketch proof to show how this modification does not affect
-the <a>robustness</a> of the IBFT 2.0 protocol. Specifically, we show that
-Lemma 5 in Section 4 of the [[IBFT2-Gray-Paper]], which states "No two
-Prepared-Certificates for the same round and for different block hashes can be
-created", still holds if this improvement is applied.
-
-*Proof.* By contradiction, assume that the Lemma is false and two
-Prepared-Certificates, $PC$ and $PC'$ are created for the same round $r$ but for
-different block hashes, $H$ and $H'$ respectively. There are two cases to
-consider: whether the proposer for round $r$ is honest or Byzantine.
-
-  <dl>
-    <dt>
-The proposer for round $r$ is honest
-    </dt>
-    <dd>
-In each Prepared-Certificate there are at least $Quorum(n_h) - f(n_h) - 1$
-<a>Prepare messages</a> sent by honest validators. It can be verified that this
-number is always higher than 0. Because honest validators send only
-<a>Prepare messages</a> matching the accepted <a>Proposal message</a>, the
-honest validators that sent the <a>Prepare messages</a> included in $PC$ must
-have received a <a>Proposal message</a> for block hash $H$, whereas the honest
-validators that sent the <a>Prepare messages</a> included in $PC'$ must have
-received a <a>Proposal message</a> for block hash $H'$. This contradicts with
-the invariant (deductible from the pseudocode) that honest proposers never send
-different <a>Proposal messages</a> for the same round number.
-    </dd>
-    <dt>
-The proposer for round $r$ is Byzantine
-    </dt>
-    <dd>
-Because the <a>Prepare messages</a> included in Prepared-Certificates are sent
-by non-proposing validators, no more than $f(n_h) - 1$ <a>Prepare messages</a>
-in any Prepared-Certificate are sent by Byzantine validators. Conversely, at
-least $Quorum(n_h) - 1 - (f(n_h) - 1) \equiv Quorum(n_h) - f(n_h)$ of the
-<a>Prepare messages</a> are sent by honest validators. Because any set of
-$Quorum(n_h)$ validators contains at least $Quorum(n_h) - f(n_h)$ honest
-validators, Lemma 1 in Section 4 of the [[IBFT2-Gray-Paper]] implies that the
-intersection of any two sets of $Quorum(n_h) - f(n_h)$ honest validators is not
-empty and therefore includes at least one honest validator. From here the proof
-proceeds like in Lemma 5.
-    </dd>
-  </dl>
-
       </section>
 
       <section id="remove-repeated-message-bodies">
 
       <h4>Remove Repeated Message Bodies from the Prepared-Certificates in a Round Change Message</h4>
 
-**Modification**
-
 This improvement replaces the set of <a data-lt="proposal message">Proposal</a>
 and <a data-lt="prepare message">Prepare</a> messages included in a
 Prepared-Certificate with a set including only the following pieces of
@@ -1950,20 +1824,12 @@ <h4>Remove Repeated Message Bodies from the Prepared-Certificates in a Round Cha
 validators (for the round number included in the modified version of the
 Prepared-Certificate) over the <a>Prepare message</a> body.
 
-**Justification**
-
-The body of all the <a>Prepare messages</a> included in a Prepared-Certificate
-is identical. The body of a <a>Proposal message</a> varies from the body of a
-<a>Prepare message</a> only in the message type.
-
       </section>
 
       <section id="use-aggregate-signature-scheme">
 
       <h4>Use an Aggregate Signature Scheme for the Prepared-Certificate</h4>
 
-**Modification**
-
 The size of the Prepared-Certificate can be further reduced by employing an
 aggregate signature scheme, which allows replacing the $Quorum(n_h) - 1$
 signatures of the <a>Prepare messages</a> with a single signature.
@@ -1981,27 +1847,14 @@ <h3>Improve Message Semantics</h3>
 
       <section id="disregard-round-number">
 
-      <h4>Disregard the Round Number when Computing the Block Hash in IBFT 2.0 Messages</h4>
-
-**Modification**
+      <h4>Disregard the Round Number when Computing the Block Hash in EBFT Messages</h4>
 
 As described in Section <a href="#ibft2-block-finalization-protocol"></a>, the
-block hash included in the IBFT 2.0 messages is calculated over a tuple composed
+block hash included in the EBFT messages is calculated over a tuple composed
 of the Ethereum block and the current round number. This improvement replaces
 this hash with the hash of the Ethereum block only. Note that it is still
 required to include the current round number in the finalization proof.
 
-**Justification**
-
-The purpose of the $h$-th instance of the IBFT-2.0-block-finalization-protocol
-is to decide on the Ethereum block to be added at height $h$. Therefore, using
-[[PBFT]] terminology, the value to be decided by each instance of the
-IBFT-2.0-block-finalization-protocol is the Ethereum block, not the tuple
-composed by the Ethereum block and the current round number. The round number is
-added to the finalization proof exclusively because the finalization proof
-composed of $Quorum(n_h)$ commit seals is valid only if these commit seals were
-included in <a>Commit messages</a> targeting the same round number.
-
       </section>
 
     </section>
@@ -2009,15 +1862,15 @@ <h4>Disregard the Round Number when Computing the Block Hash in IBFT 2.0 Message
     <section id="algorith-pseudocode-with-improvements">
 
     <h3>Algorithm Pseudocode with Improvements</h3>
-	
+
 <figure id="fig-algorithm4">
   <img src="./images/IBFT2_algorithm4.png" alt="Algorithm 4">
-  <figcaption>IBFT 2.0 Protocol for IBFT node $v$ with Improvements (Algorithm 4)</figcaption>
+  <figcaption>EBFT Protocol for EBFT node $v$ with Improvements (Algorithm 4)</figcaption>
 </figure>
 
 <figure id="fig-algorithm5">
   <img src="./images/IBFT2_algorithm5.png" alt="Algorithm 5">
-  <figcaption>The IBFT 2.0-block-finalization-protocol with Improvements (Algorithm 5)</figcaption>
+  <figcaption>The EBFT-block-finalization-protocol with Improvements (Algorithm 5)</figcaption>
 </figure>
 
     </section>
@@ -2155,16 +2008,21 @@ <h3>Changes</h3>
     name: "George Polzer",
     company: "Everymans.ai",
     mailto: "gpolzer@everymans.ai",
-  }],
-  formerEditors: [{
-    name: "Daniel Burnett",
+  },{
+    name: "Roberto Saltini",
     company: "PegaSys",
+    mailto: "roberto.saltini@consensys.net",
     companyURL: "https://pegasys.tech"
   },{
     name: "David Hyland-Wood",
     company: "PegaSys",
     companyURL: "https://pegasys.tech"
   }],
+  formerEditors: [{
+    name: "Daniel Burnett",
+    company: "PegaSys",
+    companyURL: "https://pegasys.tech"
+  }],
   github: "https://github.com/EntEthAlliance/enhanced-bft",
   shortName: "EEASpec",
   copyrightStart: 2019,
@@ -2242,7 +2100,7 @@ <h3>Changes</h3>
     },
     "IBFT2-Gray-Paper": {
       title: "IBFT 2.0 Gray Paper",
-      href: "https://github.com/PegaSysEng/ibft2.x/blob/master/gray_paper/ibft2_gray_paper.pdf",
+      href: "https://member.entethalliance.org/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=c42892a9-7768-4803-897c-5d533c7713ad&forceDialog=0",
       publisher: "Roberto Saltini"
     },
     "RLP": {
@@ -2250,6 +2108,11 @@ <h3>Changes</h3>
       href: "https://github.com/ethereum/wiki/wiki/RLP",
       publisher: "Ethereum Foundation"
     },
+    "RLPx": {
+      title: "The RLPx Transport Protocol",
+      href: "https://github.com/ethereum/devp2p/blob/master/rlpx.md",
+      publisher: "Ethereum Foundation"
+    },
     "Ethereum-Yellow-Paper": {
       title: "Ethereum: A Secure Decentralized Generalized Transaction Ledger",
       href: "https://ethereum.github.io/yellowpaper/paper.pdf",
