In the first part of the cycle “How Blockchain works?” I described the elements that affect the cryptographic security of Blockchain. These include: digital fingerprint (shortcut function), Merkle tree and asymmetric cryptography. In this post I will present the basic components present in Blockchain, and in the last part I will use all the information presented earlier and present a complete description of Blockchain operation.
I must warn you that, as usual, I used the simplifications, but in the descriptions closest to the specifications of the platform Ethereum.
If you feel you need more detailed knowledge, please feel free to contact me directly and/or read the specialist literature.
Apart from the very technical elements contained in P2P, DLT, etc. protocols, Blockchain contains 4 essential components:
On a very general level, it can be said that each Blockchain consists of these components.
All accounts are identified by a unique address (uniqueness is guaranteed by the cryptographic fingerprint function described in previous part).
There are two types of accounts: user accounts and smart contract accounts.
Externally Owned Accounts (EOA)
This is an account similar to a typical bank account. Such accounts have two basic functions:
- They are used to store tokens or crypto-currencies.
- Enables users to be identified by their private key
A user account has two keys: public and private (asymmetric cryptography), which are created when creating a user account.
The address of this account is created from the last 20 bytes of the public key fingerprint for the user account. This address can be compared to the bank account number. Transfer of tokens and crypto-currencies takes place from/to the addresses of user accounts.
The second type of account is the place where the smart contract code is located. Earlier I hadn’t described what smart contracts are before. There are several separate articles that can be devoted to them, but I will try to give you some insight into the subject.
Smart contracts give the block chain the programmable feature. This means that Blockchain can also perform certain operations after a permanent state storage. These operations can also change the state of a string. If we wanted to compare this feature to database systems, smart contract could be compared to stored procedures. Of course, this is a huge simplification. In fact, Blockchain platforms can be used to create full-featured decentralized applications. For the sake of simplicity, I deliberately omit the issue of ‘Turing completeness’, which is used on the platform of the contract programming language.
Returning to the smart contract type account, we must remember that the address of this account is the code of the smart contract, which we can call and execute.
In this case, the account address is built from the fingerprint of content of the contract (source code).
Looking at transactions, you need to realize that Blockchain is a global state machine, and a transaction is the only way to change its status.
Transactions are cryptographically signed messages from an account (user or smart contract) sent over Blockchain and stored in a chain. Transactions spread like a rumor from the node where they originated to the entire network. Nodes transmit transactions to nodes with which they are directly connected. You could say that the transactions make Blockchain move.
In simple terms, the transaction consists of the following elements:
- Nonce – this is a consecutive number of transactions sent from a given account. It affects the order in which transactions are carried out and the consensus mechanism.
- Recipient’s account address – account of the addressee, user or called contract
- Value – number of tokens or crypto-currencies transferred to the recipient’s account
- Data – this is where data for e.g. smart contracts are placed.
Each accepted transaction is recorded in the system.
It is worth noting that operations performed on Blockchain that do not change its state are not transactions. For example, reading your account balance is not a transaction.
Simply put, a block is a set of transactions with additional accompanying data.
The number of transactions in a block and the structure of block data depends on the specific Blockchain platform.
A block consists of a header and a list of transactions.
The block header has the following structure:
- Shortcut function value (digital fingerprint) of the parent (previous) block header
- Time stamp
- The root of the Merkle tree for all transactions in the block. I described the Merkle tree creation algorithm in previous part.
- Level of difficulty – this value refers to the cryptographic puzzle to be solved by the Proof of Work mechanism.
- Nonce – a value enabling verification of the correctness of the cryptographic solution
How is the cryptographic solution verified?
In simple terms, a node that validates a block creates a shortcut from the following elements of the block header to be verified:
- Shortcut function value of the parent block header
- Time stamp
- Merkle’s tree root.
The result should be an abbreviation that meets the requirements of the level of difficulty. The calculation of this abbreviation is very quick and easy to verify. However, the whole problem is to find the right value for the Nonce parameter. This is done while a block is being created and it is a so-called “digging” process.
The following figure shows the blocks connected in a chain.
Fig.1 Linked blocks
Each node stores the current state of Blockchain. Here you can see the redundancy associated with the mechanisms associated with the CAP theory, which I described in previous posts.
From a technical point of view, a Blockchain node is an application that implements a specific Blockchain specification, e.g. GETH (Ethereum node implementation in GO language) and communicates via a peer-to-peer protocol with other Blockchain nodes. The node software can be implemented by different teams and in different programming languages and run on multiple system platforms.
The different nodes work together if they meet the requirements of the reference specification and the standard communication protocols and are, of course, configured accordingly.
Nodes have a local database, usually in key:value format.
Nodes also have implemented mechanisms to enable the launch of smart contracts such as EVM (Ethereum Virtual Machine).
A very important element of the knot is the ability to reach a consensus on the correct state of Blockchain.
I try to simplify every post very much, so as not to write too much at once and not to bore readers, and secondly, I am aware that not every reader has sufficient technical knowledge.
Each of the elements described here is a material for a separate chapter in the book 🙂
If you feel unsatisfied and need to explore a particular area, I encourage you to contact me. In the worst case scenario, I’ll send you back to a specific publication.