From eed80dd99ce80b309d5793fccab400021855a18e Mon Sep 17 00:00:00 2001 From: James Ray 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 e38cead54ea5c1cd3820582bcbb6e8a7d227c501 Mon Sep 17 00:00:00 2001 From: James Ray 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 2b8b183f42e36671e21c52a13d1fcec7575788e3 Mon Sep 17 00:00:00 2001 From: James Ray 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 8f41d30c9ac8e52a7cbec934bd5ce4be1e4d6498 Mon Sep 17 00:00:00 2001 From: James Ray 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 f36c33e85bf93ca467f3b45e413f088e15ba4729 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 80ac4674f23e9c287035d238af0ddd8975398506 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 4c7e1af8dee20cb84973b180464add67df919e76 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 7a11bfff65b152d1e17252ab259ae2b2a224a4e3 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 cf081330a2b87fc18f60691435e0e9c47c895425 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 ea499b08fad2c8a07695174f0588baad1be7317f 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 6ef3dde8f0efc824d95c2624ed42cd5275286dd2 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 d02530d370ec88644ee462978bce0c0b97338e2c 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 b9972e85c1d7b47141ced53bb3170d249f4a27cc 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 0738f84ddc31f941e6f46acce181b7903d78c12c 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 8a42a79f93d7c4c17d04908471a97c798d4422ba 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 abc9ecf0a28266cd67e7a723849e4db9cb52b5be 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 be99a2122af67e56d1e715c8bf926c8faaa58ba0 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 f6d12eff22666062cb1fea33773d19bac7f52e50 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 9a1ce0782ba2239f69f63a99314fe496d5bc0902 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 8360dfecf760755be2b07f840ea29464b63e3446 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 e3033f4f6b71fa80e5a93ca1b7f7d65f029eaa22 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 7aa00bda965f663d52fcdadb39dae65920d5549e 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 5b752a54485cae6c90a4bae2caf6b26d63504c3a 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 813f17a0bbf2b6129a337005f4327c0159123286 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 9df02c9d3a0afdff0460a18d184109ba253764da 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 43da5f725362b4e7bbc426a4adacd477242aa0cb 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 7b3eb6b0e086dbe4fdb1b786a9880790c626e83c 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 22dc0571bf31753c1d9061233b0b0ec4c7659507 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 b468190d2ffbdfcdad26942d093713633aa44dd5 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 fbe418c4efce33110d263e0ef45379c1db5cb9f9 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 5ae6974079a88ed6b38e888847e97d30d94e204e 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 e2baf887c86a86734adb15b37470e0007e2a1df9 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 b62e85316715ddf54132d2f92d68dcf9dcc35a91 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 2d89e913158d440bf2a610b8b8d2b95202580cba 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 342b6e24c49cba99fb4faee30b2089e300b3a4d8 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 7462ea21886501797d9a4e01bf743488ca5502e4 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 94461d5e2d4538a5c2a39e19cb97eda5bdaf0cef 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 1d1311c0b128ccc2aec81bc5b986980615a5a3e6 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 d88bc034be54f22ee0274383178d2959cdae4462 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 0e004d4df634c63b933b28c33c74aa74d03dadf5 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 e0c7fbb5451fd3f9da7d93f0231102cd6845d411 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 b99b51d903984fd573c5b26006bf18726cd818d0 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 dfe36bb258f21b9be51d6307db8d8e0935ffa1bd 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 005d1d3f37fb0d54dcb5aea0f2ea9d07e8c43dbf 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 f9aa891cfe714f2b0da68ba3ee88e6fa1dfddaca 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 46df7fa3eda4cabab39f2c15bc0cbd5ace647d65 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 28914abace586f91178ec1907cc598935e83fb71 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 f6bed1b9637f2ddf54fd417f3d2e59bce373d14c 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 d71f13977a1d1b2e56ea7a0d6590ec0788e3de41 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 b5ad4e8210321850a4be72d63122c3974c04f7af 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 fe638b0f109dc14275804758acd16cc67fca3bd2 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 83b51b83f20c2ee6ba6407c8a0824dd6f36a7901 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 598d123f222a7180f604f0f5aa22d7b6b25ee6d9 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 75afd2b551bdfb7e4eeb76b4c63b4f00da961f23 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 29892b487c1c84dc3382881e12df1a36e20cc5f7 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 c279c86ca0eebfe153ce1cc35a6e92a2aa4a8972 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 797e7f768862b7cfb04bebca6af46f3f4c6e56f2 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 6872f49caff3d9f67ec7e4c45ff36d61074c4d98 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 a6ab880ee5216a4a9622c48512477c635de676cb 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 acded14845efdaaad32d749079c1d02f2e2c95af 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 befe654a40fd42c103dfadc2f11add8cd87f4f21 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 a91781243c1a1eabf0c3f3275cc174788e384450 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 005cfce2a99049226516f496b4286593ec4ec0f5 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 97701669bd1e31f70dc39db4112d110cd6959ff5 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 d4d2dd4fc50f0512b8626055dc1bce35889345f4 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 71e11c21ac37bcf6fe3e581b44b5ef1b8a928ff9 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 2e9656186e85f5e19b43579d4b1c66574a3e67ca 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 c281bf7e3ed95b1195bd4702f5fa1d71aee6db87 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 1087c5b365167223e60044283daa9bd14717295b 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 e8d7f101b0aebf0359534d7334ace1d70c927f99 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 6a7bdab9afc58a72083b115fd74f381ceaaded5d 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 511160bea6fac6bf1c511f9acf39640c24f0b636 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 684e54a3cfdf081119bbace8734b50cf4575eac3 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 040bfab7a0864d49559e74cad7820a2715c6c6c8 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 6066b2d6e43281be849e0642499e2bcae62f50d9 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 db4fbb9f5075d71e674ed05b82b712f74de939fd 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 31713160f8516bf305be22ab66b79dfce87d7155 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 beb1b2282fdcc625b9287aca241263dee132c0f9 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 caad528e1823eff225b86b66876bc606549bde7e 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 29e4373eb64389f76c1583c2ca2fab2de8d15d12 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 9402e7b9f12d07b17451e7a9389e17e89ce6a71c 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 483f7870367fa2b438e763d4f250a1ec3bb2ca69 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 629a941dab7bdac1070bcce0e2312624f346302c 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 7a726a69f9b188593dc8755a2d32c3d2ff348e83 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 bc595c17f9e4915d7cf1530abf663d88e44634c6 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 d6c600dd264f88962d2a7daa4e61dca5ef929896 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 60ef67d36eb9ed77188c57d82ea51f7d0ca51b8a 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 f2008730d7326512a81955f3e1ab4a2b81137435 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 913e0b79c70067b37217c8f5ce4151e32ec35acd 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 7888cd0f6a07aa27f3b6e2c0be608e5e468bcb4c 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 66643a385f8af8b61f3f345e99ea2c5185d6a31d 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 6ed145abf2d8cf4b3e259da536951a323fb1b812 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 9862000868d9dfa6e38ea3b7fa863316c68ce195 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 b78a29f6f601ca92b9668f19aefa9a5e297489db 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 08752ca830ca381d3428d00a6cd4ed77bc5c650f 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 49ee0e29ce66b05b5fd10ac7d3757085f965e586 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 a7d1298d0cc6773928717e4b0a723ba1b382b553 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 b7a54234ff3601a204d889df88f837772a720026 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 811cc22f705a39503c95c5203156767dc1bac93a 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 9085d698a23c330019c3d8381f7fed0acadd9d55 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 054d3b995069e77570b7c4572670f2cd0491b458 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 e460d2010d72cc57bd68d5cd688b685483b5b593 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 f1ff1ae31e4e25f1e6652fcd08e6c872a0d6da63 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 5c729695e3cc77d18a994ca50bb88444342452b6 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 b71e5117c1dee4a3a91117823510ec284feb74d1 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 0e7dc24890cbe8909edb451508fa25ca3660688c 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 4d4364a8d2599c010a09262129ff3f9f2fa9d7a9 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 00593e9167bb1f4d635b9a7976169e414b4922b9 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 c57cb2e3a096032785bd48d2a599b63a3083a73f 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 ea47150d64710eb50b9b9c12f2237ae4bd193dcd 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 97a9fb94843e500c5926fac4c3b2b272da4b8fe3 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 d838ad903c0c63d08d17b9db534648f9e3bf2376 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 da82f550e11290408b0e1e3487b1c883221615f8 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 a727e5af45bd2632c04f24929b37ef8f148be3f5 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 70c4734e9d4c458a943829e355436260cd73e800 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 b5d96fe110bb791fe0e7f186b120fd3a499fcbf0 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 a2f3bce5f7a352946ed02062c0c76bf42f2a2b55 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 409079277d35fec6dae40638e5dc01c70be5d822 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 e195fe6be38d38cb04aa6b72abe1c67dea4b5b65 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 45d3ee56574cd2a1280d49ea0fdaac77fa187246 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 7f4c4fc0d8308b1f2b5adddbce9739fbb1a7001e 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 45f759f58ca723c5ea4de1940b14b239e6e37884 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 c3e747c9b7678ca33e372366b98f23b196bd2728 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 8a724088ad453b9eb597984d374935af6bf37da9 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 f01439d00b0661d5a7b5390466414fa550b4f51d 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 33fb0437ae3a5fdcbff856b9c6447d2add8895de 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 7c531c83e57ea5c01e6769e0add3299419e9695b 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 a7ad11ac5392e302ef001958a3fb95f94cea9824 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 450bc5a7e0ec8db671ceb400de1f1206e1e165f5 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 c1681143bb3e487e2b9691d440257f5de2be193a 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 e99c41896d6ad7782c84a12d17e673ac36a78a70 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 da16a1b160ee4c2971f0f9b0a9c3384a9c4aa2f9 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 1e92fa80fe5b92209cfc8f60122f639ec0ba18d9 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 70792a27ffd4e2f82becbce8c621a4d7d2415c33 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 ff98ad5d4117ec266f84c29eeb451528d7b3690d 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 ecb72b6d6a172edf3883392bd911025024943732 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 d225080facd05a455a17cdd0e9ae69bc6412896a 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 f5e5aecd5a46db685dde4799a803677f4507523b 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 2abf06406ee2cebb96586e83fa79d17382e14cc1 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 9a83f3dae06d76382c2082aab4f33b237f095371 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 63db9f6b087bed88257e39b94516b36c8597d3f2 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 4e412e3c7004e725f6ac3f163174b75c33485efc 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 72b50e3dc97ea614a2b34c871833a2ed813556ce 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 23bd272daa4cf898481e598a0b6419b051d4705e 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 313e8051daaec7029981587778a8a701a6a5c4e3 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 42e3445f99b6423642954ca6e947f1e0a8566871 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 4dfccf551de42196094a7fcf6b3b13ea2e740d1e 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 a5c738fb3e6f4e1d14482af7abff0faff94f75fb 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 33d4fb58e5722d5775b2d2e81d2a829789fc5321 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 2b2ab97e35e9e2b31392cff2392a17408c1c296c 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 7aa9d830e295ec7c8e30432feb8776c8802a76c0 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 5da8319290113ab019d52ff055bc6096b1f981f5 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 d68b614f9a46e41b7f085f98505327d385ad8f74 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 3f7d7668eda1f0e37780a969b0d5f5f146be3814 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 623d3520ca7c28e062e3db1adbf6fa19df44473b 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 8ee3571eeb8a44c82d69044915f0ff4682268315 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 b1c8a6bc09bcdf29f6868ea80a9fd5297e6b9238 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 0d6f7df5991c004fecb117ba16b59c1a3c105584 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 5dc7a5349d900bc38a3092061f205a90dbfb7059 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 d565dbccf6bb8f978ffc0176812efc5b6c1ae754 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 20c5a67a3ca31813eca3e13db5f5e06f1fe25c05 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 f6902c9a9edcd835e0230081f2aad029c857dd6d 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 4514ea6568aa274f12a312e9f9afbab2c770f303 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 220a9e77b2af154ecfd145fd22e3ff8bada46a7e 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 44421a3c32f747d4350138c4269c4cfa1a7474b3 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 94163ff073613a9dbf111140d01cec1cfc862642 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 090e9ee8e648a081ec77abb67ef821239339fede 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 e8cc77a7d5918327d2fa353761d1f39b905a63e6 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 57b0fd3c00760368b97f53a8dac60b2c62bfb082 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 ca26132ec85da3892673c4a88be452dd20c4c349 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 658750b8f7f8fcb09f0a3781a6d8152d334bd55b 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 5c12bd32e2c053470d7793db05fc81168b0e332d 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 4f95e9538013658bccd81f6e1bbdfb5cb56ba9ff 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 6a9b7919fa32b65cc399a19a030c8d29fd489ab3 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 4138c90089eff0578c8e1f507fd72ddbf490b77c 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 c362b186d0cbd9d986df1649e6d22aa5d90d5ce5 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 bbf2dde7c37578b0e2146464dfcdc658d1cdf3ef 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 98fe5bfe3e3dc12b2515ab4b93c915eb88a64940 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 770392e649abcf22f3e06e2fab605ff12a0cc662 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 e255ceb0a6bb803d7fd14ee995f49d7ac2d86bd1 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 d064c94fac9371415f2c4f6ca0f503a00f6b3406 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 981d894db47759dfef83a174199f56e9384bd76f 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 81bfb64d853860b4389dcd80ee93c0aee1c8ba6d 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 021cb944ca5e8ed5aa5d4aabfe79f723f8948a0c 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 e00f51c82166799d3ee1755711d01ba2d04d9b01 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 5953472df245a7f02dec3cf0ea4971de95782ac9 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 187a9361415779d2cae38b8e5365bdc150d8d181 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 e2fb0bf4c6796aec0cd490ac05f765d4a781a1ff 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 f0f06df993b9d766a4de838c1a44a66b1f0aba3c 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 76d221f7777df9a159f2eb04d8ebd9345b4885c4 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 238f0a90d63f6b3b481f2867322e49894609f718 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 6c901b741c12abff42d3bc191dc97826b8c8e870 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 57d36e13b5dbabf0dfc732db39e4d8ab81d07bcb 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 da1ca7f4bf825630cbaf7bef370434552e7670fc 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 9808a1674aa2caa8c342774b3c1e875b52e113db 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 534a1e46140556a705cd56f61f2fcc6658031cd9 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 9d307e760b8c283f52ecb39338adc94de167a624 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 07b34de880e9eae2d2f6adb04b53468d18422e87 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 b0aeeb1e34468966ebc26ce8a6173972164692e2 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 4299ab029146a3f17fe42da8f3e87ef6c813c4fb 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 fc702894736cfec82172c13aa4f66adfd9ae21fa 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 6c00c7420d1d404febeefee026d95440d3113dcc 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 7fa433e7dddccad29f4dee1aef651d846c0fb029 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 63ff7e0e70691dabb66f2f327889e88eb18a3d20 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 8cdd97bce60258856b1b80b101f7e1cecdbb2b25 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 f110bac0f928a907081eb4bee45c8d79c9ccf16a 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 3042a115880c22951aaad3c45f78bae4f78233f9 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 9301b6263b0e4131b426262a66dc169c2f7b06da 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 a314b3f31a498110c7cc434ed785b3e32e30b6b7 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 8aa3e96690758c7416dcf2698ce1b28c90fa97bb 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 35aa14dbee39853f4d5295b8f9a2fed0f5b7dadf 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 87edbc63b122ac46ec087bba53aef6cc5a442f6b 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 50e32f8fe2fc6e1a1b270ff0b694a992087c53fb 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 1c40cf2559c844ec2e6ae170ba6abae68d157830 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 b23eea8373fe04c062e0d510257e91b3444c78ca 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 118d6c9c1ea862d3514a0ec3a436abf54ee5af78 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 f5d12c18f9be18a8f9744f72732bda5a18295fa0 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 ed4800e43fb4c879d81461f14c89d468103af8af 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 4f7e91a935723e0b644f289aaa6ce3d4618cb3f8 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 aacb579cb176549b6759bee573a9a308d1ba43bd 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 638baeee5271c587f29362bb582befcb6b3d5523 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 5b60d755c1c08e7fb5b9f3dfdc869ec3320d3ffb 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 34b9991f4d4692a6da379208f6b7bbd12f65413c 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 9d5b043ddf8c896395ac9a7b769b57a54da45014 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 7266cc0eb3fa9947c4b79054887791d6382ed0dc 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 27af799767016acd3f6331d8a2bce51645dba4bc 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 d10c563fcd9bb4ee98c83b53148604409e8e8369 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 987b312e0d8124f89518d4ed530d9ccd2eb8c0ce 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 64c872e7453c9cb96413d299a44071e28efaaad1 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 0437001704de6b2f8cb0383342d65748c0e5e0c1 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 fc39122616b9598d0c500a7e2f1b8297d33afb64 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 58e57a22dcb9da11b7c17a82d795b89479e0e1e6 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 a9295a4b1f11f8d004d877bc60a8a09da9ac0e6b 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 ae699571b31dcfdf35fec9e88ec5a5e88a805c34 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 6dd2c6b12e454faf74b44c3485b971c43eda0c63 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 3d8ebd5f369f2c04f3560638f0827a85ff24f7cd 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 d8dcac64ff2055041a806a6cae76f10009e0f826 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 0d6d19d3459a2f65873de5fba48a664c4adce363 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 0773ff06480472cd6a106251e24247f18b7cd729 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 e790839f2a7fca8a22c7007392f4a944d0203315 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 e3fd37d763664ae3cbfd8ae2db25c7d862f0c470 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 17a6d0820fdf77a923e5e6db60aa60bd09ac6e92 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 26f862a5e5c493a3aea663ca6a5be5cbabe4e227 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 948a1a1ca8dab70df55dcd714b507c62756dd8e0 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 8c402d9e3786019de20eb229a5893c178e333554 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 09cbc4a783d1ec652fded90b1585583a1ec4db75 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 8dcb918280d412167432584c6df10b207bf7c70a 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 00f23f55ceea29d212d8eb7ef92863c5d805c129 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 dbc9c8729a91ee7c26e4e92520e74ec9d5089095 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 b62d2c04263a6c002f691fb9aa0fd61b67d749bb 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 43e29bd94e46f60c2de6accb90f098211586446e 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 1f0a75747b963885f56295656ed326b3272c0bd1 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 d15999334eb109379dc850cf67a91283beb033ab 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 0bede3ba042e6c0583d90c984b98b4cf5d0fae33 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 ca0799f19439c65531a87e56c4c395176d978fcd 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 ffb2fadbde9883f294c9b80f35350b428a13d254 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 fb75810761501103e85fc4d86cc17149016d1aee 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 2f2585932d2c3c903078d665bc68b4a1a1654de0 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 f0888522ace2af3069831699b74969b1210dab2e 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 3c67e2ca48b80da7c67418e1403ce1744fb85ceb 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 789062b4fb346b3392a5406199f6058667a98723 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 48e7684338eb845b6e7969602d440f4e7594fe85 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 8eeee4576bf2cef9750dfe963fa6bd530ed15cd3 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 e9ab994fef7e57e6f08c5ed425d9f0016868105a 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 b9a7ac29d84f690c8d939ee885c07d1bda5c55d1 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 791e2795a90d4c00f6e87f06a5e4751edb85db2d 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 9f7e1b60a031c3d159f5ca71716ea12cbecf8dea 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 f3c39fddd4f661e957c0c615fe42eca5115d9bf7 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 176e03bda268b0404cd3178ffc651a43a137283c 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 0a3da30cd4a50da89d4a4a5dacc00dba314be72d 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 ae491e40398854ece17ae6911c01bd5f8033a8c6 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 dd54dd0a26b3c1c5deeb3c78eebe9538a4d3a8ba 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 907a518402c0f05e0bdfb8dcd74d87ec139af4e5 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 75fd12ef347e4a3e93b68df8718c22b896c9a2be 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 ce27db00c22017e1ab7e257201343f2ef4c3fd34 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 1824bbd1706bc7c6fa9516e64457d5d79f74f423 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 c14924ab2cd0237130120ecc532e95fef6313ac9 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 e5e00e5cbe2410fae53432b2750b2f808ef8cd4e 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 8134dd1eaf85c96ca0bdee59d3d7b2ccffe0441b 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 c100ea338a908b4e7b4084507f78caad971f72a0 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 689ee02cf643bdc7e22bc8f38730e545dcb5dcd0 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 9fc0fe3f9d0430acd3d0ea7739a39a6044dcdff3 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 cec4fa394a5cc428e322b7920c5cb159df4b8702 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 3d80b5d3f9e44ec094fd490054c063e52eca81ac 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 5d2c444759a07f11cdaf538a89c8c4e3905778c8 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 0fbfa7020b5c26e731f12eeaffe99a09ee48dcd1 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 1667ddb9aea7ff43a7fdc277b19048984fe28770 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 f4bdf14540d37b85a8cd67a5d9925eae267ac1e0 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 6c5b89454ecd6cf27f23f996bd2c6479f5c3e12d 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 cf33546990d3e32a1776c93e7c903a3f24471c5e 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 d1906ce6a93de81f018c54b5b28232195a27868b 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 84cf2ebaff089ae64150531f839cdc2cd8f2bfe0 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 727c2ea8f94b30a1d1d15d077de7df4ad4d80464 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 fdac7dc5ff78c4fd75b4b3c8c42e77b254b26a7b 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 7c1401b69ab3d1b463e1c032afb3a6635409fb3a 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 b83b7431e4dc3710daf78eae54323207b9e2e7d3 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 ce3ae35c6ac5ca7fd9e7a9c9c4f54261a5269e44 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 162b5a0143203fc73a12fa3da32ebcc6602a1606 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 93050d3dea98f253871a3a8a1cee3df4b3c6beec 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 723f681b3c6aed4873e99267e1716b2f9c0db550 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 2b68b2bea6a8f2952321bd0f151c83b174a2bada 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 15d6481e513e9cb29639cc23c33acd32e21b87a7 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 d126c9856aa220e60bea506bae9fe46003bf599e 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 4659719cd965339b0b53543b47cbdeb70ac18e1a 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 8e19296a155b2b9a9df5de46e4b7f7ed76547fb1 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 1916a346d0a66c99888570044b3d534a84c8766c 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 7de5a2fe0d642caf835715e1cf566028fb100f80 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 cde833ebc36493d3943793adbd7f048211e21400 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 8f898efd5d57435897eed3d3c1522e00e0e7fe14 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 5cca3e0cab227b34d93582ae1048458439bab344 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 2e76a0baed7f0a683abc625d96311f71b48f08f4 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 0ad5cf9fe89b33f68cbc7878cb239e90e86a0a75 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 ccf75bbb74b54bae31365ed931fdf48bc0f90444 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 d409648263534f667ac099c72821a986bbc4d780 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 e354b74134a4c81673016cfc0a3a6e26ead5e730 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 3cc6cc92270291b6f58226038ad9827dd7618277 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 c177202adae1232f92e9cb0fc1eae9edef2c3820 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 7a9a385a4e89303a9351c27939cfa0c698628d0c 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 0bc24543c9b235c94210eda40a3d3ba381dff474 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 f42a178a656ee7ca6539f15c5054bd49301125e2 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 06c67bdd5b0ba56e6a99d2ffdee53e4c17e5da16 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 a3819fbe8c45fd75d20772e2b66b5ad7b0f09711 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 e1fd0afaacc32bca863e26ae088a0f54f44bce85 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 5955d43fd57fcd777c19314dc4a511858418e6aa 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 bb8a257ecbc84fa0cd706bf3a1127b050570818e 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 03b5be81024c173a24e6b0b44340b2cbe689b4c2 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 cc5724d294631c54578da704d6b2afa81d739204 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 3eb6afef17a4f682c31ad3c31a213cca6bc72d00 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 7dc670a107b6d5301903b2573c8e16492fe1eb1f 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 e653258d1f94c6a29ff1c2c5b43e191f535fba49 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 f6089a68fa768db666aea10762aea27d755a115d 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 ca7f9261f4dbfc73e9ea5d57f2bfea05174ce04b 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 37908f35fee1e4e22bc918fc5b134738d884b73c 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 9b7f0371d5d5a0390c484e3d9a06e53b50aebcdf 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: