From 04678b6089c155c108b05e15cbcaf8626262a06f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 16 Sep 2017 11:39:11 +1000 Subject: [PATCH 001/335] Footnote clarifying meaning of low-order 11 bits --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..ee46bfe6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -353,7 +353,7 @@ \subsubsection{Transaction Receipt} M(O) \equiv \bigvee_{t \in \{O_a\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) \end{equation} -where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence. Formally: +where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence./footnote{11 bits $= 2^2048$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: \begin{eqnarray} M_{3:2048}(\mathbf{x}: \mathbf{x} \in \mathbb{B}) & \equiv & \mathbf{y}: \mathbf{y} \in \mathbb{B}_{256} \quad \text{where:}\\ \mathbf{y} & = & (0, 0, ..., 0) \quad \text{except:}\\ From a12a2d9df62c135d9ebd1c2fc0cdd1f0b291c6aa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 16 Sep 2017 11:42:11 +1000 Subject: [PATCH 002/335] Rewording accumulation of nibbles keys and branches --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..18f88bd6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1315,7 +1315,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} In a manner similar to a radix tree, when the trie is traversed from root to leaf, one may build a single key-value pair. The key is accumulated through the traversal, acquiring a single nibble from each branch node (just as with a radix tree). Unlike a radix tree, in the case of multiple keys sharing the same prefix or in the case of a single key having a unique suffix, two optimising nodes are provided. Thus while traversing, one may potentially acquire multiple nibbles from each of the other two node types, extension and leaf. There are three kinds of nodes in the trie: \begin{description} \item[Leaf] A two-item structure whose first item corresponds to the nibbles in the key not already accounted for by the accumulation of keys and branches traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is required to be $true$. -\item[Extension] A two-item structure whose first item corresponds to a series of nibbles of size greater than one that are shared by at least two distinct keys past the accumulation of nibbles keys and branches as traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is required to be $false$. +\item[Extension] A two-item structure whose first item corresponds to a series of nibbles of size greater than one that are shared by at least two distinct keys past the accumulation of the keys of nibbles and the keys of branches as traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is required to be $false$. \item[Branch] A 17-item structure whose first sixteen items correspond to each of the sixteen possible nibble values for the keys at this point in their traversal. The 17th item is used in the case of this being a terminator node and thus a key being ended at this point in its traversal. \end{description} From 4edf749d13e38551e3327e282c72da583e3c9dfe Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 16 Sep 2017 11:58:49 +1000 Subject: [PATCH 003/335] to proof [sic] that a correct DAG has been used --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..891ab544 100644 --- a/Paper.tex +++ b/Paper.tex @@ -479,7 +479,7 @@ \subsubsection{Block Header Validity} \end{equation} with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. -Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. +Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to prove that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. From 2f0949592e7b90948f098cdedccb94f68adb4aff Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 19 Oct 2017 14:31:11 +1100 Subject: [PATCH 004/335] \textit{Homestead} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..f7cfccec 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1141,7 +1141,7 @@ \section{Conclusion} \label{ch:conclusion} \section{Acknowledgements} -Many thanks to Aeron Buchanan for authoring the Homestead revisions, Christoph Jentzsch for authoring the Ethash algorithm and Yoichi Hirai for doing most of the EIP-150 changes. Important maintenance, useful corrections and suggestions were provided by a number of others from the Ethereum DEV organisation and Ethereum community at large including Gustav Simonsson, Pawe\l{} Bylica, Jutta Steiner, Nick Savers, Viktor Tr\'{o}n, Marko Simovic, Giacomo Tazzari and, of course, Vitalik Buterin. +Many thanks to Aeron Buchanan for authoring the \textit{Homestead} revisions, Christoph Jentzsch for authoring the Ethash algorithm and Yoichi Hirai for doing most of the EIP-150 changes. Important maintenance, useful corrections and suggestions were provided by a number of others from the Ethereum DEV organisation and Ethereum community at large including Gustav Simonsson, Pawe\l{} Bylica, Jutta Steiner, Nick Savers, Viktor Tr\'{o}n, Marko Simovic, Giacomo Tazzari and, of course, Vitalik Buterin. \section{Availability} @@ -1482,7 +1482,7 @@ \section{Fee Schedule}\label{app:fees} $G_{exp}$ & 10 & Partial payment for an {\small EXP} operation. \\ $G_{expbyte}$ & 50 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\small EXP} operation. \\ $G_{memory}$ & 3 & Paid for every additional word when expanding memory. \\ -$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\it Homestead transition}.\\ +$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\\ $G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ $G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \\ $G_{transaction}$ & 21000 & Paid for every transaction. \\ From 837bdd048681a7e1f9ce62bf5ea1736b9a75022f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Dec 2016 19:59:35 +0100 Subject: [PATCH 005/335] EIP155: replay protection --- Paper.tex | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index f6092bb0..eace17dd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1404,7 +1404,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is the `recovery id', a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} @@ -1412,7 +1412,7 @@ \section{Signing Transactions}\label{app:signing} \begin{align} 0 < r &< \mathtt{\tiny secp256k1n} \\ 0 < s &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ -v &\in \{27,28\} +v &\in \{27,28,\mathtt{\tiny chain\_id} \times 2 + 35 , \mathtt{\tiny chain\_id} \times 2 + 36\} \end{align} where: \begin{align} @@ -1425,11 +1425,16 @@ \section{Signing Transactions}\label{app:signing} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} -The message hash, $h(T)$, to be signed is the Keccak hash of the transaction without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$: +The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{i}) & \text{if} \; T_t = 0\\ -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}) & \text{otherwise} +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{if} \; v \notin \{27, 28\}\\ +\end{cases} \\ +\nonumber \text{where} \\ +\nonumber \mathbf{p} & \equiv & \begin{cases} +T_{\mathbf{i}} & \text{if}\ T_t = 0 \\ +T_{\mathbf{d}} & \text{otherwise} \end{cases} \\ h(T) & \equiv & \mathtt{\small KEC}( L_S(T) ) \end{eqnarray} From c9ff18e7312a2fa8e3207c98a9c8f11bfc2ed17f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 25 Apr 2017 17:44:15 +0200 Subject: [PATCH 006/335] Normalizing the input of ECDSARECOVER function --- Paper.tex | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index eace17dd..0f173cb9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1429,7 +1429,7 @@ \section{Signing Transactions}\label{app:signing} \begin{eqnarray} L_S(T) & \equiv & \begin{cases} (T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ -(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{if} \; v \notin \{27, 28\}\\ +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{otherwise}\\ \end{cases} \\ \nonumber \text{where} \\ \nonumber \mathbf{p} & \equiv & \begin{cases} @@ -1446,9 +1446,13 @@ \section{Signing Transactions}\label{app:signing} \end{eqnarray} We may then define the sender function $S$ of the transaction as: -\begin{equation} -S(T) \equiv \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), T_w, T_r, T_s) \big) \big) -\end{equation} +\begin{eqnarray} +S(T) &\equiv& \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), v_0, T_r, T_s) \big) \big) \\ +v_0 &\equiv& \begin{cases} +T_w &\text{if}\ T_w\in\{27, 28\} \\ +28 - (T_w \bmod 2) &\text{otherwise} +\end{cases} +\end{eqnarray} The assertion that the sender of a signed transaction equals the address of the signer should be self-evident: \begin{equation} From db78ad41e27f35a9d9eaec581086c6721cac8af2 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 17:48:43 +0200 Subject: [PATCH 007/335] Remove spurious spaces --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 0f173cb9..f3b5ba1c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1404,7 +1404,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} @@ -1412,7 +1412,7 @@ \section{Signing Transactions}\label{app:signing} \begin{align} 0 < r &< \mathtt{\tiny secp256k1n} \\ 0 < s &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ -v &\in \{27,28,\mathtt{\tiny chain\_id} \times 2 + 35 , \mathtt{\tiny chain\_id} \times 2 + 36\} +v &\in \{27,28,\mathtt{\tiny chain\_id} \times 2 + 35, \mathtt{\tiny chain\_id} \times 2 + 36\} \end{align} where: \begin{align} @@ -1425,7 +1425,7 @@ \section{Signing Transactions}\label{app:signing} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} -The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: +The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} (T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ From b0a29defd89d2e163dde31d6081dfbdc1a0674ca Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 11:05:02 +0200 Subject: [PATCH 008/335] Add spaces --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index f3b5ba1c..3b4987df 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1404,7 +1404,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier $\mathtt{\tiny chain\_id}$ is a constant natural number. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} @@ -1428,8 +1428,8 @@ \section{Signing Transactions}\label{app:signing} The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} -(T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ -(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{otherwise}\\ +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\} \\ +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{otherwise} \\ \end{cases} \\ \nonumber \text{where} \\ \nonumber \mathbf{p} & \equiv & \begin{cases} From 55a76c84d264e4836d0a542a3b84ededc18cc5f8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 10:36:01 +1100 Subject: [PATCH 009/335] Add Davey2002_zbMATH01748069 --- Biblio.bib | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index f3c0ee9c..b22cb66d 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,3 +1,16 @@ +@Book{Davey2002_zbMATH01748069, + Author = {B.A. {Davey} and H.A. {Priestley}}, + Title = {{Introduction to lattices and order. 2nd ed.}}, + Edition = {2nd ed.}, + ISBN = {0-521-78451-4/pbk}, + Pages = {xii + 298}, + Year = {2002}, + Publisher = {Cambridge: Cambridge University Press}, + Language = {English}, + MSC2010 = {06-01}, + Zbl = {1002.06001}, +} + @Misc{cryptoeprint:2013:881, Note = {{http://eprint.iacr.org/}}, Url = {{Cryptology ePrint Archive, Report 2013/881}}, @@ -141,4 +154,4 @@ @article{FowlerNollVo1991FNVHash author = {Glenn Fowler, Landon Curt Noll, Phong Vo}, title = {{Fowler–Noll–Vo hash function}}, year = {{1991}}, -} \ No newline at end of file +} From 10036bf0b178b3069941f3de2c5f048b638df5e9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 10:38:30 +1100 Subject: [PATCH 010/335] \section{List of mathematical symbols} \bigvee --- Paper.tex | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..dbf1f657 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2211,4 +2211,14 @@ \subsection{Proof-of-work function} \end{cases} \end{equation} +\section{List of mathematical symbols}\label{app:symbols} +\begin{tabularx}{\textwidth}{lcX} +\toprule +Symbol & Latex Command & Description \\ +\midrule +\hypertarget{bigvee}{ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{zbMATH01748069}).}\\ +\bottomrule +\end{tabularx} + \end{document} From 16d5510f4d516698dcab82d35df665e03735d236 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 10:39:06 +1100 Subject: [PATCH 011/335] \cite{Davey2002_zbMATH01748069} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index dbf1f657..fceee8c1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2217,7 +2217,7 @@ \section{List of mathematical symbols}\label{app:symbols} Symbol & Latex Command & Description \\ \midrule \hypertarget{bigvee}{ -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{zbMATH01748069}).}\\ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).}\\ \bottomrule \end{tabularx} From b4b344520af8fb1ed51a8f39a6ecd42d5d78ad3a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:02:09 +1100 Subject: [PATCH 012/335] Options for hyperref, and \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} --- Paper.tex | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..2c7aa34a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1,6 +1,5 @@ \documentclass[9pt,oneside]{amsart} %\usepackage{tweaklist} -\usepackage{url} \usepackage{cancel} \usepackage{xspace} \usepackage{graphicx} @@ -20,6 +19,15 @@ \usepackage[usenames,dvipsnames]{xcolor} \usepackage{afterpage} \usepackage{tikz} +\usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} +%,pagebackref=true + +% I will insert other table packages in here after this is merged. + +%This should be the last package before \input{Version.tex} +\PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} +% "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . +% Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . \input{Version.tex} From 424455edca424e0ef6c6e0cf4dd8f9f6e4e977dc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:07:58 +1100 Subject: [PATCH 013/335] Prepend a hash with a backslash to pass hyperref --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2c7aa34a..1cf93218 100644 --- a/Paper.tex +++ b/Paper.tex @@ -298,7 +298,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} From f132070f3a179aed09a5a9fb557a42fc8a06d0da Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:25:51 +1100 Subject: [PATCH 014/335] Formatting packages --- Paper.tex | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..393504ba 100644 --- a/Paper.tex +++ b/Paper.tex @@ -21,6 +21,14 @@ \usepackage{afterpage} \usepackage{tikz} +% For formatting +%\usepackage{underscore} +%\usepackage{lipsum} % to generate filler text for testing of document rendering +\usepackage[english]{babel} +\usepackage[autostyle]{csquotes} +\MakeOuterQuote{"} +% Put before hyperref + \input{Version.tex} \newcommand{\hcancel}[1]{% From 27a0001b5450203572bcf44b8540ca43f5b24071 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:42:55 +1100 Subject: [PATCH 015/335] May as well comment out \lightpink if it's unused for performance reasons --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..d143f480 100644 --- a/Paper.tex +++ b/Paper.tex @@ -31,7 +31,7 @@ }% \definecolor{lightyellow}{rgb}{1,0.98,0.9} -\definecolor{lightpink}{rgb}{1,0.94,0.95} +%\definecolor{lightpink}{rgb}{1,0.94,0.95} \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} From 4915aeb56bc365fda8a084eccce17b2ab3e8fde6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:45:21 +1100 Subject: [PATCH 016/335] not the least being Bitcoin --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..edfe21ec 100644 --- a/Paper.tex +++ b/Paper.tex @@ -51,7 +51,7 @@ %\pagecolor{lightpink} \begin{abstract} -The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not least Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. +The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not the least being Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. Ethereum implements this paradigm in a generalised manner. Furthermore it provides a plurality of such resources, each with a distinct state and operating code but able to interact through a message-passing framework with others. We discuss its design, implementation issues, the opportunities it provides and the future hurdles we envisage. \end{abstract} From 52f0b1d7607e04227e98b2aa9e143e551d95cdcf Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 15:39:33 +0100 Subject: [PATCH 017/335] Add a new element I_w in the input tuple I --- Paper.tex | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 5a3450f1..990ce1cb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -675,7 +675,8 @@ \section{Contract Creation} \label{ch:create} I_s & \equiv & s \\ I_v & \equiv & v \\ I_\mathbf{b} & \equiv & \mathbf{i} \\ -I_e & \equiv & e +I_e & \equiv & e \\ +I_w & \equiv & \top \end{eqnarray} $I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_H$ has no special treatment and is determined from the blockchain. @@ -770,6 +771,7 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ +I_w & \equiv & \top \\ \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} @@ -815,6 +817,7 @@ \subsection{Execution Environment} \item $I_\mathbf{b}$, the byte array that is the machine code to be executed. \item $I_H$, the block header of the present block. \item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item $I_w$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: From 219dd8cbf2cda383d2e54923f4442a11c1914111 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 15:45:26 +0100 Subject: [PATCH 018/335] Add a "write permission" argument to Theta --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 990ce1cb..693292d8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -585,7 +585,7 @@ \subsection{Execution} \begin{equation} (\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} \Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0) & \text{if} \quad T_t = \varnothing \\ -\Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0) & \text{otherwise} +\Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -720,7 +720,7 @@ \section{Message Call} \label{ch:call} Aside from evaluating to a new state and transaction substate, message calls also have an extra component---the output data denoted by the byte array $\mathbf{o}$. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e) +(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) \end{equation} Note that we need to differentiate between the value that is to be transferred, $v$, from the value apparent in the execution context, $\tilde{v}$, for the {\small DELEGATECALL} instruction. @@ -771,7 +771,7 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ -I_w & \equiv & \top \\ +I_w & \equiv & w \\ \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} @@ -1951,7 +1951,7 @@ \subsection{Instruction Set} \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[3] \dots (\boldsymbol{\mu}_\mathbf{s}[3] + \boldsymbol{\mu}_\mathbf{s}[4] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ &&&& $\boldsymbol{\mu}'_g \equiv \boldsymbol{\mu}_g + g'$ \\ @@ -1985,7 +1985,7 @@ \subsection{Instruction Set} \midrule 0xf2 & {\small CALLCODE} & 7 & 1 & Message-call into this account with an alternative account's code. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ &&&& same account as at present, simply that the code is overwritten.\\ @@ -2005,7 +2005,7 @@ \subsection{Instruction Set} &&&& argument is $\boldsymbol{\mu}_\mathbf{s}[2]$. As a result, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ in the definition of {\small CALL} \\ &&&& should respectively be replaced with $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& Otherwise exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_s, I_o, I_a, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_p, 0, I_v, \mathbf{i}, I_e + 1)\end{array} & \text{if} \quad I_v \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_s, I_o, I_a, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_p, 0, I_v, \mathbf{i}, I_e + 1, I_w)\end{array} & \text{if} \quad I_v \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the changes (in addition to that of the fourth parameter) to the second \\ &&&& and ninth parameters to the call $\Theta$.\\ &&&& This means that the recipient is in fact the same account as at present, simply\\ From acf26e6968d8da969744c8192a8eec15646ad594 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 16:06:11 +0100 Subject: [PATCH 019/335] Add "write permission" argument to \Lambda function --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 693292d8..57cbf914 100644 --- a/Paper.tex +++ b/Paper.tex @@ -584,7 +584,7 @@ \subsection{Execution} Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$ and substate $A$: \begin{equation} (\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} -\Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0) & \text{if} \quad T_t = \varnothing \\ +\Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ \Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -632,7 +632,7 @@ \section{Contract Creation} \label{ch:create} We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas and accrued transaction substate $(\boldsymbol{\sigma}', g', A)$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e) +(\boldsymbol{\sigma}', g', A) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -676,7 +676,7 @@ \section{Contract Creation} \label{ch:create} I_v & \equiv & v \\ I_\mathbf{b} & \equiv & \mathbf{i} \\ I_e & \equiv & e \\ -I_w & \equiv & \top +I_w & \equiv & w \end{eqnarray} $I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_H$ has no special treatment and is determined from the blockchain. @@ -1937,7 +1937,7 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ From fd9973dd4e6ead3dd6d78014207ec5316b5d5015 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 16:35:50 +0100 Subject: [PATCH 020/335] Add an exceptional halt for state changes during static calls --- Paper.tex | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 57cbf914..97086425 100644 --- a/Paper.tex +++ b/Paper.tex @@ -887,11 +887,22 @@ \subsubsection{Exceptional Halting} \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ ( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ -\lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad + \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ + \neg I_w \wedge W(w, \boldsymbol{\mu}) +\end{array} +\end{equation} +where +\begin{equation} +W(w, \boldsymbol{\mu}) \equiv +\begin{array}[t]{l} +w \in \{\text{\small CREATE}, \text{\small SSTORE}, \text{\small SELFDESTRUCT}\} \quad \vee \\ +\text{\small LOG0} \le w \wedge w \le \text{\small LOG4} \quad \vee \\ +w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge +\boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \end{array} \end{equation} -This states that the execution is in an exceptional halting state if there is insufficient gas, if the instruction is invalid (and therefore its $\delta$ subscript is undefined), if there are insufficient stack items, if a {\small JUMP}/{\small JUMPI} destination is invalid or the new stack size would be larger than 1024. The astute reader will realise that this implies that no instruction can, through its execution, cause an exceptional halt. +This states that the execution is in an exceptional halting state if there is insufficient gas, if the instruction is invalid (and therefore its $\delta$ subscript is undefined), if there are insufficient stack items, if a {\small JUMP}/{\small JUMPI} destination is invalid, the new stack size would be larger than 1024 or state modification is attempted during a static call. The astute reader will realise that this implies that no instruction can, through its execution, cause an exceptional halt. \subsubsection{Jump Destination Validity} From 7a491361f2360e0646d000f7501adeadd5c0083c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 17:54:22 +0100 Subject: [PATCH 021/335] Specify STATICCALL --- Paper.tex | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Paper.tex b/Paper.tex index 97086425..f740a54d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2022,6 +2022,14 @@ \subsection{Instruction Set} &&&& This means that the recipient is in fact the same account as at present, simply\\ &&&& that the code is overwritten {\it and} the context is almost entirely identical.\\ \midrule +0xfa & {\small STATICCALL} & 6 & 1 & Static message-call into an account. \\ +&&&& Exactly equivalent to {\small CALL} except: \\ +&&&& The argument $\boldsymbol{\mu}_\mathbf{s}[2]$ is replaced with $0$. \\ +&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and + $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ +&&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ +&&&& The last argument of $\Theta$ is $\bot$. \\ +\midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ From 85042b8c5add6be9cb757279d8c5231d465304ae Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 15:40:05 +0200 Subject: [PATCH 022/335] Adjust white spaces --- Paper.tex | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index f740a54d..86886ec5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -893,12 +893,10 @@ \subsubsection{Exceptional Halting} \end{equation} where \begin{equation} -W(w, \boldsymbol{\mu}) \equiv -\begin{array}[t]{l} +W(w, \boldsymbol{\mu}) \equiv \begin{array}[t]{l} w \in \{\text{\small CREATE}, \text{\small SSTORE}, \text{\small SELFDESTRUCT}\} \quad \vee \\ \text{\small LOG0} \le w \wedge w \le \text{\small LOG4} \quad \vee \\ -w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge -\boldsymbol{\mu}_\mathbf{s}[2] \neq 0 +w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \end{array} \end{equation} @@ -2025,8 +2023,7 @@ \subsection{Instruction Set} 0xfa & {\small STATICCALL} & 6 & 1 & Static message-call into an account. \\ &&&& Exactly equivalent to {\small CALL} except: \\ &&&& The argument $\boldsymbol{\mu}_\mathbf{s}[2]$ is replaced with $0$. \\ -&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and - $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ +&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ \midrule From 1c655cf9cbeebf1981136e29cd9b3caef2d2d377 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 16:48:27 +0100 Subject: [PATCH 023/335] EIP161a: change the initial nonce of an account --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3b4987df..beaa4cd7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -642,12 +642,12 @@ \section{Contract Creation} \label{ch:create} where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$ and $\boldsymbol{\sigma}[x]$ is the address state of $x$ or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. -The account's nonce is initially defined as zero, the balance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender's balance is also reduced by the value passed. Thus the mutated state becomes $\boldsymbol{\sigma}^*$: +The account's nonce is initially defined as one, the balance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender's balance is also reduced by the value passed. Thus the mutated state becomes $\boldsymbol{\sigma}^*$: \begin{equation} \boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except:} \end{equation} \begin{eqnarray} -\boldsymbol{\sigma}^*[a] &\equiv& \big( 0, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[a] &\equiv& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ \boldsymbol{\sigma}^*[s]_b &\equiv& \boldsymbol{\sigma}[s]_b - v \end{eqnarray} From 405cac4e48c2f5f0f2f7f71bf2139e44fc70eb2c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:06:08 +0100 Subject: [PATCH 024/335] EIP 161: Define when an account state is empty --- Paper.tex | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Paper.tex b/Paper.tex index beaa4cd7..424ab7bb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -233,6 +233,11 @@ \subsection{World State} \label{ch:state} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} +An account is \textit{empty} when it has no code, zero nonce and zero balance: +\begin{equation} +\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 +\end{equation} + \subsection{The Transaction} \label{ch:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: From 0d26ae7b85a813ccdb8b66387b9f4a9c352b440b Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:10:35 +0100 Subject: [PATCH 025/335] EIP 161: Define when an account is dead --- Paper.tex | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Paper.tex b/Paper.tex index 424ab7bb..313f6910 100644 --- a/Paper.tex +++ b/Paper.tex @@ -238,6 +238,11 @@ \subsection{World State} \label{ch:state} \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} +An account is \textit{dead} when its account state is non-existent or empty: +\begin{equation} +\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) +\end{equation} + \subsection{The Transaction} \label{ch:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: From 3ee54d98378e309abcdbdd4aeea3cece93d3d38e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:25:39 +0100 Subject: [PATCH 026/335] EIP161b: CALL and SUICIDE gas change --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 313f6910..019499a4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1995,7 +1995,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma},\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule @@ -2038,7 +2038,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} -G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] = \varnothing \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \bottomrule From 616e3aef1c45ef86c072551b3ff58d8caa35f277 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 19:15:21 +0100 Subject: [PATCH 027/335] EIP161.c --- Paper.tex | 47 ++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 38 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index 019499a4..095ce1a8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -625,7 +625,8 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that appear in the self-destruct set: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \\ +\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} And finally, we specify $\Upsilon^g$, the total gas used in this transaction and $\Upsilon^\mathbf{l}$, the logs created by this transaction: @@ -658,7 +659,11 @@ \section{Contract Creation} \label{ch:create} \end{equation} \begin{eqnarray} \boldsymbol{\sigma}^*[a] &\equiv& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ -\boldsymbol{\sigma}^*[s]_b &\equiv& \boldsymbol{\sigma}[s]_b - v +\boldsymbol{\sigma}^*[s] &\equiv& \begin{cases} +\varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ +\mathbf{a}^* & \text{otherwise} +\end{cases} \\ +\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_n, \boldsymbol{\sigma}[s]_b - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_c) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: @@ -711,6 +716,8 @@ \section{Contract Creation} \label{ch:create} \quad \boldsymbol{\sigma}' &\equiv \begin{cases} \boldsymbol{\sigma} & \text{if} \quad F \\ \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ +\quad\boldsymbol{\sigma}'[a] = \varnothing & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^{**}, a) \\ +\boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ \nonumber \text{where} \\ @@ -744,17 +751,27 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma}_1 \equiv \boldsymbol{\sigma}_1' \quad \text{except:} \\ \end{equation} \begin{equation} -\boldsymbol{\sigma}_1[s]_b \equiv \boldsymbol{\sigma}_1'[s]_b - v +\boldsymbol{\sigma}_1[s] \equiv \begin{cases} +\varnothing & \text{if}\ \boldsymbol{\sigma}_1'[s] = \varnothing \ \wedge\ v = 0 \\ +\mathbf{a}_1 &\text{otherwise} +\end{cases} +\end{equation} +\begin{equation} +\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_n, \boldsymbol{\sigma}_1'[s]_b - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_c) \end{equation} \begin{equation} \text{and}\quad \boldsymbol{\sigma}_1' \equiv \boldsymbol{\sigma} \quad \text{except:} \\ \end{equation} \begin{equation} \begin{cases} -\boldsymbol{\sigma}_1'[r] \equiv (0, v, \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}(())) & \text{if} \quad \boldsymbol{\sigma}[r] = \varnothing \\ -\boldsymbol{\sigma}_1'[r]_b \equiv \boldsymbol{\sigma}[r]_b + v & \text{otherwise} +\boldsymbol{\sigma}_1'[r] \equiv (0, v, \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}(())) & \text{if} \quad \boldsymbol{\sigma}[r] = \varnothing \wedge v \neq 0 \\ +\boldsymbol{\sigma}_1'[r] \equiv \varnothing & \text{if}\quad \boldsymbol{\sigma}[r] = \varnothing \wedge v = 0 \\ +\boldsymbol{\sigma}_1'[r] \equiv \mathbf{a}_1' & \text{otherwise} \end{cases} \end{equation} +\begin{equation} +\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) +\end{equation} The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). @@ -1029,10 +1046,16 @@ \subsection{Reward Application} The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: \begin{eqnarray} +\\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ \boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ \forall_{U \in B_\mathbf{U}}: \\ \nonumber - \boldsymbol{\sigma}'[U_c]_b & = & \boldsymbol{\sigma}[U_c]_b + (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b +\boldsymbol{\sigma}'[U_c] & = & \begin{cases} +\varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ +\mathbf{a}' &\text{otherwise} +\end{cases} \\ +\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_c]_n, \boldsymbol{\sigma}[U_c]_b + R, \boldsymbol{\sigma}[U_c]_\mathbf{s}, \boldsymbol{\sigma}[U_c]_c) \\ +R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. @@ -2031,16 +2054,22 @@ \subsection{Instruction Set} \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ &&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ -&&&& $\boldsymbol{\sigma}'[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_b \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_b + \boldsymbol{\sigma}[I_a]_b$ \\ -&&&& $\boldsymbol{\sigma}'[I_a]_b \equiv 0$ \\ +&&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} +\varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_a]_b = 0\\ +(\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + \boldsymbol{\sigma}[I_a]_b, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{if}\ r \neq I_a \\ +(\boldsymbol{\sigma}[r]_n, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{otherwise} +\end{cases}$\\ +&&&& where $r = \boldsymbol{\mu}_\mathbf{s}[0] \bmod 2^{160}$\\ +&&&& $\boldsymbol{\sigma}'[I_a]_b = 0$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} -G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0 \\ +G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0$ \\ \bottomrule \end{tabular*} From 0aed5a9d20d70a3fb78e66c5991c5b1d10ce47e3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 21:45:34 +0100 Subject: [PATCH 028/335] EIP 161: Keep the touched accounts in the substate --- Paper.tex | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/Paper.tex b/Paper.tex index 095ce1a8..ba990f64 100644 --- a/Paper.tex +++ b/Paper.tex @@ -541,14 +541,14 @@ \section{Transaction Execution} \label{ch:transactions} \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} -A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_r) +A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) \end{equation} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. -For brevity, we define the empty substate $A^0$ to have no self-destructs, no logs and a zero refund balance: +We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} -A^0 \equiv (\varnothing, (), 0) +A^0 \equiv (\varnothing, (), \{\}, 0) \end{equation} \subsection{Execution} @@ -679,7 +679,7 @@ \section{Contract Creation} \label{ch:create} Finally, the account is initialised through the execution of the initialising EVM code $\mathbf{i}$ according to the execution model (see section \ref{ch:model}). Code execution can effect several events that are not internal to the execution state: the account's storage can be altered, further accounts can be created and further message calls can be made. As such, the code execution function $\Xi$ evaluates to a tuple of the resultant state $\boldsymbol{\sigma}^{**}$, available gas remaining $g^{**}$, the accrued substate $A$ and the body code of the account $\mathbf{o}$. \begin{equation} -(\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I) \\ +(\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: \begin{eqnarray} @@ -785,11 +785,11 @@ \section{Message Call} \label{ch:call} g^{**} & \text{otherwise} \end{cases} \\ \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} -\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 1 \\ -\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 2 \\ -\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 3 \\ -\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 4 \\ -\Xi(\boldsymbol{\sigma}_1, g, I) & \text{otherwise} \end{cases} \\ +\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 1 \\ +\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 2 \\ +\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 3 \\ +\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 4 \\ +\Xi(\boldsymbol{\sigma}_1, g, I, T) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ I_p & \equiv & p \\ @@ -797,6 +797,7 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ +T & \equiv & \{s, r\} \\ \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} @@ -849,10 +850,10 @@ \subsection{Execution Environment} (\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) \end{equation} -where we will remember that $A$, the accrued substate is defined as the tuple of the suicides set $\mathbf{s}$, the log series $\mathbf{l}$ and the refunds $r$: +where we will remember that $A$, the accrued substate is defined as the tuple of the suicides set $\mathbf{s}$, the log series $\mathbf{l}$, the touched accounts $\mathbf{t}$ and the refunds $r$: \begin{equation} -A \equiv (\mathbf{s}, \mathbf{l}, r) +A \equiv (\mathbf{s}, \mathbf{l}, \mathbf{t}, r) \end{equation} \subsection{Execution Overview} @@ -861,7 +862,7 @@ \subsection{Execution Overview} The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} -\Xi(\boldsymbol{\sigma}, g, I) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ +\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ (\boldsymbol{\sigma}, \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ \boldsymbol{\mu}_g & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ @@ -1376,7 +1377,7 @@ \section{Precompiled Contracts}\label{app:precompiled} For each precompiled contract, we make use of a template function, $\Xi_{\mathtt{PRE}}$, which implements the out-of-gas checking. \begin{equation} -\Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I) \equiv \begin{cases} +\Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} (\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ (\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} \end{equation} @@ -1978,7 +1979,8 @@ \subsection{Instruction Set} &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ &&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ -&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ +&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ +&&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ &&&& $Z(\boldsymbol{\sigma}^*, \boldsymbol{\mu}, I) = \top$ or $I_e = 1024$ \\ From e5d5f4095117b44b7555ded25f31ae5c1f377634 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 6 Dec 2016 10:19:56 +0100 Subject: [PATCH 029/335] EIP161.d empty, touched accounts are deleted at the end of a transaction --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba990f64..b55caf08 100644 --- a/Paper.tex +++ b/Paper.tex @@ -622,7 +622,7 @@ \subsection{Execution} m & \equiv & {B_H}_c \end{eqnarray} -The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that appear in the self-destruct set: +The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ \forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \\ From 095faa5e991078adc904d9dd50a792d8f153eb00 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 9 Dec 2016 12:30:37 +0100 Subject: [PATCH 030/335] EIP 161: Improve local layouts --- Paper.tex | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index b55caf08..0e6eab60 100644 --- a/Paper.tex +++ b/Paper.tex @@ -235,12 +235,12 @@ \subsection{World State} \label{ch:state} An account is \textit{empty} when it has no code, zero nonce and zero balance: \begin{equation} -\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 +\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} An account is \textit{dead} when its account state is non-existent or empty: \begin{equation} -\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) +\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} \subsection{The Transaction} \label{ch:transaction} @@ -783,13 +783,13 @@ \section{Message Call} \label{ch:call} g' & \equiv & \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ g^{**} & \text{otherwise} -\end{cases} \\ +\end{cases} \\ \nonumber \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} -\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 1 \\ -\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 2 \\ -\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 3 \\ -\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 4 \\ -\Xi(\boldsymbol{\sigma}_1, g, I, T) & \text{otherwise} \end{cases} \\ +\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 1 \\ +\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 2 \\ +\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ +\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ +\Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ I_p & \equiv & p \\ @@ -797,7 +797,8 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ -T & \equiv & \{s, r\} \\ +\mathbf{t} & \equiv & \{s, r\} \\ +\\ \nonumber \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} From eef3de9f0b2891158462205f9620bd62edec0839 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 14:42:56 +0100 Subject: [PATCH 031/335] EIP 161: Note precompiled contracts can have empty account states --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 0e6eab60..f2c7620a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -237,6 +237,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} +Even callable precompiled contracts can have an empty account state. This is because their account states do not usually contain the code describing its behavior. An account is \textit{dead} when its account state is non-existent or empty: \begin{equation} From 79f18b01ae86cee855de72f7803d39681d981fe7 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 11 Apr 2017 14:26:47 +0200 Subject: [PATCH 032/335] EIP161: document the anomaly The description is based on https://github.com/ethereum/go-ethereum/pull/3341#discussion_r89548318 --- Paper.tex | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f2c7620a..f429fff2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1378,7 +1378,7 @@ \subsection{Trie Database} \section{Precompiled Contracts}\label{app:precompiled} For each precompiled contract, we make use of a template function, $\Xi_{\mathtt{PRE}}$, which implements the out-of-gas checking. -\begin{equation} +\begin{equation} \label{eq:pre} \Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} (\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ (\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} @@ -2263,4 +2263,10 @@ \subsection{Proof-of-work function} \end{cases} \end{equation} +\section{Anomalies on the Main Network} + +\subsection{Deletion of an Account Dispite Out-of-gas} + +At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. + \end{document} From abf07356cacc4ebaee3c75ad33b7cc00b382b423 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 14:35:35 +0200 Subject: [PATCH 033/335] Add a space --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f429fff2..54e7c2c8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2022,7 +2022,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma},\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule From cedfe274edb4181ea2e4a2d058f45e8aeddfb758 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 14:48:12 +0200 Subject: [PATCH 034/335] A more uniform notation for the empty set --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 54e7c2c8..365ceb5c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -549,7 +549,7 @@ \subsection{Substate} We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} -A^0 \equiv (\varnothing, (), \{\}, 0) +A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} \subsection{Execution} From ef560d24d1881e7124a4d5a6ff367a2bc3fb1fb2 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 14:51:00 +0200 Subject: [PATCH 035/335] A partial overwriting is stated with = not with \equiv --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 365ceb5c..2a61593b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -626,8 +626,8 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \\ -\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} And finally, we specify $\Upsilon^g$, the total gas used in this transaction and $\Upsilon^\mathbf{l}$, the logs created by this transaction: From 9b6bc93b137f599f95421b76e8aef6e7098ae6ef Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 15:11:07 +0200 Subject: [PATCH 036/335] In an account state, the storage root comes before the code This has to be fixed in earlier versions as well --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2a61593b..31c71d43 100644 --- a/Paper.tex +++ b/Paper.tex @@ -659,8 +659,8 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except:} \end{equation} \begin{eqnarray} -\boldsymbol{\sigma}^*[a] &\equiv& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ -\boldsymbol{\sigma}^*[s] &\equiv& \begin{cases} +\boldsymbol{\sigma}^*[a] &=& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[s] &=& \begin{cases} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} \end{cases} \\ From dc9df4e128120c820d94bd0d09fc337da172a778 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 15:21:47 +0200 Subject: [PATCH 037/335] Format --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 31c71d43..a3664341 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1051,8 +1051,8 @@ \subsection{Reward Application} \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ -\forall_{U \in B_\mathbf{U}}: \\ \nonumber +\qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ +\qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber \boldsymbol{\sigma}'[U_c] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} From 33baf34ac2bd97177f18a81d2bdc4697d932a450 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 3 Mar 2017 15:00:30 +0100 Subject: [PATCH 038/335] EIP 101: Add EXPMOD precompile --- Paper.tex | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/Paper.tex b/Paper.tex index 2d121963..579e4c7f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -791,6 +791,7 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 2 \\ \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ @@ -1438,6 +1439,32 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one. +The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. +The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. +These two words are followed by $B$ and $E$; and the rest of the input is interpreted as the third non-negative integer $M$. +All non-negative integers $B$, $E$ $M$ are encoded as byte sequences in the big-endian way. + +\begin{eqnarray} +\Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ +\ell_B &=& I_\mathbf{d}[0..31] \\ +B &=& I_\mathbf{d}[32..(31 + \ell_B)] \\ +\ell_E &=& I_\mathbf{d}[(32 + \ell_B)..(63 + \ell_B)] \\ +E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ +M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 32 + \ell_B \quad \vee \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ +g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ +\mathbf{o} &=& +\begin{cases} + () & \text{if} \ M = 0 \\ + B ^ E \bmod M \in \mathbb{B}_\ell & \text{otherwise} +\end{cases} \\ +\ell &=& +\begin{cases} +0 &\text{if}\ M = 0 \quad \vee \quad {B ^ E} \bmod M = 0 \\ +\lfloor \log_8(B ^ E \bmod M) \rfloor + 1 & \text{otherwise} +\end{cases} +\end{eqnarray} \section{Signing Transactions}\label{app:signing} @@ -1550,6 +1577,9 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ +$G_{modexpbase}$ & 45 & Payment for the precompiled exponention under modulo. \\ +$G_{arithword}$ & 6 & Paid for each word used in precompiled contracts for arbitrary precision arighmetics.\\ +$G_{quaddivisor}$ & 32 & The quadratic coefficient of the input sizes of multiplication and division precompiled contracts. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From 2059e4a35fa056b35ecab6bd066cfedf155f214c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 3 Mar 2017 15:13:06 +0100 Subject: [PATCH 039/335] EIP 101: simplify a formula A \/ B into B, because A implies B. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 579e4c7f..6a82b711 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1452,7 +1452,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \ell_E &=& I_\mathbf{d}[(32 + \ell_B)..(63 + \ell_B)] \\ E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 32 + \ell_B \quad \vee \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ \mathbf{o} &=& \begin{cases} From 80b269a4075ea104999842c7b9d7f3d943cea198 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 17:57:02 +0100 Subject: [PATCH 040/335] EIP 101: change the layout of the EXPMOD arguments This change is introduced in: https://github.com/ethereum/EIPs/pull/198/commits/60fe6515378aca6c9d1acb4f84d2f0b2a180abe8 --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6a82b711..93e570b9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1448,8 +1448,8 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ \ell_B &=& I_\mathbf{d}[0..31] \\ -B &=& I_\mathbf{d}[32..(31 + \ell_B)] \\ -\ell_E &=& I_\mathbf{d}[(32 + \ell_B)..(63 + \ell_B)] \\ +\ell_E &=& I_\mathbf{d}[32..63] \\ +B &=& I_\mathbf{d}[64..(63 + \ell_B)] \\ E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ From fa302f69f24b2d822cbee86d286c957693714d8d Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 19:04:02 +0100 Subject: [PATCH 041/335] EIP101: clarify the argument parsing --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 93e570b9..ea8ad6b6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1447,12 +1447,12 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ -\ell_B &=& I_\mathbf{d}[0..31] \\ -\ell_E &=& I_\mathbf{d}[32..63] \\ -B &=& I_\mathbf{d}[64..(63 + \ell_B)] \\ -E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ -M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ +l_B &=& I_\mathbf{d}[0..31] \in \mathbb{P}_{256} \\ +l_E &=& I_\mathbf{d}[32..63] \in \mathbb{P}_{256} \\ +B &=& I_\mathbf{d}[64..(63 + l_B)] \\ +E &=& I_\mathbf{d}[(64 + l_B)..(63 + l_B + l_E)] \\ +M &=& I_\mathbf{d}[(64 + l_B + l_E)..(|I_\mathbf{d}| - 1)] \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E \\ g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ \mathbf{o} &=& \begin{cases} From 7f4b25ce818a1422475907e9f4b4d5e459955a1d Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 19:16:55 +0100 Subject: [PATCH 042/335] EIP101: EXPMOD throws if M <= E This follows the change in https://github.com/ethereum/EIPs/pull/198/commits/c4a771ed3421b1840c3a9d77fbac05b8b58ad2c4 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ea8ad6b6..3cc06974 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1452,7 +1452,7 @@ \section{Precompiled Contracts}\label{app:precompiled} B &=& I_\mathbf{d}[64..(63 + l_B)] \\ E &=& I_\mathbf{d}[(64 + l_B)..(63 + l_B + l_E)] \\ M &=& I_\mathbf{d}[(64 + l_B + l_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E\,\vee\,M\le B \\ g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ \mathbf{o} &=& \begin{cases} From 20c217a590082c39eef1017a20de93171a701343 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 24 Apr 2017 14:28:06 +0200 Subject: [PATCH 043/335] Reformulate EXPMOD as https://github.com/ethereum/EIPs/pull/198 specifies --- Paper.tex | 39 ++++++++++++++------------------------- 1 file changed, 14 insertions(+), 25 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3cc06974..188cc62d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1439,30 +1439,21 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} -The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one. -The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. -The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. -These two words are followed by $B$ and $E$; and the rest of the input is interpreted as the third non-negative integer $M$. -All non-negative integers $B$, $E$ $M$ are encoded as byte sequences in the big-endian way. +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is ???. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. \begin{eqnarray} -\Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ -l_B &=& I_\mathbf{d}[0..31] \in \mathbb{P}_{256} \\ -l_E &=& I_\mathbf{d}[32..63] \in \mathbb{P}_{256} \\ -B &=& I_\mathbf{d}[64..(63 + l_B)] \\ -E &=& I_\mathbf{d}[(64 + l_B)..(63 + l_B + l_E)] \\ -M &=& I_\mathbf{d}[(64 + l_B + l_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E\,\vee\,M\le B \\ -g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ -\mathbf{o} &=& -\begin{cases} - () & \text{if} \ M = 0 \\ - B ^ E \bmod M \in \mathbb{B}_\ell & \text{otherwise} -\end{cases} \\ -\ell &=& -\begin{cases} -0 &\text{if}\ M = 0 \quad \vee \quad {B ^ E} \bmod M = 0 \\ -\lfloor \log_8(B ^ E \bmod M) \rfloor + 1 & \text{otherwise} +\Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ +g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ +\ell_B &\equiv& i[0..31] \\ +\ell_E &\equiv& i[32..63] \\ +\ell_M &\equiv& i[64..95] \\ +B &\equiv& i[96..(95+\ell_B)] \\ +E &\equiv& i[(96+\ell_B)..(95+\ell_B+\ell_E)] \\ +M &\equiv& i[(96+\ell_B+\ell_E)..(95+\ell_B+\ell_E+\ell_M)] \\ +i[x] &\equiv& \begin{cases} +I_{\mathbf d}[x] &\text{if}\ x < |I_{\mathbf d}| \\ +0 &\text{otherwise} \end{cases} \end{eqnarray} @@ -1577,9 +1568,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ -$G_{modexpbase}$ & 45 & Payment for the precompiled exponention under modulo. \\ -$G_{arithword}$ & 6 & Paid for each word used in precompiled contracts for arbitrary precision arighmetics.\\ -$G_{quaddivisor}$ & 32 & The quadratic coefficient of the input sizes of multiplication and division precompiled contracts. \\ +$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From c5511119de12c7d7708d46fd45d09d7b0d3e74fe Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 24 Apr 2017 14:42:40 +0200 Subject: [PATCH 044/335] Specify modulo zero --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 188cc62d..8760bbd9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1439,7 +1439,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} -The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is ???. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ From 44658b89db94a9f9e3aaafc36e0f65cfaeb33e45 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 15:29:49 +0200 Subject: [PATCH 045/335] EIP 101: remove spurious spaces --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8760bbd9..aaa18452 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1439,7 +1439,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} -The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ @@ -1568,7 +1568,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ -$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ +$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From d69ed5da6fd4798de78db6947564e213ae6ed5aa Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 24 May 2017 20:26:34 +0200 Subject: [PATCH 046/335] Update gas costs according to https://github.com/ethereum/EIPs/commit/7138d54 --- Paper.tex | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index aaa18452..519dc002 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1443,7 +1443,12 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +\ell'_E &=& \begin{cases} +0 & \text{if}\ \ell_E\le 256\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 256 \wedge E \neq 0 \\ +8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{otherwise} \\ +\end{cases} \\ \mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ \ell_B &\equiv& i[0..31] \\ \ell_E &\equiv& i[32..63] \\ @@ -1568,7 +1573,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ -$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ +$G_{quaddivisor}$ & 100 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From 93fb950e36658d72d24df57acc78f9c71725f7cc Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 26 May 2017 13:31:37 +0200 Subject: [PATCH 047/335] Fill in a corner case --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 519dc002..a1c763f5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1447,7 +1447,8 @@ \section{Precompiled Contracts}\label{app:precompiled} \ell'_E &=& \begin{cases} 0 & \text{if}\ \ell_E\le 256\wedge E=0 \\ \lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 256 \wedge E \neq 0 \\ -8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{otherwise} \\ +8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 256 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ +8(\ell_E - 32) & \text{otherwise} \\ \end{cases} \\ \mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ \ell_B &\equiv& i[0..31] \\ From 3344c5d0718dd45a3f9761fec78a2db2994670b8 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 26 May 2017 14:38:03 +0200 Subject: [PATCH 048/335] Fix the length constant from bits to bytes --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a1c763f5..8b234c2b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1445,9 +1445,9 @@ \section{Precompiled Contracts}\label{app:precompiled} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ \ell'_E &=& \begin{cases} -0 & \text{if}\ \ell_E\le 256\wedge E=0 \\ -\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 256 \wedge E \neq 0 \\ -8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 256 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ +0 & \text{if}\ \ell_E\le 32\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 32 \wedge E \neq 0 \\ +8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 32 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ 8(\ell_E - 32) & \text{otherwise} \\ \end{cases} \\ \mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ From 3922d0c7f9c787dab0a326efd899f0dabff9ce89 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 24 Jul 2017 11:38:34 +0200 Subject: [PATCH 049/335] Update expmod gas schedule, according to https://github.com/ethereum/EIPs/commit/4d4d8fb --- Paper.tex | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8b234c2b..3d915888 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1443,7 +1443,12 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +g_r &=& \Big\lfloor\frac{f\big(\max(\ell_M,\ell_B)\big)\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +f(x) &\equiv& \begin{cases} +x^2 & \text{if}\ x \le 64 \\ +\Big\lfloor\dfrac{x^2}{4}\Big\rfloor + 96 x - 3072 & \text{if}\ 64 < x \le 1024 \\ +\Big\lfloor\dfrac{x^2}{16}\Big\rfloor + 480x - 199680 & \text{otherwise} +\end{cases}\\ \ell'_E &=& \begin{cases} 0 & \text{if}\ \ell_E\le 32\wedge E=0 \\ \lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 32 \wedge E \neq 0 \\ From 0fe0e30c94c2ca4016d6e4e35e174ccedf0ae3a9 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 29 Mar 2017 17:31:02 +0200 Subject: [PATCH 050/335] \Xi does not return output on exceptional halt This makes the exceptional halts easier to distinguish from reverts --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2d121963..46c574a6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -723,7 +723,7 @@ \section{Contract Creation} \label{ch:create} \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ \nonumber \text{where} \\ -F &\equiv \big(\boldsymbol{\sigma}^{**} = \varnothing \ \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) +F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) \end{align} The exception in the determination of $\boldsymbol{\sigma}'$ dictates that $\mathbf{o}$, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. @@ -783,7 +783,7 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma}^{**} & \text{otherwise} \end{cases} \\ g' & \equiv & \begin{cases} -0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \ \wedge \ \mathbf{o} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ \nonumber \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} @@ -877,7 +877,7 @@ \subsection{Execution Overview} \end{eqnarray} \begin{equation} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} -\big(\varnothing, \boldsymbol{\mu}, A^0, I, ()\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ +\big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing\\ X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise}\\ \end{cases} From f3d6a2eca0966191a86dc49d9ed2b8d26b4b60de Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 29 Mar 2017 17:58:08 +0200 Subject: [PATCH 051/335] Specify REVERT Following https://github.com/ethereum/EIPs/pull/206/files --- Paper.tex | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 46c574a6..3b018efe 100644 --- a/Paper.tex +++ b/Paper.tex @@ -875,9 +875,10 @@ \subsection{Execution Overview} \boldsymbol{\mu}_i & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{s} & \equiv & () \end{eqnarray} -\begin{equation} +\begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} \big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ +\big(\varnothing, \boldsymbol{\mu}', A^0, I, \mathbf{o}\big) & \text{if} \quad w = \text{\small REVERT} \\ O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing\\ X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise}\\ \end{cases} @@ -886,7 +887,9 @@ \subsection{Execution Overview} where \begin{eqnarray} \mathbf{o} & \equiv & H(\boldsymbol{\mu}, I) \\ -(a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) +(a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) \\ +\boldsymbol{\mu}' & \equiv & \boldsymbol{\mu}\ \text{except:} \\ +\boldsymbol{\mu}'_g & \equiv & \boldsymbol{\mu}_g - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \end{eqnarray} Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_g$ from the resultant machine state $\boldsymbol{\mu}'$. @@ -964,13 +967,13 @@ \subsubsection{Normal Halting} The normal halting function $H$ is defined: \begin{equation} H(\boldsymbol{\mu}, I) \equiv \begin{cases} -H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small RETURN} \\ +H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w \in \{\text{\small RETURN}, \text{\small REVERT}\} \\ () & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small SELFDESTRUCT} \} \\ \varnothing & \text{otherwise} \end{cases} \end{equation} -The data-returning halt operation, \text{\small RETURN}, has a special function $H_{\text{\tiny RETURN}}$, defined in Appendix \ref{app:vm}. +The data-returning halt operations, \text{\small RETURN} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$, defined in Appendix \ref{app:vm}. \subsection{The Execution Cycle} @@ -1607,7 +1610,7 @@ \subsection{Gas Cost} with $C_\text{\tiny CALL}$, $C_\text{\tiny SELFDESTRUCT}$ and $C_\text{\tiny SSTORE}$ as specified in the appropriate section below. We define the following subsets of instructions: -$W_{zero}$ = \{{\small STOP}, {\small RETURN}\} +$W_{zero}$ = \{{\small STOP}, {\small RETURN}, {\small REVERT}\} $W_{base}$ = \{{\small ADDRESS}, {\small ORIGIN}, {\small CALLER}, {\small CALLVALUE}, {\small CALLDATASIZE}, {\small CODESIZE}, {\small GASPRICE}, {\small COINBASE},\newline \noindent\hspace*{1cm} {\small TIMESTAMP}, {\small NUMBER}, {\small DIFFICULTY}, {\small GASLIMIT}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}\} @@ -1996,8 +1999,8 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ -&&&& $Z(\boldsymbol{\sigma}^*, \boldsymbol{\mu}, I) = \top$ or $I_e = 1024$ \\ +&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting\\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_e = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_a]_b$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ &&&& created account. \\ @@ -2014,7 +2017,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ -&&&& $Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) = \top$ or if \\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ @@ -2072,6 +2075,11 @@ \subsection{Instruction Set} &&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ +0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes + but returning data and gas. \\ +&&&& The effect of this operation is described in (\ref{eq:X-def}). \\ +&&&& For the gas calculation, we need to define the memory usage: \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule From 6c2b05b2f5c3ca6344cebb7fdf43c0aee34ff5b6 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 14:42:05 +0200 Subject: [PATCH 052/335] EIP 140: the output from REVERT during a contract creation should be accessible from RETURNDATASIZE and RETURNDATACOPY, so \Lambda should return four values. --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3b018efe..2a343a2d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -595,7 +595,7 @@ \subsection{Execution} Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$ and substate $A$: \begin{equation} (\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} -\Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ +\Lambda_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ \Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -606,7 +606,7 @@ \subsection{Execution} \end{equation} and $T_o$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. -Note we use $\Theta_{3}$ to denote the fact that only the first three components of the function's value are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. +Note we use $\Theta_{3}$ and $\Lambda_{3}$ to denote the fact that only the first three components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} @@ -642,9 +642,9 @@ \section{Contract Creation} \label{ch:create} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). -We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas and accrued transaction substate $(\boldsymbol{\sigma}', g', A)$, as in section \ref{ch:transactions}: +We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas, accrued transaction substate and an error message $(\boldsymbol{\sigma}', g', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -1994,7 +1994,7 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ From 987d8aa36e8c3cb5cef4710f5aef58b9c1ec2f3b Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 16:16:41 +0200 Subject: [PATCH 053/335] Fix whitespaces --- Paper.tex | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2a343a2d..8f5190a9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -877,10 +877,10 @@ \subsection{Execution Overview} \end{eqnarray} \begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} -\big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ +\big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \\ \big(\varnothing, \boldsymbol{\mu}', A^0, I, \mathbf{o}\big) & \text{if} \quad w = \text{\small REVERT} \\ -O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing\\ -X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise}\\ +O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing \\ +X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise} \\ \end{cases} \end{equation} @@ -2017,7 +2017,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ -&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ @@ -2077,6 +2077,7 @@ \subsection{Instruction Set} &&&& The last argument of $\Theta$ is $\bot$. \\ 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ +0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we need to define the memory usage: \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ From 3161e96648db502253a349b8ac29a3518a6df6d1 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 2 Mar 2017 14:42:54 +0100 Subject: [PATCH 054/335] EIP-100: change the difficulty adjustment factor so that it considers existence of ommers --- Paper.tex | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8f5190a9..799f606f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -464,8 +464,14 @@ \subsubsection{Block Header Validity} \diffadjustment \equiv \left\lfloor\frac{{P(H)_H}_d}{2048}\right\rfloor \end{equation} \begin{equation} -\homesteadmod \equiv \text{max}\left( 1 - \left\lfloor\frac{H_s - {P(H)_H}_s}{10}\right\rfloor, -99 \right) +\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_s - {P(H)_H}_s}{9}\right\rfloor, -99 \right) \end{equation} +\begin{equation*} +x \equiv \begin{cases} +1 & \text{if} \, \lVert B_\mathbf{U}\rVert = 0 \\ +2 & \text{otherwise} +\end{cases} +\end{equation*} \begin{equation} \expdiffsymb \equiv \left\lfloor 2^{ \left\lfloor H_i \div 100000 \right\rfloor - 2 } \right\rfloor \end{equation} From 5d7d22df11128742389414a3c649833fb41f7561 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 21 Mar 2017 17:12:33 +0100 Subject: [PATCH 055/335] EIP-100: ommers of parent should be counted, not the direct ommers --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 799f606f..58eaeaab 100644 --- a/Paper.tex +++ b/Paper.tex @@ -468,7 +468,7 @@ \subsubsection{Block Header Validity} \end{equation} \begin{equation*} x \equiv \begin{cases} -1 & \text{if} \, \lVert B_\mathbf{U}\rVert = 0 \\ +1 & \text{if} \, \lVert P(H)_\mathbf{U}\rVert = 0 \\ 2 & \text{otherwise} \end{cases} \end{equation*} From 5fb2de816bcc8331919ee56e8e812b6ab5ea2390 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 2 Mar 2017 13:50:38 +0100 Subject: [PATCH 056/335] Implement EIP-658 https://github.com/ethereum/EIPs/pull/658 Now transaction receipts contain one byte indicating success or failure. --- Paper.tex | 58 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 39 insertions(+), 19 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8f5190a9..da6560cc 100644 --- a/Paper.tex +++ b/Paper.tex @@ -333,16 +333,21 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the post-transaction state, $R_{\boldsymbol{\sigma}}$, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} -R \equiv (R_{\boldsymbol{\sigma}}, R_u, R_b, R_\mathbf{l}) +R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_R(R) \equiv (\mathtt{\small TRIE}(L_S(R_{\boldsymbol{\sigma}})), R_u, R_b, R_\mathbf{l}) +L_R(R) \equiv (0 \in \mathbb{B}_{256}, R_u, R_b, R_\mathbf{l}) +\end{equation} +where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. + +We assert that the status code $R_{s'}$ is a single byte. +\begin{equation} +R_{s'} \in \mathbb{B}_{8} \end{equation} -thus the post-transaction state, $R_{\boldsymbol{\sigma}}$ is encoded into a trie structure, the root of which forms the first item. We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): \begin{equation} @@ -592,11 +597,11 @@ \subsection{Execution} \boldsymbol{\sigma}_0[S(T)]_n & \equiv & \boldsymbol{\sigma}[S(T)]_n + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$ and substate $A$: +Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $s'$: \begin{equation} -(\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} -\Lambda_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ -\Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} +(\boldsymbol{\sigma}_P, g', A, s') \equiv \begin{cases} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ +\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -606,7 +611,7 @@ \subsection{Execution} \end{equation} and $T_o$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. -Note we use $\Theta_{3}$ and $\Lambda_{3}$ to denote the fact that only the first three components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. +Note we use $\Theta_{4}$ and $\Lambda_{4}$ to denote the fact that only the first four components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} @@ -630,10 +635,11 @@ \subsection{Execution} \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction and $\Upsilon^\mathbf{l}$, the logs created by this transaction: +And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ +\Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' \end{eqnarray} These are used to help define the transaction receipt, discussed later. @@ -644,7 +650,7 @@ \section{Contract Creation} \label{ch:create} We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas, accrued transaction substate and an error message $(\boldsymbol{\sigma}', g', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -724,6 +730,10 @@ \section{Contract Creation} \label{ch:create} \end{cases} \\ \nonumber \text{where} \\ F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) +\quad s' &\equiv \begin{cases} +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ +1 & \text{otherwise} +\end{cases} \end{align} The exception in the determination of $\boldsymbol{\sigma}'$ dictates that $\mathbf{o}$, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. @@ -738,7 +748,7 @@ \section{Message Call} \label{ch:call} Aside from evaluating to a new state and transaction substate, message calls also have an extra component---the output data denoted by the byte array $\mathbf{o}$. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) +(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) \end{equation} Note that we need to differentiate between the value that is to be transferred, $v$, from the value apparent in the execution context, $\tilde{v}$, for the {\small DELEGATECALL} instruction. @@ -786,6 +796,10 @@ \section{Message Call} \label{ch:call} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \ \wedge \ \mathbf{o} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ \nonumber +s' & \equiv & \begin{cases} +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +1 & \text{otherwise} +\end{cases} \\ \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} \Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 1 \\ \Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 2 \\ @@ -1106,16 +1120,16 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{\boldsymbol{\sigma}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding states, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). The former is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{s'}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\mathbf{R}[n]_{\boldsymbol{\sigma}} = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} In the case of $B_\mathbf{R}[n]_u$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} \mathbf{R}[n]_u = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_u +\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_u \end{array} & \text{otherwise} \end{cases} \end{equation} @@ -1123,12 +1137,18 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} For $\mathbf{R}[n]_\mathbf{l}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. \begin{equation} \mathbf{R}[n]_\mathbf{l} = -\Upsilon^\mathbf{l}(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n]) +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\end{equation} + +We define $\mathbf{R}[n]_{s'}$ in a similar manner. +\begin{equation} +\mathbf{R}[n]_{s'} = +\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(B_\mathbf{R})_{\boldsymbol{\sigma}}$: +Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: \begin{equation} -\Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\mathbf{R})_{\boldsymbol{\sigma}}) +\Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} Thus the complete block-transition mechanism, less $\mathtt{PoW}$, the proof-of-work function is defined. From f5d1d67a205e6b3a43b6e10ba3d35532f9dfc0ec Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 28 Aug 2017 16:38:06 +0200 Subject: [PATCH 057/335] Fix the status code representation --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index da6560cc..f1cbfb36 100644 --- a/Paper.tex +++ b/Paper.tex @@ -344,9 +344,9 @@ \subsubsection{Transaction Receipt} \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_{s'}$ is a single byte. +We assert that the status code $R_{s'}$ is an integer. \begin{equation} -R_{s'} \in \mathbb{B}_{8} +R_{s'} \in \mathbb{P} \end{equation} We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): @@ -714,7 +714,7 @@ \section{Contract Creation} \label{ch:create} The gas remaining will be zero in any such exceptional condition, \ie if the creation was conducted as the reception of a transaction, then this doesn't affect payment of the intrinsic cost of contract creation; it is paid regardless. However, the value of the transaction is not transferred to the aborted contract's address when we are out-of-gas. -If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas and substate as $(\boldsymbol{\sigma}', g', A)$ where: +If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, substate and status code as $(\boldsymbol{\sigma}', g', A, s')$ where: \begin{align} \quad g' &\equiv \begin{cases} From 9a23fd2e343a7e1e370ee719cfacf5ad100021a0 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 8 Sep 2017 15:56:52 +0200 Subject: [PATCH 058/335] Block reward to 3 Ether --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index b359b121..635443a8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1085,9 +1085,9 @@ \subsection{Reward Application} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -We define the block reward as 5 Ether: +We define the block reward as 3 Ether: \begin{equation} -\text{Let} \quad R_b = 5 \times 10^{18} +\text{Let} \quad R_b = 3 \times 10^{18} \end{equation} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} From 36a762cbca1ee2131572b6b95fd92a9895051e2e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 8 Sep 2017 16:09:51 +0200 Subject: [PATCH 059/335] Delay the ice age --- Paper.tex | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 635443a8..f7f78ca2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -472,9 +472,10 @@ \subsubsection{Block Header Validity} 2 & \text{otherwise} \end{cases} \end{equation*} -\begin{equation} -\expdiffsymb \equiv \left\lfloor 2^{ \left\lfloor H_i \div 100000 \right\rfloor - 2 } \right\rfloor -\end{equation} +\begin{align} +\expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ +H'_i &\equiv \max(H_i - 3000000, 0) +\end{align} The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 4e815705de18b89ed77d426a864a0dbc884903ad Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 13 Apr 2017 13:39:35 +0200 Subject: [PATCH 060/335] EIP-196, EIP-197: some basic mathematical descriptions --- Paper.tex | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/Paper.tex b/Paper.tex index b359b121..3d143412 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1477,6 +1477,49 @@ \section{Precompiled Contracts}\label{app:precompiled} \end{cases} \end{eqnarray} +\subsection{zkSNARK Related Precompiled Contracts} + +We choose two numbers, both of which are prime. +\begin{eqnarray} +p &\equiv& 21888242871839275222246405745257275088696311157297823662689037894645226208583 \\ +q &\equiv& 21888242871839275222246405745257275088548364400416034343698204186575808495617 +\end{eqnarray} +Since $p$ is a prime number, $\{0, 1, \ldots, p - 1\}$ forms a field with addition and multiplication modulo $p$. We call this field $F_p$. + +We define a set~$C_1$ with +\begin{equation} +C_1\equiv\{(X,Y)\in F_p\times F_p\mid Y^2=X^3+3\}\cup\{(0,0)\} +\end{equation} +We define a binary operation $+$ on $C_1$ with +\begin{eqnarray}\label{eq:ec-addition} +(X_1, Y_1) + (X_2, Y_2)&\equiv&\begin{cases} +(X,Y)&\text{if}\ X_1\neq X_2\\ +(0,0)&\text{otherwise} +\end{cases}\\ +X&\equiv&\lambda^2-X_1-X_2\\ +Y&\equiv&\lambda(X_1-X)-Y_1\\ +\lambda&\equiv&\frac{Y_2-Y_1}{X_2-X_1} +\end{eqnarray} + +$(C_1,+)$ is known to form a group. We define the scalar multiplication $\cdot$ with +\begin{equation}\label{eq:ec-scalar-multiplication} +n\cdot P\equiv(0,0)+\underbrace{P+\cdots+P}_{n} +\end{equation} +for a natural number $n$ and a point $P$ in $C_1$. + +We define $P_1$ to be a point $(1,2)$ on $C_1$. Let $G_1$ be the subgroup of $(C_1,+)$ generated by $P_1$. $G_1$ is known to be a cyclic group of order $q$. For a point $P$ in $G_1$, we define $\log_{P_1}(P)$ to be the smallest natural number $n$ satisfying $n\cdot P_1=P$. $\log_{P_1}(P)$ is at most $q-1$. + +Let $F_{p^2}$ be a field $F_p[i]/(i+1)$. We define a set $C_2$ with +\begin{equation} +C_2\equiv\{(X,Y)\in F_{p^2}\times F_{p^2}\mid Y^2=X^3+3\}\cup\{(0,0)\} +\end{equation} +We define a binary operation $+$ and a scalar multiplication $\cdot$ with the same equations (\ref{eq:ec-addition}) and (\ref{eq:ec-scalar-multiplication}). $(C_2,+)$ is also known to be a group. We define $P_2$ in $C_2$ with +\begin{eqnarray} +P_2&\equiv& +(11559732032986387107991004021392285783925812861821192530917403151452391805634 \times i\\\nonumber &&+ 10857046999023057135944570762232829481370756359578518086990519993285655852781,\\\nonumber && 4082367875863433681332203403145435568316851327593401208105741076214120093531 \times i\\\nonumber &&+ 8495653923123431417604973247489272438418190587263600148770280649306958101930) +\end{eqnarray} +We define $G_2$ to be the subgroup of $(C_2,+)$ generated by $P_2$. $G_2$ is known to be a cyclic group of order $q$. For a point $P$ in $G_2$, we define $\log_{P_2}(P)$ be the smallest natural number $n$ satisfying $n\cdot P_2=P$. With this definition, $\log_{P_2}(P)$ is at most $q-1$. + \section{Signing Transactions}\label{app:signing} The method of signing transactions is similar to the `Electrum style signatures'; it utilises the SECP-256k1 curve as described by \cite{gura2004comparing}. From b7c70cace3440c9b9aecf6473bf11581cf4f8a68 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 13 Apr 2017 15:20:26 +0200 Subject: [PATCH 061/335] EIP-197: pairing checking precompiled contract As described in https://github.com/ethereum/EIPs/pull/212 --- Paper.tex | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/Paper.tex b/Paper.tex index 3d143412..ec6f0a8d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1520,6 +1520,62 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{eqnarray} We define $G_2$ to be the subgroup of $(C_2,+)$ generated by $P_2$. $G_2$ is known to be a cyclic group of order $q$. For a point $P$ in $G_2$, we define $\log_{P_2}(P)$ be the smallest natural number $n$ satisfying $n\cdot P_2=P$. With this definition, $\log_{P_2}(P)$ is at most $q-1$. +A 32 byte number $\mathbf{x}\in\mathbf{P}_{256}$ might and might not represent an element of $F_p$. +\begin{equation} +\delta_p(\mathbf x)\equiv\begin{cases} +\mathbf x&\text{if}\ \mathbf x Date: Thu, 13 Apr 2017 15:46:06 +0200 Subject: [PATCH 062/335] EIP-196 Define addition precompiled contract on G_1 --- Paper.tex | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Paper.tex b/Paper.tex index ec6f0a8d..19b3ee3b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1576,6 +1576,20 @@ \subsection{zkSNARK Related Precompiled Contracts} b_k&\equiv&\delta_2(I_{\mathbf d}[(|I_{\mathbf d}|-128)..(|I_{\mathbf d}|-1)]) \end{eqnarray} +We define a precompiled contract for addition on $G_1$. +\begin{eqnarray} +\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ +g_r&=&?\\ +\mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ +x&\equiv&\delta_1(\bar I_{\mathbf d}[0..63])\\ +y&\equiv&\delta_1(\bar I_{\mathbf d}[64..127])\\ +\label{eq:complemented_input}\bar I_{\mathbf d}[x]&\equiv&\begin{cases} +I_{\mathbf d}[x]&\text{if}\ x < |I_{\mathbf d}|\\ +0&\text{otherwise} +\end{cases} +\end{eqnarray} + \section{Signing Transactions}\label{app:signing} The method of signing transactions is similar to the `Electrum style signatures'; it utilises the SECP-256k1 curve as described by \cite{gura2004comparing}. From b5c5f1c11629fb0106def82113c0fe25d88eca3e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 13 Apr 2017 15:53:01 +0200 Subject: [PATCH 063/335] EIP-196 Defining the precompiled contract for scalar multiplication on G_1 --- Paper.tex | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Paper.tex b/Paper.tex index 19b3ee3b..a2ee15f1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1590,6 +1590,16 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{cases} \end{eqnarray} +We define a precompiled contract for scalar multiplication on $G_1$, where $\bar I_{\mathbf d}$ is defined in (\ref{eq:complemented_input}). +\begin{eqnarray} +\Xi_{\mathtt{BN\_MUL}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ +g_r&=&?\\ +\mathbf o&\equiv&\delta_1^{-1}(n\cdot x)\quad\text{where $\cdot$ is the scalar multiplication in $G_1$}\\ +n&\equiv&\bar I_{\mathbf d}[0..31]\\ +x&\equiv&\delta_1(\bar I_{\mathbf d}[32..95]) +\end{eqnarray} + \section{Signing Transactions}\label{app:signing} The method of signing transactions is similar to the `Electrum style signatures'; it utilises the SECP-256k1 curve as described by \cite{gura2004comparing}. From fa144bbec665ab8a3427db12854272e4f0540521 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 22 May 2017 12:27:04 +0200 Subject: [PATCH 064/335] Add some mappings from addresses to the new precompiled contracts --- Paper.tex | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Paper.tex b/Paper.tex index a2ee15f1..14b20cb6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -798,6 +798,9 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 8 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ From d27219a31a92d7a37b74651c92b08050933e6c77 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 22 May 2017 13:44:06 +0200 Subject: [PATCH 065/335] Specify gas for the snark verification precompiled contract --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 14b20cb6..405fa5e1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1566,7 +1566,8 @@ \subsection{zkSNARK Related Precompiled Contracts} \Xi_{\mathtt{SNARKV}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \qquad\Xi_{\mathtt{SNARKV}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ F\\ F&\equiv&(|I_\mathbf{d}|\bmod 192\neq 0\vee(\exists j.\ a_j=\varnothing\vee b_j=\varnothing))\\ -g_r&=&?\\ +k &=& \dfrac{|I_\mathbf{d}|}{192} \\ +g_r&=& 60000k + 40000 \\ \mathbf o[0..31]&\equiv&\begin{cases} 0x0000000000000000000000000000000000000000000000000000000000000001&\text{if}\ v\wedge\neg F\\ 0x0000000000000000000000000000000000000000000000000000000000000000&\text{if}\ \neg v\wedge\neg F From 5bb035caabb7c882023b1a14bdc678e480d12793 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 25 Jul 2017 15:46:45 +0200 Subject: [PATCH 066/335] Fix the pairing checker specification according to https://github.com/ethereum/EIPs/pull/212/commits/470c61bed3b94d67815557aca224641742badb56 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 405fa5e1..f8c8bb39 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1572,7 +1572,7 @@ \subsection{zkSNARK Related Precompiled Contracts} 0x0000000000000000000000000000000000000000000000000000000000000001&\text{if}\ v\wedge\neg F\\ 0x0000000000000000000000000000000000000000000000000000000000000000&\text{if}\ \neg v\wedge\neg F \end{cases}\\ -v&\equiv&(\log_{P_1}(a_1)\times\log_{P_2}(b_1)+\cdots+\log_{P_1}(a_k)\times\log_{P_2}(b_k)\equiv 0\mod q)\\ +v&\equiv&(\log_{P_1}(a_1)\times\log_{P_2}(b_1)+\cdots+\log_{P_1}(a_k)\times\log_{P_2}(b_k)\equiv 1\mod q)\\ a_1&\equiv&\delta_1(I_{\mathbf d}[0..63])\\ b_1&\equiv&\delta_2(I_{\mathbf d}[64..191])\\\nonumber \vdots\\ From a35c1f3c10800a12bf58c32942c3ae06c9c063fa Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 19 Sep 2017 14:02:55 +0200 Subject: [PATCH 067/335] Fill the determined gas costs --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index f8c8bb39..fa544fc9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1584,7 +1584,7 @@ \subsection{zkSNARK Related Precompiled Contracts} \begin{eqnarray} \Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ -g_r&=&?\\ +g_r &=& 500\\ \mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ x&\equiv&\delta_1(\bar I_{\mathbf d}[0..63])\\ y&\equiv&\delta_1(\bar I_{\mathbf d}[64..127])\\ @@ -1598,7 +1598,7 @@ \subsection{zkSNARK Related Precompiled Contracts} \begin{eqnarray} \Xi_{\mathtt{BN\_MUL}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_MUL}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ -g_r&=&?\\ +g_r &=& 40000\\ \mathbf o&\equiv&\delta_1^{-1}(n\cdot x)\quad\text{where $\cdot$ is the scalar multiplication in $G_1$}\\ n&\equiv&\bar I_{\mathbf d}[0..31]\\ x&\equiv&\delta_1(\bar I_{\mathbf d}[32..95]) From ce8d19855a24ce0cb5c5b58e6d9e34c8cb47fe51 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 19 Jan 2018 15:42:06 +0100 Subject: [PATCH 068/335] The fourth precompiled contract is not the final one --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b359b121..bf8e655d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1441,7 +1441,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathtt{\small RIPEMD160}(\mathbf{i} \in \mathbb{B}) & \equiv & o \in \mathbb{B}_{20} \end{eqnarray} -Finally, the fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: +The fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: \begin{eqnarray} \Xi_{\mathtt{ID}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_r &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ From 24e8956146d70236d8cb0c23beb9f7e99a2742d5 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:21:16 +0100 Subject: [PATCH 069/335] EIP-211: add the previous output buffer to the execution state --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b1e6848e..2c4cacc9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -883,7 +883,8 @@ \subsection{Execution Overview} \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ \boldsymbol{\mu}_i & \equiv & 0 \\ -\boldsymbol{\mu}_\mathbf{s} & \equiv & () +\boldsymbol{\mu}_\mathbf{s} & \equiv & () \\ +\boldsymbol{\mu}_\mathbf{o} & \equiv & () \end{eqnarray} \begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} @@ -2175,6 +2176,7 @@ \subsection{Instruction Set} &&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{o} = \mathbf{o}$ \\ &&&& $\boldsymbol{\mu}'_g \equiv \boldsymbol{\mu}_g + g'$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ From 697bdea6c4ba0a27254a4ef84dab13d4c9c3d4ff Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:30:15 +0100 Subject: [PATCH 070/335] EIP-211: specify RETURNDATASIZE --- Paper.tex | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Paper.tex b/Paper.tex index 2c4cacc9..a8a2fe73 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1863,6 +1863,10 @@ \subsection{Instruction Set} 0x0b & {\small SIGNEXTEND} & 2 & 1 & Extend length of two's complement signed integer. \\ &&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_t &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_i &\text{otherwise} \end{cases}$ \\ \multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_i$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ +\midrule +0x0d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ +\midrule \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} From 77945cf431e05db9bf300a0deacffe4a3cbb5251 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:35:38 +0100 Subject: [PATCH 071/335] EIP-211: specify RETURNDATACOPY --- Paper.tex | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Paper.tex b/Paper.tex index a8a2fe73..810cdd43 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1867,6 +1867,12 @@ \subsection{Instruction Set} 0x0d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ \midrule +0x0e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv +\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +\midrule \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} From a48f6a5a84bd4d1574163d226f9865af8bba08f0 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:49:42 +0100 Subject: [PATCH 072/335] EIP-211: specify the gas costs for RETURNDATASIZE and RETURNDATACOPY --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 810cdd43..a4d2fff9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1737,7 +1737,7 @@ \subsection{Gas Cost} C_\text{\tiny SSTORE}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SSTORE} \\ G_{exp} & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] = 0 \\ G_{exp} + G_{expbyte}\times(1+\lfloor\log_{256}(\boldsymbol{\mu}_\mathbf{s}[1])\rfloor) & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] > 0 \\ -G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \\ +G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \lor \text{\small RETURNDATACOPY} \\ G_{extcode} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1] & \text{if} \quad w = \text{\small LOG0} \\ G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+G_{logtopic} & \text{if} \quad w = \text{\small LOG1} \\ @@ -1776,7 +1776,7 @@ \subsection{Gas Cost} $W_{zero}$ = \{{\small STOP}, {\small RETURN}, {\small REVERT}\} -$W_{base}$ = \{{\small ADDRESS}, {\small ORIGIN}, {\small CALLER}, {\small CALLVALUE}, {\small CALLDATASIZE}, {\small CODESIZE}, {\small GASPRICE}, {\small COINBASE},\newline \noindent\hspace*{1cm} {\small TIMESTAMP}, {\small NUMBER}, {\small DIFFICULTY}, {\small GASLIMIT}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}\} +$W_{base}$ = \{{\small ADDRESS}, {\small ORIGIN}, {\small CALLER}, {\small CALLVALUE}, {\small CALLDATASIZE}, {\small CODESIZE}, {\small GASPRICE}, {\small COINBASE},\newline \noindent\hspace*{1cm} {\small TIMESTAMP}, {\small NUMBER}, {\small DIFFICULTY}, {\small GASLIMIT}, {\small RETURNDATASIZE}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}\} $W_{verylow}$ = \{{\small ADD}, {\small SUB}, {\small NOT}, {\small LT}, {\small GT}, {\small SLT}, {\small SGT}, {\small EQ}, {\small ISZERO}, {\small AND}, {\small OR}, {\small XOR}, {\small BYTE}, {\small CALLDATALOAD}, \newline \noindent\hspace*{1cm} {\small MLOAD}, {\small MSTORE}, {\small MSTORE8}, {\small PUSH*}, {\small DUP*}, {\small SWAP*}\} From 232398f82ad9e02ba833280c0e889de9d48d49ee Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 10:33:26 +0100 Subject: [PATCH 073/335] EIP-211: CREATE resets the previous return data This change is according to https://github.com/ethereum/EIPs/pull/211#issuecomment-287728214 --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index a4d2fff9..bd64d2eb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2179,6 +2179,7 @@ \subsection{Instruction Set} &&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ &&&& created account. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{o} \equiv ()$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ From 1a7e397af5f83a8d267a65c8788bdba839e4c74e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 9 May 2017 18:14:58 +0200 Subject: [PATCH 074/335] Move RETURNDATACOPY and RETURNDATASIZE to the 0x3. block --- Paper.tex | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index bd64d2eb..79249639 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1864,15 +1864,6 @@ \subsection{Instruction Set} &&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_t &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_i &\text{otherwise} \end{cases}$ \\ \multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_i$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ \midrule -0x0d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ -\midrule -0x0e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ -\midrule \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} @@ -1986,6 +1977,15 @@ \subsection{Instruction Set} &&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_c$ \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[2] + i$ are not subject to the $2^{256}$ modulo. \\ +\midrule +0x3d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ +\midrule +0x3e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv +\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ \bottomrule \end{tabular*} From aa9ef93051420377d617b5da7eb882c9d383b0c3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 21 Jun 2017 14:50:35 +0200 Subject: [PATCH 075/335] RETURNDATACOPY throws when it would overrun the return data buffer even when the accessed length is zero. --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 79249639..89d4ea65 100644 --- a/Paper.tex +++ b/Paper.tex @@ -931,6 +931,7 @@ \subsubsection{Exceptional Halting} \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ ( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ +( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ \neg I_w \wedge W(w, \boldsymbol{\mu}) \end{array} From 936d0bb1be13dc2dc617c8c83c20ab21e6754b52 Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Fri, 19 Jan 2018 16:30:09 +0100 Subject: [PATCH 076/335] Byzantium revision --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ce8a79ad..c943fb1b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -39,7 +39,7 @@ \newcommand*\ie{i.e.\@\xspace} %\renewcommand{\itemhook}{\setlength{\topsep}{0pt} \setlength{\itemsep}{0pt}\setlength{\leftmargin}{15pt}} -\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-150 revision (\YellowPaperVersionNumber{})}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ From 35199b8144dced866ee4dfc7473066be90140380 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 18:42:01 +1100 Subject: [PATCH 077/335] Remove lightpink lines --- Paper.tex | 2 -- 1 file changed, 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d143f480..ff1ef4aa 100644 --- a/Paper.tex +++ b/Paper.tex @@ -31,7 +31,6 @@ }% \definecolor{lightyellow}{rgb}{1,0.98,0.9} -%\definecolor{lightpink}{rgb}{1,0.94,0.95} \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} @@ -48,7 +47,6 @@ \begin{document} \pagecolor{lightyellow} -%\pagecolor{lightpink} \begin{abstract} The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not least Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. From f78734c843c7cc91b256b10814fb03d1bb821088 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 18:46:39 +1100 Subject: [PATCH 078/335] Update Paper.tex --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index edfe21ec..c162d3b9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -51,7 +51,7 @@ %\pagecolor{lightpink} \begin{abstract} -The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not the least being Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. +The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, with Bitcoin being one of the most notable ones. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. Ethereum implements this paradigm in a generalised manner. Furthermore it provides a plurality of such resources, each with a distinct state and operating code but able to interact through a message-passing framework with others. We discuss its design, implementation issues, the opportunities it provides and the future hurdles we envisage. \end{abstract} From bead47f792abf424fa19526ded9619dd8b902703 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 19:56:45 +1100 Subject: [PATCH 079/335] Add EIP-2 and EIP-649 refs --- Biblio.bib | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index f3c0ee9c..40cfbea0 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,3 +1,17 @@ +@Misc{EIP-649, + url = "https://github.com/ethereum/EIPs/blob/63c93eb71d1148435fa2cadb36da7df2bd865a3d/EIPS/eip-649.md", + author = "Afri Schoedon and Vitalik Buterin", + title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", + year = "2017", +} + +@Misc{EIP-2, + url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md", + title = "EIP-2: Homestead Hard-fork Changes", + author = "Vitalik Buterin", + year = "2015", +} + @Misc{cryptoeprint:2013:881, Note = {{http://eprint.iacr.org/}}, Url = {{Cryptology ePrint Archive, Report 2013/881}}, @@ -141,4 +155,4 @@ @article{FowlerNollVo1991FNVHash author = {Glenn Fowler, Landon Curt Noll, Phong Vo}, title = {{Fowler–Noll–Vo hash function}}, year = {{1991}}, -} \ No newline at end of file +} From ce638b84164a2dea016f50e3c80486863bf4b4d4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 20:23:39 +1100 Subject: [PATCH 080/335] \cite{EIP-100, --- Biblio.bib | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Biblio.bib b/Biblio.bib index 40cfbea0..bb77cab4 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,8 +1,17 @@ +\cite{EIP-100, + url = "https://github.com/ethereum/EIPs/blob/f3a591f6718035ba358d6a479cadabe313f6ed36/EIPS/eip-100.md", + author = "Vitalik Buterin", + title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", + year = "2016", + month = "April", +} + @Misc{EIP-649, url = "https://github.com/ethereum/EIPs/blob/63c93eb71d1148435fa2cadb36da7df2bd865a3d/EIPS/eip-649.md", author = "Afri Schoedon and Vitalik Buterin", title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", year = "2017", + month = "June", } @Misc{EIP-2, From 10390b878239548c95856adf5d511d6e5f368056 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 20:24:52 +1100 Subject: [PATCH 081/335] Update explanations of \homesteadmod and \expdiffsymb with citations for EIPs --- Paper.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Paper.tex b/Paper.tex index c943fb1b..b48e0b46 100644 --- a/Paper.tex +++ b/Paper.tex @@ -482,6 +482,8 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, $\expdiffsymb$ results in the difficulty increasing every 10000 blocks, which puts upward pressure on the time between blocks, causing it to slowly accelerate, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. + The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} & & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ From 25dc3d4aed07177df90013d7a508cd6a23c92049 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 20:59:46 +1100 Subject: [PATCH 082/335] \cite{EIP-100, -> @Misc{EIP-100, --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index bb77cab4..ed174b53 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,4 +1,4 @@ -\cite{EIP-100, +@Misc{EIP-100, url = "https://github.com/ethereum/EIPs/blob/f3a591f6718035ba358d6a479cadabe313f6ed36/EIPS/eip-100.md", author = "Vitalik Buterin", title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", From bc1ba477f0c31378742f76064286a8ff65ef9d92 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 09:28:02 +0000 Subject: [PATCH 083/335] Add Paper.out to .gitignore. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 44c9250f..59c4bba2 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ Paper.aux Paper.bbl Paper.blg Paper.log +Paper.out Paper.pdf Version.tex From 049f7172b81da09d4319716ebd55c965c9166a63 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 09:48:59 +0000 Subject: [PATCH 084/335] Add description of the new Byzantium precompiles to section 8. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 98080c7b..97f14ca7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -838,7 +838,7 @@ \section{Message Call} \label{ch:call} It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_\mathbf{b}), I_\mathbf{b})$ at some point prior in order to make the determination of $I_\mathbf{b}$ feasible. -As can be seen, there are four exceptions to the usage of the general execution framework $\Xi$ for evaluation of the message call: these are four so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become \textit{native extensions}. The four contracts in addresses 1, 2, 3 and 4 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme and the identity function respectively. +As can be seen, there are eight exceptions to the usage of the general execution framework $\Xi$ for evaluation of the message call: these are eight so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become \textit{native extensions}. The eight contracts in addresses 1 to 8 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme, the identity function, arbitrary precision modular exponentiation, elliptic curve addition, elliptic curve scalar multiplication and an elliptic curve pairing check respectively. Their full formal definition is in Appendix \ref{app:precompiled}. From 6fc61c90e2ade5d06d0c6d8019845f26f6104df7 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 16 Jan 2018 17:52:07 +0100 Subject: [PATCH 085/335] Add table of versions in README.md --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 709555e5..e22881b9 100644 --- a/README.md +++ b/README.md @@ -15,3 +15,15 @@ In order to build, use the supplied build script (``build.sh``). Following the f ## Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu + +## Protocol Versions + +Each protocol version is specified in a branch in this repository. The activation block of each version is specified in the links. + +| Branch | Version | Known Significant Issues | +|-----------------|-----------------------------------------------------------------------------------|--------------------------| +| master | [Byzantium](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-609.md) | Some EIPs not reflected | +| spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Some EIPs not reflected | +| (to be added) | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | | +| (to be added) | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | | +| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | | From 9e34cc4fabfa67e4d53628c80ea97ef607495831 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 22 Jan 2018 11:48:50 +0100 Subject: [PATCH 086/335] Separate BRANCHES.md and add fork numbers --- BRANCHES.md | 11 +++++++++++ README.md | 14 ++------------ 2 files changed, 13 insertions(+), 12 deletions(-) create mode 100644 BRANCHES.md diff --git a/BRANCHES.md b/BRANCHES.md new file mode 100644 index 00000000..f52e3349 --- /dev/null +++ b/BRANCHES.md @@ -0,0 +1,11 @@ +## Protocol Versions + +Each protocol version is specified in `Paper.tex` found in a branch of this repository. + +| Branch | Version | Applicable Block Numbers | +|-------------------|-----------------------------------------------------------------------------------|---------------------------------| +| master | [Byzantium](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-609.md) | Since 4,370,000 and onwards | +| spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Since 2,675,000 until 4,369,999 | +| tangerine-whistle | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | Since 2,463,000 until 2,674,999 | +| dao-fork | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | Since 1,920,000 until 2,462,000 | +| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | Since 1 until 1,919,999 | diff --git a/README.md b/README.md index e22881b9..6fadd673 100644 --- a/README.md +++ b/README.md @@ -13,17 +13,7 @@ The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is In order to build, use the supplied build script (``build.sh``). Following the first time, you can use the standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. It can be viewed in ``PDF`` format after building. +The previous protocol versions are listed in [BRANCHES.md](./BRANCHES.md). + ## Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu - -## Protocol Versions - -Each protocol version is specified in a branch in this repository. The activation block of each version is specified in the links. - -| Branch | Version | Known Significant Issues | -|-----------------|-----------------------------------------------------------------------------------|--------------------------| -| master | [Byzantium](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-609.md) | Some EIPs not reflected | -| spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Some EIPs not reflected | -| (to be added) | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | | -| (to be added) | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | | -| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | | From 6ac5209b4136ae596ee62fae7c3e6a21af754f35 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 10:55:34 +0000 Subject: [PATCH 087/335] Update EIP 649 URL --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index ed174b53..74b0a8db 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -7,7 +7,7 @@ @Misc{EIP-100 } @Misc{EIP-649, - url = "https://github.com/ethereum/EIPs/blob/63c93eb71d1148435fa2cadb36da7df2bd865a3d/EIPS/eip-649.md", + url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-649.md", author = "Afri Schoedon and Vitalik Buterin", title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", year = "2017", From cb9a2cba458e00f1b8a250364e9699d92d245ca5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 11:01:49 +0000 Subject: [PATCH 088/335] Update EIP 100 URL --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 74b0a8db..9421693e 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,5 +1,5 @@ @Misc{EIP-100, - url = "https://github.com/ethereum/EIPs/blob/f3a591f6718035ba358d6a479cadabe313f6ed36/EIPS/eip-100.md", + url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md", author = "Vitalik Buterin", title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", year = "2016", From e54026c2633fc7a25c40838d989d959a75331607 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 11:48:20 +0000 Subject: [PATCH 089/335] Add `- sudo apt install texlive-latex-extra` --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 7efafc8e..d2130c78 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,6 +2,7 @@ sudo: required before_install: - sudo apt-get -qq update - sudo apt-get install texlive texlive-latex3 +- sudo apt install texlive-latex-extra script: - ./build.sh deploy: From 69a76f5094bc1c9eaf110113deec66fb685642f3 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 12:16:34 +0000 Subject: [PATCH 090/335] Fix formatting of s' definition. --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 97f14ca7..a477bb06 100644 --- a/Paper.tex +++ b/Paper.tex @@ -741,12 +741,12 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ -\nonumber \text{where} \\ -F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) \quad s' &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ 1 & \text{otherwise} -\end{cases} +\end{cases} \\ +\nonumber \text{where} \\ +F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) \end{align} The exception in the determination of $\boldsymbol{\sigma}'$ dictates that $\mathbf{o}$, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. From 2e7a32274312a1ffaa4a5f6a2a157cff80feb4c0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:39:46 +1100 Subject: [PATCH 091/335] Rephrase a sentence on the $\expdiffsymb$ and add an explanation of the difficulty bomb delay --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b48e0b46..87b60e10 100644 --- a/Paper.tex +++ b/Paper.tex @@ -482,7 +482,7 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, $\expdiffsymb$ results in the difficulty increasing every 10000 blocks, which puts upward pressure on the time between blocks, causing it to slowly accelerate, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up due to network congestion. The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 62fe74b1ee3f9c11492d25a41e9f9834a492ca83 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:42:00 +1100 Subject: [PATCH 092/335] Grammar fixes: add "a", omit 'the" --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 709555e5..15f7b6a1 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ The Yellow Paper is a formal definition of the Ethereum protocol, originally by Gavin Wood, currently maintained by Nick Savers and with contributions from many people around the world. -It is free culture work, licensed under the Creative Commons Attribution Share-Alike (CC-BY-SA) version 4.0. +It is a free culture work, licensed under Creative Commons Attribution Share-Alike (CC-BY-SA) version 4.0. ## Usage From 30a45c79e4c1ba00b4247c18f6986a8da478b937 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:46:01 +1100 Subject: [PATCH 093/335] Add a period --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 15f7b6a1..d5f9a7f1 100644 --- a/README.md +++ b/README.md @@ -14,4 +14,4 @@ The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is In order to build, use the supplied build script (``build.sh``). Following the first time, you can use the standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. It can be viewed in ``PDF`` format after building. ## Other language versions -- [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu +- [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu. From 215d27a33d736769a7b96b9a7baf9657d5846b77 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:51:37 +1100 Subject: [PATCH 094/335] Update how to build --- README.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 709555e5..aa07f273 100644 --- a/README.md +++ b/README.md @@ -9,9 +9,18 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A ## Usage -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/) . +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). -In order to build, use the supplied build script (``build.sh``). Following the first time, you can use the standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. It can be viewed in ``PDF`` format after building. +## How to build + +The paper also comes as a single ``latex`` file ``Paper.tex``, which is built as a PDF as follows. + +``` +git clone https://github.com/ethereum/yellowpaper.git +cd yellowpaper +./build.sh +``` +This will create a PDF version of the Yellow Paper. Following building, you can also use standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. ## Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu From b87a989cc90aa41abacfdc3dcdea9f229512d204 Mon Sep 17 00:00:00 2001 From: Afri Schoedon <5chdn@users.noreply.github.com> Date: Mon, 22 Jan 2018 20:59:58 +0100 Subject: [PATCH 095/335] Change Ethcore to Parity. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..771958d8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -49,8 +49,8 @@ \title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ - Founder, Ethereum \& Ethcore\\ - gavin@ethcore.io + Founder, Ethereum \& Parity\\ + gavin@parity.io } \begin{document} From 356d0fb0c6dda5f8390d3742e893db2a4bcbeba7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 12:09:13 +1100 Subject: [PATCH 096/335] Add table packages tabu and tabularx --- Paper.tex | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..568cb82e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,15 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -% I will insert other table packages in here after this is merged. +%\usepackage{longtable} +%https://stackoverflow.com/questions/1918366/automated-line-breaks-in-latex-tables/1918465#1918465 +%tabularx seems better, but we can include this if we need tables to break across pages automatically, as well as tabu and longtabu + +\usepackage{tabularx} +%https://stackoverflow.com/a/1919447/7438857 + +% Tabu seems more flexible, and generally better. +\usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} From 9dbc1d68e4aff58efbbde61ba564291859220f5d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 12:29:32 +1100 Subject: [PATCH 097/335] ... refer to Appendix \ref{ch:Terminology}. --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 8ae6489a..f426e558 100644 --- a/Paper.tex +++ b/Paper.tex @@ -98,6 +98,7 @@ \subsection{Previous Work} \label{ch:previous} Early work on smart contracts has been done by \cite{szabo1997formalizing} and \cite{miller1997future}. Around the 1990s it became clear that algorithmic enforcement of agreements could become a significant force in human cooperation. Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems. In this light, Ethereum may be seen as a general implementation of such a \textit{crypto-law} system. %E language? +For a list of terms used in this paper, refer to Appendix \ref{ch:Terminology}. \section{The Blockchain Paradigm} \label{ch:overview} From e0caa58e62ac724ca91d6e065dcf7920634321b7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 14:49:50 +1100 Subject: [PATCH 098/335] Remove seemingly out-of-date to-do. --- Paper.tex | 2 -- 1 file changed, 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..417b23f5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -580,8 +580,6 @@ \subsection{Execution} where $T_\mathbf{i},T_\mathbf{d}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. -%todo Explain g_d reason? - The up-front cost $v_0$ is calculated as: \begin{equation} v_0 \equiv T_g T_p + T_v From 7ecd05765f55b701cda957ed51fb705c6e26e591 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 15:51:34 +1100 Subject: [PATCH 099/335] =?UTF-8?q?hypertargets=20lines=20100=E2=80=93199?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..1b200317 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally:\hypertarget{Upsilon_state_transition}{Upsilon_state_transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} @@ -179,7 +179,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \hypertarget{ell}{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -195,7 +195,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: -\begin{description} +\begin{description}\hypertarget{account_nonce}{account_nonce} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. From b6c96005f1bf7e9e14851a6de146368d6adc4d40 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 15:51:42 +1100 Subject: [PATCH 100/335] =?UTF-8?q?hypertargets=20lines=20200=E2=80=93299?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..710b57cd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function: +where $v$ is the account validity function:\hypertarget{v x}{} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{T n}{} -\begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$. -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$. +\begin{description}\hypertarget{T n}{} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{T p}{} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{T g}{} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{T t}{} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{T v}{} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From ed97640a98aaaa0668bb4fe4fc1f92592e136112 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 15:59:44 +1100 Subject: [PATCH 101/335] Update labels and targets --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index 710b57cd..6a8d11bd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function:\hypertarget{v x}{} +where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account_validity_function_v__x} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{T n}{} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: -\begin{description}\hypertarget{T n}{} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{T p}{} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{T g}{} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{T t}{} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{T v}{} +\begin{description}\hypertarget{tx_nonce}{tx_nonce_T__n} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx_gas_price_T__p} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx_to_address_T__t} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx_value_T__v}{tx_value_T__v} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 51f8393dd0703114245a217bb937406da42b6f49 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:03:18 +1100 Subject: [PATCH 102/335] =?UTF-8?q?hypertargets=20lines=20300=E2=80=93349?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..25646cdc 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,37 +307,37 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} -\begin{description} +\begin{description}\hypertarget{H p}{parentHash} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{H c}{beneficiary} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$. -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$. +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts-Root-def}{receipts-Root-def} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs-Bloom-def}{logs-Bloom-def} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$. +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{H_i}{blocknumber} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$. -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$. -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$. -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$. -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$. +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{H_g}{gasUsed} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{H_s}{timestamp} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{H_x}{extraData} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{H_m}{mixHash} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block nonce}{block_nonce}\hypertarget{H_n}{block_nonce} \item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. -\end{description} +\end{description}\hypertarget{B U}{} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation} +\end{equation}\hypertarget{Transaction Receipt}{Transaction_Receipt} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{R}{transaction_receipt}\hypertarget{R u}{tx_receipt_gas_used} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 205feed47f8883d078a762476e3e78037a086f01 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:13:48 +1100 Subject: [PATCH 103/335] Update labels=targets --- Paper.tex | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Paper.tex b/Paper.tex index 25646cdc..d96e2048 100644 --- a/Paper.tex +++ b/Paper.tex @@ -311,23 +311,23 @@ \subsection{The Block} \label{ch:block} %\textit{TODO: Introduce logs} -\begin{description}\hypertarget{H p}{parentHash} +\begin{description}\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{H c}{beneficiary} +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary_H__c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts-Root-def}{receipts-Root-def} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs-Bloom-def}{logs-Bloom-def} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts_Root_def_words} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs_Bloom_def_words} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{H_i}{blocknumber} +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block_number_H_i} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{H_g}{gasUsed} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{H_s}{timestamp} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{H_x}{extraData} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{H_m}{mixHash} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block nonce}{block_nonce}\hypertarget{H_n}{block_nonce} +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block_gas_used_H__g} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block_timestamp_H__s} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block_extraData_H__x} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block_nonce_H__n} \item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. -\end{description}\hypertarget{B U}{} +\end{description}\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} @@ -337,7 +337,7 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{R}{transaction_receipt}\hypertarget{R u}{tx_receipt_gas_used} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx_receipt_gas_used_R__u} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 650251a328da383a628339ca1d4a81575c7a9725 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:29:03 +1100 Subject: [PATCH 104/335] =?UTF-8?q?hypertargets=20lines=20350=E2=80=93399?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..c794908e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -389,11 +389,11 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} -\begin{array}[t]{lclc} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ +\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{block_validity_H__r} +H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{Ommer_block_hash_H__o}\\ +H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{tx_block_hash_H__t}\\ +H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{Receipts_Root_H__e}\\ +H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{logs_Bloom_filter_H__b}\\ H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} From e4146a6f3f7f9b094b28ea28bdbf906d305779f0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:45:33 +1100 Subject: [PATCH 105/335] =?UTF-8?q?Hypertargets=20lines=20400=E2=80=93499?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..09fe2e47 100644 --- a/Paper.tex +++ b/Paper.tex @@ -397,7 +397,6 @@ \subsubsection{Holistic Validity} H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} - where $p(k, v)$ is simply the pairwise RLP transformation, in this case, the first being the index of the transaction in the block and the second being the transaction receipt: \begin{equation} p(k, v) \equiv \big( \mathtt{\small RLP}(k), \mathtt{\small RLP}(v) \big) @@ -418,7 +417,7 @@ \subsubsection{Serialisation} \begin{eqnarray} \quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ \quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) -\end{eqnarray} +\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{general_element_wise_sequence_transformation_f_pow_asterisk} With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} @@ -458,7 +457,7 @@ \subsubsection{Block Header Validity} \newcommand{\mindifficulty}{D_0} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} -\newcommand{\diffadjustment}{x} +\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{block_difficulty_H__d} The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} @@ -486,7 +485,7 @@ \subsubsection{Block Header Validity} \begin{align} \expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ H'_i &\equiv \max(H_i - 3000000, 0) -\end{align} +\end{align}\hypertarget{block_gas_limit_H__l}{block_gas_limit_H__l} The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} @@ -495,7 +494,7 @@ \subsubsection{Block Header Validity} & & H_l \geqslant 5000 \end{eqnarray} -$H_s$ is the timestamp of block $H$ and must fulfil the relation: +$H_s$ is the timestamp (in Unix time) of block $H$ at the block's inception, and must fulfil the relation: \begin{equation} H_s > {P(H)_H}_s \end{equation} From f16cfa1c379ce65a69a4e1a246d5d1ec497a0c11 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:51:11 +1100 Subject: [PATCH 106/335] =?UTF-8?q?hypertargets=20lines=20500=E2=80=93599?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..29c19138 100644 --- a/Paper.tex +++ b/Paper.tex @@ -506,11 +506,11 @@ \subsubsection{Block Header Validity} \begin{equation} n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{block_header_without_nonce_and_mixmash_h__cancel_n} Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. -This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. +This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{block_header_validity_function} Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} @@ -561,16 +561,16 @@ \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) -\end{equation} +\end{equation}\hypertarget{self_destruct_set_wordy_defn}{self_destruct_set_wordy_defn} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{tx_log_series_wordy_defn} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{refund_balance_defn_words} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} -\subsection{Execution} +\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{intrinsic_gas_g_0} We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ @@ -591,7 +591,7 @@ \subsection{Execution} \begin{equation} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ -\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \\ +\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{transaction_nonce}\\ T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ g_0 & \leqslant & T_g \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ From bd1d68f618dcc104884610b57fed97a1bddb624b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:57:29 +1100 Subject: [PATCH 107/335] =?UTF-8?q?hypertargets=20lines=20646=E2=80=93662?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..6cb2ee8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -643,11 +643,12 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} -\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{self_destruct_list_A__s}\\ +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{touched_A__t}\\ \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{tx_total_gas_used_Upsilon_pow_g}\hypertarget{tx_logs_Upsilon_pow_l}{tx_logs_Upsilon_pow_l}\hypertarget{tx_status_Upsilon_pow_s} And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ @@ -658,6 +659,7 @@ \subsection{Execution} These are used to help define the transaction receipt, discussed later. \section{Contract Creation} \label{ch:create} +\hypertarget{endow}{endow} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). From 472903527a7edee43c694f41117975bbb07a2df9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 17:24:26 +1100 Subject: [PATCH 108/335] =?UTF-8?q?hypertargets=20lines=20871=E2=80=93882?= =?UTF-8?q?=20exec=20params?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..3952b96e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -868,16 +868,16 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: -\begin{itemize} -\item $I_a$, the address of the account which owns the code that is executing. -\item $I_o$, the sender address of the transaction that originated this execution. -\item $I_p$, the price of gas in the transaction that originated this execution. -\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. -\item $I_\mathbf{b}$, the byte array that is the machine code to be executed. -\item $I_H$, the block header of the present block. -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{address_of_account_which_owns_code_I__a_def_words} +\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{address_of_sender_of_tx_that_originated_execution_I__o} +\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{gas_price_in_tx_that_originated_execution_I__p} +\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{execution_input_data_I__d} +\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s} +\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{Wei_value_exec_I__v} +\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{exec_machine_code_I__b} +\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{exec_block_header_I__H} +\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{exec_call_or_create_depth_I__e} +\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{exec_permission_to_modify_state_I__w} \item $I_w$, the permission to make modifications to the state. \end{itemize} From 979eb7e9f40cccf95b268a0245ed1a3f44248ff2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 17:30:25 +1100 Subject: [PATCH 109/335] \hypertarget{Exceptional_Halting_function_Z}{Exceptional_Halting_function_Z} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..1382e779 100644 --- a/Paper.tex +++ b/Paper.tex @@ -942,7 +942,7 @@ \subsubsection{Machine State} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\subsubsection{Exceptional Halting} +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{Exceptional_Halting_function_Z} The exceptional halting function $Z$ is defined as: \begin{equation} From 3abc92be441fbdd12213da9116b5356a2cd68119 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 17:32:12 +1100 Subject: [PATCH 110/335] \hypertarget{normal_halting_function_H}{normal_halting_function_H} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..33223668 100644 --- a/Paper.tex +++ b/Paper.tex @@ -993,7 +993,7 @@ \subsubsection{Jump Destination Validity} N(i, w) \equiv \begin{cases} i + w - \text{\small PUSH1} + 2 & \text{if} \quad w \in [\text{\small PUSH1}, \text{\small PUSH32}] \\ i + 1 & \text{otherwise} \end{cases} -\end{equation} +\end{equation}\hypertarget{normal_halting_function_H}{normal_halting_function_H} \subsubsection{Normal Halting} From e799551402a90a752b749559afdc84bf7517b628 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 18:59:47 +1100 Subject: [PATCH 111/335] \hypertarget{JUMP}{JUMP} \hypertarget{JUMPI}{JUMPI} \label{eq:mu_pc} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..9f09aefd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1020,7 +1020,7 @@ \subsection{The Execution Cycle} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: \begin{eqnarray} -\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \\ +\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \hypertarget{JUMP}{JUMP} \hypertarget{JUMPI}{JUMPI} \label{eq:mu_pc}\\ \quad \boldsymbol{\mu}'_{pc} & \equiv & \begin{cases} J_{\text{JUMP}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ J_{\text{JUMPI}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ From 816f31b858c19cce8c413b716a79bf2e67d3fa1c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 10:21:39 +0000 Subject: [PATCH 112/335] Comment out tabularx --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 568cb82e..13bd410a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -26,7 +26,7 @@ %https://stackoverflow.com/questions/1918366/automated-line-breaks-in-latex-tables/1918465#1918465 %tabularx seems better, but we can include this if we need tables to break across pages automatically, as well as tabu and longtabu -\usepackage{tabularx} +%\usepackage{tabularx} %https://stackoverflow.com/a/1919447/7438857 % Tabu seems more flexible, and generally better. From ac55a9af43d79a084934717b676b5ec507aff8b8 Mon Sep 17 00:00:00 2001 From: nicksavers Date: Tue, 23 Jan 2018 11:41:34 +0100 Subject: [PATCH 113/335] Remove duplicate REVERT opcode --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..5053c0d3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2279,8 +2279,7 @@ \subsection{Instruction Set} &&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ -0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes - but returning data and gas. \\ +\midrule 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we need to define the memory usage: \\ From 277af38f7da4f7699b21958a0006e98be8799a3b Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 10:13:58 +0000 Subject: [PATCH 114/335] Clean up formatting of REVERT opcode description. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4acfb632..ad9c56a2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2278,9 +2278,9 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ \midrule -0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ +0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and remaining gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ -&&&& For the gas calculation, we need to define the memory usage: \\ +&&&& For the gas calculation, we use the memory expansion function, \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ From 7573a1f1a69f02692ed517aa3e16e79e7ccf80d4 Mon Sep 17 00:00:00 2001 From: Zac Mitton Date: Tue, 23 Jan 2018 19:55:51 +0100 Subject: [PATCH 115/335] changed ordering or receipt items to correct client implementation --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d5e6f46e..cee93f03 100644 --- a/Paper.tex +++ b/Paper.tex @@ -339,9 +339,9 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: +The transaction receipt is a tuple of four items comprising the status code of the transaction, $R_{s'}$, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$, and the Bloom filter composed from information in those logs, $R_b$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) +R \equiv (R_{s'}, R_u, R_b, R_\mathbf{l}) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: From 6c06222e5d784e8af4598663f3f97b021390e636 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:46:29 +1100 Subject: [PATCH 116/335] Update Paper.tex --- Paper.tex | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9f09aefd..3dbeb89a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -951,7 +951,8 @@ \subsubsection{Exceptional Halting} \boldsymbol{\mu}_g < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ -( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ +( w \in \{ \text{\small JUMP}, \text{\small +} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ ( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ \neg I_w \wedge W(w, \boldsymbol{\mu}) @@ -1020,7 +1021,7 @@ \subsection{The Execution Cycle} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: \begin{eqnarray} -\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \hypertarget{JUMP}{JUMP} \hypertarget{JUMPI}{JUMPI} \label{eq:mu_pc}\\ +\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \label{eq:mu_pc}\\ \quad \boldsymbol{\mu}'_{pc} & \equiv & \begin{cases} J_{\text{JUMP}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ J_{\text{JUMPI}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ @@ -2080,11 +2081,11 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} -\end{cases}$ \\ +\end{cases}$ \hypertarget{JUMP}{JUMP} \\ \midrule 0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ -&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ +&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \hypertarget{JUMPI}{JUMPI}\\ \midrule 0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ From b3c6dcb0aeee486a28bb02a6f6607f5797303650 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:54:35 +1100 Subject: [PATCH 117/335] sudo apt install texlive-latex-extra --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 7efafc8e..d2130c78 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,6 +2,7 @@ sudo: required before_install: - sudo apt-get -qq update - sudo apt-get install texlive texlive-latex3 +- sudo apt install texlive-latex-extra script: - ./build.sh deploy: From 0c26d26f5fed808b900569063741e065bd312874 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:57:29 +1100 Subject: [PATCH 118/335] Omit comments on longtable and tabularx --- Paper.tex | 7 ------- 1 file changed, 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index 13bd410a..cdadbb43 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,13 +22,6 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -%\usepackage{longtable} -%https://stackoverflow.com/questions/1918366/automated-line-breaks-in-latex-tables/1918465#1918465 -%tabularx seems better, but we can include this if we need tables to break across pages automatically, as well as tabu and longtabu - -%\usepackage{tabularx} -%https://stackoverflow.com/a/1919447/7438857 - % Tabu seems more flexible, and generally better. \usepackage{tabu} %requires array. From bbef522c828c129fb1b07f1e3526ebca279cadb9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:58:12 +1100 Subject: [PATCH 119/335] Omit comment on tabu --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index cdadbb43..9edecd58 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,6 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -% Tabu seems more flexible, and generally better. \usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} From dbbe44f4658f990962b26ee33c1aeb317a84b68c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 10:17:25 +1100 Subject: [PATCH 120/335] Add a space before \hypertarget in text mode to see if that will cause the build to pass. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1b200317..8701adf2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally:\hypertarget{Upsilon_state_transition}{Upsilon_state_transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon_state_transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From f297768d8db638ba47d935fa4a16578339a3d6e3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:19:52 +1100 Subject: [PATCH 121/335] omit network congestion --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 87b60e10..6df182db 100644 --- a/Paper.tex +++ b/Paper.tex @@ -482,7 +482,7 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up due to network congestion. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 22fae679888bf26547a89a6994df2b8477115467 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:26:50 +1100 Subject: [PATCH 122/335] Testing without underscores in the captions --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8701adf2..dff0800d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon_state_transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon state transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} @@ -195,7 +195,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: -\begin{description}\hypertarget{account_nonce}{account_nonce} +\begin{description}\hypertarget{account_nonce}{account nonce} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. From cee1a11f3ffbb38ab064f7e51ff8196110e1af13 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:34:46 +1100 Subject: [PATCH 123/335] Move \hypertarget{account_nonce}{account nonce} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index dff0800d..ba39f1f5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -193,9 +193,9 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. -The account state comprises the following four fields: +The account state comprises the following four fields:\hypertarget{account_nonce}{account nonce} -\begin{description}\hypertarget{account_nonce}{account nonce} +\begin{description} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. From c11db33dfe40a6c2c8e979c4c36dc90d604fd9a3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:50:09 +1100 Subject: [PATCH 124/335] Move \hypertarget{tx_nonce}{tx_nonce_T__n} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6a8d11bd..c4468568 100644 --- a/Paper.tex +++ b/Paper.tex @@ -252,9 +252,9 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx_nonce_T__n} -\begin{description}\hypertarget{tx_nonce}{tx_nonce_T__n} +\begin{description} \item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx_gas_price_T__p} \item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx_to_address_T__t} From b7d3fad2254f496e16edf0ddeb4deea7aeb44285 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:51:31 +1100 Subject: [PATCH 125/335] Move \hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d96e2048..68eb2623 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,11 +307,11 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} %\textit{TODO: Introduce logs} -\begin{description}\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} +\begin{description} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. \item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary_H__c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. From 5122b40882437f80bf089e08db5b756478b95103 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:54:16 +1100 Subject: [PATCH 126/335] Move \hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 68eb2623..c133b77b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -326,8 +326,8 @@ \subsection{The Block} \label{ch:block} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block_extraData_H__x} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block_nonce_H__n} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. -\end{description}\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} +\end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} From 19be698ac4ac9a96b0330d7932d251eef46df868 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:55:56 +1100 Subject: [PATCH 127/335] Omit underscores in captions --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index c4468568..2a8965cf 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account_validity_function_v__x} +where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account validity function v x} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx_nonce_T__n} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx nonce T n} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx_gas_price_T__p} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx gas price T p} \item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx_to_address_T__t} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx_value_T__v}{tx_value_T__v} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx to address T t} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{tx value T v} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From b8e7f78f726c86d3c0108f24c4c02470de4233fa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:56:43 +1100 Subject: [PATCH 128/335] Test a hypen in a caption --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba39f1f5..6d209925 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon state transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon-state transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From e90133a248b220dff5dc84398751b9738b16b241 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:13:50 +1100 Subject: [PATCH 129/335] Hypertargets for Omega, block-reward-R-b, Gamma, Phi and Pi --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..1d28711a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1093,7 +1093,7 @@ \subsection{Transaction Validation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{Omega} Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ @@ -1107,14 +1107,14 @@ \subsection{Reward Application} R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b \end{eqnarray} -If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. +If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively.\hypertarget{block-reward-R-b}{block-reward-R-b} We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_b = 3 \times 10^{18} \end{equation} -\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} +\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarget{Gamma}{Gamma} We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} @@ -1124,7 +1124,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure.\hypertarget{Phi}{Phi} And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} @@ -1160,7 +1160,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} We define $\mathbf{R}[n]_{s'}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{s'} = -\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\hypertarget{Pi}{Pi} \end{equation} Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From ddd8276c2b2655f39b82e1cbb7218091f5c57e6c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:16:55 +1100 Subject: [PATCH 130/335] Change underscores to spaces in hypertarget captions --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index c133b77b..6463fbfb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,26 +307,26 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent Hash H p def words} %\textit{TODO: Introduce logs} \begin{description} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary_H__c} +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary H c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. \item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts_Root_def_words} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs_Bloom_def_words} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs Bloom def words} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block_number_H_i} +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block number H i} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block_gas_used_H__g} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block_timestamp_H__s} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block_extraData_H__x} +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block gas used H g} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block timestamp H s} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block extraData H x} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block_nonce_H__n} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block nonce H n} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer block headers B U}{ommer_block_headers_B__U}\hypertarget{block_B}{block B} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: @@ -337,7 +337,7 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx_receipt_gas_used_R__u} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From fd3a67e16320ce80784a7d8399d46320cc251c75 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:20:30 +1100 Subject: [PATCH 131/335] Change underscores to spaces in hypertarget captions --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2a8965cf..42affba6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account validity function v x} +where $v$ is the account validity function:\hypertarget{account validity function v x}{account validity function v x} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -256,7 +256,7 @@ \subsection{The Transaction} \label{ch:transaction} \begin{description} \item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx gas price T p} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx gas limit T g} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx to address T t} \item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{tx value T v} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. From 68fc644d6c3f2b6f2041602502bf685b3b6bd456 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:22:30 +1100 Subject: [PATCH 132/335] Change underscores to spaces in hypertarget captions --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6463fbfb..6e1baea6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -316,7 +316,7 @@ \subsection{The Block} \label{ch:block} \item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary H c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts_Root_def_words} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts Root def words} \item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs Bloom def words} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. \item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block number H i} @@ -324,7 +324,7 @@ \subsection{The Block} \label{ch:block} \item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block gas used H g} \item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block timestamp H s} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block extraData H x} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash H m} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block nonce H n} \item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer block headers B U}{ommer_block_headers_B__U}\hypertarget{block_B}{block B} \end{description} @@ -332,12 +332,12 @@ \subsection{The Block} \label{ch:block} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\hypertarget{Transaction Receipt}{Transaction_Receipt} +\end{equation}\hypertarget{Transaction Receipt}{Transaction Receipt} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction receipt R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 47697453cd0493a612f3fe96ba66ea27b22c6986 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:31:09 +1100 Subject: [PATCH 133/335] Change captions to empty. --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index c794908e..de7a75a0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -389,11 +389,11 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} -\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{block_validity_H__r} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{Ommer_block_hash_H__o}\\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{tx_block_hash_H__t}\\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{Receipts_Root_H__e}\\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{logs_Bloom_filter_H__b}\\ +\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{} +H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{}\\ +H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{}\\ +H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{}\\ +H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{}\\ H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} From bba00722c9ebca3681204c42ccfd5605117053e2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:32:34 +1100 Subject: [PATCH 134/335] Empty caption --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6d209925..7e003c98 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon-state transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From 73f1d704a7918a00a6e5c0355bd3ca0820de95d7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:33:50 +1100 Subject: [PATCH 135/335] Change hypertarget captions to empty strings --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7e003c98..c0b05e34 100644 --- a/Paper.tex +++ b/Paper.tex @@ -179,7 +179,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \hypertarget{ell}{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \hypertarget{ell}{}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -193,7 +193,7 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. -The account state comprises the following four fields:\hypertarget{account_nonce}{account nonce} +The account state comprises the following four fields:\hypertarget{account_nonce}{} \begin{description} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. From 29b0eff528fc23a53352f2b769e742c8de8f2dae Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:55:17 +1100 Subject: [PATCH 136/335] Change hypertarget captions to empty strings --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index 42affba6..41cc281c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -232,9 +232,9 @@ \subsection{World State} \label{ch:state} This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} -\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) +\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\hypertarget{account validity function v x}{} \end{equation} -where $v$ is the account validity function:\hypertarget{account validity function v x}{account validity function v x} +where $v$ is the account validity function: \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx nonce T n} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx gas price T p} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx gas limit T g} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx to address T t} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{tx value T v} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 6bd7a7eee66267678f3c56cf55b8dd3f0366667c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:02:10 +1100 Subject: [PATCH 137/335] Change hypertarget captions to empty strings --- Paper.tex | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6e1baea6..42dc160f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,37 +307,37 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent Hash H p def words} +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{} %\textit{TODO: Introduce logs} \begin{description} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary H c} +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts Root def words} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs Bloom def words} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block number H i} +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block gas used H g} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block timestamp H s} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block extraData H x} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash H m} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block nonce H n} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer block headers B U}{ommer_block_headers_B__U}\hypertarget{block_B}{block B} +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}\hypertarget{block_B}{} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\hypertarget{Transaction Receipt}{Transaction Receipt} +\end{equation}\hypertarget{Transaction Receipt}{} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction receipt R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{}\hypertarget{tx_receipt_gas_used_R__u}{} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 20f1c3915e592950e8f0ed66893b1e6af00b9900 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:03:49 +1100 Subject: [PATCH 138/335] Change hypertarget captions to empty strings --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 09fe2e47..18310923 100644 --- a/Paper.tex +++ b/Paper.tex @@ -417,7 +417,7 @@ \subsubsection{Serialisation} \begin{eqnarray} \quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ \quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) -\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{general_element_wise_sequence_transformation_f_pow_asterisk} +\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{} With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} @@ -457,7 +457,7 @@ \subsubsection{Block Header Validity} \newcommand{\mindifficulty}{D_0} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} -\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{block_difficulty_H__d} +\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{} The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} @@ -485,7 +485,7 @@ \subsubsection{Block Header Validity} \begin{align} \expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ H'_i &\equiv \max(H_i - 3000000, 0) -\end{align}\hypertarget{block_gas_limit_H__l}{block_gas_limit_H__l} +\end{align}\hypertarget{block_gas_limit_H__l}{} The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 7978dff70e3ab90ce8c78379076b3672288aea3e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:05:34 +1100 Subject: [PATCH 139/335] Change hypertarget captions to empty strings --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 29c19138..55f8d2d6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -506,11 +506,11 @@ \subsubsection{Block Header Validity} \begin{equation} n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{block_header_without_nonce_and_mixmash_h__cancel_n} +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{} Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. -This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{block_header_validity_function} +This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{} Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} @@ -561,16 +561,16 @@ \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) -\end{equation}\hypertarget{self_destruct_set_wordy_defn}{self_destruct_set_wordy_defn} +\end{equation}\hypertarget{self_destruct_set_wordy_defn}{} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{tx_log_series_wordy_defn} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{refund_balance_defn_words} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn}{} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} -\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{intrinsic_gas_g_0} +\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{} We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ @@ -591,7 +591,7 @@ \subsection{Execution}\hypertarget{intrinsic_gas_g_0}{intrinsic_gas_g_0} \begin{equation} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ -\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{transaction_nonce}\\ +\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{}\\ T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ g_0 & \leqslant & T_g \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ From b76bcf34b69a33a1461b7ed9938a81d3699df539 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:07:00 +1100 Subject: [PATCH 140/335] Change hypertarget captions to empty strings --- Paper.tex | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6cb2ee8c..a1d36483 100644 --- a/Paper.tex +++ b/Paper.tex @@ -643,12 +643,12 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} -\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{self_destruct_list_A__s}\\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{touched_A__t}\\ +\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{}\\ +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{}\\ \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{tx_total_gas_used_Upsilon_pow_g}\hypertarget{tx_logs_Upsilon_pow_l}{tx_logs_Upsilon_pow_l}\hypertarget{tx_status_Upsilon_pow_s} +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{} And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ @@ -656,10 +656,9 @@ \subsection{Execution} \Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' \end{eqnarray} -These are used to help define the transaction receipt, discussed later. +These are used to help define the transaction receipt, discussed later.\hypertarget{endow}{} \section{Contract Creation} \label{ch:create} -\hypertarget{endow}{endow} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). From 4d76dbdc8f2894a6cf422bc43e027dd3685a3a19 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:08:31 +1100 Subject: [PATCH 141/335] Change hypertarget captions to empty strings --- Paper.tex | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3952b96e..6aa92535 100644 --- a/Paper.tex +++ b/Paper.tex @@ -868,16 +868,16 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: -\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{address_of_account_which_owns_code_I__a_def_words} -\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{address_of_sender_of_tx_that_originated_execution_I__o} -\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{gas_price_in_tx_that_originated_execution_I__p} -\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{execution_input_data_I__d} -\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s} -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{Wei_value_exec_I__v} -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{exec_machine_code_I__b} -\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{exec_block_header_I__H} +\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{} +\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{} +\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{} +\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{} +\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} +\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{} +\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{} +\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{} \item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{exec_call_or_create_depth_I__e} -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{exec_permission_to_modify_state_I__w} +\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{} \item $I_w$, the permission to make modifications to the state. \end{itemize} From bb543b2cc9f30ada50062712fc1107a659009809 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:27:03 +1100 Subject: [PATCH 142/335] Add a missing {} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 42dc160f..6e862de3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -326,7 +326,7 @@ \subsection{The Block} \label{ch:block} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}\hypertarget{block_B}{} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}{}\hypertarget{block_B}{} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: From ff6c7f4b0f9752cd1cfca3dac6f7170975891ac0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:28:29 +1100 Subject: [PATCH 143/335] Change hypertarget captions to empty strings --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6aa92535..ee46e867 100644 --- a/Paper.tex +++ b/Paper.tex @@ -876,7 +876,7 @@ \subsection{Execution Environment} \item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{} \item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{} \item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{} -\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{exec_call_or_create_depth_I__e} +\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{} \item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{} \item $I_w$, the permission to make modifications to the state. \end{itemize} From 981f9d1926b05f7c75c366bdbda75474ec994a01 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:31:29 +1100 Subject: [PATCH 144/335] Change hypertarget caption to empty string --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1382e779..c3decb03 100644 --- a/Paper.tex +++ b/Paper.tex @@ -942,7 +942,7 @@ \subsubsection{Machine State} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{Exceptional_Halting_function_Z} +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} The exceptional halting function $Z$ is defined as: \begin{equation} From 6c65fec06523c648c2b81dde5af3604f818ec548 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:31:57 +1100 Subject: [PATCH 145/335] Change hypertarget caption to empty string normal_halting_function_H --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 33223668..06b44484 100644 --- a/Paper.tex +++ b/Paper.tex @@ -993,7 +993,7 @@ \subsubsection{Jump Destination Validity} N(i, w) \equiv \begin{cases} i + w - \text{\small PUSH1} + 2 & \text{if} \quad w \in [\text{\small PUSH1}, \text{\small PUSH32}] \\ i + 1 & \text{otherwise} \end{cases} -\end{equation}\hypertarget{normal_halting_function_H}{normal_halting_function_H} +\end{equation}\hypertarget{normal_halting_function_H}{} \subsubsection{Normal Halting} From 10872584cc0c687372c9c943d31ddb8244882029 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:34:04 +1100 Subject: [PATCH 146/335] Fix ommer_block_headers_B__U hypertarget --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6e862de3..1bb5d7f4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -326,7 +326,7 @@ \subsection{The Block} \label{ch:block} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}{}\hypertarget{block_B}{} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{}\hypertarget{block_B}{} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: From 4cf588662b0f231a47736cd557725b5fbdd85c90 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:37:11 +1100 Subject: [PATCH 147/335] \hypertarget{empty_sequence_vs_empty_set}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..e87c80b5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -892,7 +892,7 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine.\hypertarget{empty_sequence_vs_empty_set}{} The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} From f1492b9616041882effeb3b3e61c4b167ec2e7c0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:47:24 +1100 Subject: [PATCH 148/335] Add a comment on using the hyperref package --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..241082e4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -28,6 +28,7 @@ \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . +% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. \input{Version.tex} From bd5f7ee7bbb051fc8e0fe7a0360a17ba3f7f762c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:53:49 +1100 Subject: [PATCH 149/335] Add a note on link borders. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index aa07f273..302f6977 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A ## Usage -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text. ## How to build From 6a312f0152c67bd1373218f8f944540e8ee312a2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:22:39 +1100 Subject: [PATCH 150/335] \hypertarget{rlp}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..b2fdf400 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1282,7 +1282,7 @@ \section{Terminology} \item[LLL] The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to. \end{description} - +\hypertarget{rlp}{} \section{Recursive Length Prefix}\label{app:rlp} This is a serialisation method for encoding arbitrarily structured binary data (byte arrays). From ec04330228366009e14317d828a3203809b967c1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:25:57 +1100 Subject: [PATCH 151/335] \hypertarget{R b}{ --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..5f04a3b2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1307,7 +1307,7 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the byte-array contains fewer than 56 bytes, then the output is equal to the input prefixed by the byte equal to the length of the byte array plus 128. \item Otherwise, the output is equal to the input prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the input byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183. \end{itemize} - +\hypertarget{R b}{} Formally, we define $R_b$: \begin{eqnarray} R_b(\mathbf{x}) & \equiv & \begin{cases} From 397b1c3b55ba898b9dc94139fcef4fa15d9faca4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:26:48 +1100 Subject: [PATCH 152/335] \hypertarget{R l}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..881057e5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1327,7 +1327,7 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} - +\hypertarget{R l}{} Thus we finish by formally defining $R_l$: \begin{eqnarray} R_l(\mathbf{x}) & \equiv & \begin{cases} From 0fd7d93608e34c141eec80b13251e6270c342911 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:27:41 +1100 Subject: [PATCH 153/335] \hypertarget{trie}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..4e58d71b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1362,7 +1362,7 @@ \section{Hex-Prefix Encoding}\label{app:hexprefix} \end{eqnarray} Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the second-lowest encoding the flag $t$. The low nibble of the first byte is zero in the case of an even number of nibbles and the first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining bytes. - +\hypertarget{trie}{} \section{Modified Merkle Patricia Tree}\label{app:trie} The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32 byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. From bd69e1f086a676dd686cfbd069fb335eeca8b7ac Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:29:29 +1100 Subject: [PATCH 154/335] \hypertarget{ECDSASIGN}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..8ee3bb68 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1639,7 +1639,7 @@ \section{Signing Transactions}\label{app:signing} We assert the functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. \begin{eqnarray} -\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \\ +\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \hypertarget{ECDSASIGN}{}\\ \mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_r \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} From 667312895ca26e8561c4b3afb32133b46f42c2e1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:30:36 +1100 Subject: [PATCH 155/335] \hypertarget{v}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..53988573 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1644,7 +1644,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which $r$ is the x-value; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The value 27 represents an even $y$ value and 28 represents an odd $y$ value. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the \hypertarget{v}{}aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which $r$ is the x-value; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The value 27 represents an even $y$ value and 28 represents an odd $y$ value. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} From 803f701b03eece3c2a1387d1d50fcf48504ef5ba Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:38:45 +1100 Subject: [PATCH 156/335] Add definitions for T_w, T_r and T_s (commented out, to be uncommented later) --- Paper.tex | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..c4191150 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1685,7 +1685,15 @@ \section{Signing Transactions}\label{app:signing} (T_w, T_r, T_s) = \mathtt{\small ECDSASIGN}(h(T), p_r) \end{eqnarray} -We may then define the sender function $S$ of the transaction as: +%Uncomment out after merging \hypertargets for v, r, and s. +%Thus: +%\begin{eqnarray}\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} +%T_{\mathrm{w}} = \hyperlink{v}{v}\\ +%T_{\mathrm{r}} = \hyperlink{r}{r}\\ +%T_{\mathrm{s}} = \hyperlink{s}{s} +%\end{eqnarray} + +We may then define the sender function $S$ of the transaction as:\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} \begin{eqnarray} S(T) &\equiv& \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), v_0, T_r, T_s) \big) \big) \\ v_0 &\equiv& \begin{cases} From be5f07f2e73d4beccd2f8271772e2cc9fb6f8d87 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:40:01 +1100 Subject: [PATCH 157/335] \hypertarget{h T}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..687d7928 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1664,7 +1664,7 @@ \section{Signing Transactions}\label{app:signing} \begin{equation} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} - +\hypertarget{h T}{} The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} From 3846671dc30d9836dfc399156b7a76425d26205e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:54:24 +1100 Subject: [PATCH 158/335] hypertargets for gas costs --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..876fc823 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1719,21 +1719,21 @@ \section{Fee Schedule}\label{app:fees} $G_{jumpdest}$ & 1 & Paid for a {\small JUMPDEST} operation. \\ $G_{sset}$ & 20000 & Paid for an {\small SSTORE} operation when the storage value is set to non-zero from zero. \\ $G_{sreset}$ & 5000 & Paid for an {\small SSTORE} operation when the storage value's zeroness remains unchanged or is set to zero. \\ -$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \\ -$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ +$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \hypertarget{Rselfdestruct}{}\\ +$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \hypertarget{Gselfdestruct}{}\\ $G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ $G_{create}$ & 32000 & Paid for a {\small CREATE} operation. \\ -$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \\ +$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \hypertarget{codedeposit}{}\\ $G_{call}$ & 700 & Paid for a {\small CALL} operation. \\ $G_{callvalue}$ & 9000 & Paid for a non-zero value transfer as part of the {\small CALL} operation. \\ -$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \\ +$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \hypertarget{Gnewaccount}{}\\ $G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\ $G_{exp}$ & 10 & Partial payment for an {\small EXP} operation. \\ $G_{expbyte}$ & 50 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\small EXP} operation. \\ -$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \\ -$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\\ -$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ -$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \\ +$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \hypertarget{Gtxcreate}{}\\ +$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\hypertarget{Gtxdatazero}{}\\ +$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \hypertarget{Gtxdatanonzero}{}\\ +$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \hypertarget{Gtransaction}{}\\ $G_{transaction}$ & 21000 & Paid for every transaction. \\ $G_{log}$ & 375 & Partial payment for a {\small LOG} operation. \\ $G_{logdata}$ & 8 & Paid for each byte in a {\small LOG} operation's data. \\ From 7040146b34014ef2f42392c904995e79bd6dabaf Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:04:47 +1100 Subject: [PATCH 159/335] move \hypertarget{Exceptional_Halting_function_Z}{exceptional halting} and 2 \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index c3decb03..a4fc8738 100644 --- a/Paper.tex +++ b/Paper.tex @@ -941,8 +941,8 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. - -\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} +\hypertarget{Exceptional_Halting_function_Z}{} +\subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: \begin{equation} @@ -2201,7 +2201,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting\\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_e = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_a]_b$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ @@ -2220,7 +2220,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ From 161fd92230201f958f91ed11d7f1c85ec2efad99 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:12:03 +1100 Subject: [PATCH 160/335] hypertargets for operations --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..db8eef10 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1848,7 +1848,7 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{0s: Stop and Arithmetic Operations}} \\ \multicolumn{5}{l}{All arithmetic is modulo $2^{256}$ unless otherwise noted. The zero-th power of zero $0^0$ is defined to be one.} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{stop}{}\\ 0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule 0x01 & {\small ADD} & 2 & 1 & Addition operation. \\ @@ -2018,7 +2018,7 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{blockhash}{BLOCKHASH}\\ 0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ @@ -2067,14 +2067,14 @@ \subsection{Instruction Set} &&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \hypertarget{SSTORE}{}\\ \midrule 0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \hypertarget{C tiny SSTORE}{}\\ &&&& $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} -\end{cases}$ \\ +\end{cases}$ \hypertarget{A r}{}\\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} @@ -2169,7 +2169,7 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ -\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ +\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\hypertarget{A l}{}\\ \multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ \multicolumn{5}{l}{$\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ @@ -2223,7 +2223,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ -&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ +&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \hypertarget{tiny CALL}{}\\ &&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ @@ -2248,7 +2248,7 @@ \subsection{Instruction Set} &&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ -&&&& same account as at present, simply that the code is overwritten.\\ +&&&& same account as at present, simply that the code is overwritten.\hypertarget{RETURN}{}\\ \midrule 0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ &&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ @@ -2283,7 +2283,7 @@ \subsection{Instruction Set} &&&& For the gas calculation, we use the memory expansion function, \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule -0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ +0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \hypertarget{selfdestruct}{}\\ \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ &&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ @@ -2297,7 +2297,7 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} -\end{cases}$ \\ +\end{cases}$ \hypertarget{C tiny SELFDESTRUCT}{}\\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} From 9f764d24193a49104141f378c7ef669573b957f8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:16:52 +1100 Subject: [PATCH 161/335] Delete comments on LLL This is already in the terminology list. --- Paper.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..53469e8d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2306,9 +2306,7 @@ \subsection{Instruction Set} \bottomrule \end{tabular*} -%\section{Low-level Lisp-like Language}\label{app:lll} -%The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. - +\hypertarget{GenesisBlock}{} \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: From 801b4f5b71298dc7f5e3aa6ebba475ea66a46db4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:18:20 +1100 Subject: [PATCH 162/335] \hypertarget{Jwordbytes}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..527c5932 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2308,7 +2308,7 @@ \subsection{Instruction Set} %\section{Low-level Lisp-like Language}\label{app:lll} %The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. - +\hypertarget{GenesisBlock}{} \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: @@ -2326,7 +2326,7 @@ \subsection{Definitions} \begin{tabular*}{\columnwidth}[h]{lrl} \toprule -Name & Value & Description \\ +Name & Value & Description \hypertarget{Jwordbytes}{}\\ \midrule $J_{wordbytes}$ & 4 & Bytes in word. \\ $J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ From d1a358d694ae35e89cc22b55fea403c7832453db Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:24:42 +1100 Subject: [PATCH 163/335] hypertargets for Ethash parameters --- Paper.tex | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..1afc5478 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2308,7 +2308,7 @@ \subsection{Instruction Set} %\section{Low-level Lisp-like Language}\label{app:lll} %The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. - +\hypertarget{GenesisBlock}{} \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: @@ -2328,16 +2328,16 @@ \subsection{Definitions} \toprule Name & Value & Description \\ \midrule -$J_{wordbytes}$ & 4 & Bytes in word. \\ -$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ -$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \\ -$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \\ -$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \\ -$J_{epoch}$ & 30000 & Blocks per epoch. \\ -$J_{mixbytes}$ & 128 & mix length in bytes. \\ -$J_{hashbytes}$ & 64 & Hash length in bytes. \\ -$J_{parents}$ & 256 & Number of parents of each dataset element. \\ -$J_{cacherounds}$ & 3 & Number of rounds in cache production. \\ +$J_{wordbytes}$ & 4 & Bytes in word. \hypertarget{Jdatasetinit}{}\\ +$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \hypertarget{Jdatasetgrowth}{}\\ +$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \hypertarget{Jcacheinit}{}\\ +$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \hypertarget{Jcachegrowth}{}\\ +$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \hypertarget{Jepoch}{}\\ +$J_{epoch}$ & 30000 & Blocks per epoch. \hypertarget{Jmixbytes}{}\\ +$J_{mixbytes}$ & 128 & mix length in bytes. \hypertarget{Jhashbytes}{}\\ +$J_{hashbytes}$ & 64 & Hash length in bytes. \hypertarget{Jparents}{}\\ +$J_{parents}$ & 256 & Number of parents of each dataset element. \\hypertarget{Jcacherounds}{}\ +$J_{cacherounds}$ & 3 & Number of rounds in cache production. \hypertarget{Jaccesses}{}\\ $J_{accesses}$ & 64 & Number of accesses in hashimoto loop. \\ \bottomrule \end{tabular*} @@ -2347,7 +2347,7 @@ \subsection{Size of dataset and cache} \begin{equation} E_{epoch}(H_i) = \left\lfloor\frac{H_i}{J_{epoch}}\right\rfloor \end{equation} -The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache. +The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache.\hypertarget{dsize}{} Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using \begin{equation} d_{size} = E_{prime}(J_{datasetinit} + J_{datasetgrowth} \cdot E_{epoch} - J_{mixbytes}, J_{mixbytes}) @@ -2407,7 +2407,7 @@ \subsubsection{Cache} \end{equation} Where a single round modifies each subset of the cache as follows: \begin{equation} - E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big) + E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big)\hypertarget{Ecacherounds}{} \end{equation} \begin{multline} E_{rmh}(\mathbf{x}, i) = \texttt{KEC512}(\mathbf{x'}[(i - 1 + n) \mod n] \oplus \mathbf{x'}[\mathbf{x'}[i][0] \mod n]) \\ From 2bc7acec62754baa6b8a945f0f344b6aa2fd668c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:27:10 +1100 Subject: [PATCH 164/335] \hypertarget{bigvee}{} move closing brace --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index f426e558..172073d5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2508,8 +2508,8 @@ \section{List of mathematical symbols}\label{app:symbols} \toprule Symbol & Latex Command & Description \\ \midrule -\hypertarget{bigvee}{ -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).}\\ +\hypertarget{bigvee}{} +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabularx} From 53dd071e63cc46b76a3a7c8a3115fd8ba356e84e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:28:05 +1100 Subject: [PATCH 165/335] Delete redundant empty line --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 172073d5..8df36cf5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2496,7 +2496,6 @@ \subsection{Proof-of-work function} \end{cases} \end{equation} - \section{Anomalies on the Main Network} \subsection{Deletion of an Account Despite Out-of-gas} From 0b518f65d5835158bea6f5d52dae0d08968e5342 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 20:50:06 +1100 Subject: [PATCH 166/335] Replace a double quote with two single quotes --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 393504ba..1a2482af 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2168,7 +2168,7 @@ \subsubsection{Full dataset calculation} \label{dataset} \end{equation} \subsection{Proof-of-work function} -Essentially, we maintain a ``mix" $J_{mixbytes}$ bytes wide, and repeatedly sequentially fetch $J_{mixbytes}$ bytes from the full dataset and use the $E_\text{\tiny FNV}$ function to combine it with the mix. $J_{mixbytes}$ bytes of sequential access are used so that each round of the algorithm always fetches a full page from RAM, minimizing translation lookaside buffer misses which ASICs would theoretically be able to avoid. +Essentially, we maintain a ``mix'' $J_{mixbytes}$ bytes wide, and repeatedly sequentially fetch $J_{mixbytes}$ bytes from the full dataset and use the $E_\text{\tiny FNV}$ function to combine it with the mix. $J_{mixbytes}$ bytes of sequential access are used so that each round of the algorithm always fetches a full page from RAM, minimizing translation lookaside buffer misses which ASICs would theoretically be able to avoid. If the output of this algorithm is below the desired target, then the nonce is valid. Note that the extra application of \texttt{KEC} at the end ensures that there exists an intermediate nonce which can be provided to prove that at least a small amount of work was done; this quick outer PoW verification can be used for anti-DDoS purposes. It also serves to provide statistical assurance that the result is an unbiased, 256 bit number. From e6e7250d3dae4215c974775759825567717cfac0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 21:13:06 +1100 Subject: [PATCH 167/335] Add a line break before a tx address so that it doesn't run over the margin. --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..1d3e13c8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2496,6 +2496,7 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} -At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +At block 2675119, in the transaction +\texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From c9fdebe15708510130790e3ae1046b1bd97b6e74 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 21:16:26 +1100 Subject: [PATCH 168/335] Remove parentheses surrounding the revision number in the title so that the text doesn't clash with the page number --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..9e6ecc8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -46,7 +46,7 @@ \newcommand*\ie{i.e.\@\xspace} %\renewcommand{\itemhook}{\setlength{\topsep}{0pt} \setlength{\itemsep}{0pt}\setlength{\leftmargin}{15pt}} -\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium revision (\YellowPaperVersionNumber{})}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium version \YellowPaperVersionNumber{}}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Parity\\ From d0f0f251ae52be35d67db6cb3ca2445003e0be6a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 12:50:48 +1100 Subject: [PATCH 169/335] Replace all _(\{[A-Z]+\b)([^\}]) with _{mathbf$1}$2... ...using Libre Open Office with match case and regular expressions ticked as options. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index c834c995..54766bda 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1075,7 +1075,7 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{mathbf{U} \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) \end{equation} where $k$ denotes the ``is-kin'' property: @@ -1108,7 +1108,7 @@ \subsection{Reward Application} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ \qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ -\qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber +\qquad\forall_{mathbf{U} \in B_\mathbf{U}}: \\ \nonumber \boldsymbol{\sigma}'[U_c] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} @@ -1383,7 +1383,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} When considering such a sequence, we use the common numeric subscript notation to refer to a tuple's key or value, thus: \begin{equation} -\forall_{I \in \mathfrak{I}} I \equiv (I_0, I_1) +\forall_{mathbf{I} \in \mathfrak{I}} I \equiv (I_0, I_1) \end{equation} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: @@ -1421,7 +1421,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{mathbf{I} \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} From 0bf4bd2bfc118f3aeaf8299ba07a425cfbb29a88 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:09:27 +1100 Subject: [PATCH 170/335] \PassOptionsToPackage{tabularx}\usepackage{tabu} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 75340cf4..0aa5cff9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,7 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -\usepackage{tabu} %requires array. +\PassOptionsToPackage{tabularx}\usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} From 4cf696a0e149a90e663bf32f14989fc08e713797 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:15:43 +1100 Subject: [PATCH 171/335] Add a missing closing brace --- Biblio.bib | 1 + 1 file changed, 1 insertion(+) diff --git a/Biblio.bib b/Biblio.bib index 9b4e0507..16581a2c 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -9,6 +9,7 @@ @Book{Davey2002_zbMATH01748069 Language = {English}, MSC2010 = {06-01}, Zbl = {1002.06001}, +} @Misc{EIP-100, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md", From eeaad7f59bb051b9d593d475ca08ac9bdf5f43fd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:16:16 +1100 Subject: [PATCH 172/335] Delete an empty line --- Biblio.bib | 1 - 1 file changed, 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 16581a2c..8f6a90f6 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -32,7 +32,6 @@ @Misc{EIP-2 title = "EIP-2: Homestead Hard-fork Changes", author = "Vitalik Buterin", year = "2015", - } @Misc{cryptoeprint:2013:881, From 446bee8a557de8f6091200b1784550f23cb956e7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:38:55 +1100 Subject: [PATCH 173/335] \begin{tabu}{X[l]X[c]X} \savetabu{col3} --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 0aa5cff9..ff1e5b58 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,7 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -\PassOptionsToPackage{tabularx}\usepackage{tabu} %requires array. +\usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} @@ -2508,13 +2508,13 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \section{List of mathematical symbols}\label{app:symbols} -\begin{tabularx}{\textwidth}{lcX} +\begin{tabu}{X[l]X[c]X} \savetabu{col3} \toprule Symbol & Latex Command & Description \\ \midrule \hypertarget{bigvee}{} $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule -\end{tabularx} +\end{tabu} \end{document} From 438d028048f8b3db43115ccc11ccbb203fe79abb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:45:17 +1100 Subject: [PATCH 174/335] Move \hypertarget{bigvee}{} to preceding line --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index ff1e5b58..8b221dda 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,9 +2510,8 @@ \subsection{Deletion of an Account Despite Out-of-gas} \section{List of mathematical symbols}\label{app:symbols} \begin{tabu}{X[l]X[c]X} \savetabu{col3} \toprule -Symbol & Latex Command & Description \\ +Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule -\hypertarget{bigvee}{} $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabu} From 6b6f6d804cb846597634e7b9ae905a51e246ab2a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:46:03 +1100 Subject: [PATCH 175/335] Remove parentheses --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8b221dda..88b339d7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2512,7 +2512,7 @@ \section{List of mathematical symbols}\label{app:symbols} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements \cite{Davey2002_zbMATH01748069}.\\ \bottomrule \end{tabu} From 02fe4c677011432f2b9092402fd1ce588974d2f8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 14:05:34 +1100 Subject: [PATCH 176/335] tabu* --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 88b339d7..f42b1081 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2508,7 +2508,7 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \section{List of mathematical symbols}\label{app:symbols} -\begin{tabu}{X[l]X[c]X} \savetabu{col3} +\begin{tabu*}{X[l]X[c]X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule From 375e99379783f28e2069ec2936b94870c58c8e30 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 14:11:44 +1100 Subject: [PATCH 177/335] \hyperlink{GenesisBlock}{the genesis block} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 527c5932..4842bc4c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -145,7 +145,7 @@ \subsection{Value} \subsection{Which History?} -Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (the genesis block) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. +Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (\hyperlink{GenesisBlock}{the genesis block}) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. This would mean that past a given point in time (block), multiple states of the system may coexist: some nodes believing one block to contain the canonical transactions, other nodes believing some other block to be canonical, potentially containing radically different or incompatible transactions. This is to be avoided at all costs as the uncertainty that would ensue would likely kill all confidence in the entire system. From 54f93493cd830de761495c4d86aacbfa19fa70a6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 14:13:38 +1100 Subject: [PATCH 178/335] \end{tabu*} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f42b1081..753cf2f3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2514,6 +2514,6 @@ \section{List of mathematical symbols}\label{app:symbols} \midrule $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements \cite{Davey2002_zbMATH01748069}.\\ \bottomrule -\end{tabu} +\end{tabu*} \end{document} From 03d79bca4d16717e91c903797d5c5cebe7a80a18 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 18:16:07 +1100 Subject: [PATCH 179/335] Omit yellowpaper.io as it is outdated. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 302f6977..63ce53be 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A ## Usage -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text. +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf. If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text. ## How to build From 8ad077cb861efafe82c30cfc93c056974289022a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 18:17:41 +1100 Subject: [PATCH 180/335] Update homestead block number and add Frontier. --- BRANCHES.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/BRANCHES.md b/BRANCHES.md index f52e3349..6f776007 100644 --- a/BRANCHES.md +++ b/BRANCHES.md @@ -8,4 +8,5 @@ Each protocol version is specified in `Paper.tex` found in a branch of this repo | spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Since 2,675,000 until 4,369,999 | | tangerine-whistle | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | Since 2,463,000 until 2,674,999 | | dao-fork | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | Since 1,920,000 until 2,462,000 | -| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | Since 1 until 1,919,999 | +| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | Since 1,150,000 until 1,919,999 | +| frontier | [Frontier](https://github.com/ethereum/yellowpaper/) | Since 1 until 1,149,999 | From fed380ae020523a18d49c033335409886bdbdf33 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 21:41:26 +1100 Subject: [PATCH 181/335] Add \nop command to modify hypertargets, and replace all \\hypertarget(\{.*\})\{\} with \nop$1 --- Paper.tex | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index c0b05e34..82a0c5be 100644 --- a/Paper.tex +++ b/Paper.tex @@ -29,6 +29,10 @@ % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . +\makeatletter + \newcommand{\nop}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} +\makeatother + \input{Version.tex} \newcommand{\hcancel}[1]{% @@ -101,7 +105,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \nop{Upsilon_state_transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} @@ -179,7 +183,8 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \hypertarget{ell}{}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. +op{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -193,7 +198,8 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. -The account state comprises the following four fields:\hypertarget{account_nonce}{} +The account state comprises the following four fields: +op{account_nonce} \begin{description} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. From fc45886a509b78c9bcd59a37181e6fa4687cf3b0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 21:45:31 +1100 Subject: [PATCH 182/335] Change linebreak op{ to \nop, and move \nop --- Paper.tex | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 82a0c5be..07cc9f39 100644 --- a/Paper.tex +++ b/Paper.tex @@ -105,9 +105,9 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \nop{Upsilon_state_transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) +\nop{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -183,8 +183,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. -op{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \nop{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -199,10 +198,9 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. The account state comprises the following four fields: -op{account_nonce} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. +\item[nonce] \nop{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_c$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. From ea2854723d25b5b93d344c57479779b3d23f4ccd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 22:52:53 +1100 Subject: [PATCH 183/335] Add line breaks which removes many empty lines --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c834c995..2dc6e184 100644 --- a/Paper.tex +++ b/Paper.tex @@ -187,7 +187,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. One of the more common is $\ell$, which g last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -709,7 +709,9 @@ \section{Contract Creation} \label{ch:create} \begin{equation} (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} + where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: + \begin{eqnarray} I_a & \equiv & a \\ I_o & \equiv & o \\ From d69717fcd0a7a3c7d59d4f3afd46b46d8dcbb1c7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 22:57:25 +1100 Subject: [PATCH 184/335] Fix accident --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2dc6e184..d1fb126f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -187,7 +187,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. One of the more common is $\ell$, which g last item in the given sequence: +I define a number of useful functions throughout. One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] From ca1309d664b8d766f3745b488abed4ec1930f9e2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 23:01:06 +1100 Subject: [PATCH 185/335] Remove unnecessary comment Given that these commands are after the hyperref package and haven't caused an issue, clearly this comment (to put them before) can be removed. --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c834c995..181a0833 100644 --- a/Paper.tex +++ b/Paper.tex @@ -35,7 +35,6 @@ \usepackage[english]{babel} \usepackage[autostyle]{csquotes} \MakeOuterQuote{"} -% Put before hyperref \input{Version.tex} From cf8ff0a78f5c74e40c54eb327a1911ab53dd2048 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 00:48:59 +1100 Subject: [PATCH 186/335] Add a \\ as a manual break --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1d3e13c8..7cdff15d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2497,6 +2497,6 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} At block 2675119, in the transaction -\texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +\texttt{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From 9b4a598423700d5a8b0c8e26f8b1aa2fed821c48 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 00:50:50 +1100 Subject: [PATCH 187/335] Replace \nop with \linkdest --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7d65cf7d..fdf60250 100644 --- a/Paper.tex +++ b/Paper.tex @@ -30,7 +30,7 @@ % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . \makeatletter - \newcommand{\nop}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} + \newcommand{\linkdest}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} \makeatother % For formatting %\usepackage{underscore} @@ -113,7 +113,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\nop{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) +\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -189,7 +189,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \nop{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -206,7 +206,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: \begin{description} -\item[nonce] \nop{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. +\item[nonce] \linkdest{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_c$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. From c63bb081a2d2b8ddfdecd34f23f4fa23e577e0ab Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 01:13:18 +1100 Subject: [PATCH 188/335] \usepackage{seqsplit} & \seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba} --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7cdff15d..9f5c84be 100644 --- a/Paper.tex +++ b/Paper.tex @@ -29,6 +29,8 @@ % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . +\usepackage{seqsplit} + \input{Version.tex} \newcommand{\hcancel}[1]{% @@ -2497,6 +2499,6 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} At block 2675119, in the transaction -\texttt{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +\seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From 886b206d09078bf18430a1f24c1c76dcdb772bf9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 01:13:51 +1100 Subject: [PATCH 189/335] Remove a line break --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9f5c84be..4956d894 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2498,7 +2498,6 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} -At block 2675119, in the transaction -\seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From 935c3f2f0a51bd40860ee8f92a744bbbe8f5826d Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Fri, 26 Jan 2018 15:00:25 +0000 Subject: [PATCH 190/335] Change s' to z for the status code. --- Paper.tex | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/Paper.tex b/Paper.tex index 292611dc..7302bf64 100644 --- a/Paper.tex +++ b/Paper.tex @@ -348,9 +348,9 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{z}$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) +R \equiv (R_u, R_b, R_\mathbf{l}, R_{z}) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: @@ -359,9 +359,9 @@ \subsubsection{Transaction Receipt} \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_{s'}$ is an integer. +We assert that the status code $R_{z}$ is an integer. \begin{equation} -R_{s'} \in \mathbb{P} +R_{z} \in \mathbb{P} \end{equation} We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): @@ -619,9 +619,9 @@ \subsection{Execution} \boldsymbol{\sigma}_0[S(T)]_n & \equiv & \boldsymbol{\sigma}[S(T)]_n + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $s'$: +Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} -(\boldsymbol{\sigma}_P, g', A, s') \equiv \begin{cases} +(\boldsymbol{\sigma}_P, g', A, z) \equiv \begin{cases} \Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ \Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} @@ -657,11 +657,11 @@ \subsection{Execution} \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: +And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{z}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ -\Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' +\Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} These are used to help define the transaction receipt, discussed later. @@ -672,7 +672,7 @@ \section{Contract Creation} \label{ch:create} We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas, accrued transaction substate and an error message $(\boldsymbol{\sigma}', g', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -736,7 +736,7 @@ \section{Contract Creation} \label{ch:create} The gas remaining will be zero in any such exceptional condition, \ie if the creation was conducted as the reception of a transaction, then this doesn't affect payment of the intrinsic cost of contract creation; it is paid regardless. However, the value of the transaction is not transferred to the aborted contract's address when we are out-of-gas. -If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, substate and status code as $(\boldsymbol{\sigma}', g', A, s')$ where: +If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, substate and status code as $(\boldsymbol{\sigma}', g', A, z)$ where: \begin{align} \quad g' &\equiv \begin{cases} @@ -750,7 +750,7 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ -\quad s' &\equiv \begin{cases} +\quad z &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ 1 & \text{otherwise} \end{cases} \\ @@ -770,7 +770,7 @@ \section{Message Call} \label{ch:call} Aside from evaluating to a new state and transaction substate, message calls also have an extra component---the output data denoted by the byte array $\mathbf{o}$. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. \begin{equation} -(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) +(\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) \end{equation} Note that we need to differentiate between the value that is to be transferred, $v$, from the value apparent in the execution context, $\tilde{v}$, for the {\small DELEGATECALL} instruction. @@ -818,7 +818,7 @@ \section{Message Call} \label{ch:call} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \ \wedge \ \mathbf{o} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ \nonumber -s' & \equiv & \begin{cases} +z & \equiv & \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ 1 & \text{otherwise} \end{cases} \\ @@ -1148,7 +1148,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{s'}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{z}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} \boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} @@ -1168,10 +1168,10 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -We define $\mathbf{R}[n]_{s'}$ in a similar manner. +We define $\mathbf{R}[n]_{z}$ in a similar manner. \begin{equation} -\mathbf{R}[n]_{s'} = -\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\mathbf{R}[n]_{z} = +\Upsilon^{z}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From aea9c61b314c6af5af754dec1b57456c560c2673 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Fri, 26 Jan 2018 20:32:57 +0000 Subject: [PATCH 191/335] Add missing introductory text for $\Upsilon^s$. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 292611dc..c4b53770 100644 --- a/Paper.tex +++ b/Paper.tex @@ -566,7 +566,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction and $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items, both to be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^s$ to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: From 62e6377e363d501686b9fe313ab7949c96034d13 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 29 Jan 2018 12:11:54 +0000 Subject: [PATCH 192/335] Tidy up change to $ for status code. --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7e0ac956..c6b245bf 100644 --- a/Paper.tex +++ b/Paper.tex @@ -352,9 +352,9 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{z}$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_{z}) +R \equiv (R_u, R_b, R_\mathbf{l}, R_z) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: @@ -363,9 +363,9 @@ \subsubsection{Transaction Receipt} \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_{z}$ is an integer. +We assert that the status code $R_z$ is an integer. \begin{equation} -R_{z} \in \mathbb{P} +R_z \in \mathbb{P} \end{equation} We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): @@ -570,7 +570,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^s$ to evaluate to the status code resulting from the transaction. These will be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^z$ to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: @@ -661,7 +661,7 @@ \subsection{Execution} \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{z}$, the status code of this transaction: +And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ @@ -1152,7 +1152,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{z}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_z$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} \boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} @@ -1172,10 +1172,10 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -We define $\mathbf{R}[n]_{z}$ in a similar manner. +We define $\mathbf{R}[n]_z$ in a similar manner. \begin{equation} -\mathbf{R}[n]_{z} = -\Upsilon^{z}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\mathbf{R}[n]_z = +\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From 984e4dae3321e6cb9d97cfdd884fdde3c30f9559 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:24:24 +1100 Subject: [PATCH 193/335] \label{ch:Terminology} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 753cf2f3..6d14c74c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1253,7 +1253,7 @@ \section{Availability} \appendix -\section{Terminology} +\section{Terminology} \label{ch:Terminology} \begin{description} \item[External Actor] A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum. It can interact with Ethereum through depositing signed Transactions and inspecting the blockchain and associated state. Has one (or more) intrinsic Accounts. From 15409f317e82ca93e08d89a605075bfd8c5da89f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:27:29 +1100 Subject: [PATCH 194/335] \linkdest, underscores --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 41cc281c..8f3da846 100644 --- a/Paper.tex +++ b/Paper.tex @@ -232,7 +232,7 @@ \subsection{World State} \label{ch:state} This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} -\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\hypertarget{account validity function v x}{} +\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\linkdest{account_validity_function_v__x}{} \end{equation} where $v$ is the account validity function: \begin{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\linkdest{tx_nonce}{} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\linkdest{tx_gas_price_T__p}{} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\linkdest{tx_gas_limit_T__g}{} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\linkdest{tx_to_address_T__t}{} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\linkdest{tx_value_T__v}{} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 8d52fd94a45c6148a020d5f454f503432c04ef43 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:30:24 +1100 Subject: [PATCH 195/335] move linkdest to same line --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8f3da846..60c5d0dd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -232,9 +232,9 @@ \subsection{World State} \label{ch:state} This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} -\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\linkdest{account_validity_function_v__x}{} +\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function: +\linkdest{account_validity_function_v__x}{}where $v$ is the account validity function: \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,14 +252,14 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\linkdest{tx_nonce}{} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\linkdest{tx_gas_price_T__p}{} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\linkdest{tx_gas_limit_T__g}{} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\linkdest{tx_to_address_T__t}{} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\linkdest{tx_value_T__v}{} -\item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. +\item[nonce]\linkdest{tx_nonce}{} A scalar value equal to the number of transactions sent by the sender; formally $T_n$. +\item[gasPrice]\linkdest{tx_gas_price_T__p}{} A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. +\item[gasLimit]\linkdest{tx_gas_limit_T__g}{} A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. +\item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.{} +\item[value]\linkdest{tx_value_T__v} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 6fe3b65fffb6857999f186a0da3f70079fedc4fa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:35:10 +1100 Subject: [PATCH 196/335] hypertarget => linkdest, move to same line --- Paper.tex | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1bb5d7f4..3a339c85 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,39 +307,39 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{} +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} \begin{description} -\item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{} -\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. +\item[parentHash]\linkdest{parent_Hash_H__p_def_words}{} The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$. +\item[beneficiary]\linkdest{beneficiary_H__c}{} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{} -\item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{} -\item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{}\hypertarget{block_B}{} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$. +\item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$. +\item[logsBloom]\linkdest{logs_Bloom_def_words}{} The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$. +\item[number]\linkdest{block_number_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$. +\item[gasUsed]\linkdest{block_gas_used_H__g}{} A scalar value equal to the total gas used in transactions in this block; formally $H_g$. +\item[timestamp]\linkdest{block_timestamp_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$. +\item[extraData]\linkdest{block_extraData_H__x}{} An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$. +\item[mixHash]\linkdest{mixHash_H__m}{} A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$. +\item[nonce]\linkdest{block_nonce_H__n}{} A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. \end{description} -The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: +\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\hypertarget{Transaction Receipt}{} +\end{equation}\linkdest{Transaction Receipt}{} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{}\hypertarget{tx_receipt_gas_used_R__u}{} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) \end{equation} From ba99a2af41d38fbbcf0bbb834f376d6579086b63 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:39:29 +1100 Subject: [PATCH 197/335] hypertarget => linkdest, move to same line --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index de7a75a0..7547d96e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -389,12 +389,12 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} -\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{}\\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{}\\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{}\\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{}\\ -H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) +\begin{array}[t]{lclc} +\linkdest{block_validity_H__r}{}H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +\linkdest{Ommer_block_hash_H__o}{}H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ +\linkdest{tx_block_hash_H__t}{}H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ +\linkdest{Receipts_Root_H__e}{}H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ +\linkdest{logs_Bloom_filter_H__b}{}H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} From 3270a9066c78c32149fe75eee0a66117c4625552 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:41:18 +1100 Subject: [PATCH 198/335] hypertarget: move to same line --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 18310923..7fb67b8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -417,9 +417,9 @@ \subsubsection{Serialisation} \begin{eqnarray} \quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ \quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) -\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{} +\end{eqnarray} -With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: +\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} @@ -457,9 +457,9 @@ \subsubsection{Block Header Validity} \newcommand{\mindifficulty}{D_0} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} -\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{} +\newcommand{\diffadjustment}{x} -The canonical difficulty of a block of header $H$ is defined as $D(H)$: +\hypertarget{block_difficulty_H__d}{}The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_i = 0\\ @@ -485,9 +485,9 @@ \subsubsection{Block Header Validity} \begin{align} \expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ H'_i &\equiv \max(H_i - 3000000, 0) -\end{align}\hypertarget{block_gas_limit_H__l}{} +\end{align} -The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: +\hypertarget{block_gas_limit_H__l}{}The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} & & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ & & H_l > {P(H)_H}_l - \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ From 31a86388ce55994935aeeb2eddf9bed7588203aa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:51:15 +1100 Subject: [PATCH 199/335] hypertarget: move to the same line as targeted text, change to linkdest where not in text mode --- Paper.tex | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index a1d36483..723dff4a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -643,22 +643,21 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} -\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{}\\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{}\\ -\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) +\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ +\linkdest{self_destruct_list_A__s}{}\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\linkdest{touched_A__t}{}\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{}And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ \Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' \end{eqnarray} -These are used to help define the transaction receipt, discussed later.\hypertarget{endow}{} +These are used to help define the transaction receipt, discussed later. -\section{Contract Creation} \label{ch:create} +\section{Contract Creation}\label{ch:create}\hypertarget{endow}{} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). From 8b795654bcb9c386b390f6c47def07945be94dbd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:52:46 +1100 Subject: [PATCH 200/335] hypertarget: move to the same line as targeted text, change to linkdest where not in text mode --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index 55f8d2d6..c390c9f8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -506,13 +506,13 @@ \subsubsection{Block Header Validity} \begin{equation} n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{} +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. -Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. +\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. -This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{} +This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. -Thus we are able to define the block header validity function $V(H)$: +\hypertarget{block_header_validity_function}{}Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} V(H) & \equiv & n \leqslant \frac{2^{256}}{H_d} \wedge m = H_m \quad \wedge \\ & & H_d = D(H) \quad \wedge \\ @@ -561,17 +561,17 @@ \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) -\end{equation}\hypertarget{self_destruct_set_wordy_defn}{} +\end{equation} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn}{} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} -\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{} -We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: +\subsection{Execution} +\hypertarget{intrinsic_gas_g_0}{}We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ {} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_t = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ @@ -591,8 +591,8 @@ \subsection{Execution}\hypertarget{intrinsic_gas_g_0}{} \begin{equation} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ -\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{}\\ -T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ +\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \\ +\linkdest{transaction_nonce}{}T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ g_0 & \leqslant & T_g \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ T_g & \leqslant & {B_H}_l - \ell(B_\mathbf{R})_u From b9dab3a9e2504b8883de4d964e7256741a4d4f0e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:56:17 +1100 Subject: [PATCH 201/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index ee46e867..94aef879 100644 --- a/Paper.tex +++ b/Paper.tex @@ -868,17 +868,17 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: -\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{} -\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{} -\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{} -\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{} -\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{} -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{} -\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{} -\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{} -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{} -\item $I_w$, the permission to make modifications to the state. +\begin{itemize} +\item\linkdest{address_of_account_which_owns_code_I__a_def_words}{} $I_a$, the address of the account which owns the code that is executing. +\item\linkdest{address_of_sender_of_tx_that_originated_execution_I__o}{} $I_o$, the sender address of the transaction that originated this execution. +\item\linkdest{gas_price_in_tx_that_originated_execution_I__p}{} $I_p$, the price of gas in the transaction that originated this execution. +\item\linkdest{execution_input_data_I__d}{} $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. +\item\linkdest{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. +\item\linkdest{Wei_value_exec}{} $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. +\item\linkdest{exec_machine_code_I__b}{} $I_\mathbf{b}$, the byte array that is the machine code to be executed. +\item\linkdest{exec_block_header_I__H}{} $I_H$, the block header of the present block. +\item\linkdest{exec_call_or_create_depth_I__e}{} $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item\linkdest{exec_permission_to_modify_state_I__w}{} $I_w$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: From f7b6cef0cee9e71e0d06d1282e3c4a5ea87e7fea Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:59:30 +1100 Subject: [PATCH 202/335] Move \hypertarget{normal_halting_function_H}{} move to the same line as the targeted text --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 06b44484..804b1e00 100644 --- a/Paper.tex +++ b/Paper.tex @@ -993,9 +993,9 @@ \subsubsection{Jump Destination Validity} N(i, w) \equiv \begin{cases} i + w - \text{\small PUSH1} + 2 & \text{if} \quad w \in [\text{\small PUSH1}, \text{\small PUSH32}] \\ i + 1 & \text{otherwise} \end{cases} -\end{equation}\hypertarget{normal_halting_function_H}{} +\end{equation} -\subsubsection{Normal Halting} +\subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} The normal halting function $H$ is defined: \begin{equation} From 1b64c15a5e64fe8f2a564e0971593e1161956d60 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:01:08 +1100 Subject: [PATCH 203/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3dbeb89a..8fe68913 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2081,13 +2081,13 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} -\end{cases}$ \hypertarget{JUMP}{JUMP} \\ +\end{cases}$ \\ \midrule -0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ +\linkdest{JUMP}{JUMP}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ -&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \hypertarget{JUMPI}{JUMPI}\\ +&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. {JUMPI}\\ \midrule -0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ +\linkdest{JUMPI}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ \midrule From 0539df71678f4dc3eb0b4da84259fe37f6436d86 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:02:23 +1100 Subject: [PATCH 204/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1d28711a..1d4bf056 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1107,16 +1107,16 @@ \subsection{Reward Application} R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b \end{eqnarray} -If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively.\hypertarget{block-reward-R-b}{block-reward-R-b} +If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -We define the block reward as 3 Ether: +\hypertarget{block-reward-R-b}{block-reward-R-b}We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_b = 3 \times 10^{18} \end{equation} -\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarget{Gamma}{Gamma} +\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} -We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: +\hypertarget{Gamma}{Gamma}We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_H) = \varnothing \\ @@ -1124,9 +1124,9 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarg \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure.\hypertarget{Phi}{Phi} +Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. -And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: +\hypertarget{Phi}{Phi}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ B'_n & = & n: \quad x \leqslant \frac{2^{256}}{H_d} \\ @@ -1160,10 +1160,10 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarg We define $\mathbf{R}[n]_{s'}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{s'} = -\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\hypertarget{Pi}{Pi} +\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: +\hypertarget{Pi}{Pi}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: \begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} From 2421e9234789ab5895d96ea03e00bcb11a8f9d1f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:03:58 +1100 Subject: [PATCH 205/335] Remove {JUMPI} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8fe68913..d5dc4aa0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2085,7 +2085,7 @@ \subsection{Instruction Set} \midrule \linkdest{JUMP}{JUMP}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ -&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. {JUMPI}\\ +&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}.\\ \midrule \linkdest{JUMPI}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ From 165242a13a1fdb58d307f27fd6ce21da4685ca18 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:05:18 +1100 Subject: [PATCH 206/335] hypertarget: move to the same line as the targeted text --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e87c80b5..1dae9130 100644 --- a/Paper.tex +++ b/Paper.tex @@ -892,9 +892,9 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine.\hypertarget{empty_sequence_vs_empty_set}{} +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. -The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. +\hypertarget{empty_sequence_vs_empty_set}{}The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} \Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ (\boldsymbol{\sigma}', \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ From 83731d028a78aff2eba86a0e5f42190d27e41de1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:08:12 +1100 Subject: [PATCH 207/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8ee3bb68..7363963d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1639,8 +1639,8 @@ \section{Signing Transactions}\label{app:signing} We assert the functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. \begin{eqnarray} -\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \hypertarget{ECDSASIGN}{}\\ -\mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_r \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ +\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \\ +\linkdest{ECDSASIGN}{}\mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_r \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} From dc6a5b40de7eb2e7d1dbc3b3074f6d8f38332004 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:13:55 +1100 Subject: [PATCH 208/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index 876fc823..85f92d44 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1719,22 +1719,22 @@ \section{Fee Schedule}\label{app:fees} $G_{jumpdest}$ & 1 & Paid for a {\small JUMPDEST} operation. \\ $G_{sset}$ & 20000 & Paid for an {\small SSTORE} operation when the storage value is set to non-zero from zero. \\ $G_{sreset}$ & 5000 & Paid for an {\small SSTORE} operation when the storage value's zeroness remains unchanged or is set to zero. \\ -$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \hypertarget{Rselfdestruct}{}\\ -$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \hypertarget{Gselfdestruct}{}\\ -$G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ +$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. +\linkdest{R__selfdestruct}{}\\$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ +\linkdest{G__selfdestruct}{}$G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ $G_{create}$ & 32000 & Paid for a {\small CREATE} operation. \\ -$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \hypertarget{codedeposit}{}\\ +\linkdest{G__codedeposit}{}$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \\ $G_{call}$ & 700 & Paid for a {\small CALL} operation. \\ $G_{callvalue}$ & 9000 & Paid for a non-zero value transfer as part of the {\small CALL} operation. \\ -$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \hypertarget{Gnewaccount}{}\\ -$G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\ +$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \\ +\linkdest{G__newaccount}{}$G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\ $G_{exp}$ & 10 & Partial payment for an {\small EXP} operation. \\ $G_{expbyte}$ & 50 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\small EXP} operation. \\ -$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \hypertarget{Gtxcreate}{}\\ -$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\hypertarget{Gtxdatazero}{}\\ -$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \hypertarget{Gtxdatanonzero}{}\\ -$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \hypertarget{Gtransaction}{}\\ -$G_{transaction}$ & 21000 & Paid for every transaction. \\ +$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \\ +\linkdest{G__txcreate}{}$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\\ +\linkdest{G__txdatazero}{}$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ +\linkdest{G__txdatanonzero}{}$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \\ +\linkdest{G__transaction}{}$G_{transaction}$ & 21000 & Paid for every transaction. \\ $G_{log}$ & 375 & Partial payment for a {\small LOG} operation. \\ $G_{logdata}$ & 8 & Paid for each byte in a {\small LOG} operation's data. \\ $G_{logtopic}$ & 375 & Paid for each topic of a {\small LOG} operation. \\ From 47bdb284c42b4ffb7c5214551bad2a311c0f2391 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:14:32 +1100 Subject: [PATCH 209/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index db8eef10..32bda831 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1848,8 +1848,8 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{0s: Stop and Arithmetic Operations}} \\ \multicolumn{5}{l}{All arithmetic is modulo $2^{256}$ unless otherwise noted. The zero-th power of zero $0^0$ is defined to be one.} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{stop}{}\\ -0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\linkdest{stop}{}0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule 0x01 & {\small ADD} & 2 & 1 & Addition operation. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1]$ \\ From cd23eb1676c549abce2659a97caa7660b6493643 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:17:05 +1100 Subject: [PATCH 210/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Paper.tex b/Paper.tex index 32bda831..8e787a75 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2018,8 +2018,8 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{blockhash}{BLOCKHASH}\\ -0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\linkdest{blockhash}{BLOCKHASH}0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ @@ -2067,15 +2067,15 @@ \subsection{Instruction Set} &&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \hypertarget{SSTORE}{}\\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ \midrule -0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \hypertarget{C tiny SSTORE}{}\\ -&&&& $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +\linkdest{SSTORE}{}0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ +&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&&\linkdest{C tiny SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} -\end{cases}$ \hypertarget{A r}{}\\ -&&&& $A'_{r} \equiv A_{r} + \begin{cases} +\end{cases}$ \\ +&&&& \linkdest{A r}{}$A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ @@ -2169,8 +2169,8 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ -\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\hypertarget{A l}{}\\ -\multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ +\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ +\multicolumn{5}{l}\linkdest{A l}{}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ \multicolumn{5}{l}{$\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ \multicolumn{5}{l}{The entry's topic series, $\mathbf{t}$, differs accordingly:}\vspace{5pt} \\ @@ -2223,8 +2223,8 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ -&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \hypertarget{tiny CALL}{}\\ -&&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ +&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ +&&&&\linkdest{tiny CALL}{} $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} @@ -2248,9 +2248,9 @@ \subsection{Instruction Set} &&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ -&&&& same account as at present, simply that the code is overwritten.\hypertarget{RETURN}{}\\ +&&&& same account as at present, simply that the code is overwritten.\\ \midrule -0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ +\linkdest{RETURN}{}0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ &&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ &&&& This has the effect of halting the execution at this point with output defined.\\ &&&& See section \ref{ch:model}. \\ @@ -2283,9 +2283,9 @@ \subsection{Instruction Set} &&&& For the gas calculation, we use the memory expansion function, \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule -0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \hypertarget{selfdestruct}{}\\ +0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule -0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ +\linkdest{selfdestruct}{}0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ &&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ &&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_a]_b = 0\\ @@ -2297,8 +2297,8 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} -\end{cases}$ \hypertarget{C tiny SELFDESTRUCT}{}\\ -&&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} +\end{cases}$ \\ +&&&&\linkdest{C tiny SELFDESTRUCT}{} $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ From 1ef52f26b181f8e67a7d9792eadb47f1bfa3bf51 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:18:16 +1100 Subject: [PATCH 211/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode Jwordbytes --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4842bc4c..6a53cc66 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2326,9 +2326,9 @@ \subsection{Definitions} \begin{tabular*}{\columnwidth}[h]{lrl} \toprule -Name & Value & Description \hypertarget{Jwordbytes}{}\\ +Name & Value & Description \\ \midrule -$J_{wordbytes}$ & 4 & Bytes in word. \\ +\linkdest{Jwordbytes}{}$J_{wordbytes}$ & 4 & Bytes in word. \\ $J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ $J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \\ $J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \\ From 3d884fc6e262a1caedbf2326c057b46902e66d76 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:29:49 +1100 Subject: [PATCH 212/335] Find and replace all _([:alpha:][:alnum:]*) with _{\mathrm{$1}} --- Paper.tex | 740 +++++++++++++++++++++++++++--------------------------- 1 file changed, 370 insertions(+), 370 deletions(-) diff --git a/Paper.tex b/Paper.tex index c6b245bf..fa51a9f0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -28,7 +28,7 @@ \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . -% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. +% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_{\mathrm{and}}_{\mathrm{Hypertarget}}. \makeatletter \newcommand{\linkdest}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} @@ -116,7 +116,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) +\linkdest{Upsilon_{\mathrm{state}}_{\mathrm{transition}}}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -127,7 +127,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Formally, we expand to: \begin{eqnarray} -\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_t, B) \\ +\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{\mathrm{t}}, B) \\ B & \equiv & (..., (T_0, T_1, ...) ) \\ \Pi(\boldsymbol{\sigma}, B) & \equiv & \Omega(B, \Upsilon(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \end{eqnarray} @@ -176,7 +176,7 @@ \section{Conventions}\label{ch:conventions} For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. -Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_n$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. +Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a transaction nonce. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. @@ -209,20 +209,20 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: \begin{description} -\item[nonce] \linkdest{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. -\item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. -\item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. -\item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_c$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. +\item[nonce] \linkdest{account_{\mathrm{nonce}}}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{n}}$. +\item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{b}}$. +\item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{s}}$. +\item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{c}}$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_{\mathrm{c}}$. \end{description} Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: \begin{equation} -\texttt{\small TRIE}\big(L_I^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_s +\texttt{\small TRIE}\big(L_{\mathrm{I}}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} -The collapse function for the set of key/value pairs in the trie, $L_I^*$, is defined as the element-wise transformation of the base function $L_I$, given as: +The collapse function for the set of key/value pairs in the trie, $L_{\mathrm{I}}^*$, is defined as the element-wise transformation of the base function $L_{\mathrm{I}}$, given as: \begin{equation} -L_I\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) +L_{\mathrm{I}}\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) \end{equation} where: @@ -232,29 +232,29 @@ \subsection{World State} \label{ch:state} It shall be understood that $\boldsymbol{\sigma}[a]_\mathbf{s}$ is not a `physical' member of the account and does not contribute to its later serialisation. -If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. +If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. -Thus we may define a world-state collapse function $L_S$: +Thus we may define a world-state collapse function $L_{\mathrm{S}}$: \begin{equation} -L_S(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} +L_{\mathrm{S}}(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} \end{equation} where \begin{equation} -p(a) \equiv \big(\texttt{\small KEC}(a), \texttt{\small RLP}\big( (\boldsymbol{\sigma}[a]_n, \boldsymbol{\sigma}[a]_b, \boldsymbol{\sigma}[a]_s, \boldsymbol{\sigma}[a]_c) \big) \big) +p(a) \equiv \big(\texttt{\small KEC}(a), \texttt{\small RLP}\big( (\boldsymbol{\sigma}[a]_{\mathrm{n}}, \boldsymbol{\sigma}[a]_{\mathrm{b}}, \boldsymbol{\sigma}[a]_{\mathrm{s}}, \boldsymbol{\sigma}[a]_{\mathrm{c}}) \big) \big) \end{equation} -This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: +This function, $L_{\mathrm{S}}$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} where $v$ is the account validity function: \begin{equation} -\quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} +\quad v(x) \equiv x_{\mathrm{n}} \in \mathbb{P}_{256} \wedge x_{\mathrm{b}} \in \mathbb{P}_{256} \wedge x_{\mathrm{s}} \in \mathbb{B}_{32} \wedge x_{\mathrm{c}} \in \mathbb{B}_{32} \end{equation} An account is \textit{empty} when it has no code, zero nonce and zero balance: \begin{equation} -\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 +\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_{\mathrm{n}} = 0 \wedge \boldsymbol{\sigma}[a]_{\mathrm{b}} = 0 \end{equation} Even callable precompiled contracts can have an empty account state. This is because their account states do not usually contain the code describing its behavior. @@ -268,12 +268,12 @@ \subsection{The Transaction} \label{ch:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$. -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$. -\item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. -\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_{\mathrm{n}}$. +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_{\mathrm{p}}$. +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. +\item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. +\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$. This is expanded in Appendix \ref{app:signing}. \end{description} Additionally, a contract creation transaction contains: @@ -293,28 +293,28 @@ \subsection{The Transaction} \label{ch:transaction} Appendix \ref{app:signing} specifies the function, $S$, which maps transactions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction $T$ can be represented with $S(T)$. \begin{equation} -L_T(T) \equiv \begin{cases} -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{i}, T_w, T_r, T_s) & \text{if} \; T_t = \varnothing\\ -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}, T_w, T_r, T_s) & \text{otherwise} +L_{\mathrm{T}}(T) \equiv \begin{cases} +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{i}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{d}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} \end{equation} Here, we assume all components are interpreted by the RLP as integer values, with the exception of the arbitrary length byte arrays $T_\mathbf{i}$ and $T_\mathbf{d}$. \begin{equation} \begin{array}[t]{lclclc} -T_n \in \mathbb{P}_{256} & \wedge & T_v \in \mathbb{P}_{256} & \wedge & T_p \in \mathbb{P}_{256} & \wedge \\ -T_g \in \mathbb{P}_{256} & \wedge & T_w \in \mathbb{P}_5 & \wedge & T_r \in \mathbb{P}_{256} & \wedge \\ -T_s \in \mathbb{P}_{256} & \wedge & T_\mathbf{d} \in \mathbb{B} & \wedge & T_\mathbf{i} \in \mathbb{B} +T_{\mathrm{n}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{v}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{p}} \in \mathbb{P}_{256} & \wedge \\ +T_{\mathrm{g}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{w}} \in \mathbb{P}_5 & \wedge & T_{\mathrm{r}} \in \mathbb{P}_{256} & \wedge \\ +T_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge & T_\mathbf{d} \in \mathbb{B} & \wedge & T_\mathbf{i} \in \mathbb{B} \end{array} \end{equation} where \begin{equation} -\mathbb{P}_n = \{ P: P \in \mathbb{P} \wedge P < 2^n \} +\mathbb{P}_{\mathrm{n}} = \{ P: P \in \mathbb{P} \wedge P < 2^n \} \end{equation} The address hash $T_\mathbf{t}$ is slightly different: it is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to $\varnothing$), it is the RLP empty byte sequence and thus the member of $\mathbb{B}_0$: \begin{equation} -T_\mathbf{t} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_t \neq \varnothing \\ +T_\mathbf{t} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} @@ -325,67 +325,67 @@ \subsection{The Block} \label{ch:block} %\textit{TODO: Introduce logs} \begin{description} -\item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$. -\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. -\item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$. -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$. -\item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$. -\item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$. -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$. -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$. -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$. -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$. -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. +\item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_{\mathrm{p}}$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. +\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. +\item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_{\mathrm{r}}$. +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_{\mathrm{t}}$. +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. +\item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_{\mathrm{b}}$. +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_{\mathrm{d}}$. +\item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_{\mathrm{i}}$. +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_{\mathrm{l}}$. +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_{\mathrm{s}}$. +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_{\mathrm{x}}$. +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{m}}$. +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{n}}$. \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{\mathrm{H}}, B_\mathbf{T}, B_\mathbf{U}) \end{equation} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_z) +R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) \end{equation} -The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: +The function $L_{\mathrm{R}}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_R(R) \equiv (0 \in \mathbb{B}_{256}, R_u, R_b, R_\mathbf{l}) +L_{\mathrm{R}}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_z$ is an integer. +We assert that the status code $R_{\mathrm{z}}$ is an integer. \begin{equation} -R_z \in \mathbb{P} +R_{\mathrm{z}} \in \mathbb{P} \end{equation} -We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): +We assert $R_{\mathrm{u}}$, the cumulative gas used is a positive integer and that the logs Bloom, $R_{\mathrm{b}}$, is a hash of size 2048 bits (256 bytes): \begin{equation} -R_u \in \mathbb{P} \quad \wedge \quad R_b \in \mathbb{B}_{256} +R_{\mathrm{u}} \in \mathbb{P} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \end{equation} -%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_B$; it is merely a convenience equivalence. +%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{\mathrm{B}}$; it is merely a convenience equivalence. -The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_a$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_{\mathrm{a}}$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} -O \equiv (O_a, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) +O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} \begin{equation} -O_a \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_\mathbf{t}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_\mathbf{d} \in \mathbb{B} +O_{\mathrm{a}} \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_\mathbf{t}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_\mathbf{d} \in \mathbb{B} \end{equation} We define the Bloom filter function, $M$, to reduce a log entry into a single 256-byte hash: \begin{equation} -M(O) \equiv \bigvee_{t \in \{O_a\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) +M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) \end{equation} where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence./footnote{11 bits $= 2^2048$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: @@ -396,18 +396,18 @@ \subsubsection{Transaction Receipt} m(\mathbf{x}, i) &\equiv& \mathtt{\tiny KEC}(\mathbf{x})[i, i + 1] \bmod 2048 \end{eqnarray} -where $\mathcal{B}$ is the bit reference function such that $\mathcal{B}_j(\mathbf{x})$ equals the bit of index $j$ (indexed from 0) in the byte array $\mathbf{x}$. +where $\mathcal{B}$ is the bit reference function such that $\mathcal{B}_{\mathrm{j}}(\mathbf{x})$ equals the bit of index $j$ (indexed from 0) in the byte array $\mathbf{x}$. \subsubsection{Holistic Validity} -We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: +We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: \begin{equation} \begin{array}[t]{lclc} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ -H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) +H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_{\mathrm{S}}(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}^*(B_\mathbf{U}))) & \wedge \\ +H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{T}}(B_\mathbf{T}[i]))\}) & \wedge \\ +H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{R}}(B_\mathbf{R}[i]))\}) & \wedge \\ +H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} @@ -418,22 +418,22 @@ \subsubsection{Holistic Validity} Furthermore: \begin{equation} -\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma})) = {P(B_H)_H}_r +\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} \end{equation} -Thus $\texttt{\small TRIE}(L_S(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_H)$ is the parent block of $B$, defined directly. +Thus $\texttt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{\mathrm{H}})$ is the parent block of $B$, defined directly. The values stemming from the computation of transactions, specifically the transaction receipts, $B_\mathbf{R}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} -The function $L_B$ and $L_H$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_R$, we assert the types and order of the structure for when the RLP transformation is required: +The function $L_{\mathrm{B}}$ and $L_{\mathrm{H}}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{\mathrm{R}}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} -\quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ -\quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) +\quad L_{\mathrm{H}}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ +\quad L_{\mathrm{B}}(B) & \equiv & \big( L_{\mathrm{H}}(B_{\mathrm{H}}), L_{\mathrm{T}}^*(B_\mathbf{T}), L_{\mathrm{H}}^*(B_\mathbf{U}) \big) \end{eqnarray} -With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: +With $L_{\mathrm{T}}^*$ and $L_{\mathrm{H}}^*$ being element-wise sequence transformations, thus: \begin{equation} f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} @@ -441,31 +441,31 @@ \subsubsection{Serialisation} The component types are defined thus: \begin{equation} \begin{array}[t]{lclclcl} -H_p \in \mathbb{B}_{32} & \wedge & H_o \in \mathbb{B}_{32} & \wedge & H_c \in \mathbb{B}_{20} & \wedge \\ -H_r \in \mathbb{B}_{32} & \wedge & H_t \in \mathbb{B}_{32} & \wedge & H_e \in \mathbb{B}_{32} & \wedge \\ -H_b \in \mathbb{B}_{256} & \wedge & H_d \in \mathbb{P} & \wedge & H_i \in \mathbb{P} & \wedge \\ -H_l \in \mathbb{P} & \wedge & H_g \in \mathbb{P} & \wedge & H_s \in \mathbb{P}_{256} & \wedge \\ -H_x \in \mathbb{B} & \wedge & H_m \in \mathbb{B}_{32} & \wedge & H_n \in \mathbb{B}_{8} +H_{\mathrm{p}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ +H_{\mathrm{r}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{e}} \in \mathbb{B}_{32} & \wedge \\ +H_{\mathrm{b}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{P} & \wedge & H_{\mathrm{i}} \in \mathbb{P} & \wedge \\ +H_{\mathrm{l}} \in \mathbb{P} & \wedge & H_{\mathrm{g}} \in \mathbb{P} & \wedge & H_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge \\ +H_{\mathrm{x}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{n}} \in \mathbb{B}_{8} \end{array} \end{equation} where \begin{equation} -\mathbb{B}_n = \{ B: B \in \mathbb{B} \wedge \lVert B \rVert = n \} +\mathbb{B}_{\mathrm{n}} = \{ B: B \in \mathbb{B} \wedge \lVert B \rVert = n \} \end{equation} We now have a rigorous specification for the construction of a formal block structure. The RLP function $\texttt{\small RLP}$ (see Appendix \ref{app:rlp}) provides the canonical method for transforming this structure into a sequence of bytes ready for transmission over the wire or storage locally. \subsubsection{Block Header Validity} -We define $P(B_H)$ to be the parent block of $B$, formally: +We define $P(B_{\mathrm{H}})$ to be the parent block of $B$, formally: \begin{equation} -P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_H)) = H_p +P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{\mathrm{H}})) = H_{\mathrm{p}} \end{equation} The block number is the parent's block number incremented by one: \begin{equation} -H_i \equiv {{P(H)_H}_i} + 1 +H_{\mathrm{i}} \equiv {{P(H)_{\mathrm{H}}}_{\mathrm{i}}} + 1 \end{equation} \newcommand{\mindifficulty}{D_0} @@ -476,8 +476,8 @@ \subsubsection{Block Header Validity} The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} D(H) \equiv \begin{dcases} -\mindifficulty & \text{if} \quad H_i = 0\\ -\text{max}\!\left(\mindifficulty, {P(H)_H}_d + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ +\mindifficulty & \text{if} \quad H_{\mathrm{i}} = 0\\ +\text{max}\!\left(\mindifficulty, {P(H)_{\mathrm{H}}}_{\mathrm{d}} + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ \end{dcases} \end{equation} where: @@ -485,10 +485,10 @@ \subsubsection{Block Header Validity} \mindifficulty \equiv 131072 \end{equation} \begin{equation} -\diffadjustment \equiv \left\lfloor\frac{{P(H)_H}_d}{2048}\right\rfloor +\diffadjustment \equiv \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{d}}}{2048}\right\rfloor \end{equation} \begin{equation} -\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_s - {P(H)_H}_s}{9}\right\rfloor, -99 \right) +\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{\mathrm{H}}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) \end{equation} \begin{equation*} x \equiv \begin{cases} @@ -497,49 +497,49 @@ \subsubsection{Block Header Validity} \end{cases} \end{equation*} \begin{align} -\expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ -H'_i &\equiv \max(H_i - 3000000, 0) +\expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_{\mathrm{i}} \div 100000 \right\rfloor - 2 } \right\rfloor \\ +H'_{\mathrm{i}} &\equiv \max(H_{\mathrm{i}} - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_{\mathrm{i}}$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. -The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: +The canonical gas limit $H_{\mathrm{l}}$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} -& & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l > {P(H)_H}_l - \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l \geqslant 5000 +& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} \geqslant 5000 \end{eqnarray} -$H_s$ is the timestamp of block $H$ and must fulfil the relation: +$H_{\mathrm{s}}$ is the timestamp of block $H$ and must fulfil the relation: \begin{equation} -H_s > {P(H)_H}_s +H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} \end{equation} This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. -The nonce, $H_n$, must satisfy the relations: +The nonce, $H_{\mathrm{n}}$, must satisfy the relations: \begin{equation} -n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m +n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \wedge \quad m = H_{\mathrm{m}} \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. -Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. +Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} -V(H) & \equiv & n \leqslant \frac{2^{256}}{H_d} \wedge m = H_m \quad \wedge \\ -& & H_d = D(H) \quad \wedge \\ -& & H_g \le H_l \quad \wedge \\ -& & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l > {P(H)_H}_l - \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l \geqslant 5000 \quad \wedge \\ -& & H_s > {P(H)_H}_s \quad \wedge \\ -& & H_i = {P(H)_H}_i +1 \quad \wedge \\ -& & \lVert H_x \rVert \le 32 +V(H) & \equiv & n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \wedge m = H_{\mathrm{m}} \quad \wedge \\ +& & H_{\mathrm{d}} = D(H) \quad \wedge \\ +& & H_{\mathrm{g}} \le H_{\mathrm{l}} \quad \wedge \\ +& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} \geqslant 5000 \quad \wedge \\ +& & H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} \quad \wedge \\ +& & H_{\mathrm{i}} = {P(H)_{\mathrm{H}}}_{\mathrm{i}} +1 \quad \wedge \\ +& & \lVert H_{\mathrm{x}} \rVert \le 32 \end{eqnarray} -where $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$ +where $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$ Noting additionally that \textbf{extraData} must be at most 32 bytes. @@ -575,10 +575,10 @@ \section{Transaction Execution} \label{ch:transactions} \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} -A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) +A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_{\mathrm{r}}) \end{equation} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} @@ -589,7 +589,7 @@ \subsection{Execution} We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ -{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_t = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ +{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ {} & + G_{transaction} \end{align} @@ -597,7 +597,7 @@ \subsection{Execution} The up-front cost $v_0$ is calculated as: \begin{equation} -v_0 \equiv T_g T_p + T_v +v_0 \equiv T_{\mathrm{g}} T_{\mathrm{p}} + T_{\mathrm{v}} \end{equation} The validity is determined as: @@ -605,53 +605,53 @@ \subsection{Execution} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ \boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \\ -T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ -g_0 & \leqslant & T_g \quad \wedge \\ -v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ -T_g & \leqslant & {B_H}_l - \ell(B_\mathbf{R})_u +T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ +g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ +v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ +T_{\mathrm{g}} & \leqslant & {B_{\mathrm{H}}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_g$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_u$, must be no greater than the block's \textbf{gasLimit}, ${B_H}_l$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{\mathrm{H}}}_{\mathrm{l}}$. -The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_gT_p$. The gas available for the proceeding computation, $g$, is defined as $T_g - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. +The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{gT}}_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. We define the checkpoint state $\boldsymbol{\sigma}_0$: \begin{eqnarray} \boldsymbol{\sigma}_0 & \equiv & \boldsymbol{\sigma} \quad \text{except:} \\ -\boldsymbol{\sigma}_0[S(T)]_b & \equiv & \boldsymbol{\sigma}[S(T)]_b - T_g T_p \\ -\boldsymbol{\sigma}_0[S(T)]_n & \equiv & \boldsymbol{\sigma}[S(T)]_n + 1 +\boldsymbol{\sigma}_0[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} - T_{\mathrm{g}} T_{\mathrm{p}} \\ +\boldsymbol{\sigma}_0[S(T)]_{\mathrm{n}} & \equiv & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $z$: +Evaluating $\boldsymbol{\sigma}_{\mathrm{P}}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} -(\boldsymbol{\sigma}_P, g', A, z) \equiv \begin{cases} -\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ -\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} +(\boldsymbol{\sigma}_{\mathrm{P}}, g', A, z) \equiv \begin{cases} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_\mathbf{i}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ +\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} where $g$ is the amount of gas remaining after deducting the basic amount required to pay for the existence of the transaction: \begin{equation} -g \equiv T_g - g_0 +g \equiv T_{\mathrm{g}} - g_0 \end{equation} -and $T_o$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. +and $T_{\mathrm{o}}$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. Note we use $\Theta_{4}$ and $\Lambda_{4}$ to denote the fact that only the first four components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} -g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_g - g'}{2} \Big\rfloor, A_r \} +g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, A_{\mathrm{r}} \} \end{equation} -The total refundable amount is the legitimately remaining gas $g'$, added to $A_r$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_g - g'$. +The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. -The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_P$: +The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$: \begin{eqnarray} -\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_P \quad \text{except} \\ -\boldsymbol{\sigma}^*[S(T)]_b & \equiv & \boldsymbol{\sigma}_P[S(T)]_b + g^* T_p \\ -\boldsymbol{\sigma}^*[m]_b & \equiv & \boldsymbol{\sigma}_P[m]_b + (T_g - g^*) T_p \\ -m & \equiv & {B_H}_c +\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_{\mathrm{P}} \quad \text{except} \\ +\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[S(T)]_{\mathrm{b}} + g^* T_{\mathrm{p}} \\ +\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - g^*) T_{\mathrm{p}} \\ +m & \equiv & {B_{\mathrm{H}}}_{\mathrm{c}} \end{eqnarray} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: @@ -663,7 +663,7 @@ \subsection{Execution} And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: \begin{eqnarray} -\Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ +\Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ \Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} @@ -681,7 +681,7 @@ \section{Contract Creation} \label{ch:create} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: \begin{equation} -a \equiv \mathcal{B}_{96..255}\Big(\mathtt{\tiny KEC}\Big(\mathtt{\tiny RLP}\big(\;(s, \boldsymbol{\sigma}[s]_n - 1)\;\big)\Big)\Big) +a \equiv \mathcal{B}_{96..255}\Big(\mathtt{\tiny KEC}\Big(\mathtt{\tiny RLP}\big(\;(s, \boldsymbol{\sigma}[s]_{\mathrm{n}} - 1)\;\big)\Big)\Big) \end{equation} where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$ and $\boldsymbol{\sigma}[x]$ is the address state of $x$ or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. @@ -696,14 +696,14 @@ \section{Contract Creation} \label{ch:create} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} \end{cases} \\ -\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_n, \boldsymbol{\sigma}[s]_b - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_c) +\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_{\mathrm{n}}, \boldsymbol{\sigma}[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_{\mathrm{c}}) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: \begin{equation} v' \equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}[a] = \varnothing\\ -\boldsymbol{\sigma}[a]_b & \text{otherwise} +\boldsymbol{\sigma}[a]_{\mathrm{b}} & \text{otherwise} \end{cases} \end{equation} @@ -716,18 +716,18 @@ \section{Contract Creation} \label{ch:create} \end{equation} where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: \begin{eqnarray} -I_a & \equiv & a \\ -I_o & \equiv & o \\ -I_p & \equiv & p \\ +I_{\mathrm{a}} & \equiv & a \\ +I_{\mathrm{o}} & \equiv & o \\ +I_{\mathrm{p}} & \equiv & p \\ I_\mathbf{d} & \equiv & () \\ -I_s & \equiv & s \\ -I_v & \equiv & v \\ +I_{\mathrm{s}} & \equiv & s \\ +I_{\mathrm{v}} & \equiv & v \\ I_\mathbf{b} & \equiv & \mathbf{i} \\ -I_e & \equiv & e \\ -I_w & \equiv & w +I_{\mathrm{e}} & \equiv & e \\ +I_{\mathrm{w}} & \equiv & w \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_H$ has no special treatment and is determined from the blockchain. +$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{\mathrm{H}}$ has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, $\varnothing$, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. @@ -752,7 +752,7 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a] = \varnothing & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^{**}, a) \\ \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ -\quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} +\quad\boldsymbol{\sigma}'[a]_{\mathrm{c}} = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ \quad z &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ @@ -780,7 +780,7 @@ \section{Message Call} \label{ch:call} We define $\boldsymbol{\sigma}_1$, the first transitional state as the original state but with the value transferred from sender to recipient: \begin{equation} -\boldsymbol{\sigma}_1[r]_b \equiv \boldsymbol{\sigma}[r]_b + v \quad\wedge\quad \boldsymbol{\sigma}_1[s]_b \equiv \boldsymbol{\sigma}[s]_b - v +\boldsymbol{\sigma}_1[r]_{\mathrm{b}} \equiv \boldsymbol{\sigma}[r]_{\mathrm{b}} + v \quad\wedge\quad \boldsymbol{\sigma}_1[s]_{\mathrm{b}} \equiv \boldsymbol{\sigma}[s]_{\mathrm{b}} - v \end{equation} unless $s = r$. @@ -795,7 +795,7 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_n, \boldsymbol{\sigma}_1'[s]_b - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_c) +\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_{\mathrm{n}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_{\mathrm{c}}) \end{equation} \begin{equation} \text{and}\quad \boldsymbol{\sigma}_1' \equiv \boldsymbol{\sigma} \quad \text{except:} \\ @@ -808,10 +808,10 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) +\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) \end{equation} -The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). +The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_{\mathrm{c}}$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \begin{cases} @@ -832,21 +832,21 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ -\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ -\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ \Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 8 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ -I_a & \equiv & r \\ -I_o & \equiv & o \\ -I_p & \equiv & p \\ +I_{\mathrm{a}} & \equiv & r \\ +I_{\mathrm{o}} & \equiv & o \\ +I_{\mathrm{p}} & \equiv & p \\ I_\mathbf{d} & \equiv & \mathbf{d} \\ -I_s & \equiv & s \\ -I_v & \equiv & \tilde{v} \\ -I_e & \equiv & e \\ -I_w & \equiv & w \\ +I_{\mathrm{s}} & \equiv & s \\ +I_{\mathrm{v}} & \equiv & \tilde{v} \\ +I_{\mathrm{e}} & \equiv & e \\ +I_{\mathrm{w}} & \equiv & w \\ \mathbf{t} & \equiv & \{s, r\} \\ \\ \nonumber -\text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c +\text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_{\mathrm{c}} \end{eqnarray} It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_\mathbf{b}), I_\mathbf{b})$ at some point prior in order to make the determination of $I_\mathbf{b}$ feasible. @@ -882,16 +882,16 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: \begin{itemize} -\item $I_a$, the address of the account which owns the code that is executing. -\item $I_o$, the sender address of the transaction that originated this execution. -\item $I_p$, the price of gas in the transaction that originated this execution. +\item $I_{\mathrm{a}}$, the address of the account which owns the code that is executing. +\item $I_{\mathrm{o}}$, the sender address of the transaction that originated this execution. +\item $I_{\mathrm{p}}$, the price of gas in the transaction that originated this execution. \item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. +\item $I_{\mathrm{s}}$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. +\item $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. \item $I_\mathbf{b}$, the byte array that is the machine code to be executed. -\item $I_H$, the block header of the present block. -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). -\item $I_w$, the permission to make modifications to the state. +\item $I_{\mathrm{H}}$, the block header of the present block. +\item $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: @@ -911,12 +911,12 @@ \subsection{Execution Overview} The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} -\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ +\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_{\mathrm{g}}, A, \mathbf{o}) \\ (\boldsymbol{\sigma}', \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ -\boldsymbol{\mu}_g & \equiv & g \\ +\boldsymbol{\mu}_{\mathrm{g}} & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ -\boldsymbol{\mu}_i & \equiv & 0 \\ +\boldsymbol{\mu}_{\mathrm{i}} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{s} & \equiv & () \\ \boldsymbol{\mu}_\mathbf{o} & \equiv & () \end{eqnarray} @@ -934,10 +934,10 @@ \subsection{Execution Overview} \mathbf{o} & \equiv & H(\boldsymbol{\mu}, I) \\ (a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) \\ \boldsymbol{\mu}' & \equiv & \boldsymbol{\mu}\ \text{except:} \\ -\boldsymbol{\mu}'_g & \equiv & \boldsymbol{\mu}_g - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) +\boldsymbol{\mu}'_{\mathrm{g}} & \equiv & \boldsymbol{\mu}_{\mathrm{g}} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \end{eqnarray} -Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_g$ from the resultant machine state $\boldsymbol{\mu}'$. +Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_{\mathrm{g}}$ from the resultant machine state $\boldsymbol{\mu}'$. $X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either $Z$ becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until $H$ becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. @@ -954,20 +954,20 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_Halting_function_Z}{} +\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{} \subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: \begin{equation} Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \equiv \begin{array}[t]{l} -\boldsymbol{\mu}_g < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ -\mathbf{\delta}_w = \varnothing \quad \vee \\ -\lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ +\boldsymbol{\mu}_{\mathrm{g}} < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ +\mathbf{\delta}_{\mathrm{w}} = \varnothing \quad \vee \\ +\lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_{\mathrm{w}} \quad \vee \\ ( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ ( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ - \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ - \neg I_w \wedge W(w, \boldsymbol{\mu}) + \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_{\mathrm{w}} + \mathbf{\alpha}_{\mathrm{w}} > 1024 \quad \vee \\ + \neg I_{\mathrm{w}} \wedge W(w, \boldsymbol{\mu}) \end{array} \end{equation} where @@ -989,15 +989,15 @@ \subsubsection{Jump Destination Validity} Formally: \begin{equation} -D(\mathbf{c}) \equiv D_J(\mathbf{c}, 0) +D(\mathbf{c}) \equiv D_{\mathrm{J}}(\mathbf{c}, 0) \end{equation} where: \begin{equation} -D_J(\mathbf{c}, i) \equiv \begin{cases} +D_{\mathrm{J}}(\mathbf{c}, i) \equiv \begin{cases} \{\} & \text{if} \quad i \geqslant |\mathbf{c}| \\ -\{ i \} \cup D_J(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ -D_J(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ +\{ i \} \cup D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ +D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ \end{cases} \end{equation} @@ -1026,9 +1026,9 @@ \subsection{The Execution Cycle} Stack items are added or removed from the left-most, lower-indexed portion of the series; all other items remain unchanged: \begin{eqnarray} O\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \equiv & (\boldsymbol{\sigma}', \boldsymbol{\mu}', A', I) \\ -\Delta & \equiv & \mathbf{\alpha}_w - \mathbf{\delta}_w \\ +\Delta & \equiv & \mathbf{\alpha}_{\mathrm{w}} - \mathbf{\delta}_{\mathrm{w}} \\ \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert & \equiv & \lVert\boldsymbol{\mu}_\mathbf{s}\rVert + \Delta \\ -\quad \forall x \in [\mathbf{\alpha}_w, \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert): \boldsymbol{\mu}'_\mathbf{s}[x] & \equiv & \boldsymbol{\mu}_\mathbf{s}[x-\Delta] +\quad \forall x \in [\mathbf{\alpha}_{\mathrm{w}}, \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert): \boldsymbol{\mu}'_\mathbf{s}[x] & \equiv & \boldsymbol{\mu}_\mathbf{s}[x-\Delta] \end{eqnarray} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: @@ -1044,7 +1044,7 @@ \subsection{The Execution Cycle} In general, we assume the memory, self-destruct set and system state don't change: \begin{eqnarray} \boldsymbol{\mu}'_\mathbf{m} & \equiv & \boldsymbol{\mu}_\mathbf{m} \\ -\boldsymbol{\mu}'_i & \equiv & \boldsymbol{\mu}_i \\ +\boldsymbol{\mu}'_{\mathrm{i}} & \equiv & \boldsymbol{\mu}_{\mathrm{i}} \\ A' & \equiv & A \\ \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma} \end{eqnarray} @@ -1059,11 +1059,11 @@ \section{Blocktree to Blockchain} \label{ch:ghost} Thus we define the total difficulty of block $B$ recursively as: \begin{eqnarray} -B_t & \equiv & B'_t + B_d \\ -B' & \equiv & P(B_H) +B_{\mathrm{t}} & \equiv & B'_{\mathrm{t}} + B_{\mathrm{d}} \\ +B' & \equiv & P(B_{\mathrm{H}}) \end{eqnarray} -As such given a block $B$, $B_t$ is its total difficulty, $B'$ is its parent block and $B_d$ is its difficulty. +As such given a block $B$, $B_{\mathrm{t}}$ is its total difficulty, $B'$ is its parent block and $B_{\mathrm{d}}$ is its difficulty. \section{Block Finalisation} \label{ch:finalisation} @@ -1080,14 +1080,14 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_{\mathrm{H}})_{\mathrm{H}}, 6) \end{equation} where $k$ denotes the ``is-kin'' property: \begin{equation} k(U, H, n) \equiv \begin{cases} false & \text{if} \quad n = 0 \\ s(U, H) &\\ -\quad \vee \; k(U, P(H)_H, n - 1) & \text{otherwise} +\quad \vee \; k(U, P(H)_{\mathrm{H}}, n - 1) & \text{otherwise} \end{cases} \end{equation} @@ -1101,32 +1101,32 @@ \subsection{Transaction Validation} %where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_\mathbf{T}[i]$, and $g[i]$ the total gas used immediately after said transaction. -The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_H}_g$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: +The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{\mathrm{H}}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_H}_g = \ell(\mathbf{R})_u +{B_{\mathrm{H}}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} \end{equation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_{\mathrm{b}}$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ +\qquad\boldsymbol{\sigma}'[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ \qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber -\boldsymbol{\sigma}'[U_c] & = & \begin{cases} -\varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ +\boldsymbol{\sigma}'[U_{\mathrm{c}}] & = & \begin{cases} +\varnothing &\text{if}\ \boldsymbol{\sigma}[U_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ -\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_c]_n, \boldsymbol{\sigma}[U_c]_b + R, \boldsymbol{\sigma}[U_c]_\mathbf{s}, \boldsymbol{\sigma}[U_c]_c) \\ -R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b +\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_\mathbf{s}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ +R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{\mathrm{H}}}_{\mathrm{i}})) R_{\mathrm{b}} \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. We define the block reward as 3 Ether: \begin{equation} -\text{Let} \quad R_b = 3 \times 10^{18} +\text{Let} \quad R_{\mathrm{b}} = 3 \times 10^{18} \end{equation} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} @@ -1134,34 +1134,34 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} -\boldsymbol{\sigma}_0 & \text{if} \quad P(B_H) = \varnothing \\ -\boldsymbol{\sigma}_i: \mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i)) = {P(B_H)_H}_r & \text{otherwise} +\boldsymbol{\sigma}_0 & \text{if} \quad P(B_{\mathrm{H}}) = \varnothing \\ +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ -B'_n & = & n: \quad x \leqslant \frac{2^{256}}{H_d} \\ -B'_m & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ -B^* & \equiv & B \quad \text{except:} \quad B^*_r = r(\Pi(\Gamma(B), B)) +B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \\ +B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ +B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_z$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} \boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} -In the case of $B_\mathbf{R}[n]_u$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: +In the case of $B_\mathbf{R}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} -\mathbf{R}[n]_u = \begin{cases} 0 & \text{if} \quad n < 0 \\ +\mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_u +\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} @@ -1172,9 +1172,9 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -We define $\mathbf{R}[n]_z$ in a similar manner. +We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. \begin{equation} -\mathbf{R}[n]_z = +\mathbf{R}[n]_{\mathrm{z}} = \Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} @@ -1199,10 +1199,10 @@ \subsection{Mining Proof-of-Work} \label{ch:pow} More formally, the proof-of-work function takes the form of $\mathtt{PoW}$: \begin{equation} -m = H_m \quad \wedge \quad n \leqslant \frac{2^{256}}{H_d} \quad \text{with} \quad (m, n) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d}) +m = H_{\mathrm{m}} \quad \wedge \quad n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \text{with} \quad (m, n) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) \end{equation} -Where $H_{\hcancel{n}}$ is the new block's header but \textit{without} the nonce and mix-hash components; $H_n$ is the nonce of the header; $\mathbf{d}$ is a large data set needed to compute the mixHash and $H_d$ is the new block's difficulty value (i.e. the block difficulty from section \ref{ch:ghost}). $\mathtt{PoW}$ is the proof-of-work function which evaluates to an array with the first item being the mixHash and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. The underlying algorithm is called Ethash and is described below. +Where $H_{\hcancel{n}}$ is the new block's header but \textit{without} the nonce and mix-hash components; $H_{\mathrm{n}}$ is the nonce of the header; $\mathbf{d}$ is a large data set needed to compute the mixHash and $H_{\mathrm{d}}$ is the new block's difficulty value (i.e. the block difficulty from section \ref{ch:ghost}). $\mathtt{PoW}$ is the proof-of-work function which evaluates to an array with the first item being the mixHash and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. The underlying algorithm is called Ethash and is described below. \subsubsection{Ethash} Ethash is the PoW algorithm for Ethereum 1.0. It is the latest version of Dagger-Hashimoto, introduced by \cite{dagger} and \cite{hashimoto}, although it can no longer appropriately be called that since many of the original features of both algorithms have been drastically changed in the last month of research and development. The general route that the algorithm takes is as follows: @@ -1312,7 +1312,7 @@ \section{Recursive Length Prefix}\label{app:rlp} We define the RLP function as $\mathtt{\tiny RLP}$ through two sub-functions, the first handling the instance when the value is a byte array, the second when it is a sequence of further values: \begin{equation} -\mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_b(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_l(\mathbf{x}) & \text{otherwise} \end{cases} +\mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_{\mathrm{b}}(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_{\mathrm{l}}(\mathbf{x}) & \text{otherwise} \end{cases} \end{equation} If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: @@ -1323,14 +1323,14 @@ \section{Recursive Length Prefix}\label{app:rlp} \item Otherwise, the output is equal to the input prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the input byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183. \end{itemize} \hypertarget{R b}{} -Formally, we define $R_b$: +Formally, we define $R_{\mathrm{b}}$: \begin{eqnarray} -R_b(\mathbf{x}) & \equiv & \begin{cases} +R_{\mathrm{b}}(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ (128 + \lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{else if} \quad \lVert \mathbf{x} \rVert < 56 \\ \big(183 + \big\lVert \mathtt{\tiny BE}(\lVert \mathbf{x} \rVert) \big\rVert \big) \cdot \mathtt{\tiny BE}(\lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{otherwise} \end{cases} \\ -\mathtt{\tiny BE}(x) & \equiv & (b_0, b_1, ...): b_0 \neq 0 \wedge x = \sum_{n = 0}^{n < \lVert \mathbf{b} \rVert} b_n \cdot 256^{\lVert \mathbf{b} \rVert - 1 - n} \\ +\mathtt{\tiny BE}(x) & \equiv & (b_0, b_1, ...): b_0 \neq 0 \wedge x = \sum_{n = 0}^{n < \lVert \mathbf{b} \rVert} b_{\mathrm{n}} \cdot 256^{\lVert \mathbf{b} \rVert - 1 - n} \\ (a) \cdot (b, c) \cdot (d, e) & = & (a, b, c, d, e) \end{eqnarray} @@ -1343,16 +1343,16 @@ \section{Recursive Length Prefix}\label{app:rlp} \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} -Thus we finish by formally defining $R_l$: +Thus we finish by formally defining $R_{\mathrm{l}}$: \begin{eqnarray} -R_l(\mathbf{x}) & \equiv & \begin{cases} +R_{\mathrm{l}}(\mathbf{x}) & \equiv & \begin{cases} (192 + \lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{if} \quad \lVert s(\mathbf{x}) \rVert < 56 \\ \big(247 + \big\lVert \mathtt{\tiny BE}(\lVert s(\mathbf{x}) \rVert) \big\rVert \big) \cdot \mathtt{\tiny BE}(\lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{otherwise} \end{cases} \\ s(\mathbf{x}) & \equiv & \mathtt{\tiny RLP}(\mathbf{x}_0) \cdot \mathtt{\tiny RLP}(\mathbf{x}_1) ... \end{eqnarray} -If RLP is used to encode a scalar, defined only as a positive integer ($\mathbb{P}$ or any $x$ for $\mathbb{P}_x$), it must be specified as the shortest byte array such that the big-endian interpretation of it is equal. Thus the RLP of some positive integer $i$ is defined as: +If RLP is used to encode a scalar, defined only as a positive integer ($\mathbb{P}$ or any $x$ for $\mathbb{P}_{\mathrm{x}}$), it must be specified as the shortest byte array such that the big-endian interpretation of it is equal. Thus the RLP of some positive integer $i$ is defined as: \begin{equation} \mathtt{\tiny RLP}(i : i \in \mathbb{P}) \equiv \mathtt{\tiny RLP}(\mathtt{\tiny BE}(i)) \end{equation} @@ -1394,10 +1394,10 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: \begin{eqnarray} y(\mathfrak{I}) & = & \{ (\mathbf{k}_0' \in \mathbb{Y}, \mathbf{v}_0 \in \mathbb{B}), (\mathbf{k}_1' \in \mathbb{Y}, \mathbf{v}_1 \in \mathbb{B}), ... \} \\ -\forall_n \quad \forall_{i: i < 2\lVert\mathbf{k}_n\rVert} \quad \mathbf{k}_n'[i] & \equiv & +\forall_{\mathrm{n}} \quad \forall_{i: i < 2\lVert\mathbf{k}_{\mathrm{n}}\rVert} \quad \mathbf{k}_{\mathrm{n}}'[i] & \equiv & \begin{cases} -\lfloor \mathbf{k}_n[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ -\mathbf{k}_n[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} +\lfloor \mathbf{k}_{\mathrm{n}}[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ +\mathbf{k}_{\mathrm{n}}[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} \end{cases} \end{eqnarray} @@ -1426,7 +1426,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_{\mathrm{x}} : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} @@ -1447,16 +1447,16 @@ \section{Precompiled Contracts}\label{app:precompiled} For each precompiled contract, we make use of a template function, $\Xi_{\mathtt{PRE}}$, which implements the out-of-gas checking. \begin{equation} \label{eq:pre} \Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} -(\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ -(\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} +(\varnothing, 0, A^0, ()) & \text{if} \quad g < g_{\mathrm{r}} \\ +(\boldsymbol\sigma, g - g_{\mathrm{r}}, A^0, \mathbf{o}) & \text{otherwise}\end{cases} \end{equation} -The precompiled contracts each use these definitions and provide specifications for the $\mathbf{o}$ (the output data) and $g_r$, the gas requirements. +The precompiled contracts each use these definitions and provide specifications for the $\mathbf{o}$ (the output data) and $g_{\mathrm{r}}$, the gas requirements. For the elliptic curve DSA recover VM execution function, we also define $\mathbf{d}$ to be the input data, well-defined for an infinite length by appending zeroes as required. Importantly in the case of an invalid signature ($\mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing$), then we have no output. \begin{eqnarray} \Xi_{\mathtt{ECREC}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 3000\\ +g_{\mathrm{r}} &=& 3000\\ |\mathbf{o}| &=& \begin{cases} 0 & \text{if} \quad \mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing\\ 32 & \text{otherwise} \end{cases}\\ \text{if} \quad |\mathbf{o}| = 32: &&\\ \mathbf{o}[0..11] &=& 0 \\ @@ -1472,10 +1472,10 @@ \section{Precompiled Contracts}\label{app:precompiled} The two hash functions, RIPEMD-160 and SHA2-256 are more trivially defined as an almost pass-through operation. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. \begin{eqnarray} \Xi_{\mathtt{SHA256}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 60 + 12\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ \mathbf{o}[0..31] &=& \mathtt{\tiny SHA256}(I_\mathbf{d})\\ \Xi_{\mathtt{RIP160}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 600 + 120\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ \mathbf{o}[0..11] &=& 0 \\ \mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_\mathbf{d})\\ \end{eqnarray} @@ -1489,7 +1489,7 @@ \section{Precompiled Contracts}\label{app:precompiled} The fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: \begin{eqnarray} \Xi_{\mathtt{ID}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} @@ -1497,25 +1497,25 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_r &=& \Big\lfloor\frac{f\big(\max(\ell_M,\ell_B)\big)\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +g_{\mathrm{r}} &=& \Big\lfloor\frac{f\big(\max(\ell_{\mathrm{M}},\ell_{\mathrm{B}})\big)\max(\ell'_{\mathrm{E}},1)}{G_{quaddivisor}}\Big\rfloor \\ f(x) &\equiv& \begin{cases} x^2 & \text{if}\ x \le 64 \\ \Big\lfloor\dfrac{x^2}{4}\Big\rfloor + 96 x - 3072 & \text{if}\ 64 < x \le 1024 \\ \Big\lfloor\dfrac{x^2}{16}\Big\rfloor + 480x - 199680 & \text{otherwise} \end{cases}\\ -\ell'_E &=& \begin{cases} -0 & \text{if}\ \ell_E\le 32\wedge E=0 \\ -\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 32 \wedge E \neq 0 \\ -8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 32 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ -8(\ell_E - 32) & \text{otherwise} \\ +\ell'_{\mathrm{E}} &=& \begin{cases} +0 & \text{if}\ \ell_{\mathrm{E}}\le 32\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_{\mathrm{E}}\le 32 \wedge E \neq 0 \\ +8(\ell_{\mathrm{E}} - 32) + \lfloor \log_2(i[(96+\ell_{\mathrm{B}})..(127+\ell_{\mathrm{B}})]) \rfloor & \text{if}\ 32 < \ell_{\mathrm{E}} \wedge i[(96 + \ell_{\mathrm{B}})..(127 + \ell_{\mathrm{B}})]\neq 0 \\ +8(\ell_{\mathrm{E}} - 32) & \text{otherwise} \\ \end{cases} \\ -\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ -\ell_B &\equiv& i[0..31] \\ -\ell_E &\equiv& i[32..63] \\ -\ell_M &\equiv& i[64..95] \\ -B &\equiv& i[96..(95+\ell_B)] \\ -E &\equiv& i[(96+\ell_B)..(95+\ell_B+\ell_E)] \\ -M &\equiv& i[(96+\ell_B+\ell_E)..(95+\ell_B+\ell_E+\ell_M)] \\ +\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_{\mathrm{M}}} \\ +\ell_{\mathrm{B}} &\equiv& i[0..31] \\ +\ell_{\mathrm{E}} &\equiv& i[32..63] \\ +\ell_{\mathrm{M}} &\equiv& i[64..95] \\ +B &\equiv& i[96..(95+\ell_{\mathrm{B}})] \\ +E &\equiv& i[(96+\ell_{\mathrm{B}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})] \\ +M &\equiv& i[(96+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}}+\ell_{\mathrm{M}})] \\ i[x] &\equiv& \begin{cases} I_{\mathbf d}[x] &\text{if}\ x < |I_{\mathbf d}| \\ 0 &\text{otherwise} @@ -1529,11 +1529,11 @@ \subsection{zkSNARK Related Precompiled Contracts} p &\equiv& 21888242871839275222246405745257275088696311157297823662689037894645226208583 \\ q &\equiv& 21888242871839275222246405745257275088548364400416034343698204186575808495617 \end{eqnarray} -Since $p$ is a prime number, $\{0, 1, \ldots, p - 1\}$ forms a field with addition and multiplication modulo $p$. We call this field $F_p$. +Since $p$ is a prime number, $\{0, 1, \ldots, p - 1\}$ forms a field with addition and multiplication modulo $p$. We call this field $F_{\mathrm{p}}$. We define a set~$C_1$ with \begin{equation} -C_1\equiv\{(X,Y)\in F_p\times F_p\mid Y^2=X^3+3\}\cup\{(0,0)\} +C_1\equiv\{(X,Y)\in F_{\mathrm{p}}\times F_{\mathrm{p}}\mid Y^2=X^3+3\}\cup\{(0,0)\} \end{equation} We define a binary operation $+$ on $C_1$ with \begin{eqnarray}\label{eq:ec-addition} @@ -1554,7 +1554,7 @@ \subsection{zkSNARK Related Precompiled Contracts} We define $P_1$ to be a point $(1,2)$ on $C_1$. Let $G_1$ be the subgroup of $(C_1,+)$ generated by $P_1$. $G_1$ is known to be a cyclic group of order $q$. For a point $P$ in $G_1$, we define $\log_{P_1}(P)$ to be the smallest natural number $n$ satisfying $n\cdot P_1=P$. $\log_{P_1}(P)$ is at most $q-1$. -Let $F_{p^2}$ be a field $F_p[i]/(i+1)$. We define a set $C_2$ with +Let $F_{p^2}$ be a field $F_{\mathrm{p}}[i]/(i+1)$. We define a set $C_2$ with \begin{equation} C_2\equiv\{(X,Y)\in F_{p^2}\times F_{p^2}\mid Y^2=X^3+3\}\cup\{(0,0)\} \end{equation} @@ -1565,9 +1565,9 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{eqnarray} We define $G_2$ to be the subgroup of $(C_2,+)$ generated by $P_2$. $G_2$ is known to be a cyclic group of order $q$. For a point $P$ in $G_2$, we define $\log_{P_2}(P)$ be the smallest natural number $n$ satisfying $n\cdot P_2=P$. With this definition, $\log_{P_2}(P)$ is at most $q-1$. -A 32 byte number $\mathbf{x}\in\mathbf{P}_{256}$ might and might not represent an element of $F_p$. +A 32 byte number $\mathbf{x}\in\mathbf{P}_{256}$ might and might not represent an element of $F_{\mathrm{p}}$. \begin{equation} -\delta_p(\mathbf x)\equiv\begin{cases} +\delta_{\mathrm{p}}(\mathbf x)\equiv\begin{cases} \mathbf x&\text{if}\ \mathbf x 0 \\ @@ -1829,9 +1829,9 @@ \subsection{Gas Cost} $W_{extcode}$ = \{{\small EXTCODESIZE}\} -Note the memory cost component, given as the product of $G_{memory}$ and the maximum of 0 \& the ceiling of the number of words in size that the memory must be over the current number of words, $\boldsymbol{\mu}_i$ in order that all accesses reference valid memory whether for read or write. Such accesses must be for non-zero number of bytes. +Note the memory cost component, given as the product of $G_{memory}$ and the maximum of 0 \& the ceiling of the number of words in size that the memory must be over the current number of words, $\boldsymbol{\mu}_{\mathrm{i}}$ in order that all accesses reference valid memory whether for read or write. Such accesses must be for non-zero number of bytes. -Referencing a zero length range (e.g. by attempting to pass it as the input range to a CALL) does not require memory to be extended to the beginning of the range. $\boldsymbol{\mu}'_i$ is defined as this new maximum number of words of active memory; special-cases are given where these two are not equal. +Referencing a zero length range (e.g. by attempting to pass it as the input range to a CALL) does not require memory to be extended to the beginning of the range. $\boldsymbol{\mu}'_{\mathrm{i}}$ is defined as this new maximum number of words of active memory; special-cases are given where these two are not equal. Note also that $C_{mem}$ is the memory cost function (the expansion function being the difference between the cost before and after). It is a polynomial, with the higher-order coefficient divided and floored, and thus linear up to 724B of memory used, after which it costs substantially more. @@ -1902,8 +1902,8 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] ^ {\boldsymbol{\mu}_\mathbf{s}[1] }$ \\ \midrule 0x0b & {\small SIGNEXTEND} & 2 & 1 & Extend length of two's complement signed integer. \\ -&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_t &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_i &\text{otherwise} \end{cases}$ \\ -\multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_i$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ +&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{t}} &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}} &\text{otherwise} \end{cases}$ \\ +\multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_{\mathrm{i}}$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ \midrule \end{tabular*} @@ -1932,19 +1932,19 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x16 & {\small AND} & 2 & 1 & Bitwise AND operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \boldsymbol{\mu}_\mathbf{s}[0]_i \wedge \boldsymbol{\mu}_\mathbf{s}[1]_i$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \wedge \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ \midrule 0x17 & {\small OR} & 2 & 1 & Bitwise OR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \boldsymbol{\mu}_\mathbf{s}[0]_i \vee \boldsymbol{\mu}_\mathbf{s}[1]_i$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \vee \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ \midrule 0x18 & {\small XOR} & 2 & 1 & Bitwise XOR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \boldsymbol{\mu}_\mathbf{s}[0]_i \oplus \boldsymbol{\mu}_\mathbf{s}[1]_i$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \oplus \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ \midrule 0x19 & {\small NOT} & 1 & 1 & Bitwise NOT operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0]_i = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x1a & {\small BYTE} & 2 & 1 & Retrieve single byte from word. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{(i + 8\boldsymbol{\mu}_\mathbf{s}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_\mathbf{s}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{(i + 8\boldsymbol{\mu}_\mathbf{s}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_\mathbf{s}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ &&&& For Nth byte, we count from the left (i.e. N=0 would be the most significant in big endian). \\ \bottomrule \end{tabular*} @@ -1955,7 +1955,7 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x20 & {\small SHA3} & 2 & 1 & Compute Keccak-256 hash. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \mathtt{\tiny Keccak}(\boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \bottomrule \end{tabular*} @@ -1964,22 +1964,22 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{30s: Environmental Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x30 & {\small ADDRESS} & 0 & 1 & Get address of currently executing account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_a$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{a}}$ \\ \midrule 0x31 & {\small BALANCE} & 1 & 1 & Get balance of the given account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0]]_b& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0]]_{\mathrm{b}}& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ \midrule 0x32 & {\small ORIGIN} & 0 & 1 & Get execution origination address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_o$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{o}}$ \\ &&&& This is the sender of original transaction; it is never an account with non-empty \\ &&&& associated code. \\ \midrule 0x33 & {\small CALLER} & 0 & 1 & Get caller address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_s$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{s}}$ \\ &&&& This is the address of the account that is directly responsible for this execution. \\ \midrule 0x34 & {\small CALLVALUE} & 0 & 1 & Get deposited value by the instruction/transaction responsible for this execution. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_v$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{v}}$ \\ \midrule 0x35 & {\small CALLDATALOAD} & 1 & 1 & Get input data of current environment. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_\mathbf{d}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \quad \text{with} \quad I_\mathbf{d}[x] = 0 \quad \text{if} \quad x \geqslant \lVert I_\mathbf{d} \rVert$ \\ @@ -1993,7 +1993,7 @@ \subsection{Instruction Set} &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv \begin{cases} I_\mathbf{d}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{d} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x38 & {\small CODESIZE} & 0 & 1 & Get size of code running in current environment. \\ @@ -2002,21 +2002,21 @@ \subsection{Instruction Set} 0x39 & {\small CODECOPY} & 3 & 0 & Copy code running in current environment to memory. \\ &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv \begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{b} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3a & {\small GASPRICE} & 0 & 1 & Get price of gas in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_p$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{p}}$ \\ &&&& This is gas price specified by the originating transaction.\\ \midrule 0x3b & {\small EXTCODESIZE} & 1 & 1 & Get size of an account's code. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_c \rVert$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}} \rVert$ \\ \midrule 0x3c & {\small EXTCODECOPY} & 4 & 0 & Copy an account's code to memory. \\ &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[3] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[1] + i ] \equiv \begin{cases} \mathbf{c}[\boldsymbol{\mu}_\mathbf{s}[2] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] + i < \lVert \mathbf{c} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_c$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ +&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[2] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ @@ -2026,7 +2026,7 @@ \subsection{Instruction Set} &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ \bottomrule \end{tabular*} @@ -2035,28 +2035,28 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_{\mathrm{p}}}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ &&&& or more than 256 blocks behind the current block. \\ -&&&& $P(h, n, a) \equiv \begin{cases} 0 & \text{if} \quad n > H_i \vee a = 256 \vee h = 0 \\ h & \text{if} \quad n = H_i \\ P(H_p, n, a + 1) & \text{otherwise} \end{cases}$ \\ +&&&& $P(h, n, a) \equiv \begin{cases} 0 & \text{if} \quad n > H_{\mathrm{i}} \vee a = 256 \vee h = 0 \\ h & \text{if} \quad n = H_{\mathrm{i}} \\ P(H_{\mathrm{p}}, n, a + 1) & \text{otherwise} \end{cases}$ \\ &&&& and we assert the header $H$ can be determined as its hash is the parent hash \\ &&&& in the block following it. \\ \midrule 0x41 & {\small COINBASE} & 0 & 1 & Get the block's beneficiary address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_c$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{c}}$ \\ \midrule 0x42 & {\small TIMESTAMP} & 0 & 1 & Get the block's timestamp. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_s$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{s}}$ \\ \midrule 0x43 & {\small NUMBER} & 0 & 1 & Get the block's number. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_i$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{i}}$ \\ \midrule 0x44 & {\small DIFFICULTY} & 0 & 1 & Get the block's difficulty. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_d$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{d}}$ \\ \midrule 0x45 & {\small GASLIMIT} & 0 & 1 & Get the block's gas limit. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_l$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{l}}$ \\ \bottomrule \end{tabular*} @@ -2068,30 +2068,30 @@ \subsection{Instruction Set} \midrule 0x51 & {\small MLOAD} & 1 & 1 & Load word from memory. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ]$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ -&&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x52 & {\small MSTORE} & 2 & 0 & Save word to memory. \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ -&&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x53 & {\small MSTORE8} & 2 & 0 & Save byte to memory. \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv (\boldsymbol{\mu}_\mathbf{s}[1] \bmod 256) $ \\ -&&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 1) \div 32 })$ \\ -&&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 1) \div 32 })$ \\ +&&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ \midrule 0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ &&&& $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ +G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} \end{cases}$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ +R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule @@ -2185,9 +2185,9 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ \multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ -\multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ +\multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_{\mathrm{a}}, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ -\multicolumn{5}{l}{$\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ +\multicolumn{5}{l}{$\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ \multicolumn{5}{l}{The entry's topic series, $\mathbf{t}$, differs accordingly:}\vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xa0 & {\small LOG0} & 2 & 0 & Append log record with no topics. \\ @@ -2209,35 +2209,35 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ -&&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_{\mathrm{g}}, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, L(\boldsymbol{\mu}_{\mathrm{g}}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathrm{g}}, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_{\mathrm{a}}]_{\mathrm{n}} = \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}} + 1$ \\ &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ -&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_e = 1024$ \\ -&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_a]_b$ (balance of the caller is too \\ -&&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting}\\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ +&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ +&&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ &&&& created account. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{o} \equiv ()$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[3] \dots (\boldsymbol{\mu}_\mathbf{s}[3] + \boldsymbol{\mu}_\mathbf{s}[4] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_{\mathrm{a}}, I_{\mathrm{o}}, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge \\ \quad\quad I_{\mathrm{e}} < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{o} = \mathbf{o}$ \\ -&&&& $\boldsymbol{\mu}'_g \equiv \boldsymbol{\mu}_g + g'$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{g}} \equiv \boldsymbol{\mu}_{\mathrm{g}} + g'$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ -&&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ +&&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ &&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ &&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} @@ -2245,7 +2245,7 @@ \subsection{Instruction Set} C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -\min\{ L(\boldsymbol{\mu}_g - C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})), \boldsymbol{\mu}_{\mathbf{s}}[0] \} & \text{if} \quad \boldsymbol{\mu}_g \ge C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ +\min\{ L(\boldsymbol{\mu}_{\mathrm{g}} - C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})), \boldsymbol{\mu}_{\mathbf{s}}[0] \} & \text{if} \quad \boldsymbol{\mu}_{\mathrm{g}} \ge C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ \boldsymbol{\mu}_{\mathbf{s}}[0] & \text{otherwise} \end{cases}$\\ &&&& $C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + C_{\text{\tiny XFER}}(\boldsymbol{\mu}) + C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$\\ @@ -2260,16 +2260,16 @@ \subsection{Instruction Set} \midrule 0xf2 & {\small CALLCODE} & 7 & 1 & Message-call into this account with an alternative account's code. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\\ \quad\quad{}I_{\mathrm{e}} < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ -&&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ +&&&& (as in {\small CALL}) to the present address $I_{\mathrm{a}}$. This means that the recipient is in fact the\\ &&&& same account as at present, simply that the code is overwritten.\\ \midrule 0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ &&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ &&&& This has the effect of halting the execution at this point with output defined.\\ &&&& See section \ref{ch:model}. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} @@ -2280,7 +2280,7 @@ \subsection{Instruction Set} &&&& argument is $\boldsymbol{\mu}_\mathbf{s}[2]$. As a result, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ in the definition of {\small CALL} \\ &&&& should respectively be replaced with $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& Otherwise exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_s, I_o, I_a, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_p, 0, I_v, \mathbf{i}, I_e + 1, I_w)\end{array} & \text{if} \quad I_v \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{s}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_{\mathrm{p}}, 0, I_{\mathrm{v}}, \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \text{if} \quad I_{\mathrm{v}} \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the changes (in addition to that of the fourth parameter) to the second \\ &&&& and ninth parameters to the call $\Theta$.\\ &&&& This means that the recipient is in fact the same account as at present, simply\\ @@ -2296,28 +2296,28 @@ \subsection{Instruction Set} 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and remaining gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we use the memory expansion function, \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ -&&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ +&&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_{\mathrm{a}} \}$ \\ &&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} -\varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_a]_b = 0\\ -(\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + \boldsymbol{\sigma}[I_a]_b, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{if}\ r \neq I_a \\ -(\boldsymbol{\sigma}[r]_n, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{otherwise} +\varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} = 0\\ +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\ r \neq I_{\mathrm{a}} \\ +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{otherwise} \end{cases}$\\ &&&& where $r = \boldsymbol{\mu}_\mathbf{s}[0] \bmod 2^{160}$\\ -&&&& $\boldsymbol{\sigma}'[I_a]_b = 0$ \\ +&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathrm{b}} = 0$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ +R_{selfdestruct} & \text{if} \quad I_{\mathrm{a}} \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0$ \\ +&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \neq 0$ \\ \bottomrule \end{tabular*} @@ -2358,7 +2358,7 @@ \subsection{Definitions} \subsection{Size of dataset and cache} The size for Ethash's cache $\mathbf{c} \in \mathbb{B}$ and dataset $\mathbf{d} \in \mathbb{B}$ depend on the epoch, which in turn depends on the block number. \begin{equation} - E_{epoch}(H_i) = \left\lfloor\frac{H_i}{J_{epoch}}\right\rfloor + E_{epoch}(H_{\mathrm{i}}) = \left\lfloor\frac{H_{\mathrm{i}}}{J_{epoch}}\right\rfloor \end{equation} The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache. Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using @@ -2380,12 +2380,12 @@ \subsection{Dataset generation} \subsubsection{Seed hash} The seed hash is different for every epoch. For the first epoch it is the Keccak-256 hash of a series of 32 bytes of zeros. For every other epoch it is always the Keccak-256 hash of the previous seed hash: \begin{equation} - \mathbf{s} = C_{seedhash}(H_i) + \mathbf{s} = C_{seedhash}(H_{\mathrm{i}}) \end{equation} \begin{equation} - C_{seedhash}(H_i) = \begin{cases} -\texttt{KEC}(\mathbf{0}_{32}) & \text{if} \quad E_{epoch}(H_i) = 0 \quad \\ -\texttt{KEC}(C_{seedhash}(H_i - J_{epoch})) & \text{otherwise} + C_{seedhash}(H_{\mathrm{i}}) = \begin{cases} +\texttt{KEC}(\mathbf{0}_{32}) & \text{if} \quad E_{epoch}(H_{\mathrm{i}}) = 0 \quad \\ +\texttt{KEC}(C_{seedhash}(H_{\mathrm{i}} - J_{epoch})) & \text{otherwise} \end{cases} \end{equation} With $\mathbf{0}_{32}$ being 32 bytes of zeros. @@ -2460,16 +2460,16 @@ \subsection{Proof-of-work function} The PoW-function returns an array with the compressed mix as its first item and the Keccak-256 hash of the concatenation of the compressed mix with the seed hash as the second item: \begin{equation} - \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d}) = \lbrace \mathbf{m}_c(\mathtt{\small KEC}(\mathtt{\small RLP}(L_H(H_{\hcancel{n}}))), H_n, \mathbf{d}), \texttt{KEC}(\mathbf{s}_h(\mathtt{\small KEC}(\mathtt{\small RLP}(L_H(H_{\hcancel{n}}))), H_n) + \mathbf{m}_c(\mathtt{\small KEC}(\mathtt{\small RLP}(L_H(H_{\hcancel{n}}))), H_n, \mathbf{d})) \rbrace + \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) = \lbrace \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d}), \texttt{KEC}(\mathbf{s}_{\mathrm{h}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}) + \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d})) \rbrace \end{equation} -With $H_{\hcancel{n}}$ being the hash of the header without the nonce. The compressed mix $\mathbf{m}_c$ is obtained as follows: +With $H_{\hcancel{n}}$ being the hash of the header without the nonce. The compressed mix $\mathbf{m}_{\mathrm{c}}$ is obtained as follows: \begin{equation} - \mathbf{m}_c(\mathbf{h}, \mathbf{n}, \mathbf{d}) = E_{compress}(E_{accesses}(\mathbf{d}, \sum_{i = 0}^{n_{mix}} \mathbf{s}_h(\mathbf{h}, \mathbf{n}), \mathbf{s}_h(\mathbf{h}, \mathbf{n}), -1), -4) + \mathbf{m}_{\mathrm{c}}(\mathbf{h}, \mathbf{n}, \mathbf{d}) = E_{compress}(E_{accesses}(\mathbf{d}, \sum_{i = 0}^{n_{mix}} \mathbf{s}_{\mathrm{h}}(\mathbf{h}, \mathbf{n}), \mathbf{s}_{\mathrm{h}}(\mathbf{h}, \mathbf{n}), -1), -4) \end{equation} The seed hash being: \begin{equation} - \mathbf{s}_h(\mathbf{h}, \mathbf{n}) = \texttt{KEC512}(\mathbf{h} + E_{revert}(\mathbf{n})) + \mathbf{s}_{\mathrm{h}}(\mathbf{h}, \mathbf{n}) = \texttt{KEC512}(\mathbf{h} + E_{revert}(\mathbf{n})) \end{equation} $E_{revert}(\mathbf{n})$ returns the reverted bytes sequence of the nonce $\mathbf{n}$: \begin{equation} From a6730daf58edfa4123fc60932a5bdd0fa6c00c6f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:31:47 +1100 Subject: [PATCH 213/335] Remove underscores in a URL --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index fa51a9f0..0a980cec 100644 --- a/Paper.tex +++ b/Paper.tex @@ -28,7 +28,7 @@ \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . -% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_{\mathrm{and}}_{\mathrm{Hypertarget}}. +% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. \makeatletter \newcommand{\linkdest}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} From ee13fcb3aa2e1137f90edeab419e8f88eac57291 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:35:01 +1100 Subject: [PATCH 214/335] Remove mathrms that have been added in the wrong place. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 0a980cec..b169d2b7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -116,7 +116,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_{\mathrm{state}}_{\mathrm{transition}}}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) +\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. From 4d8837ba8eebf7f19f81674943cdc3c8ce79df23 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:39:32 +1100 Subject: [PATCH 215/335] Remove mathrms that have been added in the wrong place --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b169d2b7..387506b7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -418,7 +418,7 @@ \subsubsection{Holistic Validity} Furthermore: \begin{equation} -\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} +\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} \end{equation} Thus $\texttt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{\mathrm{H}})$ is the parent block of $B$, defined directly. From 019f74c844bba77374c6dcdb6aa13b9bf1268abb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:53:15 +1100 Subject: [PATCH 216/335] Replace all mathrm\\\{([A-Z]\} with $1 Using Libre Open Office with match case and regex. --- Paper.tex | 166 +++++++++++++++++++++++++++--------------------------- 1 file changed, 83 insertions(+), 83 deletions(-) diff --git a/Paper.tex b/Paper.tex index 387506b7..e6147e9e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -217,12 +217,12 @@ \subsection{World State} \label{ch:state} Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: \begin{equation} -\texttt{\small TRIE}\big(L_{\mathrm{I}}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} +\texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} -The collapse function for the set of key/value pairs in the trie, $L_{\mathrm{I}}^*$, is defined as the element-wise transformation of the base function $L_{\mathrm{I}}$, given as: +The collapse function for the set of key/value pairs in the trie, $L_{I}^*$, is defined as the element-wise transformation of the base function $L_{I}$, given as: \begin{equation} -L_{\mathrm{I}}\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) +L_{I}\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) \end{equation} where: @@ -234,16 +234,16 @@ \subsection{World State} \label{ch:state} If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. -Thus we may define a world-state collapse function $L_{\mathrm{S}}$: +Thus we may define a world-state collapse function $L_{S}$: \begin{equation} -L_{\mathrm{S}}(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} +L_{S}(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} \end{equation} where \begin{equation} p(a) \equiv \big(\texttt{\small KEC}(a), \texttt{\small RLP}\big( (\boldsymbol{\sigma}[a]_{\mathrm{n}}, \boldsymbol{\sigma}[a]_{\mathrm{b}}, \boldsymbol{\sigma}[a]_{\mathrm{s}}, \boldsymbol{\sigma}[a]_{\mathrm{c}}) \big) \big) \end{equation} -This function, $L_{\mathrm{S}}$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: +This function, $L_{S}$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} @@ -293,7 +293,7 @@ \subsection{The Transaction} \label{ch:transaction} Appendix \ref{app:signing} specifies the function, $S$, which maps transactions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction $T$ can be represented with $S(T)$. \begin{equation} -L_{\mathrm{T}}(T) \equiv \begin{cases} +L_{T}(T) \equiv \begin{cases} (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{i}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{d}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} @@ -344,7 +344,7 @@ \subsection{The Block} \label{ch:block} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{\mathrm{H}}, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) \end{equation} \subsubsection{Transaction Receipt} @@ -357,9 +357,9 @@ \subsubsection{Transaction Receipt} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) \end{equation} -The function $L_{\mathrm{R}}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: +The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_{\mathrm{R}}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) +L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. @@ -373,7 +373,7 @@ \subsubsection{Transaction Receipt} R_{\mathrm{u}} \in \mathbb{P} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \end{equation} -%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{\mathrm{B}}$; it is merely a convenience equivalence. +%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_{\mathrm{a}}$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} @@ -403,10 +403,10 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: \begin{equation} \begin{array}[t]{lclc} -H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_{\mathrm{S}}(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}^*(B_\mathbf{U}))) & \wedge \\ -H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{T}}(B_\mathbf{T}[i]))\}) & \wedge \\ -H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{R}}(B_\mathbf{R}[i]))\}) & \wedge \\ +H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_{S}(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}^*(B_\mathbf{U}))) & \wedge \\ +H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_\mathbf{T}[i]))\}) & \wedge \\ +H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_\mathbf{R}[i]))\}) & \wedge \\ H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} @@ -418,22 +418,22 @@ \subsubsection{Holistic Validity} Furthermore: \begin{equation} -\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} +\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} \end{equation} -Thus $\texttt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{\mathrm{H}})$ is the parent block of $B$, defined directly. +Thus $\texttt{\small TRIE}(L_{S}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{H})$ is the parent block of $B$, defined directly. The values stemming from the computation of transactions, specifically the transaction receipts, $B_\mathbf{R}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} -The function $L_{\mathrm{B}}$ and $L_{\mathrm{H}}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{\mathrm{R}}$, we assert the types and order of the structure for when the RLP transformation is required: +The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} -\quad L_{\mathrm{H}}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ -\quad L_{\mathrm{B}}(B) & \equiv & \big( L_{\mathrm{H}}(B_{\mathrm{H}}), L_{\mathrm{T}}^*(B_\mathbf{T}), L_{\mathrm{H}}^*(B_\mathbf{U}) \big) +\quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ +\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_\mathbf{T}), L_{H}^*(B_\mathbf{U}) \big) \end{eqnarray} -With $L_{\mathrm{T}}^*$ and $L_{\mathrm{H}}^*$ being element-wise sequence transformations, thus: +With $L_{T}^*$ and $L_{H}^*$ being element-wise sequence transformations, thus: \begin{equation} f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} @@ -458,14 +458,14 @@ \subsubsection{Serialisation} \subsubsection{Block Header Validity} -We define $P(B_{\mathrm{H}})$ to be the parent block of $B$, formally: +We define $P(B_{H})$ to be the parent block of $B$, formally: \begin{equation} -P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{\mathrm{H}})) = H_{\mathrm{p}} +P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = H_{\mathrm{p}} \end{equation} The block number is the parent's block number incremented by one: \begin{equation} -H_{\mathrm{i}} \equiv {{P(H)_{\mathrm{H}}}_{\mathrm{i}}} + 1 +H_{\mathrm{i}} \equiv {{P(H)_{H}}_{\mathrm{i}}} + 1 \end{equation} \newcommand{\mindifficulty}{D_0} @@ -477,7 +477,7 @@ \subsubsection{Block Header Validity} \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_{\mathrm{i}} = 0\\ -\text{max}\!\left(\mindifficulty, {P(H)_{\mathrm{H}}}_{\mathrm{d}} + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ +\text{max}\!\left(\mindifficulty, {P(H)_{H}}_{\mathrm{d}} + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ \end{dcases} \end{equation} where: @@ -485,10 +485,10 @@ \subsubsection{Block Header Validity} \mindifficulty \equiv 131072 \end{equation} \begin{equation} -\diffadjustment \equiv \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{d}}}{2048}\right\rfloor +\diffadjustment \equiv \left\lfloor\frac{{P(H)_{H}}_{\mathrm{d}}}{2048}\right\rfloor \end{equation} \begin{equation} -\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{\mathrm{H}}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) +\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{H}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) \end{equation} \begin{equation*} x \equiv \begin{cases} @@ -505,14 +505,14 @@ \subsubsection{Block Header Validity} The canonical gas limit $H_{\mathrm{l}}$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} -& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ -& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} < {P(H)_{H}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{H}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ & & H_{\mathrm{l}} \geqslant 5000 \end{eqnarray} $H_{\mathrm{s}}$ is the timestamp of block $H$ and must fulfil the relation: \begin{equation} -H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} +H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \end{equation} This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. @@ -532,11 +532,11 @@ \subsubsection{Block Header Validity} V(H) & \equiv & n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \wedge m = H_{\mathrm{m}} \quad \wedge \\ & & H_{\mathrm{d}} = D(H) \quad \wedge \\ & & H_{\mathrm{g}} \le H_{\mathrm{l}} \quad \wedge \\ -& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ -& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} < {P(H)_{H}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{H}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ & & H_{\mathrm{l}} \geqslant 5000 \quad \wedge \\ -& & H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} \quad \wedge \\ -& & H_{\mathrm{i}} = {P(H)_{\mathrm{H}}}_{\mathrm{i}} +1 \quad \wedge \\ +& & H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \quad \wedge \\ +& & H_{\mathrm{i}} = {P(H)_{H}}_{\mathrm{i}} +1 \quad \wedge \\ & & \lVert H_{\mathrm{x}} \rVert \le 32 \end{eqnarray} where $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$ @@ -608,11 +608,11 @@ \subsection{Execution} T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ -T_{\mathrm{g}} & \leqslant & {B_{\mathrm{H}}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} +T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{\mathrm{H}}}_{\mathrm{l}}$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{gT}}_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. @@ -623,9 +623,9 @@ \subsection{Execution} \boldsymbol{\sigma}_0[S(T)]_{\mathrm{n}} & \equiv & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_{\mathrm{P}}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$, remaining gas $g'$, substate $A$ and status code $z$: +Evaluating $\boldsymbol{\sigma}_{P}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{P}$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} -(\boldsymbol{\sigma}_{\mathrm{P}}, g', A, z) \equiv \begin{cases} +(\boldsymbol{\sigma}_{P}, g', A, z) \equiv \begin{cases} \Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_\mathbf{i}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ \Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} @@ -646,12 +646,12 @@ \subsection{Execution} The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. -The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$: +The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{P}$: \begin{eqnarray} -\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_{\mathrm{P}} \quad \text{except} \\ -\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[S(T)]_{\mathrm{b}} + g^* T_{\mathrm{p}} \\ -\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - g^*) T_{\mathrm{p}} \\ -m & \equiv & {B_{\mathrm{H}}}_{\mathrm{c}} +\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_{P} \quad \text{except} \\ +\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{P}[S(T)]_{\mathrm{b}} + g^* T_{\mathrm{p}} \\ +\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{P}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - g^*) T_{\mathrm{p}} \\ +m & \equiv & {B_{H}}_{\mathrm{c}} \end{eqnarray} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: @@ -727,7 +727,7 @@ \section{Contract Creation} \label{ch:create} I_{\mathrm{w}} & \equiv & w \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{\mathrm{H}}$ has no special treatment and is determined from the blockchain. +$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{H}$ has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, $\varnothing$, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. @@ -889,7 +889,7 @@ \subsection{Execution Environment} \item $I_{\mathrm{s}}$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. \item $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. \item $I_\mathbf{b}$, the byte array that is the machine code to be executed. -\item $I_{\mathrm{H}}$, the block header of the present block. +\item $I_{H}$, the block header of the present block. \item $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). \item $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} @@ -954,7 +954,7 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{} +\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{} \subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: @@ -989,15 +989,15 @@ \subsubsection{Jump Destination Validity} Formally: \begin{equation} -D(\mathbf{c}) \equiv D_{\mathrm{J}}(\mathbf{c}, 0) +D(\mathbf{c}) \equiv D_{J}(\mathbf{c}, 0) \end{equation} where: \begin{equation} -D_{\mathrm{J}}(\mathbf{c}, i) \equiv \begin{cases} +D_{J}(\mathbf{c}, i) \equiv \begin{cases} \{\} & \text{if} \quad i \geqslant |\mathbf{c}| \\ -\{ i \} \cup D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ -D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ +\{ i \} \cup D_{J}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ +D_{J}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ \end{cases} \end{equation} @@ -1060,7 +1060,7 @@ \section{Blocktree to Blockchain} \label{ch:ghost} Thus we define the total difficulty of block $B$ recursively as: \begin{eqnarray} B_{\mathrm{t}} & \equiv & B'_{\mathrm{t}} + B_{\mathrm{d}} \\ -B' & \equiv & P(B_{\mathrm{H}}) +B' & \equiv & P(B_{H}) \end{eqnarray} As such given a block $B$, $B_{\mathrm{t}}$ is its total difficulty, $B'$ is its parent block and $B_{\mathrm{d}}$ is its difficulty. @@ -1080,14 +1080,14 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_{\mathrm{H}})_{\mathrm{H}}, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_{H})_{H}, 6) \end{equation} where $k$ denotes the ``is-kin'' property: \begin{equation} k(U, H, n) \equiv \begin{cases} false & \text{if} \quad n = 0 \\ s(U, H) &\\ -\quad \vee \; k(U, P(H)_{\mathrm{H}}, n - 1) & \text{otherwise} +\quad \vee \; k(U, P(H)_{H}, n - 1) & \text{otherwise} \end{cases} \end{equation} @@ -1101,9 +1101,9 @@ \subsection{Transaction Validation} %where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_\mathbf{T}[i]$, and $g[i]$ the total gas used immediately after said transaction. -The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{\mathrm{H}}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: +The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{H}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_{\mathrm{H}}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} +{B_{H}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} \end{equation} \subsection{Reward Application} @@ -1112,14 +1112,14 @@ \subsection{Reward Application} \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ +\qquad\boldsymbol{\sigma}'[{B_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{B_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ \qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber \boldsymbol{\sigma}'[U_{\mathrm{c}}] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ \mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_\mathbf{s}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ -R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{\mathrm{H}}}_{\mathrm{i}})) R_{\mathrm{b}} +R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{b}} \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. @@ -1134,12 +1134,12 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} -\boldsymbol{\sigma}_0 & \text{if} \quad P(B_{\mathrm{H}}) = \varnothing \\ -\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} & \text{otherwise} +\boldsymbol{\sigma}_0 & \text{if} \quad P(B_{H}) = \varnothing \\ +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} @@ -1497,25 +1497,25 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_{\mathrm{r}} &=& \Big\lfloor\frac{f\big(\max(\ell_{\mathrm{M}},\ell_{\mathrm{B}})\big)\max(\ell'_{\mathrm{E}},1)}{G_{quaddivisor}}\Big\rfloor \\ +g_{\mathrm{r}} &=& \Big\lfloor\frac{f\big(\max(\ell_{M},\ell_{B})\big)\max(\ell'_{E},1)}{G_{quaddivisor}}\Big\rfloor \\ f(x) &\equiv& \begin{cases} x^2 & \text{if}\ x \le 64 \\ \Big\lfloor\dfrac{x^2}{4}\Big\rfloor + 96 x - 3072 & \text{if}\ 64 < x \le 1024 \\ \Big\lfloor\dfrac{x^2}{16}\Big\rfloor + 480x - 199680 & \text{otherwise} \end{cases}\\ -\ell'_{\mathrm{E}} &=& \begin{cases} -0 & \text{if}\ \ell_{\mathrm{E}}\le 32\wedge E=0 \\ -\lfloor \log_2(E)\rfloor &\text{if}\ \ell_{\mathrm{E}}\le 32 \wedge E \neq 0 \\ -8(\ell_{\mathrm{E}} - 32) + \lfloor \log_2(i[(96+\ell_{\mathrm{B}})..(127+\ell_{\mathrm{B}})]) \rfloor & \text{if}\ 32 < \ell_{\mathrm{E}} \wedge i[(96 + \ell_{\mathrm{B}})..(127 + \ell_{\mathrm{B}})]\neq 0 \\ -8(\ell_{\mathrm{E}} - 32) & \text{otherwise} \\ +\ell'_{E} &=& \begin{cases} +0 & \text{if}\ \ell_{E}\le 32\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_{E}\le 32 \wedge E \neq 0 \\ +8(\ell_{E} - 32) + \lfloor \log_2(i[(96+\ell_{B})..(127+\ell_{B})]) \rfloor & \text{if}\ 32 < \ell_{E} \wedge i[(96 + \ell_{B})..(127 + \ell_{B})]\neq 0 \\ +8(\ell_{E} - 32) & \text{otherwise} \\ \end{cases} \\ -\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_{\mathrm{M}}} \\ -\ell_{\mathrm{B}} &\equiv& i[0..31] \\ -\ell_{\mathrm{E}} &\equiv& i[32..63] \\ -\ell_{\mathrm{M}} &\equiv& i[64..95] \\ -B &\equiv& i[96..(95+\ell_{\mathrm{B}})] \\ -E &\equiv& i[(96+\ell_{\mathrm{B}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})] \\ -M &\equiv& i[(96+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}}+\ell_{\mathrm{M}})] \\ +\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_{M}} \\ +\ell_{B} &\equiv& i[0..31] \\ +\ell_{E} &\equiv& i[32..63] \\ +\ell_{M} &\equiv& i[64..95] \\ +B &\equiv& i[96..(95+\ell_{B})] \\ +E &\equiv& i[(96+\ell_{B})..(95+\ell_{B}+\ell_{E})] \\ +M &\equiv& i[(96+\ell_{B}+\ell_{E})..(95+\ell_{B}+\ell_{E}+\ell_{M})] \\ i[x] &\equiv& \begin{cases} I_{\mathbf d}[x] &\text{if}\ x < |I_{\mathbf d}| \\ 0 &\text{otherwise} @@ -1682,7 +1682,7 @@ \section{Signing Transactions}\label{app:signing} The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_{\mathrm{r}}$, $T_{\mathrm{s}}$ and $T_{\mathrm{w}}$. The other operates on nine elements: \begin{eqnarray} -L_{\mathrm{S}}(T) & \equiv & \begin{cases} +L_{S}(T) & \equiv & \begin{cases} (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}) & \text{if} \; v \in \{27, 28\} \\ (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, \mathtt{\tiny chain\_{\mathrm{id}}}, (), ()) & \text{otherwise} \\ \end{cases} \\ @@ -1691,7 +1691,7 @@ \section{Signing Transactions}\label{app:signing} T_{\mathbf{i}} & \text{if}\ T_{\mathrm{t}} = 0 \\ T_{\mathbf{d}} & \text{otherwise} \end{cases} \\ -h(T) & \equiv & \mathtt{\small KEC}( L_{\mathrm{S}}(T) ) +h(T) & \equiv & \mathtt{\small KEC}( L_{S}(T) ) \end{eqnarray} The signed transaction $G(T, p_{\mathrm{r}})$ is defined as: @@ -2044,19 +2044,19 @@ \subsection{Instruction Set} &&&& in the block following it. \\ \midrule 0x41 & {\small COINBASE} & 0 & 1 & Get the block's beneficiary address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{c}}$ \\ \midrule 0x42 & {\small TIMESTAMP} & 0 & 1 & Get the block's timestamp. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{s}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{s}}$ \\ \midrule 0x43 & {\small NUMBER} & 0 & 1 & Get the block's number. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{i}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{i}}$ \\ \midrule 0x44 & {\small DIFFICULTY} & 0 & 1 & Get the block's difficulty. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{d}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{d}}$ \\ \midrule 0x45 & {\small GASLIMIT} & 0 & 1 & Get the block's gas limit. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{l}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{l}}$ \\ \bottomrule \end{tabular*} @@ -2214,7 +2214,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting}\\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ @@ -2233,7 +2233,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ @@ -2460,7 +2460,7 @@ \subsection{Proof-of-work function} The PoW-function returns an array with the compressed mix as its first item and the Keccak-256 hash of the concatenation of the compressed mix with the seed hash as the second item: \begin{equation} - \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) = \lbrace \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d}), \texttt{KEC}(\mathbf{s}_{\mathrm{h}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}) + \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d})) \rbrace + \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) = \lbrace \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d}), \texttt{KEC}(\mathbf{s}_{\mathrm{h}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}(H_{\hcancel{n}}))), H_{\mathrm{n}}) + \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d})) \rbrace \end{equation} With $H_{\hcancel{n}}$ being the hash of the header without the nonce. The compressed mix $\mathbf{m}_{\mathrm{c}}$ is obtained as follows: \begin{equation} From 34b641dfd0d7cacb28ea6592a4094458d81592ad Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:59:19 +1100 Subject: [PATCH 217/335] Remove mathrms where wrongly added --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e6147e9e..29280a2e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -832,8 +832,8 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ -\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ -\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ \Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 8 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_{\mathrm{a}} & \equiv & r \\ From d0aed8e97132b66b8ccba5782bdf17fdcc2a0582 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:02:25 +1100 Subject: [PATCH 218/335] Remove wrong mathrms --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 29280a2e..99255a3e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1624,22 +1624,22 @@ \subsection{zkSNARK Related Precompiled Contracts} We define a precompiled contract for addition on $G_1$. \begin{eqnarray} -\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}&\equiv&\Xi_{\mathtt{BN\_{\mathrm{PRE}}}}\quad\text{except:}\\ -\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ +\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_{\mathrm{PRE}}}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ g_{\mathrm{r}} &=& 500\\ \mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ x&\equiv&\delta_1(\bar I_{\mathbf d}[0..63])\\ y&\equiv&\delta_1(\bar I_{\mathbf d}[64..127])\\ -\label{eq:complemented_{\mathrm{input}}}\bar I_{\mathbf d}[x]&\equiv&\begin{cases} +\label{eq:complemented_input}\bar I_{\mathbf d}[x]&\equiv&\begin{cases} I_{\mathbf d}[x]&\text{if}\ x < |I_{\mathbf d}|\\ 0&\text{otherwise} \end{cases} \end{eqnarray} -We define a precompiled contract for scalar multiplication on $G_1$, where $\bar I_{\mathbf d}$ is defined in (\ref{eq:complemented_{\mathrm{input}}}). +We define a precompiled contract for scalar multiplication on $G_1$, where $\bar I_{\mathbf d}$ is defined in (\ref{eq:complemented_input}). \begin{eqnarray} -\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ -\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ +\Xi_{\mathtt{BN\_MUL}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ g_{\mathrm{r}} &=& 40000\\ \mathbf o&\equiv&\delta_1^{-1}(n\cdot x)\quad\text{where $\cdot$ is the scalar multiplication in $G_1$}\\ n&\equiv&\bar I_{\mathbf d}[0..31]\\ From a3927b035fed0fcbfe2007d553ce207880b21538 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:05:10 +1100 Subject: [PATCH 219/335] Remove wrong mathrms --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 99255a3e..5e6db8fc 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1624,7 +1624,7 @@ \subsection{zkSNARK Related Precompiled Contracts} We define a precompiled contract for addition on $G_1$. \begin{eqnarray} -\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_{\mathrm{PRE}}}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ g_{\mathrm{r}} &=& 500\\ \mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ From e91c99a92fd1647f4710aafe5caac9e70098c490 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:07:19 +1100 Subject: [PATCH 220/335] Remove wrong mathrms --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 5e6db8fc..d8036cba 100644 --- a/Paper.tex +++ b/Paper.tex @@ -954,7 +954,7 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{} +\hypertarget{Exceptional_Halting_function_Z}{} \subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: From c1788feb1e53ae4bc64b7dd25fce3edd5020f5b4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:13:31 +1100 Subject: [PATCH 221/335] Remove wrong mathrms --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index d8036cba..e45016f9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1394,10 +1394,10 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: \begin{eqnarray} y(\mathfrak{I}) & = & \{ (\mathbf{k}_0' \in \mathbb{Y}, \mathbf{v}_0 \in \mathbb{B}), (\mathbf{k}_1' \in \mathbb{Y}, \mathbf{v}_1 \in \mathbb{B}), ... \} \\ -\forall_{\mathrm{n}} \quad \forall_{i: i < 2\lVert\mathbf{k}_{\mathrm{n}}\rVert} \quad \mathbf{k}_{\mathrm{n}}'[i] & \equiv & +\forall_{n} \quad \forall_{i: i < 2\lVert\mathbf{k}_{n}\rVert} \quad \mathbf{k}_{n}'[i] & \equiv & \begin{cases} -\lfloor \mathbf{k}_{\mathrm{n}}[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ -\mathbf{k}_{\mathrm{n}}[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} +\lfloor \mathbf{k}_{n}[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ +\mathbf{k}_{n}[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} \end{cases} \end{eqnarray} @@ -1426,7 +1426,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_{\mathrm{x}} : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_{x} : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} From 1fb8c89404d2474d0aae5e6535f0f790645e1a33 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:15:41 +1100 Subject: [PATCH 222/335] Remove wrong mathrms --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e45016f9..47c75989 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2214,7 +2214,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting}\\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ @@ -2233,7 +2233,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}_{Z}}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ From db322787a19251ae2eb7e716a1a4848daae0f39c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:19:28 +1100 Subject: [PATCH 223/335] Add a missing forward slash --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 54766bda..4b7d658d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1075,7 +1075,7 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{mathbf{U} \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{\mathbf{U} \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) \end{equation} where $k$ denotes the ``is-kin'' property: From 42fede7810016cd13ecd548b3b32dc0ba6cea98b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:24:04 +1100 Subject: [PATCH 224/335] Add missing forward slashes before mathbfs --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4b7d658d..6ce11a88 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1108,7 +1108,7 @@ \subsection{Reward Application} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ \qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ -\qquad\forall_{mathbf{U} \in B_\mathbf{U}}: \\ \nonumber +\qquad\forall_{\mathbf{U} \in B_{\mathbf{U}}}: \\ \nonumber \boldsymbol{\sigma}'[U_c] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} @@ -1383,7 +1383,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} When considering such a sequence, we use the common numeric subscript notation to refer to a tuple's key or value, thus: \begin{equation} -\forall_{mathbf{I} \in \mathfrak{I}} I \equiv (I_0, I_1) +\forall_{\mathbf{I} \in \mathfrak{I}} I \equiv (I_0, I_1) \end{equation} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: @@ -1421,7 +1421,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{mathbf{I} \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{\mathbf{I} \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} From 6643e712ad02c8993fa1d33b55d05d7aef01e72b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:30:58 +1100 Subject: [PATCH 225/335] Fix error from auto find and replace T_gT_p => T_{\mathrm{gT}}_{\mathrm{p}} => T_{\mathrm{g}}T_{\mathrm{p}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 47c75989..d6a5f1fb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -614,7 +614,7 @@ \subsection{Execution} Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. -The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{gT}}_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. +The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. We define the checkpoint state $\boldsymbol{\sigma}_0$: \begin{eqnarray} From fed5ae2db122bc90820622beeee7cec018fe0d06 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:45:51 +1100 Subject: [PATCH 226/335] Add \pagebreak[1]s --- Paper.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index d1fb126f..86c510c0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -709,9 +709,7 @@ \section{Contract Creation} \label{ch:create} \begin{equation} (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} - -where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: - +\pagebreak[1]where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is:\pagebreak[1] \begin{eqnarray} I_a & \equiv & a \\ I_o & \equiv & o \\ From 8544de0a034d09adf2ab5cfe00829638573c5580 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:49:02 +1100 Subject: [PATCH 227/335] Fix an error with \hyperlink{Exceptional_Halting_function_Z} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index d6a5f1fb..6506e354 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2233,7 +2233,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}_{Z}}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ From d7cda8fe54777214454dbc9f3666135b61281122 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 14:31:25 +1100 Subject: [PATCH 228/335] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1afc5478..e960ebb9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2308,7 +2308,7 @@ \subsection{Instruction Set} %\section{Low-level Lisp-like Language}\label{app:lll} %The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. -\hypertarget{GenesisBlock}{} + \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: @@ -2328,17 +2328,17 @@ \subsection{Definitions} \toprule Name & Value & Description \\ \midrule -$J_{wordbytes}$ & 4 & Bytes in word. \hypertarget{Jdatasetinit}{}\\ -$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \hypertarget{Jdatasetgrowth}{}\\ -$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \hypertarget{Jcacheinit}{}\\ -$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \hypertarget{Jcachegrowth}{}\\ -$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \hypertarget{Jepoch}{}\\ -$J_{epoch}$ & 30000 & Blocks per epoch. \hypertarget{Jmixbytes}{}\\ -$J_{mixbytes}$ & 128 & mix length in bytes. \hypertarget{Jhashbytes}{}\\ -$J_{hashbytes}$ & 64 & Hash length in bytes. \hypertarget{Jparents}{}\\ -$J_{parents}$ & 256 & Number of parents of each dataset element. \\hypertarget{Jcacherounds}{}\ -$J_{cacherounds}$ & 3 & Number of rounds in cache production. \hypertarget{Jaccesses}{}\\ -$J_{accesses}$ & 64 & Number of accesses in hashimoto loop. \\ +$J_{wordbytes}$ & 4 & Bytes in word. \\ +\linkdest{J__datasetinit}{}$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ +\linkdest{J__datasetgrowth}{}$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \\ +\linkdest{J__cacheinit}{}$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \\ +\linkdest{J__cachegrowth}{}$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \\ +\linkdest{J__epoch}{}$J_{epoch}$ & 30000 & Blocks per epoch. \\ +\linkdest{J__mixbytes}{}$J_{mixbytes}$ & 128 & mix length in bytes. \\ +\linkdest{J__hashbytes}{}$J_{hashbytes}$ & 64 & Hash length in bytes. \\ +\linkdest{J__parents}{}$J_{parents}$ & 256 & Number of parents of each dataset element. \\ +\linkdest{J__cacherounds}{}$J_{cacherounds}$ & 3 & Number of rounds in cache production. \\ +\linkdest{J__accesses}{}$J_{accesses}$ & 64 & Number of accesses in hashimoto loop. \\ \bottomrule \end{tabular*} @@ -2347,8 +2347,8 @@ \subsection{Size of dataset and cache} \begin{equation} E_{epoch}(H_i) = \left\lfloor\frac{H_i}{J_{epoch}}\right\rfloor \end{equation} -The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache.\hypertarget{dsize}{} -Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using +The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache. +\linkdest{d__size}{}Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using \begin{equation} d_{size} = E_{prime}(J_{datasetinit} + J_{datasetgrowth} \cdot E_{epoch} - J_{mixbytes}, J_{mixbytes}) \end{equation} @@ -2407,7 +2407,7 @@ \subsubsection{Cache} \end{equation} Where a single round modifies each subset of the cache as follows: \begin{equation} - E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big)\hypertarget{Ecacherounds}{} + E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big)\linkdest{E__cacherounds}{} \end{equation} \begin{multline} E_{rmh}(\mathbf{x}, i) = \texttt{KEC512}(\mathbf{x'}[(i - 1 + n) \mod n] \oplus \mathbf{x'}[\mathbf{x'}[i][0] \mod n]) \\ From 5e4e44eef9f0df6c623f201fc98543e5711a6668 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:50:32 +1100 Subject: [PATCH 229/335] \hypertarget{R l}{}Thus --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 881057e5..f13b678b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1327,8 +1327,8 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} -\hypertarget{R l}{} -Thus we finish by formally defining $R_l$: + +\hypertarget{R l}{}Thus we finish by formally defining $R_l$: \begin{eqnarray} R_l(\mathbf{x}) & \equiv & \begin{cases} (192 + \lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{if} \quad \lVert s(\mathbf{x}) \rVert < 56 \\ From 7479ba0e0c920343153ca84d8d11e554a122c621 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:52:50 +1100 Subject: [PATCH 230/335] Move \linkdest{Transaction Receipt}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 319916c7..704255b1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -345,9 +345,9 @@ \subsection{The Block} \label{ch:block} \linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\linkdest{Transaction Receipt}{} +\end{equation} -\subsubsection{Transaction Receipt} +\subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. From 26e25ec425864e91112088c9530a7cf8bfcd0ab7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:54:32 +1100 Subject: [PATCH 231/335] Readd JUMPI --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d5dc4aa0..bb1d1ba4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -951,8 +951,7 @@ \subsubsection{Exceptional Halting} \boldsymbol{\mu}_g < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ -( w \in \{ \text{\small JUMP}, \text{\small -} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ +( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ ( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ \neg I_w \wedge W(w, \boldsymbol{\mu}) From 2ba7911e566dd7ebdbafd56ab0e861700ff6a2d8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:56:45 +1100 Subject: [PATCH 232/335] Make empty second argument \linkdest{blockhash}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8e787a75..05cd35f9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2019,7 +2019,7 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ -\linkdest{blockhash}{BLOCKHASH}0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ +\linkdest{blockhash}{}0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ From b59d31cf3fbb218b1d583feb7b57866fc2fc064a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 22:03:09 +1100 Subject: [PATCH 233/335] Append {} after \linkdest{JUMP}, remove JUMP in second braces --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index bb1d1ba4..31078fc4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2082,11 +2082,11 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ \midrule -\linkdest{JUMP}{JUMP}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ +\linkdest{JUMP}{}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}.\\ \midrule -\linkdest{JUMPI}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ +\linkdest{JUMPI}{}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ \midrule From ea581e5cf60f082ab5a244003fcbb9586e86ff2e Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Wed, 31 Jan 2018 10:45:21 +0000 Subject: [PATCH 234/335] Minor corrections and revisions to transaction receipt section --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index f9111885..c80c3e9d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -350,10 +350,10 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} -In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. +In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$, the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: \begin{equation} R \equiv (R_z, R_u, R_b, R_\mathbf{l}) @@ -377,7 +377,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} %Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_B$; it is merely a convenience equivalence. -The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_a$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} O \equiv (O_a, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} @@ -390,7 +390,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} M(O) \equiv \bigvee_{t \in \{O_a\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) \end{equation} -where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence./footnote{11 bits $= 2^2048$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: +where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence.\footnote{11 bits $= 2^{2048}$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: \begin{eqnarray} M_{3:2048}(\mathbf{x}: \mathbf{x} \in \mathbb{B}) & \equiv & \mathbf{y}: \mathbf{y} \in \mathbb{B}_{256} \quad \text{where:}\\ \mathbf{y} & = & (0, 0, ..., 0) \quad \text{except:}\\ From 31a82fd597aa8f10a3317b2b96dbe0f9bd5163e3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 31 Jan 2018 15:56:58 +0100 Subject: [PATCH 235/335] Fix the calculation of cache size in ethash See https://github.com/ethereum/yellowpaper/issues/517 This has to be ported to all protocol versions. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..d9b66c51 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2373,7 +2373,7 @@ \subsection{Size of dataset and cache} \begin{equation} E_{prime}(x, y) = \begin{cases} x & \text{if} \quad x / y \in \mathbb{P} \\ -E_{prime}((x - 1) \cdot y, y) & \text{otherwise} +E_{prime}(x - 2 \cdot y, y) & \text{otherwise} \end{cases} \end{equation} \subsection{Dataset generation} From 484037ab15aed6f258ac5293edb60399544e5e2d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:27:31 +1100 Subject: [PATCH 236/335] Remove {} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 60c5d0dd..854ad06e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -258,7 +258,7 @@ \subsection{The Transaction} \label{ch:transaction} \item[nonce]\linkdest{tx_nonce}{} A scalar value equal to the number of transactions sent by the sender; formally $T_n$. \item[gasPrice]\linkdest{tx_gas_price_T__p}{} A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. \item[gasLimit]\linkdest{tx_gas_limit_T__g}{} A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. -\item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.{} +\item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$. \item[value]\linkdest{tx_value_T__v} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From e4c336fc8514798254eccb97079c1dea8cea5efc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:35:31 +1100 Subject: [PATCH 237/335] \linkdest{block_validity}{}, \linkdest{new_state_H__r}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7547d96e..0aa8ae15 100644 --- a/Paper.tex +++ b/Paper.tex @@ -387,10 +387,10 @@ \subsubsection{Transaction Receipt} \subsubsection{Holistic Validity} -We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: +\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} \begin{array}[t]{lclc} -\linkdest{block_validity_H__r}{}H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +\linkdest{new_state_H__r}{}H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ \linkdest{Ommer_block_hash_H__o}{}H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ \linkdest{tx_block_hash_H__t}{}H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ \linkdest{Receipts_Root_H__e}{}H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ From 43433329639a885caf8f8298e30534ff1a3b29ea Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:36:23 +1100 Subject: [PATCH 238/335] \hypertarget{Omega}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1d4bf056..77c6e77c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1093,7 +1093,7 @@ \subsection{Transaction Validation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{Omega} Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{} Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ From 980698244169d834cdfbea82da6de9def6cf893c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:37:12 +1100 Subject: [PATCH 239/335] \hypertarget{block_reward_R__b}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 77c6e77c..36305e23 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1109,7 +1109,7 @@ \subsection{Reward Application} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -\hypertarget{block-reward-R-b}{block-reward-R-b}We define the block reward as 3 Ether: +\hypertarget{block_reward_R__b}{}We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_b = 3 \times 10^{18} \end{equation} From af8f9556591d018b0999c77abf1566da6b9a23f3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:37:41 +1100 Subject: [PATCH 240/335] \hypertarget{Gamma}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 36305e23..620a36e7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1116,7 +1116,7 @@ \subsection{Reward Application} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} -\hypertarget{Gamma}{Gamma}We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: +\hypertarget{Gamma}{}We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_H) = \varnothing \\ From 5b8491164b7151a539844b5eb9ba3100ea5d2b00 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:38:07 +1100 Subject: [PATCH 241/335] \hypertarget{Phi}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 620a36e7..beca185e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1126,7 +1126,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. -\hypertarget{Phi}{Phi}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: +\hypertarget{Phi}{}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ B'_n & = & n: \quad x \leqslant \frac{2^{256}}{H_d} \\ From c829b7068f1e9270f4492c9a6c210b80879c2e5f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:38:43 +1100 Subject: [PATCH 242/335] \hypertarget{Pi}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index beca185e..b2fd9d39 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1163,7 +1163,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -\hypertarget{Pi}{Pi}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: +\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: \begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} From ef88bef17720a5653bc54ce940eb7a78399a1274 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:43:01 +1100 Subject: [PATCH 243/335] Move \hypertarget{h T}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 687d7928..af5ca0d6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1664,8 +1664,8 @@ \section{Signing Transactions}\label{app:signing} \begin{equation} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} -\hypertarget{h T}{} -The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: + +\hypertarget{h T}{}The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} (T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\} \\ From eb1caa6245a90cf5e5f8f3c388c131419a1c80e4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:47:07 +1100 Subject: [PATCH 244/335] _{\mathrm{t}} => _{t} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6506e354..a22e18fe 100644 --- a/Paper.tex +++ b/Paper.tex @@ -116,7 +116,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) +\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -127,7 +127,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Formally, we expand to: \begin{eqnarray} -\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{\mathrm{t}}, B) \\ +\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{t}, B) \\ B & \equiv & (..., (T_0, T_1, ...) ) \\ \Pi(\boldsymbol{\sigma}, B) & \equiv & \Omega(B, \Upsilon(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \end{eqnarray} From fc898b15d057ede739b499688141d07e22072e87 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:30:12 +1100 Subject: [PATCH 245/335] Fix in-text citations: *by* \cite{EIP-#} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..32ecf35b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -502,7 +502,7 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 by \cite{EIP-649} and delayed and implemented earlier in EIP-2. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks by \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. \hypertarget{block_gas_limit_H__l}{}The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 89ac1de111256ca5eef0036ed02266803528bff2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:32:53 +1100 Subject: [PATCH 246/335] Add parentheses around \cite{Davey2002_zbMATH01748069} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 32ecf35b..4447b9c6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2517,7 +2517,7 @@ \section{List of mathematical symbols}\label{app:symbols} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements \cite{Davey2002_zbMATH01748069}.\\ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabu*} From a691d3d98699d8917d1d3329d110e6853a6711b6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:34:17 +1100 Subject: [PATCH 247/335] Remove \\ in 0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..303ce71d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,7 +2510,7 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Despite Out-of-gas} -At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \section{List of mathematical symbols}\label{app:symbols} \begin{tabu*}{X[l]X[c]X} \savetabu{col3} From fc55da93472df833e378d26fe353ff67b0c58779 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:43:09 +1100 Subject: [PATCH 248/335] Move \hypertarget{Exceptional_Halting_function_Z}{} The column actually broke on the preceding line, causing hyperlinks to direct to the bottom of the column. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..296cdec9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -955,8 +955,8 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_Halting_function_Z}{} -\subsubsection{Exceptional Halting} + +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} The exceptional halting function $Z$ is defined as: \begin{equation} From 3e5726002e2d624a12d73dd0c5544414efcea644 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:51:50 +1100 Subject: [PATCH 249/335] Move hypertargets to the same line as section headings, and rename some targets --- Paper.tex | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index 296cdec9..71c48b5e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1298,8 +1298,8 @@ \section{Terminology} \label{ch:Terminology} \item[LLL] The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to. \end{description} -\hypertarget{rlp}{} -\section{Recursive Length Prefix}\label{app:rlp} + +\section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} This is a serialisation method for encoding arbitrarily structured binary data (byte arrays). We define the set of possible structures $\mathbb{T}$: @@ -1323,8 +1323,8 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the byte-array contains fewer than 56 bytes, then the output is equal to the input prefixed by the byte equal to the length of the byte array plus 128. \item Otherwise, the output is equal to the input prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the input byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183. \end{itemize} -\hypertarget{R b}{} -Formally, we define $R_b$: + +\hypertarget{RLP_serialisation_of_a_byte_array_R__b_math_def}{}Formally, we define $R_b$: \begin{eqnarray} R_b(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ @@ -1344,7 +1344,7 @@ \section{Recursive Length Prefix}\label{app:rlp} \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} -\hypertarget{R l}{}Thus we finish by formally defining $R_l$: +\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{}Thus we finish by formally defining $R_l$: \begin{eqnarray} R_l(\mathbf{x}) & \equiv & \begin{cases} (192 + \lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{if} \quad \lVert s(\mathbf{x}) \rVert < 56 \\ @@ -1378,8 +1378,8 @@ \section{Hex-Prefix Encoding}\label{app:hexprefix} \end{eqnarray} Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the second-lowest encoding the flag $t$. The low nibble of the first byte is zero in the case of an even number of nibbles and the first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining bytes. -\hypertarget{trie}{} -\section{Modified Merkle Patricia Tree}\label{app:trie} + +\section{Modified Merkle Patricia Tree}\label{app:trie}\hypertarget{trie}{} The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32 byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. Formally, we assume the input value $\mathfrak{I}$, a set containing pairs of byte sequences: @@ -2322,8 +2322,7 @@ \subsection{Instruction Set} \bottomrule \end{tabular*} -\hypertarget{GenesisBlock}{} -\section{Genesis Block}\label{app:genesis} +\section{Genesis Block}\label{app:genesis}\hypertarget{GenesisBlock}{} The genesis block is 15 items, and is specified thus: \begin{equation} From e6eb7a94bc4cd63e5bcc4b6b1250f8874bf05f7a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:56:29 +1100 Subject: [PATCH 250/335] Add RLP R_b and R_l word defs. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 71c48b5e..9914e2a7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1316,7 +1316,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_b(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_l(\mathbf{x}) & \text{otherwise} \end{cases} \end{equation} -If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: +\hypertarget{RLP_serialisation_of_a_byte_array_R__b_word_def}{}If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: \begin{itemize} \item If the byte-array contains solely a single byte and that single byte is less than 128, then the input is exactly equal to the output. @@ -1337,7 +1337,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} Thus $\mathtt{\tiny BE}$ is the function that expands a positive integer value to a big-endian byte array of minimal length and the dot operator performs sequence concatenation. -If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: +\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_word_def}{}If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: \begin{itemize} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. From 123f30b6ef19884fd8ee8d43efe91a93ce781bcf Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 12:03:08 +1100 Subject: [PATCH 251/335] Remove duplicate hypertargets --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index c4191150..d49d5c80 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1687,13 +1687,13 @@ \section{Signing Transactions}\label{app:signing} %Uncomment out after merging \hypertargets for v, r, and s. %Thus: -%\begin{eqnarray}\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} +%\begin{eqnarray}\hypertarget{T__w}{}\hypertarget{T__r}{}\hypertarget{T__s}{} %T_{\mathrm{w}} = \hyperlink{v}{v}\\ %T_{\mathrm{r}} = \hyperlink{r}{r}\\ %T_{\mathrm{s}} = \hyperlink{s}{s} %\end{eqnarray} -We may then define the sender function $S$ of the transaction as:\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} +We may then define the sender function $S$ of the transaction as: \begin{eqnarray} S(T) &\equiv& \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), v_0, T_r, T_s) \big) \big) \\ v_0 &\equiv& \begin{cases} From 9f585d45c52adb5d761d147ceb1c5c6597f51efb Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Feb 2018 14:38:14 +0100 Subject: [PATCH 252/335] Final touches See PR https://github.com/ethereum/yellowpaper/pull/515 --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 389fca61..11f7876e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -210,7 +210,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: \begin{description} -\item[nonce] \linkdest{account_{\mathrm{nonce}}}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{n}}$. +\item[nonce] \linkdest{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{n}}$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{b}}$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{s}}$. \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{c}}$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_{\mathrm{c}}$. @@ -327,8 +327,8 @@ \subsection{The Block} \label{ch:block} \begin{description} \item[parentHash]\linkdest{parent_Hash_H__p_def_words}{} The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_{\mathrm{p}}$. -\item[ommersHash]\linkdest{beneficiary_H__c}{} The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. -\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. +\item[beneficiary]\linkdest{beneficiary_H__c}{} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_{\mathrm{r}}$. \item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_{\mathrm{t}}$. \item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. From ee76f605c2a91a532b0a85c0e800e14a1f646795 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Feb 2018 15:19:15 +0100 Subject: [PATCH 253/335] Add a missing {} as the second argument of \linkdest --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 725993ef..6a171af5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -273,7 +273,7 @@ \subsection{The Transaction} \label{ch:transaction} \item[gasPrice]\linkdest{tx_gas_price_T__p}{} A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_{\mathrm{p}}$. \item[gasLimit]\linkdest{tx_gas_limit_T__g}{} A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. \item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. -\item[value]\linkdest{tx_value_T__v} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. +\item[value]\linkdest{tx_value_T__v}{} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$. This is expanded in Appendix \ref{app:signing}. \end{description} From 21520d5f465b9072691be6fa605d770855ce56b7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 09:54:33 +1100 Subject: [PATCH 254/335] 2 \hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{f^*} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..e4cb9263 100644 --- a/Paper.tex +++ b/Paper.tex @@ -191,7 +191,7 @@ \section{Conventions}\label{ch:conventions} When considering variants of existing values, I follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, I may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. -When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. +When considering the use of existing functions, given a function $f$, the function \hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{$f^*$} denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: @@ -435,7 +435,7 @@ \subsubsection{Serialisation} \hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} -f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f +\hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{f^*}\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} The component types are defined thus: From ee0e997612ff07507c6be58c59cc11f628bd09b4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:03:27 +1100 Subject: [PATCH 255/335] \linkdest{r}{r} \linkdest{s}{s} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..62546b8f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1665,8 +1665,8 @@ \section{Signing Transactions}\label{app:signing} We declare that a signature is invalid unless all the following conditions are true: \begin{align} -0 < r &< \mathtt{\tiny secp256k1n} \\ -0 < s &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ +0 < \linkdest{r}{r} &< \mathtt{\tiny secp256k1n} \\ +0 < \linkdest{s}{s} &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ v &\in \{27,28,\mathtt{\tiny chain\_{\mathrm{id}}} \times 2 + 35, \mathtt{\tiny chain\_{\mathrm{id}}} \times 2 + 36\} \end{align} where: From b2e6381e254a05753926ef9aeb046b6cf03bc7f5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:12:41 +1100 Subject: [PATCH 256/335] \hypertarget{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..77aaf0a3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -264,7 +264,7 @@ \subsection{World State} \label{ch:state} \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} -\subsection{The Transaction} \label{ch:transaction} +\subsection{The Transaction} \label{subsec:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: @@ -274,7 +274,7 @@ \subsection{The Transaction} \label{ch:transaction} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. \item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. -\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$. This is expanded in Appendix \ref{app:signing}. +\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally \hypertarget{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$}. This is expanded in Appendix \ref{app:signing}. \end{description} Additionally, a contract creation transaction contains: From 51ad91d3444d54199982f157be1f7f2794a01b8d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:18:47 +1100 Subject: [PATCH 257/335] hypertarget => linkdest I tested the former and it direct to the next line. Thus linkdest must be used whenever it encapsulates math mode, or any part, or is included in it. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 77aaf0a3..3f000832 100644 --- a/Paper.tex +++ b/Paper.tex @@ -274,7 +274,7 @@ \subsection{The Transaction} \label{subsec:transaction} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. \item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. -\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally \hypertarget{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$}. This is expanded in Appendix \ref{app:signing}. +\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally \linkdest{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$}. This is expanded in Appendix \ref{app:signing}. \end{description} Additionally, a contract creation transaction contains: From b4355f4a267025a1d02ccefe11feec6f2db8aef3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:21:20 +1100 Subject: [PATCH 258/335] Thus => Reiterating from \hyperlink{T__w_T__r_T__s}{previously} --- Paper.tex | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index d49d5c80..4f1d9d97 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1685,13 +1685,12 @@ \section{Signing Transactions}\label{app:signing} (T_w, T_r, T_s) = \mathtt{\small ECDSASIGN}(h(T), p_r) \end{eqnarray} -%Uncomment out after merging \hypertargets for v, r, and s. -%Thus: -%\begin{eqnarray}\hypertarget{T__w}{}\hypertarget{T__r}{}\hypertarget{T__s}{} -%T_{\mathrm{w}} = \hyperlink{v}{v}\\ -%T_{\mathrm{r}} = \hyperlink{r}{r}\\ -%T_{\mathrm{s}} = \hyperlink{s}{s} -%\end{eqnarray} +Reiterating from \hyperlink{T__w_T__r_T__s}{previously}: +\begin{eqnarray} +\linkdest{T__w}{T_{\mathrm{w}}} = \hyperlink{v}{v}\\ +\linkdest{T__r}{T_{\mathrm{r}} = \hyperlink{r}{r}\\ +\linkdest{T__s}{T_{\mathrm{s}} = \hyperlink{s}{s} +\end{eqnarray} We may then define the sender function $S$ of the transaction as: \begin{eqnarray} From a63aad7a91e1ab4eddcc801483a9ed84edb51e9f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:32:37 +1100 Subject: [PATCH 259/335] \hyperlink{trie}{trie} & \hyperlink{Receipts_Root_H__e}{$H_{\mathrm{e}}$} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..a075e2ce 100644 --- a/Paper.tex +++ b/Paper.tex @@ -351,7 +351,7 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed \hyperlink{trie}{trie} and the root recorded in the header as \hyperlink{Receipts_Root_H__e}{$H_{\mathrm{e}}$}. \linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} From 5ce6bcadcdf6fad9f5787abd226347f69d51c52d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:38:47 +1100 Subject: [PATCH 260/335] Ommer footnote, link words to maths. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..b6b5f8f6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -321,7 +321,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (which is not saying much, in that it isn't commonly used) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} @@ -343,12 +343,12 @@ \subsection{The Block} \label{ch:block} \item[nonce]\linkdest{block_nonce_H__n}{} A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{n}}$. \end{description} -\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: +\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above), $B_{\mathbf{U}}$ and a series of the transactions, $B_{\mathbf{T}}$. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}}) \end{equation} -\subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} +\subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. From c6308591e91cb870b845ab8641652d6ace58386b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:13:09 +1100 Subject: [PATCH 261/335] Transaction receipt changes \Upsilon^z => \Upsilon{\mathrm{z}}, \Upsilon^g => \Upsilon{\mathrm{g}} \linkdest{Transaction_Receipt}{} \hyperlink{Transaction_Receipt}{transaction receipt} Other targets for parameters --- Paper.tex | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..30b046d3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -348,12 +348,12 @@ \subsection{The Block} \label{ch:block} B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) \end{equation} -\subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} +\subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt, $R$, is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, \hyperlink{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{$R_\mathbf{l}$} and the Bloom filter composed from information in those logs, \hyperlink{RLP_serialisation_of_a_byte_array_R__b_math_def}{$R_{\mathrm{b}}$} and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) \end{equation} @@ -376,7 +376,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} %Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. -The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_{\mathbf{l}}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_{\mathbf{t}}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} @@ -570,7 +570,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^z$ to evaluate to the status code resulting from the transaction. These will be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^{\mathrm{g}}$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^{\mathbf{l}}$ to evaluate to the transaction's accrued log items and $\Upsilon^{\mathrm{z}}$ to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: @@ -661,14 +661,14 @@ \subsection{Execution} \linkdest{touched_A__t}{}\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{}And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_z}{}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: \begin{eqnarray} -\Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ +\Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ -\Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z +\Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} -These are used to help define the transaction receipt, discussed later. +These are used to help define the \hyperlink{Transaction_Receipt}{transaction receipt}. \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} @@ -1161,7 +1161,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \begin{equation} \mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} +\Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} @@ -1169,13 +1169,13 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} For $\mathbf{R}[n]_\mathbf{l}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. \begin{equation} \mathbf{R}[n]_\mathbf{l} = -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^{\mathbf{l}}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{\mathrm{z}} = -\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} \hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From c6cd9a555af0cc96231f1e51b7e4114a41d9db6e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:14:43 +1100 Subject: [PATCH 262/335] Remove braces around \mathbf --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 30b046d3..676cf6a8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -376,7 +376,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} %Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. -The sequence $R_{\mathbf{l}}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_{\mathbf{t}}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} From 1566aa7911fe76cd6290dbf44ba1ac463d8c9e87 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:20:00 +1100 Subject: [PATCH 263/335] Replace _(\\mathbf\{[:alnum:]+\}) with _{$1} ...using Libre Open Office with regular expressions ticked as an option. --- Paper.tex | 442 +++++++++++++++++++++++++++--------------------------- 1 file changed, 221 insertions(+), 221 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..df23849d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -185,7 +185,7 @@ \section{Conventions}\label{ch:conventions} Throughout, we assume scalars are positive integers and thus belong to the set $\mathbb{P}$. The set of all byte sequences is $\mathbb{B}$, formally defined in Appendix \ref{app:rlp}. If such a set of sequences is restricted to those of a particular length, it is denoted with a subscript, thus the set of all byte sequences of length $32$ is named $\mathbb{B}_{32}$ and the set of all positive integers smaller than $2^{256}$ is named $\mathbb{P}_{256}$. This is formally defined in section \ref{ch:block}. -Square brackets are used to index into and reference individual components or subsequences of sequences, \eg $\boldsymbol{\mu}_\mathbf{s}[0]$ denotes the first item on the machine's stack. For subsequences, ellipses are used to specify the intended range, to include elements at both limits, \eg $\boldsymbol{\mu}_\mathbf{m}[0..31]$ denotes the first 32 items of the machine's memory. +Square brackets are used to index into and reference individual components or subsequences of sequences, \eg $\boldsymbol{\mu}_{\mathbf{s}}[0]$ denotes the first item on the machine's stack. For subsequences, ellipses are used to specify the intended range, to include elements at both limits, \eg $\boldsymbol{\mu}_{\mathbf{m}}[0..31]$ denotes the first 32 items of the machine's memory. In the case of the global state $\boldsymbol{\sigma}$, which is a sequence of accounts, themselves tuples, the square brackets are used to reference an individual account. @@ -218,7 +218,7 @@ \subsection{World State} \label{ch:state} Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: \begin{equation} -\texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} +\texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_{\mathbf{s}})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} The collapse function for the set of key/value pairs in the trie, $L_{I}^*$, is defined as the element-wise transformation of the base function $L_{I}$, given as: @@ -231,7 +231,7 @@ \subsection{World State} \label{ch:state} k \in \mathbb{B}_{32} \quad \wedge \quad v \in \mathbb{P} \end{equation} -It shall be understood that $\boldsymbol{\sigma}[a]_\mathbf{s}$ is not a `physical' member of the account and does not contribute to its later serialisation. +It shall be understood that $\boldsymbol{\sigma}[a]_{\mathbf{s}}$ is not a `physical' member of the account and does not contribute to its later serialisation. If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. @@ -280,7 +280,7 @@ \subsection{The Transaction} \label{ch:transaction} Additionally, a contract creation transaction contains: \begin{description} -\item[init] An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally $T_\mathbf{i}$. +\item[init] An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally $T_{\mathbf{i}}$. \end{description} \textbf{init} is an EVM-code fragment; it returns the \textbf{body}, a second fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code). \textbf{init} is executed only once at account creation and gets discarded immediately thereafter. @@ -288,24 +288,24 @@ \subsection{The Transaction} \label{ch:transaction} In contrast, a message call transaction contains: \begin{description} -\item[data] An unlimited size byte array specifying the input data of the message call, formally $T_\mathbf{d}$. +\item[data] An unlimited size byte array specifying the input data of the message call, formally $T_{\mathbf{d}}$. \end{description} Appendix \ref{app:signing} specifies the function, $S$, which maps transactions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction $T$ can be represented with $S(T)$. \begin{equation} L_{T}(T) \equiv \begin{cases} -(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{i}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ -(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{d}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathbf{i}}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathbf{d}}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} \end{equation} -Here, we assume all components are interpreted by the RLP as integer values, with the exception of the arbitrary length byte arrays $T_\mathbf{i}$ and $T_\mathbf{d}$. +Here, we assume all components are interpreted by the RLP as integer values, with the exception of the arbitrary length byte arrays $T_{\mathbf{i}}$ and $T_{\mathbf{d}}$. \begin{equation} \begin{array}[t]{lclclc} T_{\mathrm{n}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{v}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{p}} \in \mathbb{P}_{256} & \wedge \\ T_{\mathrm{g}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{w}} \in \mathbb{P}_5 & \wedge & T_{\mathrm{r}} \in \mathbb{P}_{256} & \wedge \\ -T_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge & T_\mathbf{d} \in \mathbb{B} & \wedge & T_\mathbf{i} \in \mathbb{B} +T_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge & T_{\mathbf{d}} \in \mathbb{B} & \wedge & T_{\mathbf{i}} \in \mathbb{B} \end{array} \end{equation} where @@ -313,9 +313,9 @@ \subsection{The Transaction} \label{ch:transaction} \mathbb{P}_{\mathrm{n}} = \{ P: P \in \mathbb{P} \wedge P < 2^n \} \end{equation} -The address hash $T_\mathbf{t}$ is slightly different: it is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to $\varnothing$), it is the RLP empty byte sequence and thus the member of $\mathbb{B}_0$: +The address hash $T_{\mathbf{t}}$ is slightly different: it is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to $\varnothing$), it is the RLP empty byte sequence and thus the member of $\mathbb{B}_0$: \begin{equation} -T_\mathbf{t} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ +T_{\mathbf{t}} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} @@ -345,22 +345,22 @@ \subsection{The Block} \label{ch:block} \linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}) \end{equation} \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. +Each receipt, denoted $B_{\mathbf{R}}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_{\mathbf{l}}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} -R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) +R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}}) \end{equation} The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) +L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}) \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. @@ -374,19 +374,19 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} R_{\mathrm{u}} \in \mathbb{P} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \end{equation} -%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. +%Notably $B_{\mathbf{T}}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. -The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_{\mathbf{l}}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_{\mathbf{t}}$ and some number of bytes of data, $O_{\mathbf{d}}$: \begin{equation} -O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) +O \equiv (O_{\mathrm{a}}, ({O_{\mathbf{t}}}_0, {O_{\mathbf{t}}}_1, ...), O_{\mathbf{d}}) \end{equation} \begin{equation} -O_{\mathrm{a}} \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_\mathbf{t}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_\mathbf{d} \in \mathbb{B} +O_{\mathrm{a}} \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_{\mathbf{t}}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_{\mathbf{d}} \in \mathbb{B} \end{equation} We define the Bloom filter function, $M$, to reduce a log entry into a single 256-byte hash: \begin{equation} -M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) +M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_{\mathbf{t}}} \big( M_{3:2048}(t) \big) \end{equation} where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence.\footnote{11 bits $= 2^{2048}$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: @@ -401,14 +401,14 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} \subsubsection{Holistic Validity} -\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: +\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_{\mathbf{T}}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: \begin{equation} \begin{array}[t]{lclc} \linkdest{new_state_H__r}{}H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -\linkdest{Ommer_block_hash_H__o}{}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ -\linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_\mathbf{T}[i]))\}) & \wedge \\ -\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_\mathbf{R}[i]))\}) & \wedge \\ -\linkdest{logs_Bloom_filter_H__b}{}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_{\mathrm{b}} \big) +\linkdest{Ommer_block_hash_H__o}{}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_{\mathbf{U}}))) & \wedge \\ +\linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{T}} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_{\mathbf{T}}[i]))\}) & \wedge \\ +\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_{\mathbf{R}}[i]))\}) & \wedge \\ +\linkdest{logs_Bloom_filter_H__b}{}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_{\mathbf{R}}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} where $p(k, v)$ is simply the pairwise RLP transformation, in this case, the first being the index of the transaction in the block and the second being the transaction receipt: @@ -423,14 +423,14 @@ \subsubsection{Holistic Validity} Thus $\texttt{\small TRIE}(L_{S}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{H})$ is the parent block of $B$, defined directly. -The values stemming from the computation of transactions, specifically the transaction receipts, $B_\mathbf{R}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. +The values stemming from the computation of transactions, specifically the transaction receipts, $B_{\mathbf{R}}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ -\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_\mathbf{T}), L_{H}^*(B_\mathbf{U}) \big) +\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) \end{eqnarray} \hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: @@ -492,7 +492,7 @@ \subsubsection{Block Header Validity} \end{equation} \begin{equation*} x \equiv \begin{cases} -1 & \text{if} \, \lVert P(H)_\mathbf{U}\rVert = 0 \\ +1 & \text{if} \, \lVert P(H)_{\mathbf{U}}\rVert = 0 \\ 2 & \text{otherwise} \end{cases} \end{equation*} @@ -575,10 +575,10 @@ \section{Transaction Execution} \label{ch:transactions} \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} -A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_{\mathrm{r}}) +A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}) \end{equation} -\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} @@ -588,12 +588,12 @@ \subsection{Substate} \subsection{Execution} \hypertarget{intrinsic_gas_g_0}{}We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} -g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ +g_0 \equiv {} & \sum_{i \in T_{\mathbf{i}}, T_{\mathbf{d}}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ {} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ {} & + G_{transaction} \end{align} -where $T_\mathbf{i},T_\mathbf{d}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. +where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. The up-front cost $v_0$ is calculated as: \begin{equation} @@ -608,11 +608,11 @@ \subsection{Execution} \linkdest{transaction_nonce}{}T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ -T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} +T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_{\mathbf{R}})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. @@ -626,8 +626,8 @@ \subsection{Execution} Evaluating $\boldsymbol{\sigma}_{P}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{P}$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} (\boldsymbol{\sigma}_{P}, g', A, z) \equiv \begin{cases} -\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_\mathbf{i}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ -\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_\mathbf{d}, 0, \top) & \text{otherwise} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathbf{i}}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ +\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_{\mathbf{d}}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -657,14 +657,14 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\linkdest{self_destruct_list_A__s}{}\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ -\linkdest{touched_A__t}{}\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) +\linkdest{self_destruct_list_A__s}{}\forall i \in A_{\mathbf{s}}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\linkdest{touched_A__t}{}\forall i \in A_{\mathbf{t}}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} \hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{}And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_{\mathbf{l}} \\ \Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} @@ -696,7 +696,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} \end{cases} \\ -\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_{\mathrm{n}}, \boldsymbol{\sigma}[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_{\mathrm{c}}) +\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_{\mathrm{n}}, \boldsymbol{\sigma}[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}[s]_{\mathbf{s}}, \boldsymbol{\sigma}[s]_{\mathrm{c}}) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: @@ -719,15 +719,15 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{a}} & \equiv & a \\ I_{\mathrm{o}} & \equiv & o \\ I_{\mathrm{p}} & \equiv & p \\ -I_\mathbf{d} & \equiv & () \\ +I_{\mathbf{d}} & \equiv & () \\ I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & v \\ -I_\mathbf{b} & \equiv & \mathbf{i} \\ +I_{\mathbf{b}} & \equiv & \mathbf{i} \\ I_{\mathrm{e}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{H}$ has no special treatment and is determined from the blockchain. +$I_{\mathbf{d}}$ evaluates to the empty tuple as there is no input data to this call. $I_{H}$ has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, $\varnothing$, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. @@ -795,7 +795,7 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_{\mathrm{n}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_{\mathrm{c}}) +\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_{\mathrm{n}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}_1'[s]_{\mathbf{s}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{c}}) \end{equation} \begin{equation} \text{and}\quad \boldsymbol{\sigma}_1' \equiv \boldsymbol{\sigma} \quad \text{except:} \\ @@ -808,7 +808,7 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) +\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + v, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) \end{equation} The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_{\mathrm{c}}$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). @@ -839,17 +839,17 @@ \section{Message Call} \label{ch:call} I_{\mathrm{a}} & \equiv & r \\ I_{\mathrm{o}} & \equiv & o \\ I_{\mathrm{p}} & \equiv & p \\ -I_\mathbf{d} & \equiv & \mathbf{d} \\ +I_{\mathbf{d}} & \equiv & \mathbf{d} \\ I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & \tilde{v} \\ I_{\mathrm{e}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \\ \mathbf{t} & \equiv & \{s, r\} \\ \\ \nonumber -\text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_{\mathrm{c}} +\text{Let} \; \mathtt{\tiny KEC}(I_{\mathbf{b}}) & = & \boldsymbol{\sigma}[c]_{\mathrm{c}} \end{eqnarray} -It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_\mathbf{b}), I_\mathbf{b})$ at some point prior in order to make the determination of $I_\mathbf{b}$ feasible. +It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_{\mathbf{b}}), I_{\mathbf{b}})$ at some point prior in order to make the determination of $I_{\mathbf{b}}$ feasible. As can be seen, there are eight exceptions to the usage of the general execution framework $\Xi$ for evaluation of the message call: these are eight so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become \textit{native extensions}. The eight contracts in addresses 1 to 8 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme, the identity function, arbitrary precision modular exponentiation, elliptic curve addition, elliptic curve scalar multiplication and an elliptic curve pairing check respectively. @@ -915,10 +915,10 @@ \subsection{Execution Overview} (\boldsymbol{\sigma}', \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ \boldsymbol{\mu}_{\mathrm{g}} & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ -\boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ +\boldsymbol{\mu}_{\mathbf{m}} & \equiv & (0, 0, ...) \\ \boldsymbol{\mu}_{\mathrm{i}} & \equiv & 0 \\ -\boldsymbol{\mu}_\mathbf{s} & \equiv & () \\ -\boldsymbol{\mu}_\mathbf{o} & \equiv & () +\boldsymbol{\mu}_{\mathbf{s}} & \equiv & () \\ +\boldsymbol{\mu}_{\mathbf{o}} & \equiv & () \end{eqnarray} \begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} @@ -942,13 +942,13 @@ \subsection{Execution Overview} $X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either $Z$ becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until $H$ becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. \subsubsection{Machine State} -The machine state $\boldsymbol{\mu}$ is defined as the tuple $(g, pc, \mathbf{m}, i, \mathbf{s})$ which are the gas available, the program counter $pc \in \mathbb{P}_{256}$ , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents $\boldsymbol{\mu}_\mathbf{m}$ are a series of zeroes of size $2^{256}$. +The machine state $\boldsymbol{\mu}$ is defined as the tuple $(g, pc, \mathbf{m}, i, \mathbf{s})$ which are the gas available, the program counter $pc \in \mathbb{P}_{256}$ , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents $\boldsymbol{\mu}_{\mathbf{m}}$ are a series of zeroes of size $2^{256}$. For the ease of reading, the instruction mnemonics, written in small-caps (\eg \space {\small ADD}), should be interpreted as their numeric equivalents; the full table of instructions and their specifics is given in Appendix \ref{app:vm}. For the purposes of defining $Z$, $H$ and $O$, we define $w$ as the current operation to be executed: \begin{equation}\label{eq:currentoperation} -w \equiv \begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_\mathbf{b} \rVert \\ +w \equiv \begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_{\mathbf{b}} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases} \end{equation} @@ -963,10 +963,10 @@ \subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{ \begin{array}[t]{l} \boldsymbol{\mu}_{\mathrm{g}} < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ \mathbf{\delta}_{\mathrm{w}} = \varnothing \quad \vee \\ -\lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_{\mathrm{w}} \quad \vee \\ -( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ -( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ - \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_{\mathrm{w}} + \mathbf{\alpha}_{\mathrm{w}} > 1024 \quad \vee \\ +\lVert\boldsymbol{\mu}_{\mathbf{s}}\rVert < \mathbf{\delta}_{\mathrm{w}} \quad \vee \\ +( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_{\mathbf{s}}[0] \notin D(I_{\mathbf{b}}) ) \quad \vee \\ +( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + \boldsymbol{\mu}_{\mathbf{s}}[2] > \lVert\boldsymbol{\mu}_{\mathbf{o}}\rVert) \quad \vee \\ + \lVert\boldsymbol{\mu}_{\mathbf{s}}\rVert - \mathbf{\delta}_{\mathrm{w}} + \mathbf{\alpha}_{\mathrm{w}} > 1024 \quad \vee \\ \neg I_{\mathrm{w}} \wedge W(w, \boldsymbol{\mu}) \end{array} \end{equation} @@ -975,7 +975,7 @@ \subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{ W(w, \boldsymbol{\mu}) \equiv \begin{array}[t]{l} w \in \{\text{\small CREATE}, \text{\small SSTORE}, \text{\small SELFDESTRUCT}\} \quad \vee \\ \text{\small LOG0} \le w \wedge w \le \text{\small LOG4} \quad \vee \\ -w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 +w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \end{array} \end{equation} @@ -1027,8 +1027,8 @@ \subsection{The Execution Cycle} \begin{eqnarray} O\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \equiv & (\boldsymbol{\sigma}', \boldsymbol{\mu}', A', I) \\ \Delta & \equiv & \mathbf{\alpha}_{\mathrm{w}} - \mathbf{\delta}_{\mathrm{w}} \\ -\lVert\boldsymbol{\mu}'_\mathbf{s}\rVert & \equiv & \lVert\boldsymbol{\mu}_\mathbf{s}\rVert + \Delta \\ -\quad \forall x \in [\mathbf{\alpha}_{\mathrm{w}}, \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert): \boldsymbol{\mu}'_\mathbf{s}[x] & \equiv & \boldsymbol{\mu}_\mathbf{s}[x-\Delta] +\lVert\boldsymbol{\mu}'_{\mathbf{s}}\rVert & \equiv & \lVert\boldsymbol{\mu}_{\mathbf{s}}\rVert + \Delta \\ +\quad \forall x \in [\mathbf{\alpha}_{\mathrm{w}}, \lVert\boldsymbol{\mu}'_{\mathbf{s}}\rVert): \boldsymbol{\mu}'_{\mathbf{s}}[x] & \equiv & \boldsymbol{\mu}_{\mathbf{s}}[x-\Delta] \end{eqnarray} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: @@ -1043,7 +1043,7 @@ \subsection{The Execution Cycle} In general, we assume the memory, self-destruct set and system state don't change: \begin{eqnarray} -\boldsymbol{\mu}'_\mathbf{m} & \equiv & \boldsymbol{\mu}_\mathbf{m} \\ +\boldsymbol{\mu}'_{\mathbf{m}} & \equiv & \boldsymbol{\mu}_{\mathbf{m}} \\ \boldsymbol{\mu}'_{\mathrm{i}} & \equiv & \boldsymbol{\mu}_{\mathrm{i}} \\ A' & \equiv & A \\ \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma} @@ -1093,13 +1093,13 @@ \subsection{Ommer Validation} and $s$ denotes the ``is-sibling'' property: \begin{equation} -s(U, H) \equiv (P(H) = P(U)\; \wedge \; H \neq U \; \wedge \; U \notin B(H)_\mathbf{U}) +s(U, H) \equiv (P(H) = P(U)\; \wedge \; H \neq U \; \wedge \; U \notin B(H)_{\mathbf{U}}) \end{equation} where $B(H)$ is the block of the corresponding header $H$. \subsection{Transaction Validation} -%where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_\mathbf{T}[i]$, and $g[i]$ the total gas used immediately after said transaction. +%where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_{\mathbf{T}}[i]$, and $g[i]$ the total gas used immediately after said transaction. The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{H}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} @@ -1112,13 +1112,13 @@ \subsection{Reward Application} \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ +\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_{\mathbf{U}}\rVert}{32})R_{\mathrm{b}} \\ \qquad\forall_{\mathbf{U} \in \mathbf{B}_{\mathbf{U}}}: \\ \nonumber \boldsymbol{\sigma}'[\mathbf{U}_{\mathrm{c}}] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[\mathbf{U}_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ -\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_\mathbf{s}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ +\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathbf{s}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{b}} \end{eqnarray} @@ -1152,30 +1152,30 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} \end{equation} -In the case of $B_\mathbf{R}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: +In the case of $B_{\mathbf{R}}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} \mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} +\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} -For $\mathbf{R}[n]_\mathbf{l}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. +For $\mathbf{R}[n]_{\mathbf{l}}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. \begin{equation} -\mathbf{R}[n]_\mathbf{l} = -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\mathbf{R}[n]_{\mathbf{l}} = +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{\mathrm{z}} = -\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} \hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: @@ -1461,8 +1461,8 @@ \section{Precompiled Contracts}\label{app:precompiled} \text{if} \quad |\mathbf{o}| = 32: &&\\ \mathbf{o}[0..11] &=& 0 \\ \mathbf{o}[12..31] &=& \mathtt{\tiny KEC}\big(\mathtt{\tiny ECDSARECOVER}(h, v, r, s)\big)[12..31] \quad \text{where:}\\ -\mathbf{d}[0..(|I_\mathbf{d}|-1)] &=& I_\mathbf{d}\\ -\mathbf{d}[|I_\mathbf{d}|..] &=& (0, 0, ...) \\ +\mathbf{d}[0..(|I_{\mathbf{d}}|-1)] &=& I_{\mathbf{d}}\\ +\mathbf{d}[|I_{\mathbf{d}}|..] &=& (0, 0, ...) \\ h &=& \mathbf{d}[0..31]\\ v &=& \mathbf{d}[32..63]\\ r &=& \mathbf{d}[64..95]\\ @@ -1472,12 +1472,12 @@ \section{Precompiled Contracts}\label{app:precompiled} The two hash functions, RIPEMD-160 and SHA2-256 are more trivially defined as an almost pass-through operation. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. \begin{eqnarray} \Xi_{\mathtt{SHA256}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ -\mathbf{o}[0..31] &=& \mathtt{\tiny SHA256}(I_\mathbf{d})\\ +g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ +\mathbf{o}[0..31] &=& \mathtt{\tiny SHA256}(I_{\mathbf{d}})\\ \Xi_{\mathtt{RIP160}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ \mathbf{o}[0..11] &=& 0 \\ -\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_\mathbf{d})\\ +\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_{\mathbf{d}})\\ \end{eqnarray} For the purposes here, we assume we have well-defined standard cryptographic functions for RIPEMD-160 and SHA2-256 of the form: @@ -1489,8 +1489,8 @@ \section{Precompiled Contracts}\label{app:precompiled} The fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: \begin{eqnarray} \Xi_{\mathtt{ID}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_{\mathrm{r}} &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ -\mathbf{o} &=& I_\mathbf{d} +g_{\mathrm{r}} &=& 15 + 3\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ +\mathbf{o} &=& I_{\mathbf{d}} \end{eqnarray} The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. @@ -1607,8 +1607,8 @@ \subsection{zkSNARK Related Precompiled Contracts} \begin{eqnarray} \Xi_{\mathtt{SNARKV}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \qquad\Xi_{\mathtt{SNARKV}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ F\\ -F&\equiv&(|I_\mathbf{d}|\bmod 192\neq 0\vee(\exists j.\ a_{\mathrm{j}}=\varnothing\vee b_{\mathrm{j}}=\varnothing))\\ -k &=& \dfrac{|I_\mathbf{d}|}{192} \\ +F&\equiv&(|I_{\mathbf{d}}|\bmod 192\neq 0\vee(\exists j.\ a_{\mathrm{j}}=\varnothing\vee b_{\mathrm{j}}=\varnothing))\\ +k &=& \dfrac{|I_{\mathbf{d}}|}{192} \\ g_{\mathrm{r}}&=& 60000k + 40000 \\ \mathbf o[0..31]&\equiv&\begin{cases} 0x0000000000000000000000000000000000000000000000000000000000000001&\text{if}\ v\wedge\neg F\\ @@ -1776,15 +1776,15 @@ \subsection{Gas Cost} \begin{equation} C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \equiv C_{mem}(\boldsymbol{\mu}'_{\mathrm{i}})-C_{mem}(\boldsymbol{\mu}_{\mathrm{i}}) + \begin{cases} C_\text{\tiny SSTORE}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SSTORE} \\ -G_{exp} & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] = 0 \\ -G_{exp} + G_{expbyte}\times(1+\lfloor\log_{256}(\boldsymbol{\mu}_\mathbf{s}[1])\rfloor) & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] > 0 \\ -G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \lor \text{\small RETURNDATACOPY} \\ -G_{extcode} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1] & \text{if} \quad w = \text{\small LOG0} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+G_{logtopic} & \text{if} \quad w = \text{\small LOG1} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+2G_{logtopic} & \text{if} \quad w = \text{\small LOG2} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+3G_{logtopic} & \text{if} \quad w = \text{\small LOG3} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+4G_{logtopic} & \text{if} \quad w = \text{\small LOG4} \\ +G_{exp} & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_{\mathbf{s}}[1] = 0 \\ +G_{exp} + G_{expbyte}\times(1+\lfloor\log_{256}(\boldsymbol{\mu}_{\mathbf{s}}[1])\rfloor) & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_{\mathbf{s}}[1] > 0 \\ +G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_{\mathbf{s}}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \lor \text{\small RETURNDATACOPY} \\ +G_{extcode} + G_{copy}\times\lceil\boldsymbol{\mu}_{\mathbf{s}}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1] & \text{if} \quad w = \text{\small LOG0} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+G_{logtopic} & \text{if} \quad w = \text{\small LOG1} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+2G_{logtopic} & \text{if} \quad w = \text{\small LOG2} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+3G_{logtopic} & \text{if} \quad w = \text{\small LOG3} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+4G_{logtopic} & \text{if} \quad w = \text{\small LOG4} \\ C_\text{\tiny CALL}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small CALL} \lor \text{\small CALLCODE} \lor \text{\small DELEGATECALL} \\ C_\text{\tiny SELFDESTRUCT}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SELFDESTRUCT} \\ G_{create} & \text{if} \quad w = \text{\small CREATE}\\ @@ -1803,7 +1803,7 @@ \subsection{Gas Cost} \end{cases} \end{equation} \begin{equation} -w \equiv \begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_\mathbf{b} \rVert\\ +w \equiv \begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_{\mathbf{b}} \rVert\\ \text{\small STOP} & \text{otherwise} \end{cases} \end{equation} @@ -1867,43 +1867,43 @@ \subsection{Instruction Set} \linkdest{stop}{}0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule 0x01 & {\small ADD} & 2 & 1 & Addition operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule 0x02 & {\small MUL} & 2 & 1 & Multiplication operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] \times \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] \times \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule 0x03 & {\small SUB} & 2 & 1 & Subtraction operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] - \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] - \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule 0x04 & {\small DIV} & 2 & 1 & Integer division operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ \lfloor\boldsymbol{\mu}_\mathbf{s}[0] \div \boldsymbol{\mu}_\mathbf{s}[1]\rfloor & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ \lfloor\boldsymbol{\mu}_{\mathbf{s}}[0] \div \boldsymbol{\mu}_{\mathbf{s}}[1]\rfloor & \text{otherwise}\end{cases}$ \\ \midrule 0x05 & {\small SDIV} & 2 & 1 & Signed integer division operation (truncated). \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ -2^{255} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = -2^{255} \wedge \quad \boldsymbol{\mu}_\mathbf{s}[1] = -1\\ \mathbf{sgn} (\boldsymbol{\mu}_\mathbf{s}[0] \div \boldsymbol{\mu}_\mathbf{s}[1]) \lfloor |\boldsymbol{\mu}_\mathbf{s}[0] \div \boldsymbol{\mu}_\mathbf{s}[1]| \rfloor & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ -2^{255} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] = -2^{255} \wedge \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = -1\\ \mathbf{sgn} (\boldsymbol{\mu}_{\mathbf{s}}[0] \div \boldsymbol{\mu}_{\mathbf{s}}[1]) \lfloor |\boldsymbol{\mu}_{\mathbf{s}}[0] \div \boldsymbol{\mu}_{\mathbf{s}}[1]| \rfloor & \text{otherwise}\end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ &&&& Note the overflow semantic when $-2^{255}$ is negated.\\ \midrule 0x06 & {\small MOD} & 2 & 1 & Modulo remainder operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ \boldsymbol{\mu}_\mathbf{s}[0] \bmod \boldsymbol{\mu}_\mathbf{s}[1] & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ \boldsymbol{\mu}_{\mathbf{s}}[0] \bmod \boldsymbol{\mu}_{\mathbf{s}}[1] & \text{otherwise}\end{cases}$ \\ \midrule 0x07 & {\small SMOD} & 2 & 1 & Signed modulo remainder operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ \mathbf{sgn} (\boldsymbol{\mu}_\mathbf{s}[0]) (|\boldsymbol{\mu}_\mathbf{s}[0]| \bmod |\boldsymbol{\mu}_\mathbf{s}[1]|) & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ \mathbf{sgn} (\boldsymbol{\mu}_{\mathbf{s}}[0]) (|\boldsymbol{\mu}_{\mathbf{s}}[0]| \bmod |\boldsymbol{\mu}_{\mathbf{s}}[1]|) & \text{otherwise}\end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule 0x08 & {\small ADDMOD} & 3 & 1 & Modulo addition operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] = 0\\ (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1]) \mod \boldsymbol{\mu}_\mathbf{s}[2] & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] = 0\\ (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1]) \mod \boldsymbol{\mu}_{\mathbf{s}}[2] & \text{otherwise}\end{cases}$ \\ &&&& All intermediate calculations of this operation are not subject to the $2^{256}$ modulo. \\ \midrule 0x09 & {\small MULMOD} & 3 & 1 & Modulo multiplication operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] = 0\\ (\boldsymbol{\mu}_\mathbf{s}[0] \times \boldsymbol{\mu}_\mathbf{s}[1]) \mod \boldsymbol{\mu}_\mathbf{s}[2] & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] = 0\\ (\boldsymbol{\mu}_{\mathbf{s}}[0] \times \boldsymbol{\mu}_{\mathbf{s}}[1]) \mod \boldsymbol{\mu}_{\mathbf{s}}[2] & \text{otherwise}\end{cases}$ \\ &&&& All intermediate calculations of this operation are not subject to the $2^{256}$ modulo. \\ \midrule 0x0a & {\small EXP} & 2 & 1 & Exponential operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] ^ {\boldsymbol{\mu}_\mathbf{s}[1] }$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] ^ {\boldsymbol{\mu}_{\mathbf{s}}[1] }$ \\ \midrule 0x0b & {\small SIGNEXTEND} & 2 & 1 & Extend length of two's complement signed integer. \\ -&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{t}} &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}} &\text{otherwise} \end{cases}$ \\ -\multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_{\mathrm{i}}$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ +&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{t}} &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_{\mathbf{s}}[0] + 1) \\ \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}} &\text{otherwise} \end{cases}$ \\ +\multicolumn{5}{l}{$\boldsymbol{\mu}_{\mathbf{s}}[x]_{\mathrm{i}}$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_{\mathbf{s}}[x]$} \vspace{5pt} \\ \midrule \end{tabular*} @@ -1912,39 +1912,39 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{10s: Comparison \& Bitwise Logic Operations}} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x10 & {\small LT} & 2 & 1 & Less-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] < \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] < \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x11 & {\small GT} & 2 & 1 & Greater-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] > \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x12 & {\small SLT} & 2 & 1 & Signed less-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] < \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] < \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule 0x13 & {\small SGT} & 2 & 1 & Signed greater-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] > \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule 0x14 & {\small EQ} & 2 & 1 & Equality comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] = \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x15 & {\small ISZERO} & 1 & 1 & Simple not operator. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x16 & {\small AND} & 2 & 1 & Bitwise AND operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \wedge \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} \wedge \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}}$ \\ \midrule 0x17 & {\small OR} & 2 & 1 & Bitwise OR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \vee \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} \vee \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}}$ \\ \midrule 0x18 & {\small XOR} & 2 & 1 & Bitwise XOR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \oplus \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} \oplus \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}}$ \\ \midrule 0x19 & {\small NOT} & 1 & 1 & Bitwise NOT operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x1a & {\small BYTE} & 2 & 1 & Retrieve single byte from word. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{(i + 8\boldsymbol{\mu}_\mathbf{s}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_\mathbf{s}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_{\mathbf{s}}[1]_{(i + 8\boldsymbol{\mu}_{\mathbf{s}}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_{\mathbf{s}}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ &&&& For Nth byte, we count from the left (i.e. N=0 would be the most significant in big endian). \\ \bottomrule \end{tabular*} @@ -1954,8 +1954,8 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{20s: SHA3}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x20 & {\small SHA3} & 2 & 1 & Compute Keccak-256 hash. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \mathtt{\tiny Keccak}(\boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \mathtt{\tiny Keccak}(\boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1] - 1) ])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$ \\ \bottomrule \end{tabular*} @@ -1964,69 +1964,69 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{30s: Environmental Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x30 & {\small ADDRESS} & 0 & 1 & Get address of currently executing account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{a}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{a}}$ \\ \midrule 0x31 & {\small BALANCE} & 1 & 1 & Get balance of the given account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0]]_{\mathrm{b}}& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0]]_{\mathrm{b}}& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ \midrule 0x32 & {\small ORIGIN} & 0 & 1 & Get execution origination address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{o}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{o}}$ \\ &&&& This is the sender of original transaction; it is never an account with non-empty \\ &&&& associated code. \\ \midrule 0x33 & {\small CALLER} & 0 & 1 & Get caller address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{s}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{s}}$ \\ &&&& This is the address of the account that is directly responsible for this execution. \\ \midrule 0x34 & {\small CALLVALUE} & 0 & 1 & Get deposited value by the instruction/transaction responsible for this execution. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{v}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{v}}$ \\ \midrule 0x35 & {\small CALLDATALOAD} & 1 & 1 & Get input data of current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_\mathbf{d}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \quad \text{with} \quad I_\mathbf{d}[x] = 0 \quad \text{if} \quad x \geqslant \lVert I_\mathbf{d} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathbf{d}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + 31) ] \quad \text{with} \quad I_{\mathbf{d}}[x] = 0 \quad \text{if} \quad x \geqslant \lVert I_{\mathbf{d}} \rVert$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x36 & {\small CALLDATASIZE} & 0 & 1 & Get size of input data in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert I_\mathbf{d} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert I_{\mathbf{d}} \rVert$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x37 & {\small CALLDATACOPY} & 3 & 0 & Copy input data in current environment to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} I_\mathbf{d}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{d} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[2] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] + i ] \equiv +\begin{cases} I_{\mathbf{d}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + i < \lVert I_{\mathbf{d}} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x38 & {\small CODESIZE} & 0 & 1 & Get size of code running in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert I_\mathbf{b} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert I_{\mathbf{b}} \rVert$ \\ \midrule 0x39 & {\small CODECOPY} & 3 & 0 & Copy code running in current environment to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{b} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[2] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] + i ] \equiv +\begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + i < \lVert I_{\mathbf{b}} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[1] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3a & {\small GASPRICE} & 0 & 1 & Get price of gas in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{p}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{p}}$ \\ &&&& This is gas price specified by the originating transaction.\\ \midrule 0x3b & {\small EXTCODESIZE} & 1 & 1 & Get size of an account's code. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}]_{\mathrm{c}} \rVert$ \\ \midrule 0x3c & {\small EXTCODECOPY} & 4 & 0 & Copy an account's code to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[3] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[1] + i ] \equiv -\begin{cases} \mathbf{c}[\boldsymbol{\mu}_\mathbf{s}[2] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] + i < \lVert \mathbf{c} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}}$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[2] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[3] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i ] \equiv +\begin{cases} \mathbf{c}[\boldsymbol{\mu}_{\mathbf{s}}[2] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] + i < \lVert \mathbf{c} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ +&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}]_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[1], \boldsymbol{\mu}_{\mathbf{s}}[3])$ \\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[2] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert \boldsymbol{\mu}_{\mathbf{o}} \rVert$ \\ \midrule 0x3e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[2] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] + i ] \equiv +\begin{cases} \boldsymbol{\mu}_{\mathbf{o}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + i < \lVert \boldsymbol{\mu}_{\mathbf{o}} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ \bottomrule \end{tabular*} @@ -2035,7 +2035,7 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ -\linkdest{blockhash}{}&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{\mathbf{H}_{\mathrm{p}}}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ +\linkdest{blockhash}{}&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv P(I_{\mathbf{H}_{\mathrm{p}}}, \boldsymbol{\mu}_{\mathbf{s}}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ &&&& or more than 256 blocks behind the current block. \\ @@ -2044,19 +2044,19 @@ \subsection{Instruction Set} &&&& in the block following it. \\ \midrule 0x41 & {\small COINBASE} & 0 & 1 & Get the block's beneficiary address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{c}}$ \\ \midrule 0x42 & {\small TIMESTAMP} & 0 & 1 & Get the block's timestamp. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{s}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{s}}$ \\ \midrule 0x43 & {\small NUMBER} & 0 & 1 & Get the block's number. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{i}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{i}}$ \\ \midrule 0x44 & {\small DIFFICULTY} & 0 & 1 & Get the block's difficulty. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{d}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{d}}$ \\ \midrule 0x45 & {\small GASLIMIT} & 0 & 1 & Get the block's gas limit. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{l}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{l}}$ \\ \bottomrule \end{tabular*} @@ -2067,52 +2067,52 @@ \subsection{Instruction Set} 0x50 & {\small POP} & 1 & 0 & Remove item from stack. \\ \midrule 0x51 & {\small MLOAD} & 1 & 1 & Load word from memory. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ]$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + 31) ]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_{\mathbf{s}}[0] + 32) \div 32 })$ \\ &&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x52 & {\small MSTORE} & 2 & 0 & Save word to memory. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + 31) ] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_{\mathbf{s}}[0] + 32) \div 32 })$ \\ &&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x53 & {\small MSTORE8} & 2 & 0 & Save byte to memory. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv (\boldsymbol{\mu}_\mathbf{s}[1] \bmod 256) $ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 1) \div 32 })$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] ] \equiv (\boldsymbol{\mu}_{\mathbf{s}}[1] \bmod 256) $ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_{\mathbf{s}}[0] + 1) \div 32 })$ \\ &&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathbf{s}}[\boldsymbol{\mu}_{\mathbf{s}}[0]]$ \\ \midrule \linkdest{SSTORE}{}0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathbf{s}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] ] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1] $ \\ &&&&\linkdest{C tiny SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ +G_{sset} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathbf{s}}[\boldsymbol{\mu}_{\mathbf{s}}[0]] = 0 \\ G_{sreset} & \text{otherwise} \end{cases}$ \\ &&&&\linkdest{A r}{} $A'_{r} \equiv A_{r} + \begin{cases} -R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ +R_{sclear} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathbf{s}}[\boldsymbol{\mu}_{\mathbf{s}}[0]] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule \linkdest{JUMP}{}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ -&&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ +&&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}.\\ \midrule \linkdest{JUMPI}{}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ -&&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ +&&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_{\mathbf{s}}[0] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ \midrule 0x58 & {\small PC} & 0 & 1 & Get the value of the program counter \textit{prior} to the increment \\ &&&& corresponding to this instruction. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_{pc}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{pc}$ \\ \midrule 0x59 & {\small MSIZE} & 0 & 1 & Get the size of active memory in bytes. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv 32\boldsymbol{\mu}_{i}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv 32\boldsymbol{\mu}_{i}$ \\ \midrule 0x5a & {\small GAS} & 0 & 1 & Get the amount of available gas, including the corresponding reduction \\ &&&& for the cost of this instruction. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_{g}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{g}$ \\ \midrule 0x5b & {\small JUMPDEST} & 0 & 0 & Mark a valid destination for jumps. \\ &&&& This operation has no effect on machine state during execution. \\ @@ -2124,21 +2124,21 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{60s \& 70s: Push Operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x60 & {\small PUSH1} & 0 & 1 & Place 1 byte item on stack. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv c(\boldsymbol{\mu}_{pc} + 1)$ \\ -&&&& $\text{where} \quad c(x) \equiv \begin{cases} I_\mathbf{b}[x] & \text{if} \quad x < \lVert I_\mathbf{b} \rVert \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv c(\boldsymbol{\mu}_{pc} + 1)$ \\ +&&&& $\text{where} \quad c(x) \equiv \begin{cases} I_{\mathbf{b}}[x] & \text{if} \quad x < \lVert I_{\mathbf{b}} \rVert \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& The bytes are read in line from the program code's bytes array. \\ &&&& The function $c$ ensures the bytes default to zero if they extend past the limits.\\ &&&& The byte is right-aligned (takes the lowest significant place in big endian). \\ \midrule 0x61 & {\small PUSH2} & 0 & 1 & Place 2-byte item on stack. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{c}\big( (\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 2) \big)$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{c}\big( (\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 2) \big)$ \\ &&&& with $\boldsymbol{c}(\boldsymbol{x}) \equiv (c(\boldsymbol{x}_0), ..., c(\boldsymbol{x}_{\lVert x \rVert -1})) $ with $c$ as defined as above. \\ &&&& The bytes are right-aligned (takes the lowest significant place in big endian). \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0x7f & {\small PUSH32} & 0 & 1 & Place 32-byte (full word) item on stack. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{c}\big((\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 32) \big)$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{c}\big((\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 32) \big)$ \\ &&&& where $\boldsymbol{c}$ is defined as above. \\ &&&& The bytes are right-aligned (takes the lowest significant place in big endian). \\ \bottomrule @@ -2149,15 +2149,15 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{80s: Duplication Operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x80 & {\small DUP1} & 1 & 2 & Duplicate 1st stack item. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \midrule 0x81 & {\small DUP2} & 2 & 3 & Duplicate 2nd stack item. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0x8f & {\small DUP16} & 16 & 17 & Duplicate 16th stack item. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[15]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[15]$ \\ \bottomrule \end{tabular*} @@ -2166,18 +2166,18 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{90s: Exchange Operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x90 & {\small SWAP1} & 2 & 2 & Exchange 1st and 2nd stack items. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[1] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[1] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \midrule 0x91 & {\small SWAP2} & 3 & 3 & Exchange 1st and 3rd stack items. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[2]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[2] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[2]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[2] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0x9f & {\small SWAP16} & 17 & 17 & Exchange 1st and 17th stack items. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[16]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[16] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[16]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[16] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \bottomrule \end{tabular*} @@ -2185,21 +2185,21 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ \multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ -\multicolumn{5}{l}\linkdest{A l}{}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_{\mathrm{a}}, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ +\multicolumn{5}{l}\linkdest{A l}{}{$A'_{\mathbf{l}} \equiv A_{\mathbf{l}} \cdot (I_{\mathrm{a}}, \mathbf{t}, \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ -\multicolumn{5}{l}{$\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ +\multicolumn{5}{l}{$\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$}\\ \multicolumn{5}{l}{The entry's topic series, $\mathbf{t}$, differs accordingly:}\vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xa0 & {\small LOG0} & 2 & 0 & Append log record with no topics. \\ &&&& $\mathbf{t} \equiv ()$ \\ \midrule 0xa1 & {\small LOG1} & 3 & 0 & Append log record with one topic. \\ -&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0xa4 & {\small LOG4} & 6 & 0 & Append log record with four topics. \\ -&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4], \boldsymbol{\mu}_\mathbf{s}[5])$ \\ +&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_{\mathbf{s}}[2], \boldsymbol{\mu}_{\mathbf{s}}[3], \boldsymbol{\mu}_{\mathbf{s}}[4], \boldsymbol{\mu}_{\mathbf{s}}[5])$ \\ \bottomrule \end{tabular*} @@ -2208,40 +2208,40 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{f0s: System operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ -&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_{\mathrm{g}}, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, L(\boldsymbol{\mu}_{\mathrm{g}}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathrm{g}}, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[1] \dots (\boldsymbol{\mu}_{\mathbf{s}}[1] + \boldsymbol{\mu}_{\mathbf{s}}[2] - 1) ]$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_{\mathrm{g}}, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, L(\boldsymbol{\mu}_{\mathrm{g}}), I_{\mathrm{p}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathrm{g}}, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_{\mathrm{a}}]_{\mathrm{n}} = \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}} + 1$ \\ -&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ -&&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ +&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_{\mathbf{s}} \equiv A_{\mathbf{s}} \cup A^+_{\mathbf{s}} \quad \wedge \quad A'_{\mathbf{l}} \equiv A_{\mathbf{l}} \cdot A^+_{\mathbf{l}} \quad \wedge \quad A'_{\mathbf{t}} \equiv A_{\mathbf{t}} \cup A^+_{\mathbf{t}}$ \\ +&&&& $ \wedge \quad A'_{\mathbf{r}} \equiv A_{\mathbf{r}} + A^+_{\mathbf{r}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv x$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ -&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ +&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_{\mathbf{s}}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ &&&& created account. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{o} \equiv ()$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[1], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{o}} \equiv ()$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ -&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[3] \dots (\boldsymbol{\mu}_\mathbf{s}[3] + \boldsymbol{\mu}_\mathbf{s}[4] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_{\mathrm{a}}, I_{\mathrm{o}}, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge \\ \quad\quad I_{\mathrm{e}} < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ -&&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{o} = \mathbf{o}$ \\ +&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[3] \dots (\boldsymbol{\mu}_{\mathbf{s}}[3] + \boldsymbol{\mu}_{\mathbf{s}}[4] - 1) ]$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_{\mathrm{a}}, I_{\mathrm{o}}, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_{\mathbf{s}}[2], \boldsymbol{\mu}_{\mathbf{s}}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge \\ \quad\quad I_{\mathrm{e}} < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $n \equiv \min(\{ \boldsymbol{\mu}_{\mathbf{s}}[6], |\mathbf{o}|\})$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[5] \dots (\boldsymbol{\mu}_{\mathbf{s}}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{o}} = \mathbf{o}$ \\ &&&& $\boldsymbol{\mu}'_{\mathrm{g}} \equiv \boldsymbol{\mu}_{\mathrm{g}} + g'$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ -&&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ +&&&& $t \equiv \boldsymbol{\mu}_{\mathbf{s}}[1] \mod 2^{160}$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ -&&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ +&&&& $\boldsymbol{\mu}_{\mathbf{s}}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[3], \boldsymbol{\mu}_{\mathbf{s}}[4]), \boldsymbol{\mu}_{\mathbf{s}}[5], \boldsymbol{\mu}_{\mathbf{s}}[6])$ \\ &&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ &&&&\linkdest{tiny CALL}{} $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \\ C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} @@ -2250,26 +2250,26 @@ \subsection{Instruction Set} \end{cases}$\\ &&&& $C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + C_{\text{\tiny XFER}}(\boldsymbol{\mu}) + C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$\\ &&&& $C_{\text{\tiny XFER}}(\boldsymbol{\mu}) \equiv \begin{cases} -G_{callvalue} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +G_{callvalue} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathbf{s}}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0xf2 & {\small CALLCODE} & 7 & 1 & Message-call into this account with an alternative account's code. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\\ \quad\quad{}I_{\mathrm{e}} < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ -&&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_{\mathbf{s}}[2], \boldsymbol{\mu}_{\mathbf{s}}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\\ \quad\quad{}I_{\mathrm{e}} < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_{\mathbf{s}}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_{\mathrm{a}}$. This means that the recipient is in fact the\\ &&&& same account as at present, simply that the code is overwritten.\\ \midrule \linkdest{RETURN}{}0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ -&&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ +&&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots ( \boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1] - 1 ) ]$ \\ &&&& This has the effect of halting the execution at this point with output defined.\\ &&&& See section \ref{ch:model}. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$ \\ \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} @@ -2277,10 +2277,10 @@ \subsection{Instruction Set} 0xf4 & {\small DELEGATECALL} & 6 & 1 & Message-call into this account with an alternative account's code, but persisting\\ &&&& the current values for {\it sender} and {\it value}. \\ &&&& Compared with {\small CALL}, {\small DELEGATECALL} takes one fewer arguments. The omitted\\ -&&&& argument is $\boldsymbol{\mu}_\mathbf{s}[2]$. As a result, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ in the definition of {\small CALL} \\ -&&&& should respectively be replaced with $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ +&&&& argument is $\boldsymbol{\mu}_{\mathbf{s}}[2]$. As a result, $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$, $\boldsymbol{\mu}_{\mathbf{s}}[5]$ and $\boldsymbol{\mu}_{\mathbf{s}}[6]$ in the definition of {\small CALL} \\ +&&&& should respectively be replaced with $\boldsymbol{\mu}_{\mathbf{s}}[2]$, $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$ and $\boldsymbol{\mu}_{\mathbf{s}}[5]$. \\ &&&& Otherwise exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{s}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_{\mathrm{p}}, 0, I_{\mathrm{v}}, \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \text{if} \quad I_{\mathrm{v}} \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{s}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad \boldsymbol{\mu}_{\mathbf{s}}[0], I_{\mathrm{p}}, 0, I_{\mathrm{v}}, \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \text{if} \quad I_{\mathrm{v}} \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the changes (in addition to that of the fourth parameter) to the second \\ &&&& and ninth parameters to the call $\Theta$.\\ &&&& This means that the recipient is in fact the same account as at present, simply\\ @@ -2288,15 +2288,15 @@ \subsection{Instruction Set} \midrule 0xfa & {\small STATICCALL} & 6 & 1 & Static message-call into an account. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& The argument $\boldsymbol{\mu}_\mathbf{s}[2]$ is replaced with $0$. \\ -&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ -&&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ +&&&& The argument $\boldsymbol{\mu}_{\mathbf{s}}[2]$ is replaced with $0$. \\ +&&&& The deeper argument $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$, $\boldsymbol{\mu}_{\mathbf{s}}[5]$ and $\boldsymbol{\mu}_{\mathbf{s}}[6]$ are respectively replaced with \\ +&&&& $\boldsymbol{\mu}_{\mathbf{s}}[2]$, $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$ and $\boldsymbol{\mu}_{\mathbf{s}}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ \midrule 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and remaining gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we use the memory expansion function, \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule @@ -2304,20 +2304,20 @@ \subsection{Instruction Set} &&&& $A'_{\mathbf{s}} \equiv A_{\mathbf{s}} \cup \{ I_{\mathrm{a}} \}$ \\ &&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} = 0\\ -(\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\ r \neq I_{\mathrm{a}} \\ -(\boldsymbol{\sigma}[r]_{\mathrm{n}}, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{otherwise} +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\ r \neq I_{\mathrm{a}} \\ +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, 0, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{otherwise} \end{cases}$\\ -&&&& where $r = \boldsymbol{\mu}_\mathbf{s}[0] \bmod 2^{160}$\\ +&&&& where $r = \boldsymbol{\mu}_{\mathbf{s}}[0] \bmod 2^{160}$\\ &&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathrm{b}} = 0$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{selfdestruct} & \text{if} \quad I_{\mathrm{a}} \notin A_\mathbf{s} \\ +R_{selfdestruct} & \text{if} \quad I_{\mathrm{a}} \notin A_{\mathbf{s}} \\ 0 & \text{otherwise} \end{cases}$ \\ &&&&\linkdest{C tiny SELFDESTRUCT}{} $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \neq 0$ \\ +&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \neq 0$ \\ \bottomrule \end{tabular*} From 758675b5058dbd80757f645447a5420afc8bb8cb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:38:38 +1100 Subject: [PATCH 264/335] \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..4ef05bd2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -177,7 +177,7 @@ \section{Conventions}\label{ch:conventions} For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. -Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. +Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$}, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a transaction nonce. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. From b5101c5103d62b919b62912201540cf14028a95b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:43:04 +1100 Subject: [PATCH 265/335] 2 more \hyperlink{transaction_nonce}{transaction nonce} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4ef05bd2..01a38ca6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -179,7 +179,7 @@ \section{Conventions}\label{ch:conventions} Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$}, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. -Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a transaction nonce. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. +Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a \hyperlink{transaction_nonce}{transaction nonce}. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. Arbitrary-length sequences are typically denoted as a bold lower-case letter, \eg $\mathbf{o}$ is used to denote the byte sequence given as the output data of a message call. For particularly important values, a bold uppercase letter may be used. @@ -560,7 +560,7 @@ \section{Transaction Execution} \label{ch:transactions} \begin{enumerate} \item The transaction is well-formed RLP, with no additional trailing bytes; \item the transaction signature is valid; -\item the transaction nonce is valid (equivalent to the sender account's current nonce); +\item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the sender account's current nonce); \item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} From 32fa4bb5b38d7bc4c7a388d46140c69adbd7b500 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:14:53 +1100 Subject: [PATCH 266/335] hyperlinks for state transition functions --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..db01e1f2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -128,12 +128,12 @@ \section{The Blockchain Paradigm} \label{ch:overview} Formally, we expand to: \begin{eqnarray} -\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{t}, B) \\ +\boldsymbol{\sigma}_{t+1} & \equiv & \hyperlink{Pi}{\Pi}(\boldsymbol{\sigma}_{t}, B) \\ B & \equiv & (..., (T_0, T_1, ...) ) \\ -\Pi(\boldsymbol{\sigma}, B) & \equiv & \Omega(B, \Upsilon(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) +\Pi(\boldsymbol{\sigma}, B) & \equiv & \hyperlink{Omega}{\Omega}(B, \hyperlink{Upsilon}{\Upsilon}(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \end{eqnarray} -Where $\Omega$ is the block-finalisation state transition function (a function that rewards a nominated party); $B$ is this block, which includes a series of transactions amongst some other components; and $\Pi$ is the block-level state-transition function. +Where \hyperlink{Omega}{$\Omega$} is the block-finalisation state transition function (a function that rewards a nominated party); \linkdest{block}{$B$} is this block, which includes a series of transactions amongst some other components; and $\hyperlink{Pi}{\Pi}$ is the block-level state-transition function. This is the basis of the blockchain paradigm, a model that forms the backbone of not only Ethereum, but all decentralised consensus-based transaction systems to date. @@ -319,7 +319,7 @@ \subsection{The Transaction} \label{ch:transaction} \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} -\subsection{The Block} \label{ch:block} +\subsection{The Block} \linkdest{block}{} The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: @@ -565,7 +565,7 @@ \section{Transaction Execution} \label{ch:transactions} \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} -Formally, we consider the function $\Upsilon$, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: +Formally, we consider the function \hyperlink{Upsilon}{$\Upsilon$}, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: \begin{equation} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} From 43bb09e4263b3cbde042bfba68bb6009c2b27fdb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:28:40 +1100 Subject: [PATCH 267/335] \hyperlink{Upsilon_state_transition}{$\Upsilon$} --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..0cdd3e4f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -173,7 +173,7 @@ \section{Conventions}\label{ch:conventions} The two sets of highly structured, `top-level', state values, are denoted with bold lowercase Greek letters. They fall into those of world-state, which are denoted $\boldsymbol{\sigma}$ (or a variant thereupon) and those of machine-state, $\boldsymbol{\mu}$. -Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. +Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the Ethereum state transition function. For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. @@ -555,7 +555,7 @@ \section{Gas and Payment} \label{ch:payment} \section{Transaction Execution} \label{ch:transactions} -The execution of a transaction is the most complex part of the Ethereum protocol: it defines the state transition function $\Upsilon$. It is assumed that any transactions executed first pass the initial tests of intrinsic validity. These include: +The execution of a transaction is the most complex part of the Ethereum protocol: it defines the state transition function \hyperlink{Upsilon_state_transition}{$\Upsilon$}. It is assumed that any transactions executed first pass the initial tests of intrinsic validity. These include: \begin{enumerate} \item The transaction is well-formed RLP, with no additional trailing bytes; @@ -565,7 +565,7 @@ \section{Transaction Execution} \label{ch:transactions} \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} -Formally, we consider the function $\Upsilon$, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: +Formally, we consider the function \hyperlink{Upsilon_state_transition}{$\Upsilon$}, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: \begin{equation} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} @@ -1150,7 +1150,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. -As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. +As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} From 340085d8e2599624b3f96fdd9dc07807a751bb46 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:34:19 +1100 Subject: [PATCH 268/335] \hyperlink{C__SSTORE} \hyperlink{SSTORE} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..29844d4e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -175,7 +175,7 @@ \section{Conventions}\label{ch:conventions} Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg \hyperlink{C__SSTORE}{$C_\text{SSTORE}$}, the cost function for the \hyperlink{SSTORE}{{\tiny SSTORE}} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. @@ -2086,7 +2086,7 @@ \subsection{Instruction Set} \midrule \linkdest{SSTORE}{}0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ &&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ -&&&&\linkdest{C tiny SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +&&&&\linkdest{C__SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} \end{cases}$ \\ From 06cfdd5c9583e03836b8a991707f829a75d8dcc8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:38:20 +1100 Subject: [PATCH 269/335] \cite{Keccak} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..ac5dc9ef 100644 --- a/Paper.tex +++ b/Paper.tex @@ -175,7 +175,7 @@ \section{Conventions}\label{ch:conventions} Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest, rather than later releases, by \cite{Keccak}) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. From c2a99a6c395e86a3efbe8ed237e81af8f940e53a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:40:03 +1100 Subject: [PATCH 270/335] @misc{Keccak --- Biblio.bib | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Biblio.bib b/Biblio.bib index 8f6a90f6..b29e71cf 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,3 +1,15 @@ +@misc{Keccak, + url = "https://keccak.team/keccak.html", + note = "Accessed 6 October 2017. Unable to be archived by the Wayback Machine.", + author = "Guido Bertoni +and Joan Daemen +and Michaël Peeters +and Gilles Van Assche +and Ronny Van Keer", + title = {{KECCAK}}, + year = "2017", +} + @Book{Davey2002_zbMATH01748069, Author = {B.A. {Davey} and H.A. {Priestley}}, Title = {{Introduction to lattices and order. 2nd ed.}}, From 30d234935346fde99b8dacdd4741209486f27cea Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:56:09 +1100 Subject: [PATCH 271/335] Add missing closing braces --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4f1d9d97..a24be0e9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1685,11 +1685,11 @@ \section{Signing Transactions}\label{app:signing} (T_w, T_r, T_s) = \mathtt{\small ECDSASIGN}(h(T), p_r) \end{eqnarray} -Reiterating from \hyperlink{T__w_T__r_T__s}{previously}: +\hyperlink{T__w_T__r_T__s}{Reiterating from previously}: \begin{eqnarray} \linkdest{T__w}{T_{\mathrm{w}}} = \hyperlink{v}{v}\\ -\linkdest{T__r}{T_{\mathrm{r}} = \hyperlink{r}{r}\\ -\linkdest{T__s}{T_{\mathrm{s}} = \hyperlink{s}{s} +\linkdest{T__r}{T_{\mathrm{r}}} = \hyperlink{r}{r}\\ +\linkdest{T__s}{T_{\mathrm{s}}} = \hyperlink{s}{s} \end{eqnarray} We may then define the sender function $S$ of the transaction as: From 5a0c9091ece5805c11b93863c4545b9db277edc9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 14:04:01 +1100 Subject: [PATCH 272/335] Update @article to @misc when there is no journal field --- Biblio.bib | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Biblio.bib b/Biblio.bib index 8f6a90f6..d62c86de 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -98,14 +98,14 @@ @Article{aron2012bitcoin year = {{2012}}, } -@article{mastercoin2013willett, +@misc{mastercoin2013willett, url = {{https://github.com/mastercoin-MSC/spec}}, author = {J. R. Willett}, title = {{MasterCoin Complete Specification}}, year = {{2013}}, } -@article{colouredcoins2012rosenfeld, +@misc{colouredcoins2012rosenfeld, url = {{https://bitcoil.co.il/BitcoinX.pdf}}, author = {Meni Rosenfeld}, title = {{Overview of Colored Coins}}, @@ -137,42 +137,42 @@ @InProceedings{miller1997future year = {{1997}}, } -@article{buterin2013ethereum, +@misc{buterin2013ethereum, url = {{https://github.com/ethereum/wiki/wiki/White-Paper}}, author = {Vitalik Buterin}, title = {{Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform}}, year = {{2013}}, } -@article{back2002hashcash, +@misc{back2002hashcash, url = {{http://www.hashcash.org/papers/amortizable.pdf}}, author = {Adam Back}, title = {{Hashcash - Amortizable Publicly Auditable Cost-Functions}}, year = {{2002}}, } -@article{hashimoto, +@misc{hashimoto, url = {{https://mirrorx.com/files/hashimoto.pdf}}, author = {Thaddeus Dryja}, title = {{Hashimoto: I/O bound proof of work}}, year = {{2014}}, } -@article{dagger, +@misc{dagger, url = {{http://vitalik.ca/ethereum/dagger.html}}, author = {Vitalik Buterin}, title = {{Dagger: A Memory-Hard to Compute, Memory-Easy to Verify Scrypt Alternative}}, year = {{2013}}, } -@article{lerner2014randmemohash, +@misc{lerner2014randmemohash, url = {{http://www.hashcash.org/papers/memohash.pdf}}, author = {Sergio Demian Lerner}, title = {{Strict Memory Hard Hashing Functions}}, year = {{2014}}, } -@article{FowlerNollVo1991FNVHash, +@misc{FowlerNollVo1991FNVHash, url = {{https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#cite_note-2}}, author = {Glenn Fowler, Landon Curt Noll, Phong Vo}, title = {{Fowler–Noll–Vo hash function}}, From e075f7b328464333b360ddaf1131bd223a835b5e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 14:42:49 +1100 Subject: [PATCH 273/335] Test: Swap bibliographystyle and bibliography --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..51701597 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1250,8 +1250,8 @@ \section{Availability} The source of this paper is maintained at \url{https://github.com/ethereum/yellowpaper/}. An auto-generated PDF is located at \url{https://ethereum.github.io/yellowpaper/paper.pdf}. -\bibliography{Biblio} \bibliographystyle{plainnat} +\bibliography{Biblio} \end{multicols} From 472014356dcd0af9cf71f20f8cda6b9d25eee176 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 15:47:15 +1100 Subject: [PATCH 274/335] Change some {{...}} to "..." --- Biblio.bib | 64 +++++++++++++++++++++++++++--------------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/Biblio.bib b/Biblio.bib index 8f6a90f6..48b6f8c8 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,20 +1,20 @@ @Book{Davey2002_zbMATH01748069, - Author = {B.A. {Davey} and H.A. {Priestley}}, - Title = {{Introduction to lattices and order. 2nd ed.}}, - Edition = {2nd ed.}, - ISBN = {0-521-78451-4/pbk}, - Pages = {xii + 298}, - Year = {2002}, - Publisher = {Cambridge: Cambridge University Press}, - Language = {English}, - MSC2010 = {06-01}, - Zbl = {1002.06001}, + Author = "B.A. {Davey} and H.A. {Priestley}", + Title = "Introduction to lattices and order. 2nd ed.", + Edition = "2nd ed.", + ISBN = "0-521-78451-4/pbk", + Pages = "xii + 298", + Year = "2002", + Publisher = "Cambridge: Cambridge University Press", + Language = "English", + MSC2010 = "06-01", + Zbl = "1002.06001", } @Misc{EIP-100, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md", author = "Vitalik Buterin", - title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", + title = "{EIP}-100: Change difficulty adjustment to target mean block time including uncles", year = "2016", month = "April", } @@ -22,50 +22,50 @@ @Misc{EIP-100 @Misc{EIP-649, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-649.md", author = "Afri Schoedon and Vitalik Buterin", - title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", + title = "{EIP}-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", year = "2017", month = "June", } @Misc{EIP-2, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md", - title = "EIP-2: Homestead Hard-fork Changes", + title = "{EIP}-2: Homestead Hard-fork Changes", author = "Vitalik Buterin", year = "2015", } @Misc{cryptoeprint:2013:881, - Note = {{http://eprint.iacr.org/}}, - Url = {{Cryptology ePrint Archive, Report 2013/881}}, - author = {Sompolinsky, Yonatan and Zohar, Aviv}, - title = {{Accelerating Bitcoin{'}s Transaction Processing. Fast Money Grows on Trees, Not Chains}}, - year = {{2013}}, + Note = "\url{http://eprint.iacr.org/}", + Url = "Cryptology ePrint Archive, Report 2013/881", + author = "Sompolinsky, Yonatan and Zohar, Aviv", + title = "Accelerating Bitcoin{'}s Transaction Processing. Fast Money Grows on Trees, Not Chains", + year = "2013", } @InCollection{gura2004comparing, - BookTitle = {{Cryptographic Hardware and Embedded Systems-CHES 2004}}, - Publisher = {{Springer}}, - author = {Gura, Nils and Patel, Arun and Wander, Arvinderpal and Eberle, Hans and Shantz, Sheueling Chang}, - title = {{Comparing elliptic curve cryptography and RSA on 8-bit CPUs}}, - pages = {119-132}, - year = {{2004}}, + BookTitle = "Cryptographic Hardware and Embedded Systems-CHES 2004", + Publisher = "Springer", + author = "Gura, Nils and Patel, Arun and Wander, Arvinderpal and Eberle, Hans and Shantz, Sheueling Chang", + title = "Comparing elliptic curve cryptography and {RSA} on 8-bit {CPUs}", + pages = "119-132", + year = "2004", } @InProceedings{laurie2004proof, - BookTitle = {{Workshop on Economics and Information, Security}}, - author = {Laurie, Ben and Clayton, Richard}, - title = {{Proof-of-Work{''} proves not to work; version 0.2}}, - year = {{2004}}, + BookTitle = "Workshop on Economics and Information, Security", + author = "Laurie, Ben and Clayton, Richard", + title = "{``}Proof-of-Work{''} proves not to work; version 0.2", + year = "2004", } @Misc{vishnumurthy03karma:a, - author = {Vivek Vishnumurthy and Sangeeth Chandrakumar and Emin Gün Sirer}, - title = {KARMA: A Secure Economic Framework for Peer-to-Peer Resource Sharing}, - year = {2003} + author = "Vivek Vishnumurthy and Sangeeth Chandrakumar and Emin Gün Sirer", + title = "{KARMA}: A Secure Economic Framework for Peer-to-Peer Resource Sharing", + year = "2003" } @InProceedings{dwork92pricingvia, - author = {Cynthia Dwork and Moni Naor}, + author = "Cynthia Dwork and Moni Naor}, title = {Pricing via processing or combatting junk mail}, booktitle = {In 12th Annual International Cryptology Conference}, year = {1992}, From ca555b5389973121f48b4f9ae0df7c93bd771ddc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 15:54:38 +1100 Subject: [PATCH 275/335] Tips on editing, headings --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 725059d9..752018df 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,13 @@ cd yellowpaper ``` This will create a PDF version of the Yellow Paper. Following building, you can also use standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. +## Tips on editing + +You can use [TeX Stack Exchange](https://tex.stackexchange.com/); https://en.wikibooks.org/wiki/LaTeX/ (e.g. [Bibliography Management](https://en.wikibooks.org/wiki/LaTeX/Bibliography_Management) and [Hyperlinks](https://en.wikibooks.org/wiki/LaTeX/Hyperlinks)); and [BibTeX editor](http://truben.no/latex/bibtex/). + +## Versions + The previous protocol versions are listed in [BRANCHES.md](./BRANCHES.md). -## Other language versions +### Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu. From 41ab50b97d2cdf3eeb92bd2ea371e7bec52a1e84 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 17:20:15 +1100 Subject: [PATCH 276/335] Replaced an unbalanced brace with a double quote --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 48b6f8c8..512304fb 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -65,7 +65,7 @@ @Misc{vishnumurthy03karma:a } @InProceedings{dwork92pricingvia, - author = "Cynthia Dwork and Moni Naor}, + author = "Cynthia Dwork and Moni Naor", title = {Pricing via processing or combatting junk mail}, booktitle = {In 12th Annual International Cryptology Conference}, year = {1992}, From 1a0c22474b109e36707257d5368e80ea2a34cefa Mon Sep 17 00:00:00 2001 From: Li Xuanji Date: Wed, 7 Feb 2018 15:39:15 -0500 Subject: [PATCH 277/335] Cleanup ECREC definition and a few other things --- Paper.tex | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..a8865bfb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -26,7 +26,7 @@ %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} -% "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . +% "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . % For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. @@ -115,7 +115,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} \linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \end{equation} @@ -1148,6 +1148,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) \end{eqnarray} + With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. @@ -1453,7 +1454,8 @@ \section{Precompiled Contracts}\label{app:precompiled} The precompiled contracts each use these definitions and provide specifications for the $\mathbf{o}$ (the output data) and $g_{\mathrm{r}}$, the gas requirements. -For the elliptic curve DSA recover VM execution function, we also define $\mathbf{d}$ to be the input data, well-defined for an infinite length by appending zeroes as required. Importantly in the case of an invalid signature ($\mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing$), then we have no output. +We define $\Xi_{\mathtt{ERCEC}}$ as a precompiled contract for the elliptic curve digital signature algorithm (ECDSA) public key recovery function (ecrecover). See \ref{app:signing} for the definition of the function $\mathtt{\tiny ECDSARECOVER}$. We also define $\mathbf{d}$ to be the input data, well-defined for an infinite length by appending zeroes as required. In the case of an invalid signature ($\mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing$), we return no output. + \begin{eqnarray} \Xi_{\mathtt{ECREC}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_{\mathrm{r}} &=& 3000\\ @@ -1469,7 +1471,8 @@ \section{Precompiled Contracts}\label{app:precompiled} s &=& \mathbf{d}[96..127] \end{eqnarray} -The two hash functions, RIPEMD-160 and SHA2-256 are more trivially defined as an almost pass-through operation. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. +We define $\Xi_{\mathtt{SHA256}}$ and $\Xi_{\mathtt{RIP160}}$ as precompiled contracts implementing the SHA2-256 and RIPEMD-160 hash functions respectively. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. + \begin{eqnarray} \Xi_{\mathtt{SHA256}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ @@ -1477,10 +1480,11 @@ \section{Precompiled Contracts}\label{app:precompiled} \Xi_{\mathtt{RIP160}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ \mathbf{o}[0..11] &=& 0 \\ -\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_{\mathbf{d}})\\ +\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_{\mathbf{d}}) \end{eqnarray} For the purposes here, we assume we have well-defined standard cryptographic functions for RIPEMD-160 and SHA2-256 of the form: + \begin{eqnarray} \mathtt{\small SHA256}(\mathbf{i} \in \mathbb{B}) & \equiv & o \in \mathbb{B}_{32} \\ \mathtt{\small RIPEMD160}(\mathbf{i} \in \mathbb{B}) & \equiv & o \in \mathbb{B}_{20} @@ -1603,7 +1607,7 @@ \subsection{zkSNARK Related Precompiled Contracts} y_1&\equiv&\delta_{\mathrm{p}}(\mathbf x[96..127]) \end{eqnarray} -We define a precompiled contract for zkSNARK verification. +We define $\Xi_{\mathtt{SNARKV}}$ as a precompiled contract for zkSNARK verification. \begin{eqnarray} \Xi_{\mathtt{SNARKV}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \qquad\Xi_{\mathtt{SNARKV}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ F\\ @@ -1623,6 +1627,7 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{eqnarray} We define a precompiled contract for addition on $G_1$. + \begin{eqnarray} \Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ @@ -1652,7 +1657,7 @@ \section{Signing Transactions}\label{app:signing} It is assumed that the sender has a valid private key $p_{\mathrm{r}}$, which is a randomly selected positive integer (represented as a byte array of length 32 in big-endian form) in the range \hbox{$[1, \mathtt{\tiny secp256k1n} - 1]$}. -We assert the functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. +We assume the existence of functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. \begin{eqnarray} \mathtt{\small ECDSAPUBKEY}(p_{\mathrm{r}} \in \mathbb{B}_{32}) & \equiv & p_{\mathrm{u}} \in \mathbb{B}_{64} \\ \linkdest{ECDSASIGN}{}\mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_{\mathrm{r}} \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ @@ -1734,7 +1739,7 @@ \section{Fee Schedule}\label{app:fees} $G_{jumpdest}$ & 1 & Paid for a {\small JUMPDEST} operation. \\ $G_{sset}$ & 20000 & Paid for an {\small SSTORE} operation when the storage value is set to non-zero from zero. \\ $G_{sreset}$ & 5000 & Paid for an {\small SSTORE} operation when the storage value's zeroness remains unchanged or is set to zero. \\ -$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. +$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \linkdest{R__selfdestruct}{}\\$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ \linkdest{G__selfdestruct}{}$G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ $G_{create}$ & 32000 & Paid for a {\small CREATE} operation. \\ From c7dab56457a1138db6a88a27c4f73cdd06ed0726 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 11:40:55 +1100 Subject: [PATCH 278/335] Remove an extra } --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b6b5f8f6..e4f0960f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -345,7 +345,7 @@ \subsection{The Block} \label{ch:block} \linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above), $B_{\mathbf{U}}$ and a series of the transactions, $B_{\mathbf{T}}$. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}}) +B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}) \end{equation} \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} From b4c8a4987e20317705496f6ac8bc86236cedb22d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 11:44:05 +1100 Subject: [PATCH 279/335] ref{ch:block} => \hyperlink{block} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index db01e1f2..a68d25e6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -183,7 +183,7 @@ \section{Conventions}\label{ch:conventions} Arbitrary-length sequences are typically denoted as a bold lower-case letter, \eg $\mathbf{o}$ is used to denote the byte sequence given as the output data of a message call. For particularly important values, a bold uppercase letter may be used. -Throughout, we assume scalars are positive integers and thus belong to the set $\mathbb{P}$. The set of all byte sequences is $\mathbb{B}$, formally defined in Appendix \ref{app:rlp}. If such a set of sequences is restricted to those of a particular length, it is denoted with a subscript, thus the set of all byte sequences of length $32$ is named $\mathbb{B}_{32}$ and the set of all positive integers smaller than $2^{256}$ is named $\mathbb{P}_{256}$. This is formally defined in section \ref{ch:block}. +Throughout, we assume scalars are positive integers and thus belong to the set $\mathbb{P}$. The set of all byte sequences is $\mathbb{B}$, formally defined in Appendix \ref{app:rlp}. If such a set of sequences is restricted to those of a particular length, it is denoted with a subscript, thus the set of all byte sequences of length $32$ is named $\mathbb{B}_{32}$ and the set of all positive integers smaller than $2^{256}$ is named $\mathbb{P}_{256}$. This is formally defined in section \hyperlink{block}. Square brackets are used to index into and reference individual components or subsequences of sequences, \eg $\boldsymbol{\mu}_\mathbf{s}[0]$ denotes the first item on the machine's stack. For subsequences, ellipses are used to specify the intended range, to include elements at both limits, \eg $\boldsymbol{\mu}_\mathbf{m}[0..31]$ denotes the first 32 items of the machine's memory. @@ -191,7 +191,7 @@ \section{Conventions}\label{ch:conventions} When considering variants of existing values, I follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, I may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. -When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. +When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \hyperlink{block}. I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: From 75253c317cfb354734d1f8c644ec1340610486bc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 11:52:53 +1100 Subject: [PATCH 280/335] move by \cite{Keccak} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ac5dc9ef..311bcdb3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -175,7 +175,7 @@ \section{Conventions}\label{ch:conventions} Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest, rather than later releases, by \cite{Keccak}) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest by \cite{Keccak}, rather than later releases), is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. From ead443b874287d6a38c291f475b0f24bae24e2dd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 12:57:49 +1100 Subject: [PATCH 281/335] Fix spacing of table of maths symbols --- Paper.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..2d426e56 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,13 +2510,11 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. -\section{List of mathematical symbols}\label{app:symbols} -\begin{tabu*}{X[l]X[c]X} \savetabu{col3} +\begin{tabu*} spread 0pt{X[l] X[c] X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabu*} - \end{document} From f78721db21b028f60a6fbc47713584a3719064e5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:17:46 +1100 Subject: [PATCH 282/335] \hyperlink{bigvee}{\bigvee} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..d2034ede 100644 --- a/Paper.tex +++ b/Paper.tex @@ -386,7 +386,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} We define the Bloom filter function, $M$, to reduce a log entry into a single 256-byte hash: \begin{equation} -M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_{\mathbf{t}}} \big( M_{3:2048}(t) \big) +M(O) \equiv \hyperlink{bigvee}{\bigvee}_{t \in \{O_{\mathrm{a}}\} \cup O_{\mathbf{t}}} \big( M_{3:2048}(t) \big) \end{equation} where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence.\footnote{11 bits $= 2^{2048}$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: From b69b459a3868d8df567d3a80aae927b4eaff1f74 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:21:58 +1100 Subject: [PATCH 283/335] \hyperlink{Transaction Receipt} \hyperlink{Pi}{ --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..61effa40 100644 --- a/Paper.tex +++ b/Paper.tex @@ -423,7 +423,7 @@ \subsubsection{Holistic Validity} Thus $\texttt{\small TRIE}(L_{S}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{H})$ is the parent block of $B$, defined directly. -The values stemming from the computation of transactions, specifically the transaction receipts, $B_{\mathbf{R}}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. +The values stemming from the computation of transactions, specifically the \hyperlink{Transaction_Receipt}{transaction receipts}, $B_{\mathbf{R}}$, and that defined through the transaction's \hyperlink{Pi}{state-accumulation function, $\Pi$}, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} From ff5abbc7c7438b6053bdbcb531d26fa163f9e8a3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:26:12 +1100 Subject: [PATCH 284/335] \hyperlink{ommer_block_headers_B__U}{B_{\mathbf{U}}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..ae93f939 100644 --- a/Paper.tex +++ b/Paper.tex @@ -430,7 +430,7 @@ \subsubsection{Serialisation} The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ -\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) +\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(\hyperlink{ommer_block_headers_B__U}{B_{\mathbf{U}}}) \big) \end{eqnarray} \hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: From 627a695f6850b32de273b4e2b8ff1fb7bea53e33 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:32:50 +1100 Subject: [PATCH 285/335] L_{R} hypertargets and links --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..8f703253 100644 --- a/Paper.tex +++ b/Paper.tex @@ -358,7 +358,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}}) \end{equation} -The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: +\hypertarget{transaction_receipt_preparation_function_for_RLP_serialisation}{}The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}) \end{equation} @@ -407,7 +407,7 @@ \subsubsection{Holistic Validity} \linkdest{new_state_H__r}{}H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ \linkdest{Ommer_block_hash_H__o}{}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_{\mathbf{U}}))) & \wedge \\ \linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{T}} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_{\mathbf{T}}[i]))\}) & \wedge \\ -\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_{\mathbf{R}}[i]))\}) & \wedge \\ +\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: p(i, \hyperlink{transaction_receipt_preparation_function_for_RLP_serialisation}{L_{R}}(B_{\mathbf{R}}[i]))\}) & \wedge \\ \linkdest{logs_Bloom_filter_H__b}{}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_{\mathbf{R}}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} @@ -427,7 +427,7 @@ \subsubsection{Holistic Validity} \subsubsection{Serialisation} -The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: +The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the \hyperlink{transacation_receipt_preparation_function_for_RLP_serialisation}{transaction receipt preparation function $L_{R}$}, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ \quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) From c285969c2eb2a0625aa9aa9777e214a41e785647 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:36:21 +1100 Subject: [PATCH 286/335] \hypertarget{block_preparation_function_for_RLP_serialization_L__B}{}\hypertarget{block_preparation_function_for_RLP_serialization_L__H}{} These aren't actually used elsewhere. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..42803586 100644 --- a/Paper.tex +++ b/Paper.tex @@ -427,7 +427,7 @@ \subsubsection{Holistic Validity} \subsubsection{Serialisation} -The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: +\hypertarget{block_preparation_function_for_RLP_serialization_L__B}{}\hypertarget{block_preparation_function_for_RLP_serialization_L__H}{}The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ \quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) From a5a16769cf7f3d167ef46436710519f05ca468e6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:59:19 +1100 Subject: [PATCH 287/335] Links for component types (plus update elsewhere) in block and block header preparation functions. --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..be5a21b4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -334,10 +334,10 @@ \subsection{The Block} \label{ch:block} \item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. \item[logsBloom]\linkdest{logs_Bloom_def_words}{} The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_{\mathrm{b}}$. \item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_{\mathrm{d}}$. -\item[number]\linkdest{block_number_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_{\mathrm{i}}$. +\item[number]\linkdest{block_number_word_def_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally \hyperlink{block_number_H__i}{$H_{\mathrm{i}}$}. \item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_{\mathrm{l}}$. \item[gasUsed]\linkdest{block_gas_used_H__g}{} A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. -\item[timestamp]\linkdest{block_timestamp_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_{\mathrm{s}}$. +\item[timestamp]\linkdest{block_timestamp_word_def_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally \hyperlink{block_timestamp_H__s}{$H_{\mathrm{s}}$}. \item[extraData]\linkdest{block_extraData_H__x}{} An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_{\mathrm{x}}$. \item[mixHash]\linkdest{mixHash_H__m}{} A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{m}}$. \item[nonce]\linkdest{block_nonce_H__n}{} A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{n}}$. @@ -441,11 +441,11 @@ \subsubsection{Serialisation} The component types are defined thus: \begin{equation} \begin{array}[t]{lclclcl} -H_{\mathrm{p}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ -H_{\mathrm{r}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{e}} \in \mathbb{B}_{32} & \wedge \\ -H_{\mathrm{b}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{P} & \wedge & H_{\mathrm{i}} \in \mathbb{P} & \wedge \\ -H_{\mathrm{l}} \in \mathbb{P} & \wedge & H_{\mathrm{g}} \in \mathbb{P} & \wedge & H_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge \\ -H_{\mathrm{x}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{n}} \in \mathbb{B}_{8} +\hyperlink{parent_Hash_H__p_def_words}{H_{\mathrm{p}}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ +\hyperlink{new_state_H__r}{H_{\mathrm{r}}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & \hyperlink{Receipts_Root_H__e}{H_{\mathrm{e}}} \in \mathbb{B}_{32} & \wedge \\ +\hyperlink{logs_Bloom_filter_H__b}{H_{\mathrm{b}}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{P} & \wedge & \hyperlink{block_number_H__i}{H_{\mathrm{i}}} \in \mathbb{P} & \wedge \\ +\hyperlink{block_gas_limit_H__l}{H_{\mathrm{l}}} \in \mathbb{P} & \wedge & H_{\mathrm{g}} \in \mathbb{P} & \wedge & \hyperlink{block_timestamp_H__s}{H_{\mathrm{s}}} \in \mathbb{P}_{256} & \wedge \\ +\hyperlink{block_extraData_H__x}{H_{\mathrm{x}}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & \hyperlink{block_nonce_H__n}{H_{\mathrm{n}}} \in \mathbb{B}_{8} \end{array} \end{equation} @@ -510,7 +510,7 @@ \subsubsection{Block Header Validity} & & H_{\mathrm{l}} \geqslant 5000 \end{eqnarray} -$H_{\mathrm{s}}$ is the timestamp (in Unix's time()) of block $H$ and must fulfil the relation: +\hypertarget{block_timestamp_H__s}{}$H_{\mathrm{s}}$ is the timestamp (in Unix's time()) of block $H$ and must fulfil the relation: \begin{equation} H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \end{equation} From e456ca3740e1c2951f6bab89390eb3a85b67afe7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:04:02 +1100 Subject: [PATCH 288/335] \hypertarget{block_number_H__i}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index be5a21b4..2b560b35 100644 --- a/Paper.tex +++ b/Paper.tex @@ -463,7 +463,7 @@ \subsubsection{Block Header Validity} P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = H_{\mathrm{p}} \end{equation} -The block number is the parent's block number incremented by one: +\hypertarget{block_number_H__i}{}The block number is the parent's block number incremented by one: \begin{equation} H_{\mathrm{i}} \equiv {{P(H)_{H}}_{\mathrm{i}}} + 1 \end{equation} From 4c08f3374d2a62006b22a831b5c5ca5c8095fb37 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:08:02 +1100 Subject: [PATCH 289/335] \hyperlink{parent_Hash_H__p_def_words}{H_{\mathrm{p}}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2b560b35..452bb783 100644 --- a/Paper.tex +++ b/Paper.tex @@ -460,7 +460,7 @@ \subsubsection{Block Header Validity} We define $P(B_{H})$ to be the parent block of $B$, formally: \begin{equation} -P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = H_{\mathrm{p}} +P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = \hyperlink{parent_Hash_H__p_def_words}{H_{\mathrm{p}}} \end{equation} \hypertarget{block_number_H__i}{}The block number is the parent's block number incremented by one: From 014a6ff5c66eff7cd2683836480d2089806008cb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:28:25 +1100 Subject: [PATCH 290/335] More hyperlinks: upsilon_pow_g,l,z, account_nonce, block_nonce_H__n --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 452bb783..08d32241 100644 --- a/Paper.tex +++ b/Paper.tex @@ -517,7 +517,7 @@ \subsubsection{Block Header Validity} This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. -The nonce, $H_{\mathrm{n}}$, must satisfy the relations: +The nonce, \hyperlink{block_nonce_H__n}{$H_{\mathrm{n}}$}, must satisfy the relations: \begin{equation} n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \wedge \quad m = H_{\mathrm{m}} \end{equation} @@ -560,7 +560,7 @@ \section{Transaction Execution} \label{ch:transactions} \begin{enumerate} \item The transaction is well-formed RLP, with no additional trailing bytes; \item the transaction signature is valid; -\item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the sender account's current nonce); +\item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the \hyperlink{account_nonce}{sender account's current nonce}); \item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} @@ -570,7 +570,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^{\mathrm{g}}$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^{\mathbf{l}}$ to evaluate to the transaction's accrued log items and $\Upsilon^{\mathrm{z}}$ to evaluate to the status code resulting from the transaction. These will be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define \hyperlink{tx_total_gas_used_Upsilon_pow_g}{$\Upsilon^{\mathrm{g}}$} to evaluate to the amount of gas used in the execution of a transaction, \hyperlink{tx_logs_Upsilon_pow_l}{$\Upsilon^{\mathbf{l}}$} to evaluate to the transaction's accrued log items and \hyperlink{tx_status_Upsilon_pow_z}{$\Upsilon^{\mathrm{z}}$} to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: From d7e25d2ecf4aeab7471b594dbd35f0be131e55f7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:35:40 +1100 Subject: [PATCH 291/335] \hyperlink{SSTORE}{{\small SSTORE}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..33850212 100644 --- a/Paper.tex +++ b/Paper.tex @@ -578,7 +578,7 @@ \subsection{Substate} A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}) \end{equation} -\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the \hyperlink{SSTORE}{{\small SSTORE}} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} From 8bce0fb8708dcccdde7647fba75e64b84a89f28e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:42:55 +1100 Subject: [PATCH 292/335] Intrinsic gas hyperlinks and mathrm: \hyperlink{G__txdatazero}{G_{\mathrm{txdatazero}}}, etc. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..24d64aa4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -588,12 +588,12 @@ \subsection{Substate} \subsection{Execution} \hypertarget{intrinsic_gas_g_0}{}We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} -g_0 \equiv {} & \sum_{i \in T_{\mathbf{i}}, T_{\mathbf{d}}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ -{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ -{} & + G_{transaction} +g_0 \equiv {} & \sum_{i \in T_{\mathbf{i}}, T_{\mathbf{d}}} \begin{cases} \hyperlink{G__txdatazero}{G_{\mathrm{txdatazero}}} & \text{if} \quad i = 0 \\ \hyperlink{G__txdatanonzero}{G_{\mathrm{txdatanonzero}}} & \text{otherwise} \end{cases} \\ +{} & + \begin{cases} \hyperlink{Gtxcreate}{G_{\mathrm{txcreate}}} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ +{} & + \hyperlink{Gtransaction}{G_{\mathrm{transaction}}} \end{align} -where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. +where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_{\mathrm{txcreate}}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. The up-front cost $v_0$ is calculated as: \begin{equation} From 79b68808ae037453f03b734af29a8a58502914d5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:50:04 +1100 Subject: [PATCH 293/335] The up-front cost hyperlinks It's pretty simple anyway but nevertheless... --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..51d2a737 100644 --- a/Paper.tex +++ b/Paper.tex @@ -595,9 +595,9 @@ \subsection{Execution} where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. -The up-front cost $v_0$ is calculated as: +The up-front cost $v_0$ is calculated as the transaction gas limit multiplied by the gas price, plus the transaction value: \begin{equation} -v_0 \equiv T_{\mathrm{g}} T_{\mathrm{p}} + T_{\mathrm{v}} +v_0 \equiv \hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}} \hyperlink{tx_gas_price_T__p}{T_{\mathrm{p}}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} \end{equation} The validity is determined as: From cd26363dc40a8aa3cf4632809408eea751425627 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:52:58 +1100 Subject: [PATCH 294/335] \hyperlink{ell}{\ell} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..25efb240 100644 --- a/Paper.tex +++ b/Paper.tex @@ -608,11 +608,11 @@ \subsection{Execution} \linkdest{transaction_nonce}{}T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ -T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_{\mathbf{R}})_{\mathrm{u}} +T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \hyperlink{ell}{\ell}(B_{\mathbf{R}})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\hyperlink{ell}{\ell}(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. From b30fb8cdd49c144f3a3d3cb153038a6d19724930 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:54:47 +1100 Subject: [PATCH 295/335] \hyperlink{account_nonce}{nonce of the account of the sender} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..bdf8ce36 100644 --- a/Paper.tex +++ b/Paper.tex @@ -614,7 +614,7 @@ \subsection{Execution} Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. -The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. +The execution of a valid transaction begins with an irrevocable change made to the state: the \hyperlink{account_nonce}{nonce of the account of the sender}, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. We define the checkpoint state $\boldsymbol{\sigma}_0$: \begin{eqnarray} From 8fc6d3e82e9ccc37207834a6429f2671092d1d7e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:01:42 +1100 Subject: [PATCH 296/335] \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..a2f7470a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -578,7 +578,7 @@ \subsection{Substate} A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}) \end{equation} -\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn_A__s}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn_A__l}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn_A__t}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words_A__r}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} @@ -641,7 +641,7 @@ \subsection{Execution} After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} -g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, A_{\mathrm{r}} \} +g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} \} \end{equation} The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. From 8902ba2d1109cd77663590e9272486cd73ab2ea6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:08:28 +1100 Subject: [PATCH 297/335] \hyperlink{tx_log_series_wordy_defn_A__l}{A_{\mathbf{l}}} etc. --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a2f7470a..4529da52 100644 --- a/Paper.tex +++ b/Paper.tex @@ -6,7 +6,7 @@ \usepackage{multicol} \usepackage{subfig} \usepackage{amsmath} -\usepackage{amssymb} +\usepackage{amssymb}Th \usepackage[a4paper,width=170mm,top=18mm,bottom=22mm,includeheadfoot]{geometry} \usepackage{booktabs} \usepackage{array} @@ -644,7 +644,7 @@ \subsection{Execution} g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} \} \end{equation} -The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. +The total refundable amount is the legitimately remaining gas $g'$, added to \hyperlink{refund_balance_defn_words_A__r}{$A_{\mathrm{r}}$}, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{P}$: \begin{eqnarray} @@ -664,7 +664,7 @@ \subsection{Execution} \hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_z}{}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: \begin{eqnarray} \Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_{\mathbf{l}} \\ +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & \hyperlink{tx_log_series_wordy_defn_A__l}{A_{\mathbf{l}}} \\ \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} From ca94d647af38b7c8d6cd2602101918af432d908c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:08:59 +1100 Subject: [PATCH 298/335] Remove a mistake "Th" --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 4529da52..1c60ea56 100644 --- a/Paper.tex +++ b/Paper.tex @@ -6,7 +6,7 @@ \usepackage{multicol} \usepackage{subfig} \usepackage{amsmath} -\usepackage{amssymb}Th +\usepackage{amssymb} \usepackage[a4paper,width=170mm,top=18mm,bottom=22mm,includeheadfoot]{geometry} \usepackage{booktabs} \usepackage{array} From c63ed730c884b6bf2ebeda185ba2e099061a7f0e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:13:06 +1100 Subject: [PATCH 299/335] \hyperlink{rlp}{RLP} etc. and grammar --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..41860e28 100644 --- a/Paper.tex +++ b/Paper.tex @@ -679,12 +679,12 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} (\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} -The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: +The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the \hyperlink{rlp}{RLP} encoding of the structure containing only the sender and the \hyperlink{account nonce}{account nonce}. Thus we define the resultant address for the new account $a$: \begin{equation} a \equiv \mathcal{B}_{96..255}\Big(\mathtt{\tiny KEC}\Big(\mathtt{\tiny RLP}\big(\;(s, \boldsymbol{\sigma}[s]_{\mathrm{n}} - 1)\;\big)\Big)\Big) \end{equation} -where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$ and $\boldsymbol{\sigma}[x]$ is the address state of $x$ or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. +where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to a binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$, and $\boldsymbol{\sigma}[x]$ is the address state of $x$, or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. The account's nonce is initially defined as one, the balance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender's balance is also reduced by the value passed. Thus the mutated state becomes $\boldsymbol{\sigma}^*$: \begin{equation} From 61d01ca3f2a158cf507f2eb480799621a9e928ce Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:17:24 +1100 Subject: [PATCH 300/335] \hyperlink{trie}{TRIE} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..c155bd7b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -691,7 +691,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except:} \end{equation} \begin{eqnarray} -\boldsymbol{\sigma}^*[a] &=& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[a] &=& \big( 1, v + v', \mathtt{\tiny \hyperlink{trie}{TRIE}}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ \boldsymbol{\sigma}^*[s] &=& \begin{cases} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} From a499bd85e180a0f776eda513f40eeb257f9f2ca3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:25:50 +1100 Subject: [PATCH 301/335] \hyperlink{execenv}{execution environment} and linkdest --- Paper.tex | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..04ea35dd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -714,7 +714,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \begin{equation} (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} -\pagebreak[1]where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is:\pagebreak[1] +\pagebreak[1]where $I$ contains the parameters of the \hyperlink{exec_env}{execution environment}, that is:\pagebreak[1] \begin{eqnarray} I_{\mathrm{a}} & \equiv & a \\ I_{\mathrm{o}} & \equiv & o \\ @@ -723,7 +723,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & v \\ I_{\mathbf{b}} & \equiv & \mathbf{i} \\ -I_{\mathrm{e}} & \equiv & e \\ +\hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} @@ -877,21 +877,21 @@ \subsection{Fees Overview} See Appendix \ref{app:vm} for a rigorous definition of the EVM gas cost. -\subsection{Execution Environment} +\subsection{Execution Environment}\linkdest{exec_env} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: \begin{itemize} -\item\linkdest{address_of_account_which_owns_code_I__a_def_words}{} $I_{\mathrm{a}}$, the address of the account which owns the code that is executing. -\item\linkdest{address_of_sender_of_tx_that_originated_execution_I__o}{} $I_{\mathrm{o}}$, the sender address of the transaction that originated this execution. -\item\linkdest{gas_price_in_tx_that_originated_execution_I__p}{} $I_{\mathrm{p}}$, the price of gas in the transaction that originated this execution. -\item\linkdest{execution_input_data_I__d}{} $I_{\mathbf{d}}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. +\item\linkdest{address_of_account_which_owns_code_I__a_def_words}{}\linkdest{I__a} $I_{\mathrm{a}}$, the address of the account which owns the code that is executing. +\item\linkdest{address_of_sender_of_tx_that_originated_execution_I__o}{}\linkdest{I__o} $I_{\mathrm{o}}$, the sender address of the transaction that originated this execution. +\item\linkdest{gas_price_in_tx_that_originated_execution_I__p}{}\linkdest{I__p} $I_{\mathrm{p}}$, the price of gas in the transaction that originated this execution. +\item\linkdest{execution_input_data_I__d}{}\linkdest{I__d} $I_{\mathbf{d}}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. \item\linkdest{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} $I_{\mathrm{s}}$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. -\item\linkdest{Wei_value_exec}{} $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. -\item\linkdest{exec_machine_code_I__b}{} $I_{\mathbf{b}}$, the byte array that is the machine code to be executed. -\item\linkdest{exec_block_header_I__H}{} $I_{\mathbf{H}}$, the block header of the present block. -\item\linkdest{exec_call_or_create_depth_I__e}{} $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). -\item\linkdest{exec_permission_to_modify_state_I__w}{} $I_{\mathrm{w}}$, the permission to make modifications to the state. +\item\linkdest{Wei_value_exec_I__v}{}\linkdest{I__v}{} $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. +\item\linkdest{exec_machine_code_I__b}{}\linkdest{I__b} $I_{\mathbf{b}}$, the byte array that is the machine code to be executed. +\item\linkdest{exec_block_header_I__H}{}\linkdest{I__H} $I_{\mathbf{H}}$, the block header of the present block. +\item\linkdest{exec_call_or_create_depth_I__e}{}\linkdest{I__e} $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item\linkdest{exec_permission_to_modify_state_I__w}{}\linkdest{I__e} $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: From ec4c7f34a2061ccdcfbea5929d48e0086fd9a247 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:33:55 +1100 Subject: [PATCH 302/335] \hyperlink{hhalt}{normal halting} \hyperlink{zhalt}{exceptional halting} + linkdests --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..7e0b5cbe 100644 --- a/Paper.tex +++ b/Paper.tex @@ -907,7 +907,7 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an \hyperlink{zhalt}{exceptional halting} state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a \hyperlink{hhalt}{normal halting} state of the machine. \hypertarget{empty_sequence_vs_empty_set}{}The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} @@ -955,7 +955,7 @@ \subsubsection{Machine State} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{}\linkdest{zhalt} The exceptional halting function $Z$ is defined as: \begin{equation} @@ -1008,7 +1008,7 @@ \subsubsection{Jump Destination Validity} i + 1 & \text{otherwise} \end{cases} \end{equation} -\subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} +\subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{}\linkdest{hhalt} The normal halting function $H$ is defined: \begin{equation} From 5706ace2daba6e015e4347643219727d33e8da4c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:37:12 +1100 Subject: [PATCH 303/335] \hyperlink{stop}{\small STOP}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..7d931540 100644 --- a/Paper.tex +++ b/Paper.tex @@ -949,7 +949,7 @@ \subsubsection{Machine State} For the purposes of defining $Z$, $H$ and $O$, we define $w$ as the current operation to be executed: \begin{equation}\label{eq:currentoperation} w \equiv \begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_{\mathbf{b}} \rVert \\ -\text{\small STOP} & \text{otherwise} +\text{\hyperlink{stop}{\small STOP}} & \text{otherwise} \end{cases} \end{equation} From 6fc4fec0df957f3dddc97dcdbb1607d24b3cdce3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:39:40 +1100 Subject: [PATCH 304/335] \hyperlink{stop}{{\small STOP}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..e7a4f38e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -985,7 +985,7 @@ \subsubsection{Jump Destination Validity} We previously used $D$ as the function to determine the set of valid jump destinations given the code that is being run. We define this as any position in the code occupied by a {\small JUMPDEST} instruction. -All such positions must be on valid instruction boundaries, rather than sitting in the data portion of {\small PUSH} operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined {\small STOP} operations that trail it). +All such positions must be on valid instruction boundaries, rather than sitting in the data portion of {\small PUSH} operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined \hyperlink{stop}{{\small STOP}} operations that trail it). Formally: \begin{equation} From c916a0a8dfcc3665d6e8ee8bf621cb8ada1e4a99 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:54:11 +1100 Subject: [PATCH 305/335] \hyperlink{RETURN} selfdestruct --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..f48c56d0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1013,13 +1013,13 @@ \subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} The normal halting function $H$ is defined: \begin{equation} H(\boldsymbol{\mu}, I) \equiv \begin{cases} -H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w \in \{\text{\small RETURN}, \text{\small REVERT}\} \\ -() & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small SELFDESTRUCT} \} \\ +H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w \in \{\text{\small \hyperlink{RETURN}{RETURN}}, \text{\small REVERT}\} \\ +() & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small \hyperlink{selfdestruct}{SELFDESTRUCT}} \} \\ \varnothing & \text{otherwise} \end{cases} \end{equation} -The data-returning halt operations, \text{\small RETURN} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$, defined in Appendix \ref{app:vm}. +The data-returning halt operations, \hyperlink{RETURN}{\text{\small RETURN}} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$. \subsection{The Execution Cycle} From e63a37c8c010aa4d7c2c9e340673dea02909e428 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:57:05 +1100 Subject: [PATCH 306/335] discussed \hyperlink{empty_sequence_vs_empty_set}{here} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f48c56d0..8d0e0c1d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1019,7 +1019,7 @@ \subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} \end{cases} \end{equation} -The data-returning halt operations, \hyperlink{RETURN}{\text{\small RETURN}} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$. +The data-returning halt operations, \hyperlink{RETURN}{\text{\small RETURN}} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$. Note also the difference between the empty sequence and the empty set as discussed \hyperlink{empty_sequence_vs_empty_set}{here}. \subsection{The Execution Cycle} From 6f21bc31b5ddc32b66ddd7bcc3c93601c2b8e704 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:00:50 +1100 Subject: [PATCH 307/335] \hyperlink{JUMP}{J_{\text{JUMP}}} \hyperlink{JUMPI}{J_{\text{JUMPI}}} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..d5ce1838 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1035,8 +1035,8 @@ \subsection{The Execution Cycle} \begin{eqnarray} \quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \label{eq:mu_pc}\\ \quad \boldsymbol{\mu}'_{pc} & \equiv & \begin{cases} -J_{\text{JUMP}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ -J_{\text{JUMPI}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ +\hyperlink{JUMP}{J_{\text{JUMP}}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ +\hyperlink{JUMPI}{J_{\text{JUMPI}}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ N(\boldsymbol{\mu}_{pc}, w) & \text{otherwise} \end{cases} \end{eqnarray} From 12f04111d648d7c6792a2ac9dbe6b866012ed0a5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:04:15 +1100 Subject: [PATCH 308/335] \hyperlink{Genesis_Block}{genesis block} --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..cf841150 100644 --- a/Paper.tex +++ b/Paper.tex @@ -159,7 +159,7 @@ \subsection{Value} \subsection{Which History?} -Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (\hyperlink{GenesisBlock}{the genesis block}) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. +Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (\hyperlink{Genesis_Block}{the genesis block}) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. This would mean that past a given point in time (block), multiple states of the system may coexist: some nodes believing one block to contain the canonical transactions, other nodes believing some other block to be canonical, potentially containing radically different or incompatible transactions. This is to be avoided at all costs as the uncertainty that would ensue would likely kill all confidence in the entire system. @@ -1053,7 +1053,7 @@ \subsection{The Execution Cycle} \section{Blocktree to Blockchain} \label{ch:ghost} -The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually we identify the path that has had the most computation done upon it, or, the \textit{heaviest} path. Clearly one factor that helps determine the heaviest path is the block number of the leaf, equivalent to the number of blocks, not counting the unmined genesis block, in the path. The longer the path, the greater the total mining effort that must have been done in order to arrive at the leaf. This is akin to existing schemes, such as that employed in Bitcoin-derived protocols. +The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually we identify the path that has had the most computation done upon it, or, the \textit{heaviest} path. Clearly one factor that helps determine the heaviest path is the block number of the leaf, equivalent to the number of blocks, not counting the unmined \hyperlink{Genesis_Block}{genesis block}, in the path. The longer the path, the greater the total mining effort that must have been done in order to arrive at the leaf. This is akin to existing schemes, such as that employed in Bitcoin-derived protocols. Since a block header includes the difficulty, the header alone is enough to validate the computation done. Any block contributes toward the total computation or \textit{total difficulty} of a chain. @@ -2321,7 +2321,7 @@ \subsection{Instruction Set} \bottomrule \end{tabular*} -\section{Genesis Block}\label{app:genesis}\hypertarget{GenesisBlock}{} +\section{Genesis Block}\label{app:genesis}\hypertarget{Genesis_Block}{} The genesis block is 15 items, and is specified thus: \begin{equation} From a01fd9ca84a8d3e66995c54d63c8cd98424e208f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:12:35 +1100 Subject: [PATCH 309/335] hyperlinks block_header_validity_function ommer_block_header --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..5b4f2382 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1073,14 +1073,14 @@ \section{Block Finalisation} \label{ch:finalisation} \item Validate (or, if mining, determine) ommers; \item validate (or, if mining, determine) transactions; \item apply rewards; -\item verify (or, if mining, compute a valid) state and nonce. +\item verify (or, if mining, compute a valid) state and \hyperlink{block nonce}{block nonce}. \end{enumerate} \subsection{Ommer Validation} -The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: +The validation of \hyperlink{ommer_block_headers_B__U}{ommer headers} means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_{\mathbf{U}} \rVert \leqslant 2 \bigwedge_{\mathbf{U} \in B_{\mathbf{U}}} V({\mathbf{U}}) \; \wedge \; k({\mathbf{U}}, P(\mathbf{B}_{\mathbf{H}})_{\mathbf{H}}, 6) +\lVert B_{\mathbf{U}} \rVert \leqslant 2 \bigwedge_{\mathbf{U} \in B_{\mathbf{U}}} \hyperlink{block_header_validity_function}{V({\mathbf{U}}})\; \wedge \; k({\mathbf{U}}, P(\mathbf{B}_{\mathbf{H}})_{\mathbf{H}}, 6) \end{equation} where $k$ denotes the ``is-kin'' property: From 06d541c09e962afb73a161d85c51bac75133b087 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:19:40 +1100 Subject: [PATCH 310/335] \hyperlink{H__g} --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..2663d01e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -328,7 +328,7 @@ \subsection{The Block} \label{ch:block} \begin{description} \item[parentHash]\linkdest{parent_Hash_H__p_def_words}{} The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_{\mathrm{p}}$. \item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. -\item[beneficiary]\linkdest{beneficiary_H__c}{} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. +\item[beneficiary]\linkdest{beneficiary_H__c}{}\linkdest{H__c} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_{\mathrm{r}}$. \item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_{\mathrm{t}}$. \item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. @@ -336,7 +336,7 @@ \subsection{The Block} \label{ch:block} \item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_{\mathrm{d}}$. \item[number]\linkdest{block_number_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_{\mathrm{i}}$. \item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_{\mathrm{l}}$. -\item[gasUsed]\linkdest{block_gas_used_H__g}{} A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. +\item[gasUsed]\linkdest{block_gas_used_H__g}{}\linkdest{H__g} A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. \item[timestamp]\linkdest{block_timestamp_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_{\mathrm{s}}$. \item[extraData]\linkdest{block_extraData_H__x}{} An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_{\mathrm{x}}$. \item[mixHash]\linkdest{mixHash_H__m}{} A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{m}}$. @@ -1101,9 +1101,9 @@ \subsection{Transaction Validation} %where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_{\mathbf{T}}[i]$, and $g[i]$ the total gas used immediately after said transaction. -The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{H}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: +The given \textbf{gasUsed} must correspond faithfully to the transactions listed: \hyperlink{H__g}{${B_{H}}_{\mathrm{g}}$}, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_{H}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} +{B_{H}}_{\mathrm{g}} = \hyperlink{ell}{\ell}(\mathbf{R})_{\mathrm{u}} \end{equation} \subsection{Reward Application} From 722f659220eba1395f92e380a33954b480f644fd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:22:37 +1100 Subject: [PATCH 311/335] \hyperlink{R__u} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2663d01e..881a0bed 100644 --- a/Paper.tex +++ b/Paper.tex @@ -353,7 +353,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_{\mathbf{R}}[i]$ for the $i$th transaction, is placed in an index-keyed \hyperlink{trie}{trie} and the root recorded in the header as \hyperlink{Receipts_Root_H__e}{$H_{\mathrm{e}}$}. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt, $R$, is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, \hyperlink{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{$R_\mathbf{l}$} and the Bloom filter composed from information in those logs, \hyperlink{RLP_serialisation_of_a_byte_array_R__b_math_def}{$R_{\mathrm{b}}$} and the status code of the transaction, $R_{\mathrm{z}}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}\linkdest{R__u}The transaction receipt, $R$, is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, \hyperlink{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{$R_\mathbf{l}$} and the Bloom filter composed from information in those logs, \hyperlink{RLP_serialisation_of_a_byte_array_R__b_math_def}{$R_{\mathrm{b}}$} and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}}) \end{equation} @@ -1103,7 +1103,7 @@ \subsection{Transaction Validation} The given \textbf{gasUsed} must correspond faithfully to the transactions listed: \hyperlink{H__g}{${B_{H}}_{\mathrm{g}}$}, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_{H}}_{\mathrm{g}} = \hyperlink{ell}{\ell}(\mathbf{R})_{\mathrm{u}} +{B_{H}}_{\mathrm{g}} = \hyperlink{ell}{\ell}(\hyperlink{R__u}{\mathbf{R})_{\mathrm{u}}} \end{equation} \subsection{Reward Application} From 9d594899ece2646b02d8d3220a2dcfe124295394 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:49:40 +1100 Subject: [PATCH 312/335] R_{\mathrm{b}} as the block reward => R_{\mathrm{block}} + links --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..688d1bf5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1108,25 +1108,25 @@ \subsection{Transaction Validation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_{\mathrm{b}}$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{} Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_{\mathrm{block}}$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{} Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_{\mathbf{U}}\rVert}{32})R_{\mathrm{b}} \\ +\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_{\mathbf{U}}\rVert}{32})R_{\mathrm{block}} \\ \qquad\forall_{\mathbf{U} \in \mathbf{B}_{\mathbf{U}}}: \\ \nonumber \boldsymbol{\sigma}'[\mathbf{U}_{\mathrm{c}}] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[\mathbf{U}_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ \mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathbf{s}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ -R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{b}} +R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{block}} \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -\hypertarget{block_reward_R__b}{}We define the block reward as 3 Ether: +\hypertarget{block_reward_R__block}{}We define the block reward as 3 Ether: \begin{equation} -\text{Let} \quad R_{\mathrm{b}} = 3 \times 10^{18} +\text{Let} \quad R_{\mathrm{block}} = 3 \times 10^{18} \end{equation} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} @@ -1315,7 +1315,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_{\mathrm{b}}(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_{\mathrm{l}}(\mathbf{x}) & \text{otherwise} \end{cases} \end{equation} -\hypertarget{RLP_serialisation_of_a_byte_array_R__b_word_def}{}If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: +\hypertarget{RLP_serialisation_of_a_byte_array_R__b_word_def}{}\linkdest{R__b}If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: \begin{itemize} \item If the byte-array contains solely a single byte and that single byte is less than 128, then the input is exactly equal to the output. @@ -1324,7 +1324,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \end{itemize} \hypertarget{RLP_serialisation_of_a_byte_array_R__b_math_def}{}Formally, we define $R_{\mathrm{b}}$: -\begin{eqnarray} +\begin{eqnarray}R_\{\\mathrm\{b\}\} R_{\mathrm{b}}(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ (128 + \lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{else if} \quad \lVert \mathbf{x} \rVert < 56 \\ @@ -1336,7 +1336,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} Thus $\mathtt{\tiny BE}$ is the function that expands a positive integer value to a big-endian byte array of minimal length and the dot operator performs sequence concatenation. -\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_word_def}{}If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: +\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_word_def}{}\linkdest{R__l}If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: \begin{itemize} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. From 9cf1949e89ef5bdbc368206c2896429a4ceb3de7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 17:52:34 +1100 Subject: [PATCH 313/335] Remove accidentally added R_\{\\mathrm\{b\}\} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 688d1bf5..7e3a9c14 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1324,7 +1324,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \end{itemize} \hypertarget{RLP_serialisation_of_a_byte_array_R__b_math_def}{}Formally, we define $R_{\mathrm{b}}$: -\begin{eqnarray}R_\{\\mathrm\{b\}\} +\begin{eqnarray} R_{\mathrm{b}}(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ (128 + \lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{else if} \quad \lVert \mathbf{x} \rVert < 56 \\ From 731cc979eeefc5b74b03df1e4f6b983e42b75fb9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 18:12:13 +1100 Subject: [PATCH 314/335] \hyperlink{H_cancel_n}{\hcancel{n}}, etc. + grammar --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..035001f7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -473,7 +473,7 @@ \subsubsection{Block Header Validity} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} \newcommand{\diffadjustment}{x} -\hypertarget{block_difficulty_H__d}{}The canonical difficulty of a block of header $H$ is defined as $D(H)$: +\hypertarget{block_difficulty_H__d}{}\linkdest{H__d}The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_{\mathrm{i}} = 0\\ @@ -523,7 +523,7 @@ \subsubsection{Block Header Validity} \end{equation} with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. -\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. +\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}\linkdest{H_cancel_n}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. @@ -1135,17 +1135,17 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_{H}) = \varnothing \\ -\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small \hyperlink{trie}{TRIE}}}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. -\hypertarget{Phi}{}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: +\hypertarget{Phi}{}And finally we define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ -B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \\ -B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ +B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{\hyperlink{H__d}{H_{\mathrm{d}}}} \\ +B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hyperlink{H_cancel_n}{\hcancel{n}}}, n, \mathbf{d}) \\ B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. From 024d6e28423364f18667d40a3b56211b3a50add0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 18:31:48 +1100 Subject: [PATCH 315/335] which is, more links in State and Nonce Evaluation --- Paper.tex | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..e36c3804 100644 --- a/Paper.tex +++ b/Paper.tex @@ -117,7 +117,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) +\linkdest{Upsilon_state_transition}\linkdest{Upsilon}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -661,14 +661,14 @@ \subsection{Execution} \linkdest{touched_A__t}{}\forall i \in A_{\mathbf{t}}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_z}{}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\linkdest{Upsilon_pow_g}\hypertarget{tx_logs_Upsilon_pow_l}{}\linkdest{Upsilon_pow_l}\hypertarget{tx_status_Upsilon_pow_z}{}\linkdest{Upsilon_pow_z}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: \begin{eqnarray} \Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_{\mathbf{l}} \\ \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} -These are used to help define the \hyperlink{Transaction_Receipt}{transaction receipt}. +These are used to help define the \hyperlink{Transaction_Receipt}{transaction receipt} and are also used \hyperlink{Upsilon_pow_g2}{later} for state and nonce validation. \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} @@ -1139,51 +1139,51 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, which is trivial and efficient since the trie is by nature an immutable data structure. \hypertarget{Phi}{}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \\ B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ -B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) +B^* & \equiv & B \quad \text{except:} \quad {\hyperlink{Transaction Receipt}{B^*_{\mathrm{r}}}} = \hyperlink{r}{r}(\hyperlink{Pi}{\Pi}(\Gamma(B), B)) \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. -As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. +As specified at the beginning of the present work, \hyperlink{Pi}{$\Pi$} is the state-transition function, which is defined in terms of \hyperlink{Omega}{$\Omega$}, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +\hyperlink{Transaction_Receipt}{As previously detailed}, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \hyperlink{Upsilon}{\Upsilon}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} \end{equation} -In the case of $B_{\mathbf{R}}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: +In the case of \hyperlink{Transaction_Receipt}{$B_{\mathbf{R}}[n]_{\mathrm{u}}$}, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} \mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} +\linkdest{Upsilon_pow_g2}\hyperlink{Upsilon_pow_g}{\Upsilon^{\mathrm{g}}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} -For $\mathbf{R}[n]_{\mathbf{l}}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. +For $\mathbf{R}[n]_{\mathbf{l}}$, we utilise the \hyperlink{Upsilon_pow_l}{$\Upsilon^\mathbf{l}$} function that we conveniently defined in the transaction execution function. \begin{equation} \mathbf{R}[n]_{\mathbf{l}} = \Upsilon^{\mathbf{l}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} -We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. +We define \hyperlink{Upsilon_pow_z}{$\mathbf{R}[n]_{\mathrm{z}}$} in a similar manner. \begin{equation} \mathbf{R}[n]_{\mathrm{z}} = \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} -\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: +\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\hyperlink{ell}{\ell}(\boldsymbol{\sigma})$: \begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} -Thus the complete block-transition mechanism, less $\mathtt{PoW}$, the proof-of-work function is defined. +Thus the complete block-transition mechanism is defined, except for $\mathtt{PoW}$, the proof-of-work function. \subsection{Mining Proof-of-Work} \label{ch:pow} From 80a17cde576b646ef875ccb0092b93d02d7566b4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 18:40:11 +1100 Subject: [PATCH 316/335] Remove an extra } --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 035001f7..532ac9fb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1135,7 +1135,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_{H}) = \varnothing \\ -\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small \hyperlink{trie}{TRIE}}}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small \hyperlink{trie}{TRIE}}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} From ee356233257027ee07066cc61f855044ff92c7cd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 9 Feb 2018 14:40:52 +1100 Subject: [PATCH 317/335] but isn't a common word --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index e4f0960f..79ddfc14 100644 --- a/Paper.tex +++ b/Paper.tex @@ -321,7 +321,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (which is not saying much, in that it isn't commonly used) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (but isn't a common word) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} From 0ef2548a32dd3f48e31618c445454cff78adf36c Mon Sep 17 00:00:00 2001 From: William Entriken Date: Mon, 12 Feb 2018 15:36:04 -0500 Subject: [PATCH 318/335] Use build/ directory for building --- build.sh | 11 ++++++----- travis_deploy.sh | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/build.sh b/build.sh index 7f8c44cf..d99ed8cc 100755 --- a/build.sh +++ b/build.sh @@ -16,8 +16,9 @@ fi echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ -bibtex Paper && \ -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex +mkdir build +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ +bibtex build/Paper && \ +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex diff --git a/travis_deploy.sh b/travis_deploy.sh index 766c275c..7a2e09df 100755 --- a/travis_deploy.sh +++ b/travis_deploy.sh @@ -12,7 +12,7 @@ echo "# Automatic build" > README.md echo "Built pdf from \`$SHA\`. See https://github.com/ethereum/yellowpaper/ for details." >> README.md echo "The generated pdf is here: https://ethereum.github.io/yellowpaper/paper.pdf" >> README.md echo '' > index.html -mv Paper.pdf paper.pdf +mv build/Paper.pdf paper.pdf git add -f README.md index.html paper.pdf git commit -m "Built pdf from {$SHA}." From 82abbd3cd60347957b915bfe06a9aa18448a39da Mon Sep 17 00:00:00 2001 From: William Entriken Date: Mon, 12 Feb 2018 16:00:22 -0500 Subject: [PATCH 319/335] Add option to build white paper --- Paper.tex | 10 ++++++---- build.sh | 18 ++++++++++++++++-- 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index d3be65e9..dae7a3ff 100644 --- a/Paper.tex +++ b/Paper.tex @@ -42,7 +42,10 @@ \usepackage[autostyle]{csquotes} \MakeOuterQuote{"} -\input{Version.tex} +% Default rendering options +\definecolor{pagecolor}{rgb}{1,0.98,0.9} +\def\YellowPaperVersionNumber{unknown revision} +\IfFileExists{Options.tex}{\input{Options.tex}} \newcommand{\hcancel}[1]{% \tikz[baseline=(tocancel.base)]{ @@ -51,7 +54,6 @@ }% }% -\definecolor{lightyellow}{rgb}{1,0.98,0.9} \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} @@ -59,7 +61,7 @@ \newcommand*\ie{i.e.\@\xspace} %\renewcommand{\itemhook}{\setlength{\topsep}{0pt} \setlength{\itemsep}{0pt}\setlength{\leftmargin}{15pt}} -\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium version \YellowPaperVersionNumber{}}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium version \YellowPaperVersionNumber}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Parity\\ @@ -67,7 +69,7 @@ } \begin{document} -\pagecolor{lightyellow} +\pagecolor{pagecolor} \begin{abstract} The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, with Bitcoin being one of the most notable ones. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. diff --git a/build.sh b/build.sh index 7f8c44cf..826428b0 100755 --- a/build.sh +++ b/build.sh @@ -1,19 +1,32 @@ #!/usr/bin/env bash +## +## Usage: build.sh [white] +## + + set -e +rm -rf Options.tex + if [ -d ".git" ]; then SHA=`git rev-parse --short --verify HEAD` DATE=`git show -s --format="%cd" --date=short HEAD` REV="$SHA - $DATE" +echo "\def\YellowPaperVersionNumber{$REV}" >> Options.tex + +fi + -else +if [ "$1" == "white" ]; then -REV="unknown revision" +echo "\definecolor{pagecolor}{rgb}{1,1,1}" >> Options.tex fi + + echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ @@ -21,3 +34,4 @@ bibtex Paper && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex +rm -rf Options.tex From 40b1618a6c0fe314cfdac85ecd8ddb83b6cbe8a8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 01:31:30 +0000 Subject: [PATCH 320/335] Update ommer footnote --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 79ddfc14..af07e53c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -321,7 +321,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (but isn't a common word) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is a gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} From 9f52e77909fa539d1b2a4a957cfdda56a83b8f98 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 01:50:21 +0000 Subject: [PATCH 321/335] Add a space --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2d426e56..f4a3bab1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,7 +2510,7 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. -\begin{tabu*} spread 0pt{X[l] X[c] X} \savetabu{col3} +\begin{tabu*} spread 0pt {X[l] X[c] X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule From af3eca9ccd3610542b2445cc2597256b449c5cf1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 01:54:20 +0000 Subject: [PATCH 322/335] Re-add removed line --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index f4a3bab1..4b480334 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,6 +2510,7 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +\section{List of mathematical symbols} \label{app:symbols} \begin{tabu*} spread 0pt {X[l] X[c] X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ From 4599ee48c8ad08272c2219da06b21cf5def9fdb2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 02:07:50 +0000 Subject: [PATCH 323/335] Remove maths in English --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 51d2a737..21b2f08d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -595,7 +595,7 @@ \subsection{Execution} where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. -The up-front cost $v_0$ is calculated as the transaction gas limit multiplied by the gas price, plus the transaction value: +The up-front cost $v_0$ is calculated as: \begin{equation} v_0 \equiv \hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}} \hyperlink{tx_gas_price_T__p}{T_{\mathrm{p}}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} \end{equation} From 5d6bd24767ced653edb5113df70c382c5025b6c1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 02:25:47 +0000 Subject: [PATCH 324/335] Fix an error --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 04ea35dd..06040a86 100644 --- a/Paper.tex +++ b/Paper.tex @@ -721,9 +721,9 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{p}} & \equiv & p \\ I_{\mathbf{d}} & \equiv & () \\ I_{\mathrm{s}} & \equiv & s \\ -I_{\mathrm{v}} & \equiv & v \\ +\hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & v \\ I_{\mathbf{b}} & \equiv & \mathbf{i} \\ -\hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & e \\ +I_{\mathrm{e}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} From 3356e1719163693dceada812dab9daa8a7b94b06 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 03:38:58 +0000 Subject: [PATCH 325/335] Delete an empty line --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a94c13a0..21211f8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1144,7 +1144,6 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \hypertarget{Phi}{}And finally we define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ - B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{\hyperlink{H__d}{H_{\mathrm{d}}}} \\ B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hyperlink{H_cancel_n}{\hcancel{n}}}, n, \mathbf{d}) \\ B^* & \equiv & B \quad \text{except:} \quad {\hyperlink{Transaction Receipt}{B^*_{\mathrm{r}}}} = \hyperlink{r}{r}(\hyperlink{Pi}{\Pi}(\Gamma(B), B)) From 7d0f1bc7fcb834a359d9e33a71c7d40afc380d85 Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 22:50:44 -0500 Subject: [PATCH 326/335] Fix the build, #583 --- build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.sh b/build.sh index b549e13d..c527bdda 100755 --- a/build.sh +++ b/build.sh @@ -29,7 +29,7 @@ fi echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex -mkdir build +mkdir -p build pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ bibtex build/Paper && \ pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ From 746590d2030103056472cb597251a3ab30e79ceb Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 21:11:11 -0500 Subject: [PATCH 327/335] Use serial comma --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 9556fc95..ad26a8c7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -90,7 +90,7 @@ \section{Introduction}\label{sec:introduction} \subsection{Driving Factors} \label{ch:driving} -There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another. This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience or corruption of existing legal systems. By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end. +There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another. This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience, or corruption of existing legal systems. By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end. Dealings in this proposed system would have several attributes not often found in the real world. The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter. Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in human-based systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake. From 556d87528b5e682e1a32b0452f95c0e3125a8b5a Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 21:30:54 -0500 Subject: [PATCH 328/335] Typos and grammar fixes --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index ad26a8c7..ff65fcd9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -503,7 +503,7 @@ \subsubsection{Block Header Validity} H'_{\mathrm{i}} &\equiv \max(H_{\mathrm{i}} - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 by \cite{EIP-649} and delayed and implemented earlier in EIP-2. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks by \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_{\mathrm{i}}$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 by \cite{EIP-649} and delayed and implemented earlier in EIP-2. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the denominator 9, in order to target the mean block time including uncle blocks by \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_{\mathrm{i}}$, which is obtained by subtracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. \hypertarget{block_gas_limit_H__l}{}The canonical gas limit $H_{\mathrm{l}}$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} @@ -525,7 +525,7 @@ \subsubsection{Block Header Validity} \end{equation} with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. -\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}\linkdest{H_cancel_n}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. +\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}\linkdest{H_cancel_n}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to prove that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. @@ -563,7 +563,7 @@ \section{Transaction Execution} \label{ch:transactions} \item The transaction is well-formed RLP, with no additional trailing bytes; \item the transaction signature is valid; \item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the \hyperlink{account_nonce}{sender account's current nonce}); -\item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; +\item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; and \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} @@ -1223,7 +1223,7 @@ \subsection{Data Feeds} The general pattern involves a single contract within Ethereum which, when given a message call, replies with some timely information concerning an external phenomenon. An example might be the local temperature of New York City. This would be implemented as a contract that returned that value of some known point in storage. Of course this point in storage must be maintained with the correct such temperature, and thus the second part of the pattern would be for an external server to run an Ethereum node, and immediately on discovery of a new block, creates a new valid transaction, sent to the contract, updating said value in storage. The contract's code would accept such updates only from the identity contained on said server. \subsection{Random Numbers} -Providing random numbers within a deterministic system is, naturally, an impossible task. However, we can approximate with pseudo-random numbers by utilising data which is generally unknowable at the time of transacting. Such data might include the block's hash, the block's timestamp and the block's beneficiary address. In order to make it hard for malicious miner to control those values, one should use the {\small BLOCKHASH} operation in order to use hashes of the previous 256 blocks as pseudo-random numbers. For a series of such numbers, a trivial solution would be to add some constant amount and hashing the result. +Providing random numbers within a deterministic system is, naturally, an impossible task. However, we can approximate with pseudo-random numbers by utilising data which is generally unknowable at the time of transacting. Such data might include the block's hash, the block's timestamp and the block's beneficiary address. In order to make it hard for malicious miners to control those values, one should use the {\small BLOCKHASH} operation in order to use hashes of the previous 256 blocks as pseudo-random numbers. For a series of such numbers, a trivial solution would be to add some constant amount and hashing the result. \section{Future Directions} \label{ch:future} @@ -1382,7 +1382,7 @@ \section{Hex-Prefix Encoding}\label{app:hexprefix} Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the second-lowest encoding the flag $t$. The low nibble of the first byte is zero in the case of an even number of nibbles and the first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining bytes. \section{Modified Merkle Patricia Tree}\label{app:trie}\hypertarget{trie}{} -The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32 byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. +The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32-byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. Formally, we assume the input value $\mathfrak{I}$, a set containing pairs of byte sequences: \begin{equation} @@ -2335,7 +2335,7 @@ \section{Genesis Block}\label{app:genesis}\hypertarget{Genesis_Block}{} \big( \big( 0_{256}, \mathtt{\tiny KEC}\big(\mathtt{\tiny RLP}\big( () \big)\big), 0_{160}, stateRoot, 0, 0, 0_{2048}, 2^{17}, 0, 0, 3141592, time, 0, 0_{256}, \mathtt{\tiny KEC}\big( (42) \big) \big), (), () \big) \end{equation} -Where $0_{256}$ refers to the parent hash, a 256-bit hash which is all zeroes; $0_{160}$ refers to the beneficiary address, a 160-bit hash which is all zeroes; $0_{2048}$ refers to the log bloom, 2048-bit of all zeros; $2^{17}$ refers to the difficulty; the transaction trie root, receipt trie root, gas used, block number and extradata are both $0$, being equivalent to the empty byte array. The sequences of both ommers and transactions are empty and represented by $()$. $\mathtt{\tiny KEC}\big( (42) \big)$ refers to the Keccak hash of a byte array of length one whose first and only byte is of value 42, used for the nonce. $\mathtt{\tiny KEC}\big(\mathtt{\tiny RLP}\big( () \big)\big)$ value refers to the hash of the ommer lists in RLP, both empty lists. +Where $0_{256}$ refers to the parent hash, a 256-bit hash which is all zeroes; $0_{160}$ refers to the beneficiary address, a 160-bit hash which is all zeroes; $0_{2048}$ refers to the log bloom, 2048-bit of all zeros; $2^{17}$ refers to the difficulty; the transaction trie root, receipt trie root, gas used, block number and extradata are both $0$, being equivalent to the empty byte array. The sequences of both ommers and transactions are empty and represented by $()$. $\mathtt{\tiny KEC}\big( (42) \big)$ refers to the Keccak hash of a byte array of length one whose first and only byte is of value 42, used for the nonce. $\mathtt{\tiny KEC}\big(\mathtt{\tiny RLP}\big( () \big)\big)$ value refers to the hash of the ommer list in RLP, both empty lists. The proof-of-concept series include a development premine, making the state root hash some value $stateRoot$. Also $time$ will be set to the initial timestamp of the genesis block. The latest documentation should be consulted for those values. @@ -2413,7 +2413,7 @@ \subsubsection{Cache} \begin{equation} n = \left\lfloor\frac{c_{size}}{J_{hashbytes}}\right\rfloor \end{equation} -The cache is calculated by performing $J_{cacherounds}$ rounds of the RandMemoHash algorithm to the inital cache $\mathbf{c'}$: +The cache is calculated by performing $J_{cacherounds}$ rounds of the RandMemoHash algorithm to the initial cache $\mathbf{c'}$: \begin{equation} \mathbf{c} = E_{cacherounds}(\mathbf{c'}, J_{cacherounds}) \end{equation} From c11ac358588776ef22ffa7326431e22f465de3ab Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 21:34:33 -0500 Subject: [PATCH 329/335] Standardize on "we" as the first-person author --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index ff65fcd9..52e348e3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -94,7 +94,7 @@ \subsection{Driving Factors} \label{ch:driving} Dealings in this proposed system would have several attributes not often found in the real world. The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter. Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in human-based systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake. -Overall, I wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about. +Overall, we wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about. \subsection{Previous Work} \label{ch:previous} @@ -171,13 +171,13 @@ \subsection{Which History?} \section{Conventions}\label{ch:conventions} -I use a number of typographical conventions for the formal notation, some of which are quite particular to the present work: +We use a number of typographical conventions for the formal notation, some of which are quite particular to the present work: The two sets of highly structured, `top-level', state values, are denoted with bold lowercase Greek letters. They fall into those of world-state, which are denoted $\boldsymbol{\sigma}$ (or a variant thereupon) and those of machine-state, $\boldsymbol{\mu}$. Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg \hyperlink{C__SSTORE}{$C_\text{SSTORE}$}, the cost function for the \hyperlink{SSTORE}{{\tiny SSTORE}} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg \hyperlink{C__SSTORE}{$C_\text{SSTORE}$}, the cost function for the \hyperlink{SSTORE}{{\tiny SSTORE}} operation. For specialised and possibly externally defined functions, we may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$}, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. @@ -191,11 +191,11 @@ \section{Conventions}\label{ch:conventions} In the case of the global state $\boldsymbol{\sigma}$, which is a sequence of accounts, themselves tuples, the square brackets are used to reference an individual account. -When considering variants of existing values, I follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, I may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. +When considering variants of existing values, we follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, we may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. When considering the use of existing functions, given a function $f$, the function \hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{$f^*$} denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +We define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -218,7 +218,7 @@ \subsection{World State} \label{ch:state} \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{c}}$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_{\mathrm{c}}$. \end{description} -Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: +Since we typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, we define a convenient equivalence: \begin{equation} \texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_{\mathbf{s}})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} @@ -1215,7 +1215,7 @@ \subsubsection{Ethash} \section{Implementing Contracts} -There are several patterns of contracts engineering that allow particular useful behaviours; two of these that I will briefly discuss are data feeds and random numbers. +There are several patterns of contracts engineering that allow particular useful behaviours; two of these that we will briefly discuss are data feeds and random numbers. \subsection{Data Feeds} A data feed contract is one which provides a single service: it gives access to information from the external world within Ethereum. The accuracy and timeliness of this information is not guaranteed and it is the task of a secondary contract author---the contract that utilises the data feed---to determine how much trust can be placed in any single data feed. @@ -1243,7 +1243,7 @@ \subsection{Scalability} \section{Conclusion} \label{ch:conclusion} -I have introduced, discussed and formally defined the protocol of Ethereum. Through this protocol the reader may implement a node on the Ethereum network and join others in a decentralised secure social operating system. Contracts may be authored in order to algorithmically specify and autonomously enforce rules of interaction. +We have introduced, discussed and formally defined the protocol of Ethereum. Through this protocol the reader may implement a node on the Ethereum network and join others in a decentralised secure social operating system. Contracts may be authored in order to algorithmically specify and autonomously enforce rules of interaction. \section{Acknowledgements} From 3e4ee16a1543522c6b383d97a81f2bda42e7f7ba Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 20:58:56 +1100 Subject: [PATCH 330/335] \hyperlink zhalt, hhalt --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 52e348e3..642b3a35 100644 --- a/Paper.tex +++ b/Paper.tex @@ -941,7 +941,7 @@ \subsection{Execution Overview} Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_{\mathrm{g}}$ from the resultant machine state $\boldsymbol{\mu}'$. -$X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either $Z$ becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until $H$ becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. +$X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either \hyperlink{zhalt}{$Z$} becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until \hyperlink{hhalt}{$H$} becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. \subsubsection{Machine State} The machine state $\boldsymbol{\mu}$ is defined as the tuple $(g, pc, \mathbf{m}, i, \mathbf{s})$ which are the gas available, the program counter $pc \in \mathbb{P}_{256}$ , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents $\boldsymbol{\mu}_{\mathbf{m}}$ are a series of zeroes of size $2^{256}$. From c02a7450d0dd1c663df6e9849ebe0a9f7458cc7a Mon Sep 17 00:00:00 2001 From: Alexandre Kurth Date: Fri, 16 Feb 2018 11:05:47 +0100 Subject: [PATCH 331/335] add french translation link --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 752018df..dff723eb 100644 --- a/README.md +++ b/README.md @@ -32,3 +32,4 @@ The previous protocol versions are listed in [BRANCHES.md](./BRANCHES.md). ### Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu. +- [French](https://github.com/asseth/yellowpaper) translated by Asseth (checkout to branch 'french' ). From 0f86e261e1b3db44f967608b332dd39de194bb7a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:07:01 +1100 Subject: [PATCH 332/335] \hyperlink{hhalt} zhalt --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 642b3a35..aa851044 100644 --- a/Paper.tex +++ b/Paper.tex @@ -909,7 +909,7 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an \hyperlink{zhalt}{exceptional halting} state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a \hyperlink{hhalt}{normal halting} state of the machine. +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions \hyperlink{zhalt}{$Z$} which determines if the present state is an \hyperlink{zhalt}{exceptional halting} state of the machine and \hyperlink{hhalt}{$H$}, specifying the output data of the instruction if and only if the present state is a \hyperlink{hhalt}{normal halting} state of the machine. \hypertarget{empty_sequence_vs_empty_set}{}The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} From ba09a5e45acdf52034614fe5935af5b7619ea34e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:46:54 +1100 Subject: [PATCH 333/335] \hyperlink{Gamma}{\Gamma} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 52e348e3..ea11511f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1157,7 +1157,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \hyperlink{Transaction_Receipt}{As previously detailed}, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \hyperlink{Upsilon}{\Upsilon}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \hyperlink{Gamma}{\Gamma}(B) & \text{if} \quad n < 0 \\ \hyperlink{Upsilon}{\Upsilon}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} \end{equation} In the case of \hyperlink{Transaction_Receipt}{$B_{\mathbf{R}}[n]_{\mathrm{u}}$}, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: From 15ed9942507128fcc0087c71f5d22f6e39c05003 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:52:03 +1100 Subject: [PATCH 334/335] \hyperlink{Omega}{\Omega} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 52e348e3..43e4a8e5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1181,9 +1181,9 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} -\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\hyperlink{ell}{\ell}(\boldsymbol{\sigma})$: +\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\hyperlink{Omega}{\Omega}$ applied to the final transaction's resultant state, $\hyperlink{ell}{\ell}(\boldsymbol{\sigma})$: \begin{equation} -\Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) +\Pi(\boldsymbol{\sigma}, B) \equiv \hyperlink{Omega}{\Omega}(B, \ell(\boldsymbol{\sigma})) \end{equation} Thus the complete block-transition mechanism is defined, except for $\mathtt{PoW}$, the proof-of-work function. From ccb9bd5dc822df0da4d1e266b495259cfec2c51b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 17 Feb 2018 00:17:56 +1100 Subject: [PATCH 335/335] I__e => I__w --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 06040a86..b9a20e87 100644 --- a/Paper.tex +++ b/Paper.tex @@ -891,7 +891,7 @@ \subsection{Execution Environment}\linkdest{exec_env} \item\linkdest{exec_machine_code_I__b}{}\linkdest{I__b} $I_{\mathbf{b}}$, the byte array that is the machine code to be executed. \item\linkdest{exec_block_header_I__H}{}\linkdest{I__H} $I_{\mathbf{H}}$, the block header of the present block. \item\linkdest{exec_call_or_create_depth_I__e}{}\linkdest{I__e} $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). -\item\linkdest{exec_permission_to_modify_state_I__w}{}\linkdest{I__e} $I_{\mathrm{w}}$, the permission to make modifications to the state. +\item\linkdest{exec_permission_to_modify_state_I__w}{}\linkdest{I__w} $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: