From 9fde3f4a07487b702a4b30ff74f26e0cd153db05 Mon Sep 17 00:00:00 2001 From: Alfred Gaillard Date: Mon, 2 Sep 2024 09:44:12 +0200 Subject: [PATCH 1/3] style: add some missing words. (#917) * style: add a missing "be". * style: add a missing "it is". * refactor: clearer sentence --- Paper.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Paper.tex b/Paper.tex index 3db75fcc..7c36c4f8 100644 --- a/Paper.tex +++ b/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}. From f3553dd559f574f061037718512444abc53bbd40 Mon Sep 17 00:00:00 2001 From: stehled Date: Mon, 4 Nov 2024 10:50:13 +0100 Subject: [PATCH 2/3] Fix transactions typo (#919) --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 7c36c4f8..3e581123 100644 --- a/Paper.tex +++ b/Paper.tex @@ -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} From c03e06744c93744406de144ce56d479a21ed0c7b Mon Sep 17 00:00:00 2001 From: raxhvl <10168946+raxhvl@users.noreply.github.com> Date: Wed, 8 Jan 2025 11:09:31 +0100 Subject: [PATCH 3/3] =?UTF-8?q?=F0=9F=90=9E=20fix:=20Formula=20for=20initc?= =?UTF-8?q?ode=20limit=20(#920)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: rahul --- Paper.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Paper.tex b/Paper.tex index 3e581123..229e9986 100644 --- a/Paper.tex +++ b/Paper.tex @@ -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}