This article will give you an overview of the blockchain basics, transactions, and blocks.
Blockchain technology enables us to write programs without having to think about the details of the underlying communication infrastructure.
However, just to be aware of some of the keywords which are commonly used when studying the infrastructure, we’ll name just a few among others (borrowed from the Solidity documentation):
- elliptic-curve cryptography,
- peer-to-peer network.
Although it’s interesting to see how these technologies work “under the blockchain’s hood”, the beneficial fact is that you don’t have to be closely familiar with them. You can just implicitly utilize them and maybe even forget they’re there. However, they represent some of the key elements which make up Web3.
💡 Note: Here, we need to establish a firm distinction between the terms Web3 in the blockchain context that is the subject of our interest when discussing Solidity, and the Semantic Web, sometimes known as Web 3.0, which is an extension of the World Wide Web, intended to make Internet data machine-readable.
One of the main roles of a blockchain is to preserve the data and make it temper-resistant. In that sense, we can easily consider a blockchain as a globally shared, transactional database.
A blockchain network is globally shared because any party in the network can access and read its contents.
It is transactional because any change to the blockchain has to be accepted by almost all, or at least the majority of other members, depending on the blockchain implementation.
In database theory and practice having a transactional property means two things: the change to the database is either applied completely or not at all (see here); no other transaction can modify the effect of a transaction being executed.
There is also a strong security property that is inherent in the way how blockchain works: each new block header includes the hash of the previous block.
To alter a block in a blockchain, an attacker would have to re-mine the targeted block and all the following blocks, therefore creating a chain fork.
Also, an attacker would need to invest more total work than was invested in the original chain segment to get his chain fork accepted by the rest of the network (source).
The latter would require immense computing power and energy, making the entire effort unfeasible in theory.
However, there have been successful attacks on blockchain networks, mostly due to the smaller scale of a particular network, where a fraudulent consensus (the verification process) was less difficult to fabricate, block creation errors, or insufficient security measures (source).
An example to the story above is already given in part by the example we did in the previous article: a smart contract for (simulated) currency transfer between any two parties.
There was a list of accounts holding balances in a cryptocurrency, Wei, and our smart contract supported transfers of a given amount of currency from the sender to the receiver.
What’s important in the context of such transactions is that the same amount of currency should always be “simultaneously” deducted from the sender’s account and added to the receiver’s account.
What we mean by “simultaneously” is not a matter of happening at the same moment, but happening with the same, but the opposite consequence, i.e. if the amount gets successfully deducted from the sender’s account, it has to be added to the receiver’s account.
If an error occurs after the amount is decreased from the sender’s account, but before the amount is added to the receiver’s account, the operation should revert to the smart contract’s previous state, as it was before the transaction started.
This way, the blockchain behaves in a consistent, transactional manner and warrants that the transaction will be done entirely or not at all.
In the context of everything said so far, with our subcurrency example in mind, we may ask ourselves:
💬 Question: How would we enable an account owner to transfer the currency only from the account in his ownership?
The answer to the question is relatively simple:
💡 Answer: A transaction always bears the sender’s cryptographic signature, which serves as a seal in granting access to precisely defined modifications of (operations on) the database, such as currency transfer from the account owner originally holding the currency, to the account owner – receiver of the currency.
There is no story about blockchain without actually mentioning the block itself. We will definitively return to talk about a block from some other angles, but with a security perspective in mind, we will focus on overcoming a significant obstacle known (in Bitcoin terms) a “double-spend attack” (source).
Some paragraphs ago, we mentioned a blockchain attack implying the majority of the network members’ acceptance, popularly known as the “51% attack”.
Let’s assume there are two transactions in the blockchain network, and each of them attempts to transfer all the account’s currency to another account, i.e. they will both attempt to empty the account.
Since there can be only one accepted, confirmed transaction (in contrast to two or more possible unconfirmed transactions), the transaction that gets confirmed first will end up bundled in a block. It is not under our control or, for that matter, not even a subject of our concern which block will be the first one.
What matters is that the second block will be rejected and the contention between the blocks/transactions will be resolved automatically, and the likelihood of the double-spend attack problem will decrease with each additional confirmation (source).
Blocks are sequentially added to a blockchain, ordered by the time of their arrival. Adding a block to the blockchain is mostly done in regular intervals, which last about 17 seconds for the Ethereum network.
Nonetheless, the blockchain tip can sometimes be reverted during the order selection mechanism. In that case, a confirmed block will get discarded and become a stale block, and the stale block’s successor blocks just get returned to the memory pool.
💡 Note: discarded or stale blocks are popularly and wrongly called orphan blocks. (source)
For block reversal to happen, two conditions should occur.
(1) First, multiple blocks should get created from the same parent block P simultaneously (by different miners) and get confirmed by the network, forming a fork with multiple subchains/branches at the tip (block) P of the blockchain.
As there are multiple successor block candidates (e.g. we will assume three blocks, A, B, and C), each block has an equal chance of becoming a permanent part of the blockchain.
Because blocks propagate through the blockchain network differently, miners will receive one of the blocks (A, B, or C) before the other blocks and start mining a new block on the block they received first.
(2) Second, one of the miners will mine and broadcast a new block, e.g. C1 to the network before the other miners mine blocks A1 or B1 (these don’t exist as yet).
Since the fastest miner first received block C and then produced C1, it will extend the branch P-C, effectively making the branch P-C-C1 the longest one. Once the network detects there is a chain longer than the chains P-A and P-B, it will disqualify the candidate blocks A and B as stale blocks, thus resolving the contention.
All the miners who chose a different blockchain from the fork, e.g. P-A or P-B, and started building their blockchains on them, will experience a block reversal, as their chains will also get updated by the network with the blockchain P-C-C1 as the longest one.
The blockchain tip reversal gets less likely to happen as more blocks are confirmed and added to the blockchain. A common number of confirmations after we can be virtually certain that our block became a permanent part of a blockchain is six confirmations (source).
In this article, we first shortly made a short detour (sorry about that) to a missing part about Solidity events, and then boldly stepped into the direction of blockchain basics, transactions, and blocks.
First, we made friends with an event listener example based on
Second, we glanced at the blockchain basics. You already know the works: some basic terms, dry notes, etc. It’s just a scratch, really.
Third, we learned about how blockchain treats transactions and how it makes them feel secure, shared and cared for. That’s why we mentioned some properties that make blockchain look like a database.
Fourth, we went into some light details on what a block is, what is its role in the blockchain ecosystem and what are some of the risks present in a blockchain network.
This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):
Solidity is the programming language of the future.
It gives you the rare and sought-after superpower to program against the “Internet Computer”, i.e., against decentralized Blockchains such as Ethereum, Binance Smart Chain, Ethereum Classic, Tron, and Avalanche – to mention just a few Blockchain infrastructures that support Solidity.
In particular, Solidity allows you to create smart contracts, i.e., pieces of code that automatically execute on specific conditions in a completely decentralized environment. For example, smart contracts empower you to create your own decentralized autonomous organizations (DAOs) that run on Blockchains without being subject to centralized control.
NFTs, DeFi, DAOs, and Blockchain-based games are all based on smart contracts.
This course is a simple, low-friction introduction to creating your first smart contract using the Remix IDE on the Ethereum testnet – without fluff, significant upfront costs to purchase ETH, or unnecessary complexity.
I’m an experienced computer science engineer and technology enthusiast dedicated to understanding how the world works and using my knowledge and ability to advance it. I’m focused on becoming an expert in Solidity and crypto technology, with a passion for coding, learning, and contributing to the Finxter mission of increasing the collective intelligence of humanity.