Unbundling global consensus from the Smart Contract Account model
New type of account
Each OneBalance account can be thought of as its own rollup.
The account wraps individual user state from all chains and replicates it in a virtual environment.
This virtual environment issues state transition requests as “resource locks” and fulfills those state transitions through cross-chain execution proofs. This virtual environment is secured by a credible commitment machine.
A OneBalance account can create an arbitrary number of sub accounts across any number of chains and manage any state present on those chains.
Resource Locks
- A resource lock is a credible commitment made by a user to escrow some state conditional on particular conditions fulfilled, or an expiry time (example could be a cross-chain request to purchase an NFT on Solana using USDC deposited in the OneBalance account from Ethereum)
- Introduces a separation between fulfillment time and settlement time: since the account provides local assurance of the lock, solvers can bring a requested state transition on a destination chain without waiting for finality on the origin chain.
Architectures
OneBalance can incentivize atomicity, but it cannot guarantee it. Accounts can enforce two types of constraints:
- Constraints over what states of the world it requires in order to issue a lock
- Constraints over what states of the world it requires in order to fulfill a lock
How does this thing scale to one billion concurrent users? OneBalance accounts create “local” locks, whereas regular accounts can only create “global” locks. Global locks require locking the state of all accounts in the execution environment during sequencing, whereas local locks only require locking the state of accounts which are party to the lock.
Thoughts:
- It's not a silver-bullet solution. Basically it turns the problem upside-down by putting the account the center of the architecture, which will control the lock. An operation performed with this type of account must always look back at the state of the lock, which ensures account-local serialization and consistency (whether finalization or rollback).
- The key components are:
- A credible commitment machine: holds the public lock
- A solver: executes the operations requesting and fulfilling the lock
- Not all operations can be carried out, only those that can support timeouts or rollbacks.
- It's primarily async, contrary to their initial claims.