4.1 KiB
title, tags, editor
| title | tags | editor | |||
|---|---|---|---|---|---|
| Carnot Overview |
|
Corey Petty |
Carnot (formerly LogosBFT) is a Byzantine Fault Tolerant (BFT) consensus candidate for the Nomos Network that utilizes Fountain Codes and a committees tree structure to optimize message propagation in the presence of a large number of nodes, while maintaining high througput and fast finality. More specifically, these are the research contributions in Carnot. To our knowledge, Carnot is the first consensus protocol that can achieve together all of these properties:
- Scalability: Carnot is highly scalable, scaling to thousands of nodes.
- Responsiveness: The ability of a protocol to operate with the speed of a wire but not a maximum delay (block delay, slot time, etc.) is called responsiveness. Responsiveness reduces latency and helps the Carnot achieve Fast Finality. Moreover, it improves Carnot's resilience against adversaries that can slow down network traffic.
- Fork avoidance: Carnot avoids the formation of forks in a happy path. Forks formation has the following adverse consequences that the Carnot avoids.
- Wastage of resources on orphan blocks and reduced throughput with increased latency for transactions in orphan blocks
- Increased attack vector on PoS as attackers can employ a strategy to force the network to accept their fork resulting in increased stake for adversaries.
- FAQ: Here is a page that tracks various questions people have around Carnot.
Work Streams
Current State of the Art
An ongoing survey of the current state of the art around Consensus Mechanisms and their peripheral dependencies is being conducted by Tuanir, and can be found in the following WIP Overleaf document:
Committee Tree Overlay
The basis of Carnot is dependent upon establishing an committee overlay tree structure for message distribution.
An overview video can be found in the following link:
The details of this are being worked on by Moh and Alexander and can be found in the following overleaf documents:
- Moh's draft
- Alexander's notes on the statistical properties of committees
- Alexander's python code for computing committee sizes
A simulation notebook is being worked on by Corey to investigate the properties of various tree overlay structures and estimate their practical performance:
Failure Recovery
There exists a timeout that triggers an overlay reconfiguration. Currently work is being done to calculate the probabilities of another failure based on a given percentage of byzantine nodes within the network.
- Recovery Failure Probabilities - LINK TO WORK HERE
Random Beacon
A random beacon is required to choose a leader and establish a seed for defining the overlay tree. Marcin is working on the various avenues. His previous presentations can be found in the following presentation slides (in chronological order):
Erasure Coding (LT Codes / Fountain Codes / Raptor Codes)
In order to reduce message complexity during propagation, we are investigating the use of Luby Transform (LT) codes, more specifically Fountain Codes, to break up the block to be propagated to validators and recombined by local peers within a committee.
- LT Code implementation in Rust - unclear about legal status of LT or Raptor Codes, it is currently under investigation.