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.
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.
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.
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.
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.
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.