Introducing Spedn — a smart contract language for Bitcoin Cash
When new opcodes were added (or rather re-enabled) in May 2018 hardfork of Bitcoin Cash there was quite an expectation of a smart contract boom. What can we see today, nearly half year later? There were some cool new ideas mostly revolving around token protocols utilizing OP_RETURN to store metadata attached to coins. There’s also ChainBet protocol utilizing OP_MOD to provide cryptographically proven random bets, and recently Forfeits were proposed that use OP_CHECKDATASIG (that is expected to activate in November hardfork) to prove doublespend attempt.
I re-read the paragraph above and found it too technical.
This is a glimpse of what I struggled every time I tried to read some spec or article that proposes a new, clever Bitcoin Cash smart contract. This is because of Script. This famous, intentionally not Turing-complete, FORTH-like language feels for me almost like one of those esoteric languages made with the sole purpose of making your brain hurt. This is mainly because it belongs to a quite obscure family of stack-oriented languages. That means no ordinary variables that programmers are used to. Instead you have to keep the entire execution stack in your head to understand what’s going on. And it’s Reverse Polish Notation. Oh, I know it! I remember doing that exercise on a blackboard during a CS 101 lecture 10 years ago.
Maybe I’m too sarcastic. Script is both brilliant and just hard to use. And I think I’m not the only one that is repelled from it because of that.
After reading yet another article with a Script example I didn’t understand, the realization was made. Script is basically a low-level assembly language for Bitcoin Cash virtual machine bytecode and we need some high-level language that can be compiled to it.
Somebody?
…
So I started working. My platonic love for Haskell finally can be consummated by making an actual, useful project.
Today, I’m pleased to announce Spedn. A high-level smart contract language for Bitcoin Cash.
It is designed for explicitness and safety:
- It is statically typed — detects many errors at compile time
- It is explicitly typed — no guessing what the expression is supposed to return
- It is purely-functional — free of side effects, the common source of bugs
- It has a familiar C-like syntax
How does it look like? Here’s an example based on one of the contracts defined in ChainBet protocol:
Spend is in very early, experimental phase of development. Many breaking changes may come and it’s far from being an “out of the box” solution for smart contracts developers. I therefor invite you to comment, review, suggest, complain and contribute.
Where to start? Here.
