(2019-12-18) Petrowski Polkadot Consensus Part1 Introduction

Joe Petrowski on Polkadot Consensus Part 1: Introduction. This series will be a discussion about security and consensus in Polkadot. In part 1, we will define some terms before getting into the details of how Polkadot creates and secures blocks.

Consensus algorithms help a network of computers operate like a single computer. In practice, this means that almost every computer in the network must agree on some initial state and then agree on a log of deterministic operations to the initial state, such that they arrive at the same final state.

While blockchains bring some interesting tools to this domain, this coordination problem is nothing new.

What does this have to do with blockchain? We want a network of computers to agree on some value. That value could be the balance of an account, the outcome of a vote or the execution result of a smart contract.

In fact, some pre-existing consensus algorithms resembled blockchains. In a 2001 lecture, MIT professor Barbara Liskov talked about batching transactions to improve Practical Byzantine Fault Tolerance (PBFT) performance, well before Bitcoin existed.

In a distributed system like a blockchain, you need to answer a few questions: Who can propose the next change? Which set of changes is final? What happens if someone breaks the rules?

It’s important to make these distinctions early because many blockchain consensus protocols unite them into one. Proof of work, for example, uses the proof to select the proper author of a block; the longest chain to decide which chain is final; and the cost of making that proof as the punishment for breaking the rules. In Polkadot, these questions are all answered in isolation.

Non-blockchain systems still answer these questions. For example, one could make the assumption that all computers run the same software. In most cases, this is fine.

In a public network, however, we can’t make such an assumption

Security in a blockchain system is a measure of the difficulty of breaking consensus. In proof of authority, security is the difficulty to take control of the authorities. In proof of work, security is the cost to acquire and operate enough hash power to create a longer chain than the network. And in proof of stake, security is the value staked and the value at risk.

Members of Parity Technologies and Web3 Foundation developed and implemented a library of algorithms to tackle consensus and security. In this series, we will start with GRANDPA, our finality algorithm, because all block production algorithms must respect this finality. Then we will move on to BABE, our block-production engine, and discuss how we add blocks to the chain. Finally, we will end with a discussion on how we use economics to secure GRANDPA and BABE.