Moving Cloud Chain

Whitepaper Version 1.0

Abstract: Moving Cloud Chain is a distributed data storage protocol based on blockchain technologies. It is ourgoal to build a safe, stable and intelligent blockchain platform that can support many use cases and can meetthe needs of financial, Internet-of-Things (IoT), entertainment, gaming, health, and wellness industries.

Released under the MIT License and is the first intelligent platform and digital currency for wearable devicesthat allow participants to earn Moving Cloud coins through a concept we call Proof of Exercise or PoE.

In addition to the "health + financial" business model the Moving Cloud platform can dynamically launchsidechains and supports Distributed Applications or DAPPs and smart contracts development based on theJavaScript programming language. This is our first release.

1. Title2. Table of Contents3. Revision History4. Introduction to Moving Cloud Chain Platform5. Initial Business Use Cases

1. Enterprise Users2. Developers3. Consumer

6. System Highlights

2. Table of Contents

1. Development Language2. Tookits3. Deployment4. Flexibility5. Security

7. Design Rationale

1. Turing-Completeness, scripting, and Sidechains2. Accounts and UTXO3. Relational and Non-Relational Databases

8. Technical Specification

1. Consensus Mechanism2. Delegate Voting3. New Blocks4. Missed Blocks5. BFT and PBFT6. Sidechains and DAPP7. Sandboxes8. Transactions9. Account System

10. Clients11. Performance and Scalability

9. Additional Platform Features

1. Token System2. Arbitration3. Exchange4. Proof-of-Effort5. IoT10. Pre-mining and Allocations

10. Pre-Mining and Allocations11. MCC Blockchain Spec.12. Conclusion13. Contact Information14. References

Version/ Description/ Author/ Date/ Email/

V1.0 1st Release/ 2017-06-23 developer@mcstore.cn

In a revolutionary whitepaper released in 2008 by Satoshi Nakamoto, whose name is presumed to be apseudonym for the Bitcoin core development team, Satoshi describes the protocol and model for a peer-to-peer electronic cash system. In 2009, the core developers released the first version of the Bitcoin protocolbringing the concept to life.

Bitcoin was designed to be the worlds first, peer-to-peer (P2P), distributed and decentralized electronicpayment system that allows for payments to be sent or received securely and without the need for processingthrough a 3rd party entity through the use of a proof-of-work based blockchain. In a proof-of-work basedsystem transactions are timestamped and added to blocks which are then processed "mined" and added to thechain of blocks. This mechanism is designed to prevent double-spending and ensures that any attacker mustnot only redo the work for the block of transactions they wish to modify but also redo the work of all subsequentblocks in order to successfully double-spend. This type of attack becomes exponentially more difficult as eachsubsequent block is added to the chain and this is the reason why most exchanges wait for at least 6confirmations before settling an order.

The launch and popularity of Bitcoin has since ushered in a new era of research and development intoblockchain technology, its many use cases, and also identified several areas where the Bitcoin protocol wasperceived as being deficient or not scalable for some applications and use cases. The result was alternativeprotocols or "altcoins" such as Moving Cloud Coin (MCC), Zcash, Ethereum, and Litecoin among others.

Moving Cloud Chain ("MCC") is a new distributed and decentralized application platform and protocol thattakes an adaptive approach towards ease of use, upgradability, blockchain scalability, safety, and efficiency. Itutilizes practical byzantine fault tolerance and delegated Proof-of-Stake algorithms as well as implements anovel Proof-of-Effort system for earning MCC coins.

The MCC platform itself is a fully open and decentralized application which has it's own cryptocurrency calledMCC coin. MCC coin is capable of interfacing with sidechains or any decentralized application (DAPP) throughthe use of a "two-way peg" mechanism so that it can be used to bridge or as a medium for asset transitionamong all DAPPs.

In order to help developer's creating a decentralized applications we've also provided Software Development

3. Revision History/

4. Introduction: The Moving Cloud Chain

Kits (SDKs) and Application Programming Interfaces (APIs) on GitHub along with the source code at thefollowing link: https://github.com/xingyunmcc/mcc

Our SDKs and APIs are based on Turing Complete JavaScript and we hope that by providing a group ofindustry standard solutions developers will find MCC easy to use, customize, and deploy decentralizedapplications, smart contracts, digital assets, and customized sidechains.

All MCC client software has the ability to access DAPPS through the client software making very easy fordevelopers to launch and publish their applications across the ecosystem.

Already one of the fastest growing blockchain technologies in China, we believe with the open sourcecommunity's help we are certain we can make MCC even better!

The tools provided with the MCC platform can easily be used to create a complete blockchain and if desiredpeg the new blockchain to MCC, Bitcoin or other blockchains thereby providing a link to other well developedcryptocurrencies. We believe this feature will be very attractive to start-up companies as well as small andmedium enterprises (SMEs).

Our tools will also allow SMEs to easily customize the blockchain to meet their specific needs or move awayfrom closed and proprietary systems into a distributed and secure blockchain platform. This can aid in auditing,business promotions, and transparency with investors by being able to publish information on an open andtrustworthy platform.

E-Commerce: MCC has already established a proof-of-concept (POC) store in China using the MCC platformfor both the storefront, device marketplace and client applications. It was initially launched for China market butwe plan to extend this internationally as soon as possible. It is a fitness based platform based on a concept wecall proof-of-effort (POE) which is a real-world physical activity driven platform rewards users with coins basedon their activity. The http://mcc.mcstore.com is currently only available in Chinese language but internationalversion are in progress.

Using JavaScript developers can easily create and deploy DAPP applications and games by following theirown business models and design goals. The business models may be free, fixed price, or supported by in-game/in-app purchases. Developers are free to design and create the revenue model that works best for them

5. Initial Business Use Cases

5.1 Enterprises

5.2 Developers

and their applications.

Individual users can earn MCC coins just by exercising through our Proof-of-Effort algorithm and intelligentwearable devices. They can also download, install, and use any number of DAPPs through the MCC Store andclient applications. MCC platform can also support different kinds of decentralized applications that allows forusers to contribute content or towards application development while also being able to earn money for theircontributions. This opens the possibility for users and developers to create vivid communities and ecosystemsaround popular applications and games.

Please reference Figures 1 and 2 for an illustration of a simple DAPP/sidechain ecosystem.

Figure 1: Basic DAPP Structure

5.3 Consumer

Figure 2:

We chose JavaScript as the primary development language because of its numerous NPM libraries, ease ofuse, and general popularity in comparison to languages being used on other platforms. JavaScript combinedwith SQLite makes DApp development easier and more similar to traditional web/app development which webelieve will make our platform easier and more convenient for developers to use and build on.

We built a command-line utility so that sidechains can be created quickly and easily to help reduce

6. System Highlights

6.1 Development Language

6.2 Toolkits

development work and time to market. We also developed a series of APIs that allow the developer to easilyaccess complex functions such as consensus mechanism, random number generation, database, andcryptography functions are easier to access and can be quickly updated for scalability and security.

On Moving Cloud Chain it is very easy to deploy a DApp. Developers just need to commit their project onGithub and then register their DApp using our web based or lightweight wallets. The DApps can then bedownloaded accessed by any user on the platform.

We design the system with adaptability and flexibility in mind so that developers can freely customize allparameters in their sidechain such as transaction processing speed, transaction types, transaction fees, andconsensus mechanisms.

One key highlight of the MCC platform is our consensus algorithm that is based on combining PracticalByzantine Fault Tolerance (PBFT) with Delegated Proof of Stake (DPOS). This greatly reducing the attacksurface and will prevent bifurcation of the network as long as the majority of validators are honest. Thissignificantly reduces the chance of fork happening without delegate approval in addition the community couldvote to manually revert all of the blocks produced by the attacker since the attacker will always be known.

We have implemented BIP 39 (passphrase system), multi-signature support, and a two-factor authenticationsystem natively.

One of the design highlights in Bitcoin is its scripting engine that allows for not only transferring currency butcan perform smart contracts, automate multi-signature functions, perform escrow functions and allow forarbitration. However, Bitcoin's scripting engine is not without limitations such as not being able to supportlooping instructions, limitations on script length or size, and transaction limitations.

Ethereum on the other hand created a new blockchain platform with a completely new programming/scripting

6.3 Deployment

6.4 Flexibility

6.5 Security

7. Design Rationale

7.1 Turing-Completeness, scripting, and Sidechains

language, named Solidity. This greatly expanded the scale of what could be done by Smart Contracts andDistributed Applications by enabling the applications to read from the blockchain, perform billing functions, andcreate new currencies on top of Ethereum among other functions. It also eliminated many of the limitations ofBitcoin because Solidity is claimed to be a Turing-Complete language. Meaning that Solidity should be ablesolve any computation can be represented by a mathematical model.

Ethereum then became the prevalent platform for decentralized applications. However, we believe thatbecause the application and application data generated are stored in the same blockchain this design alsocreates scalability problems as initially the blockchain grew quite rapidly. Ethereum tried to slow doneblockchain growth by optimizing and compressing the program code and data but this still does not solve theproblem completely.

In contrast, a sidechain mechanism addresses scalability completely differently. On the MCC platform everysidechain runs in a different distributed node network with independent audiences, investors, and developmentteams. This natural fragmentation solution not only solves many of the problems with blockchain expansionrates but also allows each application to have a personalized set of books (blockchain), consensusmechanism, block parameters, and transaction types. So, we propose that sidechains are a less costly, moreflexible and easy-to-use solution than solely Turing-Complete programming/scripting alone.

In Bitcoin and derived systems the concept of an "account" is deprecated and may be removed at some pointin the future. https://github.com/bitcoin/bitcoin/issues/3816 However, the Bitcoin accounting system was neverdesigned to be a bookkeeping system per se but rather as a way to organize groups of addresses. In a Bitcoinwallet you can have many of these "accounts" linked to different groups of addresses. However, when sendingBitcoin the "sendtoaddress" command/api function does not distinguish between accounts. It checks the walletfor all UTXOs or Unspent Transaction Outputs and sums them to determine if there are a sufficient quantity ofBitcion's in the users wallet to complete the transfer.

Bitcoin transactions can have multiple inputs and outputs. For example, if a Bitcoin user has two addresseseach with 0.25btc for a total of 0.50btc then If the user wishes to purchase a product for 0.30btc a transactionwill be made with bitcoin from the two addresses with the difference returned minus the mining fee. Each inputincludes a reference of the current UTXO and a cryptographic signature generated by the private keyassociated with the public address in the UTXO.

One advantage of how Bitcoin uses UTXOs is it allows the user to create a new address for every transactionwhich is presumed to provide an elevated level of anonymity thus making the transaction data more randomand slightly increasing the security. However, the UTXO has the disadvantage that in the example above bothUTXOs must be spent and the difference returned to the owner. There are companies that are using this to tryand identify people using the bitcoin network.

7.2 Accounts and UTXO

The Moving Cloud Chain platform uses an account based system that provides the following benefits:

Database efficiency. Without going into the complexity of Bitcoin in detail UTXO let's say hypothetically that:

1. If a user has five UTXOs they will need to store a minimum of 300 bytes. This is based on 20 bytes for theaddress, 32 bytes for a transaction number, and 8 bytes for the transaction amount giving us (20 + 32 +8)= 60 bytes * 5 totaling 300 bytes uncompressed.

2. In an account based system information about the account can be stored in as little as 30 bytes. In thiscase, 20 bytes for address, 8 bytes for balance, and 2 bytes for a random number.

It is easy to view and calculate the balance in an account.

We think an account based system is much simpler, easier to code and understand for applicationdevelopers.

Constant balance reference. A light client can access arbitrary data of a user's account in constant time,whereas in a UTXO system the access time may change after every transaction due to complexity of"looking up" all unspent UTXOs.

Thus the MCC platform is not a "pure" currency system because it was designed to be an applicationfriendly/developer friendly platform. We believe using an accounting system is the better option considering ourdesign goals.

Currently the majority of blockchain systems are using lightweight non-relational databases such as BerkeleyDB, LevelDB, etc. Usually these kinds of database support some simple data structures, like B-tree, hashtable,and queue. However they are generally not able to manipulate data through SQL. Perhaps non-relationaldatabases are good enough for many electronic currency applications but we don't believe this is the case forsmart contract and DApp platform applications considering finance, banking, e-commerce and other sectors.Current mainstream non-blockchain software application generally all use a relational database for theseindustries because of the following advantages:

Transaction processing speed and handling of queries, ordering, transaction security.

Data update costs are lower.

Advanced query functions such as JOIN are available.

We chose SQLite, a high performance embedded relational database system, that can support data volumes ofup to 140TB by default. The data file can be shared among different byte order machines and being able to usethe SQL query language is very convenient for DApp developers.

7.3 Relational Databases versus Non-Relational Databases

The consensus mechanism used by MCC system is based on DPOS combined with an optimized PBFTalgorithm to implement a principal electoral system composed of delegates or trustees and candidates(potential trustees). The algorithm can achieve consensus with O(N^2) message complexity and O(1) timecomplexity when t (number of nodes on which a problem can occur such as attack, network error, or is offline)is less than n/3 where n = total number of all nodes or simply (t<n/3).

Similar to other DPOS systems there are a current maximum of 101 delegates or trustees on the MCCplatform. Delegates are trustful account nodes that maintain the network, process transactions, and add newblocks. They are voted for by the community and all other nodes are called candidates. The top 101 candidateswith the most votes become can become delegates.

Every MCC user has the right to vote for up to 101 delegates with the weight of their votes being determined bythe amount of MCC in their account.

Each round of voting generates 101 blocks and changes in rank are reflected after each round.

8.3.1 New blocks are added to the blockchain and broadcast to the network every 10 seconds. Once a newblock is accepted into the chain the confirmation count for all transactions will increase by 1. After gaining atleast 6 confirmation a transaction can generally be considered as safe or final. Safety is considered as afunction of the size of the transaction versus the confirmation count whereas a transaction concerning only asmall amount of money may only require 1 confirmation and if the transaction concerns a very large amount ofmoney it will require additional confirmations.

If a significant number of delegates exhibit failure a schedule block will "miss" and get recorded by the network.This can also affect the number of nodes that appear "online" and slow down the voting process. Thereforeelection of delegates should be considered carefully so that election process promotes the safety and stabilityof the platform.

8. Technical Details

8.1 Consensus Mechanism

8.2 Delegate Voting

8.3 New Blocks

8.4 Network issues and "missed" blocks

One of the major differences between MCC system and traditional DPOS systems is that MCC is a hybridsystem that applies both DPOS and PBFT algorithms to try to reduce the risks, instability, and attack vectorsthat have affected other DPOS systems.

8.5.1 The Double-Spend Attack: This kind of attack can occur anytime a previous block or blocks can bereplaced or modified or can exclude transaction that were previously included. This can also be called a 51%attack. In our system the probability of this type of attack succeeding is quite low given how we apply theDPOS and PBFT algorithms as described below.

8.5.2 Stake Grinding Attack: Stake Grinding is where a delegate or several delegates attempts to guess thenext block or future blocks by generating a large number of potential future blocks by using network parametersagainst itself or otherwise attempting to affect the randomness by which validators are chosen and the blockgeneration process to give them an unfair advantage or chance of generating a valid block.

While it is possible for this type of attack to occur on the MCC platform we think it is unlikely given the costsassociated with such an attack, the process of validator selection, and the percentage of validators that mustcollude to form such an attack. It could however slow the network down until the validators can converge theblockchain into the correct order.

8.5.3 The process: In MCC first the list of delegates is randomly sorted for the current round of voting so thenodes cannot predict the order in which delegates are chosen to produce/validate blocks then delegates areselected to process blocks using a round-robin algorithm.

In addition we apply a PBFT algorithm that chooses delegates by way of round-robin. However, blocks are notgenerated after delegates are vote. Instead, a proposal is issued to determine the hash of the next block. Andonly when more than 2/3 of all nodes agree with this proposal will the next block will be generated. And thishash must match that as agreed with all delegates of current round. So the addition of PBFT helps to solve theissue of abuse of delegates' rights and improved the security and control of the blockchain.

8.6.1 MCC system provides a command line utility that developers can use to easily create a basic sidechainsystem. Developers are also able to fully customize their sidechain system, including its own database,consensus mechanism, trading mode and account architecture. The sidechain system can be hosted either byclusters of nodes or individual delegates creating shards that partition the network reducing growth rate of themain blockchain.

8.5 Byzantine Fault Tolerance (BFT) and Practical ByzantineFault Tolerance (PBFT)

8.6 Sidechain and DAPP

8.6.2 Every DAPP is related to a sidechain. A sidechain's core code is developed by nodejs but the UserInterface (UI) can be developed by many front-end techniques such as QT, HTML, or JavaScript. Thecommunication mechanism between the front-end and back-end is usually implemented using JSON RPCprotocol. The developer or owner of a DAPP can easily trace the usage of their application once deployed onthe MCC system.

Compared to cryptocurrency that is based on a community consensus, DAPPs are more like a private entity. Allthe transactions within a DAPP are handled by the main node run by DAPP's owner.

DAPP transactions are handled by the master node, which is the first node on the sidechain and is run by theowner/creator of the DAPP. So the owner of DAPP must have an MCC account, which will function like a multi-signature account. The major objective of this is to create transaction on the MCC main blockchain and collectthat block's signature, which establishes the link between the DAPP sidechain and MCC. This also links thedeveloper's account to the DAPP, the sidechain's main node, and MCC. The process is very similar to howmulti-signature wallets are created.

When a new DAPP is created and signed on main node, the SHA256 hash of this block is calculated and thensubmitted to the main blockchain of MCC system as a DAPP block by the DAPP owner. And once MCC's mainblockchain receives information of a trade including a DAPP hash, the delegate will compare it with theprevious one and then store it into MCC blockchain. The main node then stores the hash value, the blocksignature and which delegate created the block and saves it back to the main blockchain.

In the future when master node synchronizes with network user can verify all DAPP blocks through the MCCblockchain and effectively making it impossible to remove DAPP history from block chain.

Developers can also replace MCC blockchain with Bitcoin blockchain to have the same functionality since theusage of MCC API will be the same. The security of a DAPP can also be guaranteed by Bitcoin blockchain.Developers can take advantage of both MCC and BTC as the currency of their DAPP.

When cross-chain transactions occur, either to or from a DAPP, either MCC coin, BTC or other coin will bedelivered to the appropriate DAPP address and the appropriate amount of money will be shown in that DAPP'saccount. The deposit mechanism for both BTC and MCC are the same and will deliver to the appropriateaddress.

So this also means that for every DAPP created it is the developer's account that external coins will bedelivered to during cross-chain operations. Considering this as it relates to DAPP security, DAPP accountsshould be multi-signature that is signed by a trusted authority when dealing with financial transactions.

Withdrawals from DAPPs are the main node's responsibility! When a withdrawal request is received theDAPP's main node will move the money from DAPP address to MCC blockchain or Bitcoin blockchain.

So DAPP developers can issue their own tokens to use it as the currency of their DAPP platform. The only

limitation is that DAPPs cannot exchange tokens directly with each other using this mechanism but must useeither Bitcoin or MCC as the network medium.

What is a Sandbox? A Sandbox special type of environment for running programs in a restricted environmentgoverned by a security policy. Many times these are used in order to test software without affecting the mainsystem. A sandbox is also used to test suspicious software if it is suspect that the integrity is suspected ofbeing compromised by virus or other malicious and unwanted behavior. A sandbox will typically intercept thesystem calls, monitor a program's activities, and control usage of computer's resources such as disk I/O, filesystem, or network access according to user's policy.

The MCC platform implements a sandbox mechanism by using the VM module of nodejs. The VM module is anencapsulation of JavaScript V8 engine, which is then used to run the pure JavaScript code. However, it cannotuse system APIs to access local file systems or directly access network communications.

It also lacks the "require" function therefore many third-party libraries cannot be easily imported and modulardevelopment is not impossible. This requires DAPP developers to use a "browserify" technique to bundle allthe third-party libraries their application needs encoded to a JavaScript file so that the MCC system can load itto run. Some necessary system level APIs are provided to sidechain through IPC (Inter-ProcessCommunication), which takes into account both security and functional completeness.

The MCC system has built-in abstract transaction layer on which almost all the functionalities of system coreare established, such as: token transfers, voting, application store, deposits, and withdrawals. Sidechains canalso implement their own type of transaction. The main difference between each transaction is the type oftransaction and the asset. The underlying transaction data structure is as defined below but there areextensions to this for some type of transactions.

8.7 Sandbox and VM

8.8 Transaction

Transaction{requiredVARCHAR(20)id;requiredVARCHAR(20)blockId;requiredTINYINTtype;requiredINTtimestamp;requiredVARCHAR(21)senderId;optionalVARCHAR(21)recipientId;requiredBIGINTamount;requiredBIGINTfee;requiredBINARY(64)signature;optionalBINARY(64)signSignature;optionalTEXTsignatures;requiredBINARY(32)senderPublicKey;}

Let's take a voting transaction as an example of an extension: each vote is connected to a basic transactionwith the transaction ID.

Asset_Votes{requiredVARCHAR(20)transactionId;optionalTEXTvotes;}

Every account in MCC system consists of one passphrase, a pair of public/private key, and an address. Userscan also set their a secondary password.

Note that a major difference between MCC accounts and Bitcoin is that each account is related to only oneaddress as opposed to multiple addresses and private keys related to one wallet in Bitcoin.

We implemented BIP 39, which is a Bitcoin proposal that describes a mnemonic code for generatingdeterministic keys. Mnemonics are much easier for people to remember than other forms of passwordgeneration and hexadecimal passwords as are sometimes used with cryptocurrencies.

The mnemonic encodes entropy in a multiple of 32 bits into several simple words. The MCC systemimplementation uses an entropy length of 128 bits which gets converted into twelve random words. These 12words form the passphrase and are entirely random and will be a list of words that look like this:

barely decline storm stamp protect purple certain cup arena busy latin shell

8.9 Account System

A key pair consists of two keys a public key and a private key. To generate the key pair we perform a SHA256hash of the passphrase as a random seed and feed it to the Edwards-Curve Digital Signature Algorithm(EdDSA). The result looks like this:

The account address is a big number generated by reversely converting the first 8 bits of the SHA256 hash ofpublic key resulting in:

AccountNumber:5034187504202890358

MCC platform provides three classes of clients "full", "lite", and "mobile:

The full client is a perfect solution for super users, delegates and developers. It can run on Windows, MacOSX, and Linux. However, only the Linux operating system can be used to run candidate or delegate nodes forblocks forging and generation. Full version wallets download the complete blockchain from other nodes alreadyin the network through the peer-to-peer (P2P) network.

The "lite" wallet client allows users to connect to the MCC network and access full version wallet API if theowner of the node supporting it opens all the rights of the API to the full version wallet. Typically lite wallets areused for day-to-day management of a user's MCC account. And it can be accessed on the many platformswithout software installation because it is based on the HTTP protocol. Lite wallets do not howerver download acopy of the blockchain.

The MCC lite wallet has several advantages such as: it provides fast, very easy, and secure access to theMCC platform, users do not need to download a copy of the blockchain, no private keys are transmitted overthe network as all data is signed locally.

If you want to run a delegate node, you can use lite wallet to register a delegate or candidate account butcannot run delegate node operations through it to produce a block.

DAPP users can take advantage of lite version wallet to find DAPPs and manage installed DAPP. The APIs ofboth DAPP and node are available for DAPP developers to invoke so application can be developed anddeployed very quickly and easily.

PublicKey:9989388b220a13465e49f52df5ba28ba08eb1e7a973320347f9687a107dc2f9a

PrivateKey:91e891f653e3ed0232d8c7de2e72b625d50d48593fc0fb570c0db25c5e44569a9989388b220a13465e49f52df5ba28ba08eb1e7a973320347f9687a107dc2f9a

8.10 Client

The mobile version of the client allows users to manage their own MCC accounts on mobile devices for usingboth iOS and Android platforms. The client can be downloaded from either Apple's appstore or Google'sGoogle Play respectively. The backend of the client is based on the same solution as that applied in ourdesktop version, but mobile client applies responsive UI instead to fit the mobile device screen and changessome interfaces as necessary to be compatible with the mobile device's operating system. The mobile clientmakes interacting with or using MCC very convenient and user friendly and it also supports all the DAPPcapabilities of our platform.

A single transaction requires ~100 bytes. So let's look at the network bandwidth required to process 10,000transactions per second (TPS). Currently a block is processed every 10 seconds so each block would need tocontain 100,000 transaction and size of the block will equal 10 megabytes (MB). This 10MB block needs reachall nodes and with our current parameters we can expect 10 nodes to receive this block within ~5 seconds, 100nodes receive the block in ~10 seconds and so on as every node shares the data with its peers. For this sizeblock we expect that block can reach the next node every 5 seconds so in order to achieve this we expect anominal bandwidth of at least 20 MB/s per node (10MB data x 10 nodes / 5 seconds). We realize that in reallife bandwidth can and will be highly variable and there is much room for optimization in this area. However thisis a problem for all blockchain platforms and there is a lot of research and development being done in order tobetter optimize network performance, latency, and transaction processing.

In the MCC toolkit we provide a simple "hello world" program that functions as a simple token system.

It is easy for anyone to create a token without even needing to write a single line of code because a new tokensystem can be created by just editing some parameters in a JSON configuration file. These token functions in away similar to how the Ethereum system works. The tokens on the MCC platform can represent gold, stock,mortgage, or any other type of asset. And once created they can be traded because in effect the tokens arerunning in a sidechain and can be accessible via DAPP or MCC platform.

There are many types of business transactions that involve paying money to or receiving money from people orcompanies we don't know, especially in e-commerce transactions where it is frequently the case to do business

8.11 Performance and Scalability

9. Additional Platform Features and Examples

9.1 Token System

9.2 Mediation and Segregated Witness

with unknown people or companies. So many times it is in the interest of both parties to conduct businessthrough an intermediary such as Ebay or Taobao and many other platforms.

In the case of Taobao or Ebay when there is a dispute over a product or service they act as a mediator and askboth sides to present evidence and then adjudicate or make a decision as to course of action to remedy thesituation.

In the world of blockchains and distributed P2P platforms this type of mediation can be done but it doesn'trequire a centralized platform to do it. It is commonly called a multiple signature wallet or multi-sig wallet. We'vealready integrated this capability on the MCC platform and below is one scenario as to how it can work:

With multi-signature wallets mediation can occur when a wallet is created with a consensus scheme such as 2-of-3 or 3-of-5 where in a 2-of-3 at least two signatures are required to trigger the transaction to complete.

In a 3-party multi-signature mediation we will have a buyer, seller, and mediator participating using a 2-of-3multi-sig wallet. This wallet will require that at least two of the three parties agree for the transaction tocomplete. In other words either: the buyer and seller can agree –OR- the buyer or seller agree with themediator. Either way at least two of the three parties must agree to a resolution before transaction will becomplete.

The process:

1. Both the buyer and seller decide on a 3rd party mediator. 2. The buyer creates a 2-of-3 multi-signature account and gets a new account passphrase. WRITE this

down!!! Copy the master public key and publish it to the mediator/market and vendor. Gather the publickeys for both mediator and vendor/seller then add them to the wallet. The buyer then transfers a paymentto this new multi-signature wallet. This publishes that a payment was made but it will not complete until 2-of-3 parties agree.

3. The seller can then verify that a payment has been made to the multi-signature wallet and sends productto the buyer.

4. Once the buyer receives the item and is happy that the product or service works as intended they shouldsign the transaction with their private key so payment can be completed. The seller then also signs thetransaction and payment will automatically be completed.

5. However if there is a problem buyer and seller can create a new transaction to refund the buyer. If there isa more complicated issue such the buyer refusing to pay or there is a dispute about the product function,quality, or some other issue then the mediator can be called to help resolve the conflict.

6. The buyer, seller or both can then send complaints and whatever evidence they have supporting their sideof the situation to the mediator. The mediator can then either sign the transaction if they agree with the

seller or create a new transaction reverting the money the money to the buyer if the product or servicewas never delivered. In the latter case both the buyer and mediator would to need create a newtransaction refunding money to the buyer.

In a decentralized exchange there are two basic types of exchange functions: digital currency (DC) to fiat anddigital currency to digital currency. For example: an exchange of Bitcoin (BTC) to U.S. Dollar (USD) or ChineseRenminbi (CNY) is a fiat to DC exchange. Whereas a Bitcoin (BTC) to Litecoin (LTC) is a DC to DC exchange.

Protocols and methods for a fully decentralized fiat to DC exchange are still not fully implemented yet butplatforms such as Local Bitcoins come closer to this ideal.

However DC-to-DC exchanges are relatively straightforward as currencies can be transferred directly throughpeer-to-peer trade using an "atomic cross chain exchange API". Or they can be processed using a usinganother medium such as MCC where the seller is required to transfer some quantity of an asset from anotherblockchain such as Bitcoin (BTC) to an MCC sidechain. This can be done by using an SPV proof-of-frozen-assets on MCC's main chain. However since we are using relational databases it is fairly easy to create a wellperforming matching engine using query and index functions.

Proof-Of-Existence can be used to register copyright, patents, and trademarks or other documents. It is basedon the concept of applying checksums and digital signatures to signing files. These signatures can be added tothe MCC blockchain thus anyone can verify that files are authentic by checking the signatures in the chain. Wecan also add metadata such as timestamps, owners' digital signatures to prove when they own these files.Once recorded on the blockchain the information cannot be forged or revised and it does not expose anyprivate data but can be verified at any time without the need for a third party.

There are many types of IoT devices and each category consumer, commercial, industrial will probably need aseparate approach. However on the MCC platform sidechains can be rapidly configured to meet thesespecialized needs. Using sidechains devices can be assigned an ID and then communicate with system usingSPV APIs.

In this kind of system devices can report status to an application monitoring the network and then alerts can beconfigured and system performance monitored from anywhere with Internet access. And by using sidechainswe can naturally partition devices so that only devices of the same type or market segment can communicate

9.3 Decentralized Exchange

9.4 Proof-Of-Existence

9.5 IoT (Internet of Things)

on the chain. This saves bandwidth and also reduces growth rate of the main chain.

A potential use case would be a MCC enabled vending machine running on a sidechain the vending machinecan then report inventory levels, process payments, and send machine health or error information directly tothe sidechain where management or service technicians can receive alerts or monitor inventory levels.

a.EscrowAddress:MDKATRHEXP6xPFLyetkZdwrgJLoVi3VsG9<br>b.EscrowAddress:M61aEnahT7z3Ax8Rn8d4Jj3YcEfnpHNw1r<br>c.EscrowAddress:MAgAyPjgz17xfta8Ng6BjRAYZjwZcwnHd7<br>

1.EscrowAddress:MCgFRj7AfZCkqvHoYkuwd6PKUfT18mUsz32.EscrowAddress:M5LDSZLHtGnTdjXSuh1zZXzeiv59myWkKx3.EscrowAddress:MPYTM3prmtNSpeszsTEBfqUSBYwshDrKf8

1.EscrowAddress:M6bLdxbjuSWibyJBwu6TPyLnkYzDKmEr8H

10 Pre-mining and Allocations

1. 60% (600 million) MCC reserved for intelligent sports wear. Amount to bereleased over a 10 year period 60 million additional MCC available each year.

2. 40% (400 million) MCC reserved for mergers, acquisitions, market incentives,operations, continued research and development. Currently all of these areunspent and locked.

a. 30% (300 million) reserved for mergers, acquisitions, market maker, factory incentives,and hardware and intelligent device research and development.

b. 10% (100 million) reserved software development, platform operations, and hardwareupgrades. Any will release will be published with at least 7 working days notice.

11. Blockchain Specification

Desc. Item

Name: Moving Cloud

English abbreviation: MCC

The core algorithm: round-robin

Block Time: 10 seconds

Main features: DPOS, PBFT, Javascript

Pre-Mine amount: 1 billion MCC pre dig (POW)

POS interest: 0%

Pre-dig: Yes

Wallet transfer fee: 0.01 MCC

Moving Cloud Chain is a decentralized application platform that is designed to:

Lower the learning curve for developers by using widely adopted languages such as JavaScript so that DAPPdevelopment is not much different from developing web applications.

Improve database efficiency and scalability by using a relational database system.

Be open and flexible so that platform can be used in many different ways and not just limited to singular areassuch as finance, distributed filesystems, supply chain, or IoT but is open to development in all areas andapplications.

Provide an abstraction layer and API, which can be modified and upgraded to support changing needs andevolution of the blockchain technologies.

Increase security, network robustness, and reduce the risk of forks and double-spends by incorporating anenhanced version of delegated proof-of-stake with practical byzantine fault tolerance.

Incorporate an easy to use sidechain subsystem to provide enhance scalability and allow for a more personaland flexible DAPP development environment.

We consider the MCC system as a proactive, low-cost, and full stack solution that will surely be a nextgeneration incubator of decentralized applications.

12 Conclusion

Desc. Item

Website: mcc.mcstore.cn

www.mcstore.cn

Block Explorer http://block.mcstore.cn/

General Information: contact@mcstore.cn

Development Group: deverloper@mcstore.cn

Note: Currently website is only available in Chinese but we are furiously working on translations forEnglish, Japanese, and other languages!

Practical Byzantine Fault Tolerance: http://pmg.csail.mit.edu/papers/osdi99.pdf

Proof of Stake FAQ: https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ

Validator Ordering and Randomness http://vitalik.ca/files/randomness.html

Cryptocurrencies without Proof of Work https://arxiv.org/pdf/1406.5694.pdf

A proof of stake Design Philosophy https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51

Delegated Proof of Stake Consensus https://bitshares.org/technology/delegated-proof-of-stake-consensus/

Ed25519 Edwards Curve Digital Signature Algorithm https://ed25519.cr.yp.to/ed25519-20110926.pdf

Bitcoin Multisignature https://en.bitcoin.it/wiki/Multisignature

Lisk https://github.com/LiskHQ/lisk

13.

Contact Information

14. References:

Crypti https://github.com/borispovod/crypti-docs

ASCH https://github.com/AschPlatform/asch