Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Contentos. The Decentralized Global Content Ecosystem. Technical White paper


Published on

Contentos Technology White Paper
Contentos is a blockchain system that concentrated on the content service. The system provides the
account privilege level and authorization management function that could keep account security as
much as possible as well as cater to flexible operation demands. The inserted economic rules
encourage users to contribute the value contents to system and enhance interaction and degree of
participation. For the perspective of blockchain consensus mechanism, Contentos adopts dPoS which
greatly improves TPS comparing with PoW. On the basis of dPoS, it also invites BFT mechanism to
further improving service response velocity and to realize iBFT algorithm. It is the consensus
mechanism that could automatically be adaptive in line with system’s dynamic parameters.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Contentos. The Decentralized Global Content Ecosystem. Technical White paper

  1. 1. Contentos Technology White Paper Contentos is a blockchain system that concentrated on the content service. The system provides the account privilege level and authorization management function that could keep account security as much as possible as well as cater to flexible operation demands. The inserted economic rules encourage users to contribute the value contents to system and enhance interaction and degree of participation. For the perspective of blockchain consensus mechanism, Contentos adopts dPoS which greatly improves TPS comparing with PoW. On the basis of dPoS, it also invites BFT mechanism to further improving service response velocity and to realize iBFT algorithm. It is the consensus mechanism that could automatically be adaptive in line with system’s dynamic parameters. Based on JSONRPC’s interface service, Contentos supports application to integrate through HTTP, HTPS or Websocket. The system also provide the smart contract function which allows developers to leverage in dAPP instantly as well as cater to the customized demands at the most extent. In order to further improve the convenience and usability of the smart contract system, Contentos opens the abundant API for smart contract which not only support the data check and account transfer of the blockchain but also sustain the most comprehensive content management and the flexible transfer among the contracts. Targeting to the common users’ business demand, Contentos also offers a batch of smart contract templates, reducing the technological threshold of the smart contract application and be easy to more users’ fast deployment. 1.Consensus Mechanism 1.1 Design Philosophy It is restricted to the CAP theory in the perspective of computer science: at most, a distributed system could cope with two if the three items of consistency, availability and partition tolerance. Contentos refers a lot of fundamental design and theory, studies explicit treatment network partition and maintains the balance among the three items by optimizing the consistency and availability of the data. Hence, it could greatly improve efficiency, irreversibly and openness of the whole Contentos network. Based on the chain, dPoS algorithm inclines to select the high availability rather than the high consistency. Because the high availability means that all transactions could be confirmed but they shall cost at the consistency copy of the whole network. But if based on BFT, it will incline to select the high consistency.
  2. 2. On the basis of BT, Contentos realizes a kind of smartly and dynamically adjusted consensus algorithm iBFT(Inteligence ByzantineFault Tolerance). BFT consensus algorithm has three consensus models: ⚫ Linear Model--greatly reducing communication information, saving network resources, serving more blockchain transactions; ⚫ Timely Model--sacrificing certain network resources, block could reach the consensus quickly so as to reduce the blockchain transaction confirmation time; ⚫ Mixing Model--Contentos network could ensure the confirmation time with saving the network resources better, possessing the advantages of two consensus models; The consensus model of Contents is modularization design, supporting hot plug, customizable, configurable smart and dynamic selection. Under the smart selection mode, the intelligent algorithm will select the most proper consensus model in accordance with the network computing power, bandwidth, transaction confirmation quantity, network congestion and other serial factors. 1.2 Election Regulation Bookkeepers Contentos: based dPoS algorithm, it realizes the public election of the bookkeepers. All the users possessing COS in Contentos network have the rights to apply for being the bookkeepers and the users enjoying COS have quality to vote. Each person could vote more 30 tickets and the top 20 knots are responsible for manufacturing block. For the left one assigned quota, the knots out of the top 20 could generate the block in turn. The 21st knot is called the bookkeeper. Contentos could generate a block for each 3 seconds and at any time, one of bookkeepers has right to manufacture the block and generating 21 blocks for each round. At the beginning of the round, the 21st bookkeeper is selected from COS possessor and the production order of the bookkeeper is decided by 2/3 or more bookkeepers. 1.3 Consensus Model Design In the Contento blockchain network, there are totally m bookkeepers and each slot is a view on the polling chart S (w1, w2, ..., wn), called as s. In addition, the block is b and height is h, father block Hash is H and the i bookkeeper knot corresponds with <b>oi of the signature of block.
  3. 3. Linear Consensus Model 1.On a timestamp, the bookkeeper w1 production height is h1’s block; 2.The follow-up bookkeepers continue to generate h2, h3, h4..., generating a block means that the current bookkeeper ensure the block between the last block generation height to the current block height; please note that the bookkeeper does not confirm the block generated by themselves; 3.When the confirmation number of the block with hi height reaches to 2/3 n+1, the block with hi height enters into Prepared status; 4.For further bookkeeper to go on generating blocks, when the block number under Prepared status reaches to 2/3n+1, according to Prepared status order, the previous 1/3 blocks enter into Committed states, becoming the irreversible blockchain database. Assumed that there are 4 bookkeepers in Contentos network: Timely Consensus Model 1. In a timestamp, bookkeeper wt generates block b, and broadcasts after signature. The prerequisites message: <PrePrepare<s, b, H, h, <b>ot> 2. Bookkeeper knot: after receiving the prerequisites for the first time, the verification information is valid and then broadcasts the preparation information. 3. When bookkeeper knot wi received 2f other knot signature’s preparation information at least, the block enters into the Prepared status which confirm information to all knots <Commit <s, b, H, h, <b>ot> 4. After bookkeeper knot wi received 2f confirmation information, it will be deemed that the consensus of the block is consist, the block enters into the Committed conditions and will be persistent to the blockchain database.
  4. 4. Mixing Consensus Model 1. In a timestamp, the bookkeeper w1 generation height is h1’s block; 2. The continuous bookkeeper will go on generate the block h2, h3, h4... For generating each block, the current bookkeeper will make a confirmation from the next block of last block height to the current block height; 3.When the confirmation number of a height hi’s block reaches to 2/3n+1, the block whose height is hi will enter into Prepared status and transfer <Commit> information; 4.When current bookkeeper broadcasting height is hi block’s preparation information <Commit<s, Hi, Hp, h, <b>o>, after all bookkeepers received <Commit> information, it will verify block and change height hi’s block, entering into the Prepared status and transferring <Commit> information; 5.All bookkeepers collected 2f confirmation at least, it is deemed that the block consensus is reached, the block enters into the Committed status and be persistent to the blockchain database. Byzantium Punishment The difficult points of the Byzantium Punishment is that there might be several proposals in the system at any time and the process to complete the total consistency is quite hard and encounters many barriers. When making the proposals, the bookkeepers pay the quite low cost which aggravate the generation of vicious Byzantium knot. For example (including but not limiting): ⚫ Bookkeepers’ illegal block generation ⚫ Bookkeepers’ inefficient block generation or no generating for many times ⚫ Bookkeepers’ disorder block generation or consensus vote
  5. 5. ⚫ Bookkeepers’ repeated consensus vote to the different block with the same height After acting any invalid behaviors, the bookkeepers will be managed and controlled by Cententos whose account charging right will be restricted. In addition, Contentos adopts the economic punishment will further hinder bookkeepers’ behaviors. The bookkeepers must pay the cash deposit firstly and then participation the block generation and consensus formation. If a Contentos produced by a bookkeeper is deemed as the vicious action, the cash deposit will be confiscated. The add of the cash deposit guarantee the cost of the bookkeepers’ evil behaviors. 2.Economic System ⚫ Contentos system token identification is COS which participate all the negotiability actions. Under the current version, the negotiability means the accounts transfer before the wallet. ⚫ Possessing the token will not gain the extra rights and benefits. If needing to obtain the system right, they shall need to lockup the current token, being the proof for interest-free. Within the system, the identification of the proof is VESTS. The possess number of VESTS directly decides on the influence of the system operation, for example it could change the distribution relations of the bonus pool. The sufficient VESTS also provide the Witness quality for competition. ⚫ The ratios of COS and VESTS is constant as 1:1 ⚫ The Contentos system generates a new block for each three seconds. When producing the new block, the new VESTS will be added into the bonus pool ⚫ The mathematical model decides the VESTS generation number of each block. If necessary, all council members will interfere the model through voting so as to adjust the newly added VESTS number so as to make the system economy cater to the productivity demand ⚫ All users could share VESTS from the bonus pool by virtue of taking part in the system activities. ⚫ The developers of Dapp will gain 10% award of the whole bonus pool at most. ⚫ At present, the main activity is “creating contents” which includes uploading videos as well as making comments. In addition, the former could share 63% benefits of the bonus pool and the latter could share the 13.5%. The bonus pools is accumulated. When a new block is g appearing, it will find whether there is a qualified bonus target. If no, the new generated bonus will be accumulated to the bonus pool. ⚫ 9% bonus of the new block will enter into Witness’s account as the encouragement ⚫ The final 4.5% benefits settlement is quite special which is the prize for the content moderation. By virtue of pledging a part of VESTS, the users could moderate the video. After submitting the moderation reports, the arbitrators will check and vote whether the reports are valid or not. If yes,
  6. 6. the pledged VESTS will be returned and the users also could gain the award by ratio from the bonus pool. If no, the pledged VESTS will be added into the report bonus pool. The report bonus pools could not be accumulated forever and each 1,000 blocks could reset the report bonus pool. If there are the qualified targets at the reset time, they will be awarded, otherwise, the VESTS in the pool will be put into the bonus pool and comment award pool half and half. The mechanism is used to ensure “effective report encouragement means and preventing speculative report”. In special, if the comment or report of a video or a comment has already passed the arbitration, the report application will be rejected directly. ⚫ The award of the creators and observers shall abide by the same algorithm which is called “Past Window Weight Cumulative Calculation Method”. For a creation and comment, the gained VESTS number for the settlement time is mainly depended on three factors: first, current “ past accumulated rshares”; second, current size of the bonus pool and third, the creation’s rshares. ⚫ rshares is used to describe the weight after the creation is voted (liked). The value is decided by two elements the vote users’ VESTS and users’ VOTE POWER. The latter is computed by a complex formula. After computing the VESTS and VOTE POWER, it could gain users’ rashare. All the rashare for voting the creation is rashares. ⚫ When a creation is settled, its rshares will be accumulated into the “past accumulative rshares”, namely p_rshares. In order to prevent p_rshares only grows, it also regulated p_shares’ attenuation function. To be precise, when generating each block, p_shares will attenuate 3/(86400*17)p_shares’ number. It also means that a rshares will continue to affect settlement within 17 days. ⚫ If knew p_shares, rewards and a creation’s shares on the settlement knot, the author for this creation will gain the shares * (reward / p_shares) awards. ⚫ Specially, although the creation and comments abide by the same algorithm, their p_shares accumulative functions are distinguished. The creation is simple linear accumulation and the comment bonus pool is the square rooting algorithm. ⚫ The window period for a creation from issuing to settlement is 7 days. And the current time + 7*86400 is the settlement time and the settlement is the only one. If voting the creation who surpass the window period, the vote will be neglected directly. ⚫ The COS and VESTS could mutually transfer. The procedure from the COS to VESTS is Power up and the weight will increase. On the contrary, it is called Power down. ⚫ The power up transformation is instant and could transfer their own COS to other VESTS account. ⚫ Power down transformation is progressive. After submit the application, you could fetch 1/13 of the transformation amount for each weak and finish the fetch for 13 weeks. And it only could transform VESTS to their own COS account. Each user only could have a power down
  7. 7. application once. 3. Account System Account name is the sole identification of the Contentos blockchain account. The valid account name include 3 to 13 characters and each character could be the random low case English letters, Arabic numerals or period. The length and character collect’s restriction conditions almost could not increase users’ name selection difficulty. But Contentos system could greatly reduce storage in engineering and improve title check match efficiency. 3.1 Limitation and Authorization Contentos account has 3 built-in privilege levels: Owner, Active, Posting. ⚫ Owner Limitation: enjoying the absolute control over the account and could make all operation. ⚫ Active Limitation: excepting modifying account information, it could make all operation. ⚫ Posting Limitation: only could make social operation, such as delivering contents or voting; avoiding making account transfer, buy and sell and other operation, affecting the account asset. Built-in limitations are correspondent to a pair of public and private keys. The three pairs of public and private keys are generated when the account was established. The users could log in by one of the private keys, possessing the correspondent jurisdiction level. For example, applying Posting private key to log in, the users could only deliver social contents and could not make account transfer and modify the account information. According PoLP, users applies the proper private key to log in will greatly reduce the account security risk. In most applied scenes, the users shall not adopt Owner private key to log in. Contentos applies digital signature to authorize the privilege. Before user issuing a transaction, they must log in by their private key. After witness knot receiving transaction, it will firstly verify whether the digital signature is legal or not and check whether the signature key is equipped with the limitation level to implement transaction. If no passing, transaction will be rejected to implement. Sometimes, users will share their own privilege with one or more account, namely the authorization requirement. For example, an organization O’s official blog demands several maintainers and each maintainer could issue contents by the name of O. In order to realize the group blog function, the account O needs to authorize its posting jurisdiction to a group of maintenance account. A maintainer
  8. 8. M issues an article and state the author is O and signs with his own private key (M). Contentos will check the signature private key is equipped with O’s posting limitation. Because it authorize to M, thus M’s signature could be accepted. By virtue of authorization, M could issue the content on behalf of O without knowing O’s private keys. Contentos account limitation’s authorization is always existed. With default condition, Owner/Active/Posting limitations are respectively authenticated to the correspondent account public keys, namely only the users possess these limitations. For any limitation level, the users could modify authentication information, designed one or more authenticated targets. The authenticated targets are divided two kinds: ⚫ Other accounts’ public keys ⚫ Other accounts’ users name and limitation For the second situation, its is a little bit complicated but quite flexible. For example, user_a authenticates his active to user_b@active, user_b authenticates his active to user_c@active. In this way, it forms a authentication chain. The user_c applies active private key to log in and possesses user_a’s active limitation, although user_a does not authenticate to him directly. Contentos support the identification of authentication chain but also restrict the length of the authentication chain for its features. But luckily, most users only need the short authentication chain. Contentos also sustains the weight distribution to authentication for more complicated authentication requirements. For example, admin’s owner limitation is authorized to 3 accounts: user_a, user_b and user_c whose weights are all 0.5 so that each of them gain “half” authentication. Only two of them co- sign could apply admin’s owner authentication. The private key leakage of single account will not affect admin account security. Such multiple users signature mechanism could greatly reduce the authentication introduction’ security risks. 3.2 Parallel Privilege Authentication Contentos account authorization management and the jurisdiction authentication mechanism based on digital signature is the upper application logical decouple and a “read only” procedure. Although some transaction will modify authorization information, the modification could be valid after block generation. Hence, all transaction jurisdiction authentication could parallel operation which do not need to rely on complicated application logy. Moreover, p2p knots could start the jurisdiction
  9. 9. authentication operation when just receiving transaction. These transactions are officially packed to block. For implementing, they do not need to authenticate again. Jurisdiction authentication is a computing-intensive process which need more operation time. The parallel limitation authentication could greatly improve Contentos operation efficiency totally. Through replay blocks re-generating blockchain status, it also could omit the authentication. Because the all transactions included by a legal block has be authenticated when entering into the block which also could improve the replay’s velocity obviously. 3.3Account Recover When users’ Owner private key is stole and modified, the users could find the account back through Contentos’ account recover function. The users need to provide one of valid Owner private keys within 30 days. The designed auxiliary account approves and submit the account recover application to reset the Owner key. All accounts have their own auxiliary account. With the default conditions, recover auxiliary account is the creator of the user account. The users could modify their own recover auxiliary account to set their trust friend’s account. Recover auxiliary account is different to authorize the Owner limitation to other accounts because recover auxiliary account only could participate the account recovery process but not have any limitation of the account so that it could submit any transaction on behalf of users. 4.Smart Contract and Virtual Machine Technological Background COS smart contract applies C/C++as the major programming language and the bottom applies Web Assembly virtual machine. WebAssembly (WASM) is a new emerging Web standard, gaining the wide supports from Google, Microsoft, Apple and other major companies. Till now, the most mature tool chain for formulating application and WASM code compiling is CLANG/LLVM and C/C++ compiler. The tool chains developed by the third-party include: Rust, Python and Solidity. Although these languages seems to be simple, their features might affect the scope of your application program. Contract Capacity
  10. 10. Users could compile the contract developed by themselves into WASM knots to deploy into the blockchain and Contentos would provide a set of API supporting contract’s external allocation. COS smart contract offer similar development capability under Ethereum ERC 20 regulations and it also could post a message, like, data statistics and other operation through the API provided by system. Contract supports the hot upgrade and could assist users to amend BUG fast. Contract Limitation Considering the fairness of user applying Contentos blockchain service, each user smart contract implementation period, CPU application, network, internal resources will be limited. Development Compilation Applying C/C++ as the major programming language, we will provide a set package-well COS C/C++ API supporting contract development. The set API enjoys the stronger security and is more convenient to apply and read. Offering contract compilation script could be convenient compilation contract, generating WASM section code files and ABI interface files. Security Mechanism Firstly, contract is operating a sandboxed implementation environment. WASM guarantees a higher security and availability through reducing the semantic dangerous features as well as keep C/C++ largest compatibility. Before the contract operation, we will firstly make strict limitation check and resource limitation of the contract so as to ensure the security. 5.Virtual Machine Content API Apart from the capability of the virtual machine, the virtual machine of contentos also could provide enough and abundant ram chain’s API so as to assist the content developers. Hence, the developers could realize various high level functions through composing Dapp. The planned API includes but not is limited to the following aspects: ⚫ Users’ any raw operation on the chain, such as obtaining the specific contents of a transaction ⚫ The virtual operation data generated on the chain, such as acquiring the witness bonus value within certain period ⚫ Submitting the native chain writing operation, such as pressing ahead posting a message or liking
  11. 11. ⚫ Mutual operation among the contracts, such as deciding the contract implementation flow in accordance with another contract’s implementation results Example Taking a specific example: promotion party A needs to publicize an article so as to cooperation cyber celebrity B. A agreed with B that if B could create a propaganda video and win over 10,000 likes within 7 days, A will give B 100 COS as bonus. Such flow could adopt contract API to realize: 1. Firstly, A deploys the contract and pledges the 100 COS to the contract 2. When B issuing the video, the contract is launched 3. After 7 days, the contract will be implemented automatically by the likes number of the video. If the result caters to the agreement, the account transfer API will transfer the 100 COS to B’s account. Otherwise, these COS will be returned to A’s account according tot he contract. 6.Contract Model At present, most public chain could provide the contract function but does not offer well contract model and automatic deployment contraction function which make the users could enjoy the advantage of contract any more. Contentos public chain is quite convenient and easy in this field. The public chain could collect dozens of common contracts and develop easy API interfaces to these contracts. Dapp’s developers could submit model integration suggestion and will directly update to the core code of the public chain after received by the developing group.