Solidity Fast Track: Learn Solidity Fast

'Learn X in Y minutes' this time with X = Solidity 0.7 and Y = 20

You might be familiar with the Learn X in Y minutes. For example you could learn JavaScript in 20 minutes at https://learnxinyminutes.com/docs/javascript/. Unfortunately there is no equivalent for Solidity, but this is about to change.

Do you have 20 minutes to learn all of the basics? We even include the required blockchain basics.

So we have no time to loose. Let's start.

What is Bitcoin? (Blockchain 101)

Bitcoin fundamentally is a digital currency, but there is one major issue with any digital currency. It can be copied an infinite amount of times by anyone. This is what Bitcoin solves.

Technically a 'Bitcoin' doesn't actually exist. It's not an actual coin someone owns on their hard drive. Rather it's a long list of transactions. The first transaction for a created Bitcoin comes from mining, the details here are not important now, just know that a miner is rewarded for doing hard work.

So to obtain Bitcoin, someone has to send it to me. This someone creates a transaction saying 'Send 1 BTC to Markus'. He publishes this transaction. Nodes in the Bitcoin network will eventually see it. They collect transactions and store them together in a block. Those blocks will be put together sequentially into a chain, also known as 'blockchain'. To prevent spamming the network, any transaction must also pay a fee.

In other words, a blockchain is just a list of strictly ordered transactions. To obtain the balance of an address, all we need to do is go through this long list until the end and keep track of all the incoming Bitcoins and all the outgoing Bitcoins. The current balance of an address equals the sum of all incoming minus the sum of all outgoing Bitcoins. Pretty simple right?

What's different in Ethereum? (Blockchain 102)

Now that we know how Bitcoin works, let's explore what's new in Ethereum. And that's the capability to create smart contracts. I like to think of smart contracts as essentially automated, verifiable addresses. In Bitcoin, every address is just a human sending Bitcoin from A to B, or a software acting on behalf of a human. Let's compare the difference between those two automations:

Let's imagine I run a computer software that automatically trades Bitcoin. You could think of it as an automated account. It listens to external output (who is sending me how much money, what is the current Bitcoin price etc.) and reacts by sending Bitcoins. Who knows and can change the behavior of this software? Only me, it's running only on my personal computer.
Now compare that to an Ethereum smart contract. Just like before it listens to external output and reacts by sending Ether (or other things). Who knows what the software is doing? Everyone. Who can change the behavior? Nobody (unless its designed to be changed). The software is running on every Ethereum node, and in many cases, for all eternity.

So that's a smart contract in a nutshell. An automated account that is immutable and verifiable, because it runs on every machine of the network.

Let's get to Solidity!

Now it's time to talk about Solidity. Those automated accounts (as mentioned about, let's just call them smart contracts from now on) can be programmed. If you're a super nerd, you can just write direct machine code operations for it, also known as OPCODES. But if you are a normal person, you will want to use a higher level abstraction.

Solidity is here to help you. Just like many other languages, given the Solidity source code a compiler is generating the machine code for the Ethereum Virtual Machine (EVM).

Smart Contracts 101

What exactly defines a smart contract?

You can send a transaction to this address, just like you can to a normal address. One difference here is that you can send data along in your transaction which will define

what function code on the contract to execute
what are the input parameters to the function

Another difference is the concept of gas costs. They are essentially just the transaction fees, but in a normal transaction that just sends money from A to B, we know exactly how many resources are required by Ethereum nodes to process and verify the transaction (not a lot). But in a smart contract, you could do very heavy computations and store large amount of data. Every Ethereum node would have to compute and store this data. So to prevent spamming the network, we need a way to determine the resource impact of a transaction to a contract. Every OPCODE has a pre-defined gas cost.

In general you can know that there are four tiers of gas costs:

Writing to Storage: Very expensive.
Reading from Storage: Average.
In-memory data and computations: Cheap.
Deleting (freeing up) storage data: You get money back.

One very important thing for you to know is that there is a maximum amount of gas you can use in a single transaction. You can see here that it's changing over time and tends to go slowly up. But always know that there is a max. So you should never loop over arbitrary large arrays. This is bad design for contracts. Instead find a way to split the computation into smaller steps.

For example instead of sending money to all defined addresses, have a single function that sends the money to only who just called the contract. Then everyone who wants their money, needs to call the function. This is called the withdrawal pattern. (If the last part was a bit over your head still, don't worry. Read the rest and come back here afterwards.)

1. Let's talk about Functions

Let's look at our first example. This would be a pretty stupid smart contract to actually have, but it makes a great example. Anyone could send Ether to this contract and it would automatically send only half the Ether back. A money eating machine. Don't actually use this.

We could deploy this contract, meaning we put it on the blockchain and it will get an address for everyone to send transactions to. Once it's deployed, nobody can stop it, it will run forever, always with the same pre-defined behavior.

Let's break down each line.

// SPDX-License-Identifier: MIT
pragma solidity 0.7.5;

contract FastTrack {
  function payMeBackHalf() external payable {
    uint256 halfAmount = msg.value / 2;
    (bool success, ) = msg.sender.call{value: halfAmount}("");

    require(success, "return transaction failed");
  }
}

// SPDX-License-Identifier: MIT: Just a software license identifier that's required since 0.6.8. Check out available identifiers here.
pragma solidity 0.7.5: Specify which version of the Solidity compiler the contract is written for.
contract FastTrack: Specify the name of your smart contract.
function payMeBackHalf() external payable: A function we define that other people can use when interacting with out contract. Here we specify the name, visibility and declare it as payable. The visibility is external, meaning the function can only be called from outside of this contract. The opposite would be private, meaning the function is just a helper function we use in our contract to make it more readable. Declaring the function as payable means someone calling this function is allowed to send Ether along with the call. If it's not declared as payable, people couldn't send any Ether at all when calling this particular function.
uint256 halfAmount = msg.value / 2: This line is simple. The msg.value is a pre-defined variable and just holds the amount of Ether that is being sent to this contract. Now we set an unsigned integer with 256 bits to half of this value. Why unsigned? Because the value must be positive. Why 256 bits? The EVM operates on 32 bytes == 256 bits registers. You could use smaller types (like uint32), but this makes only sense in very specific situations. Don't worry about it now and just use 32 bytes types.
(bool success, ) = msg.sender.call{value: halfAmount}(""): Okay this one might look a little bit complicated, but it's not. We also could have used the previous way to write it which was msg.transfer(halfAmount). Same effect, but its usage is discouraged and the call way is also great for explaining more since the .transfer just does a lot under the hood. The msg.sender.call is creating another transaction. Remember a contract is just an automated address, so of course it can create transactions itself. In this case we send it to msg.sender, another pre-defined variable which is the current person (or contract) sending the transaction to this contract. The .call returns two values bool success and bytes result. Bool is just a value that is either true or false and bytes is just any undefined data (0's and 1's). However we do not care about the result data and just ignore it. We also send only an empty string via .call(""), meaning we don't send any data with our call, but we set value to halfAmount.. This is effectively just a transfer of Ether transaction.
require(success, "return transaction failed"): Now this require you will see a lot of times in contracts. It's a short form for if (!success) revert("return transaction failed"). And it reverts a transaction with the given error message. If a transaction is reverted, it's considered invalid. So anytime this would happen in your smart contract, the transaction is just ignored by Ethereum nodes and it will never be integrated into the blockchain.

2. Let's talk about Storage

In the above example we have only used data that was sent to in the transaction itself, but that alone would be pretty useless. We want to be able to store and read data inside the contract to enable more advanced use cases.

Let's build an escrow contract that enables a buyer and a seller that don't trust each other to do a trade online. They choose a trusted third-party arbitrator in case of a conflict. The contract will introduce the concept of

Storage
Modifiers
Two more data types: address and mappings
Constructors

Storage variables are defined at the top of the contract. You define the data type, the visibility and the name.

Type: address
Visibility: public
Name: seller

Types: We've already introduced the most important types, namely bool, integers and bytes. Each of those can be either a single value or a list of values (arrays). The two new types we added are:

address: This type represents an Ethereum address. This could be a human-controlled account address, also known as externally-owned account (EOA), or a smart contract address. There are a few other types, but don't worry about those for now.
mapping: This is just a key-value storage. You define the types for the key and the value, in our case address and bool. Now we can read and write to this variable:

read: myMapping[myAddressKey]
write: myMapping[myAddressKey] = myBool

Visibility: In storage you can choose between private, internal or public. Internal has to do with inheritance which is out of the scope of this introduction, so just think about private vs. public. Most of the times you probably want a public variable. This is just a convenience for people interacting with the contract to easily read the value. A private value does not mean the data is secret. A clever person could still find out the value.

Constructor: In our first contract we just deployed it without any additional data. But sometimes you might want to define some parameters when creating the contract. In our escrow we want to set the addresses for our three entities, seller, buyer and arbitrator.

Modifiers: We introduce the concept of modifiers here. You don't have to use them, but they can make the code more readable. You can define a bunch of requirements for a function call in them via the require statement. The '_;' indicates that here the function code will be executed here.

How does our Escrow Contract work?

Look at the example on the right. You should have all the knowledge to understand the code now. But take your time. Can you see what is happening?

When doing an online trade, the seller can discuss with the buyer which arbitrator to choose. Once decided, someone can deploy this contract. Now the buyer can call depositIntoEscrow and transfer the purchase price amount into the contract. Then the money is locked in our contract.

In the normal case the seller would now ship the product, the buyer receives it and calls confirmPurchase. Then the seller can also call confirmPurchase and the money will be sent to him.

In the case of a refund, the buyer would send the product back to the seller. Now the seller would call confirmRefund. Next the buyer can also call confirmRefund and the money will be sent back to him.

In the case of a dispute, a buyer might claim to never have received a product. So the buyer calls confirmRefund, while the seller would call confirmPurchase. Now nobody gets any money, but the arbitrator can be called. The arbitrator can investigate the case and then decide if to call confirmPurchase or confirmRefund.

Job for you: Try to improve on this for the dispute case by allowing the arbitrator to split the remaining funds in a ratio that he defines. So for example the arbitrator could decide, send 30% to the buyer and 70% to the seller.

contract Escrow {
  address public seller;
  address public buyer;
  address public arbitrator;

  uint256 public purchasePrice;
  uint256 public purchaseConfirmationCount;
  uint256 public refundConfirmationCount;

  mapping(address => bool) public hasConfirmedPurchase;
  mapping(address => bool) public hasConfirmedRefund;

  constructor(
    address seller_,
    address buyer_,
    address arbitrator_
  ) {
    seller = seller_;
    buyer = buyer_;
    arbitrator = arbitrator_;
  }

  modifier isRegisteredParticipant {
    require(
      msg.sender == seller ||
        msg.sender == buyer ||
        msg.sender == arbitrator,
      "Only registered participants can call this"
    );

    _;
  }

  function depositIntoEscrow() external payable {
    require(purchasePrice == 0, "Already deposited");
    require(
      msg.sender == buyer,
      "Only buyer should deposit into escrow"
    );
    purchasePrice = msg.value;
  }

  function confirmPurchase() external isRegisteredParticipant {
    require(
      !hasConfirmedPurchase[msg.sender],
      "Already confirmed purchase"
    );

    hasConfirmedPurchase[msg.sender] = true;
    purchaseConfirmationCount = purchaseConfirmationCount + 1;

    if (purchaseConfirmationCount >= 2) {
      _sendFundsTo(seller);
    }
  }

  function confirmRefund() external isRegisteredParticipant {
    require(
      !hasConfirmedRefund[msg.sender],
      "Already confirmed refund"
    );

    hasConfirmedRefund[msg.sender] = true;
    refundConfirmationCount = refundConfirmationCount + 1;

    if (refundConfirmationCount >= 2) {
      _sendFundsTo(buyer);
    }
  }

  function _sendFundsTo(address recipient) private {
    (bool success, ) = recipient.call{value: purchasePrice}("");
    require(success, "Sending funds transaction failed");
  }
}

Congratulations. That's it.

I know you're already an expert, but even experts can still learn more right? A few ideas on what to look at next would be:

Events: A special type of storage that cannot be accessed by contracts themselves.
Structs: Custom types you can define that are a collection of sub-types.
ERC-20: A very popular contract standard. See here for how you can implement one easily.
Libraries: Special contracts that have no storage, but can be used only for implementation code.
Inheritance: Solidity supports inheritance including polymorphism. A great way to structure your contracts.

And last but not least, check out my overview about Solidity development and all the relevant tools and infrastructure here.

Markus Waas

Solidity Developer