A conventional blockchain, say Ethereum, can be understood thus:

Imagine a supercomputer that has all the code and can execute any number of requests simultaneously from a community that has no central leadership. [In technical terms, this is known as decentralised autonomous organisation or DAO]

Now let us introduce the first complexity – if this supercomputer is really a network of numerous individual community members who provide the resource, and the members expect to be paid for their services.

This leads us to the second complexity -the user of this service must pay the provider using an unique / native token. In this community the token is called Ether (ETH).

The next rule is that any one is free to enter or exit the community – no permission need be sought – and there is no restriction on the extent of participation.

One can participate by either being a provider of resources or by being a user of the resources. Each such provider of resources is a small part of the vast network of computers that this community is.

In the Ethereum universe, each computer that this provider brings into the network is called the Ethereum Virtual Machine (EVM). So, the leaderless community that we talked of in the first para is this network of EVMs owned by those first group of participants in this community.

Each of this EVM (colloquially called nodes) stores up to date duplicate copies of the same master. This master contains all information required to operate – that is, the code, transaction, token holdings etc. The master is free to everyone who is willing to participate but the member must invest in the hardware and the resources like electricity needed to run the hardware. How do they get compensated for these expenses?

This is where the second set of participants contribute. The second set consists of people who have requests for services and are willing to pay for it.

What are these requests? A request is a transaction involving a transfer of ETH from one account to another. For a request to be accepted or a transaction to happen any one EVM / Node from the first set of participants (called miner) has to validate the transaction.

To validate the transaction, he asks the following questions:

Does the member making the request has the required number of tokens to pay for the transaction?

Is the request feasible, given the resources of the network?

Does this member have permission to make such a request?

For any random validator (miner) to answer these questions, all information must be stored with all members in the system.

What is a transaction?

A transaction is a transfer of ether from one account to another or in some cases a call to functions in various smart contracts on the EVM. For the moment we will ignore the “call to functions in various smart contracts” as it requires more knowledge of the blockchain.

The focus then shifts to what is an Account. Though an Account means nothing more than what a normal person (as User) understands of it, in technical parlance it is an Externally Owned Account (EAO).

An EAO can receive, store and send ETH (the native crypto currency on the Ethereum platform) as well as interact with “smart contracts stored in tokens.”

Things to remember here:

One needs an account to submit a transaction on the Ethereum network. (We will use the colloquial “account” rather than the technically correct EOA).

Accounts can initiate transactions to interact with “Smart Contracts” or with other accounts.

Transactions between accounts can only be requests to transfer funds (ETH); and

Last but most important, an account is not a wallet, and a wallet is not an account. [We will visit this later.]

The steps involved in a transaction are:

The transaction is assigned a unique code known as Transaction Hash (also called as TxID, TxHash,….) An illustration of a transaction hash: 0x3242ecd0b79da7edb05aaf278b1526ce157678e6592ff5ec2ceefc87d177a147 The transaction is broadcast over the network to all nodes.

If valid, the transaction is added to a pool of other pending transactions awaiting execution. This pool of pending transaction is called as “MemPool.”

Miners select pending transactions from this pool to form a block of transactions. This block is at this stage a draft and needs to be confirmed.

Miners then race to solve a complex equation – a proof of work (PoW) puzzle – to get the privilege of adding and confirming a new block to the chain. It is needless to add here that to solve this puzzle the miner requires enormous computing power.

Once the puzzle is solved, the winning miner is compensated with a block reward and at the same time the block is broadcast to the network. This is when the transactions that are part of this block are executed.

To sum up, to successfully complete your transaction:

The transaction must be valid.

The transaction must be selected by a successful miner. [A miner is successful if he solves the complex puzzle.]

Most important, the transaction’s total computational complexity must not exceed its designated gas limit. [The limit is set by the person initiating the transaction].