How Scilla could speed up blockchain transactions

Better throughput will produce more efficient smart contract processing, explains Zilliqa's Amrit Kumar and Ilya Sergey.

How Scilla could speed up blockchain transactions

The program language Zilliqa features a unique "separation between different orthogonal aspects of the language," explains Zilliqa's Ilya Sergey to Dan Patterson of TechRepublic. The following is an edited transcript of the interview.

Dan Patterson: Tell us a little bit about how the code works, how Zilliqa works.

Amrit Kumar: So, one aspect of Zilliqa is first to ensure that the throughput remains very high. It roughly increases linearly with the network size. The other aspect that we'll focus in Zilliqa is to have a smart contract language that's safe to use, that's safe to deploy, so if you write a smart contract language that actually gets deployed on a chain, then it will be bug-free, you know, as much as you can, and actually you can actually prove strong properties about the contract. So you could, for instance, prove that your contract is not going to freeze funds. Your contract is not going to leak funds to other, let's say, parties, and this is where Zilliqa comes in and Ilya will be very happy to elaborate on that bit.

Ilya Sergey: All right, so let me take it from here. So we designed Zilliqa as a programming language which would be good for writing typical applications that people consider smart contracts being a good field for, such as ICOs, such as different crowd funding campaigns, games, but it's a pretty general language.

SEE: IT Hiring Kit: Programmer (Tech Pro Research)

So what makes it different from smart contract programming languages such as Solidity is a separation between different orthogonal aspects of the language. So this separation is what it makes it easier both implement the sharded executions of contracts written in Zilliqa and verify that the contracts are actually doing what they're supposed to do. So think of it this way, so contracts in fact embody multiple functions. They serve as agents that communicate with each other and also with the users of the blockchain performing the transfer of funds and they are also act as ordinary programs that perform the computation.

So these two aspects, the computation and the communication, they are quite orthogonal and it's nice to be able to reason about them separately. So having the communication being something that is sort of outside interface of the contract and this is how the contracts interact with each other makes it possible to fit the interaction between smart contracts into this sharded architecture of Zilliqa, something that Amrit will be able to elaborate upon. So whenever a contract communicates with another contract, this is something that gets processed only by a part of the system in a shard or small subset of the shards rather than the entire network, which will be the case in Ethereum where each transaction is processed by the entire network.

This is how we get the scalability component. The correctness component actually draws from many, many years of research in formal methods and the reasoning about programs and communicating transition systems. So thinking of contracts as these automata that just send messages to each other, we can formulate properties of interest such as whether this contract will eventually give me money back, whether this contract ever performed this operation, and et cetera. So all these properties that we care about, so if you think of it even the recent Parity wallet bug discovered in Ethereum, that was a subject of a problem that can be stated very easily, whether anyone can suicide this contract. If we can write a contract in a way that we can formally prove Ethereum that it is never the case, then we have covered the corresponding safety aspect. So in this way of structuring contracts in Zilliqa makes it possible to prove properties like this formally about the contracts even before we deploy them.

Also see