# Proto-Danksharding

Introducing a novel transaction format designated for 'blob-carrying transactions.' These transactions house substantial data quantities that remain inaccessible to EVM execution, yet their commitments remain accessible. This format is meticulously designed to seamlessly align with the anticipated structure employed in comprehensive sharding.

***

### **How works?**

Instead of incorporating rollup block data within transaction calldata, rollups would shift the responsibility to rollup block submitters to encapsulate the data within 'blobs.' This approach ensures data availability, a prerequisite for rollups, while being significantly more cost-effective than calldata. The central requirement for rollups is that data should be accessible temporarily to enable honest actors to construct the rollup state, without necessitating indefinite retention.

In the context of optimistic rollups, actual provision of underlying data becomes mandatory only during the submission of fraud proofs. These proofs scrutinize the transition through incremental steps, loading a limited number of blob values at a time via calldata. For each value, a KZG proof is furnished, and the point evaluation precompile is leveraged to validate the value against the versioned hash submitted earlier. Subsequently, the fraud proof verification is conducted on this data as per the existing practices.

For ZK rollups, two commitments are provided for their transaction or state delta data: the blob commitment (validated by the protocol to link to available data) and the ZK rollup's native commitment using its internal proof system. A proof of equivalence protocol, employing the point evaluation precompile, substantiates that the two commitments pertain to identical data.

Lifetime of a blob transaction:

<figure><img src="https://329848969-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiCuit7g63wokaA1ep6ST%2Fuploads%2FGI31DaYhVmTGGnxn1llv%2FScreen%20Shot%202023-08-28%20at%2013.54.23.png?alt=media&#x26;token=11b91b45-aaea-4cc0-a94f-80c3d9239eee" alt=""><figcaption></figcaption></figure>

***
