Both beacon chain and shard chains use the same consensus mechanism to produce new blocks.
Incognito implements the more energy-efficient Proof-of-Stake [King and Nadal, 2012] in lieu of Proof-of-Work [Dwork and Naor, 1992; Juels, 1999]. Anyone can be a validator candidate by staking PRV. The minimum stake is 1,750 PRV. The beacon chain randomly assigns validators for each shard.
Each validator has one vote. A block is considered valid if it collects more than ⅔ valid signatures from the validator committee.
Practical Byzantine Fault Tolerance (pBFT)
Incognito implements a variant of pBFT [Castro et al., 1999] at the consensus layer. We further improve its efficiency by employing the BLS-based aggregate multi-signature scheme AMSP [Boneh et al., 2018].
At the beginning of each round, the smallest id validator is the first proposer. The proposer proposes the block and broadcasts it to the shard committee. Proposers take turns in a round-robin fashion, based on their id in the current committee setup.
If a proposer fails to propose its block in less than the time taken to build the last three blocks, the next validator will be elected as the new proposer. If a proposer fails to propose its block on time, it will lose its reward for that epoch. If a proposer fails to propose its block three times in an epoch, it cannot be a committee member for the next three epochs.
Figure 3. Incognito implements a variant of Practical Byzantine Fault Tolerance.
Validators play an important role in the consensus mechanism. They collectively verify transactions and earn rewards in return.
Validators earn Privacy (PRV), the native coin of the Incognito network, for every block created (Section 8).
When someone makes a privacy transaction (say, in pBTC or pDAI), validators also earn transaction fees in that currency.
We introduce a few parameters to explain the validator life cycle. These parameters are fine-tuned over time, as parameter fine-tuning is a crucial part of Incognito mechanism design.
|X||The staking amount||1750 PRV|
|P||The maximum number of substitutes per shard||P=A*K|
|M||The maximum number of validators per shards||32|
|K||The maximum number of substitutions per shard in an epoch||M/10|
|A||The ratio between substitutes and substitutions||2|
|N||The number of shards||8|
|B||The block time||40s|
|T||The number of blocks in an epoch||350|
Table 1. Validator parameters.
The life cycle of a validator is as follows:
- The user stakes X to become a candidate and waits until the next epoch for random selection. The maximum waiting time is T.
- The candidate is randomly selected by the beacon chain to become a substitute for a specific shard Si with i ∈ [0, N).
- If the number of current substitutes is less than P, the candidate automatically becomes a new substitute for shard Si.
- Otherwise, the candidate will wait until the next epoch for the next random selection.
- The substitute must sync all block data of shard Si in advance.
- If the number of current validators in shard Si is less than M, the substitute automatically becomes a new validator for shard Si at the next epoch.
- Otherwise, the substitute will replace an existing validator in shard Si at the next epoch.
- The new validator starts producing blocks for shard Si.
- The ex-validator becomes a normal user and can stake again (go back to the beginning of the life cycle).
Figure 4. The life cycle of a validator
BLS-based Aggregate Multi-Signatures from Pairing
As the number of validators grows, the total size of all validator signatures also grows and impacts the block size. To solve this problem, we implement the BLS-based aggregate multi-signature scheme AMSP [Boneh et al., 2018].
When the block proposer proposes a new block, all the validators in the current committee verify the block and broadcast their signatures. All of these signatures are then aggregated into a single aggregate signature. Regardless of the number of validators, the size of the aggregate signature is only 32 bytes.
The implementation is mainly in the Consensus component in the Incognito architecture.
Figure 5. The layered Incognito architecture.
The code is open-source on Github with links to specific packages provided below.
- pBFT . For the consensus algorithm, Incognito implements a variant of pBFT (Practical Byzantine Fault Tolerance). Its code is in the blsbft package.
- BLS. For multi-signature aggregation, Incognito implements BLS Multi-Signatures. Its code is in the blsmultisig package.
- RNG. For random number generator, Incognito currently uses Bitcoin block hash. We’ll explore other RNG solutions in the future. Its code is in the btc package.
We have proposed a new approach to scale privacy on cryptonetworks by applying sharding on privacy transactions to increase throughput for Incognito. Incognito throughput scales out linearly with the number of shards. The more shards we add, the more transactions it can handle.
Previous Topic: Privacy at Scale with Sharding
[Boneh et al., 2018] Boneh, D., Drijvers, M., and Neven, G. (2018). Compact multi-signatures for smaller blockchains. In International Conference on the Theory and Application of Cryptology and Information Security, pages 435-464. Springer.
[Castro et al., 1999] Castro, M., Liskov, B., et al. (1999). Practical byzantine fault tolerance. In OSDI, volume 99, pages 173-186.
[Dwork and Naor, 1992] Dwork, C. and Naor, M. (1992). Pricing via processing or combatting junk mail. In Annual International Cryptology Conference, pages 139-147. Springer.
[Juels, 1999] Juels, A. (1999). Client puzzles: A cryptographic countermeasure against connection depletion attacks. In Proc. Networks and Distributed System Security Symposium (NDSS), 1999.
[King and Nadal, 2012] King, S. and Nadal, S. (2012). Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. self-published paper, August, 19.