By Stephane Gosselin and Ankit Chiplunkar on behalf of Frontier Research

For discussion, please visit ethresear.ch.

See Research Day 2024 slides and recording.

Motivation

Web3 and the crypto ecosystem more broadly has historically had a chain centric worldview. We believe this is an outdated framework originating from a perceived scarcity in blockspace due to the bundling of credible commitment machines with global consensus.

We believe an ecosystem wide transition towards an account centric worldview which bundles accounts with credible commitment machines is both necessary and inevitable in order to consolidated a fragmented user experience.

We propose a new account model called “Credible Accounts” and introduce a framework called “OneBalance” for creating and managing these accounts. With this proposal, we hope to provide a missing component of the web3 stack that will help onboard the first billion humans onto crypto.

TLDR

OneBalance is a framework for creating and managing accounts on credible commitment machines. We call these Credible Accounts.

Each account can thought of as an rollup which allows users to conveniently manage their state and reliably request state transitions on any chain.

This is achieved through the introduction of two key concepts:

1. Accounts on credible commitment machines, and
2. Resource locks

A credible commitment machine is responsible for securing the account, issuing resource locks over the state it holds, and validating the fulfillment of such locks.

By introducing Credible Accounts, we hope to accelerate the transition of the ecosystem from EOAs, the JSON-RPC API, and the transaction supply chain, towards an architecture built around message passing of resource locks and fulfillment proofs.

A Credible Account on OneBalance can:

• Combine token balances from every chain
• Abstract gas on any chain
• Swap and send tokens to and from any chain
• Issue complex permissions over any subset of user state
• Incentivize and enforce atomic asynchronous composability across multiple chains
• Authenticate user using modern methods such as passkey, session keys, FIDO
• Fast confirmations through separation of fulfillment from settlement

Many use cases are unlocked with these new capabilities. Users can spend any token to pay for state transitions. They can aggregate liquidity that lives both on-chain and off-chain. They even have the building blocks to build a decentralized Fireblocks, or a non-custodial Binance.

Wallet 1.0 - Externally Owned Accounts

The web3 market structure equilibrium, as defined by Ethereum, is the use of public-private key-pair, aka, Externally Owned Account (EOA) to manage all aspects of a user’s state.

Since EOAs sit outside the blockchain, the chain has no view over what message have been signed. The chain relies on the use of nonces to sequence user state transaction requests, often called transactions.

Here, we simplify down a smart contract blockchain such as Ethereum to a Credible Commitment Machine bundled with Global Consensus.

Credible Commitment Machines

Thomas Schelling’s 1960 The Strategy of Conflict famously introduced the game theory concept of “focal point” better known as his name sake “Schelling point” .

A lesser know contribution of this work was the introduction of “credible commitments” which he describes as “a promise or threat believable to others by creating a situation where the costs of reneging on the commitment are higher than the benefits”.

According to Schelling, a credible commitment must provide:

1. Irrevocability: Making the commitment in such a way that it cannot be easily reversed. This might involve physical actions or formal agreements that lock the party into their commitment.
2. Increased Costs: Ensuring that backing out of the commitment imposes significant costs, either financially, reputationally, or strategically.
3. Observable Commitment: The commitment must be visible and understandable to other parties, ensuring they believe in the credibility of the commitment.

The concept was further refined by Nick Szabo in 1997 with the introduction of the concept of smart contracts as software enforced contracts, which was further explored by Mark S. Miller and Marc Stiegler in 2003.

These investigations lead to the Ethereum Whitepaper published by Vitalik Buterin in 2014 proposing Ethereum as the first smart contract blockchain capable of creating and enforcing arbitrary credible commitments.

Many important contributions to the topic followed with a noteworthy contribution by Mohammad Akbarpour and Shengwu Li in 2019 providing a formal definition to Credible Mechanisms and introducing the auction trilemma.

Loosely defined, we refer to a Credible Commitment Machine as a secure computer able to programmatically issue and enforce commitments such that they are believable or “credible” to a third party observer.

EOAs and Request Equivocation

EOAs are not credible commitment machines. Since the chain has no view over what the user has signed, it must consider any transaction signed with the same nonce as valid. This means that at any time, a user can equivocate their state transition request by signing and submit a new transaction which overwrites their nonce.

This makes EOAs, and the transaction supply chain more broadly, incapable of providing credible commitments as they violate the principle of irrevocability. Downstream parties in the transaction supply chain such as solvers are unable to rely on the commitments made by EOAs as they may be equivocated at any time.

To date, every system looking to protect against request equivocation have relied on locking funds in a deposit smart contract. This is the approach used by all types of bridges (L2, intent, POA, IBC, ZK). All implementations of secure cross chain interactions rely on the transfer of assets to a smart contract as a request which cannot be equivocated.

The class of networks based on HTLCs such as the Interledger Protocol all use timelocked requests as a form of credible commitment for security passing economic messages between ledgers.

Wallet 2.0 - Smart Contract Accounts

Smart Contract Accounts (SCAs) solve the request equivocation problem by bringing the signer on chain. This allows the account to leverage the chain’s credible commitment machine and global consensus to timestamp and sequence each state transition requests issued by the user thereby preventing equivocation.

Vitalik has long been a proponent of smart contract wallets as these offer great UX features broadly referred to as account abstraction which includes gas abstraction, social recovery, permissions policies, and modern authentication methods.

Despite addressing the equivocation problem, smart contract accounts deployed to chains with global consensus like Ethereum are prohibitively expensive and slow. This is because virtual machines such as the EVM require the sequential execution of global locks over all user accounts for every state transition request. This is equivalent to forming a single global queue of all users waiting to do something on chain.

The Account Dilemma

We observe a tradeoff between EOAs and SCAs. On one side we have EOAs which are fast and cheap, but cannot make credible commitments due to request equivocation. On the other side we have SCAs which can make credible commitments, but are slow and expensive due to global consensus. We call this fundamental tradeoff the Account Dilemma.

Wallet 3.0 - Credible Accounts

We propose a new account model called Credible Accounts which aims to solve the Account Dilemma. Credible Accounts live in a secure computer of the users choice that can make credible commitments about what messages it will and won’t sign.

By unbundling global consensus from the Smart Contract Account model, we are able to keep the speed and cost advantage of EOAs while retaining the UX improvements and non-equivocation guarantees of SCAs.

The OneBalance Framework for Credible Accounts

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.

Since a OneBalance account provides the same guarantees as a SCA, it comes with all the same UX benefits of account abstraction, such as gas abstraction, social recovery, permission policies, and modern authentication methods.

A OneBalance account can create an arbitrary number of sub accounts across any number of chains and manage any state present on those chains. It is backwards compatible with all chains, smart contracts, and assets including Ethereum, Solana, Bitcoin, ERC20s, NFTs, DAOs, multisigs, defi protocols, and deposits or points programs. This multi-ecosystem compatibility is not possible with other current account model.

The OneBalance framework for Credible Accounts is implemented in a modular way using standards developed by the CAKE Working Group to allow users / apps / wallets to pick an choose any component of the CAKE Framework needed for their use case.

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.

An example could be a cross-chain request to purchase an NFT on Solana using USDC deposited in the OneBalance account from Ethereum.

resource_lock: {
	lock: 1500 USDC,
	fulfill: DeGods #12345,
	expiry: Solana block 245547084
}

Resource locks are necessary to prevent solvers from being griefed by a user through double spending or equivocating their request during execution.

Since the user makes a commitment not to overwrite their request within a time window, it removes the uncertainty solvers typically incur between a transaction being signed and the finalized chain state.

A lock is analogous to depositing funds in a smart contract, or issuing an ERC20 approval, but without spending gas or waiting for on-chain finality since it is done within the account itself.

The lock expiry needs to be of long enough duration to provide solvers the chance to execute the requested state transition on the destination chain and submit a proof of fulfillment to the fulfillment engine.

Crucially, this 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.

This allows users to buy SOL with ETH at the speed of Solana without being constrained by the speed of Ethereum. This fulfillment speed can be extended to execution of any state transition such as sniping an NFT, sending money to your grandmother, or anything else users do on blockchains.

Resource locks can implement constraints which sit anywhere along the spectrum of permissions.

Permissions could be stateful or stateless. For example:

• Scoped session keys: a stateless permission for an app like a Telegram bot to take arbitrary actions on subsets of a user’s token balances
• Circuit breaker: a stateful permission to sell all open positions if there is no account activity or market volatility above a predefined threshold
• Limit order: a stateful permission to post an order if a pair reaches a certain price on a DEX
• MFA: a stateless permission to post a transaction if two valid authentication methods are provided

Credible Commitment Machine

A credible commitment machine is a secure computer on which the account lives and is trusted to provide assurances over the valid issuance of resource locks and the validation of their fulfillment.

We present here four possible architectures of credible commitment machines which provide for secure issuance and enforcement of locks: Trusted Execution Environments (TEEs), Multi-Party Computation / chain signatures (MPC), Smart Contract Accounts (SCAs), and in protocol virtual machine changes.

These mechanisms are being developed and refined as we speak, it is likely that the ideal architecture today will look vastly different than the one five years from now.

This is why a OneBalance account allows users to migrate between CCMs over time as they look for better properties.

Roadmap

OneBalance v1:

• add support for transactions and swaps of any token on any chain
• add support for session keys for trusted applications
• add support for user rage quit through exit hatch

OneBalance v2:

• add support for stateless policies
• add support for arbitrary transactions
• add support for authentication modules

OneBalance v3:

• add support for stateful policies

OneBalance v4:

• add liveness guarantees through account replication

Acknowledgements

Thank you to the collective consciousness of the crypto ecosystem for fostering a fertile ground for innovation.

In no particular order, thank you to the following collaborators for the many stimulating discussions which lead to the creation of this proposal:

Murat Akdeniz, Ahmed Al-Balaghi, Viktor Bunin, Jonah Burian, Vitalik Buterin, Philippe Castonguay, Vaibhav Chellani, Valery Cherepanov, Jasper De Gooijer, Nicolas Della Penna, Justin Drake, Brendan Farmer, Ben Fisch, Mattia Gagliardi, Johnny Gannon, Matt Garnett, Ivo Georgiev, Christopher Goes, Pedro Gomes, Mason Hall, Sam Hart, Connor Howe, Sreeram Kannan, Hart Lambur, Zaki Manian, Robert Miller, Alex Obadia, Puja Ohlhaver, Anatolii Padenko, Nick Pai, Illia Polosukhin, Karthik Senthil, Tomasz Stanczak, Henri Stern, Alex Stokes, Caleb Tebbe, Dror Tirosh, Dean Tribble, Drew Van der Werff, Alex Watts, Yoav Weiss, Nathan Worsley, Evgeny Yurtae, Philipp Zentner, Noah Zinsmeister, apriori, jxom, awkweb.

Discussion