fix: Correct description lines of the code (#20)

Co-authored-by: Olivier Bégassat <[email protected]>

hub/generalities/context/intro.tex

@@ -20,7 +20,7 @@
 This happens whenever the current instruction is either
 (\emph{c}) of \textbf{\inst{CALL}-type} or
 (\emph{d}) of \textbf{\inst{CREATE}-type}.
-Determining when a context change may happen is therfore comparatively easy.
+Determining when a context change may happen is therefore comparatively easy.
 This is the purpose of the \cmc{}.
 
 \saNote{} Whenever the execution context \emph{may change} the \zkEvm{} \textbf{must} perform various sanity checks (such as making sure that its gas supply pre-opcode is nonnegative.)

hub/heartbeat/execution_required.tex

@@ -1,4 +1,4 @@
-We explain the remaing cases i.e. those cases where \evm{} execution is required. These are:
+We explain the remaining cases i.e. those cases where \evm{} execution is required. These are:
 \begin{itemize}
 	\item the transaction is a \textbf{message call} and the recipient account has \textbf{nonempty byte code};
 	\item the transaction is a \textbf{contract deployment} with \textbf{nonempty initialization code};

hub/instruction_handling/call/precompiles/ecadd_ecmul_ecpairing/empty.tex

@@ -48,7 +48,7 @@
 		\end{enumerate}
 		the first one is interpreted as the zero integer $\in \mathbb{N}_{256}$;
 		the second one is interpreted, by \evm{} convention and as already explained, as the \textbf{point at infinity} on the \texttt{altbn} curve;
-		this input data is therfore well-formed and cannot trigger $\scenPrcFailureKnownToRam$; 
+		this input data is therefore well-formed and cannot trigger $\scenPrcFailureKnownToRam$; 
 		furthermore, the return data is (the \evm{} encoding of) the point at infinity
 		$
 		\utt{00} \;

hub/instruction_handling/call/precompiles/modexp/success.tex

@@ -15,7 +15,7 @@
 (\emph{b}) potentially extract the exponent
 (\emph{c}) potentially extract the modulus
 (\emph{d}) potentially transfer the output of the precompile to a dedicated execution context's \textsc{ram}
-(\emph{e}) potentially copy part of the ouput to the current exeuction context's \textsc{ram}.
+(\emph{e}) potentially copy part of the output to the current exeuction context's \textsc{ram}.
 \begin{description}
 	\item[\underline{\underline{Miscellaneous row $n^°(i + \prcModexpSuccessExtractBaseRowOffset)$:}}]
 		the \zkEvm{} triggers the \oobMod{} instruction \oobInstModexpExtract{};

notes/stipend.md

@@ -139,7 +139,7 @@ We can have some columns that contain the contents of things to look-up else whe
 The idea would be that one has
 - WCP_SELECTOR * EXT_SELECTOR = 0
 - If STAMP = 0 Then WCP_SELECTOR + MOD_SELECTOR = 0 (i.e. both are zero)
-- If WCP_SELECTOR = 1 Then LOOKUP_INST $\in$ { LT, ISZERO } (i.E. we can only request LT and ISZERO instuctions)
+- If WCP_SELECTOR = 1 Then LOOKUP_INST $\in$ { LT, ISZERO } (i.E. we can only request LT and ISZERO instructions)
 - If MOD_SELECTOR = 1 Then LOOKUP_INST = DIV (i.e. we can only request the DIV from MOD)
 
 ### CREATE workflow

oob/precompiles/common/generalities.tex

@@ -53,6 +53,6 @@
 		Note that at this stage the conditions that trigger $\locHubSuccess \equiv 1$ aren't set.
 		Neither is it clear that \locHubSuccess{} is binary.
 \end{description}
-We remind the reader that the remaing objectives of the \oobMod{} module in this particular case are to perform the following tasks
+We remind the reader that the remaining objectives of the \oobMod{} module in this particular case are to perform the following tasks
 \green{(\emph{a})} compare the call gas to the (constant) cost of these precompiles thus justifying the \locHubSuccess{} (In case of \inst{ECPAIRING} a congruence must also be checked)
 \green{(\emph{b})} compute the \locReturnGas{}.

pkg/IEEEtrantools.sty

@@ -2483,7 +2483,7 @@ in the IEEEeqnarray column specifications.}%
 \toks0={##}%
 % make preamble advance col counter if this environment needs this
 \if@advanceIEEEeqncolcnt\@IEEEappendtoksA{\global\advance\@IEEEeqncolcnt by 1\relax}\fi
-% insert the column defintion into the preamble, being careful not to expand
+% insert the column definition into the preamble, being careful not to expand
 % the column definition
 \@IEEEappendtoksA{\tabskip=\@IEEEBPcurglue}%
 \@IEEEappendNOEXPANDtoksA{\begingroup\csname @IEEEeqnarraycolPRE}%

prc/blkmdx/columns.tex

@@ -22,7 +22,7 @@
 The following column is a ``limb'' which contains limbs (i.e. $\llarge$-byte integers) representing data.
 This data may be either input data
 (\inst{MODEXP} base, exponent or modulus, \inst{BLAKE2f} ``\col{rounds}'' and ``\col{f}'' parameters and \col{h}, \col{m} and \col{t} parameters)
-or ouput data
+or output data
 (\inst{MODEXP} result or \inst{BLAKE2f} result.)
 \begin{enumerate}[resume]
 	\item \limb{}:

rlp_addr/intro.tex

@@ -14,4 +14,4 @@
     \zeta \cdot
     h
 \]
-In applications this method is used by the \inst{CREATE2} opcode: the address $s$ is that of the creator account, $\zeta$ (the ``salt'') is a stack argument and $h = \texttt{KECCAK}(\textbf{i})$ is the hash of the initalization code $\textbf{i}$.
+In applications this method is used by the \inst{CREATE2} opcode: the address $s$ is that of the creator account, $\zeta$ (the ``salt'') is a stack argument and $h = \texttt{KECCAK}(\textbf{i})$ is the hash of the initialization code $\textbf{i}$.

rlp_txn/generalities/constancies.tex

@@ -33,7 +33,7 @@
 	\item $\absTxNumInfty$ is block-constant.
 \end{enumerate}
 We draw the attention of the reader to the fact that the following constraints hold by construction of the relevant columns.
-There is therfore no reason to explictly include the following constraints in the implementation.
+There is therefore no reason to explicitly include the following constraints in the implementation.
 \begin{enumerate}[resume]
 	\item $\ispadding$ is $\phaseRlpPrefix$-decrementing; \quad (\trash)
 	\item $\done$ and $\accsize$ are $\ct$-incrementing; \quad (\trash)