The master trick by Satoshi Nakamoto was not to design novel cryptographic primitives, but to combine a list of basic ingredients to solve a single problem that has plagued the deployment of e-cash protocols.

What was that problem? At the heart of e-cash protocols is the double-spending problem:

Double-spending problem: Given a list of pending transactions that spend the same coin, the system needs to determine which single transaction should be confirmed as final.

The way to solve this problem is to appoint a trusted broker to decide which transaction should be confirmed in the ledger.

It is this solution, the trusted broker, which is the real problem solved by Satoshi Nakamoto. Trying to find an appropriate broker to step up and take on this role was not possible. From a bank’s perspective it makes sense, why fix something that does not appear to be broken?

Satoshi Nakamoto’s insight was to overcome the limitations of the trusted broker:

• Replace human trust with programmable rules. The trusted element of the broker was explicitly defined into a set of rules that can be enforced by cryptography on a global scale.
• Allow anyone to be the broker. The trusted broker was replaced with an open-membership group who compete with each other to temporarily run the system.
• Financial incentives. Anyone who competes to temporarily take on the role of the broker will be financially rewarded.

Thanks to this insight, Satoshi Nakamoto reduced the role of a trusted broker such that:

• Broker is not trusted with monetary policy.
• Broker is not trusted to set or dictate rules of the system.
• Broker is not trusted to manage an approve list of who can transact.
• Broker is not trusted to reverse already confirmed transactions.

In cryptocurrency, the broker is essentially just a transaction ordering service. They are only trusted to pick valid transactions for confirmation in the database.

This exceedingly limited responsibility has led to a change of the role’s name from broker to block producer.

To better understand the evolution of the broker, we focus on this insight and the basic ingredients used by Satoshi Nakamoto. Most importantly, we explore how everything ties together to allow a system like Bitcoin or Ethereum to survive in the wild.

A user’s identity on the network

No authority is responsible for managing an approval list or registrar on who is allowed to send transactions on the network.

Permissionless: Anyone, regardless of their identity or geographical location, can participate in the system.

What is my identity on the network? A user can have multiple identities on the network thanks to public key cryptography.

All identities are generated locally on the user’s computer as public-private key pairs:

• Private key (d). A cryptographic random number generated by the user.
• Public key (P). It is shared with others and acts as your identity.
• Account/address (A). A cryptographic hash of the public key such that A = H(P).

As the name suggests, the private key should be kept private and the public key can be shared with others.

The public-key cryptography used in cryptocurrencies relies on the discrete log problem. It is computationally infeasible for anyone who has a copy of the public key P to compute the private key D. This is why it is safe to share the public key P and a user can have as many identities as their heart desires. Finally, it is considered to be pseudonymous as a public key is not necessarily tied to your real-world identity.

A Bitcoin address or an Ethereum account is just a public key that has been transformed via a cryptographic hash function.

We use the phrase public key / address / account interchangeably throughout this course.

How can I authorise a transaction using my public key? Thanks to public key cryptography, we have the digital equivalent of a signature. Only the signer can sign a message in their name and anyone can verify they have indeed signed it.

There are two interfaces:

σ = Sign(d, m) // m is the message, and σ is the signature

bool = VerifySignature(σ, P, m) // returns TRUE or FALSE

Only a private key and the message is required to sign a message. Anyone with a copy of the message and the signature can verify that indeed the public key has signed this message.

Without access to the private key, no one can forge your signature on a desired message.

The mathematics behind the digital signature is not important for this article, but you can read more about it here. As a historical note, both digital signatures and key exchange were solved at the same time (it is the inverse problem).

Transactions

At the heart of a cryptocurrency is a public and widely replicated database. Anyone can read it and pay to write to it.

In line with classical database theory is the concept of a transaction. It allows the user to specify the code, function call and arguments they wish to execute. This transaction will read and update data in the database. The user is responsible for crafting, signing and ultimately playing for the transaction’s execution.

Figure 1 provides an overview of the fields that may be found in a transaction:

• Sender & signature. Sender’s address and digital signature.
• Receiver. Receiver’s address.
• Value. Value in the native currency to be transferred.
• Transaction fee. A payment to entice block producers to accept this transaction.
• Payload (data). The bytecode for executing a transaction beyond a simple transfer.

Transaction formats differ significantly across cryptocurrencies, but they all implement roughly the same fields.

Gossip protocol

Let’s assume the user has signed and authorised a transaction, this brings up the question.

How is the user’s transaction confirmed and its execution applied to the database?

Before answering this question, we need to introduce three agents who support the peer-to-peer network:

• User. Individuals who want their transactions to be confirmed and executed against the database.
• Nodes. They are responsible for propagating new transactions and blocks to all other nodes on the network.
• Block producers. They compete in a leader election to win the authority for ordering a list of transactions in the next block.

A user must connect and publish their transaction to the peer-to-peer network. Every node will take a copy of this transaction, check its validity as a pending transaction against their local copy of the database, and then pass it on to their connected peers.

The ultimate goal is to propagate this transaction across the network to reach the block producers. It is up to the block producers to include the user’s transaction in a future block.

Blocks and the blockchain

A block is an ordered list of transactions. Upon receiving a new block, every node will execute the transactions in order and apply the update to their local copy of the database. In a way, it can be seen as a process for performing a batch update. Keep in mind for later articles as the ordered component will lead to some interesting attacks.

Blocks arrival at regular intervals:

• In Bitcoin, the target is every 10 minutes.
• in Ethereum, the target is every 14 seconds.

As Figure 3 illustrates, every block is appended to the previous block to form a chain of blocks. This is where the name blockchain comes from.

Fun fact: The word “blockchain” does not appear in the Bitcoin white paper.

A transaction is only considered confirmed when it is included in a bock and we call this one confirmation. Each additional block that is appended on top of this block is considered another confirmation. As we will see soon, a “confirmation” and “final” are not the same.

Leader election

The insightful solution by Satoshi Nakamoto was to open the membership of block producers such that anyone can participate in the process. His solution is designed as a competition with sequential rounds and in each round the participants compete to win the right to produce the next block. A participant’s performance in one round is independent of all previous rounds.

Proof of work.

There is no trusted authority to decide the winner of a round.

The leader election process must be conducted in an objective manner such that anyone can publicly verify who won the round. Proof of work (or stake) solves this problem. It acts as a sybil-resistance mechanism to limit who can participate in the block production process and it is an objective way to decide the winner of a round.

In both cases, competitors compete based on how much they can spend (or invest).

Fixing a misconception: Proof of work (or stake) has nothing to do with how well the system can scale transaction throughput. Its sole purpose is to decide the winner of a leader election.

Leader election example.

To illustrate an example, we consider the puzzle in Figure 5 which could appear on a show like “Countdown” (a long-running show in the UK). It has some similar properties to the proof of work puzzle used in Bitcoin and Ethereum.

The idea of the puzzle is simple. All participants have the same information and must use any combinations of the numbers alongside addition, subtraction, multiplication, division to recompute (or get as close as possible) to the challenge 275. Unlike the game show, the first competitor to solve this puzzle should publicly broadcast it as fast as possible to declare themselves as the winner.

Break time: Try to solve the puzzle yourself and come back when you are done.

There are some interesting properties that emerge from the puzzle:

• Puzzle difficulty. All participants must compete and solve the same difficult puzzle.
• Time-consuming to solve. It takes some time to solve depending on your computational resources.
• Quick to verify. Given a solution, you can quickly verify whether it is correct.
• More than one solution. There are several ways to solve the same puzzle.
• Solution quality. Not all solutions are equal and you can apply a weighting to say one solution is better than the other.

The proof of work puzzle used by Bitcoin and Ethereum have similar properties. The core difference is that a proof of work puzzle is more similar to a lottery-based game as opposed to countdown. It is based on chance and competitors are continuously opening scratch cards until they find the winner. More details on how it works exactly can be found here.

Forks and eventual consistency

The probabilistic nature of proof of work is that one or more blocks can be produced in the same round. This is problematic as only one block can be appended to the blockchain and all other competing blocks must be discarded. We call this a fork at the chain’s tip.

Decide which fork to follow.

Assuming there are two or more competing blocks, all block producers can only decide to extend one of the blocks. This is called the fork-choice rule and there are several strategies:

• Extend first seen. A block producer will only extend the first block they receive.
• Random coin-flip. A block producer will extend one of the blocks at random.
• Extend heaviest block. A block producer will extend the block with the best solution to the proof of work puzzle (and it will switch blocks if necessary).

In all cases, the block producer will eventually move onto another block if they follow behind tip. For example in Figure 6, a block producer may decide to initially extend Block 3b, but they will eventually decide to stop working on Block 3b as the competing fork becomes the longest and heaviest chain.

Uncertain transaction status.

There is only a probabilistic guarantee that a transaction will eventually be finalised due to forks at the chain’s tip.

For example in Figure 6, a transaction can be confirmed in Block 3b, considered dropped in Block 4 and then re-confirmed in Block 5. Put another way, a user may be informed their transaction was confirmed, dropped, and re-confirmed as it flips back-and-forth.

It is recommended a user relies on the following heuristic before considering a transaction final:

X Confirmations: You should wait X confirmations before considering the transaction final.

Kraken has a nice break-down on confirmations they use before accepting a deposit on their service. A general rule of thumb is that more confirmations the better as it is less likely the transaction will be forked out of the chain. This assumes that 51% of the block producers are honest and they will always follow the longest (heaviest) chain.

Is it safe to assume a simple majority are honest? it all depends on the cryptocurrency network as we will see in a future article. If you don’t make it that far, then just remember to never trust confirmations for Ethereum Classic (ETC).

Financial incentives

Block producers compete in the leadership election to maximise their profit and this can be called Maximal Extractable Value (MEV). There are three sources of revenue:

• Block subsidy. Every block rewards the block producer with an issuance of new coins. This is often linked with the network’s monetary policy.
• Transaction fees. All transactions include an explicit fee that acts as a tip and rewards the block producer including it in a block.
• Extractable value. A block producer may include a list of transactions as they can indirectly extract value from its execution.

The portion of a block producer’s revenue depends on the cryptocurrency network. For example, Bitcoin miners have mostly relied on a large block subsidy to reward the block producers (and ultimately secure its network). On the other hand, Ethereum miners are being rewarded handsomely from transaction fees and more controversially extractable value.

How financial incentives are set up remains a hotly debated topic. It has direct consequences on the security and reliability of the network. We will discuss it more in a future article.

Concluding the overview

Satoshi Nakamoto brought together the following basic ingredients:

• Pseudonymous identity. Anyone can generate their own public-private key pair and transact on the network.
• Digital signatures and transactions. Anyone can sign a transaction and pay for the privilege to execute it on the database.
• Gossip protocol. Anyone can connect to a peer-to-peer network and publish their transaction to the world.
• Leader election. Opening the membership via a fierce competition to allow anyone to participate in the transaction confirmation process.
• Financial incentives. Participants are rewarded for supporting the network.

Together, it has led to self-sustaining peer to peer network. Bitcoin is 13 years old and Ethereum is 8 years old. This simple fact alongside the rise of a trillion-dollar industry is a testament the basic ingredients work. There are still issues, thorns and subtle details that we will cover throughout the course, but it is incredible that Satoshi Nakamoto planted the seed for this to grow.

Thank you Satoshi for everything.