Origins of Spice: lessons learned in smart contract development (Part I)
This post is the first in a series about our in-house, dog-fed tool: Dune Spice. Are you interested in having the Spice’s accumulated expertise ported to your blockchain/language? Then get in touch! We’ll be releasing Spice very soon!
When I started writing smart contracts, I assumed it would be just like any other programming task. You have your world computer, the blockchain. You write entrypoints which receive money, compute stuff and possibly send back some money. You stare really hard at the program once written, test it, maybe even prove it correct to some extent. In return, you get a sort of unbreakable vending machine that people can trust because it does exactly what its code tells it. End of story?
Well, not all your users will be keen on writing command line calls to your dapp. Perhaps then, you’ll want to build a front-end: a webapp. This webapp is going to need to interact with the blockchain constantly, either to query its state or to send transactions.
So, for the sake of usability, you’re going to want to replicate the on-chain data structures in your webapp, and sync it with the blockchain. You’ll probably need to do some of that in the back-end. Maybe you’re running a raffle, and you need to periodically insert a secret number into it, and, later, you need to reveal it? You need to crawl the blockchain for transactions to and from your smart contract, in order to monitor what’s going on.
What I’m getting at is you’ll probably need to duplicate a lot of code, in several programming languages (say Liquidity, OCaml and Javascript in our case). Smart contracts are hard to get right. You need performance and security because this piece of code will be on-chain forever, manipulating people’s money. Odds are you’re going to have to make lots of small to big changes all the way until the last stages. Every time, you’ll need to modify at least three code-bases to propagate these changes. What could go wrong?!
It is dangerous to do things this way, this much is clear. But what I’ve learned from actually developing and deploying smart contracts is that it’s also really, really tedious. My bet is that this is playing a big part in why smart contract development has not taken off as much as one might have imagined a few years ago. And when it has, spectacular bugs have occurred (at this point, I don’t think I even make a list of links to the horror stories out there!).
Dogfooding Spice
In response to both the tedium and the anxiety of getting things wrong, we started developing our own internal tool for smart contract development. Every time we wrote a new smart contract, we automated some parts of what had been done in the previous one. First, it was about scripting simple scenarios: deploy your contract, memorize its address, make some calls to it. Next, we wanted to be able to generate a simple Dapp directly from the smart contract source code. For this, we used OCaml’s outstanding fitness for programming languages manipulation. Our code would automatically spit out OCaml and Javascript interfaces to our contracts. Now, every time there was a change to a contract, we could just re-generate our dapp and get nice, readable type errors wherever we had broken things.
But wait! If our contracts were now basically OCaml interfaces, we could do so much more than just script a smart-contract deployment and a few calls! We could write full-fledged scenarios, check invariants automatically, use property-based testing (speaking of which, check out this beautiful post from the Concordium Blockchain centre).
We built all these features into a tool we call Spice, whose release is imminent. Spice is the reason we’ve been able to port Tezos’ zk-snarks to Dune Network, right as development was being made public. Using Spice, we delivered the Dune Playground game platform. We’re also using it to develop Dune Oasis in record time, as well as another, major ongoing project!
Our dedicated team of nine have developed many other awesome tools for Tezos and/or Dune Network. The Dunscan block explorer pioneered UIs for Proof-of-stake. The Liquidity and Love smart contract languages, made by our PhDs in programming languages, are both readable and strongly-typed. The Metal browser extension is a simple and elegant way to interact with dapps in the browser. The IronMin storage library has brought massive performance improvements on vanilla Tezos storage. We have ported the Solidity programming language to OCaml and are currently testing it on the Dune Network. The list goes on!
We’re constantly innovating from the ground up, developing our own smart contracts and learning the pain points! At the same time, we’re reliably delivering tools and services for the public and our clients. In the next post, we’ll go into more detail about the inner workings of Spice. I will open-source it, and detail exciting prospects for the future with Solidity integration and more formal methods. Please get in touch if you’re interested in getting Spice for other smart contract languages/blockchains!
Join the #duniverse:
Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network
