EIP-4750: Fix formatting (#6125)

EIPS/eip-4750.md

@@ -17,13 +17,13 @@ Introduce the ability to have several code sections in EOF-formatted ([EIP-3540]
 
 ## Motivation
 
-Currently in the EVM everything is a dynamic jump. Languages like Solidity generate most jumps in a static manner (i.e. the destination is pushed to the stack right before, `PUSHn .. JUMP`). Unfortunately however this cannot be used by most EVM interpreters, because of added requirement of validation/analysis. This also restricts them from making optimisations and potentially reducing the cost of jumps.
+Currently, in the EVM everything is a dynamic jump. Languages like Solidity generate most jumps in a static manner (i.e. the destination is pushed to the stack right before, `PUSHn .. JUMP`). Unfortunately however this cannot be used by most EVM interpreters, because of added requirement of validation/analysis. This also restricts them from making optimisations and potentially reducing the cost of jumps.
 
 [EIP-4200](./eip-4200.md) introduces static jump instructions, which remove the need for *most* dynamic jump use cases, but not everything can be solved with them.
 
 This EIP aims to remove the need and disallow dynamic jumps as it offers the most important feature those are used for: calling into and returning from functions.
 
-Furthermore it aims to improve analysis opportunities by encoding the number of inputs and outputs for each given function, and isolating the stack of each function (i.e. a function cannot read the stack of the caller/callee).
+Furthermore, it aims to improve analysis opportunities by encoding the number of inputs and outputs for each given function, and isolating the stack of each function (i.e. a function cannot read the stack of the caller/callee).
 
 ## Specification
 
@@ -36,7 +36,7 @@ Furthermore it aims to improve analysis opportunities by encoding the number of
 5. Exactly one type section MAY be present.
 6. The type section, if present, MUST directly precede all code sections.
 7. The type section, if present, contains a sequence of pairs of bytes: first byte in a pair encodes number of inputs, and second byte encodes number of outputs of the code section with the same index. *Note:* This implies that there is a limit of 256 stack for the input and in the output.
-8. Therefore type section size MUST be `n * 2` bytes, where `n` is the number of code sections.
+8. Therefore, type section size MUST be `n * 2` bytes, where `n` is the number of code sections.
 9. First code section MUST have 0 inputs and 0 outputs.
 10. Type section MAY be omitted if only a single code.
 section is present. In that case it implicitly defines 0 inputs and 0 outputs for this code section.
@@ -66,7 +66,7 @@ We introduce three new instructions:
 
 1. `CALLF` (`0xb0`) - call a function
 2. `RETF` (`0xb1`) - return from a function
-2. `JUMPF` (`0xb2`) - jump to a function (without updating return stack)
+3. `JUMPF` (`0xb2`) - jump to a function (without updating return stack)
 
 If the code is legacy bytecode, any of these instructions results in an *exceptional halt*. (*Note: This means no change to behaviour.*)
 
@@ -88,17 +88,17 @@ If the code is valid EOF1, the following execution rules apply:
 6. Pops nothing and pushes nothing to data stack.
 7. Pushes to return stack an item:
 
-```
-(code_section_index = current_section_index, 
-offset = PC_post_instruction,
-stack_height = data_stack.height - types[code_section_index].inputs)
-```
-
-Under `PC_post_instruction` we mean the PC position after the entire immediate argument of `CALLF`. Data stack height is saved as it was before function inputs were pushed.
-
-*Note:* Code validation rules of [EIP-3670](./eip-3670.md) guarantee there is always an instruction following `CALLF` (since terminating instruction is required to be final one in the section), therefore `PC_post_instruction` always points to an instruction inside section bounds.
-
-7. Sets `current_section_index` to `code_section_index` and `PC` to `0`, and execution continues in the called section.
+   ```
+   (code_section_index = current_section_index, 
+   offset = PC_post_instruction,
+   stack_height = data_stack.height - types[code_section_index].inputs)
+   ```
+   
+   Under `PC_post_instruction` we mean the PC position after the entire immediate argument of `CALLF`. Data stack height is saved as it was before function inputs were pushed.
+   
+   *Note:* Code validation rules of [EIP-3670](./eip-3670.md) guarantee there is always an instruction following `CALLF` (since terminating instruction is required to be final one in the section), therefore `PC_post_instruction` always points to an instruction inside section bounds.
+   
+8. Sets `current_section_index` to `code_section_index` and `PC` to `0`, and execution continues in the called section.
 
 #### `JUMPF`