My Zilliqa Dev Setup For 2021

Starling Foundries
Builders of Zilliqa
8 min readApr 9, 2021

--

Being a Zilliqa developer usually means doing both smart contract development in Zilliqa’s smart contract Domain Specific Language Scilla as well as integrations in one or more of the Zilliqa SDKs. In this post I’ll spill the beans on my stack for 2021. I’ve been writing Scilla for 2 years now and let me reassure you, it’s never been easier. With some tricks you can be up and running, rapidly prototyping the next formally verified OpFi protocol or simple $hitcoin. I’ve come to a simplified stack that I recently slimmed down due to getting an M1 macbook Air. It includes: VSCode as my main IDE, neovim for whizzing around and quick edits, node with nvim, the official JS sdk and for production I also use docker. Testing out my projects usually involves the testnet and testnet faucet, although Ceres looks promising.

Starting from the top

This follow-along assumes you have a unix-style terminal this might be WSL for windows, terminal for Mac or any linux shell. Beyond that you should have git installed and configured to where you can clone from github. Download VS Code and install it. You can install either available scilla language plugins, I’ve only used the old one, which is passable with some quirks. That’s all it takes to get VS Code ready, and for beginners I recommend starting with VS Code and going back and forth between your editor window and the Savant IDE to easily access the public type checker. This is probably 80% of my workflow.

Local SDK

Even if you only want to do Scilla development and leave the rest of the dev work to another specialist, you will still eventually want a local SDK installation for tests at least. The most robust SDK by far is the official JS/TS library. I am not a fan of Javascript, but I’ve learned through experience to stick with the herd on this one. There are of course other SDKs including the golang official sdk, a java and python one among many others. For the fact that the ZRC examples are all in Javascript alone, I suggest you start with that one before you jump into your preferred language. The SDK readme has the instructions, which are for installing it as a project dependency, so follow those each time you make a new Zilliqa project. I also keep the ZLI handy on my local machine for some common tasks which I do not want to maintain scrips in JS for, the installation of ZLI is very simple thanks to golang’s modules so I will suggest that you have it, even if you rarely use it. These two pieces together will allow you to manage your off-chain interactions with Zilliqa in as painless a way as possible.

Getting Code

As a developer I try to avoid starting from scratch, its easier to experiment with and reason about an already working codebase than to start from the beginning every time. I mostly rely on the example contracts found in the Zilliqa Reference Contract (ZRC) library. From there I usually use git to track incremental changes, and use the off-chain scripts found in the references folder for each contract to form the basis of my new project. I want to draw your attention to the ZRC2 fungible token contract (ERC-777 clone) in particular, as it is the most mature. I recommend starting with the ZRCs if you’d like to read some working code to get a handle for how to write Scilla. From here, assuming you’ve selected a contract to start with it is helpful to confirm it passes Zilliqa’s typechecker and can thus be deployed to the network.

Checking and Deploying

This is the step in your journey you will feel that someone has put your day on repeat. Testing anything for a distributed setting is hard, so give yourself more time to get Scilla codes right than in your favorite general purpose language. I like to copy and paste my target contract, along with any helper scripts I need to deploy and run it to a git repo, open that whole directory in VScode with:

code .

From there I typically rely on the Savant IDE to access the online type-checker. I’ve had it installed locally at various times but the value-for-effort for that is way too low for me to even include it in this post. Just add your *.scilla file on the left, and then copy/paste code from vscode into the Savant editor panel. Once you click ‘Check’ the checker will run over the contract and probably complain about something — it is very thorough. From here a good rule of thumb is to start from the top, the checker reads the program line-by-line and often errors late in the contract are confounded by the earlier problems, so start from the top of the file and you will debug faster. You’ll get used to this process and this step will go faster as time goes on.

After you’ve got your contract in a state where it is passing the checker, you can even deploy it right from the IDE to the isolated server, testnet or mainnet. I mainly work with the testnet, so it is worth mentioning here that the ‘accounts’ granted by the Savant IDE are automatically given testnet ZIL, but you cannot export them to use with a deploy.js script or transfer.js later. Either expect to do all the wallet stuff in-browser with the builtin accounts, or you should come to Savant with a web3-compliant wallet JSON. For getting testnet ZILs or web3-wallet you must turn to the Nucleus Wallet web app.

The wallets you create with ‘new wallet’ will be valid for all networks, but won’t have any $ZIL to do anything useful without using the faucet to get funds. Once you’re at the step you have generated a wallet, you have to request funds for that wallet from Nucleus. I’ve had issues in the past because the wallet generator reports the address in 0x… format when the faucet expects a bech32 (zilXYZ123…) format. To convert without writing a script, you can paste the address into the devex explorer, which will give you a button to convert back and forth between the address formats.

I typically use the built-in Savant accounts when I don’t need to test off-chain interactions, but when I’ve got a permissioned transition, such as the mint transition in ZRC1, then I know I will eventually have to deploy a version of the contract to test with further Zilliqa Javascript SDK scripts and I will need a wallet shared between them. This is when I reach for the longer process of creating and importing a Nucleus-generated wallet keystore into savant. The panel looks like this and as long as you remember the password, should be painless.

Opening the Import account functions
Many options presented — keystore is easiest for prototyping

This is actually the conclusion of my regular workflow. I still have many other tools I rely on, but the Zilliqa-specific parts are all here, and if you followed along you are ready to get to work. Below I continue with some tips for installing the various SDKs, as well as adding Docker and vim to your workflow.

Appendix

Installation of the Python SDK

The python SDK is honestly an emotional rollercoaster. Parts of it work swimmingly and are very ergonomic to use, parts of it don’t predictably work and I haven’t been able to trace down why. Python is my preferred language, so I’ll help anyone who wants to use it with a free lift over the first (undocumented) hurdle: The implicit requirement for gmp. This library doesn’t come with Python, but is expected by a pyzil dep to exist on your machine. To fix this, on linux install libgmp-dev (ubuntu):

apt install libgmp-devor on OSX:brew install libmpc

I doubt you will find a straightforward installation process on windows, so I don’t suggest it. The Python SDK as of this writing can, as of today, send a valid transaction, so my hope is that with more users it will shape up.

Installation of the Vim plugin

Honestly I’d guess the majority the ZRC code is written using Vim. If you’re familiar with Vim already then you might prefer it like I do. I use both VSCode and Vim locally, but VSCode is typically only used for copying/pasting into Savant. I cannot guess what your setup for vim is, but I personally can recommend neovim, along with the vim-plug plugin manager, which can automatically install the vim-scilla plugin without a hitch.

Installation of Ceres

Ceres is useful as a local tool to simulate the Zilliqa blockchain with artificial ZIL and faster blocks. Both useful for rapid prototyping. The Ceres binary requires several things, including Docker. I went through the readme a few weeks ago and made a PR with the last details you need to get started. So head over to the readme and install away.

A workable DOCKERFILE

The JS SDK does have some funky requirements, and it doesn’t work with all Node versions. After many reinstallations, troubleshooting, I’ve come up with a DOCKERFILE that I use as my starting point for a nodejs Zilliqa App. Here it is in all its glory for you to start with:

FROM node:11-alpine

ENV PRIVKEY="abcdefg12345..."
RUN apk add python alpine-sdk libsodium-dev libtool autoconf automake

RUN mkdir -p /home/node/app/node_modules && chown -R node:node /home/node/app

WORKDIR /home/node/app

COPY package*.json ./

USER node

RUN npm install yarn
RUN yarn

COPY --chown=node:node . .

EXPOSE 8080

CMD [ "node", "app.js" ]

Assuming you already followed the JS SDK installation steps and drop this DOCKERFILE in the project root where the app.js and package.json is, you should be able to just run your app in an isolated container with:

docker build --tag zillibox:1.0 . docker run --publish 8000:8080 --name bb zillibox:1.0

So get out there and make us some Dapps.

--

--

Starling Foundries
Builders of Zilliqa

Errant scientist with solutions looking for problems. I like blockchains and geoscience the most.