Are you interested in learning about blockchain architecture? This article will explain in an easy way and in plain words how does blockchain architecture work.
Blockchain systems can seem complex; however, they can be easily understood by examining each component technology individually. At a high level, blockchains utilize well-known computer science mechanisms (linked lists, distributed networking) as well as cryptographic primitives (hashing, digital signatures, public/private keys) mixed with financial concepts (such as ledgers).
Blockchain Architecture – Hashes
An important component of the blockchain technology is the use of cryptographic hash functions for many operations, such as hashing the content of a block. Hashing is a method of calculating a relatively unique fixed-size output (called a message digest, or just digest) for an input of nearly any size (e.g., a file, some text, or an image).
Even the smallest change of input (e.g., a single bit) will result in a completely different output digest. Table 1 shows simple examples of this. Hash algorithms are designed to be one-way (known as being preimage resistant): it is computationally infeasible to find any input that maps to any pre-specified output.
If a particular output is desired, many inputs must be tried by passing them through the hash function until an input is found that produces the desired result. Hash algorithms are also designed to be collision resistant (known as second preimage resistant): it is computationally infeasible to find two or more inputs that produce the same output.
A hashing algorithm used in many blockchain technologies is the Secure Hash Algorithm (SHA) with an output size of 256 bits (SHA-256). Many computers support this algorithm in hardware, making it fast to compute.
This algorithm has an output of 32 (8-bit) characters (shown below, in Table 1, as a 64-character hexadecimal string), meaning that there are 2256 ≈ 1077, or
115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possible digest values. The algorithm for SHA-256, as well as others, is specified in Federal
Information Processing Standard (FIPS) 180-4. The NIST Secure Hashing website contains FIPS specifications for all NIST-approved hashing algorithms.
Since there is an extremely large number of possible input values and a finite number of possible
output digest values, it is possible to have a collision where hash(x) = hash(y) (i.e., the hash of two different inputs produces the same digest).
However, it is highly unlikely for any such input x and y that produce the same digest to both be valid in the context of the blockchain system (in this case, both being valid blockchain transactions) as well as be computed reasonably close to each other in time. The hashing algorithm used (SHA-256) is said to be collision resistant, since to find a collision in SHA-256, one would have to execute the algorithm, on average, about 2128 times. Blockchain technologies take a list of transactions and create a hash “fingerprint” (the digest is the fingerprint) for the list. Anyone with the same list of transactions can generate the exact same fingerprint. If a single value in a transaction within the list changes, the digest for that block changes, making it easy to discover even minor one bit changes.
Blockchain Architecture – Transactions
A transaction is a recording of a transfer of assets (digital currency, units of inventory, etc.) between parties. An analog to this would be a record in a checking account for each time money was deposited or withdrawn. Table 2 shows a notional example of a transaction. Each block in a blockchain contains multiple transactions. A single transaction typically requires at least the following information fields, but can contain more:
- Amount – The total amount of the digital asset to transfer.
- Inputs – A list of the digital assets to be transferred (their total value equals the amount). Note that each digital asset is uniquely identified and may have different values from other assets. However, assets cannot be added or removed from existing digital assets. Instead, digital assets can be split into multiple new digital assets (each with lesser value) or combined to form fewer new digital assets (each with a correspondingly greater value).
- Outputs – The accounts that will be the recipients of the digital assets. Each output specifies the value to be transferred to the new owner(s), the identity of the new owner(s), and a set of conditions the new owners must meet to receive that value. If the digital assets provided are more than required, the extra funds are returned to the sender (this is a mechanism to “make change”).
- Transaction ID/Hash – A unique identifier for each transaction. Some blockchains use an ID, and others take a hash of the specific transaction as a unique identifier.
Determining the validity of a transaction is important. Just because someone claims a transaction took place does not mean it really happened. Transactions are signed and can be verified with public/private key pairs at any time.
A fundamental technology utilized by blockchain technologies is asymmetric-key cryptography (also referred to as public/private key cryptography). Asymmetric-key cryptography uses a pair of keys: a public key and a private key that are mathematically related to each other.
The public key may be made public without reducing the security of the process, but the private key must remain secret if the data is to retain its cryptographic protection.
Even though there is a relationship between the two keys, the private key cannot efficiently be determined based on knowledge of the public key.
Asymmetric key cryptography uses the different keys of the key pair for specific functions, dependent on which service is to be provided. For example, when digitally signing data, the cryptographic algorithm utilizes the private key to sign. The signature can then be verified using the corresponding public key.
Asymmetric-Key Cryptography Utilization in Blockchain Systems:
- Private keys are used to digitally sign transactions.
- Public keys are used to derive addresses, allowing for a one-to-many approach for pseudonymity (one public key pair can yield multiple addresses; in some cases, multiple public key pairs are utilized to create multiple addresses).
- Public keys are used to verify signatures generated with private keys.
- Asymmetric-key cryptography provides the ability to verify that the user transferring value to another user is in possession of the private key capable of signing the value.
Addresses and Address Derivation
A user’s address is a short, alphanumeric string derived from the user’s public key using a hash function, along with some additional data (used to detect errors).
Addresses are used to send and receive digital assets. Most blockchain systems make use of addresses as the “to” and “from” endpoints in a transaction. Addresses are shorter than the public keys and are not secret.
To generate an address, it typically means taking a public key, hashing it, and converting the hash to text:
public key → hash function → address
Users can generate as many private/public key pairs, and therefore addresses as desired, allowing for a varying degree of pseudo-anonymity. Addresses act as the public-facing “identity” on a blockchain for a user, and oftentimes an address will be converted into a QR code for easier use.
When a blockchain distributes digital assets, it does so by assigning them to an address. To spend that digital asset, a user must prove possession of the address’s corresponding private key. By digitally signing a transaction with the private key, the transaction can be verified with the public key.
Private Key Storage
Most users of a blockchain system do not record their private keys manually, rather, software commonly called a wallet securely stores them. The wallet can store private keys, public keys, and associated addresses. The wallet software can also calculate the total number of assets a user may have.
A private key is usually generated using a secure random function, meaning that reconstructing it is difficult, if not impossible. If a user loses a private key, then any asset associated with that key is lost. If a private key is stolen, the attacker will have full access to all assets controlled by that private key.
The security of private keys is so important that many users use special secure hardware to store it.
459 Private key storage is an extremely important aspect of blockchain technology.
When it is reported in the news that “Bitcoin was stolen from…”, it almost certainly means the private keys were found and used to sign a transaction sending the money to a new account, not that the system was compromised. Note that because blockchain data cannot generally be changed, once a criminal steals a private key and publicly moves the associated funds to another account, it cannot be undone.
Blockchain Architecture – Ledgers
A ledger is a collection of transactions. Throughout history, pen and paper ledgers have been used to keep track of the exchange of goods and services.
More recently, ledgers have been stored digitally, often in large databases owned and operated solely by centralized “trusted” third parties on behalf of a community of users (i.e., the third party is the owner of the ledger).
Centralized ledgers may have shortcomings, such as:
- They may be lost or destroyed; a user must trust that the owner is properly backing up the system.
- The transactions may not be valid; a user must trust that the owner is validating each received transaction.
- The transaction list may not be complete; a user must trust that the owner is including all valid transactions that have been received.
- The transaction data may have been altered; a user must trust that the owner is not altering past transactions.
Of course, it is in the best interest of any centralized ledger to backup data, validate transactions, include all valid transactions, and not to alter history.
A ledger implemented using a blockchain can mitigate these issues through the use of a distributed consensus mechanism. One aspect of this is that the blockchain ledger will be copied and distributed amongst every node within the system. Figure 1 depicts a simple network with four nodes, where each has a copy of a ledger of transactions.
New transactions are submitted to a node (as seen in Figure 2), which will then alert the rest of the network that a new transaction has arrived (as seen in Figure 3).
At this point, it is a pending transaction, and not included in a block within the ledger.
Eventually, a node will include this new transaction within a block and complete the system’s required consensus method (explained later). This new block will be distributed across the system and all ledgers will be updated to include the new transaction (as seen in Figure 4).
Whenever new users join the system, they receive a full copy of the blockchain, making loss or destruction of the ledger difficult. All transactions are stored in blocks within the blockchain (transactions discussed in Section 2.2).
Blockchain Architecture – Blocks
Users may submit candidate transactions to the ledger by sending these transactions to some of the nodes participating in the blockchain. Submitted transactions are propagated to the other nodes in the network (but this by itself does not include the transaction in the blockchain).
The distributed transactions then wait in a queue, or transaction pool, until they are added to the blockchain by a mining node.
Mining nodes are the subset of nodes that maintain the blockchain by publishing new blocks.
Transaction are added to the blockchain when a mining node publishes a block. A block contains a set of validated transactions. ‘Validity’ is ensured by checking that the providers of funds in each transaction (listed in the transaction’s ‘input’ values) have each cryptographically signed the transaction.
This verifies that the providers of funds for a transaction had access to the private key which could sign over the available funds. The other mining nodes will check the validity of all transactions in a published block and will not accept a block if it contains any invalid transactions.
After creation, each block is hashed thereby creating a digest that represents the block. The change of even a single bit in the block would completely change the hash value. The block’s hash digest is used to help protect the block from change since all nodes will have a copy of the block’s hash and can then check to make sure that the block has not been changed.
The actual construction of a block is slightly more complicated. The data fields comprising a block typically consist of the following:
- The block number, also known as block height
- The current block hash value
- The previous block hash value
- The Merkle tree root hash (defined below)
- A timestamp
- The size of the block
- The nonce value, which is a number manipulated by the mining node to solve the hash puzzle that gives them the right to publish the block (see Section 4.1 for details)
- A list of transactions included within the block
Rather than storing the hash of every transaction within the header of a block, a data structure known as a Merkle tree is utilized. A Merkle tree combines the hash values of data together until there is a singular root (a Merkle tree root hash). The root is an efficient mechanism used to summarize the transactions in a block and verify the presence of a transaction within a block.
This structure ensures that the data sent in a distributed network is valid, since any alteration to the underlying data would be detected and can be discarded. Figure 5 shows an example of a Merkle tree:
- The bottom row represents the data to be summarized, in the case of blockchains this is the transaction data.
- The second to bottom row shows that data being hashed.
- The hashed data from the second row is then combined and then hashed on the third to bottom row.
- Finally, the top row shows the Root hash, which combines and hashes H4 and H5. The root hash is a hash of all previous combinations and hashes made.
Figure 6 shows the relationship between a Merkle tree and a block. The bottom row of the tree contains blockchain transactions Tx0 through Tx3. The Merkle root is stored within the block header.
The entire block header is hashed; the block header hash value is stored within the block itself, as well as within in the next block, and this helps provide the immutability of transactions since the Merkle root hash will not match if any change is made to the transactions.
Blocks are chained together through each block containing the hash of the previous block’s header, thus forming the blockchain. If a previously published block were changed, it would have a different hash. This in turn would cause all subsequent blocks to also have different hashes since they include the hash of the previous block. This makes it possible to easily detect and reject any changes to previously published blocks. Figure 7 shows a generic chain of blocks.