Testnet 2.4 Overview

Three major differences comparing with the previous testnet:

1. Shard ID encoding in our address definition
2. Initial support for multi-native-tokens
3. Enabling and testing Proof of Staked Work hybrid consensus

Chain / Shard ID Encoding

Remember in our previous address encoding, an address consists of a normal 20-byte Ethereum address (which is called the recipient of a QuarkChain address) and a 4-byte full shard ID.

To better support re-sharding and dynamic updates without affecting existing shards, we proposed a middle layer abstraction between the whole network and the underlying shards, which is called, well, chains: a QuarkChain network, contains multiple chains, where each chain contains multiple shards. Note that a chain is merely a conceptual layer, all the consensus logic (e.g. root-chain-first-consensus, or cross-shard transaction implementation) still apply to all the shards.

Now the 4-byte full shard ID is encoded as following (using 0x0001000f as an example):

1. Use first two bytes to denote chain ID. In the example the chain ID is 1 (0x0001)
2. The remaining two bytes follow the same encoding as before. Assume chain 1 has 8 shards, 0x000f corresponds to shard 7 because SHARD_ID = FULL_SHARD_ID & (SHARD_SIZE - 1)

Therefore 0x0001000f should be interpreted as chain 1 shard 7.

The benefit of such encoding is that re-sharding can be easily achieved as adding more chains without affecting existing shards. At the same time we are also investigating how to split an existing chain to have more shards.

Some extra notes:

1. Shards under the same chain should follow the same consensus parameters
2. Now the network configuration is using chain as the base unit. For example in testnet2.4, we have 4 chains using ethash PoW algorithm where each chain has only 1 shard, plus 1 chain using double-sha256 PoW algorithm which has 2 shards, and finally plus 1 chain using qkchash PoW algorithm with 2 shards. See the sample config for more details

Support Multi-Native-Tokens

Starting from tesnet 2.4, initial support of multi-native-tokens will be launched, including following functionalities:

1. Requesting different tokens through the faucet
2. Sending / receiving tokens using the web wallet

There are certain limits at the same time, which should be implemented gradually during later iterations:

1. Can't specify tokens for gas usage
2. Can't add new tokens without changing consensus parameters

Proof of Staked Work

We also enabled Proof of Staked Work (PoSW) hybrid consensus on certain shards to better understanding its cryptoeconomic implications. In a word, PoSW encourages miners to stake certain amount of tokens such that he/she can mine more easily. When combined with proper stake slashing conditions, this consensus mechanism can help the network better guard against 51% attacks. For details and an analysis using recent ETC 51% attack as an example, please take a look at this article.

The current stage includes implementation of difficulty lowering for miners who stake more than certain amount of TQKC tokens (see the end of this page for actual numbers) during a certain range of block period, plus a lock-up period for miners. Let's use an example to illustrate the ideas.

If we use a window of size 10, and use 100 TQKC as the minimum stake to enjoy the lower difficulty benefit, a miner without any tokens will mine every block with normal difficulty; if he has 100 TQKC, then 1 in 10 blocks he can mine with lowered block difficulty; if he has 10 * 100 = 1000 TQKC, then every block he decide to mine can have a lower effective block difficulty.

Also, after he mined a block, he can't move the stakes out of the coinbase address for 10 blocks, which is to help estimate stakes accurately.

---

Keeping all those features in mind, following is a summary of our network setup for testnet 2.4.

chain 0: running ethash, 1 shard, no PoSW.

chain 1: running ethash, 1 shard, PoSW requiring 10,000 TQKC minimum to lower the difficulty once in a window (256 blocks).

chain 2: running ethash, 1 shard, PoSW requiring 20,000 TQKC minimum to lower the difficulty once in a window (256 blocks).

chain 3: running ethash, 1 shard, PoSW requiring 40,000 TQKC minimum to lower the difficulty once in a window (256 blocks).

chain 4: runing double-SHA256, has 2 shards, no PoSW.

chain 5: running qkchash, has 2 shards, no PoSW.

For PoSW, when the block difficulty is lowered, effective diff = actual diff // 20.

Supported tokens include: TQKC (default token), QBTC, QETH, QAAPL, QTSLA, QI.