Several months ago I discovered a nifty little scripting language called WREN in my pursuit of high-performance deterministic scripting engines that could be leveraged for smart contracts.
Wren is a small, fast, class-based scripting language
Here are some of the highlights from their github repo.
- Wren is small. The VM implementation is under 4,000 semicolons. You can skim the whole thing in an afternoon. It's small, but not dense.
- Wren is fast. A fast single-pass compiler to tight bytecode, and a compact object representation help Wren compete with other dynamic languages.
- Wren is class-based. There are lots of scripting languages out there, but many have unusual or non-existent object models. Wren places classes front and center.
- Wren is a scripting language. Wren is intended for embedding in applications. It has no dependencies, a small standard library, and an easy-to-use C API. It compiles cleanly as C99, C++98 or anything later.
Requirements for Smart Contract Scripting Language
A blockchain based smart contract scripting language has some very tough requirements:
Speed is Critical
I have stated many times that the bottleneck for blockchain performance is the single threaded business logic of applications. Every blockchain transaction has the power to change the environment for the next transaction which makes out-of-order or parallel execution difficult.
Deterministic Execution
The point of smart contracts is to come to an unambiguous consensus on the current state of the application. This requires all machines to arrive at the exact some conclusion. Any deviations could result in an unexpected and undesirable blockchain fork.
Sandboxing
Creating a blockchain that is ready and able to run arbitrary code requires that the code is heavily sandboxed. This means that it cannot enter infinite loops nor allocate an unbounded amount of memory. Not only must execution time be monitored, but it must be deterministically calculated as part of global consensus. In other words, it must count operations, not wall clock time and it must exit with an error at the exact same point on all machines.
Why WREN is Perfect for a Smart Contract Platform
Most of Wren’s performance comes from language design decisions. While it’s dynamically typed and dispatched, classes are relatively statically defined. That makes a lot of things much easier. Wren’s closest sibling, by far, is Lua. Lua is more dynamic than Wren which makes its job harder.
You can see some benchmarks of how fast WREN is compared to many other popular languages in this table.
It gets this performance by combining the best aspects of scripting and statically typed languages. This allows it to generate very efficient code.
Most of Wren’s performance comes from language design decisions. While it’s dynamically typed and dispatched, classes are relatively statically defined. That makes a lot of things much easier. Other languages have a much more mutable object model, and cannot change that without breaking lots of existing code.
I recently forked wren to add Sandbox support and submitted a pull request. This was relatively trivial to implement because the code base was very clean and easy to understand.
Comparison to Ethereum and Lisk
In my opinion there is no comparison. The performance of the Ethereum virtual machine is burdened by poor design decisions. Many of Ethereum's poor decisions are a result of being built and designed by programmers with less language experience and more blockchain experience. In other words, the EVM is designed by blockchain engineers thinking about blockchain problems and as a side effect they built a system that no language engineer would virtual machine designer would ever consider viable.
I have built my own languages and compilers and can testify that designing high performance languages is a skill that most programmers do not have.
Wren has been designed by Bob Nystrom author of the book Game Programming Patterns. Game programming is very demanding and requires high performance scripting that is easily embedded within native C/C++ applications.
From what I can tell about Lisk and it's reliance on Javascript, it is not suitable for running untrusted code on a public blockchain in the same way Ethereum is. Lisk is targeting a different market. When I first heard of lisk I was excited because I thought they found a deterministic Javascript interpreter with sandboxing and computation metering; I was wrong.
Future Work
Wren isn't perfect. The language is still in its infancy, but if adopted by a blockchain community it could mature very quickly. There is only one aspect of Wren that I would like to change and that is to convert it to use Integer math. Blockchain's do not require floating point operations. Making this change should be relatively simple.
Once the Wren VM and compiler is mature, then it is simply a matter of integrating the VM with some C++ APIs for reading and writing blockchain state and generating blockchain operations. This kind of feature is probably best to keep in a sidechain / subchain until all the kinks are worked out.