Fix typos 'instrution' → 'instruction' around whole repo (#31)

formal/uniqueness.tex

@@ -10,7 +10,7 @@
      \item type constraints for \godGiven{} inputs;
      \item $\zkEvmModuleRel_{\moduleName}(\fullTrace_\moduleName) = \mTrue$
 \end{enumerate}
-Let us assumed that we have established \textbf{uniqueness of scaffolding}. Then we can focus on the computations that fit inside the scaffolding. You can have the following notion of \textbf{essential uniqueness}: the cells that actively participate in the computation are determined by inputs alone. Here we superimpose on the computation which is hopefully captured by the constraint system the idea that some cells represent ``\textbf{inputs}'' while others represent ``\textbf{outputs}''. This is of course a natural point of view but breaks down when you consider the detail of how modules function. Modules typically get their instrutions served with inputs \emph{and} predicted outputs. And in that sense they aren't producing outputs, rather verifying that predicted outputs fit into a constraint system.
+Let us assumed that we have established \textbf{uniqueness of scaffolding}. Then we can focus on the computations that fit inside the scaffolding. You can have the following notion of \textbf{essential uniqueness}: the cells that actively participate in the computation are determined by inputs alone. Here we superimpose on the computation which is hopefully captured by the constraint system the idea that some cells represent ``\textbf{inputs}'' while others represent ``\textbf{outputs}''. This is of course a natural point of view but breaks down when you consider the detail of how modules function. Modules typically get their instructions served with inputs \emph{and} predicted outputs. And in that sense they aren't producing outputs, rather verifying that predicted outputs fit into a constraint system.
 
 Here is a slightly more precise notion. For a given computation performed by a given module one can, given scaffolding guarantees, identify individual cells as carrying ``inputs'' and others as carrying ``outputs''. Constraints apply globally throughout the trace but may be ``prescriptive'' only in certain circumstances e.g.
 \begin{Verbatim}[commandchars=\\\{\}]

hub/columns/scenarios/call.tex

@@ -9,7 +9,7 @@
 	\item \scenCallAbortWontRevert:
 		turns on for unexceptional \inst{CALL}-type instructions that abort and which won't be rolled back;
 \end{enumerate}
-The columns below pertain to unexceptional, unaborted \inst{CALL}-type instrutions i.e. \inst{CALL}'s that are entered. 
+The columns below pertain to unexceptional, unaborted \inst{CALL}-type instructions i.e. \inst{CALL}'s that are entered. 
 For the sake of clarity we provide our working definition of \textbf{precompiles}, \textbf{externally owned accounts} and \textbf{smart contracts}.
 A \textbf{precompile} is an account whose address is in the range $\{\texttt{0x01},\texttt{0x02},\dots, \texttt{0x09}\}$.
 A \textbf{smart contract} is any account with nonempty bytecode.

hub/generalities/stamps/kec.tex

@@ -42,7 +42,7 @@
 for the justification concerning the interpretation of ``$\stackDecCreateFlag \cdot \decFlag{2}$'' and ``$\stackDecHaltFlag   \cdot \decFlag{1}$''.
 
 \saNote{}
-Other than the underlying instrution being unexceptional, the arithmetization only triggers the \stackHashInfoFlag{} when the relevant \texttt{size} parameter is nonzero.
+Other than the underlying instruction being unexceptional, the arithmetization only triggers the \stackHashInfoFlag{} when the relevant \texttt{size} parameter is nonzero.
 When the size parameter is zero the \hashInfoMod{} module does not get called upon, rather we manually insert $\emptyKeccak{}$\footnote{Or, more accurately $\emptyKeccakHi$ and $\emptyKeccakLo$} in the relevant cells of the trace.
 
 \saNote{}

hub/instruction_handling/call/intro.tex

@@ -3,7 +3,7 @@
 These are among the most complex instructions in the \evm{} and certainly in the present arithmetization.
 Their complexity stems from the following main reasons:
 (\emph{a}) the manifold ways in which \inst{CALL}-type instructions may raise an exception
-(\emph{b}) the possibility for unexceptional instrutions to be aborted yet
+(\emph{b}) the possibility for unexceptional instructions to be aborted yet
 (\emph{c}) the possibility for unexceptional, unaborted \inst{CALL}-type instructions to be reverted later.
 Furthermore
 (\emph{d}) instruction-processing must differentiate the case where the target is an \textbf{externally owned account} (which leads to no code execution), a \textbf{smart contract} or a \textbf{precompile}.

hub/instruction_handling/call/triggers/mxp.tex

@@ -7,4 +7,4 @@
 		+ & \scenCallUnexceptional _{i} \\
 	\end{array} \right]
 \]
-In other words the \mxpMod{} will be triggered in all cases \emph{except for} that of a \staticxSH{} (and of \suxSH{}'s, which are caught ahead of instrution processing.)
+In other words the \mxpMod{} will be triggered in all cases \emph{except for} that of a \staticxSH{} (and of \suxSH{}'s, which are caught ahead of instruction processing.)

hub/instruction_handling/create/triggers/oob.tex

@@ -2,4 +2,4 @@
 \[
 	\locTriggerOob \define \scenCreateUnexceptional _{i}
 \]
-\saNote{} Recall that the the \oobMod{} module detects aborting conditions and failure conditions for \inst{CREATE}-type instrutions. 
+\saNote{} Recall that the the \oobMod{} module detects aborting conditions and failure conditions for \inst{CREATE}-type instructions. 

mmu/columns/macro.tex

@@ -1,4 +1,4 @@
-The following columns belong to the ``macro-instrution'' perspective, i.e. their contents behave as expected only on 
+The following columns belong to the ``macro-instruction'' perspective, i.e. their contents behave as expected only on 
 \textbf{macro-instruction-rows}. 
 \begin{enumerate}
 	\item \macroInst{}:

mmu/columns/shared.tex

@@ -1,6 +1,6 @@
 \begin{enumerate}
 	\item $\mmuStamp$:
-		macro-instruction stamp column; increases by one with every (macro) instrution processed by the \mmuMod{} module; 
+		macro-instruction stamp column; increases by one with every (macro) instruction processed by the \mmuMod{} module; 
 	\item $\microStamp$:
 		micro-instruction stamp column; a single macro-instruction may give rise to several micro-instructions dealt with in the \mmioMod{} module;
 \end{enumerate}
@@ -66,7 +66,7 @@
 	\item \mmuInstFlagModexpData{}:
 	\item \mmuInstFlagBlake{}:
 \end{enumerate}
-We introduce binary columns that will help us orient ourselves within the micro-instrution-writing-rows.
+We introduce binary columns that will help us orient ourselves within the micro-instruction-writing-rows.
 \begin{enumerate}[resume]
 	\item $\isLeftZero$:
 		binary column that lights up for ``left zero rows''; 

mmu/instructions/exoToRamTransplants/micro_instruction_writing.tex

@@ -3,7 +3,7 @@
 \end{center}
 The micro-instruction-writing phase is very simple: the same instruction gets repeated over and over again (with incrementing source and target limb offsets, that is.)
 \begin{description}
-	\item[\underline{Progression:}] \label{mmu: instructions: modexpdata: micro instrution writing: tlo progression}
+	\item[\underline{Progression:}] \label{mmu: instructions: modexpdata: micro instruction writing: tlo progression}
 		we impose generally \If $\isMicro_{i} = 1$ \Then
 		\begin{enumerate}
 			\item $\stdProgression_{i}\Big[\isMicro, \microSlo \Big]$

mmu/instructions/invalidCodePrefix/_inputs.tex

@@ -1 +1 @@
-\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instrutions: invalid code prefix: preprocessing and micro instruction writing}                    \input{instructions/invalidCodePrefix/preprocessing}
+\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instructions: invalid code prefix: preprocessing and micro instruction writing}                    \input{instructions/invalidCodePrefix/preprocessing}

mmu/instructions/mload/_inputs.tex

@@ -1 +1 @@
-\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instrutions: mload: preprocessing and micro instruction writing}                    \input{instructions/mload/preprocessing}
+\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instructions: mload: preprocessing and micro instruction writing}                    \input{instructions/mload/preprocessing}

mmu/instructions/modexpData/intro.tex

@@ -34,7 +34,7 @@
 			\end{array} \right.
 		\]
 \end{description}
-Using shorthands introduced in section~(\ref{mmu: instrutions: modexpdata: shorthands}) we will furthermore be guaranteed that
+Using shorthands introduced in section~(\ref{mmu: instructions: modexpdata: shorthands}) we will furthermore be guaranteed that
 \[
 	\left\{ \begin{array}{l}
 		0 < \locModexpParamByteSize \leq 512    \\

mmu/instructions/modexpData/micro_instruction_writing.tex

@@ -2,7 +2,7 @@
 \end{center}
 We impose the following:
 \begin{description}
-	\item[\underline{Progression:}] \label{mmu: instructions: modexpdata: micro instrution writing: tlo progression}
+	\item[\underline{Progression:}] \label{mmu: instructions: modexpdata: micro instruction writing: tlo progression}
 		we impose generally \If $\isMicro_{i} = 1$ \Then $\stdProgression_{i}\Big[\isMicro, \microTlo \Big]$
 \end{description}
 \saNote{} \label{mmu: modexData: microTLO explanation} Recall that in the present case (\mmuInstFlagModexpData{} instruction) the we have
@@ -194,4 +194,4 @@
 \saNote{} Let us say a few words on the ``\textbf{multiple nontrivial rows case}'' and in particular let us address the matter of the 
 \microSlo, \microSbo, \microTlo{} and \microTbo{} supposedly being already set (except for on the first nontrivial row.)
 This results from the fact that the first nontrivial row and all middle rows \textbf{pay forward} in terms of \microSlo, \microSbo, and \microTbo{}.
-When it comes to \microTlo{} the behavior of this column was already settled at the start, see here~(\ref{mmu: instructions: modexpdata: micro instrution writing: tlo progression}).
+When it comes to \microTlo{} the behavior of this column was already settled at the start, see here~(\ref{mmu: instructions: modexpdata: micro instruction writing: tlo progression}).

mmu/instructions/mstore/_inputs.tex

@@ -1 +1 @@
-\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instrutions: mstore: preprocessing and micro instruction writing}                    \input{instructions/mstore/preprocessing}
+\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instructions: mstore: preprocessing and micro instruction writing}                    \input{instructions/mstore/preprocessing}

mmu/instructions/mstore8/_inputs.tex

@@ -1 +1 @@
-\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instrutions: mstore8: preprocessing and micro instruction writing}                    \input{instructions/mstore8/preprocessing}
+\subsubsection{Pre-processing and micro-instruction-writing}                    \label{mmu: instructions: mstore8: preprocessing and micro instruction writing}                    \input{instructions/mstore8/preprocessing}

mmu/instructions/ramToExoWithPadding/micro_instruction_writing.tex

@@ -2,7 +2,7 @@
 
 We impose the following:
 \begin{description}
-	\item[\underline{Progression:}] \label{mmu: instructions: modexpdata: micro instrution writing: tlo progression}
+	\item[\underline{Progression:}] \label{mmu: instructions: modexpdata: micro instruction writing: tlo progression}
 		we impose generally \If $\isMicro_{i} = 1$ \Then:
 		\begin{enumerate}
 			\item $\stdProgression_{i}\Big[\isMicro, \microTlo \Big]$

mmu/instructions/rightPaddedWordExtraction/micro_instruction_writing.tex

@@ -95,7 +95,7 @@
 				\item \If $\locSecondLimbSingleSource = 0$ \Then $\locSecondMicroInst \define \mmioInstRamToLimbTwoSource$
 			\end{enumerate}
 		\end{enumerate}
-		\saNote{} The \mmioMod{} is going to carry out a second micro-instrution even if the second limb to be extracted is empty i.e. in case $\locSecondLimbVoid \equiv 1$.
+		\saNote{} The \mmioMod{} is going to carry out a second micro-instruction even if the second limb to be extracted is empty i.e. in case $\locSecondLimbVoid \equiv 1$.
 		We have chosen for that instruction to be \mmioInstLimbVanishes{}.
 		In order for this instruction to not affect exogenous data modules we impose that no exogneous data be loaded.
 		This follows from $\microExoSum \equiv 0$.

shf/instructions.tex

@@ -1,9 +1,9 @@
-The \textbf{shifting module} deals with the following instrutions:
+The \textbf{shifting module} deals with the following instructions:
 \begin{multicols}{3}
 \begin{enumerate}
 	\item \inst{SHR}
 	\item \inst{SHL}
 	\item \inst{SAR}
 \end{enumerate}
 \end{multicols}
-\noindent In previous iterations of our \zkEvm{} these instructions were dealt with in the binary module.
+\noindent In previous iterations of our \zkEvm{} these instructions were dealt with in the binary module.

stp/columns.tex

@@ -51,7 +51,7 @@
 The \gasUpfront{} excludes
 (\emph{a}) gas paid out of pocket by the caller to the callee (resp. creator to the createe);
 (\emph{b}) leftover gas that gets paid back after the \inst{CALL}/\inst{CREATE}-type instruction terminates execution and the current context resumes.
-Thus \gasUpfront{} is the part of the instruction's gas cost that determines whether one of these instrutions raises an \oogxSH{}.
+Thus \gasUpfront{} is the part of the instruction's gas cost that determines whether one of these instructions raises an \oogxSH{}.
 
 We further introduce columns that allow us to duplicate values from the current module and make them available in a straightforward manner to the \wcpMod{} and \modMod{} modules for certain computations.
 \begin{enumerate}[resume]