pull down to refresh

My understanding of Fedimint is not deep, but I believe they put a lot of work into how the guardians reach consensus together on the state of the mint, especially in the case where some of the guardians might be acting maliciously. It's pretty cool how robust the system can be.
One of the people working on Fedimint, @dpc (dpc_pw on X), just released today a project he's calling Byzantine Fault Tolerant Engine. He lists the goal of the project as
becoming good general purpose modular consensus engine, and be ambitious about other aspects of the design space and implementation.
Some of the applications dpc suggested this might be useful for include:
  • CI system coordination,
  • review systems,
  • etc.
I can vaguely grasp how this might be used, but am clearly in way beyond my depth. My interest is piqued, though.
17 sats \ 1 reply \ @k00b 13 Jun
I'm glad you shared this. I was going to but wanted to think about it more.
I spent most of my time exploring its consensus protocol which is a variation on simplex and produces a dynamic, random leader, byzantine fault tolerant consensus that extends immutable records (ie a chain of blocks ... but not necessarily having anything to do with cryptocurrency).
I began imagining what it might be used for in the context of fedimint, which I haven't studied very closely, but likely does not handle byzantine faults given guardian members are assumed to be trustworthy (at least among each other).
I imagine this could make fedimints far more dynamic in terms of guardians (existing guardians can vote to add/remove others) and offer non-expiring mints or, perhaps most interesting to me, money<->censorship resistant information relationships (without shitcoins ... assuming everything is transparently full reserve).
reply
My understanding was that fedimint does have some ability to handle byzantine faults.
Fedimint does say in their docs that "a BFT consensus algorithm is used to agree on a set of consensus items."
On another page they say
The consensus protocols we are discussing, asynchronous ones, can only handle about 1/3 faulty nodes, so this will also be our assumption when building our protocol on top if not stated otherwise.
But the reason dpc is working on this (aside from it being really interesting) is that they perhaps would like it to be more robust.
reply