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, on the theoretical side I was diving deeper into distributed systems like Bitcoin, Ethereum, and the Internet Computer.

Finding the topic

Luckily, a couple of PhD students at Roger Wattenhofer's DISCO group — the teacher of the course that made me fall in love with distributed systems — 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". 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.

Consensus on Demand

The PhD students I was working with had already developed an algorithm, called Consensus on Demand (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).

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, 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, 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. When I first managed to run it on my computer (for just one round...), I was electrified!

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.

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

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.

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 had now come to fruition. Enough theory, though — I wanted to go back to building [link to come].