Compiling and Executing Smart Contracts (1)

I want to explore some options to compile and execute smart contracts in a blockchain. Some of these options already exist, but others are experimental or only base ideas. Although this initial post is centered around smart contracts in Ethereum, I plan to explore other implementations in upcoming posts.

If you are a newbie to smart contracts on Ethereum, read:

A 101 Noob Intro to Programming Smart Contracts on Ethereum
Making Sense of Blockchain Smart Contracts
Writing a contract

The usual path to program and execute smart contracts in that platform, is to write source code in Solidity programming language, compile it to bytecodes, and execute the resulting program using the Ethereum Virtual Machine:

But they are other options in programming language, compiling to Ethereum bytecodes, like Serpent, LLL:

But by far, Solidity is the most popular programming language in use. There is an emerging tool ecosystem around Solidity, and lots of examples.

Another option (to be explored, yet) is to compile a classic programming language to Ethereum bytecodes:

It is not an easy task: the programming language (Java, JavaScript, C#) has its own semantics, that it could be not easy to implement in pure Ethereum bytecodes. But one advantage of this approach, is that the developers can use all the tooling (IDEs, testing, … ) to write the smart contracts.

Executing the bytecodes in an Ethereum Virtual Machine implies to read bytecode by bytecode, and execute its semantic in a big code switch and loop. But it is not the only option. The bytecodes could be compiled to something more optimized:

As an implementation of this approach, there is the Ethereum Go approach: having a JIT optimizing compiler, read Optimising the Ethereum Virtual Machine. Excerpt:

The go-ethereum repository implements —among the Ethereum client and tool suite— the Ethereum Protocol in the Go language. It contains two implementation of the EVM, one extremely simple byte code interpreter that simple loops over the byte code and a JIT-like interpreter that compiles the byte code in to manageable data types and structures.

And there is another approach: to compile the bytecode semantic directly to programming language, then compile/interpret the resulting source code using the native compiler/interpreter:

The output source code would use the Ethereum VM data and structures, like the storage. One issue with this approach is that the bytecode could be a bit complicated, because it is oriented to the original programming language (ie Solidity) semantic, mapped by the compiler to the Ethereum VM bytecodes. As an example: a simple integer or string operation in Solidity could be mapped to too many bytecodes, because there is no simple operations in Ethereum VM specification to manage integers nor strings: the VM is oriented to manage integer numbers of 32 bytes (sometimes, 20 bytes as an address). Then, the bytecodes usually don’t reflect the original intention in a clear way.

A variant of the above approach: instead of generating source code in classic programming language, the output could be the bytecodes of the final executor, ie, Java bytecodes or CLR (.NET) bytecodes. But I think that this is only an optimized case, that could be implemented after the main case: the generation of source code could be a plus, to use it directly in programs, and in the final programming language tools, like an IDE.

Another idea: to compile existing source code in smart contract programming language, to classic language source code:

In this way, the original semantic of integers, strings, maps, could be implemented directly in Java or C#: at the end, only the storage status is important for a smart contract in Ethereum blockchain. If a Solidity contract could be compiled to programming language without altering the expected result, a programmer could use a lot of tools to run the generated contract.

I think that Solidity+Ethereum VM is the most popular implementation, and it is in the path to be the “de facto” approach, with more and more tooling and emerging ecosystem. But the other options deserve an exploratory implementation.

Upcoming post: out-of-Ethereum approachs, like Lisk running JavaScript smart contracts in NodeJS; more discussion of the options enumerated in this posts; more alternative implementations; specific discussion of Solidity to bytecodes compiling.

Stay tuned!

Angel “Java” Lopez

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s