🔗 - What is the Blockchain?

A Blockchain is a decentralized, distributed, immutable, public digital ledger where each record is called “block” (all these blocks are linked together using cryptography - and maths - forming a chain, this is where they take their name), used to record transactions between different users or computers. Blockchains are mostly known for their role in the cryptocurrencies systems, such as Bitcoin or Ethereum.

The goal of this technology is to allow digital information to be distributed among different parties but not edited in any possible way, thus creating an immutable set of blocks that show the history of what happened.

Explaining the blockchain using Ethereum

Whether or not you know what it is, you’ll most likely have heard about Ethereum: we’ll use this blockchain to explain how the technology works underneath, since the ledger that powers Playerself - Polygon (more about that later) - is compatible with this blockchain.

Ethereum is a transaction-based state machine, a term that refers to a system that reads a series of inputs and will transition to a new state on those inputs. The first state is called “genesis state”, which is basically the starting empty state of the blockchain; the last state, instead, is the current state of the ledger.

All the transactions, as we already stated before, are grouped into blocks, and each block is linked together with its “parent” - or previous - block. The process of validating a block is known as mining, another buzzword that you may have heard in the news: this process consists on providing a mathematical “proof” when submitting the block to the blockchain; the node that proves it first is rewarded with a certain amount of Ether, the intrinsic digital token of the Blockchain. This process is known as “proof of work”.

Ethereum is currently trying to change this kind of process, moving towards a more eco-friendly approach: the proof of work mechanism is really resource-intensive and needs a lot of computational power (this is why you can’t find your best GPU). This new approach, used in the ledger that runs Playerself logic, is called proof of stake, where a computer (called node) can validate a block based on how many coins they hold: the more money they hold, the more validating power they have.

Accounts

Inside the global “shared-state” of Ethereum there are these small objects, that for readablity we’ll call them “accounts”, that have a state and a 20-byte address, a long string identifier. Each account inside its state has its balance, which is basically the number of Wei (1 Ether = 1e+18 Wei) it owns.

There’s a special kind of accounts, called “contract accounts”, that in their state they hold also their “contract code”: those are the beloved Smart Contracts that make Ethereum so powerful and widely used.

Unlike EOAs (“Externally owned accounts”, the term used to target all the non-contract accounts), a contract cannot initiate a new transaction on its own: it can only execute transactions in response to a transaction they receive from an EOA or from another contract (more on Smart Contracts later).

Gas and payments

An important concept in Ethereum is the concept of fee. Every computation that occurs as a result of a transaction on the Ethereum network incurs a fee, there’s no escape.

Gas is the unit used to measure the fees required for a computation; gas price, instead, is the amount of Ether that you are willing to spend on each unit of gas (measured in gwei, 1 gwei = 1,000,000,000 Wei). When an account sends a transaction, it must set a gas limit and a gas price (dont’t worry, all the wallet solutions available already do this for you): the product of these two represent the maximum amount of wei that it is willing to pay for executing that given transaction.

Of course an account needs to have enough balance to cover this expense; also any unspent gas will be refunded at the end of the transaction, exchanged at the original rate. If an account does not provide enough gas to execute a transaction (inside a transaction there are many operations, each operation costs a fixed amount of gas), the transaction is invalid and literally “runs out of gas”: if this happens, none of the gas is refunded to the account and the failed transaction is recorded.

All the money spent on gas is typically sent to the miner’s address that is validating the block where transaction is placed: this is the reward we were talking about. As you can imagine, the higher the gas price an address is willing to pay, the greater the value the miner generates: the miner is then incentivized to select your transaction first and insert it in a block.

This means that if the network is congested (a lot of addresses are sending a lot of transactions), you’ll need to increase the amount of wei you’re willing to pay in order to be sure that your transaction will be executed: this is the reason why Ethereum gas fees (at the time of writing this) are really high - the “transaction competition” is really strong.

Smart Contracts

Even though the word “contract” briongs to mind legal agreements, this is not the case for Ethereum: as we stated before, a “smart contract” is just a bunch of code that is able to run on the blockchain and its results are guaranteed to produce the same result for everyone who runs them.

The term was coined in the 90’s by Nick Szabo and he defined it as “a set of promises, specified in digital form, including protocols within which the parties perform on the other promises.”.

Ethereum Virtual Machine (EVM)

Before talking about Smart Contract concepts, we need to take a little step back and talk about the Ethereum Virtual Machine (we’ll refer to it as EVM later and most likely everywhere).

The EVM is literally the Ethereum Core and it’s how the Ethereum blockchain has evolved from a static distributed ledger to a distributed transaction-based state machine: the specific rules of changing state from block to block are defined by the EVM.

The Ethereum transition function can be written down as follows:

F(S, T) = S'

Given a valid state S and a new set of valid transactions T, the function F(S, T) produces the new valid output state S’.

We will not talk about EVM instructions and implementations, but if you’re curious you can read more about it here.

BACK TO THE CONTRACTS

Using the Nick Szabo’s metaphor of the vending machine, we know that to get a snack we need to the give some money to it.

money + snack number = snack obtained (yay! 🍫)

The logic of obtaining the snack is programmed inside the vending machine: the same goes for a smart contract.

If we wanted to write a smart contract that acts like the above snack dispenser, we will write something like this:

pragma solidity 0.8.7;

contract VendingMachine {

    // Declare state variables of the contract
    address public owner;
    mapping (address => uint) public cupcakeBalances;

    // When 'VendingMachine' contract is deployed:
    // 1. set the deploying address as the owner of the contract
    // 2. set the deployed smart contract's cupcake balance to 100
    constructor() {
        owner = msg.sender;
        cupcakeBalances[address(this)] = 100;
    }

    // Allow the owner to increase the smart contract's cupcake balance
    function refill(uint amount) public {
        require(msg.sender == owner, "Only the owner can refill.");
        cupcakeBalances[address(this)] += amount;
    }

    // Allow anyone to purchase cupcakes
    function purchase(uint amount) public payable {
        require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
        require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase");
        cupcakeBalances[address(this)] -= amount;
        cupcakeBalances[msg.sender] += amount;
    }
}

Buy calling the purchase function we can obtain our cupcake, but only if we provide 1 ETH to it; if we are the owner of the smart contract (aka the vending machine owner), we can call the refill function to refill the vending machine with cupcackes.

There are mainly two programming languages for writing smart contracts:

• Solidity (used in the example above)

• Vyper

Something to take in mind: smart contracts alone cannot get information about “real-world” events because they cannot send requests to outside the EVM, and this is a “by design” feature. Also smart contracts have a maximum size of 24KB.

Learn more

This explanation is based on this awesome work by Preethi Kasireddy. If you want a more in-depth view of how Ethereum works, we strongly recommend reading it.