Writing my First Ethereum Smart Contract (Part 1)

I am sure you would have heard about Bitcoin. Similar to Bitcoin, Ethereum is another blockchain platform with its own cryptocurrency — Ether (ETH).

Ethereum is a decentralised, open-source blockchain with smart contract — world’s programmable blockchain. Unlike Bitcoin, Ethereum gives you the capability to develop your own digital assets.

Solidity is the programming language that is used to write smart contract in Ethereum. Let’s get started with some basics of Solidity!

Photo by John Schnobrich on Unsplash

Solidity Compilation

Solc is used to compile solidity code into Ethereum Virtual Machine (EVM) bytecode. The bytecode will then be deployed to Ethereum Network in a transaction.

Introduction to the Solidity

Basic Structure of a smart contract

The structure is very similar to any OOP languages like Java/C#.

We should always define the solidity version on the 1st line, followed by the implementation of the contract where it can encapsulate the variables and methods. Class inheritance is supported as well.

Example of an abstract contract

Example of a contract with inheritance

Basic Data type

• bool
• enum <name> {members}
  - e.g. enum diceFaces { one, two, three, four, five, six}
• int, uint, int8, uint8, int16, uint16, … , uint256
  - signed and unsigned (can be both positive/negative numbers) integers with size
  - default = 256, hence int = int256, uint = uint256
  - int8 means 1 byte signed integer
• address
  - holds 20 byte address (for example ethereum account address)
• String

Complex Data Types

• bytes
  - dynamic array of bytes
• <type>[]
  - dynamic array
  - e.g. uint[] numArr;
• mapping(<key type> => <value type>)
  - concept of a hash map of <key type> to <value type>
  - e.g. mapping(address => uint) balance;
• struct <name> { <member types> }
  - e.g. struct item {
  string name;
  uint id;
  address addr;
  }

Variable scope

• State variables — defined within the scope of a contract. It has persistent storage and will be stored in Ethereum’s ledger.
  e.g.
  contract ReadWriter {
  uint data; // state variable
  }
• Local variables — defined within scope of a function. It consumes EVM stack memory during execution but will be discarded upon completion.
  e.g.
  contract ReadWriter {
  function calculateFoo() {
  uint temp; // local variable
  }
  }

There are 2 types of storage:

1. storage — EVM’s persistent storage (expensive for GAS). Default of state variables
2. memory — EVM’s temporary storage (lower GAS). Default for local variables.

While memory is the default storage type for local variables but it (and function parameters) can also be defined as storage explicitly.

Function Syntax

function <name> (<params>) <visibility / modifier> <return type> {
  <function body> ...
}
e.g. The following method is callable by end users
function calculateSum(uint num) public view returns (uint) {
  ...
  return total;
}

Visibility

1. external — can be called from another contract using call or delegatecall
2. public — public function or state variables that is callable by end users / web3
3. internal — function or state variables accessible from current or inherited contracts
4. private — function or state variables accessible only from current contract

Function modifier

1. payable — able to receive ether. Otherwise, an error will be thrown if ether is provided.
2. view — does not change state variables. Can be called without transaction fee (read-only functions, does not modify state at all)
3. pure — does not access state variable at all. Can be called without transaction fee. Such functions usually only does calculation.

Function Modifier using _

_ is used for commonly re-used snippets of code. This can help to improves readability.

Special methods and variables

• msg.value — amount of ether sent in transaction call
• msg.sender — caller of current transaction
• tx.origin — original caller of transaction chain
• tx.gasprice — GAS price specified by the caller

Demonstrate the difference between tx.orgin and msg.sender

Events

Events is an inheritable member of a contract. It allows applications to subscribe and listen to these events. Transaction logs are created when an event is emitted. These logs are stored in the chain and will be accessible using address of the contract while it still exist in the chain.

// Declare an event
event <name> (<parameters>)
// Emit an event
emit <name> (<parameters>)

Conclusion

Above summarises the basic concept to Solidity programming and I hope it has given you an insightful overview of the syntax and let’s get started with a full fledge example of a smart contract in the next article!

Thank you for reading!