# Block Archival ## ERA There's already a client using their own format for archiving blocks: [ERA format](https://github.com/status-im/nimbus-eth2/blob/613f4a9a50c9c4bd8568844eaffb3ac15d067e56/docs/e2store.md#era-files) This archive mechanism is fixed slot length, which means a limited number of files, and also stores the initial state of the archive, which allows for replaying blocks from part way through the progression of the chain, without needing to replay blocks from genesis. This is neat, but ultimately means storing a lot of state data, which is getting quite large. ## SSZ Could simply store block_slot.ssz - Allows simply grabbing a block at a given slot, - Could potentially be organised to differentiate canonical/non canonical slots via naming. - results in large numbers of files, even if stored in folders to organise. ## SSZ + TAR Could store ssz files inside tar archives. For example, an archive may be for a month of time (based on UTC probably for simplicity) It could contain an index file to simplify finding slot->block root ``` 2020-12/01/1.ssz 2020-12/01/2.ssz 2020-12/02/7201.ssz 2020-12/roots.txt 2020-12/non-canonical 2020-12/non-canonical/01/3.ssz 2020-12/non-canonical/02/7202.ssz 2020-12/non-canonical/roots.txt ``` This could then potentialy be delivered as a `2022-12.tar`, and could include non-canonical separately or not at all, but it would scale to allow either solution. Separating by the day of the month, should be no more than 7200 blocks per folder. The roots.txt file could be top level and have up to about 220k block roots listed ``` bacd20f09da907734434f052bd4c9503aa16bab1960e89ea20610d08d064481c:01/1.ssz 2757f6fd8590925cd000a86a3e543f98a93eae23781783a33e34504729a8ad0c:01/2.ssz a914215cfb24fc299b5257a4f6e0a7f96aedfa3f7bea8c4b974566b58fbd10e4:02/7201.ssz ``` Also, knowing slot time, can easily work to the folder structure containing the ssz of the block... - slot 7201 was 2020-02-02: 12:00:35am UTC, so will be in december-2020, 02 folder By root is less trivial, needing to index or search the roots files to locate blocks if requested by root. Non-canonical block storage is not strictly required and could be not distributed, or distributed separately fairly easily. Root files could be rolled up fairly easily into a larger file, as long as year-month as prepended to filenames... Files would need to be verified on initial load, which would be possible via the signature that is built into the signed beacon block.