feat: submit data via blobs OR calldata #7
Conversation
src/Zenith.sol
Outdated
| /// @param s - see _submitBlock. | ||
| /// @custom:reverts see _submitBlock. | ||
| /// @custom:emits see _submitBlock. | ||
| function submitBlock(BlockHeader memory header, bytes memory blockData, uint8 v, bytes32 r, bytes32 s) external { |
There was a problem hiding this comment.
should probablt make this bytes calldata otherwise it will get calldatacopy'd to memory and cost significant gas in memexpansion
There was a problem hiding this comment.
yeah i knowwwww, it's annoying, the reason i had it like this is because the shared _submitBlock function needs to have committedData as memory because bytes memory encodedHashes can't be calldata...
There was a problem hiding this comment.
but i think i can fix this, sec
There was a problem hiding this comment.
hmm yeah, actually no. i think as long as we're abi-encoding the blockData into the blockCommitment it's going to calldatacopy... 🤔
There was a problem hiding this comment.
okay, we could do this instead: 4aaca56
make Zenith agnostic to the submitted blockData. once we wean ourselves off emitting blockData (eg remove the BlockData event) the contracts will no longer calldatacopy the blockData :)
There was a problem hiding this comment.
this is also overall cleaner contract code, but it puts even more onus on the Node to gracefully discard any malformed, invalid or junk blockData. given that that has already been a dynamic between the Builders <> Node, this seems right to lean into.
let's align on & document the expected encoding for blockData that is considered valid by the node.
something like:
abi.encodePacked(0x01, packedBlobHashes) OR abi.encodePacked(0x02, rlpEncodedTransactions)
and some rules around how we handle missing blob hashes, invalid transactions, etc.
There was a problem hiding this comment.
per our discussion in DMs, we can also include a bytes32 blockDataHash in the function params which is also hashed in the Sequencer signature. Zenith still ignores the raw blockData, but the Node will reject the block if blockDataHash != keccak256(blockData)
this is reminding me: we need to think about how the block numbers of rollup blocks won't necessarily coincide with the sequence number on Zenith. because sequence numbers on Zenith can be consumed by invalid blocks.
There was a problem hiding this comment.
added here: 6c7f37d
There was a problem hiding this comment.
block numbers of rollup blocks
this should be the mainnet block number
anna-carroll
force-pushed
the
anna/multiplex
branch
from
de9c38e to
6c7f37d
Compare
Allow block data submission via 4844 blobs OR calldata