4844 batch posting support #2095
Conversation
cla-bot
bot
added
the
s
| To: to, | ||
| Value: value256, | ||
| Data: calldata, | ||
| Sidecar: &types.BlobTxSidecar{ |
There was a problem hiding this comment.
Much nicer how they have the sidecar as part of the BlobTx struct now.
| } | ||
| var use4844 bool | ||
| config := b.config() | ||
| if config.Post4844Blobs && latestHeader.ExcessBlobGas != nil && latestHeader.BlobGasUsed != nil { |
There was a problem hiding this comment.
TODO: just in case make sure that latestHeader isn't an Arbitrum header
| MaxSize: 100000, | ||
| MaxSize: 100000, | ||
| // TODO: is 1000 bytes an appropriate margin for error vs blob space efficiency? | ||
| Max4844BatchSize: (254 * params.BlobTxFieldElementsPerBlob / 8 * (params.MaxBlobGasPerBlock / params.BlobTxBlobGasPerBlob)) - 1000, |
There was a problem hiding this comment.
Is there some way a batch that is (254 * params.BlobTxFieldElementsPerBlob / 8 * (params.MaxBlobGasPerBlock / params.BlobTxBlobGasPerBlob)) could expand to be bigger than (256 * params.BlobTxFieldElementsPerBlob / 8 * (params.MaxBlobGasPerBlock / params.BlobTxBlobGasPerBlob)) bytes when encoded as field elements? In any case it's probably worth being cautious about at the beginning.
There was a problem hiding this comment.
No, this math is based on us being able to pack 254 bits into every field element guaranteed. The 1000 byte margin of error is for compression and that we might exceed the max size we're aiming for (I'm unsure if this is still possible or it was a bug that we already fixed).
Points into #2093
Replace by fee support in this PR isn't very good, but we can fix that after we have a working MVP.