12.3.2024
Tutorials
Never miss an important update, event, or early access
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Hello, Sovryn community. We start this section with a foreword from the inspiring book “The Business Blockchain”, which foreshadows the nature of the blockchain’s protagonist, featured in today’s part - the block.
“At its core, the blockchain is a technology that permanently records transactions in a way that cannot be later erased but can only be sequentially updated, in essence keeping a never-ending historical trail. This seemingly simple functional description has gargantuan implications. It is making us rethink the old ways of creating transactions, storing data, and moving assets, and that’s only the beginning.” - WILLIAM MOUGAYAR, THE BUSINESS BLOCKCHAIN
Let’s start with taking a look at what Bitcoin actually looks like, using the BlockCypher blockchain explorer.
1. Click the link above, which brings you to a blockchain explorer.
2. Select BTC by clicking its icon.
3. In the Recent block section on the right, click the top-most block in the Block height column.
4. Blockchain explorers like the one we are using are really handy when tracking transactions or proving a transaction was sent. To use this explorer for tracking, insert the transaction number (generated by the sender) to the search bar in the top right.
“Simply seeing a transaction in a third-party block explorer does not technically “prove” that a transaction was sent. This explorer only shows that the person running the explorer says that the transaction was sent, so you trust that they are honest about this. The only real way to “prove” a transaction was sent is to instruct the person you are trying to prove this to install a full node on their own computer and download and verify the blockchain themselves.” - John Light
Good, we are done here. Keep rocking with the block attributes down below.
A block is the cornerstone that gives the blockchain its use case. Blockchain blocks are basic data recording structures that function as transactional history keepers. Over time, these blocks are organized into a linear sequence to create the structural chronology of a blockchain (a linked list of hash pointers). Blocks hold information about recent, previously-unconfirmed transactions and also a reference to the block that came immediately before it. This chain of IDs, as if the blocks were holding each others’ digital hands, ensures the data integrity of the entire structure.
To modify a block, you have to rebuild starting at that block and redo every block after that until your version of the blockchain is heavier than the version you are trying to replace. Depending on how deep the block you are trying to rebuild is, you will probably run out of money before you can cause a re-org since this process would be complicated, expensive, and time-consuming to do. This way, the older blocks, which are buried deeper into the structure of this chain, become harder to remove or edit. The resilience of a proof-of-work blockchain, one of the basic concepts of blockchain technology, comes from the blockchain’s history and all the “work” that was already put in it, which is obtained gradually over time.
So far, we did a light blockchain exploration and clarified the importance of the blockchain and its data integrity protection mechanism. Before we start with the description of the Bitcoin block attributes, let me say one important thing: Every bit and byte has meaning here, but since this post is not meant to be written in a “university professor” tone, let’s also use a bit of magic :).
Every Bitcoin block consists of the following sections:
Let’s take a look at them one by one:
The first element we will discuss is a technical data structure label, called a “magic number.” The magic number is not a blockchain-native attribute. It is a unique numerical artifact that can help you identify a certain blockchain, data file, or part of another program. “Magic number” is a term that coders and developers use across all programming languages and operating systems instead of using the full length of a classical name. Bitcoin blockchain, for example, uses a special 4-bytes long code starting with a hashtag symbol, such as #x0xD9B4BEF9, which Bitcoin clients use to identify themselves. This combination of characters acts as a name for a specific chain (or any data source).
Magic numbers are also used in computer science for both files and protocols to identify the data type. A program receiving such a file/data structure can check the magic number of the incoming data and immediately recognize what data structure or protocol it is dealing with. Protocols, like Bitcoin, use data structures to talk to each other (e.g. propagating blocks through the network). In interactive communication, nodes check the first bytes of a file or a transaction to identify the type of data structure. The node, in this case, is a blockchain server containing a copy of the current blockchain state that is distributed among all other nodes (each supporters’ computer connected to a blockchain network). By the way, precisely this gossiping between all nodes created the mighty aspect of decentralization.
Example 1 - File Type
The following identificator is used by computers to identify or verify the content of a data file.
78 01 73 0D 62 62 60
This specific digital signature identified a file as the Apple Disk Image file.
“Why is it useful?”; you might be asking. Let me illustrate further: if you see the color green, you don’t need another explanation of what color it is, since you can recognize the color itself. If I could tell you that that color you should be seeing is “zelená,” when you have no knowledge of Czech vocabulary, this label would be useless. However, if we would use a code that acts as the computer and human-readable standard, the magic number, it would be easily translatable to any language of humans of the technological world.
Example 2 - Attribute
#008000 (RGB(0, 128, 0)) = Green color
This description is used in HTML and CSS, as well as in many other programming languages.
The block size defines the maximum amount of data that will fit into a single block. It is theoretically possible for only a few transactions to take up an entire block because of how large (in terms of data) the transactions are. If you recall what a block is from an earlier part, you can imagine that it is like a postal envelope, and the maximum limit this envelope can hold is ten letters. When the envelope is filled with ten letters, the individual transactions are broadcasted to their destination, and miners close the block and add a “stamp” on it, in the form of a human-readable digital signature. If the envelope has been filled up with more than ten letters, the post-office clerk (miners) can refuse to handle this service. In a real post office, for instance, they would tell you something like “this is not a valid postal envelope, and you should send it as a box”. This is a protective concept for blockchain technology. Without this feature, an attacker could flood the network with lots of transactions, potentially bringing the network to a halt.
It is already possible for an attacker to “flood the network with lots of transactions, but in that case, nodes will just ban this particular peer. What is actually risky for Bitcoin transactions is the issue of large blocks that signal that the amount of data in each block increases and reaches the block’s limits. Some fear that a backlog of transactions awaiting inclusion in future blocks will clog up the Bitcoin network, making future blocks consistently full. In this scenario, bitcoin nodes, which form the collective “backbone” that relays transactions across the network, will be overloaded with data. Some transactions could be severely delayed or even rejected altogether. This scenario can be prevented by implementing a “rollup” solution where a massive amount of transactions can be shared with the Bitcoin layer 2 networks such as RSK. I will explain the scalability issue and the rollup implementation in part ten of this series. Now back to the block itself.
When the size of the block is near its limit, the cost of the fee can rise, and the time needed to confirm your transaction can extend. In the blockchain world, it’s necessary to establish a certain balance between the maximal limit the block could handle, fees for a transaction, and the average time needed to confirm transactions.
To enhance Bitcoin transaction capabilities and remove its bottleneck effect, developers came up with a software update solution called SegWit. This soft fork update helped the Bitcoin blockchain by:
and thus diminishing blockchain scalability issues.
The problem of scalability mentioned above means that the more a blockchain is used and adopted, the more transactions it will have; the more transactions it has, the slower it becomes and the higher fees get. However, if you decide to pay a high enough fee for speeding up, your transaction will not confirm any slower. Also, if the blockchain has started becoming congested and you decide not to increase the affiliated fee, your transaction will take longer to confirm. If a transaction is dropped from the mempool then no fees will be paid because the transaction will never be confirmed. The user will have to re-try sending their transaction.
When a crypto token is really popular and people use it a lot, the blockchain of this token starts to be crowded. Each block has many transactions, which leads to a higher value of the block size attribute. SegWit increased the capacity of the blockchain by putting signature data from transactions outside of the original 1MB block (for SegWit-format transactions). Since signatures make up the bulk of the data in a single-input-two-output transaction, this helps save a significant amount of space on transactions. Using Bitcoin as an example, the implementation of SegWit results in an actual block size increase from 1 MB to almost 4 MB.
Misconceptions:
Keep in mind that scalability and transaction times are essential aspects of every blockchain. Regarding this problem, let’s mention additional features some blockchains possess. For some blockchains, it is possible to dynamically change the block size limit to be lower or higher as current traffic dictates. Thanks to this ability, blockchains like Monero can benefit from being less prone to a slowdown during the network traffic peak, at the cost of giving attackers the ability to bloat the blockchain and potentially centralize blockchain validation.
A block header is a tool that gives us additional information about previous blocks in the form of a hashed header of the previous block.
The transaction counter, aka “number of transactions in the block,” is a simple integer (a whole number composed from values of the mathematical scale from “1 to 9”) that shows us the cardinality (number) of transactions this block has at the current time. The size of the transaction counter is from 1 to 9 bytes. You can imagine these transactions as a simple list of the transactions in sequential order. For example, if the transaction counter has a value of 20, the transaction list will store 20 single transactions.
Another package of important information provided by the Header is a block Version and the Hash of the previous block Header (every Header contains info about its ancestors, the next-door neighbor). The current version of the particular block is important information since a blockchain simply ignores versions that are not up to date. The previous hashed block Header is a “codename” provided by a hashing function that gives us a reference to the block added to the chain right before the currently active block. A hash is cryptographically defined as a unique fingerprint that secures the authenticity of the transaction source. Here you have another example of the digital “blocks holding each other’s hands.” Each block contains information about its ancestors, and that’s where the blockchain hierarchy obtains its resilience from.
Now, let’s illustrate this with an easy example.
We know that a blockchain is a linear structure, but imagine a man trying to pull one stone block from the middle of a pyramid in Egypt. The weight of all the upper levels will be severely limiting for such an action. As a reminder from the earlier paragraph, actually, the most recent block is the easiest one to change/remove. To follow on with the pyramid metaphor: imagine you are building a pyramid from the ground up. The last block you put on is the easiest one to remove, right? Because it doesn’t have any weight built on top of it yet. In the same way as somebody who would like to remove a stone block of a pyramid to change its structure, cause damage, or just get inside and steal, the same hidden approach would be chosen by someone trying to recreate part of the blockchain. This approach would most likely be made in secret and without anybody noticing it. In the matter of blockchain fraud, the moment when this “someone” would be willing to reveal their privately prepared version of the chain (and you know about this from the 51% Attack episode) would be once they are sure that their chain is heavy enough to overtake the current chain. This would instantly cause a blockchain reorganization. Depending on the length of the reorg, it could definitely get people’s attention!
The next part of the Header is another hash. This time, the hash carries info about the root of all transactions that are present in this block. This hash is called the Merkle (tree) Root. Blockchains are these Merkle trees, and just like every other tree on Earth, a Merkle tree has its root. Hash Merkle root is a root hash of such a Merkle tree consisting of the transactions in this block. We can look at all transactions in our current block, put them into the Merkle tree structure, and then take a root value and put it in hashed form into our Header. Then each transaction in the block is bound to this root hash. It’s like a signature and a timestamp in terms of transaction execution information. This proves that the transaction happened to take place in this block, not elsewhere.
The time information has 4 bytes and provides us with information about the current timestamp. A timestamp is a piece of temporal information regarding an event that is recorded by the computer and then stored as a log or metadata. Any event or activity could have a timestamp recorded, depending on the needs of the user or the capabilities of the process creating the timestamp.
The target represents another 4 bytes of the block we are diving in. It is a variable that tells us information about the mining difficulty of this current block that will be explained in the following paragraphs.
The last piece of this puzzle is a nonce. Speaking about the nonces of the block, do you remember what miners actually do? They take a hash of a Merkle root of the particular block and try to guess a correct nonce, which they have to append to a block before they submit this block to the blockchain. This nonce is something like glue that holds the block together. It goes like this:
Miners start to guess the correct form of the nonce from zero. So the nonce is equal to the value of zero. They will append it to the hash of the Merkle root, hash it together so they obtain a special alphanumeric code, and compare this code with the block’s target. If the hash we obtained a few seconds ago has a lower value than the current target, we are done with guessing (mining) and they successfully solve the block’s puzzle. They are rewarded for their unique solution by obtaining tokens of the block they just mined. On the other hand, if this hash has a higher value than our comparative target, they need to guess that nonce value again, increment the value of zero by one, append this to the current Merkle root, calculate the hash again and compare this with the target. If this hash is still higher than our target, well, they need to keep guessing until they find a proper match.
As long as a mined block satisfies all consensus rules, including the difficulty target requirements, it is considered valid. In a case where two valid adepts were mined nearby simultaneously, and both fulfill the current difficulty target, the one that was first seen by a majority of other miners will likely be the one that ends up getting built upon.
Also bear in mind that the hash we have obtained with a nonce value equal to zero will look completely different against the hash that has been created with a nonce containing a value of 1.
Let’s summarize this by imagining the following process:
The lower the target’s value is, the more difficult it is to find a correct nonce value and make this puzzle work. And now…let’s just never talk about mining again, deal? :)
Congratulations. You made the seventh step in becoming a blockchain expert.
This series is mirrored on the Sovryn Wiki here. It is also published on Hackernoon.
See you later in episode 8, where we will investigate Smart Contracts!
Until then, stay Sovryn!
