Improving Data Availability with Projective Rollups
In this article we’re going to introduce a new layer 2 concept in a class of rollups called projective rollups. We’ll look at the benefits this new class of rollups offers and why this solution is needed. We’ll also discuss how this technology relates to existing layer 2 and sidechain technology and how it can be implemented into existing and future iterations of these solutions.
Note: Projective rollups were first described in this video by Sebastien Guillemot, CTO and Co-founder of dcSpark. This post is based on that video.
What are Projective Rollups?
Projective rollups are a new class currently being researched and developed at dcSpark. They are not a new type of rollup; instead, projective rollups are a new class or “family” of rollups that allow developers to easily project a state from the Layer 1 to the Layer 2 (and partially extendable to sidechain even though they are not L2s). Such data projection is currently difficult -at times impossible- to do.
We believe that projective rollups are the next natural step in the development of layer 2 solutions, allowing layer 2s to add to the ecosystem they’re a part of instead of fracturing it, which is what they currently do.
Why is Data Projectivity Important?
Each blockchain has its own architecture, consensus mechanism, execution environment, and other unique elements that enable it to function. But these also restrict what can be done on that blockchain. In order to extend blockchain protocols, advance them, and give them new functionality, new technology has been developed. The first of these developments were sidechains, and these were quickly followed by rollups — on which extensive and exciting R&D is ongoing!
As these solutions were implemented across the blockchain space, we saw expanded functionality -like when Milkomeda C1 brought EVM functionality and Solidity smart contracts to the Cardano ecosystem- along with significant improvements in both the user and developer experience. But, as individual blockchain ecosystems became distributed across these new layer 2s there was a fracturing of application state and a resulting reduction in the composability of that data. In some instances, such as oracles, fracturing state also leads to lower security as data providers are fractured between L2s and the L1. This fracturing of state by the propagation of layer 2 technology led to the ideation and development of projective rollups.
The Oracle Example
Data is a necessity for applications running on top of blockchains, and off-chain data, supplied by oracles, is crucial for the correct functioning of many elements of the blockchain ecosystem. This is particularly visible in DeFi, where protocols rely on oracles to supply reliable, up-to-date data points from off-chain sources. Without this off-chain data provided by oracles, many current and future uses of blockchain technology would not be possible.
Building a trustworthy and robust oracle system requires a huge feat of engineering, and a large enough set of trusted actors to maintain this data availability system. The importance and value-add that oracles have in the ecosystem can further be underscored by the large number of attacks we’ve seen trying to manipulate or undermine oracles to draw a profit in a malicious way.
So, blockchain ecosystems require oracles with the highest possible level of security and assurance. However, when you distribute an ecosystem across numerous layer 2s and sidechains, an instance of the oracle service needs to be implemented, from scratch, on each of these ecosystem fragments, as well as on the layer 1, so everyone can access the data. This essentially divides the oracle’s security budget -and, potentially, their validator set- between each of these instances. Reducing that budget’s overall effectiveness at protecting each of their services, and therefore protecting their users, from exploitation by attackers.
Projective rollups introduce the ability to project data from the layer 1 to these layer 2s, meaning that oracles will only need to deploy one instance of their oracle to the layer 1, a.k.a. mainchain, and then project that data to all the layer 2s. This allows the oracle provider to focus their whole security budget on building a robust and secure, single instance of their oracle that the entire ecosystem can then rely on.
Oracles are our example here, but projective rollup technology can be used with almost any piece of on-chain data. Next, we’ll look at the existing world of sidechains and rollups and how, and even if, we can implement projective rollup technology on each of these solutions.
Sidechains, Rollups, and Projective Rollups
Sidechains and the different forms of rollups currently deployed in the blockchain world can be put on a spectrum where we have solutions with high developer flexibility but, typically, lower security at one end, and we have higher security solutions with a much lower level of developer flexibility at the other end.
The above solutions are each described below, along with links to examples, before we also explain how it is possible to project data onto each of them. Each solution is different and brings with it its own challenges for building data projection capabilities, and implementing a data projection solution gets progressively harder as we move along the scale from left to right.
Sidechains
Examples: Milkomeda C1 — Polygon
Description: A sidechain is a separate blockchain that is philosophically aligned with the mainchain, extends it, but doesn’t inherit the security of that mainchain. Instead of building their own independent ecosystem, the builders of a sidechain want to stay connected to and aligned with the ethos of the mainchain and their ecosystem while giving themselves greater flexibility, e.g. a new consensus model, different smart contracting languages, different block times, etc.
Data Projection: Data projection is the most simple for sidechains. The preferred method would be to implement an enshrined messaging protocol into the bridge that connects the sidechain to the mainchain. The validators are then not only passing transactions but also messages containing data.
We will soon be releasing Wrapped Smart Contracts for Milkomeda, which make use of an enshrined messaging protocol and allow users to call and execute sidechain smart contracts from the mainchain and vice-versa. This will give the Milkomeda C1 sidechain data projection capabilities as states can be passed from mainchain smart contacts to the sidechain through this protocol, allowing DApps on the sidechain to source oracle data and more directly from Cardano.
Sovereign Rollups
Examples: Celestia — Paima Engine (by Paima Studios)
Description: Sovereign rollups, are rollups that post their data to the layer 1 as raw data, i.e. not through a smart contract. Transactions are secured by the rollup’s nodes and, as a result, sovereign rollups don’t require a proof system on the layer 1 like their more secure optimistic and zero-knowledge cousins do. It is easy to move assets to a sovereign rollup, but difficult to transfer them back from the rollup to the layer 1 as there is no canonical way to do so.
Data Projection: Unlike optimistic and zk rollups, sovereign rollup do not project their state back onto the layer 1, meaning that, like with sidechains, they only need to worry about receiving the data from the layer 1 and not about making it backward compatible for validation purposes — ultimately meaning that data projection for sovereign rollups is relatively simple. Paima Engine takes full advantage of this quality of sovereign rollups, and the team at Paima Studios is already utilizing data projection techniques.
Optimistic Rollups
Examples: Milkomeda A1 — Optimism — Arbitrum
Description: Optimistic rollups post their transaction data on the layer 1 in batches, and this data is assumed to be correct by the users of the rollup (it is this assumption that data is correct that give optimistic rollups their name). Once a batch of transaction data has been posted to the layer 1 there is a set window of time where anyone can dispute the authenticity of that data. If someone disputes the batch’s authenticity a fraud proof system is run on the layer 1 to validate the transactions in that batch.
If no one disputes the batch’s authenticity during the allotted time frame then the transactions are considered confirmed by the mainchain. Optimistic rollups can be used to bring different programming languages and VMs to an ecosystem — like Milkomeda A1 does, delivering Ethereum Virtual Machine functionality and Solidity to Algorand. These rollups are currently more popular than the more secure zk rollups as the fraud proof systems used are easier to write than a full zk system.
Data Projection: Optimistic rollups can support projective rollup technology. However, it is difficult because previous data projections need to be made available for the fraud proof systems used to validate the rollup data during a dispute. Currently, these fraud proof systems only have access to the current state of the layer 1, not the historic state, meaning they can’t check previous layer 1 states and confirm the projected data.
Some complicated techniques can be employed to enhance a fraud proof system and allow it to access this historic state, but this is not easily doable with Ethereum in its current form. As core contributors to Milkomeda, dcSpark is currently in talks with the core developers at Algorand about what changes might be needed to Algorand to allow for the use of projective rollup technology for optimistic rollup systems, like Milkomeda A1, on Algorand.
Zk Rollups
Examples: zkSync
Description: Zk rollups rely on zero knowledge (zk) proofs to secure their transactions and are designed using zk systems. To update a zk rollup a summary of the changes to the rollup’s state are published to the layer 1, along with a cryptographic validity proof that proves the correctness of those changes. Once the layer 1 smart contract has accepted the validity proof then the transactions are considered confirmed.
This technique allows you to add new VMs on top of the layer 1, but it has very limited flexibility as the VM’s code needs to be compatible with zk circuits, specific elliptical curves, specific arithmetic, and other constraints derived from the blockchain the rollup is built on top of.
Data Projection: It is not feasible to add data projection functionality to zk rollups built on chains, like Ethereum, that are not built on zk technology. This is because the rollup needs to be able to prove the data that has been projected onto it, and Ethereum and other non-zk-based chains cannot compress their own state into the zk proof that the rollup needs to do this.
If you are using zk rollups on a zk-based chain then recursive snarks can be used to make this proof available to the rollup. For example, Mina, a zk-based, layer 1 blockchain that does support recursive snarks, allows you to create constant proofs of the state of the Mina layer 1 and transfer these proofs around; meaning that blockchains like Mina can support projective zk rollups.
Developing Projective Rollup Technology at dcSpark!
Projective rollups are at the cutting edge of layer 2 development, and the utility and possibilities this technology can offer to layer 2s across the blockchain ecosystem are very exciting! The team here at dcSpark, along with our partners at Paima Studios, have been working hard to develop the techniques explained above and implement projective rollup techniques into multiple sidechain and layer 2 solutions.
This is an inspiring time as we don’t believe that the above methods are the only ways data can be projected from a layer 1 to a layer 2. We are actively exploring new cryptographic techniques that can enable different security modes from layer 2s and different methods of data projection.
If you want to learn more about our developments in this area, or if you have any questions on this topic, please don’t hesitate to reach out to us on Twitter or join our developer Discord to get in touch and join the conversation!
Follow dcSpark:
Website: dcspark.io
Twitter: @dcspark_io
Discord: /dcSpark
Medium: /dcSpark
GitHub: /dcSpark
