Explain how blobs are used for Rollups

Historically, rollups post compressed batches of transactions to the L1 which can be verified because all the data is stored in calldata.

However, as ofEIP-4844 which was included in the Dencun upgrade to the Ethereum network (~March 2024), added a new transaction type (type 3) which enabled "blobs" or "Binary Large OBjects".

Now, rollups take advantage of this by posting most of their L2 compressed batch of transactions in a blob (like this sample zksync transaction)

However, according to the EIP:

“blob-carrying transactions” which contain a large amount of data that cannot be accessed by EVM execution, but whose commitment can be accessed.

The data of the blob cannot be accessed by the EVM, which begs the questions:

How can blobs be programmatically used to verify the rollup from a zk or optimistic rollup?

We can look at the sample zksync transaction here and start putting the pieces together.

https://ethereum.stackexchange.com/questions/163066/how-is-rollup-data-verified-with-blobs

Start with EIP-4844, the linked sample zkSync transaction, and the referenced Ethereum StackExchange question. Trace how blob commitments and transaction data relate to rollup verification for both zk and optimistic rollups. Done means the documentation clearly explains the programmatic verification path and the EVM's limits on blob access.