Skip to content

nep-0514.md

Latest commit

 

History

History
165 lines (110 loc) · 5.49 KB

nep-0514.md

File metadata and controls

165 lines (110 loc) · 5.49 KB
NEP 514
Title Reducing the number of Block Producer Seats in `testnet`
Authors Nikolay Kurtov <nikolay.kurtov@near.org>
Status Final
DiscussionsTo #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.

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
  2. Release owners or developers of features start a lot of validating nodes to
  3. ensure testnet gets some chunk-only producing nodes.
  4. 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

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

Benefits

See Consequences.

Concerns

See Consequences.

Copyright

Copyright and related rights waived via CC0.