Ethereum Smart Contracts for Beginners – part 2

Writing Smart Contracts in Remix

Posts in this series:

1. How Do Ethereum Smart Contracts Work?
2. Writing Smart Contracts in Remix
3. Setting Up Truffle to Deploy Smart Contracts
4. Truffle Console and Truffle Tests
5. Ethereum Apps with Web3.js

My first experience with Solidity was in Remix. At that time, I knew nothing about the language nor about programming smart contracts. I was asked to solve a coding task in Solidity to evaluate how well I could learn the basics of a new language and paradigm in a limited amount of time. The aim of this test was studying the language and coding an actual solution for a problem.

When you want to assess something specific, you probably want to cut out all the noise, and avoid distractions or difficulties resulting from things that are not relevant. That includes compiling the code and making it run which, as you know if you’re a developer, are the first task you have to solve in any new developent environment. That is why you do dozens, maybe hundreds, of “Hello World” implementations in your developer life: it shows you have covered the basic tasks of the system.

This task is very simplified with modern IDEs, where usually you just have to press some function key to compile the code and see some result. But it was not so in the early days, and that is pretty much where we are at this point in Ethereum’s life.

Getting a contract compiled, deployed and executed is less than trivial, and explain how to do that is the aim of this series. In the situation above, I was given Remix to write my code in, and avoid almost all those complications, so that the task could focus on my coding skills only. But that doesn’t mean Remix is obvious to new starters and there were still many things I did not understand at that time, and I wished I had had some introduction to it before starting.

This post covers that ground, and is basically a tour of Remix for newbies. It is the second in my series about Ethereum execution environments, and how to start writing and testing Ethereum smart contracts. Remix can be a very efficient and pleasant way to get introduced to smart contracts.

Remix

Remix is a website where you can type your Solidity code, compile it, deploy it and then query it. It even includes the facility to debug a transaction and see the EVM opcodes associated to the contract.

In my opinion, this is the easiest way to start, since you quickly get an integrated environment that lets you do most of the things you’d do in the whole development cycle.

I don’t normally use Remix for serious development. I need to manage my files in a project with other languages (a smart contract project rarely is only about the smart contract itself, and must have a front end developed in some other environment) and I find it easier to do with an offline setup. But truth be told, Remix has several interesting features to try to facilitate this, like generating a test file (although without any awareness of your contract), loading files from disk and even storing them on Github.

For my tastes, Remix is great as a starting point, to quickly test an algorithm or explore gas costs and the behaviour of the EVM, in effect, to conduct my own manual unit tests. It is also a quick way to get the bytecode if I need it and to explore abstruse errors like Stack Too Deep.

Even better, I find it has a decent debugger that is easy to operate (much better than Truffle’s, which I’ll explore later in this series). But the main reason I use it is because I don’t have to do any setup.

Remix’s Start Screen

At the start screen, you have a choice of languages to write your code in, including Solidity and Vyper environments, and a set of actions in a toolbar on the left. I only use Solidity, so I’ll restrain myself to that option here. Once I create a New File, I get a working screen divided in three main areas:

•  the code panel
• the execution results below the code
• the control panel

Let’s explore the options in the control panel.

Solidity Compiler

This is the first step in development: compile your smart contract. There are two options at the top I want to highlight. First is Compiler, which lets you choose the version of the Solidity compiler you are going to use. The different versions differ in several aspects of the language, and in particular from version to 0.4 to 0.5 the changes were very pronounced. You should pick the one that matches the features of the code you want to use, but nowadays I always stay with the latest one. Remember this version has to match what you declare in the pragma of your Solidity file.

This has to go hand in hand with the capabilities of the EVM you want to use, as defined by the EVM Version. Here you can find names like constantinople, byzantium, homestead, etc. with correspond to major upgrades of Ethereum’s capabilities, hard forks of the blockchain. I find the compiler default option is the best unless you have a specific feature you need in one of the forks.

This panel is all about whether the code compiles, and so you’ll see errors and warnings listed in this area in big bold balloons, and line markers, which help you fix the errors quickly. Once that is done, hit the big Compile button (unless you have the Auto compile option selected to use it in the next steps.

Deploy & Run Transactions

Once the contract is compiled, it must be deployed on the blockchain. The first thing to note here is the list Environment, which gives you a choice of networks (refer to my earlier post for more about this).

• Remix can simulate the EVM in memory, as if it contained a blockchain in itself. This is the JavaScript VM.
• You can connect to a live network by using the Injected Web3 option. This looks for a browser extension (typically Metamask) that can serve as an Ethereum node or connect you to one. 
• You can connect to any network accessible to your machine through the option Web3 Provider, by specifying the address/port of an Ethereum node. This could be a remote node or one running locally on your machine (eg. Geth, Parity, Ganache), and can include a live network or even a simulated one (if you’re using Ganache).

Since I am doing tests, I always choose the in-memory version: JavaScript VM. You also have the option of selecting the maximum gas you want to spend and its price, but I keep the default values, which work well for tests.

Running Transactions

A box shows the contract that is selected (corresponding to the code tab that is showing) and below this you can deploy your contract by hitting the button Deploy. You may have an instance of that contract already deployed, in which case you can select to use it by giving it the proper address.

Once you have an instance, you’ll see it in a list of deployed contracts below. Expand any of these and you’ll see a list of all the methods you can invoke on this contract. Pure and View appear in blue and immediately return a result. Methods that result in transactions are in orange, and produce an entry in the log area of the screen, with the details of the transaction. This also includes a button to debug it.

Debugger

The last tab I want to talk about hosts the debugger. The remaining tabs give you some advanced options, like selecting the type of warnings you want to receive, generating test files, or managing plugins and the very options available in the toolbar. Remix even lets you activate ZoKrates for producing zk-SNARKs. I’ll let you explore those on your own.

There are two ways to start the debugger: one is from the Debugger tab, the other is from the output area, after a transaction has been submitted. They are functionally equivalent, and this is because in Ethereum, unlike other languages, you can’t debug the code live.

What you can do is to debug a transaction that has already run to its conclusion, essentially replaying it step by step. Surprisingly, even function calls can be debugged, because a transaction is generated for them, because Remix still creates a transaction in these cases, although it does not need to.

Debugging in Remix

As you start a debugging session, the control panel is filled up with several new areas, including:

• the list of opcodes of the contract;
• some statistics of the current execution step;
• a panel of execution control buttons;
•  and several panels with the contents of all local variables, contract state (storage) variables, stack and memory

Remix does not let you debug the actual Solidity code. Instead, you can only proceed step by step on the EVM bytecodes, and there is a big gap between these and the high level representation of Solidity.

You can easily jump from one opcode to the next using the buttons in the execution control panel. You need quite some experience to associate the Solidity and the bytecode,  and it takes a some good time before you can fully understand what is going on. That is why I recommend, at first, that you investigate the effects of each opcode in a good site  while watching the contents of the memory, stack and variables change. This way, you will be able to understand what the code is doing and, if needed, understand what is causing any errors.

---

Remix is a good way to take the first steps in Smart Contract writing. It is not perfect, and can even be a bit scary when you look at it for the first time. Still, it is an accessible way to start and removes lots of the complications of doing it all from scratch.

In the next steps of this quest, I’ll take you to the lands of Truffle, and explore how you can write automated tests and command-line apps that interact with the Ethereum blockchain. I hope you can join for the journey.
Farewell.