We recently announced the imminent launch of Versatus LASR, the world’s first Stateless Rollup. As expected, many of you have reached out to us asking for more information. How does it work? Why stateless? How is it Language Agnostic? How does it differ from other Rollups? Total the first of a series of blog posts where we “dig deeper” into the details of LASR.
Stateful vs Stateless
First of all, WTF does it even mean to be a “Stateless Rollup”. To answer that question, let’s first discuss what it means to be “Stateful”. Stateful systems are systems in which previous values, combined with inputs, determine the next value. The simplest version of a stateful system might be a simple incremental counter. With the incremental counter, the previous inputs are saved (State of the system), and the State plus the new inputs determine the output.
Suppose we have an incremental counter that counts the number of people entering a venue. Every time 1 person enters the venue, the counter increases by 1. It starts at 0, but then when the first person enters, it increases to 1. Then the second person entering increments the counter to 2, and so forth and so on. In this scenario, the “State” of the system (a simple counter) is 0 to start, before transitioning to 1 and then 2, and then 3, etc. Now blockchains are much more complex than a simple counter, but in simple terms, the purpose of a blockchain is to get a large number of nodes to agree whether the current “State” of the network is 1, or 2 or 3. The difference is, for most blockchains they’re tracking the various quantities of digital assets associated with various accounts/addresses.
state t = 0
state t+1 = 1
state t+2 = 2
Blockchains are inherently “stateful”. There have been discussions about whether or not the concept of a “stateless blockchain” is something that can exist in reality, and discussions around this have largely come to the conclusion that they cannot. Stateless blockchains, or at least settlement layers are somewhat of an oxymoron. The idea, however, is that it’s not truly stateless, but rather most nodes don’t retain the full state, but rather verify a new state proof given a batch of transactions. Ultimately, those transactions have to alter the data associated with some account/address somewhere. Even in the event that every single individual interacting with the blockchain maintained only their own account values, and contributed to some shared proving mechanism, each account itself is stateful and needs to be retained. Further, the proof itself (typically a root hash of some variant of trie), would need to be retained by nodes, so while the “global state” may just be a proof of some sort, that proof is a form of state. It’s next value is dependent on the previous value and any inputs.
state t + 1 of the blockchain depends on state t of the blockchain
When we talk about truly stateless systems, think about a simple calculator. If you enter 1 + 1 the calculator will return 2. If you then enter 1 + 1 again, you will again get 2. The value 1 + 1, entered into the calculator, is not dependent on the previous values entered into the calculator. The result produced by the calculator is always only dependent on the inputs. These types of systems are typically very efficient, they don’t come with a lot of computational overhead, they don’t require a lot of memory or storage, they just process inputs and produce outputs.
results are independent and cleared after completion
no state is retained, next calculation not dependent on previous inputs/results
Rollups
Ok, so now that we are familiar with the concepts of statefulness and statelessness, let’s discuss what a “Rollup” is. A rollup is sort of like an express lane for public transportation in a bustling city where the streets frequently get congested. Rollups are off-chain scalability solutions that allow users to access faster, cheaper execution. Rollups typically work as separate chains. Users can bridge onto these separate chains and engage in some activity, such as play a game, buy an NFT, use a DEX, stake their tokens, etc. Basically anything you want to do on the main chain you can do on the rollup.
The rollup retains a state of account data and transactions, and “rolls” the transactions “up” into a single transaction that gets settled on the main chain. By doing this, the rollup can “prove” the account bridging actually has the assets/values that they are bridging. They can do this by producing “fraud proofs”, i.e. a verification of all of the transactions that occurred on the Rollup. Rollups, much like the main chain, as of today, are stateful. This means that users cannot just use the rollup directly from the main chain. They have to bridge some assets from their account into the rollup (often referred to as Layer 2), before they can interact with anything or send funds across the rollup. The nodes operating the rollup “know” the assets that all the users that bridged into it have available to use in the rollup. Users cannot, however, use the assets that remain on the main chain on the rollup unless and until they have bridged into it.
Rollups do come with some significant benefits. Because they are off-chain, there is additional flexibility, and because they batch settle transactions and proofs back to the main chain as a single transaction (albeit a large transaction with lots of data), individual transactions on the rollup are significantly cheaper. Rollups also typically offer faster execution for transactions than the base chain, although in the current implementations this is typically done by sacrificing decentralization and/or security, or by introducing trusted parties.
Despite the benefits, rollups come with significant costs. Rollups, because of bridging and the lack of shared sequencers and efficient communication across various rollups, fragment the user base through the bridging process. Instead of having a single global state, each rollup retains its “own” state. Even though the state on the rollup is dependent on the state of the base chain at the time of bridging, this state is not shared across the ecosystem of rollups. This also means that developers have to deploy their program to each rollup, one by one, if they want to tap into the user base of all rollups.
Initiate the LASR Sequence
This is where LASR comes in. LASR, instead of retaining its own state, relies on the state of the main chain(s) it is deployed on top of. Versatus LASR uses an “Executable Oracle’’ to “export” account data from the main chain to execute, in parallel, batches of transactions, which then immediately settle back to the main chain upon completion and verification. This provides users and developers with all of the benefits of using a Rollup, with virtually none of the setbacks.
