SyncVM

Introduction

The SyncVM (Synchronicity Virtual Machine) is the data and computation layer of the sREAL Engine. The SyncVM both improves upon and subsumes the EVM, SVM and MoveVM, extending them with programmable privacy, synchronous execution, and function-level composability. The SyncVM is sufficiently generalized such that any application can be built on top of it and includes Web 2 level performance heretofore unseen in any other modern blockchain VM.

Programmable privacy empowers users with fine-tuned control over the conditions under which each element and property of their data can be computed over (while retaining privacy) or revealed. Programmable privacy unlocks a new highly customizable design space where users can build credit without doxxing themselves, exchanges can publish aggregate order-book stats while hiding individual orders, and users can send value without exposing payment histories.

Synchronous Execution is the ability to atomically trigger function calls in response to changes in the state of a blockchain execution environment. Synchronous Execution addresses three of the most persistent structural limits of on-chain markets: capital not being used to the fullest extent, MEV and latency asymmetry. Synchronous Execution requires a novel Gas system. For more detail on how the SyncVM Gas system works, see: Gas

Function-level composability includes two new ways functions can work: (1) functions can call one another without additional development to integrate them, and (2) writing to state can be contingent on a set of functions returning true. The former increases composability to dramatically decrease the friction to iterate at the frontier of on-chain applications. The latter, in conjunction with Synchronous Execution, enables capital to be used to the fullest extent by facilitating interoperability among protocols.

Sovereign Prebuilt Modules

The Sovereign Prebuilt Modules provide basic rollup functionality optimized for low latency, high throughput leviathan-free computation. They define a model for state transition functions, ingest transaction data with a sequencer, post transaction data to a DA layer, and prove the execution trace with a ZK proof. For more information on the Sovereign Prebuilt Modules, Prebuilt Modules - The Sovereign SDK Book .

Account Module

The Sovereign Prebuilt Modules support a rudimentary account model. In the EVM, in order to allow agents (i.e., anything that can invoke function calls) to perform permissioned actions on behalf of an account, protocols need to do prohibitively large development work to support it. The Account Module extends the Sovereign SDK with account abstraction and improves the EVM’s model for function calls by allowing users to specify arbitrary conditions under which agents can call function logic on their behalf, giving them incredible flexibility and control over which actions they allow other accounts to perform on their behalf, and which accounts can do so.

The Account Module accomplishes this through its design of a programmable account. A programmable account is a mapping of an accountId to a permission. Permissions can be composed of arbitrarily complex logic.

Synchronous Execution Module

The Synchronous Execution Module is one of the most important parts of the SyncVM, creating the ability to atomically trigger function calls in response to changes in state.

The Sovereign SDK provides three types of state: a value, a map, and a vector (i.e., a list). The Synchronous Execution Module defines a fourth type: a synchronous wrapper that can be used to create an atomic link between a part of state and arbitrary function calls to be executed when that part of state is written to. Synchronous function calls are stored in a list inside the synchronous wrapper.

Synchronous function calls are comprised of four parts: the function call, cancellation permissions, an active account, and a gas payer.

• Function call: the function to be synchronously called on behalf of the active account.
• Cancellation permissions: users can specify arbitrarily complex conditions under which the function call can be removed.
• Active account: the account to which the function call is attributed.
• Gas payer: the account from which gas is debited.

State to which synchronous function calls are attached is called synchronous state. When synchronous state is written to, its synchronous function calls are executed in the order specified by the synchronous wrapper.

The Synchronous Execution Module implements call level reversion, which means that if a particular synchronous function call is reverted or its spender has insufficient gas to pay for the call, then only that particular call reverts, instead of all function calls in the wrapper.

Conditional Execution Module

The Conditional Execution Module enhances Synchronous Execution beyond simply triggering function calls if synchronous state is written to by defining the conditional execution manager, which allows users to prevent the execution of synchronous function calls unless arbitrary conditions are met.

For example, a user can limit synchronous logic to create a limit order for a Bitcoin perpetual only if and when the price of Bitcoin reaches a certain threshold. This can be expanded to any set of arbitrary conditions on any number of parts of state.

State Permissioning Module

The State Permissioning Module allows for the attaching of arbitrary sets of permissions to read and write state.

For example, with respect to the reading of data, a user who develops a trading strategy can permission other users who deposit some minimum amount of capital to the strategy’s reserves to view its unrealized profit and loss since they deposited the capital, but not the logic of the strategy itself.

Another example with respect to the reading of data is that a user can permission the reading of their state to anyone with a particular password and limit the duration of time in which the password is valid.

With respect to the writing of data, the State Permissioning Module empowers users with the ability to grant other accounts permission to spend on their behalf under certain conditions, without forfeiting custody of the assets.

Dispatcher

Synchronous Execution depends upon the ability to store function calls in state, which the Sovereign SDK does not natively support. The dispatcher defines a global type for arbitrary function calls to modules, which lets modules communicate with one another.