mirror of https://github.com/logos-co/roadmap.git
changed LogosBFT to Carnot
This commit is contained in:
parent
01119993ba
commit
39a55295e8
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Frequently Asked Questions"
|
||||
tags:
|
||||
- "LogosBFT"
|
||||
- "Carnot"
|
||||
- "consensus"
|
||||
openToc: true
|
||||
---
|
||||
|
|
@ -31,7 +31,7 @@ openToc: true
|
|||
|
||||
> `Marcin:` Great, and definitely, we cannot attest that a node was not participating - I was not suggesting that;). But we can also think about extending the attestation for lazy-participants case (if it’s not already part of the protocol).
|
||||
|
||||
> `Moh:` OK, thanks for the clarification 😁 . Of course we can have this feature to forward the proof of participation of successor committees. In the first version of LogosBFT we had this feature as a sliding window. One could choose the size of the window (in terms of tree levels) for which a node should forward the proof of participation. In the most recent version the size of sliding window is 0. And it is 1 for the root committee. It means root committee members have to forward the proof of participation of their child committee members. Since I was able to prove protocol correctness without forwarding the proofs so we avoid it. But it can be part of the protocol without any significant changes in the protocol
|
||||
> `Moh:` OK, thanks for the clarification 😁 . Of course we can have this feature to forward the proof of participation of successor committees. In the first version of Carnot we had this feature as a sliding window. One could choose the size of the window (in terms of tree levels) for which a node should forward the proof of participation. In the most recent version the size of sliding window is 0. And it is 1 for the root committee. It means root committee members have to forward the proof of participation of their child committee members. Since I was able to prove protocol correctness without forwarding the proofs so we avoid it. But it can be part of the protocol without any significant changes in the protocol
|
||||
|
||||
> If the proof scheme is efficient ( as the results you presented) in practice and the cost of creating and verifying proofs is not significant then actually adding proofs can be good. But not required.
|
||||
|
||||
|
|
@ -1,32 +1,35 @@
|
|||
---
|
||||
title: "Logos BFT Overview"
|
||||
title: "Carnot Overview"
|
||||
tags:
|
||||
- "consensus"
|
||||
- "candidate"
|
||||
- "LogosBFT"
|
||||
- "Carnot"
|
||||
editor: "Corey Petty"
|
||||
---
|
||||
|
||||
Logos BFT is a [consensus](/consensus/index.md) candidate for the Logos 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.
|
||||
Carnot (formerly LogosBFT) is a Byzantine Fault Tolerant (BFT) [consensus](roadmap/consensus/index.md) 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.
|
||||
|
||||
- [FAQ](roadmap/consensus/candidates/logos-bft/FAQ.md): Here is a page that tracks various questions people have around LogosBFT.
|
||||
- [FAQ](roadmap/consensus/candidates/carnot/FAQ.md): 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 beign conducted by Tuanir, and can be found in the following WIP Overleaf document:
|
||||
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:
|
||||
- [WIP Consensus SoK](https://www.overleaf.com/project/633acc1acaa6ffe456d1ab1f)
|
||||
|
||||
### Committee Tree Overlay
|
||||
The basis of LogosBFT is dependent upon establishing an committee overlay tree structure for message distribution.
|
||||
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:
|
||||
- [LogosBFT Overview by Moh during Offsite](https://drive.google.com/file/d/17L0JPgC0L1ejbjga7_6ZitBfHUe3VO11/view?usp=sharing)
|
||||
- [Carnot Overview by Moh during Offsite](https://drive.google.com/file/d/17L0JPgC0L1ejbjga7_6ZitBfHUe3VO11/view?usp=sharing)
|
||||
|
||||
The details of this are being worked on by Moh and Alexander and can be found in the following overleaf documents:
|
||||
- [Moh's draft](https://www.overleaf.com/project/6341fb4a3cf4f20f158afad3)
|
||||
- [Alexander's notes on the statistical properties of committees](https://www.overleaf.com/project/630c7e20e56998385e7d8416)
|
||||
|
||||
A simulation notebook is being worked on by Corey to investigate the properties of various tree overlay structures and estimate their practical performance:
|
||||
- [Corey's Overlay Jupyter Notebook](https://github.com/logos-co/scratch/tree/main/corpetty/committee_sim)
|
||||
|
||||
#### 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
|
||||
|
|
@ -8,8 +8,8 @@ Consensus is the foundation of the network. It is how a group of peer-to-peer no
|
|||
|
||||
## Consensus Roadmap
|
||||
### Consensus Candidates
|
||||
- [glacier](roadmap/consensus/candidates/glacier.md)
|
||||
- [logos-bft](roadmap/consensus/candidates/logos-bft.md)
|
||||
- [Glacier](roadmap/consensus/candidates/glacier.md)
|
||||
- [Carnot](roadmap/consensus/candidates/carnot/overview.md)
|
||||
|
||||
### Theoretical Analysis
|
||||
- [snow-family](roadmap/consensus/theory/snow-family.md)
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ title: "Theoretical Analysis of the Snow Family of Consensus Protocols"
|
|||
tags:
|
||||
- "consensus"
|
||||
- "theory"
|
||||
- "snow"
|
||||
---
|
||||
|
||||
In order to evaluate the properties of the Avalanche family of consensus protocols more rigorously than the original [whitepapers](), we work to create an analytical framework to explore and better understand the theoretical boundaries of the underlying protocols, and under what parameterization they will break vs a set of adversarial strategies
|
||||
Loading…
Reference in New Issue