Attributes
- Authors: @Olshansky @RawthiL
- Active Contributors: @BenVan @shane @fredt @kutoft
- Parameters:
pocketcore/BlockByteSize:8000000→12000000→16000000pocketcore/MinimumNumberOfProofs:10→500
- Ref: Block Sizes, Claims and Proofs in the Multi-Gateway Era
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:
- Onboarding new gateways
- 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:
- A small fraction of existing sessions will no longer be rewarded
- New/small/niche chains with very low relay volume may lead to node consolidation
The response to this is:
- The value selected is worth the tradeoff of growing the network while minimizing the impact on node ROI.
- 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:
The takeaways from this data include:
- State & block size is increasing, but at a reasonable pace
- The impact on sessions that will no longer make it on-chain will be minimal
Copyright
Copyright and related rights waived via CC0.
