Skip to main content

Cryptography in Distributed Ledger Technologies

In this section, learn about the cryptography that's used in distributed ledger technologies and why it is used.

Overview​

  • 3.7 Hash Functions
  • 3.8 DLT Accounts and Digital Signatures
  • 3.9 Public Key Infrastructure in DLT
  • 3.10 Create your First DLT transactions

[3.7] Hash Functions​

Hash functions are critical to distributed ledger technology, as without hashing, these technologies would not work.

For instance, using Bitcoin as an example, hash functions are used for the following:

  1. Creating a unique identifier of a transaction.
  2. Generating a Bitcoin address from a public key. Specifically a Bitcoin address is generated by taking the RIPEMD160 hash of the SHA256 hash of the public key. RIPEMD160 allows shortening the length of the address, while a combination of hashing techniques helps providing more resilience regarding different attacks.
  3. Establishing a reference to all of the transactions of a block via one string in a block header (a block header can be viewed as the block’s meta data). This reference is established by organising the block’s transactions into a Merkle tree, and adding the Merkle tree root to a block header.
  4. Connecting a block to a previous block. This is implemented by making sure each block header includes the hash of the previous block’s header.
  5. Verifying blocks have a sufficient proof-of-work. Bitcoin’s consensus protocol requires a certain amount of work to be conducted in the production of each block. To do so, the hash of each block header is checked to make sure that it less than a certain number. The lower the number, the more work is required.

Hash Values in Block Headers

DLTs use hash functions in block headers not just to link to previous block(s), but hash functions are also used to condense information into the block header about things such as the transactions contained in this block, the current ledger state and transaction processing information (receipts).

Let’s go through an example of the Bitcoin block header parameters:

  • Previous Block Hash: This is the link to the previous block. It is the SHA256 hash of the SHA256 hash of the previous block header.
  • Time: The block time is a Unix epoch timestamp regarding when the header was created. For Bitcoin, this timestamp must be strictly greater than the median time of the previous 11 blocks and Bitcoin nodes will not accept blocks with times more than two hours in the future according to their local clock.
  • Merkle Tree Root: This is the Merkle tree root of all the transactions of the block when they are organised into a Merkle tree structure. Discussed further below.
  • Nonce: This is an arbitrary number miners change to modify the block header’s hash value, in order to produce a hash value less than or equal to the target threshold.
  • nBits: An encoded version of the target threshold that this block header’s hash must be less than or equal to.
  • Version: The block version number, which indicates the set of block validation rules the creator of this block has followed.

As you can see, even though a Bitcoin block header has only six parameters, two of those parameters (Previous Block Hash, Merkle Tree Root) are hashes, whereas two more parameters (Nonce, nBits) relate to the block hash. This should show that hashing is very important in DLTs.

Merkle Tree Root in Block Header Example

This example will show how the transactions of the block link to the Merkle tree root parameter in the block header.

Let’s look at an example with four transactions (T1, T2, T3 and T4) in this block.

Bitcoin Block Header Diagram 1 (See here)

Now we will work towards generating the Merkle tree root of the block header. To do so, the first step is to hash these transactions individually, where H1 is the hash of transaction T1, etc.

Bitcoin Block Header Diagram 2 (See here)

Then, each pair of transactions are hashed together (where the input to the hash function is the two previous hash values, e.g. the input that generated hash value H12 is hash values H1 and H2).

Bitcoin Block Header Diagram 3 (See here)

Now, we continue hashing pairs of transactions until we reach the root of the Merkle tree. The final value generated will be the same value as the Merkle Tree Root contained in the block header (as long as all data is correct).

Bitcoin Block Header Diagram 4 (See here)

Referencing Files

Distributed ledgers are not designed to store large pieces of data, which can instead be stored locally or in a distributed database such as IPFS. A fairly common use of hash functions in DLTs is to place a hash of a large file in a transaction. This hash value can directly link to the file’s storage location (if the file is stored in a hash addressable database such as IPFS). Or this hash value can be used to locally check that a received file matches the one referenced on the blockchain.

A hash reference added to a DLT network provides timestamp evidence. Due to the properties of the hash function used, the file must have existed when the transaction that included the hash was accepted by the DLT network.

But a hash reference added to a DLT network does not give proof of data availability. For instance, the locally stored copy of the file may have been overwritten (and any change to the file data will lead to a different hash value). Or the file could have been removed from a distributed database.

[3.8] DLT Accounts and Digital Signatures​

To broadcast a transaction to update a distributed ledger, firstly a DLT account is needed and secondly a digital signature needs to be created in order to prove that this transaction has been authorised by the account holder.

DLT Accounts

Each DLT account consists of primarily a public and private key pair generated for use by an asymmetric encryption algorithm. The public key creates a unique identifier of this account. But as public keys are long, it is better to find a more appropriate reference.

In permissionless DLT networks, where the owners of each account are not known, hashing the public key leads to a condensed account reference known as an address. For instance, an Ethereum address is appended with 0x and is followed with the last 20 bytes (in hexadecimal format) of the keccak-256 hash of the public key. In permissioned DLT networks, the owners of each account are more likely to be known, so they can have more personal account references, such as Alice Smith or Bob Jones. To authorise DLT accounts in a permissioned DLT network, a certificate maybe required, see section 3.9.

Additionally, A DLT account can be stored in different locations. For instance it can be saved on a local machine in an encrypted format. It can be saved on a DLT node (make sure you trust who is running the node!). It can be saved in a hardware security model mentioned in section 3.1. It can even be saved on paper. Either way, your DLT account will need to be accessible by a digital signing algorithm when it is required to sign transactions.

DLT Account Signing Algorithms

The most common signature algorithm used in DLTs is the Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve. This signature algorithm was introduced to the world through the invention of Bitcoin and therefore has been widely reused in other permissionless DLT networks.

The secp256k1 curve is in the category of curves with small discriminants. Whereas there have been no known breaks of curves will small discriminants, the secp256k1 curve is not rated as a safe curve in terms of the criteria identified here.

One popular DLT signing algorithm that is rated as safe by the same source is the Edwards-curve Digital Signature Algorithm (EdDSA) using curve 25519 (also known as ed25519). Nowadays some permissionless DLT networks, such as Cardano and Stellar, support only EdDSA with curve 25519. Whereas other permissionless DLT networks, such as Polkadot and the XRP Ledger, support both EdDSA with curve 25519 and ECDSA with the secp256k1 curve.

The final popular signing algorithm in DLT is ECDSA with the P-256 curve (also known as secp256r1). This is used in permissioned DLTs such as Corda and Fabric, providing them both with National Institute of Standards and Technology (NIST) approved cryptography. NIST approved cryptography is required for any technology implementation regarding the US government.

Transaction Signing

The DLT account’s private key is used to sign a transaction using a DLT specific digital signing algorithm (such as the ones described above). This signed transaction is broadcast to a DLT node, who in turn gossips it to other DLT nodes. The public key (and possibly certificate) of the DLT account is checked by the DLT nodes to verify that a transaction is authentic. If the transaction passes validation checks, it will be eventually accepted and processed by the DLT network.

[3.9] Public Key Infrastructure in DLT​

Usages for Public Key Infrastructure

The permissionless DLT networks do not force the use of a Public Key Infrastructure (PKI) because this would go against the open permissionless nature of these networks.

Alternatively, permissioned DLT networks may use a Public Key Infrastructure (PKI) to manage the identity of the participants in DLTs. The key idea is that each organisation belonging to the network can have a certificate authority that can generate cryptographic material (e.g., certificates containing public keys) for each of its parties.

Hyperledger Fabric (Fabric) is a widely used permissioned DLT that has the most advanced PKI for identity management.

Hyperledger Fabric’s Public Key Infrastructure

Fabric utilises the concept of the membership service provider (MSP), which manages the process of issuing certificates, validating certificates, and user authentication. Users can rely on the MSP of their organization (which have a unique ID) to validate identities, generate signatures and sign messages. Each Fabric network may have one or more MSPs. MSP content is generated by the Hyperledger Fabric Certificate Authority.

Cryptographic Materials Generated for an Membership Service Provider

Each MSP includes a list of self-signed certificates that constitute the root of trust (who is the ultimate party that is trusted regarding identity management), a list of administrator certificates (parties that can change the configuration of the MSP), node certificates, TLS certificates and others. TLS certificates are used when nodes on the network need to establish secure connections to client applications and other nodes.

MSPs generate identities encoded in X.509 certificates (with OpenSSL or with a Fabric-based tool called cryptogen). Those certificates include with which organisation is the identity related with, and arbitrary attributes (that can be retrieved by smart contracts). Different identities include:

A. Clients: who are the entities that transact on the network;

B. Administrators: who are the entities that handle administrative tasks such as installing chaincode;

C. Peer Nodes: who are responsible for endorsing and broadcasting transactions;

D. Orderer nodes: who are responsible for agreeing on the order of the transactions in the Fabric network.

Summary

  1. Using PKI on a permissioned blockchain is a complex process. Administrators need to be skilled in networks,distributed systems, and cryptography.
  2. Every organization in Fabric has an MSP that generates crypto material for their clients and nodes, allowing them to communicate with other nodes and clients in the network.

[3.10] Create your First DLT transactions​

Note that the external exercise linked to in this page is a non-essential element of the course. It is provided for your benefit to build your blockchain developer skills. FutureLearn advises you that interacting with the content may require or result in personal data transfer to this external website; FutureLearn recommend that you check external websites privacy policies before use.

Faucets

For permissionless DLT networks, where transaction fees are required, you will also need a balance in order to get your transaction accepted. For mainnets you will have to buy the necessary value from an exchange. But as this course is only using testnets, you will be able to use a faucet. These faucets give out free cryptocurrency to help users test their applications before possibly moving them to mainnet. The process of using a faucet will be described in the exercise step by step instructions.

Creating Transactions via Overledger

In our next example, we will use Overledger to create transactions for the Ethereum Ropsten testnet, the XRP Ledger testnet and the Bitcoin testnet.

For this task, go to the seventh exercise link on our Github repository in a new tab and follow the step by step instructions.