# Index Based EOF Container

## Objective

Reformulate the EOF container to provide efficient access without validation, to support features such as banning code introspection and non-validated execution.

## Specification

container := header, managed_body, unmanaged_body
header := magic, version, kind_container, container_end_index, kind_code, num_code_sections, code_index+, kind_data, data_index, terminator
managed_body := types_section, code_section+, data_section
types_section := (inputs, outputs, max_stack_height)+

The types kind is removed with a container kind, where the

### Header
| name | length | value | description |
|-|-|-|-|
| magic | 2 bytes | 0xEF00 | EOF prefix |
| version | 1 byte | 0x01 | EOF version |
| kind_container | 1 byte | 0x01 | kind marker for container size section |
| container_end_index | 2 bytes | 0x00??-0xC000 | 16-bit unsigned big-endian integer denoting the length of managed container. Currently constrained by EIP-3680 |
| kind_code | 1 byte | 0x02 | kind marker for code size section |
| num_code_sections | 2 bytes | 0x0001-0xFFFF | 16-bit unsigned big-endian integer denoting the number of the code sections |
| code_index | 2 bytes | 0x0001-0xFFFF | 16-bit unsigned big-endian integer denoting the length of the code section content |
| kind_data | 1 byte | 0x03 | kind marker for data size section |
| data_index| 2 bytes | 0x0000-0xFFFF | 16-bit unsigned big-endian integer denoting the length of the data section content inside teh manager portion of the container |
| terminator | 1 byte | 0x00 | marks the end of the header |

### Body

| name | length | value | description |
|-|-|-|-|
| types_section | variable | n/a | stores code section metadata |
| inputs | 1 byte | 0x00-0x7F | number of stack elements the code section consumes |
| outputs | 1 byte | 0x00-0x7F | number of stack elements the code section returns |
| max_stack_height | 2 bytes | 0x0000-0x03FF | maximum number of elements ever placed onto the stack by the code section |
| code_section | variable | n/a | arbitrary sequence of bytes |
| data_section | variable | n/a | arbitrary sequence of bytes |
| uncontained data | variable | n/a | arbitrary sequence of bytes following `container_end_index` |

### Container Validation
The following validity constraints are placed on the container format:

* minimum valid header size is `15` bytes
* version must be `0x01`
* the number of code sections must not exceed `1024`
* the number of type sections is the same as the number of code sections
* the first `code_index` must be `13 + 10*num_code_sections`
* each subsequent `code_index` must be greater than the prior
* `data_index` must be greater than the last `code_index`
* `container_end_index` must be greater than or equal to `data_index`
* There may be extra data after the `container_end_index`

### Notes on interactions

* Bytes less than the `container_end_index` are the "managed" container. Bytes past the managed container are "unmanaged data".
* The intent of data in the managed section is to be constants and data used by the code that need to be constant.
* The data outside the managed section is appropriate for constructor parameters.
* The contract should expect that the data outside the managed section will not be stable across deployments.
* Any `[EXT]CODECOPY` must start no earlier than the `data_index`.
* `[EXT]CODECOPY` may cross the "container boundary," where the offset is less than the `container_end_locaiton` and size is greater than the number of bytes remaining in the managed container.
* This setup would provide an effieicnt means to implement the first alternative in the ["ban code intrpspection"](https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113) proposal.
* If allowed code and initcode size are increased beyond 64 KiB then alternate type headers can be introduced for 32-bit index values (0x81, 0x82, and 0x83) without disrupting the intent of the format.