Update cancun branch with latest changes from master (#922)

* style: add some missing words. (#917)

* style: add a missing "be".

* style: add a missing "it is".

* refactor: clearer sentence

* Fix transactions typo (#919)

* 🐞 fix: Formula for initcode limit (#920)

Co-authored-by: rahul <[email protected]>

---------

Co-authored-by: Alfred Gaillard <[email protected]>
Co-authored-by: stehled <[email protected]>
Co-authored-by: raxhvl <[email protected]>
Co-authored-by: rahul <[email protected]>

Paper.tex

@@ -733,7 +733,7 @@ \section{Gas and Payment} \label{ch:payment}
 
 To incentivize validators to include transactions, there is an additional fee known as a \textit{priority fee}, which is also specified as wei per unit of gas consumed. The total fee paid by the transactor therefore is the sum of the base fee per gas and the priority fee per gas multiplied by the total gas consumed. Ether used to satisfy the priority fee is delivered to the \textit{beneficiary} address, the address of an account typically under the control of the validator.
 
-Transactors using type 2 transactions can specify the maximum priority fee they are willing to pay (\textbf{maxPriorityFeePerGas}) as well as the max total fee they are willing to pay (\textbf{maxFeePerGas}), inclusive of both the priority fee and the base fee. \textbf{maxFeePerGas} must at least as high as the base fee for the transaction to be included in a block. Type 0 and type 1 transactions have only one field for specifiying a gas price--\textbf{gasPrice}--which also must be at least as high as the base fee for inclusion in a block. The amount by which \textbf{gasPrice} is higher than the base fee constitutes the priority fee in the case of a type 0 or type 1 transaction.
+Transactors using type 2 transactions can specify the maximum priority fee they are willing to pay (\textbf{maxPriorityFeePerGas}) as well as the max total fee they are willing to pay (\textbf{maxFeePerGas}), inclusive of both the priority fee and the base fee. \textbf{maxFeePerGas} must be at least as high as the base fee for the transaction to be included in a block. Type 0 and type 1 transactions have only one field for specifiying a gas price--\textbf{gasPrice}--which also must be at least as high as the base fee for inclusion in a block. The amount by which \textbf{gasPrice} is higher than the base fee constitutes the priority fee in the case of a type 0 or type 1 transaction.
 
 Transactors are free to select any priority fee that they wish, however validators are free to ignore transactions as they choose. A higher priority fee on a transaction will therefore cost the sender more in terms of Ether and deliver a greater value to the validator and thus will more likely be selected for inclusion. Since there will be a (weighted) distribution of minimum acceptable priority fees, transactors will necessarily have a trade-off to make between lowering the priority fee and maximising the chance that their transaction will be included in a block in a timely manner.
 
@@ -789,7 +789,7 @@ \subsection{Execution}
 \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}
 where $T_{\mathbf{i}},T_{\mathbf{d}}$ means the series of bytes of the transaction's associated data and initialisation EVM-code, depending on whether the transaction is for contract-creation or message-call.
-$G_{\mathrm{txcreate}}$ is added if the transaction is contract-creating, but not if a result of EVM-code.
+$G_{\mathrm{txcreate}}$ is added if the transaction is contract-creating, but not if it is a message call.
 $\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}.
 
@@ -848,7 +848,7 @@ \subsection{Execution}
 and
 \begin{equation}
   n \equiv \begin{cases}
-    \lVert T_{\mathrm{i}} \rVert & \text{if} \; T_{\mathrm{t}} \neq \varnothing \\
+    \lVert T_{\mathrm{i}} \rVert & \text{if} \; T_{\mathrm{t}} = \varnothing \\
     0 & \text{otherwise}
   \end{cases}
 \end{equation}
@@ -2062,7 +2062,7 @@ \section{Signing Transactions}\label{app:signing}
 \linkdest{T__r}{T_{\mathrm{r}}} = \hyperlink{r}{r}\\
 \linkdest{T__s}{T_{\mathrm{s}}} = \hyperlink{s}{s}
 \end{eqnarray}
-and $\hyperlink{T__w}{T_{\mathrm{w}}}$ of legacy transcations is either $27 + T_{\mathrm{y}}$ or $2\hyperlink{chain_id}{\beta} + 35 + T_{\mathrm{y}}$.
+and $\hyperlink{T__w}{T_{\mathrm{w}}}$ of legacy transactions is either $27 + T_{\mathrm{y}}$ or $2\hyperlink{chain_id}{\beta} + 35 + T_{\mathrm{y}}$.
 
 We may then define the sender function $S$ of the transaction as:
 \begin{eqnarray}