Lab 2 - Writing smart contracts using Solidity

In this lab we'll start to create the smart contracts for CryptoFlight. We'll start by a quick overview of the Solidity language and then head into the actual development using Remix.

Introduction to Smart contract

A smart contract, or crypto-contract, is simply a program that runs on the blockchain. In traditional web applications you probably have some kind of central server that acts as the trusted third party. The frontend of the application communicates with the backend, sending requests and receiving responses. In the world of smart contracts we also have a frontend built with HTML, CSS and JavaScript, but instead of a backend we communicate with the blockchain. It's also possible to build hybrid applications where we both have a traditional server for one part of the application and a decentralized blockchain approach for other parts.

In a decentralized application such as a smart contract we trust the consensus on the blockchain. An important thing to remember when writing smart contracts is that every operation and everything that is stored has a cost bound to it. This is so that we can give an incentive to the miners to actually run the code in the contract. Every operation has a certain gas price that you pay for using Ether. When we're using the testnet we don't need to pay any real money since the Ether doesn't have any real value. However, if you want to run the application on the mainnet you need to pay for its deployment with real Ether. Every time someone calls the contract that caller must also pay for the gas cost using real Ether. This is something we will come back to later when discussing how we actually write our contract.

The Solidity programming language

The most popular programming language for writing apps in Ethereum is Solidity. It has a syntax that looks somewhat similar to JavaScript mixed with C. Some important things to note is that Solidity is a strongly typed language, and it's important to use the right types for the right purpose since we pay for every execution. A larger data structure requires more computational power from the network and is therefore more costly.

To declare a variable in Solidity you first declare the datatype and the the name of the variable. For example:

bool finished;
uint64 number;
string name;

Unlike JavaScript, you are required to have a semi-colon on the end of each line (in JavaScript this is optional). If you don't explicitly declare a variable as constant it will be considered to be a variable data type. To mark it as constant you simple add the keyword constant after the type declaration.

Structs looks similar to what you're are used to in C, these are composite data types that can consist of any number of other data types. The concept of an array also exists in Solidity. These are of variable length and can be contain any data type, but the datatype must be explicitly defined and an array can only hold one type of data. A struct looks like:

struct Traveller {
    bool finished;
    uint64 number;
    string name;
}

And an array has the following declaration:

address[] public approvedTravellers;

Dictionaries in Solidity are works a little bit different compared to other languages. These are called mappings in solidity and maps from one key to one value. So far it's similar to objects in JavaScript, hashmaps in Java or dicts in Python. The main difference is that a mapping in Solidity resolves to either a value or a byte-representation of 0. What that means in practice is that it's possible to try to retrieve any value from a mapping without having an exception thrown. If the value doesn't exist it will just return zero. The syntax for creating a mapping is: mapping(string => address) members, this one maps from strings to addresses.

There is no such thing as a class in Solidity, however the contracts themselves can be are very similar to classes. A contract can have a constructor, any number of instance variables and include functions. A function in a solidity contract is similar to a method in Java.

The constructor gets declared with the keyword constructor from version 0.5.0 and onwards. If you follow old tutorials you've might seen it getting declared with a function that has the same name as the contract (similar to Java). The constructor accepts any number of parameters and is used to setting the initial state of the contract.

A function in Solidity is declared by the keyword function, a set of input parameters and its visibility, for example public. It's also possible to mark a function as payable if it should be able to receive ether. An example of a function:

function addTraveller() public payable {
    require(msg.value >= minBid);
    
    Traveller memory newTraveller = Traveller({
       user: msg.sender,
       bid: msg.value,
       approved: false
    });
    
    travellers.push(newTraveller);
}

This is an actual function we'll use in our CryptoFlight contract. We create a new traveller from the struct Traveller, setting the user to the caller of the function and adding it to the array of travellers. All of this will make more sense as we start implementing the contract.

The code snippet above also introduce another keyword: require. This makes sure that the amount of ether that gets sent to the contract is no less than the minimum bidding price set by the airline. If it's less than the minimum bid the function will not continue executing. Again, this will all make more sense later on.

Another important concept in Solidity is modifiers. A modifier is some code that gets executed right before the function starts executing. The concept is somewhat similar to middlewares (in Node) or macros (in C). For example, if you write a server in Node using Express you might define a middleware for making sure that the caller has the required access level. A modifier in Solidity looks like:

modifier auth() {
    require(msg.sender == creator);
    _;
}

This modifier, auth, is used to make sure that only the creator of the contract can call a certain function. In the CryptoFlight contract this will be used for making sure that only the airline that created the contract is able to finalize it. The underscore on the third line is where the rest on the function code will be executed. One benefit of this architecture is that it's possible to add a middleware both before after the function execution.

That's a very short intro to Solidity, it's a fairly small language with a couple of caveats but it should be pretty quick to get up and running with it.

Introduction to Remix

When you develop traditional apps in other courses you most likely have both a debugger and a profiler to help you out. You might also use an IDE such as CLion for C++ or IntelliJ for Java. We are going to use a web based IDE called Remix. This tool allows you to write the code and test it locally in the browser, without the need for deploying it the the Ropsten testnet (or the main Ethereum network).

Getting started with remix is easy just go to remix.ethereum.org and create a new project. When you first visit Remix you will see an example project called Ballot that basically is an example of how you can implement distributed voting as a smart contract. If you read other tutorials about Ethereum and smart contracts, voting will definitely come up as an example.

The main screen of Remix

We are mostly going to spend our time in the code editor view and alternate between the Compile and Run tab in the upper right hand corner. You can close the left-most pane if you need some more screen estate.

In the compile-tab you will see the current compiler version and a button for compiling your solidity-contract. Every time you make a change in the code you need to recompile the code and deploy a new contract. The CryptoFlight-contract should be working with all compilers that are of version 0.5.0 and above, at least up to the currently latest which is 0.5.4. If you are from the future (welcome again!) there might be some breaking changes. In that case, just choose an older compiler version from the dropdown, for example 0.5.4.

Over in the Run-tab you can first choose which environment you want to run in, that is, which blockchain you want to connect to. You can use a Web3-provider if you want to connect to a live blockchain (for example for Ropsten testnet or the Ethereum mainnet). Injected Web3 is useful if you want to connect to a blockchain running locally (for example the one we started using Ganache in Lab 1). This can be useful if you want to perform some testing and have a better overview of the transactions. We are going to use the third alternative, JavaScript VM. This is a barebone Ethereum testnet running in the browser.

In the Account-dropdown you can choose which account you want to perform the transaction from. This is useful for simulating different users interacting with your dapp and we'll come back to this soon.

Gas limit is the maximum amount of gas you are willing to pay for every invocation. For our testing purposes it doesn't really matter so just leave it at its default value.

Value is the amount of ether you want to send along in the transaction. Be aware that the default unit here is wei. One ether equals 1,000,000,000,000,000,000 wei. I recommend changing this to Ether while testing so we more easily can see the effect our transaction has on the the account balance.

Introduction to CryptoFlight and its smart contract

The core idea with CryptoFlight is to provide a way for airlines to sell remaining tickets for a price as good as possible and for travellers to get left-over tickets as cheap as possible. An airline posts an offer with a departure and destination as well as their minimum acceptable bid. The travellers can list all available flights and make make sure that all deployed contracts actually uses our code we will have a separate factory-contract. This contract is responsible for holding a list of deployed contracts as well as acting as a creator of new contracts.

Using the factory-pattern in Solidity is a fairly common practice. It's often required to keep the application fully decentralized since the alternative would be to store the addresses of the deployed contracts in a central data store off-chain.

Implementing the contract

We now have a pretty good idea of what the contract should do and what functions we need so let's get started implementing it. First, create a new file in Remix and name in CryptoFlight.sol

Now we'll create the contract and build it out step by step. I will provide the full code example by the end of this section so no need to copy and paste these snippets.

pragma solidity >=0.5.0 <0.6.0;

contract CryptoFlight {
    struct Traveller {
        uint256 bid;
        address payable user;
        bool approved;
    }

    Traveller[] public travellers;
    address payable creator;
    uint256 minBid;
    string departure;
    string destination;
    bool finalized;
    
    constructor(uint256 _minBid, string memory _departure, string memory _destination, address payable _creator) public {
        creator = _creator;
        minBid = _minBid;
        departure = _departure;
        destination =  _destination;
        finalized = false;
    }
}

On the first line we declare what version of Solidity the code is intended for. This code should compile properly on all versions from 0.5.0, up to but not including 0.6.0. Then we define the actual contract. The struct Traveller contains all travellers that has signed up for this specific flight. We save the bid of the traveller, its address and a variable saying if the traveller gets approved or not. Note that the user is marked as payable since we might what to return the ether to the traveller in case he or she doesn't make it to the flight.

Next we declare an array that holds all the travellers. The creator is the address of the contract-creator. It's marked as payable since the contract creator (the airline) will be the one that receives the Ether from its participants when the contract gets finalized (more on that later). We will later create our own token (CFToken) and use it as a means of payment instead of using Ether.

The minBid variable is set by the creator when he or she creates the contract. This is the least amount of Ether (later on CFToken) what the airline think is acceptable for a certain flight. The departure and destination variables are self-explanatory and the variable finalized marks if a flight is finalized or not. When the flight is finalized all of the assets in the contract will be paid out, either the contract creator (the airline) for the travellers that gets accepted, or back to the travellers if they didn't make it to this flight.

In the constructor we initialize all of these variables. It's common practice in Solidity to mark the parameters in the function header with a leading underscore so we can keep them separated from the instance variables which are the one we initialize.

function getFlight() public view returns(address, uint256, string memory, string memory, bool) {
    return (creator, minBid, departure, destination, finalized);
}

The getFlight-function returns all of the information for a flight in the form of a tuple. This is similar to how return-functions works in Python. In JavaScript you would instead return an object here. We must define the variable types in the header of the function so the compiler knows what we want to return.

 function addTraveller() public payable {
     require(msg.value >= minBid);
     
     Traveller memory newTraveller = Traveller({
        user: msg.sender,
        bid: msg.value,
        approved: false
     });
     
     travellers.push(newTraveller);
 }

To add a traveller we call the addTraveller()-function which is marked as payable since we need to send some Ether along with the function call. The Ether sent is stored in the contract implicitly. To keep track of the caller of the function, we store the sender along with its bid in the the travellers-array. The approved-variable will be used later to determine whether or not the traveller got an seat on the flight.

modifier auth() {
    require(msg.sender == creator);
    _;
}

function finalizeFlight(uint64 _seats) public auth {
    uint64 seatsFilled = 0;
    
    while (seatsFilled < _seats && seatsFilled < travellers.length) {
        uint256 currentHighestBid = 0;
        uint64 currentHighestId = 0;
        
        for (uint16 i = 0; i < travellers.length; i++) {
            if (currentHighestBid < travellers[i].bid && !travellers[i].approved) {
                currentHighestBid = travellers[i].bid;
                currentHighestId = i;
            }
        }
        
        travellers[currentHighestId].approved = true;
        
        seatsFilled++;
    }
    
    for (uint16 i = 0; i < travellers.length; i++) {
        if (travellers[i].approved) {
            address payable _creator = creator;
            _creator.transfer(travellers[i].bid);
        } else {
            Traveller storage traveller = travellers[_seats];
            address payable user = traveller.user;
            user.transfer(traveller.bid);
        }
    }
    
    finalized = true;
}

Finally we have the function for finalizing a contract. The auth-modifier makes sure that only the creator of the contract is able to call the finalize-function. When the function gets called by the contract-creator the code inside the function will execute.

The function takes in parameter, seats, which corresponds to the number of seats that the airline wants to offer for the specific flights. We set the number of filled seats to be zero and then work our way through the list of travellers that are interested in taking the flight. We work our way through the list of travellers and fills up the seats one by one. If the number of seats offered are greater than or equal to the number of travellers interested in the flight give all of them a seat on the flight. If the number of seats offered are less than the travellers that want to take the flight we assign the seats to the travellers with the highest bid first. If two travellers have put in the same bid for a certain flight we choose the traveller that signed up first.

When we assigned all the seats and determined who should get a should who should be left out we start paying out all of the ether. For the travellers that got a seat the ether is transferred to the contract creator. If a traveller doesn't get a seat on the flight, the assets are returned back to him.

Implementing the factory-pattern

As described earlier, the factory-pattern is very common for ethereum contracts. We will build a separate contract, CryptoFlightFactory, that we use to deploy CryptoFlight-contracts and save the deployed contracts in an array. The code looks as follows:

CryptoFlight.sol

pragma solidity >=0.5.0 <0.6.0;

contract CryptoFlightFactory {
    CryptoFlight[] public deployedFlights;

    function createFlight(uint256 minimumBid, string memory departure, string memory destination) public {
        CryptoFlight flight = new CryptoFlight(minimumBid, departure, destination, msg.sender);
        deployedFlights.push(flight);
    }

    function getDeployedFlights() public view returns (CryptoFlight[] memory) {
        return deployedFlights;
    }
}

The deployedFlights-array holds the addresses to all deployed flights. When createContract gets called the airline needs to specify the minimum acceptable bid, the departure city as well as the destination city. We then push this flight to the deployedFlights-array.

Our deployedFlights-array is declared as public so it is reachable for anyone, however, we need a separate function for returning a list of all flights since we need to pass in the index of the flight we want to retrieve. This is the purpose of the getDeployedFlights-function, calling it returns the full list of deployed flights.

That's it for our contract, the full code looks like:

CryptoFlight.sol

pragma solidity >=0.5.0 <0.6.0;

contract CryptoFlightFactory {
    CryptoFlight[] public deployedFlights;

    function createFlight(uint256 minimumBid, string memory departure, string memory destination) public {
        CryptoFlight flight = new CryptoFlight(minimumBid, departure, destination, msg.sender);
        deployedFlights.push(flight);
    }

    function getDeployedFlights() public view returns (CryptoFlight[] memory) {
        return deployedFlights;
    }
}

contract CryptoFlight {
    struct Traveller {
        uint256 bid;
        address payable user;
        bool approved;
    }

    Traveller[] public travellers;
    address payable creator;
    uint256 minBid;
    string departure;
    string destination;
    bool finalized;

    modifier auth() {
        require(msg.sender == creator);
        _;
    }

    constructor(uint256 _minBid, string memory _departure, string memory _destination, address payable _creator) public payable {
        creator = _creator;
        minBid = _minBid;
        departure = _departure;
        destination =  _destination;
        finalized = false;
    }

    function getFlight() public view returns(address, uint256, string memory, string memory, bool) {
        return (creator, minBid, departure, destination, finalized);
    }

    function addTraveller() public payable {
        require(msg.value >= minBid);
        
        address payable user = msg.sender;
        
        Traveller memory newTraveller = Traveller({
           user: user,
           bid: msg.value,
           approved: false
        });

        travellers.push(newTraveller);
    }

    function finalizeFlight(uint64 _seats) public auth {
        uint64 seatsFilled = 0;

        while (seatsFilled < _seats && seatsFilled < travellers.length) {
            uint256 currentHighestBid = 0;
            uint64 currentHighestId = 0;

            for (uint16 i = 0; i < travellers.length; i++) {
                if (currentHighestBid < travellers[i].bid && !travellers[i].approved) {
                    currentHighestBid = travellers[i].bid;
                    currentHighestId = i;
                }
            }

            travellers[currentHighestId].approved = true;

            seatsFilled++;
        }

        for (uint16 i = 0; i < travellers.length; i++) {
            if (travellers[i].approved) {
                address payable _creator = creator;
                _creator.transfer(travellers[i].bid);
            } else {
                Traveller storage traveller = travellers[_seats];
                address payable user = traveller.user;
                user.transfer(traveller.bid);
            }
        }

        finalized = true;
    }
}

In a later lab we will need to rewrite these contracts a little bit to make use of our own token instead of Ether. We will also add an array to store the travellers that got a seat in the finalized contract, but this will do for now and is enough to get up and running with some smart contract development. We will also change the CryptoFlightFactory to include the address to our token so that this can be used inside of deployed flights.

Deploying and testing your smart contract using Remix

Now it's time to actually try out the contract inside Remix. Copy the full code above to your CryptoFlight.sol file inside Remix. Make sure the compiler is set to at least 0.5.0 and click the "Start to compile"-button and make sure the contract compiles without any errors.

Then head over to the Run-tab and set the environment to JavaScript VM and select the first account in the list. If this is the first time you interact with a contract here the number of ether should be equal to 100.

Select CryptoFlightFactory in the dropdown and click Deploy. This deploys the factory-contract to our local blockchain running in the JavaScript virtual machine. The amount of ether in the account you used to deploy the contract should now have decreased slightly since we need to pay gas for deploying a contract.

Under the Deployed Contracts-tab, expand the CryptoFlightFactory label and you should now see the available methods. As expected we have three methods visible, one for creating a new CryptoFlight-contract, one for retrieving a single CryptoFlight-contract and one for retrieving an array of all deployed flights.

Next up we'll pretend to be an airline and deploy our very first CryptoFlight-contract. To do this, enter the minimum bid as well as the the departure and destination in the field to the right of the red createFlight-button. Remember that the minimumBid is in wei. For example we might fill in:

This will deploy a new CryptoFlight-contract with a minimum bid of 100 wei and the flight departing from Stockholm and arriving in Gothenburg. If the deployment is successful you will see an output in the debug-log similar to:

To get the address of the contract we just deployed we will use the getDeployedFlights-function inside cryptoFlightFactory. This functions returns an array of the addresses to all deployed flights.

Copy this address and paste it into the "At Address" field right above. Also, remember to change the dropdown to CryptoFlight.

Click the blue "At Address" button to retrieve this contract from the blockchain. Now you should see a new contract appear in the bottom of the right-hand panel:

Now we will pretend to be a traveller who wants to traveller from Stockholm to Gothenburg and put in a bid of 5 ether. In the top of the panel, select the second account which still should have a balance of 100 ether. Fill in 5 in the field for value and set the dropdown to ether instead of wei:

Then go back down to the contract view and click the button addTraveller:

If you look in the debug-console you should see a confirmation that the transaction was successful. In the account-view you should also see the balance decreasing with a little bit more than 5 ether, this is the amount that we transfered into the contract plus the gas we had to pay to execute the function:

Now repeat this two times with different accounts. Let account number 3 make an offer of 10 ether and account 4 an offer of 15 ether. The account balances should now look similar to:

As you can see, the first account has a little less than 100 ether, the second has 95, the third 90 and the fourth 85. Now we willl finalize the flight using the first account. Let's say the airline has 2 empty seats on the flight from Stockholm to Gothenburg. It wants to fill these seats and get as much money (ether) as possible for them. So, having the first account selected we will now finalize the contract using the finalizeFlights-function:

This will set the flight as finalized and transfer the Ether stored in the contract to its creator (the airline). In lab number 4 we will change the contract a little bit to make use of our own token instead of Ether as a means of payment.

Wrap up

We have now familiarized ourselves with the Solidity programming language, written our very first smart contract and done some manual testing in Remix. Next up we're going to write a frontend for the application using the Truffle framework in combination with React. See you in the third lab!

References and Useful links

https://ethgasstation.info

Solidity — Solidity 0.8.11 documentation

Remix documentation has moved! — Remix, Ethereum-IDE 1 documentation

Solidity Smart Contracts Design PatternsMedium

Introduction to Solidity Programming and Smart Contracts (For Complete Beginners)Medium

Advanced Solidity Concepts — CryptoZombies Lesson 3 and 4Medium