First things first, what is a blockchain?

Some say it's a database, while others think it's a system. I believe that the correct definition is the one available on Wikipedia: A blockchain, originally block chain, is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block a timestamp, and transaction data (generally represented as a Merkle tree root hash).

If a blockchain is used as a distributed ledger, effectively means that it's managed by a peer-to-peer network, collectively adhering to a protocol for inter-node communication and a consensus for transaction validation. Blockchains are considered to be secure by design as they exemplify a distributed computing system.

In our three-year quest to offer premium blockchain development to all our clients at Udevoffice, we have tried and tested many workflows for this to happen. During this time, we ended up with a simple process to develop and launch smart contracts (both for crypto and for DApps). In this article, we are focusing on:

• the Ethereum blockchain and
• on developing a token using smart contracts.

The focus of this article will be the ETHEREUM BLOCKCHAIN and how to develop a token using smart contracts. Before we dive in, let's take a little detour and explain more about the inner architecture of the Ethereum blockchain.
Before diving in, we will take a little detour and explain more about the inner architecture of the Ethereum blockchain. You will need programming skills and terminal knowledge. We will develop publish and unit test a coin/token called PostCoin on the Ethereum Rinkeby testnet network. Further experimenting exercises are available at the end of the article.
Propper blockchain knowledge is not required. We will walk you through all the terminology and point to the right resources whenever in-depth knowledge is necessary.

The EVM

The Ethereum blockchain is composed of nodes that communicate with each other. Each node lays on a common piece of software that, in the case of Ethereum, is called the Ethereum Virtual Machine or simply EVM.

Each node, that stores full or partial information about each block in the chain, verifies the authenticity and traceability of transactions.

The EVM is a Turing complete machine; this means that it can compute almost anything, given the necessary amount of resources. Various implementations of the EVM can be found all over the Internet. Some examples of what we worked with here at Udevoffice include go-ethereum or simply (geth), an Ethereum client written in GO, Parity client written in Rust and EthereumJ written in Java.

These are the go-to resources for whenever you want to install a local blockchain node or you want a custom setup for a private chain. If you are interested in private blockchains with custom logic for consensus algorithm, block rewards or custom Proof of Authority chains we recommend the Parity client because of their extensive documentation.

On the other hand, for the purpose of writing smart contracts, there's no need to install or use them because the Truffle framework that we are using here will simulate a local blockchain for you with no hassle.

Addresses

Each blockchain entity is uniquely identified by an address. There are two types: contract address and user address.

Syntactically they look the same, both use a 20 byte format which is a 40 character hex encoded string prefixed with 0x (example: 0xD52216266AC1EF883F3A13CDCD7C3F21523A3f7C).

The fundamental difference between the two is that one can store code (smart contract addresses) while the other doesn't. Another difference is that the initiator of a transaction is always a user address. This is important to note because as a smart contract developer the initiator of a function(transaction) chain is always the user. Smart contracts don't do anything by themselves, they just alter the initial transaction the user sent. If you come from a web development background you can think of them as middlewares for the client requests.

Transactions

Each mined block contains transactions that vary from a simple basic transaction (sending ether to another address) to complex transactions that are governed by the business requirements coded in the smart contracts. One special category of transactions is the token transactions that are governed by a Token developed over the ethereum network. The Tokens are actually smart contracts that encapsulate business logic specific to the DApp developed.

Transactions may include subtransactions. When a user calls a contract and the contract interacts with other contracts or entities on the blockchain.

There are two types of transactions that concern us smart contract developers and the main difference between them is that one is free and one costs ether. A read transaction (the free one) simply reads state from the blockchain (this can be getters or static functions) and the other are write transactions. The read transactions are never included in the mining pool (they are not mined). The read transactions are just requests that are executed on the local node that read state from the blockchain.

Consensus

This is an algorithm that has multiple implementations and is used by all blockchains. It describes how the nodes agree on what information to permanently store on the blocks that form the blockchain.

Multiple implementations of the blockchain consensus exist:

Proof of Work (PoW) consensus. 
This is the algorithm used by the Bitcoin and Main Ethereum network and is tightly related to the way miners mine blocks. Mining is the process of solving mathematical equations in order to verify and include transactions.
High computational power is required by the miners to solve the mathematical equations. Each block corresponds to a specific equation and whoever solves the problem first will get the right to generate the new block in the chain.
We will relate to this consensus algorithm in this article because it is still the most spread algorithm used on the main blockchain networks. In-depth information can also be found on Cointelegraph.

Proof of Authority (PoA) and Proof of Stake consensus algorithms. 

• A problem with the PoW algorithm is that the difficulty of the mathematical equation increases on each block and in respect to that the computational power required increases also. So other algorithms emerged (like PoA, PoS or Delegate PoS). 
• The Proof of Authority algorithm has a dedicated set of nodes called validators that validate transactions with respect to a set of rules. They usually have a dedicated type of node. The validator list is, in most blockchains, that implement PoA modified with a voting system that in most cases implemented directly on the chain. (Example Kovan test network)  The Proof of Stake algorithm aims to achieve distributed consensus by using a staking system in which the participants stake a portion of their wealth (in tokens or the main network coin) and become responsible of the generation of the next block. In the case of misbehaviour, the participant loses his stake.

The Delegated Proof of Stake is a hybrid of the PoA and PoS most importantly used in the EoS network.

Miners, gas and gas price

In a blockchain, most of the hard work is done by miners. They execute and put transactions in a block. On Ethereum, most of the resources needed for computation are guaranteed by those miners. They include the transactions in a mining pool then they order them using an algorithm for prioritization and finally, they generate a new block for the blockchain. The last block is linked with the one before it (hence the "chain" in the blockchain word) to achieve traceability.

In this context, the Smart Contracts can be defined (in a very simple way) as a set of instructions for the miners on how to execute user-initiated transactions.
But wait. Here you might have spotted a problem. There seems to be a lot of work for the miners! So how can we make sure that miners will want to mine our transactions? 

Some kind of reward must be introduced for the miners to incentivize their work. Also, this reward should be constant per each mined block. This means that the same amount of work needs to be done to mine, secure and generate two blocks of the same size. So we need to measure blocks, and in order to do that, we first need to think of a method to measure a transaction in a block.

In order to solve this issue, some kind of variable has to be introduced that can measure the complexity of the code we write in our smart contracts. This concept will also help us determine how many transactions can fit in a block. And, finally, this should be directly dependant on the price the user pays for his transactions to be executed. On the Ethereum blockchain, this is called the gas.

Usually, miners prioritize transactions by their gas amount and gas price. The gas price is a user set value that literally translates to how much money a user spends on 1 point of gas. Therefore, the actual cost of a transaction is the total gas that transaction consumes multiplied by the gasPrice.

Smart contract code and gas consumption correlation

For a certain piece of code to be executed we, as smart contract developers, will always have to think about the amount of gas each operation will cost. This is the reason that most of the smart contract code out there is focused primarily on safety and then on gas consumption. Also, there is no point of making a super transaction that will resolve in theory our business logic without considering the gas amount that the transaction will consume. We can generate a transaction that requires more gas than a block can fit in and in consequence that transaction will never be executed on the blockchain. Also, don't think that a situation like this is far fetched. A simple iteration on a dynamic array can cause this.

We must also bear in mind that high gas consumption literally translates to a higher price for the end-user. For more information on gas prices, a maintained repository with actual gas costs per operation can be found here on Github.

Smart contract code - privacy and security

Another cause of concern when writing smart contracts is that your code is not private! You must be aware that, with every line of code you write, an "evil" eye is reading it and may try to break it. Also, there is no point of thinking your code is private because this is a decentralized technology and making your code public is an encouraged practice.

Another practise of those that develop smart contracts is to audit other developers smart contract code this is to reduce the risk of a bug to end up in the final published code. And a bug, when considering the distributed nature of the blockchain can and will most certainly be exploited!
The reason behind this is that smart contracts CAN'T be updated. Once the address is associated with the code you can consider the smart contract published and being in a totally immutable state.

In fact, the action of publishing a smart contract is a transaction itself that is mined by miners and included in a block with a specific address.