/Blockchain Series #3: Blockchain structure and transactions

Blockchain Series #3: Blockchain structure and transactions

After having introduced some general terminology in the last part, we talk about the structure of a block(chain) and how transactions on a blockchain looks like.

Transactions in a blockchain network can entail the transfer of any digital asset, depend-ing on the specifications of the respective blockchain protocol. Transactions are secured via a pair of keys, a public one, which is visible to the network and a private one, that is kept by the node. The keys are cryptographically linked, which enables the counterparty in a transaction to verify the signature of a transaction by just looking at the public key provided to him by the counterparty. Digital signatures, thus, ensure that a message was generated by the signer. Upon successful verification, a signature is non-repudiable, i.e. the signature is tied to the particular transaction and the signer cannot deny having signed the transaction. Before including a transaction into a block, the node has to ensure that it is actually valid. This is done by verifying whether the transaction meets the preconditions that the blockchain protocol sets, for example whether the signer of the transaction actually has the asset it claims to own. Before discussing how the verified transactions get included into a block and added onto a blockchain, the structure of the latter needs to be clarified.

As illustrated in the figure above, a blockchain is comprised of many blocks, each of which contains information about transactions, a hash pointer (prev hash) and a so-called nonce. In each block, verified transactions are bundled together using a hierarchical system of hash functions (Merkle tree). The Merkle tree outputs a single hash, which is a 256-bit digest of all transactions that are contained in a block (Merkle root). The hash pointer references to the block header of the previous block. The block header contains all the information of a block. It is the hash value resulting from the block’s Merkle root, the hash pointer of the preceding block and the nonce. The hash pointer of the previous block, again is a digest of all the input data of its preceding block. Being reminded that every hash is unique and the smallest change in any input field leads to a complete different hash value, this means that chaining blocks together by always taking the hash value of the previous block as an input for the block header (which is also a hash) renders the chain immutable by design. Attempting to tamper with any single transaction in the chain retroactively would be trivial to observe, as the block header of the respective block would change, and therewith, all subsequent blocks since every block contains the input of its preceding block in the form of the hash pointer. Chaining together the blocks with cryptographic mechanisms thereby makes the blockchain tamper-proof. A question that has not been answered yet is, why every block contains another input, the nonce. This will also lead us to the main invention of the blockchain technology, the distributed consenses, proof-of-work being the most well-known one. More on that in part #4 of the series.