scalability/scalability

[giscus[bot]]

scalability/scalability

https://hyperledger-labs.github.io/splice/scalability/scalability.html

[scolear]

The parties that are over the 200 limit - are they determined by creation-date? Meaning, there is no chance that an already working party, under the 200 limit, will be after the limit as more parties are added due to some other sorting mechanism (say alphabetical) ?

[horus20]

Did I understand correctly, if we use directly #splice-wallet:Splice.Wallet.TransferPreapproval:TransferPreapprovalProposal for external parties, then incoming transfers will be automatically approved (by validator), but at the same time we will not have problems with the limit?

[tonychew-hydrax]

Curious how does it work under the hood and why does WalletAppInstall matter that would affect the 200 limit? I feel this might be useful in explaining the underlying system design nuance better

[PumpkinSeed]

We investigated this limitation on one of our devnet nodes. We created ~500 parties and onboarded them to the Wallet, which resulted in the creation of the ValidatorRight and WalletAppInstall contracts for each party.

After that, we noticed that every attempt to connect to the Canton participant failed with the following error:

MAXIMUM_NUMBER_OF_STREAMS(2,0): The number of streams in use (1000) has reached or exceeded the limit (1000).

This happened because the Validator itself overloaded the Participant with connections to UpdateService/GetUpdateTrees.

By offboarding, we mean removing the ValidatorRight and WalletAppInstall contracts from the party. The Validator has an offboard endpoint, but since nobody could connect to the participant, calling that endpoint didn’t work.

To resolve this, we wrote a script that manually archived the ValidatorRight and WalletAppInstall contracts. Archiving the ValidatorRight was straightforward since it could be done by the party. However, archiving the WalletAppInstall required signatures from both the Validator and the party. To work around this, we temporarily granted the Validator actAs rights so it could sign on behalf of the party.

Even then, we couldn’t connect to the participant, so we temporarily shut down our Validator node. We then ran the script, which archived the ValidatorRight and WalletAppInstall contracts for all 500 parties, and restarted the Validator afterwards.

Aftermath: The devnet now works relatively well. The only missing part is that the devnet Validator, which was a Featured App Party, no longer receives the Featured App Rewards. We are currently investigating this. It seems the party still receives the AppRewardCoupon, but the automation does not pick it up. Validator Rewards, however, continue to flow smoothly.

[PumpkinSeed]

We wanted to further test the limitations, so we created over 1,500 parties. We simulated transfers by interacting directly with the Ledger API, making three transactions per second using the TransferPreapproval_Send choice. The Ledger Node ran on a machine with 2 vCPUs and 6 GiB of RAM, utilizing 27% of its resources at this throughput. This confirms that the limitation only exists when parties are onboarded through the Wallet API or Validator.

[waynecollier-da]

2026-01-05 Update on party scaling on the global synchronizer (gsync)

• Technical limit on the number of external parties with data hosted on a given Validator node:
  Currently the known limit is based on testing by the Canton scaling workgroup; they report that a single Validator can host at least 250,000 external parties.

• Current known largest number of external parties hosted on a running Validator on MainNet as of today: 75,000

• Max total parties currently allowed on the Global Synchronizer (currently based on the time required to ingest both the topology state, and the ACS of the DSO):
  330,000 as of this week
  400,000 with fixes that will reach MainNet by the end of January 2026
  Upgrades expected on MainNet by March will allow the gsync to support over 1 million parties

• Current cap on new party onboarding by a single wallet: 2,000 new parties onboarded per week. This is driven by the overall party number limits of the gsync. Accommodations can be made for onboarding large sets of customers at once.

The Canton Foundation coordinates the per-wallet party onboarding cap between the Canton engineering team and the Validator node operators; reach out to operations - at - canton.foundation to learn more.