-
Notifications
You must be signed in to change notification settings - Fork 138
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
NEP-514: Reducing the number of Block Producer Seats in
testnet (#514)
- Loading branch information
Showing
3 changed files
with
182 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,166 @@ | ||
| --- | ||
| NEP: 514 | ||
| Title: Reducing the number of Block Producer Seats in `testnet` | ||
| Authors: Nikolay Kurtov <[email protected]> | ||
| Status: New | ||
| DiscussionsTo: https://github.com/nearprotocol/neps/pull/514 | ||
| Type: Protocol | ||
| Version: 1.0.0 | ||
| Created: 2023-10-25 | ||
| LastUpdated: 2023-10-25 | ||
| --- | ||
|
|
||
|
|
||
| ## Summary | ||
|
|
||
| This proposal aims to adjust the number of block producer seats on `testnet` in | ||
| order to ensure a positive number of chunk-only producers present in `testnet` | ||
| at all times. | ||
|
|
||
| ## Motivation | ||
|
|
||
| The problem is that important code paths are not exercised in `testnet`. This | ||
| makes `mainnet` releases more risky than they have to be, and greatly slows | ||
| down development of features related to chunk-only producers, such as State | ||
| Sync. | ||
|
|
||
| That is because `testnet` has fewer validating nodes than the number of block | ||
| producer seats configured. | ||
|
|
||
| The number of validating nodes on `testnet` is somewhere in the range of | ||
| [26, 46], which means that all validating nodes are block producers and none of | ||
| them are chunk-only producers. [Grafana](https://nearinc.grafana.net/goto/7Kh81P7IR?orgId=1). | ||
|
|
||
| `testnet` configuration is currently the following: | ||
|
|
||
| * `"num_block_producer_seats": 100,` | ||
| * `"num_block_producer_seats_per_shard": [ 100, 100, 100, 100 ],` | ||
| * `"num_chunk_only_producer_seats": 200,` | ||
|
|
||
| It's evident that the 100 block producer seats significantly outnumber the | ||
| validating nodes in `testnet`. | ||
|
|
||
| An alternative solution to the problem stated above can be the following: | ||
|
|
||
| 1. Encourage the community to run more `testnet` validating nodes | ||
| 1. Release owners or developers of features start a lot of validating nodes to | ||
| 1. ensure `testnet` gets some chunk-only producing nodes. | ||
| 1. Exercise the unique code paths in a separate chain, a-la `localnet`. | ||
|
|
||
| Let's consider each of these options. | ||
|
|
||
| ### More community nodes | ||
|
|
||
| This would be the ideal perfect situation. More nodes joining will make | ||
| `testnet` more similar to `mainnet`, which will have various positive effects | ||
| for protocol developers and dApp developers. | ||
|
|
||
| However, this option is expensive, because running a validating node costs | ||
| money, and most community members can't afford spending that amount of money for | ||
| the good of the network. | ||
|
|
||
| ### More protocol developer nodes | ||
|
|
||
| While this option may seem viable, it poses significant financial challenges for | ||
| protocol development. The associated computational expenses are exorbitantly | ||
| high, making it an impractical choice for sustainable development. | ||
|
|
||
| ### Test in separate chains | ||
|
|
||
| That is the current solution, and it has significant drawbacks: | ||
|
|
||
| * Separate chains are short-lived and may miss events critical to the unique | ||
| code paths of chunk-only producers | ||
| * Separate chains need special attention to be configured in a way that | ||
| accommodates for chunk-only producers. Most test cases are not concerned about | ||
| them, and don't exercise the unique code paths. | ||
| * Separate chains can't process real transaction traffic. The traffic must | ||
| either be synthetic or "inspired" by real traffic. | ||
| * Each such test has a significant cost of running multiple nodes, in some | ||
| cases, tens of nodes. | ||
|
|
||
| ## Specification | ||
|
|
||
| The proposal suggests altering the number of block producer seats to ensure that | ||
| a portion of the `testnet` validating nodes become chunk-only producers. | ||
|
|
||
| The desired `testnet` configuration is the following: | ||
|
|
||
| * `"num_block_producer_seats": 20,` | ||
| * `"num_block_producer_seats_per_shard": [ 20, 20, 20, 20 ],` | ||
| * `"num_chunk_only_producer_seats": 100,` | ||
|
|
||
| I suggest to implement the change for all networks that are not `mainnet` and | ||
| have `use_production_config` in the genesis file. `use_production_config` is a | ||
| sneaky parameter in `GenesisConfig` that lets protocol upgrades to change | ||
| network's `GenesisConfig`. | ||
|
|
||
| I don't have a solid argument for lowering the number of chunk producer seats, | ||
| but that reflects the reality that we don't expect a lot of nodes joining | ||
| `testnet`. It also makes it easier to test the case of too many validating nodes | ||
| willing to join a network. | ||
|
|
||
| ## Reference Implementation | ||
|
|
||
| [#9563](https://github.com/near/nearcore/pull/9563) | ||
|
|
||
| If `use_production_config`, check whether `chain_id` is eligible, then change | ||
| the configuration as specified above. | ||
|
|
||
| ## Security Implications | ||
|
|
||
| The block production in `testnet` becomes more centralized. It's not a new | ||
| concern as 50% of stake is already owned by nodes operated by the protocol | ||
| developers. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| See above. | ||
|
|
||
| ## Future possibilities | ||
|
|
||
| Adjust the number of block and chunk producer seats according to the development | ||
| of the number of `testnet` validating nodes. | ||
|
|
||
| ## Consequences | ||
|
|
||
| ### Positive | ||
|
|
||
| * Chunk-only production gets tested in `testnet` | ||
| * Development of State Sync and other features related to chunk-only producers accelerates | ||
|
|
||
| ### Neutral | ||
|
|
||
| * `testnet` block production becomes more centralized | ||
|
|
||
| ### Negative | ||
|
|
||
| * Any? | ||
|
|
||
| ### Backwards Compatibility | ||
|
|
||
| During the protocol upgrade, some nodes will become chunk-only producers. | ||
|
|
||
| The piece of code that updates `testnet` configuration value will need to be | ||
| kept in the database in case somebody wants to generate `EpochInfo` compatible | ||
| with the protocol versions containing the implementation of this NEP. | ||
|
|
||
| ## Changelog | ||
|
|
||
| ### 1.0.0 - Initial Version | ||
|
|
||
| The Protocol Working Group members approved this NEP on Oct 26, 2023. | ||
|
|
||
| [Zulip link](https://near.zulipchat.com/#narrow/stream/297873-pagoda.2Fnode/topic/How.20to.20test.20a.20chunk-only.20producer.20node.20in.20testnet.3F/near/396090090) | ||
|
|
||
| #### Benefits | ||
|
|
||
| See [Consequences](#consequences). | ||
|
|
||
| #### Concerns | ||
|
|
||
| See [Consequences](#consequences). | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |