Following our Hello, World! post, and the first part of this series Stateful vs Stateless, we received a lot of requests for more information about how LASR actually works. In this post, we will walk through the process, starting with a user-initiated transaction, and ending with the transaction confirmation on the settlement layer.
LASR, like many existing “Rollups”, batches transactions to the settlement layer. The major difference is that LASR, instead of retaining its own chain and state, uses the settlement layer state, it then posts changes to relevant accounts on the settlement layer rather than changes to its own state. This enables LASR to be more secure and scale more efficiently.
How is this possible?
As we briefly discussed in the Hello World post, there are 4 core components of LASR, each of which deserves its own post (*hint hint*), but for a quick refresher, those 4 components are:
- A Peer to Peer Compute Network
- App Specific Nano Runtimes
- An Executable Oracle
- An external DA layer
A transaction’s life begins when a user signs a transaction that is relayed to the Versatus LASR Compute Network. Once the network receives the transaction the following steps are taken to execute, verify and finalize it:
- A User submits a transaction to LASR via RPC.
- LASR schedules the transaction to be executed.
- Through the Executable Oracle’s Account, LASR requests data from the settlement layer (for a batch of transactions) necessary to verify the transaction’s validity.
- In parallel, the network proceeds with executing the parts of the transaction that are not dependent on the settlement layer data
- LASR schedules the parts of the transaction that are dependent to execute upon the receipt of the necessary data.
- The LASR network retrieves the app-specific nano runtime for the program/contract the user is interacting with. Each nano runtime is sourced from our content-addressable storage backed by IPFS.
- When the LASR network receives the data necessary to complete the execution of the transaction, nodes in the network call the operations that the transaction requires
- The LASR network awaits a quorum threshold to agree on the validity of the full results of the execution.
- Once the quorum threshold is reached, the results from the transaction are batched together with other transactions and the “deltas” (changes to the relevant account(s)) are posted back to the Executable Oracle via the Executable Oracle Account.
- Simultaneously, full transaction data, including the relevant account state(s) at the moment of the transaction submission is posted to the external DA layer as a data blob.
LASR’s unique model verifies transactions without requiring nodes to know all of the data from the main settlement blockchain. This model is efficient, lightweight and enables wide decentralization. Combined with an external DA to store full transaction data, we maintain the full transaction history plus efficient on-chain settlement. Maintaining a snapshot of the account state at the moment of execution ensures that verification proofs can be produced for every transaction in the network. This secures the network and ensures a fast and scalable experience. Through LASR’s stateless settlement approach, we unlock a completely new set of solutions that will be built upon Web3.
