In collaboration with a lot of people. I'll reach out to see what you guys prefer for name / psuedonym if anyone wants to distribute this externally Overview A group of us got together during AW week (Aug 2023) to dream up insane interactions between worlds. It's a discussion that was inspired by a question that Ludens posed: what happens when you drive a car into a tennis court? Neither a racing game nor a tennis game would ever plan for this event, but given they share the same base layer, they could. Whatever happens during the interaction is insane and unexpected. We want that. Our discussion had two goals. First, we maxed out insanity. We wanted to come up with interactions between worlds that no one would anticipate. It was a massive free-for-all between all the games we've ever built or played. Second, we got pragmatic. We explored what the design process would actually look like to enable interactions like these. We had builders from 6 on-chain games / studios (Moving Castles, Sky Strife, Primodium, Words3, Network States, AutoRoad) at the table. This is a hastily prepared debrief of what we came up with.

Pun Wai, Lyron Co Ting Keh What are proto-danksharding blobs? Ethereum's rollups need data availability (DA) to remain permissionless. Many production rollups today ensure DA by storing transactions directly in Ethereum calldata. Doing so inherits the security of Ethereum. This, however, comes with the drawback of high costs. Rollups that use Ethereum for DA must compete with all other network activity for the same available space per block, thus driving up L2 transaction costs. Proto-danksharding (described in EIP-4844) is a soon-to-be upgrade that increases the data available in each Ethereum block from ~100KB to 1MB. More space means cheaper storage. Cheaper storage means cheaper DA. Cheaper DA means cheaper txs for users. How does proto-danksharding make this increase in block storage economically viable for nodes? Rather than storing data blobs in the execution layer, proto-danksharding has raw data stored temporarily in the consensus layer, with only the commitments stored in the execution layer. Raw blob data in the consensus layer can then be deleted after a small time window to avoid blowing up disk space requirements for nodes. Why is it useful to open blob commitments in-circuit?

Goal Prove batch multi-opens of KZG blobs described in EIP-4844. Motivation Data availability is a critical aspect to Ethereum's rollup-centric roadmap. Current production systems for storing rollup transactions make compromises in cost (when stored in calldata) or in trust (when stored off-chain). Danksharding, along with the intermediate upgrade of proto-danksharding, presents a promising solution. It is an approach for storing aribitrary blobs of data cheaply on the main Ethereum network. How? Rather than storing blobs directly in the calldata at the execution layer, proto-danksharding has raw data stored temporarily at the consensus layer, with only the commitments stored at the execution layer. These blob commitments are KZG vector commitments. To make use of them in the EVM, contracts must check the validity of batches of KZG openings. Given the lack of a BLS precompile on top of an already compute intensive procedure, this is only feasible on-chain when done within a SNARK.