# Fast Internet Computer consensus (2022–2023)

> Massimo's 2022–2023 master's thesis project — his one shot at real academic research: a faster consensus protocol for the Internet Computer, developed at ETH's DISCO group, which became Banyan (Best Paper at Middleware 2024).

- Canonical URL: [https://massimo.context-use.com/p/about/projects/2022-2023_fast-internet-computer-consensus/story](https://massimo.context-use.com/p/about/projects/2022-2023_fast-internet-computer-consensus/story)
- Site index: [https://massimo.context-use.com/llms.txt](https://massimo.context-use.com/llms.txt)
- Last edited: 2026-07-25T11:11:11.026Z

For my master's thesis, I wanted to do something that could be considered real academic research. All my projects so far had been mostly about engineering and, as I wasn't planning to do a PhD, I thought this would be my last chance to do real research.

Many of the courses I took during my master's were about theoretical computer science. I knew I would never be a researcher in that field — many of my classmates were light years ahead of me when it came to theoretical CS — but for my thesis I wanted to challenge myself on that front and see if I could do any good.

Throughout my master's, while on the practical side I was building all the different versions of [Omnia](https://massimo.context-use.com/p/about/projects/2020-2024_omnia/intro), on the theoretical side I was diving deeper into distributed systems like Bitcoin, Ethereum, and [the Internet Computer](https://massimo.context-use.com/p/about/chapters/2020-2024_zurich/2022-2023_master-thesis-at-disco#finding-the-internet-computer).

### Finding the topic

Luckily, a couple of PhD students at [Roger Wattenhofer's](https://disco.ethz.ch/members/wroger) DISCO group — the teacher of the course that [made me fall in love with distributed systems](https://massimo.context-use.com/p/about/chapters/2020-2024_zurich/2020-2021_getting-into-distributed-systems#the-distributed-systems-course) — were considering researching the Internet Computer too, and so I found the topic of my thesis.

### Reducing finality

The goal was to reduce the finality of the Internet Computer blockchain: the amount of time it takes for a block (and the transactions in it) to be permanently approved by the network — in this case, the servers running the Internet Computer protocol.

Time to finality is quite big in traditional blockchains: about 60 minutes for Bitcoin and 15 for Ethereum. The Internet Computer had already made massive improvements on that front, with a time to finality of a couple of seconds. We wanted to reduce it even further.

### Why it mattered

I cared so much about this problem because I saw it as one of the main bottlenecks preventing the creation of a real ["world computer"](https://massimo.context-use.com/p/about/chapters/2020-2024_zurich/2022-2023_master-thesis-at-disco#the-world-computer). For a world computer to run real applications, they would have to be at least as good as traditional applications running on AWS. An application with a latency of a couple of seconds — instead of the milliseconds of traditional ones — would never scale beyond the few crypto enthusiasts.

![Motivation slide contrasting the Internet Computer's ~2-second time to finality with AWS's near-instant response.](https://assets.massimo.context-use.com/a/about/projects/2022-2023_fast-internet-computer-consensus/motivation-latency){size=large align=center}

### Consensus on Demand

The PhD students I was working with had already developed an algorithm, called Consensus on Demand ([arxiv.org/abs/2202.03756](https://arxiv.org/abs/2202.03756)), that would, under certain circumstances, significantly improve the finality of any permissioned blockchain (like the Internet Computer) via what we called a fast path. The problem was that this optimization would result in a latency overhead in all the circumstances in which the fast path couldn't be used — which, in a real-world scenario, happened quite often due to network delays and the other problems that distributed systems engineers have to face daily. During my master's thesis, we managed to codesign Consensus on Demand onto the Internet Computer consensus to remove that overhead. The result became "Fast Internet Computer consensus" ([arxiv.org/pdf/2312.05869v1](https://arxiv.org/pdf/2312.05869v1)).

![Latency diagram comparing "CoD + ICC" — where a green fast path runs first and is then followed by the full blue ICC round — against "FICC", where the fast path and ICC run together so finality is reached in barely more than one round trip.](https://assets.massimo.context-use.com/a/about/projects/2022-2023_fast-internet-computer-consensus/cod-vs-ficc){size=large align=center}

### A single round-trip

FICC was the first consensus algorithm to allow blocks to be confirmed in just a single round-trip time in the Byzantine fault tolerance (BFT) setting. This basically meant that you couldn't go any faster — a block would at least have to be propagated to the network, which takes at least one round-trip.

All the distributed systems theory I had spent countless hours learning during my master's had finally resulted in a small contribution to science. I was really happy.

### Implementing it

Beyond designing the new consensus algorithm and proving its guarantees of safety, liveness, and termination, the project came with another interesting challenge: implementing the FICC algorithm on my own Internet Computer subnet and demonstrating the latency improvements.

The Internet Computer protocol is a [massive Rust codebase](https://github.com/dfinity/ic), written by some of the best distributed systems engineers and cryptographers. The idea that I had to figure out how to integrate FICC into that huge and beautiful machine was daunting. When I started there wasn't even ChatGPT — and it certainly wouldn't have been able to really help for at least another year or two. Back then I didn't even know [Rust](https://www.rust-lang.org/), and it took me several days just to figure out which parts of the IC replica could be safely removed in order to run it on my computer. Eventually, this led to my [Fast Internet Computer Consensus repo](https://github.com/massimoalbarello/fast_internet_computer_consensus). When I first managed to run it on my computer (for just one round...), I was electrified!

![Photo of a monitor running four terminal panes in VS Code, each executing a node of the consensus_on_demand (FICC) prototype — logging genesis-block initialization, peer IDs, notarization shares, and rounds — during the first local multi-node run.](https://assets.massimo.context-use.com/a/about/projects/2022-2023_fast-internet-computer-consensus/first-local-run){size=large align=center}

### Testing it in the wild

After months of hard work, we were ready to test our algorithm on a real distributed system.

We deployed both a simplified version of the original Internet Computer Consensus and our improved version, Fast Internet Computer Consensus, on a bunch of servers distributed around the world.

![World map marking the roughly sixteen geographically distributed servers — across North America, South America, Europe, Asia, and Australia — on which the simplified Internet Computer Consensus and FICC were deployed for testing.](https://assets.massimo.context-use.com/a/about/projects/2022-2023_fast-internet-computer-consensus/world-servers){size=large align=center}

We tested both versions under different conditions and we managed to observe a significant improvement!

![Box-plot chart of block finalization latency in seconds, comparing baseline ICC (n=16, f=5) at a median of ~4.1s against three FICC configurations; the best (n=16, f=3, p=3) reaches a median of ~2.5s — a roughly 30% reduction highlighted by a green downward arrow.](https://assets.massimo.context-use.com/a/about/projects/2022-2023_fast-internet-computer-consensus/latency-results){size=large align=center}

While a 30% reduction in latency might not seem that significant, we were gratified by the fact that you couldn't do any better. We had created a consensus algorithm that would finalize blocks in one round trip (under good network conditions) and wouldn't introduce any latency overhead (under bad network conditions). The way to reduce finalization latency even further could not be via an even better algorithm; it could only be via clever engineering and the tuning of parameters like the number of nodes, geographical location, resiliency to Byzantine actors, and so on. For some intuition on how it all worked, have a look at the ![slides from my thesis defense](https://assets.massimo.context-use.com/a/about/projects/2022-2023_fast-internet-computer-consensus/thesis-defense-presentation).

### Full circle

By the end of my master's thesis, I had gone full circle! What started a couple of years before as a big career pivot [from electronics to distributed systems](https://massimo.context-use.com/p/about/chapters/2020-2024_zurich/2020_from-electronics-to-computer-science) had now come to fruition. Enough theory, though — I wanted to go back to building *[link to come]*.