11
May
20

Zilliqa (ZIL) Guide - a scalable, secure blockchain platform

Zilliqa describes itself as “the scalable and secure blockchain platform for hosting decentralized applications.” It’s one of the most well-known projects in the space that uses sharding technology. It also uses a unique smart contract language called “Scilla.” We take a look at both of them in future sections. Zilliqa is a third-generation blockchain, which aims to solve one of the most pressing issues in the space – scalability.

 

The Team behind Zilliqa

 

In 2017, a group of computer scientists and academics created the platform. The team includes Prateek Saxena from the University of California and Xinshu Dong and Amrit Kumar from the University of Singapore.

 
The core team of Zilliqa consists of 5 people. Their expertise ranges from marketing, technology, development to operations.
 
Ziliqa also has a very impressive board of advisors.
 
The advisory board of zilliqa consists of highly qualified individuals
 
Here’s a brief look at some of the main advisors.
 

  • Loi Luu is the CEO and Founder of Kyber.
  • Evan Cheng is the Director of Engineering, Blockchain at Facebook
  • Aquinas Hobor is the Assistant Professor at National University of Singapore
  • Alexander Lipton is the Chief Technical Officer at SilaMoney
  • Nicolai Oster is the Head of ICO & Partner at Bitcoin Suisse AG
  •  

    What is Sharding?

     
    As Zilliqa puts it:
     

    “Sharding is a concept that has existed in distributed databases for a long time but hasn’t been demonstrated for open, permissionless blockchains (where anyone can join and participate) at scale. The idea is to automatically split up a large network of machines processing transactions into parallel sub-committees or “shards”. Each shard processes its own microblock in parallel with other shards, and resulting microblocks are merged into a final one. This automatic network parallelization has now been made practical for open blockchains through Zilliqa!”

     

    Sharding is a term that has been taken from database systems. In database systems, you have to deal with a humongous amount of bulky data. This, unfortunately, makes the database extremely cumbersome to deal with and affects overall throughput and performance. By utilizing sharding, you can horizontally partition your database and turn them into smaller, more manageable tables.

     
    The following diagram shows you a pictorial representation of sharding at work:
     

     
    So, why specifically a horizontal partition and not a vertical one? Check out the following table.
     

     
    Now, if we partition the table vertically, this is what we get:
     

     

    As you can see, when you partition the table vertically, you get two completely different tables. Because of the partition, the table turns into two completely different tables. As opposed to that, what happens when the table gets partitioned horizontally?

     
    However, if we were to partition the database horizontally, this is what you get:
     

     

    A horizontal partition turns the database into smaller tables of the same database. These smaller databases are called shards.

     

    How does Sharding Help Blockchain?

     

    The problem with projects like Ethereum or Bitcoin is that as more nodes enter the ecosystem, the more time it takes for the network to reach consensus. Sharding will help break the global state of the blockchain into tinier, more manageable shards. Every single unique account is in one shard and the accounts in that shard will only transact with the other accounts in the same shard.

     
    Vitalik Buterin explained shards like this:
     

    “Imagine that Ethereum has been split into thousands of islands. Each island can do its own thing. Each of the islands has its own unique features and everyone belonging on that island i.e. the accounts, can interact with each other AND they can freely indulge in all its features. If they want to contact other islands, they will have to use some sort of protocol.”

     

    If utilized properly, sharding technology can allow a decentralized network to enjoy increased transaction rates as the network expands.

     

    While sharding is an amazing idea, it has one significant weakness.

     

    You see, as bitdegree puts it, think of sharding as breaking up a book into two and giving a half each to two people and telling them to find out what the full story is. The only way that they can do so is to meet each other physically and find out what the full story is.

     

    In the scenario of a blockchain, instead of ripping up a book in half, we are ripping up the entire library in half and throwing the halves over a tiny continent and telling the residents to figure out each individual story.

     

    Can you imagine the sheer amount of energy it will take to do something like that? This is why Ziliqa has a hybrid consensus mechanism that utilizes Proof of Work (POW) and Practical Byzantine Fault Tolerance (PBFT).

     

    Mining POW and PBFT

     

    Proof of work is the same consensus mechanism that is used by Bitcoin. In it, there are participants called “miners” who mine for new blocks and coins by solving complex computational puzzles. Proof of work or (POW) is one of the best defenses against a Sybil attack. In a Sybil attack, an attacker takes control of several different nodes and floods the network with spam transactions. Using POW, this will be exceedingly expensive for an attacker to do.

     

    Ok, so that one half of the consensus mechanism, what about the other half then? The other half is PBFT or Practical Byzantine Fault Tolerance. By using this method, Zilliqa guarantees “finality.”

     

    Finality, in very loose terms, means that once a particular operation has been done, it will forever be etched in history and nothing can revert that operation. This is particularly important in fields that deal with finance. Imagine that Alice owns a particular amount of an asset in a company. If there is some glitch in the company’s processes, she shouldn’t have to revert ownership of that asset.

     
    So, let’s work with what we have here right now.
     

    Sharding gives Zilliqa a tool that it can use to achieve high transaction speeds, while the POW-PBFT hybrid consensus mechanism allows Zilliqa to do so efficiently. In fact, Zilliqa can reach speeds of 2,000 transactions per second, which is significantly higher than Bitcoin, Ethereum’s, and even Visa.

     

    This is a crucial fact, and we will explore how this is going to boost up Zilliqa’s token value later on in the report.

     

    Zilliqa ICO

     

    Zilliqa raised around $20 million USD in private funding alone at the end of 2017. That was more than enough for the project to start operations without having an ICO. However, there was so much interest and demand in the project that the team decided to hold an ICO so that people can get their hands on the ZIL tokens. Subsequently, an ICO was held between 27th December 2017 and 4th January 2018, wherein the company raised a further $20 million.

     

    Zilliqa and smart contracts

     

    To power its smart contracts, Zilliqa has created its own programming language called Scilla or Smart Contract Intermediate-Level LAnguage. The main issue that Scilla is looking to solve is smart contract security. So, before we take a look into how Scilla works, let’s see the security problems that the current smart contracts are facing.

     

    The Current State of Smart Contract Security

     

    Back in 2016, everyone was excited about The DAO. It was basically a complex smart contract that was going to be a decentralized venture capital fund for future Dapp development. However, that dream soon came crashing down, when a vulnerability in their smart saw a hacker siphon away $50 million dollars worth of Ethereum. This incident caused such a cataclysmic uproar that the entire Ethereum community got split into Ethereum Classic and Ethereum.

     
    The scary part is that this is not a one-off situation.
     

    Smart contract security is a huge cause of concern for prospective investors. In order to gain mainstream adoption, smart contracts and cryptocurrencies must earn the unwavering faith of the public.

     

    This begs the question, what exactly is stopping smart contracts from gaining complete security?

     

    Firstly, as you may know, blockchains and smart contracts are inherently immutable by nature. Meaning, once you enter something into the blockchain, you can’t tamper with it anymore. While this is definitely a big plus point, the fact remains this has an undesirable flipside as well. Once a smart contract has been executed, you can’t go back and fix a bug! Basically, if you want to avoid a hard fork, then you better be 100% sure that your smart contract is absolutely faultless.

     

    Obviously, that is an unreasonable thing to ask and this why the crypto space right now is riddled with faulty smart contracts. As Ethereum Foundation’s Martin Swende puts it, “This is Disneyland for hackers.”

     

    Secondly, one must keep in mind that these solidity contracts are running on gas consumption. So, whenever a developer presents a smart contract for execution, they must specify a gas limit as well. Since each and every line of the contract code consumes gas, the specified limit should be enough to cover the entire contract.

     

    This is why it is doubly important to make sure that the contract isn’t buggy. A bug may simply siphon away all the gas in the contract mid-execution. Also, we can’t simply let a buggy contract float around in the ecosystem, because the whole process is being executed in a Byzantine network where we are assuming that each and every node is malicious and trying to take advantage of a vulnerability.

     

    Ok, so what is the solution here?

     

    Let’s look at what two of the most important cryptocurrencies in the world are doing.

     

    Bitcoin is using a simple scripting language to take care of their transactions. The language is simple for entry-level participants to understand and take part in. However, it is not that flexible and only allows for relatively simplistic transactions.

     

    On the other hand, Ethereum is using the Turing complete solidity. Meaning, if given enough time and resources, it should be, theoretically, able to compute anything. So, while this affords developers a lot of flexibility, it is a simple language and can lead to disasters if not coded properly.

     

    This is why Zilliqa chose to create an intermediate-level language. Scilla hopes to be both simple to understand and flexible enough for real-world applications. One thing to keep in mind, while Scilla is being designed in the context of Zilliqa, it is not agnostic to the underlying blockchain platform and hence can be used with any other blockchain.

     

    How Does Scilla Work?

     

    So, how does Scilla achieve this balance between flexibility and simplicity without compromising on security? By separating various programming concerns, namely:

     

  • Between computation and communication
  • Between effectful and pure computations
  • Between invocation and continuation
  •  
    Computation and Communication
     

    There are tons of computations that take place during smart contract execution like balance changing, value computation of a function, etc. These computations are implemented as standalone, atomic transitions that are self-sufficient and don’t require involvement from other parties.

     

    However, there may be instances during the contract execution when such an involvement will be required (e.g. when you need to transfer the control of a particular mechanism to another party). In instances such as these, the program demands explicit communication between the parties via message sending and receiving.

     
    This property allows the smart contract to:
     

  • Compute without outside interference.
  • Make sure that concrete and efficient communication is maintained when another party needs to get involved in the operations.
  •  
    Effectful and Pure Computations
     

    Smart contracts need to have an in-built halting property. Every computation that is taking place within the contract has to be terminable. Also, these must have a predictable effect on the overall state of the contract. This property ensures that contract execution remains under control and doesn’t behave in unforeseen ways.

     
    Invocation and Continuation
     

    The contracts in Scilla are structured as communication automata which provides a computational model, known as continuation-passing style (CPS), where a call to an external function is made in the last line of instruction.

     
    So, what exactly is the advantage of this model?
     

    Calling an external function mid-execution can lead to a plethora of problems, like the re-entrancy attack. In fact, it was the re-entrancy attack that caused the DAO attack.

     
    How is a Scilla Contract Framed?
     
    The following is what a simple Scilla contract looks like:
     
    (* Scilla contract structure *)

    (***************************************************)
    (* Associated library *)
    (***************************************************)

    library MyContractLib

    (* Library code block follows *)

    (***************************************************)
    (* Contract definition *)
    (***************************************************)

    contract MyContract

    (* Immutable fields declaration *)
    (vname_1 : vtype_1,
    vname_2 : vtype_2)

    (* Mutable fields declaration *)

    field vname_1 : vtype_1 = init_val_1
    field vname_2 : vtype_2 = init_val_2

    (* Transitions *)

    (* Transition signature *)

    transition firstTransition (param_1 : type_1, param_2 : type_2)

    (* Transition body *)

    end

    transition secondTransition (param_1: type_1)

    (* Transition body *)

    end
     
    NOTE: Code taken from Scilla docs.
     

    As you can see, the contract starts with library declaration. The libraries contain simple mathematical functions like a function to compute the boolean and of two bits or computing factorial of a given natural number.

     
    The contact that you see above has three parts to it:
     

  • Declaring immutable variables of the contract
  • Declare the mutable fields
  • Transition definitions
  •  
    Part #1: Immutable Variables
     
    The immutable variables are declared in this part of the contract:
     
    vname_1 : vtype_1,
    vname_2 : vtype_2

     

    The immutable variables (or contract parameters) have their values defined at the time of contract creation and cannot be tampered with later on. These variables are specified at the beginning of the contract, right after the contract name is defined.

     
    Each declaration has:
     

  • A variable name and its type. Both of those are separated by a “:”
  • If multiple declarations are required, then they are separated by a “,”
  • They must be initialized at the time of contract creation
  •  
    Part #2: Mutable Fields
     
    Following are the mutable fields in the contract:
     
    field name1 : type1 = expr1
    field name2 : type2 = expr2

     

    This part of the contract represents the state that is not set in stone. It presents the mutable and changeable part of the contract which is subject to state transition. In other words, the value of these fields get modified as the contract goes through various transitions.

     
    Part #3: Transitions
     

    The “Transitions” section of the contract defines the change in the state of the contract. The follow section shows the two transition states that our contract are going through:

     
    transition firstTransition (param_1 : type_1, param_2 : type_2)

    (* Transition body *)

    end

    transition secondTransition (param_1: type_1)

    (* Transition body *)

    end

    As you can see, these transitions are defined by the keyword “transition”, followed by the name and parameters to be passed. The transition function ends with the “end” keyword.

    Now, let’s look at what is happening inside the parameters.

    (param_1 : type_1, param_2 : type_2)

  • param_1 is the name of the parameter
  • type_1 is the type of parameter param_1
  • The param_1 and type_1 are separated by a “:”
  • Multiple parameters are separated by a “,”/li>

    Ok, so we have seen how the parameters are declared within the transition function. However, what about the “transition” keyword itself? Turns out, each transition has the following implicit parameters available to it:

  • _sender : ByStr20 = This is the account of the sender of the message, i.e. the one that triggered this transition
  • _amount : Uint128 = This is the incoming amount of ZIL tokens. These must be accepted explicitly by the “accept” statement. Remember, when we told you that explicit messaging is required in Scilla whenever an outside party gets involved? This is an example of that. The money transfer doesn’t take place if the transition function doesn’t execute “accept”.
  •  

    The Classic HelloWorld Contract

     

    Let’s take a look at how a classical “Hello World” contract works in Scilla.

     
    library HelloWorld
    let one_msg =
    fun (msg : Message) =>
    let nil_msg = Nil {Message} in
    Cons {Message} msg nil_msg

    let not_owner_code = Int32 1
    let set_hello_code = Int32 2

    contract HelloWorld
    (owner: ByStr20)

    field welcome_msg : String = ""
    transition setHello (msg : String)
    is_owner = builtin eq owner _sender;
    match is_owner with
    | False =>
    msg = {_tag : "Main"; _recipient : _sender; _amount : Uint128 0; code : not_owner_code};
    msgs = one_msg msg;
    send msgs
    | True =>
    welcome_msg := msg;
    msg = {_tag : "Main"; _recipient : _sender; _amount : Uint128 0; code : set_hello_code};
    msgs = one_msg msg;
    send msgs
    end
    end

     
    Alright, so let’s breakdown sections of this contract and see what is going on.
     
    Section #1: Libraries
     
    library HelloWorld

    let one_msg =
    fun (msg : Message) =>
    let nil_msg = Nil {Message} in
    Cons {Message} msg nil_msg

    let not_owner_code = Int32 1
    let set_hello_code = Int32 2

    A library is declared right in the beginning of the smart contract. This HelloWorld contract code has a function one_msg in the library and two global constants.

    Section #2: Mutable and Immutable Variables

    contract HelloWorld
    (owner: Address)

    field welcome_msg : String = ""
     

    Like we have mentioned before, Scilla contracts have two kinds of state variables:

     

  • Mutable
  • Immutable
  •  

    In this HelloWorld contract, “owner” is the immutable variable. Throughout the execution of this contract, the owner’s address won’t change.

     

    On the other hand, the variable “welcome_msg” is a mutable variable whose state adn value will change through the contract execution.

     

    Section #3: Transitions

     
    transition setHello (msg : String)
    is_owner = builtin eq owner _sender;
    match is_owner with
    | False =>
    msg = {_tag : "Main"; _recipient : _sender; _amount : Uint128 0; code : not_owner_code};
    msgs = one_msg msg;
    send msgs
    | True =>
    welcome_msg := msg;
    msg = {_tag : "Main"; _recipient : _sender; _amount : Uint128 0; code : set_hello_code};
    msgs = one_msg msg;
    send msgs
    end
    end

    transition getHello ()
    r <- welcome_msg;
    msg = {_tag : "Main"; _recipient : _sender; _amount : Uint128 0; msg : r};
    msgs = one_msg msg;
    send msgs
    end

     

    We have two transition functions here, which can change the value of the mutable variables and engage in inter-contract communication. What are these two transition functions?

     

  • setHello(): This transition function takes a String as input, updates welcome_msg and informs the caller about the success/failure of the operation
  • getHello(): This function simply sends the current value of welcome_msg to the caller.
  •  

    If you’re interested in trying out Scilla, then you can test out the following two platforms:

     

  • Blockchain IDE
  • Interpreter IDE
  •  

    Conclusion

     

    If Zilliqa can pull off their product, then they may very well open the floodgates to truly scalable Dapps. The Zilliqa development team is strong in technology and business. They have made some valuable partnerships and an extremely active community supports it. Zilliqa has so far managed to do a throughput of more than 2,800 transactions per second. This is one of the most promising projects in the space and something you should definitely keep an eye out for.

    disclaimer

    CHAIA.iO is not a registered investment, legal or tax advisor or a broker/dealer. All investment/financial opinions expressed by CHAIA.iO or the authors of the respective articles on www.chaia.io are from personal research and experience of the owner of the site or the authors and are intended as educational material. Although best efforts are made to ensure that all information is accurate and up to date, occasionally unintended errors or misprints may occur. You should take independent financial advice from a professional in connection with, or independently research and verify, any information that you find on our Website and wish to rely upon, whether for the purpose of making an investment decision or otherwise.

    Rajarshi Mitra
    Blockchain Researcher