Author: KAUTUK; Source: Substack; Translation: Kate, Marsbit
One of my tweets recently went viral and received a lot of attention in the Web3 online community! It’s a very short “tweet” post consisting of four parts, but I hear you asking, what does it mean exactly? Let me explain.
Forget Rollup, Skip the Clichés
Opening a Rollup article with topics like “What is Rollup” or “Why do we need Rollup” is like killing off Uncle Ben or shooting Wayne’s parents in every iteration of Spiderman and Batman movies. If you are reading this article, chances are you are already familiar with these well-documented arguments. Furthermore, if you are reading this, I think we can move beyond the debate of application chains and application Rollups. So let’s get to the point.
- Intent principle and practice exploration What use cases can be achieved?
- FTX court documents disclose list of celebrity endorsement fees, with O’Neal’s fee at $750,000.
- Musk’s Demon and Management My Pain Never Stops
The Rise of Application-Specific Rollups
Generic Rollups are Frustrating
Generic Rollups are like the Indian school system (I believe they share similar characteristics with other school systems, but this is the one I have firsthand experience with).
Athletes, singers, mathematicians, philosophers, economists, and storytellers all have to go through the same process to get passing grades. Technically, the system doesn’t “favor” any particular group, but it’s not “fair” to everyone either. But hey, we make friends! (This will be important later).
Similarly, for applications on generic Rollups, the bottleneck is the environment itself as it cannot cater to the specific needs of each application individually. Each application may require different types of optimizations, but expecting something tailor-made for them is unreasonable. However, if you just want to give it a try, get a rough idea, it’s the most convenient choice. Additionally, for some applications, just like some average students, it might be the right solution!
What about friends? It’s an application ecosystem built along with your application. If you’re an entrepreneur, you can simply call up your accountant friend to help you hide taxes from the government 🙂
Application-Specific Rollups are Confusing
Okay, my child has exceptional athletic abilities, can’t go to a public school, needs special training. Should I send her to a sports academy or should I hire a private coach…
Specific Complexity
Let’s play a game.
Below is a list of 8 application-specific Rollups. However, in each group, there is one item that doesn’t belong to that group. Can you figure out which one it is?
Application-specificity is becoming a perplexing term. Some application-specific rollups allow for contract deployment on top of themselves, while others allow for contract deployment because their virtual machine (VM) supports it, but their owners restrict it. There are also application-specific rollups with closed VMs or no VM at all, and they do not support other types of development.
Is it fair to categorize them together?
The answer to the previous question~
Group 1: Celo is a strange choice 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 one because it is the only Rollup specifically built to be directly used, while others are networks optimized for specific features such as privacy, NFT, and TPS, so applications deployed on top of them can inherit these features. Other projects that can be included in Group 2 include Kinto, Kroma, Public Goods Network, etc.
Deploying contracts in a modified general-purpose virtual machine
These virtual machines for deploying smart contracts are nothing more than Turing complete state machines. The contracts you deploy on them are just additional modifications to the state itself. It does not really affect the core state transition rules of the virtual machine. Rollup is essentially a VM, and your business logic resides on it.
Your business logic is separate from the state transition functionality of the rollup.
I also refer to it as the “smart contract paradigm for building applications” because you deploy some additional logic on top of the VM. Rollup does not “directly” care about how to prove the logic of the application. 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 continuously enhance the foundation itself to make it suitable for the application. You can continue to enhance the state transition functionality (STF) and add/remove opcodes to improve application performance, but the application is still independent and subject to the limitations of the VM itself.
It’s like a Lamborghini Urus pulling a Lamborghini Huracan.
A separate application on an application-specific Rollup can do better! Much better!
If you continuously enhance the STF to make the scope of STF smaller and more aligned with the business logic of the application, what will happen? 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, damn, wait a minute!
Micro-Rollups are born!
Therefore, a Micro-Rollup is just a rollup where the state transition functionality of the application is the business logic itself.
The application has become a rollup, and the state can be managed in any execution environment in any possible way. The state transition rules can be directly applied to the runtime of the application. The application can be customized without any limitations. These proofs are related to your business logic, not the machine. It makes your application lightweight.
These special state transition functions will be discussed in another article, stay tuned 🙂
As far as developers’ experience is concerned, Micro-Rollup is unrestricted. You can use any tools you like to build them because they are not limited by the VM. They look like web2 backend applications, but they regularly send transaction proofs to the parent L1. I think this will be a major factor in influencing web2 developers to transition to the web3 field.
In fact, a better example would be the Rimac Nevera, because it is faster and electric, so it may be cheaper to run, but I can’t find a sexier road picture.
The only drawback of this approach is customizing the proof mechanism for each different application. If the application logic can be compiled into a common intermediary, then proving this common intermediary will eliminate the pain of proving each application separately. But personally, I think this is just a trade-off between efficiency and faster development. We want to improve every bit of efficiency as much as possible.
There are ways to bypass it without using methods involving VMs in the execution layer. What if there is a tool that allows developers to do this?
This is the mission statement of Stackr Labs – we are building a micro-rollup framework and SDK so that anyone can build their applications unrestrictedly in any language, just like building web3 backend applications. Making Micro-rollup development as simple as writing and deploying smart contracts, not to mention the ability to modularly increase the developer’s choices in any ecosystem.
So is micro-rollup real?
It has always been real. (But just like rollup, sorry, I don’t want to upset Jon)
Applications like Loopring, dYdX, and Fuel-v1 have appeared or been in existence for a long time. These are super-optimized rollups with custom logic specifically designed to serve their use cases. The first non-VM-specific application rollup that I know of and have personally been involved in is the Hubble Optimistic rollup, which has a history of 3 years and once served as the core infrastructure of the Worldcoin token. (This is also the main inspiration for Stackr)
It’s just now that it becomes important to distinguish these terms.
You can build Micro-Rollups without restrictions:
1. Consumer products such as games, exchanges, NFT markets, etc;
2. App-chains can be transformed into app-rollups;
3. You can even build new types of virtual machines that support unique use cases, thus opening the door to virtual machine innovation.
I will write another article discussing the pros and cons of Micro-Rollup and which applications make sense to build using the Micro-Rollup framework.
Conclusion
The missing element in the tree I presented earlier is a custom state machine.
In addition, for standalone applications, deploying a single protocol using VM or EVM-based rollups is not efficient. It is suitable for applications that already have a bunch of smart contracts and run protocols on the EVM chain, but not for “wanting more applications” and wanting to get rid of VM limitations.
If we trim this tree, the final tree looks like this. This is also why I believe that in the near future, app-rollup, micro-rollup, or rollup will be called Apps.
Therefore, Micro Rollups = Apps on rollups Apps as Rollups
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
