From 38a6e93b49f6128d0bcd172fbd1e8943d6d955cd Mon Sep 17 00:00:00 2001 From: Anonim Date: Fri, 3 Jan 2025 08:42:28 +0300 Subject: [PATCH 1/3] intro.tex --- rom/intro.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rom/intro.tex b/rom/intro.tex index 7fb420b3..0490d500 100644 --- a/rom/intro.tex +++ b/rom/intro.tex @@ -2,7 +2,7 @@ The \romMod{} module contains \emph{nonempty} bytecodes (i.e. words $\in\mathbb{B}^*$) of contracts used within a conflation of blocks (and thus all transactions contained therein) as well as some associated metadata. Its main role in the overall design is to provide the \hubMod{} module with the correct sequence of instructions. It furthermore is responsible for assembling the \inst{PUSH}-values and for tagging (in)valid jump destinations as required by \textsc{jump destination analysis}. -Most of the arithmetization below focuses on building the \romMod{} module as a seqence of padded byte codes and of extracting the correct push values from it (i.e. the $X$-byte long arguments of actual \inst{PUSH\_X} instructions). +Most of the arithmetization below focuses on building the \romMod{} module as a sequence of padded byte codes and of extracting the correct push values from it (i.e. the $X$-byte long arguments of actual \inst{PUSH\_X} instructions). There are three kinds of accesses to bytecode that the \romMod{} module deals with, with contract deployment being subdivided into 1 or 2 phases (since deployments may fail): \begin{enumerate} From 3fb2b9503bb7246c675dca52b90966ad9c4a71de Mon Sep 17 00:00:00 2001 From: Anonim Date: Fri, 3 Jan 2025 08:43:45 +0300 Subject: [PATCH 2/3] talk_ethcc --- notes/talk_ethcc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/notes/talk_ethcc b/notes/talk_ethcc index 39322300..f88f746f 100644 --- a/notes/talk_ethcc +++ b/notes/talk_ethcc @@ -18,7 +18,7 @@ Slides - KECCAK # différences api - opcodes (Number, Basefee, PREVRANDAO) - - seqencer imposed limits (SHA3, ECDSA) + - sequencer imposed limits (SHA3, ECDSA) - MODEXP limited to 4096 bit integers - tx with TO = precompile: not accepted - tx that are INVALID: not accepted From e23807d5573c003adeb0b969d237581c680e3c6a Mon Sep 17 00:00:00 2001 From: Anonim Date: Fri, 3 Jan 2025 08:44:59 +0300 Subject: [PATCH 3/3] intro.tex --- rom_v3/intro.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rom_v3/intro.tex b/rom_v3/intro.tex index 9eccc8e4..787dd8ee 100644 --- a/rom_v3/intro.tex +++ b/rom_v3/intro.tex @@ -2,7 +2,7 @@ Its main role in the overall design is to provide the \hubMod{} module with the correct sequence of instructions. It furthermore assembles the \inst{PUSH}-values from the bytes following a \inst{PUSHX} instruction. It also tags (in)valid jump destinations as such as required by \textsc{jump destination analysis}. -Most of the arithmetization below focuses on building the \romMod{} module as a seqence of padded byte codes and of extracting the correct push values from it (i.e. the $\inst{X}$-byte long arguments of actual \inst{PUSHX} instructions). +Most of the arithmetization below focuses on building the \romMod{} module as a sequence of padded byte codes and of extracting the correct push values from it (i.e. the $\inst{X}$-byte long arguments of actual \inst{PUSHX} instructions). There are three kinds of accesses to bytecode that the \romMod{} module deals with, with contract deployment being subdivided into 1 or 2 phases (since deployments may fail): \begin{enumerate}