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.