Origin document: https://docs.google.com/document/d/1uBomaVieGAjsyHeqSlwmqOyPOln1CemVlWXZjQXUMRY/edit#

Overview

The aim of this project is to allow V0 to scale within guard rails in order to accommodate growth while V1 is still in development. This is meant to be a non-functional roadmap, meaning the requirements and work performed in this project can be done in parallel to the functional roadmap of features and bug fixes in v0.

Step 1: Guard Rails Data Collection Automation

Tl;dr Automate data collection for network capacity previously done in an ad-hoc matter.

Originally performed by Andrew Nguyen Guard Rails was a project that aimed to benchmark a series of data points in the Pocket Network from which scalability guard rails would be derived from. The original work resulted in the following document: https://docs.google.com/document/d/1QcsPfhj636zBazw2jAay8H6gdBKXcIMmohY0o321hhQ/edit

The idea of this step in the project is to automate the experiments realized in the original Guard Rails project and build a series of infrastructure components that monitor nodes in the Mainnet network continuously, which allows to establish a baseline, and subsequently measure how that baseline moves with different changes such as the ones proposed in the subsequent steps of this project.

The reasoning of why this is the first step is that this creates a mechanism that allows several scalability modifications to be safely tested in isolated environments and measured against the Mainnet environment for a safer and more predictable release.

Step 2: Block Size Increase + Block Time Reduction

Tl;dr Reducing block times and increasing block sizes requires coordination but is low-hanging fruit with some risk that can help scale the network.

As part of the RC-0.9.0 release, a new DAO parameter was included which allows the modification of the block size dynamically via a DAO parameter transaction. On top of that, block timing is a configuration which is established in the “config.json” configuration file of nodes, which controls block timing. In this step we are proposing a series of experiments that would test the impact of modifying these 2 parameters in a network to understand their impact on several metrics, specifically those outlined in the Guard Rails described in Step 1.

Proposed experiments are:

1. Block size increment in isolation: Increase the block size in isolation and fill blocks with fuzzed transactions, simulating a volume similar to the transaction volume expected in Mainnet. The success criteria would be acceptable parameters and an increase in the amount of transactions possible in a single block, thus increasing the scalability of the network linearly by the amount the block size is increased to.
2. Block Time Reduction: Understand the impact of reducing block times, to allow for more frequent blocks. This would allow for more transactions in the same timeframe as we have it in mainnet to date (~4 blocks per hour).
3. Block Size Increase + Block Time Reduction: Ultimately find the desired sweet spot for scalability and impact on Guard Rail parameters which would ultimately result in a stable but more scalable network.

These experiments must be carried out with vigor and maximum visibility, deploying the wrong combination to production could have catastrophic implications for the network and very hard recoveries via social coordination.

Step 3: Scaling the Claim and Proof lifecycle

Tl;dr Move from a one-app/one-chain/one-node tree design to a multi-app/multi-chain/one-node design, which is complex, has open-ended questions and comes with security tradeoffs.