Blob storage module

[citizen-stig]

Description

This PR introduces a new module "sov-blob-storage" for storing Data Access (DA) layer blobs within the Rollup state. The addition of this module serves as a prerequisite for sequencing with soft confirmations. The default state transition function (STF) will utilize this module to manage deferred blocks.

The module consists of two key methods:

    pub fn store_blobs<B: BlobTransactionTrait>(
        &self,
        block_number: u64,
        blobs: &[B],
        working_set: &mut WorkingSet<C::Storage>,
    ) -> anyhow::Result<()>
    
    pub fn take_blobs_for_block_number<B: BlobTransactionTrait>(
        &self,
        block_number: u64,
        working_set: &mut WorkingSet<C::Storage>,
    ) -> Vec<B>

The State Transition Function (STF) now has the flexibility to decide which blobs to execute and when.

Consider a situation where the STF receives a blob from the preferred sequencer in block 100. It can use the store_blob function to hold onto deferred blobs, and later retrieve these blobs at the next block or after several blocks.

Points to Consider

This PR mainly focuses on the public API for this module. The current implementation is straightforward and does not contain much business logic.

One key consideration is the "defer period", which refers to the number of blocks for which blobs will be deferred. Currently, this value is hard-coded in the STF, but should it be stored in the state instead?

Also, how strict should this module be? Should it limit the number of blobs that can be stored or track the total size of stored blobs? Should it permit the insertion of blobs out of order?

Linked Issues

• Related to Based Sequencing with Soft Confirmations #408

Testing

Integration tests have been added

Docs

#![deny(missing_docs)]

[preston-evans98]

It seems like there's some potential for type confusion here - is the stored blob a serialized BlobTransaction, or is it just the blob data? Maybe it would be more natural to change from storing a blob as a raw Vec<u8> to storing it as a concrete StoredBlob type which contains the data (probably as a Vec<u8>) and the sender?

[citizen-stig]

It seems like there's some potential for type confusion here - is the stored blob a serialized BlobTransaction, or is it just the blob data? Maybe it would be more natural to change from storing a blob as a raw Vec<u8> to storing it as a concrete StoredBlob type which contains the data (probably as a Vec<u8>) and the sender?

Yes, I've done via introducing BlobTransactionTrait generic, so STF can just pass it without thinking twice.

[preston-evans98]

Looks great, thanks for addressing the comments @citizen-stig!