Principle and design goals

Technology implementation

Consensus mechanism

In ZILLIQA, we use PBFT as the basis consensus protocol and employ two rounds EC-Schnorr multisignatures to replace the prepare and commit phases in PBFT. The different modifications to the PBFT phases are explained below. 

1) Pre-prepare phase: As in standard PBFT, the leader distributes a TX-Block or a statement (signed by the leader) to all the nodes in the consensus group.

2) Prepare phase: All honest nodes check the validity of the TX-Block and the leader collects responses from more than 2n/3 nodes. This guarantees that the statement proposed by the leader is safe and consistent with all previous histories. The signature is generated using ECSchnorr multisignature. The leader also builds the bitmap of nodes who signed the TX-Block.

3) Commit phase: To ensure that more than 2n/3 nodes know the fact that more than 2n/3 nodes have verified the TX-Block, we perform a second round of EC-Schnorr multisignature. The statement being signed is the multisignature generated from the last round. 

At the end of the three phases, the consensus is reached on the TX-Block proposed by the leader. 

Accounts and transactions

ZILLIQA is an account-based system (as Ethereum). There are two types of accounts: normal account and contract  account. A normal account is created by generating an ECSchnorr private key. A contract account is created by another account.  

Each account (whether normal or contract) is associated with an account state. The account state is a key, value store
and comprises of the following keys:
1) account nonce: (64 bits) A counter (initialized to 0) that counts the number of transactions sent from a normal account. In case of a contract account, it counts the number of contract creations made by the account.
2) balance: (128 bits) A non-negative value. Whenever an account receives tokens from another account, the received amount is added to the account’s balance.When an account sends tokens to another account, the balance is reduced by the appropriate amount.
3) code hash: (256 bits) This stores SHA3-256 digest of the contract code. For a normal account it is the SHA3-256 digest of the empty string.
4) storage root: (256 bits) Each account has a storage which is again a key, value store with 256-bit keys and 256-bit values. storage root is a SHA3-256 digest that represents this storage. For instance, if the storage is a trie, then storage root is the digest of the root of the trie.

A transaction is always sent from a normal account address and it updates the global state of ZILLIQA. A transaction has the following fields:
1) version (32 bits): Current version.
2) nonce (64 bits): A counter equal to the number of transactions sent by the sender of this transaction.
3) to (160 bits): Destination account address. In case the transaction creates a new contract account, this field is the rightmost 160 bits of SHA3-256 of the empty string.
4) amount (128 bits): The transaction amount to be transferred to the destination address.
5) gas price (128 bits): Gas is defined as the smallest unit of computation. gas price is the amount that the sender is willing to pay per unit of gas for computations incurred in the transaction processing.
6) gas limit (128 bits): The maximum amount of gas that should be used while processing the transaction.
7) code (unlimited): An expandable byte array that specifies the contract code. It is present only when the transaction creates a new contract account.
8) data (unlimited): An expandable byte array that specifies the data that should be used to process the transaction. It is present only when the transaction invokes a call to a contract at the destination address.
9) pubkey (264 bits): An EC-Schnorr public key that should be used to verify the signature. The pubkey field
also determines the sending address of the transaction.
10) signature (512 bits): An EC-Schnorr signature on the entire data.
Each transaction is uniquely identified by a transaction ID — a SHA3-256 digest of the transaction data that excludes the signature field.

Smart contract system

ZILLIQA comes with an innovative special-purpose smart contract language and execution environment that leverages the underlying architecture to provide a large scale and highly efficient computation platform. In this section, we present the smart contract layer that employs a dataflow programming architecture.

A. Computational Sharding using Dataflow Paradigm 

ZILLIQA’s smart contract language and its execution platform is designed to leverage the underlying network and transaction sharding architecture. The sharded architecture is ideal for running computation-intensive tasks in an efficient manner. The key idea is the following: only a subset of the network (such as a shard) would perform the computation. We refer to this approach as computational sharding. 

In contrast with existing smart contract architectures (such as Ethereum), computational sharding in ZILLIQA takes a very different approach towards how to process contracts. In Ethereum, every full node is required to perform the same computation to validate the outcome of the computation and update the global state. Albeit being secure, such a fully redundant programming model is prohibitively expensive for running large-scale computations that can be easily parallelized. Examples include simple computations such as search, sort and linear algebra computations, to more complex computations such as training a neural net, data mining, financial modeling, etc. ZILLIQA’s computational sharding approach relies on a new smart contract language that is not Turing-complete but scales much better for a multitude of applications. The smart contract language in ZILLIQA follows a data flow programming style . In the dataflow execution model, a contract is represented by a directed graph. Nodes in the graph are primitive instructions or operations. Directed arcs between two nodes represent the data dependencies between the operations, i.e., output of the first and the input to the second. A node gets activated (or operational) as soon as all of its inputs are available. This stands in contrast to the classical von Neumann execution model (as employed in Ethereum), in which an instruction is only executed when the program counter reaches it, regardless of whether or not it can be executed earlier. The key advantage of employing a dataflow approach is that more than one instruction can be executed at once. Thus, if several nodes in the graph become activated at the same time, they can be executed in parallel. This simple principle provides the potential for massive parallel execution. To see this, we present a simple sequential program in Figure 1a with three instructions and in Figure 1b, we present its dataflow variant.UnderthevonNeumannexecutionmodel,theprogram would run in three time units: first computing A, then B and finally C. The model does not capture the fact that A and B can be independently computed. The dataflow program on the other hand can compute these two values in parallel. The node that performs addition gets activated as soon as A and B are available.

Cryptography

The cryptographic layer defines the cryptographic primitives used in ZILLIQA. Similar to several other blockchain platforms, ZILLIQA relies on elliptic curve cryptography for digital 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 based on Keccak which is widely used in different blockchain platforms in particular Ethereum. In the near future, we may switch to Keccak to enable better interoperability with other platforms.  

Distributed storage protocol

Storage pruning. We are currently exploring ways to securely prune the dated blocks stored on the blockchain to reduce the storage requirements and ease the joining process for new nodes. We may consider multi-grade storage, compression of blocks and transactions as possible solutions.  

Cross-chain and exchange technology

Cross-Chain support. ZILLIQA has every intention to complement other public blockchains and build a healthy ecosystem to provide end users a broad spectrum of platforms of choice for their applications. To this end, ZILLIQA will seek technical solutions to support gradual cross-chain communication and potentially enable cross-chain applications.  

Special technology

Economic model and incentive

A. Token Supply 

ZILLIQA has a finite supply of 21 billion ZILs. The smallest unit being 10−12 part of a ZIL. Each final TX-Block comes with a block reward that generates new tokens. The block reward will be spread over a period of 10 years decreasing over time. We aim to mine roughly 80% of the tokens in the first 4 years and the remaining 20% in the next 6 years. The token emission will be “smooth” in the sense that the block reward does not reduce drastically after a certain number of blocks. The smooth reduction in the block reward means that the network hashrate canbe expectedto be stable as thereward reduces over gradually over time. After 10 years, we expect to have reached significant scale both in terms of the number of nodes in the network and users executing transactions. By then, we expect the market to have stabilized upon certain rates of transaction fees to fully sustain the running of the network without a need for new tokens entering the system as rewards. 

B. Incentivizing Miners 

Miners reach consensus on transactions, process them, perform computations as per the smart contract and update the global state. Miners are hence incentivized by requiring the sender of each transaction to pay some gas upfront.

Governance mechanism

Applications