Scalability

An overview of Autonomys' approach to achieving unprecedented scale

Autonomys is taking a first-principles approach to scaling the Subspace Protocol that builds on existing blockchain scalability protocols, including the likes of Prism and OmniLedger, and our own novel research.

Constraints to scaling blockchain TPS

For any blockchain system, there are at least three physical scaling constraints:

• The communication constraint—the upload bandwidth of a single participating node

• The computation constraint—the number of transactions a node is capable of executing per second

• The storage constraint—the number of transactions stored by each node

The goal of blockchain scaling is to achieve the maximum possible throughput under these physical constraints, measured by TPS (transactions per second).

In a conventional blockchain design, a participating node (often referred to as a full node or a miner) has to download, store and execute all the transactions. This requirement leads to several upper bounds. For instance, the throughput cannot exceed the average upload bandwidth divided by the average size of transactions. Thus, if the average bandwidth is 10 Mbit/s and the average size is 250 bytes, the throughput cannot exceed 5000 TPS under the communication constraint—too small for certain applications.

The huge number of transactions generated by the future Internet-of-Agents, as well as the mainstreaming of the burgeoning decentralized finance (DeFi), decentralized science (DeSci) and on-chain gaming (GameFi) ecosystems, will significantly expedite the demand for greater scalability. How can we scale the Autonomys Network throughput by 100x to be able to handle 500,000 TPS?

Scaling the Autonomys Network

In order to achieve this goal throughput of 500,000 TPS, we could increase the upload bandwidth to at least 1Gbit/s. However, this would sacrifice decentralization, as nodes with low bandwidth would no longer be able to participate. Instead, having already decoupled the requirement that every node store and execute all transactions, via our DSN and DecEx, we are now decoupling the bandwidth requirement.

Inspired by the similarities between rollup and sharding designs, we propose a unique sharding approach based on cryptographic sortition. Our system consists of a beacon chain and multiple data shards. The beacon chain is maintained by all the farmers through the PoAS consensus algorithm. Each data shard is maintained by a subset of farmers selected by cryptographic sortition over time. For instance, a farmer could be elected as a leader for the beacon chain if they have a lottery ticket close enough to $C_t$ (i.e. the distance between the ticket and $C_t$ is smaller than a threshold $T_b$); elected as a member for data shard 1 if the distance is no smaller than the threshold $T_b$, but smaller than $T_b + T_s$; elected as a member for data shard 2 if the distance is no smaller than $T_b + T_s$, but smaller than $T_b + 2T_s$; and so on. Generally, a farmer is elected as a member for data shard $i$ if the distance is no smaller than $T_b + (i-1)T_s$, but smaller than $T_b + iT_s$. A farmer is only assigned to a shard when elected and is a member of at most one shard at any time. This dynamic shard membership is recorded on-chain as farmers prove their winning tickets.

When a new domain joins, it is assigned to a data shard. A farmer elected as a leader for this shard downloads recent blocks and transaction bundles, then produces a new shard block on the longest available chain. This new block is shared with domain operators, the DSN, as well as future leaders. Its block header is shared with all the farmers through gossiping (to be included in the beacon chain). This process is a variation of Nakamoto’s longest chain protocol, and the majority of leaders in any shard are honest due to cryptographic sortition, which supports shard safety and liveness with high probability.

To address data withholding attacks, where a malicious shard leader colludes with malicious domain operators, the system allows future shard leaders to detect such attacks. For rare undetected attacks, we propose an on-chain complaint mechanism similar to Tas and Boneh (2023). This workflow is illustrated for one domain and shard below.

Data flow between domain, shard and beacon chain

Next, we present an alternative design using cryptographic sortition and erasure coding. In this setup, explicit shards are unnecessary. When a domain operator creates a transaction bundle, it broadcasts the header to all the farmers (to be included in the beacon chain) and disseminates erasure-coded chunks. Farmers receiving a chunk can vote for the bundle via cryptographic sortition, with voting data recorded on the beacon chain to facilitate consensus on data availability. This is in spirit similar to a very recent scalability design proposed in Fisch et al. (2024).