From a65fa87d361822a8d5454233e85a934c42fc2ffd Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 16:04:31 +0200 Subject: [PATCH 001/460] CODECOPY updates the memory usage --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index fc1c300c..94d71811 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1750,6 +1750,7 @@ \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}[1])$ \\ \midrule 0x3a & {\small GASPRICE} & 0 & 1 & Get price of gas in current environment. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_p$ \\ From 402978085669c09edd68a852ff6d1b9f9c5c18e3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 16:08:23 +0200 Subject: [PATCH 002/460] CODECOPY and CALLDATACOPY update the memory usage --- Paper.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Paper.tex b/Paper.tex index 94d71811..ae492502 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1742,6 +1742,7 @@ \subsection{Instruction Set} 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}$\\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_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. \\ @@ -1763,6 +1764,7 @@ \subsection{Instruction Set} &&&& $\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}_s[0] \mod 2^{160}]_c$ \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ \bottomrule \end{tabular*} From 6bce3e6393dd09c158f734f5ff519af883cdb375 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Wed, 12 Oct 2016 15:29:41 +0100 Subject: [PATCH 003/460] Add link to README --- Paper.tex | 2 +- README.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 548342ec..2396e754 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1170,7 +1170,7 @@ \section{Conclusion} \label{ch:conclusion} \section{Acknowledgements} -Important maintenance, useful corrections and suggestions were provided by a number of others from the Ethereum DEV organisation and Ethereum community at large including Christoph Jentzsch, Gustav Simonsson, Aeron Buchanan, Pawe\l{} Bylica, Jutta Steiner, Nick Savers, Viktor Tr\'{o}n, Marko Simovic and, of course, Vitalik Buterin. +Important maintenance, useful corrections and suggestions were provided by a number of others from the Ethereum DEV organisation and Ethereum community at large including Christoph Jentzsch, Gustav Simonsson, Aeron Buchanan, Pawe\l{} Bylica, Jutta Steiner, Nick Savers, Viktor Tr\'{o}n, Marko Simovic, Yoichi Hirai, Giacomo Tazzari and, of course, Vitalik Buterin. \bibliography{Biblio} \bibliographystyle{plainnat} diff --git a/README.md b/README.md index fd57a332..6a29a0ef 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ [![Gitter](https://badges.gitter.im/ethereum/yellowpaper.svg)](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) -The paper comes as a single ``latex`` file ``Paper.tex``. +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at http://gavwood.com/Paper.pdf . It can be viewed in ``PDF`` format with ``pdflatex Paper.tex`` (local install of a current free tex distribution required). From 821a083200a8976faee20c01dad0f7bdf3f2a33c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 16:59:20 +0200 Subject: [PATCH 004/460] Split the instruction class W_{ext} into W_{extcode} and W_{extbal} --- Paper.tex | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2396e754..663ddfe4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1492,7 +1492,8 @@ \section{Fee Schedule}\label{app:fees} $G_{low}$ & 5 & Amount of gas to pay for operations of the set {\small $W_{low}$}. \\ $G_{mid}$ & 8 & Amount of gas to pay for operations of the set {\small $W_{mid}$}. \\ $G_{high}$ & 10 & Amount of gas to pay for operations of the set {\small $W_{high}$}. \\ -$G_{ext}$ & 20 & Amount of gas to pay for operations of the set {\small $W_{ext}$}. \\ +$G_{extcode}$ & 700 & Amount of gas to pay for operations of the set {\small $W_{extcode}$}. \\ +$G_{extbal}$ & 400 & Amount of gas to pay for operations of the set {\small $W_{extbal}$}. \\ $G_{sload}$ & 50 & Paid for a {\small SLOAD} operation. \\ $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. \\ @@ -1539,7 +1540,7 @@ \subsection{Gas Cost} 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_{ext} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ +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} \\ @@ -1556,7 +1557,8 @@ \subsection{Gas Cost} G_{low} & \text{if} \quad w \in W_{low}\\ G_{mid} & \text{if} \quad w \in W_{mid}\\ G_{high} & \text{if} \quad w \in W_{high}\\ -G_{ext} & \text{if} \quad w \in W_{ext} +G_{extcode} & \text{if} \quad w \in W_{extcode}\\ +G_{extbal} & \text{if} \quad w \in W_{extbal} \end{cases} \end{equation} \begin{equation} @@ -1584,7 +1586,9 @@ \subsection{Gas Cost} $W_{high}$ = \{{\small JUMPI}\} -$W_{ext}$ = \{{\small BALANCE}, {\small EXTCODESIZE}, {\small BLOCKHASH}\} +$W_{extcode}$ = \{{\small EXTCODESIZE}, {\small BLOCKHASH}\} + +$W_{extbal}$ = \{{\small BALANCE}\} 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. From 747acd6260ad94e92cbf5795f6e5887c9e00b372 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 17:11:00 +0200 Subject: [PATCH 005/460] Refactor the definition of BALANCE gas cost --- Paper.tex | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 663ddfe4..b382ec97 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1493,8 +1493,8 @@ \section{Fee Schedule}\label{app:fees} $G_{mid}$ & 8 & Amount of gas to pay for operations of the set {\small $W_{mid}$}. \\ $G_{high}$ & 10 & Amount of gas to pay for operations of the set {\small $W_{high}$}. \\ $G_{extcode}$ & 700 & Amount of gas to pay for operations of the set {\small $W_{extcode}$}. \\ -$G_{extbal}$ & 400 & Amount of gas to pay for operations of the set {\small $W_{extbal}$}. \\ -$G_{sload}$ & 50 & Paid for a {\small SLOAD} operation. \\ +$G_{balance}$ & 400 & Amount of gas to pay for a {\small BALANCE} operation. \\ +$G_{sload}$ & 200 & Paid for a {\small SLOAD} operation. \\ $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. \\ @@ -1558,7 +1558,7 @@ \subsection{Gas Cost} G_{mid} & \text{if} \quad w \in W_{mid}\\ G_{high} & \text{if} \quad w \in W_{high}\\ G_{extcode} & \text{if} \quad w \in W_{extcode}\\ -G_{extbal} & \text{if} \quad w \in W_{extbal} +G_{balance} & \text{if} \quad w = \text{\small BALANCE} \end{cases} \end{equation} \begin{equation} @@ -1588,8 +1588,6 @@ \subsection{Gas Cost} $W_{extcode}$ = \{{\small EXTCODESIZE}, {\small BLOCKHASH}\} -$W_{extbal}$ = \{{\small BALANCE}\} - 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. 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. From 60499ebebf23b25639900172bcde27812794d84e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 17:02:54 +0200 Subject: [PATCH 006/460] Change the basic gas cost of CALL, CALLCODE and DELEGATECALL to 700 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b382ec97..96d0d157 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1502,7 +1502,7 @@ \section{Fee Schedule}\label{app:fees} $R_{suicide}$ & 24000 & Refund given (added into refund counter) for suiciding an account. \\ $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_{call}$ & 40 & Paid for a {\small CALL} operation. \\ +$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_{callnewaccount}$ & 25000 & Paid for a {\small CALL} operation to a not previously existing account. \\ From 41e31d9d8f52397642141bbabaad42641f40bf00 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 17:09:41 +0200 Subject: [PATCH 007/460] Increase the gas cost of SUICIDE to 5000 --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 96d0d157..57cc3056 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1500,6 +1500,7 @@ \section{Fee Schedule}\label{app:fees} $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_{suicide}$ & 24000 & Refund given (added into refund counter) for suiciding an account. \\ +$G_{suicide}$ & 5000 & Amount of gas to pay for a {\small SUICIDE} 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_{call}$ & 700 & Paid for a {\small CALL} operation. \\ @@ -1547,6 +1548,7 @@ \subsection{Gas Cost} 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} \\ +G_{suicide} & \text{if} \quad w = \text{\small SUICIDE} \\ G_{create} & \text{if} \quad w = \text{\small CREATE}\\ G_{sha3}+G_{sha3word} \lceil \mathbf{s}[1] \div 32 \rceil & \text{if} \quad w = \text{\small SHA3}\\ G_{jumpdest} & \text{if} \quad w = \text{\small JUMPDEST}\\ @@ -1574,7 +1576,7 @@ \subsection{Gas Cost} with $C_\text{\tiny CALL}$ and $C_\text{\tiny SSTORE}$ as specified in the appropriate section below. We define the following subsets of instructions: -$W_{zero}$ = \{{\small STOP}, {\small SUICIDE}, {\small RETURN}\} +$W_{zero}$ = \{{\small STOP}, {\small RETURN}\} $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}\} From 540059e6c70aaf9ae75ce3318bbf5ec82221ef5b Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 18:04:01 +0200 Subject: [PATCH 008/460] When CALL gets a too big gas argument, it tries to cap the argument --- Paper.tex | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 57cc3056..0d8a7b04 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1976,7 +1976,17 @@ \subsection{Instruction Set} &&&& 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. \\ -&&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + \boldsymbol{\mu}_\mathbf{s}[0] + C_{\text{\tiny CALLXFER}}(\boldsymbol{\mu}) + C_{\text{\tiny CALLNEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ +&&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ +&&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} +\end{cases}$ \\ +&&&& $C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +\boldsymbol{\mu}_g - C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad \boldsymbol{\mu}_g < C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + \boldsymbol{\mu}_{\mathbf{s}}[0] \;\wedge \\ +&\quad\quad \boldsymbol{\mu}_g \ge C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ +\boldsymbol{\mu}_{\mathbf{s}}[0] & \text{otherwise} +\end{cases}$\\ +&&&& $C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + C_{\text{\tiny CALLXFER}}(\boldsymbol{\mu}) + C_{\text{\tiny CALLNEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$\\ &&&& $C_{\text{\tiny CALLXFER}}(\boldsymbol{\mu}) \equiv \begin{cases} G_{callvalue} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ 0 & \text{otherwise} @@ -1985,10 +1995,6 @@ \subsection{Instruction Set} G_{callnewaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}) \equiv \begin{cases} -\boldsymbol{\mu}_\mathbf{s}[0] + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ -\boldsymbol{\mu}_\mathbf{s}[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: \\ From dab13dcd7d336051caedbadae1ad5f5800bb2afb Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 18:22:11 +0200 Subject: [PATCH 009/460] The gas cost of CALL is capped at all but one 64th --- Paper.tex | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 0d8a7b04..c20b6f42 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1605,6 +1605,12 @@ \subsection{Gas Cost} \end{cases} \end{equation} +Another useful function is ``all but one 64th'' function~$L$ defined as: + +\begin{equation} +L(n) \equiv n - \lfloor n / 64 \rfloor +\end{equation} + \subsection{Instruction Set} As previously specified in section \ref{ch:model}, these definitions take place in the final context there. In particular we assume $O$ is the EVM state-progression function and define the terms pertaining to the next cycle's state $(\boldsymbol{\sigma}', \boldsymbol{\mu}')$ such that: @@ -1982,7 +1988,7 @@ \subsection{Instruction Set} C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -\boldsymbol{\mu}_g - C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad \boldsymbol{\mu}_g < C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + \boldsymbol{\mu}_{\mathbf{s}}[0] \;\wedge \\ +L(\boldsymbol{\mu}_g - C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})) & \text{if} \quad L(\boldsymbol{\mu}_g - C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})) < \boldsymbol{\mu}_{\mathbf{s}}[0] \;\wedge \\ &\quad\quad \boldsymbol{\mu}_g \ge C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ \boldsymbol{\mu}_{\mathbf{s}}[0] & \text{otherwise} \end{cases}$\\ From 2f3915ab0500aeb6286af44b7f245f1a5ca19429 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 18:30:16 +0200 Subject: [PATCH 010/460] CREATE only provides all but one 64th of the parent gas --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c20b6f42..9e6b40e7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1955,7 +1955,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, \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) & \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 implies: $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 b57a147cac87f9b0b7fdda5eda409e5e941fa2ae Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 12 Oct 2016 18:38:43 +0200 Subject: [PATCH 011/460] SUICIDE takes more fee if the recipient is empty --- Paper.tex | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9e6b40e7..48b39c9f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1548,7 +1548,7 @@ \subsection{Gas Cost} 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} \\ -G_{suicide} & \text{if} \quad w = \text{\small SUICIDE} \\ +C_\text{\tiny SUICIDE}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SUICIDE} \\ G_{create} & \text{if} \quad w = \text{\small CREATE}\\ G_{sha3}+G_{sha3word} \lceil \mathbf{s}[1] \div 32 \rceil & \text{if} \quad w = \text{\small SHA3}\\ G_{jumpdest} & \text{if} \quad w = \text{\small JUMPDEST}\\ @@ -1574,7 +1574,7 @@ \subsection{Gas Cost} C_{memory}(a) \equiv G_{memory} \cdot a + \Big\lfloor \dfrac{a^2}{512} \Big\rfloor \end{equation} -with $C_\text{\tiny CALL}$ and $C_\text{\tiny SSTORE}$ as specified in the appropriate section below. We define the following subsets of instructions: +with $C_\text{\tiny CALL}$, $C_\text{\tiny SUICIDE}$ 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}\} @@ -2038,6 +2038,10 @@ \subsection{Instruction Set} R_{suicide} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $C_{\text{\tiny SUICIDE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +G_{suicide} + G_{callnewaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ +G_{suicide} & \text{otherwise} +\end{cases}$ \\ \bottomrule \end{tabular*} From 3b4e1a3f029cd6f08ca2e70b6a110da457a4ba58 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Sat, 15 Oct 2016 14:18:07 +0200 Subject: [PATCH 012/460] Fixes and improvements to EIP-150 spec - Condense and simplify the `CALL` gas costs. - Correct `BLOCKHASH` gas cost. --- Paper.tex | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/Paper.tex b/Paper.tex index 48b39c9f..47854b9a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1152,7 +1152,7 @@ \section{Future Directions} \label{ch:future} The state database won't be forced to maintain all past state trie structures into the future. It should maintain an age for each node and eventually discard nodes that are neither recent enough nor checkpoints; checkpoints, or a set of nodes in the database that allow a particular block's state trie to be traversed, could be used to place a maximum limit on the amount of computation needed in order to retrieve any state throughout the blockchain. -Blockchain consolidation could be used in order to reduce the amount of blocks a client would need to download to act as a full, mining, node. A compressed archive of the trie structure at given points in time (perhaps one in every 10000th block) could be maintained by the peer network, effectively recasting the genesis block. This would reduce the amount to be downloaded to a single archive plus a hard maximum limit of blocks. +Blockchain consolidation could be used in order to reduce the amount of blocks a client would need to download to act as a full, mining, node. A compressed archive of the trie structure at given points in time (perhaps one in every 10,000th block) could be maintained by the peer network, effectively recasting the genesis block. This would reduce the amount to be downloaded to a single archive plus a hard maximum limit of blocks. Finally, blockchain compression could perhaps be conducted: nodes in state trie that haven't sent/received a transaction in some constant amount of blocks could be thrown out, reducing both Ether-leakage and the growth of the state database. @@ -1170,7 +1170,7 @@ \section{Conclusion} \label{ch:conclusion} \section{Acknowledgements} -Important maintenance, useful corrections and suggestions were provided by a number of others from the Ethereum DEV organisation and Ethereum community at large including Christoph Jentzsch, Gustav Simonsson, Aeron Buchanan, Pawe\l{} Bylica, Jutta Steiner, Nick Savers, Viktor Tr\'{o}n, Marko Simovic, Yoichi Hirai, Giacomo Tazzari and, of course, Vitalik Buterin. +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. \bibliography{Biblio} \bibliographystyle{plainnat} @@ -1520,6 +1520,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3}$ & 30 & Paid for each {\small SHA3} operation. \\ $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. \\ %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 @@ -1536,7 +1537,7 @@ \subsection{Gas Cost} The general gas cost function, $C$, is defined as: \begin{equation} -C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \equiv C_{memory}(\boldsymbol{\mu}'_i)-C_{memory}(\boldsymbol{\mu}_i) + \begin{cases} +C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \equiv C_{mem}(\boldsymbol{\mu}'_i)-C_{mem}(\boldsymbol{\mu}_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 \\ @@ -1560,7 +1561,8 @@ \subsection{Gas Cost} G_{mid} & \text{if} \quad w \in W_{mid}\\ G_{high} & \text{if} \quad w \in W_{high}\\ G_{extcode} & \text{if} \quad w \in W_{extcode}\\ -G_{balance} & \text{if} \quad w = \text{\small BALANCE} +G_{balance} & \text{if} \quad w = \text{\small BALANCE}\\ +G_{blockhash} & \text{if} \quad w = \text{\small BLOCKHASH}\\ \end{cases} \end{equation} \begin{equation} @@ -1571,7 +1573,7 @@ \subsection{Gas Cost} where: \begin{equation} -C_{memory}(a) \equiv G_{memory} \cdot a + \Big\lfloor \dfrac{a^2}{512} \Big\rfloor +C_{mem}(a) \equiv G_{memory} \cdot a + \Big\lfloor \dfrac{a^2}{512} \Big\rfloor \end{equation} with $C_\text{\tiny CALL}$, $C_\text{\tiny SUICIDE}$ and $C_\text{\tiny SSTORE}$ as specified in the appropriate section below. We define the following subsets of instructions: @@ -1588,13 +1590,13 @@ \subsection{Gas Cost} $W_{high}$ = \{{\small JUMPI}\} -$W_{extcode}$ = \{{\small EXTCODESIZE}, {\small BLOCKHASH}\} +$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. 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. -Note also that $C_{memory}$ 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. +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. While defining the instruction set, we defined the memory-expansion for range function, $M$, thus: @@ -1982,22 +1984,21 @@ \subsection{Instruction Set} &&&& 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. \\ -&&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ +&&&& $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 GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ -C_{\text{\tiny GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} +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 GASCAPPED}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -L(\boldsymbol{\mu}_g - C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})) & \text{if} \quad L(\boldsymbol{\mu}_g - C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})) < \boldsymbol{\mu}_{\mathbf{s}}[0] \;\wedge \\ -&\quad\quad \boldsymbol{\mu}_g \ge C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ +&&&& $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})\\ \boldsymbol{\mu}_{\mathbf{s}}[0] & \text{otherwise} \end{cases}$\\ -&&&& $C_{\text{\tiny CALLEXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + C_{\text{\tiny CALLXFER}}(\boldsymbol{\mu}) + C_{\text{\tiny CALLNEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$\\ -&&&& $C_{\text{\tiny CALLXFER}}(\boldsymbol{\mu}) \equiv \begin{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 \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $C_{\text{\tiny CALLNEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +&&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{callnewaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ 0 & \text{otherwise} \end{cases}$ \\ From fd1a018656971a123b1bcea54af6d0aaeb3b080f Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Sat, 15 Oct 2016 14:21:20 +0200 Subject: [PATCH 013/460] Update revision. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 47854b9a..79f70540 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{Homestead revision}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-150 revision}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ From 48c969720c241d47eff96e80290fcc07d13c29d9 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Sat, 15 Oct 2016 14:31:50 +0200 Subject: [PATCH 014/460] Cleanup `SUICIDE` instruction. --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 79f70540..ce2770bf 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1506,7 +1506,7 @@ \section{Fee Schedule}\label{app:fees} $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_{callnewaccount}$ & 25000 & Paid for a {\small CALL} operation to a not previously existing account. \\ +$G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SUICIDE} operation which creates an account. \\ $G_{exp}$ & 10 & Partial payment for an {\small EXP} operation. \\ $G_{expbyte}$ & 10 & 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. \\ @@ -1999,7 +1999,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{callnewaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ +G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule @@ -2039,9 +2039,9 @@ \subsection{Instruction Set} R_{suicide} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $C_{\text{\tiny SUICIDE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{suicide} + G_{callnewaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ -G_{suicide} & \text{otherwise} +&&&& $C_{\text{\tiny SUICIDE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{suicide} + \begin{cases} +G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ +0 & \text{otherwise} \end{cases}$ \\ \bottomrule \end{tabular*} From d92070dd99d137b88856feff341fa540fdb8842c Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Fri, 25 Nov 2016 18:24:51 +0100 Subject: [PATCH 015/460] Update link --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 6a29a0ef..80198adc 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ [![Gitter](https://badges.gitter.im/ethereum/yellowpaper.svg)](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at http://gavwood.com/Paper.pdf . +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at http://paper.gavwood.com . It can be viewed in ``PDF`` format with ``pdflatex Paper.tex`` (local install of a current free tex distribution required). From 5dff5f0bf4c9ac0b3c83805a78cb7957c25a7aeb Mon Sep 17 00:00:00 2001 From: Johannes Date: Fri, 2 Dec 2016 12:08:19 +0100 Subject: [PATCH 016/460] small typo (#196) --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index ce2770bf..6c0cd84b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1673,21 +1673,21 @@ \subsection{Instruction Set} \toprule \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 comparision. \\ +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}$ \\ \midrule -0x11 & {\small GT} & 2 & 1 & Greater-than comparision. \\ +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}$ \\ \midrule -0x12 & {\small SLT} & 2 & 1 & Signed less-than comparision. \\ +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}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule -0x13 & {\small SGT} & 2 & 1 & Signed greater-than comparision. \\ +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}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule -0x14 & {\small EQ} & 2 & 1 & Equality comparision. \\ +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}$ \\ \midrule 0x15 & {\small ISZERO} & 1 & 1 & Simple not operator. \\ From f1afa83d7525cd8687e14ba3d895c75e7cd8761e Mon Sep 17 00:00:00 2001 From: Gustav Simonsson Date: Thu, 15 Dec 2016 14:39:20 +0100 Subject: [PATCH 017/460] correct secp256k1n off-by-one for homestead blocks --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6c0cd84b..6540f615 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1438,7 +1438,7 @@ \section{Signing Transactions}\label{app:signing} 0 < r &< \mathtt{\tiny secp256k1n} \\ 0 < s &< \begin{dcases} \mathtt{\tiny secp256k1n} & \text{if} \quad H_i < \firsthomesteadblock \\ -\mathtt{\tiny secp256k1n} \div 2 & \text{otherwise} \\ +\mathtt{\tiny secp256k1n} \div 2 + 1 & \text{otherwise} \\ \end{dcases} \\ v &\in \{27,28\} \end{align} From 58369ec81d12b9f95db241994c45af3f138ecd14 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 22 Dec 2016 15:53:01 +0100 Subject: [PATCH 018/460] Decument the memory usage update in LOG operations --- Paper.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Paper.tex b/Paper.tex index 6c0cd84b..11c6a047 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1936,6 +1936,8 @@ \subsection{Instruction Set} \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}{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} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xa0 & {\small LOG0} & 2 & 0 & Append log record with no topics. \\ From cd8c1f71c6bffc37db215207760a09f06b06587c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 23 Dec 2016 11:38:55 +0100 Subject: [PATCH 019/460] CODECOPY read position calculation does not use modulo --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 6c0cd84b..db5f5382 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1764,6 +1764,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{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}[1])$ \\ +&&&& 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$ \\ From bb5dce05f56e29da587c81fe2add66ea562b4bce Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 23 Dec 2016 11:39:18 +0100 Subject: [PATCH 020/460] EXTCODECOPY read position calculation does not use modulo --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index db5f5382..cee1d1fb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1778,6 +1778,7 @@ \subsection{Instruction Set} \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}_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. \\ \bottomrule \end{tabular*} From f8b12d154eb8e0df32ccdfb48639080ca85f28eb Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 23 Dec 2016 13:42:44 +0100 Subject: [PATCH 021/460] The read position of CALLDATACOPY is not calculated modulo (#204) The VMtest case calldatacopy_DataIndexTooHigh suggests this behavior. --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 6c0cd84b..569f49cd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1754,6 +1754,7 @@ \subsection{Instruction Set} 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}'_i \equiv M(\boldsymbol{\mu}_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 From 134b8ee11c7a893dd49348f53e8beb9a1d1fa479 Mon Sep 17 00:00:00 2001 From: gregor Date: Fri, 30 Dec 2016 10:18:23 +0100 Subject: [PATCH 022/460] TYPO: Add missing it --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7d5654fe..3dce8097 100644 --- a/Paper.tex +++ b/Paper.tex @@ -241,7 +241,7 @@ \subsection{Homestead} \label{ch:homestead} \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 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: \begin{description} \item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$. From 5f0851d18836554b9be71181d33d83eb01e581e0 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 10 Jan 2017 15:43:58 +0100 Subject: [PATCH 023/460] Add the first Travis YML file that builds Paper.pdf --- .travis.yml | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 .travis.yml diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 00000000..2231904b --- /dev/null +++ b/.travis.yml @@ -0,0 +1,10 @@ +sudo: required +before_install: +- sudo apt-get -qq update +- sudo apt-get install texlive texlive-latex3 +script: +- 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 From 53f1de6db04465cee1596bd0d640a4c1dcb3e3fe Mon Sep 17 00:00:00 2001 From: chriseth Date: Wed, 11 Jan 2017 15:07:46 +0100 Subject: [PATCH 024/460] Deploy pdf from travis. --- .travis.yml | 12 ++++++++++++ README.md | 2 +- deploykey.enc | Bin 0 -> 1680 bytes travis_deploy.sh | 28 ++++++++++++++++++++++++++++ 4 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 deploykey.enc create mode 100755 travis_deploy.sh diff --git a/.travis.yml b/.travis.yml index 2231904b..0389dd82 100644 --- a/.travis.yml +++ b/.travis.yml @@ -8,3 +8,15 @@ script: - pdflatex -interaction=errorstopmode -halt-on-error Paper.tex - pdflatex -interaction=errorstopmode -halt-on-error Paper.tex - pdflatex -interaction=errorstopmode -halt-on-error Paper.tex +deploy: + provider: script + script: ./travis_deploy.sh + skip_cleanup: true + on: + branch: master +env: + global: + - ENCRYPTION_LABEL="19a81de38b62" + - COMMIT_AUTHOR_EMAIL="chris@ethereum.org" + - COMMIT_AUTHOR="Travis CI" + - PUSH_REPO="git@github.com:ethereum/yellowpaper.git" diff --git a/README.md b/README.md index 80198adc..a3f23746 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ [![Gitter](https://badges.gitter.im/ethereum/yellowpaper.svg)](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at http://paper.gavwood.com . +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 . It can be viewed in ``PDF`` format with ``pdflatex Paper.tex`` (local install of a current free tex distribution required). diff --git a/deploykey.enc b/deploykey.enc new file mode 100644 index 0000000000000000000000000000000000000000..bc9eb1cbfd21ee7702e91490148d60f0d3c37586 GIT binary patch literal 1680 zcmV;B25Nao+dVF_3g<=p6`sR8>ienWYRhh& zhafL3Ok^Jth79?M<^B`NDJp$la%JJA3)Nd8j)cTPK21X>!_RQ1dw_DA@QNCsCKUyM zWA2fob@NE?h}5U&^cV#aOkk#1Ht{3cZtB>qjh+A2oIc$NL_fp@bn6sE^$gEIi;TXi zIfG7x%s~BzU|5!FKE{zbtl2rN9uqf04e%5h3UG*>8Or=|6eCwijFvk#b_GI5f9(2X zRl$<})p)i%cP&Hk6fdIcbVL)lP;F4Tw$^Y+M3Sv?dpwU0WApTeA;Np}QLjCUB5B>% z1yh4D9t9d2&Kdqm`n~#8c*i1HC8}#IJ0XUvHP!7(d$jK_T*v$U>`eTF1#kIv!dCeXfJiaj;{s^}5h;pn@7|?rF6+Jo_W^+cvt#2A5wrz>bu>bF0V$!GC zDygl`l&u8WnT0|A#B&|yDoa7BhG~LbMYB&0MKYi9%-7o1J8v%z4=>p>0v&LD+ToRD z=;^9ON1_-B`EbV|K(cfgk&TzO)c0|h=wu|#|GnF?m1IrDdNw~eqJ@8r?&f5VIzTt6 zMD^_%;pUB85+Wb%^RLCt{Q%*}DWy_7f6T~i&qh*)jZB+Fktqv>ODsN%RarUP`IZmw z#WNeO>_!K7GDeXGn}p{4u%%);+Dn+$=mJnyCI(zY#yyI#>oeQZ39z; zdre{VJP8JR(@1GL0Zdv$XbLcwCy+C3*Y)1Rw`(%lt=B{11^ycMz0HN}@p%Px$3DLU z(siy%Rjb7&Ni5C#WYuoP8*LFq#0k)o;{Lu?&=#!@rW`9b0!4Qs7?_#4h=*m8$-UBk;1uxzrqv>ZnfJClZ6H83!EE1X`~yS$z=PqSvkebt}RIjwr>>FM zD~YcpFsYI~E0%n4Kd(5f1~%;@u1fpYzM)qfL(<=XbZvnbVC<(4)H#f)%b{t=K-7gt zcEJY{t*YZe6El|*#^T$5=>YRN$ay7mw598H#$?5+Dl9H5bdpHI>2!LA{bf$Vx#4hz z@LD~g3Zsu=nsbM{&kWqpOS=`96oR{QIc#{jFgkP|bEP~WL3QIz-NoZnY?^iJbe}Ii zMbXEJ`5IB7y1g$|=Q0m~jY9+_alGbwAiEhY9~n2#s8@7Nc)_kqG+l-JM3e(fZ%IEP z8`&_TiwBQ&GNG*4bC2k!0Cb<8KfbJ0B#gMfS?Rrb`M7a33$k0W;KcB-e_#H3>YyF% z>8B^;1|zTm04MGdm8HKJteGpnd5s2uwJ)}T{o{pDEL(PlX*J1r*gViS&g`bPA>cst zTFq3d5>)D|&-BGlquwfg3AG+2)EvY%{z!O{k3=sNd18~KoybChOv-D? 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 +git add -f README.md index.html paper.pdf +git commit -m "Built pdf from {$SHA}." + +ENCRYPTED_KEY_VAR="encrypted_${ENCRYPTION_LABEL}_key" +ENCRYPTED_IV_VAR="encrypted_${ENCRYPTION_LABEL}_iv" +ENCRYPTED_KEY=${!ENCRYPTED_KEY_VAR} +ENCRYPTED_IV=${!ENCRYPTED_IV_VAR} +openssl aes-256-cbc -K $ENCRYPTED_KEY -iv $ENCRYPTED_IV -in deploykey.enc -out deploykey -d +chmod 600 deploykey +eval `ssh-agent -s` +ssh-add deploykey + +git push -f "$PUSH_REPO" gh-pages From 8e46f524610d35e10a9549c0cc92c5e2244ce864 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 02:23:30 +0000 Subject: [PATCH 025/460] Include a section with links to the Github repo --- Paper.tex | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Paper.tex b/Paper.tex index 9fb28b67..71bd2992 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1173,6 +1173,10 @@ \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. +\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} From ff9c3487a6f9992ed962e23bc8100fc9a6a10a98 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 02:53:36 +0000 Subject: [PATCH 026/460] Fix typos: intial to initial --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9fb28b67..ac354c50 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2062,7 +2062,7 @@ \section{Genesis Block}\label{app:genesis} 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. -The proof-of-concept series include a development premine, making the state root hash some value $stateRoot$. Also $time$ will be set to the intial timestamp of the genesis block. The latest documentation should be consulted for those values. +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. \section{Ethash}\label{app:ethash} \subsection{Definitions} @@ -2122,9 +2122,9 @@ \subsubsection{Seed hash} With $\mathbf{0}_{32}$ being 32 bytes of zeros. \subsubsection{Cache} -The cache production process involves using the seed hash to first sequentially filling up $c_{size}$ bytes of memory, then performing $J_{cacherounds}$ passes of the RandMemoHash algorithm created by \cite{lerner2014randmemohash}. The intial cache $\mathbf{c'}$, being an array of arrays of single bytes, will be constructed as follows. +The cache production process involves using the seed hash to first sequentially filling up $c_{size}$ bytes of memory, then performing $J_{cacherounds}$ passes of the RandMemoHash algorithm created by \cite{lerner2014randmemohash}. The initial cache $\mathbf{c'}$, being an array of arrays of single bytes, will be constructed as follows. -We define the array $\mathbf{c}_{i}$, consisting of 64 single bytes, as the $i$th element of the intial cache: +We define the array $\mathbf{c}_{i}$, consisting of 64 single bytes, as the $i$th element of the initial cache: \begin{equation} \mathbf{c}_{i} = \begin{cases} \texttt{KEC512}(\mathbf{s}) & \text{if} \quad i = 0 \quad \\ From dd47c442be05ba79301918ba2663e7395dd00059 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 02:57:16 +0000 Subject: [PATCH 027/460] Ethash isn't planned, but is the reality for current Ethereum --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 9fb28b67..df587ec6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1131,7 +1131,7 @@ \subsection{Mining Proof-of-Work} \label{ch:pow} 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. \subsubsection{Ethash} -Ethash is the planned 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: +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: There exists a seed which can be computed for each block by scanning through the block headers up until that point. From the seed, one can compute a pseudorandom cache, $J_{cacheinit}$ bytes in initial size. Light clients store the cache. From the cache, we can generate a dataset, $J_{datasetinit}$ bytes in initial size, with the property that each item in the dataset depends on only a small number of items from the cache. Full clients and miners store the dataset. The dataset grows linearly with time. From 00f77421f373487332646ff59225c64c102a2584 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 12:50:14 +0000 Subject: [PATCH 028/460] Rename SUICIDE to SELFDESTRUCT (as per EIP6) --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index a87e257a..be699534 100644 --- a/Paper.tex +++ b/Paper.tex @@ -730,7 +730,7 @@ \section{Contract Creation} \label{ch:create} Note that the intention from block \firsthomesteadblock\ onwards ({\it Homestead}) is that the result is either a successfully created new contract with its endowment, or no new contract with no transfer of value. Before {\it Homestead}, if there is not enough gas to pay $c$, an account at the new contract's address is created, along with all the initialisation side-effects, and the value is transferred, but no contract code is deployed. \subsection{Subtleties} -Note that while the initialisation code is executing, the newly created address exists but with no intrinsic body code. Thus any message call received by it during this time causes no code to be executed. If the initialisation execution ends with a {\small SUICIDE} instruction, the matter is moot since the account will be deleted before the transaction is completed. For a normal {\small STOP} code, or if the code returned is otherwise empty, then the state is left with a zombie account, and any remaining balance will be locked into the account forever. +Note that while the initialisation code is executing, the newly created address exists but with no intrinsic body code. Thus any message call received by it during this time causes no code to be executed. If the initialisation execution ends with a {\small SELFDESTRUCT} instruction, the matter is moot since the account will be deleted before the transaction is completed. For a normal {\small STOP} code, or if the code returned is otherwise empty, then the state is left with a zombie account, and any remaining balance will be locked into the account forever. \section{Message Call} \label{ch:call} In the case of executing a message call, several parameters are required: sender ($s$), transaction originator ($o$), recipient ($r$), the account whose code is to be executed ($c$, usually the same as recipient), available gas ($g$), value ($v$) and gas price ($p$) together with an arbitrary length byte array, $\mathbf{d}$, the input data of the call and finally the present depth of the message-call/contract-creation stack ($e$). @@ -953,7 +953,7 @@ \subsubsection{Normal Halting} \begin{equation} H(\boldsymbol{\mu}, I) \equiv \begin{cases} H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small RETURN} \\ -() & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small SUICIDE} \} \\ +() & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small SELFDESTRUCT} \} \\ \varnothing & \text{otherwise} \end{cases} \end{equation} @@ -1500,14 +1500,14 @@ \section{Fee Schedule}\label{app:fees} $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_{suicide}$ & 24000 & Refund given (added into refund counter) for suiciding an account. \\ -$G_{suicide}$ & 5000 & Amount of gas to pay for a {\small SUICIDE} operation. \\ +$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for suiciding an account. \\ +$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_{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_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SUICIDE} operation which creates an account. \\ +$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}$ & 10 & 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. \\ @@ -1550,7 +1550,7 @@ \subsection{Gas Cost} 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 SUICIDE}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SUICIDE} \\ +C_\text{\tiny SELFDESTRUCT}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SELFDESTRUCT} \\ G_{create} & \text{if} \quad w = \text{\small CREATE}\\ G_{sha3}+G_{sha3word} \lceil \mathbf{s}[1] \div 32 \rceil & \text{if} \quad w = \text{\small SHA3}\\ G_{jumpdest} & \text{if} \quad w = \text{\small JUMPDEST}\\ @@ -1577,7 +1577,7 @@ \subsection{Gas Cost} C_{mem}(a) \equiv G_{memory} \cdot a + \Big\lfloor \dfrac{a^2}{512} \Big\rfloor \end{equation} -with $C_\text{\tiny CALL}$, $C_\text{\tiny SUICIDE}$ and $C_\text{\tiny SSTORE}$ as specified in the appropriate section below. We define the following subsets of instructions: +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}\} @@ -2035,15 +2035,15 @@ \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 -0xff & {\small SUICIDE} & 1 & 0 & Halt execution and register account for later deletion. \\ +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$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{suicide} & \text{if} \quad I_a \notin A_\mathbf{s} \\ +R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $C_{\text{\tiny SUICIDE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{suicide} + \begin{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}[1] \mod 2^{160}] = \varnothing \\ 0 & \text{otherwise} \end{cases}$ \\ From 91e2cea0b0ec91072f284b401129a4ef56280ea3 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 12:51:01 +0000 Subject: [PATCH 029/460] Rename other references of suicide to self-destruct --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index be699534..d8fb0eea 100644 --- a/Paper.tex +++ b/Paper.tex @@ -547,9 +547,9 @@ \subsection{Substate} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_r) \end{equation} -The tuple contents include $A_\mathbf{s}$, the suicide 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). 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 suicides, no logs and a zero refund balance: +For brevity, we define the empty substate $A^0$ to have no self-destructs, no logs and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), 0) \end{equation} @@ -625,7 +625,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 suicide list: +The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that appear in the self-destruct list: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ \forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing @@ -854,7 +854,7 @@ \subsection{Execution Environment} \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). \end{itemize} -The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the suicide list $\mathbf{s}$, the log series $\mathbf{l}$, the refunds $r$ and the resultant output, $\mathbf{o}$, given these definitions: +The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the self-destruct list $\mathbf{s}$, the log series $\mathbf{l}$, the refunds $r$ and the resultant output, $\mathbf{o}$, given these definitions: \begin{equation} (\boldsymbol{\sigma}', g', \mathbf{s}, \mathbf{l}, r, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) \end{equation} @@ -980,7 +980,7 @@ \subsection{The Execution Cycle} \end{cases} \end{eqnarray} -In general, we assume the memory, suicide list and system state don't change: +In general, we assume the memory, self-destruct list and system state don't change: \begin{eqnarray} \boldsymbol{\mu}'_\mathbf{m} & \equiv & \boldsymbol{\mu}_\mathbf{m} \\ \boldsymbol{\mu}'_i & \equiv & \boldsymbol{\mu}_i \\ @@ -1500,7 +1500,7 @@ \section{Fee Schedule}\label{app:fees} $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 suiciding an account. \\ +$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ $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. \\ From 5bd0797513e10a991ff0cd100fff061b1ef7ebdc Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 12:51:50 +0000 Subject: [PATCH 030/460] Use 'self-destruct set' consistently --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index d8fb0eea..6501fcb8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -625,7 +625,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 list: +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 @@ -854,7 +854,7 @@ \subsection{Execution Environment} \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). \end{itemize} -The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the self-destruct list $\mathbf{s}$, the log series $\mathbf{l}$, the refunds $r$ and the resultant output, $\mathbf{o}$, given these definitions: +The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the self-destruct set $\mathbf{s}$, the log series $\mathbf{l}$, the refunds $r$ and the resultant output, $\mathbf{o}$, given these definitions: \begin{equation} (\boldsymbol{\sigma}', g', \mathbf{s}, \mathbf{l}, r, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) \end{equation} @@ -980,7 +980,7 @@ \subsection{The Execution Cycle} \end{cases} \end{eqnarray} -In general, we assume the memory, self-destruct list and system state don't change: +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 \\ From a985b8931a7d0f1faaa909fc0b447965855fa09b Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 12:55:21 +0000 Subject: [PATCH 031/460] Remove obsolete commented out fee description (it has its own appendix now) --- Paper.tex | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/Paper.tex b/Paper.tex index a87e257a..e6629487 100644 --- a/Paper.tex +++ b/Paper.tex @@ -813,31 +813,8 @@ \subsection{Fees Overview} Storage fees have a slightly nuanced behaviour---to incentivise minimisation of the use of storage (which corresponds directly to a larger state database on all nodes), the execution fee for an operation that clears an entry in the storage is not only waived, a qualified refund is given; in fact, this refund is effectively paid up-front since the initial usage of a storage location costs substantially more than normal usage. -%More formally, given an instruction, it is possible to calculate the gas cost of executing it as follows: -% -%\begin{itemize} -%\item {\small SHA3} costs $G_{sha3}$ gas -%\item {\small SLOAD} costs $G_{sload}$ gas -%\item {\small BALANCE} costs $G_{balance}$ gas -%\item {\small SSTORE} costs $d.G_{sstore}$ gas where: -%\begin{itemize} -%\item $d = 2$ if the new value of the storage is non-zero and the old is zero; -%\item $d = 0$ if the new value of the storage is zero and the old is non-zero; -%\item $d = 1$ otherwise. -%\end{itemize} -%\item {\small CALL} costs $G_{call}$, though additional gas may be taken for the execution of the account's associated code, if non-empty. -%\item {\small CREATE} costs $G_{create}$, though additional gas may be taken for the execution of the account initialisation code. -%\item {\small STOP} costs $G_{stop}$ gas -%\item {\small SUICIDE} costs $G_{suicide}$ gas -%\item All other operations cost $G_{step}$ gas. -%\end{itemize} -% -%Additionally, when memory is accessed with {\small MSTORE}, {\small MSTORE8}, {\small MLOAD}, {\small CALLDATACOPY}, {\small CODECOPY}, {\small RETURN}, {\small SHA3}, {\small CREATE} or {\small CALL}, the memory should be enlarged to the smallest multiple of words such that all addressed bytes now fit in it. - See Appendix \ref{app:vm} for a rigorous definition of the EVM gas cost. -%Whenever a higher memory index is referenced, the fee difference to take it to the higher usage from the original (lower) usage is charged. Notably, because {\small MSTORE} and {\small MLOAD} operate on word lengths, they implicitly increase the highest-accessed index to 31 greater than their target index. - \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$: From 9538c90731572bd958bb76cf46e464a92bc013f5 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 01:59:36 +0000 Subject: [PATCH 032/460] Include build script --- README.md | 2 +- build.sh | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) create mode 100755 build.sh diff --git a/README.md b/README.md index a3f23746..4402d4d0 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is It can be viewed in ``PDF`` format with ``pdflatex Paper.tex`` (local install of a current free tex distribution required). -After creating ``Paper.pdf`` for the first time and every time the bibliography file (``Biblio.bib``) is updated, you will also need to run ``bibtex Paper`` and then ``pdflater Paper`` twice (e.g. ``bibtex Paper && pdflatex Paper && pdflatex Paper``) in order to correctly incorporate all the bibliography references. +After creating ``Paper.pdf`` for the first time and every time the bibliography file (``Biblio.bib``) is updated, you will also need to run ``bibtex Paper`` and then ``pdflater Paper`` twice (e.g. ``bibtex Paper && pdflatex Paper && pdflatex Paper``) in order to correctly incorporate all the bibliography references. Alternatively, try the supplied build script (``build.sh``). There are also some online tools like http://latex.informatik.uni-halle.de/latex-online/latex.php you can use for compiling/preview. diff --git a/build.sh b/build.sh new file mode 100755 index 00000000..e07343ed --- /dev/null +++ b/build.sh @@ -0,0 +1,9 @@ +#!/usr/bin/env bash + +set -e + +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 From 29e8f18bbb464f6dce6897922db8fef23f9a2c5a Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 01:59:57 +0000 Subject: [PATCH 033/460] Use the build script in travis --- .travis.yml | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/.travis.yml b/.travis.yml index 0389dd82..7efafc8e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -3,11 +3,7 @@ before_install: - sudo apt-get -qq update - sudo apt-get install texlive texlive-latex3 script: -- 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 +- ./build.sh deploy: provider: script script: ./travis_deploy.sh From eb48b6e20045b009a2e9b1e3e1ad32e2fda710b6 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 14:49:25 +0000 Subject: [PATCH 034/460] Proper error propagation in build script --- build.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/build.sh b/build.sh index e07343ed..ae12ddb0 100755 --- a/build.sh +++ b/build.sh @@ -2,8 +2,8 @@ set -e -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 && \ +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 From e1d6937bcbb89802cfbbb5b76abaf636ae0f6c44 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 20:53:09 +0000 Subject: [PATCH 035/460] Use out-of-gas consistently --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a87e257a..e24e372a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -698,16 +698,16 @@ \section{Contract Creation} \label{ch:create} $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 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. +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 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. If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: \begin{equation} c \equiv G_{codedeposit} \times |\mathbf{o}| \end{equation} -If there is not enough gas remaining to pay this, \ie $g^{**} < c$, then we also declare an Out-of-Gas exception. +If there is not enough gas remaining to pay this, \ie $g^{**} < c$, then we also declare an out-of-gas exception. -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. +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: From 1320dbdcd8f7b9d7e00bf39c96c030061694d00d Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 20:53:51 +0000 Subject: [PATCH 036/460] Move the OOG shorthand to the first occurance of out-of-gas --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e24e372a..17273bb4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -698,7 +698,7 @@ \section{Contract Creation} \label{ch:create} $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 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. +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. If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: \begin{equation} @@ -803,7 +803,7 @@ \subsection{Basics} The machine does not follow the standard von Neumann architecture. Rather than storing program code in generally-accessible memory or storage, it is stored separately in a virtual ROM interactable only through a specialised instruction. -The machine can have exceptional execution for several reasons, including stack underflows and invalid instructions. Like the out-of-gas (OOG) exception, they do not leave state changes intact. Rather, the machine halts immediately and reports the issue to the execution agent (either the transaction processor or, recursively, the spawning execution environment) which will deal with it separately. +The machine can have exceptional execution for several reasons, including stack underflows and invalid instructions. Like the out-of-gas exception, they do not leave state changes intact. Rather, the machine halts immediately and reports the issue to the execution agent (either the transaction processor or, recursively, the spawning execution environment) which will deal with it separately. \subsection{Fees Overview} From ea0faa741cd9287eee497c0980cb06e851875e68 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 13 Jan 2017 09:56:41 +0000 Subject: [PATCH 037/460] Replace unbalanced bracket with comma --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a87e257a..2c595477 100644 --- a/Paper.tex +++ b/Paper.tex @@ -325,7 +325,8 @@ \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$. +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$: \begin{equation} From 71afd59b6b418c631297184cb89d62aa881009b7 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 02:00:24 +0000 Subject: [PATCH 038/460] Include git hash in generated PDF --- Paper.tex | 4 +++- build.sh | 4 ++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 0bd82740..7a303c20 100644 --- a/Paper.tex +++ b/Paper.tex @@ -21,6 +21,8 @@ \usepackage{afterpage} \usepackage{tikz} +\input{Version.tex} + \newcommand{\hcancel}[1]{% \tikz[baseline=(tocancel.base)]{ \node[inner sep=0pt,outer sep=0pt] (tocancel) {#1}; @@ -39,7 +41,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}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-150 revision}} \\ {\smaller {\YellowPaperVersionNumber{}}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ diff --git a/build.sh b/build.sh index ae12ddb0..1cbc57bc 100755 --- a/build.sh +++ b/build.sh @@ -2,6 +2,10 @@ set -e +SHA=`git rev-parse --short --verify HEAD` + +echo "\newcommand{\YellowPaperVersionNumber}{$SHA}" > Version.tex + pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ bibtex Paper && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ From 7efcc9c89aeab6ab1e2169e818a55b9ae3c98421 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 02:33:32 +0000 Subject: [PATCH 039/460] Slightly better formatting for the git hash --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7a303c20..346c47d3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -41,7 +41,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}} \\ {\smaller {\YellowPaperVersionNumber{}}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-150 revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ From 8b25783b6bfe1a971f0671eedcba3b2ac1aa4afd Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 11:06:48 +0000 Subject: [PATCH 040/460] Add build date --- build.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/build.sh b/build.sh index 1cbc57bc..4c9ddf8a 100755 --- a/build.sh +++ b/build.sh @@ -3,8 +3,9 @@ set -e SHA=`git rev-parse --short --verify HEAD` +DATE=`date "+%Y-%m-%d"` -echo "\newcommand{\YellowPaperVersionNumber}{$SHA}" > Version.tex +echo "\newcommand{\YellowPaperVersionNumber}{$SHA - $DATE}" > Version.tex pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ bibtex Paper && \ From 34170b6a7ae23f7c4368abaa0a52a4efbeda6060 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 20:45:16 +0000 Subject: [PATCH 041/460] Take date of last commit as build date --- build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.sh b/build.sh index 4c9ddf8a..9d67506b 100755 --- a/build.sh +++ b/build.sh @@ -3,7 +3,7 @@ set -e SHA=`git rev-parse --short --verify HEAD` -DATE=`date "+%Y-%m-%d"` +DATE=`git show -s --format="%cd" --date="format:%Y-%m-%d" HEAD` echo "\newcommand{\YellowPaperVersionNumber}{$SHA - $DATE}" > Version.tex From 100d7155f8c4832eddf4b77ea34262fef0144112 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 12 Jan 2017 20:46:43 +0000 Subject: [PATCH 042/460] Use 'unknown revision' if building without git --- build.sh | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/build.sh b/build.sh index 9d67506b..4a32bcea 100755 --- a/build.sh +++ b/build.sh @@ -2,10 +2,19 @@ set -e +if [ -d ".git" ]; then + SHA=`git rev-parse --short --verify HEAD` DATE=`git show -s --format="%cd" --date="format:%Y-%m-%d" HEAD` +REV="$SHA - $DATE" + +else + +REV="unknown revision" + +fi -echo "\newcommand{\YellowPaperVersionNumber}{$SHA - $DATE}" > Version.tex +echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ bibtex Paper && \ From 980a2824e233f416902aeb3dc70801d4f2ac01fb Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 17 Jan 2017 14:24:59 +0000 Subject: [PATCH 043/460] Use git short date as YYYY-MM-DD --- build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.sh b/build.sh index 4a32bcea..7f8c44cf 100755 --- a/build.sh +++ b/build.sh @@ -5,7 +5,7 @@ set -e if [ -d ".git" ]; then SHA=`git rev-parse --short --verify HEAD` -DATE=`git show -s --format="%cd" --date="format:%Y-%m-%d" HEAD` +DATE=`git show -s --format="%cd" --date=short HEAD` REV="$SHA - $DATE" else From 4a399edb72f0ffccded1dcdf5fe5ec14ae856fc1 Mon Sep 17 00:00:00 2001 From: Nicola Squartini Date: Tue, 17 Jan 2017 17:00:30 +0100 Subject: [PATCH 044/460] Update Paper.tex --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 346c47d3..8998286b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1458,7 +1458,7 @@ \section{Signing Transactions}\label{app:signing} 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} -The assertion that the sender of the a signed transaction equals the address of the signer should be self-evident: +The assertion that the sender of a signed transaction equals the address of the signer should be self-evident: \begin{equation} \forall T: \forall p_r: S(G(T, p_r)) \equiv A(p_r) \end{equation} From 27a2bb82d858d6df6798d9ca2fade49114b4b30d Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 27 Jan 2017 10:46:24 +0000 Subject: [PATCH 045/460] Include invalid instruction from EIP141 --- Paper.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Paper.tex b/Paper.tex index 8998286b..c68f9e0b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2019,6 +2019,8 @@ \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 +0xfe & {\small INVALID} & 0 & 0 & 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 \}$ \\ &&&& $\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$ \\ From 4d917eccdbd02c32110d71f27b51bb1d0a67b87c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 13 Feb 2017 17:53:36 +0100 Subject: [PATCH 046/460] Change the delta and alpha of INVALID instruction into nothing. This makes sure that the machine halts. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c68f9e0b..60522438 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2019,7 +2019,7 @@ \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 -0xfe & {\small INVALID} & 0 & 0 & Designated invalid instruction. \\ +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 \}$ \\ From fc434e20d322bbc6287ca35ffa464af6a20d8de1 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 22 Dec 2016 14:37:08 +0100 Subject: [PATCH 047/460] Fix the memory consumption of CODECOPY --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 60522438..aa65090f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1749,7 +1749,7 @@ \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}[1])$ \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_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. \\ From d0f4cbcff1ff52f3f1fc0837912ee9da333b214c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 20 Feb 2017 18:01:32 +0100 Subject: [PATCH 048/460] Make sure that message call consumes all gas when exceptional halting happens --- Paper.tex | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1948eb98..87ba3880 100644 --- a/Paper.tex +++ b/Paper.tex @@ -774,7 +774,11 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma} & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ \boldsymbol{\sigma}^{**} & \text{otherwise} \end{cases} \\ -(\boldsymbol{\sigma}^{**}, g', \mathbf{s}, \mathbf{o}) & \equiv & \begin{cases} +g' & \equiv & \begin{cases} +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +g^{**} & \text{otherwise} +\end{cases} \\ +(\boldsymbol{\sigma}^{**}, g^{**}, \mathbf{s}, \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 \\ From 98833f0f20a29ac7d5979b0e121cd881bd519edc Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 21 Feb 2017 16:05:18 +0100 Subject: [PATCH 049/460] Remove a left-over comment --- Paper.tex | 5 ----- 1 file changed, 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1948eb98..76f6afb0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -642,11 +642,6 @@ \subsection{Execution} These are used to help define the transaction receipt, discussed later. -%In the case that $s = m$ then we simply return the Ether back to the sender/miner, collapsing the exception into: -%\begin{eqnarray} -%\boldsymbol{\sigma}'[s]_b & \equiv & \boldsymbol{\sigma}_P[s]_b + g -%\end{eqnarray} - \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$). From e0e1706a3b8997f2a76471144bfbfb0d88645215 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 5 Oct 2016 16:41:25 +0200 Subject: [PATCH 050/460] Add a parentheses in SMOD definition This solves #190. The other way of putting parentheses did not make sense becasue `sign(x) * |x|` can immediately be optimized into `x`. Also, I checked one EVM implementation's behavior ``` evm --debug --code "60601960401907" ``` and saw SMOD returning a negative-looking number. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1948eb98..a69d3fa7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1635,7 +1635,7 @@ \subsection{Instruction Set} &&&& $\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. \\ From 310ef9a272a3e6995a9ae01654a76828bebc1bfb Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 30 Dec 2016 14:16:57 +0100 Subject: [PATCH 051/460] The output from a CALL is considered as the empty string when the call fails --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1948eb98..3373070e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1961,7 +1961,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, \mathbf{o}) & \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)\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'$ \\ From d070b73a1d26a912ddc4fceeb184081739bb530f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 30 Dec 2016 14:25:58 +0100 Subject: [PATCH 052/460] Also in DELEGATECALL and CALLCODE, the output string is empty when the call fails --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3373070e..365b585e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1995,7 +1995,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, \mathbf{o}) & \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)\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.\\ @@ -2015,7 +2015,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, \mathbf{o}) & \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)\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 56170aba0e6c7ec969d68c5980bc73f2ac2ff6ba Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 25 Nov 2016 11:37:36 +0100 Subject: [PATCH 053/460] Update the fee schedule following EIP 160 https://github.com/ethereum/EIPs/issues/160 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 29b88d4f..653e9c1d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1493,7 +1493,7 @@ \section{Fee Schedule}\label{app:fees} $G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \\ $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}$ & 10 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\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_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ From 3403963b35ba0d73d831647d7496891bf597502c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 25 Nov 2016 12:12:27 +0100 Subject: [PATCH 054/460] EIP170 --- Paper.tex | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 653e9c1d..06bc9f5c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -704,9 +704,12 @@ \section{Contract Creation} \label{ch:create} 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. If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: -\begin{equation} -c \equiv G_{codedeposit} \times |\mathbf{o}| -\end{equation} +\begin{align} +c \equiv \begin{cases} + 2^{256} - 1 & \text{if} \quad |\mathbf{o}| \le 24000 \\ + G_{codedeposit} \times |\mathbf{o}| & \text{otherwise} +\end{cases} +\end{align} If there is not enough gas remaining to pay this, \ie $g^{**} < c$, then we also declare an out-of-gas exception. From 4a2dbf6adfacc6dd5f959a974b10a3316c4fb0b9 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Dec 2016 19:59:35 +0100 Subject: [PATCH 055/460] EIP155 --- Paper.tex | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 06bc9f5c..192f7a4f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1417,7 +1417,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 id' or `chain id doubled plus 35 or 36'. The recovery id 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 id is a constant natural number. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} @@ -1428,7 +1428,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\tiny secp256k1n} & \text{if} \quad H_i < \firsthomesteadblock \\ \mathtt{\tiny secp256k1n} \div 2 + 1 & \text{otherwise} \\ \end{dcases} \\ - 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} @@ -1441,11 +1441,13 @@ \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, T_\mathbf{i}) & \text{if} \; T_t = 0 \wedge v \in \{27, 28\}\\ +(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}) & \text{if} \; T_t \neq 0 \wedge v \in \{27, 28\} \\ +(T_n, T_p, T_g, T_t, T_v, T_\mathbf{i}, \mathtt{\tiny chain\_id}, (), ()) & \text{if} \; T_t = 0 \wedge v \notin \{27, 28\}\\ +(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}, \mathtt{\tiny chain\_id}, (), ()) & \text{otherwise} \end{cases} \\ h(T) & \equiv & \mathtt{\small KEC}( L_S(T) ) \end{eqnarray} From c6aa5d02e47ae76edfc7223fb2cd388cffa02bca Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 16:48:27 +0100 Subject: [PATCH 056/460] 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 192f7a4f..ad095461 100644 --- a/Paper.tex +++ b/Paper.tex @@ -663,12 +663,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 998cc7e854d84f485383769d356a342431f218da Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:06:08 +0100 Subject: [PATCH 057/460] Define when an account state is empty --- Paper.tex | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Paper.tex b/Paper.tex index ad095461..5430de9c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -233,6 +233,14 @@ \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 state is 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{Homestead} \label{ch:homestead} A significant block number for compatibility with the public network is the block marking the transition between the {\it Frontier} and {\it Homestead} phases of the platform, which we denote with the symbol \firsthomesteadblock, defined thus From 697f6b98c5b9c3e66a6043f82c010de6f91a3998 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:10:35 +0100 Subject: [PATCH 058/460] Define when an account is dead --- Paper.tex | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Paper.tex b/Paper.tex index 5430de9c..7b41d34e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -241,6 +241,12 @@ \subsection{World State} \label{ch:state} \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} +An account is 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{Homestead} \label{ch:homestead} A significant block number for compatibility with the public network is the block marking the transition between the {\it Frontier} and {\it Homestead} phases of the platform, which we denote with the symbol \firsthomesteadblock, defined thus From 16bb9f1e388ddbf3d561adb19d996457ced722cc Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:25:39 +0100 Subject: [PATCH 059/460] 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 7b41d34e..c0ea0b41 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2008,7 +2008,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 @@ -2051,7 +2051,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}[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{\sigma}[I_a]_b \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \bottomrule From 96ea0526dd6d41694ed6cc8f544a9ab4e652aff2 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 9 Dec 2016 11:48:24 +0100 Subject: [PATCH 060/460] Define the balance update function that also performs the cleanup --- Paper.tex | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Paper.tex b/Paper.tex index c0ea0b41..a99122d3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -247,6 +247,16 @@ \subsection{World State} \label{ch:state} \equiv \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} +Here is a function that updates the balance of an account state but deletes the account state when it becomes empty: +\begin{equation} +\rho_b(\boldsymbol{\sigma}, a, x) \equiv +\begin{cases} +\varnothing \quad\text{if}\quad \boldsymbol{\sigma}[a]_n = 0 \wedge x = 0 \wedge \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \\ +(\boldsymbol{\sigma}[a]_n, x, \boldsymbol{\sigma}[a]_s, \boldsymbol{\sigma}[a]_c) \quad \text{otherwise} +\end{cases} +\end{equation} +for $a \in \mathbb{B}_{20}$ and $x \in \mathbb{P}_{256}$. + \subsection{Homestead} \label{ch:homestead} A significant block number for compatibility with the public network is the block marking the transition between the {\it Frontier} and {\it Homestead} phases of the platform, which we denote with the symbol \firsthomesteadblock, defined thus From 870c8cd345b1786a097aceecd66fbd8ebe98f4a4 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 19:15:21 +0100 Subject: [PATCH 061/460] EIP161.c --- Paper.tex | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index a99122d3..ab78cbc8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -647,15 +647,16 @@ \subsection{Execution} 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}_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 \\ +\boldsymbol{\sigma}^*[S(T)] & \equiv & \rho_b(\boldsymbol{\sigma}_P, S(T), \boldsymbol{\sigma}_P[S(T)]_b + g^* T_p) \\ +\boldsymbol{\sigma}^*[m] & \equiv & \rho_b(\boldsymbol{\sigma}_P, m, \boldsymbol{\sigma}_P[m]_b + (T_g - g^*) T_p) \\ 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: \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: @@ -693,7 +694,7 @@ \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& \rho_b(\boldsymbol{\sigma}, s, \boldsymbol{\sigma}[s]_b - v) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: @@ -751,6 +752,8 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma} & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ \boldsymbol{\sigma}^{**} & \text{if} \quad g^{**} Date: Mon, 5 Dec 2016 21:45:34 +0100 Subject: [PATCH 062/460] Keep the touched accounts in the substate --- Paper.tex | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/Paper.tex b/Paper.tex index ab78cbc8..9ca59f35 100644 --- a/Paper.tex +++ b/Paper.tex @@ -571,14 +571,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: +For brevity, we define the initial substate $A^0$ to have no self-destructs, no logs, a set of touched accounts and a zero refund balance: \begin{equation} -A^0 \equiv (\varnothing, (), 0) +A^0(T) \equiv (\varnothing, (), T, 0) \quad\text{for}\quad T \subseteq \mathbb{B}_{20} \end{equation} \subsection{Execution} @@ -710,7 +710,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} @@ -806,11 +806,11 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma}^{**} & \text{otherwise} \end{cases} \\ (\boldsymbol{\sigma}^{**}, g', \mathbf{s}, \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 \\ @@ -818,6 +818,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} @@ -867,7 +868,7 @@ \subsection{Execution Environment} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the self-destruct set $\mathbf{s}$, the log series $\mathbf{l}$, the refunds $r$ and the resultant output, $\mathbf{o}$, given these definitions: \begin{equation} -(\boldsymbol{\sigma}', g', \mathbf{s}, \mathbf{l}, r, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) +(\boldsymbol{\sigma}', g', \mathbf{s}, \mathbf{l}, r, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I, T) \end{equation} \subsection{Execution Overview} @@ -876,7 +877,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 & X_{0,1,2,4}\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0, I)\big) \\ +\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & X_{0,1,2,4}\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0(T), I)\big) \\ \boldsymbol{\mu}_g & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ @@ -885,7 +886,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(\emptyset), I, ()\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} @@ -1387,9 +1388,9 @@ \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} -(\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ -(\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} +\Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} +(\varnothing, 0, A^0(\emptyset), ()) & \text{if} \quad g < g_r \\ +(\boldsymbol\sigma, g - g_r, A^0(T), \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. @@ -1985,7 +1986,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 implies: $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 implies: $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 bc47431ecc5fd792d506f7d2ba4ffb0804bf6836 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 6 Dec 2016 10:19:56 +0100 Subject: [PATCH 063/460] 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 9ca59f35..f8b970f6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -652,7 +652,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 825566d58f3affe3ff10f6f55ad3cfcdcaed9650 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 6 Dec 2016 11:09:14 +0100 Subject: [PATCH 064/460] Precompiled contracts are touched even when out-of-gas --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f8b970f6..e7509ac8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1389,7 +1389,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, T) \equiv \begin{cases} -(\varnothing, 0, A^0(\emptyset), ()) & \text{if} \quad g < g_r \\ +(\varnothing, 0, A^0(T), ()) & \text{if} \quad g < g_r \\ (\boldsymbol\sigma, g - g_r, A^0(T), \mathbf{o}) & \text{otherwise}\end{cases} \end{equation} From e41e63ae1308749e654d7162f66271740553ec10 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 6 Dec 2016 12:40:00 +0100 Subject: [PATCH 065/460] Change the revision --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index e7509ac8..71cd5265 100644 --- a/Paper.tex +++ b/Paper.tex @@ -41,7 +41,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{EIP-170 revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ From 7685f51cab1222ab0b2ea402c656526a8600016b Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 9 Dec 2016 12:30:37 +0100 Subject: [PATCH 066/460] Improve local layouts --- Paper.tex | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 71cd5265..55b0a588 100644 --- a/Paper.tex +++ b/Paper.tex @@ -236,7 +236,7 @@ \subsection{World State} \label{ch:state} An account state is 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) +\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} @@ -244,7 +244,7 @@ \subsection{World State} \label{ch:state} An account is 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) +\quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} Here is a function that updates the balance of an account state but deletes the account state when it becomes empty: @@ -805,6 +805,7 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma} & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ \boldsymbol{\sigma}^{**} & \text{otherwise} \end{cases} \\ +\\ \nonumber (\boldsymbol{\sigma}^{**}, g', \mathbf{s}, \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 \\ @@ -819,6 +820,7 @@ \section{Message Call} \label{ch:call} I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ T & \equiv & \{s, r\} \\ +\\ \nonumber \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} From 748408754a90a6d96d1864d30adae62519aca5ec Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Feb 2017 10:57:42 +0100 Subject: [PATCH 067/460] Add more EIP numbers in the title These EIPs were applied on the same block number, so it makes sense to list them all. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 55b0a588..d949cf32 100644 --- a/Paper.tex +++ b/Paper.tex @@ -41,7 +41,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-170 revision (\YellowPaperVersionNumber{})}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-155/160/161/170 revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ From 7175c053891706ab935455fc3e2ebb9416f1512e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Feb 2017 10:58:36 +0100 Subject: [PATCH 068/460] Update wording --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index d949cf32..78549724 100644 --- a/Paper.tex +++ b/Paper.tex @@ -247,7 +247,7 @@ \subsection{World State} \label{ch:state} \quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} -Here is a function that updates the balance of an account state but deletes the account state when it becomes empty: +We define the function that updates the balance of an account state but deletes the account state when it becomes empty: \begin{equation} \rho_b(\boldsymbol{\sigma}, a, x) \equiv \begin{cases} From bf86378f27dcb2d7ec6543574c2dbe43fc02b72a Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 13 Jan 2017 10:39:19 +0100 Subject: [PATCH 069/460] Insert a comma --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 29b88d4f..c2f2769f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -97,7 +97,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} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From 23f7828d264c10866f06acebc01208c4611c71ec Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 28 Feb 2017 16:36:22 +0100 Subject: [PATCH 070/460] Fix wording --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 78549724..c2828042 100644 --- a/Paper.tex +++ b/Paper.tex @@ -255,7 +255,7 @@ \subsection{World State} \label{ch:state} (\boldsymbol{\sigma}[a]_n, x, \boldsymbol{\sigma}[a]_s, \boldsymbol{\sigma}[a]_c) \quad \text{otherwise} \end{cases} \end{equation} -for $a \in \mathbb{B}_{20}$ and $x \in \mathbb{P}_{256}$. +where $a \in \mathbb{B}_{20}$ and $x \in \mathbb{P}_{256}$. \subsection{Homestead} \label{ch:homestead} From 5565163142b2ba700a0b9060e1f2f10e61a392a8 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 28 Feb 2017 16:36:33 +0100 Subject: [PATCH 071/460] Fix the code size limit in EIP170 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c2828042..5f4b9bb0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -731,7 +731,7 @@ \section{Contract Creation} \label{ch:create} If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: \begin{align} c \equiv \begin{cases} - 2^{256} - 1 & \text{if} \quad |\mathbf{o}| \le 24000 \\ + 2^{256} - 1 & \text{if} \quad |\mathbf{o}| \le 24576 \\ G_{codedeposit} \times |\mathbf{o}| & \text{otherwise} \end{cases} \end{align} From 862f8da7610945b3823ca8b66d1dff68f3436b84 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Thu, 2 Mar 2017 17:24:51 +0100 Subject: [PATCH 072/460] Revert "Spurious dragon changes" --- Paper.tex | 126 +++++++++++++++++++----------------------------------- 1 file changed, 43 insertions(+), 83 deletions(-) diff --git a/Paper.tex b/Paper.tex index 58ea0f2d..28065c55 100644 --- a/Paper.tex +++ b/Paper.tex @@ -41,7 +41,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-155/160/161/170 revision (\YellowPaperVersionNumber{})}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-150 revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ @@ -233,30 +233,6 @@ \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 state is 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 -\end{equation} - -An account is dead when its account state is non-existent or empty: -\begin{equation} -\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) -\quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) -\end{equation} - -We define the function that updates the balance of an account state but deletes the account state when it becomes empty: -\begin{equation} -\rho_b(\boldsymbol{\sigma}, a, x) \equiv -\begin{cases} -\varnothing \quad\text{if}\quad \boldsymbol{\sigma}[a]_n = 0 \wedge x = 0 \wedge \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \\ -(\boldsymbol{\sigma}[a]_n, x, \boldsymbol{\sigma}[a]_s, \boldsymbol{\sigma}[a]_c) \quad \text{otherwise} -\end{cases} -\end{equation} -where $a \in \mathbb{B}_{20}$ and $x \in \mathbb{P}_{256}$. - \subsection{Homestead} \label{ch:homestead} A significant block number for compatibility with the public network is the block marking the transition between the {\it Frontier} and {\it Homestead} phases of the platform, which we denote with the symbol \firsthomesteadblock, defined thus @@ -571,14 +547,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_\mathbf{t}, A_r) +A \equiv (A_\mathbf{s}, A_\mathbf{l}, 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). $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). 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 initial substate $A^0$ to have no self-destructs, no logs, a set of touched accounts and a zero refund balance: +For brevity, we define the empty substate $A^0$ to have no self-destructs, no logs and a zero refund balance: \begin{equation} -A^0(T) \equiv (\varnothing, (), T, 0) \quad\text{for}\quad T \subseteq \mathbb{B}_{20} +A^0 \equiv (\varnothing, (), 0) \end{equation} \subsection{Execution} @@ -647,16 +623,15 @@ \subsection{Execution} 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}_P \quad \text{except} \\ -\boldsymbol{\sigma}^*[S(T)] & \equiv & \rho_b(\boldsymbol{\sigma}_P, S(T), \boldsymbol{\sigma}_P[S(T)]_b + g^* T_p) \\ -\boldsymbol{\sigma}^*[m] & \equiv & \rho_b(\boldsymbol{\sigma}_P, m, \boldsymbol{\sigma}_P[m]_b + (T_g - g^*) T_p) \\ +\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 \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: +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{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] & \equiv & \varnothing \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: @@ -683,13 +658,13 @@ \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 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}^*$: +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}^*$: \begin{equation} \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& \rho_b(\boldsymbol{\sigma}, s, \boldsymbol{\sigma}[s]_b - v) +\boldsymbol{\sigma}^*[a] &\equiv& \big( 0, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[s]_b &\equiv& \boldsymbol{\sigma}[s]_b - v \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: @@ -705,7 +680,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, \{s, a\}) \\ +(\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I) \\ \end{equation} where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: \begin{eqnarray} @@ -724,12 +699,9 @@ \section{Contract Creation} \label{ch:create} 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. If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: -\begin{align} -c \equiv \begin{cases} - 2^{256} - 1 & \text{if} \quad |\mathbf{o}| \le 24576 \\ - G_{codedeposit} \times |\mathbf{o}| & \text{otherwise} -\end{cases} -\end{align} +\begin{equation} +c \equiv G_{codedeposit} \times |\mathbf{o}| +\end{equation} If there is not enough gas remaining to pay this, \ie $g^{**} < c$, then we also declare an out-of-gas exception. @@ -747,8 +719,6 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma} & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ \boldsymbol{\sigma}^{**} & \text{if} \quad g^{**} Date: Thu, 2 Mar 2017 18:06:04 +0100 Subject: [PATCH 073/460] Fix broken definition. --- Paper.tex | 42 ++++++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 16 deletions(-) diff --git a/Paper.tex b/Paper.tex index 28065c55..e1018218 100644 --- a/Paper.tex +++ b/Paper.tex @@ -273,7 +273,7 @@ \subsection{The Transaction} \label{ch:transaction} \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} +(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}, T_w, T_r, T_s) & \text{otherwise} \end{cases} \end{equation} @@ -327,7 +327,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. +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$: @@ -580,13 +580,13 @@ \subsection{Execution} 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 \\ +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 \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_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$. 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. @@ -696,7 +696,11 @@ \section{Contract Creation} \label{ch:create} $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. +<<<<<<< Updated upstream 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. +======= +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 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. +>>>>>>> Stashed changes If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: \begin{equation} @@ -829,9 +833,15 @@ \subsection{Execution Environment} \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). \end{itemize} -The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the self-destruct set $\mathbf{s}$, the log series $\mathbf{l}$, the refunds $r$ and the resultant output, $\mathbf{o}$, given these definitions: +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 defined it as: \begin{equation} -(\boldsymbol{\sigma}', g', \mathbf{s}, \mathbf{l}, r, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) +(\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$: + +\begin{equation} +A \equiv (\mathbf{s}, \mathbf{l}, r) \end{equation} \subsection{Execution Overview} @@ -999,7 +1009,7 @@ \subsection{Ommer Validation} where $k$ denotes the ``is-kin'' property: \begin{equation} -k(U, H, n) \equiv \begin{cases} false & \text{if} \quad n = 0 \\ +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} \end{cases} @@ -1027,7 +1037,7 @@ \subsection{Reward Application} \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]_b & = & \boldsymbol{\sigma}[U_c]_b + (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. @@ -1076,7 +1086,7 @@ \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} = +\mathbf{R}[n]_\mathbf{l} = \Upsilon^\mathbf{l}(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n]) \end{equation} @@ -1114,7 +1124,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 I 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. @@ -1420,7 +1430,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\tiny secp256k1n} & \text{if} \quad H_i < \firsthomesteadblock \\ \mathtt{\tiny secp256k1n} \div 2 + 1 & \text{otherwise} \\ \end{dcases} \\ - v &\in \{27,28\} + v &\in \{27,28\} \end{align} where: \begin{align} @@ -1437,7 +1447,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, 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, T_\mathbf{d}) & \text{otherwise} \end{cases} \\ h(T) & \equiv & \mathtt{\small KEC}( L_S(T) ) \end{eqnarray} @@ -2074,7 +2084,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. 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}) @@ -2090,7 +2100,7 @@ \subsection{Size of dataset and cache} \end{cases} \end{equation} \subsection{Dataset generation} -In order the generate the dataset we need the cache $\mathbf{c}$, which is an array of bytes. It depends on the cache size $c_{size}$ and the seed hash $\mathbf{s} \in \mathbb{B}_{32}$. +In order the generate the dataset we need the cache $\mathbf{c}$, which is an array of bytes. It depends on the cache size $c_{size}$ and the seed hash $\mathbf{s} \in \mathbb{B}_{32}$. \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} @@ -2114,7 +2124,7 @@ \subsubsection{Cache} \texttt{KEC512}(\mathbf{c}_{i-1}) & \text{otherwise} \end{cases} \end{equation} -Therefore $ \mathbf{c'}$ can be defined as +Therefore $ \mathbf{c'}$ can be defined as \begin{equation} \mathbf{c'}[i] = \mathbf{c}_{i} \quad \forall \quad i < n \end{equation} @@ -2141,7 +2151,7 @@ \subsubsection{Cache} \text{with} \quad \mathbf{x'} = \mathbf{x} \quad \text{except} \quad \mathbf{x'}[j] = E_{rmh}(\mathbf{x}, j) \quad \forall \quad j < i \end{multline} -\subsubsection{Full dataset calculation} \label{dataset} +\subsubsection{Full dataset calculation} \label{dataset} Essentially, we combine data from $J_{parents}$ pseudorandomly selected cache nodes, and hash that to compute the dataset. The entire dataset is then generated by a number of items, each $J_{hashbytes}$ bytes in size: \begin{equation} \mathbf{d}[i] = E_{datasetitem}(\mathbf{c}, i) \quad \forall \quad i < \left\lfloor\frac{d_{size}}{J_{hashbytes}}\right\rfloor From f7ce3497a78ffe2b27c900bcf8eba4427b83c502 Mon Sep 17 00:00:00 2001 From: Gav Date: Thu, 2 Mar 2017 18:16:16 +0100 Subject: [PATCH 074/460] Resolve conflict. --- Paper.tex | 4 ---- 1 file changed, 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index e1018218..9e674993 100644 --- a/Paper.tex +++ b/Paper.tex @@ -696,11 +696,7 @@ \section{Contract Creation} \label{ch:create} $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. -<<<<<<< Updated upstream 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. -======= -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 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. ->>>>>>> Stashed changes If the initialization code completes successfully, a final contract-creation cost is paid, the code-deposit cost, $c$, proportional to the size of the created contract's code: \begin{equation} From 926281a2f7438378a1379374b6311cfbb664f6ef Mon Sep 17 00:00:00 2001 From: Gav Date: Thu, 2 Mar 2017 18:17:05 +0100 Subject: [PATCH 075/460] Add gitignore. --- .gitignore | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..44c9250f --- /dev/null +++ b/.gitignore @@ -0,0 +1,8 @@ +.DS_Store +Paper.aux +Paper.bbl +Paper.blg +Paper.log +Paper.pdf +Version.tex + From f772424919fb67c74a031ea3d3583a47e69c2bbe Mon Sep 17 00:00:00 2001 From: Gav Date: Thu, 2 Mar 2017 18:20:38 +0100 Subject: [PATCH 076/460] Update instructions now that build.sh is necessary. --- README.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/README.md b/README.md index 4402d4d0..f3e4b58f 100644 --- a/README.md +++ b/README.md @@ -4,10 +4,4 @@ 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 . -It can be viewed in ``PDF`` format with ``pdflatex Paper.tex`` (local install of a current free tex distribution required). - -After creating ``Paper.pdf`` for the first time and every time the bibliography file (``Biblio.bib``) is updated, you will also need to run ``bibtex Paper`` and then ``pdflater Paper`` twice (e.g. ``bibtex Paper && pdflatex Paper && pdflatex Paper``) in order to correctly incorporate all the bibliography references. Alternatively, try the supplied build script (``build.sh``). - -There are also some online tools like http://latex.informatik.uni-halle.de/latex-online/latex.php you can use for -compiling/preview. - +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. From b0242d9480f4dca2b17ca412ecb4f6ff066e8d69 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Thu, 2 Mar 2017 18:22:28 +0100 Subject: [PATCH 077/460] Add alt link --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f3e4b58f..8a1b7805 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,6 @@ [![Gitter](https://badges.gitter.im/ethereum/yellowpaper.svg)](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) -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 . +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 . 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. From 5f9fb10942e4c8a5521f2cf551343ac7575a59ad Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Thu, 2 Mar 2017 18:23:01 +0100 Subject: [PATCH 078/460] Provide anchor for alt link. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8a1b7805..fabebcb8 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,6 @@ [![Gitter](https://badges.gitter.im/ethereum/yellowpaper.svg)](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) -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 . +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. From a05003087536704d2578af1cfecebf7ae800264c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 21 Mar 2017 16:24:47 +0100 Subject: [PATCH 079/460] In evaluation of \Xi, drop the fourth element and extract the remaining gas from the machine state --- Paper.tex | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 11eca5e7..a7193097 100644 --- a/Paper.tex +++ b/Paper.tex @@ -850,7 +850,8 @@ \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 & X_{0,1,2,4}\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0, I)\big) \\ +\Xi(\boldsymbol{\sigma}, g, I) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ +(\boldsymbol{\sigma}, \boldsymbol{\mu}'\!, A, I'\!, \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ \boldsymbol{\mu}_g & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ @@ -871,7 +872,7 @@ \subsection{Execution Overview} (a, b, c) \cdot d & \equiv & (a, b, c, d) \end{eqnarray} -Note that we must drop the fourth value in the tuple returned by $X$ to correctly evaluate $\Xi$, hence the subscript $X_{0,1,2,4}$. +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}'$. $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. From ee5179bac97e89d5c9cd8dc7f6d9cab673892585 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 21 Mar 2017 16:25:26 +0100 Subject: [PATCH 080/460] Instead of concatenating a triple with an element, now we need to concatenate a quadruple with an element --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a7193097..07d327ef 100644 --- a/Paper.tex +++ b/Paper.tex @@ -869,7 +869,7 @@ \subsection{Execution Overview} where \begin{eqnarray} \mathbf{o} & \equiv & H(\boldsymbol{\mu}, I) \\ -(a, b, c) \cdot d & \equiv & (a, b, c, d) +(a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) \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}'$. From 77cf0a2c41a10117c5866a0369c9f9ac6f4fc729 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 23 Mar 2017 10:27:49 +0100 Subject: [PATCH 081/460] Make sure only one version of the protocol is described --- Paper.tex | 35 +++++++---------------------------- 1 file changed, 7 insertions(+), 28 deletions(-) diff --git a/Paper.tex b/Paper.tex index 11eca5e7..4dceed5d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -33,8 +33,6 @@ \definecolor{lightyellow}{rgb}{1,0.98,0.9} \definecolor{lightpink}{rgb}{1,0.94,0.95} -\newcommand{\firsthomesteadblock}{\ensuremath{N_H}} - \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} \newcommand*\Eg{e.g.\@\xspace} @@ -147,6 +145,8 @@ \subsection{Which History?} The scheme we use in order to generate consensus is a simplified version of the GHOST protocol introduced by \cite{cryptoeprint:2013:881}. This process is described in detail in section \ref{ch:ghost}. +Sometimes, a path follows a new protocol from a particular height. This document describes one version of the protocol. In order to follow back the history of a path, one might need to reference multiple versions of this document. + \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: @@ -233,14 +233,6 @@ \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} -\subsection{Homestead} \label{ch:homestead} - -A significant block number for compatibility with the public network is the block marking the transition between the {\it Frontier} and {\it Homestead} phases of the platform, which we denote with the symbol \firsthomesteadblock, defined thus -\begin{equation} -\firsthomesteadblock \equiv 1,\! 150,\! 000 -\end{equation} -The protocol was upgraded at this block, so this symbol appears in some equations to account for the changes. - \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: @@ -442,7 +434,6 @@ \subsubsection{Block Header Validity} \end{equation} \newcommand{\mindifficulty}{D_0} -\newcommand{\frontiermod}{\ensuremath{\varsigma_1}} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} \newcommand{\diffadjustment}{x} @@ -451,7 +442,6 @@ \subsubsection{Block Header Validity} \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_i = 0\\ -\text{max}\!\left(\mindifficulty, {P(H)_H}_d + \diffadjustment\times\frontiermod + \expdiffsymb \right) & \text{if} \quad H_i<\firsthomesteadblock\\ \text{max}\!\left(\mindifficulty, {P(H)_H}_d + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ \end{dcases} \end{equation} @@ -463,12 +453,6 @@ \subsubsection{Block Header Validity} \diffadjustment \equiv \left\lfloor\frac{{P(H)_H}_d}{2048}\right\rfloor \end{equation} \begin{equation} -\frontiermod \equiv \begin{cases} -1 & \text{if} \quad H_s < {P(H)_H}_s + 13 \\ --1 & \text{otherwise} \\ -\end{cases} -\end{equation} -\begin{equation} \homesteadmod \equiv \text{max}\left( 1 - \left\lfloor\frac{H_s - {P(H)_H}_s}{10}\right\rfloor, -99 \right) \end{equation} \begin{equation} @@ -561,11 +545,11 @@ \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 \wedge H_i \geq \firsthomesteadblock \\ 0 & \text{otherwise} \end{cases} \\ +{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_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 or before the {\it Homestead transition}. $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}. %todo Explain g_d reason? @@ -712,12 +696,10 @@ \section{Contract Creation} \label{ch:create} \begin{align} \quad g' &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ -g^{**} & \text{if} \quad g^{**} Date: Thu, 23 Mar 2017 13:24:58 +0100 Subject: [PATCH 082/460] Use bold font for \mu_s as in other occurrences. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 11eca5e7..722845c1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1762,12 +1762,12 @@ \subsection{Instruction Set} &&&& 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}_s[0] \mod 2^{160}]_c \rVert$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_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}_s[0] \mod 2^{160}]_c$ \\ +&&&& 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. \\ \bottomrule From 79ddb92a8c4cf386a61239f6660b0c619446ec86 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 23 Mar 2017 14:44:44 +0100 Subject: [PATCH 083/460] Zero-th power of zero Fixes #257 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 11eca5e7..c522d6a6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1615,7 +1615,7 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{0s: Stop and Arithmetic Operations}} \\ -\multicolumn{5}{l}{All arithmetic is modulo $2^{256}$ unless otherwise noted.} \vspace{5pt} \\ +\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} \\ 0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule From acfaf896ac005bcae8caf0e0f3dd0cf049c611c7 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 24 Mar 2017 19:43:16 +0100 Subject: [PATCH 084/460] Replace a broken link Fixes #247 --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 4314259f..f3c0ee9c 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -102,7 +102,7 @@ @InProceedings{miller1997future } @article{buterin2013ethereum, - url = {{http://ethereum.org/ethereum.html}}, + 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}}, From e90d9596f6f2759d8cafe699f45e2ed8f389f376 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thorkil=20V=C3=A6rge?= Date: Sun, 26 Mar 2017 13:19:28 +0200 Subject: [PATCH 085/460] Fix stack index error in SELFDESTRUCT SELFDESTRUCT sends balance to mu_s[0], not to mu_s[1]. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 11eca5e7..76f7160e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2037,7 +2037,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}[1] \mod 2^{160}] = \varnothing \\ +G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] = \varnothing \\ 0 & \text{otherwise} \end{cases}$ \\ \bottomrule From 8e8c7d6eb50caedf559c8101ec264df380d3fe22 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 30 Mar 2017 12:52:42 +0200 Subject: [PATCH 086/460] Turn an unused I' into underscore --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 07d327ef..25f85d33 100644 --- a/Paper.tex +++ b/Paper.tex @@ -851,7 +851,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}) \\ -(\boldsymbol{\sigma}, \boldsymbol{\mu}'\!, A, I'\!, \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ +(\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 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ From 5cd01fe6860fbbe9eb65b7d36f38c19fab5963e0 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Thu, 30 Mar 2017 13:06:17 +0200 Subject: [PATCH 087/460] underscore becomes standard ellision operator --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 25f85d33..cbe8e448 100644 --- a/Paper.tex +++ b/Paper.tex @@ -851,7 +851,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}) \\ -(\boldsymbol{\sigma}, \boldsymbol{\mu}'\!, A, \_, \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ +(\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 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ From d3bbc46f84a998d6d0d5c0590e157b73e1910783 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 25 Nov 2016 11:37:36 +0100 Subject: [PATCH 088/460] Update the fee schedule following EIP 160 https://github.com/ethereum/EIPs/issues/160 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7d3311ad..883d54c1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1478,7 +1478,7 @@ \section{Fee Schedule}\label{app:fees} $G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \\ $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}$ & 10 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\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_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ From a5a96d7f56e1208b73c6ab75342c747d3d61f76d Mon Sep 17 00:00:00 2001 From: Ian Sweet Date: Sat, 1 Apr 2017 15:06:46 -0400 Subject: [PATCH 089/460] Fix remaining issues from PR #167, namely equation 105 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7d3311ad..6bf4302c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -755,7 +755,7 @@ \section{Message Call} \label{ch:call} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ -(\boldsymbol{\sigma}^{**}, g^{**}, \mathbf{s}, \mathbf{o}) & \equiv & \begin{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 \\ From 8a6b0578393ae8af1c3133c400ad5cc249ee11a2 Mon Sep 17 00:00:00 2001 From: Justin Date: Mon, 10 Apr 2017 12:33:33 +0100 Subject: [PATCH 090/460] Fix typo: T_t should be T_\mathbf{t} Also cleanup nomenclature around byte sequences. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7d3311ad..06dfadab 100644 --- a/Paper.tex +++ b/Paper.tex @@ -161,7 +161,7 @@ \section{Conventions}\label{ch:conventions} 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. -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. +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}. @@ -282,9 +282,9 @@ \subsection{The Transaction} \label{ch:transaction} \mathbb{P}_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-series 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_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_t \neq \varnothing \\ \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} @@ -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 series. 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 series. 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. 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 e1bb9a07627736e4a2055fdc0438171d0f64f44a Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 12 Apr 2017 11:19:02 +0100 Subject: [PATCH 091/460] Fix typo (the => that) --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6bf4302c..ba81b803 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1274,7 +1274,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} -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 the 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} From c217d342e64b26303bf4be605418ff1afb06e87f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 9 May 2017 17:12:28 +0200 Subject: [PATCH 092/460] Remove a duplicate `otherwise` --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 37c1b196..501b59d5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1940,7 +1940,7 @@ \subsection{Instruction Set} &&&& $Z(\boldsymbol{\sigma}^*, \boldsymbol{\mu}, I) = \top$ 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, otherwise. \\ +&&&& created account. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule From d05682f9142b5fbfba0025b35326735bfadbc77c Mon Sep 17 00:00:00 2001 From: "Mr. Is" Date: Wed, 10 May 2017 08:20:34 -0500 Subject: [PATCH 093/460] Minor improvement of grammar, particularly comma use and that/which clause awkwardness. --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 37c1b196..cf1c0b7d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -63,7 +63,7 @@ \section{Introduction}\label{sec:introduction} -With ubiquitous internet connections in most places of the world, global information transmission has become incredibly cheap. Technology-rooted movements like Bitcoin have demonstrated, through the power of the default, consensus mechanisms and voluntary respect of the social contract that it is possible to use the internet to make a decentralised value-transfer system, shared across the world and virtually free to use. This system can be said to be a very specialised version of a cryptographically secure, transaction-based state machine. Follow-up systems such as Namecoin adapted this original ``currency application'' of the technology into other applications albeit rather simplistic ones. +With ubiquitous internet connections in most places of the world, global information transmission has become incredibly cheap. Technology-rooted movements like Bitcoin have demonstrated through the power of the default, consensus mechanisms, and voluntary respect of the social contract, that it is possible to use the internet to make a decentralised value-transfer system that can be shared across the world and virtually free to use. This system can be said to be a very specialised version of a cryptographically secure, transaction-based state machine. Follow-up systems such as Namecoin adapted this original ``currency application'' of the technology into other applications albeit rather simplistic ones. Ethereum is a project which attempts to build the generalised technology; technology on which all transaction-based state machine concepts may be built. Moreover it aims to provide to the end-developer a tightly integrated end-to-end system for building software on a hitherto unexplored compute paradigm in the mainstream: a trustful object messaging compute framework. @@ -308,8 +308,8 @@ \subsection{The Block} \label{ch:block} \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 proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally $H_m$. -\item[nonce] A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally $H_n$. +\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$. \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 42349211765ac30ab6cf6192adf3c578e0db3e8d Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 25 Nov 2016 12:12:27 +0100 Subject: [PATCH 094/460] EIP170: max code size --- Paper.tex | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6bf4302c..50ac2d1b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -695,14 +695,16 @@ \section{Contract Creation} \label{ch:create} \begin{align} \quad g' &\equiv \begin{cases} -0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +0 & \text{if} \quad F \\ g^{**} - c & \text{otherwise} \\ \end{cases} \\ \quad \boldsymbol{\sigma}' &\equiv \begin{cases} -\boldsymbol{\sigma} & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +\boldsymbol{\sigma} & \text{if} \quad F \\ \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} -\end{cases} +\end{cases} \\ +\nonumber \text{where} \\ +F &\equiv \big(\boldsymbol{\sigma}^{**} = \varnothing \ \vee\ g^{**} < c \ \vee\ |\mathbf{o}| \ge 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 4b127a811a2d85de76922cbc2c5cf751e8857787 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 21 Jun 2017 16:30:39 +0200 Subject: [PATCH 095/460] An abbreviation abbreviates but does not imply --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 37c1b196..21ee68f8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1934,7 +1934,7 @@ \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 implies: $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{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 9dde85e83ae844e71d0fc9c4cec94c9999770779 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Wed, 5 Jul 2017 12:02:36 +0200 Subject: [PATCH 096/460] Fix off-by-one. Should be strictly greater than the limit, the limit itself is acceptable. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 50ac2d1b..a9175e3f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -704,7 +704,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}| \ge 24576\big) +F &\equiv \big(\boldsymbol{\sigma}^{**} = \varnothing \ \vee\ g^{**} < c \ \vee\ |\mathbf{o}| \gt 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 5c91095f2797d7d878f62a32a0460eb6f7c08c00 Mon Sep 17 00:00:00 2001 From: Gav Wood Date: Wed, 5 Jul 2017 12:08:57 +0200 Subject: [PATCH 097/460] Use actual latex. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a9175e3f..f5d86e31 100644 --- a/Paper.tex +++ b/Paper.tex @@ -704,7 +704,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}| \gt 24576\big) +F &\equiv \big(\boldsymbol{\sigma}^{**} = \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 74d15d1fe7e1028ab1f63fa6686ec185440e3e57 Mon Sep 17 00:00:00 2001 From: likang Date: Mon, 7 Aug 2017 18:04:08 +0800 Subject: [PATCH 098/460] modify (136) --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8b6ce813..1a6bbaa4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -937,7 +937,7 @@ \subsection{The Execution Cycle} O\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \equiv & (\boldsymbol{\sigma}', \boldsymbol{\mu}', A', I) \\ \Delta & \equiv & \mathbf{\alpha}_w - \mathbf{\delta}_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}_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: From 53c7e58e82ed424ad59298cc677a97c7ccfe2853 Mon Sep 17 00:00:00 2001 From: Peng Wang Date: Wed, 9 Aug 2017 20:44:38 -0400 Subject: [PATCH 099/460] fixed a typo in equation (118): (\sigma, \mu', ...) -> (\sigma', \mu', ...) --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..f69b21f9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -835,7 +835,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}) \\ -(\boldsymbol{\sigma}, \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ +(\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 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ From a804f78b55c0987cc2390979be0f83040480ad3a Mon Sep 17 00:00:00 2001 From: midinpa Date: Wed, 6 Sep 2017 16:10:16 +0900 Subject: [PATCH 100/460] typo fixed (then => than) --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..e458bb7c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -888,7 +888,7 @@ \subsubsection{Exceptional Halting} \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 then 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 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. \subsubsection{Jump Destination Validity} From 56709c99fd29fb572af034f8cd8b7909a9900c4e Mon Sep 17 00:00:00 2001 From: 4000D Date: Tue, 12 Sep 2017 16:55:05 +0900 Subject: [PATCH 101/460] use parentheses for multiply --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..be8ff793 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2078,7 +2078,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 - 1) \cdot y, y) & \text{otherwise} \end{cases} \end{equation} \subsection{Dataset generation} From 096ab2bac9b3055aa78620c39677d08889b889d0 Mon Sep 17 00:00:00 2001 From: 4000D Date: Tue, 12 Sep 2017 16:55:33 +0900 Subject: [PATCH 102/460] account state order fixed --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index be8ff793..0e57e314 100644 --- a/Paper.tex +++ b/Paper.tex @@ -741,7 +741,7 @@ \section{Message Call} \label{ch:call} \end{equation} \begin{equation} \begin{cases} -\boldsymbol{\sigma}_1'[r] \equiv (v, 0, \mathtt{\tiny KEC}(()), \mathtt{\tiny TRIE}(\varnothing)) & \text{if} \quad \boldsymbol{\sigma}[r] = \varnothing \\ +\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} \end{cases} \end{equation} From 4eea25f64a43f3fcfa11b2c8eecb65b6c6d76a99 Mon Sep 17 00:00:00 2001 From: 4000D Date: Wed, 13 Sep 2017 15:29:00 +0900 Subject: [PATCH 103/460] fix typo --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 0e57e314..549ebab7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2082,7 +2082,7 @@ \subsection{Size of dataset and cache} \end{cases} \end{equation} \subsection{Dataset generation} -In order the generate the dataset we need the cache $\mathbf{c}$, which is an array of bytes. It depends on the cache size $c_{size}$ and the seed hash $\mathbf{s} \in \mathbb{B}_{32}$. +In order to generate the dataset we need the cache $\mathbf{c}$, which is an array of bytes. It depends on the cache size $c_{size}$ and the seed hash $\mathbf{s} \in \mathbb{B}_{32}$. \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} From 41f0c0dbefcaf2fb177e9fd8110cde107df5e3d7 Mon Sep 17 00:00:00 2001 From: Lane Rettig Date: Thu, 21 Sep 2017 14:05:29 -0400 Subject: [PATCH 104/460] fix small grammatical typo --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..76d7501f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -817,7 +817,7 @@ \subsection{Execution Environment} \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). \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 defined it as: +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: \begin{equation} (\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) \end{equation} From 04678b6089c155c108b05e15cbcaf8626262a06f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 16 Sep 2017 11:39:11 +1000 Subject: [PATCH 105/460] Footnote clarifying meaning of low-order 11 bits --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..ee46bfe6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -353,7 +353,7 @@ \subsubsection{Transaction Receipt} M(O) \equiv \bigvee_{t \in \{O_a\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) \end{equation} -where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence. Formally: +where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence./footnote{11 bits $= 2^2048$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: \begin{eqnarray} M_{3:2048}(\mathbf{x}: \mathbf{x} \in \mathbb{B}) & \equiv & \mathbf{y}: \mathbf{y} \in \mathbb{B}_{256} \quad \text{where:}\\ \mathbf{y} & = & (0, 0, ..., 0) \quad \text{except:}\\ From a12a2d9df62c135d9ebd1c2fc0cdd1f0b291c6aa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 16 Sep 2017 11:42:11 +1000 Subject: [PATCH 106/460] Rewording accumulation of nibbles keys and branches --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..18f88bd6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1315,7 +1315,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} In a manner similar to a radix tree, when the trie is traversed from root to leaf, one may build a single key-value pair. The key is accumulated through the traversal, acquiring a single nibble from each branch node (just as with a radix tree). Unlike a radix tree, in the case of multiple keys sharing the same prefix or in the case of a single key having a unique suffix, two optimising nodes are provided. Thus while traversing, one may potentially acquire multiple nibbles from each of the other two node types, extension and leaf. There are three kinds of nodes in the trie: \begin{description} \item[Leaf] A two-item structure whose first item corresponds to the nibbles in the key not already accounted for by the accumulation of keys and branches traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is required to be $true$. -\item[Extension] A two-item structure whose first item corresponds to a series of nibbles of size greater than one that are shared by at least two distinct keys past the accumulation of nibbles keys and branches as traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is required to be $false$. +\item[Extension] A two-item structure whose first item corresponds to a series of nibbles of size greater than one that are shared by at least two distinct keys past the accumulation of the keys of nibbles and the keys of branches as traversed from the root. The hex-prefix encoding method is used and the second parameter to the function is required to be $false$. \item[Branch] A 17-item structure whose first sixteen items correspond to each of the sixteen possible nibble values for the keys at this point in their traversal. The 17th item is used in the case of this being a terminator node and thus a key being ended at this point in its traversal. \end{description} From 4edf749d13e38551e3327e282c72da583e3c9dfe Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 16 Sep 2017 11:58:49 +1000 Subject: [PATCH 107/460] to proof [sic] that a correct DAG has been used --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..891ab544 100644 --- a/Paper.tex +++ b/Paper.tex @@ -479,7 +479,7 @@ \subsubsection{Block Header Validity} \end{equation} with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. -Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. +Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to prove that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. From 2f0949592e7b90948f098cdedccb94f68adb4aff Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 19 Oct 2017 14:31:11 +1100 Subject: [PATCH 108/460] \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 731c412672482aa86328dc62c5283cb3afda44d5 Mon Sep 17 00:00:00 2001 From: Ayrat Badykov Date: Thu, 19 Oct 2017 11:59:06 +0300 Subject: [PATCH 109/460] fix ommer reference --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..a4ba01d7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -290,7 +290,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{http://nonbinary.org/wiki/Gender_neutral_language#Family_Terms}}). 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 f4a09dc4bbf07798795247b564b20ab017e73b5a Mon Sep 17 00:00:00 2001 From: Nadir Akhtar Date: Thu, 26 Oct 2017 19:41:59 -0700 Subject: [PATCH 110/460] Changed one " to `` --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..0cc221ca 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2160,7 +2160,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 096539e26dd13325ef26973539ee61e26f3a3a6b Mon Sep 17 00:00:00 2001 From: nicksavers Date: Sat, 18 Nov 2017 19:45:49 +0100 Subject: [PATCH 111/460] Fix minGasLimit to 5000 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 37c1b196..2047d52a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -463,7 +463,7 @@ \subsubsection{Block Header Validity} \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 125000 +& & H_l \geqslant 5000 \end{eqnarray} $H_s$ is the timestamp of block $H$ and must fulfil the relation: From 0f5fd44388815f47cfcac6729389f8a07d30e751 Mon Sep 17 00:00:00 2001 From: Jaycen Horton Date: Mon, 20 Nov 2017 00:05:05 -0700 Subject: [PATCH 112/460] Update Paper.tex Change ECDSARESTORE to ECDSARECOVER to keep consistent with the following (and previous) defined terms --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..7a703406 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1397,7 +1397,7 @@ \section{Signing Transactions}\label{app:signing} It is assumed that the sender has a valid private key $p_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 ECDSARESTORE}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. +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 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}) \\ From 3d5c683c79c1d136e15e17d71fa75080fbb4754b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thorkil=20V=C3=A6rge?= Date: Mon, 11 Dec 2017 11:28:41 +0100 Subject: [PATCH 113/460] Fix minor spelling errors Fix capitalization of some instances of the word "Greek" --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1a6bbaa4..2925e169 100644 --- a/Paper.tex +++ b/Paper.tex @@ -153,13 +153,13 @@ \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 $\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. 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. -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 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. From 20edf349c0e18949f8aaea041f6d68b67e5370c6 Mon Sep 17 00:00:00 2001 From: Gav Date: Sat, 6 Jan 2018 16:19:03 +0100 Subject: [PATCH 114/460] Add license. --- LICENCE.md | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 9 ++- 2 files changed, 183 insertions(+), 1 deletion(-) create mode 100644 LICENCE.md diff --git a/LICENCE.md b/LICENCE.md new file mode 100644 index 00000000..22dc42ec --- /dev/null +++ b/LICENCE.md @@ -0,0 +1,175 @@ +## creative commons + +# Attribution-ShareAlike 4.0 International + +Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. + +### Using Creative Commons Public Licenses + +Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. + +* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors). + +* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees). + +## Creative Commons Attribution-ShareAlike 4.0 International Public License + +By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. + +### Section 1 – Definitions. + +a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. + +b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. + +c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License. + +d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. + +e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. + +f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. + +g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. + +h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. + +i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. + +j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. + +k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. + +l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. + +m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. + +### Section 2 – Scope. + +a. ___License grant.___ + + 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: + + A. reproduce and Share the Licensed Material, in whole or in part; and + + B. produce, reproduce, and Share Adapted Material. + + 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. + + 3. __Term.__ The term of this Public License is specified in Section 6(a). + + 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. + + 5. __Downstream recipients.__ + + A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. + + B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. + + C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. + + 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). + +b. ___Other rights.___ + + 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. + + 2. Patent and trademark rights are not licensed under this Public License. + + 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. + +### Section 3 – License Conditions. + +Your exercise of the Licensed Rights is expressly made subject to the following conditions. + +a. ___Attribution.___ + + 1. If You Share the Licensed Material (including in modified form), You must: + + A. retain the following if it is supplied by the Licensor with the Licensed Material: + + i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); + + ii. a copyright notice; + + iii. a notice that refers to this Public License; + + iv. a notice that refers to the disclaimer of warranties; + + v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; + + B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and + + C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. + + 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. + + 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. + +b. ___ShareAlike.___ + +In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. + +1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. + +2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. + +3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. + +### Section 4 – Sui Generis Database Rights. + +Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: + +a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; + +b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and + +c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. + +For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. + +### Section 5 – Disclaimer of Warranties and Limitation of Liability. + +a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__ + +b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__ + +c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. + +### Section 6 – Term and Termination. + +a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. + +b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: + + 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or + + 2. upon express reinstatement by the Licensor. + + For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. + +c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. + +d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. + +### Section 7 – Other Terms and Conditions. + +a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. + +b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.t stated herein are separate from and independent of the terms and conditions of this Public License. + +### Section 8 – Interpretation. + +a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. + +b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. + +c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. + +d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. + +``` +Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. + +Creative Commons may be contacted at [creativecommons.org](http://creativecommons.org/). +``` diff --git a/README.md b/README.md index fabebcb8..31f0fa54 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,14 @@ -# yellowpaper +# Ethereum Yellow Paper +[![License: CC BY-SA 4.0](https://img.shields.io/badge/License-CC%20BY--SA%204.0-lightgrey.svg)](https://creativecommons.org/licenses/by-sa/4.0/) [![Gitter](https://badges.gitter.im/ethereum/yellowpaper.svg)](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) +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)i version 4.0. + +## 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/) . 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. From b35d7ef4fcc0538195221061f7bbeb742c22dcf2 Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Sun, 7 Jan 2018 20:45:09 +0100 Subject: [PATCH 115/460] Remove accidental i from README --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 31f0fa54..0c6e11d3 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)i version 4.0. +It is free culture work, licensed under the Creative Commons Attribution Share-Alike (CC-BY-SA) version 4.0. ## Usage From 73cf3307bec2db0b29621e96a94623ed433802e7 Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Sun, 7 Jan 2018 21:04:40 +0100 Subject: [PATCH 116/460] Fix minGasLimit to 5000 mentioned in #393 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 41414fda..f6092bb0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -490,7 +490,7 @@ \subsubsection{Block Header Validity} & & 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 125000 \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 From d9cfed792680216d89d925b5d51cb30a4dc23469 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thorkil=20V=C3=A6rge?= Date: Tue, 16 Jan 2018 20:36:44 +0100 Subject: [PATCH 117/460] Update Paper.tex --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f6092bb0..5de2fb5f 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 the `recovery id', 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 837bdd048681a7e1f9ce62bf5ea1736b9a75022f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Dec 2016 19:59:35 +0100 Subject: [PATCH 118/460] EIP155: replay protection --- Paper.tex | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index f6092bb0..eace17dd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1404,7 +1404,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is the `recovery id', a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} @@ -1412,7 +1412,7 @@ \section{Signing Transactions}\label{app:signing} \begin{align} 0 < r &< \mathtt{\tiny secp256k1n} \\ 0 < s &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ -v &\in \{27,28\} +v &\in \{27,28,\mathtt{\tiny chain\_id} \times 2 + 35 , \mathtt{\tiny chain\_id} \times 2 + 36\} \end{align} where: \begin{align} @@ -1425,11 +1425,16 @@ \section{Signing Transactions}\label{app:signing} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} -The message hash, $h(T)$, to be signed is the Keccak hash of the transaction without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$: +The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{i}) & \text{if} \; T_t = 0\\ -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}) & \text{otherwise} +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{if} \; v \notin \{27, 28\}\\ +\end{cases} \\ +\nonumber \text{where} \\ +\nonumber \mathbf{p} & \equiv & \begin{cases} +T_{\mathbf{i}} & \text{if}\ T_t = 0 \\ +T_{\mathbf{d}} & \text{otherwise} \end{cases} \\ h(T) & \equiv & \mathtt{\small KEC}( L_S(T) ) \end{eqnarray} From c9ff18e7312a2fa8e3207c98a9c8f11bfc2ed17f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 25 Apr 2017 17:44:15 +0200 Subject: [PATCH 119/460] Normalizing the input of ECDSARECOVER function --- Paper.tex | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index eace17dd..0f173cb9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1429,7 +1429,7 @@ \section{Signing Transactions}\label{app:signing} \begin{eqnarray} L_S(T) & \equiv & \begin{cases} (T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ -(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{if} \; v \notin \{27, 28\}\\ +(T_n, T_p, T_g, T_t, T_v, \mathbf{p}, \mathtt{\tiny chain\_id}, (), ()) & \text{otherwise}\\ \end{cases} \\ \nonumber \text{where} \\ \nonumber \mathbf{p} & \equiv & \begin{cases} @@ -1446,9 +1446,13 @@ \section{Signing Transactions}\label{app:signing} \end{eqnarray} We may then define the sender function $S$ of the transaction as: -\begin{equation} -S(T) \equiv \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), T_w, T_r, T_s) \big) \big) -\end{equation} +\begin{eqnarray} +S(T) &\equiv& \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), v_0, T_r, T_s) \big) \big) \\ +v_0 &\equiv& \begin{cases} +T_w &\text{if}\ T_w\in\{27, 28\} \\ +28 - (T_w \bmod 2) &\text{otherwise} +\end{cases} +\end{eqnarray} The assertion that the sender of a signed transaction equals the address of the signer should be self-evident: \begin{equation} From db78ad41e27f35a9d9eaec581086c6721cac8af2 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 17:48:43 +0200 Subject: [PATCH 120/460] Remove spurious spaces --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 0f173cb9..f3b5ba1c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1404,7 +1404,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the sign and finiteness of the curve point; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The chain identifier is a constant natural number. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} @@ -1412,7 +1412,7 @@ \section{Signing Transactions}\label{app:signing} \begin{align} 0 < r &< \mathtt{\tiny secp256k1n} \\ 0 < s &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ -v &\in \{27,28,\mathtt{\tiny chain\_id} \times 2 + 35 , \mathtt{\tiny chain\_id} \times 2 + 36\} +v &\in \{27,28,\mathtt{\tiny chain\_id} \times 2 + 35, \mathtt{\tiny chain\_id} \times 2 + 36\} \end{align} where: \begin{align} @@ -1425,7 +1425,7 @@ \section{Signing Transactions}\label{app:signing} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} -The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: +The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} (T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\}\\ From b0a29defd89d2e163dde31d6081dfbdc1a0674ca Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 11:05:02 +0200 Subject: [PATCH 121/460] 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 7a009bf836c614dd3961a9598c79165afbc17390 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8C=BF=E5=93=A5?= Date: Thu, 18 Jan 2018 11:36:24 +0800 Subject: [PATCH 122/460] add Chinese version link in ReadMe.md add Chinese version link in ReadMe.md --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 0c6e11d3..709555e5 100644 --- a/README.md +++ b/README.md @@ -12,3 +12,6 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A 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. + +## Other language versions +- [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu From 55a76c84d264e4836d0a542a3b84ededc18cc5f8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 10:36:01 +1100 Subject: [PATCH 123/460] Add Davey2002_zbMATH01748069 --- Biblio.bib | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index f3c0ee9c..b22cb66d 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,3 +1,16 @@ +@Book{Davey2002_zbMATH01748069, + Author = {B.A. {Davey} and H.A. {Priestley}}, + Title = {{Introduction to lattices and order. 2nd ed.}}, + Edition = {2nd ed.}, + ISBN = {0-521-78451-4/pbk}, + Pages = {xii + 298}, + Year = {2002}, + Publisher = {Cambridge: Cambridge University Press}, + Language = {English}, + MSC2010 = {06-01}, + Zbl = {1002.06001}, +} + @Misc{cryptoeprint:2013:881, Note = {{http://eprint.iacr.org/}}, Url = {{Cryptology ePrint Archive, Report 2013/881}}, @@ -141,4 +154,4 @@ @article{FowlerNollVo1991FNVHash author = {Glenn Fowler, Landon Curt Noll, Phong Vo}, title = {{Fowler–Noll–Vo hash function}}, year = {{1991}}, -} \ No newline at end of file +} From 10036bf0b178b3069941f3de2c5f048b638df5e9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 10:38:30 +1100 Subject: [PATCH 124/460] \section{List of mathematical symbols} \bigvee --- Paper.tex | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..dbf1f657 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2211,4 +2211,14 @@ \subsection{Proof-of-work function} \end{cases} \end{equation} +\section{List of mathematical symbols}\label{app:symbols} +\begin{tabularx}{\textwidth}{lcX} +\toprule +Symbol & Latex Command & Description \\ +\midrule +\hypertarget{bigvee}{ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{zbMATH01748069}).}\\ +\bottomrule +\end{tabularx} + \end{document} From 16d5510f4d516698dcab82d35df665e03735d236 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 10:39:06 +1100 Subject: [PATCH 125/460] \cite{Davey2002_zbMATH01748069} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index dbf1f657..fceee8c1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2217,7 +2217,7 @@ \section{List of mathematical symbols}\label{app:symbols} Symbol & Latex Command & Description \\ \midrule \hypertarget{bigvee}{ -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{zbMATH01748069}).}\\ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).}\\ \bottomrule \end{tabularx} From b4b344520af8fb1ed51a8f39a6ecd42d5d78ad3a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:02:09 +1100 Subject: [PATCH 126/460] Options for hyperref, and \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} --- Paper.tex | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..2c7aa34a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1,6 +1,5 @@ \documentclass[9pt,oneside]{amsart} %\usepackage{tweaklist} -\usepackage{url} \usepackage{cancel} \usepackage{xspace} \usepackage{graphicx} @@ -20,6 +19,15 @@ \usepackage[usenames,dvipsnames]{xcolor} \usepackage{afterpage} \usepackage{tikz} +\usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} +%,pagebackref=true + +% I will insert other table packages in here after this is merged. + +%This should be the last package before \input{Version.tex} +\PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} +% "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . +% Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . \input{Version.tex} From 424455edca424e0ef6c6e0cf4dd8f9f6e4e977dc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:07:58 +1100 Subject: [PATCH 127/460] Prepend a hash with a backslash to pass hyperref --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2c7aa34a..1cf93218 100644 --- a/Paper.tex +++ b/Paper.tex @@ -298,7 +298,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} From f132070f3a179aed09a5a9fb557a42fc8a06d0da Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:25:51 +1100 Subject: [PATCH 128/460] Formatting packages --- Paper.tex | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..393504ba 100644 --- a/Paper.tex +++ b/Paper.tex @@ -21,6 +21,14 @@ \usepackage{afterpage} \usepackage{tikz} +% For formatting +%\usepackage{underscore} +%\usepackage{lipsum} % to generate filler text for testing of document rendering +\usepackage[english]{babel} +\usepackage[autostyle]{csquotes} +\MakeOuterQuote{"} +% Put before hyperref + \input{Version.tex} \newcommand{\hcancel}[1]{% From 27a0001b5450203572bcf44b8540ca43f5b24071 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:42:55 +1100 Subject: [PATCH 129/460] May as well comment out \lightpink if it's unused for performance reasons --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..d143f480 100644 --- a/Paper.tex +++ b/Paper.tex @@ -31,7 +31,7 @@ }% \definecolor{lightyellow}{rgb}{1,0.98,0.9} -\definecolor{lightpink}{rgb}{1,0.94,0.95} +%\definecolor{lightpink}{rgb}{1,0.94,0.95} \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} From 4915aeb56bc365fda8a084eccce17b2ab3e8fde6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 19 Jan 2018 17:45:21 +1100 Subject: [PATCH 130/460] not the least being Bitcoin --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba8d7c43..edfe21ec 100644 --- a/Paper.tex +++ b/Paper.tex @@ -51,7 +51,7 @@ %\pagecolor{lightpink} \begin{abstract} -The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not least Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. +The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not the least being Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. Ethereum implements this paradigm in a generalised manner. Furthermore it provides a plurality of such resources, each with a distinct state and operating code but able to interact through a message-passing framework with others. We discuss its design, implementation issues, the opportunities it provides and the future hurdles we envisage. \end{abstract} From 52f0b1d7607e04227e98b2aa9e143e551d95cdcf Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 15:39:33 +0100 Subject: [PATCH 131/460] Add a new element I_w in the input tuple I --- Paper.tex | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 5a3450f1..990ce1cb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -675,7 +675,8 @@ \section{Contract Creation} \label{ch:create} I_s & \equiv & s \\ I_v & \equiv & v \\ I_\mathbf{b} & \equiv & \mathbf{i} \\ -I_e & \equiv & e +I_e & \equiv & e \\ +I_w & \equiv & \top \end{eqnarray} $I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_H$ has no special treatment and is determined from the blockchain. @@ -770,6 +771,7 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ +I_w & \equiv & \top \\ \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} @@ -815,6 +817,7 @@ \subsection{Execution Environment} \item $I_\mathbf{b}$, the byte array that is the machine code to be executed. \item $I_H$, the block header of the present block. \item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item $I_w$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: From 219dd8cbf2cda383d2e54923f4442a11c1914111 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 15:45:26 +0100 Subject: [PATCH 132/460] Add a "write permission" argument to Theta --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 990ce1cb..693292d8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -585,7 +585,7 @@ \subsection{Execution} \begin{equation} (\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} \Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0) & \text{if} \quad T_t = \varnothing \\ -\Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0) & \text{otherwise} +\Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -720,7 +720,7 @@ \section{Message Call} \label{ch:call} Aside from evaluating to a new state and transaction substate, message calls also have an extra component---the output data denoted by the byte array $\mathbf{o}$. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e) +(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) \end{equation} Note that we need to differentiate between the value that is to be transferred, $v$, from the value apparent in the execution context, $\tilde{v}$, for the {\small DELEGATECALL} instruction. @@ -771,7 +771,7 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ -I_w & \equiv & \top \\ +I_w & \equiv & w \\ \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} @@ -1951,7 +1951,7 @@ \subsection{Instruction Set} \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[3] \dots (\boldsymbol{\mu}_\mathbf{s}[3] + \boldsymbol{\mu}_\mathbf{s}[4] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ &&&& $\boldsymbol{\mu}'_g \equiv \boldsymbol{\mu}_g + g'$ \\ @@ -1985,7 +1985,7 @@ \subsection{Instruction Set} \midrule 0xf2 & {\small CALLCODE} & 7 & 1 & Message-call into this account with an alternative account's code. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ &&&& same account as at present, simply that the code is overwritten.\\ @@ -2005,7 +2005,7 @@ \subsection{Instruction Set} &&&& argument is $\boldsymbol{\mu}_\mathbf{s}[2]$. As a result, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ in the definition of {\small CALL} \\ &&&& should respectively be replaced with $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& Otherwise exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_s, I_o, I_a, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_p, 0, I_v, \mathbf{i}, I_e + 1)\end{array} & \text{if} \quad I_v \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_s, I_o, I_a, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_p, 0, I_v, \mathbf{i}, I_e + 1, I_w)\end{array} & \text{if} \quad I_v \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the changes (in addition to that of the fourth parameter) to the second \\ &&&& and ninth parameters to the call $\Theta$.\\ &&&& This means that the recipient is in fact the same account as at present, simply\\ From acf26e6968d8da969744c8192a8eec15646ad594 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 16:06:11 +0100 Subject: [PATCH 133/460] Add "write permission" argument to \Lambda function --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 693292d8..57cbf914 100644 --- a/Paper.tex +++ b/Paper.tex @@ -584,7 +584,7 @@ \subsection{Execution} Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$ and substate $A$: \begin{equation} (\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} -\Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0) & \text{if} \quad T_t = \varnothing \\ +\Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ \Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -632,7 +632,7 @@ \section{Contract Creation} \label{ch:create} We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas and accrued transaction substate $(\boldsymbol{\sigma}', g', A)$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e) +(\boldsymbol{\sigma}', g', A) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -676,7 +676,7 @@ \section{Contract Creation} \label{ch:create} I_v & \equiv & v \\ I_\mathbf{b} & \equiv & \mathbf{i} \\ I_e & \equiv & e \\ -I_w & \equiv & \top +I_w & \equiv & w \end{eqnarray} $I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_H$ has no special treatment and is determined from the blockchain. @@ -1937,7 +1937,7 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ From fd9973dd4e6ead3dd6d78014207ec5316b5d5015 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 16:35:50 +0100 Subject: [PATCH 134/460] Add an exceptional halt for state changes during static calls --- Paper.tex | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 57cbf914..97086425 100644 --- a/Paper.tex +++ b/Paper.tex @@ -887,11 +887,22 @@ \subsubsection{Exceptional Halting} \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ ( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ -\lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad + \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ + \neg I_w \wedge W(w, \boldsymbol{\mu}) +\end{array} +\end{equation} +where +\begin{equation} +W(w, \boldsymbol{\mu}) \equiv +\begin{array}[t]{l} +w \in \{\text{\small CREATE}, \text{\small SSTORE}, \text{\small SELFDESTRUCT}\} \quad \vee \\ +\text{\small LOG0} \le w \wedge w \le \text{\small LOG4} \quad \vee \\ +w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge +\boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \end{array} \end{equation} -This states that the execution is in an exceptional halting state if there is insufficient gas, if the instruction is invalid (and therefore its $\delta$ subscript is undefined), if there are insufficient stack items, if a {\small JUMP}/{\small JUMPI} destination is invalid or the new stack size would be larger than 1024. The astute reader will realise that this implies that no instruction can, through its execution, cause an exceptional halt. +This states that the execution is in an exceptional halting state if there is insufficient gas, if the instruction is invalid (and therefore its $\delta$ subscript is undefined), if there are insufficient stack items, if a {\small JUMP}/{\small JUMPI} destination is invalid, the new stack size would be larger than 1024 or state modification is attempted during a static call. The astute reader will realise that this implies that no instruction can, through its execution, cause an exceptional halt. \subsubsection{Jump Destination Validity} From 7a491361f2360e0646d000f7501adeadd5c0083c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 17 Feb 2017 17:54:22 +0100 Subject: [PATCH 135/460] Specify STATICCALL --- Paper.tex | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Paper.tex b/Paper.tex index 97086425..f740a54d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2022,6 +2022,14 @@ \subsection{Instruction Set} &&&& This means that the recipient is in fact the same account as at present, simply\\ &&&& that the code is overwritten {\it and} the context is almost entirely identical.\\ \midrule +0xfa & {\small STATICCALL} & 6 & 1 & Static message-call into an account. \\ +&&&& Exactly equivalent to {\small CALL} except: \\ +&&&& The argument $\boldsymbol{\mu}_\mathbf{s}[2]$ is replaced with $0$. \\ +&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and + $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ +&&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ +&&&& The last argument of $\Theta$ is $\bot$. \\ +\midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ From 85042b8c5add6be9cb757279d8c5231d465304ae Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 15:40:05 +0200 Subject: [PATCH 136/460] Adjust white spaces --- Paper.tex | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index f740a54d..86886ec5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -893,12 +893,10 @@ \subsubsection{Exceptional Halting} \end{equation} where \begin{equation} -W(w, \boldsymbol{\mu}) \equiv -\begin{array}[t]{l} +W(w, \boldsymbol{\mu}) \equiv \begin{array}[t]{l} w \in \{\text{\small CREATE}, \text{\small SSTORE}, \text{\small SELFDESTRUCT}\} \quad \vee \\ \text{\small LOG0} \le w \wedge w \le \text{\small LOG4} \quad \vee \\ -w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge -\boldsymbol{\mu}_\mathbf{s}[2] \neq 0 +w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \end{array} \end{equation} @@ -2025,8 +2023,7 @@ \subsection{Instruction Set} 0xfa & {\small STATICCALL} & 6 & 1 & Static message-call into an account. \\ &&&& Exactly equivalent to {\small CALL} except: \\ &&&& The argument $\boldsymbol{\mu}_\mathbf{s}[2]$ is replaced with $0$. \\ -&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and - $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ +&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ \midrule From 1c655cf9cbeebf1981136e29cd9b3caef2d2d377 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 16:48:27 +0100 Subject: [PATCH 137/460] EIP161a: change the initial nonce of an account --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3b4987df..beaa4cd7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -642,12 +642,12 @@ \section{Contract Creation} \label{ch:create} where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$ and $\boldsymbol{\sigma}[x]$ is the address state of $x$ or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. -The account's nonce is initially defined as zero, the balance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender's balance is also reduced by the value passed. Thus the mutated state becomes $\boldsymbol{\sigma}^*$: +The account's nonce is initially defined as one, the balance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender's balance is also reduced by the value passed. Thus the mutated state becomes $\boldsymbol{\sigma}^*$: \begin{equation} \boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except:} \end{equation} \begin{eqnarray} -\boldsymbol{\sigma}^*[a] &\equiv& \big( 0, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[a] &\equiv& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ \boldsymbol{\sigma}^*[s]_b &\equiv& \boldsymbol{\sigma}[s]_b - v \end{eqnarray} From 405cac4e48c2f5f0f2f7f71bf2139e44fc70eb2c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:06:08 +0100 Subject: [PATCH 138/460] EIP 161: Define when an account state is empty --- Paper.tex | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Paper.tex b/Paper.tex index beaa4cd7..424ab7bb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -233,6 +233,11 @@ \subsection{World State} \label{ch:state} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} +An account is \textit{empty} when it has no code, zero nonce and zero balance: +\begin{equation} +\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 +\end{equation} + \subsection{The Transaction} \label{ch:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: From 0d26ae7b85a813ccdb8b66387b9f4a9c352b440b Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:10:35 +0100 Subject: [PATCH 139/460] EIP 161: Define when an account is dead --- Paper.tex | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Paper.tex b/Paper.tex index 424ab7bb..313f6910 100644 --- a/Paper.tex +++ b/Paper.tex @@ -238,6 +238,11 @@ \subsection{World State} \label{ch:state} \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} +An account is \textit{dead} when its account state is non-existent or empty: +\begin{equation} +\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) +\end{equation} + \subsection{The Transaction} \label{ch:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: From 3ee54d98378e309abcdbdd4aeea3cece93d3d38e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 17:25:39 +0100 Subject: [PATCH 140/460] EIP161b: CALL and SUICIDE gas change --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 313f6910..019499a4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1995,7 +1995,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}] = \varnothing \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma},\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule @@ -2038,7 +2038,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} -G_{newaccount} & \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] = \varnothing \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \bottomrule From 616e3aef1c45ef86c072551b3ff58d8caa35f277 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 19:15:21 +0100 Subject: [PATCH 141/460] EIP161.c --- Paper.tex | 47 ++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 38 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index 019499a4..095ce1a8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -625,7 +625,8 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that appear in the self-destruct set: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \\ +\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} And finally, we specify $\Upsilon^g$, the total gas used in this transaction and $\Upsilon^\mathbf{l}$, the logs created by this transaction: @@ -658,7 +659,11 @@ \section{Contract Creation} \label{ch:create} \end{equation} \begin{eqnarray} \boldsymbol{\sigma}^*[a] &\equiv& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ -\boldsymbol{\sigma}^*[s]_b &\equiv& \boldsymbol{\sigma}[s]_b - v +\boldsymbol{\sigma}^*[s] &\equiv& \begin{cases} +\varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ +\mathbf{a}^* & \text{otherwise} +\end{cases} \\ +\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_n, \boldsymbol{\sigma}[s]_b - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_c) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: @@ -711,6 +716,8 @@ \section{Contract Creation} \label{ch:create} \quad \boldsymbol{\sigma}' &\equiv \begin{cases} \boldsymbol{\sigma} & \text{if} \quad F \\ \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ +\quad\boldsymbol{\sigma}'[a] = \varnothing & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^{**}, a) \\ +\boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ \nonumber \text{where} \\ @@ -744,17 +751,27 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma}_1 \equiv \boldsymbol{\sigma}_1' \quad \text{except:} \\ \end{equation} \begin{equation} -\boldsymbol{\sigma}_1[s]_b \equiv \boldsymbol{\sigma}_1'[s]_b - v +\boldsymbol{\sigma}_1[s] \equiv \begin{cases} +\varnothing & \text{if}\ \boldsymbol{\sigma}_1'[s] = \varnothing \ \wedge\ v = 0 \\ +\mathbf{a}_1 &\text{otherwise} +\end{cases} +\end{equation} +\begin{equation} +\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_n, \boldsymbol{\sigma}_1'[s]_b - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_c) \end{equation} \begin{equation} \text{and}\quad \boldsymbol{\sigma}_1' \equiv \boldsymbol{\sigma} \quad \text{except:} \\ \end{equation} \begin{equation} \begin{cases} -\boldsymbol{\sigma}_1'[r] \equiv (0, v, \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}(())) & \text{if} \quad \boldsymbol{\sigma}[r] = \varnothing \\ -\boldsymbol{\sigma}_1'[r]_b \equiv \boldsymbol{\sigma}[r]_b + v & \text{otherwise} +\boldsymbol{\sigma}_1'[r] \equiv (0, v, \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}(())) & \text{if} \quad \boldsymbol{\sigma}[r] = \varnothing \wedge v \neq 0 \\ +\boldsymbol{\sigma}_1'[r] \equiv \varnothing & \text{if}\quad \boldsymbol{\sigma}[r] = \varnothing \wedge v = 0 \\ +\boldsymbol{\sigma}_1'[r] \equiv \mathbf{a}_1' & \text{otherwise} \end{cases} \end{equation} +\begin{equation} +\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) +\end{equation} The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). @@ -1029,10 +1046,16 @@ \subsection{Reward Application} The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: \begin{eqnarray} +\\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ \boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ \forall_{U \in B_\mathbf{U}}: \\ \nonumber - \boldsymbol{\sigma}'[U_c]_b & = & \boldsymbol{\sigma}[U_c]_b + (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b +\boldsymbol{\sigma}'[U_c] & = & \begin{cases} +\varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ +\mathbf{a}' &\text{otherwise} +\end{cases} \\ +\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_c]_n, \boldsymbol{\sigma}[U_c]_b + R, \boldsymbol{\sigma}[U_c]_\mathbf{s}, \boldsymbol{\sigma}[U_c]_c) \\ +R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. @@ -2031,16 +2054,22 @@ \subsection{Instruction Set} \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ &&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ -&&&& $\boldsymbol{\sigma}'[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_b \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_b + \boldsymbol{\sigma}[I_a]_b$ \\ -&&&& $\boldsymbol{\sigma}'[I_a]_b \equiv 0$ \\ +&&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} +\varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_a]_b = 0\\ +(\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + \boldsymbol{\sigma}[I_a]_b, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{if}\ r \neq I_a \\ +(\boldsymbol{\sigma}[r]_n, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{otherwise} +\end{cases}$\\ +&&&& where $r = \boldsymbol{\mu}_\mathbf{s}[0] \bmod 2^{160}$\\ +&&&& $\boldsymbol{\sigma}'[I_a]_b = 0$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} -G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0 \\ +G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0$ \\ \bottomrule \end{tabular*} From 0aed5a9d20d70a3fb78e66c5991c5b1d10ce47e3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 5 Dec 2016 21:45:34 +0100 Subject: [PATCH 142/460] EIP 161: Keep the touched accounts in the substate --- Paper.tex | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/Paper.tex b/Paper.tex index 095ce1a8..ba990f64 100644 --- a/Paper.tex +++ b/Paper.tex @@ -541,14 +541,14 @@ \section{Transaction Execution} \label{ch:transactions} \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} -A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_r) +A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) \end{equation} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. -For brevity, we define the empty substate $A^0$ to have no self-destructs, no logs and a zero refund balance: +We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} -A^0 \equiv (\varnothing, (), 0) +A^0 \equiv (\varnothing, (), \{\}, 0) \end{equation} \subsection{Execution} @@ -679,7 +679,7 @@ \section{Contract Creation} \label{ch:create} Finally, the account is initialised through the execution of the initialising EVM code $\mathbf{i}$ according to the execution model (see section \ref{ch:model}). Code execution can effect several events that are not internal to the execution state: the account's storage can be altered, further accounts can be created and further message calls can be made. As such, the code execution function $\Xi$ evaluates to a tuple of the resultant state $\boldsymbol{\sigma}^{**}$, available gas remaining $g^{**}$, the accrued substate $A$ and the body code of the account $\mathbf{o}$. \begin{equation} -(\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I) \\ +(\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: \begin{eqnarray} @@ -785,11 +785,11 @@ \section{Message Call} \label{ch:call} g^{**} & \text{otherwise} \end{cases} \\ \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} -\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 1 \\ -\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 2 \\ -\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 3 \\ -\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I) & \text{if} \quad r = 4 \\ -\Xi(\boldsymbol{\sigma}_1, g, I) & \text{otherwise} \end{cases} \\ +\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 1 \\ +\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 2 \\ +\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 3 \\ +\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 4 \\ +\Xi(\boldsymbol{\sigma}_1, g, I, T) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ I_p & \equiv & p \\ @@ -797,6 +797,7 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ +T & \equiv & \{s, r\} \\ \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} @@ -849,10 +850,10 @@ \subsection{Execution Environment} (\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) \end{equation} -where we will remember that $A$, the accrued substate is defined as the tuple of the suicides set $\mathbf{s}$, the log series $\mathbf{l}$ and the refunds $r$: +where we will remember that $A$, the accrued substate is defined as the tuple of the suicides set $\mathbf{s}$, the log series $\mathbf{l}$, the touched accounts $\mathbf{t}$ and the refunds $r$: \begin{equation} -A \equiv (\mathbf{s}, \mathbf{l}, r) +A \equiv (\mathbf{s}, \mathbf{l}, \mathbf{t}, r) \end{equation} \subsection{Execution Overview} @@ -861,7 +862,7 @@ \subsection{Execution Overview} The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} -\Xi(\boldsymbol{\sigma}, g, I) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ +\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ (\boldsymbol{\sigma}, \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ \boldsymbol{\mu}_g & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ @@ -1376,7 +1377,7 @@ \section{Precompiled Contracts}\label{app:precompiled} For each precompiled contract, we make use of a template function, $\Xi_{\mathtt{PRE}}$, which implements the out-of-gas checking. \begin{equation} -\Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I) \equiv \begin{cases} +\Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} (\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ (\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} \end{equation} @@ -1978,7 +1979,8 @@ \subsection{Instruction Set} &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ &&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ -&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ +&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ +&&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ &&&& $Z(\boldsymbol{\sigma}^*, \boldsymbol{\mu}, I) = \top$ or $I_e = 1024$ \\ From e5d5f4095117b44b7555ded25f31ae5c1f377634 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 6 Dec 2016 10:19:56 +0100 Subject: [PATCH 143/460] EIP161.d empty, touched accounts are deleted at the end of a transaction --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba990f64..b55caf08 100644 --- a/Paper.tex +++ b/Paper.tex @@ -622,7 +622,7 @@ \subsection{Execution} m & \equiv & {B_H}_c \end{eqnarray} -The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that appear in the self-destruct set: +The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ \forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \\ From 095faa5e991078adc904d9dd50a792d8f153eb00 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 9 Dec 2016 12:30:37 +0100 Subject: [PATCH 144/460] EIP 161: Improve local layouts --- Paper.tex | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index b55caf08..0e6eab60 100644 --- a/Paper.tex +++ b/Paper.tex @@ -235,12 +235,12 @@ \subsection{World State} \label{ch:state} An account is \textit{empty} when it has no code, zero nonce and zero balance: \begin{equation} -\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 +\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} An account is \textit{dead} when its account state is non-existent or empty: \begin{equation} -\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \equiv \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) +\mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} \subsection{The Transaction} \label{ch:transaction} @@ -783,13 +783,13 @@ \section{Message Call} \label{ch:call} g' & \equiv & \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ g^{**} & \text{otherwise} -\end{cases} \\ +\end{cases} \\ \nonumber \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} -\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 1 \\ -\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 2 \\ -\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 3 \\ -\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, T) & \text{if} \quad r = 4 \\ -\Xi(\boldsymbol{\sigma}_1, g, I, T) & \text{otherwise} \end{cases} \\ +\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 1 \\ +\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 2 \\ +\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ +\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ +\Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ I_p & \equiv & p \\ @@ -797,7 +797,8 @@ \section{Message Call} \label{ch:call} I_s & \equiv & s \\ I_v & \equiv & \tilde{v} \\ I_e & \equiv & e \\ -T & \equiv & \{s, r\} \\ +\mathbf{t} & \equiv & \{s, r\} \\ +\\ \nonumber \text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c \end{eqnarray} From eef3de9f0b2891158462205f9620bd62edec0839 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 14:42:56 +0100 Subject: [PATCH 145/460] EIP 161: Note precompiled contracts can have empty account states --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 0e6eab60..f2c7620a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -237,6 +237,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 \end{equation} +Even callable precompiled contracts can have an empty account state. This is because their account states do not usually contain the code describing its behavior. An account is \textit{dead} when its account state is non-existent or empty: \begin{equation} From 79f18b01ae86cee855de72f7803d39681d981fe7 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 11 Apr 2017 14:26:47 +0200 Subject: [PATCH 146/460] EIP161: document the anomaly The description is based on https://github.com/ethereum/go-ethereum/pull/3341#discussion_r89548318 --- Paper.tex | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f2c7620a..f429fff2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1378,7 +1378,7 @@ \subsection{Trie Database} \section{Precompiled Contracts}\label{app:precompiled} For each precompiled contract, we make use of a template function, $\Xi_{\mathtt{PRE}}$, which implements the out-of-gas checking. -\begin{equation} +\begin{equation} \label{eq:pre} \Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} (\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ (\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} @@ -2263,4 +2263,10 @@ \subsection{Proof-of-work function} \end{cases} \end{equation} +\section{Anomalies on the Main Network} + +\subsection{Deletion of an Account Dispite Out-of-gas} + +At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. + \end{document} From abf07356cacc4ebaee3c75ad33b7cc00b382b423 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 14:35:35 +0200 Subject: [PATCH 147/460] Add a space --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f429fff2..54e7c2c8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2022,7 +2022,7 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma},\boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule From cedfe274edb4181ea2e4a2d058f45e8aeddfb758 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 14:48:12 +0200 Subject: [PATCH 148/460] A more uniform notation for the empty set --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 54e7c2c8..365ceb5c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -549,7 +549,7 @@ \subsection{Substate} We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} -A^0 \equiv (\varnothing, (), \{\}, 0) +A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} \subsection{Execution} From ef560d24d1881e7124a4d5a6ff367a2bc3fb1fb2 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 14:51:00 +0200 Subject: [PATCH 149/460] A partial overwriting is stated with = not with \equiv --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 365ceb5c..2a61593b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -626,8 +626,8 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \\ -\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & \equiv & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} And finally, we specify $\Upsilon^g$, the total gas used in this transaction and $\Upsilon^\mathbf{l}$, the logs created by this transaction: From 9b6bc93b137f599f95421b76e8aef6e7098ae6ef Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 15:11:07 +0200 Subject: [PATCH 150/460] In an account state, the storage root comes before the code This has to be fixed in earlier versions as well --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2a61593b..31c71d43 100644 --- a/Paper.tex +++ b/Paper.tex @@ -659,8 +659,8 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except:} \end{equation} \begin{eqnarray} -\boldsymbol{\sigma}^*[a] &\equiv& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ -\boldsymbol{\sigma}^*[s] &\equiv& \begin{cases} +\boldsymbol{\sigma}^*[a] &=& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[s] &=& \begin{cases} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} \end{cases} \\ From dc9df4e128120c820d94bd0d09fc337da172a778 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 11 May 2017 15:21:47 +0200 Subject: [PATCH 151/460] Format --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 31c71d43..a3664341 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1051,8 +1051,8 @@ \subsection{Reward Application} \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ -\forall_{U \in B_\mathbf{U}}: \\ \nonumber +\qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ +\qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber \boldsymbol{\sigma}'[U_c] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} From 33baf34ac2bd97177f18a81d2bdc4697d932a450 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 3 Mar 2017 15:00:30 +0100 Subject: [PATCH 152/460] EIP 101: Add EXPMOD precompile --- Paper.tex | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/Paper.tex b/Paper.tex index 2d121963..579e4c7f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -791,6 +791,7 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 2 \\ \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ @@ -1438,6 +1439,32 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one. +The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. +The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. +These two words are followed by $B$ and $E$; and the rest of the input is interpreted as the third non-negative integer $M$. +All non-negative integers $B$, $E$ $M$ are encoded as byte sequences in the big-endian way. + +\begin{eqnarray} +\Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ +\ell_B &=& I_\mathbf{d}[0..31] \\ +B &=& I_\mathbf{d}[32..(31 + \ell_B)] \\ +\ell_E &=& I_\mathbf{d}[(32 + \ell_B)..(63 + \ell_B)] \\ +E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ +M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 32 + \ell_B \quad \vee \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ +g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ +\mathbf{o} &=& +\begin{cases} + () & \text{if} \ M = 0 \\ + B ^ E \bmod M \in \mathbb{B}_\ell & \text{otherwise} +\end{cases} \\ +\ell &=& +\begin{cases} +0 &\text{if}\ M = 0 \quad \vee \quad {B ^ E} \bmod M = 0 \\ +\lfloor \log_8(B ^ E \bmod M) \rfloor + 1 & \text{otherwise} +\end{cases} +\end{eqnarray} \section{Signing Transactions}\label{app:signing} @@ -1550,6 +1577,9 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ +$G_{modexpbase}$ & 45 & Payment for the precompiled exponention under modulo. \\ +$G_{arithword}$ & 6 & Paid for each word used in precompiled contracts for arbitrary precision arighmetics.\\ +$G_{quaddivisor}$ & 32 & The quadratic coefficient of the input sizes of multiplication and division precompiled contracts. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From 2059e4a35fa056b35ecab6bd066cfedf155f214c Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 3 Mar 2017 15:13:06 +0100 Subject: [PATCH 153/460] EIP 101: simplify a formula A \/ B into B, because A implies B. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 579e4c7f..6a82b711 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1452,7 +1452,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \ell_E &=& I_\mathbf{d}[(32 + \ell_B)..(63 + \ell_B)] \\ E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 32 + \ell_B \quad \vee \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ \mathbf{o} &=& \begin{cases} From 80b269a4075ea104999842c7b9d7f3d943cea198 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 17:57:02 +0100 Subject: [PATCH 154/460] EIP 101: change the layout of the EXPMOD arguments This change is introduced in: https://github.com/ethereum/EIPs/pull/198/commits/60fe6515378aca6c9d1acb4f84d2f0b2a180abe8 --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6a82b711..93e570b9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1448,8 +1448,8 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ \ell_B &=& I_\mathbf{d}[0..31] \\ -B &=& I_\mathbf{d}[32..(31 + \ell_B)] \\ -\ell_E &=& I_\mathbf{d}[(32 + \ell_B)..(63 + \ell_B)] \\ +\ell_E &=& I_\mathbf{d}[32..63] \\ +B &=& I_\mathbf{d}[64..(63 + \ell_B)] \\ E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ From fa302f69f24b2d822cbee86d286c957693714d8d Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 19:04:02 +0100 Subject: [PATCH 155/460] EIP101: clarify the argument parsing --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 93e570b9..ea8ad6b6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1447,12 +1447,12 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ -\ell_B &=& I_\mathbf{d}[0..31] \\ -\ell_E &=& I_\mathbf{d}[32..63] \\ -B &=& I_\mathbf{d}[64..(63 + \ell_B)] \\ -E &=& I_\mathbf{d}[(64 + \ell_B)..(63 + \ell_B + \ell_E)] \\ -M &=& I_\mathbf{d}[(64 + \ell_B + \ell_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + \ell_B + \ell_E \\ +l_B &=& I_\mathbf{d}[0..31] \in \mathbb{P}_{256} \\ +l_E &=& I_\mathbf{d}[32..63] \in \mathbb{P}_{256} \\ +B &=& I_\mathbf{d}[64..(63 + l_B)] \\ +E &=& I_\mathbf{d}[(64 + l_B)..(63 + l_B + l_E)] \\ +M &=& I_\mathbf{d}[(64 + l_B + l_E)..(|I_\mathbf{d}| - 1)] \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E \\ g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ \mathbf{o} &=& \begin{cases} From 7f4b25ce818a1422475907e9f4b4d5e459955a1d Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 19:16:55 +0100 Subject: [PATCH 156/460] EIP101: EXPMOD throws if M <= E This follows the change in https://github.com/ethereum/EIPs/pull/198/commits/c4a771ed3421b1840c3a9d77fbac05b8b58ad2c4 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ea8ad6b6..3cc06974 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1452,7 +1452,7 @@ \section{Precompiled Contracts}\label{app:precompiled} B &=& I_\mathbf{d}[64..(63 + l_B)] \\ E &=& I_\mathbf{d}[(64 + l_B)..(63 + l_B + l_E)] \\ M &=& I_\mathbf{d}[(64 + l_B + l_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E\,\vee\,M\le B \\ g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ \mathbf{o} &=& \begin{cases} From 20c217a590082c39eef1017a20de93171a701343 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 24 Apr 2017 14:28:06 +0200 Subject: [PATCH 157/460] Reformulate EXPMOD as https://github.com/ethereum/EIPs/pull/198 specifies --- Paper.tex | 39 ++++++++++++++------------------------- 1 file changed, 14 insertions(+), 25 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3cc06974..188cc62d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1439,30 +1439,21 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} -The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one. -The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. -The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. -These two words are followed by $B$ and $E$; and the rest of the input is interpreted as the third non-negative integer $M$. -All non-negative integers $B$, $E$ $M$ are encoded as byte sequences in the big-endian way. +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is ???. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. \begin{eqnarray} -\Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:}\\ -l_B &=& I_\mathbf{d}[0..31] \in \mathbb{P}_{256} \\ -l_E &=& I_\mathbf{d}[32..63] \in \mathbb{P}_{256} \\ -B &=& I_\mathbf{d}[64..(63 + l_B)] \\ -E &=& I_\mathbf{d}[(64 + l_B)..(63 + l_B + l_E)] \\ -M &=& I_\mathbf{d}[(64 + l_B + l_E)..(|I_\mathbf{d}| - 1)] \\ -\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}, g, I) &\equiv& (\varnothing, 0, A^0, ()) \quad \text{if} \quad |I_\mathbf{d}| < 64 + l_B + l_E\,\vee\,M\le B \\ -g_r &=& G_{modexpbase} + G_{arithword} \Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil + |M|^2 |E| / G_{quaddivisor} \\ -\mathbf{o} &=& -\begin{cases} - () & \text{if} \ M = 0 \\ - B ^ E \bmod M \in \mathbb{B}_\ell & \text{otherwise} -\end{cases} \\ -\ell &=& -\begin{cases} -0 &\text{if}\ M = 0 \quad \vee \quad {B ^ E} \bmod M = 0 \\ -\lfloor \log_8(B ^ E \bmod M) \rfloor + 1 & \text{otherwise} +\Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ +g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ +\ell_B &\equiv& i[0..31] \\ +\ell_E &\equiv& i[32..63] \\ +\ell_M &\equiv& i[64..95] \\ +B &\equiv& i[96..(95+\ell_B)] \\ +E &\equiv& i[(96+\ell_B)..(95+\ell_B+\ell_E)] \\ +M &\equiv& i[(96+\ell_B+\ell_E)..(95+\ell_B+\ell_E+\ell_M)] \\ +i[x] &\equiv& \begin{cases} +I_{\mathbf d}[x] &\text{if}\ x < |I_{\mathbf d}| \\ +0 &\text{otherwise} \end{cases} \end{eqnarray} @@ -1577,9 +1568,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ -$G_{modexpbase}$ & 45 & Payment for the precompiled exponention under modulo. \\ -$G_{arithword}$ & 6 & Paid for each word used in precompiled contracts for arbitrary precision arighmetics.\\ -$G_{quaddivisor}$ & 32 & The quadratic coefficient of the input sizes of multiplication and division precompiled contracts. \\ +$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From c5511119de12c7d7708d46fd45d09d7b0d3e74fe Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 24 Apr 2017 14:42:40 +0200 Subject: [PATCH 158/460] Specify modulo zero --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 188cc62d..8760bbd9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1439,7 +1439,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} -The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is ???. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ From 44658b89db94a9f9e3aaafc36e0f65cfaeb33e45 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 15:29:49 +0200 Subject: [PATCH 159/460] EIP 101: remove spurious spaces --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8760bbd9..aaa18452 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1439,7 +1439,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} -The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. +The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ @@ -1568,7 +1568,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ -$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ +$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From d69ed5da6fd4798de78db6947564e213ae6ed5aa Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 24 May 2017 20:26:34 +0200 Subject: [PATCH 160/460] Update gas costs according to https://github.com/ethereum/EIPs/commit/7138d54 --- Paper.tex | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index aaa18452..519dc002 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1443,7 +1443,12 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +\ell'_E &=& \begin{cases} +0 & \text{if}\ \ell_E\le 256\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 256 \wedge E \neq 0 \\ +8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{otherwise} \\ +\end{cases} \\ \mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ \ell_B &\equiv& i[0..31] \\ \ell_E &\equiv& i[32..63] \\ @@ -1568,7 +1573,7 @@ \section{Fee Schedule}\label{app:fees} $G_{sha3word}$ & 6 & Paid for each word (rounded up) for input data to a {\small SHA3} operation. \\ $G_{copy}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\ $G_{blockhash}$ & 20 & Payment for {\small BLOCKHASH} operation. \\ -$G_{quaddivisor}$ & 20 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ +$G_{quaddivisor}$ & 100 & The quadratic coefficient of the input sizes of the exponation-over-modulo precompiled contract. \\ %extern u256 const c_copyGas; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added. \bottomrule From 93fb950e36658d72d24df57acc78f9c71725f7cc Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 26 May 2017 13:31:37 +0200 Subject: [PATCH 161/460] Fill in a corner case --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 519dc002..a1c763f5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1447,7 +1447,8 @@ \section{Precompiled Contracts}\label{app:precompiled} \ell'_E &=& \begin{cases} 0 & \text{if}\ \ell_E\le 256\wedge E=0 \\ \lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 256 \wedge E \neq 0 \\ -8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{otherwise} \\ +8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 256 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ +8(\ell_E - 32) & \text{otherwise} \\ \end{cases} \\ \mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ \ell_B &\equiv& i[0..31] \\ From 3344c5d0718dd45a3f9761fec78a2db2994670b8 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 26 May 2017 14:38:03 +0200 Subject: [PATCH 162/460] Fix the length constant from bits to bytes --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a1c763f5..8b234c2b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1445,9 +1445,9 @@ \section{Precompiled Contracts}\label{app:precompiled} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ \ell'_E &=& \begin{cases} -0 & \text{if}\ \ell_E\le 256\wedge E=0 \\ -\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 256 \wedge E \neq 0 \\ -8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 256 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ +0 & \text{if}\ \ell_E\le 32\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 32 \wedge E \neq 0 \\ +8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 32 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ 8(\ell_E - 32) & \text{otherwise} \\ \end{cases} \\ \mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ From 3922d0c7f9c787dab0a326efd899f0dabff9ce89 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 24 Jul 2017 11:38:34 +0200 Subject: [PATCH 163/460] Update expmod gas schedule, according to https://github.com/ethereum/EIPs/commit/4d4d8fb --- Paper.tex | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8b234c2b..3d915888 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1443,7 +1443,12 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_r &=& \Big\lfloor\frac{\max(\ell_M,\ell_B)^2\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +g_r &=& \Big\lfloor\frac{f\big(\max(\ell_M,\ell_B)\big)\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +f(x) &\equiv& \begin{cases} +x^2 & \text{if}\ x \le 64 \\ +\Big\lfloor\dfrac{x^2}{4}\Big\rfloor + 96 x - 3072 & \text{if}\ 64 < x \le 1024 \\ +\Big\lfloor\dfrac{x^2}{16}\Big\rfloor + 480x - 199680 & \text{otherwise} +\end{cases}\\ \ell'_E &=& \begin{cases} 0 & \text{if}\ \ell_E\le 32\wedge E=0 \\ \lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 32 \wedge E \neq 0 \\ From 0fe0e30c94c2ca4016d6e4e35e174ccedf0ae3a9 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 29 Mar 2017 17:31:02 +0200 Subject: [PATCH 164/460] \Xi does not return output on exceptional halt This makes the exceptional halts easier to distinguish from reverts --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2d121963..46c574a6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -723,7 +723,7 @@ \section{Contract Creation} \label{ch:create} \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ \nonumber \text{where} \\ -F &\equiv \big(\boldsymbol{\sigma}^{**} = \varnothing \ \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) +F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) \end{align} The exception in the determination of $\boldsymbol{\sigma}'$ dictates that $\mathbf{o}$, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. @@ -783,7 +783,7 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma}^{**} & \text{otherwise} \end{cases} \\ g' & \equiv & \begin{cases} -0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \ \wedge \ \mathbf{o} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ \nonumber \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} @@ -877,7 +877,7 @@ \subsection{Execution Overview} \end{eqnarray} \begin{equation} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} -\big(\varnothing, \boldsymbol{\mu}, A^0, I, ()\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ +\big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing\\ X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise}\\ \end{cases} From f3d6a2eca0966191a86dc49d9ed2b8d26b4b60de Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 29 Mar 2017 17:58:08 +0200 Subject: [PATCH 165/460] Specify REVERT Following https://github.com/ethereum/EIPs/pull/206/files --- Paper.tex | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 46c574a6..3b018efe 100644 --- a/Paper.tex +++ b/Paper.tex @@ -875,9 +875,10 @@ \subsection{Execution Overview} \boldsymbol{\mu}_i & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{s} & \equiv & () \end{eqnarray} -\begin{equation} +\begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} \big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ +\big(\varnothing, \boldsymbol{\mu}', A^0, I, \mathbf{o}\big) & \text{if} \quad w = \text{\small REVERT} \\ O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing\\ X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise}\\ \end{cases} @@ -886,7 +887,9 @@ \subsection{Execution Overview} where \begin{eqnarray} \mathbf{o} & \equiv & H(\boldsymbol{\mu}, I) \\ -(a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) +(a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) \\ +\boldsymbol{\mu}' & \equiv & \boldsymbol{\mu}\ \text{except:} \\ +\boldsymbol{\mu}'_g & \equiv & \boldsymbol{\mu}_g - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \end{eqnarray} Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_g$ from the resultant machine state $\boldsymbol{\mu}'$. @@ -964,13 +967,13 @@ \subsubsection{Normal Halting} The normal halting function $H$ is defined: \begin{equation} H(\boldsymbol{\mu}, I) \equiv \begin{cases} -H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small RETURN} \\ +H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w \in \{\text{\small RETURN}, \text{\small REVERT}\} \\ () & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small SELFDESTRUCT} \} \\ \varnothing & \text{otherwise} \end{cases} \end{equation} -The data-returning halt operation, \text{\small RETURN}, has a special function $H_{\text{\tiny RETURN}}$, defined in Appendix \ref{app:vm}. +The data-returning halt operations, \text{\small RETURN} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$, defined in Appendix \ref{app:vm}. \subsection{The Execution Cycle} @@ -1607,7 +1610,7 @@ \subsection{Gas Cost} with $C_\text{\tiny CALL}$, $C_\text{\tiny SELFDESTRUCT}$ and $C_\text{\tiny SSTORE}$ as specified in the appropriate section below. We define the following subsets of instructions: -$W_{zero}$ = \{{\small STOP}, {\small RETURN}\} +$W_{zero}$ = \{{\small STOP}, {\small RETURN}, {\small REVERT}\} $W_{base}$ = \{{\small ADDRESS}, {\small ORIGIN}, {\small CALLER}, {\small CALLVALUE}, {\small CALLDATASIZE}, {\small CODESIZE}, {\small GASPRICE}, {\small COINBASE},\newline \noindent\hspace*{1cm} {\small TIMESTAMP}, {\small NUMBER}, {\small DIFFICULTY}, {\small GASLIMIT}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}\} @@ -1996,8 +1999,8 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ -&&&& $Z(\boldsymbol{\sigma}^*, \boldsymbol{\mu}, I) = \top$ or $I_e = 1024$ \\ +&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting\\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_e = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_a]_b$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ &&&& created account. \\ @@ -2014,7 +2017,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ -&&&& $Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) = \top$ or if \\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ @@ -2072,6 +2075,11 @@ \subsection{Instruction Set} &&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ +0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes + but returning data and gas. \\ +&&&& The effect of this operation is described in (\ref{eq:X-def}). \\ +&&&& For the gas calculation, we need to define the memory usage: \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule From 6c2b05b2f5c3ca6344cebb7fdf43c0aee34ff5b6 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 14:42:05 +0200 Subject: [PATCH 166/460] EIP 140: the output from REVERT during a contract creation should be accessible from RETURNDATASIZE and RETURNDATACOPY, so \Lambda should return four values. --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3b018efe..2a343a2d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -595,7 +595,7 @@ \subsection{Execution} Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$ and substate $A$: \begin{equation} (\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} -\Lambda(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ +\Lambda_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ \Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -606,7 +606,7 @@ \subsection{Execution} \end{equation} and $T_o$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. -Note we use $\Theta_{3}$ to denote the fact that only the first three components of the function's value are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. +Note we use $\Theta_{3}$ and $\Lambda_{3}$ to denote the fact that only the first three components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} @@ -642,9 +642,9 @@ \section{Contract Creation} \label{ch:create} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). -We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas and accrued transaction substate $(\boldsymbol{\sigma}', g', A)$, as in section \ref{ch:transactions}: +We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas, accrued transaction substate and an error message $(\boldsymbol{\sigma}', g', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -1994,7 +1994,7 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ From 987d8aa36e8c3cb5cef4710f5aef58b9c1ec2f3b Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 10 May 2017 16:16:41 +0200 Subject: [PATCH 167/460] Fix whitespaces --- Paper.tex | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2a343a2d..8f5190a9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -877,10 +877,10 @@ \subsection{Execution Overview} \end{eqnarray} \begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} -\big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I)\\ +\big(\varnothing, \boldsymbol{\mu}, A^0, I, \varnothing\big) & \text{if} \quad Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \\ \big(\varnothing, \boldsymbol{\mu}', A^0, I, \mathbf{o}\big) & \text{if} \quad w = \text{\small REVERT} \\ -O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing\\ -X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise}\\ +O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \cdot \mathbf{o} & \text{if} \quad \mathbf{o} \neq \varnothing \\ +X\big(O(\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \text{otherwise} \\ \end{cases} \end{equation} @@ -2017,7 +2017,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ -&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ @@ -2077,6 +2077,7 @@ \subsection{Instruction Set} &&&& The last argument of $\Theta$ is $\bot$. \\ 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ +0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we need to define the memory usage: \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ From 3161e96648db502253a349b8ac29a3518a6df6d1 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 2 Mar 2017 14:42:54 +0100 Subject: [PATCH 168/460] EIP-100: change the difficulty adjustment factor so that it considers existence of ommers --- Paper.tex | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8f5190a9..799f606f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -464,8 +464,14 @@ \subsubsection{Block Header Validity} \diffadjustment \equiv \left\lfloor\frac{{P(H)_H}_d}{2048}\right\rfloor \end{equation} \begin{equation} -\homesteadmod \equiv \text{max}\left( 1 - \left\lfloor\frac{H_s - {P(H)_H}_s}{10}\right\rfloor, -99 \right) +\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_s - {P(H)_H}_s}{9}\right\rfloor, -99 \right) \end{equation} +\begin{equation*} +x \equiv \begin{cases} +1 & \text{if} \, \lVert B_\mathbf{U}\rVert = 0 \\ +2 & \text{otherwise} +\end{cases} +\end{equation*} \begin{equation} \expdiffsymb \equiv \left\lfloor 2^{ \left\lfloor H_i \div 100000 \right\rfloor - 2 } \right\rfloor \end{equation} From 5d7d22df11128742389414a3c649833fb41f7561 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 21 Mar 2017 17:12:33 +0100 Subject: [PATCH 169/460] EIP-100: ommers of parent should be counted, not the direct ommers --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 799f606f..58eaeaab 100644 --- a/Paper.tex +++ b/Paper.tex @@ -468,7 +468,7 @@ \subsubsection{Block Header Validity} \end{equation} \begin{equation*} x \equiv \begin{cases} -1 & \text{if} \, \lVert B_\mathbf{U}\rVert = 0 \\ +1 & \text{if} \, \lVert P(H)_\mathbf{U}\rVert = 0 \\ 2 & \text{otherwise} \end{cases} \end{equation*} From 5fb2de816bcc8331919ee56e8e812b6ab5ea2390 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 2 Mar 2017 13:50:38 +0100 Subject: [PATCH 170/460] Implement EIP-658 https://github.com/ethereum/EIPs/pull/658 Now transaction receipts contain one byte indicating success or failure. --- Paper.tex | 58 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 39 insertions(+), 19 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8f5190a9..da6560cc 100644 --- a/Paper.tex +++ b/Paper.tex @@ -333,16 +333,21 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the post-transaction state, $R_{\boldsymbol{\sigma}}$, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} -R \equiv (R_{\boldsymbol{\sigma}}, R_u, R_b, R_\mathbf{l}) +R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_R(R) \equiv (\mathtt{\small TRIE}(L_S(R_{\boldsymbol{\sigma}})), R_u, R_b, R_\mathbf{l}) +L_R(R) \equiv (0 \in \mathbb{B}_{256}, R_u, R_b, R_\mathbf{l}) +\end{equation} +where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. + +We assert that the status code $R_{s'}$ is a single byte. +\begin{equation} +R_{s'} \in \mathbb{B}_{8} \end{equation} -thus the post-transaction state, $R_{\boldsymbol{\sigma}}$ is encoded into a trie structure, the root of which forms the first item. We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): \begin{equation} @@ -592,11 +597,11 @@ \subsection{Execution} \boldsymbol{\sigma}_0[S(T)]_n & \equiv & \boldsymbol{\sigma}[S(T)]_n + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$ and substate $A$: +Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $s'$: \begin{equation} -(\boldsymbol{\sigma}_P, g', A) \equiv \begin{cases} -\Lambda_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ -\Theta_{3}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} +(\boldsymbol{\sigma}_P, g', A, s') \equiv \begin{cases} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ +\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -606,7 +611,7 @@ \subsection{Execution} \end{equation} and $T_o$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. -Note we use $\Theta_{3}$ and $\Lambda_{3}$ to denote the fact that only the first three components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. +Note we use $\Theta_{4}$ and $\Lambda_{4}$ to denote the fact that only the first four components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} @@ -630,10 +635,11 @@ \subsection{Execution} \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction and $\Upsilon^\mathbf{l}$, the logs created by this transaction: +And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ +\Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' \end{eqnarray} These are used to help define the transaction receipt, discussed later. @@ -644,7 +650,7 @@ \section{Contract Creation} \label{ch:create} We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas, accrued transaction substate and an error message $(\boldsymbol{\sigma}', g', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -724,6 +730,10 @@ \section{Contract Creation} \label{ch:create} \end{cases} \\ \nonumber \text{where} \\ F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) +\quad s' &\equiv \begin{cases} +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ +1 & \text{otherwise} +\end{cases} \end{align} The exception in the determination of $\boldsymbol{\sigma}'$ dictates that $\mathbf{o}$, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. @@ -738,7 +748,7 @@ \section{Message Call} \label{ch:call} Aside from evaluating to a new state and transaction substate, message calls also have an extra component---the output data denoted by the byte array $\mathbf{o}$. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) +(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) \end{equation} Note that we need to differentiate between the value that is to be transferred, $v$, from the value apparent in the execution context, $\tilde{v}$, for the {\small DELEGATECALL} instruction. @@ -786,6 +796,10 @@ \section{Message Call} \label{ch:call} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \ \wedge \ \mathbf{o} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ \nonumber +s' & \equiv & \begin{cases} +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ +1 & \text{otherwise} +\end{cases} \\ \qquad (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) & \equiv & \begin{cases} \Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 1 \\ \Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 2 \\ @@ -1106,16 +1120,16 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{\boldsymbol{\sigma}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding states, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). The former is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{s'}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\mathbf{R}[n]_{\boldsymbol{\sigma}} = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} In the case of $B_\mathbf{R}[n]_u$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} \mathbf{R}[n]_u = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_u +\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_u \end{array} & \text{otherwise} \end{cases} \end{equation} @@ -1123,12 +1137,18 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} For $\mathbf{R}[n]_\mathbf{l}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. \begin{equation} \mathbf{R}[n]_\mathbf{l} = -\Upsilon^\mathbf{l}(\mathbf{R}[n - 1]_{\boldsymbol{\sigma}}, B_\mathbf{T}[n]) +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\end{equation} + +We define $\mathbf{R}[n]_{s'}$ in a similar manner. +\begin{equation} +\mathbf{R}[n]_{s'} = +\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(B_\mathbf{R})_{\boldsymbol{\sigma}}$: +Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: \begin{equation} -\Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\mathbf{R})_{\boldsymbol{\sigma}}) +\Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} Thus the complete block-transition mechanism, less $\mathtt{PoW}$, the proof-of-work function is defined. From f5d1d67a205e6b3a43b6e10ba3d35532f9dfc0ec Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 28 Aug 2017 16:38:06 +0200 Subject: [PATCH 171/460] Fix the status code representation --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index da6560cc..f1cbfb36 100644 --- a/Paper.tex +++ b/Paper.tex @@ -344,9 +344,9 @@ \subsubsection{Transaction Receipt} \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_{s'}$ is a single byte. +We assert that the status code $R_{s'}$ is an integer. \begin{equation} -R_{s'} \in \mathbb{B}_{8} +R_{s'} \in \mathbb{P} \end{equation} We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): @@ -714,7 +714,7 @@ \section{Contract Creation} \label{ch:create} The gas remaining will be zero in any such exceptional condition, \ie if the creation was conducted as the reception of a transaction, then this doesn't affect payment of the intrinsic cost of contract creation; it is paid regardless. However, the value of the transaction is not transferred to the aborted contract's address when we are out-of-gas. -If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas and substate as $(\boldsymbol{\sigma}', g', A)$ where: +If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, substate and status code as $(\boldsymbol{\sigma}', g', A, s')$ where: \begin{align} \quad g' &\equiv \begin{cases} From 9a23fd2e343a7e1e370ee719cfacf5ad100021a0 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 8 Sep 2017 15:56:52 +0200 Subject: [PATCH 172/460] Block reward to 3 Ether --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index b359b121..635443a8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1085,9 +1085,9 @@ \subsection{Reward Application} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -We define the block reward as 5 Ether: +We define the block reward as 3 Ether: \begin{equation} -\text{Let} \quad R_b = 5 \times 10^{18} +\text{Let} \quad R_b = 3 \times 10^{18} \end{equation} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} From 36a762cbca1ee2131572b6b95fd92a9895051e2e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 8 Sep 2017 16:09:51 +0200 Subject: [PATCH 173/460] Delay the ice age --- Paper.tex | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 635443a8..f7f78ca2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -472,9 +472,10 @@ \subsubsection{Block Header Validity} 2 & \text{otherwise} \end{cases} \end{equation*} -\begin{equation} -\expdiffsymb \equiv \left\lfloor 2^{ \left\lfloor H_i \div 100000 \right\rfloor - 2 } \right\rfloor -\end{equation} +\begin{align} +\expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ +H'_i &\equiv \max(H_i - 3000000, 0) +\end{align} The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 4e815705de18b89ed77d426a864a0dbc884903ad Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 13 Apr 2017 13:39:35 +0200 Subject: [PATCH 174/460] EIP-196, EIP-197: some basic mathematical descriptions --- Paper.tex | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/Paper.tex b/Paper.tex index b359b121..3d143412 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1477,6 +1477,49 @@ \section{Precompiled Contracts}\label{app:precompiled} \end{cases} \end{eqnarray} +\subsection{zkSNARK Related Precompiled Contracts} + +We choose two numbers, both of which are prime. +\begin{eqnarray} +p &\equiv& 21888242871839275222246405745257275088696311157297823662689037894645226208583 \\ +q &\equiv& 21888242871839275222246405745257275088548364400416034343698204186575808495617 +\end{eqnarray} +Since $p$ is a prime number, $\{0, 1, \ldots, p - 1\}$ forms a field with addition and multiplication modulo $p$. We call this field $F_p$. + +We define a set~$C_1$ with +\begin{equation} +C_1\equiv\{(X,Y)\in F_p\times F_p\mid Y^2=X^3+3\}\cup\{(0,0)\} +\end{equation} +We define a binary operation $+$ on $C_1$ with +\begin{eqnarray}\label{eq:ec-addition} +(X_1, Y_1) + (X_2, Y_2)&\equiv&\begin{cases} +(X,Y)&\text{if}\ X_1\neq X_2\\ +(0,0)&\text{otherwise} +\end{cases}\\ +X&\equiv&\lambda^2-X_1-X_2\\ +Y&\equiv&\lambda(X_1-X)-Y_1\\ +\lambda&\equiv&\frac{Y_2-Y_1}{X_2-X_1} +\end{eqnarray} + +$(C_1,+)$ is known to form a group. We define the scalar multiplication $\cdot$ with +\begin{equation}\label{eq:ec-scalar-multiplication} +n\cdot P\equiv(0,0)+\underbrace{P+\cdots+P}_{n} +\end{equation} +for a natural number $n$ and a point $P$ in $C_1$. + +We define $P_1$ to be a point $(1,2)$ on $C_1$. Let $G_1$ be the subgroup of $(C_1,+)$ generated by $P_1$. $G_1$ is known to be a cyclic group of order $q$. For a point $P$ in $G_1$, we define $\log_{P_1}(P)$ to be the smallest natural number $n$ satisfying $n\cdot P_1=P$. $\log_{P_1}(P)$ is at most $q-1$. + +Let $F_{p^2}$ be a field $F_p[i]/(i+1)$. We define a set $C_2$ with +\begin{equation} +C_2\equiv\{(X,Y)\in F_{p^2}\times F_{p^2}\mid Y^2=X^3+3\}\cup\{(0,0)\} +\end{equation} +We define a binary operation $+$ and a scalar multiplication $\cdot$ with the same equations (\ref{eq:ec-addition}) and (\ref{eq:ec-scalar-multiplication}). $(C_2,+)$ is also known to be a group. We define $P_2$ in $C_2$ with +\begin{eqnarray} +P_2&\equiv& +(11559732032986387107991004021392285783925812861821192530917403151452391805634 \times i\\\nonumber &&+ 10857046999023057135944570762232829481370756359578518086990519993285655852781,\\\nonumber && 4082367875863433681332203403145435568316851327593401208105741076214120093531 \times i\\\nonumber &&+ 8495653923123431417604973247489272438418190587263600148770280649306958101930) +\end{eqnarray} +We define $G_2$ to be the subgroup of $(C_2,+)$ generated by $P_2$. $G_2$ is known to be a cyclic group of order $q$. For a point $P$ in $G_2$, we define $\log_{P_2}(P)$ be the smallest natural number $n$ satisfying $n\cdot P_2=P$. With this definition, $\log_{P_2}(P)$ is at most $q-1$. + \section{Signing Transactions}\label{app:signing} The method of signing transactions is similar to the `Electrum style signatures'; it utilises the SECP-256k1 curve as described by \cite{gura2004comparing}. From b7c70cace3440c9b9aecf6473bf11581cf4f8a68 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 13 Apr 2017 15:20:26 +0200 Subject: [PATCH 175/460] 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 176/460] EIP-196 Define addition precompiled contract on G_1 --- Paper.tex | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Paper.tex b/Paper.tex index ec6f0a8d..19b3ee3b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1576,6 +1576,20 @@ \subsection{zkSNARK Related Precompiled Contracts} b_k&\equiv&\delta_2(I_{\mathbf d}[(|I_{\mathbf d}|-128)..(|I_{\mathbf d}|-1)]) \end{eqnarray} +We define a precompiled contract for addition on $G_1$. +\begin{eqnarray} +\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ +g_r&=&?\\ +\mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ +x&\equiv&\delta_1(\bar I_{\mathbf d}[0..63])\\ +y&\equiv&\delta_1(\bar I_{\mathbf d}[64..127])\\ +\label{eq:complemented_input}\bar I_{\mathbf d}[x]&\equiv&\begin{cases} +I_{\mathbf d}[x]&\text{if}\ x < |I_{\mathbf d}|\\ +0&\text{otherwise} +\end{cases} +\end{eqnarray} + \section{Signing Transactions}\label{app:signing} The method of signing transactions is similar to the `Electrum style signatures'; it utilises the SECP-256k1 curve as described by \cite{gura2004comparing}. From b5c5f1c11629fb0106def82113c0fe25d88eca3e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Thu, 13 Apr 2017 15:53:01 +0200 Subject: [PATCH 177/460] EIP-196 Defining the precompiled contract for scalar multiplication on G_1 --- Paper.tex | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Paper.tex b/Paper.tex index 19b3ee3b..a2ee15f1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1590,6 +1590,16 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{cases} \end{eqnarray} +We define a precompiled contract for scalar multiplication on $G_1$, where $\bar I_{\mathbf d}$ is defined in (\ref{eq:complemented_input}). +\begin{eqnarray} +\Xi_{\mathtt{BN\_MUL}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ +g_r&=&?\\ +\mathbf o&\equiv&\delta_1^{-1}(n\cdot x)\quad\text{where $\cdot$ is the scalar multiplication in $G_1$}\\ +n&\equiv&\bar I_{\mathbf d}[0..31]\\ +x&\equiv&\delta_1(\bar I_{\mathbf d}[32..95]) +\end{eqnarray} + \section{Signing Transactions}\label{app:signing} The method of signing transactions is similar to the `Electrum style signatures'; it utilises the SECP-256k1 curve as described by \cite{gura2004comparing}. From fa144bbec665ab8a3427db12854272e4f0540521 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 22 May 2017 12:27:04 +0200 Subject: [PATCH 178/460] Add some mappings from addresses to the new precompiled contracts --- Paper.tex | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Paper.tex b/Paper.tex index a2ee15f1..14b20cb6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -798,6 +798,9 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 8 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_a & \equiv & r \\ I_o & \equiv & o \\ From d27219a31a92d7a37b74651c92b08050933e6c77 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 22 May 2017 13:44:06 +0200 Subject: [PATCH 179/460] Specify gas for the snark verification precompiled contract --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 14b20cb6..405fa5e1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1566,7 +1566,8 @@ \subsection{zkSNARK Related Precompiled Contracts} \Xi_{\mathtt{SNARKV}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \qquad\Xi_{\mathtt{SNARKV}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ F\\ F&\equiv&(|I_\mathbf{d}|\bmod 192\neq 0\vee(\exists j.\ a_j=\varnothing\vee b_j=\varnothing))\\ -g_r&=&?\\ +k &=& \dfrac{|I_\mathbf{d}|}{192} \\ +g_r&=& 60000k + 40000 \\ \mathbf o[0..31]&\equiv&\begin{cases} 0x0000000000000000000000000000000000000000000000000000000000000001&\text{if}\ v\wedge\neg F\\ 0x0000000000000000000000000000000000000000000000000000000000000000&\text{if}\ \neg v\wedge\neg F From 5bb035caabb7c882023b1a14bdc678e480d12793 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 25 Jul 2017 15:46:45 +0200 Subject: [PATCH 180/460] Fix the pairing checker specification according to https://github.com/ethereum/EIPs/pull/212/commits/470c61bed3b94d67815557aca224641742badb56 --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 405fa5e1..f8c8bb39 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1572,7 +1572,7 @@ \subsection{zkSNARK Related Precompiled Contracts} 0x0000000000000000000000000000000000000000000000000000000000000001&\text{if}\ v\wedge\neg F\\ 0x0000000000000000000000000000000000000000000000000000000000000000&\text{if}\ \neg v\wedge\neg F \end{cases}\\ -v&\equiv&(\log_{P_1}(a_1)\times\log_{P_2}(b_1)+\cdots+\log_{P_1}(a_k)\times\log_{P_2}(b_k)\equiv 0\mod q)\\ +v&\equiv&(\log_{P_1}(a_1)\times\log_{P_2}(b_1)+\cdots+\log_{P_1}(a_k)\times\log_{P_2}(b_k)\equiv 1\mod q)\\ a_1&\equiv&\delta_1(I_{\mathbf d}[0..63])\\ b_1&\equiv&\delta_2(I_{\mathbf d}[64..191])\\\nonumber \vdots\\ From a35c1f3c10800a12bf58c32942c3ae06c9c063fa Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 19 Sep 2017 14:02:55 +0200 Subject: [PATCH 181/460] Fill the determined gas costs --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index f8c8bb39..fa544fc9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1584,7 +1584,7 @@ \subsection{zkSNARK Related Precompiled Contracts} \begin{eqnarray} \Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ -g_r&=&?\\ +g_r &=& 500\\ \mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ x&\equiv&\delta_1(\bar I_{\mathbf d}[0..63])\\ y&\equiv&\delta_1(\bar I_{\mathbf d}[64..127])\\ @@ -1598,7 +1598,7 @@ \subsection{zkSNARK Related Precompiled Contracts} \begin{eqnarray} \Xi_{\mathtt{BN\_MUL}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_MUL}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ -g_r&=&?\\ +g_r &=& 40000\\ \mathbf o&\equiv&\delta_1^{-1}(n\cdot x)\quad\text{where $\cdot$ is the scalar multiplication in $G_1$}\\ n&\equiv&\bar I_{\mathbf d}[0..31]\\ x&\equiv&\delta_1(\bar I_{\mathbf d}[32..95]) From ce8d19855a24ce0cb5c5b58e6d9e34c8cb47fe51 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 19 Jan 2018 15:42:06 +0100 Subject: [PATCH 182/460] The fourth precompiled contract is not the final one --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b359b121..bf8e655d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1441,7 +1441,7 @@ \section{Precompiled Contracts}\label{app:precompiled} \mathtt{\small RIPEMD160}(\mathbf{i} \in \mathbb{B}) & \equiv & o \in \mathbb{B}_{20} \end{eqnarray} -Finally, the fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: +The fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: \begin{eqnarray} \Xi_{\mathtt{ID}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_r &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ From 24e8956146d70236d8cb0c23beb9f7e99a2742d5 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:21:16 +0100 Subject: [PATCH 183/460] EIP-211: add the previous output buffer to the execution state --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b1e6848e..2c4cacc9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -883,7 +883,8 @@ \subsection{Execution Overview} \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ \boldsymbol{\mu}_i & \equiv & 0 \\ -\boldsymbol{\mu}_\mathbf{s} & \equiv & () +\boldsymbol{\mu}_\mathbf{s} & \equiv & () \\ +\boldsymbol{\mu}_\mathbf{o} & \equiv & () \end{eqnarray} \begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} @@ -2175,6 +2176,7 @@ \subsection{Instruction Set} &&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{o} = \mathbf{o}$ \\ &&&& $\boldsymbol{\mu}'_g \equiv \boldsymbol{\mu}_g + g'$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ From 697bdea6c4ba0a27254a4ef84dab13d4c9c3d4ff Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:30:15 +0100 Subject: [PATCH 184/460] EIP-211: specify RETURNDATASIZE --- Paper.tex | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Paper.tex b/Paper.tex index 2c4cacc9..a8a2fe73 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1863,6 +1863,10 @@ \subsection{Instruction Set} 0x0b & {\small SIGNEXTEND} & 2 & 1 & Extend length of two's complement signed integer. \\ &&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_t &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_i &\text{otherwise} \end{cases}$ \\ \multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_i$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ +\midrule +0x0d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ +\midrule \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} From 77945cf431e05db9bf300a0deacffe4a3cbb5251 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:35:38 +0100 Subject: [PATCH 185/460] EIP-211: specify RETURNDATACOPY --- Paper.tex | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Paper.tex b/Paper.tex index a8a2fe73..810cdd43 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1867,6 +1867,12 @@ \subsection{Instruction Set} 0x0d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ \midrule +0x0e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv +\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +\midrule \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} From a48f6a5a84bd4d1574163d226f9865af8bba08f0 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 7 Mar 2017 22:49:42 +0100 Subject: [PATCH 186/460] EIP-211: specify the gas costs for RETURNDATASIZE and RETURNDATACOPY --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 810cdd43..a4d2fff9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1737,7 +1737,7 @@ \subsection{Gas Cost} C_\text{\tiny SSTORE}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SSTORE} \\ G_{exp} & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] = 0 \\ G_{exp} + G_{expbyte}\times(1+\lfloor\log_{256}(\boldsymbol{\mu}_\mathbf{s}[1])\rfloor) & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] > 0 \\ -G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \\ +G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \lor \text{\small RETURNDATACOPY} \\ G_{extcode} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1] & \text{if} \quad w = \text{\small LOG0} \\ G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+G_{logtopic} & \text{if} \quad w = \text{\small LOG1} \\ @@ -1776,7 +1776,7 @@ \subsection{Gas Cost} $W_{zero}$ = \{{\small STOP}, {\small RETURN}, {\small REVERT}\} -$W_{base}$ = \{{\small ADDRESS}, {\small ORIGIN}, {\small CALLER}, {\small CALLVALUE}, {\small CALLDATASIZE}, {\small CODESIZE}, {\small GASPRICE}, {\small COINBASE},\newline \noindent\hspace*{1cm} {\small TIMESTAMP}, {\small NUMBER}, {\small DIFFICULTY}, {\small GASLIMIT}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}\} +$W_{base}$ = \{{\small ADDRESS}, {\small ORIGIN}, {\small CALLER}, {\small CALLVALUE}, {\small CALLDATASIZE}, {\small CODESIZE}, {\small GASPRICE}, {\small COINBASE},\newline \noindent\hspace*{1cm} {\small TIMESTAMP}, {\small NUMBER}, {\small DIFFICULTY}, {\small GASLIMIT}, {\small RETURNDATASIZE}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}\} $W_{verylow}$ = \{{\small ADD}, {\small SUB}, {\small NOT}, {\small LT}, {\small GT}, {\small SLT}, {\small SGT}, {\small EQ}, {\small ISZERO}, {\small AND}, {\small OR}, {\small XOR}, {\small BYTE}, {\small CALLDATALOAD}, \newline \noindent\hspace*{1cm} {\small MLOAD}, {\small MSTORE}, {\small MSTORE8}, {\small PUSH*}, {\small DUP*}, {\small SWAP*}\} From 232398f82ad9e02ba833280c0e889de9d48d49ee Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 22 Mar 2017 10:33:26 +0100 Subject: [PATCH 187/460] EIP-211: CREATE resets the previous return data This change is according to https://github.com/ethereum/EIPs/pull/211#issuecomment-287728214 --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index a4d2fff9..bd64d2eb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2179,6 +2179,7 @@ \subsection{Instruction Set} &&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ &&&& created account. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{o} \equiv ()$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ From 1a7e397af5f83a8d267a65c8788bdba839e4c74e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 9 May 2017 18:14:58 +0200 Subject: [PATCH 188/460] Move RETURNDATACOPY and RETURNDATASIZE to the 0x3. block --- Paper.tex | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index bd64d2eb..79249639 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1864,15 +1864,6 @@ \subsection{Instruction Set} &&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_t &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_i &\text{otherwise} \end{cases}$ \\ \multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_i$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ \midrule -0x0d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ -\midrule -0x0e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ -\midrule \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} @@ -1986,6 +1977,15 @@ \subsection{Instruction Set} &&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_c$ \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[2] + i$ are not subject to the $2^{256}$ modulo. \\ +\midrule +0x3d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ +\midrule +0x3e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv +\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ \bottomrule \end{tabular*} From aa9ef93051420377d617b5da7eb882c9d383b0c3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 21 Jun 2017 14:50:35 +0200 Subject: [PATCH 189/460] RETURNDATACOPY throws when it would overrun the return data buffer even when the accessed length is zero. --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 79249639..89d4ea65 100644 --- a/Paper.tex +++ b/Paper.tex @@ -931,6 +931,7 @@ \subsubsection{Exceptional Halting} \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ ( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ +( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ \neg I_w \wedge W(w, \boldsymbol{\mu}) \end{array} From 936d0bb1be13dc2dc617c8c83c20ab21e6754b52 Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Fri, 19 Jan 2018 16:30:09 +0100 Subject: [PATCH 190/460] Byzantium revision --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ce8a79ad..c943fb1b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -39,7 +39,7 @@ \newcommand*\ie{i.e.\@\xspace} %\renewcommand{\itemhook}{\setlength{\topsep}{0pt} \setlength{\itemsep}{0pt}\setlength{\leftmargin}{15pt}} -\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{EIP-150 revision (\YellowPaperVersionNumber{})}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Ethcore\\ From 35199b8144dced866ee4dfc7473066be90140380 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 18:42:01 +1100 Subject: [PATCH 191/460] Remove lightpink lines --- Paper.tex | 2 -- 1 file changed, 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d143f480..ff1ef4aa 100644 --- a/Paper.tex +++ b/Paper.tex @@ -31,7 +31,6 @@ }% \definecolor{lightyellow}{rgb}{1,0.98,0.9} -%\definecolor{lightpink}{rgb}{1,0.94,0.95} \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} @@ -48,7 +47,6 @@ \begin{document} \pagecolor{lightyellow} -%\pagecolor{lightpink} \begin{abstract} The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not least Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. From f78734c843c7cc91b256b10814fb03d1bb821088 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 18:46:39 +1100 Subject: [PATCH 192/460] Update Paper.tex --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index edfe21ec..c162d3b9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -51,7 +51,7 @@ %\pagecolor{lightpink} \begin{abstract} -The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not the least being Bitcoin. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. +The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, with Bitcoin being one of the most notable ones. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. Ethereum implements this paradigm in a generalised manner. Furthermore it provides a plurality of such resources, each with a distinct state and operating code but able to interact through a message-passing framework with others. We discuss its design, implementation issues, the opportunities it provides and the future hurdles we envisage. \end{abstract} From bead47f792abf424fa19526ded9619dd8b902703 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 19:56:45 +1100 Subject: [PATCH 193/460] Add EIP-2 and EIP-649 refs --- Biblio.bib | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index f3c0ee9c..40cfbea0 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,3 +1,17 @@ +@Misc{EIP-649, + url = "https://github.com/ethereum/EIPs/blob/63c93eb71d1148435fa2cadb36da7df2bd865a3d/EIPS/eip-649.md", + author = "Afri Schoedon and Vitalik Buterin", + title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", + year = "2017", +} + +@Misc{EIP-2, + url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md", + title = "EIP-2: Homestead Hard-fork Changes", + author = "Vitalik Buterin", + year = "2015", +} + @Misc{cryptoeprint:2013:881, Note = {{http://eprint.iacr.org/}}, Url = {{Cryptology ePrint Archive, Report 2013/881}}, @@ -141,4 +155,4 @@ @article{FowlerNollVo1991FNVHash author = {Glenn Fowler, Landon Curt Noll, Phong Vo}, title = {{Fowler–Noll–Vo hash function}}, year = {{1991}}, -} \ No newline at end of file +} From ce638b84164a2dea016f50e3c80486863bf4b4d4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 20:23:39 +1100 Subject: [PATCH 194/460] \cite{EIP-100, --- Biblio.bib | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Biblio.bib b/Biblio.bib index 40cfbea0..bb77cab4 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,8 +1,17 @@ +\cite{EIP-100, + url = "https://github.com/ethereum/EIPs/blob/f3a591f6718035ba358d6a479cadabe313f6ed36/EIPS/eip-100.md", + author = "Vitalik Buterin", + title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", + year = "2016", + month = "April", +} + @Misc{EIP-649, url = "https://github.com/ethereum/EIPs/blob/63c93eb71d1148435fa2cadb36da7df2bd865a3d/EIPS/eip-649.md", author = "Afri Schoedon and Vitalik Buterin", title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", year = "2017", + month = "June", } @Misc{EIP-2, From 10390b878239548c95856adf5d511d6e5f368056 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 20:24:52 +1100 Subject: [PATCH 195/460] Update explanations of \homesteadmod and \expdiffsymb with citations for EIPs --- Paper.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Paper.tex b/Paper.tex index c943fb1b..b48e0b46 100644 --- a/Paper.tex +++ b/Paper.tex @@ -482,6 +482,8 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, $\expdiffsymb$ results in the difficulty increasing every 10000 blocks, which puts upward pressure on the time between blocks, causing it to slowly accelerate, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. + The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} & & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ From 25dc3d4aed07177df90013d7a508cd6a23c92049 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 20 Jan 2018 20:59:46 +1100 Subject: [PATCH 196/460] \cite{EIP-100, -> @Misc{EIP-100, --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index bb77cab4..ed174b53 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,4 +1,4 @@ -\cite{EIP-100, +@Misc{EIP-100, url = "https://github.com/ethereum/EIPs/blob/f3a591f6718035ba358d6a479cadabe313f6ed36/EIPS/eip-100.md", author = "Vitalik Buterin", title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", From bc1ba477f0c31378742f76064286a8ff65ef9d92 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 09:28:02 +0000 Subject: [PATCH 197/460] Add Paper.out to .gitignore. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 44c9250f..59c4bba2 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ Paper.aux Paper.bbl Paper.blg Paper.log +Paper.out Paper.pdf Version.tex From 049f7172b81da09d4319716ebd55c965c9166a63 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 09:48:59 +0000 Subject: [PATCH 198/460] Add description of the new Byzantium precompiles to section 8. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 98080c7b..97f14ca7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -838,7 +838,7 @@ \section{Message Call} \label{ch:call} It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_\mathbf{b}), I_\mathbf{b})$ at some point prior in order to make the determination of $I_\mathbf{b}$ feasible. -As can be seen, there are four exceptions to the usage of the general execution framework $\Xi$ for evaluation of the message call: these are four so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become \textit{native extensions}. The four contracts in addresses 1, 2, 3 and 4 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme and the identity function respectively. +As can be seen, there are eight exceptions to the usage of the general execution framework $\Xi$ for evaluation of the message call: these are eight so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become \textit{native extensions}. The eight contracts in addresses 1 to 8 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme, the identity function, arbitrary precision modular exponentiation, elliptic curve addition, elliptic curve scalar multiplication and an elliptic curve pairing check respectively. Their full formal definition is in Appendix \ref{app:precompiled}. From 6fc61c90e2ade5d06d0c6d8019845f26f6104df7 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Tue, 16 Jan 2018 17:52:07 +0100 Subject: [PATCH 199/460] Add table of versions in README.md --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 709555e5..e22881b9 100644 --- a/README.md +++ b/README.md @@ -15,3 +15,15 @@ In order to build, use the supplied build script (``build.sh``). Following the f ## Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu + +## Protocol Versions + +Each protocol version is specified in a branch in this repository. The activation block of each version is specified in the links. + +| Branch | Version | Known Significant Issues | +|-----------------|-----------------------------------------------------------------------------------|--------------------------| +| master | [Byzantium](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-609.md) | Some EIPs not reflected | +| spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Some EIPs not reflected | +| (to be added) | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | | +| (to be added) | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | | +| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | | From 9e34cc4fabfa67e4d53628c80ea97ef607495831 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 22 Jan 2018 11:48:50 +0100 Subject: [PATCH 200/460] Separate BRANCHES.md and add fork numbers --- BRANCHES.md | 11 +++++++++++ README.md | 14 ++------------ 2 files changed, 13 insertions(+), 12 deletions(-) create mode 100644 BRANCHES.md diff --git a/BRANCHES.md b/BRANCHES.md new file mode 100644 index 00000000..f52e3349 --- /dev/null +++ b/BRANCHES.md @@ -0,0 +1,11 @@ +## Protocol Versions + +Each protocol version is specified in `Paper.tex` found in a branch of this repository. + +| Branch | Version | Applicable Block Numbers | +|-------------------|-----------------------------------------------------------------------------------|---------------------------------| +| master | [Byzantium](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-609.md) | Since 4,370,000 and onwards | +| spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Since 2,675,000 until 4,369,999 | +| tangerine-whistle | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | Since 2,463,000 until 2,674,999 | +| dao-fork | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | Since 1,920,000 until 2,462,000 | +| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | Since 1 until 1,919,999 | diff --git a/README.md b/README.md index e22881b9..6fadd673 100644 --- a/README.md +++ b/README.md @@ -13,17 +13,7 @@ The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is In order to build, use the supplied build script (``build.sh``). Following the first time, you can use the standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. It can be viewed in ``PDF`` format after building. +The previous protocol versions are listed in [BRANCHES.md](./BRANCHES.md). + ## Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu - -## Protocol Versions - -Each protocol version is specified in a branch in this repository. The activation block of each version is specified in the links. - -| Branch | Version | Known Significant Issues | -|-----------------|-----------------------------------------------------------------------------------|--------------------------| -| master | [Byzantium](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-609.md) | Some EIPs not reflected | -| spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Some EIPs not reflected | -| (to be added) | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | | -| (to be added) | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | | -| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | | From 6ac5209b4136ae596ee62fae7c3e6a21af754f35 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 10:55:34 +0000 Subject: [PATCH 201/460] Update EIP 649 URL --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index ed174b53..74b0a8db 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -7,7 +7,7 @@ @Misc{EIP-100 } @Misc{EIP-649, - url = "https://github.com/ethereum/EIPs/blob/63c93eb71d1148435fa2cadb36da7df2bd865a3d/EIPS/eip-649.md", + url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-649.md", author = "Afri Schoedon and Vitalik Buterin", title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", year = "2017", From cb9a2cba458e00f1b8a250364e9699d92d245ca5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 11:01:49 +0000 Subject: [PATCH 202/460] Update EIP 100 URL --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 74b0a8db..9421693e 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,5 +1,5 @@ @Misc{EIP-100, - url = "https://github.com/ethereum/EIPs/blob/f3a591f6718035ba358d6a479cadabe313f6ed36/EIPS/eip-100.md", + url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md", author = "Vitalik Buterin", title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", year = "2016", From e54026c2633fc7a25c40838d989d959a75331607 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 11:48:20 +0000 Subject: [PATCH 203/460] Add `- sudo apt install texlive-latex-extra` --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 7efafc8e..d2130c78 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,6 +2,7 @@ sudo: required before_install: - sudo apt-get -qq update - sudo apt-get install texlive texlive-latex3 +- sudo apt install texlive-latex-extra script: - ./build.sh deploy: From 69a76f5094bc1c9eaf110113deec66fb685642f3 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 12:16:34 +0000 Subject: [PATCH 204/460] Fix formatting of s' definition. --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 97f14ca7..a477bb06 100644 --- a/Paper.tex +++ b/Paper.tex @@ -741,12 +741,12 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ -\nonumber \text{where} \\ -F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) \quad s' &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ 1 & \text{otherwise} -\end{cases} +\end{cases} \\ +\nonumber \text{where} \\ +F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ g^{**} < c \ \vee\ |\mathbf{o}| > 24576\big) \end{align} The exception in the determination of $\boldsymbol{\sigma}'$ dictates that $\mathbf{o}$, the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account. From 2e7a32274312a1ffaa4a5f6a2a157cff80feb4c0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:39:46 +1100 Subject: [PATCH 205/460] Rephrase a sentence on the $\expdiffsymb$ and add an explanation of the difficulty bomb delay --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b48e0b46..87b60e10 100644 --- a/Paper.tex +++ b/Paper.tex @@ -482,7 +482,7 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, $\expdiffsymb$ results in the difficulty increasing every 10000 blocks, which puts upward pressure on the time between blocks, causing it to slowly accelerate, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up due to network congestion. The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 62fe74b1ee3f9c11492d25a41e9f9834a492ca83 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:42:00 +1100 Subject: [PATCH 206/460] Grammar fixes: add "a", omit 'the" --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 709555e5..15f7b6a1 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ The Yellow Paper is a formal definition of the Ethereum protocol, originally by Gavin Wood, currently maintained by Nick Savers and with contributions from many people around the world. -It is free culture work, licensed under the Creative Commons Attribution Share-Alike (CC-BY-SA) version 4.0. +It is a free culture work, licensed under Creative Commons Attribution Share-Alike (CC-BY-SA) version 4.0. ## Usage From 30a45c79e4c1ba00b4247c18f6986a8da478b937 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:46:01 +1100 Subject: [PATCH 207/460] Add a period --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 15f7b6a1..d5f9a7f1 100644 --- a/README.md +++ b/README.md @@ -14,4 +14,4 @@ The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is In order to build, use the supplied build script (``build.sh``). Following the first time, you can use the standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. It can be viewed in ``PDF`` format after building. ## Other language versions -- [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu +- [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu. From 215d27a33d736769a7b96b9a7baf9657d5846b77 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 22 Jan 2018 23:51:37 +1100 Subject: [PATCH 208/460] Update how to build --- README.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 709555e5..aa07f273 100644 --- a/README.md +++ b/README.md @@ -9,9 +9,18 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A ## Usage -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/) . +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). -In order to build, use the supplied build script (``build.sh``). Following the first time, you can use the standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. It can be viewed in ``PDF`` format after building. +## How to build + +The paper also comes as a single ``latex`` file ``Paper.tex``, which is built as a PDF as follows. + +``` +git clone https://github.com/ethereum/yellowpaper.git +cd yellowpaper +./build.sh +``` +This will create a PDF version of the Yellow Paper. Following building, you can also use standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. ## Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu From b87a989cc90aa41abacfdc3dcdea9f229512d204 Mon Sep 17 00:00:00 2001 From: Afri Schoedon <5chdn@users.noreply.github.com> Date: Mon, 22 Jan 2018 20:59:58 +0100 Subject: [PATCH 209/460] Change Ethcore to Parity. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..771958d8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -49,8 +49,8 @@ \title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium revision (\YellowPaperVersionNumber{})}}} \author{ Dr. Gavin Wood\\ - Founder, Ethereum \& Ethcore\\ - gavin@ethcore.io + Founder, Ethereum \& Parity\\ + gavin@parity.io } \begin{document} From 356d0fb0c6dda5f8390d3742e893db2a4bcbeba7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 12:09:13 +1100 Subject: [PATCH 210/460] 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 b5a19225a340b3a85fe0e88313fe55567358bfad Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 12:27:39 +1100 Subject: [PATCH 211/460] providing ``consumers'' with the ability to make micro-payments --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..bff407a3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -87,7 +87,7 @@ \subsection{Previous Work} \label{ch:previous} \cite{dwork92pricingvia} provided the first work into the usage of a cryptographic proof of computational expenditure (``proof-of-work'') as a means of transmitting a value signal over the Internet. The value-signal was utilised here as a spam deterrence mechanism rather than any kind of currency, but critically demonstrated the potential for a basic data channel to carry a \textit{strong economic signal}, allowing a receiver to make a physical assertion without having to rely upon \textit{trust}. \cite{back2002hashcash} later produced a system in a similar vein. -The first example of utilising the proof-of-work as a strong economic signal to secure a currency was by \cite{vishnumurthy03karma:a}. In this instance, the token was used to keep peer-to-peer file trading in check, ensuring ``consumers'' be able to make micro-payments to ``suppliers'' for their services. The security model afforded by the proof-of-work was augmented with digital signatures and a ledger in order to ensure that the historical record couldn't be corrupted and that malicious actors could not spoof payment or unjustly complain about service delivery. Five years later, \cite{nakamoto2008bitcoin} introduced another such proof-of-work-secured value token, somewhat wider in scope. The fruits of this project, Bitcoin, became the first widely adopted global decentralised transaction ledger. +The first example of utilising the proof-of-work as a strong economic signal to secure a currency was by \cite{vishnumurthy03karma:a}. In this instance, the token was used to keep peer-to-peer file trading in check, providing ``consumers'' with the ability to make micro-payments to ``suppliers'' for their services. The security model afforded by the proof-of-work was augmented with digital signatures and a ledger in order to ensure that the historical record couldn't be corrupted and that malicious actors could not spoof payment or unjustly complain about service delivery. Five years later, \cite{nakamoto2008bitcoin} introduced another such proof-of-work-secured value token, somewhat wider in scope. The fruits of this project, Bitcoin, became the first widely adopted global decentralised transaction ledger. Other projects built on Bitcoin's success; the alt-coins introduced numerous other currencies through alteration to the protocol. Some of the best known are Litecoin and Primecoin, discussed by \cite{sprankel2013technical}. Other projects sought to take the core value content mechanism of the protocol and repurpose it; \cite{aron2012bitcoin} discusses, for example, the Namecoin project which aims to provide a decentralised name-resolution system. From 9dbc1d68e4aff58efbbde61ba564291859220f5d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 12:29:32 +1100 Subject: [PATCH 212/460] ... refer to Appendix \ref{ch:Terminology}. --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index 8ae6489a..f426e558 100644 --- a/Paper.tex +++ b/Paper.tex @@ -98,6 +98,7 @@ \subsection{Previous Work} \label{ch:previous} Early work on smart contracts has been done by \cite{szabo1997formalizing} and \cite{miller1997future}. Around the 1990s it became clear that algorithmic enforcement of agreements could become a significant force in human cooperation. Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems. In this light, Ethereum may be seen as a general implementation of such a \textit{crypto-law} system. %E language? +For a list of terms used in this paper, refer to Appendix \ref{ch:Terminology}. \section{The Blockchain Paradigm} \label{ch:overview} From e0caa58e62ac724ca91d6e065dcf7920634321b7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 14:49:50 +1100 Subject: [PATCH 213/460] Remove seemingly out-of-date to-do. --- Paper.tex | 2 -- 1 file changed, 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..417b23f5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -580,8 +580,6 @@ \subsection{Execution} where $T_\mathbf{i},T_\mathbf{d}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. -%todo Explain g_d reason? - The up-front cost $v_0$ is calculated as: \begin{equation} v_0 \equiv T_g T_p + T_v From 7ecd05765f55b701cda957ed51fb705c6e26e591 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 15:51:34 +1100 Subject: [PATCH 214/460] =?UTF-8?q?hypertargets=20lines=20100=E2=80=93199?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..1b200317 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally:\hypertarget{Upsilon_state_transition}{Upsilon_state_transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} @@ -179,7 +179,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \hypertarget{ell}{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -195,7 +195,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: -\begin{description} +\begin{description}\hypertarget{account_nonce}{account_nonce} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. From b6c96005f1bf7e9e14851a6de146368d6adc4d40 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 15:51:42 +1100 Subject: [PATCH 215/460] =?UTF-8?q?hypertargets=20lines=20200=E2=80=93299?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..710b57cd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function: +where $v$ is the account validity function:\hypertarget{v x}{} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{T n}{} -\begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$. -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$. +\begin{description}\hypertarget{T n}{} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{T p}{} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{T g}{} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{T t}{} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{T v}{} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From ed97640a98aaaa0668bb4fe4fc1f92592e136112 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 15:59:44 +1100 Subject: [PATCH 216/460] Update labels and targets --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index 710b57cd..6a8d11bd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function:\hypertarget{v x}{} +where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account_validity_function_v__x} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{T n}{} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: -\begin{description}\hypertarget{T n}{} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{T p}{} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{T g}{} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{T t}{} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{T v}{} +\begin{description}\hypertarget{tx_nonce}{tx_nonce_T__n} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx_gas_price_T__p} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx_to_address_T__t} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx_value_T__v}{tx_value_T__v} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 51f8393dd0703114245a217bb937406da42b6f49 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:03:18 +1100 Subject: [PATCH 217/460] =?UTF-8?q?hypertargets=20lines=20300=E2=80=93349?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..25646cdc 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,37 +307,37 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} -\begin{description} +\begin{description}\hypertarget{H p}{parentHash} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{H c}{beneficiary} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$. -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$. +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts-Root-def}{receipts-Root-def} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs-Bloom-def}{logs-Bloom-def} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$. +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{H_i}{blocknumber} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$. -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$. -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$. -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$. -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$. +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{H_g}{gasUsed} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{H_s}{timestamp} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{H_x}{extraData} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{H_m}{mixHash} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block nonce}{block_nonce}\hypertarget{H_n}{block_nonce} \item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. -\end{description} +\end{description}\hypertarget{B U}{} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation} +\end{equation}\hypertarget{Transaction Receipt}{Transaction_Receipt} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{R}{transaction_receipt}\hypertarget{R u}{tx_receipt_gas_used} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 205feed47f8883d078a762476e3e78037a086f01 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:13:48 +1100 Subject: [PATCH 218/460] Update labels=targets --- Paper.tex | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Paper.tex b/Paper.tex index 25646cdc..d96e2048 100644 --- a/Paper.tex +++ b/Paper.tex @@ -311,23 +311,23 @@ \subsection{The Block} \label{ch:block} %\textit{TODO: Introduce logs} -\begin{description}\hypertarget{H p}{parentHash} +\begin{description}\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{H c}{beneficiary} +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary_H__c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts-Root-def}{receipts-Root-def} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs-Bloom-def}{logs-Bloom-def} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts_Root_def_words} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs_Bloom_def_words} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{H_i}{blocknumber} +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block_number_H_i} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{H_g}{gasUsed} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{H_s}{timestamp} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{H_x}{extraData} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{H_m}{mixHash} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block nonce}{block_nonce}\hypertarget{H_n}{block_nonce} +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block_gas_used_H__g} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block_timestamp_H__s} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block_extraData_H__x} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block_nonce_H__n} \item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. -\end{description}\hypertarget{B U}{} +\end{description}\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} @@ -337,7 +337,7 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{R}{transaction_receipt}\hypertarget{R u}{tx_receipt_gas_used} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx_receipt_gas_used_R__u} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 650251a328da383a628339ca1d4a81575c7a9725 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:29:03 +1100 Subject: [PATCH 219/460] =?UTF-8?q?hypertargets=20lines=20350=E2=80=93399?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..c794908e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -389,11 +389,11 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} -\begin{array}[t]{lclc} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ +\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{block_validity_H__r} +H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{Ommer_block_hash_H__o}\\ +H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{tx_block_hash_H__t}\\ +H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{Receipts_Root_H__e}\\ +H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{logs_Bloom_filter_H__b}\\ H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} From e4146a6f3f7f9b094b28ea28bdbf906d305779f0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:45:33 +1100 Subject: [PATCH 220/460] =?UTF-8?q?Hypertargets=20lines=20400=E2=80=93499?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..09fe2e47 100644 --- a/Paper.tex +++ b/Paper.tex @@ -397,7 +397,6 @@ \subsubsection{Holistic Validity} H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} - where $p(k, v)$ is simply the pairwise RLP transformation, in this case, the first being the index of the transaction in the block and the second being the transaction receipt: \begin{equation} p(k, v) \equiv \big( \mathtt{\small RLP}(k), \mathtt{\small RLP}(v) \big) @@ -418,7 +417,7 @@ \subsubsection{Serialisation} \begin{eqnarray} \quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ \quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) -\end{eqnarray} +\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{general_element_wise_sequence_transformation_f_pow_asterisk} With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} @@ -458,7 +457,7 @@ \subsubsection{Block Header Validity} \newcommand{\mindifficulty}{D_0} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} -\newcommand{\diffadjustment}{x} +\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{block_difficulty_H__d} The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} @@ -486,7 +485,7 @@ \subsubsection{Block Header Validity} \begin{align} \expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ H'_i &\equiv \max(H_i - 3000000, 0) -\end{align} +\end{align}\hypertarget{block_gas_limit_H__l}{block_gas_limit_H__l} The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} @@ -495,7 +494,7 @@ \subsubsection{Block Header Validity} & & H_l \geqslant 5000 \end{eqnarray} -$H_s$ is the timestamp of block $H$ and must fulfil the relation: +$H_s$ is the timestamp (in Unix time) of block $H$ at the block's inception, and must fulfil the relation: \begin{equation} H_s > {P(H)_H}_s \end{equation} From f16cfa1c379ce65a69a4e1a246d5d1ec497a0c11 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:51:11 +1100 Subject: [PATCH 221/460] =?UTF-8?q?hypertargets=20lines=20500=E2=80=93599?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..29c19138 100644 --- a/Paper.tex +++ b/Paper.tex @@ -506,11 +506,11 @@ \subsubsection{Block Header Validity} \begin{equation} n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{block_header_without_nonce_and_mixmash_h__cancel_n} Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. -This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. +This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{block_header_validity_function} Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} @@ -561,16 +561,16 @@ \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) -\end{equation} +\end{equation}\hypertarget{self_destruct_set_wordy_defn}{self_destruct_set_wordy_defn} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{tx_log_series_wordy_defn} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{refund_balance_defn_words} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} -\subsection{Execution} +\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{intrinsic_gas_g_0} We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ @@ -591,7 +591,7 @@ \subsection{Execution} \begin{equation} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ -\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \\ +\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{transaction_nonce}\\ T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ g_0 & \leqslant & T_g \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ From bd1d68f618dcc104884610b57fed97a1bddb624b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 16:57:29 +1100 Subject: [PATCH 222/460] =?UTF-8?q?hypertargets=20lines=20646=E2=80=93662?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..6cb2ee8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -643,11 +643,12 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} -\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{self_destruct_list_A__s}\\ +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{touched_A__t}\\ \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{tx_total_gas_used_Upsilon_pow_g}\hypertarget{tx_logs_Upsilon_pow_l}{tx_logs_Upsilon_pow_l}\hypertarget{tx_status_Upsilon_pow_s} And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ @@ -658,6 +659,7 @@ \subsection{Execution} These are used to help define the transaction receipt, discussed later. \section{Contract Creation} \label{ch:create} +\hypertarget{endow}{endow} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). From 472903527a7edee43c694f41117975bbb07a2df9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 17:24:26 +1100 Subject: [PATCH 223/460] =?UTF-8?q?hypertargets=20lines=20871=E2=80=93882?= =?UTF-8?q?=20exec=20params?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..3952b96e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -868,16 +868,16 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: -\begin{itemize} -\item $I_a$, the address of the account which owns the code that is executing. -\item $I_o$, the sender address of the transaction that originated this execution. -\item $I_p$, the price of gas in the transaction that originated this execution. -\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. -\item $I_\mathbf{b}$, the byte array that is the machine code to be executed. -\item $I_H$, the block header of the present block. -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{address_of_account_which_owns_code_I__a_def_words} +\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{address_of_sender_of_tx_that_originated_execution_I__o} +\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{gas_price_in_tx_that_originated_execution_I__p} +\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{execution_input_data_I__d} +\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s} +\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{Wei_value_exec_I__v} +\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{exec_machine_code_I__b} +\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{exec_block_header_I__H} +\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{exec_call_or_create_depth_I__e} +\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{exec_permission_to_modify_state_I__w} \item $I_w$, the permission to make modifications to the state. \end{itemize} From 979eb7e9f40cccf95b268a0245ed1a3f44248ff2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 17:30:25 +1100 Subject: [PATCH 224/460] \hypertarget{Exceptional_Halting_function_Z}{Exceptional_Halting_function_Z} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..1382e779 100644 --- a/Paper.tex +++ b/Paper.tex @@ -942,7 +942,7 @@ \subsubsection{Machine State} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\subsubsection{Exceptional Halting} +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{Exceptional_Halting_function_Z} The exceptional halting function $Z$ is defined as: \begin{equation} From 3abc92be441fbdd12213da9116b5356a2cd68119 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 17:32:12 +1100 Subject: [PATCH 225/460] \hypertarget{normal_halting_function_H}{normal_halting_function_H} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..33223668 100644 --- a/Paper.tex +++ b/Paper.tex @@ -993,7 +993,7 @@ \subsubsection{Jump Destination Validity} N(i, w) \equiv \begin{cases} i + w - \text{\small PUSH1} + 2 & \text{if} \quad w \in [\text{\small PUSH1}, \text{\small PUSH32}] \\ i + 1 & \text{otherwise} \end{cases} -\end{equation} +\end{equation}\hypertarget{normal_halting_function_H}{normal_halting_function_H} \subsubsection{Normal Halting} From e799551402a90a752b749559afdc84bf7517b628 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 18:59:47 +1100 Subject: [PATCH 226/460] \hypertarget{JUMP}{JUMP} \hypertarget{JUMPI}{JUMPI} \label{eq:mu_pc} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..9f09aefd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1020,7 +1020,7 @@ \subsection{The Execution Cycle} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: \begin{eqnarray} -\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \\ +\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \hypertarget{JUMP}{JUMP} \hypertarget{JUMPI}{JUMPI} \label{eq:mu_pc}\\ \quad \boldsymbol{\mu}'_{pc} & \equiv & \begin{cases} J_{\text{JUMP}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ J_{\text{JUMPI}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ From 816f31b858c19cce8c413b716a79bf2e67d3fa1c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 23 Jan 2018 10:21:39 +0000 Subject: [PATCH 227/460] Comment out tabularx --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 568cb82e..13bd410a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -26,7 +26,7 @@ %https://stackoverflow.com/questions/1918366/automated-line-breaks-in-latex-tables/1918465#1918465 %tabularx seems better, but we can include this if we need tables to break across pages automatically, as well as tabu and longtabu -\usepackage{tabularx} +%\usepackage{tabularx} %https://stackoverflow.com/a/1919447/7438857 % Tabu seems more flexible, and generally better. From ac55a9af43d79a084934717b676b5ec507aff8b8 Mon Sep 17 00:00:00 2001 From: nicksavers Date: Tue, 23 Jan 2018 11:41:34 +0100 Subject: [PATCH 228/460] Remove duplicate REVERT opcode --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a477bb06..5053c0d3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2279,8 +2279,7 @@ \subsection{Instruction Set} &&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ -0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes - but returning data and gas. \\ +\midrule 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we need to define the memory usage: \\ From 277af38f7da4f7699b21958a0006e98be8799a3b Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 22 Jan 2018 10:13:58 +0000 Subject: [PATCH 229/460] Clean up formatting of REVERT opcode description. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4acfb632..ad9c56a2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2278,9 +2278,9 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ \midrule -0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and gas. \\ +0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and remaining gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ -&&&& For the gas calculation, we need to define the memory usage: \\ +&&&& For the gas calculation, we use the memory expansion function, \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ From 7573a1f1a69f02692ed517aa3e16e79e7ccf80d4 Mon Sep 17 00:00:00 2001 From: Zac Mitton Date: Tue, 23 Jan 2018 19:55:51 +0100 Subject: [PATCH 230/460] changed ordering or receipt items to correct client implementation --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d5e6f46e..cee93f03 100644 --- a/Paper.tex +++ b/Paper.tex @@ -339,9 +339,9 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: +The transaction receipt is a tuple of four items comprising the status code of the transaction, $R_{s'}$, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$, and the Bloom filter composed from information in those logs, $R_b$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) +R \equiv (R_{s'}, R_u, R_b, R_\mathbf{l}) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: From 6c06222e5d784e8af4598663f3f97b021390e636 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:46:29 +1100 Subject: [PATCH 231/460] Update Paper.tex --- Paper.tex | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9f09aefd..3dbeb89a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -951,7 +951,8 @@ \subsubsection{Exceptional Halting} \boldsymbol{\mu}_g < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ -( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ +( w \in \{ \text{\small JUMP}, \text{\small +} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ ( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ \neg I_w \wedge W(w, \boldsymbol{\mu}) @@ -1020,7 +1021,7 @@ \subsection{The Execution Cycle} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: \begin{eqnarray} -\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \hypertarget{JUMP}{JUMP} \hypertarget{JUMPI}{JUMPI} \label{eq:mu_pc}\\ +\quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \label{eq:mu_pc}\\ \quad \boldsymbol{\mu}'_{pc} & \equiv & \begin{cases} J_{\text{JUMP}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ J_{\text{JUMPI}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ @@ -2080,11 +2081,11 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} -\end{cases}$ \\ +\end{cases}$ \hypertarget{JUMP}{JUMP} \\ \midrule 0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ -&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ +&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \hypertarget{JUMPI}{JUMPI}\\ \midrule 0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ From b3c6dcb0aeee486a28bb02a6f6607f5797303650 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:54:35 +1100 Subject: [PATCH 232/460] sudo apt install texlive-latex-extra --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 7efafc8e..d2130c78 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,6 +2,7 @@ sudo: required before_install: - sudo apt-get -qq update - sudo apt-get install texlive texlive-latex3 +- sudo apt install texlive-latex-extra script: - ./build.sh deploy: From 0c26d26f5fed808b900569063741e065bd312874 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:57:29 +1100 Subject: [PATCH 233/460] Omit comments on longtable and tabularx --- Paper.tex | 7 ------- 1 file changed, 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index 13bd410a..cdadbb43 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,13 +22,6 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -%\usepackage{longtable} -%https://stackoverflow.com/questions/1918366/automated-line-breaks-in-latex-tables/1918465#1918465 -%tabularx seems better, but we can include this if we need tables to break across pages automatically, as well as tabu and longtabu - -%\usepackage{tabularx} -%https://stackoverflow.com/a/1919447/7438857 - % Tabu seems more flexible, and generally better. \usepackage{tabu} %requires array. From bbef522c828c129fb1b07f1e3526ebca279cadb9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 09:58:12 +1100 Subject: [PATCH 234/460] Omit comment on tabu --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index cdadbb43..9edecd58 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,6 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -% Tabu seems more flexible, and generally better. \usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} From dbbe44f4658f990962b26ee33c1aeb317a84b68c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 10:17:25 +1100 Subject: [PATCH 235/460] Add a space before \hypertarget in text mode to see if that will cause the build to pass. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1b200317..8701adf2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally:\hypertarget{Upsilon_state_transition}{Upsilon_state_transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon_state_transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From f297768d8db638ba47d935fa4a16578339a3d6e3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:19:52 +1100 Subject: [PATCH 236/460] omit network congestion --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 87b60e10..6df182db 100644 --- a/Paper.tex +++ b/Paper.tex @@ -482,7 +482,7 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up due to network congestion. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 22fae679888bf26547a89a6994df2b8477115467 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:26:50 +1100 Subject: [PATCH 237/460] Testing without underscores in the captions --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8701adf2..dff0800d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon_state_transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon state transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} @@ -195,7 +195,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: -\begin{description}\hypertarget{account_nonce}{account_nonce} +\begin{description}\hypertarget{account_nonce}{account nonce} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. From cee1a11f3ffbb38ab064f7e51ff8196110e1af13 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:34:46 +1100 Subject: [PATCH 238/460] Move \hypertarget{account_nonce}{account nonce} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index dff0800d..ba39f1f5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -193,9 +193,9 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. -The account state comprises the following four fields: +The account state comprises the following four fields:\hypertarget{account_nonce}{account nonce} -\begin{description}\hypertarget{account_nonce}{account nonce} +\begin{description} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. From c11db33dfe40a6c2c8e979c4c36dc90d604fd9a3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:50:09 +1100 Subject: [PATCH 239/460] Move \hypertarget{tx_nonce}{tx_nonce_T__n} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6a8d11bd..c4468568 100644 --- a/Paper.tex +++ b/Paper.tex @@ -252,9 +252,9 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx_nonce_T__n} -\begin{description}\hypertarget{tx_nonce}{tx_nonce_T__n} +\begin{description} \item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx_gas_price_T__p} \item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx_to_address_T__t} From b7d3fad2254f496e16edf0ddeb4deea7aeb44285 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:51:31 +1100 Subject: [PATCH 240/460] Move \hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d96e2048..68eb2623 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,11 +307,11 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} %\textit{TODO: Introduce logs} -\begin{description}\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} +\begin{description} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. \item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary_H__c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. From 5122b40882437f80bf089e08db5b756478b95103 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:54:16 +1100 Subject: [PATCH 241/460] Move \hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 68eb2623..c133b77b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -326,8 +326,8 @@ \subsection{The Block} \label{ch:block} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block_extraData_H__x} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block_nonce_H__n} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. -\end{description}\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} +\end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} From 19be698ac4ac9a96b0330d7932d251eef46df868 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:55:56 +1100 Subject: [PATCH 242/460] Omit underscores in captions --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index c4468568..2a8965cf 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account_validity_function_v__x} +where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account validity function v x} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx_nonce_T__n} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx nonce T n} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx_gas_price_T__p} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx gas price T p} \item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx_to_address_T__t} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx_value_T__v}{tx_value_T__v} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx to address T t} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{tx value T v} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From b8e7f78f726c86d3c0108f24c4c02470de4233fa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 11:56:43 +1100 Subject: [PATCH 243/460] Test a hypen in a caption --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ba39f1f5..6d209925 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon state transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon-state transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From e90133a248b220dff5dc84398751b9738b16b241 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:13:50 +1100 Subject: [PATCH 244/460] Hypertargets for Omega, block-reward-R-b, Gamma, Phi and Pi --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..1d28711a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1093,7 +1093,7 @@ \subsection{Transaction Validation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{Omega} Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ @@ -1107,14 +1107,14 @@ \subsection{Reward Application} R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b \end{eqnarray} -If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. +If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively.\hypertarget{block-reward-R-b}{block-reward-R-b} We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_b = 3 \times 10^{18} \end{equation} -\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} +\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarget{Gamma}{Gamma} We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} @@ -1124,7 +1124,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure.\hypertarget{Phi}{Phi} And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} @@ -1160,7 +1160,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} We define $\mathbf{R}[n]_{s'}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{s'} = -\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\hypertarget{Pi}{Pi} \end{equation} Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From ddd8276c2b2655f39b82e1cbb7218091f5c57e6c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:16:55 +1100 Subject: [PATCH 245/460] Change underscores to spaces in hypertarget captions --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index c133b77b..6463fbfb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,26 +307,26 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent_Hash_H__p_def_words} +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent Hash H p def words} %\textit{TODO: Introduce logs} \begin{description} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary_H__c} +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary H c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. \item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts_Root_def_words} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs_Bloom_def_words} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs Bloom def words} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block_number_H_i} +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block number H i} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block_gas_used_H__g} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block_timestamp_H__s} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block_extraData_H__x} +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block gas used H g} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block timestamp H s} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block extraData H x} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block_nonce_H__n} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{ommer_block_headers_B__U}\hypertarget{block_B}{block_B} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block nonce H n} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer block headers B U}{ommer_block_headers_B__U}\hypertarget{block_B}{block B} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: @@ -337,7 +337,7 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx_receipt_gas_used_R__u} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From fd3a67e16320ce80784a7d8399d46320cc251c75 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:20:30 +1100 Subject: [PATCH 246/460] Change underscores to spaces in hypertarget captions --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2a8965cf..42affba6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -234,7 +234,7 @@ \subsection{World State} \label{ch:state} \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function:\hypertarget{account_validity_function_v__x}{account validity function v x} +where $v$ is the account validity function:\hypertarget{account validity function v x}{account validity function v x} \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -256,7 +256,7 @@ \subsection{The Transaction} \label{ch:transaction} \begin{description} \item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx gas price T p} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx_gas_limit_T__g} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx gas limit T g} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx to address T t} \item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{tx value T v} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. From 68fc644d6c3f2b6f2041602502bf685b3b6bd456 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:22:30 +1100 Subject: [PATCH 247/460] Change underscores to spaces in hypertarget captions --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6463fbfb..6e1baea6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -316,7 +316,7 @@ \subsection{The Block} \label{ch:block} \item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary H c} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts_Root_def_words} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts Root def words} \item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs Bloom def words} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. \item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block number H i} @@ -324,7 +324,7 @@ \subsection{The Block} \label{ch:block} \item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block gas used H g} \item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block timestamp H s} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block extraData H x} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash_H__m} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash H m} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block nonce H n} \item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer block headers B U}{ommer_block_headers_B__U}\hypertarget{block_B}{block B} \end{description} @@ -332,12 +332,12 @@ \subsection{The Block} \label{ch:block} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\hypertarget{Transaction Receipt}{Transaction_Receipt} +\end{equation}\hypertarget{Transaction Receipt}{Transaction Receipt} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction_receipt_R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction receipt R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 47697453cd0493a612f3fe96ba66ea27b22c6986 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:31:09 +1100 Subject: [PATCH 248/460] Change captions to empty. --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index c794908e..de7a75a0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -389,11 +389,11 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} -\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{block_validity_H__r} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{Ommer_block_hash_H__o}\\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{tx_block_hash_H__t}\\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{Receipts_Root_H__e}\\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{logs_Bloom_filter_H__b}\\ +\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{} +H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{}\\ +H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{}\\ +H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{}\\ +H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{}\\ H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} From bba00722c9ebca3681204c42ccfd5605117053e2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:32:34 +1100 Subject: [PATCH 249/460] Empty caption --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6d209925..7e003c98 100644 --- a/Paper.tex +++ b/Paper.tex @@ -101,7 +101,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{Upsilon-state transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} From 73f1d704a7918a00a6e5c0355bd3ca0820de95d7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:33:50 +1100 Subject: [PATCH 250/460] Change hypertarget captions to empty strings --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7e003c98..c0b05e34 100644 --- a/Paper.tex +++ b/Paper.tex @@ -179,7 +179,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \hypertarget{ell}{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \hypertarget{ell}{}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -193,7 +193,7 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. -The account state comprises the following four fields:\hypertarget{account_nonce}{account nonce} +The account state comprises the following four fields:\hypertarget{account_nonce}{} \begin{description} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. From 29b0eff528fc23a53352f2b769e742c8de8f2dae Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 12:55:17 +1100 Subject: [PATCH 251/460] Change hypertarget captions to empty strings --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index 42affba6..41cc281c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -232,9 +232,9 @@ \subsection{World State} \label{ch:state} This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} -\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) +\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\hypertarget{account validity function v x}{} \end{equation} -where $v$ is the account validity function:\hypertarget{account validity function v x}{account validity function v x} +where $v$ is the account validity function: \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{tx nonce T n} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{tx gas price T p} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{tx gas limit T g} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{tx to address T t} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{tx value T v} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 6bd7a7eee66267678f3c56cf55b8dd3f0366667c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:02:10 +1100 Subject: [PATCH 252/460] Change hypertarget captions to empty strings --- Paper.tex | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6e1baea6..42dc160f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,37 +307,37 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{ommerheaders} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{parent Hash H p def words} +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{} %\textit{TODO: Introduce logs} \begin{description} \item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{beneficiary H c} +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{} \item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{receipts Root def words} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{logs Bloom def words} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{} +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{} \item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{block number H i} +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{} \item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{block gas used H g} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{block timestamp H s} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{block extraData H x} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{mixHash H m} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{block nonce H n} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer block headers B U}{ommer_block_headers_B__U}\hypertarget{block_B}{block B} +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{} +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{} +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}\hypertarget{block_B}{} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\hypertarget{Transaction Receipt}{Transaction Receipt} +\end{equation}\hypertarget{Transaction Receipt}{} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{transaction receipt R}\hypertarget{tx_receipt_gas_used_R__u}{tx receipt gas used R u} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{}\hypertarget{tx_receipt_gas_used_R__u}{} The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} From 20f1c3915e592950e8f0ed66893b1e6af00b9900 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:03:49 +1100 Subject: [PATCH 253/460] Change hypertarget captions to empty strings --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 09fe2e47..18310923 100644 --- a/Paper.tex +++ b/Paper.tex @@ -417,7 +417,7 @@ \subsubsection{Serialisation} \begin{eqnarray} \quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ \quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) -\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{general_element_wise_sequence_transformation_f_pow_asterisk} +\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{} With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} @@ -457,7 +457,7 @@ \subsubsection{Block Header Validity} \newcommand{\mindifficulty}{D_0} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} -\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{block_difficulty_H__d} +\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{} The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} @@ -485,7 +485,7 @@ \subsubsection{Block Header Validity} \begin{align} \expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ H'_i &\equiv \max(H_i - 3000000, 0) -\end{align}\hypertarget{block_gas_limit_H__l}{block_gas_limit_H__l} +\end{align}\hypertarget{block_gas_limit_H__l}{} The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 7978dff70e3ab90ce8c78379076b3672288aea3e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:05:34 +1100 Subject: [PATCH 254/460] Change hypertarget captions to empty strings --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 29c19138..55f8d2d6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -506,11 +506,11 @@ \subsubsection{Block Header Validity} \begin{equation} n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{block_header_without_nonce_and_mixmash_h__cancel_n} +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{} Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. -This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{block_header_validity_function} +This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{} Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} @@ -561,16 +561,16 @@ \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) -\end{equation}\hypertarget{self_destruct_set_wordy_defn}{self_destruct_set_wordy_defn} +\end{equation}\hypertarget{self_destruct_set_wordy_defn}{} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{tx_log_series_wordy_defn} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{refund_balance_defn_words} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn}{} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} -\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{intrinsic_gas_g_0} +\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{} We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ @@ -591,7 +591,7 @@ \subsection{Execution}\hypertarget{intrinsic_gas_g_0}{intrinsic_gas_g_0} \begin{equation} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ -\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{transaction_nonce}\\ +\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{}\\ T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ g_0 & \leqslant & T_g \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ From b76bcf34b69a33a1461b7ed9938a81d3699df539 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:07:00 +1100 Subject: [PATCH 255/460] Change hypertarget captions to empty strings --- Paper.tex | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6cb2ee8c..a1d36483 100644 --- a/Paper.tex +++ b/Paper.tex @@ -643,12 +643,12 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} -\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{self_destruct_list_A__s}\\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{touched_A__t}\\ +\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{}\\ +\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{}\\ \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{tx_total_gas_used_Upsilon_pow_g}\hypertarget{tx_logs_Upsilon_pow_l}{tx_logs_Upsilon_pow_l}\hypertarget{tx_status_Upsilon_pow_s} +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{} And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ @@ -656,10 +656,9 @@ \subsection{Execution} \Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' \end{eqnarray} -These are used to help define the transaction receipt, discussed later. +These are used to help define the transaction receipt, discussed later.\hypertarget{endow}{} \section{Contract Creation} \label{ch:create} -\hypertarget{endow}{endow} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). From 4d76dbdc8f2894a6cf422bc43e027dd3685a3a19 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:08:31 +1100 Subject: [PATCH 256/460] Change hypertarget captions to empty strings --- Paper.tex | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3952b96e..6aa92535 100644 --- a/Paper.tex +++ b/Paper.tex @@ -868,16 +868,16 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: -\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{address_of_account_which_owns_code_I__a_def_words} -\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{address_of_sender_of_tx_that_originated_execution_I__o} -\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{gas_price_in_tx_that_originated_execution_I__p} -\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{execution_input_data_I__d} -\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s} -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{Wei_value_exec_I__v} -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{exec_machine_code_I__b} -\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{exec_block_header_I__H} +\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{} +\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{} +\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{} +\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{} +\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} +\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{} +\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{} +\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{} \item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{exec_call_or_create_depth_I__e} -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{exec_permission_to_modify_state_I__w} +\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{} \item $I_w$, the permission to make modifications to the state. \end{itemize} From bb543b2cc9f30ada50062712fc1107a659009809 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:27:03 +1100 Subject: [PATCH 257/460] Add a missing {} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 42dc160f..6e862de3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -326,7 +326,7 @@ \subsection{The Block} \label{ch:block} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}\hypertarget{block_B}{} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}{}\hypertarget{block_B}{} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: From ff6c7f4b0f9752cd1cfca3dac6f7170975891ac0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:28:29 +1100 Subject: [PATCH 258/460] Change hypertarget captions to empty strings --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6aa92535..ee46e867 100644 --- a/Paper.tex +++ b/Paper.tex @@ -876,7 +876,7 @@ \subsection{Execution Environment} \item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{} \item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{} \item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{} -\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{exec_call_or_create_depth_I__e} +\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{} \item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{} \item $I_w$, the permission to make modifications to the state. \end{itemize} From 981f9d1926b05f7c75c366bdbda75474ec994a01 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:31:29 +1100 Subject: [PATCH 259/460] Change hypertarget caption to empty string --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1382e779..c3decb03 100644 --- a/Paper.tex +++ b/Paper.tex @@ -942,7 +942,7 @@ \subsubsection{Machine State} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{Exceptional_Halting_function_Z} +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} The exceptional halting function $Z$ is defined as: \begin{equation} From 6c65fec06523c648c2b81dde5af3604f818ec548 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:31:57 +1100 Subject: [PATCH 260/460] Change hypertarget caption to empty string normal_halting_function_H --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 33223668..06b44484 100644 --- a/Paper.tex +++ b/Paper.tex @@ -993,7 +993,7 @@ \subsubsection{Jump Destination Validity} N(i, w) \equiv \begin{cases} i + w - \text{\small PUSH1} + 2 & \text{if} \quad w \in [\text{\small PUSH1}, \text{\small PUSH32}] \\ i + 1 & \text{otherwise} \end{cases} -\end{equation}\hypertarget{normal_halting_function_H}{normal_halting_function_H} +\end{equation}\hypertarget{normal_halting_function_H}{} \subsubsection{Normal Halting} From 10872584cc0c687372c9c943d31ddb8244882029 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:34:04 +1100 Subject: [PATCH 261/460] Fix ommer_block_headers_B__U hypertarget --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 6e862de3..1bb5d7f4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -326,7 +326,7 @@ \subsection{The Block} \label{ch:block} \item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} \item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} \item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{}{ommer_block_headers_B__U}{}\hypertarget{block_B}{} +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{}\hypertarget{block_B}{} \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: From 4cf588662b0f231a47736cd557725b5fbdd85c90 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:37:11 +1100 Subject: [PATCH 262/460] \hypertarget{empty_sequence_vs_empty_set}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..e87c80b5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -892,7 +892,7 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine.\hypertarget{empty_sequence_vs_empty_set}{} The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} From f1492b9616041882effeb3b3e61c4b167ec2e7c0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:47:24 +1100 Subject: [PATCH 263/460] Add a comment on using the hyperref package --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..241082e4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -28,6 +28,7 @@ \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . +% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. \input{Version.tex} From bd5f7ee7bbb051fc8e0fe7a0360a17ba3f7f762c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 13:53:49 +1100 Subject: [PATCH 264/460] Add a note on link borders. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index aa07f273..302f6977 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A ## Usage -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text. ## How to build From 6a312f0152c67bd1373218f8f944540e8ee312a2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:22:39 +1100 Subject: [PATCH 265/460] \hypertarget{rlp}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..b2fdf400 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1282,7 +1282,7 @@ \section{Terminology} \item[LLL] The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to. \end{description} - +\hypertarget{rlp}{} \section{Recursive Length Prefix}\label{app:rlp} This is a serialisation method for encoding arbitrarily structured binary data (byte arrays). From ec04330228366009e14317d828a3203809b967c1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:25:57 +1100 Subject: [PATCH 266/460] \hypertarget{R b}{ --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..5f04a3b2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1307,7 +1307,7 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the byte-array contains fewer than 56 bytes, then the output is equal to the input prefixed by the byte equal to the length of the byte array plus 128. \item Otherwise, the output is equal to the input prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the input byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183. \end{itemize} - +\hypertarget{R b}{} Formally, we define $R_b$: \begin{eqnarray} R_b(\mathbf{x}) & \equiv & \begin{cases} From 397b1c3b55ba898b9dc94139fcef4fa15d9faca4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:26:48 +1100 Subject: [PATCH 267/460] \hypertarget{R l}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..881057e5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1327,7 +1327,7 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} - +\hypertarget{R l}{} Thus we finish by formally defining $R_l$: \begin{eqnarray} R_l(\mathbf{x}) & \equiv & \begin{cases} From 0fd7d93608e34c141eec80b13251e6270c342911 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:27:41 +1100 Subject: [PATCH 268/460] \hypertarget{trie}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..4e58d71b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1362,7 +1362,7 @@ \section{Hex-Prefix Encoding}\label{app:hexprefix} \end{eqnarray} Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the second-lowest encoding the flag $t$. The low nibble of the first byte is zero in the case of an even number of nibbles and the first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining bytes. - +\hypertarget{trie}{} \section{Modified Merkle Patricia Tree}\label{app:trie} The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32 byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. From bd69e1f086a676dd686cfbd069fb335eeca8b7ac Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:29:29 +1100 Subject: [PATCH 269/460] \hypertarget{ECDSASIGN}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..8ee3bb68 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1639,7 +1639,7 @@ \section{Signing Transactions}\label{app:signing} We assert the functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. \begin{eqnarray} -\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \\ +\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \hypertarget{ECDSASIGN}{}\\ \mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_r \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} From 667312895ca26e8561c4b3afb32133b46f42c2e1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:30:36 +1100 Subject: [PATCH 270/460] \hypertarget{v}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..53988573 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1644,7 +1644,7 @@ \section{Signing Transactions}\label{app:signing} \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} -Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which $r$ is the x-value; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The value 27 represents an even $y$ value and 28 represents an odd $y$ value. +Where $p_u$ is the public key, assumed to be a byte array of size 64 (formed from the concatenation of two positive integers each $< 2^{256}$) and $p_r$ is the private key, a byte array of size 32 (or a single positive integer in the \hypertarget{v}{}aforementioned range). It is assumed that $v$ is either the `recovery identifier' or `chain identifier doubled plus 35 or 36'. The recovery identifier is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which $r$ is the x-value; this value is in the range of $[27, 30]$, however we declare the upper two possibilities, representing infinite values, invalid. The value 27 represents an even $y$ value and 28 represents an odd $y$ value. \newcommand{\slimit}{\ensuremath{\text{s-limit}}} From 803f701b03eece3c2a1387d1d50fcf48504ef5ba Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:38:45 +1100 Subject: [PATCH 271/460] Add definitions for T_w, T_r and T_s (commented out, to be uncommented later) --- Paper.tex | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..c4191150 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1685,7 +1685,15 @@ \section{Signing Transactions}\label{app:signing} (T_w, T_r, T_s) = \mathtt{\small ECDSASIGN}(h(T), p_r) \end{eqnarray} -We may then define the sender function $S$ of the transaction as: +%Uncomment out after merging \hypertargets for v, r, and s. +%Thus: +%\begin{eqnarray}\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} +%T_{\mathrm{w}} = \hyperlink{v}{v}\\ +%T_{\mathrm{r}} = \hyperlink{r}{r}\\ +%T_{\mathrm{s}} = \hyperlink{s}{s} +%\end{eqnarray} + +We may then define the sender function $S$ of the transaction as:\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} \begin{eqnarray} S(T) &\equiv& \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), v_0, T_r, T_s) \big) \big) \\ v_0 &\equiv& \begin{cases} From be5f07f2e73d4beccd2f8271772e2cc9fb6f8d87 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:40:01 +1100 Subject: [PATCH 272/460] \hypertarget{h T}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..687d7928 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1664,7 +1664,7 @@ \section{Signing Transactions}\label{app:signing} \begin{equation} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} - +\hypertarget{h T}{} The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} From 3846671dc30d9836dfc399156b7a76425d26205e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 14:54:24 +1100 Subject: [PATCH 273/460] hypertargets for gas costs --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..876fc823 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1719,21 +1719,21 @@ \section{Fee Schedule}\label{app:fees} $G_{jumpdest}$ & 1 & Paid for a {\small JUMPDEST} operation. \\ $G_{sset}$ & 20000 & Paid for an {\small SSTORE} operation when the storage value is set to non-zero from zero. \\ $G_{sreset}$ & 5000 & Paid for an {\small SSTORE} operation when the storage value's zeroness remains unchanged or is set to zero. \\ -$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \\ -$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ +$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \hypertarget{Rselfdestruct}{}\\ +$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \hypertarget{Gselfdestruct}{}\\ $G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ $G_{create}$ & 32000 & Paid for a {\small CREATE} operation. \\ -$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \\ +$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \hypertarget{codedeposit}{}\\ $G_{call}$ & 700 & Paid for a {\small CALL} operation. \\ $G_{callvalue}$ & 9000 & Paid for a non-zero value transfer as part of the {\small CALL} operation. \\ -$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \\ +$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \hypertarget{Gnewaccount}{}\\ $G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\ $G_{exp}$ & 10 & Partial payment for an {\small EXP} operation. \\ $G_{expbyte}$ & 50 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\small EXP} operation. \\ -$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \\ -$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\\ -$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ -$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \\ +$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \hypertarget{Gtxcreate}{}\\ +$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\hypertarget{Gtxdatazero}{}\\ +$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \hypertarget{Gtxdatanonzero}{}\\ +$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \hypertarget{Gtransaction}{}\\ $G_{transaction}$ & 21000 & Paid for every transaction. \\ $G_{log}$ & 375 & Partial payment for a {\small LOG} operation. \\ $G_{logdata}$ & 8 & Paid for each byte in a {\small LOG} operation's data. \\ From 7040146b34014ef2f42392c904995e79bd6dabaf Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:04:47 +1100 Subject: [PATCH 274/460] move \hypertarget{Exceptional_Halting_function_Z}{exceptional halting} and 2 \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index c3decb03..a4fc8738 100644 --- a/Paper.tex +++ b/Paper.tex @@ -941,8 +941,8 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. - -\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} +\hypertarget{Exceptional_Halting_function_Z}{} +\subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: \begin{equation} @@ -2201,7 +2201,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting\\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_e = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_a]_b$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ @@ -2220,7 +2220,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an exceptional halting \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ From 161fd92230201f958f91ed11d7f1c85ec2efad99 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:12:03 +1100 Subject: [PATCH 275/460] hypertargets for operations --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..db8eef10 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1848,7 +1848,7 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{0s: Stop and Arithmetic Operations}} \\ \multicolumn{5}{l}{All arithmetic is modulo $2^{256}$ unless otherwise noted. The zero-th power of zero $0^0$ is defined to be one.} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{stop}{}\\ 0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule 0x01 & {\small ADD} & 2 & 1 & Addition operation. \\ @@ -2018,7 +2018,7 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{blockhash}{BLOCKHASH}\\ 0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ @@ -2067,14 +2067,14 @@ \subsection{Instruction Set} &&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \hypertarget{SSTORE}{}\\ \midrule 0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \hypertarget{C tiny SSTORE}{}\\ &&&& $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} -\end{cases}$ \\ +\end{cases}$ \hypertarget{A r}{}\\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} @@ -2169,7 +2169,7 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ -\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ +\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\hypertarget{A l}{}\\ \multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ \multicolumn{5}{l}{$\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ @@ -2223,7 +2223,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ -&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ +&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \hypertarget{tiny CALL}{}\\ &&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ @@ -2248,7 +2248,7 @@ \subsection{Instruction Set} &&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ -&&&& same account as at present, simply that the code is overwritten.\\ +&&&& same account as at present, simply that the code is overwritten.\hypertarget{RETURN}{}\\ \midrule 0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ &&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ @@ -2283,7 +2283,7 @@ \subsection{Instruction Set} &&&& For the gas calculation, we use the memory expansion function, \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule -0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ +0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \hypertarget{selfdestruct}{}\\ \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ &&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ @@ -2297,7 +2297,7 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} -\end{cases}$ \\ +\end{cases}$ \hypertarget{C tiny SELFDESTRUCT}{}\\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} From 9f764d24193a49104141f378c7ef669573b957f8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:16:52 +1100 Subject: [PATCH 276/460] Delete comments on LLL This is already in the terminology list. --- Paper.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..53469e8d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2306,9 +2306,7 @@ \subsection{Instruction Set} \bottomrule \end{tabular*} -%\section{Low-level Lisp-like Language}\label{app:lll} -%The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. - +\hypertarget{GenesisBlock}{} \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: From 801b4f5b71298dc7f5e3aa6ebba475ea66a46db4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:18:20 +1100 Subject: [PATCH 277/460] \hypertarget{Jwordbytes}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..527c5932 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2308,7 +2308,7 @@ \subsection{Instruction Set} %\section{Low-level Lisp-like Language}\label{app:lll} %The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. - +\hypertarget{GenesisBlock}{} \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: @@ -2326,7 +2326,7 @@ \subsection{Definitions} \begin{tabular*}{\columnwidth}[h]{lrl} \toprule -Name & Value & Description \\ +Name & Value & Description \hypertarget{Jwordbytes}{}\\ \midrule $J_{wordbytes}$ & 4 & Bytes in word. \\ $J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ From d1a358d694ae35e89cc22b55fea403c7832453db Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:24:42 +1100 Subject: [PATCH 278/460] hypertargets for Ethash parameters --- Paper.tex | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..1afc5478 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2308,7 +2308,7 @@ \subsection{Instruction Set} %\section{Low-level Lisp-like Language}\label{app:lll} %The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. - +\hypertarget{GenesisBlock}{} \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: @@ -2328,16 +2328,16 @@ \subsection{Definitions} \toprule Name & Value & Description \\ \midrule -$J_{wordbytes}$ & 4 & Bytes in word. \\ -$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ -$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \\ -$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \\ -$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \\ -$J_{epoch}$ & 30000 & Blocks per epoch. \\ -$J_{mixbytes}$ & 128 & mix length in bytes. \\ -$J_{hashbytes}$ & 64 & Hash length in bytes. \\ -$J_{parents}$ & 256 & Number of parents of each dataset element. \\ -$J_{cacherounds}$ & 3 & Number of rounds in cache production. \\ +$J_{wordbytes}$ & 4 & Bytes in word. \hypertarget{Jdatasetinit}{}\\ +$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \hypertarget{Jdatasetgrowth}{}\\ +$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \hypertarget{Jcacheinit}{}\\ +$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \hypertarget{Jcachegrowth}{}\\ +$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \hypertarget{Jepoch}{}\\ +$J_{epoch}$ & 30000 & Blocks per epoch. \hypertarget{Jmixbytes}{}\\ +$J_{mixbytes}$ & 128 & mix length in bytes. \hypertarget{Jhashbytes}{}\\ +$J_{hashbytes}$ & 64 & Hash length in bytes. \hypertarget{Jparents}{}\\ +$J_{parents}$ & 256 & Number of parents of each dataset element. \\hypertarget{Jcacherounds}{}\ +$J_{cacherounds}$ & 3 & Number of rounds in cache production. \hypertarget{Jaccesses}{}\\ $J_{accesses}$ & 64 & Number of accesses in hashimoto loop. \\ \bottomrule \end{tabular*} @@ -2347,7 +2347,7 @@ \subsection{Size of dataset and cache} \begin{equation} E_{epoch}(H_i) = \left\lfloor\frac{H_i}{J_{epoch}}\right\rfloor \end{equation} -The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache. +The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache.\hypertarget{dsize}{} Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using \begin{equation} d_{size} = E_{prime}(J_{datasetinit} + J_{datasetgrowth} \cdot E_{epoch} - J_{mixbytes}, J_{mixbytes}) @@ -2407,7 +2407,7 @@ \subsubsection{Cache} \end{equation} Where a single round modifies each subset of the cache as follows: \begin{equation} - E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big) + E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big)\hypertarget{Ecacherounds}{} \end{equation} \begin{multline} E_{rmh}(\mathbf{x}, i) = \texttt{KEC512}(\mathbf{x'}[(i - 1 + n) \mod n] \oplus \mathbf{x'}[\mathbf{x'}[i][0] \mod n]) \\ From 2bc7acec62754baa6b8a945f0f344b6aa2fd668c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:27:10 +1100 Subject: [PATCH 279/460] \hypertarget{bigvee}{} move closing brace --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index f426e558..172073d5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2508,8 +2508,8 @@ \section{List of mathematical symbols}\label{app:symbols} \toprule Symbol & Latex Command & Description \\ \midrule -\hypertarget{bigvee}{ -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).}\\ +\hypertarget{bigvee}{} +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabularx} From 53dd071e63cc46b76a3a7c8a3115fd8ba356e84e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 15:28:05 +1100 Subject: [PATCH 280/460] Delete redundant empty line --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 172073d5..8df36cf5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2496,7 +2496,6 @@ \subsection{Proof-of-work function} \end{cases} \end{equation} - \section{Anomalies on the Main Network} \subsection{Deletion of an Account Despite Out-of-gas} From 0b518f65d5835158bea6f5d52dae0d08968e5342 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 20:50:06 +1100 Subject: [PATCH 281/460] Replace a double quote with two single quotes --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 393504ba..1a2482af 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2168,7 +2168,7 @@ \subsubsection{Full dataset calculation} \label{dataset} \end{equation} \subsection{Proof-of-work function} -Essentially, we maintain a ``mix" $J_{mixbytes}$ bytes wide, and repeatedly sequentially fetch $J_{mixbytes}$ bytes from the full dataset and use the $E_\text{\tiny FNV}$ function to combine it with the mix. $J_{mixbytes}$ bytes of sequential access are used so that each round of the algorithm always fetches a full page from RAM, minimizing translation lookaside buffer misses which ASICs would theoretically be able to avoid. +Essentially, we maintain a ``mix'' $J_{mixbytes}$ bytes wide, and repeatedly sequentially fetch $J_{mixbytes}$ bytes from the full dataset and use the $E_\text{\tiny FNV}$ function to combine it with the mix. $J_{mixbytes}$ bytes of sequential access are used so that each round of the algorithm always fetches a full page from RAM, minimizing translation lookaside buffer misses which ASICs would theoretically be able to avoid. If the output of this algorithm is below the desired target, then the nonce is valid. Note that the extra application of \texttt{KEC} at the end ensures that there exists an intermediate nonce which can be provided to prove that at least a small amount of work was done; this quick outer PoW verification can be used for anti-DDoS purposes. It also serves to provide statistical assurance that the result is an unbiased, 256 bit number. From e6e7250d3dae4215c974775759825567717cfac0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 21:13:06 +1100 Subject: [PATCH 282/460] Add a line break before a tx address so that it doesn't run over the margin. --- Paper.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..1d3e13c8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2496,6 +2496,7 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} -At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +At block 2675119, in the transaction +\texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From c9fdebe15708510130790e3ae1046b1bd97b6e74 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 25 Jan 2018 21:16:26 +1100 Subject: [PATCH 283/460] Remove parentheses surrounding the revision number in the title so that the text doesn't clash with the page number --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c1a7bb8c..9e6ecc8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -46,7 +46,7 @@ \newcommand*\ie{i.e.\@\xspace} %\renewcommand{\itemhook}{\setlength{\topsep}{0pt} \setlength{\itemsep}{0pt}\setlength{\leftmargin}{15pt}} -\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium revision (\YellowPaperVersionNumber{})}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium version \YellowPaperVersionNumber{}}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Parity\\ From d0f0f251ae52be35d67db6cb3ca2445003e0be6a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 12:50:48 +1100 Subject: [PATCH 284/460] Replace all _(\{[A-Z]+\b)([^\}]) with _{mathbf$1}$2... ...using Libre Open Office with match case and regular expressions ticked as options. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index c834c995..54766bda 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1075,7 +1075,7 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{mathbf{U} \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) \end{equation} where $k$ denotes the ``is-kin'' property: @@ -1108,7 +1108,7 @@ \subsection{Reward Application} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ \qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ -\qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber +\qquad\forall_{mathbf{U} \in B_\mathbf{U}}: \\ \nonumber \boldsymbol{\sigma}'[U_c] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} @@ -1383,7 +1383,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} When considering such a sequence, we use the common numeric subscript notation to refer to a tuple's key or value, thus: \begin{equation} -\forall_{I \in \mathfrak{I}} I \equiv (I_0, I_1) +\forall_{mathbf{I} \in \mathfrak{I}} I \equiv (I_0, I_1) \end{equation} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: @@ -1421,7 +1421,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{mathbf{I} \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} From 0bf4bd2bfc118f3aeaf8299ba07a425cfbb29a88 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:09:27 +1100 Subject: [PATCH 285/460] \PassOptionsToPackage{tabularx}\usepackage{tabu} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 75340cf4..0aa5cff9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,7 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -\usepackage{tabu} %requires array. +\PassOptionsToPackage{tabularx}\usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} From 4cf696a0e149a90e663bf32f14989fc08e713797 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:15:43 +1100 Subject: [PATCH 286/460] Add a missing closing brace --- Biblio.bib | 1 + 1 file changed, 1 insertion(+) diff --git a/Biblio.bib b/Biblio.bib index 9b4e0507..16581a2c 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -9,6 +9,7 @@ @Book{Davey2002_zbMATH01748069 Language = {English}, MSC2010 = {06-01}, Zbl = {1002.06001}, +} @Misc{EIP-100, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md", From eeaad7f59bb051b9d593d475ca08ac9bdf5f43fd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:16:16 +1100 Subject: [PATCH 287/460] Delete an empty line --- Biblio.bib | 1 - 1 file changed, 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 16581a2c..8f6a90f6 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -32,7 +32,6 @@ @Misc{EIP-2 title = "EIP-2: Homestead Hard-fork Changes", author = "Vitalik Buterin", year = "2015", - } @Misc{cryptoeprint:2013:881, From 446bee8a557de8f6091200b1784550f23cb956e7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:38:55 +1100 Subject: [PATCH 288/460] \begin{tabu}{X[l]X[c]X} \savetabu{col3} --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 0aa5cff9..ff1e5b58 100644 --- a/Paper.tex +++ b/Paper.tex @@ -22,7 +22,7 @@ \usepackage[bookmarks=true, unicode=true, pdftitle={Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain}, pdfauthor={Gavin Wood and others as per https://github.com/ethereum/yellowpaper/commits/master},pdfkeywords={Ethereum, Yellow Paper, blockchain, virtual machine, cryptography, decentralised, singleton, transaction, generalised},pdfborder={0 0 0.5 [1 3]}]{hyperref} %,pagebackref=true -\PassOptionsToPackage{tabularx}\usepackage{tabu} %requires array. +\usepackage{tabu} %requires array. %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} @@ -2508,13 +2508,13 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \section{List of mathematical symbols}\label{app:symbols} -\begin{tabularx}{\textwidth}{lcX} +\begin{tabu}{X[l]X[c]X} \savetabu{col3} \toprule Symbol & Latex Command & Description \\ \midrule \hypertarget{bigvee}{} $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule -\end{tabularx} +\end{tabu} \end{document} From 438d028048f8b3db43115ccc11ccbb203fe79abb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:45:17 +1100 Subject: [PATCH 289/460] Move \hypertarget{bigvee}{} to preceding line --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index ff1e5b58..8b221dda 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,9 +2510,8 @@ \subsection{Deletion of an Account Despite Out-of-gas} \section{List of mathematical symbols}\label{app:symbols} \begin{tabu}{X[l]X[c]X} \savetabu{col3} \toprule -Symbol & Latex Command & Description \\ +Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule -\hypertarget{bigvee}{} $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabu} From 6b6f6d804cb846597634e7b9ae905a51e246ab2a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 13:46:03 +1100 Subject: [PATCH 290/460] Remove parentheses --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8b221dda..88b339d7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2512,7 +2512,7 @@ \section{List of mathematical symbols}\label{app:symbols} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements \cite{Davey2002_zbMATH01748069}.\\ \bottomrule \end{tabu} From 02fe4c677011432f2b9092402fd1ce588974d2f8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 14:05:34 +1100 Subject: [PATCH 291/460] tabu* --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 88b339d7..f42b1081 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2508,7 +2508,7 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \section{List of mathematical symbols}\label{app:symbols} -\begin{tabu}{X[l]X[c]X} \savetabu{col3} +\begin{tabu*}{X[l]X[c]X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule From 375e99379783f28e2069ec2936b94870c58c8e30 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 14:11:44 +1100 Subject: [PATCH 292/460] \hyperlink{GenesisBlock}{the genesis block} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 527c5932..4842bc4c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -145,7 +145,7 @@ \subsection{Value} \subsection{Which History?} -Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (the genesis block) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. +Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (\hyperlink{GenesisBlock}{the genesis block}) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. This would mean that past a given point in time (block), multiple states of the system may coexist: some nodes believing one block to contain the canonical transactions, other nodes believing some other block to be canonical, potentially containing radically different or incompatible transactions. This is to be avoided at all costs as the uncertainty that would ensue would likely kill all confidence in the entire system. From 54f93493cd830de761495c4d86aacbfa19fa70a6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 14:13:38 +1100 Subject: [PATCH 293/460] \end{tabu*} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f42b1081..753cf2f3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2514,6 +2514,6 @@ \section{List of mathematical symbols}\label{app:symbols} \midrule $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements \cite{Davey2002_zbMATH01748069}.\\ \bottomrule -\end{tabu} +\end{tabu*} \end{document} From 03d79bca4d16717e91c903797d5c5cebe7a80a18 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 18:16:07 +1100 Subject: [PATCH 294/460] Omit yellowpaper.io as it is outdated. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 302f6977..63ce53be 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ It is free culture work, licensed under the Creative Commons Attribution Share-A ## Usage -The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf or just [yellowpaper.io](http://yellowpaper.io/). If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text. +The paper comes as a single ``latex`` file ``Paper.tex``. The latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf. If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text. ## How to build From 8ad077cb861efafe82c30cfc93c056974289022a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 18:17:41 +1100 Subject: [PATCH 295/460] Update homestead block number and add Frontier. --- BRANCHES.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/BRANCHES.md b/BRANCHES.md index f52e3349..6f776007 100644 --- a/BRANCHES.md +++ b/BRANCHES.md @@ -8,4 +8,5 @@ Each protocol version is specified in `Paper.tex` found in a branch of this repo | spurious-dragon | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) | Since 2,675,000 until 4,369,999 | | tangerine-whistle | [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md) | Since 2,463,000 until 2,674,999 | | dao-fork | [DAO Fork](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-779.md) | Since 1,920,000 until 2,462,000 | -| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | Since 1 until 1,919,999 | +| homestead | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) | Since 1,150,000 until 1,919,999 | +| frontier | [Frontier](https://github.com/ethereum/yellowpaper/) | Since 1 until 1,149,999 | From fed380ae020523a18d49c033335409886bdbdf33 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 21:41:26 +1100 Subject: [PATCH 296/460] Add \nop command to modify hypertargets, and replace all \\hypertarget(\{.*\})\{\} with \nop$1 --- Paper.tex | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index c0b05e34..82a0c5be 100644 --- a/Paper.tex +++ b/Paper.tex @@ -29,6 +29,10 @@ % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . +\makeatletter + \newcommand{\nop}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} +\makeatother + \input{Version.tex} \newcommand{\hcancel}[1]{% @@ -101,7 +105,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \hypertarget{Upsilon_state_transition}{} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \nop{Upsilon_state_transition} \begin{equation} \boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} @@ -179,7 +183,8 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \hypertarget{ell}{}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. +op{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -193,7 +198,8 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. -The account state comprises the following four fields:\hypertarget{account_nonce}{} +The account state comprises the following four fields: +op{account_nonce} \begin{description} \item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. From fc45886a509b78c9bcd59a37181e6fa4687cf3b0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 21:45:31 +1100 Subject: [PATCH 297/460] Change linebreak op{ to \nop, and move \nop --- Paper.tex | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 82a0c5be..07cc9f39 100644 --- a/Paper.tex +++ b/Paper.tex @@ -105,9 +105,9 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \nop{Upsilon_state_transition} +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) +\nop{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -183,8 +183,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. -op{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \nop{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -199,10 +198,9 @@ \subsection{World State} \label{ch:state} The world state (\textit{state}), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix \ref{app:rlp}). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree (\textit{trie}, see Appendix \ref{app:trie}). The trie requires a simple database backend that maintains a mapping of bytearrays to bytearrays; we name this underlying database the state database. This has a number of benefits; firstly the root node of this structure is cryptographically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states. The account state comprises the following four fields: -op{account_nonce} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. +\item[nonce] \nop{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_c$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. From ea2854723d25b5b93d344c57479779b3d23f4ccd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 22:52:53 +1100 Subject: [PATCH 298/460] Add line breaks which removes many empty lines --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c834c995..2dc6e184 100644 --- a/Paper.tex +++ b/Paper.tex @@ -187,7 +187,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. One of the more common is $\ell$, which g last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -709,7 +709,9 @@ \section{Contract Creation} \label{ch:create} \begin{equation} (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} + where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: + \begin{eqnarray} I_a & \equiv & a \\ I_o & \equiv & o \\ From d69717fcd0a7a3c7d59d4f3afd46b46d8dcbb1c7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 22:57:25 +1100 Subject: [PATCH 299/460] Fix accident --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2dc6e184..d1fb126f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -187,7 +187,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. One of the more common is $\ell$, which g last item in the given sequence: +I define a number of useful functions throughout. One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] From ca1309d664b8d766f3745b488abed4ec1930f9e2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 26 Jan 2018 23:01:06 +1100 Subject: [PATCH 300/460] Remove unnecessary comment Given that these commands are after the hyperref package and haven't caused an issue, clearly this comment (to put them before) can be removed. --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c834c995..181a0833 100644 --- a/Paper.tex +++ b/Paper.tex @@ -35,7 +35,6 @@ \usepackage[english]{babel} \usepackage[autostyle]{csquotes} \MakeOuterQuote{"} -% Put before hyperref \input{Version.tex} From cf8ff0a78f5c74e40c54eb327a1911ab53dd2048 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 00:48:59 +1100 Subject: [PATCH 301/460] Add a \\ as a manual break --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1d3e13c8..7cdff15d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2497,6 +2497,6 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} At block 2675119, in the transaction -\texttt{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +\texttt{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From 9b4a598423700d5a8b0c8e26f8b1aa2fed821c48 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 00:50:50 +1100 Subject: [PATCH 302/460] Replace \nop with \linkdest --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7d65cf7d..fdf60250 100644 --- a/Paper.tex +++ b/Paper.tex @@ -30,7 +30,7 @@ % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . \makeatletter - \newcommand{\nop}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} + \newcommand{\linkdest}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} \makeatother % For formatting %\usepackage{underscore} @@ -113,7 +113,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\nop{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) +\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -189,7 +189,7 @@ \section{Conventions}\label{ch:conventions} When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \nop{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -206,7 +206,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: \begin{description} -\item[nonce] \nop{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. +\item[nonce] \linkdest{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_c$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. From c63bb081a2d2b8ddfdecd34f23f4fa23e577e0ab Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 01:13:18 +1100 Subject: [PATCH 303/460] \usepackage{seqsplit} & \seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba} --- Paper.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7cdff15d..9f5c84be 100644 --- a/Paper.tex +++ b/Paper.tex @@ -29,6 +29,8 @@ % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . +\usepackage{seqsplit} + \input{Version.tex} \newcommand{\hcancel}[1]{% @@ -2497,6 +2499,6 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} At block 2675119, in the transaction -\texttt{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +\seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From 886b206d09078bf18430a1f24c1c76dcdb772bf9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 27 Jan 2018 01:13:51 +1100 Subject: [PATCH 304/460] Remove a line break --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9f5c84be..4956d894 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2498,7 +2498,6 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Dispite Out-of-gas} -At block 2675119, in the transaction -\seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \end{document} From 935c3f2f0a51bd40860ee8f92a744bbbe8f5826d Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Fri, 26 Jan 2018 15:00:25 +0000 Subject: [PATCH 305/460] Change s' to z for the status code. --- Paper.tex | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/Paper.tex b/Paper.tex index 292611dc..7302bf64 100644 --- a/Paper.tex +++ b/Paper.tex @@ -348,9 +348,9 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{z}$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) +R \equiv (R_u, R_b, R_\mathbf{l}, R_{z}) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: @@ -359,9 +359,9 @@ \subsubsection{Transaction Receipt} \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_{s'}$ is an integer. +We assert that the status code $R_{z}$ is an integer. \begin{equation} -R_{s'} \in \mathbb{P} +R_{z} \in \mathbb{P} \end{equation} We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): @@ -619,9 +619,9 @@ \subsection{Execution} \boldsymbol{\sigma}_0[S(T)]_n & \equiv & \boldsymbol{\sigma}[S(T)]_n + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $s'$: +Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} -(\boldsymbol{\sigma}_P, g', A, s') \equiv \begin{cases} +(\boldsymbol{\sigma}_P, g', A, z) \equiv \begin{cases} \Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ \Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} @@ -657,11 +657,11 @@ \subsection{Execution} \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: +And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{z}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ -\Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' +\Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} These are used to help define the transaction receipt, discussed later. @@ -672,7 +672,7 @@ \section{Contract Creation} \label{ch:create} We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}$ to the tuple containing the new state, remaining gas, accrued transaction substate and an error message $(\boldsymbol{\sigma}', g', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: @@ -736,7 +736,7 @@ \section{Contract Creation} \label{ch:create} The gas remaining will be zero in any such exceptional condition, \ie if the creation was conducted as the reception of a transaction, then this doesn't affect payment of the intrinsic cost of contract creation; it is paid regardless. However, the value of the transaction is not transferred to the aborted contract's address when we are out-of-gas. -If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, substate and status code as $(\boldsymbol{\sigma}', g', A, s')$ where: +If such an exception does not occur, then the remaining gas is refunded to the originator and the now-altered state is allowed to persist. Thus formally, we may specify the resultant state, gas, substate and status code as $(\boldsymbol{\sigma}', g', A, z)$ where: \begin{align} \quad g' &\equiv \begin{cases} @@ -750,7 +750,7 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ -\quad s' &\equiv \begin{cases} +\quad z &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ 1 & \text{otherwise} \end{cases} \\ @@ -770,7 +770,7 @@ \section{Message Call} \label{ch:call} Aside from evaluating to a new state and transaction substate, message calls also have an extra component---the output data denoted by the byte array $\mathbf{o}$. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. \begin{equation} -(\boldsymbol{\sigma}', g', A, s', \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) +(\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) \end{equation} Note that we need to differentiate between the value that is to be transferred, $v$, from the value apparent in the execution context, $\tilde{v}$, for the {\small DELEGATECALL} instruction. @@ -818,7 +818,7 @@ \section{Message Call} \label{ch:call} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \ \wedge \ \mathbf{o} = \varnothing \\ g^{**} & \text{otherwise} \end{cases} \\ \nonumber -s' & \equiv & \begin{cases} +z & \equiv & \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\ 1 & \text{otherwise} \end{cases} \\ @@ -1148,7 +1148,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{s'}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{z}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} \boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} @@ -1168,10 +1168,10 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -We define $\mathbf{R}[n]_{s'}$ in a similar manner. +We define $\mathbf{R}[n]_{z}$ in a similar manner. \begin{equation} -\mathbf{R}[n]_{s'} = -\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\mathbf{R}[n]_{z} = +\Upsilon^{z}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From aea9c61b314c6af5af754dec1b57456c560c2673 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Fri, 26 Jan 2018 20:32:57 +0000 Subject: [PATCH 306/460] Add missing introductory text for $\Upsilon^s$. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 292611dc..c4b53770 100644 --- a/Paper.tex +++ b/Paper.tex @@ -566,7 +566,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction and $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items, both to be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^s$ to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: From 62e6377e363d501686b9fe313ab7949c96034d13 Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Mon, 29 Jan 2018 12:11:54 +0000 Subject: [PATCH 307/460] Tidy up change to $ for status code. --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7e0ac956..c6b245bf 100644 --- a/Paper.tex +++ b/Paper.tex @@ -352,9 +352,9 @@ \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{z}$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_{z}) +R \equiv (R_u, R_b, R_\mathbf{l}, R_z) \end{equation} The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: @@ -363,9 +363,9 @@ \subsubsection{Transaction Receipt} \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_{z}$ is an integer. +We assert that the status code $R_z$ is an integer. \begin{equation} -R_{z} \in \mathbb{P} +R_z \in \mathbb{P} \end{equation} We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): @@ -570,7 +570,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^s$ to evaluate to the status code resulting from the transaction. These will be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^z$ to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: @@ -661,7 +661,7 @@ \subsection{Execution} \forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{z}$, the status code of this transaction: +And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ @@ -1152,7 +1152,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{z}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_z$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} \boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} @@ -1172,10 +1172,10 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -We define $\mathbf{R}[n]_{z}$ in a similar manner. +We define $\mathbf{R}[n]_z$ in a similar manner. \begin{equation} -\mathbf{R}[n]_{z} = -\Upsilon^{z}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\mathbf{R}[n]_z = +\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From 984e4dae3321e6cb9d97cfdd884fdde3c30f9559 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:24:24 +1100 Subject: [PATCH 308/460] \label{ch:Terminology} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 753cf2f3..6d14c74c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1253,7 +1253,7 @@ \section{Availability} \appendix -\section{Terminology} +\section{Terminology} \label{ch:Terminology} \begin{description} \item[External Actor] A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum. It can interact with Ethereum through depositing signed Transactions and inspecting the blockchain and associated state. Has one (or more) intrinsic Accounts. From 15409f317e82ca93e08d89a605075bfd8c5da89f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:27:29 +1100 Subject: [PATCH 309/460] \linkdest, underscores --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 41cc281c..8f3da846 100644 --- a/Paper.tex +++ b/Paper.tex @@ -232,7 +232,7 @@ \subsection{World State} \label{ch:state} This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} -\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\hypertarget{account validity function v x}{} +\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\linkdest{account_validity_function_v__x}{} \end{equation} where $v$ is the account validity function: \begin{equation} @@ -252,13 +252,13 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\hypertarget{tx_nonce}{} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\linkdest{tx_nonce}{} \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\hypertarget{tx_gas_price_T__p}{} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\hypertarget{tx_gas_limit_T__g}{} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\hypertarget{tx_to_address_T__t}{} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\hypertarget{tx value T v}{} +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\linkdest{tx_gas_price_T__p}{} +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\linkdest{tx_gas_limit_T__g}{} +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\linkdest{tx_to_address_T__t}{} +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\linkdest{tx_value_T__v}{} \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 8d52fd94a45c6148a020d5f454f503432c04ef43 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:30:24 +1100 Subject: [PATCH 310/460] move linkdest to same line --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8f3da846..60c5d0dd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -232,9 +232,9 @@ \subsection{World State} \label{ch:state} This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} -\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a]))\linkdest{account_validity_function_v__x}{} +\forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} -where $v$ is the account validity function: +\linkdest{account_validity_function_v__x}{}where $v$ is the account validity function: \begin{equation} \quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} \end{equation} @@ -252,14 +252,14 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields:\linkdest{tx_nonce}{} +A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$.\linkdest{tx_gas_price_T__p}{} -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$.\linkdest{tx_gas_limit_T__g}{} -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$.\linkdest{tx_to_address_T__t}{} -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.\linkdest{tx_value_T__v}{} -\item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. +\item[nonce]\linkdest{tx_nonce}{} A scalar value equal to the number of transactions sent by the sender; formally $T_n$. +\item[gasPrice]\linkdest{tx_gas_price_T__p}{} A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. +\item[gasLimit]\linkdest{tx_gas_limit_T__g}{} A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. +\item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.{} +\item[value]\linkdest{tx_value_T__v} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From 6fe3b65fffb6857999f186a0da3f70079fedc4fa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:35:10 +1100 Subject: [PATCH 311/460] hypertarget => linkdest, move to same line --- Paper.tex | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1bb5d7f4..3a339c85 100644 --- a/Paper.tex +++ b/Paper.tex @@ -307,39 +307,39 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding\hypertarget{ommerheaders}{} to the comprised transactions, $\mathbf{T}$, and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information:\hypertarget{parent_Hash_H__p_def_words}{} +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} \begin{description} -\item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$.\hypertarget{beneficiary_H__c}{} -\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. +\item[parentHash]\linkdest{parent_Hash_H__p_def_words}{} The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$. +\item[beneficiary]\linkdest{beneficiary_H__c}{} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$.\hypertarget{receipts_Root_def_words}{} -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$.\hypertarget{logs_Bloom_def_words}{} -\item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$.\hypertarget{block_number_H_i}{} -\item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$.\hypertarget{block_gas_used_H__g}{} -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$.\hypertarget{block_timestamp_H__s}{} -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$.\hypertarget{block_extraData_H__x}{} -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$.\hypertarget{mixHash_H__m}{} -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$.\hypertarget{block_nonce_H__n}{} -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$.\hypertarget{ommer_block_headers_B__U}{}\hypertarget{block_B}{} +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$. +\item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$. +\item[logsBloom]\linkdest{logs_Bloom_def_words}{} The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$. +\item[number]\linkdest{block_number_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$. +\item[gasUsed]\linkdest{block_gas_used_H__g}{} A scalar value equal to the total gas used in transactions in this block; formally $H_g$. +\item[timestamp]\linkdest{block_timestamp_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$. +\item[extraData]\linkdest{block_extraData_H__x}{} An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$. +\item[mixHash]\linkdest{mixHash_H__m}{} A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$. +\item[nonce]\linkdest{block_nonce_H__n}{} A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. \end{description} -The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: +\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\hypertarget{Transaction Receipt}{} +\end{equation}\linkdest{Transaction Receipt}{} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$.\hypertarget{transaction_receipt_R}{}\hypertarget{tx_receipt_gas_used_R__u}{} +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_{s'}$: \begin{equation} R \equiv (R_u, R_b, R_\mathbf{l}, R_{s'}) \end{equation} From ba99a2af41d38fbbcf0bbb834f376d6579086b63 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:39:29 +1100 Subject: [PATCH 312/460] hypertarget => linkdest, move to same line --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index de7a75a0..7547d96e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -389,12 +389,12 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} -\begin{array}[t]{lclc}\hypertarget{block_validity_H__r}{} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \hypertarget{Ommer_block_hash_H__o}{}\\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \hypertarget{tx_block_hash_H__t}{}\\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \hypertarget{Receipts_Root_H__e}{}\\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \hypertarget{logs_Bloom_filter_H__b}{}\\ -H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) +\begin{array}[t]{lclc} +\linkdest{block_validity_H__r}{}H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +\linkdest{Ommer_block_hash_H__o}{}H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ +\linkdest{tx_block_hash_H__t}{}H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ +\linkdest{Receipts_Root_H__e}{}H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ +\linkdest{logs_Bloom_filter_H__b}{}H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) \end{array} \end{equation} From 3270a9066c78c32149fe75eee0a66117c4625552 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:41:18 +1100 Subject: [PATCH 313/460] hypertarget: move to same line --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 18310923..7fb67b8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -417,9 +417,9 @@ \subsubsection{Serialisation} \begin{eqnarray} \quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ \quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) -\end{eqnarray}\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{} +\end{eqnarray} -With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: +\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} @@ -457,9 +457,9 @@ \subsubsection{Block Header Validity} \newcommand{\mindifficulty}{D_0} \newcommand{\homesteadmod}{\ensuremath{\varsigma_2}} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} -\newcommand{\diffadjustment}{x}\hypertarget{block_difficulty_H__d}{} +\newcommand{\diffadjustment}{x} -The canonical difficulty of a block of header $H$ is defined as $D(H)$: +\hypertarget{block_difficulty_H__d}{}The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_i = 0\\ @@ -485,9 +485,9 @@ \subsubsection{Block Header Validity} \begin{align} \expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ H'_i &\equiv \max(H_i - 3000000, 0) -\end{align}\hypertarget{block_gas_limit_H__l}{} +\end{align} -The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: +\hypertarget{block_gas_limit_H__l}{}The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} & & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ & & H_l > {P(H)_H}_l - \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ From 31a86388ce55994935aeeb2eddf9bed7588203aa Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:51:15 +1100 Subject: [PATCH 314/460] hypertarget: move to the same line as targeted text, change to linkdest where not in text mode --- Paper.tex | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index a1d36483..723dff4a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -643,22 +643,21 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} -\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \hypertarget{self_destruct_list_A__s}{}\\ -\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \hypertarget{touched_A__t}{}\\ -\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) +\boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ +\linkdest{self_destruct_list_A__s}{}\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\linkdest{touched_A__t}{}\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{} -And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{}And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{s}$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ \Upsilon^s(\boldsymbol{\sigma}, T) & \equiv & s' \end{eqnarray} -These are used to help define the transaction receipt, discussed later.\hypertarget{endow}{} +These are used to help define the transaction receipt, discussed later. -\section{Contract Creation} \label{ch:create} +\section{Contract Creation}\label{ch:create}\hypertarget{endow}{} There are a number of intrinsic parameters used when creating an account: sender ($s$), original transactor ($o$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code and finally the present depth of the message-call/contract-creation stack ($e$). From 8b795654bcb9c386b390f6c47def07945be94dbd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:52:46 +1100 Subject: [PATCH 315/460] hypertarget: move to the same line as targeted text, change to linkdest where not in text mode --- Paper.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Paper.tex b/Paper.tex index 55f8d2d6..c390c9f8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -506,13 +506,13 @@ \subsubsection{Block Header Validity} \begin{equation} n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$.\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{} +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. -Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. +\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. -This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.\hypertarget{block_header_validity_function}{} +This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. -Thus we are able to define the block header validity function $V(H)$: +\hypertarget{block_header_validity_function}{}Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} V(H) & \equiv & n \leqslant \frac{2^{256}}{H_d} \wedge m = H_m \quad \wedge \\ & & H_d = D(H) \quad \wedge \\ @@ -561,17 +561,17 @@ \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) -\end{equation}\hypertarget{self_destruct_set_wordy_defn}{} +\end{equation} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the\hypertarget{tx_log_series_wordy_defn}{} transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as\hypertarget{tx_touched_accounts_wordy_defn}{} decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end\hypertarget{refund_balance_defn_words}{} of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} A^0 \equiv (\varnothing, (), \varnothing, 0) \end{equation} -\subsection{Execution}\hypertarget{intrinsic_gas_g_0}{} -We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: +\subsection{Execution} +\hypertarget{intrinsic_gas_g_0}{}We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ {} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_t = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ @@ -591,8 +591,8 @@ \subsection{Execution}\hypertarget{intrinsic_gas_g_0}{} \begin{equation} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ -\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \hypertarget{transaction_nonce}{}\\ -T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ +\boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \\ +\linkdest{transaction_nonce}{}T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ g_0 & \leqslant & T_g \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ T_g & \leqslant & {B_H}_l - \ell(B_\mathbf{R})_u From b9dab3a9e2504b8883de4d964e7256741a4d4f0e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:56:17 +1100 Subject: [PATCH 316/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index ee46e867..94aef879 100644 --- a/Paper.tex +++ b/Paper.tex @@ -868,17 +868,17 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: -\begin{itemize}\hypertarget{address_of_account_which_owns_code_I__a_def_words}{} -\item $I_a$, the address of the account which owns the code that is executing.\hypertarget{address_of_sender_of_tx_that_originated_execution_I__o}{} -\item $I_o$, the sender address of the transaction that originated this execution.\hypertarget{gas_price_in_tx_that_originated_execution_I__p}{} -\item $I_p$, the price of gas in the transaction that originated this execution.\hypertarget{execution_input_data_I__d}{} -\item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.\hypertarget{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.\hypertarget{Wei_value_exec}{} -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.\hypertarget{exec_machine_code_I__b}{} -\item $I_\mathbf{b}$, the byte array that is the machine code to be executed.\hypertarget{exec_block_header_I__H}{} -\item $I_H$, the block header of the present block.\hypertarget{exec_call_or_create_depth_I__e}{} -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present).\hypertarget{exec_permission_to_modify_state_I__w}{} -\item $I_w$, the permission to make modifications to the state. +\begin{itemize} +\item\linkdest{address_of_account_which_owns_code_I__a_def_words}{} $I_a$, the address of the account which owns the code that is executing. +\item\linkdest{address_of_sender_of_tx_that_originated_execution_I__o}{} $I_o$, the sender address of the transaction that originated this execution. +\item\linkdest{gas_price_in_tx_that_originated_execution_I__p}{} $I_p$, the price of gas in the transaction that originated this execution. +\item\linkdest{execution_input_data_I__d}{} $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. +\item\linkdest{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. +\item\linkdest{Wei_value_exec}{} $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. +\item\linkdest{exec_machine_code_I__b}{} $I_\mathbf{b}$, the byte array that is the machine code to be executed. +\item\linkdest{exec_block_header_I__H}{} $I_H$, the block header of the present block. +\item\linkdest{exec_call_or_create_depth_I__e}{} $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item\linkdest{exec_permission_to_modify_state_I__w}{} $I_w$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: From f7b6cef0cee9e71e0d06d1282e3c4a5ea87e7fea Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 10:59:30 +1100 Subject: [PATCH 317/460] Move \hypertarget{normal_halting_function_H}{} move to the same line as the targeted text --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 06b44484..804b1e00 100644 --- a/Paper.tex +++ b/Paper.tex @@ -993,9 +993,9 @@ \subsubsection{Jump Destination Validity} N(i, w) \equiv \begin{cases} i + w - \text{\small PUSH1} + 2 & \text{if} \quad w \in [\text{\small PUSH1}, \text{\small PUSH32}] \\ i + 1 & \text{otherwise} \end{cases} -\end{equation}\hypertarget{normal_halting_function_H}{} +\end{equation} -\subsubsection{Normal Halting} +\subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} The normal halting function $H$ is defined: \begin{equation} From 1b64c15a5e64fe8f2a564e0971593e1161956d60 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:01:08 +1100 Subject: [PATCH 318/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3dbeb89a..8fe68913 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2081,13 +2081,13 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} -\end{cases}$ \hypertarget{JUMP}{JUMP} \\ +\end{cases}$ \\ \midrule -0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ +\linkdest{JUMP}{JUMP}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ -&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \hypertarget{JUMPI}{JUMPI}\\ +&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. {JUMPI}\\ \midrule -0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ +\linkdest{JUMPI}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ \midrule From 0539df71678f4dc3eb0b4da84259fe37f6436d86 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:02:23 +1100 Subject: [PATCH 319/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1d28711a..1d4bf056 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1107,16 +1107,16 @@ \subsection{Reward Application} R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b \end{eqnarray} -If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively.\hypertarget{block-reward-R-b}{block-reward-R-b} +If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -We define the block reward as 3 Ether: +\hypertarget{block-reward-R-b}{block-reward-R-b}We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_b = 3 \times 10^{18} \end{equation} -\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarget{Gamma}{Gamma} +\subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} -We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: +\hypertarget{Gamma}{Gamma}We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_H) = \varnothing \\ @@ -1124,9 +1124,9 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarg \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure.\hypertarget{Phi}{Phi} +Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. -And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: +\hypertarget{Phi}{Phi}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ B'_n & = & n: \quad x \leqslant \frac{2^{256}}{H_d} \\ @@ -1160,10 +1160,10 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation}\hypertarg We define $\mathbf{R}[n]_{s'}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{s'} = -\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\hypertarget{Pi}{Pi} +\Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: +\hypertarget{Pi}{Pi}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: \begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} From 2421e9234789ab5895d96ea03e00bcb11a8f9d1f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:03:58 +1100 Subject: [PATCH 320/460] Remove {JUMPI} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8fe68913..d5dc4aa0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2085,7 +2085,7 @@ \subsection{Instruction Set} \midrule \linkdest{JUMP}{JUMP}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ -&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. {JUMPI}\\ +&&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}.\\ \midrule \linkdest{JUMPI}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ From 165242a13a1fdb58d307f27fd6ce21da4685ca18 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:05:18 +1100 Subject: [PATCH 321/460] hypertarget: move to the same line as the targeted text --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e87c80b5..1dae9130 100644 --- a/Paper.tex +++ b/Paper.tex @@ -892,9 +892,9 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine.\hypertarget{empty_sequence_vs_empty_set}{} +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. -The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. +\hypertarget{empty_sequence_vs_empty_set}{}The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} \Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ (\boldsymbol{\sigma}', \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ From 83731d028a78aff2eba86a0e5f42190d27e41de1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:08:12 +1100 Subject: [PATCH 322/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 8ee3bb68..7363963d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1639,8 +1639,8 @@ \section{Signing Transactions}\label{app:signing} We assert the functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. \begin{eqnarray} -\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \hypertarget{ECDSASIGN}{}\\ -\mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_r \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ +\mathtt{\small ECDSAPUBKEY}(p_r \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \\ +\linkdest{ECDSASIGN}{}\mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_r \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ \mathtt{\small ECDSARECOVER}(e \in \mathbb{B}_{32}, v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) & \equiv & p_u \in \mathbb{B}_{64} \end{eqnarray} From dc6a5b40de7eb2e7d1dbc3b3074f6d8f38332004 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:13:55 +1100 Subject: [PATCH 323/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index 876fc823..85f92d44 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1719,22 +1719,22 @@ \section{Fee Schedule}\label{app:fees} $G_{jumpdest}$ & 1 & Paid for a {\small JUMPDEST} operation. \\ $G_{sset}$ & 20000 & Paid for an {\small SSTORE} operation when the storage value is set to non-zero from zero. \\ $G_{sreset}$ & 5000 & Paid for an {\small SSTORE} operation when the storage value's zeroness remains unchanged or is set to zero. \\ -$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \hypertarget{Rselfdestruct}{}\\ -$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \hypertarget{Gselfdestruct}{}\\ -$G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ +$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. +\linkdest{R__selfdestruct}{}\\$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ +\linkdest{G__selfdestruct}{}$G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ $G_{create}$ & 32000 & Paid for a {\small CREATE} operation. \\ -$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \hypertarget{codedeposit}{}\\ +\linkdest{G__codedeposit}{}$G_{codedeposit}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \\ $G_{call}$ & 700 & Paid for a {\small CALL} operation. \\ $G_{callvalue}$ & 9000 & Paid for a non-zero value transfer as part of the {\small CALL} operation. \\ -$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \hypertarget{Gnewaccount}{}\\ -$G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\ +$G_{callstipend}$ & 2300 & A stipend for the called contract subtracted from $G_{callvalue}$ for a non-zero value transfer. \\ +\linkdest{G__newaccount}{}$G_{newaccount}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\ $G_{exp}$ & 10 & Partial payment for an {\small EXP} operation. \\ $G_{expbyte}$ & 50 & Partial payment when multiplied by $\lceil\log_{256}(exponent)\rceil$ for the {\small EXP} operation. \\ -$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \hypertarget{Gtxcreate}{}\\ -$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\hypertarget{Gtxdatazero}{}\\ -$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \hypertarget{Gtxdatanonzero}{}\\ -$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \hypertarget{Gtransaction}{}\\ -$G_{transaction}$ & 21000 & Paid for every transaction. \\ +$G_{memory}$ & 3 & Paid for every additional word when expanding memory. \\ +\linkdest{G__txcreate}{}$G_\text{txcreate}$ & 32000 & Paid by all contract-creating transactions after the {\textit{Homestead} transition}.\\ +\linkdest{G__txdatazero}{}$G_{txdatazero}$ & 4 & Paid for every zero byte of data or code for a transaction. \\ +\linkdest{G__txdatanonzero}{}$G_{txdatanonzero}$ & 68 & Paid for every non-zero byte of data or code for a transaction. \\ +\linkdest{G__transaction}{}$G_{transaction}$ & 21000 & Paid for every transaction. \\ $G_{log}$ & 375 & Partial payment for a {\small LOG} operation. \\ $G_{logdata}$ & 8 & Paid for each byte in a {\small LOG} operation's data. \\ $G_{logtopic}$ & 375 & Paid for each topic of a {\small LOG} operation. \\ From 47bdb284c42b4ffb7c5214551bad2a311c0f2391 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:14:32 +1100 Subject: [PATCH 324/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index db8eef10..32bda831 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1848,8 +1848,8 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{0s: Stop and Arithmetic Operations}} \\ \multicolumn{5}{l}{All arithmetic is modulo $2^{256}$ unless otherwise noted. The zero-th power of zero $0^0$ is defined to be one.} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{stop}{}\\ -0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\linkdest{stop}{}0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule 0x01 & {\small ADD} & 2 & 1 & Addition operation. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1]$ \\ From cd23eb1676c549abce2659a97caa7660b6493643 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:17:05 +1100 Subject: [PATCH 325/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Paper.tex b/Paper.tex index 32bda831..8e787a75 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2018,8 +2018,8 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ -\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \hypertarget{blockhash}{BLOCKHASH}\\ -0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ +\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ +\linkdest{blockhash}{BLOCKHASH}0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ @@ -2067,15 +2067,15 @@ \subsection{Instruction Set} &&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \hypertarget{SSTORE}{}\\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ \midrule -0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \hypertarget{C tiny SSTORE}{}\\ -&&&& $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +\linkdest{SSTORE}{}0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ +&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&&\linkdest{C tiny SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} -\end{cases}$ \hypertarget{A r}{}\\ -&&&& $A'_{r} \equiv A_{r} + \begin{cases} +\end{cases}$ \\ +&&&& \linkdest{A r}{}$A'_{r} \equiv A_{r} + \begin{cases} R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ @@ -2169,8 +2169,8 @@ \subsection{Instruction Set} \begin{tabular*}{\columnwidth}[h]{rlrrl} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ -\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\hypertarget{A l}{}\\ -\multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ +\multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ +\multicolumn{5}{l}\linkdest{A l}{}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ \multicolumn{5}{l}{$\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ \multicolumn{5}{l}{The entry's topic series, $\mathbf{t}$, differs accordingly:}\vspace{5pt} \\ @@ -2223,8 +2223,8 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ -&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \hypertarget{tiny CALL}{}\\ -&&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ +&&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ +&&&&\linkdest{tiny CALL}{} $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} @@ -2248,9 +2248,9 @@ \subsection{Instruction Set} &&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ -&&&& same account as at present, simply that the code is overwritten.\hypertarget{RETURN}{}\\ +&&&& same account as at present, simply that the code is overwritten.\\ \midrule -0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ +\linkdest{RETURN}{}0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ &&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ &&&& This has the effect of halting the execution at this point with output defined.\\ &&&& See section \ref{ch:model}. \\ @@ -2283,9 +2283,9 @@ \subsection{Instruction Set} &&&& For the gas calculation, we use the memory expansion function, \\ &&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule -0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \hypertarget{selfdestruct}{}\\ +0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule -0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ +\linkdest{selfdestruct}{}0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ &&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ &&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_a]_b = 0\\ @@ -2297,8 +2297,8 @@ \subsection{Instruction Set} &&&& $A'_{r} \equiv A_{r} + \begin{cases} R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ 0 & \text{otherwise} -\end{cases}$ \hypertarget{C tiny SELFDESTRUCT}{}\\ -&&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} +\end{cases}$ \\ +&&&&\linkdest{C tiny SELFDESTRUCT}{} $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ From 1ef52f26b181f8e67a7d9792eadb47f1bfa3bf51 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:18:16 +1100 Subject: [PATCH 326/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode Jwordbytes --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4842bc4c..6a53cc66 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2326,9 +2326,9 @@ \subsection{Definitions} \begin{tabular*}{\columnwidth}[h]{lrl} \toprule -Name & Value & Description \hypertarget{Jwordbytes}{}\\ +Name & Value & Description \\ \midrule -$J_{wordbytes}$ & 4 & Bytes in word. \\ +\linkdest{Jwordbytes}{}$J_{wordbytes}$ & 4 & Bytes in word. \\ $J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ $J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \\ $J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \\ From 3d884fc6e262a1caedbf2326c057b46902e66d76 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:29:49 +1100 Subject: [PATCH 327/460] Find and replace all _([:alpha:][:alnum:]*) with _{\mathrm{$1}} --- Paper.tex | 740 +++++++++++++++++++++++++++--------------------------- 1 file changed, 370 insertions(+), 370 deletions(-) diff --git a/Paper.tex b/Paper.tex index c6b245bf..fa51a9f0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -28,7 +28,7 @@ \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . -% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. +% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_{\mathrm{and}}_{\mathrm{Hypertarget}}. \makeatletter \newcommand{\linkdest}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} @@ -116,7 +116,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_t, T) +\linkdest{Upsilon_{\mathrm{state}}_{\mathrm{transition}}}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -127,7 +127,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Formally, we expand to: \begin{eqnarray} -\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_t, B) \\ +\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{\mathrm{t}}, B) \\ B & \equiv & (..., (T_0, T_1, ...) ) \\ \Pi(\boldsymbol{\sigma}, B) & \equiv & \Omega(B, \Upsilon(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \end{eqnarray} @@ -176,7 +176,7 @@ \section{Conventions}\label{ch:conventions} For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. -Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_n$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. +Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a transaction nonce. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. @@ -209,20 +209,20 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: \begin{description} -\item[nonce] \linkdest{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_n$. -\item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_b$. -\item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. -\item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_c$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. +\item[nonce] \linkdest{account_{\mathrm{nonce}}}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{n}}$. +\item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{b}}$. +\item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{s}}$. +\item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{c}}$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_{\mathrm{c}}$. \end{description} Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: \begin{equation} -\texttt{\small TRIE}\big(L_I^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_s +\texttt{\small TRIE}\big(L_{\mathrm{I}}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} -The collapse function for the set of key/value pairs in the trie, $L_I^*$, is defined as the element-wise transformation of the base function $L_I$, given as: +The collapse function for the set of key/value pairs in the trie, $L_{\mathrm{I}}^*$, is defined as the element-wise transformation of the base function $L_{\mathrm{I}}$, given as: \begin{equation} -L_I\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) +L_{\mathrm{I}}\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) \end{equation} where: @@ -232,29 +232,29 @@ \subsection{World State} \label{ch:state} It shall be understood that $\boldsymbol{\sigma}[a]_\mathbf{s}$ is not a `physical' member of the account and does not contribute to its later serialisation. -If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. +If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. -Thus we may define a world-state collapse function $L_S$: +Thus we may define a world-state collapse function $L_{\mathrm{S}}$: \begin{equation} -L_S(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} +L_{\mathrm{S}}(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} \end{equation} where \begin{equation} -p(a) \equiv \big(\texttt{\small KEC}(a), \texttt{\small RLP}\big( (\boldsymbol{\sigma}[a]_n, \boldsymbol{\sigma}[a]_b, \boldsymbol{\sigma}[a]_s, \boldsymbol{\sigma}[a]_c) \big) \big) +p(a) \equiv \big(\texttt{\small KEC}(a), \texttt{\small RLP}\big( (\boldsymbol{\sigma}[a]_{\mathrm{n}}, \boldsymbol{\sigma}[a]_{\mathrm{b}}, \boldsymbol{\sigma}[a]_{\mathrm{s}}, \boldsymbol{\sigma}[a]_{\mathrm{c}}) \big) \big) \end{equation} -This function, $L_S$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: +This function, $L_{\mathrm{S}}$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} where $v$ is the account validity function: \begin{equation} -\quad v(x) \equiv x_n \in \mathbb{P}_{256} \wedge x_b \in \mathbb{P}_{256} \wedge x_s \in \mathbb{B}_{32} \wedge x_c \in \mathbb{B}_{32} +\quad v(x) \equiv x_{\mathrm{n}} \in \mathbb{P}_{256} \wedge x_{\mathrm{b}} \in \mathbb{P}_{256} \wedge x_{\mathrm{s}} \in \mathbb{B}_{32} \wedge x_{\mathrm{c}} \in \mathbb{B}_{32} \end{equation} An account is \textit{empty} when it has no code, zero nonce and zero balance: \begin{equation} -\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_c = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_n = 0 \wedge \boldsymbol{\sigma}[a]_b = 0 +\mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big) \wedge \boldsymbol{\sigma}[a]_{\mathrm{n}} = 0 \wedge \boldsymbol{\sigma}[a]_{\mathrm{b}} = 0 \end{equation} Even callable precompiled contracts can have an empty account state. This is because their account states do not usually contain the code describing its behavior. @@ -268,12 +268,12 @@ \subsection{The Transaction} \label{ch:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_n$. -\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. -\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. -\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$. -\item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. -\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. +\item[nonce] A scalar value equal to the number of transactions sent by the sender; formally $T_{\mathrm{n}}$. +\item[gasPrice] A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_{\mathrm{p}}$. +\item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. +\item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. +\item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. +\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$. This is expanded in Appendix \ref{app:signing}. \end{description} Additionally, a contract creation transaction contains: @@ -293,28 +293,28 @@ \subsection{The Transaction} \label{ch:transaction} Appendix \ref{app:signing} specifies the function, $S$, which maps transactions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction $T$ can be represented with $S(T)$. \begin{equation} -L_T(T) \equiv \begin{cases} -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{i}, T_w, T_r, T_s) & \text{if} \; T_t = \varnothing\\ -(T_n, T_p, T_g, T_t, T_v, T_\mathbf{d}, T_w, T_r, T_s) & \text{otherwise} +L_{\mathrm{T}}(T) \equiv \begin{cases} +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{i}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{d}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} \end{equation} Here, we assume all components are interpreted by the RLP as integer values, with the exception of the arbitrary length byte arrays $T_\mathbf{i}$ and $T_\mathbf{d}$. \begin{equation} \begin{array}[t]{lclclc} -T_n \in \mathbb{P}_{256} & \wedge & T_v \in \mathbb{P}_{256} & \wedge & T_p \in \mathbb{P}_{256} & \wedge \\ -T_g \in \mathbb{P}_{256} & \wedge & T_w \in \mathbb{P}_5 & \wedge & T_r \in \mathbb{P}_{256} & \wedge \\ -T_s \in \mathbb{P}_{256} & \wedge & T_\mathbf{d} \in \mathbb{B} & \wedge & T_\mathbf{i} \in \mathbb{B} +T_{\mathrm{n}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{v}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{p}} \in \mathbb{P}_{256} & \wedge \\ +T_{\mathrm{g}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{w}} \in \mathbb{P}_5 & \wedge & T_{\mathrm{r}} \in \mathbb{P}_{256} & \wedge \\ +T_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge & T_\mathbf{d} \in \mathbb{B} & \wedge & T_\mathbf{i} \in \mathbb{B} \end{array} \end{equation} where \begin{equation} -\mathbb{P}_n = \{ P: P \in \mathbb{P} \wedge P < 2^n \} +\mathbb{P}_{\mathrm{n}} = \{ P: P \in \mathbb{P} \wedge P < 2^n \} \end{equation} The address hash $T_\mathbf{t}$ is slightly different: it is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to $\varnothing$), it is the RLP empty byte sequence and thus the member of $\mathbb{B}_0$: \begin{equation} -T_\mathbf{t} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_t \neq \varnothing \\ +T_\mathbf{t} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} @@ -325,67 +325,67 @@ \subsection{The Block} \label{ch:block} %\textit{TODO: Introduce logs} \begin{description} -\item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_p$. -\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_o$. -\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_c$. -\item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_r$. -\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_t$. -\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_e$. -\item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_b$. -\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_d$. -\item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_i$. -\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_l$. -\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_g$. -\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_s$. -\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_x$. -\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_m$. -\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_n$. +\item[parentHash] The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_{\mathrm{p}}$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. +\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. +\item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_{\mathrm{r}}$. +\item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_{\mathrm{t}}$. +\item[receiptsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. +\item[logsBloom] The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_{\mathrm{b}}$. +\item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_{\mathrm{d}}$. +\item[number] A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_{\mathrm{i}}$. +\item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_{\mathrm{l}}$. +\item[gasUsed] A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. +\item[timestamp] A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_{\mathrm{s}}$. +\item[extraData] An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_{\mathrm{x}}$. +\item[mixHash] A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{m}}$. +\item[nonce] A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{n}}$. \end{description} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{\mathrm{H}}, B_\mathbf{T}, B_\mathbf{U}) \end{equation} \subsubsection{Transaction Receipt} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. -The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: +The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} -R \equiv (R_u, R_b, R_\mathbf{l}, R_z) +R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) \end{equation} -The function $L_R$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: +The function $L_{\mathrm{R}}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_R(R) \equiv (0 \in \mathbb{B}_{256}, R_u, R_b, R_\mathbf{l}) +L_{\mathrm{R}}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. -We assert that the status code $R_z$ is an integer. +We assert that the status code $R_{\mathrm{z}}$ is an integer. \begin{equation} -R_z \in \mathbb{P} +R_{\mathrm{z}} \in \mathbb{P} \end{equation} -We assert $R_u$, the cumulative gas used is a positive integer and that the logs Bloom, $R_b$, is a hash of size 2048 bits (256 bytes): +We assert $R_{\mathrm{u}}$, the cumulative gas used is a positive integer and that the logs Bloom, $R_{\mathrm{b}}$, is a hash of size 2048 bits (256 bytes): \begin{equation} -R_u \in \mathbb{P} \quad \wedge \quad R_b \in \mathbb{B}_{256} +R_{\mathrm{u}} \in \mathbb{P} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \end{equation} -%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_B$; it is merely a convenience equivalence. +%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{\mathrm{B}}$; it is merely a convenience equivalence. -The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_a$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_{\mathrm{a}}$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} -O \equiv (O_a, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) +O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} \begin{equation} -O_a \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_\mathbf{t}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_\mathbf{d} \in \mathbb{B} +O_{\mathrm{a}} \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_\mathbf{t}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_\mathbf{d} \in \mathbb{B} \end{equation} We define the Bloom filter function, $M$, to reduce a log entry into a single 256-byte hash: \begin{equation} -M(O) \equiv \bigvee_{t \in \{O_a\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) +M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) \end{equation} where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence./footnote{11 bits $= 2^2048$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: @@ -396,18 +396,18 @@ \subsubsection{Transaction Receipt} m(\mathbf{x}, i) &\equiv& \mathtt{\tiny KEC}(\mathbf{x})[i, i + 1] \bmod 2048 \end{eqnarray} -where $\mathcal{B}$ is the bit reference function such that $\mathcal{B}_j(\mathbf{x})$ equals the bit of index $j$ (indexed from 0) in the byte array $\mathbf{x}$. +where $\mathcal{B}$ is the bit reference function such that $\mathcal{B}_{\mathrm{j}}(\mathbf{x})$ equals the bit of index $j$ (indexed from 0) in the byte array $\mathbf{x}$. \subsubsection{Holistic Validity} -We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: +We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: \begin{equation} \begin{array}[t]{lclc} -H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ -H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ -H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ -H_b &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_b \big) +H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_{\mathrm{S}}(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}^*(B_\mathbf{U}))) & \wedge \\ +H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{T}}(B_\mathbf{T}[i]))\}) & \wedge \\ +H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{R}}(B_\mathbf{R}[i]))\}) & \wedge \\ +H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} @@ -418,22 +418,22 @@ \subsubsection{Holistic Validity} Furthermore: \begin{equation} -\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma})) = {P(B_H)_H}_r +\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} \end{equation} -Thus $\texttt{\small TRIE}(L_S(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_H)$ is the parent block of $B$, defined directly. +Thus $\texttt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{\mathrm{H}})$ is the parent block of $B$, defined directly. The values stemming from the computation of transactions, specifically the transaction receipts, $B_\mathbf{R}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} -The function $L_B$ and $L_H$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_R$, we assert the types and order of the structure for when the RLP transformation is required: +The function $L_{\mathrm{B}}$ and $L_{\mathrm{H}}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{\mathrm{R}}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} -\quad L_H(H) & \equiv & (\begin{array}[t]{l}H_p, H_o, H_c, H_r, H_t, H_e, H_b, H_d,\\ H_i, H_l, H_g, H_s, H_x, H_m, H_n \; )\end{array} \\ -\quad L_B(B) & \equiv & \big( L_H(B_H), L_T^*(B_\mathbf{T}), L_H^*(B_\mathbf{U}) \big) +\quad L_{\mathrm{H}}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ +\quad L_{\mathrm{B}}(B) & \equiv & \big( L_{\mathrm{H}}(B_{\mathrm{H}}), L_{\mathrm{T}}^*(B_\mathbf{T}), L_{\mathrm{H}}^*(B_\mathbf{U}) \big) \end{eqnarray} -With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: +With $L_{\mathrm{T}}^*$ and $L_{\mathrm{H}}^*$ being element-wise sequence transformations, thus: \begin{equation} f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} @@ -441,31 +441,31 @@ \subsubsection{Serialisation} The component types are defined thus: \begin{equation} \begin{array}[t]{lclclcl} -H_p \in \mathbb{B}_{32} & \wedge & H_o \in \mathbb{B}_{32} & \wedge & H_c \in \mathbb{B}_{20} & \wedge \\ -H_r \in \mathbb{B}_{32} & \wedge & H_t \in \mathbb{B}_{32} & \wedge & H_e \in \mathbb{B}_{32} & \wedge \\ -H_b \in \mathbb{B}_{256} & \wedge & H_d \in \mathbb{P} & \wedge & H_i \in \mathbb{P} & \wedge \\ -H_l \in \mathbb{P} & \wedge & H_g \in \mathbb{P} & \wedge & H_s \in \mathbb{P}_{256} & \wedge \\ -H_x \in \mathbb{B} & \wedge & H_m \in \mathbb{B}_{32} & \wedge & H_n \in \mathbb{B}_{8} +H_{\mathrm{p}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ +H_{\mathrm{r}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{e}} \in \mathbb{B}_{32} & \wedge \\ +H_{\mathrm{b}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{P} & \wedge & H_{\mathrm{i}} \in \mathbb{P} & \wedge \\ +H_{\mathrm{l}} \in \mathbb{P} & \wedge & H_{\mathrm{g}} \in \mathbb{P} & \wedge & H_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge \\ +H_{\mathrm{x}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{n}} \in \mathbb{B}_{8} \end{array} \end{equation} where \begin{equation} -\mathbb{B}_n = \{ B: B \in \mathbb{B} \wedge \lVert B \rVert = n \} +\mathbb{B}_{\mathrm{n}} = \{ B: B \in \mathbb{B} \wedge \lVert B \rVert = n \} \end{equation} We now have a rigorous specification for the construction of a formal block structure. The RLP function $\texttt{\small RLP}$ (see Appendix \ref{app:rlp}) provides the canonical method for transforming this structure into a sequence of bytes ready for transmission over the wire or storage locally. \subsubsection{Block Header Validity} -We define $P(B_H)$ to be the parent block of $B$, formally: +We define $P(B_{\mathrm{H}})$ to be the parent block of $B$, formally: \begin{equation} -P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_H)) = H_p +P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{\mathrm{H}})) = H_{\mathrm{p}} \end{equation} The block number is the parent's block number incremented by one: \begin{equation} -H_i \equiv {{P(H)_H}_i} + 1 +H_{\mathrm{i}} \equiv {{P(H)_{\mathrm{H}}}_{\mathrm{i}}} + 1 \end{equation} \newcommand{\mindifficulty}{D_0} @@ -476,8 +476,8 @@ \subsubsection{Block Header Validity} The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} D(H) \equiv \begin{dcases} -\mindifficulty & \text{if} \quad H_i = 0\\ -\text{max}\!\left(\mindifficulty, {P(H)_H}_d + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ +\mindifficulty & \text{if} \quad H_{\mathrm{i}} = 0\\ +\text{max}\!\left(\mindifficulty, {P(H)_{\mathrm{H}}}_{\mathrm{d}} + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ \end{dcases} \end{equation} where: @@ -485,10 +485,10 @@ \subsubsection{Block Header Validity} \mindifficulty \equiv 131072 \end{equation} \begin{equation} -\diffadjustment \equiv \left\lfloor\frac{{P(H)_H}_d}{2048}\right\rfloor +\diffadjustment \equiv \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{d}}}{2048}\right\rfloor \end{equation} \begin{equation} -\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_s - {P(H)_H}_s}{9}\right\rfloor, -99 \right) +\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{\mathrm{H}}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) \end{equation} \begin{equation*} x \equiv \begin{cases} @@ -497,49 +497,49 @@ \subsubsection{Block Header Validity} \end{cases} \end{equation*} \begin{align} -\expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_i \div 100000 \right\rfloor - 2 } \right\rfloor \\ -H'_i &\equiv \max(H_i - 3000000, 0) +\expdiffsymb &\equiv \left\lfloor 2^{ \left\lfloor H'_{\mathrm{i}} \div 100000 \right\rfloor - 2 } \right\rfloor \\ +H'_{\mathrm{i}} &\equiv \max(H_{\mathrm{i}} - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_{\mathrm{i}}$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. -The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: +The canonical gas limit $H_{\mathrm{l}}$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} -& & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l > {P(H)_H}_l - \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l \geqslant 5000 +& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} \geqslant 5000 \end{eqnarray} -$H_s$ is the timestamp of block $H$ and must fulfil the relation: +$H_{\mathrm{s}}$ is the timestamp of block $H$ and must fulfil the relation: \begin{equation} -H_s > {P(H)_H}_s +H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} \end{equation} This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. -The nonce, $H_n$, must satisfy the relations: +The nonce, $H_{\mathrm{n}}$, must satisfy the relations: \begin{equation} -n \leqslant \frac{2^{256}}{H_d} \quad \wedge \quad m = H_m +n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \wedge \quad m = H_{\mathrm{m}} \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$. +with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. -Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_d$. +Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. Thus we are able to define the block header validity function $V(H)$: \begin{eqnarray} -V(H) & \equiv & n \leqslant \frac{2^{256}}{H_d} \wedge m = H_m \quad \wedge \\ -& & H_d = D(H) \quad \wedge \\ -& & H_g \le H_l \quad \wedge \\ -& & H_l < {P(H)_H}_l + \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l > {P(H)_H}_l - \left\lfloor\frac{{P(H)_H}_l}{1024}\right\rfloor \quad \wedge \\ -& & H_l \geqslant 5000 \quad \wedge \\ -& & H_s > {P(H)_H}_s \quad \wedge \\ -& & H_i = {P(H)_H}_i +1 \quad \wedge \\ -& & \lVert H_x \rVert \le 32 +V(H) & \equiv & n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \wedge m = H_{\mathrm{m}} \quad \wedge \\ +& & H_{\mathrm{d}} = D(H) \quad \wedge \\ +& & H_{\mathrm{g}} \le H_{\mathrm{l}} \quad \wedge \\ +& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} \geqslant 5000 \quad \wedge \\ +& & H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} \quad \wedge \\ +& & H_{\mathrm{i}} = {P(H)_{\mathrm{H}}}_{\mathrm{i}} +1 \quad \wedge \\ +& & \lVert H_{\mathrm{x}} \rVert \le 32 \end{eqnarray} -where $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d})$ +where $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$ Noting additionally that \textbf{extraData} must be at most 32 bytes. @@ -575,10 +575,10 @@ \section{Transaction Execution} \label{ch:transactions} \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} -A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_r) +A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_{\mathrm{r}}) \end{equation} -The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_r$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion. $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends). $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction. Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} @@ -589,7 +589,7 @@ \subsection{Execution} We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ -{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_t = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ +{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ {} & + G_{transaction} \end{align} @@ -597,7 +597,7 @@ \subsection{Execution} The up-front cost $v_0$ is calculated as: \begin{equation} -v_0 \equiv T_g T_p + T_v +v_0 \equiv T_{\mathrm{g}} T_{\mathrm{p}} + T_{\mathrm{v}} \end{equation} The validity is determined as: @@ -605,53 +605,53 @@ \subsection{Execution} \begin{array}[t]{rcl} S(T) & \neq & \varnothing \quad \wedge \\ \boldsymbol{\sigma}[S(T)] & \neq & \varnothing \quad \wedge \\ -T_n & = & \boldsymbol{\sigma}[S(T)]_n \quad \wedge \\ -g_0 & \leqslant & T_g \quad \wedge \\ -v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_b \quad \wedge \\ -T_g & \leqslant & {B_H}_l - \ell(B_\mathbf{R})_u +T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ +g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ +v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ +T_{\mathrm{g}} & \leqslant & {B_{\mathrm{H}}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_g$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_u$, must be no greater than the block's \textbf{gasLimit}, ${B_H}_l$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{\mathrm{H}}}_{\mathrm{l}}$. -The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_gT_p$. The gas available for the proceeding computation, $g$, is defined as $T_g - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. +The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{gT}}_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. We define the checkpoint state $\boldsymbol{\sigma}_0$: \begin{eqnarray} \boldsymbol{\sigma}_0 & \equiv & \boldsymbol{\sigma} \quad \text{except:} \\ -\boldsymbol{\sigma}_0[S(T)]_b & \equiv & \boldsymbol{\sigma}[S(T)]_b - T_g T_p \\ -\boldsymbol{\sigma}_0[S(T)]_n & \equiv & \boldsymbol{\sigma}[S(T)]_n + 1 +\boldsymbol{\sigma}_0[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} - T_{\mathrm{g}} T_{\mathrm{p}} \\ +\boldsymbol{\sigma}_0[S(T)]_{\mathrm{n}} & \equiv & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_P$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_P$, remaining gas $g'$, substate $A$ and status code $z$: +Evaluating $\boldsymbol{\sigma}_{\mathrm{P}}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} -(\boldsymbol{\sigma}_P, g', A, z) \equiv \begin{cases} -\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad g, T_p, T_v, T_\mathbf{i}, 0, \top) & \text{if} \quad T_t = \varnothing \\ -\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_o, &\\ \quad\quad T_t, T_t, g, T_p, T_v, T_v, T_\mathbf{d}, 0, \top) & \text{otherwise} +(\boldsymbol{\sigma}_{\mathrm{P}}, g', A, z) \equiv \begin{cases} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_\mathbf{i}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ +\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} \end{equation} where $g$ is the amount of gas remaining after deducting the basic amount required to pay for the existence of the transaction: \begin{equation} -g \equiv T_g - g_0 +g \equiv T_{\mathrm{g}} - g_0 \end{equation} -and $T_o$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. +and $T_{\mathrm{o}}$ is the original transactor, which can differ from the sender in the case of a message call or contract creation not directly triggered by a transaction but coming from the execution of EVM-code. Note we use $\Theta_{4}$ and $\Lambda_{4}$ to denote the fact that only the first four components of the functions' values are taken; the final represents the message-call's output value (a byte array) and is unused in the context of transaction evaluation. After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} -g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_g - g'}{2} \Big\rfloor, A_r \} +g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, A_{\mathrm{r}} \} \end{equation} -The total refundable amount is the legitimately remaining gas $g'$, added to $A_r$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_g - g'$. +The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. -The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_P$: +The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$: \begin{eqnarray} -\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_P \quad \text{except} \\ -\boldsymbol{\sigma}^*[S(T)]_b & \equiv & \boldsymbol{\sigma}_P[S(T)]_b + g^* T_p \\ -\boldsymbol{\sigma}^*[m]_b & \equiv & \boldsymbol{\sigma}_P[m]_b + (T_g - g^*) T_p \\ -m & \equiv & {B_H}_c +\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_{\mathrm{P}} \quad \text{except} \\ +\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[S(T)]_{\mathrm{b}} + g^* T_{\mathrm{p}} \\ +\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - g^*) T_{\mathrm{p}} \\ +m & \equiv & {B_{\mathrm{H}}}_{\mathrm{c}} \end{eqnarray} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: @@ -663,7 +663,7 @@ \subsection{Execution} And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: \begin{eqnarray} -\Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_g - g' \\ +\Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ \Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} @@ -681,7 +681,7 @@ \section{Contract Creation} \label{ch:create} The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: \begin{equation} -a \equiv \mathcal{B}_{96..255}\Big(\mathtt{\tiny KEC}\Big(\mathtt{\tiny RLP}\big(\;(s, \boldsymbol{\sigma}[s]_n - 1)\;\big)\Big)\Big) +a \equiv \mathcal{B}_{96..255}\Big(\mathtt{\tiny KEC}\Big(\mathtt{\tiny RLP}\big(\;(s, \boldsymbol{\sigma}[s]_{\mathrm{n}} - 1)\;\big)\Big)\Big) \end{equation} where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$ and $\boldsymbol{\sigma}[x]$ is the address state of $x$ or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. @@ -696,14 +696,14 @@ \section{Contract Creation} \label{ch:create} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} \end{cases} \\ -\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_n, \boldsymbol{\sigma}[s]_b - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_c) +\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_{\mathrm{n}}, \boldsymbol{\sigma}[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_{\mathrm{c}}) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: \begin{equation} v' \equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}[a] = \varnothing\\ -\boldsymbol{\sigma}[a]_b & \text{otherwise} +\boldsymbol{\sigma}[a]_{\mathrm{b}} & \text{otherwise} \end{cases} \end{equation} @@ -716,18 +716,18 @@ \section{Contract Creation} \label{ch:create} \end{equation} where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: \begin{eqnarray} -I_a & \equiv & a \\ -I_o & \equiv & o \\ -I_p & \equiv & p \\ +I_{\mathrm{a}} & \equiv & a \\ +I_{\mathrm{o}} & \equiv & o \\ +I_{\mathrm{p}} & \equiv & p \\ I_\mathbf{d} & \equiv & () \\ -I_s & \equiv & s \\ -I_v & \equiv & v \\ +I_{\mathrm{s}} & \equiv & s \\ +I_{\mathrm{v}} & \equiv & v \\ I_\mathbf{b} & \equiv & \mathbf{i} \\ -I_e & \equiv & e \\ -I_w & \equiv & w +I_{\mathrm{e}} & \equiv & e \\ +I_{\mathrm{w}} & \equiv & w \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_H$ has no special treatment and is determined from the blockchain. +$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{\mathrm{H}}$ has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, $\varnothing$, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. @@ -752,7 +752,7 @@ \section{Contract Creation} \label{ch:create} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \quad\boldsymbol{\sigma}'[a] = \varnothing & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^{**}, a) \\ \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ -\quad\boldsymbol{\sigma}'[a]_c = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} +\quad\boldsymbol{\sigma}'[a]_{\mathrm{c}} = \texttt{\small KEC}(\mathbf{o}) & \text{otherwise} \end{cases} \\ \quad z &\equiv \begin{cases} 0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor g^{**} < c \\ @@ -780,7 +780,7 @@ \section{Message Call} \label{ch:call} We define $\boldsymbol{\sigma}_1$, the first transitional state as the original state but with the value transferred from sender to recipient: \begin{equation} -\boldsymbol{\sigma}_1[r]_b \equiv \boldsymbol{\sigma}[r]_b + v \quad\wedge\quad \boldsymbol{\sigma}_1[s]_b \equiv \boldsymbol{\sigma}[s]_b - v +\boldsymbol{\sigma}_1[r]_{\mathrm{b}} \equiv \boldsymbol{\sigma}[r]_{\mathrm{b}} + v \quad\wedge\quad \boldsymbol{\sigma}_1[s]_{\mathrm{b}} \equiv \boldsymbol{\sigma}[s]_{\mathrm{b}} - v \end{equation} unless $s = r$. @@ -795,7 +795,7 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_n, \boldsymbol{\sigma}_1'[s]_b - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_c) +\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_{\mathrm{n}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_{\mathrm{c}}) \end{equation} \begin{equation} \text{and}\quad \boldsymbol{\sigma}_1' \equiv \boldsymbol{\sigma} \quad \text{except:} \\ @@ -808,10 +808,10 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) +\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) \end{equation} -The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). +The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_{\mathrm{c}}$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \begin{cases} @@ -832,21 +832,21 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ -\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ -\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ \Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 8 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ -I_a & \equiv & r \\ -I_o & \equiv & o \\ -I_p & \equiv & p \\ +I_{\mathrm{a}} & \equiv & r \\ +I_{\mathrm{o}} & \equiv & o \\ +I_{\mathrm{p}} & \equiv & p \\ I_\mathbf{d} & \equiv & \mathbf{d} \\ -I_s & \equiv & s \\ -I_v & \equiv & \tilde{v} \\ -I_e & \equiv & e \\ -I_w & \equiv & w \\ +I_{\mathrm{s}} & \equiv & s \\ +I_{\mathrm{v}} & \equiv & \tilde{v} \\ +I_{\mathrm{e}} & \equiv & e \\ +I_{\mathrm{w}} & \equiv & w \\ \mathbf{t} & \equiv & \{s, r\} \\ \\ \nonumber -\text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_c +\text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_{\mathrm{c}} \end{eqnarray} It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_\mathbf{b}), I_\mathbf{b})$ at some point prior in order to make the determination of $I_\mathbf{b}$ feasible. @@ -882,16 +882,16 @@ \subsection{Execution Environment} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: \begin{itemize} -\item $I_a$, the address of the account which owns the code that is executing. -\item $I_o$, the sender address of the transaction that originated this execution. -\item $I_p$, the price of gas in the transaction that originated this execution. +\item $I_{\mathrm{a}}$, the address of the account which owns the code that is executing. +\item $I_{\mathrm{o}}$, the sender address of the transaction that originated this execution. +\item $I_{\mathrm{p}}$, the price of gas in the transaction that originated this execution. \item $I_\mathbf{d}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. -\item $I_s$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. -\item $I_v$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. +\item $I_{\mathrm{s}}$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. +\item $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. \item $I_\mathbf{b}$, the byte array that is the machine code to be executed. -\item $I_H$, the block header of the present block. -\item $I_e$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). -\item $I_w$, the permission to make modifications to the state. +\item $I_{\mathrm{H}}$, the block header of the present block. +\item $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: @@ -911,12 +911,12 @@ \subsection{Execution Overview} The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} -\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_g, A, \mathbf{o}) \\ +\Xi(\boldsymbol{\sigma}, g, I, T) & \equiv & (\boldsymbol{\sigma}'\!, \boldsymbol{\mu}'_{\mathrm{g}}, A, \mathbf{o}) \\ (\boldsymbol{\sigma}', \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ -\boldsymbol{\mu}_g & \equiv & g \\ +\boldsymbol{\mu}_{\mathrm{g}} & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ -\boldsymbol{\mu}_i & \equiv & 0 \\ +\boldsymbol{\mu}_{\mathrm{i}} & \equiv & 0 \\ \boldsymbol{\mu}_\mathbf{s} & \equiv & () \\ \boldsymbol{\mu}_\mathbf{o} & \equiv & () \end{eqnarray} @@ -934,10 +934,10 @@ \subsection{Execution Overview} \mathbf{o} & \equiv & H(\boldsymbol{\mu}, I) \\ (a, b, c, d) \cdot e & \equiv & (a, b, c, d, e) \\ \boldsymbol{\mu}' & \equiv & \boldsymbol{\mu}\ \text{except:} \\ -\boldsymbol{\mu}'_g & \equiv & \boldsymbol{\mu}_g - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) +\boldsymbol{\mu}'_{\mathrm{g}} & \equiv & \boldsymbol{\mu}_{\mathrm{g}} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \end{eqnarray} -Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_g$ from the resultant machine state $\boldsymbol{\mu}'$. +Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_{\mathrm{g}}$ from the resultant machine state $\boldsymbol{\mu}'$. $X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either $Z$ becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until $H$ becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. @@ -954,20 +954,20 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_Halting_function_Z}{} +\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{} \subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: \begin{equation} Z(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \equiv \begin{array}[t]{l} -\boldsymbol{\mu}_g < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ -\mathbf{\delta}_w = \varnothing \quad \vee \\ -\lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ +\boldsymbol{\mu}_{\mathrm{g}} < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ +\mathbf{\delta}_{\mathrm{w}} = \varnothing \quad \vee \\ +\lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_{\mathrm{w}} \quad \vee \\ ( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ ( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ - \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ - \neg I_w \wedge W(w, \boldsymbol{\mu}) + \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_{\mathrm{w}} + \mathbf{\alpha}_{\mathrm{w}} > 1024 \quad \vee \\ + \neg I_{\mathrm{w}} \wedge W(w, \boldsymbol{\mu}) \end{array} \end{equation} where @@ -989,15 +989,15 @@ \subsubsection{Jump Destination Validity} Formally: \begin{equation} -D(\mathbf{c}) \equiv D_J(\mathbf{c}, 0) +D(\mathbf{c}) \equiv D_{\mathrm{J}}(\mathbf{c}, 0) \end{equation} where: \begin{equation} -D_J(\mathbf{c}, i) \equiv \begin{cases} +D_{\mathrm{J}}(\mathbf{c}, i) \equiv \begin{cases} \{\} & \text{if} \quad i \geqslant |\mathbf{c}| \\ -\{ i \} \cup D_J(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ -D_J(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ +\{ i \} \cup D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ +D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ \end{cases} \end{equation} @@ -1026,9 +1026,9 @@ \subsection{The Execution Cycle} Stack items are added or removed from the left-most, lower-indexed portion of the series; all other items remain unchanged: \begin{eqnarray} O\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \equiv & (\boldsymbol{\sigma}', \boldsymbol{\mu}', A', I) \\ -\Delta & \equiv & \mathbf{\alpha}_w - \mathbf{\delta}_w \\ +\Delta & \equiv & \mathbf{\alpha}_{\mathrm{w}} - \mathbf{\delta}_{\mathrm{w}} \\ \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert & \equiv & \lVert\boldsymbol{\mu}_\mathbf{s}\rVert + \Delta \\ -\quad \forall x \in [\mathbf{\alpha}_w, \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert): \boldsymbol{\mu}'_\mathbf{s}[x] & \equiv & \boldsymbol{\mu}_\mathbf{s}[x-\Delta] +\quad \forall x \in [\mathbf{\alpha}_{\mathrm{w}}, \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert): \boldsymbol{\mu}'_\mathbf{s}[x] & \equiv & \boldsymbol{\mu}_\mathbf{s}[x-\Delta] \end{eqnarray} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: @@ -1044,7 +1044,7 @@ \subsection{The Execution Cycle} In general, we assume the memory, self-destruct set and system state don't change: \begin{eqnarray} \boldsymbol{\mu}'_\mathbf{m} & \equiv & \boldsymbol{\mu}_\mathbf{m} \\ -\boldsymbol{\mu}'_i & \equiv & \boldsymbol{\mu}_i \\ +\boldsymbol{\mu}'_{\mathrm{i}} & \equiv & \boldsymbol{\mu}_{\mathrm{i}} \\ A' & \equiv & A \\ \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma} \end{eqnarray} @@ -1059,11 +1059,11 @@ \section{Blocktree to Blockchain} \label{ch:ghost} Thus we define the total difficulty of block $B$ recursively as: \begin{eqnarray} -B_t & \equiv & B'_t + B_d \\ -B' & \equiv & P(B_H) +B_{\mathrm{t}} & \equiv & B'_{\mathrm{t}} + B_{\mathrm{d}} \\ +B' & \equiv & P(B_{\mathrm{H}}) \end{eqnarray} -As such given a block $B$, $B_t$ is its total difficulty, $B'$ is its parent block and $B_d$ is its difficulty. +As such given a block $B$, $B_{\mathrm{t}}$ is its total difficulty, $B'$ is its parent block and $B_{\mathrm{d}}$ is its difficulty. \section{Block Finalisation} \label{ch:finalisation} @@ -1080,14 +1080,14 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_{\mathrm{H}})_{\mathrm{H}}, 6) \end{equation} where $k$ denotes the ``is-kin'' property: \begin{equation} k(U, H, n) \equiv \begin{cases} false & \text{if} \quad n = 0 \\ s(U, H) &\\ -\quad \vee \; k(U, P(H)_H, n - 1) & \text{otherwise} +\quad \vee \; k(U, P(H)_{\mathrm{H}}, n - 1) & \text{otherwise} \end{cases} \end{equation} @@ -1101,32 +1101,32 @@ \subsection{Transaction Validation} %where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_\mathbf{T}[i]$, and $g[i]$ the total gas used immediately after said transaction. -The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_H}_g$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: +The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{\mathrm{H}}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_H}_g = \ell(\mathbf{R})_u +{B_{\mathrm{H}}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} \end{equation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_{\mathrm{b}}$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number. Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ +\qquad\boldsymbol{\sigma}'[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ \qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber -\boldsymbol{\sigma}'[U_c] & = & \begin{cases} -\varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ +\boldsymbol{\sigma}'[U_{\mathrm{c}}] & = & \begin{cases} +\varnothing &\text{if}\ \boldsymbol{\sigma}[U_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ -\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_c]_n, \boldsymbol{\sigma}[U_c]_b + R, \boldsymbol{\sigma}[U_c]_\mathbf{s}, \boldsymbol{\sigma}[U_c]_c) \\ -R & \equiv & (1 + \frac{1}{8} (U_i - {B_H}_i)) R_b +\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_\mathbf{s}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ +R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{\mathrm{H}}}_{\mathrm{i}})) R_{\mathrm{b}} \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. We define the block reward as 3 Ether: \begin{equation} -\text{Let} \quad R_b = 3 \times 10^{18} +\text{Let} \quad R_{\mathrm{b}} = 3 \times 10^{18} \end{equation} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} @@ -1134,34 +1134,34 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} -\boldsymbol{\sigma}_0 & \text{if} \quad P(B_H) = \varnothing \\ -\boldsymbol{\sigma}_i: \mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i)) = {P(B_H)_H}_r & \text{otherwise} +\boldsymbol{\sigma}_0 & \text{if} \quad P(B_{\mathrm{H}}) = \varnothing \\ +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ -B'_n & = & n: \quad x \leqslant \frac{2^{256}}{H_d} \\ -B'_m & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ -B^* & \equiv & B \quad \text{except:} \quad B^*_r = r(\Pi(\Gamma(B), B)) +B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \\ +B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ +B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_z$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_u$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_b$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} \boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} \end{equation} -In the case of $B_\mathbf{R}[n]_u$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: +In the case of $B_\mathbf{R}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} -\mathbf{R}[n]_u = \begin{cases} 0 & \text{if} \quad n < 0 \\ +\mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_u +\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} @@ -1172,9 +1172,9 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -We define $\mathbf{R}[n]_z$ in a similar manner. +We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. \begin{equation} -\mathbf{R}[n]_z = +\mathbf{R}[n]_{\mathrm{z}} = \Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} @@ -1199,10 +1199,10 @@ \subsection{Mining Proof-of-Work} \label{ch:pow} More formally, the proof-of-work function takes the form of $\mathtt{PoW}$: \begin{equation} -m = H_m \quad \wedge \quad n \leqslant \frac{2^{256}}{H_d} \quad \text{with} \quad (m, n) = \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d}) +m = H_{\mathrm{m}} \quad \wedge \quad n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \text{with} \quad (m, n) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) \end{equation} -Where $H_{\hcancel{n}}$ is the new block's header but \textit{without} the nonce and mix-hash components; $H_n$ is the nonce of the header; $\mathbf{d}$ is a large data set needed to compute the mixHash and $H_d$ is the new block's difficulty value (i.e. the block difficulty from section \ref{ch:ghost}). $\mathtt{PoW}$ is the proof-of-work function which evaluates to an array with the first item being the mixHash and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. The underlying algorithm is called Ethash and is described below. +Where $H_{\hcancel{n}}$ is the new block's header but \textit{without} the nonce and mix-hash components; $H_{\mathrm{n}}$ is the nonce of the header; $\mathbf{d}$ is a large data set needed to compute the mixHash and $H_{\mathrm{d}}$ is the new block's difficulty value (i.e. the block difficulty from section \ref{ch:ghost}). $\mathtt{PoW}$ is the proof-of-work function which evaluates to an array with the first item being the mixHash and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. The underlying algorithm is called Ethash and is described below. \subsubsection{Ethash} Ethash is the PoW algorithm for Ethereum 1.0. It is the latest version of Dagger-Hashimoto, introduced by \cite{dagger} and \cite{hashimoto}, although it can no longer appropriately be called that since many of the original features of both algorithms have been drastically changed in the last month of research and development. The general route that the algorithm takes is as follows: @@ -1312,7 +1312,7 @@ \section{Recursive Length Prefix}\label{app:rlp} We define the RLP function as $\mathtt{\tiny RLP}$ through two sub-functions, the first handling the instance when the value is a byte array, the second when it is a sequence of further values: \begin{equation} -\mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_b(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_l(\mathbf{x}) & \text{otherwise} \end{cases} +\mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_{\mathrm{b}}(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_{\mathrm{l}}(\mathbf{x}) & \text{otherwise} \end{cases} \end{equation} If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: @@ -1323,14 +1323,14 @@ \section{Recursive Length Prefix}\label{app:rlp} \item Otherwise, the output is equal to the input prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the input byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183. \end{itemize} \hypertarget{R b}{} -Formally, we define $R_b$: +Formally, we define $R_{\mathrm{b}}$: \begin{eqnarray} -R_b(\mathbf{x}) & \equiv & \begin{cases} +R_{\mathrm{b}}(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ (128 + \lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{else if} \quad \lVert \mathbf{x} \rVert < 56 \\ \big(183 + \big\lVert \mathtt{\tiny BE}(\lVert \mathbf{x} \rVert) \big\rVert \big) \cdot \mathtt{\tiny BE}(\lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{otherwise} \end{cases} \\ -\mathtt{\tiny BE}(x) & \equiv & (b_0, b_1, ...): b_0 \neq 0 \wedge x = \sum_{n = 0}^{n < \lVert \mathbf{b} \rVert} b_n \cdot 256^{\lVert \mathbf{b} \rVert - 1 - n} \\ +\mathtt{\tiny BE}(x) & \equiv & (b_0, b_1, ...): b_0 \neq 0 \wedge x = \sum_{n = 0}^{n < \lVert \mathbf{b} \rVert} b_{\mathrm{n}} \cdot 256^{\lVert \mathbf{b} \rVert - 1 - n} \\ (a) \cdot (b, c) \cdot (d, e) & = & (a, b, c, d, e) \end{eqnarray} @@ -1343,16 +1343,16 @@ \section{Recursive Length Prefix}\label{app:rlp} \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} -Thus we finish by formally defining $R_l$: +Thus we finish by formally defining $R_{\mathrm{l}}$: \begin{eqnarray} -R_l(\mathbf{x}) & \equiv & \begin{cases} +R_{\mathrm{l}}(\mathbf{x}) & \equiv & \begin{cases} (192 + \lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{if} \quad \lVert s(\mathbf{x}) \rVert < 56 \\ \big(247 + \big\lVert \mathtt{\tiny BE}(\lVert s(\mathbf{x}) \rVert) \big\rVert \big) \cdot \mathtt{\tiny BE}(\lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{otherwise} \end{cases} \\ s(\mathbf{x}) & \equiv & \mathtt{\tiny RLP}(\mathbf{x}_0) \cdot \mathtt{\tiny RLP}(\mathbf{x}_1) ... \end{eqnarray} -If RLP is used to encode a scalar, defined only as a positive integer ($\mathbb{P}$ or any $x$ for $\mathbb{P}_x$), it must be specified as the shortest byte array such that the big-endian interpretation of it is equal. Thus the RLP of some positive integer $i$ is defined as: +If RLP is used to encode a scalar, defined only as a positive integer ($\mathbb{P}$ or any $x$ for $\mathbb{P}_{\mathrm{x}}$), it must be specified as the shortest byte array such that the big-endian interpretation of it is equal. Thus the RLP of some positive integer $i$ is defined as: \begin{equation} \mathtt{\tiny RLP}(i : i \in \mathbb{P}) \equiv \mathtt{\tiny RLP}(\mathtt{\tiny BE}(i)) \end{equation} @@ -1394,10 +1394,10 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: \begin{eqnarray} y(\mathfrak{I}) & = & \{ (\mathbf{k}_0' \in \mathbb{Y}, \mathbf{v}_0 \in \mathbb{B}), (\mathbf{k}_1' \in \mathbb{Y}, \mathbf{v}_1 \in \mathbb{B}), ... \} \\ -\forall_n \quad \forall_{i: i < 2\lVert\mathbf{k}_n\rVert} \quad \mathbf{k}_n'[i] & \equiv & +\forall_{\mathrm{n}} \quad \forall_{i: i < 2\lVert\mathbf{k}_{\mathrm{n}}\rVert} \quad \mathbf{k}_{\mathrm{n}}'[i] & \equiv & \begin{cases} -\lfloor \mathbf{k}_n[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ -\mathbf{k}_n[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} +\lfloor \mathbf{k}_{\mathrm{n}}[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ +\mathbf{k}_{\mathrm{n}}[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} \end{cases} \end{eqnarray} @@ -1426,7 +1426,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_{\mathrm{x}} : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} @@ -1447,16 +1447,16 @@ \section{Precompiled Contracts}\label{app:precompiled} For each precompiled contract, we make use of a template function, $\Xi_{\mathtt{PRE}}$, which implements the out-of-gas checking. \begin{equation} \label{eq:pre} \Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, g, I, T) \equiv \begin{cases} -(\varnothing, 0, A^0, ()) & \text{if} \quad g < g_r \\ -(\boldsymbol\sigma, g - g_r, A^0, \mathbf{o}) & \text{otherwise}\end{cases} +(\varnothing, 0, A^0, ()) & \text{if} \quad g < g_{\mathrm{r}} \\ +(\boldsymbol\sigma, g - g_{\mathrm{r}}, A^0, \mathbf{o}) & \text{otherwise}\end{cases} \end{equation} -The precompiled contracts each use these definitions and provide specifications for the $\mathbf{o}$ (the output data) and $g_r$, the gas requirements. +The precompiled contracts each use these definitions and provide specifications for the $\mathbf{o}$ (the output data) and $g_{\mathrm{r}}$, the gas requirements. For the elliptic curve DSA recover VM execution function, we also define $\mathbf{d}$ to be the input data, well-defined for an infinite length by appending zeroes as required. Importantly in the case of an invalid signature ($\mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing$), then we have no output. \begin{eqnarray} \Xi_{\mathtt{ECREC}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 3000\\ +g_{\mathrm{r}} &=& 3000\\ |\mathbf{o}| &=& \begin{cases} 0 & \text{if} \quad \mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing\\ 32 & \text{otherwise} \end{cases}\\ \text{if} \quad |\mathbf{o}| = 32: &&\\ \mathbf{o}[0..11] &=& 0 \\ @@ -1472,10 +1472,10 @@ \section{Precompiled Contracts}\label{app:precompiled} The two hash functions, RIPEMD-160 and SHA2-256 are more trivially defined as an almost pass-through operation. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. \begin{eqnarray} \Xi_{\mathtt{SHA256}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 60 + 12\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ \mathbf{o}[0..31] &=& \mathtt{\tiny SHA256}(I_\mathbf{d})\\ \Xi_{\mathtt{RIP160}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 600 + 120\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ \mathbf{o}[0..11] &=& 0 \\ \mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_\mathbf{d})\\ \end{eqnarray} @@ -1489,7 +1489,7 @@ \section{Precompiled Contracts}\label{app:precompiled} The fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: \begin{eqnarray} \Xi_{\mathtt{ID}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_r &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ \mathbf{o} &=& I_\mathbf{d} \end{eqnarray} @@ -1497,25 +1497,25 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_r &=& \Big\lfloor\frac{f\big(\max(\ell_M,\ell_B)\big)\max(\ell'_E,1)}{G_{quaddivisor}}\Big\rfloor \\ +g_{\mathrm{r}} &=& \Big\lfloor\frac{f\big(\max(\ell_{\mathrm{M}},\ell_{\mathrm{B}})\big)\max(\ell'_{\mathrm{E}},1)}{G_{quaddivisor}}\Big\rfloor \\ f(x) &\equiv& \begin{cases} x^2 & \text{if}\ x \le 64 \\ \Big\lfloor\dfrac{x^2}{4}\Big\rfloor + 96 x - 3072 & \text{if}\ 64 < x \le 1024 \\ \Big\lfloor\dfrac{x^2}{16}\Big\rfloor + 480x - 199680 & \text{otherwise} \end{cases}\\ -\ell'_E &=& \begin{cases} -0 & \text{if}\ \ell_E\le 32\wedge E=0 \\ -\lfloor \log_2(E)\rfloor &\text{if}\ \ell_E\le 32 \wedge E \neq 0 \\ -8(\ell_E - 32) + \lfloor \log_2(i[(96+\ell_B)..(127+\ell_B)]) \rfloor & \text{if}\ 32 < \ell_E \wedge i[(96 + \ell_B)..(127 + \ell_B)]\neq 0 \\ -8(\ell_E - 32) & \text{otherwise} \\ +\ell'_{\mathrm{E}} &=& \begin{cases} +0 & \text{if}\ \ell_{\mathrm{E}}\le 32\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_{\mathrm{E}}\le 32 \wedge E \neq 0 \\ +8(\ell_{\mathrm{E}} - 32) + \lfloor \log_2(i[(96+\ell_{\mathrm{B}})..(127+\ell_{\mathrm{B}})]) \rfloor & \text{if}\ 32 < \ell_{\mathrm{E}} \wedge i[(96 + \ell_{\mathrm{B}})..(127 + \ell_{\mathrm{B}})]\neq 0 \\ +8(\ell_{\mathrm{E}} - 32) & \text{otherwise} \\ \end{cases} \\ -\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_M} \\ -\ell_B &\equiv& i[0..31] \\ -\ell_E &\equiv& i[32..63] \\ -\ell_M &\equiv& i[64..95] \\ -B &\equiv& i[96..(95+\ell_B)] \\ -E &\equiv& i[(96+\ell_B)..(95+\ell_B+\ell_E)] \\ -M &\equiv& i[(96+\ell_B+\ell_E)..(95+\ell_B+\ell_E+\ell_M)] \\ +\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_{\mathrm{M}}} \\ +\ell_{\mathrm{B}} &\equiv& i[0..31] \\ +\ell_{\mathrm{E}} &\equiv& i[32..63] \\ +\ell_{\mathrm{M}} &\equiv& i[64..95] \\ +B &\equiv& i[96..(95+\ell_{\mathrm{B}})] \\ +E &\equiv& i[(96+\ell_{\mathrm{B}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})] \\ +M &\equiv& i[(96+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}}+\ell_{\mathrm{M}})] \\ i[x] &\equiv& \begin{cases} I_{\mathbf d}[x] &\text{if}\ x < |I_{\mathbf d}| \\ 0 &\text{otherwise} @@ -1529,11 +1529,11 @@ \subsection{zkSNARK Related Precompiled Contracts} p &\equiv& 21888242871839275222246405745257275088696311157297823662689037894645226208583 \\ q &\equiv& 21888242871839275222246405745257275088548364400416034343698204186575808495617 \end{eqnarray} -Since $p$ is a prime number, $\{0, 1, \ldots, p - 1\}$ forms a field with addition and multiplication modulo $p$. We call this field $F_p$. +Since $p$ is a prime number, $\{0, 1, \ldots, p - 1\}$ forms a field with addition and multiplication modulo $p$. We call this field $F_{\mathrm{p}}$. We define a set~$C_1$ with \begin{equation} -C_1\equiv\{(X,Y)\in F_p\times F_p\mid Y^2=X^3+3\}\cup\{(0,0)\} +C_1\equiv\{(X,Y)\in F_{\mathrm{p}}\times F_{\mathrm{p}}\mid Y^2=X^3+3\}\cup\{(0,0)\} \end{equation} We define a binary operation $+$ on $C_1$ with \begin{eqnarray}\label{eq:ec-addition} @@ -1554,7 +1554,7 @@ \subsection{zkSNARK Related Precompiled Contracts} We define $P_1$ to be a point $(1,2)$ on $C_1$. Let $G_1$ be the subgroup of $(C_1,+)$ generated by $P_1$. $G_1$ is known to be a cyclic group of order $q$. For a point $P$ in $G_1$, we define $\log_{P_1}(P)$ to be the smallest natural number $n$ satisfying $n\cdot P_1=P$. $\log_{P_1}(P)$ is at most $q-1$. -Let $F_{p^2}$ be a field $F_p[i]/(i+1)$. We define a set $C_2$ with +Let $F_{p^2}$ be a field $F_{\mathrm{p}}[i]/(i+1)$. We define a set $C_2$ with \begin{equation} C_2\equiv\{(X,Y)\in F_{p^2}\times F_{p^2}\mid Y^2=X^3+3\}\cup\{(0,0)\} \end{equation} @@ -1565,9 +1565,9 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{eqnarray} We define $G_2$ to be the subgroup of $(C_2,+)$ generated by $P_2$. $G_2$ is known to be a cyclic group of order $q$. For a point $P$ in $G_2$, we define $\log_{P_2}(P)$ be the smallest natural number $n$ satisfying $n\cdot P_2=P$. With this definition, $\log_{P_2}(P)$ is at most $q-1$. -A 32 byte number $\mathbf{x}\in\mathbf{P}_{256}$ might and might not represent an element of $F_p$. +A 32 byte number $\mathbf{x}\in\mathbf{P}_{256}$ might and might not represent an element of $F_{\mathrm{p}}$. \begin{equation} -\delta_p(\mathbf x)\equiv\begin{cases} +\delta_{\mathrm{p}}(\mathbf x)\equiv\begin{cases} \mathbf x&\text{if}\ \mathbf x 0 \\ @@ -1829,9 +1829,9 @@ \subsection{Gas Cost} $W_{extcode}$ = \{{\small EXTCODESIZE}\} -Note the memory cost component, given as the product of $G_{memory}$ and the maximum of 0 \& the ceiling of the number of words in size that the memory must be over the current number of words, $\boldsymbol{\mu}_i$ in order that all accesses reference valid memory whether for read or write. Such accesses must be for non-zero number of bytes. +Note the memory cost component, given as the product of $G_{memory}$ and the maximum of 0 \& the ceiling of the number of words in size that the memory must be over the current number of words, $\boldsymbol{\mu}_{\mathrm{i}}$ in order that all accesses reference valid memory whether for read or write. Such accesses must be for non-zero number of bytes. -Referencing a zero length range (e.g. by attempting to pass it as the input range to a CALL) does not require memory to be extended to the beginning of the range. $\boldsymbol{\mu}'_i$ is defined as this new maximum number of words of active memory; special-cases are given where these two are not equal. +Referencing a zero length range (e.g. by attempting to pass it as the input range to a CALL) does not require memory to be extended to the beginning of the range. $\boldsymbol{\mu}'_{\mathrm{i}}$ is defined as this new maximum number of words of active memory; special-cases are given where these two are not equal. Note also that $C_{mem}$ is the memory cost function (the expansion function being the difference between the cost before and after). It is a polynomial, with the higher-order coefficient divided and floored, and thus linear up to 724B of memory used, after which it costs substantially more. @@ -1902,8 +1902,8 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] ^ {\boldsymbol{\mu}_\mathbf{s}[1] }$ \\ \midrule 0x0b & {\small SIGNEXTEND} & 2 & 1 & Extend length of two's complement signed integer. \\ -&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_t &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_i &\text{otherwise} \end{cases}$ \\ -\multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_i$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ +&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{t}} &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}} &\text{otherwise} \end{cases}$ \\ +\multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_{\mathrm{i}}$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ \midrule \end{tabular*} @@ -1932,19 +1932,19 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x16 & {\small AND} & 2 & 1 & Bitwise AND operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \boldsymbol{\mu}_\mathbf{s}[0]_i \wedge \boldsymbol{\mu}_\mathbf{s}[1]_i$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \wedge \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ \midrule 0x17 & {\small OR} & 2 & 1 & Bitwise OR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \boldsymbol{\mu}_\mathbf{s}[0]_i \vee \boldsymbol{\mu}_\mathbf{s}[1]_i$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \vee \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ \midrule 0x18 & {\small XOR} & 2 & 1 & Bitwise XOR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \boldsymbol{\mu}_\mathbf{s}[0]_i \oplus \boldsymbol{\mu}_\mathbf{s}[1]_i$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \oplus \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ \midrule 0x19 & {\small NOT} & 1 & 1 & Bitwise NOT operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0]_i = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x1a & {\small BYTE} & 2 & 1 & Retrieve single byte from word. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_i \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{(i + 8\boldsymbol{\mu}_\mathbf{s}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_\mathbf{s}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{(i + 8\boldsymbol{\mu}_\mathbf{s}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_\mathbf{s}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ &&&& For Nth byte, we count from the left (i.e. N=0 would be the most significant in big endian). \\ \bottomrule \end{tabular*} @@ -1955,7 +1955,7 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x20 & {\small SHA3} & 2 & 1 & Compute Keccak-256 hash. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \mathtt{\tiny Keccak}(\boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \bottomrule \end{tabular*} @@ -1964,22 +1964,22 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{30s: Environmental Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x30 & {\small ADDRESS} & 0 & 1 & Get address of currently executing account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_a$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{a}}$ \\ \midrule 0x31 & {\small BALANCE} & 1 & 1 & Get balance of the given account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0]]_b& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0]]_{\mathrm{b}}& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ \midrule 0x32 & {\small ORIGIN} & 0 & 1 & Get execution origination address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_o$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{o}}$ \\ &&&& This is the sender of original transaction; it is never an account with non-empty \\ &&&& associated code. \\ \midrule 0x33 & {\small CALLER} & 0 & 1 & Get caller address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_s$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{s}}$ \\ &&&& This is the address of the account that is directly responsible for this execution. \\ \midrule 0x34 & {\small CALLVALUE} & 0 & 1 & Get deposited value by the instruction/transaction responsible for this execution. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_v$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{v}}$ \\ \midrule 0x35 & {\small CALLDATALOAD} & 1 & 1 & Get input data of current environment. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_\mathbf{d}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \quad \text{with} \quad I_\mathbf{d}[x] = 0 \quad \text{if} \quad x \geqslant \lVert I_\mathbf{d} \rVert$ \\ @@ -1993,7 +1993,7 @@ \subsection{Instruction Set} &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv \begin{cases} I_\mathbf{d}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{d} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x38 & {\small CODESIZE} & 0 & 1 & Get size of code running in current environment. \\ @@ -2002,21 +2002,21 @@ \subsection{Instruction Set} 0x39 & {\small CODECOPY} & 3 & 0 & Copy code running in current environment to memory. \\ &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv \begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{b} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3a & {\small GASPRICE} & 0 & 1 & Get price of gas in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_p$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{p}}$ \\ &&&& This is gas price specified by the originating transaction.\\ \midrule 0x3b & {\small EXTCODESIZE} & 1 & 1 & Get size of an account's code. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_c \rVert$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}} \rVert$ \\ \midrule 0x3c & {\small EXTCODECOPY} & 4 & 0 & Copy an account's code to memory. \\ &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[3] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[1] + i ] \equiv \begin{cases} \mathbf{c}[\boldsymbol{\mu}_\mathbf{s}[2] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] + i < \lVert \mathbf{c} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_c$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ +&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[2] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ @@ -2026,7 +2026,7 @@ \subsection{Instruction Set} &&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ &&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ \bottomrule \end{tabular*} @@ -2035,28 +2035,28 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_{\mathrm{p}}}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ &&&& or more than 256 blocks behind the current block. \\ -&&&& $P(h, n, a) \equiv \begin{cases} 0 & \text{if} \quad n > H_i \vee a = 256 \vee h = 0 \\ h & \text{if} \quad n = H_i \\ P(H_p, n, a + 1) & \text{otherwise} \end{cases}$ \\ +&&&& $P(h, n, a) \equiv \begin{cases} 0 & \text{if} \quad n > H_{\mathrm{i}} \vee a = 256 \vee h = 0 \\ h & \text{if} \quad n = H_{\mathrm{i}} \\ P(H_{\mathrm{p}}, n, a + 1) & \text{otherwise} \end{cases}$ \\ &&&& and we assert the header $H$ can be determined as its hash is the parent hash \\ &&&& in the block following it. \\ \midrule 0x41 & {\small COINBASE} & 0 & 1 & Get the block's beneficiary address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_c$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{c}}$ \\ \midrule 0x42 & {\small TIMESTAMP} & 0 & 1 & Get the block's timestamp. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_s$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{s}}$ \\ \midrule 0x43 & {\small NUMBER} & 0 & 1 & Get the block's number. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_i$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{i}}$ \\ \midrule 0x44 & {\small DIFFICULTY} & 0 & 1 & Get the block's difficulty. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_d$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{d}}$ \\ \midrule 0x45 & {\small GASLIMIT} & 0 & 1 & Get the block's gas limit. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_H}_l$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{l}}$ \\ \bottomrule \end{tabular*} @@ -2068,30 +2068,30 @@ \subsection{Instruction Set} \midrule 0x51 & {\small MLOAD} & 1 & 1 & Load word from memory. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ]$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ -&&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x52 & {\small MSTORE} & 2 & 0 & Save word to memory. \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ -&&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ -&&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x53 & {\small MSTORE8} & 2 & 0 & Save byte to memory. \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv (\boldsymbol{\mu}_\mathbf{s}[1] \bmod 256) $ \\ -&&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 1) \div 32 })$ \\ -&&&& The addition in the calculation of $\boldsymbol{\mu}'_i$ is not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 1) \div 32 })$ \\ +&&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ \midrule 0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_a]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ &&&& $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ +G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} \end{cases}$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_a]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ +R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule @@ -2185,9 +2185,9 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ \multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ -\multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_a, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ +\multicolumn{5}{l}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_{\mathrm{a}}, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ -\multicolumn{5}{l}{$\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ +\multicolumn{5}{l}{$\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ \multicolumn{5}{l}{The entry's topic series, $\mathbf{t}$, differs accordingly:}\vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xa0 & {\small LOG0} & 2 & 0 & Append log record with no topics. \\ @@ -2209,35 +2209,35 @@ \subsection{Instruction Set} \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_g, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_a, I_o, L(\boldsymbol{\mu}_g), I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_e + 1, I_w) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_g, \varnothing\big) & \text{otherwise} \end{cases}$ \\ -&&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_{\mathrm{g}}, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, L(\boldsymbol{\mu}_{\mathrm{g}}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathrm{g}}, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_{\mathrm{a}}]_{\mathrm{n}} = \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}} + 1$ \\ &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ -&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_e = 1024$ \\ -&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_a]_b$ (balance of the caller is too \\ -&&&& low to fulfil the value transfer); and otherwise $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting}\\ +&&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ +&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ +&&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ &&&& created account. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{o} \equiv ()$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ &&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[3] \dots (\boldsymbol{\mu}_\mathbf{s}[3] + \boldsymbol{\mu}_\mathbf{s}[4] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_a, I_o, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge \\ \quad\quad I_e < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_{\mathrm{a}}, I_{\mathrm{o}}, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge \\ \quad\quad I_{\mathrm{e}} < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{o} = \mathbf{o}$ \\ -&&&& $\boldsymbol{\mu}'_g \equiv \boldsymbol{\mu}_g + g'$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{g}} \equiv \boldsymbol{\mu}_{\mathrm{g}} + g'$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ -&&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_a]_b$ (not enough funds) or $I_e = 1024$ (call depth limit reached); $x=1$ \\ +&&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ &&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ &&&& $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} @@ -2245,7 +2245,7 @@ \subsection{Instruction Set} C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -\min\{ L(\boldsymbol{\mu}_g - C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})), \boldsymbol{\mu}_{\mathbf{s}}[0] \} & \text{if} \quad \boldsymbol{\mu}_g \ge C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ +\min\{ L(\boldsymbol{\mu}_{\mathrm{g}} - C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})), \boldsymbol{\mu}_{\mathbf{s}}[0] \} & \text{if} \quad \boldsymbol{\mu}_{\mathrm{g}} \ge C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})\\ \boldsymbol{\mu}_{\mathbf{s}}[0] & \text{otherwise} \end{cases}$\\ &&&& $C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + C_{\text{\tiny XFER}}(\boldsymbol{\mu}) + C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$\\ @@ -2260,16 +2260,16 @@ \subsection{Instruction Set} \midrule 0xf2 & {\small CALLCODE} & 7 & 1 & Message-call into this account with an alternative account's code. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_a, I_o, I_a, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_p, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_e + 1, I_w)\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\\ \quad\quad{}I_e < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\\ \quad\quad{}I_{\mathrm{e}} < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ -&&&& (as in {\small CALL}) to the present address $I_a$. This means that the recipient is in fact the\\ +&&&& (as in {\small CALL}) to the present address $I_{\mathrm{a}}$. This means that the recipient is in fact the\\ &&&& same account as at present, simply that the code is overwritten.\\ \midrule 0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ &&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ &&&& This has the effect of halting the execution at this point with output defined.\\ &&&& See section \ref{ch:model}. \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} @@ -2280,7 +2280,7 @@ \subsection{Instruction Set} &&&& argument is $\boldsymbol{\mu}_\mathbf{s}[2]$. As a result, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ in the definition of {\small CALL} \\ &&&& should respectively be replaced with $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ &&&& Otherwise exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_s, I_o, I_a, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_p, 0, I_v, \mathbf{i}, I_e + 1, I_w)\end{array} & \text{if} \quad I_v \leqslant \boldsymbol{\sigma}[I_a]_b \;\wedge\; I_e < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{s}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_{\mathrm{p}}, 0, I_{\mathrm{v}}, \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \text{if} \quad I_{\mathrm{v}} \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the changes (in addition to that of the fourth parameter) to the second \\ &&&& and ninth parameters to the call $\Theta$.\\ &&&& This means that the recipient is in fact the same account as at present, simply\\ @@ -2296,28 +2296,28 @@ \subsection{Instruction Set} 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and remaining gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we use the memory expansion function, \\ -&&&& $\boldsymbol{\mu}'_i \equiv M(\boldsymbol{\mu}_i, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule 0xff & {\small SELFDESTRUCT} & 1 & 0 & Halt execution and register account for later deletion. \\ -&&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_a \}$ \\ +&&&& $A'_\mathbf{s} \equiv A_\mathbf{s} \cup \{ I_{\mathrm{a}} \}$ \\ &&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} -\varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_a]_b = 0\\ -(\boldsymbol{\sigma}[r]_n, \boldsymbol{\sigma}[r]_b + \boldsymbol{\sigma}[I_a]_b, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{if}\ r \neq I_a \\ -(\boldsymbol{\sigma}[r]_n, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_c) & \text{otherwise} +\varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} = 0\\ +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\ r \neq I_{\mathrm{a}} \\ +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{otherwise} \end{cases}$\\ &&&& where $r = \boldsymbol{\mu}_\mathbf{s}[0] \bmod 2^{160}$\\ -&&&& $\boldsymbol{\sigma}'[I_a]_b = 0$ \\ +&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathrm{b}} = 0$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{selfdestruct} & \text{if} \quad I_a \notin A_\mathbf{s} \\ +R_{selfdestruct} & \text{if} \quad I_{\mathrm{a}} \notin A_\mathbf{s} \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_a]_b \neq 0$ \\ +&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \neq 0$ \\ \bottomrule \end{tabular*} @@ -2358,7 +2358,7 @@ \subsection{Definitions} \subsection{Size of dataset and cache} The size for Ethash's cache $\mathbf{c} \in \mathbb{B}$ and dataset $\mathbf{d} \in \mathbb{B}$ depend on the epoch, which in turn depends on the block number. \begin{equation} - E_{epoch}(H_i) = \left\lfloor\frac{H_i}{J_{epoch}}\right\rfloor + E_{epoch}(H_{\mathrm{i}}) = \left\lfloor\frac{H_{\mathrm{i}}}{J_{epoch}}\right\rfloor \end{equation} The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache. Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using @@ -2380,12 +2380,12 @@ \subsection{Dataset generation} \subsubsection{Seed hash} The seed hash is different for every epoch. For the first epoch it is the Keccak-256 hash of a series of 32 bytes of zeros. For every other epoch it is always the Keccak-256 hash of the previous seed hash: \begin{equation} - \mathbf{s} = C_{seedhash}(H_i) + \mathbf{s} = C_{seedhash}(H_{\mathrm{i}}) \end{equation} \begin{equation} - C_{seedhash}(H_i) = \begin{cases} -\texttt{KEC}(\mathbf{0}_{32}) & \text{if} \quad E_{epoch}(H_i) = 0 \quad \\ -\texttt{KEC}(C_{seedhash}(H_i - J_{epoch})) & \text{otherwise} + C_{seedhash}(H_{\mathrm{i}}) = \begin{cases} +\texttt{KEC}(\mathbf{0}_{32}) & \text{if} \quad E_{epoch}(H_{\mathrm{i}}) = 0 \quad \\ +\texttt{KEC}(C_{seedhash}(H_{\mathrm{i}} - J_{epoch})) & \text{otherwise} \end{cases} \end{equation} With $\mathbf{0}_{32}$ being 32 bytes of zeros. @@ -2460,16 +2460,16 @@ \subsection{Proof-of-work function} The PoW-function returns an array with the compressed mix as its first item and the Keccak-256 hash of the concatenation of the compressed mix with the seed hash as the second item: \begin{equation} - \mathtt{PoW}(H_{\hcancel{n}}, H_n, \mathbf{d}) = \lbrace \mathbf{m}_c(\mathtt{\small KEC}(\mathtt{\small RLP}(L_H(H_{\hcancel{n}}))), H_n, \mathbf{d}), \texttt{KEC}(\mathbf{s}_h(\mathtt{\small KEC}(\mathtt{\small RLP}(L_H(H_{\hcancel{n}}))), H_n) + \mathbf{m}_c(\mathtt{\small KEC}(\mathtt{\small RLP}(L_H(H_{\hcancel{n}}))), H_n, \mathbf{d})) \rbrace + \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) = \lbrace \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d}), \texttt{KEC}(\mathbf{s}_{\mathrm{h}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}) + \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d})) \rbrace \end{equation} -With $H_{\hcancel{n}}$ being the hash of the header without the nonce. The compressed mix $\mathbf{m}_c$ is obtained as follows: +With $H_{\hcancel{n}}$ being the hash of the header without the nonce. The compressed mix $\mathbf{m}_{\mathrm{c}}$ is obtained as follows: \begin{equation} - \mathbf{m}_c(\mathbf{h}, \mathbf{n}, \mathbf{d}) = E_{compress}(E_{accesses}(\mathbf{d}, \sum_{i = 0}^{n_{mix}} \mathbf{s}_h(\mathbf{h}, \mathbf{n}), \mathbf{s}_h(\mathbf{h}, \mathbf{n}), -1), -4) + \mathbf{m}_{\mathrm{c}}(\mathbf{h}, \mathbf{n}, \mathbf{d}) = E_{compress}(E_{accesses}(\mathbf{d}, \sum_{i = 0}^{n_{mix}} \mathbf{s}_{\mathrm{h}}(\mathbf{h}, \mathbf{n}), \mathbf{s}_{\mathrm{h}}(\mathbf{h}, \mathbf{n}), -1), -4) \end{equation} The seed hash being: \begin{equation} - \mathbf{s}_h(\mathbf{h}, \mathbf{n}) = \texttt{KEC512}(\mathbf{h} + E_{revert}(\mathbf{n})) + \mathbf{s}_{\mathrm{h}}(\mathbf{h}, \mathbf{n}) = \texttt{KEC512}(\mathbf{h} + E_{revert}(\mathbf{n})) \end{equation} $E_{revert}(\mathbf{n})$ returns the reverted bytes sequence of the nonce $\mathbf{n}$: \begin{equation} From a6730daf58edfa4123fc60932a5bdd0fa6c00c6f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:31:47 +1100 Subject: [PATCH 328/460] Remove underscores in a URL --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index fa51a9f0..0a980cec 100644 --- a/Paper.tex +++ b/Paper.tex @@ -28,7 +28,7 @@ \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} % "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . -% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_{\mathrm{and}}_{\mathrm{Hypertarget}}. +% For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. \makeatletter \newcommand{\linkdest}[1]{\Hy@raisedlink{\hypertarget{#1}{}}} From ee13fcb3aa2e1137f90edeab419e8f88eac57291 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:35:01 +1100 Subject: [PATCH 329/460] Remove mathrms that have been added in the wrong place. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 0a980cec..b169d2b7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -116,7 +116,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_{\mathrm{state}}_{\mathrm{transition}}}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) +\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. From 4d8837ba8eebf7f19f81674943cdc3c8ce79df23 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:39:32 +1100 Subject: [PATCH 330/460] Remove mathrms that have been added in the wrong place --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b169d2b7..387506b7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -418,7 +418,7 @@ \subsubsection{Holistic Validity} Furthermore: \begin{equation} -\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} +\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} \end{equation} Thus $\texttt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{\mathrm{H}})$ is the parent block of $B$, defined directly. From 019f74c844bba77374c6dcdb6aa13b9bf1268abb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:53:15 +1100 Subject: [PATCH 331/460] Replace all mathrm\\\{([A-Z]\} with $1 Using Libre Open Office with match case and regex. --- Paper.tex | 166 +++++++++++++++++++++++++++--------------------------- 1 file changed, 83 insertions(+), 83 deletions(-) diff --git a/Paper.tex b/Paper.tex index 387506b7..e6147e9e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -217,12 +217,12 @@ \subsection{World State} \label{ch:state} Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: \begin{equation} -\texttt{\small TRIE}\big(L_{\mathrm{I}}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} +\texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} -The collapse function for the set of key/value pairs in the trie, $L_{\mathrm{I}}^*$, is defined as the element-wise transformation of the base function $L_{\mathrm{I}}$, given as: +The collapse function for the set of key/value pairs in the trie, $L_{I}^*$, is defined as the element-wise transformation of the base function $L_{I}$, given as: \begin{equation} -L_{\mathrm{I}}\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) +L_{I}\big( (k, v) \big) \equiv \big(\texttt{\small KEC}(k), \texttt{\small RLP}(v)\big) \end{equation} where: @@ -234,16 +234,16 @@ \subsection{World State} \label{ch:state} If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. -Thus we may define a world-state collapse function $L_{\mathrm{S}}$: +Thus we may define a world-state collapse function $L_{S}$: \begin{equation} -L_{\mathrm{S}}(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} +L_{S}(\boldsymbol{\sigma}) \equiv \{ p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} \end{equation} where \begin{equation} p(a) \equiv \big(\texttt{\small KEC}(a), \texttt{\small RLP}\big( (\boldsymbol{\sigma}[a]_{\mathrm{n}}, \boldsymbol{\sigma}[a]_{\mathrm{b}}, \boldsymbol{\sigma}[a]_{\mathrm{s}}, \boldsymbol{\sigma}[a]_{\mathrm{c}}) \big) \big) \end{equation} -This function, $L_{\mathrm{S}}$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: +This function, $L_{S}$, is used alongside the trie function to provide a short identity (hash) of the world state. We assume: \begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \; \vee \; (a \in \mathbb{B}_{20} \; \wedge \; v(\boldsymbol{\sigma}[a])) \end{equation} @@ -293,7 +293,7 @@ \subsection{The Transaction} \label{ch:transaction} Appendix \ref{app:signing} specifies the function, $S$, which maps transactions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction $T$ can be represented with $S(T)$. \begin{equation} -L_{\mathrm{T}}(T) \equiv \begin{cases} +L_{T}(T) \equiv \begin{cases} (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{i}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{d}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} @@ -344,7 +344,7 @@ \subsection{The Block} \label{ch:block} The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{\mathrm{H}}, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) \end{equation} \subsubsection{Transaction Receipt} @@ -357,9 +357,9 @@ \subsubsection{Transaction Receipt} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) \end{equation} -The function $L_{\mathrm{R}}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: +The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_{\mathrm{R}}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) +L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. @@ -373,7 +373,7 @@ \subsubsection{Transaction Receipt} R_{\mathrm{u}} \in \mathbb{P} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \end{equation} -%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{\mathrm{B}}$; it is merely a convenience equivalence. +%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_{\mathrm{a}}$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} @@ -403,10 +403,10 @@ \subsubsection{Holistic Validity} We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: \begin{equation} \begin{array}[t]{lclc} -H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_{\mathrm{S}}(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}^*(B_\mathbf{U}))) & \wedge \\ -H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{T}}(B_\mathbf{T}[i]))\}) & \wedge \\ -H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{\mathrm{R}}(B_\mathbf{R}[i]))\}) & \wedge \\ +H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_{S}(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}^*(B_\mathbf{U}))) & \wedge \\ +H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_\mathbf{T}[i]))\}) & \wedge \\ +H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_\mathbf{R}[i]))\}) & \wedge \\ H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} @@ -418,22 +418,22 @@ \subsubsection{Holistic Validity} Furthermore: \begin{equation} -\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} +\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} \end{equation} -Thus $\texttt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{\mathrm{H}})$ is the parent block of $B$, defined directly. +Thus $\texttt{\small TRIE}(L_{S}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{H})$ is the parent block of $B$, defined directly. The values stemming from the computation of transactions, specifically the transaction receipts, $B_\mathbf{R}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} -The function $L_{\mathrm{B}}$ and $L_{\mathrm{H}}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{\mathrm{R}}$, we assert the types and order of the structure for when the RLP transformation is required: +The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} -\quad L_{\mathrm{H}}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ -\quad L_{\mathrm{B}}(B) & \equiv & \big( L_{\mathrm{H}}(B_{\mathrm{H}}), L_{\mathrm{T}}^*(B_\mathbf{T}), L_{\mathrm{H}}^*(B_\mathbf{U}) \big) +\quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ +\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_\mathbf{T}), L_{H}^*(B_\mathbf{U}) \big) \end{eqnarray} -With $L_{\mathrm{T}}^*$ and $L_{\mathrm{H}}^*$ being element-wise sequence transformations, thus: +With $L_{T}^*$ and $L_{H}^*$ being element-wise sequence transformations, thus: \begin{equation} f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} @@ -458,14 +458,14 @@ \subsubsection{Serialisation} \subsubsection{Block Header Validity} -We define $P(B_{\mathrm{H}})$ to be the parent block of $B$, formally: +We define $P(B_{H})$ to be the parent block of $B$, formally: \begin{equation} -P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{\mathrm{H}})) = H_{\mathrm{p}} +P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = H_{\mathrm{p}} \end{equation} The block number is the parent's block number incremented by one: \begin{equation} -H_{\mathrm{i}} \equiv {{P(H)_{\mathrm{H}}}_{\mathrm{i}}} + 1 +H_{\mathrm{i}} \equiv {{P(H)_{H}}_{\mathrm{i}}} + 1 \end{equation} \newcommand{\mindifficulty}{D_0} @@ -477,7 +477,7 @@ \subsubsection{Block Header Validity} \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_{\mathrm{i}} = 0\\ -\text{max}\!\left(\mindifficulty, {P(H)_{\mathrm{H}}}_{\mathrm{d}} + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ +\text{max}\!\left(\mindifficulty, {P(H)_{H}}_{\mathrm{d}} + \diffadjustment\times\homesteadmod + \expdiffsymb \right) & \text{otherwise}\\ \end{dcases} \end{equation} where: @@ -485,10 +485,10 @@ \subsubsection{Block Header Validity} \mindifficulty \equiv 131072 \end{equation} \begin{equation} -\diffadjustment \equiv \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{d}}}{2048}\right\rfloor +\diffadjustment \equiv \left\lfloor\frac{{P(H)_{H}}_{\mathrm{d}}}{2048}\right\rfloor \end{equation} \begin{equation} -\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{\mathrm{H}}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) +\homesteadmod \equiv \text{max}\left( x - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{H}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) \end{equation} \begin{equation*} x \equiv \begin{cases} @@ -505,14 +505,14 @@ \subsubsection{Block Header Validity} The canonical gas limit $H_{\mathrm{l}}$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} -& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ -& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} < {P(H)_{H}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{H}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ & & H_{\mathrm{l}} \geqslant 5000 \end{eqnarray} $H_{\mathrm{s}}$ is the timestamp of block $H$ and must fulfil the relation: \begin{equation} -H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} +H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \end{equation} This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. @@ -532,11 +532,11 @@ \subsubsection{Block Header Validity} V(H) & \equiv & n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \wedge m = H_{\mathrm{m}} \quad \wedge \\ & & H_{\mathrm{d}} = D(H) \quad \wedge \\ & & H_{\mathrm{g}} \le H_{\mathrm{l}} \quad \wedge \\ -& & H_{\mathrm{l}} < {P(H)_{\mathrm{H}}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ -& & H_{\mathrm{l}} > {P(H)_{\mathrm{H}}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{\mathrm{H}}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} < {P(H)_{H}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ +& & H_{\mathrm{l}} > {P(H)_{H}}_{\mathrm{l}} - \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ & & H_{\mathrm{l}} \geqslant 5000 \quad \wedge \\ -& & H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}} \quad \wedge \\ -& & H_{\mathrm{i}} = {P(H)_{\mathrm{H}}}_{\mathrm{i}} +1 \quad \wedge \\ +& & H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \quad \wedge \\ +& & H_{\mathrm{i}} = {P(H)_{H}}_{\mathrm{i}} +1 \quad \wedge \\ & & \lVert H_{\mathrm{x}} \rVert \le 32 \end{eqnarray} where $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$ @@ -608,11 +608,11 @@ \subsection{Execution} T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ -T_{\mathrm{g}} & \leqslant & {B_{\mathrm{H}}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} +T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{\mathrm{H}}}_{\mathrm{l}}$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{gT}}_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. @@ -623,9 +623,9 @@ \subsection{Execution} \boldsymbol{\sigma}_0[S(T)]_{\mathrm{n}} & \equiv & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} + 1 \end{eqnarray} -Evaluating $\boldsymbol{\sigma}_{\mathrm{P}}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$, remaining gas $g'$, substate $A$ and status code $z$: +Evaluating $\boldsymbol{\sigma}_{P}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{P}$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} -(\boldsymbol{\sigma}_{\mathrm{P}}, g', A, z) \equiv \begin{cases} +(\boldsymbol{\sigma}_{P}, g', A, z) \equiv \begin{cases} \Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_\mathbf{i}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ \Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_\mathbf{d}, 0, \top) & \text{otherwise} \end{cases} @@ -646,12 +646,12 @@ \subsection{Execution} The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. -The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{\mathrm{P}}$: +The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{P}$: \begin{eqnarray} -\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_{\mathrm{P}} \quad \text{except} \\ -\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[S(T)]_{\mathrm{b}} + g^* T_{\mathrm{p}} \\ -\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{\mathrm{P}}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - g^*) T_{\mathrm{p}} \\ -m & \equiv & {B_{\mathrm{H}}}_{\mathrm{c}} +\boldsymbol{\sigma}^* & \equiv & \boldsymbol{\sigma}_{P} \quad \text{except} \\ +\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{P}[S(T)]_{\mathrm{b}} + g^* T_{\mathrm{p}} \\ +\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{P}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - g^*) T_{\mathrm{p}} \\ +m & \equiv & {B_{H}}_{\mathrm{c}} \end{eqnarray} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: @@ -727,7 +727,7 @@ \section{Contract Creation} \label{ch:create} I_{\mathrm{w}} & \equiv & w \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{\mathrm{H}}$ has no special treatment and is determined from the blockchain. +$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{H}$ has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, $\varnothing$, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. @@ -889,7 +889,7 @@ \subsection{Execution Environment} \item $I_{\mathrm{s}}$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. \item $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. \item $I_\mathbf{b}$, the byte array that is the machine code to be executed. -\item $I_{\mathrm{H}}$, the block header of the present block. +\item $I_{H}$, the block header of the present block. \item $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). \item $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} @@ -954,7 +954,7 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{} +\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{} \subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: @@ -989,15 +989,15 @@ \subsubsection{Jump Destination Validity} Formally: \begin{equation} -D(\mathbf{c}) \equiv D_{\mathrm{J}}(\mathbf{c}, 0) +D(\mathbf{c}) \equiv D_{J}(\mathbf{c}, 0) \end{equation} where: \begin{equation} -D_{\mathrm{J}}(\mathbf{c}, i) \equiv \begin{cases} +D_{J}(\mathbf{c}, i) \equiv \begin{cases} \{\} & \text{if} \quad i \geqslant |\mathbf{c}| \\ -\{ i \} \cup D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ -D_{\mathrm{J}}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ +\{ i \} \cup D_{J}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{if} \quad \mathbf{c}[i] = \text{\small JUMPDEST} \\ +D_{J}(\mathbf{c}, N(i, \mathbf{c}[i])) & \text{otherwise} \\ \end{cases} \end{equation} @@ -1060,7 +1060,7 @@ \section{Blocktree to Blockchain} \label{ch:ghost} Thus we define the total difficulty of block $B$ recursively as: \begin{eqnarray} B_{\mathrm{t}} & \equiv & B'_{\mathrm{t}} + B_{\mathrm{d}} \\ -B' & \equiv & P(B_{\mathrm{H}}) +B' & \equiv & P(B_{H}) \end{eqnarray} As such given a block $B$, $B_{\mathrm{t}}$ is its total difficulty, $B'$ is its parent block and $B_{\mathrm{d}}$ is its difficulty. @@ -1080,14 +1080,14 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_{\mathrm{H}})_{\mathrm{H}}, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{U \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_{H})_{H}, 6) \end{equation} where $k$ denotes the ``is-kin'' property: \begin{equation} k(U, H, n) \equiv \begin{cases} false & \text{if} \quad n = 0 \\ s(U, H) &\\ -\quad \vee \; k(U, P(H)_{\mathrm{H}}, n - 1) & \text{otherwise} +\quad \vee \; k(U, P(H)_{H}, n - 1) & \text{otherwise} \end{cases} \end{equation} @@ -1101,9 +1101,9 @@ \subsection{Transaction Validation} %where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_\mathbf{T}[i]$, and $g[i]$ the total gas used immediately after said transaction. -The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{\mathrm{H}}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: +The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{H}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_{\mathrm{H}}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} +{B_{H}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} \end{equation} \subsection{Reward Application} @@ -1112,14 +1112,14 @@ \subsection{Reward Application} \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{B_{\mathrm{H}}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ +\qquad\boldsymbol{\sigma}'[{B_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{B_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ \qquad\forall_{U \in B_\mathbf{U}}: \\ \nonumber \boldsymbol{\sigma}'[U_{\mathrm{c}}] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ \mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_\mathbf{s}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ -R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{\mathrm{H}}}_{\mathrm{i}})) R_{\mathrm{b}} +R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{b}} \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. @@ -1134,12 +1134,12 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} -\boldsymbol{\sigma}_0 & \text{if} \quad P(B_{\mathrm{H}}) = \varnothing \\ -\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{\mathrm{H}})_{\mathrm{H}}}_{\mathrm{r}} & \text{otherwise} +\boldsymbol{\sigma}_0 & \text{if} \quad P(B_{H}) = \varnothing \\ +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_{\mathrm{S}}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} @@ -1497,25 +1497,25 @@ \section{Precompiled Contracts}\label{app:precompiled} \begin{eqnarray} \Xi_{\mathtt{EXPMOD}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{except:} \\ -g_{\mathrm{r}} &=& \Big\lfloor\frac{f\big(\max(\ell_{\mathrm{M}},\ell_{\mathrm{B}})\big)\max(\ell'_{\mathrm{E}},1)}{G_{quaddivisor}}\Big\rfloor \\ +g_{\mathrm{r}} &=& \Big\lfloor\frac{f\big(\max(\ell_{M},\ell_{B})\big)\max(\ell'_{E},1)}{G_{quaddivisor}}\Big\rfloor \\ f(x) &\equiv& \begin{cases} x^2 & \text{if}\ x \le 64 \\ \Big\lfloor\dfrac{x^2}{4}\Big\rfloor + 96 x - 3072 & \text{if}\ 64 < x \le 1024 \\ \Big\lfloor\dfrac{x^2}{16}\Big\rfloor + 480x - 199680 & \text{otherwise} \end{cases}\\ -\ell'_{\mathrm{E}} &=& \begin{cases} -0 & \text{if}\ \ell_{\mathrm{E}}\le 32\wedge E=0 \\ -\lfloor \log_2(E)\rfloor &\text{if}\ \ell_{\mathrm{E}}\le 32 \wedge E \neq 0 \\ -8(\ell_{\mathrm{E}} - 32) + \lfloor \log_2(i[(96+\ell_{\mathrm{B}})..(127+\ell_{\mathrm{B}})]) \rfloor & \text{if}\ 32 < \ell_{\mathrm{E}} \wedge i[(96 + \ell_{\mathrm{B}})..(127 + \ell_{\mathrm{B}})]\neq 0 \\ -8(\ell_{\mathrm{E}} - 32) & \text{otherwise} \\ +\ell'_{E} &=& \begin{cases} +0 & \text{if}\ \ell_{E}\le 32\wedge E=0 \\ +\lfloor \log_2(E)\rfloor &\text{if}\ \ell_{E}\le 32 \wedge E \neq 0 \\ +8(\ell_{E} - 32) + \lfloor \log_2(i[(96+\ell_{B})..(127+\ell_{B})]) \rfloor & \text{if}\ 32 < \ell_{E} \wedge i[(96 + \ell_{B})..(127 + \ell_{B})]\neq 0 \\ +8(\ell_{E} - 32) & \text{otherwise} \\ \end{cases} \\ -\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_{\mathrm{M}}} \\ -\ell_{\mathrm{B}} &\equiv& i[0..31] \\ -\ell_{\mathrm{E}} &\equiv& i[32..63] \\ -\ell_{\mathrm{M}} &\equiv& i[64..95] \\ -B &\equiv& i[96..(95+\ell_{\mathrm{B}})] \\ -E &\equiv& i[(96+\ell_{\mathrm{B}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})] \\ -M &\equiv& i[(96+\ell_{\mathrm{B}}+\ell_{\mathrm{E}})..(95+\ell_{\mathrm{B}}+\ell_{\mathrm{E}}+\ell_{\mathrm{M}})] \\ +\mathbf o &=& (B^E\bmod M)\in\mathbb P_{8\ell_{M}} \\ +\ell_{B} &\equiv& i[0..31] \\ +\ell_{E} &\equiv& i[32..63] \\ +\ell_{M} &\equiv& i[64..95] \\ +B &\equiv& i[96..(95+\ell_{B})] \\ +E &\equiv& i[(96+\ell_{B})..(95+\ell_{B}+\ell_{E})] \\ +M &\equiv& i[(96+\ell_{B}+\ell_{E})..(95+\ell_{B}+\ell_{E}+\ell_{M})] \\ i[x] &\equiv& \begin{cases} I_{\mathbf d}[x] &\text{if}\ x < |I_{\mathbf d}| \\ 0 &\text{otherwise} @@ -1682,7 +1682,7 @@ \section{Signing Transactions}\label{app:signing} The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_{\mathrm{r}}$, $T_{\mathrm{s}}$ and $T_{\mathrm{w}}$. The other operates on nine elements: \begin{eqnarray} -L_{\mathrm{S}}(T) & \equiv & \begin{cases} +L_{S}(T) & \equiv & \begin{cases} (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}) & \text{if} \; v \in \{27, 28\} \\ (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, \mathtt{\tiny chain\_{\mathrm{id}}}, (), ()) & \text{otherwise} \\ \end{cases} \\ @@ -1691,7 +1691,7 @@ \section{Signing Transactions}\label{app:signing} T_{\mathbf{i}} & \text{if}\ T_{\mathrm{t}} = 0 \\ T_{\mathbf{d}} & \text{otherwise} \end{cases} \\ -h(T) & \equiv & \mathtt{\small KEC}( L_{\mathrm{S}}(T) ) +h(T) & \equiv & \mathtt{\small KEC}( L_{S}(T) ) \end{eqnarray} The signed transaction $G(T, p_{\mathrm{r}})$ is defined as: @@ -2044,19 +2044,19 @@ \subsection{Instruction Set} &&&& in the block following it. \\ \midrule 0x41 & {\small COINBASE} & 0 & 1 & Get the block's beneficiary address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{c}}$ \\ \midrule 0x42 & {\small TIMESTAMP} & 0 & 1 & Get the block's timestamp. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{s}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{s}}$ \\ \midrule 0x43 & {\small NUMBER} & 0 & 1 & Get the block's number. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{i}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{i}}$ \\ \midrule 0x44 & {\small DIFFICULTY} & 0 & 1 & Get the block's difficulty. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{d}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{d}}$ \\ \midrule 0x45 & {\small GASLIMIT} & 0 & 1 & Get the block's gas limit. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{l}}$ \\ +&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{l}}$ \\ \bottomrule \end{tabular*} @@ -2214,7 +2214,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting}\\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ @@ -2233,7 +2233,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{\mathrm{Z}}}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ @@ -2460,7 +2460,7 @@ \subsection{Proof-of-work function} The PoW-function returns an array with the compressed mix as its first item and the Keccak-256 hash of the concatenation of the compressed mix with the seed hash as the second item: \begin{equation} - \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) = \lbrace \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d}), \texttt{KEC}(\mathbf{s}_{\mathrm{h}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}) + \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{\mathrm{H}}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d})) \rbrace + \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d}) = \lbrace \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d}), \texttt{KEC}(\mathbf{s}_{\mathrm{h}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}(H_{\hcancel{n}}))), H_{\mathrm{n}}) + \mathbf{m}_{\mathrm{c}}(\mathtt{\small KEC}(\mathtt{\small RLP}(L_{H}(H_{\hcancel{n}}))), H_{\mathrm{n}}, \mathbf{d})) \rbrace \end{equation} With $H_{\hcancel{n}}$ being the hash of the header without the nonce. The compressed mix $\mathbf{m}_{\mathrm{c}}$ is obtained as follows: \begin{equation} From 34b641dfd0d7cacb28ea6592a4094458d81592ad Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 11:59:19 +1100 Subject: [PATCH 332/460] Remove mathrms where wrongly added --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e6147e9e..29280a2e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -832,8 +832,8 @@ \section{Message Call} \label{ch:call} \Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 3 \\ \Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 4 \\ \Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 5 \\ -\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ -\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 7 \\ \Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{if} \quad r = 8 \\ \Xi(\boldsymbol{\sigma}_1, g, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_{\mathrm{a}} & \equiv & r \\ From d0aed8e97132b66b8ccba5782bdf17fdcc2a0582 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:02:25 +1100 Subject: [PATCH 333/460] Remove wrong mathrms --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 29280a2e..99255a3e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1624,22 +1624,22 @@ \subsection{zkSNARK Related Precompiled Contracts} We define a precompiled contract for addition on $G_1$. \begin{eqnarray} -\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}&\equiv&\Xi_{\mathtt{BN\_{\mathrm{PRE}}}}\quad\text{except:}\\ -\Xi_{\mathtt{BN\_{\mathrm{ADD}}}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ +\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_{\mathrm{PRE}}}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ g_{\mathrm{r}} &=& 500\\ \mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ x&\equiv&\delta_1(\bar I_{\mathbf d}[0..63])\\ y&\equiv&\delta_1(\bar I_{\mathbf d}[64..127])\\ -\label{eq:complemented_{\mathrm{input}}}\bar I_{\mathbf d}[x]&\equiv&\begin{cases} +\label{eq:complemented_input}\bar I_{\mathbf d}[x]&\equiv&\begin{cases} I_{\mathbf d}[x]&\text{if}\ x < |I_{\mathbf d}|\\ 0&\text{otherwise} \end{cases} \end{eqnarray} -We define a precompiled contract for scalar multiplication on $G_1$, where $\bar I_{\mathbf d}$ is defined in (\ref{eq:complemented_{\mathrm{input}}}). +We define a precompiled contract for scalar multiplication on $G_1$, where $\bar I_{\mathbf d}$ is defined in (\ref{eq:complemented_input}). \begin{eqnarray} -\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ -\Xi_{\mathtt{BN\_{\mathrm{MUL}}}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ +\Xi_{\mathtt{BN\_MUL}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\\ g_{\mathrm{r}} &=& 40000\\ \mathbf o&\equiv&\delta_1^{-1}(n\cdot x)\quad\text{where $\cdot$ is the scalar multiplication in $G_1$}\\ n&\equiv&\bar I_{\mathbf d}[0..31]\\ From a3927b035fed0fcbfe2007d553ce207880b21538 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:05:10 +1100 Subject: [PATCH 334/460] Remove wrong mathrms --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 99255a3e..5e6db8fc 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1624,7 +1624,7 @@ \subsection{zkSNARK Related Precompiled Contracts} We define a precompiled contract for addition on $G_1$. \begin{eqnarray} -\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_{\mathrm{PRE}}}}\quad\text{except:}\\ +\Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ g_{\mathrm{r}} &=& 500\\ \mathbf o&\equiv&\delta_1^{-1}(x+y)\quad\text{where $+$ is the group operation in $G_1$}\\ From e91c99a92fd1647f4710aafe5caac9e70098c490 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:07:19 +1100 Subject: [PATCH 335/460] Remove wrong mathrms --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 5e6db8fc..d8036cba 100644 --- a/Paper.tex +++ b/Paper.tex @@ -954,7 +954,7 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{} +\hypertarget{Exceptional_Halting_function_Z}{} \subsubsection{Exceptional Halting} The exceptional halting function $Z$ is defined as: From c1788feb1e53ae4bc64b7dd25fce3edd5020f5b4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:13:31 +1100 Subject: [PATCH 336/460] Remove wrong mathrms --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index d8036cba..e45016f9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1394,10 +1394,10 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: \begin{eqnarray} y(\mathfrak{I}) & = & \{ (\mathbf{k}_0' \in \mathbb{Y}, \mathbf{v}_0 \in \mathbb{B}), (\mathbf{k}_1' \in \mathbb{Y}, \mathbf{v}_1 \in \mathbb{B}), ... \} \\ -\forall_{\mathrm{n}} \quad \forall_{i: i < 2\lVert\mathbf{k}_{\mathrm{n}}\rVert} \quad \mathbf{k}_{\mathrm{n}}'[i] & \equiv & +\forall_{n} \quad \forall_{i: i < 2\lVert\mathbf{k}_{n}\rVert} \quad \mathbf{k}_{n}'[i] & \equiv & \begin{cases} -\lfloor \mathbf{k}_{\mathrm{n}}[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ -\mathbf{k}_{\mathrm{n}}[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} +\lfloor \mathbf{k}_{n}[i \div 2] \div 16 \rfloor & \text{if} \; i \; \text{is even} \\ +\mathbf{k}_{n}[\lfloor i \div 2 \rfloor] \bmod 16 & \text{otherwise} \end{cases} \end{eqnarray} @@ -1426,7 +1426,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_{\mathrm{x}} : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_{x} : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{I \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} From 1fb8c89404d2474d0aae5e6535f0f790645e1a33 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:15:41 +1100 Subject: [PATCH 337/460] Remove wrong mathrms --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index e45016f9..47c75989 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2214,7 +2214,7 @@ \subsection{Instruction Set} &&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ &&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting}\\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ &&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ @@ -2233,7 +2233,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_{\mathrm{Halting}}_{\mathrm{function}}_{Z}}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}_{Z}}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ From db322787a19251ae2eb7e716a1a4848daae0f39c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:19:28 +1100 Subject: [PATCH 338/460] Add a missing forward slash --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 54766bda..4b7d658d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1075,7 +1075,7 @@ \subsection{Ommer Validation} The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{mathbf{U} \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) +\lVert B_\mathbf{U} \rVert \leqslant 2 \bigwedge_{\mathbf{U} \in B_\mathbf{U}} V(U) \; \wedge \; k(U, P(B_H)_H, 6) \end{equation} where $k$ denotes the ``is-kin'' property: From 42fede7810016cd13ecd548b3b32dc0ba6cea98b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:24:04 +1100 Subject: [PATCH 339/460] Add missing forward slashes before mathbfs --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4b7d658d..6ce11a88 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1108,7 +1108,7 @@ \subsection{Reward Application} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ \qquad\boldsymbol{\sigma}'[{B_H}_c]_b & = & \boldsymbol{\sigma}[{B_H}_c]_b + (1 + \frac{\lVert B_\mathbf{U}\rVert}{32})R_b \\ -\qquad\forall_{mathbf{U} \in B_\mathbf{U}}: \\ \nonumber +\qquad\forall_{\mathbf{U} \in B_{\mathbf{U}}}: \\ \nonumber \boldsymbol{\sigma}'[U_c] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[U_c] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} @@ -1383,7 +1383,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} When considering such a sequence, we use the common numeric subscript notation to refer to a tuple's key or value, thus: \begin{equation} -\forall_{mathbf{I} \in \mathfrak{I}} I \equiv (I_0, I_1) +\forall_{\mathbf{I} \in \mathfrak{I}} I \equiv (I_0, I_1) \end{equation} Any series of bytes may also trivially be viewed as a series of nibbles, given an endian-specific notation; here we assume big-endian. Thus: @@ -1421,7 +1421,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie} \begin{equation} c(\mathfrak{I}, i) \equiv \begin{cases} \texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (\lVert I_0\rVert - 1)], true), I_1 \big) \Big) & \text{if} \quad \lVert \mathfrak{I} \rVert = 1 \quad \text{where} \; \exists I: I \in \mathfrak{I} \\ -\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{mathbf{I} \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ +\texttt{\small RLP}\Big( \big(\texttt{\small HP}(I_0[i .. (j - 1)], false), n(\mathfrak{I}, j) \big) \Big) & \text{if} \quad i \ne j \quad \text{where} \; j = \arg \max_x : \exists \mathbf{l}: \lVert \mathbf{l} \rVert = x : \forall_{\mathbf{I} \in \mathfrak{I}}: I_0[0 .. (x - 1)] = \mathbf{l} \\ \texttt{\small RLP}\Big( (u(0), u(1), ..., u(15), v) \Big) & \text{otherwise} \quad \text{where} \begin{array}[t]{rcl} u(j) & \equiv & n(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} From 6643e712ad02c8993fa1d33b55d05d7aef01e72b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:30:58 +1100 Subject: [PATCH 340/460] Fix error from auto find and replace T_gT_p => T_{\mathrm{gT}}_{\mathrm{p}} => T_{\mathrm{g}}T_{\mathrm{p}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 47c75989..d6a5f1fb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -614,7 +614,7 @@ \subsection{Execution} Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. -The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{gT}}_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. +The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. We define the checkpoint state $\boldsymbol{\sigma}_0$: \begin{eqnarray} From fed5ae2db122bc90820622beeee7cec018fe0d06 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:45:51 +1100 Subject: [PATCH 341/460] Add \pagebreak[1]s --- Paper.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index d1fb126f..86c510c0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -709,9 +709,7 @@ \section{Contract Creation} \label{ch:create} \begin{equation} (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} - -where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is: - +\pagebreak[1]where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is:\pagebreak[1] \begin{eqnarray} I_a & \equiv & a \\ I_o & \equiv & o \\ From 8544de0a034d09adf2ab5cfe00829638573c5580 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 12:49:02 +1100 Subject: [PATCH 342/460] Fix an error with \hyperlink{Exceptional_Halting_function_Z} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index d6a5f1fb..6506e354 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2233,7 +2233,7 @@ \subsection{Instruction Set} &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ -&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}_{Z}}{exceptional halting} \\ +&&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ &&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ From d7cda8fe54777214454dbc9f3666135b61281122 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 14:31:25 +1100 Subject: [PATCH 343/460] hypertarget: move to the same line as the targeted text, change to linkdest where not in text mode --- Paper.tex | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Paper.tex b/Paper.tex index 1afc5478..e960ebb9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2308,7 +2308,7 @@ \subsection{Instruction Set} %\section{Low-level Lisp-like Language}\label{app:lll} %The Low-level Lisp-like Language is a language created in order to efficiently author low-level programs (contracts) without having to resort to EVM-Assembly. -\hypertarget{GenesisBlock}{} + \section{Genesis Block}\label{app:genesis} The genesis block is 15 items, and is specified thus: @@ -2328,17 +2328,17 @@ \subsection{Definitions} \toprule Name & Value & Description \\ \midrule -$J_{wordbytes}$ & 4 & Bytes in word. \hypertarget{Jdatasetinit}{}\\ -$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \hypertarget{Jdatasetgrowth}{}\\ -$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \hypertarget{Jcacheinit}{}\\ -$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \hypertarget{Jcachegrowth}{}\\ -$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \hypertarget{Jepoch}{}\\ -$J_{epoch}$ & 30000 & Blocks per epoch. \hypertarget{Jmixbytes}{}\\ -$J_{mixbytes}$ & 128 & mix length in bytes. \hypertarget{Jhashbytes}{}\\ -$J_{hashbytes}$ & 64 & Hash length in bytes. \hypertarget{Jparents}{}\\ -$J_{parents}$ & 256 & Number of parents of each dataset element. \\hypertarget{Jcacherounds}{}\ -$J_{cacherounds}$ & 3 & Number of rounds in cache production. \hypertarget{Jaccesses}{}\\ -$J_{accesses}$ & 64 & Number of accesses in hashimoto loop. \\ +$J_{wordbytes}$ & 4 & Bytes in word. \\ +\linkdest{J__datasetinit}{}$J_{datasetinit}$ & $2^{30}$ & Bytes in dataset at genesis. \\ +\linkdest{J__datasetgrowth}{}$J_{datasetgrowth}$ & $2^{23}$ & Dataset growth per epoch. \\ +\linkdest{J__cacheinit}{}$J_{cacheinit}$ & $2^{24}$ & Bytes in cache at genesis. \\ +\linkdest{J__cachegrowth}{}$J_{cachegrowth}$ & $2^{17}$ & Cache growth per epoch. \\ +\linkdest{J__epoch}{}$J_{epoch}$ & 30000 & Blocks per epoch. \\ +\linkdest{J__mixbytes}{}$J_{mixbytes}$ & 128 & mix length in bytes. \\ +\linkdest{J__hashbytes}{}$J_{hashbytes}$ & 64 & Hash length in bytes. \\ +\linkdest{J__parents}{}$J_{parents}$ & 256 & Number of parents of each dataset element. \\ +\linkdest{J__cacherounds}{}$J_{cacherounds}$ & 3 & Number of rounds in cache production. \\ +\linkdest{J__accesses}{}$J_{accesses}$ & 64 & Number of accesses in hashimoto loop. \\ \bottomrule \end{tabular*} @@ -2347,8 +2347,8 @@ \subsection{Size of dataset and cache} \begin{equation} E_{epoch}(H_i) = \left\lfloor\frac{H_i}{J_{epoch}}\right\rfloor \end{equation} -The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache.\hypertarget{dsize}{} -Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using +The size of the dataset growth by $J_{datasetgrowth}$ bytes, and the size of the cache by $J_{cachegrowth}$ bytes, every epoch. In order to avoid regularity leading to cyclic behavior, the size must be a prime number. Therefore the size is reduced by a multiple of $J_{mixbytes}$, for the dataset, and $J_{hashbytes}$ for the cache. +\linkdest{d__size}{}Let $d_{size} = \lVert \mathbf{d} \rVert$ be the size of the dataset. Which is calculated using \begin{equation} d_{size} = E_{prime}(J_{datasetinit} + J_{datasetgrowth} \cdot E_{epoch} - J_{mixbytes}, J_{mixbytes}) \end{equation} @@ -2407,7 +2407,7 @@ \subsubsection{Cache} \end{equation} Where a single round modifies each subset of the cache as follows: \begin{equation} - E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big)\hypertarget{Ecacherounds}{} + E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, n - 1) \big)\linkdest{E__cacherounds}{} \end{equation} \begin{multline} E_{rmh}(\mathbf{x}, i) = \texttt{KEC512}(\mathbf{x'}[(i - 1 + n) \mod n] \oplus \mathbf{x'}[\mathbf{x'}[i][0] \mod n]) \\ From 5e4e44eef9f0df6c623f201fc98543e5711a6668 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:50:32 +1100 Subject: [PATCH 344/460] \hypertarget{R l}{}Thus --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 881057e5..f13b678b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1327,8 +1327,8 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} -\hypertarget{R l}{} -Thus we finish by formally defining $R_l$: + +\hypertarget{R l}{}Thus we finish by formally defining $R_l$: \begin{eqnarray} R_l(\mathbf{x}) & \equiv & \begin{cases} (192 + \lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{if} \quad \lVert s(\mathbf{x}) \rVert < 56 \\ From 7479ba0e0c920343153ca84d8d11e554a122c621 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:52:50 +1100 Subject: [PATCH 345/460] Move \linkdest{Transaction Receipt}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 319916c7..704255b1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -345,9 +345,9 @@ \subsection{The Block} \label{ch:block} \linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} B \equiv (B_H, B_\mathbf{T}, B_\mathbf{U}) -\end{equation}\linkdest{Transaction Receipt}{} +\end{equation} -\subsubsection{Transaction Receipt} +\subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. From 26e25ec425864e91112088c9530a7cf8bfcd0ab7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:54:32 +1100 Subject: [PATCH 346/460] Readd JUMPI --- Paper.tex | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index d5dc4aa0..bb1d1ba4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -951,8 +951,7 @@ \subsubsection{Exceptional Halting} \boldsymbol{\mu}_g < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ \mathbf{\delta}_w = \varnothing \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_w \quad \vee \\ -( w \in \{ \text{\small JUMP}, \text{\small -} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ +( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ ( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_w + \mathbf{\alpha}_w > 1024 \quad \vee \\ \neg I_w \wedge W(w, \boldsymbol{\mu}) From 2ba7911e566dd7ebdbafd56ab0e861700ff6a2d8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 21:56:45 +1100 Subject: [PATCH 347/460] Make empty second argument \linkdest{blockhash}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 8e787a75..05cd35f9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2019,7 +2019,7 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ -\linkdest{blockhash}{BLOCKHASH}0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ +\linkdest{blockhash}{}0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{H_p}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ From b59d31cf3fbb218b1d583feb7b57866fc2fc064a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 30 Jan 2018 22:03:09 +1100 Subject: [PATCH 348/460] Append {} after \linkdest{JUMP}, remove JUMP in second braces --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index bb1d1ba4..31078fc4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2082,11 +2082,11 @@ \subsection{Instruction Set} 0 & \text{otherwise} \end{cases}$ \\ \midrule -\linkdest{JUMP}{JUMP}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ +\linkdest{JUMP}{}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ &&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}.\\ \midrule -\linkdest{JUMPI}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ +\linkdest{JUMPI}{}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ &&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ \midrule From ea581e5cf60f082ab5a244003fcbb9586e86ff2e Mon Sep 17 00:00:00 2001 From: Ben Edgington Date: Wed, 31 Jan 2018 10:45:21 +0000 Subject: [PATCH 349/460] Minor corrections and revisions to transaction receipt section --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index f9111885..c80c3e9d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -350,10 +350,10 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} -In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. +In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_e$. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_u$, the set of logs created through execution of the transaction, $R_\mathbf{l}$, the Bloom filter composed from information in those logs, $R_b$ and the status code of the transaction, $R_z$: \begin{equation} R \equiv (R_z, R_u, R_b, R_\mathbf{l}) @@ -377,7 +377,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} %Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_B$; it is merely a convenience equivalence. -The log entries, $R_\mathbf{l}$, is a series of log entries, termed, for example, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of a logger's address, $O_a$, a series of 32-bytes log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} O \equiv (O_a, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} @@ -390,7 +390,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} M(O) \equiv \bigvee_{t \in \{O_a\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) \end{equation} -where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence./footnote{11 bits $= 2^2048$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: +where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence.\footnote{11 bits $= 2^{2048}$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: \begin{eqnarray} M_{3:2048}(\mathbf{x}: \mathbf{x} \in \mathbb{B}) & \equiv & \mathbf{y}: \mathbf{y} \in \mathbb{B}_{256} \quad \text{where:}\\ \mathbf{y} & = & (0, 0, ..., 0) \quad \text{except:}\\ From 31a82fd597aa8f10a3317b2b96dbe0f9bd5163e3 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Wed, 31 Jan 2018 15:56:58 +0100 Subject: [PATCH 350/460] Fix the calculation of cache size in ethash See https://github.com/ethereum/yellowpaper/issues/517 This has to be ported to all protocol versions. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..d9b66c51 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2373,7 +2373,7 @@ \subsection{Size of dataset and cache} \begin{equation} E_{prime}(x, y) = \begin{cases} x & \text{if} \quad x / y \in \mathbb{P} \\ -E_{prime}((x - 1) \cdot y, y) & \text{otherwise} +E_{prime}(x - 2 \cdot y, y) & \text{otherwise} \end{cases} \end{equation} \subsection{Dataset generation} From 484037ab15aed6f258ac5293edb60399544e5e2d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:27:31 +1100 Subject: [PATCH 351/460] Remove {} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 60c5d0dd..854ad06e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -258,7 +258,7 @@ \subsection{The Transaction} \label{ch:transaction} \item[nonce]\linkdest{tx_nonce}{} A scalar value equal to the number of transactions sent by the sender; formally $T_n$. \item[gasPrice]\linkdest{tx_gas_price_T__p}{} A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_p$. \item[gasLimit]\linkdest{tx_gas_limit_T__g}{} A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_g$. -\item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$.{} +\item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_t$. \item[value]\linkdest{tx_value_T__v} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_v$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_w$, $T_r$ and $T_s$. This is expanded in Appendix \ref{app:signing}. \end{description} From e4c336fc8514798254eccb97079c1dea8cea5efc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:35:31 +1100 Subject: [PATCH 352/460] \linkdest{block_validity}{}, \linkdest{new_state_H__r}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7547d96e..0aa8ae15 100644 --- a/Paper.tex +++ b/Paper.tex @@ -387,10 +387,10 @@ \subsubsection{Transaction Receipt} \subsubsection{Holistic Validity} -We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: +\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_r$: \begin{equation} \begin{array}[t]{lclc} -\linkdest{block_validity_H__r}{}H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ +\linkdest{new_state_H__r}{}H_r &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ \linkdest{Ommer_block_hash_H__o}{}H_o &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ \linkdest{tx_block_hash_H__t}{}H_t &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_T(B_\mathbf{T}[i]))\}) & \wedge \\ \linkdest{Receipts_Root_H__e}{}H_e &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_R(B_\mathbf{R}[i]))\}) & \wedge \\ From 43433329639a885caf8f8298e30534ff1a3b29ea Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:36:23 +1100 Subject: [PATCH 353/460] \hypertarget{Omega}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1d4bf056..77c6e77c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1093,7 +1093,7 @@ \subsection{Transaction Validation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{Omega} Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_b$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{} Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ From 980698244169d834cdfbea82da6de9def6cf893c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:37:12 +1100 Subject: [PATCH 354/460] \hypertarget{block_reward_R__b}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 77c6e77c..36305e23 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1109,7 +1109,7 @@ \subsection{Reward Application} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -\hypertarget{block-reward-R-b}{block-reward-R-b}We define the block reward as 3 Ether: +\hypertarget{block_reward_R__b}{}We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_b = 3 \times 10^{18} \end{equation} From af8f9556591d018b0999c77abf1566da6b9a23f3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:37:41 +1100 Subject: [PATCH 355/460] \hypertarget{Gamma}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 36305e23..620a36e7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1116,7 +1116,7 @@ \subsection{Reward Application} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} -\hypertarget{Gamma}{Gamma}We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: +\hypertarget{Gamma}{}We may now define the function, $\Gamma$, that maps a block $B$ to its initiation state: \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_H) = \varnothing \\ From 5b8491164b7151a539844b5eb9ba3100ea5d2b00 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:38:07 +1100 Subject: [PATCH 356/460] \hypertarget{Phi}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 620a36e7..beca185e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1126,7 +1126,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} Here, $\mathtt{\small TRIE}(L_S(\boldsymbol{\sigma}_i))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_i$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. -\hypertarget{Phi}{Phi}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: +\hypertarget{Phi}{}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ B'_n & = & n: \quad x \leqslant \frac{2^{256}}{H_d} \\ From c829b7068f1e9270f4492c9a6c210b80879c2e5f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:38:43 +1100 Subject: [PATCH 357/460] \hypertarget{Pi}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index beca185e..b2fd9d39 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1163,7 +1163,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \Upsilon^{s}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} -\hypertarget{Pi}{Pi}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: +\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: \begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} From ef88bef17720a5653bc54ce940eb7a78399a1274 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:43:01 +1100 Subject: [PATCH 358/460] Move \hypertarget{h T}{} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 687d7928..af5ca0d6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1664,8 +1664,8 @@ \section{Signing Transactions}\label{app:signing} \begin{equation} A(p_r) = \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSAPUBKEY}(p_r) \big) \big) \end{equation} -\hypertarget{h T}{} -The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: + +\hypertarget{h T}{}The message hash, $h(T)$, to be signed is the Keccak hash of the transaction. Two different flavors of signing schemes are available. One operates without the latter three signature components, formally described as $T_r$, $T_s$ and $T_w$. The other operates on nine elements: \begin{eqnarray} L_S(T) & \equiv & \begin{cases} (T_n, T_p, T_g, T_t, T_v, \mathbf{p}) & \text{if} \; v \in \{27, 28\} \\ From eb1caa6245a90cf5e5f8f3c388c131419a1c80e4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 10:47:07 +1100 Subject: [PATCH 359/460] _{\mathrm{t}} => _{t} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 6506e354..a22e18fe 100644 --- a/Paper.tex +++ b/Paper.tex @@ -116,7 +116,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{\mathrm{t}}, T) +\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -127,7 +127,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Formally, we expand to: \begin{eqnarray} -\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{\mathrm{t}}, B) \\ +\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{t}, B) \\ B & \equiv & (..., (T_0, T_1, ...) ) \\ \Pi(\boldsymbol{\sigma}, B) & \equiv & \Omega(B, \Upsilon(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \end{eqnarray} From fc898b15d057ede739b499688141d07e22072e87 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:30:12 +1100 Subject: [PATCH 360/460] Fix in-text citations: *by* \cite{EIP-#} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..32ecf35b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -502,7 +502,7 @@ \subsubsection{Block Header Validity} H'_i &\equiv \max(H_i - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 \cite{EIP-649} and delayed and implemented earlier in EIP-2 \cite{EIP-2}. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 by \cite{EIP-649} and delayed and implemented earlier in EIP-2. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks by \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_i$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. \hypertarget{block_gas_limit_H__l}{}The canonical gas limit $H_l$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} From 89ac1de111256ca5eef0036ed02266803528bff2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:32:53 +1100 Subject: [PATCH 361/460] Add parentheses around \cite{Davey2002_zbMATH01748069} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 32ecf35b..4447b9c6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2517,7 +2517,7 @@ \section{List of mathematical symbols}\label{app:symbols} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule -$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements \cite{Davey2002_zbMATH01748069}.\\ +$\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabu*} From a691d3d98699d8917d1d3329d110e6853a6711b6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:34:17 +1100 Subject: [PATCH 362/460] Remove \\ in 0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..303ce71d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,7 +2510,7 @@ \section{Anomalies on the Main Network} \subsection{Deletion of an Account Despite Out-of-gas} -At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e\\4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. \section{List of mathematical symbols}\label{app:symbols} \begin{tabu*}{X[l]X[c]X} \savetabu{col3} From fc55da93472df833e378d26fe353ff67b0c58779 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:43:09 +1100 Subject: [PATCH 363/460] Move \hypertarget{Exceptional_Halting_function_Z}{} The column actually broke on the preceding line, causing hyperlinks to direct to the bottom of the column. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index c80c3e9d..296cdec9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -955,8 +955,8 @@ \subsubsection{Machine State} \end{equation} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\hypertarget{Exceptional_Halting_function_Z}{} -\subsubsection{Exceptional Halting} + +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} The exceptional halting function $Z$ is defined as: \begin{equation} From 3e5726002e2d624a12d73dd0c5544414efcea644 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:51:50 +1100 Subject: [PATCH 364/460] Move hypertargets to the same line as section headings, and rename some targets --- Paper.tex | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/Paper.tex b/Paper.tex index 296cdec9..71c48b5e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1298,8 +1298,8 @@ \section{Terminology} \label{ch:Terminology} \item[LLL] The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to. \end{description} -\hypertarget{rlp}{} -\section{Recursive Length Prefix}\label{app:rlp} + +\section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} This is a serialisation method for encoding arbitrarily structured binary data (byte arrays). We define the set of possible structures $\mathbb{T}$: @@ -1323,8 +1323,8 @@ \section{Recursive Length Prefix}\label{app:rlp} \item If the byte-array contains fewer than 56 bytes, then the output is equal to the input prefixed by the byte equal to the length of the byte array plus 128. \item Otherwise, the output is equal to the input prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the input byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 183. \end{itemize} -\hypertarget{R b}{} -Formally, we define $R_b$: + +\hypertarget{RLP_serialisation_of_a_byte_array_R__b_math_def}{}Formally, we define $R_b$: \begin{eqnarray} R_b(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ @@ -1344,7 +1344,7 @@ \section{Recursive Length Prefix}\label{app:rlp} \item Otherwise, the output is equal to the concatenated serialisations prefixed by the minimal-length byte-array which when interpreted as a big-endian integer is equal to the length of the concatenated serialisations byte array, which is itself prefixed by the number of bytes required to faithfully encode this length value plus 247. \end{itemize} -\hypertarget{R l}{}Thus we finish by formally defining $R_l$: +\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{}Thus we finish by formally defining $R_l$: \begin{eqnarray} R_l(\mathbf{x}) & \equiv & \begin{cases} (192 + \lVert s(\mathbf{x}) \rVert) \cdot s(\mathbf{x}) & \text{if} \quad \lVert s(\mathbf{x}) \rVert < 56 \\ @@ -1378,8 +1378,8 @@ \section{Hex-Prefix Encoding}\label{app:hexprefix} \end{eqnarray} Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the second-lowest encoding the flag $t$. The low nibble of the first byte is zero in the case of an even number of nibbles and the first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining bytes. -\hypertarget{trie}{} -\section{Modified Merkle Patricia Tree}\label{app:trie} + +\section{Modified Merkle Patricia Tree}\label{app:trie}\hypertarget{trie}{} The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32 byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. Formally, we assume the input value $\mathfrak{I}$, a set containing pairs of byte sequences: @@ -2322,8 +2322,7 @@ \subsection{Instruction Set} \bottomrule \end{tabular*} -\hypertarget{GenesisBlock}{} -\section{Genesis Block}\label{app:genesis} +\section{Genesis Block}\label{app:genesis}\hypertarget{GenesisBlock}{} The genesis block is 15 items, and is specified thus: \begin{equation} From e6eb7a94bc4cd63e5bcc4b6b1250f8874bf05f7a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 11:56:29 +1100 Subject: [PATCH 365/460] Add RLP R_b and R_l word defs. --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 71c48b5e..9914e2a7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1316,7 +1316,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_b(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_l(\mathbf{x}) & \text{otherwise} \end{cases} \end{equation} -If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: +\hypertarget{RLP_serialisation_of_a_byte_array_R__b_word_def}{}If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: \begin{itemize} \item If the byte-array contains solely a single byte and that single byte is less than 128, then the input is exactly equal to the output. @@ -1337,7 +1337,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} Thus $\mathtt{\tiny BE}$ is the function that expands a positive integer value to a big-endian byte array of minimal length and the dot operator performs sequence concatenation. -If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: +\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_word_def}{}If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: \begin{itemize} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. From 123f30b6ef19884fd8ee8d43efe91a93ce781bcf Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 2 Feb 2018 12:03:08 +1100 Subject: [PATCH 366/460] Remove duplicate hypertargets --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index c4191150..d49d5c80 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1687,13 +1687,13 @@ \section{Signing Transactions}\label{app:signing} %Uncomment out after merging \hypertargets for v, r, and s. %Thus: -%\begin{eqnarray}\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} +%\begin{eqnarray}\hypertarget{T__w}{}\hypertarget{T__r}{}\hypertarget{T__s}{} %T_{\mathrm{w}} = \hyperlink{v}{v}\\ %T_{\mathrm{r}} = \hyperlink{r}{r}\\ %T_{\mathrm{s}} = \hyperlink{s}{s} %\end{eqnarray} -We may then define the sender function $S$ of the transaction as:\hypertarget{T w}{}\hypertarget{T r}{}\hypertarget{T s}{} +We may then define the sender function $S$ of the transaction as: \begin{eqnarray} S(T) &\equiv& \mathcal{B}_{96..255}\big(\mathtt{\tiny KEC}\big( \mathtt{\small ECDSARECOVER}(h(T), v_0, T_r, T_s) \big) \big) \\ v_0 &\equiv& \begin{cases} From 9f585d45c52adb5d761d147ceb1c5c6597f51efb Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Feb 2018 14:38:14 +0100 Subject: [PATCH 367/460] Final touches See PR https://github.com/ethereum/yellowpaper/pull/515 --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 389fca61..11f7876e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -210,7 +210,7 @@ \subsection{World State} \label{ch:state} The account state comprises the following four fields: \begin{description} -\item[nonce] \linkdest{account_{\mathrm{nonce}}}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{n}}$. +\item[nonce] \linkdest{account_nonce}A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account. For account of address $a$ in state $\boldsymbol{\sigma}$, this would be formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{n}}$. \item[balance] A scalar value equal to the number of Wei owned by this address. Formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{b}}$. \item[storageRoot] A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. The hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{s}}$. \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{c}}$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_{\mathrm{c}}$. @@ -327,8 +327,8 @@ \subsection{The Block} \label{ch:block} \begin{description} \item[parentHash]\linkdest{parent_Hash_H__p_def_words}{} The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_{\mathrm{p}}$. -\item[ommersHash]\linkdest{beneficiary_H__c}{} The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. -\item[beneficiary] The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. +\item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. +\item[beneficiary]\linkdest{beneficiary_H__c}{} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_{\mathrm{r}}$. \item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_{\mathrm{t}}$. \item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. From ee76f605c2a91a532b0a85c0e800e14a1f646795 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 2 Feb 2018 15:19:15 +0100 Subject: [PATCH 368/460] Add a missing {} as the second argument of \linkdest --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 725993ef..6a171af5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -273,7 +273,7 @@ \subsection{The Transaction} \label{ch:transaction} \item[gasPrice]\linkdest{tx_gas_price_T__p}{} A scalar value equal to the number of Wei to be paid per unit of \textit{gas} for all computation costs incurred as a result of the execution of this transaction; formally $T_{\mathrm{p}}$. \item[gasLimit]\linkdest{tx_gas_limit_T__g}{} A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. \item[to]\linkdest{tx_to_address_T__t}{} The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. -\item[value]\linkdest{tx_value_T__v} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. +\item[value]\linkdest{tx_value_T__v}{} A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. \item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$. This is expanded in Appendix \ref{app:signing}. \end{description} From 21520d5f465b9072691be6fa605d770855ce56b7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 09:54:33 +1100 Subject: [PATCH 369/460] 2 \hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{f^*} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..e4cb9263 100644 --- a/Paper.tex +++ b/Paper.tex @@ -191,7 +191,7 @@ \section{Conventions}\label{ch:conventions} When considering variants of existing values, I follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, I may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. -When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. +When considering the use of existing functions, given a function $f$, the function \hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{$f^*$} denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: @@ -435,7 +435,7 @@ \subsubsection{Serialisation} \hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: \begin{equation} -f^*\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f +\hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{f^*}\big( (x_0, x_1, ...) \big) \equiv \big( f(x_0), f(x_1), ... \big) \quad \text{for any function} \; f \end{equation} The component types are defined thus: From ee0e997612ff07507c6be58c59cc11f628bd09b4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:03:27 +1100 Subject: [PATCH 370/460] \linkdest{r}{r} \linkdest{s}{s} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..62546b8f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1665,8 +1665,8 @@ \section{Signing Transactions}\label{app:signing} We declare that a signature is invalid unless all the following conditions are true: \begin{align} -0 < r &< \mathtt{\tiny secp256k1n} \\ -0 < s &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ +0 < \linkdest{r}{r} &< \mathtt{\tiny secp256k1n} \\ +0 < \linkdest{s}{s} &< \mathtt{\tiny secp256k1n} \div 2 + 1 \\ v &\in \{27,28,\mathtt{\tiny chain\_{\mathrm{id}}} \times 2 + 35, \mathtt{\tiny chain\_{\mathrm{id}}} \times 2 + 36\} \end{align} where: From b2e6381e254a05753926ef9aeb046b6cf03bc7f5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:12:41 +1100 Subject: [PATCH 371/460] \hypertarget{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..77aaf0a3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -264,7 +264,7 @@ \subsection{World State} \label{ch:state} \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \end{equation} -\subsection{The Transaction} \label{ch:transaction} +\subsection{The Transaction} \label{subsec:transaction} A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: @@ -274,7 +274,7 @@ \subsection{The Transaction} \label{ch:transaction} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. \item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. -\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally $T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$. This is expanded in Appendix \ref{app:signing}. +\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally \hypertarget{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$}. This is expanded in Appendix \ref{app:signing}. \end{description} Additionally, a contract creation transaction contains: From 51ad91d3444d54199982f157be1f7f2794a01b8d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:18:47 +1100 Subject: [PATCH 372/460] hypertarget => linkdest I tested the former and it direct to the next line. Thus linkdest must be used whenever it encapsulates math mode, or any part, or is included in it. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 77aaf0a3..3f000832 100644 --- a/Paper.tex +++ b/Paper.tex @@ -274,7 +274,7 @@ \subsection{The Transaction} \label{subsec:transaction} \item[gasLimit] A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; formally $T_{\mathrm{g}}$. \item[to] The 160-bit address of the message call's recipient or, for a contract creation transaction, $\varnothing$, used here to denote the only member of $\mathbb{B}_0$ ; formally $T_{\mathrm{t}}$. \item[value] A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; formally $T_{\mathrm{v}}$. -\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally \hypertarget{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$}. This is expanded in Appendix \ref{app:signing}. +\item[v, r, s] Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally \linkdest{T__w_T__r_T__s}{$T_{\mathrm{w}}$, $T_{\mathrm{r}}$ and $T_{\mathrm{s}}$}. This is expanded in Appendix \ref{app:signing}. \end{description} Additionally, a contract creation transaction contains: From b4355f4a267025a1d02ccefe11feec6f2db8aef3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:21:20 +1100 Subject: [PATCH 373/460] Thus => Reiterating from \hyperlink{T__w_T__r_T__s}{previously} --- Paper.tex | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index d49d5c80..4f1d9d97 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1685,13 +1685,12 @@ \section{Signing Transactions}\label{app:signing} (T_w, T_r, T_s) = \mathtt{\small ECDSASIGN}(h(T), p_r) \end{eqnarray} -%Uncomment out after merging \hypertargets for v, r, and s. -%Thus: -%\begin{eqnarray}\hypertarget{T__w}{}\hypertarget{T__r}{}\hypertarget{T__s}{} -%T_{\mathrm{w}} = \hyperlink{v}{v}\\ -%T_{\mathrm{r}} = \hyperlink{r}{r}\\ -%T_{\mathrm{s}} = \hyperlink{s}{s} -%\end{eqnarray} +Reiterating from \hyperlink{T__w_T__r_T__s}{previously}: +\begin{eqnarray} +\linkdest{T__w}{T_{\mathrm{w}}} = \hyperlink{v}{v}\\ +\linkdest{T__r}{T_{\mathrm{r}} = \hyperlink{r}{r}\\ +\linkdest{T__s}{T_{\mathrm{s}} = \hyperlink{s}{s} +\end{eqnarray} We may then define the sender function $S$ of the transaction as: \begin{eqnarray} From a63aad7a91e1ab4eddcc801483a9ed84edb51e9f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:32:37 +1100 Subject: [PATCH 374/460] \hyperlink{trie}{trie} & \hyperlink{Receipts_Root_H__e}{$H_{\mathrm{e}}$} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..a075e2ce 100644 --- a/Paper.tex +++ b/Paper.tex @@ -351,7 +351,7 @@ \subsection{The Block} \label{ch:block} \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. +Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed \hyperlink{trie}{trie} and the root recorded in the header as \hyperlink{Receipts_Root_H__e}{$H_{\mathrm{e}}$}. \linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} From 5ce6bcadcdf6fad9f5787abd226347f69d51c52d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 10:38:47 +1100 Subject: [PATCH 375/460] Ommer footnote, link words to maths. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..b6b5f8f6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -321,7 +321,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (which is not saying much, in that it isn't commonly used) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} @@ -343,12 +343,12 @@ \subsection{The Block} \label{ch:block} \item[nonce]\linkdest{block_nonce_H__n}{} A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{n}}$. \end{description} -\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: +\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above), $B_{\mathbf{U}}$ and a series of the transactions, $B_{\mathbf{T}}$. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}}) \end{equation} -\subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} +\subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. From c6308591e91cb870b845ab8641652d6ace58386b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:13:09 +1100 Subject: [PATCH 376/460] Transaction receipt changes \Upsilon^z => \Upsilon{\mathrm{z}}, \Upsilon^g => \Upsilon{\mathrm{g}} \linkdest{Transaction_Receipt}{} \hyperlink{Transaction_Receipt}{transaction receipt} Other targets for parameters --- Paper.tex | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..30b046d3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -348,12 +348,12 @@ \subsection{The Block} \label{ch:block} B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) \end{equation} -\subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} +\subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt, $R$, is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, \hyperlink{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{$R_\mathbf{l}$} and the Bloom filter composed from information in those logs, \hyperlink{RLP_serialisation_of_a_byte_array_R__b_math_def}{$R_{\mathrm{b}}$} and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) \end{equation} @@ -376,7 +376,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} %Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. -The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_{\mathbf{l}}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_{\mathbf{t}}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} @@ -570,7 +570,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^g$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^\mathbf{l}$ to evaluate to the transaction's accrued log items and $\Upsilon^z$ to evaluate to the status code resulting from the transaction. These will be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^{\mathrm{g}}$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^{\mathbf{l}}$ to evaluate to the transaction's accrued log items and $\Upsilon^{\mathrm{z}}$ to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: @@ -661,14 +661,14 @@ \subsection{Execution} \linkdest{touched_A__t}{}\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{}And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_z}{}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: \begin{eqnarray} -\Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ +\Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ -\Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z +\Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} -These are used to help define the transaction receipt, discussed later. +These are used to help define the \hyperlink{Transaction_Receipt}{transaction receipt}. \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} @@ -1161,7 +1161,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \begin{equation} \mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} +\Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} @@ -1169,13 +1169,13 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} For $\mathbf{R}[n]_\mathbf{l}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. \begin{equation} \mathbf{R}[n]_\mathbf{l} = -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^{\mathbf{l}}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{\mathrm{z}} = -\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) \end{equation} \hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: From c6cd9a555af0cc96231f1e51b7e4114a41d9db6e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:14:43 +1100 Subject: [PATCH 377/460] Remove braces around \mathbf --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 30b046d3..676cf6a8 100644 --- a/Paper.tex +++ b/Paper.tex @@ -376,7 +376,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} %Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. -The sequence $R_{\mathbf{l}}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_{\mathbf{t}}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: \begin{equation} O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) \end{equation} From 1566aa7911fe76cd6290dbf44ba1ac463d8c9e87 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:20:00 +1100 Subject: [PATCH 378/460] Replace _(\\mathbf\{[:alnum:]+\}) with _{$1} ...using Libre Open Office with regular expressions ticked as an option. --- Paper.tex | 442 +++++++++++++++++++++++++++--------------------------- 1 file changed, 221 insertions(+), 221 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..df23849d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -185,7 +185,7 @@ \section{Conventions}\label{ch:conventions} Throughout, we assume scalars are positive integers and thus belong to the set $\mathbb{P}$. The set of all byte sequences is $\mathbb{B}$, formally defined in Appendix \ref{app:rlp}. If such a set of sequences is restricted to those of a particular length, it is denoted with a subscript, thus the set of all byte sequences of length $32$ is named $\mathbb{B}_{32}$ and the set of all positive integers smaller than $2^{256}$ is named $\mathbb{P}_{256}$. This is formally defined in section \ref{ch:block}. -Square brackets are used to index into and reference individual components or subsequences of sequences, \eg $\boldsymbol{\mu}_\mathbf{s}[0]$ denotes the first item on the machine's stack. For subsequences, ellipses are used to specify the intended range, to include elements at both limits, \eg $\boldsymbol{\mu}_\mathbf{m}[0..31]$ denotes the first 32 items of the machine's memory. +Square brackets are used to index into and reference individual components or subsequences of sequences, \eg $\boldsymbol{\mu}_{\mathbf{s}}[0]$ denotes the first item on the machine's stack. For subsequences, ellipses are used to specify the intended range, to include elements at both limits, \eg $\boldsymbol{\mu}_{\mathbf{m}}[0..31]$ denotes the first 32 items of the machine's memory. In the case of the global state $\boldsymbol{\sigma}$, which is a sequence of accounts, themselves tuples, the square brackets are used to reference an individual account. @@ -218,7 +218,7 @@ \subsection{World State} \label{ch:state} Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: \begin{equation} -\texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_\mathbf{s})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} +\texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_{\mathbf{s}})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} The collapse function for the set of key/value pairs in the trie, $L_{I}^*$, is defined as the element-wise transformation of the base function $L_{I}$, given as: @@ -231,7 +231,7 @@ \subsection{World State} \label{ch:state} k \in \mathbb{B}_{32} \quad \wedge \quad v \in \mathbb{P} \end{equation} -It shall be understood that $\boldsymbol{\sigma}[a]_\mathbf{s}$ is not a `physical' member of the account and does not contribute to its later serialisation. +It shall be understood that $\boldsymbol{\sigma}[a]_{\mathbf{s}}$ is not a `physical' member of the account and does not contribute to its later serialisation. If the \textbf{codeHash} field is the Keccak-256 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_{\mathrm{c}} = \texttt{\small KEC}\big(()\big)$, then the node represents a simple account, sometimes referred to as a ``non-contract'' account. @@ -280,7 +280,7 @@ \subsection{The Transaction} \label{ch:transaction} Additionally, a contract creation transaction contains: \begin{description} -\item[init] An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally $T_\mathbf{i}$. +\item[init] An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally $T_{\mathbf{i}}$. \end{description} \textbf{init} is an EVM-code fragment; it returns the \textbf{body}, a second fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code). \textbf{init} is executed only once at account creation and gets discarded immediately thereafter. @@ -288,24 +288,24 @@ \subsection{The Transaction} \label{ch:transaction} In contrast, a message call transaction contains: \begin{description} -\item[data] An unlimited size byte array specifying the input data of the message call, formally $T_\mathbf{d}$. +\item[data] An unlimited size byte array specifying the input data of the message call, formally $T_{\mathbf{d}}$. \end{description} Appendix \ref{app:signing} specifies the function, $S$, which maps transactions to the sender, and happens through the ECDSA of the SECP-256k1 curve, using the hash of the transaction (excepting the latter three signature fields) as the datum to sign. For the present we simply assert that the sender of a given transaction $T$ can be represented with $S(T)$. \begin{equation} L_{T}(T) \equiv \begin{cases} -(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{i}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ -(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_\mathbf{d}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathbf{i}}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ +(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathbf{d}}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} \end{equation} -Here, we assume all components are interpreted by the RLP as integer values, with the exception of the arbitrary length byte arrays $T_\mathbf{i}$ and $T_\mathbf{d}$. +Here, we assume all components are interpreted by the RLP as integer values, with the exception of the arbitrary length byte arrays $T_{\mathbf{i}}$ and $T_{\mathbf{d}}$. \begin{equation} \begin{array}[t]{lclclc} T_{\mathrm{n}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{v}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{p}} \in \mathbb{P}_{256} & \wedge \\ T_{\mathrm{g}} \in \mathbb{P}_{256} & \wedge & T_{\mathrm{w}} \in \mathbb{P}_5 & \wedge & T_{\mathrm{r}} \in \mathbb{P}_{256} & \wedge \\ -T_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge & T_\mathbf{d} \in \mathbb{B} & \wedge & T_\mathbf{i} \in \mathbb{B} +T_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge & T_{\mathbf{d}} \in \mathbb{B} & \wedge & T_{\mathbf{i}} \in \mathbb{B} \end{array} \end{equation} where @@ -313,9 +313,9 @@ \subsection{The Transaction} \label{ch:transaction} \mathbb{P}_{\mathrm{n}} = \{ P: P \in \mathbb{P} \wedge P < 2^n \} \end{equation} -The address hash $T_\mathbf{t}$ is slightly different: it is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to $\varnothing$), it is the RLP empty byte sequence and thus the member of $\mathbb{B}_0$: +The address hash $T_{\mathbf{t}}$ is slightly different: it is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to $\varnothing$), it is the RLP empty byte sequence and thus the member of $\mathbb{B}_0$: \begin{equation} -T_\mathbf{t} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ +T_{\mathbf{t}} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} @@ -345,22 +345,22 @@ \subsection{The Block} \label{ch:block} \linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{H}, B_\mathbf{T}, B_\mathbf{U}) +B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}) \end{equation} \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. -Each receipt, denoted $B_\mathbf{R}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. +Each receipt, denoted $B_{\mathbf{R}}[i]$ for the $i$th transaction, is placed in an index-keyed trie and the root recorded in the header as $H_{\mathrm{e}}$. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_\mathbf{l}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, $R_{\mathbf{l}}$ and the Bloom filter composed from information in those logs, $R_{\mathrm{b}}$ and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} -R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}, R_{\mathrm{z}}) +R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}}) \end{equation} The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} -L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_\mathbf{l}) +L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}) \end{equation} where $0 \in \mathbb{B}_{256}$ replaces the pre-transaction state root that existed in previous versions of the protocol. @@ -374,19 +374,19 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} R_{\mathrm{u}} \in \mathbb{P} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \end{equation} -%Notably $B_\mathbf{T}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. +%Notably $B_{\mathbf{T}}$ does not get serialised into the block by the block preparation function $L_{B}$; it is merely a convenience equivalence. -The sequence $R_\mathbf{l}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_\mathbf{t}$ and some number of bytes of data, $O_\mathbf{d}$: +The sequence $R_{\mathbf{l}}$ is a series of log entries, $(O_0, O_1, ...)$. A log entry, $O$, is a tuple of the logger's address, $O_a$, a series of 32-byte log topics, $O_{\mathbf{t}}$ and some number of bytes of data, $O_{\mathbf{d}}$: \begin{equation} -O \equiv (O_{\mathrm{a}}, ({O_\mathbf{t}}_0, {O_\mathbf{t}}_1, ...), O_\mathbf{d}) +O \equiv (O_{\mathrm{a}}, ({O_{\mathbf{t}}}_0, {O_{\mathbf{t}}}_1, ...), O_{\mathbf{d}}) \end{equation} \begin{equation} -O_{\mathrm{a}} \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_\mathbf{t}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_\mathbf{d} \in \mathbb{B} +O_{\mathrm{a}} \in \mathbb{B}_{20} \quad \wedge \quad \forall_{t \in O_{\mathbf{t}}}: t \in \mathbb{B}_{32} \quad \wedge \quad O_{\mathbf{d}} \in \mathbb{B} \end{equation} We define the Bloom filter function, $M$, to reduce a log entry into a single 256-byte hash: \begin{equation} -M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_\mathbf{t}} \big( M_{3:2048}(t) \big) +M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_{\mathbf{t}}} \big( M_{3:2048}(t) \big) \end{equation} where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence.\footnote{11 bits $= 2^{2048}$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: @@ -401,14 +401,14 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction Receipt}{} \subsubsection{Holistic Validity} -\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_\mathbf{T}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: +\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions $B_{\mathbf{T}}$ (as specified in sec \ref{ch:finalisation}), when executed in order on the base state $\boldsymbol{\sigma}$ (derived from the final state of the parent block), result in a new state of the identity $H_{\mathrm{r}}$: \begin{equation} \begin{array}[t]{lclc} \linkdest{new_state_H__r}{}H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ -\linkdest{Ommer_block_hash_H__o}{}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_\mathbf{U}))) & \wedge \\ -\linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{T} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_\mathbf{T}[i]))\}) & \wedge \\ -\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_\mathbf{R} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_\mathbf{R}[i]))\}) & \wedge \\ -\linkdest{logs_Bloom_filter_H__b}{}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_\mathbf{R}} \big( \mathbf{r}_{\mathrm{b}} \big) +\linkdest{Ommer_block_hash_H__o}{}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_{\mathbf{U}}))) & \wedge \\ +\linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{T}} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_{\mathbf{T}}[i]))\}) & \wedge \\ +\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_{\mathbf{R}}[i]))\}) & \wedge \\ +\linkdest{logs_Bloom_filter_H__b}{}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_{\mathbf{R}}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} where $p(k, v)$ is simply the pairwise RLP transformation, in this case, the first being the index of the transaction in the block and the second being the transaction receipt: @@ -423,14 +423,14 @@ \subsubsection{Holistic Validity} Thus $\texttt{\small TRIE}(L_{S}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{H})$ is the parent block of $B$, defined directly. -The values stemming from the computation of transactions, specifically the transaction receipts, $B_\mathbf{R}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. +The values stemming from the computation of transactions, specifically the transaction receipts, $B_{\mathbf{R}}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ -\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_\mathbf{T}), L_{H}^*(B_\mathbf{U}) \big) +\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) \end{eqnarray} \hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: @@ -492,7 +492,7 @@ \subsubsection{Block Header Validity} \end{equation} \begin{equation*} x \equiv \begin{cases} -1 & \text{if} \, \lVert P(H)_\mathbf{U}\rVert = 0 \\ +1 & \text{if} \, \lVert P(H)_{\mathbf{U}}\rVert = 0 \\ 2 & \text{otherwise} \end{cases} \end{equation*} @@ -575,10 +575,10 @@ \section{Transaction Execution} \label{ch:transactions} \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: \begin{equation} -A \equiv (A_\mathbf{s}, A_\mathbf{l}, A_\mathbf{t}, A_{\mathrm{r}}) +A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}) \end{equation} -\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_\mathbf{s}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_\mathbf{l}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_\mathbf{t}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} @@ -588,12 +588,12 @@ \subsection{Substate} \subsection{Execution} \hypertarget{intrinsic_gas_g_0}{}We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} -g_0 \equiv {} & \sum_{i \in T_\mathbf{i}, T_\mathbf{d}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ +g_0 \equiv {} & \sum_{i \in T_{\mathbf{i}}, T_{\mathbf{d}}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ {} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ {} & + G_{transaction} \end{align} -where $T_\mathbf{i},T_\mathbf{d}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. +where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. The up-front cost $v_0$ is calculated as: \begin{equation} @@ -608,11 +608,11 @@ \subsection{Execution} \linkdest{transaction_nonce}{}T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ -T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_\mathbf{R})_{\mathrm{u}} +T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_{\mathbf{R}})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_\mathbf{R})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. @@ -626,8 +626,8 @@ \subsection{Execution} Evaluating $\boldsymbol{\sigma}_{P}$ from $\boldsymbol{\sigma}_0$ depends on the transaction type; either contract creation or message call; we define the tuple of post-execution provisional state $\boldsymbol{\sigma}_{P}$, remaining gas $g'$, substate $A$ and status code $z$: \begin{equation} (\boldsymbol{\sigma}_{P}, g', A, z) \equiv \begin{cases} -\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_\mathbf{i}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ -\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_\mathbf{d}, 0, \top) & \text{otherwise} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathbf{i}}, 0, \top) & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ +\Theta_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad T_{\mathrm{t}}, T_{\mathrm{t}}, g, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_{\mathbf{d}}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -657,14 +657,14 @@ \subsection{Execution} The final state, $\boldsymbol{\sigma}'$, is reached after deleting all accounts that either appear in the self-destruct list or are touched and empty: \begin{eqnarray} \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma}^* \quad \text{except} \\ -\linkdest{self_destruct_list_A__s}{}\forall i \in A_\mathbf{s}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ -\linkdest{touched_A__t}{}\forall i \in A_\mathbf{t}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) +\linkdest{self_destruct_list_A__s}{}\forall i \in A_{\mathbf{s}}: \boldsymbol{\sigma}'[i] & = & \varnothing \\ +\linkdest{touched_A__t}{}\forall i \in A_{\mathbf{t}}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} \hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_s}{}And finally, we specify $\Upsilon^g$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^z$, the status code of this transaction: \begin{eqnarray} \Upsilon^g(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_\mathbf{l} \\ +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_{\mathbf{l}} \\ \Upsilon^z(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} @@ -696,7 +696,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} \end{cases} \\ -\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_{\mathrm{n}}, \boldsymbol{\sigma}[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}[s]_\mathbf{s}, \boldsymbol{\sigma}[s]_{\mathrm{c}}) +\mathbf{a}^* &\equiv& (\boldsymbol{\sigma}[s]_{\mathrm{n}}, \boldsymbol{\sigma}[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}[s]_{\mathbf{s}}, \boldsymbol{\sigma}[s]_{\mathrm{c}}) \end{eqnarray} where $v'$ is the account's pre-existing value, in the event it was previously in existence: @@ -719,15 +719,15 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{a}} & \equiv & a \\ I_{\mathrm{o}} & \equiv & o \\ I_{\mathrm{p}} & \equiv & p \\ -I_\mathbf{d} & \equiv & () \\ +I_{\mathbf{d}} & \equiv & () \\ I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & v \\ -I_\mathbf{b} & \equiv & \mathbf{i} \\ +I_{\mathbf{b}} & \equiv & \mathbf{i} \\ I_{\mathrm{e}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple as there is no input data to this call. $I_{H}$ has no special treatment and is determined from the blockchain. +$I_{\mathbf{d}}$ evaluates to the empty tuple as there is no input data to this call. $I_{H}$ has no special treatment and is determined from the blockchain. Code execution depletes gas, and gas may not go below zero, thus execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, $\varnothing$, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation. @@ -795,7 +795,7 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_{\mathrm{n}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}_1'[s]_\mathbf{s}, \boldsymbol{\sigma}_1'[s]_{\mathrm{c}}) +\mathbf{a}_1 \equiv (\boldsymbol{\sigma}_1'[s]_{\mathrm{n}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{b}} - v, \boldsymbol{\sigma}_1'[s]_{\mathbf{s}}, \boldsymbol{\sigma}_1'[s]_{\mathrm{c}}) \end{equation} \begin{equation} \text{and}\quad \boldsymbol{\sigma}_1' \equiv \boldsymbol{\sigma} \quad \text{except:} \\ @@ -808,7 +808,7 @@ \section{Message Call} \label{ch:call} \end{cases} \end{equation} \begin{equation} -\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + v, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) +\mathbf{a}_1' \equiv (\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + v, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) \end{equation} The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_{\mathrm{c}}$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$). @@ -839,17 +839,17 @@ \section{Message Call} \label{ch:call} I_{\mathrm{a}} & \equiv & r \\ I_{\mathrm{o}} & \equiv & o \\ I_{\mathrm{p}} & \equiv & p \\ -I_\mathbf{d} & \equiv & \mathbf{d} \\ +I_{\mathbf{d}} & \equiv & \mathbf{d} \\ I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & \tilde{v} \\ I_{\mathrm{e}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \\ \mathbf{t} & \equiv & \{s, r\} \\ \\ \nonumber -\text{Let} \; \mathtt{\tiny KEC}(I_\mathbf{b}) & = & \boldsymbol{\sigma}[c]_{\mathrm{c}} +\text{Let} \; \mathtt{\tiny KEC}(I_{\mathbf{b}}) & = & \boldsymbol{\sigma}[c]_{\mathrm{c}} \end{eqnarray} -It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_\mathbf{b}), I_\mathbf{b})$ at some point prior in order to make the determination of $I_\mathbf{b}$ feasible. +It is assumed that the client will have stored the pair $(\mathtt{\tiny KEC}(I_{\mathbf{b}}), I_{\mathbf{b}})$ at some point prior in order to make the determination of $I_{\mathbf{b}}$ feasible. As can be seen, there are eight exceptions to the usage of the general execution framework $\Xi$ for evaluation of the message call: these are eight so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become \textit{native extensions}. The eight contracts in addresses 1 to 8 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme, the identity function, arbitrary precision modular exponentiation, elliptic curve addition, elliptic curve scalar multiplication and an elliptic curve pairing check respectively. @@ -915,10 +915,10 @@ \subsection{Execution Overview} (\boldsymbol{\sigma}', \boldsymbol{\mu}'\!, A, ..., \mathbf{o}) & \equiv & X\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A^0\!, I)\big) \\ \boldsymbol{\mu}_{\mathrm{g}} & \equiv & g \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ -\boldsymbol{\mu}_\mathbf{m} & \equiv & (0, 0, ...) \\ +\boldsymbol{\mu}_{\mathbf{m}} & \equiv & (0, 0, ...) \\ \boldsymbol{\mu}_{\mathrm{i}} & \equiv & 0 \\ -\boldsymbol{\mu}_\mathbf{s} & \equiv & () \\ -\boldsymbol{\mu}_\mathbf{o} & \equiv & () +\boldsymbol{\mu}_{\mathbf{s}} & \equiv & () \\ +\boldsymbol{\mu}_{\mathbf{o}} & \equiv & () \end{eqnarray} \begin{equation} \label{eq:X-def} X\big( (\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I) \big) \equiv \begin{cases} @@ -942,13 +942,13 @@ \subsection{Execution Overview} $X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either $Z$ becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until $H$ becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. \subsubsection{Machine State} -The machine state $\boldsymbol{\mu}$ is defined as the tuple $(g, pc, \mathbf{m}, i, \mathbf{s})$ which are the gas available, the program counter $pc \in \mathbb{P}_{256}$ , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents $\boldsymbol{\mu}_\mathbf{m}$ are a series of zeroes of size $2^{256}$. +The machine state $\boldsymbol{\mu}$ is defined as the tuple $(g, pc, \mathbf{m}, i, \mathbf{s})$ which are the gas available, the program counter $pc \in \mathbb{P}_{256}$ , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents $\boldsymbol{\mu}_{\mathbf{m}}$ are a series of zeroes of size $2^{256}$. For the ease of reading, the instruction mnemonics, written in small-caps (\eg \space {\small ADD}), should be interpreted as their numeric equivalents; the full table of instructions and their specifics is given in Appendix \ref{app:vm}. For the purposes of defining $Z$, $H$ and $O$, we define $w$ as the current operation to be executed: \begin{equation}\label{eq:currentoperation} -w \equiv \begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_\mathbf{b} \rVert \\ +w \equiv \begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_{\mathbf{b}} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases} \end{equation} @@ -963,10 +963,10 @@ \subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{ \begin{array}[t]{l} \boldsymbol{\mu}_{\mathrm{g}} < C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \quad \vee \\ \mathbf{\delta}_{\mathrm{w}} = \varnothing \quad \vee \\ -\lVert\boldsymbol{\mu}_\mathbf{s}\rVert < \mathbf{\delta}_{\mathrm{w}} \quad \vee \\ -( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[0] \notin D(I_\mathbf{b}) ) \quad \vee \\ -( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] > \lVert\boldsymbol{\mu}_\mathbf{o}\rVert) \quad \vee \\ - \lVert\boldsymbol{\mu}_\mathbf{s}\rVert - \mathbf{\delta}_{\mathrm{w}} + \mathbf{\alpha}_{\mathrm{w}} > 1024 \quad \vee \\ +\lVert\boldsymbol{\mu}_{\mathbf{s}}\rVert < \mathbf{\delta}_{\mathrm{w}} \quad \vee \\ +( w \in \{ \text{\small JUMP}, \text{\small JUMPI} \} \quad \wedge \\ \quad \boldsymbol{\mu}_{\mathbf{s}}[0] \notin D(I_{\mathbf{b}}) ) \quad \vee \\ +( w = \text{\small RETURNDATACOPY} \wedge \\ \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + \boldsymbol{\mu}_{\mathbf{s}}[2] > \lVert\boldsymbol{\mu}_{\mathbf{o}}\rVert) \quad \vee \\ + \lVert\boldsymbol{\mu}_{\mathbf{s}}\rVert - \mathbf{\delta}_{\mathrm{w}} + \mathbf{\alpha}_{\mathrm{w}} > 1024 \quad \vee \\ \neg I_{\mathrm{w}} \wedge W(w, \boldsymbol{\mu}) \end{array} \end{equation} @@ -975,7 +975,7 @@ \subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{ W(w, \boldsymbol{\mu}) \equiv \begin{array}[t]{l} w \in \{\text{\small CREATE}, \text{\small SSTORE}, \text{\small SELFDESTRUCT}\} \quad \vee \\ \text{\small LOG0} \le w \wedge w \le \text{\small LOG4} \quad \vee \\ -w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 +w \in \{\text{\small CALL}, \text{\small CALLCODE}\} \wedge \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \end{array} \end{equation} @@ -1027,8 +1027,8 @@ \subsection{The Execution Cycle} \begin{eqnarray} O\big((\boldsymbol{\sigma}, \boldsymbol{\mu}, A, I)\big) & \equiv & (\boldsymbol{\sigma}', \boldsymbol{\mu}', A', I) \\ \Delta & \equiv & \mathbf{\alpha}_{\mathrm{w}} - \mathbf{\delta}_{\mathrm{w}} \\ -\lVert\boldsymbol{\mu}'_\mathbf{s}\rVert & \equiv & \lVert\boldsymbol{\mu}_\mathbf{s}\rVert + \Delta \\ -\quad \forall x \in [\mathbf{\alpha}_{\mathrm{w}}, \lVert\boldsymbol{\mu}'_\mathbf{s}\rVert): \boldsymbol{\mu}'_\mathbf{s}[x] & \equiv & \boldsymbol{\mu}_\mathbf{s}[x-\Delta] +\lVert\boldsymbol{\mu}'_{\mathbf{s}}\rVert & \equiv & \lVert\boldsymbol{\mu}_{\mathbf{s}}\rVert + \Delta \\ +\quad \forall x \in [\mathbf{\alpha}_{\mathrm{w}}, \lVert\boldsymbol{\mu}'_{\mathbf{s}}\rVert): \boldsymbol{\mu}'_{\mathbf{s}}[x] & \equiv & \boldsymbol{\mu}_{\mathbf{s}}[x-\Delta] \end{eqnarray} The gas is reduced by the instruction's gas cost and for most instructions, the program counter increments on each cycle, for the three exceptions, we assume a function $J$, subscripted by one of two instructions, which evaluates to the according value: @@ -1043,7 +1043,7 @@ \subsection{The Execution Cycle} In general, we assume the memory, self-destruct set and system state don't change: \begin{eqnarray} -\boldsymbol{\mu}'_\mathbf{m} & \equiv & \boldsymbol{\mu}_\mathbf{m} \\ +\boldsymbol{\mu}'_{\mathbf{m}} & \equiv & \boldsymbol{\mu}_{\mathbf{m}} \\ \boldsymbol{\mu}'_{\mathrm{i}} & \equiv & \boldsymbol{\mu}_{\mathrm{i}} \\ A' & \equiv & A \\ \boldsymbol{\sigma}' & \equiv & \boldsymbol{\sigma} @@ -1093,13 +1093,13 @@ \subsection{Ommer Validation} and $s$ denotes the ``is-sibling'' property: \begin{equation} -s(U, H) \equiv (P(H) = P(U)\; \wedge \; H \neq U \; \wedge \; U \notin B(H)_\mathbf{U}) +s(U, H) \equiv (P(H) = P(U)\; \wedge \; H \neq U \; \wedge \; U \notin B(H)_{\mathbf{U}}) \end{equation} where $B(H)$ is the block of the corresponding header $H$. \subsection{Transaction Validation} -%where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_\mathbf{T}[i]$, and $g[i]$ the total gas used immediately after said transaction. +%where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_{\mathbf{T}}[i]$, and $g[i]$ the total gas used immediately after said transaction. The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{H}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} @@ -1112,13 +1112,13 @@ \subsection{Reward Application} \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_\mathbf{U}\rVert}{32})R_{\mathrm{b}} \\ +\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_{\mathbf{U}}\rVert}{32})R_{\mathrm{b}} \\ \qquad\forall_{\mathbf{U} \in \mathbf{B}_{\mathbf{U}}}: \\ \nonumber \boldsymbol{\sigma}'[\mathbf{U}_{\mathrm{c}}] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[\mathbf{U}_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ -\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_\mathbf{s}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ +\mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathbf{s}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{b}} \end{eqnarray} @@ -1152,30 +1152,30 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} \end{equation} -In the case of $B_\mathbf{R}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: +In the case of $B_{\mathbf{R}}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} \mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} +\Upsilon^g(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} -For $\mathbf{R}[n]_\mathbf{l}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. +For $\mathbf{R}[n]_{\mathbf{l}}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. \begin{equation} -\mathbf{R}[n]_\mathbf{l} = -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\mathbf{R}[n]_{\mathbf{l}} = +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. \begin{equation} \mathbf{R}[n]_{\mathrm{z}} = -\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_\mathbf{T}[n]) +\Upsilon^z(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} \hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: @@ -1461,8 +1461,8 @@ \section{Precompiled Contracts}\label{app:precompiled} \text{if} \quad |\mathbf{o}| = 32: &&\\ \mathbf{o}[0..11] &=& 0 \\ \mathbf{o}[12..31] &=& \mathtt{\tiny KEC}\big(\mathtt{\tiny ECDSARECOVER}(h, v, r, s)\big)[12..31] \quad \text{where:}\\ -\mathbf{d}[0..(|I_\mathbf{d}|-1)] &=& I_\mathbf{d}\\ -\mathbf{d}[|I_\mathbf{d}|..] &=& (0, 0, ...) \\ +\mathbf{d}[0..(|I_{\mathbf{d}}|-1)] &=& I_{\mathbf{d}}\\ +\mathbf{d}[|I_{\mathbf{d}}|..] &=& (0, 0, ...) \\ h &=& \mathbf{d}[0..31]\\ v &=& \mathbf{d}[32..63]\\ r &=& \mathbf{d}[64..95]\\ @@ -1472,12 +1472,12 @@ \section{Precompiled Contracts}\label{app:precompiled} The two hash functions, RIPEMD-160 and SHA2-256 are more trivially defined as an almost pass-through operation. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. \begin{eqnarray} \Xi_{\mathtt{SHA256}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ -\mathbf{o}[0..31] &=& \mathtt{\tiny SHA256}(I_\mathbf{d})\\ +g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ +\mathbf{o}[0..31] &=& \mathtt{\tiny SHA256}(I_{\mathbf{d}})\\ \Xi_{\mathtt{RIP160}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ +g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ \mathbf{o}[0..11] &=& 0 \\ -\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_\mathbf{d})\\ +\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_{\mathbf{d}})\\ \end{eqnarray} For the purposes here, we assume we have well-defined standard cryptographic functions for RIPEMD-160 and SHA2-256 of the form: @@ -1489,8 +1489,8 @@ \section{Precompiled Contracts}\label{app:precompiled} The fourth contract, the identity function $\Xi_{\mathtt{ID}}$ simply defines the output as the input: \begin{eqnarray} \Xi_{\mathtt{ID}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ -g_{\mathrm{r}} &=& 15 + 3\Big\lceil \dfrac{|I_\mathbf{d}|}{32} \Big\rceil\\ -\mathbf{o} &=& I_\mathbf{d} +g_{\mathrm{r}} &=& 15 + 3\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ +\mathbf{o} &=& I_{\mathbf{d}} \end{eqnarray} The fifth contract performs arbitrary-precision exponentiation under modulo. Here, $0 ^ 0$ is taken to be one, and $x \bmod 0$ is zero for all $x$. The first word in the input specifies the number of bytes that the first non-negative integer $B$ occupies. The second word in the input specifies the number of bytes that the second non-negative integer $E$ occupies. The third word in the input specifies the number of bytes that the third non-negative integer $M$ occupies. These three words are followed by $B$, $E$ and $M$. The rest of the input is discarded. Whenever the input is too short, the missing bytes are considered to be zero. The output is encoded big-endian into the same format as $M$'s. @@ -1607,8 +1607,8 @@ \subsection{zkSNARK Related Precompiled Contracts} \begin{eqnarray} \Xi_{\mathtt{SNARKV}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \qquad\Xi_{\mathtt{SNARKV}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ F\\ -F&\equiv&(|I_\mathbf{d}|\bmod 192\neq 0\vee(\exists j.\ a_{\mathrm{j}}=\varnothing\vee b_{\mathrm{j}}=\varnothing))\\ -k &=& \dfrac{|I_\mathbf{d}|}{192} \\ +F&\equiv&(|I_{\mathbf{d}}|\bmod 192\neq 0\vee(\exists j.\ a_{\mathrm{j}}=\varnothing\vee b_{\mathrm{j}}=\varnothing))\\ +k &=& \dfrac{|I_{\mathbf{d}}|}{192} \\ g_{\mathrm{r}}&=& 60000k + 40000 \\ \mathbf o[0..31]&\equiv&\begin{cases} 0x0000000000000000000000000000000000000000000000000000000000000001&\text{if}\ v\wedge\neg F\\ @@ -1776,15 +1776,15 @@ \subsection{Gas Cost} \begin{equation} C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \equiv C_{mem}(\boldsymbol{\mu}'_{\mathrm{i}})-C_{mem}(\boldsymbol{\mu}_{\mathrm{i}}) + \begin{cases} C_\text{\tiny SSTORE}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SSTORE} \\ -G_{exp} & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] = 0 \\ -G_{exp} + G_{expbyte}\times(1+\lfloor\log_{256}(\boldsymbol{\mu}_\mathbf{s}[1])\rfloor) & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_\mathbf{s}[1] > 0 \\ -G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \lor \text{\small RETURNDATACOPY} \\ -G_{extcode} + G_{copy}\times\lceil\boldsymbol{\mu}_\mathbf{s}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1] & \text{if} \quad w = \text{\small LOG0} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+G_{logtopic} & \text{if} \quad w = \text{\small LOG1} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+2G_{logtopic} & \text{if} \quad w = \text{\small LOG2} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+3G_{logtopic} & \text{if} \quad w = \text{\small LOG3} \\ -G_{log}+G_{logdata}\times\boldsymbol{\mu}_\mathbf{s}[1]+4G_{logtopic} & \text{if} \quad w = \text{\small LOG4} \\ +G_{exp} & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_{\mathbf{s}}[1] = 0 \\ +G_{exp} + G_{expbyte}\times(1+\lfloor\log_{256}(\boldsymbol{\mu}_{\mathbf{s}}[1])\rfloor) & \text{if} \quad w = \text{\small EXP} \wedge \boldsymbol{\mu}_{\mathbf{s}}[1] > 0 \\ +G_{verylow} + G_{copy}\times\lceil\boldsymbol{\mu}_{\mathbf{s}}[2] \div 32\rceil & \text{if} \quad w = \text{\small CALLDATACOPY} \lor \text{\small CODECOPY} \lor \text{\small RETURNDATACOPY} \\ +G_{extcode} + G_{copy}\times\lceil\boldsymbol{\mu}_{\mathbf{s}}[3] \div 32\rceil & \text{if} \quad w = \text{\small EXTCODECOPY} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1] & \text{if} \quad w = \text{\small LOG0} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+G_{logtopic} & \text{if} \quad w = \text{\small LOG1} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+2G_{logtopic} & \text{if} \quad w = \text{\small LOG2} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+3G_{logtopic} & \text{if} \quad w = \text{\small LOG3} \\ +G_{log}+G_{logdata}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+4G_{logtopic} & \text{if} \quad w = \text{\small LOG4} \\ C_\text{\tiny CALL}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small CALL} \lor \text{\small CALLCODE} \lor \text{\small DELEGATECALL} \\ C_\text{\tiny SELFDESTRUCT}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SELFDESTRUCT} \\ G_{create} & \text{if} \quad w = \text{\small CREATE}\\ @@ -1803,7 +1803,7 @@ \subsection{Gas Cost} \end{cases} \end{equation} \begin{equation} -w \equiv \begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_\mathbf{b} \rVert\\ +w \equiv \begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_{\mathbf{b}} \rVert\\ \text{\small STOP} & \text{otherwise} \end{cases} \end{equation} @@ -1867,43 +1867,43 @@ \subsection{Instruction Set} \linkdest{stop}{}0x00 & {\small STOP} & 0 & 0 & Halts execution. \\ \midrule 0x01 & {\small ADD} & 2 & 1 & Addition operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule 0x02 & {\small MUL} & 2 & 1 & Multiplication operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] \times \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] \times \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule 0x03 & {\small SUB} & 2 & 1 & Subtraction operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] - \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] - \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule 0x04 & {\small DIV} & 2 & 1 & Integer division operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ \lfloor\boldsymbol{\mu}_\mathbf{s}[0] \div \boldsymbol{\mu}_\mathbf{s}[1]\rfloor & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ \lfloor\boldsymbol{\mu}_{\mathbf{s}}[0] \div \boldsymbol{\mu}_{\mathbf{s}}[1]\rfloor & \text{otherwise}\end{cases}$ \\ \midrule 0x05 & {\small SDIV} & 2 & 1 & Signed integer division operation (truncated). \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ -2^{255} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = -2^{255} \wedge \quad \boldsymbol{\mu}_\mathbf{s}[1] = -1\\ \mathbf{sgn} (\boldsymbol{\mu}_\mathbf{s}[0] \div \boldsymbol{\mu}_\mathbf{s}[1]) \lfloor |\boldsymbol{\mu}_\mathbf{s}[0] \div \boldsymbol{\mu}_\mathbf{s}[1]| \rfloor & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ -2^{255} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] = -2^{255} \wedge \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = -1\\ \mathbf{sgn} (\boldsymbol{\mu}_{\mathbf{s}}[0] \div \boldsymbol{\mu}_{\mathbf{s}}[1]) \lfloor |\boldsymbol{\mu}_{\mathbf{s}}[0] \div \boldsymbol{\mu}_{\mathbf{s}}[1]| \rfloor & \text{otherwise}\end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ &&&& Note the overflow semantic when $-2^{255}$ is negated.\\ \midrule 0x06 & {\small MOD} & 2 & 1 & Modulo remainder operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ \boldsymbol{\mu}_\mathbf{s}[0] \bmod \boldsymbol{\mu}_\mathbf{s}[1] & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ \boldsymbol{\mu}_{\mathbf{s}}[0] \bmod \boldsymbol{\mu}_{\mathbf{s}}[1] & \text{otherwise}\end{cases}$ \\ \midrule 0x07 & {\small SMOD} & 2 & 1 & Signed modulo remainder operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0\\ \mathbf{sgn} (\boldsymbol{\mu}_\mathbf{s}[0]) (|\boldsymbol{\mu}_\mathbf{s}[0]| \bmod |\boldsymbol{\mu}_\mathbf{s}[1]|) & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0\\ \mathbf{sgn} (\boldsymbol{\mu}_{\mathbf{s}}[0]) (|\boldsymbol{\mu}_{\mathbf{s}}[0]| \bmod |\boldsymbol{\mu}_{\mathbf{s}}[1]|) & \text{otherwise}\end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule 0x08 & {\small ADDMOD} & 3 & 1 & Modulo addition operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] = 0\\ (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1]) \mod \boldsymbol{\mu}_\mathbf{s}[2] & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] = 0\\ (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1]) \mod \boldsymbol{\mu}_{\mathbf{s}}[2] & \text{otherwise}\end{cases}$ \\ &&&& All intermediate calculations of this operation are not subject to the $2^{256}$ modulo. \\ \midrule 0x09 & {\small MULMOD} & 3 & 1 & Modulo multiplication operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] = 0\\ (\boldsymbol{\mu}_\mathbf{s}[0] \times \boldsymbol{\mu}_\mathbf{s}[1]) \mod \boldsymbol{\mu}_\mathbf{s}[2] & \text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}0 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] = 0\\ (\boldsymbol{\mu}_{\mathbf{s}}[0] \times \boldsymbol{\mu}_{\mathbf{s}}[1]) \mod \boldsymbol{\mu}_{\mathbf{s}}[2] & \text{otherwise}\end{cases}$ \\ &&&& All intermediate calculations of this operation are not subject to the $2^{256}$ modulo. \\ \midrule 0x0a & {\small EXP} & 2 & 1 & Exponential operation. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0] ^ {\boldsymbol{\mu}_\mathbf{s}[1] }$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] ^ {\boldsymbol{\mu}_{\mathbf{s}}[1] }$ \\ \midrule 0x0b & {\small SIGNEXTEND} & 2 & 1 & Extend length of two's complement signed integer. \\ -&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{t}} &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_\mathbf{s}[0] + 1) \\ \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}} &\text{otherwise} \end{cases}$ \\ -\multicolumn{5}{l}{$\boldsymbol{\mu}_\mathbf{s}[x]_{\mathrm{i}}$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_\mathbf{s}[x]$} \vspace{5pt} \\ +&&&& $ \forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{t}} &\text{if} \quad i \leqslant t \quad \text{where} \; t = 256 - 8(\boldsymbol{\mu}_{\mathbf{s}}[0] + 1) \\ \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}} &\text{otherwise} \end{cases}$ \\ +\multicolumn{5}{l}{$\boldsymbol{\mu}_{\mathbf{s}}[x]_{\mathrm{i}}$ gives the $i$th bit (counting from zero) of $\boldsymbol{\mu}_{\mathbf{s}}[x]$} \vspace{5pt} \\ \midrule \end{tabular*} @@ -1912,39 +1912,39 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{10s: Comparison \& Bitwise Logic Operations}} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x10 & {\small LT} & 2 & 1 & Less-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] < \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] < \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x11 & {\small GT} & 2 & 1 & Greater-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] > \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x12 & {\small SLT} & 2 & 1 & Signed less-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] < \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] < \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule 0x13 & {\small SGT} & 2 & 1 & Signed greater-than comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] > \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& Where all values are treated as two's complement signed 256-bit integers. \\ \midrule 0x14 & {\small EQ} & 2 & 1 & Equality comparison. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = \boldsymbol{\mu}_\mathbf{s}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] = \boldsymbol{\mu}_{\mathbf{s}}[1] \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x15 & {\small ISZERO} & 1 & 1 & Simple not operator. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x16 & {\small AND} & 2 & 1 & Bitwise AND operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \wedge \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} \wedge \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}}$ \\ \midrule 0x17 & {\small OR} & 2 & 1 & Bitwise OR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \vee \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} \vee \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}}$ \\ \midrule 0x18 & {\small XOR} & 2 & 1 & Bitwise XOR operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} \oplus \boldsymbol{\mu}_\mathbf{s}[1]_{\mathrm{i}}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} \oplus \boldsymbol{\mu}_{\mathbf{s}}[1]_{\mathrm{i}}$ \\ \midrule 0x19 & {\small NOT} & 1 & 1 & Bitwise NOT operation. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0]_{\mathrm{i}} = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \begin{cases} 1 & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0]_{\mathrm{i}} = 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0x1a & {\small BYTE} & 2 & 1 & Retrieve single byte from word. \\ -&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_\mathbf{s}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[1]_{(i + 8\boldsymbol{\mu}_\mathbf{s}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_\mathbf{s}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ +&&&& $\forall i \in [0..255]: \boldsymbol{\mu}'_{\mathbf{s}}[0]_{\mathrm{i}} \equiv \begin{cases} \boldsymbol{\mu}_{\mathbf{s}}[1]_{(i + 8\boldsymbol{\mu}_{\mathbf{s}}[0])} & \text{if} \quad i < 8 \wedge \boldsymbol{\mu}_{\mathbf{s}}[0] < 32 \\ 0 & \text{otherwise} \end{cases} $\\ &&&& For Nth byte, we count from the left (i.e. N=0 would be the most significant in big endian). \\ \bottomrule \end{tabular*} @@ -1954,8 +1954,8 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{20s: SHA3}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x20 & {\small SHA3} & 2 & 1 & Compute Keccak-256 hash. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \mathtt{\tiny Keccak}(\boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \mathtt{\tiny Keccak}(\boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1] - 1) ])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$ \\ \bottomrule \end{tabular*} @@ -1964,69 +1964,69 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{30s: Environmental Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x30 & {\small ADDRESS} & 0 & 1 & Get address of currently executing account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{a}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{a}}$ \\ \midrule 0x31 & {\small BALANCE} & 1 & 1 & Get balance of the given account. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0]]_{\mathrm{b}}& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}\boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0]]_{\mathrm{b}}& \text{if} \quad \boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}] \neq \varnothing\\0&\text{otherwise}\end{cases}$ \\ \midrule 0x32 & {\small ORIGIN} & 0 & 1 & Get execution origination address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{o}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{o}}$ \\ &&&& This is the sender of original transaction; it is never an account with non-empty \\ &&&& associated code. \\ \midrule 0x33 & {\small CALLER} & 0 & 1 & Get caller address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{s}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{s}}$ \\ &&&& This is the address of the account that is directly responsible for this execution. \\ \midrule 0x34 & {\small CALLVALUE} & 0 & 1 & Get deposited value by the instruction/transaction responsible for this execution. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{v}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{v}}$ \\ \midrule 0x35 & {\small CALLDATALOAD} & 1 & 1 & Get input data of current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_\mathbf{d}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \quad \text{with} \quad I_\mathbf{d}[x] = 0 \quad \text{if} \quad x \geqslant \lVert I_\mathbf{d} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathbf{d}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + 31) ] \quad \text{with} \quad I_{\mathbf{d}}[x] = 0 \quad \text{if} \quad x \geqslant \lVert I_{\mathbf{d}} \rVert$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x36 & {\small CALLDATASIZE} & 0 & 1 & Get size of input data in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert I_\mathbf{d} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert I_{\mathbf{d}} \rVert$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x37 & {\small CALLDATACOPY} & 3 & 0 & Copy input data in current environment to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} I_\mathbf{d}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{d} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[2] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] + i ] \equiv +\begin{cases} I_{\mathbf{d}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + i < \lVert I_{\mathbf{d}} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ &&&& This pertains to the input data passed with the message call instruction or transaction. \\ \midrule 0x38 & {\small CODESIZE} & 0 & 1 & Get size of code running in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert I_\mathbf{b} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert I_{\mathbf{b}} \rVert$ \\ \midrule 0x39 & {\small CODECOPY} & 3 & 0 & Copy code running in current environment to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} I_\mathbf{b}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert I_\mathbf{b} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[2] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] + i ] \equiv +\begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + i < \lVert I_{\mathbf{b}} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[1] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3a & {\small GASPRICE} & 0 & 1 & Get price of gas in current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_{\mathrm{p}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv I_{\mathrm{p}}$ \\ &&&& This is gas price specified by the originating transaction.\\ \midrule 0x3b & {\small EXTCODESIZE} & 1 & 1 & Get size of an account's code. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert \boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}]_{\mathrm{c}} \rVert$ \\ \midrule 0x3c & {\small EXTCODECOPY} & 4 & 0 & Copy an account's code to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[3] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[1] + i ] \equiv -\begin{cases} \mathbf{c}[\boldsymbol{\mu}_\mathbf{s}[2] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] + i < \lVert \mathbf{c} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ -&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}]_{\mathrm{c}}$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[3])$ \\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[2] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[3] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i ] \equiv +\begin{cases} \mathbf{c}[\boldsymbol{\mu}_{\mathbf{s}}[2] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] + i < \lVert \mathbf{c} \rVert \\ \text{\small STOP} & \text{otherwise} \end{cases}$\\ +&&&& where $\mathbf{c} \equiv \boldsymbol{\sigma}[\boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}]_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[1], \boldsymbol{\mu}_{\mathbf{s}}[3])$ \\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[2] + i$ are not subject to the $2^{256}$ modulo. \\ \midrule 0x3d & {\small RETURNDATASIZE} & 0 & 1 & Get size of output data from the previous call from the current environment. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \lVert \boldsymbol{\mu}_\mathbf{o} \rVert$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \lVert \boldsymbol{\mu}_{\mathbf{o}} \rVert$ \\ \midrule 0x3e & {\small RETURNDATACOPY} & 3 & 0 & Copy output data from the previous call to memory. \\ -&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_\mathbf{s}[2] - 1\} } \boldsymbol{\mu}'_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] + i ] \equiv -\begin{cases} \boldsymbol{\mu}_\mathbf{o}[\boldsymbol{\mu}_\mathbf{s}[1] + i] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] + i < \lVert \boldsymbol{\mu}_\mathbf{o} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ -&&&& The additions in $\boldsymbol{\mu}_\mathbf{s}[1] + i$ are not subject to the $2^{256}$ modulo. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\forall_{i \in \{ 0 \dots \boldsymbol{\mu}_{\mathbf{s}}[2] - 1\} } \boldsymbol{\mu}'_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] + i ] \equiv +\begin{cases} \boldsymbol{\mu}_{\mathbf{o}}[\boldsymbol{\mu}_{\mathbf{s}}[1] + i] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] + i < \lVert \boldsymbol{\mu}_{\mathbf{o}} \rVert \\ 0 & \text{otherwise} \end{cases}$\\ +&&&& The additions in $\boldsymbol{\mu}_{\mathbf{s}}[1] + i$ are not subject to the $2^{256}$ modulo. \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ \bottomrule \end{tabular*} @@ -2035,7 +2035,7 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{40s: Block Information}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x40 & {\small BLOCKHASH} & 1 & 1 & Get the hash of one of the 256 most recent complete blocks. \\ -\linkdest{blockhash}{}&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv P(I_{\mathbf{H}_{\mathrm{p}}}, \boldsymbol{\mu}_\mathbf{s}[0], 0)$ \\ +\linkdest{blockhash}{}&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv P(I_{\mathbf{H}_{\mathrm{p}}}, \boldsymbol{\mu}_{\mathbf{s}}[0], 0)$ \\ &&&& where $P$ is the hash of a block of a particular number, up to a maximum age.\\ &&&& 0 is left on the stack if the looked for block number is greater than the current block number \\ &&&& or more than 256 blocks behind the current block. \\ @@ -2044,19 +2044,19 @@ \subsection{Instruction Set} &&&& in the block following it. \\ \midrule 0x41 & {\small COINBASE} & 0 & 1 & Get the block's beneficiary address. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{c}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{c}}$ \\ \midrule 0x42 & {\small TIMESTAMP} & 0 & 1 & Get the block's timestamp. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{s}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{s}}$ \\ \midrule 0x43 & {\small NUMBER} & 0 & 1 & Get the block's number. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{i}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{i}}$ \\ \midrule 0x44 & {\small DIFFICULTY} & 0 & 1 & Get the block's difficulty. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{d}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{d}}$ \\ \midrule 0x45 & {\small GASLIMIT} & 0 & 1 & Get the block's gas limit. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv {I_{H}}_{\mathrm{l}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{H}}_{\mathrm{l}}$ \\ \bottomrule \end{tabular*} @@ -2067,52 +2067,52 @@ \subsection{Instruction Set} 0x50 & {\small POP} & 1 & 0 & Remove item from stack. \\ \midrule 0x51 & {\small MLOAD} & 1 & 1 & Load word from memory. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{m}[\boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ]$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{m}}[\boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + 31) ]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_{\mathbf{s}}[0] + 32) \div 32 })$ \\ &&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x52 & {\small MSTORE} & 2 & 0 & Save word to memory. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + 31) ] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 32) \div 32 })$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + 31) ] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_{\mathbf{s}}[0] + 32) \div 32 })$ \\ &&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x53 & {\small MSTORE8} & 2 & 0 & Save byte to memory. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv (\boldsymbol{\mu}_\mathbf{s}[1] \bmod 256) $ \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[0] + 1) \div 32 })$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] ] \equiv (\boldsymbol{\mu}_{\mathbf{s}}[1] \bmod 256) $ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv \max(\boldsymbol{\mu}_{\mathrm{i}}, \ceil{ (\boldsymbol{\mu}_{\mathbf{s}}[0] + 1) \div 32 })$ \\ &&&& The addition in the calculation of $\boldsymbol{\mu}'_{\mathrm{i}}$ is not subject to the $2^{256}$ modulo. \\ \midrule 0x54 & {\small SLOAD} & 1 & 1 & Load word from storage. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathbf{s}}[\boldsymbol{\mu}_{\mathbf{s}}[0]]$ \\ \midrule \linkdest{SSTORE}{}0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ -&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ +&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathbf{s}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] ] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1] $ \\ &&&&\linkdest{C tiny SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ +G_{sset} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathbf{s}}[\boldsymbol{\mu}_{\mathbf{s}}[0]] = 0 \\ G_{sreset} & \text{otherwise} \end{cases}$ \\ &&&&\linkdest{A r}{} $A'_{r} \equiv A_{r} + \begin{cases} -R_{sclear} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] \neq 0 \\ +R_{sclear} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] = 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathbf{s}}[\boldsymbol{\mu}_{\mathbf{s}}[0]] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule \linkdest{JUMP}{}0x56 & {\small JUMP} & 1 & 0 & Alter the program counter. \\ -&&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{s}[0] $ \\ +&&&& $J_{\text{\tiny JUMP}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_{\mathbf{s}}[0] $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}.\\ \midrule \linkdest{JUMPI}{}0x57 & {\small JUMPI} & 2 & 0 & Conditionally alter the program counter. \\ -&&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_\mathbf{s}[0] & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ +&&&& $J_{\text{\tiny JUMPI}}(\boldsymbol{\mu}) \equiv \begin{cases} \boldsymbol{\mu}_{\mathbf{s}}[0] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[1] \neq 0 \\ \boldsymbol{\mu}_{pc} + 1 & \text{otherwise} \end{cases} $ \\ &&&& This has the effect of writing said value to $\boldsymbol{\mu}_{pc}$. See section \ref{ch:model}. \\ \midrule 0x58 & {\small PC} & 0 & 1 & Get the value of the program counter \textit{prior} to the increment \\ &&&& corresponding to this instruction. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_{pc}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{pc}$ \\ \midrule 0x59 & {\small MSIZE} & 0 & 1 & Get the size of active memory in bytes. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv 32\boldsymbol{\mu}_{i}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv 32\boldsymbol{\mu}_{i}$ \\ \midrule 0x5a & {\small GAS} & 0 & 1 & Get the amount of available gas, including the corresponding reduction \\ &&&& for the cost of this instruction. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_{g}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{g}$ \\ \midrule 0x5b & {\small JUMPDEST} & 0 & 0 & Mark a valid destination for jumps. \\ &&&& This operation has no effect on machine state during execution. \\ @@ -2124,21 +2124,21 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{60s \& 70s: Push Operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x60 & {\small PUSH1} & 0 & 1 & Place 1 byte item on stack. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv c(\boldsymbol{\mu}_{pc} + 1)$ \\ -&&&& $\text{where} \quad c(x) \equiv \begin{cases} I_\mathbf{b}[x] & \text{if} \quad x < \lVert I_\mathbf{b} \rVert \\ 0 & \text{otherwise} \end{cases}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv c(\boldsymbol{\mu}_{pc} + 1)$ \\ +&&&& $\text{where} \quad c(x) \equiv \begin{cases} I_{\mathbf{b}}[x] & \text{if} \quad x < \lVert I_{\mathbf{b}} \rVert \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& The bytes are read in line from the program code's bytes array. \\ &&&& The function $c$ ensures the bytes default to zero if they extend past the limits.\\ &&&& The byte is right-aligned (takes the lowest significant place in big endian). \\ \midrule 0x61 & {\small PUSH2} & 0 & 1 & Place 2-byte item on stack. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{c}\big( (\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 2) \big)$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{c}\big( (\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 2) \big)$ \\ &&&& with $\boldsymbol{c}(\boldsymbol{x}) \equiv (c(\boldsymbol{x}_0), ..., c(\boldsymbol{x}_{\lVert x \rVert -1})) $ with $c$ as defined as above. \\ &&&& The bytes are right-aligned (takes the lowest significant place in big endian). \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0x7f & {\small PUSH32} & 0 & 1 & Place 32-byte (full word) item on stack. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{c}\big((\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 32) \big)$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{c}\big((\boldsymbol{\mu}_{pc} + 1) \dots (\boldsymbol{\mu}_{pc} + 32) \big)$ \\ &&&& where $\boldsymbol{c}$ is defined as above. \\ &&&& The bytes are right-aligned (takes the lowest significant place in big endian). \\ \bottomrule @@ -2149,15 +2149,15 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{80s: Duplication Operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x80 & {\small DUP1} & 1 & 2 & Duplicate 1st stack item. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \midrule 0x81 & {\small DUP2} & 2 & 3 & Duplicate 2nd stack item. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0x8f & {\small DUP16} & 16 & 17 & Duplicate 16th stack item. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[15]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[15]$ \\ \bottomrule \end{tabular*} @@ -2166,18 +2166,18 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{90s: Exchange Operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0x90 & {\small SWAP1} & 2 & 2 & Exchange 1st and 2nd stack items. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[1]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[1] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[1] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \midrule 0x91 & {\small SWAP2} & 3 & 3 & Exchange 1st and 3rd stack items. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[2]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[2] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[2]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[2] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0x9f & {\small SWAP16} & 17 & 17 & Exchange 1st and 17th stack items. \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv \boldsymbol{\mu}_\mathbf{s}[16]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[16] \equiv \boldsymbol{\mu}_\mathbf{s}[0]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \boldsymbol{\mu}_{\mathbf{s}}[16]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[16] \equiv \boldsymbol{\mu}_{\mathbf{s}}[0]$ \\ \bottomrule \end{tabular*} @@ -2185,21 +2185,21 @@ \subsection{Instruction Set} \toprule \multicolumn{5}{c}{\textbf{a0s: Logging Operations}} \vspace{5pt} \\ \multicolumn{5}{l}{For all logging operations, the state change is to append an additional log entry on to the substate's log series:}\\ -\multicolumn{5}{l}\linkdest{A l}{}{$A'_\mathbf{l} \equiv A_\mathbf{l} \cdot (I_{\mathrm{a}}, \mathbf{t}, \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots (\boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1) ])$}\\ +\multicolumn{5}{l}\linkdest{A l}{}{$A'_{\mathbf{l}} \equiv A_{\mathbf{l}} \cdot (I_{\mathrm{a}}, \mathbf{t}, \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1] - 1) ])$}\\ \multicolumn{5}{l}{and to update the memory consumption counter:}\\ -\multicolumn{5}{l}{$\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$}\\ +\multicolumn{5}{l}{$\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$}\\ \multicolumn{5}{l}{The entry's topic series, $\mathbf{t}$, differs accordingly:}\vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xa0 & {\small LOG0} & 2 & 0 & Append log record with no topics. \\ &&&& $\mathbf{t} \equiv ()$ \\ \midrule 0xa1 & {\small LOG1} & 3 & 0 & Append log record with one topic. \\ -&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_\mathbf{s}[2])$ \\ +&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ \midrule \multicolumn{1}{c}{\vdots} & \multicolumn{1}{c}{\vdots} & \vdots & \vdots & \multicolumn{1}{c}{\vdots} \\ \midrule 0xa4 & {\small LOG4} & 6 & 0 & Append log record with four topics. \\ -&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4], \boldsymbol{\mu}_\mathbf{s}[5])$ \\ +&&&& $\mathbf{t} \equiv (\boldsymbol{\mu}_{\mathbf{s}}[2], \boldsymbol{\mu}_{\mathbf{s}}[3], \boldsymbol{\mu}_{\mathbf{s}}[4], \boldsymbol{\mu}_{\mathbf{s}}[5])$ \\ \bottomrule \end{tabular*} @@ -2208,40 +2208,40 @@ \subsection{Instruction Set} \multicolumn{5}{c}{\textbf{f0s: System operations}} \vspace{5pt} \\ \textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\ 0xf0 & {\small CREATE} & 3 & 1 & Create a new account with associated code. \\ -&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[1] \dots (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_{\mathrm{g}}, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, L(\boldsymbol{\mu}_{\mathrm{g}}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathrm{g}}, \varnothing\big) & \text{otherwise} \end{cases}$ \\ +&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[1] \dots (\boldsymbol{\mu}_{\mathbf{s}}[1] + \boldsymbol{\mu}_{\mathbf{s}}[2] - 1) ]$ \\ +&&&& $(\boldsymbol{\sigma}', \boldsymbol{\mu}'_{\mathrm{g}}, A^+, \mathbf{o}) \equiv \begin{cases}\Lambda(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, L(\boldsymbol{\mu}_{\mathrm{g}}), I_{\mathrm{p}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024\\ \big(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathrm{g}}, \varnothing\big) & \text{otherwise} \end{cases}$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_{\mathrm{a}}]_{\mathrm{n}} = \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}} + 1$ \\ -&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_\mathbf{s} \equiv A_\mathbf{s} \cup A^+_\mathbf{s} \quad \wedge \quad A'_\mathbf{l} \equiv A_\mathbf{l} \cdot A^+_\mathbf{l} \quad \wedge \quad A'_\mathbf{t} \equiv A_\mathbf{t} \cup A^+_\mathbf{t}$ \\ -&&&& $ \wedge \quad A'_\mathbf{r} \equiv A_\mathbf{r} + A^+_\mathbf{r}$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ +&&&& $A' \equiv A \Cup A^+$ which abbreviates: $A'_{\mathbf{s}} \equiv A_{\mathbf{s}} \cup A^+_{\mathbf{s}} \quad \wedge \quad A'_{\mathbf{l}} \equiv A_{\mathbf{l}} \cdot A^+_{\mathbf{l}} \quad \wedge \quad A'_{\mathbf{t}} \equiv A_{\mathbf{t}} \cup A^+_{\mathbf{t}}$ \\ +&&&& $ \wedge \quad A'_{\mathbf{r}} \equiv A_{\mathbf{r}} + A^+_{\mathbf{r}}$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv x$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting}\\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$, or $I_{\mathrm{e}} = 1024$ \\ -&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_\mathbf{s}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ +&&&& (the maximum call depth limit is reached) or $\boldsymbol{\mu}_{\mathbf{s}}[0] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (balance of the caller is too \\ &&&& low to fulfil the value transfer); and otherwise $x=A(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}})$, the address of the newly \\ &&&& created account. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[2])$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{o} \equiv ()$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[1], \boldsymbol{\mu}_{\mathbf{s}}[2])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{o}} \equiv ()$ \\ &&&& Thus the operand order is: value, input offset, input size. \\ \midrule 0xf1 & {\small CALL} & 7 & 1 & Message-call into an account. \\ -&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[3] \dots (\boldsymbol{\mu}_\mathbf{s}[3] + \boldsymbol{\mu}_\mathbf{s}[4] - 1) ]$ \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_{\mathrm{a}}, I_{\mathrm{o}}, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge \\ \quad\quad I_{\mathrm{e}} < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ -&&&& $n \equiv \min(\{ \boldsymbol{\mu}_\mathbf{s}[6], |\mathbf{o}|\})$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{o} = \mathbf{o}$ \\ +&&&& $\mathbf{i} \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[3] \dots (\boldsymbol{\mu}_{\mathbf{s}}[3] + \boldsymbol{\mu}_{\mathbf{s}}[4] - 1) ]$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}, I_{\mathrm{a}}, I_{\mathrm{o}}, t, t,\\ \quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_{\mathbf{s}}[2], \boldsymbol{\mu}_{\mathbf{s}}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge \\ \quad\quad I_{\mathrm{e}} < 1024\end{array}\\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $n \equiv \min(\{ \boldsymbol{\mu}_{\mathbf{s}}[6], |\mathbf{o}|\})$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[5] \dots (\boldsymbol{\mu}_{\mathbf{s}}[5] + n - 1) ] = \mathbf{o}[0 \dots (n - 1)]$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{o}} = \mathbf{o}$ \\ &&&& $\boldsymbol{\mu}'_{\mathrm{g}} \equiv \boldsymbol{\mu}_{\mathrm{g}} + g'$ \\ -&&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ +&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ -&&&& $t \equiv \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}$ \\ +&&&& $t \equiv \boldsymbol{\mu}_{\mathbf{s}}[1] \mod 2^{160}$ \\ &&&& where $x=0$ if the code execution for this operation failed due to an \hyperlink{Exceptional_Halting_function_Z}{exceptional halting} \\ &&&& (or for a \text{\small REVERT}) $\boldsymbol{\sigma}' = \varnothing$ or if \\ -&&&& $\boldsymbol{\mu}_\mathbf{s}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ +&&&& $\boldsymbol{\mu}_{\mathbf{s}}[2] > \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}$ (not enough funds) or $I_{\mathrm{e}} = 1024$ (call depth limit reached); $x=1$ \\ &&&& otherwise. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[3], \boldsymbol{\mu}_\mathbf{s}[4]), \boldsymbol{\mu}_\mathbf{s}[5], \boldsymbol{\mu}_\mathbf{s}[6])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[3], \boldsymbol{\mu}_{\mathbf{s}}[4]), \boldsymbol{\mu}_{\mathbf{s}}[5], \boldsymbol{\mu}_{\mathbf{s}}[6])$ \\ &&&& Thus the operand order is: gas, to, value, in offset, in size, out offset, out size. \\ &&&&\linkdest{tiny CALL}{} $C_{\text{\tiny CALL}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$ \\ &&&& $C_{\text{\tiny CALLGAS}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) + G_{callstipend} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \\ C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny GASCAP}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} @@ -2250,26 +2250,26 @@ \subsection{Instruction Set} \end{cases}$\\ &&&& $C_{\text{\tiny EXTRA}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{call} + C_{\text{\tiny XFER}}(\boldsymbol{\mu}) + C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu})$\\ &&&& $C_{\text{\tiny XFER}}(\boldsymbol{\mu}) \equiv \begin{cases} -G_{callvalue} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +G_{callvalue} & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ &&&& $C_{\text{\tiny NEW}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} -G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_\mathbf{s}[2] \neq 0 \\ +G_{newaccount} & \text{if} \quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathbf{s}}[1] \mod 2^{160}) \wedge \boldsymbol{\mu}_{\mathbf{s}}[2] \neq 0 \\ 0 & \text{otherwise} \end{cases}$ \\ \midrule 0xf2 & {\small CALLCODE} & 7 & 1 & Message-call into this account with an alternative account's code. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_\mathbf{s}[2], \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_\mathbf{s}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\\ \quad\quad{}I_{\mathrm{e}} < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ -&&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_\mathbf{s}[1]$\\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{a}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad C_{\text{\tiny CALLGAS}}(\boldsymbol{\mu}), I_{\mathrm{p}}, \boldsymbol{\mu}_{\mathbf{s}}[2], \boldsymbol{\mu}_{\mathbf{s}}[2], \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \begin{array}{l}\text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[2] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\\ \quad\quad{}I_{\mathrm{e}} < 1024\end{array} \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& Note the change in the fourth parameter to the call $\Theta$ from the 2nd stack value $\boldsymbol{\mu}_{\mathbf{s}}[1]$\\ &&&& (as in {\small CALL}) to the present address $I_{\mathrm{a}}$. This means that the recipient is in fact the\\ &&&& same account as at present, simply that the code is overwritten.\\ \midrule \linkdest{RETURN}{}0xf3 & {\small RETURN} & 2 & 0 & Halt execution returning output data. \\ -&&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[0] \dots ( \boldsymbol{\mu}_\mathbf{s}[0] + \boldsymbol{\mu}_\mathbf{s}[1] - 1 ) ]$ \\ +&&&& $H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots ( \boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[1] - 1 ) ]$ \\ &&&& This has the effect of halting the execution at this point with output defined.\\ &&&& See section \ref{ch:model}. \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$ \\ \end{tabular*} \begin{tabular*}{\columnwidth}[h]{rlrrl} @@ -2277,10 +2277,10 @@ \subsection{Instruction Set} 0xf4 & {\small DELEGATECALL} & 6 & 1 & Message-call into this account with an alternative account's code, but persisting\\ &&&& the current values for {\it sender} and {\it value}. \\ &&&& Compared with {\small CALL}, {\small DELEGATECALL} takes one fewer arguments. The omitted\\ -&&&& argument is $\boldsymbol{\mu}_\mathbf{s}[2]$. As a result, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ in the definition of {\small CALL} \\ -&&&& should respectively be replaced with $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ +&&&& argument is $\boldsymbol{\mu}_{\mathbf{s}}[2]$. As a result, $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$, $\boldsymbol{\mu}_{\mathbf{s}}[5]$ and $\boldsymbol{\mu}_{\mathbf{s}}[6]$ in the definition of {\small CALL} \\ +&&&& should respectively be replaced with $\boldsymbol{\mu}_{\mathbf{s}}[2]$, $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$ and $\boldsymbol{\mu}_{\mathbf{s}}[5]$. \\ &&&& Otherwise exactly equivalent to {\small CALL} except: \\ -&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{s}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad \boldsymbol{\mu}_\mathbf{s}[0], I_{\mathrm{p}}, 0, I_{\mathrm{v}}, \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \text{if} \quad I_{\mathrm{v}} \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ +&&&& $(\boldsymbol{\sigma}', g', A^+, \mathbf{o}) \equiv \begin{cases}\begin{array}{l}\Theta(\boldsymbol{\sigma}^*, I_{\mathrm{s}}, I_{\mathrm{o}}, I_{\mathrm{a}}, t,\\\quad \boldsymbol{\mu}_{\mathbf{s}}[0], I_{\mathrm{p}}, 0, I_{\mathrm{v}}, \mathbf{i}, I_{\mathrm{e}} + 1, I_{\mathrm{w}})\end{array} & \text{if} \quad I_{\mathrm{v}} \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \;\wedge\; I_{\mathrm{e}} < 1024 \\ (\boldsymbol{\sigma}, g, \varnothing, ()) & \text{otherwise} \end{cases}$ \\ &&&& Note the changes (in addition to that of the fourth parameter) to the second \\ &&&& and ninth parameters to the call $\Theta$.\\ &&&& This means that the recipient is in fact the same account as at present, simply\\ @@ -2288,15 +2288,15 @@ \subsection{Instruction Set} \midrule 0xfa & {\small STATICCALL} & 6 & 1 & Static message-call into an account. \\ &&&& Exactly equivalent to {\small CALL} except: \\ -&&&& The argument $\boldsymbol{\mu}_\mathbf{s}[2]$ is replaced with $0$. \\ -&&&& The deeper argument $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$, $\boldsymbol{\mu}_\mathbf{s}[5]$ and $\boldsymbol{\mu}_\mathbf{s}[6]$ are respectively replaced with \\ -&&&& $\boldsymbol{\mu}_\mathbf{s}[2]$, $\boldsymbol{\mu}_\mathbf{s}[3]$, $\boldsymbol{\mu}_\mathbf{s}[4]$ and $\boldsymbol{\mu}_\mathbf{s}[5]$. \\ +&&&& The argument $\boldsymbol{\mu}_{\mathbf{s}}[2]$ is replaced with $0$. \\ +&&&& The deeper argument $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$, $\boldsymbol{\mu}_{\mathbf{s}}[5]$ and $\boldsymbol{\mu}_{\mathbf{s}}[6]$ are respectively replaced with \\ +&&&& $\boldsymbol{\mu}_{\mathbf{s}}[2]$, $\boldsymbol{\mu}_{\mathbf{s}}[3]$, $\boldsymbol{\mu}_{\mathbf{s}}[4]$ and $\boldsymbol{\mu}_{\mathbf{s}}[5]$. \\ &&&& The last argument of $\Theta$ is $\bot$. \\ \midrule 0xfd & {\small REVERT} & 2 & 0 & Halt execution reverting state changes but returning data and remaining gas. \\ &&&& The effect of this operation is described in (\ref{eq:X-def}). \\ &&&& For the gas calculation, we use the memory expansion function, \\ -&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_\mathbf{s}[0], \boldsymbol{\mu}_\mathbf{s}[1])$ \\ +&&&& $\boldsymbol{\mu}'_{\mathrm{i}} \equiv M(\boldsymbol{\mu}_{\mathrm{i}}, \boldsymbol{\mu}_{\mathbf{s}}[0], \boldsymbol{\mu}_{\mathbf{s}}[1])$ \\ \midrule 0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\ \midrule @@ -2304,20 +2304,20 @@ \subsection{Instruction Set} &&&& $A'_{\mathbf{s}} \equiv A_{\mathbf{s}} \cup \{ I_{\mathrm{a}} \}$ \\ &&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[r] = \varnothing\ \wedge\ \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} = 0\\ -(\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\ r \neq I_{\mathrm{a}} \\ -(\boldsymbol{\sigma}[r]_{\mathrm{n}}, 0, \boldsymbol{\sigma}[r]_\mathbf{s}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{otherwise} +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, \boldsymbol{\sigma}[r]_{\mathrm{b}} + \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}}, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\ r \neq I_{\mathrm{a}} \\ +(\boldsymbol{\sigma}[r]_{\mathrm{n}}, 0, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{otherwise} \end{cases}$\\ -&&&& where $r = \boldsymbol{\mu}_\mathbf{s}[0] \bmod 2^{160}$\\ +&&&& where $r = \boldsymbol{\mu}_{\mathbf{s}}[0] \bmod 2^{160}$\\ &&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathrm{b}} = 0$ \\ &&&& $A'_{r} \equiv A_{r} + \begin{cases} -R_{selfdestruct} & \text{if} \quad I_{\mathrm{a}} \notin A_\mathbf{s} \\ +R_{selfdestruct} & \text{if} \quad I_{\mathrm{a}} \notin A_{\mathbf{s}} \\ 0 & \text{otherwise} \end{cases}$ \\ &&&&\linkdest{C tiny SELFDESTRUCT}{} $C_{\text{\tiny SELFDESTRUCT}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv G_{selfdestruct} + \begin{cases} G_{newaccount} & \text{if} \quad n \\ 0 & \text{otherwise} \end{cases}$ \\ -&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_\mathbf{s}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \neq 0$ \\ +&&&& $n \equiv \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, \boldsymbol{\mu}_{\mathbf{s}}[0] \mod 2^{160}) \wedge \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \neq 0$ \\ \bottomrule \end{tabular*} From 758675b5058dbd80757f645447a5420afc8bb8cb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:38:38 +1100 Subject: [PATCH 379/460] \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..4ef05bd2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -177,7 +177,7 @@ \section{Conventions}\label{ch:conventions} For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. -Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. +Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$}, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a transaction nonce. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. From b5101c5103d62b919b62912201540cf14028a95b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 11:43:04 +1100 Subject: [PATCH 380/460] 2 more \hyperlink{transaction_nonce}{transaction nonce} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4ef05bd2..01a38ca6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -179,7 +179,7 @@ \section{Conventions}\label{ch:conventions} Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$}, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. -Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a transaction nonce. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. +Scalars and fixed-size byte sequences (or, synonymously, arrays) are denoted with a normal lower-case letter, \eg $n$ is used in the document to denote a \hyperlink{transaction_nonce}{transaction nonce}. Those with a particularly special meaning may be Greek, \eg $\delta$, the number of items required on the stack for a given operation. Arbitrary-length sequences are typically denoted as a bold lower-case letter, \eg $\mathbf{o}$ is used to denote the byte sequence given as the output data of a message call. For particularly important values, a bold uppercase letter may be used. @@ -560,7 +560,7 @@ \section{Transaction Execution} \label{ch:transactions} \begin{enumerate} \item The transaction is well-formed RLP, with no additional trailing bytes; \item the transaction signature is valid; -\item the transaction nonce is valid (equivalent to the sender account's current nonce); +\item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the sender account's current nonce); \item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} From 32fa4bb5b38d7bc4c7a388d46140c69adbd7b500 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:14:53 +1100 Subject: [PATCH 381/460] hyperlinks for state transition functions --- Paper.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..db01e1f2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -128,12 +128,12 @@ \section{The Blockchain Paradigm} \label{ch:overview} Formally, we expand to: \begin{eqnarray} -\boldsymbol{\sigma}_{t+1} & \equiv & \Pi(\boldsymbol{\sigma}_{t}, B) \\ +\boldsymbol{\sigma}_{t+1} & \equiv & \hyperlink{Pi}{\Pi}(\boldsymbol{\sigma}_{t}, B) \\ B & \equiv & (..., (T_0, T_1, ...) ) \\ -\Pi(\boldsymbol{\sigma}, B) & \equiv & \Omega(B, \Upsilon(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) +\Pi(\boldsymbol{\sigma}, B) & \equiv & \hyperlink{Omega}{\Omega}(B, \hyperlink{Upsilon}{\Upsilon}(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \end{eqnarray} -Where $\Omega$ is the block-finalisation state transition function (a function that rewards a nominated party); $B$ is this block, which includes a series of transactions amongst some other components; and $\Pi$ is the block-level state-transition function. +Where \hyperlink{Omega}{$\Omega$} is the block-finalisation state transition function (a function that rewards a nominated party); \linkdest{block}{$B$} is this block, which includes a series of transactions amongst some other components; and $\hyperlink{Pi}{\Pi}$ is the block-level state-transition function. This is the basis of the blockchain paradigm, a model that forms the backbone of not only Ethereum, but all decentralised consensus-based transaction systems to date. @@ -319,7 +319,7 @@ \subsection{The Transaction} \label{ch:transaction} \mathbb{B}_{0} & \text{otherwise}\end{cases} \end{equation} -\subsection{The Block} \label{ch:block} +\subsection{The Block} \linkdest{block}{} The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (not saying much) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: @@ -565,7 +565,7 @@ \section{Transaction Execution} \label{ch:transactions} \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} -Formally, we consider the function $\Upsilon$, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: +Formally, we consider the function \hyperlink{Upsilon}{$\Upsilon$}, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: \begin{equation} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} From 43bb09e4263b3cbde042bfba68bb6009c2b27fdb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:28:40 +1100 Subject: [PATCH 382/460] \hyperlink{Upsilon_state_transition}{$\Upsilon$} --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..0cdd3e4f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -173,7 +173,7 @@ \section{Conventions}\label{ch:conventions} The two sets of highly structured, `top-level', state values, are denoted with bold lowercase Greek letters. They fall into those of world-state, which are denoted $\boldsymbol{\sigma}$ (or a variant thereupon) and those of machine-state, $\boldsymbol{\mu}$. -Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. +Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the Ethereum state transition function. For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. @@ -555,7 +555,7 @@ \section{Gas and Payment} \label{ch:payment} \section{Transaction Execution} \label{ch:transactions} -The execution of a transaction is the most complex part of the Ethereum protocol: it defines the state transition function $\Upsilon$. It is assumed that any transactions executed first pass the initial tests of intrinsic validity. These include: +The execution of a transaction is the most complex part of the Ethereum protocol: it defines the state transition function \hyperlink{Upsilon_state_transition}{$\Upsilon$}. It is assumed that any transactions executed first pass the initial tests of intrinsic validity. These include: \begin{enumerate} \item The transaction is well-formed RLP, with no additional trailing bytes; @@ -565,7 +565,7 @@ \section{Transaction Execution} \label{ch:transactions} \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} -Formally, we consider the function $\Upsilon$, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: +Formally, we consider the function \hyperlink{Upsilon_state_transition}{$\Upsilon$}, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state: \begin{equation} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} @@ -1150,7 +1150,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. -As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and $\Upsilon$, the transaction-evaluation function, both now well-defined. +As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_\mathbf{l}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} From 340085d8e2599624b3f96fdd9dc07807a751bb46 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:34:19 +1100 Subject: [PATCH 383/460] \hyperlink{C__SSTORE} \hyperlink{SSTORE} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..29844d4e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -175,7 +175,7 @@ \section{Conventions}\label{ch:conventions} Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg \hyperlink{C__SSTORE}{$C_\text{SSTORE}$}, the cost function for the \hyperlink{SSTORE}{{\tiny SSTORE}} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. @@ -2086,7 +2086,7 @@ \subsection{Instruction Set} \midrule \linkdest{SSTORE}{}0x55 & {\small SSTORE} & 2 & 0 & Save word to storage. \\ &&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_\mathbf{s}[ \boldsymbol{\mu}_\mathbf{s}[0] ] \equiv \boldsymbol{\mu}_\mathbf{s}[1] $ \\ -&&&&\linkdest{C tiny SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} +&&&&\linkdest{C__SSTORE}{} $C_{\text{\tiny SSTORE}}(\boldsymbol{\sigma}, \boldsymbol{\mu}) \equiv \begin{cases} G_{sset} & \text{if} \quad \boldsymbol{\mu}_\mathbf{s}[1] \neq 0 \; \wedge \; \boldsymbol{\sigma}[I_{\mathrm{a}}]_\mathbf{s}[\boldsymbol{\mu}_\mathbf{s}[0]] = 0 \\ G_{sreset} & \text{otherwise} \end{cases}$ \\ From 06cfdd5c9583e03836b8a991707f829a75d8dcc8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:38:20 +1100 Subject: [PATCH 384/460] \cite{Keccak} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..ac5dc9ef 100644 --- a/Paper.tex +++ b/Paper.tex @@ -175,7 +175,7 @@ \section{Conventions}\label{ch:conventions} Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest, rather than later releases, by \cite{Keccak}) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. From c2a99a6c395e86a3efbe8ed237e81af8f940e53a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:40:03 +1100 Subject: [PATCH 385/460] @misc{Keccak --- Biblio.bib | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Biblio.bib b/Biblio.bib index 8f6a90f6..b29e71cf 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,3 +1,15 @@ +@misc{Keccak, + url = "https://keccak.team/keccak.html", + note = "Accessed 6 October 2017. Unable to be archived by the Wayback Machine.", + author = "Guido Bertoni +and Joan Daemen +and Michaël Peeters +and Gilles Van Assche +and Ronny Van Keer", + title = {{KECCAK}}, + year = "2017", +} + @Book{Davey2002_zbMATH01748069, Author = {B.A. {Davey} and H.A. {Priestley}}, Title = {{Introduction to lattices and order. 2nd ed.}}, From 30d234935346fde99b8dacdd4741209486f27cea Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 12:56:09 +1100 Subject: [PATCH 386/460] Add missing closing braces --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 4f1d9d97..a24be0e9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1685,11 +1685,11 @@ \section{Signing Transactions}\label{app:signing} (T_w, T_r, T_s) = \mathtt{\small ECDSASIGN}(h(T), p_r) \end{eqnarray} -Reiterating from \hyperlink{T__w_T__r_T__s}{previously}: +\hyperlink{T__w_T__r_T__s}{Reiterating from previously}: \begin{eqnarray} \linkdest{T__w}{T_{\mathrm{w}}} = \hyperlink{v}{v}\\ -\linkdest{T__r}{T_{\mathrm{r}} = \hyperlink{r}{r}\\ -\linkdest{T__s}{T_{\mathrm{s}} = \hyperlink{s}{s} +\linkdest{T__r}{T_{\mathrm{r}}} = \hyperlink{r}{r}\\ +\linkdest{T__s}{T_{\mathrm{s}}} = \hyperlink{s}{s} \end{eqnarray} We may then define the sender function $S$ of the transaction as: From 5a0c9091ece5805c11b93863c4545b9db277edc9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 14:04:01 +1100 Subject: [PATCH 387/460] Update @article to @misc when there is no journal field --- Biblio.bib | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Biblio.bib b/Biblio.bib index 8f6a90f6..d62c86de 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -98,14 +98,14 @@ @Article{aron2012bitcoin year = {{2012}}, } -@article{mastercoin2013willett, +@misc{mastercoin2013willett, url = {{https://github.com/mastercoin-MSC/spec}}, author = {J. R. Willett}, title = {{MasterCoin Complete Specification}}, year = {{2013}}, } -@article{colouredcoins2012rosenfeld, +@misc{colouredcoins2012rosenfeld, url = {{https://bitcoil.co.il/BitcoinX.pdf}}, author = {Meni Rosenfeld}, title = {{Overview of Colored Coins}}, @@ -137,42 +137,42 @@ @InProceedings{miller1997future year = {{1997}}, } -@article{buterin2013ethereum, +@misc{buterin2013ethereum, url = {{https://github.com/ethereum/wiki/wiki/White-Paper}}, author = {Vitalik Buterin}, title = {{Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform}}, year = {{2013}}, } -@article{back2002hashcash, +@misc{back2002hashcash, url = {{http://www.hashcash.org/papers/amortizable.pdf}}, author = {Adam Back}, title = {{Hashcash - Amortizable Publicly Auditable Cost-Functions}}, year = {{2002}}, } -@article{hashimoto, +@misc{hashimoto, url = {{https://mirrorx.com/files/hashimoto.pdf}}, author = {Thaddeus Dryja}, title = {{Hashimoto: I/O bound proof of work}}, year = {{2014}}, } -@article{dagger, +@misc{dagger, url = {{http://vitalik.ca/ethereum/dagger.html}}, author = {Vitalik Buterin}, title = {{Dagger: A Memory-Hard to Compute, Memory-Easy to Verify Scrypt Alternative}}, year = {{2013}}, } -@article{lerner2014randmemohash, +@misc{lerner2014randmemohash, url = {{http://www.hashcash.org/papers/memohash.pdf}}, author = {Sergio Demian Lerner}, title = {{Strict Memory Hard Hashing Functions}}, year = {{2014}}, } -@article{FowlerNollVo1991FNVHash, +@misc{FowlerNollVo1991FNVHash, url = {{https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#cite_note-2}}, author = {Glenn Fowler, Landon Curt Noll, Phong Vo}, title = {{Fowler–Noll–Vo hash function}}, From e075f7b328464333b360ddaf1131bd223a835b5e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 14:42:49 +1100 Subject: [PATCH 388/460] Test: Swap bibliographystyle and bibliography --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a0cc57d4..51701597 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1250,8 +1250,8 @@ \section{Availability} The source of this paper is maintained at \url{https://github.com/ethereum/yellowpaper/}. An auto-generated PDF is located at \url{https://ethereum.github.io/yellowpaper/paper.pdf}. -\bibliography{Biblio} \bibliographystyle{plainnat} +\bibliography{Biblio} \end{multicols} From 472014356dcd0af9cf71f20f8cda6b9d25eee176 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 15:47:15 +1100 Subject: [PATCH 389/460] Change some {{...}} to "..." --- Biblio.bib | 64 +++++++++++++++++++++++++++--------------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/Biblio.bib b/Biblio.bib index 8f6a90f6..48b6f8c8 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -1,20 +1,20 @@ @Book{Davey2002_zbMATH01748069, - Author = {B.A. {Davey} and H.A. {Priestley}}, - Title = {{Introduction to lattices and order. 2nd ed.}}, - Edition = {2nd ed.}, - ISBN = {0-521-78451-4/pbk}, - Pages = {xii + 298}, - Year = {2002}, - Publisher = {Cambridge: Cambridge University Press}, - Language = {English}, - MSC2010 = {06-01}, - Zbl = {1002.06001}, + Author = "B.A. {Davey} and H.A. {Priestley}", + Title = "Introduction to lattices and order. 2nd ed.", + Edition = "2nd ed.", + ISBN = "0-521-78451-4/pbk", + Pages = "xii + 298", + Year = "2002", + Publisher = "Cambridge: Cambridge University Press", + Language = "English", + MSC2010 = "06-01", + Zbl = "1002.06001", } @Misc{EIP-100, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md", author = "Vitalik Buterin", - title = "EIP-100: Change difficulty adjustment to target mean block time including uncles", + title = "{EIP}-100: Change difficulty adjustment to target mean block time including uncles", year = "2016", month = "April", } @@ -22,50 +22,50 @@ @Misc{EIP-100 @Misc{EIP-649, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-649.md", author = "Afri Schoedon and Vitalik Buterin", - title = "EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", + title = "{EIP}-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction", year = "2017", month = "June", } @Misc{EIP-2, url = "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md", - title = "EIP-2: Homestead Hard-fork Changes", + title = "{EIP}-2: Homestead Hard-fork Changes", author = "Vitalik Buterin", year = "2015", } @Misc{cryptoeprint:2013:881, - Note = {{http://eprint.iacr.org/}}, - Url = {{Cryptology ePrint Archive, Report 2013/881}}, - author = {Sompolinsky, Yonatan and Zohar, Aviv}, - title = {{Accelerating Bitcoin{'}s Transaction Processing. Fast Money Grows on Trees, Not Chains}}, - year = {{2013}}, + Note = "\url{http://eprint.iacr.org/}", + Url = "Cryptology ePrint Archive, Report 2013/881", + author = "Sompolinsky, Yonatan and Zohar, Aviv", + title = "Accelerating Bitcoin{'}s Transaction Processing. Fast Money Grows on Trees, Not Chains", + year = "2013", } @InCollection{gura2004comparing, - BookTitle = {{Cryptographic Hardware and Embedded Systems-CHES 2004}}, - Publisher = {{Springer}}, - author = {Gura, Nils and Patel, Arun and Wander, Arvinderpal and Eberle, Hans and Shantz, Sheueling Chang}, - title = {{Comparing elliptic curve cryptography and RSA on 8-bit CPUs}}, - pages = {119-132}, - year = {{2004}}, + BookTitle = "Cryptographic Hardware and Embedded Systems-CHES 2004", + Publisher = "Springer", + author = "Gura, Nils and Patel, Arun and Wander, Arvinderpal and Eberle, Hans and Shantz, Sheueling Chang", + title = "Comparing elliptic curve cryptography and {RSA} on 8-bit {CPUs}", + pages = "119-132", + year = "2004", } @InProceedings{laurie2004proof, - BookTitle = {{Workshop on Economics and Information, Security}}, - author = {Laurie, Ben and Clayton, Richard}, - title = {{Proof-of-Work{''} proves not to work; version 0.2}}, - year = {{2004}}, + BookTitle = "Workshop on Economics and Information, Security", + author = "Laurie, Ben and Clayton, Richard", + title = "{``}Proof-of-Work{''} proves not to work; version 0.2", + year = "2004", } @Misc{vishnumurthy03karma:a, - author = {Vivek Vishnumurthy and Sangeeth Chandrakumar and Emin Gün Sirer}, - title = {KARMA: A Secure Economic Framework for Peer-to-Peer Resource Sharing}, - year = {2003} + author = "Vivek Vishnumurthy and Sangeeth Chandrakumar and Emin Gün Sirer", + title = "{KARMA}: A Secure Economic Framework for Peer-to-Peer Resource Sharing", + year = "2003" } @InProceedings{dwork92pricingvia, - author = {Cynthia Dwork and Moni Naor}, + author = "Cynthia Dwork and Moni Naor}, title = {Pricing via processing or combatting junk mail}, booktitle = {In 12th Annual International Cryptology Conference}, year = {1992}, From ca555b5389973121f48b4f9ae0df7c93bd771ddc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 15:54:38 +1100 Subject: [PATCH 390/460] Tips on editing, headings --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 725059d9..752018df 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,13 @@ cd yellowpaper ``` This will create a PDF version of the Yellow Paper. Following building, you can also use standard `pdflatex` tools like http://latex.informatik.uni-halle.de/latex-online/latex.php for compiling/preview. +## Tips on editing + +You can use [TeX Stack Exchange](https://tex.stackexchange.com/); https://en.wikibooks.org/wiki/LaTeX/ (e.g. [Bibliography Management](https://en.wikibooks.org/wiki/LaTeX/Bibliography_Management) and [Hyperlinks](https://en.wikibooks.org/wiki/LaTeX/Hyperlinks)); and [BibTeX editor](http://truben.no/latex/bibtex/). + +## Versions + The previous protocol versions are listed in [BRANCHES.md](./BRANCHES.md). -## Other language versions +### Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu. From 41ab50b97d2cdf3eeb92bd2ea371e7bec52a1e84 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Mon, 5 Feb 2018 17:20:15 +1100 Subject: [PATCH 391/460] Replaced an unbalanced brace with a double quote --- Biblio.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Biblio.bib b/Biblio.bib index 48b6f8c8..512304fb 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -65,7 +65,7 @@ @Misc{vishnumurthy03karma:a } @InProceedings{dwork92pricingvia, - author = "Cynthia Dwork and Moni Naor}, + author = "Cynthia Dwork and Moni Naor", title = {Pricing via processing or combatting junk mail}, booktitle = {In 12th Annual International Cryptology Conference}, year = {1992}, From 1a0c22474b109e36707257d5368e80ea2a34cefa Mon Sep 17 00:00:00 2001 From: Li Xuanji Date: Wed, 7 Feb 2018 15:39:15 -0500 Subject: [PATCH 392/460] Cleanup ECREC definition and a few other things --- Paper.tex | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..a8865bfb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -26,7 +26,7 @@ %This should be the last package before \input{Version.tex} \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} -% "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . +% "hyperref loads the url package internally. Use \PassOptionsToPackage{hyphens}{url}\usepackage{hyperref} to pass the option to the url package when it is loaded by hyperref. This avoids any package option clashes." Source: . % Note also this: "If the \PassOptionsToPackage{hyphens}{url} approach does not work, maybe it's "because you're trying to load the url package with a specific option, but it's being loaded by one of your packages before that with a different set of options. Try loading the url package earlier than the package that requires it. If it's loaded by the document class, try using \RequirePackage[hyphens]{url} before the document class." Source: . % For more information on using the hyperref package, refer to e.g. https://en.wikibooks.org/w/index.php?title=LaTeX/Hyperlinks&stable=0#Hyperlink_and_Hypertarget. @@ -115,7 +115,7 @@ \subsection{Previous Work} \label{ch:previous} \section{The Blockchain Paradigm} \label{ch:overview} -Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: +Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} \linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \end{equation} @@ -1148,6 +1148,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) \end{eqnarray} + With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. @@ -1453,7 +1454,8 @@ \section{Precompiled Contracts}\label{app:precompiled} The precompiled contracts each use these definitions and provide specifications for the $\mathbf{o}$ (the output data) and $g_{\mathrm{r}}$, the gas requirements. -For the elliptic curve DSA recover VM execution function, we also define $\mathbf{d}$ to be the input data, well-defined for an infinite length by appending zeroes as required. Importantly in the case of an invalid signature ($\mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing$), then we have no output. +We define $\Xi_{\mathtt{ERCEC}}$ as a precompiled contract for the elliptic curve digital signature algorithm (ECDSA) public key recovery function (ecrecover). See \ref{app:signing} for the definition of the function $\mathtt{\tiny ECDSARECOVER}$. We also define $\mathbf{d}$ to be the input data, well-defined for an infinite length by appending zeroes as required. In the case of an invalid signature ($\mathtt{\tiny ECDSARECOVER}(h, v, r, s) = \varnothing$), we return no output. + \begin{eqnarray} \Xi_{\mathtt{ECREC}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_{\mathrm{r}} &=& 3000\\ @@ -1469,7 +1471,8 @@ \section{Precompiled Contracts}\label{app:precompiled} s &=& \mathbf{d}[96..127] \end{eqnarray} -The two hash functions, RIPEMD-160 and SHA2-256 are more trivially defined as an almost pass-through operation. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. +We define $\Xi_{\mathtt{SHA256}}$ and $\Xi_{\mathtt{RIP160}}$ as precompiled contracts implementing the SHA2-256 and RIPEMD-160 hash functions respectively. Their gas usage is dependent on the input data size, a factor rounded up to the nearest number of words. + \begin{eqnarray} \Xi_{\mathtt{SHA256}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_{\mathrm{r}} &=& 60 + 12\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ @@ -1477,10 +1480,11 @@ \section{Precompiled Contracts}\label{app:precompiled} \Xi_{\mathtt{RIP160}} &\equiv& \Xi_{\mathtt{PRE}} \quad \text{where:} \\ g_{\mathrm{r}} &=& 600 + 120\Big\lceil \dfrac{|I_{\mathbf{d}}|}{32} \Big\rceil\\ \mathbf{o}[0..11] &=& 0 \\ -\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_{\mathbf{d}})\\ +\mathbf{o}[12..31] &=& \mathtt{\tiny RIPEMD160}(I_{\mathbf{d}}) \end{eqnarray} For the purposes here, we assume we have well-defined standard cryptographic functions for RIPEMD-160 and SHA2-256 of the form: + \begin{eqnarray} \mathtt{\small SHA256}(\mathbf{i} \in \mathbb{B}) & \equiv & o \in \mathbb{B}_{32} \\ \mathtt{\small RIPEMD160}(\mathbf{i} \in \mathbb{B}) & \equiv & o \in \mathbb{B}_{20} @@ -1603,7 +1607,7 @@ \subsection{zkSNARK Related Precompiled Contracts} y_1&\equiv&\delta_{\mathrm{p}}(\mathbf x[96..127]) \end{eqnarray} -We define a precompiled contract for zkSNARK verification. +We define $\Xi_{\mathtt{SNARKV}}$ as a precompiled contract for zkSNARK verification. \begin{eqnarray} \Xi_{\mathtt{SNARKV}}&\equiv&\Xi_{\mathtt{PRE}}\quad\text{except:}\\ \qquad\Xi_{\mathtt{SNARKV}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ F\\ @@ -1623,6 +1627,7 @@ \subsection{zkSNARK Related Precompiled Contracts} \end{eqnarray} We define a precompiled contract for addition on $G_1$. + \begin{eqnarray} \Xi_{\mathtt{BN\_ADD}}&\equiv&\Xi_{\mathtt{BN\_PRE}}\quad\text{except:}\\ \Xi_{\mathtt{BN\_ADD}}(\boldsymbol\sigma,g,I)&=&(\varnothing,0,A^0,())\quad\text{if}\ x=\varnothing\vee y=\varnothing\\ @@ -1652,7 +1657,7 @@ \section{Signing Transactions}\label{app:signing} It is assumed that the sender has a valid private key $p_{\mathrm{r}}$, which is a randomly selected positive integer (represented as a byte array of length 32 in big-endian form) in the range \hbox{$[1, \mathtt{\tiny secp256k1n} - 1]$}. -We assert the functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. +We assume the existence of functions $\mathtt{\small ECDSASIGN}$, $\mathtt{\small ECDSARECOVER}$ and $\mathtt{\small ECDSAPUBKEY}$. These are formally defined in the literature. \begin{eqnarray} \mathtt{\small ECDSAPUBKEY}(p_{\mathrm{r}} \in \mathbb{B}_{32}) & \equiv & p_{\mathrm{u}} \in \mathbb{B}_{64} \\ \linkdest{ECDSASIGN}{}\mathtt{\small ECDSASIGN}(e \in \mathbb{B}_{32}, p_{\mathrm{r}} \in \mathbb{B}_{32}) & \equiv & (v \in \mathbb{B}_{1}, r \in \mathbb{B}_{32}, s \in \mathbb{B}_{32}) \\ @@ -1734,7 +1739,7 @@ \section{Fee Schedule}\label{app:fees} $G_{jumpdest}$ & 1 & Paid for a {\small JUMPDEST} operation. \\ $G_{sset}$ & 20000 & Paid for an {\small SSTORE} operation when the storage value is set to non-zero from zero. \\ $G_{sreset}$ & 5000 & Paid for an {\small SSTORE} operation when the storage value's zeroness remains unchanged or is set to zero. \\ -$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. +$R_{sclear}$ & 15000 & Refund given (added into refund counter) when the storage value is set to zero from non-zero. \linkdest{R__selfdestruct}{}\\$R_{selfdestruct}$ & 24000 & Refund given (added into refund counter) for self-destructing an account. \\ \linkdest{G__selfdestruct}{}$G_{selfdestruct}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\ $G_{create}$ & 32000 & Paid for a {\small CREATE} operation. \\ From c7dab56457a1138db6a88a27c4f73cdd06ed0726 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 11:40:55 +1100 Subject: [PATCH 393/460] Remove an extra } --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index b6b5f8f6..e4f0960f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -345,7 +345,7 @@ \subsection{The Block} \label{ch:block} \linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are simply a list of ommer block headers (of the same format as above), $B_{\mathbf{U}}$ and a series of the transactions, $B_{\mathbf{T}}$. Formally, we can refer to a block $B$: \begin{equation} -B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}}) +B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}) \end{equation} \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} From b4c8a4987e20317705496f6ac8bc86236cedb22d Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 11:44:05 +1100 Subject: [PATCH 394/460] ref{ch:block} => \hyperlink{block} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index db01e1f2..a68d25e6 100644 --- a/Paper.tex +++ b/Paper.tex @@ -183,7 +183,7 @@ \section{Conventions}\label{ch:conventions} Arbitrary-length sequences are typically denoted as a bold lower-case letter, \eg $\mathbf{o}$ is used to denote the byte sequence given as the output data of a message call. For particularly important values, a bold uppercase letter may be used. -Throughout, we assume scalars are positive integers and thus belong to the set $\mathbb{P}$. The set of all byte sequences is $\mathbb{B}$, formally defined in Appendix \ref{app:rlp}. If such a set of sequences is restricted to those of a particular length, it is denoted with a subscript, thus the set of all byte sequences of length $32$ is named $\mathbb{B}_{32}$ and the set of all positive integers smaller than $2^{256}$ is named $\mathbb{P}_{256}$. This is formally defined in section \ref{ch:block}. +Throughout, we assume scalars are positive integers and thus belong to the set $\mathbb{P}$. The set of all byte sequences is $\mathbb{B}$, formally defined in Appendix \ref{app:rlp}. If such a set of sequences is restricted to those of a particular length, it is denoted with a subscript, thus the set of all byte sequences of length $32$ is named $\mathbb{B}_{32}$ and the set of all positive integers smaller than $2^{256}$ is named $\mathbb{P}_{256}$. This is formally defined in section \hyperlink{block}. Square brackets are used to index into and reference individual components or subsequences of sequences, \eg $\boldsymbol{\mu}_\mathbf{s}[0]$ denotes the first item on the machine's stack. For subsequences, ellipses are used to specify the intended range, to include elements at both limits, \eg $\boldsymbol{\mu}_\mathbf{m}[0..31]$ denotes the first 32 items of the machine's memory. @@ -191,7 +191,7 @@ \section{Conventions}\label{ch:conventions} When considering variants of existing values, I follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, I may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. -When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. +When considering the use of existing functions, given a function $f$, the function $f^*$ denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \hyperlink{block}. I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: From 75253c317cfb354734d1f8c644ec1340610486bc Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 11:52:53 +1100 Subject: [PATCH 395/460] move by \cite{Keccak} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ac5dc9ef..311bcdb3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -175,7 +175,7 @@ \section{Conventions}\label{ch:conventions} Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg $\Upsilon$, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest, rather than later releases, by \cite{Keccak}) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg $C_\text{\tiny SSTORE}$, the cost function for the {\tiny SSTORE} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest by \cite{Keccak}, rather than later releases), is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg $T_{\mathrm{n}}$, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. From ead443b874287d6a38c291f475b0f24bae24e2dd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 12:57:49 +1100 Subject: [PATCH 396/460] Fix spacing of table of maths symbols --- Paper.tex | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..2d426e56 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,13 +2510,11 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. -\section{List of mathematical symbols}\label{app:symbols} -\begin{tabu*}{X[l]X[c]X} \savetabu{col3} +\begin{tabu*} spread 0pt{X[l] X[c] X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule $\bigvee$ & \verb|\bigvee| & This is the least upper bound, supremum, or join of all elements operated on. Thus it is the greatest element of such elements (\cite{Davey2002_zbMATH01748069}).\\ \bottomrule \end{tabu*} - \end{document} From f78721db21b028f60a6fbc47713584a3719064e5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:17:46 +1100 Subject: [PATCH 397/460] \hyperlink{bigvee}{\bigvee} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..d2034ede 100644 --- a/Paper.tex +++ b/Paper.tex @@ -386,7 +386,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} We define the Bloom filter function, $M$, to reduce a log entry into a single 256-byte hash: \begin{equation} -M(O) \equiv \bigvee_{t \in \{O_{\mathrm{a}}\} \cup O_{\mathbf{t}}} \big( M_{3:2048}(t) \big) +M(O) \equiv \hyperlink{bigvee}{\bigvee}_{t \in \{O_{\mathrm{a}}\} \cup O_{\mathbf{t}}} \big( M_{3:2048}(t) \big) \end{equation} where $M_{3:2048}$ is a specialised Bloom filter that sets three bits out of 2048, given an arbitrary byte sequence. It does this through taking the low-order 11 bits of each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence.\footnote{11 bits $= 2^{2048}$, and the low-order 11 bits is the modulo 2048 of the operand, which is in this case is "each of the first three pairs of bytes in a Keccak-256 hash of the byte sequence."} Formally: From b69b459a3868d8df567d3a80aae927b4eaff1f74 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:21:58 +1100 Subject: [PATCH 398/460] \hyperlink{Transaction Receipt} \hyperlink{Pi}{ --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..61effa40 100644 --- a/Paper.tex +++ b/Paper.tex @@ -423,7 +423,7 @@ \subsubsection{Holistic Validity} Thus $\texttt{\small TRIE}(L_{S}(\boldsymbol{\sigma}))$ is the root node hash of the Merkle Patricia tree structure containing the key-value pairs of the state $\boldsymbol{\sigma}$ with values encoded using RLP, and $P(B_{H})$ is the parent block of $B$, defined directly. -The values stemming from the computation of transactions, specifically the transaction receipts, $B_{\mathbf{R}}$, and that defined through the transactions state-accumulation function, $\Pi$, are formalised later in section \ref{sec:statenoncevalidation}. +The values stemming from the computation of transactions, specifically the \hyperlink{Transaction_Receipt}{transaction receipts}, $B_{\mathbf{R}}$, and that defined through the transaction's \hyperlink{Pi}{state-accumulation function, $\Pi$}, are formalised later in section \ref{sec:statenoncevalidation}. \subsubsection{Serialisation} From ff5abbc7c7438b6053bdbcb531d26fa163f9e8a3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:26:12 +1100 Subject: [PATCH 399/460] \hyperlink{ommer_block_headers_B__U}{B_{\mathbf{U}}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..ae93f939 100644 --- a/Paper.tex +++ b/Paper.tex @@ -430,7 +430,7 @@ \subsubsection{Serialisation} The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ -\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) +\quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(\hyperlink{ommer_block_headers_B__U}{B_{\mathbf{U}}}) \big) \end{eqnarray} \hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}With $L_T^*$ and $L_H^*$ being element-wise sequence transformations, thus: From 627a695f6850b32de273b4e2b8ff1fb7bea53e33 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:32:50 +1100 Subject: [PATCH 400/460] L_{R} hypertargets and links --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..8f703253 100644 --- a/Paper.tex +++ b/Paper.tex @@ -358,7 +358,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}}) \end{equation} -The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: +\hypertarget{transaction_receipt_preparation_function_for_RLP_serialisation}{}The function $L_{R}$ trivially prepares a transaction receipt for being transformed into an RLP-serialised byte array: \begin{equation} L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}) \end{equation} @@ -407,7 +407,7 @@ \subsubsection{Holistic Validity} \linkdest{new_state_H__r}{}H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ \linkdest{Ommer_block_hash_H__o}{}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_{\mathbf{U}}))) & \wedge \\ \linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{T}} \rVert, i \in \mathbb{P}: p(i, L_{T}(B_{\mathbf{T}}[i]))\}) & \wedge \\ -\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: p(i, L_{R}(B_{\mathbf{R}}[i]))\}) & \wedge \\ +\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: p(i, \hyperlink{transaction_receipt_preparation_function_for_RLP_serialisation}{L_{R}}(B_{\mathbf{R}}[i]))\}) & \wedge \\ \linkdest{logs_Bloom_filter_H__b}{}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_{\mathbf{R}}} \big( \mathbf{r}_{\mathrm{b}} \big) \end{array} \end{equation} @@ -427,7 +427,7 @@ \subsubsection{Holistic Validity} \subsubsection{Serialisation} -The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: +The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the \hyperlink{transacation_receipt_preparation_function_for_RLP_serialisation}{transaction receipt preparation function $L_{R}$}, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ \quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) From c285969c2eb2a0625aa9aa9777e214a41e785647 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:36:21 +1100 Subject: [PATCH 401/460] \hypertarget{block_preparation_function_for_RLP_serialization_L__B}{}\hypertarget{block_preparation_function_for_RLP_serialization_L__H}{} These aren't actually used elsewhere. --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..42803586 100644 --- a/Paper.tex +++ b/Paper.tex @@ -427,7 +427,7 @@ \subsubsection{Holistic Validity} \subsubsection{Serialisation} -The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: +\hypertarget{block_preparation_function_for_RLP_serialization_L__B}{}\hypertarget{block_preparation_function_for_RLP_serialization_L__H}{}The function $L_{B}$ and $L_{H}$ are the preparation functions for a block and block header respectively. Much like the transaction receipt preparation function $L_{R}$, we assert the types and order of the structure for when the RLP transformation is required: \begin{eqnarray} \quad L_{H}(H) & \equiv & (\begin{array}[t]{l}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}},\\ H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} \; )\end{array} \\ \quad L_{B}(B) & \equiv & \big( L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*(B_{\mathbf{U}}) \big) From a5a16769cf7f3d167ef46436710519f05ca468e6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 13:59:19 +1100 Subject: [PATCH 402/460] Links for component types (plus update elsewhere) in block and block header preparation functions. --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..be5a21b4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -334,10 +334,10 @@ \subsection{The Block} \label{ch:block} \item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. \item[logsBloom]\linkdest{logs_Bloom_def_words}{} The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally $H_{\mathrm{b}}$. \item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_{\mathrm{d}}$. -\item[number]\linkdest{block_number_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_{\mathrm{i}}$. +\item[number]\linkdest{block_number_word_def_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally \hyperlink{block_number_H__i}{$H_{\mathrm{i}}$}. \item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_{\mathrm{l}}$. \item[gasUsed]\linkdest{block_gas_used_H__g}{} A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. -\item[timestamp]\linkdest{block_timestamp_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_{\mathrm{s}}$. +\item[timestamp]\linkdest{block_timestamp_word_def_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally \hyperlink{block_timestamp_H__s}{$H_{\mathrm{s}}$}. \item[extraData]\linkdest{block_extraData_H__x}{} An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_{\mathrm{x}}$. \item[mixHash]\linkdest{mixHash_H__m}{} A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{m}}$. \item[nonce]\linkdest{block_nonce_H__n}{} A 64-bit hash which, combined with the mix-hash, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{n}}$. @@ -441,11 +441,11 @@ \subsubsection{Serialisation} The component types are defined thus: \begin{equation} \begin{array}[t]{lclclcl} -H_{\mathrm{p}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ -H_{\mathrm{r}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{e}} \in \mathbb{B}_{32} & \wedge \\ -H_{\mathrm{b}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{P} & \wedge & H_{\mathrm{i}} \in \mathbb{P} & \wedge \\ -H_{\mathrm{l}} \in \mathbb{P} & \wedge & H_{\mathrm{g}} \in \mathbb{P} & \wedge & H_{\mathrm{s}} \in \mathbb{P}_{256} & \wedge \\ -H_{\mathrm{x}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{n}} \in \mathbb{B}_{8} +\hyperlink{parent_Hash_H__p_def_words}{H_{\mathrm{p}}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ +\hyperlink{new_state_H__r}{H_{\mathrm{r}}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & \hyperlink{Receipts_Root_H__e}{H_{\mathrm{e}}} \in \mathbb{B}_{32} & \wedge \\ +\hyperlink{logs_Bloom_filter_H__b}{H_{\mathrm{b}}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{P} & \wedge & \hyperlink{block_number_H__i}{H_{\mathrm{i}}} \in \mathbb{P} & \wedge \\ +\hyperlink{block_gas_limit_H__l}{H_{\mathrm{l}}} \in \mathbb{P} & \wedge & H_{\mathrm{g}} \in \mathbb{P} & \wedge & \hyperlink{block_timestamp_H__s}{H_{\mathrm{s}}} \in \mathbb{P}_{256} & \wedge \\ +\hyperlink{block_extraData_H__x}{H_{\mathrm{x}}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & \hyperlink{block_nonce_H__n}{H_{\mathrm{n}}} \in \mathbb{B}_{8} \end{array} \end{equation} @@ -510,7 +510,7 @@ \subsubsection{Block Header Validity} & & H_{\mathrm{l}} \geqslant 5000 \end{eqnarray} -$H_{\mathrm{s}}$ is the timestamp (in Unix's time()) of block $H$ and must fulfil the relation: +\hypertarget{block_timestamp_H__s}{}$H_{\mathrm{s}}$ is the timestamp (in Unix's time()) of block $H$ and must fulfil the relation: \begin{equation} H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \end{equation} From e456ca3740e1c2951f6bab89390eb3a85b67afe7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:04:02 +1100 Subject: [PATCH 403/460] \hypertarget{block_number_H__i}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index be5a21b4..2b560b35 100644 --- a/Paper.tex +++ b/Paper.tex @@ -463,7 +463,7 @@ \subsubsection{Block Header Validity} P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = H_{\mathrm{p}} \end{equation} -The block number is the parent's block number incremented by one: +\hypertarget{block_number_H__i}{}The block number is the parent's block number incremented by one: \begin{equation} H_{\mathrm{i}} \equiv {{P(H)_{H}}_{\mathrm{i}}} + 1 \end{equation} From 4c08f3374d2a62006b22a831b5c5ca5c8095fb37 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:08:02 +1100 Subject: [PATCH 404/460] \hyperlink{parent_Hash_H__p_def_words}{H_{\mathrm{p}}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2b560b35..452bb783 100644 --- a/Paper.tex +++ b/Paper.tex @@ -460,7 +460,7 @@ \subsubsection{Block Header Validity} We define $P(B_{H})$ to be the parent block of $B$, formally: \begin{equation} -P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = H_{\mathrm{p}} +P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = \hyperlink{parent_Hash_H__p_def_words}{H_{\mathrm{p}}} \end{equation} \hypertarget{block_number_H__i}{}The block number is the parent's block number incremented by one: From 014a6ff5c66eff7cd2683836480d2089806008cb Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:28:25 +1100 Subject: [PATCH 405/460] More hyperlinks: upsilon_pow_g,l,z, account_nonce, block_nonce_H__n --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 452bb783..08d32241 100644 --- a/Paper.tex +++ b/Paper.tex @@ -517,7 +517,7 @@ \subsubsection{Block Header Validity} This mechanism enforces a homeostasis in terms of the time between blocks; a smaller period between the last two blocks results in an increase in the difficulty level and thus additional computation required, lengthening the likely next period. Conversely, if the period is too large, the difficulty, and expected time to the next block, is reduced. -The nonce, $H_{\mathrm{n}}$, must satisfy the relations: +The nonce, \hyperlink{block_nonce_H__n}{$H_{\mathrm{n}}$}, must satisfy the relations: \begin{equation} n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \wedge \quad m = H_{\mathrm{m}} \end{equation} @@ -560,7 +560,7 @@ \section{Transaction Execution} \label{ch:transactions} \begin{enumerate} \item The transaction is well-formed RLP, with no additional trailing bytes; \item the transaction signature is valid; -\item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the sender account's current nonce); +\item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the \hyperlink{account_nonce}{sender account's current nonce}); \item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} @@ -570,7 +570,7 @@ \section{Transaction Execution} \label{ch:transactions} \boldsymbol{\sigma}' = \Upsilon(\boldsymbol{\sigma}, T) \end{equation} -Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define $\Upsilon^{\mathrm{g}}$ to evaluate to the amount of gas used in the execution of a transaction, $\Upsilon^{\mathbf{l}}$ to evaluate to the transaction's accrued log items and $\Upsilon^{\mathrm{z}}$ to evaluate to the status code resulting from the transaction. These will be formally defined later. +Thus $\boldsymbol{\sigma}'$ is the post-transactional state. We also define \hyperlink{tx_total_gas_used_Upsilon_pow_g}{$\Upsilon^{\mathrm{g}}$} to evaluate to the amount of gas used in the execution of a transaction, \hyperlink{tx_logs_Upsilon_pow_l}{$\Upsilon^{\mathbf{l}}$} to evaluate to the transaction's accrued log items and \hyperlink{tx_status_Upsilon_pow_z}{$\Upsilon^{\mathrm{z}}$} to evaluate to the status code resulting from the transaction. These will be formally defined later. \subsection{Substate} Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this \textit{transaction substate}, and represent it as $A$, which is a tuple: From d7e25d2ecf4aeab7471b594dbd35f0be131e55f7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:35:40 +1100 Subject: [PATCH 406/460] \hyperlink{SSTORE}{{\small SSTORE}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..33850212 100644 --- a/Paper.tex +++ b/Paper.tex @@ -578,7 +578,7 @@ \subsection{Substate} A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}) \end{equation} -\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the \hyperlink{SSTORE}{{\small SSTORE}} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} From 8bce0fb8708dcccdde7647fba75e64b84a89f28e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:42:55 +1100 Subject: [PATCH 407/460] Intrinsic gas hyperlinks and mathrm: \hyperlink{G__txdatazero}{G_{\mathrm{txdatazero}}}, etc. --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..24d64aa4 100644 --- a/Paper.tex +++ b/Paper.tex @@ -588,12 +588,12 @@ \subsection{Substate} \subsection{Execution} \hypertarget{intrinsic_gas_g_0}{}We define intrinsic gas $g_0$, the amount of gas this transaction requires to be paid prior to execution, as follows: \begin{align} -g_0 \equiv {} & \sum_{i \in T_{\mathbf{i}}, T_{\mathbf{d}}} \begin{cases} G_{txdatazero} & \text{if} \quad i = 0 \\ G_{txdatanonzero} & \text{otherwise} \end{cases} \\ -{} & + \begin{cases} G_\text{txcreate} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ -{} & + G_{transaction} +g_0 \equiv {} & \sum_{i \in T_{\mathbf{i}}, T_{\mathbf{d}}} \begin{cases} \hyperlink{G__txdatazero}{G_{\mathrm{txdatazero}}} & \text{if} \quad i = 0 \\ \hyperlink{G__txdatanonzero}{G_{\mathrm{txdatanonzero}}} & \text{otherwise} \end{cases} \\ +{} & + \begin{cases} \hyperlink{Gtxcreate}{G_{\mathrm{txcreate}}} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\ +{} & + \hyperlink{Gtransaction}{G_{\mathrm{transaction}}} \end{align} -where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. +where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_{\mathrm{txcreate}}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. The up-front cost $v_0$ is calculated as: \begin{equation} From 79b68808ae037453f03b734af29a8a58502914d5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:50:04 +1100 Subject: [PATCH 408/460] The up-front cost hyperlinks It's pretty simple anyway but nevertheless... --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..51d2a737 100644 --- a/Paper.tex +++ b/Paper.tex @@ -595,9 +595,9 @@ \subsection{Execution} where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. -The up-front cost $v_0$ is calculated as: +The up-front cost $v_0$ is calculated as the transaction gas limit multiplied by the gas price, plus the transaction value: \begin{equation} -v_0 \equiv T_{\mathrm{g}} T_{\mathrm{p}} + T_{\mathrm{v}} +v_0 \equiv \hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}} \hyperlink{tx_gas_price_T__p}{T_{\mathrm{p}}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} \end{equation} The validity is determined as: From cd26363dc40a8aa3cf4632809408eea751425627 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:52:58 +1100 Subject: [PATCH 409/460] \hyperlink{ell}{\ell} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..25efb240 100644 --- a/Paper.tex +++ b/Paper.tex @@ -608,11 +608,11 @@ \subsection{Execution} \linkdest{transaction_nonce}{}T_{\mathrm{n}} & = & \boldsymbol{\sigma}[S(T)]_{\mathrm{n}} \quad \wedge \\ g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\ v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\ -T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \ell(B_{\mathbf{R}})_{\mathrm{u}} +T_{\mathrm{g}} & \leqslant & {B_{H}}_{\mathrm{l}} - \hyperlink{ell}{\ell}(B_{\mathbf{R}})_{\mathrm{u}} \end{array} \end{equation} -Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. +Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\hyperlink{ell}{\ell}(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. From b30fb8cdd49c144f3a3d3cb153038a6d19724930 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 14:54:47 +1100 Subject: [PATCH 410/460] \hyperlink{account_nonce}{nonce of the account of the sender} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..bdf8ce36 100644 --- a/Paper.tex +++ b/Paper.tex @@ -614,7 +614,7 @@ \subsection{Execution} Note the final condition; the sum of the transaction's gas limit, $T_{\mathrm{g}}$, and the gas utilised in this block prior, given by $\ell(B_{\mathbf{R}})_{\mathrm{u}}$, must be no greater than the block's \textbf{gasLimit}, ${B_{H}}_{\mathrm{l}}$. -The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. +The execution of a valid transaction begins with an irrevocable change made to the state: the \hyperlink{account_nonce}{nonce of the account of the sender}, $S(T)$, is incremented by one and the balance is reduced by part of the up-front cost, $T_{\mathrm{g}}T_{\mathrm{p}}$. The gas available for the proceeding computation, $g$, is defined as $T_{\mathrm{g}} - g_0$. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. We define the checkpoint state $\boldsymbol{\sigma}_0$: \begin{eqnarray} From 8fc6d3e82e9ccc37207834a6429f2671092d1d7e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:01:42 +1100 Subject: [PATCH 411/460] \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..a2f7470a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -578,7 +578,7 @@ \subsection{Substate} A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}) \end{equation} -\hypertarget{self_destruct_set_wordy_defn}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. +\hypertarget{self_destruct_set_wordy_defn_A__s}{}The tuple contents include $A_{\mathbf{s}}$, the self-destruct set: a set of accounts that will be discarded following the transaction's completion.\hypertarget{tx_log_series_wordy_defn_A__l}{} $A_{\mathbf{l}}$ is the log series: this is a series of archived and indexable `checkpoints' in VM code execution that allow for contract-calls to be easily tracked by onlookers external to the Ethereum world (such as decentralised application front-ends).\hypertarget{tx_touched_accounts_wordy_defn_A__t}{} $A_{\mathbf{t}}$ is the set of touched accounts, of which the empty ones are deleted at the end of a transaction.\hypertarget{refund_balance_defn_words_A__r}{} Finally there is $A_{\mathrm{r}}$, the refund balance, increased through using the {\small SSTORE} instruction in order to reset contract storage to zero from some non-zero value. Though not immediately refunded, it is allowed to partially offset the total execution costs. We define the empty substate $A^0$ to have no self-destructs, no logs, no touched accounts and a zero refund balance: \begin{equation} @@ -641,7 +641,7 @@ \subsection{Execution} After the message call or contract creation is processed, the state is finalised by determining the amount to be refunded, $g^*$ from the remaining gas, $g'$, plus some allowance from the refund counter, to the sender at the original rate. \begin{equation} -g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, A_{\mathrm{r}} \} +g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} \} \end{equation} The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. From 8902ba2d1109cd77663590e9272486cd73ab2ea6 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:08:28 +1100 Subject: [PATCH 412/460] \hyperlink{tx_log_series_wordy_defn_A__l}{A_{\mathbf{l}}} etc. --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index a2f7470a..4529da52 100644 --- a/Paper.tex +++ b/Paper.tex @@ -6,7 +6,7 @@ \usepackage{multicol} \usepackage{subfig} \usepackage{amsmath} -\usepackage{amssymb} +\usepackage{amssymb}Th \usepackage[a4paper,width=170mm,top=18mm,bottom=22mm,includeheadfoot]{geometry} \usepackage{booktabs} \usepackage{array} @@ -644,7 +644,7 @@ \subsection{Execution} g^* \equiv g' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - g'}{2} \Big\rfloor, \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} \} \end{equation} -The total refundable amount is the legitimately remaining gas $g'$, added to $A_{\mathrm{r}}$, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. +The total refundable amount is the legitimately remaining gas $g'$, added to \hyperlink{refund_balance_defn_words_A__r}{$A_{\mathrm{r}}$}, with the latter component being capped up to a maximum of half (rounded down) of the total amount used $T_{\mathrm{g}} - g'$. The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block $B$. So we define the pre-final state $\boldsymbol{\sigma}^*$ in terms of the provisional state $\boldsymbol{\sigma}_{P}$: \begin{eqnarray} @@ -664,7 +664,7 @@ \subsection{Execution} \hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_z}{}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: \begin{eqnarray} \Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ -\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_{\mathbf{l}} \\ +\Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & \hyperlink{tx_log_series_wordy_defn_A__l}{A_{\mathbf{l}}} \\ \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} From ca94d647af38b7c8d6cd2602101918af432d908c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:08:59 +1100 Subject: [PATCH 413/460] Remove a mistake "Th" --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 4529da52..1c60ea56 100644 --- a/Paper.tex +++ b/Paper.tex @@ -6,7 +6,7 @@ \usepackage{multicol} \usepackage{subfig} \usepackage{amsmath} -\usepackage{amssymb}Th +\usepackage{amssymb} \usepackage[a4paper,width=170mm,top=18mm,bottom=22mm,includeheadfoot]{geometry} \usepackage{booktabs} \usepackage{array} From c63ed730c884b6bf2ebeda185ba2e099061a7f0e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:13:06 +1100 Subject: [PATCH 414/460] \hyperlink{rlp}{RLP} etc. and grammar --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..41860e28 100644 --- a/Paper.tex +++ b/Paper.tex @@ -679,12 +679,12 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} (\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) \end{equation} -The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. Thus we define the resultant address for the new account $a$: +The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the \hyperlink{rlp}{RLP} encoding of the structure containing only the sender and the \hyperlink{account nonce}{account nonce}. Thus we define the resultant address for the new account $a$: \begin{equation} a \equiv \mathcal{B}_{96..255}\Big(\mathtt{\tiny KEC}\Big(\mathtt{\tiny RLP}\big(\;(s, \boldsymbol{\sigma}[s]_{\mathrm{n}} - 1)\;\big)\Big)\Big) \end{equation} -where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$ and $\boldsymbol{\sigma}[x]$ is the address state of $x$ or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. +where $\mathtt{\tiny KEC}$ is the Keccak 256-bit hash function, $\mathtt{\tiny RLP}$ is the RLP encoding function, $\mathcal{B}_{a..b}(X)$ evaluates to a binary value containing the bits of indices in the range $[a, b]$ of the binary data $X$, and $\boldsymbol{\sigma}[x]$ is the address state of $x$, or $\varnothing$ if none exists. Note we use one fewer than the sender's nonce value; we assert that we have incremented the sender account's nonce prior to this call, and so the value used is the sender's nonce at the beginning of the responsible transaction or VM operation. The account's nonce is initially defined as one, the balance as the value passed, the storage as empty and the code hash as the Keccak 256-bit hash of the empty string; the sender's balance is also reduced by the value passed. Thus the mutated state becomes $\boldsymbol{\sigma}^*$: \begin{equation} From 61d01ca3f2a158cf507f2eb480799621a9e928ce Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:17:24 +1100 Subject: [PATCH 415/460] \hyperlink{trie}{TRIE} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..c155bd7b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -691,7 +691,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except:} \end{equation} \begin{eqnarray} -\boldsymbol{\sigma}^*[a] &=& \big( 1, v + v', \mathtt{\tiny TRIE}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ +\boldsymbol{\sigma}^*[a] &=& \big( 1, v + v', \mathtt{\tiny \hyperlink{trie}{TRIE}}(\varnothing), \mathtt{\tiny KEC}\big(()\big) \big) \\ \boldsymbol{\sigma}^*[s] &=& \begin{cases} \varnothing & \text{if}\ \boldsymbol{\sigma}[s] = \varnothing \ \wedge\ v = 0 \\ \mathbf{a}^* & \text{otherwise} From a499bd85e180a0f776eda513f40eeb257f9f2ca3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:25:50 +1100 Subject: [PATCH 416/460] \hyperlink{execenv}{execution environment} and linkdest --- Paper.tex | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..04ea35dd 100644 --- a/Paper.tex +++ b/Paper.tex @@ -714,7 +714,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \begin{equation} (\boldsymbol{\sigma}^{**}, g^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, g, I, \{s, a\}) \\ \end{equation} -\pagebreak[1]where $I$ contains the parameters of the execution environment as defined in section \ref{ch:model}, that is:\pagebreak[1] +\pagebreak[1]where $I$ contains the parameters of the \hyperlink{exec_env}{execution environment}, that is:\pagebreak[1] \begin{eqnarray} I_{\mathrm{a}} & \equiv & a \\ I_{\mathrm{o}} & \equiv & o \\ @@ -723,7 +723,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & v \\ I_{\mathbf{b}} & \equiv & \mathbf{i} \\ -I_{\mathrm{e}} & \equiv & e \\ +\hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} @@ -877,21 +877,21 @@ \subsection{Fees Overview} See Appendix \ref{app:vm} for a rigorous definition of the EVM gas cost. -\subsection{Execution Environment} +\subsection{Execution Environment}\linkdest{exec_env} In addition to the system state $\boldsymbol{\sigma}$, and the remaining gas for computation $g$, there are several pieces of important information used in the execution environment that the execution agent must provide; these are contained in the tuple $I$: \begin{itemize} -\item\linkdest{address_of_account_which_owns_code_I__a_def_words}{} $I_{\mathrm{a}}$, the address of the account which owns the code that is executing. -\item\linkdest{address_of_sender_of_tx_that_originated_execution_I__o}{} $I_{\mathrm{o}}$, the sender address of the transaction that originated this execution. -\item\linkdest{gas_price_in_tx_that_originated_execution_I__p}{} $I_{\mathrm{p}}$, the price of gas in the transaction that originated this execution. -\item\linkdest{execution_input_data_I__d}{} $I_{\mathbf{d}}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. +\item\linkdest{address_of_account_which_owns_code_I__a_def_words}{}\linkdest{I__a} $I_{\mathrm{a}}$, the address of the account which owns the code that is executing. +\item\linkdest{address_of_sender_of_tx_that_originated_execution_I__o}{}\linkdest{I__o} $I_{\mathrm{o}}$, the sender address of the transaction that originated this execution. +\item\linkdest{gas_price_in_tx_that_originated_execution_I__p}{}\linkdest{I__p} $I_{\mathrm{p}}$, the price of gas in the transaction that originated this execution. +\item\linkdest{execution_input_data_I__d}{}\linkdest{I__d} $I_{\mathbf{d}}$, the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data. \item\linkdest{the_address_of_the_account_which_caused_the_code_to_be_executing_I__s}{} $I_{\mathrm{s}}$, the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender. -\item\linkdest{Wei_value_exec}{} $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. -\item\linkdest{exec_machine_code_I__b}{} $I_{\mathbf{b}}$, the byte array that is the machine code to be executed. -\item\linkdest{exec_block_header_I__H}{} $I_{\mathbf{H}}$, the block header of the present block. -\item\linkdest{exec_call_or_create_depth_I__e}{} $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). -\item\linkdest{exec_permission_to_modify_state_I__w}{} $I_{\mathrm{w}}$, the permission to make modifications to the state. +\item\linkdest{Wei_value_exec_I__v}{}\linkdest{I__v}{} $I_{\mathrm{v}}$, the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value. +\item\linkdest{exec_machine_code_I__b}{}\linkdest{I__b} $I_{\mathbf{b}}$, the byte array that is the machine code to be executed. +\item\linkdest{exec_block_header_I__H}{}\linkdest{I__H} $I_{\mathbf{H}}$, the block header of the present block. +\item\linkdest{exec_call_or_create_depth_I__e}{}\linkdest{I__e} $I_{\mathrm{e}}$, the depth of the present message-call or contract-creation (i.e. the number of {\small CALL}s or {\small CREATE}s being executed at present). +\item\linkdest{exec_permission_to_modify_state_I__w}{}\linkdest{I__e} $I_{\mathrm{w}}$, the permission to make modifications to the state. \end{itemize} The execution model defines the function $\Xi$, which can compute the resultant state $\boldsymbol{\sigma}'$, the remaining gas $g'$, the accrued substate $A$ and the resultant output, $\mathbf{o}$, given these definitions. For the present context, we will define it as: From ec4c7f34a2061ccdcfbea5929d48e0086fd9a247 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:33:55 +1100 Subject: [PATCH 417/460] \hyperlink{hhalt}{normal halting} \hyperlink{zhalt}{exceptional halting} + linkdests --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..7e0b5cbe 100644 --- a/Paper.tex +++ b/Paper.tex @@ -907,7 +907,7 @@ \subsection{Execution Environment} \subsection{Execution Overview} -We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an exceptional halting state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a normal halting state of the machine. +We must now define the $\Xi$ function. In most practical implementations this will be modelled as an iterative progression of the pair comprising the full system state, $\boldsymbol{\sigma}$ and the machine state, $\boldsymbol{\mu}$. Formally, we define it recursively with a function $X$. This uses an iterator function $O$ (which defines the result of a single cycle of the state machine) together with functions $Z$ which determines if the present state is an \hyperlink{zhalt}{exceptional halting} state of the machine and $H$, specifying the output data of the instruction if and only if the present state is a \hyperlink{hhalt}{normal halting} state of the machine. \hypertarget{empty_sequence_vs_empty_set}{}The empty sequence, denoted $()$, is not equal to the empty set, denoted $\varnothing$; this is important when interpreting the output of $H$, which evaluates to $\varnothing$ when execution is to continue but a series (potentially empty) when execution should halt. \begin{eqnarray} @@ -955,7 +955,7 @@ \subsubsection{Machine State} We also assume the fixed amounts of $\mathbf{\delta}$ and $\mathbf{\alpha}$, specifying the stack items removed and added, both subscriptable on the instruction and an instruction cost function $C$ evaluating to the full cost, in gas, of executing the given instruction. -\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{} +\subsubsection{Exceptional Halting}\hypertarget{Exceptional_Halting_function_Z}{}\linkdest{zhalt} The exceptional halting function $Z$ is defined as: \begin{equation} @@ -1008,7 +1008,7 @@ \subsubsection{Jump Destination Validity} i + 1 & \text{otherwise} \end{cases} \end{equation} -\subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} +\subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{}\linkdest{hhalt} The normal halting function $H$ is defined: \begin{equation} From 5706ace2daba6e015e4347643219727d33e8da4c Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:37:12 +1100 Subject: [PATCH 418/460] \hyperlink{stop}{\small STOP}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..7d931540 100644 --- a/Paper.tex +++ b/Paper.tex @@ -949,7 +949,7 @@ \subsubsection{Machine State} For the purposes of defining $Z$, $H$ and $O$, we define $w$ as the current operation to be executed: \begin{equation}\label{eq:currentoperation} w \equiv \begin{cases} I_{\mathbf{b}}[\boldsymbol{\mu}_{pc}] & \text{if} \quad \boldsymbol{\mu}_{pc} < \lVert I_{\mathbf{b}} \rVert \\ -\text{\small STOP} & \text{otherwise} +\text{\hyperlink{stop}{\small STOP}} & \text{otherwise} \end{cases} \end{equation} From 6fc4fec0df957f3dddc97dcdbb1607d24b3cdce3 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:39:40 +1100 Subject: [PATCH 419/460] \hyperlink{stop}{{\small STOP}} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..e7a4f38e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -985,7 +985,7 @@ \subsubsection{Jump Destination Validity} We previously used $D$ as the function to determine the set of valid jump destinations given the code that is being run. We define this as any position in the code occupied by a {\small JUMPDEST} instruction. -All such positions must be on valid instruction boundaries, rather than sitting in the data portion of {\small PUSH} operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined {\small STOP} operations that trail it). +All such positions must be on valid instruction boundaries, rather than sitting in the data portion of {\small PUSH} operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined \hyperlink{stop}{{\small STOP}} operations that trail it). Formally: \begin{equation} From c916a0a8dfcc3665d6e8ee8bf621cb8ada1e4a99 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:54:11 +1100 Subject: [PATCH 420/460] \hyperlink{RETURN} selfdestruct --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..f48c56d0 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1013,13 +1013,13 @@ \subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} The normal halting function $H$ is defined: \begin{equation} H(\boldsymbol{\mu}, I) \equiv \begin{cases} -H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w \in \{\text{\small RETURN}, \text{\small REVERT}\} \\ -() & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small SELFDESTRUCT} \} \\ +H_{\text{\tiny RETURN}}(\boldsymbol{\mu}) & \text{if} \quad w \in \{\text{\small \hyperlink{RETURN}{RETURN}}, \text{\small REVERT}\} \\ +() & \text{if} \quad w \in \{ \text{\small STOP}, \text{\small \hyperlink{selfdestruct}{SELFDESTRUCT}} \} \\ \varnothing & \text{otherwise} \end{cases} \end{equation} -The data-returning halt operations, \text{\small RETURN} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$, defined in Appendix \ref{app:vm}. +The data-returning halt operations, \hyperlink{RETURN}{\text{\small RETURN}} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$. \subsection{The Execution Cycle} From e63a37c8c010aa4d7c2c9e340673dea02909e428 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 15:57:05 +1100 Subject: [PATCH 421/460] discussed \hyperlink{empty_sequence_vs_empty_set}{here} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index f48c56d0..8d0e0c1d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1019,7 +1019,7 @@ \subsubsection{Normal Halting}\hypertarget{normal_halting_function_H}{} \end{cases} \end{equation} -The data-returning halt operations, \hyperlink{RETURN}{\text{\small RETURN}} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$. +The data-returning halt operations, \hyperlink{RETURN}{\text{\small RETURN}} and \text{\small REVERT}, have a special function $H_{\text{\tiny RETURN}}$. Note also the difference between the empty sequence and the empty set as discussed \hyperlink{empty_sequence_vs_empty_set}{here}. \subsection{The Execution Cycle} From 6f21bc31b5ddc32b66ddd7bcc3c93601c2b8e704 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:00:50 +1100 Subject: [PATCH 422/460] \hyperlink{JUMP}{J_{\text{JUMP}}} \hyperlink{JUMPI}{J_{\text{JUMPI}}} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..d5ce1838 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1035,8 +1035,8 @@ \subsection{The Execution Cycle} \begin{eqnarray} \quad \boldsymbol{\mu}'_{g} & \equiv & \boldsymbol{\mu}_{g} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \label{eq:mu_pc}\\ \quad \boldsymbol{\mu}'_{pc} & \equiv & \begin{cases} -J_{\text{JUMP}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ -J_{\text{JUMPI}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ +\hyperlink{JUMP}{J_{\text{JUMP}}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMP} \\ +\hyperlink{JUMPI}{J_{\text{JUMPI}}}(\boldsymbol{\mu}) & \text{if} \quad w = \text{\small JUMPI} \\ N(\boldsymbol{\mu}_{pc}, w) & \text{otherwise} \end{cases} \end{eqnarray} From 12f04111d648d7c6792a2ac9dbe6b866012ed0a5 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:04:15 +1100 Subject: [PATCH 423/460] \hyperlink{Genesis_Block}{genesis block} --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..cf841150 100644 --- a/Paper.tex +++ b/Paper.tex @@ -159,7 +159,7 @@ \subsection{Value} \subsection{Which History?} -Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (\hyperlink{GenesisBlock}{the genesis block}) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. +Since the system is decentralised and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is necessarily a tree of blocks. In order to form a consensus as to which path, from root (\hyperlink{Genesis_Block}{the genesis block}) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the `best' blockchain, then a \textit{fork} occurs. This would mean that past a given point in time (block), multiple states of the system may coexist: some nodes believing one block to contain the canonical transactions, other nodes believing some other block to be canonical, potentially containing radically different or incompatible transactions. This is to be avoided at all costs as the uncertainty that would ensue would likely kill all confidence in the entire system. @@ -1053,7 +1053,7 @@ \subsection{The Execution Cycle} \section{Blocktree to Blockchain} \label{ch:ghost} -The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually we identify the path that has had the most computation done upon it, or, the \textit{heaviest} path. Clearly one factor that helps determine the heaviest path is the block number of the leaf, equivalent to the number of blocks, not counting the unmined genesis block, in the path. The longer the path, the greater the total mining effort that must have been done in order to arrive at the leaf. This is akin to existing schemes, such as that employed in Bitcoin-derived protocols. +The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually we identify the path that has had the most computation done upon it, or, the \textit{heaviest} path. Clearly one factor that helps determine the heaviest path is the block number of the leaf, equivalent to the number of blocks, not counting the unmined \hyperlink{Genesis_Block}{genesis block}, in the path. The longer the path, the greater the total mining effort that must have been done in order to arrive at the leaf. This is akin to existing schemes, such as that employed in Bitcoin-derived protocols. Since a block header includes the difficulty, the header alone is enough to validate the computation done. Any block contributes toward the total computation or \textit{total difficulty} of a chain. @@ -2321,7 +2321,7 @@ \subsection{Instruction Set} \bottomrule \end{tabular*} -\section{Genesis Block}\label{app:genesis}\hypertarget{GenesisBlock}{} +\section{Genesis Block}\label{app:genesis}\hypertarget{Genesis_Block}{} The genesis block is 15 items, and is specified thus: \begin{equation} From a01fd9ca84a8d3e66995c54d63c8cd98424e208f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:12:35 +1100 Subject: [PATCH 424/460] hyperlinks block_header_validity_function ommer_block_header --- Paper.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..5b4f2382 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1073,14 +1073,14 @@ \section{Block Finalisation} \label{ch:finalisation} \item Validate (or, if mining, determine) ommers; \item validate (or, if mining, determine) transactions; \item apply rewards; -\item verify (or, if mining, compute a valid) state and nonce. +\item verify (or, if mining, compute a valid) state and \hyperlink{block nonce}{block nonce}. \end{enumerate} \subsection{Ommer Validation} -The validation of ommer headers means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: +The validation of \hyperlink{ommer_block_headers_B__U}{ommer headers} means nothing more than verifying that each ommer header is both a valid header and satisfies the relation of $N$th-generation ommer to the present block where $N \leq 6$. The maximum of ommer headers is two. Formally: \begin{equation} -\lVert B_{\mathbf{U}} \rVert \leqslant 2 \bigwedge_{\mathbf{U} \in B_{\mathbf{U}}} V({\mathbf{U}}) \; \wedge \; k({\mathbf{U}}, P(\mathbf{B}_{\mathbf{H}})_{\mathbf{H}}, 6) +\lVert B_{\mathbf{U}} \rVert \leqslant 2 \bigwedge_{\mathbf{U} \in B_{\mathbf{U}}} \hyperlink{block_header_validity_function}{V({\mathbf{U}}})\; \wedge \; k({\mathbf{U}}, P(\mathbf{B}_{\mathbf{H}})_{\mathbf{H}}, 6) \end{equation} where $k$ denotes the ``is-kin'' property: From 06d541c09e962afb73a161d85c51bac75133b087 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:19:40 +1100 Subject: [PATCH 425/460] \hyperlink{H__g} --- Paper.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..2663d01e 100644 --- a/Paper.tex +++ b/Paper.tex @@ -328,7 +328,7 @@ \subsection{The Block} \label{ch:block} \begin{description} \item[parentHash]\linkdest{parent_Hash_H__p_def_words}{} The Keccak 256-bit hash of the parent block's header, in its entirety; formally $H_{\mathrm{p}}$. \item[ommersHash] The Keccak 256-bit hash of the ommers list portion of this block; formally $H_{\mathrm{o}}$. -\item[beneficiary]\linkdest{beneficiary_H__c}{} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. +\item[beneficiary]\linkdest{beneficiary_H__c}{}\linkdest{H__c} The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally $H_{\mathrm{c}}$. \item[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally $H_{\mathrm{r}}$. \item[transactionsRoot] The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally $H_{\mathrm{t}}$. \item[receiptsRoot]\linkdest{receipts_Root_def_words}{} The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally $H_{\mathrm{e}}$. @@ -336,7 +336,7 @@ \subsection{The Block} \label{ch:block} \item[difficulty] A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block's difficulty level and the timestamp; formally $H_{\mathrm{d}}$. \item[number]\linkdest{block_number_H_i}{} A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally $H_{\mathrm{i}}$. \item[gasLimit] A scalar value equal to the current limit of gas expenditure per block; formally $H_{\mathrm{l}}$. -\item[gasUsed]\linkdest{block_gas_used_H__g}{} A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. +\item[gasUsed]\linkdest{block_gas_used_H__g}{}\linkdest{H__g} A scalar value equal to the total gas used in transactions in this block; formally $H_{\mathrm{g}}$. \item[timestamp]\linkdest{block_timestamp_H__s}{} A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally $H_{\mathrm{s}}$. \item[extraData]\linkdest{block_extraData_H__x}{} An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally $H_{\mathrm{x}}$. \item[mixHash]\linkdest{mixHash_H__m}{} A 256-bit hash which, combined with the nonce, proves that a sufficient amount of computation has been carried out on this block; formally $H_{\mathrm{m}}$. @@ -1101,9 +1101,9 @@ \subsection{Transaction Validation} %where $s[i]$ equals the root of the state trie immediately after the execution of the transaction $B_{\mathbf{T}}[i]$, and $g[i]$ the total gas used immediately after said transaction. -The given \textbf{gasUsed} must correspond faithfully to the transactions listed: ${B_{H}}_{\mathrm{g}}$, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: +The given \textbf{gasUsed} must correspond faithfully to the transactions listed: \hyperlink{H__g}{${B_{H}}_{\mathrm{g}}$}, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_{H}}_{\mathrm{g}} = \ell(\mathbf{R})_{\mathrm{u}} +{B_{H}}_{\mathrm{g}} = \hyperlink{ell}{\ell}(\mathbf{R})_{\mathrm{u}} \end{equation} \subsection{Reward Application} From 722f659220eba1395f92e380a33954b480f644fd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:22:37 +1100 Subject: [PATCH 426/460] \hyperlink{R__u} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 2663d01e..881a0bed 100644 --- a/Paper.tex +++ b/Paper.tex @@ -353,7 +353,7 @@ \subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{} In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from concerning its execution. Each receipt, denoted $B_{\mathbf{R}}[i]$ for the $i$th transaction, is placed in an index-keyed \hyperlink{trie}{trie} and the root recorded in the header as \hyperlink{Receipts_Root_H__e}{$H_{\mathrm{e}}$}. -\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}The transaction receipt, $R$, is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, \hyperlink{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{$R_\mathbf{l}$} and the Bloom filter composed from information in those logs, \hyperlink{RLP_serialisation_of_a_byte_array_R__b_math_def}{$R_{\mathrm{b}}$} and the status code of the transaction, $R_{\mathrm{z}}$: +\linkdest{transaction_receipt_R}{}\linkdest{tx_receipt_gas_used_R__u}{}\linkdest{R__u}The transaction receipt, $R$, is a tuple of four items comprising the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{\mathrm{u}}$, the set of logs created through execution of the transaction, \hyperlink{RLP_serialisation_of_a_sequence_of_other_items_R__l_math_def}{$R_\mathbf{l}$} and the Bloom filter composed from information in those logs, \hyperlink{RLP_serialisation_of_a_byte_array_R__b_math_def}{$R_{\mathrm{b}}$} and the status code of the transaction, $R_{\mathrm{z}}$: \begin{equation} R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}}) \end{equation} @@ -1103,7 +1103,7 @@ \subsection{Transaction Validation} The given \textbf{gasUsed} must correspond faithfully to the transactions listed: \hyperlink{H__g}{${B_{H}}_{\mathrm{g}}$}, the total gas used in the block, must be equal to the accumulated gas used according to the final transaction: \begin{equation} -{B_{H}}_{\mathrm{g}} = \hyperlink{ell}{\ell}(\mathbf{R})_{\mathrm{u}} +{B_{H}}_{\mathrm{g}} = \hyperlink{ell}{\ell}(\hyperlink{R__u}{\mathbf{R})_{\mathrm{u}}} \end{equation} \subsection{Reward Application} From 9d594899ece2646b02d8d3220a2dcfe124295394 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 16:49:40 +1100 Subject: [PATCH 427/460] R_{\mathrm{b}} as the block reward => R_{\mathrm{block}} + links --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..688d1bf5 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1108,25 +1108,25 @@ \subsection{Transaction Validation} \subsection{Reward Application} -The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_{\mathrm{b}}$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{} Formally we define the function $\Omega$: +The application of rewards to a block involves raising the balance of the accounts of the beneficiary address of the block and each ommer by a certain amount. We raise the block's beneficiary account by $R_{\mathrm{block}}$; for each ommer, we raise the block's beneficiary by an additional $\frac{1}{32}$ of the block reward and the beneficiary of the ommer gets rewarded depending on the block number.\hypertarget{Omega}{} Formally we define the function $\Omega$: \begin{eqnarray} \\ \nonumber \Omega(B, \boldsymbol{\sigma}) & \equiv & \boldsymbol{\sigma}': \boldsymbol{\sigma}' = \boldsymbol{\sigma} \quad \text{except:} \\ -\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_{\mathbf{U}}\rVert}{32})R_{\mathrm{b}} \\ +\qquad\boldsymbol{\sigma}'[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} & = & \boldsymbol{\sigma}[{\mathbf{B}_{H}}_{\mathrm{c}}]_{\mathrm{b}} + (1 + \frac{\lVert \mathbf{B}_{\mathbf{U}}\rVert}{32})R_{\mathrm{block}} \\ \qquad\forall_{\mathbf{U} \in \mathbf{B}_{\mathbf{U}}}: \\ \nonumber \boldsymbol{\sigma}'[\mathbf{U}_{\mathrm{c}}] & = & \begin{cases} \varnothing &\text{if}\ \boldsymbol{\sigma}[\mathbf{U}_{\mathrm{c}}] = \varnothing\ \wedge\ R = 0 \\ \mathbf{a}' &\text{otherwise} \end{cases} \\ \mathbf{a}' &\equiv& (\boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{n}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{b}} + R, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathbf{s}}, \boldsymbol{\sigma}[U_{\mathrm{c}}]_{\mathrm{c}}) \\ -R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{b}} +R & \equiv & (1 + \frac{1}{8} (U_{\mathrm{i}} - {B_{H}}_{\mathrm{i}})) R_{\mathrm{block}} \end{eqnarray} If there are collisions of the beneficiary addresses between ommers and the block (i.e. two ommers with the same beneficiary address or an ommer with the same beneficiary address as the present block), additions are applied cumulatively. -\hypertarget{block_reward_R__b}{}We define the block reward as 3 Ether: +\hypertarget{block_reward_R__block}{}We define the block reward as 3 Ether: \begin{equation} -\text{Let} \quad R_{\mathrm{b}} = 3 \times 10^{18} +\text{Let} \quad R_{\mathrm{block}} = 3 \times 10^{18} \end{equation} \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} @@ -1315,7 +1315,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \mathtt{\tiny RLP}(\mathbf{x}) \equiv \begin{cases} R_{\mathrm{b}}(\mathbf{x}) & \text{if} \quad \mathbf{x} \in \mathbb{B} \\ R_{\mathrm{l}}(\mathbf{x}) & \text{otherwise} \end{cases} \end{equation} -\hypertarget{RLP_serialisation_of_a_byte_array_R__b_word_def}{}If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: +\hypertarget{RLP_serialisation_of_a_byte_array_R__b_word_def}{}\linkdest{R__b}If the value to be serialised is a byte-array, the RLP serialisation takes one of three forms: \begin{itemize} \item If the byte-array contains solely a single byte and that single byte is less than 128, then the input is exactly equal to the output. @@ -1324,7 +1324,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \end{itemize} \hypertarget{RLP_serialisation_of_a_byte_array_R__b_math_def}{}Formally, we define $R_{\mathrm{b}}$: -\begin{eqnarray} +\begin{eqnarray}R_\{\\mathrm\{b\}\} R_{\mathrm{b}}(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ (128 + \lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{else if} \quad \lVert \mathbf{x} \rVert < 56 \\ @@ -1336,7 +1336,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} Thus $\mathtt{\tiny BE}$ is the function that expands a positive integer value to a big-endian byte array of minimal length and the dot operator performs sequence concatenation. -\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_word_def}{}If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: +\hypertarget{RLP_serialisation_of_a_sequence_of_other_items_R__l_word_def}{}\linkdest{R__l}If instead, the value to be serialised is a sequence of other items then the RLP serialisation takes one of two forms: \begin{itemize} \item If the concatenated serialisations of each contained item is less than 56 bytes in length, then the output is equal to that concatenation prefixed by the byte equal to the length of this byte array plus 192. From 9cf1949e89ef5bdbc368206c2896429a4ceb3de7 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 17:52:34 +1100 Subject: [PATCH 428/460] Remove accidentally added R_\{\\mathrm\{b\}\} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 688d1bf5..7e3a9c14 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1324,7 +1324,7 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} \end{itemize} \hypertarget{RLP_serialisation_of_a_byte_array_R__b_math_def}{}Formally, we define $R_{\mathrm{b}}$: -\begin{eqnarray}R_\{\\mathrm\{b\}\} +\begin{eqnarray} R_{\mathrm{b}}(\mathbf{x}) & \equiv & \begin{cases} \mathbf{x} & \text{if} \quad \lVert \mathbf{x} \rVert = 1 \wedge \mathbf{x}[0] < 128 \\ (128 + \lVert \mathbf{x} \rVert) \cdot \mathbf{x} & \text{else if} \quad \lVert \mathbf{x} \rVert < 56 \\ From 731cc979eeefc5b74b03df1e4f6b983e42b75fb9 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 18:12:13 +1100 Subject: [PATCH 429/460] \hyperlink{H_cancel_n}{\hcancel{n}}, etc. + grammar --- Paper.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..035001f7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -473,7 +473,7 @@ \subsubsection{Block Header Validity} \newcommand{\expdiffsymb}{\ensuremath{\epsilon}} \newcommand{\diffadjustment}{x} -\hypertarget{block_difficulty_H__d}{}The canonical difficulty of a block of header $H$ is defined as $D(H)$: +\hypertarget{block_difficulty_H__d}{}\linkdest{H__d}The canonical difficulty of a block of header $H$ is defined as $D(H)$: \begin{equation} D(H) \equiv \begin{dcases} \mindifficulty & \text{if} \quad H_{\mathrm{i}} = 0\\ @@ -523,7 +523,7 @@ \subsubsection{Block Header Validity} \end{equation} with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. -\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. +\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}\linkdest{H_cancel_n}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. @@ -1135,17 +1135,17 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_{H}) = \varnothing \\ -\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small \hyperlink{trie}{TRIE}}}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. -\hypertarget{Phi}{}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: +\hypertarget{Phi}{}And finally we define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ -B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \\ -B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ +B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{\hyperlink{H__d}{H_{\mathrm{d}}}} \\ +B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hyperlink{H_cancel_n}{\hcancel{n}}}, n, \mathbf{d}) \\ B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. From 024d6e28423364f18667d40a3b56211b3a50add0 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 18:31:48 +1100 Subject: [PATCH 430/460] which is, more links in State and Nonce Evaluation --- Paper.tex | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Paper.tex b/Paper.tex index 63f02da4..e36c3804 100644 --- a/Paper.tex +++ b/Paper.tex @@ -117,7 +117,7 @@ \section{The Blockchain Paradigm} \label{ch:overview} Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. It is this final state which we accept as the canonical ``version'' of the world of Ethereum. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions thus represent a valid arc between two states; the `valid' part is important---there exist far more invalid state changes than valid state changes. Invalid state changes might, \eg, be things such as reducing an account balance without an equal and opposite increase elsewhere. A valid state transition is one which comes about through a transaction. Formally: \begin{equation} -\linkdest{Upsilon_state_transition}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) +\linkdest{Upsilon_state_transition}\linkdest{Upsilon}\boldsymbol{\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \end{equation} where $\Upsilon$ is the Ethereum state transition function. In Ethereum, $\Upsilon$, together with $\boldsymbol{\sigma}$ are considerably more powerful then any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $\boldsymbol{\sigma}$ allows components to store arbitrary state between transactions. @@ -661,14 +661,14 @@ \subsection{Execution} \linkdest{touched_A__t}{}\forall i \in A_{\mathbf{t}}: \boldsymbol{\sigma}'[i] & = & \varnothing \quad\text{if}\quad \mathtt{\tiny DEAD}(\boldsymbol{\sigma}^*\kern -2pt, i) \end{eqnarray} -\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\hypertarget{tx_logs_Upsilon_pow_l}{}\hypertarget{tx_status_Upsilon_pow_z}{}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: +\hypertarget{tx_total_gas_used_Upsilon_pow_g}{}\linkdest{Upsilon_pow_g}\hypertarget{tx_logs_Upsilon_pow_l}{}\linkdest{Upsilon_pow_l}\hypertarget{tx_status_Upsilon_pow_z}{}\linkdest{Upsilon_pow_z}And finally, we specify $\Upsilon^{\mathrm{g}}$, the total gas used in this transaction, $\Upsilon^\mathbf{l}$, the logs created by this transaction and $\Upsilon^{\mathrm{z}}$, the status code of this transaction: \begin{eqnarray} \Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - g' \\ \Upsilon^\mathbf{l}(\boldsymbol{\sigma}, T) & \equiv & A_{\mathbf{l}} \\ \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & z \end{eqnarray} -These are used to help define the \hyperlink{Transaction_Receipt}{transaction receipt}. +These are used to help define the \hyperlink{Transaction_Receipt}{transaction receipt} and are also used \hyperlink{Upsilon_pow_g2}{later} for state and nonce validation. \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} @@ -1139,51 +1139,51 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \end{cases} \end{equation} -Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, trivial and efficient since the trie is by nature an immutable data structure. +Here, $\mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}}))$ means the hash of the root node of a trie of state $\boldsymbol{\sigma}_{\mathrm{i}}$; it is assumed that implementations will store this in the state database, which is trivial and efficient since the trie is by nature an immutable data structure. \hypertarget{Phi}{}And finally define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \\ B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hcancel{n}}, n, \mathbf{d}) \\ -B^* & \equiv & B \quad \text{except:} \quad B^*_{\mathrm{r}} = r(\Pi(\Gamma(B), B)) +B^* & \equiv & B \quad \text{except:} \quad {\hyperlink{Transaction Receipt}{B^*_{\mathrm{r}}}} = \hyperlink{r}{r}(\hyperlink{Pi}{\Pi}(\Gamma(B), B)) \end{eqnarray} With $\mathbf{d}$ being a dataset as specified in appendix \ref{app:ethash}. -As specified at the beginning of the present work, $\Pi$ is the state-transition function, which is defined in terms of $\Omega$, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. +As specified at the beginning of the present work, \hyperlink{Pi}{$\Pi$} is the state-transition function, which is defined in terms of \hyperlink{Omega}{$\Omega$}, the block finalisation function and \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function, both now well-defined. -As previously detailed, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): +\hyperlink{Transaction_Receipt}{As previously detailed}, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \Upsilon(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \hyperlink{Upsilon}{\Upsilon}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} \end{equation} -In the case of $B_{\mathbf{R}}[n]_{\mathrm{u}}$, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: +In the case of \hyperlink{Transaction_Receipt}{$B_{\mathbf{R}}[n]_{\mathrm{u}}$}, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: \begin{equation} \mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ \begin{array}[b]{l} -\Upsilon^{\mathrm{g}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} +\linkdest{Upsilon_pow_g2}\hyperlink{Upsilon_pow_g}{\Upsilon^{\mathrm{g}}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n])\\ \quad + \mathbf{R}[n-1]_{\mathrm{u}} \end{array} & \text{otherwise} \end{cases} \end{equation} -For $\mathbf{R}[n]_{\mathbf{l}}$, we utilise the $\Upsilon^\mathbf{l}$ function that we conveniently defined in the transaction execution function. +For $\mathbf{R}[n]_{\mathbf{l}}$, we utilise the \hyperlink{Upsilon_pow_l}{$\Upsilon^\mathbf{l}$} function that we conveniently defined in the transaction execution function. \begin{equation} \mathbf{R}[n]_{\mathbf{l}} = \Upsilon^{\mathbf{l}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} -We define $\mathbf{R}[n]_{\mathrm{z}}$ in a similar manner. +We define \hyperlink{Upsilon_pow_z}{$\mathbf{R}[n]_{\mathrm{z}}$} in a similar manner. \begin{equation} \mathbf{R}[n]_{\mathrm{z}} = \Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) \end{equation} -\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\ell(\boldsymbol{\sigma})$: +\hypertarget{Pi}{}Finally, we define $\Pi$ as the new state given the block reward function $\Omega$ applied to the final transaction's resultant state, $\hyperlink{ell}{\ell}(\boldsymbol{\sigma})$: \begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv \Omega(B, \ell(\boldsymbol{\sigma})) \end{equation} -Thus the complete block-transition mechanism, less $\mathtt{PoW}$, the proof-of-work function is defined. +Thus the complete block-transition mechanism is defined, except for $\mathtt{PoW}$, the proof-of-work function. \subsection{Mining Proof-of-Work} \label{ch:pow} From 80a17cde576b646ef875ccb0092b93d02d7566b4 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Thu, 8 Feb 2018 18:40:11 +1100 Subject: [PATCH 431/460] Remove an extra } --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 035001f7..532ac9fb 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1135,7 +1135,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \begin{equation} \Gamma(B) \equiv \begin{cases} \boldsymbol{\sigma}_0 & \text{if} \quad P(B_{H}) = \varnothing \\ -\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small \hyperlink{trie}{TRIE}}}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} +\boldsymbol{\sigma}_{\mathrm{i}}: \mathtt{\small \hyperlink{trie}{TRIE}}(L_{S}(\boldsymbol{\sigma}_{\mathrm{i}})) = {P(B_{H})_{H}}_{\mathrm{r}} & \text{otherwise} \end{cases} \end{equation} From ee356233257027ee07066cc61f855044ff92c7cd Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 9 Feb 2018 14:40:52 +1100 Subject: [PATCH 432/460] but isn't a common word --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index e4f0960f..79ddfc14 100644 --- a/Paper.tex +++ b/Paper.tex @@ -321,7 +321,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (which is not saying much, in that it isn't commonly used) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (but isn't a common word) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} From 0ef2548a32dd3f48e31618c445454cff78adf36c Mon Sep 17 00:00:00 2001 From: William Entriken Date: Mon, 12 Feb 2018 15:36:04 -0500 Subject: [PATCH 433/460] Use build/ directory for building --- build.sh | 11 ++++++----- travis_deploy.sh | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/build.sh b/build.sh index 7f8c44cf..d99ed8cc 100755 --- a/build.sh +++ b/build.sh @@ -16,8 +16,9 @@ fi echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ -bibtex Paper && \ -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ -pdflatex -interaction=errorstopmode -halt-on-error Paper.tex +mkdir build +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ +bibtex build/Paper && \ +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex diff --git a/travis_deploy.sh b/travis_deploy.sh index 766c275c..7a2e09df 100755 --- a/travis_deploy.sh +++ b/travis_deploy.sh @@ -12,7 +12,7 @@ echo "# Automatic build" > README.md echo "Built pdf from \`$SHA\`. See https://github.com/ethereum/yellowpaper/ for details." >> README.md echo "The generated pdf is here: https://ethereum.github.io/yellowpaper/paper.pdf" >> README.md echo '' > index.html -mv Paper.pdf paper.pdf +mv build/Paper.pdf paper.pdf git add -f README.md index.html paper.pdf git commit -m "Built pdf from {$SHA}." From 82abbd3cd60347957b915bfe06a9aa18448a39da Mon Sep 17 00:00:00 2001 From: William Entriken Date: Mon, 12 Feb 2018 16:00:22 -0500 Subject: [PATCH 434/460] Add option to build white paper --- Paper.tex | 10 ++++++---- build.sh | 18 ++++++++++++++++-- 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/Paper.tex b/Paper.tex index d3be65e9..dae7a3ff 100644 --- a/Paper.tex +++ b/Paper.tex @@ -42,7 +42,10 @@ \usepackage[autostyle]{csquotes} \MakeOuterQuote{"} -\input{Version.tex} +% Default rendering options +\definecolor{pagecolor}{rgb}{1,0.98,0.9} +\def\YellowPaperVersionNumber{unknown revision} +\IfFileExists{Options.tex}{\input{Options.tex}} \newcommand{\hcancel}[1]{% \tikz[baseline=(tocancel.base)]{ @@ -51,7 +54,6 @@ }% }% -\definecolor{lightyellow}{rgb}{1,0.98,0.9} \DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} \newcommand*\eg{e.g.\@\xspace} @@ -59,7 +61,7 @@ \newcommand*\ie{i.e.\@\xspace} %\renewcommand{\itemhook}{\setlength{\topsep}{0pt} \setlength{\itemsep}{0pt}\setlength{\leftmargin}{15pt}} -\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium version \YellowPaperVersionNumber{}}}} +\title{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ {\smaller \textbf{Byzantium version \YellowPaperVersionNumber}}} \author{ Dr. Gavin Wood\\ Founder, Ethereum \& Parity\\ @@ -67,7 +69,7 @@ } \begin{document} -\pagecolor{lightyellow} +\pagecolor{pagecolor} \begin{abstract} The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, with Bitcoin being one of the most notable ones. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. diff --git a/build.sh b/build.sh index 7f8c44cf..826428b0 100755 --- a/build.sh +++ b/build.sh @@ -1,19 +1,32 @@ #!/usr/bin/env bash +## +## Usage: build.sh [white] +## + + set -e +rm -rf Options.tex + if [ -d ".git" ]; then SHA=`git rev-parse --short --verify HEAD` DATE=`git show -s --format="%cd" --date=short HEAD` REV="$SHA - $DATE" +echo "\def\YellowPaperVersionNumber{$REV}" >> Options.tex + +fi + -else +if [ "$1" == "white" ]; then -REV="unknown revision" +echo "\definecolor{pagecolor}{rgb}{1,1,1}" >> Options.tex fi + + echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ @@ -21,3 +34,4 @@ bibtex Paper && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex && \ pdflatex -interaction=errorstopmode -halt-on-error Paper.tex +rm -rf Options.tex From 40b1618a6c0fe314cfdac85ecd8ddb83b6cbe8a8 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 01:31:30 +0000 Subject: [PATCH 435/460] Update ommer footnote --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 79ddfc14..af07e53c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -321,7 +321,7 @@ \subsection{The Transaction} \label{ch:transaction} \subsection{The Block} \label{ch:block} -The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is the most prevalent (but isn't a common word) gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: +The block in Ethereum is the collection of relevant pieces of information (known as the block \textit{header}), $H$, together with information corresponding to the comprised transactions, $\mathbf{T}$,\hypertarget{ommerheaders}{} and a set of other block headers $\mathbf{U}$ that are known to have a parent equal to the present block's parent's parent (such blocks are known as \textit{ommers}\footnote{\textit{ommer} is a gender-neutral term to mean ``sibling of parent''; see \url{https://nonbinary.miraheze.org/wiki/Gender_neutral_language\#Aunt.2FUncle}}). The block header contains several pieces of information: %\textit{TODO: Introduce logs} From 9f52e77909fa539d1b2a4a957cfdda56a83b8f98 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 01:50:21 +0000 Subject: [PATCH 436/460] Add a space --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 2d426e56..f4a3bab1 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,7 +2510,7 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. -\begin{tabu*} spread 0pt{X[l] X[c] X} \savetabu{col3} +\begin{tabu*} spread 0pt {X[l] X[c] X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ \midrule From af3eca9ccd3610542b2445cc2597256b449c5cf1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 01:54:20 +0000 Subject: [PATCH 437/460] Re-add removed line --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index f4a3bab1..4b480334 100644 --- a/Paper.tex +++ b/Paper.tex @@ -2510,6 +2510,7 @@ \subsection{Deletion of an Account Despite Out-of-gas} At block 2675119, in the transaction \seqsplit{0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba}, an account at address 0x03 was called and an out-of-gas occurred during the call. Against the equation (\ref{eq:pre}), this added 0x03 in the set of touched addresses, and this transaction turned $\boldsymbol{\sigma}[0x03]$ into $\varnothing$. +\section{List of mathematical symbols} \label{app:symbols} \begin{tabu*} spread 0pt {X[l] X[c] X} \savetabu{col3} \toprule Symbol & Latex Command & Description \hypertarget{bigvee}{}\\ From 4599ee48c8ad08272c2219da06b21cf5def9fdb2 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 02:07:50 +0000 Subject: [PATCH 438/460] Remove maths in English --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 51d2a737..21b2f08d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -595,7 +595,7 @@ \subsection{Execution} where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call. $G_\text{txcreate}$ is added if the transaction is contract-creating, but not if a result of EVM-code. $G$ is fully defined in Appendix \ref{app:fees}. -The up-front cost $v_0$ is calculated as the transaction gas limit multiplied by the gas price, plus the transaction value: +The up-front cost $v_0$ is calculated as: \begin{equation} v_0 \equiv \hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}} \hyperlink{tx_gas_price_T__p}{T_{\mathrm{p}}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} \end{equation} From 5d6bd24767ced653edb5113df70c382c5025b6c1 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 02:25:47 +0000 Subject: [PATCH 439/460] Fix an error --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 04ea35dd..06040a86 100644 --- a/Paper.tex +++ b/Paper.tex @@ -721,9 +721,9 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{p}} & \equiv & p \\ I_{\mathbf{d}} & \equiv & () \\ I_{\mathrm{s}} & \equiv & s \\ -I_{\mathrm{v}} & \equiv & v \\ +\hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & v \\ I_{\mathbf{b}} & \equiv & \mathbf{i} \\ -\hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & e \\ +I_{\mathrm{e}} & \equiv & e \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} From 3356e1719163693dceada812dab9daa8a7b94b06 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 13 Feb 2018 03:38:58 +0000 Subject: [PATCH 440/460] Delete an empty line --- Paper.tex | 1 - 1 file changed, 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index a94c13a0..21211f8c 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1144,7 +1144,6 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \hypertarget{Phi}{}And finally we define $\Phi$, the block transition function, which maps an incomplete block $B$ to a complete block $B'$: \begin{eqnarray} \Phi(B) & \equiv & B': \quad B' = B^* \quad \text{except:} \\ - B'_{\mathrm{n}} & = & n: \quad x \leqslant \frac{2^{256}}{\hyperlink{H__d}{H_{\mathrm{d}}}} \\ B'_{\mathrm{m}} & = & m \quad \text{with } (x, m) = \mathtt{PoW}(B^*_{\hyperlink{H_cancel_n}{\hcancel{n}}}, n, \mathbf{d}) \\ B^* & \equiv & B \quad \text{except:} \quad {\hyperlink{Transaction Receipt}{B^*_{\mathrm{r}}}} = \hyperlink{r}{r}(\hyperlink{Pi}{\Pi}(\Gamma(B), B)) From 7d0f1bc7fcb834a359d9e33a71c7d40afc380d85 Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 22:50:44 -0500 Subject: [PATCH 441/460] Fix the build, #583 --- build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.sh b/build.sh index b549e13d..c527bdda 100755 --- a/build.sh +++ b/build.sh @@ -29,7 +29,7 @@ fi echo "\newcommand{\YellowPaperVersionNumber}{$REV}" > Version.tex -mkdir build +mkdir -p build pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ bibtex build/Paper && \ pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ From 746590d2030103056472cb597251a3ab30e79ceb Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 21:11:11 -0500 Subject: [PATCH 442/460] Use serial comma --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 9556fc95..ad26a8c7 100644 --- a/Paper.tex +++ b/Paper.tex @@ -90,7 +90,7 @@ \section{Introduction}\label{sec:introduction} \subsection{Driving Factors} \label{ch:driving} -There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another. This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience or corruption of existing legal systems. By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end. +There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another. This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience, or corruption of existing legal systems. By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end. Dealings in this proposed system would have several attributes not often found in the real world. The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter. Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in human-based systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake. From 556d87528b5e682e1a32b0452f95c0e3125a8b5a Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 21:30:54 -0500 Subject: [PATCH 443/460] Typos and grammar fixes --- Paper.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Paper.tex b/Paper.tex index ad26a8c7..ff65fcd9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -503,7 +503,7 @@ \subsubsection{Block Header Validity} H'_{\mathrm{i}} &\equiv \max(H_{\mathrm{i}} - 3000000, 0) \end{align} -Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 by \cite{EIP-649} and delayed and implemented earlier in EIP-2. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the demoninator 9, in order to target the mean block time including uncle blocks by \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_{\mathrm{i}}$, which is obtained by substracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. +Note that $\mindifficulty$ is the difficulty of the genesis block. The \textit{Homestead} difficulty parameter, $\homesteadmod$, is used to affect a dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2 by \cite{EIP-2}. In the Homestead release, the exponential difficulty symbol, $\expdiffsymb$ causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the "difficulty bomb", or "ice age", was explained in EIP-649 by \cite{EIP-649} and delayed and implemented earlier in EIP-2. $\homesteadmod$ was also modified in EIP-100 with the use of $x$, the adjustment factor above, and the denominator 9, in order to target the mean block time including uncle blocks by \cite{EIP-100}. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, $H'_{\mathrm{i}}$, which is obtained by subtracting three million from the actual block number, which in other words reduced $\expdiffsymb$ and the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from "freezing" up. \hypertarget{block_gas_limit_H__l}{}The canonical gas limit $H_{\mathrm{l}}$ of a block of header $H$ must fulfil the relation: \begin{eqnarray} @@ -525,7 +525,7 @@ \subsubsection{Block Header Validity} \end{equation} with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. -\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}\linkdest{H_cancel_n}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to proof that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. +\hypertarget{block_header_without_nonce_and_mixmash_h__cancel_n}{}\linkdest{H_cancel_n}Where $H_{\hcancel{n}}$ is the new block's header $H$, but \textit{without} the nonce and mix-hash components, $\mathbf{d}$ being the current DAG, a large data set needed to compute the mix-hash, and $\mathtt{PoW}$ is the proof-of-work function (see section \ref{ch:pow}): this evaluates to an array with the first item being the mix-hash, to prove that a correct DAG has been used, and the second item being a pseudo-random number cryptographically dependent on $H$ and $\mathbf{d}$. Given an approximately uniform distribution in the range $[0, 2^{64})$, the expected time to find a solution is proportional to the difficulty, $H_{\mathrm{d}}$. This is the foundation of the security of the blockchain and is the fundamental reason why a malicious node cannot propagate newly created blocks that would otherwise overwrite (``rewrite'') history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers. @@ -563,7 +563,7 @@ \section{Transaction Execution} \label{ch:transactions} \item The transaction is well-formed RLP, with no additional trailing bytes; \item the transaction signature is valid; \item the \hyperlink{transaction_nonce}{transaction nonce} is valid (equivalent to the \hyperlink{account_nonce}{sender account's current nonce}); -\item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; +\item the gas limit is no smaller than the intrinsic gas, $g_0$, used by the transaction; and \item the sender account balance contains at least the cost, $v_0$, required in up-front payment. \end{enumerate} @@ -1223,7 +1223,7 @@ \subsection{Data Feeds} The general pattern involves a single contract within Ethereum which, when given a message call, replies with some timely information concerning an external phenomenon. An example might be the local temperature of New York City. This would be implemented as a contract that returned that value of some known point in storage. Of course this point in storage must be maintained with the correct such temperature, and thus the second part of the pattern would be for an external server to run an Ethereum node, and immediately on discovery of a new block, creates a new valid transaction, sent to the contract, updating said value in storage. The contract's code would accept such updates only from the identity contained on said server. \subsection{Random Numbers} -Providing random numbers within a deterministic system is, naturally, an impossible task. However, we can approximate with pseudo-random numbers by utilising data which is generally unknowable at the time of transacting. Such data might include the block's hash, the block's timestamp and the block's beneficiary address. In order to make it hard for malicious miner to control those values, one should use the {\small BLOCKHASH} operation in order to use hashes of the previous 256 blocks as pseudo-random numbers. For a series of such numbers, a trivial solution would be to add some constant amount and hashing the result. +Providing random numbers within a deterministic system is, naturally, an impossible task. However, we can approximate with pseudo-random numbers by utilising data which is generally unknowable at the time of transacting. Such data might include the block's hash, the block's timestamp and the block's beneficiary address. In order to make it hard for malicious miners to control those values, one should use the {\small BLOCKHASH} operation in order to use hashes of the previous 256 blocks as pseudo-random numbers. For a series of such numbers, a trivial solution would be to add some constant amount and hashing the result. \section{Future Directions} \label{ch:future} @@ -1382,7 +1382,7 @@ \section{Hex-Prefix Encoding}\label{app:hexprefix} Thus the high nibble of the first byte contains two flags; the lowest bit encoding the oddness of the length and the second-lowest encoding the flag $t$. The low nibble of the first byte is zero in the case of an even number of nibbles and the first nibble in the case of an odd number. All remaining nibbles (now an even number) fit properly into the remaining bytes. \section{Modified Merkle Patricia Tree}\label{app:trie}\hypertarget{trie}{} -The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32 byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. +The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data, typically implemented as a database. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single value that identifies a given set of key-value pairs, which may be either a 32-byte sequence or the empty byte sequence. It is left as an implementation consideration to store and maintain the structure of the trie in a manner that allows effective and efficient realisation of the protocol. Formally, we assume the input value $\mathfrak{I}$, a set containing pairs of byte sequences: \begin{equation} @@ -2335,7 +2335,7 @@ \section{Genesis Block}\label{app:genesis}\hypertarget{Genesis_Block}{} \big( \big( 0_{256}, \mathtt{\tiny KEC}\big(\mathtt{\tiny RLP}\big( () \big)\big), 0_{160}, stateRoot, 0, 0, 0_{2048}, 2^{17}, 0, 0, 3141592, time, 0, 0_{256}, \mathtt{\tiny KEC}\big( (42) \big) \big), (), () \big) \end{equation} -Where $0_{256}$ refers to the parent hash, a 256-bit hash which is all zeroes; $0_{160}$ refers to the beneficiary address, a 160-bit hash which is all zeroes; $0_{2048}$ refers to the log bloom, 2048-bit of all zeros; $2^{17}$ refers to the difficulty; the transaction trie root, receipt trie root, gas used, block number and extradata are both $0$, being equivalent to the empty byte array. The sequences of both ommers and transactions are empty and represented by $()$. $\mathtt{\tiny KEC}\big( (42) \big)$ refers to the Keccak hash of a byte array of length one whose first and only byte is of value 42, used for the nonce. $\mathtt{\tiny KEC}\big(\mathtt{\tiny RLP}\big( () \big)\big)$ value refers to the hash of the ommer lists in RLP, both empty lists. +Where $0_{256}$ refers to the parent hash, a 256-bit hash which is all zeroes; $0_{160}$ refers to the beneficiary address, a 160-bit hash which is all zeroes; $0_{2048}$ refers to the log bloom, 2048-bit of all zeros; $2^{17}$ refers to the difficulty; the transaction trie root, receipt trie root, gas used, block number and extradata are both $0$, being equivalent to the empty byte array. The sequences of both ommers and transactions are empty and represented by $()$. $\mathtt{\tiny KEC}\big( (42) \big)$ refers to the Keccak hash of a byte array of length one whose first and only byte is of value 42, used for the nonce. $\mathtt{\tiny KEC}\big(\mathtt{\tiny RLP}\big( () \big)\big)$ value refers to the hash of the ommer list in RLP, both empty lists. The proof-of-concept series include a development premine, making the state root hash some value $stateRoot$. Also $time$ will be set to the initial timestamp of the genesis block. The latest documentation should be consulted for those values. @@ -2413,7 +2413,7 @@ \subsubsection{Cache} \begin{equation} n = \left\lfloor\frac{c_{size}}{J_{hashbytes}}\right\rfloor \end{equation} -The cache is calculated by performing $J_{cacherounds}$ rounds of the RandMemoHash algorithm to the inital cache $\mathbf{c'}$: +The cache is calculated by performing $J_{cacherounds}$ rounds of the RandMemoHash algorithm to the initial cache $\mathbf{c'}$: \begin{equation} \mathbf{c} = E_{cacherounds}(\mathbf{c'}, J_{cacherounds}) \end{equation} From c11ac358588776ef22ffa7326431e22f465de3ab Mon Sep 17 00:00:00 2001 From: William Entriken Date: Thu, 15 Feb 2018 21:34:33 -0500 Subject: [PATCH 444/460] Standardize on "we" as the first-person author --- Paper.tex | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Paper.tex b/Paper.tex index ff65fcd9..52e348e3 100644 --- a/Paper.tex +++ b/Paper.tex @@ -94,7 +94,7 @@ \subsection{Driving Factors} \label{ch:driving} Dealings in this proposed system would have several attributes not often found in the real world. The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter. Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in human-based systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake. -Overall, I wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about. +Overall, we wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about. \subsection{Previous Work} \label{ch:previous} @@ -171,13 +171,13 @@ \subsection{Which History?} \section{Conventions}\label{ch:conventions} -I use a number of typographical conventions for the formal notation, some of which are quite particular to the present work: +We use a number of typographical conventions for the formal notation, some of which are quite particular to the present work: The two sets of highly structured, `top-level', state values, are denoted with bold lowercase Greek letters. They fall into those of world-state, which are denoted $\boldsymbol{\sigma}$ (or a variant thereupon) and those of machine-state, $\boldsymbol{\mu}$. Functions operating on highly structured values are denoted with an upper-case Greek letter, \eg \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the Ethereum state transition function. -For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg \hyperlink{C__SSTORE}{$C_\text{SSTORE}$}, the cost function for the \hyperlink{SSTORE}{{\tiny SSTORE}} operation. For specialised and possibly externally defined functions, I may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. +For most functions, an uppercase letter is used, e.g. $C$, the general cost function. These may be subscripted to denote specialised variants, \eg \hyperlink{C__SSTORE}{$C_\text{SSTORE}$}, the cost function for the \hyperlink{SSTORE}{{\tiny SSTORE}} operation. For specialised and possibly externally defined functions, we may format as typewriter text, \eg the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted $\texttt{KEC}$ (and generally referred to as plain Keccak). Also $\texttt{KEC512}$ is referring to the Keccak 512 hash function. Tuples are typically denoted with an upper-case letter, \eg $T$, is used to denote an Ethereum transaction. This symbol may, if accordingly defined, be subscripted to refer to an individual component, \eg \hyperlink{transaction_nonce}{$T_{\mathrm{n}}$}, denotes the nonce of said transaction. The form of the subscript is used to denote its type; \eg uppercase subscripts refer to tuples with subscriptable components. @@ -191,11 +191,11 @@ \section{Conventions}\label{ch:conventions} In the case of the global state $\boldsymbol{\sigma}$, which is a sequence of accounts, themselves tuples, the square brackets are used to reference an individual account. -When considering variants of existing values, I follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, I may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. +When considering variants of existing values, we follow the rule that within a given scope for definition, if we assume that the unmodified `input' value be denoted by the placeholder $\Box$ then the modified and utilisable value is denoted as $\Box'$, and intermediate values would be $\Box^*$, $\Box^{**}$ \&c. On very particular occasions, in order to maximise readability and only if unambiguous in meaning, we may use alpha-numeric subscripts to denote intermediate values, especially those of particular note. When considering the use of existing functions, given a function $f$, the function \hyperlink{general_element_wise_sequence_transformation_f_pow_asterisk}{$f^*$} denotes a similar, element-wise version of the function mapping instead between sequences. It is formally defined in section \ref{ch:block}. -I define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: +We define a number of useful functions throughout. \linkdest{ell}One of the more common is $\ell$, which evaluates to the last item in the given sequence: \begin{equation} \ell(\mathbf{x}) \equiv \mathbf{x}[\lVert \mathbf{x} \rVert - 1] @@ -218,7 +218,7 @@ \subsection{World State} \label{ch:state} \item[codeHash] The hash of the EVM code of this account---this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash is formally denoted $\boldsymbol{\sigma}[a]_{\mathrm{c}}$, and thus the code may be denoted as $\mathbf{b}$, given that $\texttt{\small KEC}(\mathbf{b}) = \boldsymbol{\sigma}[a]_{\mathrm{c}}$. \end{description} -Since I typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, I define a convenient equivalence: +Since we typically wish to refer not to the trie's root hash but to the underlying set of key/value pairs stored within, we define a convenient equivalence: \begin{equation} \texttt{\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_{\mathbf{s}})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \end{equation} @@ -1215,7 +1215,7 @@ \subsubsection{Ethash} \section{Implementing Contracts} -There are several patterns of contracts engineering that allow particular useful behaviours; two of these that I will briefly discuss are data feeds and random numbers. +There are several patterns of contracts engineering that allow particular useful behaviours; two of these that we will briefly discuss are data feeds and random numbers. \subsection{Data Feeds} A data feed contract is one which provides a single service: it gives access to information from the external world within Ethereum. The accuracy and timeliness of this information is not guaranteed and it is the task of a secondary contract author---the contract that utilises the data feed---to determine how much trust can be placed in any single data feed. @@ -1243,7 +1243,7 @@ \subsection{Scalability} \section{Conclusion} \label{ch:conclusion} -I have introduced, discussed and formally defined the protocol of Ethereum. Through this protocol the reader may implement a node on the Ethereum network and join others in a decentralised secure social operating system. Contracts may be authored in order to algorithmically specify and autonomously enforce rules of interaction. +We have introduced, discussed and formally defined the protocol of Ethereum. Through this protocol the reader may implement a node on the Ethereum network and join others in a decentralised secure social operating system. Contracts may be authored in order to algorithmically specify and autonomously enforce rules of interaction. \section{Acknowledgements} From 3e4ee16a1543522c6b383d97a81f2bda42e7f7ba Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 20:58:56 +1100 Subject: [PATCH 445/460] \hyperlink zhalt, hhalt --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 52e348e3..642b3a35 100644 --- a/Paper.tex +++ b/Paper.tex @@ -941,7 +941,7 @@ \subsection{Execution Overview} Note that, when we evaluate $\Xi$, we drop the fourth element $I'$ and extract the remaining gas $\boldsymbol{\mu}'_{\mathrm{g}}$ from the resultant machine state $\boldsymbol{\mu}'$. -$X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either $Z$ becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until $H$ becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. +$X$ is thus cycled (recursively here, but implementations are generally expected to use a simple iterative loop) until either \hyperlink{zhalt}{$Z$} becomes true indicating that the present state is exceptional and that the machine must be halted and any changes discarded or until \hyperlink{hhalt}{$H$} becomes a series (rather than the empty set) indicating that the machine has reached a controlled halt. \subsubsection{Machine State} The machine state $\boldsymbol{\mu}$ is defined as the tuple $(g, pc, \mathbf{m}, i, \mathbf{s})$ which are the gas available, the program counter $pc \in \mathbb{P}_{256}$ , the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents $\boldsymbol{\mu}_{\mathbf{m}}$ are a series of zeroes of size $2^{256}$. From c02a7450d0dd1c663df6e9849ebe0a9f7458cc7a Mon Sep 17 00:00:00 2001 From: Alexandre Kurth Date: Fri, 16 Feb 2018 11:05:47 +0100 Subject: [PATCH 446/460] add french translation link --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 752018df..dff723eb 100644 --- a/README.md +++ b/README.md @@ -32,3 +32,4 @@ The previous protocol versions are listed in [BRANCHES.md](./BRANCHES.md). ### Other language versions - [Chinese](https://github.com/yuange1024/ethereum_yellowpaper) translated by YuanGe and GaoTianlu. +- [French](https://github.com/asseth/yellowpaper) translated by Asseth (checkout to branch 'french' ). From 0f86e261e1b3db44f967608b332dd39de194bb7a Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:07:01 +1100 Subject: [PATCH 447/460] \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 073f159cd1c802612e55fe42c176694b22280454 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:28:07 +1100 Subject: [PATCH 448/460] link{R__block} --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 52e348e3..ac81f83b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1110,7 +1110,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_{\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$: +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 \hyperlink{$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:} \\ @@ -1126,7 +1126,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__block}{}We define the block reward as 3 Ether: +\hypertarget{block_reward_R__block}{}\linkdest{R__block}We define the block reward as 3 Ether: \begin{equation} \text{Let} \quad R_{\mathrm{block}} = 3 \times 10^{18} \end{equation} From ba09a5e45acdf52034614fe5935af5b7619ea34e Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:46:54 +1100 Subject: [PATCH 449/460] \hyperlink{Gamma}{\Gamma} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 52e348e3..ea11511f 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1157,7 +1157,7 @@ \subsection{State \& Nonce Validation}\label{sec:statenoncevalidation} \hyperlink{Transaction_Receipt}{As previously detailed}, $\mathbf{R}[n]_{\mathrm{z}}$, $\mathbf{R}[n]_{\mathbf{l}}$ and $\mathbf{R}[n]_{\mathrm{u}}$ are the $n$th corresponding status code, logs and cumulative gas used after each transaction ($\mathbf{R}[n]_{\mathrm{b}}$, the fourth component in the tuple, has already been defined in terms of the logs). We also define the $n$th state $\boldsymbol{\sigma}[n]$, which is defined simply as the state resulting from applying the corresponding transaction to the state resulting from the previous transaction (or the block's initial state in the case of the first such transaction): \begin{equation} -\boldsymbol{\sigma}[n] = \begin{cases} \Gamma(B) & \text{if} \quad n < 0 \\ \hyperlink{Upsilon}{\Upsilon}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} +\boldsymbol{\sigma}[n] = \begin{cases} \hyperlink{Gamma}{\Gamma}(B) & \text{if} \quad n < 0 \\ \hyperlink{Upsilon}{\Upsilon}(\boldsymbol{\sigma}[n - 1], B_{\mathbf{T}}[n]) & \text{otherwise} \end{cases} \end{equation} In the case of \hyperlink{Transaction_Receipt}{$B_{\mathbf{R}}[n]_{\mathrm{u}}$}, we take a similar approach defining each item as the gas used in evaluating the corresponding transaction summed with the previous item (or zero, if it is the first), giving us a running total: From 15ed9942507128fcc0087c71f5d22f6e39c05003 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 21:52:03 +1100 Subject: [PATCH 450/460] \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 a789247634471a475f17d68620b7f5ad06269181 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 23:23:49 +1100 Subject: [PATCH 451/460] change ordering of ECDSAPUBKEY, ECDSASIGN and ECDSARECOVER in text to match math order; ", \eg by \cite{ECDSAcerticom}." --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 9d0df46c..9e14c29d 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1658,10 +1658,10 @@ \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 assume the existence of 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 ECDSAPUBKEY}$, $\mathtt{\small ECDSASIGN}$ and $\mathtt{\small ECDSARECOVER}$. These are formally defined in the literature, \eg by \cite{ECDSAcerticom}. \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}) \\ +\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}) \\ \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_{\mathrm{u}} \in \mathbb{B}_{64} \end{eqnarray} From 80b53ce75716846361e5c9fad44bad8666a01893 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 23:29:22 +1100 Subject: [PATCH 452/460] Move \hypertarget{v}{} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 9d0df46c..6d3558a2 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1665,7 +1665,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_{\mathrm{u}} \in \mathbb{B}_{64} \end{eqnarray} -Where $p_{\mathrm{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_{\mathrm{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. +Where $p_{\mathrm{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_{\mathrm{r}}$ is the private key, a byte array of size 32 (or a single positive integer in the aforementioned range). It is assumed that \hypertarget{v}{}$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 68450096e7c138bde782e760e7a4b969d46e799f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Fri, 16 Feb 2018 23:30:41 +1100 Subject: [PATCH 453/460] \hyperlink{v}{v} --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 9d0df46c..b6fb1ad9 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1673,7 +1673,7 @@ \section{Signing Transactions}\label{app:signing} \begin{align} 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\} +\hyperlink{v}{v} &\in \{27,28,\mathtt{\tiny chain\_{\mathrm{id}}} \times 2 + 35, \mathtt{\tiny chain\_{\mathrm{id}}} \times 2 + 36\} \end{align} where: \begin{align} From e8655e8439fc686813003389dfc6a4446581a69f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 17 Feb 2018 00:11:45 +1100 Subject: [PATCH 454/460] consolidated => consolidating --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 1497d6ff..c05933ca 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1236,7 +1236,7 @@ \subsection{Scalability} Scalability remains an eternal concern. With a generalised state transition function, it becomes difficult to partition and parallelise transactions to apply the divide-and-conquer strategy. Unaddressed, the dynamic value-range of the system remains essentially fixed and as the average transaction value increases, the less valuable of them become ignored, being economically pointless to include in the main ledger. However, several strategies exist that may potentially be exploited to provide a considerably more scalable protocol. -Some form of hierarchical structure, achieved by either consolidating smaller lighter-weight chains into the main block or building the main block through the incremental combination and adhesion (through proof-of-work) of smaller transaction sets may allow parallelisation of transaction combination and block-building. Parallelism could also come from a prioritised set of parallel blockchains, consolidated each block and with duplicate or invalid transactions thrown out accordingly. +Some form of hierarchical structure, achieved by either consolidating smaller lighter-weight chains into the main block or building the main block through the incremental combination and adhesion (through proof-of-work) of smaller transaction sets may allow parallelisation of transaction combination and block-building. Parallelism could also come from a prioritised set of parallel blockchains, consolidating each block and with duplicate or invalid transactions thrown out accordingly. Finally, verifiable computation, if made generally available and efficient enough, may provide a route to allow the proof-of-work to be the verification of final state. From ccb9bd5dc822df0da4d1e266b495259cfec2c51b Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 17 Feb 2018 00:17:56 +1100 Subject: [PATCH 455/460] 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: From 53bb43472253f0556e9b2b3cfde46df90ad90a41 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 17 Feb 2018 17:31:11 +1100 Subject: [PATCH 456/460] https://github.com/ethereum/yellowpaper/tree/frontier --- BRANCHES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BRANCHES.md b/BRANCHES.md index 6f776007..c560c254 100644 --- a/BRANCHES.md +++ b/BRANCHES.md @@ -9,4 +9,4 @@ Each protocol version is specified in `Paper.tex` found in a branch of this repo | 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,150,000 until 1,919,999 | -| frontier | [Frontier](https://github.com/ethereum/yellowpaper/) | Since 1 until 1,149,999 | +| frontier | [Frontier](https://github.com/ethereum/yellowpaper/tree/frontier) | Since 1 until 1,149,999 | From e3a869cd0aef184b6ee676b4075439c905180820 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Sat, 17 Feb 2018 17:48:44 +1100 Subject: [PATCH 457/460] Fix a link --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index ac81f83b..91281792 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1110,7 +1110,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 \hyperlink{$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$: +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 \hyperlink{R__block}{$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:} \\ From 03b39724d55b1e5bbc4cdee02df2892424711d3a Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 19 Feb 2018 12:40:47 +0100 Subject: [PATCH 458/460] Make sure that build fails when latex fails `set -e` seems to be non-effective in Travis build --- build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.sh b/build.sh index c527bdda..59ae535e 100755 --- a/build.sh +++ b/build.sh @@ -34,5 +34,5 @@ pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper 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 +pdflatex -output-directory=build -interaction=errorstopmode -halt-on-error Paper.tex && \ rm -rf Options.tex From 4dbe03e32283c0d264859d68aebed999c8612d14 Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 20 Feb 2018 12:07:47 +1100 Subject: [PATCH 459/460] dummy --- Paper.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/Paper.tex b/Paper.tex index cee208fe..7eeea75a 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1,3 +1,4 @@ +% \documentclass[9pt,oneside]{amsart} %\usepackage{tweaklist} \usepackage{cancel} From d08b01c4648c29e0eef4cd5c04ec7ff2c5a6606f Mon Sep 17 00:00:00 2001 From: James Ray <16969914+jamesray1@users.noreply.github.com> Date: Tue, 20 Feb 2018 12:09:17 +1100 Subject: [PATCH 460/460] Replace all \s\b([ceg-hmnz])\b with " \mathrm{$1}" using Libre Open Office with match case and regular expressions ticked as options. --- Paper.tex | 143 +++++++++++++++++++++++++++--------------------------- 1 file changed, 71 insertions(+), 72 deletions(-) diff --git a/Paper.tex b/Paper.tex index 7eeea75a..7d06a719 100644 --- a/Paper.tex +++ b/Paper.tex @@ -1,4 +1,3 @@ -% \documentclass[9pt,oneside]{amsart} %\usepackage{tweaklist} \usepackage{cancel} @@ -453,7 +452,7 @@ \subsubsection{Serialisation} where \begin{equation} -\mathbb{B}_{\mathrm{n}} = \{ B: B \in \mathbb{B} \wedge \lVert B \rVert = n \} +\mathbb{B}_{\mathrm{n}} = \{ B: B \in \mathbb{B} \wedge \lVert B \rVert = \mathrm{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. @@ -521,9 +520,9 @@ \subsubsection{Block Header Validity} 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}} +n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \wedge \quad \mathrm{m} = H_{\mathrm{m}} \end{equation} -with $(n, m) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$. +with $(n, \mathrm{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 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}}$. @@ -531,7 +530,7 @@ \subsubsection{Block Header Validity} \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_{\mathrm{d}}} \wedge m = H_{\mathrm{m}} \quad \wedge \\ +V(H) & \equiv & \mathrm{n} \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \wedge \mathrm{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)_{H}}_{\mathrm{l}} + \left\lfloor\frac{{P(H)_{H}}_{\mathrm{l}}}{1024}\right\rfloor \quad \wedge \\ @@ -541,7 +540,7 @@ \subsubsection{Block Header Validity} & & 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})$ +where $(n, \mathrm{m}) = \mathtt{PoW}(H_{\hcancel{n}}, H_{\mathrm{n}}, \mathbf{d})$ Noting additionally that \textbf{extraData} must be at most 32 bytes. @@ -627,9 +626,9 @@ \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} +(\boldsymbol{\sigma}_{P}, \mathrm{g}', A, \mathrm{z}) \equiv \begin{cases} +\Lambda_{4}(\boldsymbol{\sigma}_0, S(T), T_{\mathrm{o}}, &\\ \quad\quad \mathrm{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}}, \mathrm{g}, T_{\mathrm{p}}, T_{\mathrm{v}}, T_{\mathrm{v}}, T_{\mathbf{d}}, 0, \top) & \text{otherwise} \end{cases} \end{equation} @@ -643,16 +642,16 @@ \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, \hyperlink{refund_balance_defn_words_A__r}{A_{\mathrm{r}}} \} +g^* \equiv \mathrm{g}' + \min \{ \Big\lfloor \dfrac{T_{\mathrm{g}} - \mathrm{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 \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 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}} - \mathrm{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} \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}} \\ +\boldsymbol{\sigma}^*[S(T)]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{P}[S(T)]_{\mathrm{b}} + \mathrm{g}^* T_{\mathrm{p}} \\ +\boldsymbol{\sigma}^*[m]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{P}[m]_{\mathrm{b}} + (T_{\mathrm{g}} - \mathrm{g}^*) T_{\mathrm{p}} \\ m & \equiv & {B_{H}}_{\mathrm{c}} \end{eqnarray} @@ -665,9 +664,9 @@ \subsection{Execution} \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^{\mathrm{g}}(\boldsymbol{\sigma}, T) & \equiv & T_{\mathrm{g}} - \mathrm{g}' \\ \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 +\Upsilon^{\mathrm{z}}(\boldsymbol{\sigma}, T) & \equiv & \mathrm{z} \end{eqnarray} 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. @@ -676,9 +675,9 @@ \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$). -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}: +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}', \mathrm{g}', A, \mathbf{o})$, as in section \ref{ch:transactions}: \begin{equation} -(\boldsymbol{\sigma}', g', A, z, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, g, p, v, \mathbf{i}, e, w) +(\boldsymbol{\sigma}', \mathrm{g}', A, \mathrm{z}, \mathbf{o}) \equiv \Lambda(\boldsymbol{\sigma}, s, o, \mathrm{g}, p, v, \mathbf{i}, \mathrm{e}, w) \end{equation} 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$: @@ -714,7 +713,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} 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, \{s, a\}) \\ +(\boldsymbol{\sigma}^{**}, \mathrm{g}^{**}, A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}^*, \mathrm{g}, I, \{s, a\}) \\ \end{equation} \pagebreak[1]where $I$ contains the parameters of the \hyperlink{exec_env}{execution environment}, that is:\pagebreak[1] \begin{eqnarray} @@ -725,7 +724,7 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} I_{\mathrm{s}} & \equiv & s \\ \hyperlink{I__v}{I_{\mathrm{v}}} & \equiv & v \\ I_{\mathbf{b}} & \equiv & \mathbf{i} \\ -I_{\mathrm{e}} & \equiv & e \\ +I_{\mathrm{e}} & \equiv & \mathrm{e} \\ I_{\mathrm{w}} & \equiv & w \end{eqnarray} @@ -738,16 +737,16 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} c \equiv G_{codedeposit} \times |\mathbf{o}| \end{equation} -If there is not enough gas remaining to pay this, \ie $g^{**} < c$, then we also declare an out-of-gas exception. +If there is not enough gas remaining to pay this, \ie $g^{**} < \mathrm{c}$, then we also declare an out-of-gas exception. 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, z)$ 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}', \mathrm{g}', A, \mathrm{z})$ where: \begin{align} -\quad g' &\equiv \begin{cases} +\quad \mathrm{g}' &\equiv \begin{cases} 0 & \text{if} \quad F \\ -g^{**} - c & \text{otherwise} \\ +g^{**} - \mathrm{c} & \text{otherwise} \\ \end{cases} \\ \quad \boldsymbol{\sigma}' &\equiv \begin{cases} \boldsymbol{\sigma} & \text{if} \quad F \\ @@ -756,12 +755,12 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{} \boldsymbol{\sigma}^{**} \quad \text{except:} & \\ \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 \\ +\quad \mathrm{z} &\equiv \begin{cases} +0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \lor \mathrm{g}^{**} < \mathrm{c} \\ 1 & \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) +F &\equiv \big((\boldsymbol{\sigma}^{**} = \varnothing \ \wedge\ \mathbf{o} = \varnothing) \vee\ \mathrm{g}^{**} < \mathrm{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. @@ -776,7 +775,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, z, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, c, g, p, v, \tilde{v}, \mathbf{d}, e, w) +(\boldsymbol{\sigma}', \mathrm{g}', A, \mathrm{z}, \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, s, o, r, \mathrm{c}, \mathrm{g}, p, v, \tilde{v}, \mathbf{d}, \mathrm{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. @@ -828,23 +827,23 @@ \section{Message Call} \label{ch:call} 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 \\ -\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} \\ +\qquad (\boldsymbol{\sigma}^{**}, \mathrm{g}^{**}, A, \mathbf{o}) & \equiv & \begin{cases} +\Xi_{\mathtt{ECREC}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 1 \\ +\Xi_{\mathtt{SHA256}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 2 \\ +\Xi_{\mathtt{RIP160}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 3 \\ +\Xi_{\mathtt{ID}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 4 \\ +\Xi_{\mathtt{EXPMOD}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 5 \\ +\Xi_{\mathtt{BN\_ADD}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 6 \\ +\Xi_{\mathtt{BN\_MUL}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 7 \\ +\Xi_{\mathtt{SNARKV}}(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{if} \quad r = 8 \\ +\Xi(\boldsymbol{\sigma}_1, \mathrm{g}, I, \mathbf{t}) & \text{otherwise} \end{cases} \\ I_{\mathrm{a}} & \equiv & r \\ I_{\mathrm{o}} & \equiv & o \\ I_{\mathrm{p}} & \equiv & p \\ I_{\mathbf{d}} & \equiv & \mathbf{d} \\ I_{\mathrm{s}} & \equiv & s \\ I_{\mathrm{v}} & \equiv & \tilde{v} \\ -I_{\mathrm{e}} & \equiv & e \\ +I_{\mathrm{e}} & \equiv & \mathrm{e} \\ I_{\mathrm{w}} & \equiv & w \\ \mathbf{t} & \equiv & \{s, r\} \\ \\ \nonumber @@ -898,7 +897,7 @@ \subsection{Execution Environment}\linkdest{exec_env} 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: \begin{equation} -(\boldsymbol{\sigma}', g', A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, g, I) +(\boldsymbol{\sigma}', \mathrm{g}', A, \mathbf{o}) \equiv \Xi(\boldsymbol{\sigma}, \mathrm{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}$, the touched accounts $\mathbf{t}$ and the refunds $r$: @@ -913,9 +912,9 @@ \subsection{Execution Overview} \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}'_{\mathrm{g}}, A, \mathbf{o}) \\ +\Xi(\boldsymbol{\sigma}, \mathrm{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}_{\mathrm{g}} & \equiv & g \\ +\boldsymbol{\mu}_{\mathrm{g}} & \equiv & \mathrm{g} \\ \boldsymbol{\mu}_{pc} & \equiv & 0 \\ \boldsymbol{\mu}_{\mathbf{m}} & \equiv & (0, 0, ...) \\ \boldsymbol{\mu}_{\mathrm{i}} & \equiv & 0 \\ @@ -934,7 +933,7 @@ \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, \mathrm{c}, d) \cdot \mathrm{e} & \equiv & (a, b, \mathrm{c}, d, \mathrm{e}) \\ \boldsymbol{\mu}' & \equiv & \boldsymbol{\mu}\ \text{except:} \\ \boldsymbol{\mu}'_{\mathrm{g}} & \equiv & \boldsymbol{\mu}_{\mathrm{g}} - C(\boldsymbol{\sigma}, \boldsymbol{\mu}, I) \end{eqnarray} @@ -1087,9 +1086,9 @@ \subsection{Ommer Validation} where $k$ denotes the ``is-kin'' property: \begin{equation} -k(U, H, n) \equiv \begin{cases} false & \text{if} \quad n = 0 \\ +k(U, H, \mathrm{n}) \equiv \begin{cases} false & \text{if} \quad \mathrm{n} = 0 \\ s(U, H) &\\ -\quad \vee \; k(U, P(H)_{H}, n - 1) & \text{otherwise} +\quad \vee \; k(U, P(H)_{H}, \mathrm{n} - 1) & \text{otherwise} \end{cases} \end{equation} @@ -1146,8 +1145,8 @@ \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'_{\mathrm{n}} & = & \mathrm{n}: \quad x \leqslant \frac{2^{256}}{\hyperlink{H__d}{H_{\mathrm{d}}}} \\ +B'_{\mathrm{m}} & = & \mathrm{m} \quad \text{with } (x, \mathrm{m}) = \mathtt{PoW}(B^*_{\hyperlink{H_cancel_n}{\hcancel{n}}}, \mathrm{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)) \end{eqnarray} @@ -1157,12 +1156,12 @@ \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} \hyperlink{Gamma}{\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 \mathrm{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: \begin{equation} -\mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad n < 0 \\ +\mathbf{R}[n]_{\mathrm{u}} = \begin{cases} 0 & \text{if} \quad \mathrm{n} < 0 \\ \begin{array}[b]{l} \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} @@ -1202,7 +1201,7 @@ \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_{\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}) +m = H_{\mathrm{m}} \quad \wedge \quad \mathrm{n} \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \text{with} \quad (m, \mathrm{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_{\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. @@ -1333,8 +1332,8 @@ \section{Recursive Length Prefix}\label{app:rlp}\hypertarget{rlp}{} (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_{\mathrm{n}} \cdot 256^{\lVert \mathbf{b} \rVert - 1 - n} \\ -(a) \cdot (b, c) \cdot (d, e) & = & (a, b, c, d, e) +\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 - \mathrm{n}} \\ +(a) \cdot (b, \mathrm{c}) \cdot (d, \mathrm{e}) & = & (a, b, \mathrm{c}, d, \mathrm{e}) \end{eqnarray} 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. @@ -1413,7 +1412,7 @@ \section{Modified Merkle Patricia Tree}\label{app:trie}\hypertarget{trie}{} \begin{equation} n(\mathfrak{I}, i) \equiv \begin{cases} () & \text{if} \quad \mathfrak{I} = \varnothing \\ -c(\mathfrak{I}, i) & \text{if} \quad \lVert c(\mathfrak{I}, i)\rVert < 32 \\ +c(\mathfrak{I}, i) & \text{if} \quad \lVert \mathrm{c}(\mathfrak{I}, i)\rVert < 32 \\ \texttt{\small KEC}(c(\mathfrak{I}, i)) & \text{otherwise} \end{cases} \end{equation} @@ -1429,9 +1428,9 @@ \section{Modified Merkle Patricia Tree}\label{app:trie}\hypertarget{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), \mathrm{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) \\ +u(j) & \equiv & \mathrm{n}(\{ I : I \in \mathfrak{I} \wedge I_0[i] = j \}, i + 1) \\ v & = & \begin{cases} I_1 & \text{if} \quad \exists I: I \in \mathfrak{I} \wedge \lVert I_0 \rVert = i \\ () & \text{otherwise} @@ -1449,9 +1448,9 @@ \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_{\mathrm{r}} \\ -(\boldsymbol\sigma, g - g_{\mathrm{r}}, A^0, \mathbf{o}) & \text{otherwise}\end{cases} +\Xi_{\mathtt{PRE}}(\boldsymbol{\sigma}, \mathrm{g}, I, T) \equiv \begin{cases} +(\varnothing, 0, A^0, ()) & \text{if} \quad \mathrm{g} < g_{\mathrm{r}} \\ +(\boldsymbol\sigma, \mathrm{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_{\mathrm{r}}$, the gas requirements. @@ -1861,7 +1860,7 @@ \subsection{Gas Cost} Another useful function is ``all but one 64th'' function~$L$ defined as: \begin{equation} -L(n) \equiv n - \lfloor n / 64 \rfloor +L(n) \equiv \mathrm{n} - \lfloor \mathrm{n} / 64 \rfloor \end{equation} \subsection{Instruction Set} @@ -2053,7 +2052,7 @@ \subsection{Instruction Set} &&&& 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_{\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}$ \\ +&&&& $P(h, \mathrm{n}, a) \equiv \begin{cases} 0 & \text{if} \quad \mathrm{n} > H_{\mathrm{i}} \vee a = 256 \vee \mathrm{h} = 0 \\ \mathrm{h} & \text{if} \quad \mathrm{n} = H_{\mathrm{i}} \\ P(H_{\mathrm{p}}, \mathrm{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 @@ -2138,15 +2137,15 @@ \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 \mathrm{c}(\boldsymbol{\mu}_{pc} + 1)$ \\ +&&&& $\text{where} \quad \mathrm{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)$ \\ -&&&& with $\boldsymbol{c}(\boldsymbol{x}) \equiv (c(\boldsymbol{x}_0), ..., c(\boldsymbol{x}_{\lVert x \rVert -1})) $ with $c$ as defined as above. \\ +&&&& with $\boldsymbol{c}(\boldsymbol{x}) \equiv (c(\boldsymbol{x}_0), ..., \mathrm{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} \\ @@ -2239,11 +2238,11 @@ \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_{\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}$ \\ +&&&& $(\boldsymbol{\sigma}', \mathrm{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}, \mathrm{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{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[5] \dots (\boldsymbol{\mu}_{\mathbf{s}}[5] + \mathrm{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}'_{\mathrm{g}} \equiv \boldsymbol{\mu}_{\mathrm{g}} + \mathrm{g}'$ \\ &&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv x$ \\ &&&& $A' \equiv A \Cup A^+$ \\ &&&& $t \equiv \boldsymbol{\mu}_{\mathbf{s}}[1] \mod 2^{160}$ \\ @@ -2274,7 +2273,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_{\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}$ \\ +&&&& $(\boldsymbol{\sigma}', \mathrm{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}, \mathrm{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.\\ @@ -2294,7 +2293,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_{\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}', \mathrm{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}, \mathrm{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\\ @@ -2328,7 +2327,7 @@ \subsection{Instruction Set} 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 \\ +G_{newaccount} & \text{if} \quad \mathrm{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$ \\ @@ -2415,10 +2414,10 @@ \subsubsection{Cache} \end{equation} Therefore $ \mathbf{c'}$ can be defined as \begin{equation} - \mathbf{c'}[i] = \mathbf{c}_{i} \quad \forall \quad i < n + \mathbf{c'}[i] = \mathbf{c}_{i} \quad \forall \quad i < \mathrm{n} \end{equation} \begin{equation} - n = \left\lfloor\frac{c_{size}}{J_{hashbytes}}\right\rfloor + \mathrm{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 initial cache $\mathbf{c'}$: \begin{equation} @@ -2433,10 +2432,10 @@ \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)\linkdest{E__cacherounds}{} + E_\text{\tiny RMH}(\mathbf{x}) = \big( E_{rmh}(\mathbf{x}, 0), E_{rmh}(\mathbf{x}, 1), ... , E_{rmh}(\mathbf{x}, \mathrm{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]) \\ + E_{rmh}(\mathbf{x}, i) = \texttt{KEC512}(\mathbf{x'}[(i - 1 + \mathrm{n}) \mod \mathrm{n}] \oplus \mathbf{x'}[\mathbf{x'}[i][0] \mod \mathrm{n}]) \\ \text{with} \quad \mathbf{x'} = \mathbf{x} \quad \text{except} \quad \mathbf{x'}[j] = E_{rmh}(\mathbf{x}, j) \quad \forall \quad j < i \end{multline}