Home

Zeno, a high-performance Byzantine fault tolerant protocol

Zeno is an implementation of RBFT, or Redundant Byzantine Fault Tolerance, a consensus algorithm proposed by Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quéma. As described in their paper (citation needed), existing BFT protocols "use a special replica, called the primary, which indicates to other replicas the order in which requests should be processed. This primary can be smartly malicious and degrade the performance of the system without being detected by correct replicas."

RBFT implements a new approach whereby multiple instances of the protocol are running simultaneously, a Master instance, and one or more Backup instances. All nodes monitor the Master and compare its performance with that of the Backup instance(s). If the Master does not perform acceptably, it is considered malicious and replaced.

In addition to using RBFT, Zeno leverages RAET: Reliable Asynchronous Event Transport Protocol, a high-performance, fault-tolerant communications protocol on top of UDP. RAET leverages Daniel J. Bernstein's Curve25519, a highly-secure high performance elliptic curve.

Where Zeno differs from RBFT is that instead of using MAC authenticators, every communication is digitally signed using Curve25519. While MAC authenticators are computationally less expensive to verify than digital signatures, we feel that today, the security trade-offs are a bit high, especially given the benefits of faster verification for the protocol applications we foresee.

Also, RBFT does not specify the election process, that is, how the primaries of each protocol instance are selected. We've implemented a process that applies a voting to select the primary. The election strategy is plug-able, meaning another strategy with different security and performance characteristics could be substituted easily.

Introduction

This tutorial assumes an intermediate level knowledge of Python, basics of distributed systems, concurrency but not much else. The goal is to give you an overview of the consensus protocol technology that helps to overcome cases of Byzantine failures (random, spurious faults, or malicious, intelligent attacks) in a distributed system. We recommend going through [Getting Started] (https://docs.google.com/document/d/1MtGYbf9EtIGKHZ8g_RaoXVutegTnXu2Lzb09mJGtyxA/edit?usp=sharing) to know more about Byzantine faults and Failures, origin of BFT and info on underlying principles of Zeno

Contributors

This is a collaborative document written by Evernym team. Have something to add? See a typo? Fork and submit a pull request. Any and all contributions are welcome.

Our Solution

Many Byzantine fault tolerant replication protocols are proposed to solve the problem of byzantine faults and failures. But the performance of these BFT protocols degrades marginally when a fault or a failure occurs.

Zeno nodes execute multiple instances of the same BFT protocol simultaneously. All the instances order the requests, but only the requests ordered by one of the instances, called the master instance, are actually executed. To demonstrate the Zeno Protocol in action, we created a command-line interface (cli) that creates a "sandbox" of sorts. In this sandbox, you can spin up a small consensus pool, spin up clients, send requests, and see them move through the system.

We've tried to strike a balance between too much info, and not enough. Where the output can be a bit confusing, we'll call out what's happening. Also, the cli generates a log file with a lot more detail. It might be useful to tail the log while you run the cli to see what's happening. Also, you could attach to a running cli process with a debugger (some of us use PyCharm) and really see what's going on.

Reference: Pierre-Louis Aublin, Sonia Ben Mokhtar, Vivien Quéma: “RBFT: Redundant Byzantine Fault Tolerance” In Proceedings of the International Conference on Distributed Computing Systems (ICDCS), Philadelphia, USA, July 2013

RAET

Nacl