Why I like Wren for Smart Contracts

After my recent post about Smart Contracts several people made comments about my choice of language. Wren is an incredibly immature toy-language that is hardly battle tested and little known. Just this week I had to submit a pull request to fix a critical bug that prevented it from being usable.

In theory any language could be used because of the ground breaking advancement of eliminating the need to deterministically calculate “gas”. There are JavaScript interpreters, Lua, and Python options.

Sandboxing is Hard

When picking a language to use the number one consideration is ease of sandboxing. This means that the compiled code can be kept within certain CPU and memory constraints. The next constraint is ease of interfacing with C++ / ChainBase code.

Prior to finding Wren is discovered a fast embedded JavaScript engine, Duktape, that I thought was promising. I spent significant time attempting to implement proper sandboxing within Duktape with little success.

JavaScript is a great language, but it is not designed for speed even though modern JavaScript engines are amazing! To get amazing speed from JavaScript requires incredibly complex Just-in-Time compilation.

The truth is that most languages do not support sandboxing very well at all. Their implementations are very complex and they attempt to do far more than is necessary. For years I have looked for a good way to sandbox JavaScript. Typical approaches to sandboxing involve spawning threads at a minimum and subprocesses for very robust solutions. These sandboxes are expensive to set up and tear down and make communication with blockchain state expensive.

A blockchain environment is challenging because the amount of code that executes in the sandbox is very small! A typical contract will run in a fraction of a millisecond, but most traditional sandboxing approaches with existing libraries have significant setup / teardown costs.

Wren, even in its current immature state, has proven to be incredibly fast and efficient without having to resort to Just in Time compilation. I am certain that the Wren language could be made orders of magnitude faster with a native compiler. It would be faster than Lua or JavaScript JIT because of the language design.

A Language I can Customize

Wren isn’t a final language, it is a starting point. It is a small well organized code base that can be readily adapted to suite the needs of a blockchain. In fact, I would probably strip out many Wren features (such as Fibers) in order to make it even simpler.

Attempting to modify the high-performance Lua, JavaScript, and Python libraries would be far more challenging and error prone.

A C++-like Language

I would go so far as to say that the ultimate language would be a simple subset of C/C++. A C/C++ scripting language could be easily converted to native code while having the benefits of an easily sandboxed interpreter. Untrusted scripts would be run by the interpreter, but developers could easily convert any popular script with a trusted native alternative.

Addressing @anonymint’s concerns

When Steem was under DOS attack the hacker was broadcasting as many transactions as he could. All of the transactions were valid and included in the blockchain. The DOS was defended by the blockchain protocol, not the network protocol.

@anonymint seems to think I have misunderstood something about how GAS works in ethereum. Here is what I “know” from a first principles perspective. If people only pay for what they use and are refunded what they don’t use then all nodes need to agree on the refund.

If the author of the transaction specified the “exact” amount of GAS required then the validator could simply use that number, but we know that it is impossible for the transaction creator to know in advance how much GAS their transaction will consume. (Other users could change the state between transaction signing and applying the transaction in the block).

Regarding The Proof of Work on Transactions

I would estimate the time complexity to require the sender to spend 10x the CPU time doing POW as the validator does executing the script on the same hardware. The typical script should take no more than 1ms to run, so the typical POW should take no more than 10ms on a standard desktop computer and it wouldn’t increase in difficulty over time.

While an ASIC or GPU would enable the attacker to generate more transactions, it would be pointless. The goal of the POW is to make the attacker spend more time and money than the server. An ASIC or GPU may be able to do those calculations faster than the server can execute the script, but the attacker was still forced to use significantly more resources for the same attack.

It could be argued that POW on transactions is not necessary at all because the protocol already rate limits attackers on CPU time, bandwidth, and storage. The purpose of proof-of-work is to protect an individual node from a malicious peer. Each node can easily identify connections (and blockchain accounts) that are producing more transactions than can be included.

In fact, 99% of the time the bandwidth rate limiting will cause a transaction to fail before the CPU intensive script gets called. Proof-of-work ends up being an objective means of “requesting” wall-clock time for your script and determining the resultant pay for the block producer who includes your script.

Conclusion

The approach I propose for Smart Contracts can eventually support many different languages in parallel. The choice of language has more to do with getting a minimal viable product to market in a timely manner than anything else. Other languages will come in time if the platform proves successful.

I firmly believe that developers can easily adapt to any C/C++ like language and that smart contracts should be relatively simple pieces of code that shouldn’t be reusing large libraries of existing code even if those libraries existed. If you are not using existing libraries of code, then language of choice matters little so long as it is similar enough to other languages.