# Pre-merge execution data archival

Post-merge, archived ethereum data is available from the beacon chain via era files, since the execution payload is included in the consensus block.

Pre-merge, execution data is currently available only from the p2p network, in commonly consumable format. This proposal creates an encoding similar to

## Underlying spec

The framing in this proposal is based on the same framing as era files:

https://github.com/status-im/nimbus-eth2/blob/unstable/docs/e2store.md

## CompressedExecutionBlock

type: [0x03, 0x00]
data: snappyFramed(RlpExecutionBlock)

CompressedExecuionBlock contains the snappy-compressed Execution block, as encoded in the devp2p specification for syncing an Ethereum client.

TODO investigate headers vs bodies situation in p2p spec, potentially split into 2 types

## CompressedReceipts

type: [0x04, 0x00]
data: snappyFramed(RlpReceipts)

## Accumulator

type: [0x05, 0x00]
data: Digest

The SSZ root of the block hashes of each block in the file, see https://github.com/ethereum/portal-network-specs/blob/master/history-network.md#the-header-accumulator

> TODO total difficulty, why is it in the accumulator

## BlockIndex

Same as slot index but no zero values - see era spec

# Dump files

`dump` files are special instances of e2s files that contain chunks of the pre-merge history of Ethereum.

Each dump is identified by when it ends. Thus, the genesis dump is dump 0, followed by dump 1 which ends when slot 8192 has been processed.

# Structure

An .era file is structured in the following way:

era := group+
group := Version | block_tuple* | other-entries* | Accumulator | block-index(block)
block_tuple :=  CompressedExecutionBlock | CompressedReceipts

The block entries of a group include all blocks leading up to the era transition in slot order. For example, the group representing era 1 contains blocks from slot 0 up to and including ...