# PUP-33: Scale Parameters And Capacity for Evolution (SPACE)
**URL:** https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104
**Category:** Parameters
**Tags:** proposal
**Created:** [March 11, 2024, 8:45pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104 "2024-03-11T20:45:45Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Olshansky](https://forum.pokt.network/u/Olshansky)
#### Post date: [March 11, 2024, 8:45pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/1 "2024-03-11T20:45:45Z")
# Attributes
- **Authors:** @Olshansky @RawthiL
- **Active Contributors:** @BenVan @shane @fredt @kutoft
- **Parameters:**
1. `pocketcore/BlockByteSize`: `8000000` → `12000000` → `16000000`
2. `pocketcore/MinimumNumberOfProofs`: `10` → `500`
- Ref: [Block Sizes, Claims and Proofs in the Multi-Gateway Era](https://forum.pokt.network/t/block-sizes-claims-and-proofs-in-the-multi-gateway-era/5060)
# Table of Contents
- [1. Summary / Abstract]
- [2. Motivation / Rationale]
- [2.1 Block Size Update]
- [2.2 Minimum Number of Proofs Update]
- [3. Dissenting Opinions]
- [3.1 Updating Other Parameters]
- [3.2 Cost of increasing `BlockByteSize`]
- [3.3 Impact of Increasing `MinimumNumberOfProofs`]
- [3.4 TradeOff Table]
- [4. Analysis]
# 1. Summary / Abstract
_tl;dr We need to **Make SPACE** on Morse while Shannon is cooking._
This proposal recommends updating two on-chain parameters to enable the Pocket Network protocol to scale and support more Gateways & more Chains / Services prior to `Shannon`’s launch.
# 2. Motivation / Rationale
_tl;dr Increasing available block space and lowering usage of existing block space makes room for gateways and chains._
The next major rewrite & upgrade of the Pocket Network Protocol (`Shannon`) will have the technical capacity to scale and account for more relays, more gateways and more chains/services. Until the release & migration is complete, the current version of the Protocol (`Morse`) continues to support, grow and evolve the largest network of decentralized RPC providers.
The following two opportunities are currently limited by existing block space and its usage:
1. Onboarding new gateways
2. Adding more new chains/services
This is a result of the amount of space used by on-chain proofs. Every unique `(Application, Node, Chain)` set within every session requires an on-chain `Claim & Proof`.
`Shannon` development timelines should not hinder the opportunity and growth of the Pocket Network ecosystem. Therefore, we recommend updates to two parameters.
### 2.1 Block Size Update
_tl;dr Bigger block → More space on-chain sessions_
The block size will be updated from `8MB` to `16MB`. It will be held at `12MB` for a month in between to avoid a potential shock to the system and allow node operators to upgrade their infrastructure.
This creates more space for more on-chain sessions to exist, enabling more Gateways & more Services.
### 2.2 Minimum Number of Proofs Update
_tl;dr More proofs required → Lower number of on-chain sessions_
The minimum number of proofs (i.e. relays) per session for a node to claim their work will increase.
This will reduce the usage of existing block space by requiring _sufficient_ (i.e. above a minimum threshold) relay volume to be handled by a node before it’s session is stored & rewarded on-chain.
# 3. Dissenting Opinions
## 3.1 Updating Other Parameters
Updating `pocketcore/SessionNodeCount` or `pocketCore/MaximumChains` was also considered and discussed. However, changing these values has implications on gateways, node operators, tokenomics and other factors other than just the scalability of the protocol.
Updating other parameters can still be discussed but is out of scope given the short-term priority of resolving the Motivation & Rationale for this proposal.
## 3.2 Cost of increasing `BlockByteSize`
Increasing the block size will impact the cost of maintaining Pocket Nodes for gateways and node runners.
However, given the long block times (15 minutes) and small blocks (16MB), Pocket remains one of the cheapest and simplest blockchains to maintain. It should not have a prohibitive impact on capital expenditures for node runners.
## 3.3 Impact of Increasing `MinimumNumberOfProofs`
This has a negative impact on two accounts:
1. A small fraction of existing sessions will no longer be rewarded
2. New/small/niche chains with very low relay volume may lead to node consolidation
The response to this is:
1. The value selected is worth the tradeoff of growing the network while minimizing the impact on node ROI.
2. Consolidation of such low-volume chains is worth the tradeoff and will rebalance once traffic increases.
## 3.4 TradeOff Table
The following table captures a summary of the pros, cons & nuances.
| | On-Chain Parameter | Pros | Cons | Nuances | Additional Context |
| --- | --- | --- | --- | --- | --- |
| Block Size | `pocketcore/BlockByteSize` | Enables the ability to handle more on-chain Sessions, enabling more Gateways & more Chains | Costs for every supplier (i.e. node runner) will increase | Introduces overhead to communicate new resource requirements | 20MB blocks were tested on TestNet when the upgrade from 4MB to 8MB took places |
| # of Relays Per Session | `pocketcore/MinimumNumberOfProofs` | Reduces the number of on-chain Sessions, enabling more Gateways & more Chains | Rewards and relays for low-volume chains decrease | Could affect tokenomics if the number becomes too high. | See the amazing data & analysis from @Ramiro Rodríguez Colmeiro above |
| # Nodes Per Session | `pocketcore/SessionNodeCount` | _skipped_ | _skipped_ | Out of scope given the requirements of this discussion since it impacts one or more of QoS, decentralization & tokenomics | A new forum thread should be started for this discussion. |
| Max Chains | `pocketCore/MaximumChains` | _skipped_ | _skipped_ | Out of scope given the requirements of this discussion since it impacts one or more of QoS, decentralization & tokenomics | A new forum thread should be started for this discussion. |
# 4. Analysis
@RawthiL collected, analyzed and shared extensive data in the following discussion forum:
> [@Block Sizes, Claims and Proofs in the Multi-Gateway Era](https://forum.pokt.network/t/block-sizes-claims-and-proofs-in-the-multi-gateway-era/5060):
>
> Edits: 22/02/2024 : Corrections and added more data splitting the sample by gateway. The intention of this thread is to share data on the issue raised by @BenVan [on Discord](https://discord.com/channels/553741558869131266/564836328202567725/1209725762555355166). I will try to follow @Olshansky proposed format. What’s the problem? Block size is increasing, currently at ~7.5 MB out of a maximum of 8 MB. Things node runners could / should do Node runners can activate the pocket\_config.prevent\_negative\_reward\_claim parameter available in the [last version of Pokt](https://github.com/pokt-network/pocket-core/releases/tag/RC-0.11.1). However this won…
The takeaways from this data include:
1. State & block size is increasing, but at a reasonable pace
2. The impact on sessions that will no longer make it on-chain will be minimal
# Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
---
### Author:  [@BenVan](https://forum.pokt.network/u/BenVan)
#### Post date: [March 13, 2024, 10:23pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/2 "2024-03-13T22:23:22Z")
Are we ready to vote this?
---
### Author:  [@Olshansky](https://forum.pokt.network/u/Olshansky)
#### Post date: [March 13, 2024, 10:32pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/3 "2024-03-13T22:32:53Z")
@JackALaing Can we move this to a vote?
---
### Author:  [@shane](https://forum.pokt.network/u/shane)
#### Post date: [March 14, 2024, 3:34pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/4 "2024-03-14T15:34:40Z")
PUP-33 is now up for a vote 👉 [Snapshot](https://gov.pokt.network/#/proposal/0x32616d1febcb7eeb1894c63a090d7ca911bd86ebb10a6cc546ff5628f31b1f6b)
---
### Author:  [@poktblade](https://forum.pokt.network/u/poktblade)
#### Post date: [March 14, 2024, 9:10pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/5 "2024-03-14T21:10:23Z")
Nodies currently holds 20 app stakes staked into 5 chains, each 20M each per session (the other 6 we have are unused). Assuming best case scenario (or rather worst case scenario for block space) for our gateway, we take up 2MB of block space and have access to upwards to 9.6B relays a day assuming uniform distribution of traffic. (20M \* 20 \* 24). Obviously, the best case scenario is likely not to happen as our traffic is not uniform and not every node operator will be effective in a session. But it does give us a better general idea.
The other gateway operators that are coming onboard are expected to adopt the gateway server which will exhibit the same behaviors that Nodies gateway is showing on chain. With this, we should be able to scale upwards to roughly 3-4 more gateway (2MB each) operators if they have the same traffic patterns as us based off @RawthiL [research](https://forum.pokt.network/t/block-sizes-claims-and-proofs-in-the-multi-gateway-era/5060/23)
I support this proposal. Thanks everyone for the analysis and help
---
### Author:  [@Olshansky](https://forum.pokt.network/u/Olshansky)
#### Post date: [March 25, 2024, 7:17pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/6 "2024-03-25T19:17:16Z")
The proposal has [been approved](https://snapshot.org/#/poktdao.eth/proposal/0x32616d1febcb7eeb1894c63a090d7ca911bd86ebb10a6cc546ff5628f31b1f6b) so moving on to next steps.
1. @JackALaing When can PNF enable this on behalf of the DAO?
2. @RawthiL Is there an easy way to reproduce the data collection you did in [here](https://forum.pokt.network/t/block-sizes-claims-and-proofs-in-the-multi-gateway-era/5060/12) so we can keep track of “small sessions that go unrewarded”?
> The other gateway operators that are coming onboard are expected to adopt the gateway server which will exhibit the same behaviors that Nodies gateway is showing on chain.
1. @Andy-Liquify Wanted to double check that you plan to adopt [gateway-server](https://github.com/pokt-network/gateway-server) as stated?
> Nodies currently holds 20 app stakes staked into 5 chains, each 20M each per session (the other 6 we have are unused)
4.1 @poktblade Are the app stakes owned by nodies public? If so, could you share them?
4.2 @RawthiL Is it possible to filter by “app stake” on potkscan? If so, could you link to it.
---
### Author:  [@JackALaing](https://forum.pokt.network/u/JackALaing)
#### Post date: [March 25, 2024, 7:58pm UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/7 "2024-03-25T19:58:45Z")
> [@Olshansky](#):
>
> When can PNF enable this on behalf of the DAO?
We can execute the parameter change transactions today or tomorrow. I am guessing tomorrow morning would be best to allow for time to monitor the impact of the change during working hours?
---
### Author:  [@RawthiL](https://forum.pokt.network/u/RawthiL)
#### Post date: [March 26, 2024, 11:01am UTC](https://forum.pokt.network/t/pup-33-scale-parameters-and-capacity-for-evolution-space/5104/8 "2024-03-26T11:01:17Z")
> [@Olshansky](#):
>
> 1. @RawthiL Is there an easy way to reproduce the data collection you did in [here](https://forum.pokt.network/t/block-sizes-claims-and-proofs-in-the-multi-gateway-era/5060/12) so we can keep track of “small sessions that go unrewarded”?
The sessions with less than 500 relays will be invisible, they will never reach the block.
Gateways are the only ones that will have visibility on that (if they track their relays off-chain).
> [@Olshansky](#):
>
> 4.2 @RawthiL Is it possible to filter by “app stake” on potkscan? If so, could you link to it.
You mean get the number of relays on an arbitrary selection of apps? No, we don’t have that feature right now. Gateways relays are calculated during sync using the apps assigned to each gateway.
What you can get is the total and avg relays in the last 24 Hs of any app by means of the table filter. Just filter by an app address and see the values at the bottom of the table. However we do not support selection of arbitrary app lists (asking to add this right now).
> [@Olshansky](#):
>
> 4.1 @poktblade Are the app stakes owned by nodies public? If so, could you share them?
Let me answer this and @poktblade please verify.
Apps owners can be seen on POKTscan, you can sort them by gateway:
[https://poktscan.com/explore?tab=apps](https://poktscan.com/explore?tab=apps)
Keep in mind that the gateway label is manually asigned by us, given the lists provided by PNF. If any gateway finds that there is an error with that list, they need to talk to PNF so we can get the correct list (we wont change it if a gateway asks us because PNF uses that to charge gateways).