Recently we have received an analysis report from a 3rd party research lab (United Labs of Blockchain Technology) from China on the comparison of technical features of Loom/Tron/Cocos-BCX.
Orginal report in Chinese can be downloaded here: https://drive.google.com/open?id=1y_21VnIkVdGpHppv2A8vG9RmNA4dohOB
We higly appreciate the research and studies made by United Labs of Blockchain Technology and have translated the report into English and publish here below to share with more people interested in blockchain.
You can also download the english version here: https://drive.google.com/file/d/18hxMvwVHGyhOENU_pxwq4O6-CIs4U4hY/view?
Loom / TRON / Cocos-BCX — Comparative Report on Blockchain System Technical Features
Prepared by: United Labs of Blockchain Technology
Contents
- Overview
1.1 Brief Introduction of Loom
1.2 Brief Introduction of TRON
1.3 Brief Introduction of Cocos-BCX
Comparison of projects’ features
Summary and Prospect
Appendix
4.1 Appendix I：Relevant information of Loom authenticator
4.2 Appendix II ：Guideline to TRON Super Representative Elections (SuperNode. Abbr: SR)
- Overview
This article introduces and explores the blockchain system features of Loom Network, TRON and Cocos-BCX. For more content including but not limited to business design, economic models and community, etc., please refer to other specific reports published by the Lab.
1.1. Brief Introduction of Loom
Loom Network is a Layer 2 scaling solution for Ethereum (note: layer-2 scaling) to address the issues of low transaction throughput and high transaction cost when building DApps on Ethereum.
PlasmaChain is an important part of Loom network. It can connect multiple sidechains to the Ethereum mainchain. When deploying a dApp using Loom it immediatly creates a DPoS-based sidechain for this dApp without need of Gas fee. Dapps on this sidechain can reach confirmation of transaction in subseconds. And PlasmaChain enables game assets on Loom to be transferred to Ethereum network.
PlasmaChain was officially launched on August 24th, 2018, and is applied to support the marketplace of game Crypto Zombie on Loom.
Loom uses the DPoS mechanism for transaction confirmation, which requires corresponding validators. Therefore, Loom proposed to rely on validators to do voting and verification for the network operations. For details of this part, please refer to Appendix I.
According to news released by Loom official social channel on May 22nd, 2018, (Source: https://medium.com/loom-network/chinas-biggest-mobile-game-platform-announces-plans-to-integrate-with-loom-dappchains-16ce5c14d44e), Loom and Cocos SDK reached a partnership on integrating Cocos SDK with the Loom dApp development environment. Game developers can deploy games on Loom network via Cocos Creator. It also allows users to manage dApp wallet, transaction signing and identity verification etc via Cocos Creator.
Note ：
layer-2 scaling: Layer-2 scaling is also named layer-2 protocol, presented by Loom network and TenX Protocol, which is an extended subsystem(s) or rule(s) based on the original system. It’s externally connected to the original blockchain and the work or business process of the original blockchain system won’t be affected.
Take Loom Network’s PlasmaChain as an example. The diagram below shows the operating mode topology of PlasmaChain. The function of layer-2 scaling system in the entire business framework is clear. Each Sidechain system is labelled as “ layer-3”, which is in fact a further “layer-2 scaling” based on PlasmaChain.
operating mode topology of PlasmaChain
1.2. Brief Introduction of TRON
Different from Loom Network which is a layer-2 scaling, TRON is based on an improved DPoS mechanism (named TPoS. Note 1: TPoS). It’s a public chain that supports smart contract and non-homogeneous assets.
TRON hopes to build infrastructure for the decentralized Internet by using this chain system, thus to provide a public chain with high-throughput, high-scalability, and high-reliability to support the dApps running on top. By January 2019, the highest TPS of the whole network reached 748 (Note 2) according to statistics from TRON official explorer, much higher throughput than that of Ethereum network. Furthermore, it’s reported that TRON has established collaboration with Cocos-BCX to enable cross platform digital assets circulation. Currently it’s already realized the integration of fungible token standards of Tron and Cocos-BCX two platforms.
TRON system architecture is designed based on three layers, including application layer, core layer and storage layer. Below diagram shows its architecture design (Note 3):
Tron architecture design
Storage layer
The storage layer consists of block storage and state storage, which contain information such as transaction, account, contract and assets included. In order to support more diversified digital assets, the idea of graphic database was introduced during the design of underlying storage.
Core layer
The core layer includes subsystems such as TRON Virtual Machine(TVM), account system and consensus system.
In July 2018, TVM achieved compatibility with Ethereum’s VM (EVM), which allows developers to use Solidity to create smart contracts on TRON.
TVM supports multiple programing languages, and will support more languages in future.
In addition, to meet TRON network’s unique needs, some innovation on dPoS has been made for the consensus mechanism of TRON.
Application Layer
Developers can use APIs to easily deploy dApps and implement customized wallets. The protocol of TRON is defined by google protobuf which natively supports multi-language extensions.
Note 1: Visit the site for details: TRON team answers FAQs about the global community — http://baijiahao.baidu.com/s?id=1598521715436414301 (In Chinese)
Note 2: Data source: TRONBlockChainExplorer, https://tronscan.org/#/nodes
Note 3: Image from TRON official Github presentation document: https://github.com/tronprotocol/Documentation/blob/master/
1.3 Brief Introduction of Cocos-BCX
Cocos-BCX is a blockchain system designed for complex business, especially game applications. Cocos-BCX uses improved DPoS based consensus mechanism, with optimized transaction throughput and transaction response in order to meet the needs of gaming business models. The aim is to create a complete run-time environment with multi-game systems compatibility, providing game developers with the convenience and a perfect ecosystem environment for blockchain game development. In addition, Cocos-BCX aspires to bring users new game experience and unprecedented game forms — users will have full control of game assets, and game environment of maximized fairness and transparency
With Cocos’ deep understanding of game industry, the design of Cocos-BCX is full of unique features, such as trustable randomness, low latency for transaction response, merging of multi operative atomics, durable contract instances and iterative contract, etc.
Cocos-BCX’s business architecture consists of the application layer, runtime layer, contract layer and blockchain infrastructure layer. Below diagram shows the architecture design( Note 1).
Cocos-BCX architecture design
Cocos-BCX’s contract VM uses Lua 5.3-based language, which is compatible with most library functions and standard Lua syntax, And JS language will be supported soon. The reason for choosing these two as contract programming languages is obviously for the convenience of most game developers: Most game developers of Cocos-2dx or similar engines use Lua language, while most WEB game developers use JS language.
Moreover, Cocos-BCX released its own non-homogeneous digital assets standard NHAS-1808 Standard in August 2018, as well as its compatible design of “Worldview” system and “WorldCross”. And later in the updated version of 1808 standard assets it added functions to support more new business models, which enables, for the first time, complex financial models such as leasing and collateralization of non-homogeneous assets on blockchain.
The diagram below shows the data structure of BCX-NHAS-1808 non-homogeneous digital asset standard(Note 2).
data structure of NHAS-1808 powered by Cocos-BCX
Note 1: From the Cocos-BCX WhitePaper: https://www.cocosbcx.io/wp-content/themes/cocosBlog/source/white_paper.pdf
Note 2: Same source as Note 1
Currently, Cocos has established cooperation with several public chains including Loom, Ontology and NEO. In addition to integrating Loom dApp deployment channel via Cocos SDK mentioned above, Cocos-BCX is now working with TRON, Ontology and NEO on implementing BCX-NHAS-1808 Standard onto these blockchains and integration of homogenous/non-homogeneous assets systems(Note), which will enable transaction of homogeneous/non-homogeneous assets across these different chains, forming a cross-chain network connecting the business of different systems into a larger network.
2.Feature comparison between Loom, TRON and Cocos-BCX
This chapter will present the technical features of the three blockchain systems: including the chain system itself and the subsystems related to business implementation, such as APIs, development environments/tools, etc.
technical comparison on Loom/Tron/Cocos-BCX
3.Summary and Prospect
On the subject of sidechain-mainchain interaction, the Lab has studied many cases. But what is frustrating is that there’s still an unavoidable problem for transaction level cross-chain docking in blockchain system at current stage: As the security of blockchain is guaranteed by a series of authorization design and complex signature technologies, the interaction between the sidechain and mainchain must involve the issues of verification, identification and authorization among several chain systems.
In this scenario, the interoperability and security become two contradictory issues for the two chain systems. To maintain the existing security mechanism of the blockchain system, it will require various verification modes such as multi-signature, and proposals/voting etc.,which will significantly lower the performance (1~3min/transaction). While to improve the efficiency of the interoperation it will force to partially compromise the security issue in some degree, such as ignoring signature or authorization verification, saving the private key of sidechain or mainchain at the node, etc. Besides, the transactions on the sidechain are not traceableto the mainchain. That is to say, in the sidechain scheme, the transactions on the sidechain are not traceable to the main chain, which is contrary to the original intention of blockchain systems.
However, this doesn’t mean that the future of blockchain technology looks gloomy. New technologies keep evolving. For example, the technology of exchange gateway can now work around these problem quite well. And for the blockchains without intensive cross chain transaction demand, such solutions can also provide fairly good user experience.
Blockchain technology is a young and emerging field. We look forward to this new technology taking a great leap forward.
4.Appendix
4.1. Appendix I: Related information about Loom validator. Extracted from the Internet: http://www.tucaod.com/3497.html
4.1.1 Validator Responsibilities
It’s not possible to overstate the critical function that validators play in keeping the network honest. To ensure this, the responsibilities as a validator node will include:
Continuously running the latest and greatest version of the Loom SDK
Staking LOOM tokens for a period of time
Complying with Loom validation requirements and specs
Maintaining properly functioning hardware
Actively participating in network governance (voting on software upgrades, changes to the fee structure, etc.)
4.1.2 Requirements for Validators
As validation activity during an initial testnet phase typically requires minimal resources, we expect an accelerated bootstrapping of the network given recent milestones and momentum.
As such, we’ll be continuously iterating on precise specs and requirements to find the optimal setup for mainnet and anticipated growth in transaction volumes. At this point, approximate guidelines for testnet validators are outlined below:
Hardware
Server and backup server running Loom software (both with firewall)
Memory: 16GB of RAM, preferably 32GB
Disk space: 2TB of SSD storage
CPU: 64-bit
Processor: 2 cores, 3GHz each
Network: 1GB fiber
Hardware security module (HSM) and backup
Operation
Co-location at a top-tier data center; security and 100% uptime are paramount, so redundancy is a must
An additional backup location operation
Loom will provide examples and documentation on monitoring and alerting tools, but each validator is responsible for their own instance
Initially, more frequent upgrades during the testnet phase as the wrinkles are ironed out
LOOM Tokens
Must stake 1,250,000 LOOM tokens
Requires a 6-month lock-up period on the staked tokens
The larger the stake, the larger the validator will be rewarded
4.2. Appendix II: Guideline to TRON Super Representative Elections (SuperNode. Abbr: SR) Extracted from the official developer documentation: https://github.com/tronprotocol/Documentation/blob/master/TRX_CN/Tron-doc.md
4.2.1 Guideline for Applying to be a Super Representative Candidate
Any account in the TRON network can apply to be a super representative candidate and have the opportunity to become a super representative. Every account in the TRON network has the right to vote for his super representative candidate, and top 27 individuals among the candidates will be the Super Representatives that has the right for block generation. The votes are updated once every 6 hours.
To prevent malicious attacks, a threshold for admittance is set up — to run for Super Representative, 9999 TRX in the applicants’ account will be burnt. After successful application, users can run for Super Representatives.
4.2.2 Super Representatives Election
Voting requires TRON Power (TP), which is determined by the users’ frozen balance.
TP Calculation: 1 TP for 1 frozen TRX
Every account in TRON’s network can vote for the Super Representatives they support. Once you unfreeze your balance, an equivalent amount of TP is also lost, meaning previous vote cast may no longer be valid.
You can refreeze your balance to revalidate the votes.
Note: TRON network only records the latest votes, so every new allocation of votes you make replaces all previous records.
An Example:
freezebalance password 10_000_000 3 // 10 TP for 10 frozen TRX
votewitness password witness1 4 witness2 6 //4 votes for witness1 and 6 votes for witness2
votewitness password witness1 3 witness2 7 // 3 votes for witness1 and 7 votes
4.2.3 Super Representative Rewards
Vote Reward: 127 candidates updated once every 6 hours will share 115,200 TRX. The reward will be split in accordance to the votes each candidate receives. Total reward for candidates will be 168,192,000 TRX each year.
Block Reward: The TRON Protocol network will generate one block every 3 seconds, with each block awarding 32 TRX to Super Representatives. A total of 336,384,000 TRX will be awarded annually to 27 Super Representatives.
Each time a Super Representative finishes block production, rewards are sent to the sub-account in the superledger. Super Representatives can check, but not directly make use of this asset. A withdrawal can be made once every 24 hours, transferring the reward from the sub-account to the Super Representative’s account.
4.2.4 Committee
What is the committee?
The committee is used to modify TRON dynamic network parameters, such as block generation rewards, transaction fees, etc. The committee consists of the 27 SRs in the current round. Each SR has the right to propose and vote on proposals. When a proposal receives 19 votes or more, it is approved and the new network parameters will be applied in the next maintenance period (3 days).
Create Proposal
Only the Super Representative’s corresponding account has the rights to propose, while other accounts are forbidden. Following is the network dynamic parameters and the No. ( [min,max] ):
0: MAINTENANCE_TIME_INTERVAL, [3 * 27* 1000 , 24 * 3600 * 1000] //Change SR adjusts time interval. Currently 6 * 3600 * 1000ms
1: ACCOUNT_UPGRADE_COST, [0,100 000 000 000 000 000] //Change the cost of becoming a Tron Representative. Currently 9999_000_000 Sun
2: CREATE_ACCOUNT_FEE, [0,100 000 000 000 000 000] // Change the account creation fee. Currently 100_000Sun
3: TRANSACTION_FEE, [0,100 000 000 000 000 000] // Change the cost of the TRX deductible bandwidth. Currently 10 Sun/byte
4: ASSET_ISSUE_FEE, [0,100 000 000 000 000 000] // Change the for assets issuance. Currently 1024_000_000 Sun
5: WITNESS_PAY_PER_BLOCK, [0,100 000 000 000 000 000] // Change SR blockchain generation rewards. Currently 32_000_000 Sun
6: WITNESS_STANDBY_ALLOWANCE, [0,100 000 000 000 000 000] // Change the rewards given to the top 127 SR candidates, 115_200_000_000 Sun
7: CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT, []// Change the cost that the system creates an account. Currently 0 Sun
8: CREATE_NEW_ACCOUNT_BANDWIDTH_RATE, // Use proposals 7 and 8 together to modify the resources or TRX consumption of account creation.
9: ALLOW_CREATION_OF_CONTRACTS, //Activate Tron Virtual Machine
10: REMOVE_THE_POWER_OF_THE_GR // Remove the votes initially given to Genesis Representatives
12: EXCHANGE_CREATE_FEE, [0,100 000 000 000 000 000] //sun
13: MAX_CPU_TIME_OF_ONE_TX, [0, 1000] //ms
14: ALLOW_UPDATE_ACCOUNT_NAME, // Use to allow change of nicknames and repeated nicknames. Currently 0, indicating not allowed
15: ALLOW_SAME_TOKEN_NAME, // Use to allow creation of tokens with the same name. Currently 0, indicating not allowed
16: ALLOW_DELEGATE_RESOURCE, // Use to control unlocking of the resource proxy function
17: TOTAL_ENERGY_LIMIT, // Use to adjust Energy limit
18: ALLOW_TVM_TRANSFER_TRC10, // Allows the smart contract to call the interfaces of
TRC10 token. Currently 0, indicating not allowed. Set to 1 to allow
API: createproposal id0 value0 … idN valueN id0_N: parameter number value0_N: new parameter value
Note: In a Tron network, 1 TRX = 1000_000 Sun. Vote on the proposals
Voting on the Proposal
The proposal only supports affirmative vote, and the member who does not vote in time will be considered as a disagree. The proposal is active for 3 days after it is created. The vote will be expired if the proposal doesn’t gain enough affirmative vote during the 3-days voting window. Cancellation of previous affirmative votes is allowed.
API: approveProposal id is_or_not_add_approval id: Proposal Id. Accumulated over time of proposal creation.
is_or_not_add_approval: Approve or cancel approval
Cancel Proposal
The proposer can cancel the proposal before it becomes effective.
API: deleteProposal proposalId id: Proposal Id, Accumulated over time of proposal creation.
Query Proposal
You can enter the following interfaces to query the proposals, including: querying all proposal information, query proposal information (GetPaginatedProposalList) by paging, query specified information(GetProposalById).
For more information on api, please check out Tron-http