Storage backends

Byte storage sits behind a four-function interface, so an alternative implementation — a blob-optimised rollup, transient storage, an existing blob store — needs no change anywhere else:

interface IStorageBackend {
  function put(bytes calldata data) external returns (bytes32 hash);
  function get(bytes32 hash)        external view returns (bytes memory data);
  function has(bytes32 hash)        external view returns (bool);
  function maxChunkSize()           external view returns (uint256);
}

Everything is content-addressed by keccak256(data). ContentStore calls exactly these four and knows nothing about the medium.

The default: SSTORE2Backend

Every blob is deployed as a CREATE2 contract whose bytecode is the blob. Reads are EXTCODECOPY and therefore cheap; writes scale with blob size; duplicate writes are free, because CREATE2 to an occupied address no-ops.

maxChunkSize is a constructor immutable, not a protocol constant. The default is 24,575 — EIP-170's 24 KiB contract cap minus one byte for a leading STOP that prevents accidental execution.

A chain with a different code cap can pick a different value. File CIDs are unaffected: they are computed over chunk contents, not chunk boundaries, so two backends with different caps produce identical CIDs for the same input bytes.

Cancun is required

All sources target Solidity 0.8.24 / EVM Cancun. mcopy splices stored chunks into the readFile output buffer and slices memory in the IPFS resolver — both hot paths. On a pre-Cancun EVM, writes work and reads revert with OpcodeNotFound.

Porting to a pre-Cancun chain means swapping those mcopy blocks for word-by-word mload/mstore loops. They are localised, and neither the ABI nor CID semantics change.

Shapes worth considering

A backend only has to be content-addressed and deterministic. Everything above ContentStore is unchanged.