Fix eipw errors

EIPS/eip-6690.md

@@ -1,13 +1,13 @@
 ---
 eip: 6690
 title: EVM Modular Arithmetic Extensions (EVMMAX)
+description: Create modular addition, subtraction, and multiplication opcodes.
+author: Jared Wasinger (@jwasinger), Alex Beregszaszi (@axic)
+discussions-to: https://ethereum-magicians.org/t/eip-6690-evm-modular-arithmetic-extensions-evmmax-decoupled-from-eof/13322
 status: Draft
-type: standards track
-author: Jared Wasinger <@jwasinger>, Alex Beregszaszi (@axic)
-discussions-to:
+type: Standards Track
 category: Core
 created: 2023-03-15
-requires:
 ---
 
 ## Abstract
@@ -24,7 +24,7 @@ Benefits of the changes proposed in this EIP:
 
 ## Specification
 
-#### Overview
+### Overview
 
 During contract execution, a contract calls a setup instruction `SETUPX`, sourcing a modulus from a specified memory offset/size and computing several parameters used to speed up modular multiplication (referred to as "Montgomery" parameters).  A zeroed memory space (whose size is a stack parameter passed to `SETUPX`) is allocated separate from EVM memory.
 
@@ -38,15 +38,15 @@ The immediate is interpreted as 3 1-byte values `z`, `x`, `y` which are indexes
 
 An arithmetic operation is performed on inputs at index `x`/`y` placing the result in index `z`.
 
-#### Conventions
+### Conventions
 
 1. `x === y % m`: `x % m == y % m`
 2. `pow(x, -1, m)`: The modular multiplicative inverse of `x` with respect to modulus `m`.
 2. Opcode definition syntax is formatted as `mneumonic {immediate - type} {immediate2 - type} ...: stack_arg_1, stack_arg_2, ...` where immediates are listed in the order that they proceed the opcode and stack arguments are ordered starting at the top of the stack.
 3. In the provided pseudocode, it is assumed that opcode gas charging logic is executed prior to execution logic.
 4. Any exception thrown should immediately end the current execution frame and return to the caller.
 
-#### Constants
+### Constants
 
 | Name | Value | Description |
 | ---- | ---- | ---- |
@@ -58,7 +58,7 @@ An arithmetic operation is performed on inputs at index `x`/`y` placing the resu
 | `MULMODX_SUBQUADRATIC_START` | 50 | modulus size in in multiples of 8 bytes where we switch to subquadratic mulmont cost model |
 | `SYSTEM_WORD_SIZE_BITS` | varies depending on the system | word size in bits of a client's CPU |
 
-#### Context Variables
+### Context Variables
 
 | Name | Type | Meaning |
 | ---- | ------- | --- |
@@ -93,7 +93,7 @@ class ModState():
         self.values = [0] * self.num_vals_used
 ```
 
-#### Helpers
+### Helpers
 
 ```
 # -----------------------------------------------------------------------------
@@ -305,6 +305,7 @@ def mulmont(mod_state: ModState, x: int, y: int) -> int:
 `SETUPX : mod_id, mod_offset, mod_size, vals_used`
 
 ##### Gas Charging
+
 ```
 mod_id = evm.stack.peek(0)
 mod_offset = evm_stack.peek(1)
@@ -328,9 +329,10 @@ val_size_multiplier = math.ceil(mod_size / 8)
 
 cost += cost_precompute_mont(val_size_multiplier)
 cost += cost_evm_memory_expansion(math.ceil((num_vals_used * val_size_multiplier * 8) / 32))
-````
+```
 
 ##### Execution
+
 ```
 mod_id = stack.pop()
 mod_offset = stack.pop()
@@ -367,12 +369,15 @@ evmmax_state.active_mod_state = mod_state
 ```
 
 #### LOADX
+
 `LOADX: dst_offset, val_idx, num_vals`
 
 ##### Description
+
 Load EVMMAX values in the current active modulus state to EVM memory.
 
 ##### Gas Charging
+
 ```
 cost = LOADX_BASE_GAS
 dst_offset = evm_stack.peek(0)
@@ -387,6 +392,7 @@ cost += cost_mulmodx(val_size_multiplier) * mod_state.num_vals
 ```
 
 ##### Execution
+
 ```
 dst_offset = evm_stack.pop()
 val_idx = evm_stack.pop()
@@ -417,6 +423,7 @@ for i in range(num_vals):
 ```
 
 #### STOREX
+
 `STOREX: dst_val, offset, num_vals`
 
 ##### Description
@@ -433,7 +440,9 @@ num_vals = evm_stack.peek(2)
 val_size_multiplier = evmmax_state.active_mod_state.val_size_multiplier
 cost = STOREX_BASE_COST + num_vals * cost_mulmodx(val_size_multiplier)
 ```
+
 ##### Execution
+
 ```
 dst_val = evm_stack.pop()
 offset = evm_stack.pop()
@@ -478,12 +487,14 @@ for i in range(num_vals):
 Compute the modular addition of two EVMMAX values, storing the result in an output.
 
 ##### Gas Charging
+
 ```
 val_size_multiplier = evmmax_state.active_mod_state.val_size_multiplier
 cost = cost_addmodx(val_size_multiplier)
 ```
 
 ##### Execution
+
 ```
 mod_state = evmmax_state.active_modulus
 if mod_state == None:
@@ -511,6 +522,7 @@ Compute the modular subtraction of two EVMMAX values in the current active modul
 Same as `ADDMODX`.
 
 ##### Execution
+
 ```
 mod_state = evmmax_state.active_modulus
 if mod_state == None:
@@ -534,12 +546,14 @@ mod_state.values[z_offset] = (mod_state.values[x_offset] - mod_state.values[y_of
 Compute the Montgomery modular multiplication of two EVMMAX values in the current active modulus state, storing the result in an output.
 
 ##### Gas Charging
+
 ```
 val_size_multiplier = evmmax_state.active_mod_state.val_size_multiplier
 cost = cost_mulmodx(val_size_multiplier)
 ```
 
 ##### Execution
+
 ```
 mod_state = evmmax_state.active_modulus
 if mod_state == None:
@@ -584,6 +598,7 @@ This choice is made to keep EVMMAX memory aligned to ensure performance.
 Gas models assume a rate of 1 gas per 25ns of execution time.
 
 #### ADDMODX/SUBMODX/MULMODX
+
 `ADDMODX` and `SUBMODX` can each be implemented using a single extended-precision addition, and single extended precision subtraction.  This justifies a linear cost model.
 
 `MULMODX` runtime scales quadratically with input size.  After a certain threshold, the quadratic complexity of `mulmont_quadratic` dominates and it becomes more performant to use `mulmont_subquadratic`.  Thus, there is a segmented cost model to reflect different asymptotic behavior between quadratic/subquadratic `mulmont`.
@@ -598,8 +613,16 @@ These perform conversion to/from Montgomery and canonical forms for each value c
 
 #### SETUPX
 
-TODO
+<!-- TODO -->
 
 ## Backwards Compatibility
 
 Jumpdest analysis changes in ths EIP could potentially break existing contracts where a jump destination occurs in the 3 bytes proceeding a `0x22`/`0x23`/`0x24`.  This is unlikely to affect many existing contracts.  Further analysis of deployed contract bytecode can determine with certainty, which (if any) contracts could be broken.
+
+## Security Considerations
+
+<!-- TODO -->
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).