This article was originally published November 2019 on the Incognito blog.
Incognito is live! It’s the beginning of a better, safer internet. This document details the key parameters for Incognito Mainnet v0, and provides the reasons why we selected the initial values for these parameters.
Some of these parameters will likely be fine-tuned over time. Parameter fine-tuning is a crucial part of the Incognito mechanism design. Parameter fine-tuning responsibility is initially handled by the core team, but will be and gradually transferred to the community once self-governance is implemented in early 2020.
There are 179 transactions in the genesis block, which can be viewed here.
- The first transaction pre-mined 5,000,000 PRV and sent it to the core team, who purchased it for $1,000,000 to self-fund the project.
- The second transaction pre-mined 179,682 PRV and sent it to the Incognito DAO. These tokens will be sent to validators who participated in the testnet from July to October. The conversion rate of testnet PRV to mainnet PRV is 1:1.
- The remaining 177 transactions inscribe personal messages written by the founding node operators.
The initial value is 8.
The Incognito Testnet performed the best with 8 shards from July 2019 – October 2019. Incognito will scale the number of shards over time to increase the throughput of the network. The goal is to reach 64 shards in 2020 with our Highway implementation (to be deployed late 2019).
The initial value is 32 validators per shard.
This is the maximum number of validators at a time that can produce blocks for a shard. The goal is to scale up to 256 validators in 2020 with our Highway implementation (to be deployed late 2019).
The initial value is 8 substitutes per shard.
This is the maximum number waiting to be substituted for existing validators in the next epoch. This number should be around 15%-20% of the NUMBER_OF_VALIDATORS.
NUMBER OF SUBSTITUTIONS
The initial value is 4 substitutions per shard per epoch.
This is the maximum number of substitutions that a shard will make in an epoch. We feel that this number should be around 50% of the NUMBER_OF_SUBSTITUTES, to account for some substitutes being offline, or having not yet fully synced the shard block data.
NUMBER OF CANDIDATES
There is no limit on the number of candidates. Anyone can stake to become a candidate.
The initial value is 2MB.
The initial value is 40 seconds.
There are multiple discussions on block latency. While block latency is sometimes really fast (between 2s-10s), it can also be slow, depending on the number of nodes and the number of transactions. At this stage, we opted for a safer number, and to gradually optimize the block latency.
The initial value is 350 blocks or ~4 hours.
Epoch size determines when substitutions happen. If the epoch size is too big, it may affect the security of the network. If the epoch size is too small, too many substitutions happen and data availability could be a problem. Considering the number of nodes at the beginning, we feel that 350 blocks are a reasonable window.
The initial value is 1750 PRV.
Determining the staking amount is both art and science. Our heuristic is to go with the network configuration of 64 subchains (1 beacon and 64 shards), and 256 validators per subchain. If each validator stakes 1750 PRV, the total staking amount of the entire network is:
65 * 256 * 1,750 PRV = 29,120,000 PRV
The total supply of the network is 100,000,000 PRV, so the total staking amount is 29% of the total supply. If someone wants to take control of the network, they need to stake at least 20,000,000 PRV to exceed the pBFT 2/3+1 signature threshold. We feel that 29% is a reasonably safe staking pool. We also don’t want to lock up more than 29M PRV as that could begin to hurt the utility of PRV.
The total block rewards for the first year are 8,751,974 PRV.
Block rewards are reduced by 9% every year. 100% of PRV is fully mined after ~40 years.
Limitations & future work
Fixed committee setup
Note that for Mainnet v.0, 22 out of 32 validators are operated by the core team. These 22 validators are fixed and are not substitutable; only the other 10 validator slots are substitutable. In anticipation of potential issues in the early stage of the network, the core team wants to make sure the issues can be resolved as quickly as possible. The core team will gradually release its validator spots to the community once the network is stable.
We expect to remove this fixed committee setup within 3-6 months of the Mainnet launch.
Fixed block producer setup
Via a round-robin setup, each validator takes turns to become the block producer and proposes a new block to the committee. If at least (2*N/3) + 1 validators confirm that the block is valid, the block will be added to the subchain.
This currently causes a problem. Every 40 seconds, a new block producer is selected. For various reasons such as network delay, CPU usage, or insufficient memory, the last block at height H may not reach other validators in the committee, including the new block producer, within those 10 seconds. The new block producer, now still at block height H-1, starts producing a new block at the same height H as the last block — creating a fork of the subchain.
For Mainnet v.0, we’re utilizing a short-term solution that clearly separates the responsibilities between block producers and block validators.
- There is only 1 block producer per subchain. Its only job is to produce blocks and send them to the other N-1 nodes in the committee.
- The other N-1 nodes in the committee are block validators. A validator’s only job is to verify blocks. It receives a new block from the block producer, verifies it, and collects signatures from other validators on the same block. If it collects at least (2*N/3) + 1 signatures from other validators, it will append the block to its local copy of the subchain.
This solution is not perfect by any means but is a good-enough temporary solution. We’re working on a long-term solution.
We expect to remove this fixed block producer setup within 3 months of the Mainnet launch.
The code is hosted on Github at github.com/incognitochain.
We’d love to hear your thoughts!