TLDR
EIP-4844 introduces a "blobs" transaction type:
- Persisted in beacon-node, not in execution engine (e.g. prysm, not in geth)
- Blobs are
4096
field-elements of 32 bytes each
, max 16
per block. Max 4096 * 32 * 16 = 2 MiB
per block, targeted at 1 MiB
.
- Blobs are pruned after 2 weeks. Available long enough for all actors of a L2 to retrieve it, short enough to keep disk use manageable.
- Blobs are not required for EVM execution. I.e. sync is independent, pruning is trivial.
- Blobs are committed to with KZG: efficient vector commitment, fixed-size proof data, forward-compatible with data-availability-sampling.
- The EVM verifies blob data statelessly with new precompiles: regular calldata is used to present inputs and proofs.
- The EVM can run a ZK proof at the same time as posting the blob (does not require all blob data to go through EVM, just some commitment data)
- The execution-layer changes are forward compatible with the full dank-sharding design for even more data-availability.
Links
Ideas
- Testing:
- EL tests: 4844 blob tx processing tests
- Engine API tests: blob sidecar retrieval tests during block building
- CL tests: beacon SSZ type changes, processing changes
- Comparison and design docs: explore what's left to build to enable others to contribute more
- Spec: reach out to Proto or Ansgar if you need a start
- Tooling:
- More tools to create transactions
- A blob indexing service / site, like a block explorer
- It could just focus on blobs, and index them by blob datahash, KZG commitment, slot number, tx hash, execution block hash and beacon block root.
- Existing explorers can then just point to the blobs explorer site for any block, blob tx or blob sidecar to find the full blob data.
- Contribute to the Prysm, Geth, Lighthouse prototypes, or a new client like Besu.
- Prysm/Geth: reach out to Mofi, Mdehoog or Terence
- Lighthouse: reach out to Marius or Lighthouse team
- Besu: reach out to Abdel from Starkware (ex Besu)