Dear Community,

2018 is coming to an end. I believe for many projects, 2018 has been a difficult year filed with surprises, expectations, loss, and failures. No matter how the environment changes, CPChain will stay focused on our mission, stay true to ourselves, and aim to make progress towards our goals on a daily basis.

After countless nights of design and development, we are pleased to announce that the Alpha version of CPChain’s mainnet is officially released today.

CPChain’s R&D team has successfully completed the core design of private transactions, consensus agreements, and incentive mechanisms. We are presenting to you a new distributed infrastructure connecting the entire data sharing ecosystem of the Internet of Things.

There are several technical highlights in the mainnet (Alpha) as follows:

A) Private Transactions

In Ethereum, all transactions are open and transparent. Therefore, it is difficult for Ethereum to support online transactions which are privacy related. CPChain allows users to deploy and connect to private contracts on the chain to complete private transactions more securely. Except for the agent (Agent: acting as the certifier and middleman in the transaction) and the user himself, no third party can view the private transaction process. Some key data in the transaction process will be recorded and maintained on the blockchain for trial and verification in the private transaction process. In private data transactions, private contracts are deployed by agents. Agents will also deploy public contracts as transactional custodians.

The whole private transaction process will be as follows:

1. Seller A registers an item via the private contract CT. An item includes name, ipfs_cid, price, description and so on.

2. Buyer B checked the registered items on contract CT and chooses which items to buy.

3. Buyer B pays money to the escrow contract CE.

4. Buyer B sends the contract CT an order about which items to buy and his public key, which is used to encrypt the item’s symmetric key(e.g. AES).

5. Seller A notices the order from contract CT, and checks if the buyer has enough money from the escrow contract CE.

6. Seller A sends the contract CT the confirmation message attached with the symmetric key encrypted by the buyer’s public key.

7. Buyer B receives the encrypted symmetric key, and then decrypts it. With the symmetric key, the buyer B can decrypt the data on IPFS and then confirm that it is what they need.

8. The agent P notices the confirmation and transfers money to the seller A.

Many data transaction scenarios need to protect the privacy of both parties, including both parties’ identity and transaction information, etc., while using the tamperproof nature of blockchain technology to ensure traceability and verifiability of the transaction. This requires us to build an endogenous, reliable, and tamperproof private trading mechanism.

Under such requirement we developed a private transaction mechanism on CPChain. Private Transactions implement a scenario where parties A, B, complete the transaction under the witness of Agent C. Transactions cannot be detected externally, but will leave a record on the blockchain for future traceability and verification.

CPChain pioneered the integration of private transactions and content-addressable distributed file systems, such as IPFS. By distributing encrypted private transactions on IPFS, it greatly reduces the storage pressure on the chain and makes massive private transactions of data possible; on the other hand, the distributed nature of IPFS is utilized to ensure network access to transaction information.

B) Consensus and DPOR

— — LBFT Algorithm inside Committee

Delegated Proof of Reputation (DPoR) consensus protocol achieves a rapid internal consensus within the committee using Lightweight Byzantine Fault Tolerance (LBFT). The algorithm consists of two phases (see Figure 2), which are the block release phase and verification phase (the committee node will verify and sign the block after receiving the new block). At present, it can realize the fault tolerance of up to 1/3 of nodes’ malicious behavior or downtime within the committee, and the optimized supervision and alternative mechanism can be realized after the formal mainnet launch in March. In addition, LBFT is designed with a fault-tolerant mechanism for extreme situations, that is, most committee members are down or have colluded. This will enhance the stability and robustness of the system.

LBFT 2.0

Based on the LBFT 1.0, we propose the LBFT 2.0 to achieve a fast consensus within the committee on the premise that the algorithm is more stable.

First of all, unlike the 1.0 version, the committee was divided into the proposer committee (referred to as “Block Man” by CPChain internally) and the validator committee (referred to internally as “Verification Man”). Members of each proposer committee are elected internally and they will create blocks one by one. For a particular moment, only one legitimate proposer has the right to create a block. Correspondingly, the members of the validator committee use the consensus agreement to determine whether the new block of the proposer is legal. The LBFT 2.0 can tolerate collusion or timeouts from the proposer committee or no more than one-third of the validator committee members.

Unlike traditional PBFT (Practical Byzantine Fault Tolerance), we do not rely on a specific node to accept a request. The proposer broadcasts its own block directly to all members of the validator committee, but he cannot participate in the verification of the block himself; at the same time, the validator committee members do not have the permission to create blocks. This mechanism guarantees the independence of block creation and verification, reducing the motivation and possibility of the members of the committee colluding.

For the proposers that collude or timeout, we will introduce an impeachment mechanism. As long as two-thirds of the members of the validator committee vote that the proposer does not work properly, the validator committee will be able to make an impeachment block and thus impose a penalty on the proposer (deducting the proposer’s deposit for committee election). This will help guarantee the liveness and safety of LBFT 2.0.

The detailed process for achieving rapid consensus through LBFT 2.0 is as follows:

1. Pre-prepare Phase

When the proposer creates a new block, it broadcasts the information to all members of the validator board. For each validator who receives the block, he will first determine if the block is legal. Legality refers to the structure of the block, the timestamp, and whether it is the turn of the proposer. If the judgment is legal, the header of the block will be used as the subject to generate a “prepare message” after the validator signature is obtained. The “prepare message” will be broadcasted to all validators and it will enter the prepare phase; otherwise, it will enter the impeachment phase, which will be described in detail later.

2. Prepare Phase

The validator entering the prepare phase will be waiting to collect the “prepare message” signed by other validators. For a same data header, once a validator collects more than two-thirds of the committee members’ signatures for “prepare message”, the node will generate a signed commit message and broadcast it to all validators. We call such a validator a “prepared validator”. The event of collecting the signature of more than two-thirds of the members will be defined as a “prepared certificate”. This commit message will indicate that the validator has obtained a “prepared certificate”.

3. Commit Phase

The validator that collects the “prepared certificate” will enter the commit phase. After broadcasting its own commit message, it will also receive commit information from other nodes. Once it receives at least two-thirds of the committee members’ commit message, the node will get another certificate: “committed certificate”, indicating that the request reached the committed state on this node. At this point just by this node, we can conclude that the request has reached the prepared state in a quorum, that is, the nodes of a valid group have agreed that the block is legal.

A node that has obtained a committed certificate will broadcast a validate message to all nodes. The message includes complete information about the block and the signature of everyone in the quorum. The node that received this validate message can add this block to its local blockchain. The validators will also re-enter the pre-prepare phase, waiting for the next proposer to create a block.

Appendix — Impeachment

The Impeachment mechanism is a solution for the validator committee to deal with the situation that the proposer is not functioning properly. It guarantees the security and activity of LBFT 2.0. The core idea of impeachment is that the validator committee will produce an impeachment block and impose certain penalties on the proposer. Impeachment contains two phases: impeach prepare and impeach commit.

Impeach prepare phase

When a validator thinks that the proposer is not normal (Creating block timeout or the block created is illegal), it enters the “impeach prepare phase” and creates an impeach block. All non-faulty validators generate the same impeachment block, and the transaction of that block is a penalty for the abnormal proposer. The data header of this impeachment block will be broadcasted as an impeach prepare message to all validators. At this point it will continue to wait for other “impeach prepare messages”. After it collects such messages from more than two-thirds of the validators, it will obtain an “impeach prepared certificate”, then entering into the “impeach commit phase”.

Impeach commit phase

Similar to the commit phase of the normal consensus process, the validator that just entered the “impeach commit phase” will issue an “impeach commit message” and then wait for the “impeach commit message” from the other validators. Once the “impeach committed certificate” (two-thirds of the validators’ “impeach prepare message”) is assembled, the validator will broadcast an “impeach validate message” to all nodes, the contents of which are the impeachment block and the signatures of the members of the quorum that agree with the impeachment block.

The node that receives the message, along with the validator that issues the message will add the impeachment block into the local chain. The validator will re-enter the pre-prepare phase, waiting for the next proposer to create a block.

C) Website Amendment

With the release of the CPChain Alpha Mainnet, the CPChain website also needs to be updated. In this website amendment, we have added a blockchain browser, as well as a developer and community page, with additional improvements to come. Under the developer section, we have included CPChain’s technical documentation. Developers can create a private network through the use of the technical documentation, or by visiting our Alpha mainnet (visit URL:Http://docs.cpchain.io/index.html). Under the blockchain browser section, visitors can view key data such as block height, transaction volume, RNode status and current proposer.

The launch of the Alpha version of the mainnet is a major step forward for CPChain. We invite everyone to participate in the testing of the mainnet, and we value all suggestions for ways to improve our public chain, browser, user experience, etc. Our goal is to create an open, efficient, and secure ecosystem for IoT data sharing. For that, we welcome collaboration with our peers and community.

At present, the design of the mainnet is improving on a daily basis. After the implementation of our community’s recommendations and resolution of any inefficiencies, the official launch of the CPChain mainnet will take place before the end of March, 2019. In the following days leading up to the official launch, we will continue to work day and night to perfect our mainnet.

During the leadup to the official release, we will launch a series of community driven activities focused on the CPChain Alpha Mainnet, as well as publish multiple informative articles and videos. Thank you for your continued attention and support for CPChain, your patience will pay off!