Will Micro-Rollup be the next wave when applications become Rollup?

Will Micro-Rollup be the next wave as applications adopt Rollup?

Written by: KAUTUK, Stackr Developer Compiled by: Luffy, Foresight News

Starting a Rollup article with topics like “What is Rollup” or “Why do we need Rollup” is like killing Uncle Ben or shooting Wayne’s parents in every iteration of Spider-Man and Batman movies. If you’re reading this article, I assume you already have a basic understanding of the aforementioned questions. Here, we skip the debate between application chains and application Rollups and get straight to the point.

The rise of specific application RollupsGeneral Rollups are frustrating

General Rollups are like the Indian school system (I’m sure they share similar characteristics with other school systems, but I only have firsthand experience with it).

• Inventory of Common Scams in the Cryptocurrency Field
• LianGuai Morning News | G20 leaders will discuss advancing the proposed roadmap for cryptocurrency regulation in October.
• Artificial Intelligence and Work Automation

Athletes, singers, mathematicians, thinkers, and economists all have to go through the same process to get passing scores. This system is not “biased” towards specific groups, but it’s also not “fair” to everyone. But hey, we made friends! (This will be important later).

Similarly, for applications on general Rollups, the bottleneck is the runtime environment itself, as Rollup cannot meet the specific needs of each application individually. Each application may require different types of optimizations, and any customized improvements would be unreasonable for them. However, if you’re just experimenting and want to get a rough idea of something, this is the most convenient option. Additionally, for certain applications, like some regular students, this may be the right solution!

Specific application Rollups are confusing

Well, my child is too athletically inclined for public schools, he needs special training. Should I send him to a sports school or hire a private coach…

Rollups are difficult to categorize clearlyLet’s play a game

There are 8 specific application Rollups below. However, one project in each group doesn’t really belong to that group. Can you figure out which one it is?

Application specificity is becoming a perplexing term. There are some specific application Rollups that allow deploying contracts on top of them; there are also some specific application Rollups that can allow contract deployment because their virtual machine supports it, but with certain limitations; and there are some specific application Rollups that have closed virtual machines or no virtual machines at all and do not support other types of development.

Is it fair to classify them together?

Answers to the above exercise:

Group 1: Celo is a strange option because it allows other developers to build applications that other developers can directly use. Other projects that can be considered in Group 1 include Fuel-v1, Aevo, RhinoFi, etc.

Group 2: Loopring is a strange option because it is the only Rollup specifically built for direct use, while the others are optimized for specific functionalities such as privacy, NFT, and TPS, so that applications deployed on them can inherit these functionalities. Other projects that can be considered in Group 2 include Kinto, Kroma, Public Goods Network, etc.

Issues with deploying contracts in the modified general-purpose virtual machine

The virtual machines on which you deploy smart contracts are simply Turing complete state machines. The contracts you deploy on them are just modifications to the state itself and do not really affect the core state transition rules of the VM. Rollup is essentially a virtual machine and your business logic is built on top of it.

Your business logic is separate from the state transition function of Rollup.

I also refer to it as a “smart contract example for building applications” because you deploy some additional logic on top of the virtual machine. Rollup does not “directly” concern itself with the logic for proving applications. The VM is the Rollup, not your application.

Of course, you are the sole owner of the virtual machine and your application is the only citizen. You can continue to enhance the underlying foundation to make it more suitable for your application. You can continue to enhance the State Transition Function (STF) by adding/deleting opcodes to improve the performance of the application, but the application is still independent and subject to the limitations of the VM itself.

Just like a Lamborghini Urus pulling a Lamborghini Huracan

An individual application on a specific application Rollup can do better. What if you continue to enhance the STF, making the scope of the STF smaller and smaller to fit the business logic of your application? Eventually, as you continue to enhance, the STF will converge to the point where the business logic and STF overlap, and then you will realize…oh, wait!

The Birth of Micro-Rollup

Therefore, Micro-Rollup is simply a Rollup where the state transition function of the application is the business logic itself.

The application becomes the Rollup, and the state can be managed in any execution environment in any possible way, and the state transition rules can be directly applied in the runtime of the application. The application can be customized without any restrictions. The proof is related to your business logic, not the machine, making your application lightweight.

Micro-Rollup is not limited in terms of developer experience. You can use any tools you like to build them because they are not subject to virtual machine restrictions. They look like web2 backend applications, but they regularly publish transaction proofs to L1. I think this will be a major factor in influencing web2 developers to transition to the web3 field.

Actually, a better example is the Rimac Nevera because it is faster and electric, so it may be cheaper to operate.

The only downside of this approach is the custom proof mechanism for each different application. If the application logic can be compiled into a public intermediary, then proving the public intermediary can eliminate the pain of individually proving each application. But I personally think this is just a trade-off between efficiency and faster development.

There are some ways to solve this problem without using an execution layer involving a virtual machine. What if there is a tool that allows developers to do this?

This is the mission of Stackr Labs: we are building a Micro-Rollup framework and SDK so that anyone and everyone can build their applications without restrictions in any language they want, just like building backend applications for web2. Making Micro-Rollup development as simple as writing and deploying smart contracts, not to mention the ability to modularly increase the choice of any ecosystem for developers.

So is Micro-Rollup real?

It always has been, just like Rollup itself.

Applications like Loopring, dYdX, and Fuel-v1 have already emerged or have been around for a long time. These are highly optimized Rollups with custom logic specifically designed to serve their use cases. The first non-virtual machine specific application Rollup that I know of and have personally been involved in is Hubble Optimistic Rollup, a 3-year-old project that once served as the core infrastructure for the Worldcoin token.

Now it’s becoming increasingly important to differentiate these terms.

The use cases for Micro-Rollups are endless:

• Consumer products like games, exchanges, NFT markets, etc.

• Application chains can be transformed into application Rollups

• You can even build a new type of virtual machine that supports unique use cases, opening the door to virtual machine innovation

Conclusion

The element of a custom state machine is missing from the structure tree I showed earlier.

In addition, for individual applications, using a Rollup based on a VM or EVM to deploy a single protocol is not efficient. It is suitable for applications that already have a large number of smart contracts and run their protocols on EVM-like chains, but not for those who “want more applications” and want to get rid of VM restrictions.

So if we trim this tree, the final tree would look like this. This is also why I believe that in the near future, App-Rollup, Micro-Rollup, or RollApp will be called App.

Therefore, Micro Rollup = App on Rollup App as Rollup.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!