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.

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. 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. 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. 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. ⚫ 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. 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. 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. 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. 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. 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. ⚫ 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.