diff --git a/Biblio.bib b/Biblio.bib index 53b39313..05703633 100644 --- a/Biblio.bib +++ b/Biblio.bib @@ -94,3 +94,10 @@ @article{buterin2013ethereum year = {{2013}}, } +@article{back2002hashcash, + url = {{http://www.hashcash.org/papers/amortizable.pdf}}, + author = {Adam Back}, + title = {{Hashcash - Amortizable Publicly Auditable Cost-Functions}}, + year = {{2002}}, +} + diff --git a/Paper.tex b/Paper.tex index 4be47226..3875be2b 100644 --- a/Paper.tex +++ b/Paper.tex @@ -77,9 +77,9 @@ \subsection{Previous Work} \label{ch:previous} \cite{buterin2013ethereum} first proposed the kernel of this work in late November, 2013. Though now evolved in many ways, the key functionality of a block-chain with a Turing-complete language and an effectively unlimited inter-transaction storage capability remains unchanged. -Hashcash, introduced by \cite{laurie2004proof}, provided the first work into the usage of a cryptographic proof of computational expenditure as a means of transmitting a value signal over the Internet. Though not widely adopted, the work was later utilised and expanded upon by \cite{nakamoto2008bitcoin} in order to devise a cryptographically secure mechanism for coming to a decentralised social consensus over the order and contents of a series of cryptographically signed financial transactions. The fruits of this project, Bitcoin, provided a first glimpse into a decentralised transaction ledger. +Hashcash, introduced by \cite{back2002hashcash} (in a five-year retrospective), provided the first work into the usage of a cryptographic proof of computational expenditure as a means of transmitting a value signal over the Internet. Though not widely adopted, the work was later utilised and expanded upon by \cite{nakamoto2008bitcoin} in order to devise a cryptographically secure mechanism for coming to a decentralised social consensus over the order and contents of a series of cryptographically signed financial transactions. The fruits of this project, Bitcoin, provided a first glimpse into a decentralised transaction ledger. -Other projects built on Bitcoin's success; the alt-coins introduced numerous other currencies through alteration to the protocol. 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. +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. Other projects still aim to build upon the Bitcoin network itself, leveraging the large amount of value placed in the system and the vast amount of computation that goes into the consensus mechanism. The Mastercoin project, first proposed by \cite{mastercoin2013willett}, aims to build a richer protocol involving many additional high-level features on top of the Bitcoin protocol through utilisation of a number of auxiliary parts to the core protocol. The Coloured Coins project, proposed by \cite{colouredcoins2012rosenfeld}, takes a similar but more simplified strategy, embellishing the rules of a transaction in order to break the fungibility of Bitcoin's base currency and allow the creation and tracking of tokens through a special ``chroma-wallet''-protocol-aware piece of software. @@ -184,13 +184,13 @@ \subsection{World State} \label{ch:state} The account state comprises the first two, and potentially the last two, of the following fields: \begin{description} -\item[nonce] A scalar value equal to the number of transactions sent from this address, or, in the case of contract accounts, 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] 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[stateRoot] A 256-bit hash of the root node of a trie structure that encodes the storage contents of the contract, itself a simple mapping between byte arrays of size 32. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. 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 equi valence $\texttt{\small TRIE}(\boldsymbol{\sigma}[a]_\mathbf{s}) \equiv \boldsymbol{\sigma}[a]_s$. 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. -\item[codeHash] The hash of the EVM code of this contract---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 SHA3}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. +\item[stateRoot] A 256-bit hash of the root node of a trie structure that encodes the storage contents of the account, itself a simple mapping between byte arrays of size 32. The hash is formally denoted $\boldsymbol{\sigma}[a]_s$. 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 equi valence $\texttt{\small TRIE}(\boldsymbol{\sigma}[a]_\mathbf{s}) \equiv \boldsymbol{\sigma}[a]_s$. 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. +\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 SHA3}(\mathbf{b}) = \boldsymbol{\sigma}[a]_c$. \end{description} -If the latter field is the SHA3 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_c = \texttt{\small SHA3}\big(()\big)$, then the node represents a simple account, sometimes refered to as a ``non-contract'' account. +If the latter field is the SHA3 hash of the empty string, i.e. $\boldsymbol{\sigma}[a]_c = \texttt{\small SHA3}\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$: \begin{equation} @@ -212,24 +212,24 @@ \subsection{World State} \label{ch:state} \subsection{The Transaction} \label{ch:transaction} -A transaction (formally, $T$) is a single cryptographically-signed instruction sent by an actor external to Ethereum. An external actor can be a person (via a mobile device or desktop computer) or could be from a piece of automated software running on a server. There are two types of transactions: those which result in message calls and those which result in the creation of new contracts. Both types specify a number of common fields: +A transaction (formally, $T$) is a single cryptographically-signed instruction sent by an actor external to Ethereum. An external actor can be a person (via a mobile device or desktop computer) or could be from a piece of automated software running on a server. 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[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 contract's account; formally $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[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 the zero address for a contract-creation transaction; formally $T_t$. +\item[to] The 160-bit address of the message call's recipient or the zero address for a contract creation transaction; formally $T_t$. \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} -Additionally, a contract-creation transaction contains: +Additionally, a contract creation transaction contains: \begin{description} -\item[init] An unlimited size byte array specifying the EVM-code for the contract 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 executed 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 contract creation and that gets discarded immediately thereafter. +\textbf{init} is an EVM-code fragment; it returns the \textbf{body}, a second fragment of code that executed 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. However, a message call transaction contains: @@ -408,9 +408,9 @@ \subsubsection{Block Header Validity} \section{Gas and Payment} \label{ch:payment} -In order to avoid issues of network abuse and to sidestep the inevitable questions stemming from Turing completeness, all programmable computation in Ethereum is subject to fees. The fee schedule is specified in units of \textit{gas} (see Appendix \ref{app:fees} for the fees associated with various computation). Thus any given fragment of programmable computation (this includes creating contracts, making message calls, utilising and accessing contract storage and executing operations on the virtual machine) has a universally agreed cost in terms of gas. +In order to avoid issues of network abuse and to sidestep the inevitable questions stemming from Turing completeness, all programmable computation in Ethereum is subject to fees. The fee schedule is specified in units of \textit{gas} (see Appendix \ref{app:fees} for the fees associated with various computation). Thus any given fragment of programmable computation (this includes creating contracts, making message calls, utilising and accessing account storage and executing operations on the virtual machine) has a universally agreed cost in terms of gas. -Every transaction has a specific amount of gas associated with it: \textbf{gasLimit}. This is the amount of gas which is implicitly purchased from the sender's account balance. The purchase happens at the according \textbf{gasPrice}, also specified in the transaction. The transaction is considered invalid if the account balance cannot support such a purchase. It is named \textbf{gasLimit} since any unused gas at the end of the transaction is refunded (at the same rate of purchase) to the sender's account. Gas does not exist outside of the execution of a transaction. Thus for trusted contracts, a relatively high gas limit may be set and left alone. +Every transaction has a specific amount of gas associated with it: \textbf{gasLimit}. This is the amount of gas which is implicitly purchased from the sender's account balance. The purchase happens at the according \textbf{gasPrice}, also specified in the transaction. The transaction is considered invalid if the account balance cannot support such a purchase. It is named \textbf{gasLimit} since any unused gas at the end of the transaction is refunded (at the same rate of purchase) to the sender's account. Gas does not exist outside of the execution of a transaction. Thus for accounts with trusted code associated, a relatively high gas limit may be set and left alone. In general, Ether used to purchase gas that is not refunded is delivered to the \textit{coinbase} address, the address of an account typically under the control of the miner. Transactors are free to specify any \textbf{gasPrice} that they wish, however miners are free to ignore transactions as they choose. A higher gas price on a transaction will therefore cost the sender more in terms of Ether and deliver a greater value to the miner and thus will more likely be selected for inclusion by more miners. Miners, in general, will choose to advertise the minimum gas price for which they will execute transactions and transactors will be free to canvas these prices in determining what gas price to offer. Since there will be a (weighted) distribution of minimum acceptable gas prices, transactors will necessarily have a trade-off to make between lowering the gas price and maximising the chance that their transaction will be mined in a timely manner. @@ -509,14 +509,14 @@ \section{Transaction Execution} \label{ch:transactions} \section{Contract Creation} \label{ch:create} -There are number of intrinsic parameters used when creating a contract: sender ($s$), nonce ($n$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code. +There are number of intrinsic parameters used when creating an account: sender ($s$), nonce ($n$), available gas ($g$), gas price ($p$), endowment ($v$) together with an arbitrary length byte array, $\mathbf{i}$, the initialisation EVM code. We define the creation function formally as the function $\Lambda$, which evaluates from these values, together with the state $\boldsymbol{\sigma}_0$ to the tuple containing the new state, additional database entries and remaining gas $(\boldsymbol{\sigma}_P, g')$, as in section \ref{ch:transactions}: \begin{equation} (\boldsymbol{\sigma}_P, g') \equiv \Lambda(\boldsymbol{\sigma}_0, s, n, g, p, v, \mathbf{i}) \end{equation} -The address of the new contract is defined as being the rightmost 160 bits of the SHA3 hash of RLP encoding of the structure containing only the sender and the nonce. In the unlikely event that the address is already in use, it is treated as a big-endian integer and incremented by one until an unused address is arrived at. Thus we define the creation address function $A$: +The address of the new account is defined as being the rightmost 160 bits of the SHA3 hash of RLP encoding of the structure containing only the sender and the nonce. In the unlikely event that the address is already in use, it is treated as a big-endian integer and incremented by one until an unused address is arrived at. Thus we define the creation address function $A$: \begin{eqnarray} A(s, n) & \equiv & a \quad \text{where:} \\ a & = & \arg \min_x : x \geqslant a' \wedge \boldsymbol{\sigma}_0[x] = \varnothing \\ @@ -533,7 +533,7 @@ \section{Contract Creation} \label{ch:create} where $a$ is the address of the new account, as defined above. It is asserted that the state database will also change such that it defines the pair $(\mathtt{\tiny SHA3}(\mathbf{b}), \mathbf{b})$. -Finally, the contract 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 contract's storage can be altered, further contracts 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}^{**}$ and available gas remaining $g'$. +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}^{**}$ and available gas remaining $g'$. Code execution depletes gas; thus it may exit before the code has come to a natural halting state. In this exceptional case 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. The gas remaining should be zero. If the creation was conducted as the receiptation of a transaction, then this doesn't affect payment of the intrinsic cost: it is paid regardless. @@ -558,7 +558,7 @@ \section{Contract Creation} \label{ch:create} I_\mathbf{b} & \equiv & \mathbf{i} \end{eqnarray} -$I_\mathbf{d}$ evaluates to the empty tuple. $I_H$ has no special treatment and are determined from the blockchain. The exception in the determination of $\boldsymbol{\sigma}_P$ dictates that the resultant byte sequence from the execution of the initialisation code specifies the final body code for the newly-created contract's account, with $\boldsymbol{\sigma}_P[A(s, \boldsymbol{\sigma}[s]_n)]_{\mathbf{b}}$ being the newly created account's body code and $\mathbf{o}$ the output byte sequence of the code execution. +$I_\mathbf{d}$ evaluates to the empty tuple. $I_H$ has no special treatment and are determined from the blockchain. The exception in the determination of $\boldsymbol{\sigma}_P$ dictates that the resultant byte sequence from the execution of the initialisation code specifies the final body code for the newly-created account, with $\boldsymbol{\sigma}_P[A(s, \boldsymbol{\sigma}[s]_n)]_{\mathbf{b}}$ being the newly created account's body code and $\mathbf{o}$ the output byte sequence of the code execution. \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, no code is set. 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. @@ -576,7 +576,7 @@ \section{Message Call} \label{ch:call} \boldsymbol{\sigma}_1[r]_b & \equiv & \boldsymbol{\sigma}_1[r]_b + v \end{eqnarray} -The contract's body code (identified as the fragment whose SHA3 hash is $\boldsymbol{\sigma}[r]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts due to an exhausted gas supply, then no gas is refunded to the caller and the state is reverted to the point immediately prior to code execution. +The account's associated code (identified as the fragment whose SHA3 hash is $\boldsymbol{\sigma}[r]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts due to an exhausted gas supply, then no gas is refunded to the caller and the state is reverted to the point immediately prior to code execution. \begin{eqnarray} \boldsymbol{\sigma}_P & \equiv & \begin{cases} \boldsymbol{\sigma}_1 & \text{if} \quad \boldsymbol{\sigma}_1[r]_c = \varnothing \\ @@ -611,9 +611,9 @@ \subsection{Fees Overview} Fees (denominated in gas) are charged under three distinct circumstances, all three as prerequisite to the execution of an operation. The first and most common is the fee intrinsic to the computation of the operation. Most operations require a single gas fee to be paid for their execution; exceptions include {\small SSTORE}, {\small SLOAD}, {\small CALL}, {\small CREATE}, {\small BALANCE} and {\small SHA3}. Secondly, gas may be deducted in order to form the payment for a subordinate message call or contract creation; this forms part of the payment for {\small CREATE} and {\small CALL}. Finally, gas may be paid due to an increase in the usage of the memory. -Over a contract's execution, the total fee for memory-usage payable is proportional to smallest multiple of 32 bytes that are required such that all memory indices (whether for read or write) are included in the range. This is paid for on a just-in-time basis; as such, referencing an area of memory at least 32 bytes greater than any previously indexed memory will certainly result in an additional memory usage fee. Due to this fee it is highly unlikely addresses will ever go above 32-bit bounds since at the present price of Ether and default gas price, that would cost around US\$20M for the memory fee alone. +Over a account's execution, the total fee for memory-usage payable is proportional to smallest multiple of 32 bytes that are required such that all memory indices (whether for read or write) are included in the range. This is paid for on a just-in-time basis; as such, referencing an area of memory at least 32 bytes greater than any previously indexed memory will certainly result in an additional memory usage fee. Due to this fee it is highly unlikely addresses will ever go above 32-bit bounds since at the present price of Ether and default gas price, that would cost around US\$20M for the memory fee alone. -Storage fees have a slightly nuanced behaviour---to incentivise contracts to minimise storage use (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 waived; in fact, it is effectively paid up-front since the initial usage of a storage location costs twice as much as the normal usage. +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 waived; in fact, it is effectively paid up-front since the initial usage of a storage location costs twice as much as the normal usage. More formally, given an instruction, it is possible to calculate the gas cost of executing it as follows: @@ -627,8 +627,8 @@ \subsection{Fees Overview} \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 contract body code. -\item {\small CREATE} costs $G_{create}$, though additional gas may be taken for the execution of contract initialisation code. +\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. @@ -903,7 +903,7 @@ \subsubsection{PoC Series} \subsubsection{Release Series} -For the release series, we use a more complex proof-of-work. This has yet to be formally defined, but involves two components; firstly that it concerns contract processing, and by extension the evaluation of programs on the EVM. Secondly that it concerns the utilisation of either the blockchain or the full state trie. +For the release series, we use a more complex proof-of-work. This has yet to be formally defined, but involves two components; firstly that it concerns the evaluation of programs on the EVM. Secondly that it concerns the utilisation of either the blockchain or the full state trie. As an overview, the output of the function is based upon the system state, defined as the hash of the root node of the state trie. A set of transactions, pseudo-randomly determined from the nonce value and selected from the last $N$ blocks is taken. $N$ is large enough and the selection criteria are such that execution of the transactions requires some non-negligible amount of processing by the EVM. Whenever code is executed on the EVM, it is pseudo-randomly (seeded again by the nonce) corrupted before alteration. Corruption could involve switching addresses with other transactions or rotating them through in the state trie (perhaps to the next address with the same order of magnitude of funds), rotating through instructions that have equivalent stack behaviour (e.g. swapping {\small ADD} for {\small SUB} or {\small GT} for {\small EQ}), or more destructive techniques such as randomly changing opcodes. This results in a problem that both require generalised computation hardware and is sequentially memory (and perhaps even disk) hard. @@ -972,21 +972,21 @@ \section{Terminology} \item[Address] A 160-bit code used for identifying Accounts. -\item[Account] Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state. They are owned either by External Actors or intrinsically (as an identity) an Autonomous Object within Ethereum. If an Account identifies an Autonomous Object, then Ethereum will also maintain a Storage State particular to that Account. Each Account has a single Address that identifies it. +\item[Account] Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state. They also have some (possibly empty) EVM Code and a (possibly empty) Storage State associated with them. Though homogenous, it makes sense to distinguish between two practical types of account: those with empty associated EVM Code (thus the account balance is controlled, if at all, by some external entity) and those with non-empty associated EVM Code (thus the account represents an Autonomous Object). Each Account has a single Address that identifies it. \item[Transaction] A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object. Transactions are recorded into each block of the blockchain. -\item[Autonomous Object] A virtual object existent only within the hypothetical state of Ethereum. Has an intrinsic address. Incorporated only as the state of the storage component of the VM. +\item[Autonomous Object] A notional object existent only within the hypothetical state of Ethereum. Has an intrinsic address and thus an associated account; the account will have non-empty associated EVM Code. Incorporated only as the Storage State of that account. -\item[Storage State] The information particular to a given Autonomous Object that is maintained between the times that it runs. +\item[Storage State] The information particular to a given Account that is maintained between the times that the Account's associated EVM Code runs. -\item[Message] Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts in a perfectly trusted way, either through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction. +\item[Message] Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts, either through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction. -\item[Message Call] The act of passing a message from one Account to another. If the destination account is an Autonomous Object, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation. +\item[Message Call] The act of passing a message from one Account to another. If the destination account is associated with non-empty EVM Code, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation. \item[Gas] The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low. -\item[Contract] Synonym for Autonomous Object used for non-technical audiences. +\item[Contract] Informal term used to mean both a piece of EVM Code that may be associated with an Account or an Autonomous Object. \item[Object] Synonym for Autonomous Object. @@ -994,13 +994,13 @@ \section{Terminology} \item[Ethereum Browser] (aka Ethereum Reference Client) A cross-platform GUI of an interface similar to a simplified browser (a la Chrome) that is able to host sandboxed applications whose backend is purely on the Ethereum protocol. -\item[Ethereum Virtual Machine] (aka EVM) The virtual machine that forms the key part of the execution model for a contract's program code. +\item[Ethereum Virtual Machine] (aka EVM) The virtual machine that forms the key part of the execution model for an Account's associated EVM Code. -\item[EVM Code] The bytecode that the EVM can natively execute. +\item[EVM Code] The bytecode that the EVM can natively execute. Used to formally specify the meaning and ramifications of a message to an Account. \item[EVM Assembly] The human-readable form of EVM-code. -\item[LLL] The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts. +\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-piling to. \end{description} @@ -1359,7 +1359,7 @@ \subsection{Instruction Set} \midrule 0x32 & {\small ORIGIN} & 0 & 1 & Get execution origination address. \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv I_o$ \\ -&&&& This is the sender of original transaction; it is never a contract. \\ +&&&& 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_c$ \\ @@ -1498,17 +1498,17 @@ \subsection{Instruction Set} \toprule \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 contract. \\ +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) \equiv \Lambda(\boldsymbol{\sigma}^*, I_a, I_o, \boldsymbol{\mu}_g, I_p, \boldsymbol{\mu}_\mathbf{s}[0], \mathbf{i}, \mathbf{b})$ \\ &&&& $\boldsymbol{\sigma}^* \equiv \boldsymbol{\sigma} \quad \text{except} \quad \boldsymbol{\sigma}^*[I_a]_n = \boldsymbol{\sigma}[I_a]_n + 1$ \\ &&&& $\boldsymbol{\mu}'_\mathbf{s}[0] \equiv x$ \\ &&&& where $x=0$ if the code execution for this operation failed due to lack of gas;\\ -&&&& $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly created contract, otherwise. \\ +&&&& $x=A(I_a, \boldsymbol{\sigma}[I_a]_n)$, the address of the newly created account, otherwise. \\ &&&& $\boldsymbol{\mu}'_i \equiv \max(\boldsymbol{\mu}_i, \ceil{ (\boldsymbol{\mu}_\mathbf{s}[1] + \boldsymbol{\mu}_\mathbf{s}[2]) \div 32 })$ \\ &&&& Thus the operand order is: gas, input offset, input size. \\ \midrule -0xf1 & {\small CALL} & 7 & 1 & Message-call into contract. \\ +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) ]$ \\ &&&& $\mathbf{o} \equiv \boldsymbol{\mu}_\mathbf{m}[ \boldsymbol{\mu}_\mathbf{s}[5] \dots (\boldsymbol{\mu}_\mathbf{s}[5] + \boldsymbol{\mu}_\mathbf{s}[6] - 1) ]$ \\ &&&& $(\boldsymbol{\sigma}', g', \mathbf{o}) \equiv \Theta(\boldsymbol{\sigma}, I_a, I_o, \boldsymbol{\mu}_\mathbf{s}[1], \boldsymbol{\mu}_\mathbf{s}[0], I_p, \boldsymbol{\mu}_\mathbf{s}[2], \mathbf{i})$ \\ @@ -1732,10 +1732,10 @@ \subsubsection{Transactions} \item \texttt{create(sec, xEndowment, bCode, xGas, xGasPrice, fn)} Creates a new contract-creation transaction, given parameters: \begin{itemize} \item \texttt{sec}, the secret-key for the sender; -\item \texttt{xEndowment}, the number equal to the contract's endowment; -\item \texttt{bCode}, the binary string (byte array) of EVM-bytecode for the initialisation of the contract; +\item \texttt{xEndowment}, the number equal to the account's endowment; +\item \texttt{bCode}, the binary string (byte array) of EVM-bytecode for the initialisation of the account; \item \texttt{xGas}, the number equal to the amount of gas to purchase for the transaction (unused gas is refunded); -\item \texttt{xGasPrice}, the number equal to the price of gas for this transaction. Returns the special address object representing the new contract's account; and +\item \texttt{xGasPrice}, the number equal to the price of gas for this transaction. Returns the special address object representing the new account; and \item \texttt{fn}, the callback function, called on completion of the transaction. \end{itemize} \item \texttt{transact(sec, xValue, aDest, bData, xGas, xGasPrice, fn)} Creates a new message-call transaction, given parameters: