feat: support blob storage & miscs;

[galaio]

Description

The PR mainly implements blob storage for BSC blobtx feature. It uses KVDB & freezerDB to support blob CRUD, and implement blob expiry, and block DA verification.

Rationale

We can use --override.cancun to enable cancun fork.

Changes

Notable changes:

• blob: support config blob extra reserve;
• rawdb: support to CRUD blobs;
• freezer: support to freeze block blobs;
• chainconfig: use cancun fork for BSC;
• feat: fill WithdrawalsHash when BSC enable cancun fork;
  ...

[emailtovamos]

Wouldn't this function also require modification to consider and save sidecars?
func (bc *BlockChain) WriteBlockAndSetHead(block *types.Block, receipts []*types.Receipt, logs []*types.Log, state *state.StateDB, emitHeadEvent bool) (status WriteStatus, err error)

[galaio]

Wouldn't this function also require modification to consider and save sidecars? func (bc *BlockChain) WriteBlockAndSetHead(block *types.Block, receipts []*types.Receipt, logs []*types.Log, state *state.StateDB, emitHeadEvent bool) (status WriteStatus, err error)

Yes, I will leave some TODO for it. This pr is aim to create the basic CRUD for blobs, we can fix them later.

[zzzckck]

seems like, we don't need the if readonly check, can simply call:
f, err := newTable(datadir, name, readMeter, writeMeter, sizeGauge, maxTableSize, disableSnappy, false) ?

[galaio]

There is an error for opening new table in read-only mode, the code takes a trick to open as write mode and close first, and open as read-only later.

[emailtovamos]

Are we going to save empty blobs as well?

[galaio]

Yes, empty blobs means not blobs, same as empty transactions or receipts.

[emailtovamos]

Weren't sidecars supposed to be together with block only for propagation purposes? Why it got added inside the block itself?

[galaio]

The block struct may be a good glue struct, we can set blobs into it, and transfer them to the related component. There are other extra fields in here to record metadata.

We also need another extra blob with the block for p2p messages.

[emailtovamos]

Just wondering if there's any process that is done with blocks passing apart from broadcasting. If there is any such process then it will slow down the work due to block becoming very heavy due to blobs.

We also need another extra blob with the block for p2p messages.

If we are including sidecar inside block definition itself then we won't need to make any changes for the p2p messages and the current mechanism only will need to check for Cancun or not and act accordingly.

[galaio]

Ok, we can discuss more about the definition. The block could transfer to InsertChain, IsDataAvailbility for checking block and blob, block is a glue struct, it contains header, block body, blobs, and other metadata. So we can remove receovedBlobCache too.

Block is passed by pointer, so it will cost little in most scenarios. It is only be used in NewBlockMsg, but only header, body will be encoded.

func (b *Block) EncodeRLP(w io.Writer) error {
	return rlp.Encode(w, &extblock{
		Header:      b.header,
		Txs:         b.transactions,
		Uncles:      b.uncles,
		Withdrawals: b.withdrawals,
	})
}

[emailtovamos]

It is only be used in NewBlockMsg, but only header, body will be encoded.

If we encode the sidecars as well then we may not even need to modify BlockWithExtraData and have this definition of block everywhere except when it comes to storing. As storing of sidecars and blocks will be separate. What do you think?

[galaio]

Yes, it's a good idea.