DFINITY Foundation

Synapse.vote (original)

ICDevs.org

CryptoIsGood

Anvil

ICPL.app

ysyms

The Accumulators’ Neuron

RawTech Venture

Paul Young

ICPMANUAL

8yeargangDAO

Isaac Valadez

Krzysztof Żelazko

Nicolas.ic

Smaug’s Neuron for Retail Investors

ICLight.io

Synapse.vote (NEW)

Taggr Network

CodeGov

Sonic AMM

Rakeoff.io

OpenChat

ELNA AI

GEEKFACTORY

ICP Hub México

ICP Hub Poland

Jerry Banfield

WaterNeuron

ICP Hub Bulgaria

Gold DAO

NeuronPool

LORIMER

B3Pay

ZenithCode

Aviate Labs

Internet Computer Association

Arthur’s Neuron (used to be cycle_dao)

Inactive (Request Removal) - The Fools' Court

$STACK

Always Rejects

John Wiegley

A new proposal for the scaling of the protocol.

Welcome.

This proposal is a path forward and a plan for the scaling of the world-computer.

A single subnet is limited in its compute and storage capacity. When a subnet is full, the subnet needs to move some of its load onto other subnets with more space. A full subnet can be defined as some threshold of load that would lower the performance of the canisters on that subnet by some amount.

When a subnet is full, the protocol will do an automatic move of half of the load onto other subnets. If there are some available existing subnets that have space then the protocol can move the load onto the existing subnets that have space, otherwise the protocol will do an automatic subnet-split, where the protocol will spawn a new second subnet and then move half of the first subnet's load onto the second subnet. 

The original subnet will split its load by splitting and moving its canister ranges, straight down the middle of the load-concentrations.

Canister creators will choose a subnet-type: `fiduciary`, `european`, `application`, for their canisters, but will not choose which specific single subnet their canisters live on. The protocol can move canisters between subnets at any time, within the same subnet-types.

Any trace of specific same-subnet functionality will be taken away from the canisters' point of view.
 - Cross-canister calls can always take up to the time of a cross-subnet canister-call: **3 seconds**. Sometimes the protocol might be able to do it faster but from a canister-creator's point of view, a canister-call can always take up to 3 seconds.  
 - Management-canister `install_chunked_code` method will be made to work cross-subnet of the same subnet-type.
 - The experimental composite queries will be taken out of commission. The ICRC-3 query pattern can always be used instead of composite queries, and is better because it works when the data-canisters are on different subnets and because other canisters can call the query methods.
 - The message size limit of a cross-canister call will be the same whether the target canister is on the same subnet or on a different subnet. 
 - Management-canister `create_canister` method will create a canister on a random subnet within the same subnet-type as the caller-canister. 
 - When creating a canister with the NNS cycles-minting-canister, the caller will only be able to set the subnet-type, but not the specific subnet.
 
With this plan, every canister will always be available to perform. If someone creates a million canisters and puts heartbeats on all of them, as long as there are enough nodes in the whole network, the protocol will automatic balance the load throughout all the subnets and create new subnets as it needs, so there will never be an overloaded subnet. 

At the same time, this plan simplifies the canister development complexity for canister creators, while making sure that their applications stay scalable, no matter how many canisters are created, and no matter what other developers are doing.

This plan is for the public subnets, where anyone can install canisters. This proposal is not about the nns/system subnets or rental subnets.

##### Comparison to a different scaling proposal

There was a different proposal for scaling that proposed to let canister controllers migrate their canisters to specific subnets, and would place the responsibility of handling subnet-load-balancing onto the canister developers.  

The proposal stated that the reason for needing to let canister controllers migrate their canisters to specific subnets is the assumption that canister controllers would need to be able to keep multiple canisters on the same specific subnet to take advantage of a few same-subnet-optimizations for cross-canister calls. 

However, trying to take advantage of that on the public subnets would be an unstable optimization and make development many times more difficult if possible at all, because on the public subnets anyone would be able to install and run canisters on any specific subnet at any time, so there would be no way to predict or know how much available compute and storage any specific subnet will have at any time, and the available compute and storage on any specific subnet could change at any time, so any attempt to take advantage of that would not be consistent, and would be very hard to try to manage in that environment.  

If an application gets popular, and other applications that integrate with it try to be on the same subnet as the popular application, then the popular application might not be able to find a subnet with enough space to function if other applications keep following it around and right away filling up any subnet that the popular application tries to move to.  

As the network grows, when a subnet gets full, all the applications on it would look for empty subnets to move to. They would all be looking for the same low-load subnet qualities and there's a high chance they would all target the same few emptiest subnets to move to, and then the new subnets could get full fast since many applications are moving to the same few subnets at the same time, and some of the applications might have to move again, causing inefficiencies.

Letting canister controllers migrate their canisters to specific subnets would also make it easy for someone to make any application stop working by spamming that application's subnet (denial-of-service), since anyone would be able to target any specific subnet. If however the protocol stays in charge of which canisters live on which subnets and when, then the protocol will spread any load throughout the whole network, and it will not be possible to target a specific subnet or specific application. As the network grows with more subnets, it gets more and more safe for canisters, and it gets harder to try to target a specific subnet or application.

Concerning bandwidth, an application's canisters that spread throughout all the subnets can scale forever no matter how many canisters are created. An application's collective bandwidth between its canisters grows together with the number of subnets in the whole protocol, without limit, since each additional subnet adds to the amount of work that the application can perform in parallel at the same time. As the application and the network grow bigger, the scalability of both get better and better.

Automatic spreading of the canisters throughout all available subnets of the same subnet-type gives each dapp automatic scalability forever as the dapp grows into many canisters and as the protocol grows into many subnets. Without the developers needing to deal with an unpredictable load and limitation of a specific subnet. 


A path forward for the scaling of the world-computer.