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

Will Micro-Rollup be the next wave for Rollup applications?

In the near future, App-Rollup, Micro-Rollup, or RollApp will all be referred to as App.

Written by: KAUTUK, Stackr Developer

Translated 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 are reading this article, I assume you already have a basic understanding of the aforementioned questions, so let’s skip the debate on application chains and application Rollups and get straight to the point.

• One of the biggest competitors of Maestro and Unibot, how does Banana Gun perform in terms of data?
• Synthetix Founder Reassessing Synthetix’s Multi-chain Vision and Liquidity Sharing
• Vitalik Buterin’s latest paper How Privacy Pool Protocol Protects User Privacy and Meets Regulatory Requirements.

The rise of specific application RollupsUniversal Rollup can be frustrating

Universal Rollup is like the school system in India (I am sure they have similar characteristics to other school systems, but I only have firsthand experience with it).

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

Similarly, for applications on a universal Rollup, the bottleneck is the runtime environment itself, as Rollup cannot individually meet the needs of each application. Each application may require different types of optimizations, and any customized improvements would be impractical for them. However, if you are just experimenting and want to get a rough idea about something, this is the most convenient choice. Moreover, for certain applications, like some ordinary students, this might be the right solution!

Specific application Rollups can be confusing

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

Rollup is difficult to categorizeLet’s play a game

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

Application specificity is becoming a confusing term. There are some specific application Rollups that allow deploying contracts on top of themselves; there are also some specific application Rollups that may 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 they don’t support other types of development.

Is it fair to categorize them together?

Answers to the above exercise:

Group 1: Celo is a strange option as 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 that is specifically built to be directly usable, while the others are optimized for specific features such as privacy, NFT, and TPS, so that applications deployed on them can inherit these features. Other projects that can be considered in Group 2 include Kinto, Kroma, Public Goods Network, etc.

Issues with deploying contracts in the modified Universal 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 they do not really affect the core state transition rules of the VM. Rollup is essentially a virtual machine, and your business logic sits 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” care about the logic of proving applications. The VM is 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 foundation itself to make it suitable for the application. You can continue to enhance the State Transition Function (STF), add/remove 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 keep enhancing 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 it can manage the state in any possible way in any execution environment, 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 limited by the virtual machine. They look like web2 backend applications, but they regularly publish transaction proofs to L1. I believe 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 the proof of the public intermediary can eliminate the pain of proving each application separately. However, I personally think that this is just a trade-off between efficiency and faster development.

There are some methods to solve this problem without using an execution layer involving virtual machines. 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 web2 backend applications. Making Micro-Rollup development as simple as writing and deploying smart contracts, not to mention the ability to modularly add the ability for developers to choose any ecosystem.

So, is Micro-Rollup real?

Always has been, just like Rollup itself.

Applications like Loopring, dYdX, and Fuel-v1 have already appeared 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 with is Hubble Optimistic Rollup, a 3-year-old project that once served as the core infrastructure for the Worldcoin token.

Now it is becoming increasingly important to distinguish these terms.

The use cases for Micro-Rollups are endless:

• Consumer products such as 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, thus opening the door to virtual machine innovation

Conclusion

The structure tree I showed earlier lacked elements of a custom state machine.

In addition, for individual applications, using a Rollup based on 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 limitations.

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 as Rollup App.

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