Polkadot Consensus Part 3: BABE

Blind Assignment for Blockchain Extension (BABE) is a block production engine that was inspired by Ouroboros Praos, another proof-of-stake protocol. It can be used on its own because it provides probabilistic finality, or it can be coupled with a finality gadget like GRANDPA.

By Joe PetrowskiDecember 18, 2019

This is part 3 in our Polkadot consensus series. See part 1 for the introduction and part 2 for a discussion about GRANDPA.

Blind Assignment for Blockchain Extension (BABE) is a block production engine that was inspired by Ouroboros Praos, another proof-of-stake protocol. It can be used on its own because it provides probabilistic finality, or it can be coupled with a finality gadget like GRANDPA.

BABE is a slot-based algorithm. It breaks time into epochs, with each epoch being broken into slots. In Polkadot, each slot is six seconds long, our target block time. BABE will select an author (or several) to author a block in each slot.

Time in BABE is broken into epochs. Each epoch is a set of slots.

One way to assign authors to these slots would be simply to take turns. However, in a round-robin pattern, adversaries always know who the next author is and can use that information to coordinate attacks. Ideally, nobody knows who the slot author is until he or she proves it.

Each slot can have a primary and secondary author (or “slot leader”). Primary slot leaders are assigned randomly. Because the function is random, however, sometimes there are slots without a leader. In order to ensure a consistent block time, BABE uses a round-robin system to assign secondary slot leaders.

Primary Slot Leaders

Primary leadership is granted based on the evaluation of a verifiable random function (VRF). There’s a lot of hype around random numbers in blockchain. To make a long story short, a lot of applications depend on random number generation, but it can be difficult to find randomness that everyone agrees is random (and not gamed such that the generator benefits) when all on-chain operations must be deterministic and verifiable.

VRFs generate a pseudo-random number along with a proof that it was properly generated. They take some parameters, including a private key, as input. Our VRF takes an epoch random seed (agreed upon in advance by all nodes), a slot number and the author’s private key. Because no two nodes have the same private key, each node can generate a unique, pseudo-random value for each slot

Each author evaluates its VRF for each slot in an epoch. For each slot whose output is below some agreed-upon threshold, the validator has the right to author a block in that slot. Because of the random slot assignment process, it’s possible to have slots without a primary as well as slots with multiple primaries. We will discuss how we deal with that later.

The VRF in BABE takes an epoch randomness, slot number and validator private key as input and outputs a value for each slot in an epoch. When a block author’s output is below the network’s threshold, it produces a block as a primary block leader for that slot.

Secondary Slot Leaders

To deal with empty slots, BABE uses a round-robin fallback. Every slot has a secondary leader. If nobody claims that they are the primary at the beginning of the slot, then the secondary will author a block. This fallback will make sure that every slot has a block author and helps to guarantee a consistent block time.

Bringing BABE and GRANDPA Together

Up to now, we have GRANDPA finalizing chains and BABE creating new blocks. Some of BABE’s chains may have forks since a single slot can have multiple leaders.

The first rule of choosing the best chain to extend is simple: BABE must build on a chain that has been finalized by GRANDPA. This is one of the requirements to use GRANDPA.

A second, more subtle, requirement for using GRANDPA is that the block production algorithm must have a way of choosing the “best” chain. This property leads to BABE having probabilistic finality (thus, you could use it without GRANDPA).

The best chain in BABE is simply the one with the most blocks authored by primaries.

An example of BABE’s fork choice rule for choosing the best chain.

Forks are common in BABE. As discussed in the GRANPA article, block production is O(n), meaning that the author just has to broadcast its block to everyone but does not need everyone to send a message to everyone (like in GRANDPA). So, not everyone will have the same view of the non-finalized chain (yellow blocks in the image).

This system lets us produce blocks in an efficient way and lets GRANDPA finalize a set of them.

Wait, Whose Clock?

We are assigning slots based on time, but we don’t have a single view of time. Every computer has its own clock. We can’t use a centralized time service (called NTP servers) because that is a single point of attack. An attacker could attack the NTP server, either cutting it off or taking control to get up to more unscrupulous behavior like sending different times to different nodes.

If you’re interested, consider this scenario:

I receive a message from you saying “it’s 8:42:00.” My clock says it is 8:42:03. One of three things is possible:

1. Our clocks are in sync, it just took 3 seconds for the network to deliver your message.

2. It actually took 1 second to deliver your message. Our clocks are out of sync by 2 seconds.

3. You’re lying to me, that’s not what your clock said.
Now imagine that I receive this message when my clock says 8:41:59. If I believe that you are honestly telling me what your clock said, then I know that we are out of sync and that I must set my clock forward. I still don’t know the time it took to deliver via the network, so I don’t know how much out of sync we are.

BABE aligns slot numbers to an individual computer’s clock using relative time. When a node receives a block, it checks the reception time and the slot number associated with the block. It then adds the number of slots to each block’s time to forecast future slots and uses the median value from its data. Remember, validators know the slot numbers for which they will author in advance, so they can check incoming blocks against this.

Block authors in BABE use the reception time for blocks to create a view of the network’s time. They project the reception times into the future, based on the slot time, to determine when they should author and propose a block.

So far we have discussed how chains are made (BABE) and how they are finalized (GRANDPA). The next problem we have to solve is, how do we get people to run these protocols in the correct way? The final part of this series will discuss how the runtime provides incentives to run BABE and GRANDPA and the punishments for errors.

Read part 4 about Security ->

From the blog

How play-to-earn (P2E) is transforming onchain mobile sports gaming

Play-to-earn games are transforming mobile sports gaming. Learn how blockchain, NFTs, and platforms like Polkadot create new opportunities for digital asset ownership and cross-chain gameplay.

Polkadot Token 2049 and Decoded Asia 2024: A multichain ecosystem in action

At Token 2049 and Decoded Asia 2024 in Singapore, Polkadot teams and contributors showcased a multichain future for real-world applications. Key moments included Dr. Gavin Wood’s vision for digital individuality, Chrissy Hill’s regulatory insights, and announcements from emerging projects shaping the Web3 ecosystem.

What is a crypto wallet? Your all-access pass to the future web

In Web3, your wallet is your most valuable digital tool. It’s more than just a place to store, send, and receive cryptocurrencies securely—it’s your passport to the decentralized world.

July 2024: Key network metrics and insights

Welcome to your go-to source for the latest tech updates, key metrics, and discussions within Polkadot, brought to you by the Parity Success Team. This blog series covers a variety of topics, drawing insights from GitHub, project teams, and the Polkadot Forum.

Polkadot 2.0: The rebirth of a network

Polkadot 2.0 reimagines blockchain with a bold rebrand and powerful features: Agile Coretime, Async Backing, and Elastic Scaling. Step into a more flexible, faster, and scalable network. Learn about the improvements and changes that led to this next era of Polkadot.

Meet the Decentralized Futures grant recipients: transforming ideas into impact on Polkadot

The Decentralized Mic is here to spotlight the innovative projects and teams driving Polkadot’s growth. Join us as we explore the achievements of Decentralized Futures grant recipients and their contributions to the Polkadot ecosystem on the new ecosystem community call series.

The ultimate 2024 Polkadot grants and funding guide

Explore Polkadot ecosystem funding: grants, venture capital, bounties, and community initiatives. Discover opportunities for blockchain builders today.

Decoded 2024: Polkadot’s vision for a decentralized future

Polkadot Decoded 2024 in Brussels brought together top blockchain minds to explore the future of Web3. Highlights included Björn Wagner's insights on payments and Dr. Gavin Wood's vision for digital individuality. Showcasing technical breakthroughs and real-world use cases, Polkadot affirmed its leadership in the multi-chain future.

June 2024: Key network metrics and insights

Welcome to your go-to source for the latest tech updates, key metrics, and discussions within Polkadot, brought to you by the Parity Success Team. This blog series covers a variety of topics, drawing insights from GitHub, project teams, and the Polkadot Forum.

Introducing the New Polkadot Ledger App

Discover the new Polkadot Ledger app for seamless, secure transactions. Now available on Ledger Live, it supports Polkadot, Kusama, and more.

Polkadot’s May Ecosystem Insights

Welcome to your go-to source for the latest tech updates, key metrics, and discussions within Polkadot, brought to you by the Parity Success Team. This blog series covers a variety of topics, drawing insights from GitHub, project teams, and the Polkadot Forum.

Top takeaways from the decentralization panel at Consensus

Consensus by Coindesk 2024: a blockbuster success