Developing decentralized applications on blockchain can be challenging. Unfamiliarity with the new technology, long waiting times and the inability to “trace” errors on smart contracts are some of the reasons why development is an uphill task.

To tackle some of these challenges, we have developed Kaya RPC — Zilliqa’s RPC client for testing and development of dApps. If you are familiar with Solidity development, you can think of Kaya RPC as Zilliqa’s version of Ganache (https://truffleframework.com/ganache).

Why do we need another “Ganache”?

Ganache (originally TestRPC) was built to support smart contract development on Ethereum. DApp developers building on Zilliqa have different needs, as Zilliqa’s smart contract language is Scilla and not Solidity. If you are wondering why we use a different programming language, check out this article. Due to this difference, Scilla smart contracts are processed differently. Therefore, we built Kaya RPC from scratch to support Zilliqa DApp development.

What is Kaya RPC for?

Generally, we can classify the smart contract lifecycle into three phases — development, staging and production.

In the development phase, you can use our interpreter IDE (“Savant”) to develop your smart contracts (tutorial). However, a dApp does not only comprise of smart contracts. DApps usually have an interface, such as a web app, that will allow users to interact with the smart contract.

Your app should have an endpoint, which you can use to connect to Kaya RPC, testnet or Zilliqa blockchain.

Kaya RPC emulates the Zilliqa blockchain and will return response and error messages in the same format (as specified in the API docs).

After developing and testing on the Kaya RPC, you can proceed to the staging phase. In the staging phase, you would deploy your smart contract on the testnet. To deploy a contract or invoke a transition in a contract, you can use the blockchain IDE. The Blockchain IDE is connected to the Zilliqa blockchain via a testnet wallet and a block explorer and hence comes with (almost) all the features needed to test a Scilla contract in a real blockchain environment.

There are some differences when you are running your code on the blockchain. Unlike Kaya RPC where every transaction is confirmed instantaneously, the blockchain will consolidate and confirm transactions in batches, as consensus must be reached between the nodes. Debugging on testnet can be difficult as there are no error logs unlike Kaya RPC.

After you have adequately tested your dApp on the testnet, you are all set to deploy on the mainnet once it launches!

Using Kaya RPC

The first thing you need to do is to clone the repo and install the node packages.

git clone https://github.com/Zilliqa/kaya.git
cd kaya
npm install

Then, run node server.js. You should see the following:

Your account addresses and private keys might be different. Kaya RPC generates random keypairs by default, but there’s an option to load keypairs from a file (will be discussed more in the next section). Kaya RPC listens on localhost:4200 by default.

Interpreter

In the third line, it says that the Kaya RPC is running from the remote interpreter. What does that mean?

Scilla code has to be processed by an interpreter, which basically processes your code line-by-line and renders an output based on your input. Kaya RPC can’t run without the interpreter. The interpreter is to Kaya RPC like an engine is to a car. You need to have it.

By default, this “engine” is on a remote server. Kaya RPC will send this server a request (“interpreter request”) and wait for a response. Once a response has been received from the interpreter, Kaya RPC will process it and return a response back to the client app.

Although this is the default behaviour, it is not always the best option. For example, if you are building a high-throughput game app, the interpreter request and response will soon be a bottleneck to your app development. Generally, we try to minimize network calls as much as possible. This is when you can consider using a local interpreter to process the code (Mac or Unix-based systems required).

Configurable options

Kaya RPC is versatile and can be configured to fit the needs of developers. Some of the configurations available includes port and directory customizations, load and save data files and using fixed account key-pairs. Let me walk you through how to enable these features in the Kaya RPC.

To view all options, type node server.js -?

To start the server based with verbose mode, you can do:

node server.js -v

Personally, I love the verbose mode -v as the stack trace is extremely useful for debugging. For example, if you try to create a transaction with an invalid nonce, you will get something like this:

Let’s try to debug this message together. Firstly, we observed that the user’s nonce is 2. The payload nonce is also 2. Recall that the nonce is a counter that increases every time you send a transaction from your account. Therefore, since the user’s nonce is currently 2, the payload should have a nonce of 3. This is just a simple example of how we can use Kaya RPC’s stack trace feature to debug your application.

config.js is another way to configure the settings. If no flags are enabled, the app will load settings from the config.js file.

Another option that is useful is fixtures, which is the ability to load accounts keypairs from a file:

node server.js -v -f test/account-fixtures.json

Having a predictable set of account keypairs will help you to test your application quickly as you don’t have to copy/paste the private keys every time.

Interacting with Kaya RPC

Kaya RPC is a server which accepts incoming requests as long as it’s in the right format. You can test Kaya RPC using the scripts found under test/scripts/. The scripts use zilliqa-js, Zilliqa’s official Javascript library, to send transactions to the Kaya RPC.

On one console, npm run debug:fixtures. On another console, run node DeployContract.js — test. It will automatically send a request to Kaya RPC to “deploy” a HelloWorld contract. Next, you can use node CreateTransaction.js — test to change the welcome message to Morning.

How can you tell that the changes has been made? You can make a request to check the server for the contract state. Our API Docs have a list of methods you can use to interact with the Kaya RPC Server (or Zilliqa blockchain in general). For example, if we try to do a curl request to check for the state, you will get something like:

You may be wondering, how would I know the contract address? If your verbose mode is on, you would be able to see it on the console screen. Otherwise, you can try to do GetSmartContracts to get the state of all contracts created by an account.

Summary

Kaya RPC is built to help developers to build dApps faster and more easily. The development of Kaya RPC is an ongoing process, so it does not support every method yet. The code is open-source (https://github.com/Zilliqa/kaya), so please feel free to contribute!

We will share more insights and tutorials on building a dApp end-to-end in the more blog posts coming up soon.