Subspace Ecosystem: A Guide for Domain Operators and Developers

Introduction

As part of solving The Farmer’s Dilemma, Subspace’s initial whitepaper outlined a system where consensus and computation are distinct entities.

Farmers are responsible for proposing transaction order, while staked executor nodes (now referred to as operator nodes) manage the state and compute transitions. This modular design choice is meant to empower farmers, enabling them to participate in the consensus process without the intensive computational demands of transaction execution. It also introduces operators as distinct network participants that may be relied on to handle this heavier load.

The central component to decoupled execution is the concept of domains. The Subspace system of domains is conceptually similar to rollups on Ethereum. The primary difference is enshrining these rollups into the core protocol itself. Domains are namespaced (separate) execution environments that allow for horizontal scalability.

A key benefit for developers is the ability to launch their own networks while leveraging the underlying consensus chain. This not only ensures robust security, but also guarantees reliable data availability and settlement processes. Essentially, it’s about harnessing the inherent strengths of the blockchain to offer a more flexible, secure, and efficient environment for decentralized applications.

Domain Runtime Registry and Instantiation

Domain runtimes are registered on the consensus chain. This is a permissioned operation at the current time. In the future, we will allow what we call “open” domains, where anyone will be able to register a conforming runtime on the Subspace network. Currently, an EVM is the sole registered runtime. Other types of runtimes, like those based on WASM, will be added later on.

Once a runtime has been registered, it is available to be instantiated with a domain genesis configuration that defines domain specific information such as the domain name, block size and number of bundles per slot and block. This can be executed by any account that places a deposit, allowing Subspace users to launch their own EVM domain within the Subspace Network. This is limited to the sudo account, but will be opened up soon.

Operators and Nominators

Anyone can participate as an operator once a domain has been instantiated. An operator’s responsibility is to bundle and then execute transactions for a domain. They do this by registering, depositing stake, and running a node.

Once registered and running a node, the operator participates in the VRF election process to produce bundles. The election is stake weighted, meaning an increased stake increases the probability of being elected to produce the next bundle.

When we say “operator” we mean a couple of different things depending on the context. There is the “operator node” which is the software responsible for compiling and submitting bundles and executing transactions. There is also an “operator pool”, which is created when registering as an operator.

Upon registration, the pool is created. The initial stake is then deposited into the pool and the registering account becomes the pool owner. There are two important options to consider when registering:

1. Minimum nominator stake
2. Nominator tax, which is the percentage of nominator earnings that an operator will keep.

And with this now enters a new class of network participant: the nominator. As previously mentioned, being selected to produce a bundle is a probabilistic outcome based on an operator’s stake weight. The only way to increase the probability of bundle production is to increase the relative stake in an operator pool.

One way of doing this is to attract nominators who can add stake to an existing operator pool. Nominators can share in any operator pool earnings after paying the tax that was determined when the operator pool was created. In this way, an operator is able to leverage their hardware investment by taxing those who, foregoing the overhead of running a node, choose to trust their stake to the proper and efficient running of an existing operator.

Epochs and Epoch Transitions

An epoch is an amount of time where the staking distribution remains static. Any changes that impact stake distribution that occur during this period are collected and applied during the next epoch transition. Currently, epoch transitions occur every 100 domain blocks. An epoch transition will include:

• allocation of rewards earned by the operator during the last epoch
• any deposits or withdrawals of stake by operators or nominators
• operator registrations and deregistrations
• taxes earned by operator owners from their nominators
• update the domain’s staking summary

Transaction Lifecycle

What does producing a bundle actually mean? Why do operators want to compete for this right? To begin explaining these concepts, it may be best to explain the full lifecycle of a domain transaction.

• A transaction begins with the submission by a user to a domain node in the domain’s network.
• This transaction is then gossiped to other operator nodes and will reside in each nodes transaction pool until a bundle producer is elected that has also been assigned a transaction range that includes this transaction.
• The bundle producer will then select the transaction and include it in a bundle that is submitted to the consensus chain. Note, the same transaction may (and probabilistically will) end up in multiple bundles.
• All consensus nodes receiving the bundle will verify that the bundle is well-formed and that it includes a valid proof of election. Consensus nodes will NOT execute the transaction, instead they will include as many bundles as will fit in the block and apply each bundle header to the consensus chain state.
• Once the consensus node has broadcasted the block on the consensus network, domain operators who observe at least one domain bundle within the block will build a corresponding domain block.
• Operators will deduplicate bundled transactions and then deterministically shuffle them, grouped by sender account, based on randomness from the consensus chain.
• Once the transactions have been deduplicated and ordered, each operator executes each extrinsic and produces an execution receipt that tracks, among other things, each transaction’s post state root. This will allow for other operators to challenge any execution that doesn’t match their own execution results (more on this later). ****

When an operator is selected to create a bundle, they will include the most recent execution receipt from the latest block they executed. This receipt will be included in the bundle’s header. The bundle producer is paid for the fees associated with the block execution that generated this receipt, not for the transactions included in the current bundle. These fees will be distributed in the epoch transition after the challenge period has been met and the execution receipt has been confirmed.

Detecting Fraud

As mentioned above, every operator runs every transaction within each domain block, producing their own execution receipts. These execution receipts are deterministic, so every operator should produce the exact same receipt. Therefore, if an honest operator observes a different receipt than they have produced locally, they have detected fraud.

When an operator detects fraud, they will submit a fraud proof to the consensus chain. All child blocks of the execution receipt will be pruned and the related operators will be slashed if it is proven to be valid. Transactions are not considered confirmed until a certain amount of time has passed to allow for dishonest operators to be challenged. This is due to the potential of fraud. The timeframe is typically referred to as the challenge period and is currently set to 256 blocks or roughly 26 minutes. The current value is for testing purposes and will likely change for mainnet.

Nova EVM

All the above enables a foundational domain of the Subspace Network, Nova.

Nova is an EVM chain on the Frontier pallet. Frontier extends Ethereum’s compatibility to Substrate-based chains like Subspace. The essence of Nova’s EVM compatibility lies in its user-friendly design: it’s tailored for those already acquainted with the EVM landscape. This means that developers and users entrenched in EVM-based ecosystems can effortlessly adapt to the Subspace environment.

Practically, this translates to familiar processes and tools. For instance, conducting transactions through MetaMask or deploying smart contracts using tools like Foundry or Hardhat becomes straightforward and seamless on Subspace. The only requisite change is a simple configuration update to connect with a Subspace Nova RPC node.

What’s next

We are still early in the development and evolution of domains on the Subspace Network.

In the near term, we will be enabling cross-domain messaging which will allow for value transfer across domains and with the consensus chain. We will also be improving the operator user experience with various upgrades such as syncing from other operator nodes rather than the consensus node. Looking ahead, we’re planning to introduce ‘open domains.’ This means we’ll be enabling permissionless registration of domain runtimes, allowing any conforming runtimes to be registered and instantiated by any user.

This is just a few of the many improvements we’re planning for the future. Subspace is rapidly improving its developer experience and the novel innovations that can be built on top of the network.

As we head into the new year, we’re extremely excited to continue showcasing what we have been working on. If you’re a developer eager to join us on our mission, we invite you to get in touch via our Discord. For more in-depth information on Subspace Network, work through the documentation available on the Subnomicon documentation page.