Zilliqa （ZIL）白皮书.pdf

The ZILLIQA Technical Whitepaper[Version 0.1]August 10, 2017The ZILLIQA Teamm B twitter zilliqaAbstractExisting cryptocurrencies and smart contract plat-s are known to have scalability issues, i.e., the number oftransactions they are capable of processing per second is limited,usually less than 10. As the number of applications utilizingpublic cryptocurrencies and smart contract plats grow, thedemand for processing high transaction rates in the order ofhundreds and thousands of Tx/s is increasing.In this work, we present ZILLIQA a new blockchain platthat is designed to scale in transaction rates. As the number ofminers in ZILLIQA increases, its transaction rates are expected toincrease. At Ethereum’s present network size of 30,000 miners,ZILLIQA would expect to process about a thousand times thetransaction rates of Ethereum. The cornerstone in ZILLIQA’sdesign is the idea of sharding dividing the mining networkinto smaller shards each capable of processing transactions inparallel.ZILLIQA further proposes an innovative special-purpose smartcontract language and cution environment that leverages theunderlying architecture to provide a large scale and highlyefficient computation plat. The smart contract language inZILLIQA follows a dataflow programming style which makes itideal for running large-scale computations that can be easilyparallelized. Examples include simple computations such assearch, sort and linear algebra computations, to more complexcomputations such as training neural nets, data mining, financialmodeling, scientific computing and in general any MapReducetask.I. INTRODUCTIONCryptocurrencies and smart contract plats are becom-ing a shared computational resource. One could view theseplats as a new generation of computers that synchronizeover thousands of individual computers. However, existingcryptocurrencies and smart contract plats have widelyrecognized limitations in scaling. Average transaction rates inBitcoin [1], Ethereum [2], and related cryptocurrencies havebeen limited to below 10 usually about 3-7 transactionsper second Tx/s. As the number of applications utilizingpublic cryptocurrencies and smart contract plats grow, thedemand for processing high transaction rates in the order ofhundreds of Tx/s is increasing. A global payment networkwould likely require tens of thousands of Tx/s in capacity.Can we build a decentralized and open blockchain platcapable of processing at that scaleThe limitations in scaling up existing protocols are some-what fundamental they are rooted in the design of theconsensus and network protocols. Therefore, even though re-engineering the parameters of the existing protocols in sayBitcoin or Ethereum e.g., the block size or the block ratemay show some speedup, to support applications that needprocessing of thousands of Tx/s however requires rethinkingthe underlying protocols from scratch.We present ZILLIQA a new blockchain plat that isdesigned to scale in transaction rates. As the number of minersin ZILLIQA increases, its transaction rates are expected toincrease as well. Specifically, ZILLIQA’s design allows itstransaction rates to roughly double with every few hundrednodes added to its network. As of this writing, the Ethereummining network is over 30,000 nodes. At Ethereum’s presentcapacity, ZILLIQA would expect to process about a thousandtimes the transaction rates of Ethereum.ZILLIQA is a redesign from scratch and has been underresearch and development for over 2 years. The cornerstonein ZILLIQA’s design is the idea of sharding dividing themining network into smaller consensus groups called shardseach capable of processing transactions in parallel. If themining network of ZILLIQA is say 8000 miners, ZILLIQAautomatically creates 10 sub-networks each of size 800 miners,in a decentralized manner without a trusted co-ordinator. Now,if one sub-network can agree on a set of say 100 transactionsin one time epoch, then 10 sub-networks can agree on a totalof 1000 transactions in aggregate. The key to aggregatingsecurely is to ensure that sub-networks process different trans-actions with no overlaps without double-spending.The assumptions are similar to existing blockchain-basedsolutions. We assume that the mining network will have a frac-tion of malicious nodes/identities with a total computationalpower that is a fraction 14 of the complete network.It is based on a standard proof-of-work scheme, however, ithas a new two-layer blockchain structure. It features a highlyoptimized consensus algorithm for processing shards.ZILLIQA further comes with an innovative special-purposesmart contract language and cution environment that lever-age the underlying architecture to provide a large scale andhighly efficient computation plat. The smart contractlanguage in ZILLIQA follows a dataflow programming style,where the smart contract can be represented as a directedgraph. Nodes in the graph are operations or functions, while1an arc between two nodes represent the output of the first andthe to the second. A node gets activated or operationalas soon as all of its s become valid and thus a dataflowcontract is inherently parallel and suitable for decentralizedsystems such as ZILLIQA.The sharded architecture is ideal for running large-scalecomputations that can be easily parallelized. Examples includesimple computations such as search, sort and linear algebracomputations, to more complex computations such as train-ing a neural net, data mining, financial modeling, scientificcomputing and in general any MapReduce task among others.This document outlines the technical design of ZILLIQAblockchain protocol. ZILLIQA has a new, conceptually cleanand modular design. It has six layers the cryptographic layerSection III, data layer Section IV, the network layer Sec-tion V, the consensus layer Section VI, the smart contractlayer Section VII and the incentive layer Section VIII.Before we present the different layers, we first discuss thesystem settings, underlying assumptions and threat modelin Section II.II. SYSTEM SETTING AND ASSUMPTIONSEntities in ZILLIQA. There are two main entities inZILLIQA users and miners. A user is an external entitywho uses ZILLIQA’s infrastructure to transfer funds or runsmart contracts. Miners are the nodes in the network whorun ZILLIQA’s consensus protocol and get rewarded for theirservice. In the rest of this whitepaper, we interchangeably usethe terms miner and node.ZILLIQA’s mining network is further divided into severalsmaller networks referred to as a shard. A miner is assignedto a shard by a set of miners called DS nodes. This set of DSnodes is also referred to as the DS committee. Each shard andthe DS committee has a leader. The leaders play an importantrole in the ZILLIQA’s consensus protocol and for the overallfunctioning of the network.Each user has a public, private key pair for a digital signa-ture scheme and each miner in the network has an associatedIP address and a public key that serves as an identity.Intrinsic token. ZILLIQA has an intrinsic token calledZillings or ZILs for short. Zillings give plat usage rightsto the users in terms of using it to pay for transactionprocessing or run smart contracts. Throughout this whitepaper,any reference to amount, value, balance or payment, shouldbe assumed to be counted in ZIL.Adversarial model. We assume that the mining network atany point of time has a fraction of byzantine nodes/identitieswith a total computational power that is at most f n4 of thecomplete network, where 0 f 1 and n is the total sizeof the network. The factor 14 is an arbitrary constant boundedaway from 13 selected as such to yield reasonable constantparameters. We further assume that honest nodes are reliableduring protocol runs, and failed or disconnected nodes arecounted in the byzantine fraction.Byzantine nodes can deviate from the protocol, drop ormodify messages and send different messages to honest nodes.Further, all byzantine nodes can collude together. We assumethat the total computation power of the byzantine adversariesis still confined to standard cryptographic assumptions ofprobabilistic polynomial-time adversaries.We however assume that messages from honest nodes inthe absence of network partition can be delivered to honestdestinations after a certain bound , but may be time-varying.The bound is used to ensure liveness but not safety [3]. Incase such timing and connectivity assumptions are not met, itbecomes possible for byzantine nodes to delay the messagessignificantly simulating a gain in computation power orworse “eclipse” the network [4]. In the event of networkpartition, as dictated by the CAP theorem, one can only choosebetween consistency and availability [5]. In ZILLIQA, wechoose to be consistent and sacrifice availability.III. CRYPTOGRAPHIC LAYERThe cryptographic layer defines the cryptographic primi-tives used in ZILLIQA. Similar to several other blockchainplats, ZILLIQA relies on elliptic curve cryptography fordigital signatures and a memory-hard hash function for proof-of-work PoW.Throughout this whitepaper, we extensively use SHA3 [6]hash function to present our design. SHA3 is originally basedon Keccak [7] which is widely used in different blockchainplats in particular Ethereum. In the near future, we mayswitch to Keccak to enable better interoperability with otherplats.A. Schnorr SignatureZILLIQA employs Elliptic Curve Based Schnorr SignatureAlgorithm EC-Schnorr [8] as the base signing algorithm.We instantiate the scheme with secp256k1 curve [9]. Thesame curve is currently used in Bitcoin and Ethereum but fora different signing algorithm called ECDSA. Choosing EC-Schnorr over ECDSA has several benefits that we discussbelow1 Non-malleability Inally put, the non-malleabilityproperty means that given a set of signatures generated ona message using a private key, it should be hard for anadversary to produce a new signature for the same messagethat is valid for the corresponding public key. Unlike ECDSAwhich is malleable, EC-Schnorr has been proven to be non-malleable [10].2 Multisignature A multisignature scheme allows multi-ple signers to “aggregate” their signatures on a given messageinto a single signature which can be authenticated against asingle public key that “aggregates” the keys of all the autho-rized parties. While, EC-Schnorr is natively a multisignaturescheme see [11], ECDSA allows creating multisignatures butin a less flexible way.ZILLIQA uses EC-Schnorr based multisignatures to reducethe signature size when multiple signatures are required on amessage. Smaller signatures are particularly important in ourconsensus protocol where multiple parties need to agree on adata by signing it.23 Speed EC-Schnorr is faster than ECDSA since the latterrequires computing an inverse modulo a large number. Noinversion is required in EC-Schnorr.The exact EC-Schnorr key generation, signing and verifica-tion procedures are given in Appendix A. In the Appendix, wealso present how EC-Schnorr can be used as a multisignaturescheme.B. Proof of WorkZILLIQA uses PoW only to prevent Sybil attacks andgenerate node identities. This is in contrast to many ex-isting blockchain plats in particular Bitcoin [1] andEthereum [12], where PoW is used to reach distributedconsensus. ZILLIQA employs Ethash [13], the PoW algorithmused in Ethereum 1.0.Ethash is a memory hard hash function designed to make iteasy to mine with GPUs but hard with specialized computinghardware such as ASICs. To achieve this, Ethash computationrequires a considerable amount of memory in GBs and I/Obandwidth such that the function cannot be invoked in parallelon specialized computing hardware.Roughly speaking, Ethash takes a data for instance a blockheader and a nonce of 64-bits as s and generates a 256-bits digest. The algorithm consists of four subroutines whichare run in the given order1 Seed generation Seed is a SHA3-256 digest which isupdated after every 30000 blocks called an epoch. Forthe first epoch it is the SHA3-256 hash of a series of32 bytes of zeros. For every other epoch it is always theSHA3-256 hash of the previous seed.2 Cache generation The seed is used to generate a pseu-dorandom cache using SHA3-512. The size of the cachelinearly increases with epoch. The initial size of the cacheis 16 MB.3 Dataset generation The cache is then used to generatea dataset, where each “item” in the dataset depends ononly a small number of items in the cache. The datasetis updated once every epoch so that the miners do nothave to make changes to it very frequently. The size ofthe dataset also increases linearly with epoch. The initialsize of the dataset is 1 GB.4 Mining and Verification Mining involves grabbing ran-dom slices of the dataset and hashing them together.Verification uses the cache to regenerate the specificpieces of the dataset needed to compute the hash.IV. DATA LAYERBroadly speaking, the data layer defines the data thatconstitutes the global state of ZILLIQA. By extension, it alsodefines the data needed by the different entities in ZILLIQAto update its global state.A. Accounts, Addresses and StateZILLIQA is an account-based system as Ethereum. Thereare two types of accounts normal account and contractaccount. A normal account is created by generating an EC-Schnorr private key. A contract account is created by anotheraccount.Each account is identified by an address derived differentlydepending on its type. The address for a normal account isderived from the account’s private key. For a given privatekey sk, the address Anormal is a 160-bit value computed asAnormal LSB160SHA3-256PubKeysk;where, LSB160 returns the rightmost 160 bits of the and PubKey returns the public key corresponding to the in-put secret key. The address for a contract account is computedfrom the address of its creator and how many transactions thecreator account has sent, aka account nonce described below.Acontract LSB160SHA3-256addressjjnonce;where, address is the address of the creator account, andnonce is the creator’s nonce value.Each account whether normal or contract is associatedwith an account state. The account state is a key, value storeand comprises of the following keys1 account nonce 64 bits A counter initialized to0 that counts the number of transactions sent from anormal account. In case of a contract account, it countsthe number of contract creations made by the account.2 balance 128 bits A non-negative value. Wheneveran account receives tokens from another account, thereceived amount is added to the account’s balance.When an account sends tokens to another account, thebalance is reduced by the appropriate amount.3 code hash 256 bits This stores SHA3-256 digestof the contract code. For a normal account it is theSHA3-25