Could WREN be the future of Smart Contract Scripting Languages?

in #smartcontracts4 years ago


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.

Sort:  

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.

class Unicorn { 
  isFancy { true } // Unicorns are always fancy.
}

Also I agree with his beliefs :)

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.

Monadic second-order logic (MSOL) is a restriction of second-order logic in which only quantification over unary relations (i.e.: sets) are allowed. Quantification over functions, owing to the equivalence to relations as described above, is thus also not allowed. The second-order logic without these restrictions is sometimes called full second-order logic to distinguish it from the monadic version. Monadic second-order logic is particularly used in the context of Courcelle's theorem, an algorithmic meta-theorem in graph theory.

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

This is rather exciting data to come across, thank you for the sharing and namaste :)

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.

But is it secure? I favor OCaml or something similar. I think new languages often have bugs, and WREN is new. It may be high performance but if it's not secure then it will not be able to carry billions of dollars without the risk of bugs or obfuscated code.

I will look into WREN more but the virtual machine method of security is security by isolation, and we already see that approach failed with Solidity. As far as LISK goes, that's a joke in terms of security and no one should think it can do something serious.

i'll take a look on Wren
thanks @dantheman

So this is all super helpful and as a ether holder, a blessing. Thanks for the insight. :D

WREN is more than 2x as fast as python... the potential looks awesome!

And why did not like luajit?

Because the code is far more complex and syntax not familiar to most coders. Also no sand box.

Not sure what you mean that its far more complex? Really the main difference is that you replace curlies {} with then do and end. It's a minor syntax difference, but really any experienced programmer should have no trouble adapting to it.

Also not sure what you mean by no sandbox? Do you mean the scripting environment? You can control that with setfenv and getfenv and if you're using lua 5.2+ just use _ENV.

Inspiring work!

Oh DAN! It's AWESOME!!

Интересно молодец давай еще!

Hello, hope and they are well. I have prepared a project that I hope you like it. and help me with an upvote. Happy day!

maybe WREN be the future of Smart Contract Scripting Languages ...... maybe ...

I'm no coder, but from what you say its seems to be more efficient and that is what always prevails. Keep up the good work :)

Will somebody alert me when this becomes an ICO? In the meantime, I will keep my eye on this.

I took this quote from the official Lisk blog. Can you comment?

Lisk is written in JavaScript, which is not secure!

No! Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place. There are other programming languages we could have used, which owing to their strongly typed nature, make it less probable for the developer to write bad code. However, that doesn’t mean these languages do not come with other important trade offs. We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its speed and security across a wide range of devices. Therefore, its ever increasing developer base and ease of access played a huge role in that decision.
With regard to JavaScript’s known limitation on number precision larger than 32 bits. We have worked around this limitation by conducting integer based arithmetic throughout the code base using BigNumber.js (a library for arbitrary-precision decimal and non-decimal arithmetic). Blockchain application developers are largely shielded by our API, or in cases which require it, they can utilize the same library used by the Lisk core. Therefore, this limitation is not a problem, nor has it been since Lisk’s inception.
To further strengthen the code base, we are planning an eventual transition to TypeScript — a strongly typed JavaScript super-set — which once implemented should mitigate the issues normally associated with weakly typed code. We are also contemplating pushing back certain critical core features to C++ for maximum speed and security. In summary, we are leveraging all options available to solve some of the known problems associated with using JavaScript on such a project as Lisk.

And their assumption is wrong. The compiler should be where the responsibility is to prevent insecure code from even being able to compile. Depending on thousands of individual developers means having to trust each and every developer and why would you want to do that? It increases your risk for zero gain. On the other hand if you use a secure language then you only have to trust the developers who write the compiler and design the secure language.

The fewer developers you have to trust the lower your risk.

Hey brotha just wanted to let you know under your paragraph "Deterministic Execution" you have some when I think you mean same. @dantheman

It's probably a bad idea to use a general-purpose programming language for smart contracts.

Interesting. The speed charts are impressive.

About Lisk. Can you comment on this article? TNX

“Yes, we believe Lisk can host a project of this size, if not greater. The reason for this are twofold, our choice of database system: PostgreSQL, which has many avenues for scalability, and secondly the fact that each sidechain operates autonomously from the mainchain with the minimum of parental dependency."

I had to laugh at that quote. No SQL database can complete with graphene for single threaded business logic required by block chains. Not even close. Like 100x difference.

:) I was thinking of making a post referring to this article but ... then I had a feeling that people would laugh at me. My instinct was right on this one :)

Thanks for your reply, by the way. You are doing a great job here.

Looks cool. I had a professor who helped design floating point. It's pretty amazing as it uses electronics to do very complicated approximating stuff quickly, but I understand keeping things all in integers. I'm that way too.

Huge tangent here, but how did you get into coding your own compilers and languages? Computer science was my second major in undergrad, but I mostly gave it up since college (occassionally write something in python, but always simple projects). I assume many coders/devs are reading this, any tips on jumping back in with dormant skills?

I wrote 5 compilers in college in 4 different languages / language paradigms. Then after college I wrote an interpreter that would call c++ code. The interpreted language had C++ like syntax with exceptions, etc. Performance was terrible, but it worked.

That was all 14 years ago, so I am a tad rusty.

Last time I wrote a compiler was about 20 years ago. Most of my stuff was really simple though. I wrote a lot more interpreters than I did compilers.

What about rust which I believe ethcore was re written in?

thanks for sharing this information, I like what you posted. if you want you can visit my blogg you. Thank you

Thanks for another excellent well written piece. I would first like to say that you succeeded in making a subject that is complex and opaque for non-programmers accessible and understandable.

In my opinion, if we were to put a monetary value based on the whole lot of submissions in the last seven days, I would put the value of your post at over $20K. So, I think that those jealous, envious, and malicious comments I see here and too many other places on Steemit are an unfortunate price one has to pay for being on the platform.

It is certainly encouraging for me to read your post because it demonstrates that there are very mature serious thinkers leading the charge here at Steemit with considerable understanding and experience in dealing with the technical issues at hand in gaining critical mass for the platform while protecting it from abuse and fraudulent activities.

I think that Steemit is a fabulous value proposition and it is only natural that the trending posts tend to be dominated by a fairly narrow range of subjects and niches.

I believe that, with further releases that lessen the learning curve for non-technical content creators, the range of interests of participants on the platform will widen dramatically thereby allowing content creators who have no visibility today to finally have a reasonable audience and increase their chances of generating an income from their efforts.

The Steemit platform is poised to open a tsunami of opportunities for creative developers, artists, and scientists that do not exist anywhere else today nor appear on the horizon.

Needless to say, I am very excited at the possibilities.
Thank you @dantheman

Coin Marketplace

STEEM 0.22
TRX 0.02
BTC 11657.18
ETH 390.14
SBD 1.04