Could WREN be the future of Smart Contract Scripting Languages?
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.
I am an indie game developer as my side job. Also have done a few pro things with Bioware (small gigs). I may want to check out WREN for some other projects. Speed in game dev as you indicated is critical. I am constantly trying to optimize.
I have a game greenlit on Steam that I need to finish, but I became distracted by this thing called steemit a week or two after it was greenlit. I am starting to find balance and will dive back into it.
At some point I am thinking of tying steem into my game as something optional and I may get to a point where I will want to pick your brain or some other steem dev you could steer me to.
I outlined the basic concept of how someone might use steem within a game platfrom (and perhaps others) here.
My thought was fuel the game dev via steem power, yet allow the game to pull steem dollars from the games steem account and distribute steem dollars to people who complete games. It hopefully could be done but I'm not sure how the transaction would work for sure. The game would be able to issue steem dollar withdrawal requests from a fixed account and give it to players who provided one of their public keys on their game profile.
My initial experiment would be simple. If you complete a single player level, get a % of whatever steem dollars are in the pool, complete a multiplayer game level, all players get some %.
Post useful content about the game and people playing it, let people perhaps vote on it, and that'd be how the steem dollars were replenished.
You can't unsee this: Nude statues of Trump pop up in US cities
Brought to you by the Illuminati's 'The All seeing eye'
https://steemit.com/news/@cryptocurrency1/you-can-t-unsee-this-nude-statues-of-trump-pop-up-in-us-cities
Flagged for outsize reward on a platform update. This is only a tiny component of what might be needed to create a working, usable, programmable smart contract platform. $3500 in post value for a progress report on this small piece is absurd.
Also, @dantheman, one comment on the content. While the performance of Wren as a in interpreted/byte code language indeed appears impressive, and going that route means something usable much sooner at lower costs, it is still going to fall far short of native code. If "Speed is Critical" that might not be the best approach. Obviously there are always engineering trade-offs to be made.
As someone who has lived in the scripting world (as opposed to the compiled world), I would be more than happy to build smart contracts using a language like this.
The syntax itself looks a lot like python, with sprinkles of javascript and ruby.
Also I agree with his beliefs :)
Einstein would be jealous of you @dan
Still not decidable though, so you need a way to interrupt the execution as you can't tell in advance that the script it going to terminate. The only language that would be suitable for smart contracts that's also decidable is Tau, but it's still very much a work in progress AFAICT.
Reg. the side chain integration, would that be integrated as a side chain of Steem or Bitshares? Actually why not make Bitshares a sidechain of Steem? That would allow to extend Steem with a decentralized exchange, and plenty of fiat on-ramps, and it would bring a lot of volume to Bitshares. Win-Win.
"Actually why not make Bitshares a sidechain of Steem? That would allow to extend Steem with a decentralized exchange, and plenty of fiat on-ramps, and it would bring a lot of volume to Bitshares. Win-Win." +5%
Tau isn't yet complete. OCaml is a good language and there are others but the issue is, no one has built anything similar to an OCaml smart contract language. Tau is actually going through a redesign phase right now but the lead developer has chosen to go with MSO (monadic second order logic) over graphs.
I do agree if Tau exists then use it, because coming up with a new language for smart contracts is hard, and to trust any compiler which isn't designed correct by construction is also a mistake.
References
https://en.wikipedia.org/wiki/Second-order_logic
It is true it isn't decidable which means it would have to operate on a calculation limit. With the calculation limit which I already implemented it is impossible to write an infinite loop.
** it can call native code, there is no protection when native code is called and it will count as a single op unless the native code provides a means to provide an alternative weight for the call. **
A decidable language is the ideal. The question is what language to go with until we have a decidable language? If you implement WREN, please only do so on a temporary basis so that when a better language comes along it can be swapped out. It might work for Steem, for now, but if Tau releases with MSO over graphs then you have a better language. The thing is, we don't know if Tau will be a success, but I do like the approach and decisions taken by Ohad so far.
It's all greek to me ;-)
Glad you're at the helm, @dan!
WOW, bombs dropping :)
steem dollar and steem power are smart contracts, that WORK
What she said!
This is rather exciting data to come across, thank you for the sharing and namaste :)
nice
When you compare Wren to the Ethereum VM, are you referring to Solidity? The ETH community raves about the performance but it didn't help them design safe Smart Contracts.
No. The VM and the language. Eth would be much slower than Python.
I also thought that Lisk is amazing but, now, that you said this it makes me think otherwise. Thanks for sharing this information with us.