PUP-10: Increase SessionNodeCount to 24

Attributes

  • Author(s): @Andrew

  • Parameter: SessionNodeCount

  • Current Value: 5

  • New Value: 24

Summary

As Pocket Network grows, scalability optimizations are necessary to ensure Pocket Network is fully utilizing the theoretical capacity of the network. By increasing the SessionNodeCount, Pocket Network can increase the network wide Relay capacity while optimizing for block production times and state size. In addition to the scalability optimization, this change enables the Portal API to have a larger pool of Service Nodes to choose from in a session, when it applies its cherry picking strategies creating a higher standard of quality of service for apps using the Portal.

Rationale

In the current protocol architecture, the validation of Claim+Proof requires 1 Session Generation. As Service Nodes continue to grow indefinitely with Pocket Network maturation, validation of Claim+Proof transactions will continue to account for the majority of block processing time. Benchmarking shows that any SessionNodeCount less than 100 is not statistically significant for Session Generation times, which means we can increase SessionNodeCount up to 100 without trading off Session Generation Time. By increasing the SessionNodeCount, a smaller amount of unique Single-Chain Sessions are needed to be generated during the Claim+Proof validation, while the number of active Service Nodes remains the same. By leveraging this parameter, Pocket Network is able to saturate the ‘Network Wide’ Relay capacity while optimizing the block processing times. While there is little effect to node runner economics, block processing and state size is greatly helped by increasing this parameter.

24 Service Nodes

The maximum block size allows for a capacity of 6,000 simultaneous active servicers. At 24 nodes per session, this allows for a conservative block processing time and a small state size consumption relative to today’s 2,000 apps; 1:5 ratio. Given conditions today, upgrading beyond 24 nodes per session is likely overkill given the 15 minute block times.

Demonstration

Modification of the SessionNodeCount

SessionNodeCount: 24


Demonstration:

// Assuming 6K ‘Simultaneous Active Servicers’

Less Apps & More Nodes Per Session is better for block processing & blockchain data

* 1K Apps & 6 Nodes Per Session
  * - 5 Minute Processing Per Block & 237KB of State Data

* 500 Apps & 12 Nodes Per Session
  * - 2.5 Minute Processing Per Block & 119 KB of State Data
* 250 Apps & 24 Nodes Per Session
  * - 1.25 Minute Processing Per Block & 59 KB of State Data

FAQ

After this change, will the same number of Service Nodes be relaying?

Yes, the exact same amount of nodes will be relaying, the proposal is just to expand out Session size to optimize block processing by reducing unique Session generation.

Will this change affect Service Node relay distribution?

Possibly. Given the pool of nodes the Portal may cherry pick from will be larger, it’s possible the rewards will bias towards higher quality nodes, per the cherry picking strategy that the Portal applies. This would manifest in a higher quality of service for the applications and an increased standard of service for node runners.

Analyst(s)

Andrew Nguyen, Protocol Lead

Luis C. de Leon, CTO

Alex Firmani, Director of Engineering

Copyright

Copyright and related rights waived via CC0.

4 Likes

I support this PUP 100%. The increase in number of nodes per session will provide an immediate tangible benefit to end users as the selection of nodes will make it more likely to get service from nodes that are geographically close to the user.

1 Like

I support this PUP without reservation.

2 Likes

As with others, and as a node runner myself, I fully support this.

This proposal is now up for voting! Snapshot

This proposal has been voted in.

When will it be implemented?

1 Like

Yep indeed, this proposal passed on Christmas Eve. Early Christmas present!

I expect it to be implemented very soon. One last piece of code needs to be shipped on the Portal before the node count can be increased. The implementation has been slightly slower due to the holidays.

3 Likes

Very looking forward to this. Will help out the smaller node farms for sure on their daily average to be closer to that of the network average, which has been challenging.

2 Likes

Has there been any further updates to this? Not sure if I’m seeing much difference at this time in terms of my nodes being chosen for sessions, but that also could be due to the increases in new nodes as well added to the network.

The parameter has now been changed to 12 nodes per session. We’ll be monitoring to see how this performs, then moving on to 18 or 24 for the next step in the implementation.

3 Likes

The parameter has now been changed to 24 nodes per session, meaning this proposal has been fully implemented.

3 Likes

Wonderful! :clap:t2: Great work on getting this done!

1 Like

The only downside I see now is some extra bloating of the blockchain, since each block has 1500-2600 txs now as opposed to 600-1200 txs prior to implementing this change.