• Main rollup costs is CALLDATA cost on Ethereum

Proto Danksharding - EIP 4844

• Move from calldata to blobs (125 Kb) which are cheaper

• Main feature of proto danksharding is blob-carrying transaction

• Blobs are not interpreted directly by Ethereum so they are mainly for L2s. EVM can only view commitment to a blob.

• Blobs are attached to blocks

• How it works?

  • Rollups post the transactions they execute in data blobs. Every Block has 1 Blob associated.
  • Blobs of data are held in the consensus client at the node level
  • Consensus clients attest that they have seen the data and that it has been propagated around the network
  • If this data was kept forever, it would bloat the consensus clients and lead to large hardware requirements for running nodes
  • Instead, the data is automatically pruned from the node every 1-3 months
  • Storing rollup data long term becomes the responsibility of the people that need it, such as rollup operators, exchanges, indexing services etc

• How is blob data verified?

  • The blob of data submitted by a rollup provider has to be verified to ensure the rollup is not misbehaving. This is done through ZKP
  • Rollups uses KZG commitment scheme to reduce the blob of data submitted to a small cryptographic commitment and posts this commitment.
  • This commitment is the result of evaluating a polynomial fit to the data at certain points. These points are defined by the random numbers generated in a KZG ceremony. Provers can then evaluate the polynomial at the same points in order to verify the data - if they arrive at the same values then the data is correct.
  • The commitment evaluates the polynomial at some secret data points. A prover would fit the same polynomial over the data and evaluate it at the same values, checking that the result is the same.
  • This is conceptually the same as the way execution clients check the validity of Ethereum transactions on layer 1 using Merkle proofs.
  • Technical - new pre- compiles

Full Danksharding

• Danksharding turns Ethereum into a unified settlement and data availability layer.
• Danksharding uses distributed data sampling across blobs to scale Ethereum.
• 1 Block will have 64 Blobs ()
• Changes to consensus clients to handle large blobs
• Requires Proposer - builder sepration
• Requires Data Availability Sampling (DAS) to be implemented
• Danksharding there is only one proposer that chooses all transactions and all data that go into that slot

Why PBS is needed for full danksharding?

• Without PBS, individual validators have to generate expensive commitments and proofs for 32MB of blob data, this would in turn require them to have more powerful hardware which hurts decentralisation.
• Outsource block building to specialised block builders and validator just chooses block which block is the most profitable (Same way it does now with out of protocol PBS and mev-boost)
• Anyone can verify the blobs cheaply and quickly, meaning any normal validator can check that the block builders are behaving honestly. If not, block builders can be penalised