How to program smart contracts with Ethereum and web assembly

Note: We have used commission links in this article and marked them with “*”. If an order is placed via these links, t3n.de receives a commission.

Ethereum is behind one of the most popular cryptocurrencies – and yet it is much more than that. This means that cryptographic money can be managed completely autonomously thanks to algorithms. But how do the so-called smart contracts work and where is the journey going?

In order to understand the principle of smart contracts in Ethereum, it is necessary to first undertake a brief excursion into the world of programming languages. The common programming languages ​​are basically divided into two groups: interpreted and compiled languages. In the first group, programs are written in a high-level language, which are then executed by an interpreter. Two popular examples of this are Python and JavaScript. Interpreted languages ​​are common in many application domains (such as the web) because you can get started right away. In addition, they are very universal and can be used on different platforms without the need for additional tooling.

On the other hand, there are compiled languages ​​in which a compiler first converts the program text into another language – often binary machine code. This binary code is platform-dependent and is executed directly on a processor. The compiler can (and must) output tailor-made code for the instruction set of the processor, for example for ARM or Intel compatible CPUs. Well-known representatives of this type are C and Rust.

However, the reality is, as always, more complex than these simple categories suggest. For a long time there have been mixed forms, such as Java. The Java compiler does not translate Java code directly into “real” machine code, but into a special intermediate format. This intermediate format in turn is then executed by an interpreter – the Java Virtual Machine – on the specific processor architecture.

The smart contracts in Ethereum work in a similar way. All nodes that validate transactions in Ethereum and mine new currencies contain an instance of the Ethereum Virtual Machine (EVM). In the Yellow Paper, the technical specification of Ethereum, it is precisely defined which instructions the EVM support – and how they are to be executed.

It is an in-house development that has numerous special features:

• Interaction with the outside world is not possible: All algorithmic decisions must result from the blockchain and its transactions.
• Arithmetic is based on 256-bit values ​​to make it easier to deal with addresses and large amounts of money.
• Special operations such as the hash functions are built in directly to increase performance.
• A cost function (fuel) is assigned to all instructions, which roughly corresponds to the required execution time and the amount of memory required. The term metering is common in English.
• Programming on the EVM

Similar to the Java ecosystem, there are several programming languages ​​for which EVM compilers are available. The most common language is Solidity, which superficially (syntactically) is reminiscent of JavaScript. As of the end of 2020, the Ethereum documentation lists two more languages: Vyper, which is based on Python, and Yul Plus, a completely independent development.

Also interesting: “Ethereum founder Vitalik Buterin: philosopher in a rainbow shirt”

What all these languages ​​have in common is that they are domain-specific because, in contrast to the general-purpose languages, they occupy a niche with special features and in particular a special runtime: the EVM. Of course, such domain-specific languages ​​(DSL) are generally a good idea to reduce the complexity of applications.

But in the case of the EVM, that doesn’t make much sense. After all, it can – regardless of the lack of interaction with the blockchain-external world – execute any algorithm, so it is (in simple terms) Turing-complete.

So why not use an existing language and runtime environment? If necessary, you would then have to remove features, but you could fall back on a longer experience, more stable tooling and – much more importantly – a broader base of programmers. Because it is old hat that nowadays the popularity of a programming language not only depends on whether you can program in it particularly concise, type-safe or dynamic, but also how easily you can access how many existing libraries and packages. This change of times is particularly illustrated by JavaScript, which is often criticized for its crude semantics, but has been the most popular programming language since the millionth NPM package at the latest.

You might be interested in that too