What is CPChain¶
CPChain is a new blockchain infrastructure for the next generation IoT.
Built-in Smart Contract¶
CPChain comes with 6 built-in smart contracts to ensure normal operations of DPoR.
Proxy Register Contract¶
Proxy contract addresses and real contract addresses can be bound through function
registerProxyContract(). Thus, there is no need to modify the address in Go or Solidity when a contract is update. The real contract address can be obtained through function
RPT (abbreviated from reputation) contract calculates RNode’s reputation value. It is a core component of RNode ecosystem. Here is the detail of the RNode ecosystem. Reputation value consists of 5 dimensions, Account Balance（AB), Transaction (TX), Data Contribution (DC), Blockchain Maintenance (BM), and Proxy Reputation (PR). Refer to RPT Evaluation for detailed implementation.
By invoking function
getRpt(), developer can obtain the reputation value of corresponding node. RPT contract can be updated by contract deployer to avoid some faulty nodes maliciously increasing their RPT values. The weights of above 5 dimensions can be customized by 5 PRT contract functions
updateOmega(). The weight of window size can also be adjusted via the function
A campaign contract is called once a user starts mining. If its passes the test of admission contract, it is registered as an RNode by the campaign contract. Furthermore, given the condition that RPT value of the user is one of the top 21 RNodes, it is qualified to claim campaign aiming to become one of the committee members. In other words, that user acquires an opportunity to insert a block into cpchain and obtain some cpc as rewards.
Here we list some vital functions in campaign contract.
claimCampaign(): this function is called when a user claims a campaign. A fee paid in cpc is required by campaign contract as a deposit.
quitCampaign(): this function is called after a user quits the campaign. It is about to get its deposit back via this function.
punishCandidate(): this function can only be invoked by contract deployer. The deployer can detain the RNode’s deposit if it observes any malicious behavior from an RNode.
candidateInfoOf(): functions to retrieve RNodes and their information.
Admission contract is called by campaign contract to verify whether the candidates’ CPU and memory resources match the requirements of mining. Two functions
updateMemoryDifficulty()are implemented to fulfil this verification purpose.
PDash contract is an important app on cpchain, which helps RPT contract to calculate Proxy Reputation. You can click here to get more details.
Register contract is used for recoding the upload history of nodes. It collaborates with RPT contract to calculate nodes’ Data Contribution.
Our data privacy mechanism allows users to deploy and call private contract on cpchain for completing their private transactions in a secure way. Besides the agent P (validator and intermediary) and accounts accepted by the deployer, others are permitted from viewing the private transactions. Although the private transactions are invisible for others who are not the transaction’s participants, some sophisticated key data is recorded and maintained in blockchain. The data is available for audition and validation for private transactions when necessary.
User Scenario Steps¶
- Seller A registers an item via the private contract CT. An item includes name, ipfs_cid, price, description and so on.
- Buyer B checks the registered items on contract CT and chooses some items to buy.
- Buyer B pays money to an escrow contract CE.
- Buyer B sends contract CT an order describing which item to buy and its public key, the one used to encrypt the item’s symmetric key (e.g. AES).
- Seller A receives the notification about the order from contract CT, and checks if the buyer have enough money from the escrow contract CE.
- Seller A sends contract CT the confirmation message attached with the symmetric key encrypted by the buyer’s public key.
- 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 whether it is what it needs.
- The agent P notices the confirmation and transfer money to seller A.
The consensus in LBFT 2.0 is determined by two two committees: Validators Committee and Proposers Committee, which leads to a bipartite committee structure. Proposers and validators, just as their names imply, take the responsibility of proposing and validating blocks respectively.
The consensus process works in a finite state machine which consists of five states idle, prepare, commit, impeach prepare and impeach commit. The former three states are designed for normal cases, and the rest are specializing in handling abnormal cases.
Due to the lack of space in this page, we explicate LBFT 2.0 in Consensus
CPChain Nodes Roles¶
Economy Node: Requires a minimum of 20,000 CPC tokens for participation. Investors who meet this requirement may participate as an economy node and have the right to vote in the community.
Reputation Node: Requires a minimum of 200,000 CPC tokens for participation. Investors with the basic configuration of computing and storing can participate to support the CPChain Open Transmission Protocol (COTP).
Industry Node: IoT Industry partners and CPChain ecosystem’s peer developers have the right to participate as an Industry Node.
A node has to meet one of the following requirements to become a Reputation Node:
1. Economic node + Computing and Storing node: An economy node must lock-up a specific amount of tokens (200,000 minimum and 5,000,000 maximum) for 90 days and must satisfy the software, hardware, and network connection requirements. The locked up tokens have a positive correlation with the basic rewards. Reputation nodes will be refunded after they leave the election.
2. Industry Node + Computing and Storage Node: An industry node will be upgraded to a reputation node once meeting all the hardware, software, and network requirements. Industry nodes must be verified by the CPChain foundation.
Reputation Nodes have the right to be elected as a proposers committee member and to be granted rewards from the Blockchain.
RPT (abbreviated from reputation) value of a node is evaluated by extracting data from blockchain. By employing RPT Contract, a node can evaluates its RPT value by following five dimensions:
- Account Balance（AB),
- Transaction (TX),
- Data Contribution (DC),
- Blockchain Maintenance (BM),
- Proxy Reputation (PR).
Each dimension has a full score of 100 point. And the total score is calculated as:
RPT = 0.5*AB + 0.15*Tx + 0.1*PR + 0.15*DC + 0.1*BM
A account balance score is granted to an RNode according to its account balance percentile among all RNode addresses (excluding CPChain Foundation and Exchange addresses). Score percentiles are demonstrated below.
Transactions here are defined as transactions that exchange tokens for data product. The definition of Transactions can be expanded as the of CPChain ecosystem develops.
Transaction score is evaluated by all transactions statistics. For each transaction record a node finishes,
- 5 points is granted to the node.
- The full score is 100 points.
An RNode can serve as a proxy helping other nodes complete transactions. Its RPT is augmented after assuming the responsibility as a proxy.
Proxy reputation score is calculated according to following rules:
- Once an RNode registers as a proxy, it obtains 10 initial points.
- For each successful transaction with the node’s help as a proxy, it gets 5 points.
- The full score is 100 points.
Uploading data augments RPT value. There are two parts in data contribution, as basic DC score and bonus DC score.
Data contribution score is calculated according to following rules:
- For each file an RNode uploads, the node is rewarded 3 points in DC score.
- The full score of basic DC is 30 points.
- Each time other node purchases a file that RNode uploads, the RNode is rewarded 5 bonus points.
- The full score of bonus DC is 70 points.
Blockchain Maintenance score is calculated given a node’s contribution in proposing a certain block. For a successfully inserted block,
- Its proposer is rewarded 100 points.
- Other committee members are rewarded 80 points each.
- The rest RNodes are rewarded 60 points each.
- Memory: 4GB
- Storage: 256GB
- CPU: Intel Xeon E5-1650 v3 (alike)
- Network: 300Mbps
- Memory: 16GB
- Storage: 1TB
- CPU: Intel Xeon E5-2686 v4 (alike)
- Network: 1Gbps
Node Entitlements & Rewards¶
CPChain’s ecosystem is established by a lot of Internet of Things (IoT) enterprises, developers and users. It is a long-term process. As a result, CPChain will divide the incentive system into two stages. In the first stage, CPChain Foundation would be the main fund provider, for the ecosystem establishment and the chain maintenance. The next stage is mainly performed by the market. With the optimization of CPChain ecosystem and the increase in data sharing and transferring, the reward for RNodes will mainly be generated by smart contracts and market transactions.
In the first stage, reputation nodes’ entitlements will be allocated to two parts:
CPChain will create a reward pool with 5 million CPC annually (1.25 million CPC quarterly, 13,700 CPC daily). The RNodes and the Economy Nodes receive the corresponding CPC reward based on the ratio of the locked margin to the total margin. (Economy Node and RNode will both need a 90-day lock-up session). The detailed process goes as follows:
Each season contains 90 days, which is also named as lock-up period. There are 7 special days served as fundraising ahead of each lock-up period. Each fundraising is overlapped with previous lock-up period. In fundraising, the following operations are allowed:
- All civilians can deposit coin in the reward pool, to become economic nodes or RNodes.
- Nodes that have already had coins deposited in the pool can choose to whether continue deposit the next season or renew the deposit value.
When a fundraising ends, the following rules are applied:
- No one adjusts or withdraw its deposit until next fundraising.
- Nodes that decide to withdraw the deposit, receive the coins.
- Any node that renews its deposit balance get recalculated its CPChain nodes role as economic node, RNode or the rest.
- All nodes with deposit in this lock-up period receive their reward from the pool.
The reward for a certain node from the pool is proportional to its deposit in a season. In other word, the basic reward is calculated as 5000000*d/D, where d is deposit of a certain node, and D is the total value of coins in the reward pool.
Proposers committee nodes are entitled to blockchain maintenance rewards, after it proposes a block and successfully gets it inserted into the chain. As defined in the RNode ecosystem, the annual supply from maintenance is 40 million CPC in the first year, and being decreased by 25% annually for the next four years. Thus, the annual supply for five years is 40 million, 30 million, 22.5 million, 17 million and 12.75 million respectively. After five years, the supply runs out. In other words, no CPC is rewarded after that time.
Meanwhile, CPC Mainnet inserts a block every 10 seconds, which yields around 3 million blocks each year. Therefore, we conclude the reward and supply in the table below.
|Year||Reward||Num of Blocks||Supply|
* Both the first and the fifth year contain a leap day (29 Feb 2020 and 2024, respectively), which results in a larger number of generated blocks compared to the other three years.
Note that in our LBFT 2.0 protocol, an impeach block in inserted into the chain if the proposer is faulty or non-responding. Intuitively, a faulty proposer cannot receive the reward. Hence, the amount of annual supply could be smaller than the one listed in the table above.
Use smart contracts to lock deposit, the functions are as follow:
Determine the node level based on the amount of deposit of the node. lock the deposit to fixed range of length of blockchain. Reward distribution according to proportion of node’s deposits. Connection with Reputation list.
Execution Fee - Gas System¶
All operations in CPC is not conducted free. An amount of tokens are cost as operation fees, whose unit is denoted by Gas. Gas is measured by the amount of computational overheads when executing a certain operation. Every single operation, no matter transaction or smart contract, is executed along with gas deducted.
Here we list important definitions:
- Gas, the unit measuring execution fee.
- Gas Limit, the maximum gas the applicant willing to pay.
- Gas price, the amount the applicant pays for each unit of gas.
Gas is a special unit, measuring the amount of computational overheads when executing a certain operation. Every operation is associated with an fixed number of gas, indicating the computational effort of this operation.
All gas-consuming operations are curated in
An instance is shown below,
demonstrating the value of gas of a non-smart-contract transaction and creating a smart contract.
// Per transaction not creating a contract. // NOTE: Not payable on data of calls between transactions. TxGas uint64 = 21000 // Per transaction that creates a contract. // NOTE: Not payable on data of calls between transactions. TxGasContractCreation uint64 = 53000
Thus, a normal transaction requires 21,000 gas, while a smart contract is created at a cost of 53000 gas.
Gas limit, as its name indicates,
refers to the maximum gas a node is going to pay in a transaction.
Apparently, the equation
gas <= gas limit always holds.
It limits the upper bound of transaction fees in a contract,
and avoid a contract involving unexpectedly high gas.
This kind of situation occurs when an error, like too much loops,
is embedded in the contract.
Gas limit is tunable parameter when a node applies for a transaction. We also offer a default setting for it, preventing the node from being drained out.
Gas price is the fee for each gas a node pays.
By analogy, gas is like gallon when fueling a car.
Gas limit is the fuel tank of the car, limiting maximum gas.
And gas price is the petroleum price per gallon.
Thus, the total fee for a transaction is
gas * gas price.
When a node applies for a transaction, the system calculates a gas price based on transaction history on the chain. However, gas price is also tunable. A node can define gas price at any value as long as it can afford it. Transactions with high gas price have higher chance being selected by committee, and further get inserted into the chain. But it expenses more for the node. In comparison, a low gas price demands low cost of tokens, by sacrificing the possibility of being verified by committee.
The fee of a certain transaction is
gas * gas price.
However, for smart contract transaction involving multiple operations,
fee cannot be determined until the whole transaction terminates.
Thus, when a node applies for a transaction,
it is required to pay
gas limit * gas price tokens.
And after the transaction terminates,
(gas limit-gas) * gas price is refunded to this node.
Note that transaction fee as
gas * gas price is not refundable.
Even the transaction fails, like an abnormal contract involving gas outnumbering gas limit,
the system does not refunds deducted fee.
The rationale is that committee members have assumed their responsibility of
verifying this transaction at the cost of their computing overheads,
which should be rewarded with transaction fee.
In addition, this mechanism avoids malicious nodes
occupying computing capability of the chain at no cost.