diff --git a/BRANCHES.md b/BRANCHES.md
index eb1485dc..90beb72e 100644
--- a/BRANCHES.md
+++ b/BRANCHES.md
@@ -4,10 +4,11 @@ Each protocol version is specified in `Paper.tex` found in a branch of this repo
| Branch | Version | Applicable Block Numbers |
|-------------------|-------------------------------------------------------------------------------------------------------------------|-----------------------------------|
-| 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 |
+| master | [Cancun](https://eips.ethereum.org/EIPS/eip-7569) | 19,426,587 until 22,431,084
+| shanghai | [Shanghai](https://github.com/ethereum/execution-specs/blob/mainnet/src/ethereum/forks/shanghai/__init__.py) | 17,034,870 until 19,426,586
+| paris | [Paris](https://github.com/ethereum/execution-specs/blob/mainnet/src/ethereum/forks/paris/__init__.py) | 15,537,394 until 17,034,869
+| london | [Gray Glacier](https://eips.ethereum.org/EIPS/eip-5133)
[Arrow Glacier](https://eips.ethereum.org/EIPS/eip-4345)
[London](https://github.com/ethereum/execution-specs/blob/mainnet/src/ethereum/forks/london/__init__.py) | 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/execution-specs/blob/mainnet/src/ethereum/forks/berlin/__init__.py) | 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 |
| petersburg | [Constantinople](https://eips.ethereum.org/EIPS/eip-1013) + [Petersburg](https://eips.ethereum.org/EIPS/eip-1716) | Since 7,280,000 until 9,068,999 |
| byzantium | [Byzantium](https://eips.ethereum.org/EIPS/eip-609) | Since 4,370,000 until 7,279,999 |
diff --git a/Biblio.bib b/Biblio.bib
index 63cf80d9..6882f3a0 100644
--- a/Biblio.bib
+++ b/Biblio.bib
@@ -234,6 +234,14 @@ @Misc{EIP-4345
month = "October",
}
+@Misc{EIP-4844,
+ url = "https://eips.ethereum.org/EIPS/eip-4844",
+ title = "{EIP}-4844: Shard Blob Transactions",
+ author = "Buterin, Feist and Loerakker, Kadianakis and Garnett, Taiwo and Dietrichs",
+ year = "2022",
+ month = "February",
+}
+
@misc{EIP-5133,
url = {https://eips.ethereum.org/EIPS/eip-5133},
title = {{EIP}-5133: Delaying Difficulty Bomb to mid-{September} 2022},
diff --git a/Paper.tex b/Paper.tex
index 32a30624..251c6b78 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{{Shanghai version}}]{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ \smaller \textbf{{Shanghai version \YellowPaperVersionNumber}}}
+\title[Ethereum: A Secure Decentralised Generalised Transaction Ledger\\ \smaller \textbf{{Cancun version}}]{Ethereum: A Secure Decentralised Generalised Transaction Ledger \\ \smaller \textbf{{Cancun version \YellowPaperVersionNumber}}}
\author{
Dr. Gavin Wood\\
Founder, Ethereum \& Parity\\
@@ -133,8 +133,9 @@ \section{The Blockchain Paradigm} \label{ch:overview}
\begin{eqnarray}
\boldsymbol{\sigma}_{t+1} & \equiv & \hyperlink{Pi}{\Pi}(\boldsymbol{\sigma}_{t}, B) \\
B & \equiv & (..., (T_0, T_1, ...), ...) \\
-\Pi(\boldsymbol{\sigma}, B) & \equiv & \hyperlink{Upsilon}{\Upsilon}(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...
+\Pi(\boldsymbol{\sigma}, B) & \equiv & \hyperlink{Upsilon}{\Upsilon}(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...\footnotemark
\end{eqnarray}
+\footnotetext{Note that since the Cancun fork, blocks also need to process \textit{system-level transactions} before processing regular transactions. System-level transactions are defined in sub-section \ref{subsec:System_Level_Transactions}.}
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}.}.
@@ -181,7 +182,7 @@ \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{Shanghai} version.
+This document describes the \textit{Cancun} 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, 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}.}
@@ -205,6 +206,7 @@ \subsection{Which History?}
$F_{\mathrm{Gray Glacier}}$ & 15050000 \\
$F_{\mathrm{Paris}}$ & 15537394 \\
$F_{\mathrm{Shanghai}}$ & 17034870 \\
+$F_{\mathrm{Cancun}}$ & 19426587 \\
\bottomrule
\end{tabular}
\end{center}
@@ -323,7 +325,7 @@ \subsection{The Transaction} \label{subsec:transaction}
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.}.
EIP-2718 by \cite{EIP-2718} introduced the notion of different transaction types.
-As of the \textit{London} version of the protocol, there are three transaction types: 0 (legacy), 1 (EIP-2930 by \cite{EIP-2930}), and 2 (EIP-1559 by \cite{EIP-1559}).
+As of the \textit{Cancun} version of the protocol, there are four transaction types: 0 (legacy), 1 (EIP-2930 by \cite{EIP-2930}), 2 (EIP-1559 by \cite{EIP-1559}), and 3 (EIP-4844 by \cite{EIP-4844}).
Further, there are two subtypes 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').
All transaction types specify a number of common fields:
@@ -350,17 +352,22 @@ \subsection{The Transaction} \label{subsec:transaction}
$T_{\mathrm{w}} = 27 + T_{\mathrm{y}}$ or $T_{\mathrm{w}} = 2\beta + 35 + T_{\mathrm{y}}$ (see EIP-155 by \cite{EIP-155}).
\end{description}
-There are differences in how one's acceptable gas price is specified in type 2 transactions versus type 0 and type 1 transactions. Type 2 transactions take better advantage of the gas market improvements introduced in EIP-1559 by explicitly limiting the \textit{priority fee}\footnote{The \textit{priority fee} is discussed in greater detail in sections \ref{ch:payment} and \ref{ch:transactions}.} that is paid. Type 2 transactions have the following two fields related to gas:
+There are differences in how one's acceptable gas price is specified in type 0 and type 1 transactions versus other types.
+Type 0 and type 1 transactions specify gas price as a single value:
+\begin{description}
+ \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}}$.\footnote{Type 0 and type 1 transactions will get the same gas price behavior as a type 2 transaction with $T_{\mathrm{m}}$ and $T_{\mathrm{f}}$ set to the value of $T_{\mathrm{p}}$.}
+\end{description}
+In contrast, type 2 and above transactions take better advantage of the gas market improvements introduced in EIP-1559 by explicitly limiting the \textit{priority fee}\footnote{The \textit{priority fee} is discussed in greater detail in sections \ref{ch:payment} and \ref{ch:transactions}.} that is paid. Type 2 and above transactions have the following two fields related to gas:
\begin{description}
\item[maxFeePerGas]\linkdest{max_fee_per_gas}{} A scalar value equal to the maximum 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{m}}$.
\item[maxPriorityFeePerGas]\linkdest{max_priority_fee_per_gas}{} A scalar value equal to the maximum number of Wei to be paid to the block's fee recipient as an incentive to include the transaction; formally $T_{\mathrm{f}}$.
\end{description}
-In contrast, type 0 and type 1 transactions specify gas price as a single value:
-
+Type 3 transactions introduce the following two fields related to blob-carrying transactions:
\begin{description}
- \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}}$.\footnote{Type 0 and type 1 transactions will get the same gas price behavior as a type 2 transaction with $T_{\mathrm{m}}$ and $T_{\mathrm{f}}$ set to the value of $T_{\mathrm{p}}$.}
+ \item[maxFeePerBlobGas]\linkdest{max_fee_per_blob_gas}{} A scalar value equal to the maximum number of Wei to be paid per unit of \textit{blob gas} for all blob data costs incurred as a result of the execution of this transaction; formally $T_{\mathrm{b}}$.
+ \item[blobVersionedHashes]\linkdest{blob_versioned_hashes}{} A list of versioned hashes of the blobs that are being committed with this transaction; formally $T_{\mathbf{B}}$. Each element of that list is a 32-byte versioned hash matching blobs committed in the corresponding consensus beacon block. The first (leftmost) byte of each hash should be equal to the current version byte $V_{blob}$.
\end{description}
Additionally, a contract creation transaction (regardless of transaction type) contains:
@@ -377,6 +384,12 @@ \subsection{The Transaction} \label{subsec:transaction}
\item[data] An unlimited size byte array specifying the input data of the message call, formally $T_{\mathbf{d}}$.
\end{description}
+As of the Cancun version of the protocol, the blob version is defined as:
+\begin{eqnarray}
+ V_{blob} & \in & \mathbb{B}_{1} \\
+ V_{blob} & \equiv & 1
+\end{eqnarray}
+
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}
@@ -384,6 +397,8 @@ \subsection{The Transaction} \label{subsec:transaction}
(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{x}} = 0 \\
(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, T_{\mathbf{A}}, T_{\mathrm{y}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{x}} = 1 \\
(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{f}}, T_{\mathrm{m}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, T_{\mathbf{A}}, T_{\mathrm{y}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{x}} = 2 \\
+(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{f}}, T_{\mathrm{m}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathrm{d}}, T_{\mathbf{A}}, T_{\mathbf{b}}, T_{\mathbf{B}}, \\
+T_{\mathrm{y}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{x}} = 3 \\
\end{cases}
\end{equation}
where
@@ -394,14 +409,14 @@ \subsection{The Transaction} \label{subsec:transaction}
\end{cases}
\end{equation}
-Here, we assume all components are interpreted by the RLP as integer values, with the exception of the access list $T_{\mathbf{A}}$ and 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 access list $T_{\mathbf{A}}$, the blob versioned hashes $T_{\mathbf{B}}$ and the arbitrary length byte arrays $T_{\mathbf{i}}$ and $T_{\mathbf{d}}$.
\begin{equation}
\begin{array}[t]{lclclc}
-T_{\mathrm{x}} \in \{0, 1, 2\} & \wedge & T_{\mathrm{c}} = \beta & \wedge & T_{\mathrm{n}} \in \mathbb{N}_{256} & \wedge \\
+T_{\mathrm{x}} \in \{0, 1, 2, 3\} & \wedge & T_{\mathrm{c}} = \beta & \wedge & T_{\mathrm{n}} \in \mathbb{N}_{256} & \wedge \\
T_{\mathrm{p}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{g}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{v}} \in \mathbb{N}_{256} & \wedge \\
T_{\mathrm{w}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{r}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{s}} \in \mathbb{N}_{256} & \wedge \\
T_{\mathrm{y}} \in \mathbb{N}_{1} & \wedge & T_{\mathbf{d}} \in \mathbb{B} & \wedge & T_{\mathbf{i}} \in \mathbb{B} & \wedge \\
-T_{\mathrm{m}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{f}} \in \mathbb{N}_{256}
+T_{\mathrm{m}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{f}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{b}} \in \mathbb{N}_{256}
\end{array}
\end{equation}
where
@@ -409,9 +424,14 @@ \subsection{The Transaction} \label{subsec:transaction}
\mathbb{N}_{\mathrm{n}} = \{ P: P \in \mathbb{N} \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$.
+Type 3 transaction cannot create contracts, so in that case $T_{\mathbf{t}}$ must always be a 20-byte address hash.
+
\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{x}} = 3 \lor T_{\mathrm{t}} \neq \varnothing \\
\mathbb{B}_{0} & \text{otherwise}\end{cases}
\end{equation}
@@ -467,6 +487,9 @@ \subsection{The Block}\linkdest{block}\label{subsec:The_Block}
\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}}$}.
+\item[blobGasUsed]\linkdest{blob_gas_used_H__bg}{} A scalar value equal to the total blob gas used in blob-carrying transactions in this block; formally \hyperlink{H__bg}{$H_{\mathrm{bg}}$}.
+\item[excessBlobGas]\linkdest{excess_blob_gas_H__ebg}{} A scalar value equal to the total excess blob gas in this block; formally \hyperlink{H__ebg}{$H_{\mathrm{ebg}}$}.
+\item[parentBeaconBlockRoot]\linkdest{parent_beacon_block_root_H__br}{} The hash tree root of the consensus layer block corresponding to this execution layer block; formally \hyperlink{H__br}{$H_{\mathrm{br}}$}.
\end{description}
\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}
@@ -582,7 +605,7 @@ \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}}, H_{\mathrm{w}} \; )\end{array} \\
+\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}}, H_{\mathrm{bg}}, H_{\mathrm{ebg}}, H_{\mathrm{br}} \; )\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:
@@ -605,7 +628,8 @@ \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} & \wedge & \hyperlink{withdrawals_root_H__w}{H_{\mathrm{w}}} \in \mathbb{B}_{32}
+\hyperlink{block_baseFeePerGas_H__f}{H_{\mathrm{f}}} \in \mathbb{N} & \wedge & \hyperlink{withdrawals_root_H__w}{H_{\mathrm{w}}} \in \mathbb{B}_{32} & \wedge & \hyperlink{blob_gas_used_H__bg}{H_{\mathrm{bg}}} \in \mathbb{N} & \wedge \\
+\hyperlink{excess_blob_gas_H__ebg}{H_{\mathrm{ebg}}} \in \mathbb{N} & \wedge & \hyperlink{parent_beacon_block_root_H__br}{H_{\mathrm{br}}} \in \mathbb{B}_{32}
\end{array}
\end{equation}
@@ -692,6 +716,43 @@ \subsubsection{Block Header Validity}
H_{\mathrm{s}} > {P(H)_{\mathrm{H}}}_{\mathrm{s}}
\end{equation}
+The Cancun update introduced a different type of gas, called blob-gas, used only to pay for blob hash data in type 3 transactions.
+We define a block blob-gas target $\tau_{blob}$, contrary to the dynamic block gas target $\tau$, this target is fixed and defined as:
+
+\begin{equation}
+ \tau_{blob} = 393,216
+\end{equation}
+
+The maximum amount of blob-gas that can be used in a block is defined as:
+\begin{equation}
+ \mathrm{bg}_{max} \equiv 789,432
+\end{equation}
+
+The current header's excess blob gas, $H_{\mathrm{ebg}}$, represents the amount by which the parent overshot the target blob-gas.
+It is calculated from the parent's header, $P(H)_{\mathrm{H}}$, using the following function:
+
+\begin{equation}
+ E(H) \equiv \begin{cases}
+ 0 & \text{if} \quad (P(H)_{\mathrm{ebg}} + \\
+ & P(H)_{\mathrm{bg}}) < \tau_{blob} \\
+ P(H)_{\mathrm{ebg}} + P(H)_{\mathrm{bg}} - \tau_{blob} & \text{otherwise}
+ \end{cases}
+\end{equation}
+
+The total blob-gas used in the current block is calculated like this:
+\begin{equation}
+ HG_{blob}(H) \equiv \sum_{T \in B_{\mathbf{T}}} TG_{blob}(T)
+\end{equation}
+
+\hypertarget{base_fee_per_blob_gas}{}Each block also compute a base-fee per blob-gas, this fee is computed as the Taylor approximation of the exponential function:
+\begin{eqnarray}
+ f_{blob}(H) & \equiv & \left\lfloor \frac{1}{A_1} \sum_{i=1}^{k} A_i \right\rfloor \\
+ A_1 & \equiv & 3,338,477 \\
+ A_{i+1} & \equiv & \left\lfloor \frac{A_i \times H_{\mathrm{ebg}}}{A_1} \times i \right\rfloor \\
+ k & \equiv & \max \{ i \in \mathbb{N} \mid A_i > 0 \}
+\end{eqnarray}
+
+
The \textit{Paris} hard fork changed Ethereum's consensus from proof of work to proof of stake, and thus deprecated many block header properties related to proof of work. These deprecated properties include \textbf{nonce} ($H_{\mathbf{n}}$), \textbf{ommersHash} ($H_{\mathbf{o}}$), \textbf{difficulty} ($H_{\mathbf{d}}$), and \textbf{mixHash} ($H_{\mathbf{m}}$).
\textbf{mixHash} has been replaced with a new field \textbf{prevRandao} ($H_{\mathbf{a}}$). The other header fields related to proof of work have been replaced with constants:
@@ -704,6 +765,7 @@ \subsubsection{Block Header Validity}
The value of \textbf{prevRandao} must be determined using information from the Beacon Chain.
While the details of generating the \textit{RANDAO} value on the Beacon Chain is beyond the scope of this paper, we refer to the expected \textit{RANDAO} value for the previous block as $\mathtt{PREVRANDAO}()$.
+Similarly, the value of \textbf{parentBeaconBlockRoot} ($H_{\mathrm{br}}$) must be determined using information from the Beacon Chain, we refer to the expected value as $\mathtt{PARENT\_BEACON\_BLOCK\_ROOT}()$.
\hypertarget{block_header_validity_function}{}Thus we are able to define the block header validity function $V(H)$:
\begin{eqnarray}
@@ -718,11 +780,49 @@ \subsubsection{Block Header Validity}
\nonumber& & H_{\mathrm{o}} = \texttt{KEC}(\texttt{RLP}(())) \quad \wedge \\
\nonumber& & H_{\mathrm{d}} = 0 \quad \wedge \\
\nonumber& & H_{\mathrm{n}} = \texttt{0x0000000000000000} \quad \wedge \\
-\nonumber& & H_{\mathrm{a}} = \mathtt{PREVRANDAO}()
+\nonumber& & H_{\mathrm{a}} = \mathtt{PREVRANDAO}() \wedge \\
+\nonumber& & H_{\mathrm{bg}} \leq \mathrm{bg}_{max} \quad \wedge \\
+\nonumber& & H_{\mathrm{bg}} = HG_{blob}(H) \wedge \\
+\nonumber& & H_{\mathrm{ebg}} = E(H) \wedge \\
+\nonumber& & H_{\mathrm{br}} = \mathtt{PARENT\_BEACON\_BLOCK\_ROOT}()
\end{eqnarray}
Note additionally that \textbf{extraData} must be at most 32 bytes.
+\subsection{System-level Transactions}\label{subsec:System_Level_Transactions}
+Introduced by the Cancun update, each block now begins with the execution of a predefined set of system-level transactions $T_{sys}$.
+System-level transactions are executed before any other regular transactions,
+and are not included in the block's transaction list $B_{\mathbf{T}}$.
+Those transactions behave like regular transactions but with some caveats:
+they always target predefined system contracts,
+they do not incur any gas fee, reward or burn, and their gas usage do not count towards the block's gas limit.
+The signature and nonce checks are also ignored for those transactions,
+the sender address $S(T)$ is always set to be the system account $a_{sys}$ \eqref{eq:system_address}.
+
+A system-level transaction contains the same fields as a regular transaction $\textit{T}$.
+
+The set of system-level transactions $T_{sys}$ is defined as:
+
+\begin{equation}
+ T_{sys} \equiv \{T_{beacon\_root}\}
+\end{equation}
+
+where
+\begin{eqnarray}
+ T_{beacon\_root} \equiv \begin{cases}
+ T_{\mathrm{x}} = 0 \\
+ T_{\mathrm{n}} = \sigma[\hyperlink{beacon_root_address}{a_{beacon\_root}}]_n \\
+ T_{\mathrm{p}} = 0 \\
+ T_{\mathrm{g}} = 30,000,000 \\
+ T_{\mathrm{t}} = \hyperlink{beacon_root_address}{a_{beacon\_root}} \\
+ T_{\mathrm{v}} = 0 \\
+ T_{\mathrm{d}} = \hyperlink{parent_beacon_block_root_H__br}{H_{\mathrm{br}}} \\
+ T_{\mathrm{w}} = 0 \\
+ T_{\mathrm{r}} = 0 \\
+ T_{\mathrm{s}} = 0 \\
+ \end{cases}
+\end{eqnarray}
+
\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 account storage and executing operations on the virtual machine) has a universally agreed cost in terms of gas.
@@ -752,6 +852,7 @@ \section{Transaction Execution} \label{ch:transactions}
\item the sender account balance contains at least the cost, $v_0$, required in up-front payment;
\item the \textbf{maxFeePerGas}, $T_m$, in the case of type 2 transactions, or \textbf{gasPrice}, $T_p$, in the case of type 0 and type 1 transactions, is greater than or equal to the block's base fee, $H_{\mathrm{f}}$; and
\item for type 2 transactions, \textbf{maxPriorityFeePerGas}, $T_f$, must be no larger than \textbf{maxFeePerGas}, $T_m$.
+\item for type 3 transactions, $T_{\mathrm{t}}$ cannot be $\varnothing$ and must always be a 20-byte address.
\end{enumerate}
Formally, we consider the function \hyperlink{Upsilon_state_transition}{$\Upsilon$}, with $T$ being a transaction and $\boldsymbol{\sigma}$ the state:
@@ -764,19 +865,20 @@ \section{Transaction Execution} \label{ch:transactions}
\subsection{Substate} \label{ch:substate}
Throughout transaction execution, we accrue certain information that is acted upon immediately following the transaction. We call this the \textit{accrued transaction substate}, or \textit{accrued substate} for short, 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_{\mathbf{a}}, A_{\mathbf{K}})
+A \equiv (A_{\mathbf{s}}, A_{\mathbf{l}}, A_{\mathbf{t}}, A_{\mathrm{r}}, A_{\mathbf{a}}, A_{\mathbf{K}}, A_{\mathbf{c}})
\end{equation}
\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}{}$A_{\mathrm{r}}$ is 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.
-Finally, EIP-2929 by \cite{EIP-2929} introduced \hypertarget{accessed_addresses_defn_words_A__a}{}$A_{\mathbf{a}}$, the set of accessed account addresses, and \hypertarget{accessed_storage_keys_defn_words_A__k}{}$A_{\mathbf{K}}$, the set of accessed storage keys
+On top of that, EIP-2929 by \cite{EIP-2929} introduced \hypertarget{accessed_addresses_defn_words_A__a}{}$A_{\mathbf{a}}$, the set of accessed account addresses, and \hypertarget{accessed_storage_keys_defn_words_A__k}{}$A_{\mathbf{K}}$, the set of accessed storage keys
(more accurately, each element of $A_{\mathbf{K}}$ is a tuple of a 20-byte account address and a 32-byte storage slot).
+Finally, \hypertarget{refund_balance_defn_words_A__r}{}$A_{\mathrm{c}}$ is the set of contract addresses created during the transaction.
-We define the empty accrued substate $A^0$ to have no self-destructs, no logs, no touched accounts, zero refund balance, all precompiled contracts in the accessed addresses, and no accessed storage:
+We define the empty accrued substate $A^0$ to have no self-destructs, no logs, no touched accounts, zero refund balance, all precompiled contracts in the accessed addresses, no accessed storage and no created contracts:
\begin{equation}
-A^0 \equiv (\varnothing, (), \varnothing, 0, \pi, \varnothing)
+A^0 \equiv (\varnothing, (), \varnothing, 0, \pi, \varnothing, \varnothing)
\end{equation}
where $\hyperlink{precompiled_set}{\pi}$ is the set of all precompiled addresses.
@@ -838,11 +940,17 @@ \subsection{Execution}
\end{cases}
\end{equation}
+The total blob-gas of the transaction is calculated as:
+\begin{equation}
+ TG_{blob}(T) \equiv \lVert T_{\mathrm{B}} \rVert \times G_{\mathrm{blob}}
+\end{equation}
+
The up-front cost $v_0$ is calculated as:
\begin{equation}
v_0 \equiv \begin{cases}
\hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}}T_{\mathrm{p}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} & \text{if} \; T_{\mathrm{x}} = 0 \lor T_{\mathrm{x}} = 1 \\
\hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}}T_{\mathrm{m}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} & \text{if} \; T_{\mathrm{x}} = 2 \\
+ \hyperlink{tx_gas_limit_T__g}{T_{\mathrm{g}}}T_{\mathrm{m}} + \hyperlink{tx_value_T__v}{T_{\mathrm{v}}} + TG_{blob}(T) \times T_{\mathrm{b}} & \text{if} \; T_{\mathrm{x}} = 3 \\
\end{cases}
\end{equation}
@@ -878,11 +986,19 @@ \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 $\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$.
-For type 2 transactions, we add an additional check that \textbf{maxPriorityFeePerGas} is no larger than \textbf{maxFeePerGas}:
+For transactions of type 2 and above, we add an additional check that \textbf{maxPriorityFeePerGas} is no larger than \textbf{maxFeePerGas}:
\begin{equation}
T_{\mathrm{m}} \geqslant T_{\mathrm{f}}
\end{equation}
+For type 3 transactions, we add the following additional checks:
+\begin{eqnarray}
+ T_{\mathrm{t}} & \neq & \varnothing \quad \wedge \\
+ \lVert T_{\mathrm{B}} \rVert & \geqslant & 1 \quad \wedge \\
+ \forall \mathrm{b} \in T_{\mathrm{B}} : \mathrm{b}[0] & = & V_{blob} \quad \wedge \\
+ T_{\mathrm{b}} & \geqslant & f_{blob}(B_{\mathrm{H}})
+\end{eqnarray}
+
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}} 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$:
@@ -976,10 +1092,12 @@ \section{Contract Creation}\label{ch:create}\hypertarget{endow}{}
\end{align}
where $\cdot$ is the concatenation of byte arrays, $\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 address of the new account is added to the set of accessed accounts:
-\begin{equation}
-A^* \equiv A \quad \text{except} \quad A^*_{\mathbf{a}} \equiv A_{\mathbf{a}} \cup \{a\}
-\end{equation}
+The address of the new account is added to the set of accessed accounts and the set of created contracts:
+\begin{eqnarray}
+ A^* & \equiv & A \quad \text{except} \\
+ \quad A^*_{\mathbf{a}} & \equiv & A_{\mathbf{a}} \cup \{a\} \\
+ \quad A^*_{\mathbf{c}} & \equiv & A_{\mathbf{c}} \cup \{a\}
+\end{eqnarray}
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}
@@ -1176,6 +1294,7 @@ \section{Message Call} \label{ch:call}
\Xi_{\mathtt{BN\_MUL}} (\boldsymbol{\sigma}_1, \boldsymbol{\theta}, g, A, I) & \text{if} \quad c = 7 \\
\Xi_{\mathtt{SNARKV}} (\boldsymbol{\sigma}_1, \boldsymbol{\theta}, g, A, I) & \text{if} \quad c = 8 \\
\Xi_{\mathtt{BLAKE2\_F}}(\boldsymbol{\sigma}_1, \boldsymbol{\theta}, g, A, I) & \text{if} \quad c = 9 \\
+\Xi_{\mathtt{KZG\_PROOF}}(\boldsymbol{\sigma}_1, \boldsymbol{\theta}, g, A, I) & \text{if} \quad c = 10 \\
\Xi (\boldsymbol{\sigma}_1, \boldsymbol{\theta}, g, A, I) & \text{otherwise} \end{cases}
\end{equation}
and
@@ -2028,6 +2147,61 @@ \subsection{BLAKE2 Precompiled Contract}
\mathtt{LE}_k(x) \equiv (b_0, b_1, ..., b_{k-1}): x = \sum_{n = 0}^{k-1} b_n \cdot 256^n
\end{equation}
+\subsection{Verify KZG Proof Precompiled Contract}
+EIP-4844 by \cite{EIP-4844} defines $\Xi_{\mathtt{KZG\_PROOF}}$ as a precompiled contract implementing the verification of KZG proofs claiming that a blob commitment evaluates to a given value at a given point.
+We define the number of field elements per blob $E$ as 4096 represented as a 32-byte big-endian integer:
+\begin{equation}
+ E = 0x000000000000000000000000000000000000000000000000000000000001000
+\end{equation}
+
+We define the BLS modulus $B$, also represented as a 32-byte big-endian integer:
+\begin{equation}
+ B = 0x73eda753299d7d483339d80809a1d8055d23bda000000000000000000000001
+\end{equation}
+
+The proof verifying function $\mathtt{VERIFY\_KZG\_PROOF}$ is defined in the \href{https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_kzg_proof}{consensus layer specification}.
+
+\begin{eqnarray}
+ \Xi_{\mathtt{KZG\_PROOF}} &\equiv& \Xi_{\mathtt{PRE}}\quad\text{except:} \\
+ v &\equiv& I_{\mathbf{d}}[0..32] \\
+ z &\equiv& I_{\mathbf{d}}[32..64] \\
+ y &\equiv& I_{\mathbf{d}}[64..96] \\
+ c &\equiv& I_{\mathbf{d}}[96..144] \\
+ p &\equiv& I_{\mathbf{d}}[144..192] \\
+ \Xi_{\mathtt{KZG\_PROOF}}(\boldsymbol\sigma,g,A,I) &=& \left(\varnothing,0,A,()\right) \quad \text{if}\ F \\
+ F &\equiv& (\lVert I_{\mathbf{d}} \rVert \neq 192 \lor (V_{blob} \cdot \mathtt{KEC}(c)[1..32]) \neq v \lor \neg \mathtt{VERIFY\_KZG\_PROOF}(c, z, y, p)) \\
+ % h_{kzg}(c) &\equiv& V_{blob} \cdot \mathtt{KEC}(c)[1..32] \\
+ \mathbf{o} &\equiv& E \cdot B
+\end{eqnarray}
+
+\section{System Contracts}\label{app:system_contracts}
+
+The Cancun update started the introduction of system contracts.
+These are regular-smart contracts that exist at pre-defined addresses.
+They differ from precompiled contracts in that they are implemented in EVM bytecode and can be interacted with like any other contract.
+They are called directly by execution client using a special $a_\mathtt{SYSTEM}$ address at the beginning of block execution,
+and are used to publish system-level information directly to the world state $\boldsymbol{\sigma}$ so that it can be used by any other smart-contracts.
+
+\begin{equation} \label{eq:system_address}
+ a_{sys} \equiv 0xfffffffffffffffffffffffffffffffffffffffe
+\end{equation}
+
+\subsection{Beacon Block Root Contract}
+
+Publish the parent consensus beacon block root \hyperlink{parent_beacon_block_root_H__br}{$H_{\mathrm{br}}$}
+to the world state $\boldsymbol{\sigma}$.
+
+We define the address and deployed bytecode of the beacon block root contract to be:
+\begin{eqnarray}
+ \hypertarget{beacon_root_address}{a_{beacon\_root}} \equiv 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02 \\
+ \mathbf{b}_{beacon\_root} \equiv 0x3373fffffffffffffffffffffffffffffffffffffffe \\
+ \nonumber 14604d57602036146024575f5ffd5b5f35801560495762001fff \\
+ \nonumber 810690815414603c575f5ffd5b62001fff01545f5260205ff35b \\
+ \nonumber 5f5ffd5b62001fff42064281555f359062001fff015500 \\
+ \boldsymbol{\sigma}[a_{beacon\_root}]_{\mathbf{c}} \equiv \texttt{KEC}(\mathbf{b}_{beacon\_root})
+\end{eqnarray}
+
+
\section{Signing Transactions}\label{app:signing}
Transactions are signed using recoverable ECDSA signatures. This method utilises the SECP-256k1 curve as described by \cite{Courtois2014}, and is implemented similarly to as described by \cite{gura2004comparing} on p.~9 of 15, para.~3.
@@ -2067,13 +2241,14 @@ \section{Signing Transactions}\label{app:signing}
A(p_{\mathrm{r}}) = \mathcal{B}_{96..255}\big(\mathtt{KEC}\big( \mathtt{ECDSAPUBKEY}(p_{\mathrm{r}}) \big) \big)
\end{equation}
-\hypertarget{h_of_T}{}The message hash, $h(T)$, to be signed is the Keccak-256 hash of the transaction. Four different flavours of signing schemes are available:
+\hypertarget{h_of_T}{}The message hash, $h(T)$, to be signed is the Keccak-256 hash of the transaction. Five different flavours of signing schemes are available:
\begin{eqnarray}
L_{\mathrm{X}}(T) & \equiv & \begin{cases}
(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}) & \text{if} \; T_{\mathrm{x}} = 0 \land T_{\mathrm{w}} \in \{27, 28\} \\
(T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, \beta, (), ()) & \text{if} \; T_{\mathrm{x}} = 0 \land T_{\mathrm{w}} \in \{2\beta + 35, 2\beta + 36\} \\
(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, T_{\mathbf{A}}) & \text{if} \; T_{\mathrm{x}} = 1 \\
-(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{f}}, T_{\mathrm{m}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, T_{\mathbf{A}}) & \text{if} \; T_{\mathrm{x}} = 2
+(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{f}}, T_{\mathrm{m}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, \mathbf{p}, T_{\mathbf{A}}) & \text{if} \; T_{\mathrm{x}} = 2 \\
+(T_{\mathrm{c}}, T_{\mathrm{n}}, T_{\mathrm{f}}, T_{\mathrm{m}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathrm{d}}, T_{\mathbf{A}}, T_{\mathbf{b}}, T_{\mathbf{B}}) & \text{if} \; T_{\mathrm{x}} = 3 \\
\end{cases} \\
\nonumber \text{where} \\
\nonumber \mathbf{p} & \equiv & \begin{cases}
@@ -2163,6 +2338,7 @@ \section{Fee Schedule}\label{app:fees}
$G_{\mathrm{keccak256word}}$ & 6 & Paid for each word (rounded up) for input data to a {\small KECCAK256} operation. \\
$G_{\mathrm{copy}}$ & 3 & Partial payment for {\small *COPY} operations, multiplied by words copied, rounded up. \\
$G_{\mathrm{blockhash}}$ & 20 & Payment for each {\small BLOCKHASH} operation. \\
+$G_{\mathrm{blob}}$ & 131,072 & Cost for each blobl of a type-3 transaction. \\
%extern u256 const c_{\mathrm{copyGas}}; ///< Multiplied by the number of 32-byte words that are copied (round up) for any *COPY operation and added.
\bottomrule
@@ -2232,9 +2408,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}, {\small PUSH0}\}
+$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}, {\small BLOBBASEFEE}\}
-$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{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 BLOBHASH}, {\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}\}
@@ -2242,7 +2418,7 @@ \subsection{Gas Cost}
$W_{\mathrm{high}}$ = \{{\small JUMPI}\}
-$W_{\mathrm{copy}}$ = \{{\small CALLDATACOPY}, {\small CODECOPY}, {\small RETURNDATACOPY}\}
+$W_{\mathrm{copy}}$ = \{{\small CALLDATACOPY}, {\small CODECOPY}, {\small RETURNDATACOPY}, {\small MCOPY}\}
$W_{\mathrm{call}}$ = \{{\small CALL}, {\small CALLCODE}, {\small DELEGATECALL}, {\small STATICCALL}\}
@@ -2531,6 +2707,15 @@ \subsection{Instruction Set}
\midrule
0x48 & {\small BASEFEE} & 0 & 1 & Get the current block's base fee. \\
&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv {I_{\mathrm{H}}}_{\mathrm{f}}$ \\
+\midrule
+0x49 & {\small BLOBHASH} & 1 & 1 & Get one of the blob hashes of the current transaction. \\
+&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \begin{cases}
+ T_{\mathbf{B}}[\boldsymbol{\mu}_{\mathbf{s}}[0]] & \text{if} \quad \boldsymbol{\mu}_{\mathbf{s}}[0] < \lVert T_{\mathbf{B}} \rVert \\
+ 0 & \text{otherwise}
+\end{cases}$ \\
+\midrule
+0x4a & {\small BLOBBASEFEE} & 0 & 1 & Get base fee per blob-gas of the current block. \\
+&&&& $\boldsymbol{\mu}'_{\mathbf{s}}[0] \equiv \hyperlink{base_fee_per_blob_gas}{f_{blob}(I_{\mathrm{H}})}$ \\
\bottomrule
\end{tabu}
@@ -2634,6 +2819,9 @@ \subsection{Instruction Set}
\midrule
0x5d & {\small TSTORE} & 2 & 0 & Save word to transient storage. \\
&&&& $\boldsymbol{\theta}'[I_{\mathrm{a}}]_{\mathbf{s}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] ] \equiv \boldsymbol{\mu}_{\mathbf{s}}[1] $ \\
+\midrule
+0x5e & {\small MCOPY} & 3 & 0 & Copy arbitrary bytes sequence from one location of the memory to another location. \\
+&&&& $\boldsymbol{\mu}'_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[0] \dots (\boldsymbol{\mu}_{\mathbf{s}}[0] + \boldsymbol{\mu}_{\mathbf{s}}[2]) ] \equiv \boldsymbol{\mu}_{\mathbf{m}}[ \boldsymbol{\mu}_{\mathbf{s}}[1] \dots (\boldsymbol{\mu}_{\mathbf{s}}[1] + \boldsymbol{\mu}_{\mathbf{s}}[2]) ]$ \\
\bottomrule
\end{tabu}
@@ -2838,14 +3026,18 @@ \subsection{Instruction Set}
0xfe & {\small INVALID} & $\varnothing$ & $\varnothing$ & Designated invalid instruction. \\
\midrule
\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}} \}$ \\
+&&&& since the \textit{Shanghai} update, this opcode has been marked as deprecated, \\
+&&&& any use in newly deployed contracts is strongly discouraged. \\
+&&&& $A'_{\mathbf{s}} \equiv \begin{cases}
+ A_{\mathbf{s}} \cup \{ I_{\mathrm{a}} \} \ & \text{if}\quad I_{\mathrm{a}} \in A_{\mathbf{c}} \\
+ A_{\mathbf{s}} & \text{otherwise}
+\end{cases}$ \\
&&&& $A'_{\mathbf{a}} \equiv A_{\mathbf{a}} \cup \{ r \}$ \\
&&&& $\boldsymbol{\sigma}'[r] \equiv \begin{cases}
\varnothing &\text{if}\quad \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}\quad 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}}, 0, \boldsymbol{\sigma}[r]_{\mathbf{s}}, \boldsymbol{\sigma}[r]_{\mathrm{c}}) & \text{if}\quad r = I_{\mathrm{a}} \wedge I_{\mathrm{a}} \in A_{\mathbf{c}} \\
+\boldsymbol{\sigma}[r] & \text{otherwise}
\end{cases}$\\ \\
&&&& where $r = \boldsymbol{\mu}_{\mathbf{s}}[0] \bmod 2^{160}$\\ \\
&&&& $\boldsymbol{\sigma}'[I_{\mathrm{a}}]_{\mathrm{b}} = 0$ \\