diff --git a/BRANCHES.md b/BRANCHES.md
index 248f7ecc..eb1485dc 100644
--- a/BRANCHES.md
+++ b/BRANCHES.md
@@ -4,7 +4,8 @@ Each protocol version is specified in `Paper.tex` found in a branch of this repo
| Branch | Version | Applicable Block Numbers |
|-------------------|-------------------------------------------------------------------------------------------------------------------|-----------------------------------|
-| master | [Paris](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) | 15,537,394 until 17,034,869
+| master | [Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) | 17,034,870 until 19,426,586
+| paris | [Paris](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) | 15,537,394 until 17,034,869
| london | [Gray Glacier](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/gray-glacier.md)
[Arrow Glacier](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/arrow-glacier.md)
[London](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/mainnet-upgrades/london.md) | Since 15,050,000 until 15,537,393
Since 13,773,000 until 15,049,999
Since 12,965,000 until 13,772,999 |
| berlin | [Berlin](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) | Since 12,244,000 until 12,964,999 |
| istanbul | [Muir Glacier](https://eips.ethereum.org/EIPS/eip-2387)
[Istanbul](https://eips.ethereum.org/EIPS/eip-1679) | Since 9,200,000 until 12,243,999
Since 9,069,000 until 9,199,999 |
diff --git a/Paper.tex b/Paper.tex
index cb042ad2..a0a12216 100644
--- a/Paper.tex
+++ b/Paper.tex
@@ -64,7 +64,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{{Paris version}}]{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ \smaller \textbf{{Paris version \YellowPaperVersionNumber}}}
+\title[Ethereum: A Secure Decentralised Generalised Transaction Ledger\\ \smaller \textbf{{Shanghai version}}]{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ \smaller \textbf{{Shanghai version \YellowPaperVersionNumber}}}
\author{
Dr. Gavin Wood\\
Founder, Ethereum \& Parity\\
@@ -136,7 +136,7 @@ \section{The Blockchain Paradigm} \label{ch:overview}
\Pi(\boldsymbol{\sigma}, B) & \equiv & \hyperlink{Upsilon}{\Upsilon}(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...
\end{eqnarray}
-Where \hyperlink{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.
+Where \hyperlink{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 for transactions\footnote{Note that since the Shanghai fork, blocks also needs to process \textit{withdrawal operations} in order to reach their final state. Withdrawal operations are defined in sub-section \ref{subsec:The_Withdrawal}, and block final state is discussed in greater detail in section \ref{ch:finalisation}.}.
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.
@@ -150,6 +150,7 @@ \subsection{Value}
Multiplier & Name \\
\midrule
$10^0$ & Wei \\
+$10^9$ & Gwei \\
$10^{12}$ & Szabo \\
$10^{15}$ & Finney \\
$10^{18}$ & Ether \\
@@ -180,10 +181,10 @@ \subsection{Which History?}
\item after reaching a \textit{terminal total difficulty} in the case of the \textit{Paris} update, or
\item at a particular block timestamp in the case of post-\textit{Paris} updates.
\end{itemize}
-This document describes the \textit{Paris} version.
+This document describes the \textit{Shanghai} version.
In order to follow back the history of a path, one must reference multiple versions of this document.
-Here are the block numbers of protocol updates on the Ethereum main network:\footnote{Note that while the Paris fork activated at block 15,537,394, the trigger was not the block number, but rather reaching a specified \textit{total difficulty}. The trigger for the \textit{Paris} hard fork is discussed in greater detail in section \ref{ch:pos_transition}.}
+Here are the block numbers of protocol updates on the Ethereum main network:\footnote{Note that while the Paris, Shanghai, and every upcoming forks activated at a given block number (e.g. 15,537,394 for Paris), the trigger was not the block number, but rather reaching a specified \textit{timestamp} (or \textit{total difficulty} for Paris). The trigger for the \textit{Paris} and subsequent hard fork are discussed in greater detail in section \ref{ch:pos_transition}.}
\par
\begin{center}
\begin{tabular}{lr}
@@ -203,6 +204,7 @@ \subsection{Which History?}
$F_{\mathrm{Arrow Glacier}}$ & 13773000 \\
$F_{\mathrm{Gray Glacier}}$ & 15050000 \\
$F_{\mathrm{Paris}}$ & 15537394 \\
+$F_{\mathrm{Shanghai}}$ & 17034870 \\
\bottomrule
\end{tabular}
\end{center}
@@ -413,9 +415,37 @@ \subsection{The Transaction} \label{subsec:transaction}
\mathbb{B}_{0} & \text{otherwise}\end{cases}
\end{equation}
+\subsection{The Withdrawal}\linkdest{withdrawal}\label{subsec:The_Withdrawal}
+A withdrawal (formally, \textit{W}) is a tuple of data describing a consensus layer validator's withdrawal of some amount of its staked Ether.
+A withdrawal is created and validated in the consensus layer of the blockchain and then pushed to the execution layer.
+A withdrawal is composed of the following fields:
+
+\begin{description}
+\item[globalIndex] zero based incrementing withdrawal index that acts as a unique identifier for this withdrawal; formally $W_{\mathrm{g}}$.
+\item[validatorIndex] index of consensus layer's validator this withdrawal corresponds to; formally $W_{\mathrm{v}}$.
+\item[recipient] the 20-bytes address that will receives Ether form this withdrawal; formally $W_{\mathrm{r}}$.
+\item[amount] a nonzero amount of Ether denominated in Gwei ($10^9$ Wei); formally $W_{\mathrm{a}}$.
+\end{description}
+
+Withdrawal serialisation is defined as:
+\begin{equation}
+\linkdest{L_Withdrawal} L_{\mathrm{W}}(W) \equiv
+(W_{\mathrm{g}}, W_{\mathrm{v}}, W_{\mathrm{r}}, T_{\mathrm{a}})
+\end{equation}
+
+Here, we assume all components are interpreted by the RLP as integer values except for $W_\mathbf{r}$ which is a 20-bytes address:
+\begin{equation}
+\begin{array}[t]{lclc}
+W_{\mathrm{g}} \in \mathbb{N}_{64} & \wedge & W_{\mathrm{v}} \in \mathbb{N}_{64} & \wedge \\
+W_{\mathrm{r}} \in \mathbb{B}_{20} & \wedge & W_{\mathrm{a}} \in \mathbb{N}_{64}
+\end{array}
+\end{equation}
+
\subsection{The Block}\linkdest{block}\label{subsec:The_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 now deprecated property $\mathbf{U}$ that prior to the \textit{Paris} hard fork contained headers of blocks whose parents were equal to the present block's parent's parent (such blocks were 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_in_English\#Aunt/Uncle}}). 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}{} a now deprecated property $\mathbf{U}$ that prior to the \textit{Paris} hard fork contained headers of blocks whose parents were equal to the present block's parent's parent (such blocks were 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_in_English\#Aunt/Uncle}}),
+and, since the \textit{Shanghai} hard fork, $\mathbf{W}$, a collection of validator's withdrawal pushed by the consensus layer. The block header contains several pieces of information:
%\textit{TODO: Introduce logs}
@@ -423,7 +453,7 @@ \subsection{The Block}\linkdest{block}\label{subsec:The_Block}
\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] A 256-bit hash field that is now deprecated due to the replacement of proof of work consensus. It is now to a constant, $\texttt{KEC}(\texttt{RLP}(()))$; formally $H_{\mathrm{o}}$.
\item[beneficiary]\linkdest{beneficiary_H__c}{}\linkdest{H__c} The 160-bit address to which priority fees from this block are 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[stateRoot] The Keccak 256-bit hash of the root node of the state trie, after all transactions and withdrawals 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}}$.
\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}}$.
@@ -436,10 +466,11 @@ \subsection{The Block}\linkdest{block}\label{subsec:The_Block}
\item[prevRandao]\linkdest{prevRandao_H__a}{}\linkdest{H__a} the latest RANDAO mix\footnote{RANDAO is a pseudorandom value generated by validators on the Ethereum consensus layer. Refer to the consensus layer specs (\url{https://github.com/ethereum/consensus-specs}) for more detail on RANDAO.} of the post beacon state of the previous block; formally $H_{\mathrm{a}}$.
\item[nonce]\linkdest{block_nonce_H__n}{}\linkdest{block_nonce} A 64-bit value that is now deprecated due to the replacement of proof of work consensus. It is set to \texttt{0x0000000000000000}; formally \hyperlink{H__n}{$H_{\mathrm{n}}$}.
\item[baseFeePerGas]\linkdest{block_baseFeePerGas_H__f}{} A scalar value equal to the amount of wei that is burned for each unit of gas consumed; formally \hyperlink{H__f}{$H_{\mathrm{f}}$}.
+\item[withdrawalsRoot]\linkdest{withdrawals_root_H__w}{} The Keccak 256-bit hash of the root node of the trie structure populated with each withdrawal operations pushed by the consensus layer for this block; formally \hyperlink{H__w}{$H_{\mathrm{w}}$}.
\end{description}
-\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other two components in the block are a series of transactions, $B_{\mathbf{T}}$, and an empty array which was previously reserved for ommer block headers, $B_{\mathbf{U}}$. Formally, we can refer to a block $B$:
+\linkdest{ommer_block_headers_B__U}{}\linkdest{block_B}{}The other three components in the block are a series of transactions, $B_{\mathbf{T}}$, an empty array which was previously reserved for ommer block headers, $B_{\mathbf{U}}$, and a series of withdrawals, $B_{\mathbf{W}}$. Formally, we can refer to a block $B$:
\begin{equation}
-B \equiv (B_{\mathrm{H}}, B_{\mathbf{T}}, B_{\mathbf{U}})
+B \equiv (B_{\mathrm{H}}, B_{\mathbf{T}}, B_{\mathbf{U}}, B_{\mathbf{W}})
\end{equation}
\subsubsection{Transaction Receipt}\linkdest{Transaction_Receipt}{}
@@ -499,17 +530,27 @@ \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: the block's ommers field $B_{\mathbf{U}}$ must be an empty array and the block's header must be consistent with the given transactions $B_{\mathbf{T}}$. For the header to be consistent with the transactions $B_{\mathbf{T}}$, \textbf{stateRoot} ($H_{\mathrm{r}}$) must match the resultant state after executing all transactions in order on the base state $\boldsymbol{\sigma}$ (as specified in section \ref{ch:finalisation}), and \textbf{transactionsRoot} ($H_{\mathrm{t}}$), \textbf{receiptsRoot} ($H_{\mathrm{e}}$), and \textbf{logsBloom} ($H_{\mathrm{b}}$) must be correctly derived from the transactions themselves, the transaction receipts resulting from execution, and the resulting logs, respectively.
+\linkdest{block_validity}{}We can assert a block's validity if and only if it satisfies several conditions:
+the block's ommers field $B_{\mathbf{U}}$ must be an empty array and the block's header must be consistent with the given transactions $B_{\mathbf{T}}$ and withdrawals $B_{\mathbf{W}}$.
+For the header to be consistent with the transactions $B_{\mathbf{T}}$ and withdrawals $B_{\mathbf{W}}$, \textbf{stateRoot} ($H_{\mathrm{r}}$) must match the resultant state after executing all transactions, then all withdrawals, in order on the base state $\boldsymbol{\sigma}$ (as specified in section \ref{ch:finalisation}),
+and \textbf{transactionsRoot} ($H_{\mathrm{t}}$), \textbf{receiptsRoot} ($H_{\mathrm{e}}$), \textbf{logsBloom} ($H_{\mathrm{b}}$) and \textbf{withdrawalsRoot} ($H_{\mathrm{w}}$) must be correctly derived from the transactions themselves, the transaction receipts resulting from execution, the resulting logs, and the withdrawals, respectively.
\begin{equation}
\begin{array}[t]{lclc}
B_{\mathbf{U}} &\equiv& () & \wedge \\
\linkdest{new_state_H__r}{}H_{\mathrm{r}} &\equiv& \mathtt{TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\
\linkdest{tx_block_hash_H__t}{}H_{\mathrm{t}} &\equiv& \mathtt{TRIE}(\{\forall i < \lVert B_{\mathbf{T}} \rVert, i \in \mathbb{N}: &\\&& \quad\quad p_{\mathrm{T}}(i, B_{\mathbf{T}}[i])\}) & \wedge \\
\linkdest{Receipts_Root_H__e}{}H_{\mathrm{e}} &\equiv& \mathtt{TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{N}: &\\&& \quad\quad p_{\mathrm{R}}(i, B_{\mathbf{R}}[i])\}) & \wedge \\
+\linkdest{Withdrawals_Root_H__w}{}H_{\mathrm{w}} &\equiv& \mathtt{TRIE}(\{\forall i < \lVert B_{\mathbf{W}} \rVert, i \in \mathbb{N}: &\\&& \quad\quad p_{\mathrm{W}}(i, B_{\mathbf{W}}[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_{\mathrm{T}}(k, v)$ and $p_{\mathrm{R}}(k, v)$ are pairwise RLP transformations, but with a special treatment for EIP-2718 transactions:
+
+where $p_{\mathrm{W}}(k, v)$ is a pairwise RLP transformation for withdrawals:
+\begin{equation}
+p_{\mathrm{W}}(k, W) \equiv \left( \mathtt{RLP}(k), \mathtt{RLP}(\hyperlink{L_Withdrawal}{L_{\mathrm{W}}}(W)) \right)
+\end{equation}
+
+similarly, $p_{\mathrm{T}}(k, v)$ and $p_{\mathrm{R}}(k, v)$ are pairwise RLP transformations, but with a special treatment for EIP-2718 transactions:
\begin{equation}
p_{\mathrm{T}}(k, T) \equiv \left( \mathtt{RLP}(k), \begin{cases}
\mathtt{RLP}(\hyperlink{L_transaction}{L_{\mathrm{T}}}(T)) & \text{if} \quad T_{\mathrm{x}} = 0 \\
@@ -541,8 +582,8 @@ \subsubsection{Serialisation}
\hypertarget{block_preparation_function_for_RLP_serialization_L__B}{}\linkdest{L__B}\hypertarget{block_preparation_function_for_RLP_serialization_L__H}{}\linkdest{L__B}The function $L_{\mathrm{B}}$ and $L_{\mathrm{H}}$ are the preparation functions for a block and block header respectively.
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{a}}, H_{\mathrm{n}}, H_{\mathrm{f}} \; )\end{array} \\
-\quad L_{\mathrm{B}}(B) & \equiv & \big( L_{\mathrm{H}}(B_{\mathrm{H}}), \widetilde{L}_{\mathrm{T}}^*(B_{\mathbf{T}}), L_{\mathrm{H}}^*(\hyperlink{ommer_block_headers_B__U}{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{a}}, H_{\mathrm{n}}, H_{\mathrm{f}}, H_{\mathrm{w}} \; )\end{array} \\
+\quad L_{\mathrm{B}}(B) & \equiv & \big( L_{\mathrm{H}}(B_{\mathrm{H}}), \widetilde{L}_{\mathrm{T}}^*(B_{\mathbf{T}}), L_{\mathrm{H}}^*(\hyperlink{ommer_block_headers_B__U}{B_{\mathbf{U}}}), L_{\mathrm{W}}^*(B_{\mathbf{W}}) \big)
\end{eqnarray}
where $\widetilde{L}_{\mathrm{T}}$ takes a special care of EIP-2718 transactions:
\begin{equation}
@@ -551,7 +592,7 @@ \subsubsection{Serialisation}
(T_{\mathrm{x}}) \cdot \mathtt{RLP}(L_{\mathrm{T}}(T)) & \text{otherwise}
\end{cases}
\end{equation}
-\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}with $\widetilde{L}_{\mathrm{T}}^*$ and $L_{\mathrm{H}}^*$ being element-wise sequence transformations, thus:
+\hypertarget{general_element_wise_sequence_transformation_f_pow_asterisk}{}with $\widetilde{L}_{\mathrm{T}}^*$, $L_{\mathrm{H}}^*$, and $L_{\mathrm{W}}^*$, 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}
@@ -564,7 +605,7 @@ \subsubsection{Serialisation}
\hyperlink{logs_Bloom_filter_H__b}{H_{\mathrm{b}}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{N} & \wedge & \hyperlink{block_number_H__i}{H_{\mathrm{i}}} \in \mathbb{N} & \wedge \\
\hyperlink{block_gas_limit_H__l}{H_{\mathrm{l}}} \in \mathbb{N} & \wedge & H_{\mathrm{g}} \in \mathbb{N} & \wedge & \hyperlink{block_timestamp_H__s}{H_{\mathrm{s}}} \in \mathbb{N}_{256} & \wedge \\
\hyperlink{block_extraData_H__x}{H_{\mathrm{x}}} \in \mathbb{B} & \wedge & H_{\mathrm{a}} \in \mathbb{B}_{32} & \wedge & \hyperlink{block_nonce_H__n}{H_{\mathrm{n}}} \in \mathbb{B}_{8} & \wedge \\
-\hyperlink{block_baseFeePerGas_H__f}{H_{\mathrm{f}}} \in \mathbb{N}
+\hyperlink{block_baseFeePerGas_H__f}{H_{\mathrm{f}}} \in \mathbb{N} & \wedge & \hyperlink{withdrawals_root_H__w}{H_{\mathrm{w}}} \in \mathbb{B}_{32}
\end{array}
\end{equation}
@@ -743,7 +784,7 @@ \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} \hyperlink{G__txdatazero}{G_{\mathrm{txdatazero}}} & \text{if} \quad i = 0 \\ \hyperlink{G__txdatanonzero}{G_{\mathrm{txdatanonzero}}} & \text{otherwise} \end{cases} \\
-\nonumber {} & + \begin{cases} \hyperlink{G__txcreate}{G_{\mathrm{txcreate}}} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\
+\nonumber {} & + \begin{cases} \hyperlink{G__txcreate}{G_{\mathrm{txcreate}}} + \hyperlink{initcode_cost}{R({\lVert T_{\mathbf{i}} \rVert})} & \text{if} \quad T_{\mathrm{t}} = \varnothing \\ 0 & \text{otherwise} \end{cases} \\
\nonumber {} & + \hyperlink{G__transaction}{G_{\mathrm{transaction}}} \\
\nonumber {} & + \sum_{j = 0}^{\lVert T_{\mathbf{A}} \rVert - 1} \big( G_{\mathrm{accesslistaddress}} + \lVert T_{\mathbf{A}}[j]_{\mathbf{s}} \rVert G_{\mathrm{accessliststorage}} \big)
\end{align}
@@ -752,6 +793,12 @@ \subsection{Execution}
$\hyperlink{G__accesslistaddress}{G_{\mathrm{accesslistaddress}}}$ and $\hyperlink{G__accessliststorage}{G_{\mathrm{accessliststorage}}}$ are the costs of warming up account and storage access, respectively.
$G$ is fully defined in Appendix \ref{app:fees}.
+\hypertarget{initcode_cost}{}We define the \textit{initcode cost function}, formally $R$, as the amount of gas that needs to be paid for each word of the initcode prior to executing the creation code of a new contract:
+
+\begin{equation}
+ R(x) \equiv \hyperlink{G__initcodeword}{G_{\mathrm{initcodeword}}} \times \lceil \frac{x}{32} \rceil
+\end{equation}
+
\hypertarget{effective_gas_price_p}{}We define the \textit{effective gas price}, formally $p$, as the amount of wei the transaction signer will pay per unit of gas consumed during the transaction's execution. It is calculated as follows:
\begin{equation}
@@ -787,6 +834,7 @@ \subsection{Execution}
g_0 & \leqslant & T_{\mathrm{g}} \quad \wedge \\
v_0 & \leqslant & \boldsymbol{\sigma}[S(T)]_{\mathrm{b}} \quad \wedge \\
m & \geqslant & H_{\mathrm{f}} \quad \wedge \\
+n & \leqslant & 49152 \quad \wedge \\
T_{\mathrm{g}} & \leqslant & {B_{\mathrm{H}}}_{\mathrm{l}} - \hyperlink{ell}{\ell}(B_{\mathbf{R}})_{\mathrm{u}}
\end{array}
\end{equation}
@@ -797,7 +845,15 @@ \subsection{Execution}
T_{\mathrm{m}} & \text{if} \; T_{\mathrm{x}} = 2 \\
\end{cases}
\end{equation}
+and
+\begin{equation}
+ n \equiv \begin{cases}
+ \lVert T_{\mathrm{i}} \rVert & \text{if} \; T_{\mathrm{t}} \neq \varnothing \\
+ 0 & \text{otherwise}
+ \end{cases}
+\end{equation}
+The penultimate condition ensures that, for create transactions, the length of the initcode is no greater than 49152 bytes.
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_{\mathrm{H}}}_{\mathrm{l}}$.
Also, with a slight abuse of notation, we assume that $\boldsymbol{\sigma}[S(T)]_{\mathrm{c}} = \texttt{KEC}\big( () \big)$, $\boldsymbol{\sigma}[S(T)]_{\mathrm{n}} = 0$, and $\boldsymbol{\sigma}[S(T)]_{\mathrm{b}} = 0$ if $\boldsymbol{\sigma}[S(T)] = \varnothing$.
@@ -830,7 +886,7 @@ \subsection{Execution}
a \cup T_{\mathrm{t}} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\
a & \text{otherwise}
\end{cases} \\
-a & \equiv A^0_{\mathbf{a}} \cup \{S(T)\} \cup_{E \in T_{\mathbf{A}}} \{ \hyperlink{access_list_entry}{E}_{\mathrm{a}} \}
+a & \equiv A^0_{\mathbf{a}} \cup S(T) \cup H_c \cup_{E \in T_{\mathbf{A}}} \{ \hyperlink{access_list_entry}{E}_{\mathrm{a}} \}
\end{align}
and $g$ is the amount of gas remaining after deducting the basic amount required to pay for the existence of the transaction:
\begin{equation}
@@ -1327,6 +1383,12 @@ \section{Transition to Proof of Stake} \label{ch:pos_transition}
Upon reaching the terminal block, new blocks are processed by the Beacon Chain.
+\subsection{Post-Paris Updates}
+Because the Beacon Chain generate a new slot every 12 seconds, post-\textit{Paris} updates can be scheduled to occur at a specific timestamp.
+At the execution layer, the update will then happen in the first produced block after the scheduled timestamp.
+For example the \textit{Shanghai} hard fork was scheduled to occur at 2023-04-12 10:27:35 UTC, on Epoch 194,048.
+Validators failed to propose a block during the two first slots of this Epoch, but at slot 6,209,538 a validator finally proposed the block 17,034,870, marking the transition to \textit{Shanghai} on the execution layer.
+
\section{Blocktree to Blockchain} \label{ch:blocktree_to_blockchain}
Prior to the transition to proof of stake at the \textit{Paris} hard fork, the canonical blockchain was defined as the block path with the greatest \textit{total difficulty}, defined in section \ref{ch:pos_transition} as $B_{\mathrm{t}}$.
@@ -1347,13 +1409,30 @@ \section{Blocktree to Blockchain} \label{ch:blocktree_to_blockchain}
\section{Block Finalisation} \label{ch:finalisation}
-The process of finalising a block involves two stages:
+The process of finalising a block involves three stages:
\begin{enumerate}
+\item executing withdrawals;
\item validate transactions;
\item verify state.
\end{enumerate}
+\subsection{Executing Withdrawals}
+After processing the block's transactions, the withdrawals are executed. A withdrawal is simply an increase of the recipient account's balance of the specified Gwei amount. No other balances are decreased, a withdrawal is not a transfer but a creation of funds.
+A withdrawal operation cannot fail and has no gas cost. We define the function $E$ as the withdrawal state transition function:
+
+\begin{eqnarray}
+E(\boldsymbol{\sigma}_w, W) & \equiv & \boldsymbol{\sigma}_{w+1} \\
+\boldsymbol{\sigma}_{w+1} & \equiv & \boldsymbol{\sigma}_w \quad \text{except:} \\
+\boldsymbol{\sigma}_{w+1}[W_r]_{\mathrm{b}} & \equiv & \boldsymbol{\sigma}_{w}[W_r]_{\mathrm{b}} + (W_a \times 10^9)
+\end{eqnarray}
+
+\hypertarget{Kappa}{}Finally, we define $K$, the block-level state transition function for withdrawals:
+
+\begin{equation}
+K(\boldsymbol{\sigma}, B) \equiv E(E(\boldsymbol{\sigma}, W_0), W_1) ...
+\end{equation}
+
\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.
@@ -1378,7 +1457,7 @@ \subsection{State 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{H}}}_{\mathrm{r}} & = & \mathtt{TRIE}(L_{\mathrm{S}}(\hyperlink{Pi}{\Pi}(\Gamma(B), B)))
+{B'_{\mathrm{H}}}_{\mathrm{r}} & = & \mathtt{TRIE}(L_{\mathrm{S}}(\hyperlink{Kappa}{K}(\hyperlink{Pi}{\Pi}(\Gamma(B), B), B)))
\end{eqnarray}
As specified at the beginning of the present work, \hyperlink{Pi}{$\Pi$} is the state-transition function, which is defined in terms of \hyperlink{Upsilon_state_transition}{$\Upsilon$}, the transaction-evaluation function.
@@ -2030,6 +2109,8 @@ \section{Fee Schedule}\label{app:fees}
\linkdest{G__selfdestruct}{}$G_{\mathrm{selfdestruct}}$ & 5000 & Amount of gas to pay for a {\small SELFDESTRUCT} operation. \\
$G_{\mathrm{create}}$ & 32000 & Paid for a {\small CREATE} operation. \\
\linkdest{G__codedeposit}{}$G_{\mathrm{codedeposit}}$ & 200 & Paid per byte for a {\small CREATE} operation to succeed in placing code into state. \\
+\linkdest{G__initcodeword}{}$G_{\mathrm{initcodeword}}$ & 2 & Paid per word of the initcode at the beginning of a deploy transaction, a {\small CREATE},\\
+&&or a {\small CREATE2} operation. \\
$G_{\mathrm{callvalue}}$ & 9000 & Paid for a non-zero value transfer as part of the {\small CALL} operation. \\
\linkdest{G__callstipend}{}$G_{\mathrm{callstipend}}$ & 2300 & A stipend for the called contract subtracted from $G_{\mathrm{callvalue}}$ for a non-zero value transfer. \\
\linkdest{G__newaccount}{}$G_{\mathrm{newaccount}}$ & 25000 & Paid for a {\small CALL} or {\small SELFDESTRUCT} operation which creates an account. \\
@@ -2079,8 +2160,8 @@ \subsection{Gas Cost}
G_{\mathrm{log}}+G_{\mathrm{logdata}}\times\boldsymbol{\mu}_{\mathbf{s}}[1]+4G_{\mathrm{logtopic}} & \text{if} \quad w = \text{\small LOG4} \\
C_\text{\tiny CALL}(\boldsymbol{\sigma}, \boldsymbol{\mu}, A) & \text{if} \quad w \in W_{\mathrm{call}} \\
C_\text{\tiny SELFDESTRUCT}(\boldsymbol{\sigma}, \boldsymbol{\mu}) & \text{if} \quad w = \text{\small SELFDESTRUCT} \\
-G_{\mathrm{create}} & \text{if} \quad w = \text{\small CREATE}\\
-G_{\mathrm{create}}+G_{\mathrm{keccak256word}} \times \lceil \boldsymbol{\mu}_{\mathbf{s}}[2] \div 32 \rceil & \text{if} \quad w = \text{\small \hyperlink{create2}{CREATE2}}\\
+G_{\mathrm{create}} + \hyperlink{initcode_cost}{R(\boldsymbol{\mu}_{\mathbf{s}}[2])} & \text{if} \quad w = \text{\small CREATE}\\
+G_{\mathrm{create}}+G_{\mathrm{keccak256word}} \times \lceil \boldsymbol{\mu}_{\mathbf{s}}[2] \div 32 \rceil + \hyperlink{initcode_cost}{R(\boldsymbol{\mu}_{\mathbf{s}}[2])} & \text{if} \quad w = \text{\small \hyperlink{create2}{CREATE2}}\\
G_{\mathrm{keccak256}}+G_{\mathrm{keccak256word}} \times \lceil \boldsymbol{\mu}_{\mathbf{s}}[1] \div 32 \rceil & \text{if} \quad w = \text{\small KECCAK256}\\
G_{\mathrm{jumpdest}} & \text{if} \quad w = \text{\small JUMPDEST}\\
C_\text{\tiny SLOAD}(\boldsymbol{\mu}, A, I) & \text{if} \quad w = \text{\small SLOAD}\\
@@ -2115,9 +2196,9 @@ \subsection{Gas Cost}
$W_{\mathrm{zero}}$ = \{{\small STOP}, {\small RETURN}, {\small REVERT}\}
-$W_{\mathrm{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 PREVRANDAO}, {\small GASLIMIT}, {\small CHAINID}, {\small RETURNDATASIZE}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}, \newline \noindent\hspace*{1cm} {\small BASEFEE}\}
+$W_{\mathrm{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 PREVRANDAO}, {\small GASLIMIT}, {\small CHAINID}, {\small RETURNDATASIZE}, {\small POP}, {\small PC}, {\small MSIZE}, {\small GAS}, \newline \noindent\hspace*{1cm} {\small BASEFEE}, {\small PUSH0}\}
-$W_{\mathrm{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 SHL}, {\small SHR}, {\small SAR}, \newline \noindent\hspace*{1cm} {\small CALLDATALOAD}, {\small MLOAD}, {\small MSTORE}, {\small MSTORE8}, {\small PUSH*}, {\small DUP*}, {\small SWAP*}\}
+$W_{\mathrm{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 SHL}, {\small SHR}, {\small SAR}, \newline \noindent\hspace*{1cm} {\small CALLDATALOAD}, {\small MLOAD}, {\small MSTORE}, {\small MSTORE8}, {\small PUSH1}, ..., {\small PUSH32}, {\small DUP*}, {\small SWAP*}\}
$W_{\mathrm{low}}$ = \{{\small MUL}, {\small DIV}, {\small SDIV}, {\small MOD}, {\small SMOD}, {\small SIGNEXTEND}, {\small SELFBALANCE}\}
@@ -2514,8 +2595,11 @@ \subsection{Instruction Set}
\begin{tabu}{\usetabu{opcodes}}
\toprule
-\multicolumn{5}{c}{\textbf{60s \& 70s: Push Operations}} \vspace{5pt} \\
+\multicolumn{5}{c}{\textbf{5f, 60s \& 70s: Push Operations}} \vspace{5pt} \\
\textbf{Value} & \textbf{Mnemonic} & $\delta$ & $\alpha$ & \textbf{Description} \vspace{5pt} \\
+0x5f & {\small PUSH0} & 0 & 1 & Place 0 on the stack. \\
+&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv 0$ \\
+\midrule
0x60 & {\small PUSH1} & 0 & 1 & Place 1 byte item on stack. \\
&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv c(\boldsymbol{\mu}_{\mathrm{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}$ \\
@@ -2604,15 +2688,16 @@ \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) ]$ \\
&&&& $\hyperlink{salt}{\zeta} \equiv \varnothing$ \\
&&&& $(\boldsymbol{\sigma}', g', A', z, \mathbf{o}) \equiv \begin{cases}
-\hyperlink{lambda}{\Lambda}(\boldsymbol{\sigma}^*, A, 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, \zeta, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \; \\ \quad &\wedge\; I_{\mathrm{e}} < 1024\\
+\hyperlink{lambda}{\Lambda}(\boldsymbol{\sigma}^*, A, 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, \zeta, I_{\mathrm{w}}) & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] \leqslant \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{b}} \; \wedge \\ \quad &\; I_{\mathrm{e}} < 1024 \wedge \lVert \mathbf{i} \rVert \leqslant 49152\\
\big(\boldsymbol{\sigma}, L(\boldsymbol{\mu}_{\mathrm{g}}), A, 0, () \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$ \\
&&&& $\boldsymbol{\mu}'_{\mathrm{g}} \equiv \boldsymbol{\mu}_{\mathrm{g}} - \hyperlink{L_but_64}{L}(\boldsymbol{\mu}_{\mathrm{g}}) + g'$ \\
&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv x$ \\
-&&&& where $x=0$ if $z = 0$, i.e., the \hyperlink{contract_creation_result}{contract creation process failed}, 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=\mathtt{ADDR}(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}}, \zeta, \mathbf{i} )$, the\\
-&&&& address of the newly created account (\ref{eq:new-address}). \\
+&&&& where $x=0$ if $z = 0$, i.e., the \hyperlink{contract_creation_result}{contract creation process failed},\\
+&&&& or $\lVert \mathbf{i} \rVert > 49152$ (initcode is longer than 49152 bytes),\\
+&&&& 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=\mathtt{ADDR}(I_{\mathrm{a}}, \boldsymbol{\sigma}[I_{\mathrm{a}}]_{\mathrm{n}}, \zeta, \mathbf{i} )$, the address of the newly created account (\ref{eq:new-address}). \\
&&&& $\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 \begin{cases}
() & \text{if} \quad z = 1 \\
@@ -2708,7 +2793,9 @@ \subsection{Instruction Set}
\midrule
0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\
\midrule
-\linkdest{selfdestruct}{}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. Readers should be warned, \\
+&&&& since the \textit{Shanghai} update, this opcode has been marked as deprecated. \\
+&&&& Its behavior might be subject to breaking change in an upcoming update. \\
&&&& $A'_{\mathbf{s}} \equiv A_{\mathbf{s}} \cup \{ I_{\mathrm{a}} \}$ \\
&&&& $A'_{\mathbf{a}} \equiv A_{\mathbf{a}} \cup \{ r \}$ \\
&&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases}
diff --git a/README.md b/README.md
index 91f1dc50..ecfec5b2 100644
--- a/README.md
+++ b/README.md
@@ -4,15 +4,15 @@
[](https://gitter.im/ethereum/yellowpaper?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
[](https://www.gitpoap.io/gh/ethereum/yellowpaper)
-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.
+The Yellow Paper is a formal definition of the Ethereum protocol, originally by Gavin Wood, currently maintained by Andrew Ashikhmin and with contributions from many people around the world.
It is a free culture work, licensed under Creative Commons Attribution Share-Alike (CC-BY-SA) Version 4.0.
## Repository Currently Outdated
-The Yellow Paper is out of date. It reflects the Ethereum specification up to the [Paris](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) network upgrade ("the merge"), activated on the Ethereum mainnet at block `15_537_394` (September 2022).
+The Yellow Paper is out of date. It reflects the Ethereum specification up to the [Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) network upgrade, activated on the Ethereum mainnet at block `17_034_870` (April 2023).
-It does **not** contain changes introduced in any post-merge upgrade.
+It does **not** yet contain changes introduced by the Cancun upgrade.
An alternative [Python Execution Layer specification](https://ethereum.github.io/execution-specs/) is actively maintained and up to date.