The Proto-Danksharding (a.k.a.EIP4844) proposed for rollup centricity brings a new paradigm to rollups.
From the beginning of 2021, we have been researching distributed systems with storage areas that will be erased after a certain period of time and the most efficient zkRollup under these conditions. This was also included in the scalability proposal for the Brave browser’s THEMIS protocol, which we joined. Although we had planned to develop our own Data Availability Layer with such storage areas, EIP4844 was proposed in 2022. With this, we were able to spend a year and a half developing the most powerful algorithm under proto-danksharding conditions.
Proto-danksharding supports very inexpensive and secure storage areas (called blobs) that are only stored for a certain period of time. These conditions enable the following, which are still largely undiscussed in the zkRollup community:
- Accumulating “state delta” over a long period of time.
- Passing data directly to users if they are online. If not online, the retrievable data is stored in an inexpensive area for a period of time.
“State delta” is a method of rebuilding Layer 2 databases to guarantee the safety of the user’s assets by writing all the final changes to the database itself, unlike zkRollup’s original proposal where all the historical transaction data is stored on L1. This is not possible with Optimistic Rollup, which requires that transactions can actually be executed even in L1, but it is possible with zkRollup.
For example, let’s say that you and I have 1 ETH round-trip for 10000 transfers, which needs 20,000 transaction data to be stored. If we use state delta, the difference (delta) is zero, so the writing will be zero, and the gas cost of storing this data will also be zero. Using state delta is more efficient because only the final difference is written, so the longer the period between one writing and the next (i.e. the longer the finality period), the more efficient. A radical solution to this problem was proposed by the co-founder of Intmax as “preconsensus mechanism” in February 2021.
In addition, in order to make state delta more efficient, we have invented a method to distribute the data difference of individual accounts (EOA), which account for a large part of state delta, directly online to users, so that they can safely exit their assets to L1 on their own at any time. The same methodology used in Plasma Cash and Plasma Prime is used, thus Intmax can be described as a zkRollup + Plasma hybrid. This makes it massively efficient because only frequently shared and used smart contract (CA) data remains in state delta, while many changes were duplicated in state delta and only their final data is written. However, the edge case remains when a user is not online and does not receive the data difference or is not provided proof of receipt. This can be solved at no cost by a new method where zkRollup’s operator is forced by ZKP circuit to write the user’s state delta data to a proto-danksharding blob for a certain period of time. We call this technique zkRollup with limited online assumption.
Further optimizations follow. It turns out that even commonly shared storage — the smart contract (CA) data above — can also be removed from L1. The solution is Liveness/Safety Separation. Users have already been given what they need to move their assets to L1. Even if the availability of the data in the contract is lost (which is unlikely to happen), the risk is limited to only the inability to update the state of the dapps using the contract, and the user’s assets can be safely moved to L1. The user’s assets can be safely withdrawn to L1. Originally, Liveness and Safety were not separable in L1. This is because if L1 stops, the asset cannot be moved, effectively resulting in the loss of the asset. However, in Layer 2, the Exit of the asset can be made possible by using the Liveness of L1, allowing the Safety to be separated.
This allows the Contract (CA) assets to be removed from state diff except for data such as balances and the list of transactor IDs necessary to Exit to L1, and the remaining part of the asset can benefit from the lengthening of finality by the preconsensus mechanism, resulting in strong efficiency. It is actually possible for stopped dapps to restart with Exited assets or assets remaining on L2.
The idea of the zkRollup with limited online assumption and Liveness/Safety Separation was presented by the co-founder of Intmax in October 2021 but understanding was limited at the time and the company decided to focus its efforts on development. Now with Intmax zkRollup, the core concept has been implemented as an MVP, and NFTs can be run with almost zero gas.
When we combine those components (Preconsensus mechanism, state delta, zkRollup with limited online assumption, and Liveness/Safety Separation), we can achieve almost zero gas cost on zkRollup. Not only is the data storage paid for, but even the zkp verification cost is almost reduced by the preconsensus mechanism. This transforms Ethereum into a true modular-type network with an almost unlimited number of parallelisms without on-chain costs, which is a completely new paradigm.
The disadvantage is only the complexity of system development due to these combinations, which falls only on the development side. Of course, this can be combined with zkEVM.
The ultimate purpose
So, what are some use cases of this powerful zkRollup solution? We are seeing great adoptions on Dapps, DeFi, and NFTs, which started from Ethereum. Intmax will of course be used for scaling these, and we consider it our mission to help Ethereum’s many dapps, but the ultimate goal is beyond that. It is to make this zkRollup as usable as a regular cloud platform, and the existence of a governable backend with the same security as Ethereum will allow the ownership and governance rights of regular web applications, not just crypto, to be crypto-nized and made into governance tokens and NFTs. It makes available to the owners and users of all web-connected systems the powerful financial capabilities of crypto and direct governance through digital signatures, which until now have been concentrated in the hands of crypto developers. The system can be built to be inclusive of regions that have been behind in many financial matters due to the lack of financial infrastructure and financial inclusion issues. It is the goal of Intmax, Internet Maximalism, to financialize the web, rather than bringing the web to finance.
Special optimization is possible for backend use of zkRollup’s normal web application (Web2 type). See Q3 in the following Q&A.
Reference: Intmax Whitepaper
Q&A
Q1: Intmax zkRollup eliminates most data costs. How is it different from Validium?
A: Intmax is completely different from Validium. In Validium, the worst-case Data Availability Attack results in a total freeze of user assets; in Intmax zkRollup, the damage is only a partial service outage; meaning that the damage is a partial loss of Liveness, and all user assets can be safely Exit to L1.
Q2: How is this different from Adamantium, which saves gas when users are online?
A: With Adamantium, only the Power User gets full trust and safety, whereas on Intmax zkRollup, all users are safe. Also, Adamantium does not have Liveness/Safety Serapation, so its efficiency is limited when smart contract data changes frequently. Also, Adamantium does not clearly describe Exit security. If the security of Exit to L1 is the same as that of a normal zkRollup, it would be very different from Intmax’s architecture.
Q3: It seems inefficient to use zkRollup as a cloud. What about the front end?
A: As for database changes, those involving all users would be better recorded by zkRollup. For individual users, changes can be made by zkRollup and by state channel. Very importantly, the state channel can use the same format of Intmax zkRollup’s user-side data (User Asset Storage) and does not require any new system complexity.
Much of the burden of the cloud is web page hosting. And for dynamic web page hosting, there is a special scheme called Verifiable BackEnd (VBE).
Detail: https://hackmd.io/ZTImRSapRH-zADmY7cNJVA?view#5-Verifiable-web-application-hosting
The core of this VBE architecture is that if the client side and the back end share the same VM that builds the front end, they can output the same front end as long as the input and execution code are the same.
In other words, if you can pass the execution code and the Merkle proof of the input data, you can do client-side validation. Of course, this takes a bit of time, so it is possible to improve efficiency by speculative execution, building the front end first and sending the proof data for validation later. The database can use a zkRollup database, which is why the ownership can have direct governance over the system.
The above allows Verifiable BackEnd to run at the same level of cost and performance as a regular cloud platform.
Come join us!
If you have any questions, please reach out to us on Discord and Twitter.
