Ethereum Development Walkthrough (Part 1: Smart contracts)

Smart contracts, ICOs, Mist, Metamask, Remix, geth, web3.. You’ve probably seen it all if you spent a little time trying to get into the world of Ethereum developement.

Some deploy smart contracts to a test network, others tell you to read a yellow paper, while others advise you to use the truffle suite because it’s great. And you are there, not knowing what exactly to do and how everything works together.

If this is the first article that you read on Ethereum or the blockchain eco-system in general, you are going to love it! Experts calling each others names on twitter, unsafe standards and protocols, untested and buggy development tools. Not everything is figured out yet, everyone is going in different directions, and there still a lot to be done. The future of institutions, banks, and governments is being decided by mad developers! It’s so great.

Anyway, don’t worry anymore, I’ll try to connect all the dots for you in this tutorial series, and walk you through the universe of Smart contracts and dapps developement, and show you how everything fits together.

While I will not get into every detail, I’ll link some materials that will help you understand some concepts better, and it’s up to you to research them and get into all the little details. The goal of this series is to help you understand better how things work together, in the simplest way possible, like a friend would explain it to you.

I don’t even know what Ethereum is

The official website of Ethereum tells us this:

Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference.

In other words, it uses the capabilities that gives us the blockchain technology to certify the execution of the code that we run.

If you don’t know what the blockchain, Ethereum, Bitcoin, cryptocurrency or any of these words mean, I advise you to listen to this excellent podcast by Tim Ferriss, interviewing Nick Szabo and Naval Ravikant: The Quiet Master of Cryptocurrency — Nick Szabo

What are Smart Contracts?

On Ethereum, Smart Contracts are scripts that can handle money. It’s as simple as that.

These contracts are enforced and certified by parties that we call miners. Miners are multiple computers who add a transaction (Execution of a smart contract, payment of a cryptocurrency etc.) to a public ledger that we call a block. Multiple blocks constitute a blockchain.

We pay these miners with something called Gas, which is the cost to run a contract. When you publish a smart contract, or execute a function of a smart contract, or transfer money to another account, you pay some ether that gets converted into gas.

If it’s still unclear, or you want to know more details, here are some interesting links:

• A different introduction to Smart Contracts in video.
• Smart contracts page on Wikipedia.
• A more detailed explanation of Gas.

Before diving into smart contracts development

In this tutorial, I’ll assume that you already have some basis in software development, and have a basic knowledge of Javascript and Node.JS. Otherwise, you’ll be quickly lost. Solidity, the programming langage that we will use to develop, is close to Javascript’s syntax, and since a lot of development tools around Ethereum are based on Javascript and NodeJS, it will be easier for you to get in if you are already comfortable with both. This is not a tutorial for beginners, and while I’ll link some alternative tutorials for you if you didn’t understand some concepts, it’s up to you to research the rest.

Smart contracts development

Now, finally, we start the interesting part, as I said Solidity is close to Javascript, but they are not alike. On Solidity, and I’m sorry to tell you that, frontend developer, you just can’t slap JQuery on a piece of code and hope that it will work, you can’t overlook security, and you just can’t hack your way through. We will see why when we will discuss security, development patterns, and fail-proofing our code.

Now, for our first example, I’m thinking about a script inspired by the movie In Time, where, in a dystopian future, people trade their remaining time to live like money. In the movie, they have a variant of arm wrestling that involves playing with that time, and we will do just that! Wrestling money using a Smart Contract.

And don’t worry, I’ll make available for you all the scripts we will see on Github.

Also, if it’s the first time you deal with smart contracts, it’s fine if you don’t understand everything now, it takes practice, reading the docs, and a bit of research to get accustomed to Solidity.

The code

Now, onto the coding, first of all, the base of a Solidity script is the following snippet, the pragma directive to tell the compiler which version of Solidity we are using, and the name of our contract, a similar structure to a class in Javascript. Here it’s “Wrestling”.

We want two wrestlers, so we will add two variables that hold the address of their accounts (Public keys of their wallets).

In our little game, in each round, the wrestlers will be able to put in a sum of money, and if one put in double the money of the other(in total), he will win.

One important thing about the public/private keywords is, even though, a variable is private, it doesn’t mean that someone couldn’t read its content, it just means that it can be accessed only inside the contract, but in reality, since the whole blockchain is stored on a lot of computers, the information that is stored inside the variable could always be seen by others, and that represents the first security consideration that you should keep in mind.

On the other hand, the compiler automatically creates getter functions for public variables. To make it possible for other contracts or users to change the value of the public variable, you need to create a setter function.

Now we will add three events, for every step of our game. The beginning, when the wrestlers register, during the game, for each round, and at the end, when a wrestler wins. Events are simply logs, and they can be used to call JavaScript callbacks in the user interface of distributed applications, also known as dapps. Events can even be used for debugging purposes during development since there is no equivalent to the “console.log()” function of JavaScript on Solidity.

Now we will add the constructor, in Solidity, it has the same name as our contract and it will be called only once, upon the creation of the contract.

Here, the first wrestler will be the one who created the contract. “msg.sender” is the address of the one who invoked the function.

Next we let another wrestler register with the following function:

The require function is a special error-handling function within Solidity that will revert changes if a condition is not met. In our example, if the variable wrestler2 equals the 0x0 address (the equivalent of 0 for addresses), we can proceed, if the address wrestler2 is different from the 0x0 address, it means that a player has already registered as an opponent, and therefore, we will refuse new registrations.

Again, “msg.sender” is the address of the account that called the function, and we emit an event that signals the start of the wrestling.

Now, every wrestler will call a function, “wrestle()”, putting in money. And if both have played, we see if one of them has won (our rule was that one of them have to put in double the cash of the other one). The “payable” keyword means that the function can receive money, if it isn’t set, the function will not accept ether. The “msg.value” is the amount of ether that was sent to the contract.

We then add the endOfGame(), and endOfRound() functions. The “internal” keyword is the same as private, the only difference is that internal functions could be inherited by other contracts(since Solidity is similar to other object-oriented languages), while private functions cannot be inherited.

Notice that we don’t deliver the money to the winner directly, while in this case it’s not that important, since the winner will take all the money off this contract, in other cases, when multiple users can withdraw ether off a contract, it’s more secure to use a withdraw pattern, to avoid re-entrancy.

It simply means, that if for example multiple users can withdraw money off a contract, one can simply call the withdraw function multiple times at once and get payed multiple times. So we need to write our withdraw function in such a manner that it will nullify the amount he should receive before proceeding to pay him.

It looks like this:

And that’s it. You can find the whole snippet at the following link:

devzl/ethereum-walkthrough-1

Using an IDE

Copy the snippet now, and open the Remix IDE in a new tab of your browser:

You can use Remix directly on your browser, and it has a lot interesting functionalities that you could hardly find elsewhere at the moment.

Click on the button “+” on the top left of the page and create a new file named “Wrestling.sol”, then past the code that you can find in the github repo linked above:

Finally some syntax highlighting. Github doesn’t support Solidity .sol extension yet.

On the right part of the page, you can find multiple interesting tabs such as the “Analysis” one, that will show errors and recommendations. I leave you to discover this tool more. I wanted to show it to you, even though we will use other tools in the next part, the goal of this tutorial series, as I said before, is to connect the dots for you, and show you how things fit together, and it’s up to you to decide whether or not you are at ease using an IDE on a browser. Invite you to read the docs of Remix if you do.

Alternatively, you should start getting familiar with solidity by reading its docs.

In the next part, we will see how to deploy the Smart Contract to two kinds of test networks, discover truffle, ganache, and geth, and how they can all fit together.

If you liked this first part, you can find me on twitter @dev_zl.

Part two can be found here.

Ethereum Development Walkthrough (Part 1: Smart contracts) was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.