-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Support consensus engines without a single proposer. #8888
Comments
First of all, congratulations on the HBBFT implementation in Rust! I wanted to do one myself in my spare time but never managed to get around to doing it. We would definitely be open to including it in Parity and accepting any and all contributions necessary to making it work. HoneyBadgerBFT and similar algorithms were a part of the motivation for the Although there is no actual "proposer" for HoneyBadgerBFT, there are a couple things to consider: The EVM requires an HoneyBadgerBFT as described in the paper allows nodes participating in the consensus to come to an agreement, but proving that agreement has been reached to non-consensus nodes requires some form of justification. This is the "seal" type in the
Note that the first two options can lead to different valid seals being created (even if no authorities are byzantine) since they aren't a result of polynomial interpolation, which would require significant refactoring in Parity to ensure that the blockchain is based on the "bare" hash of the header and not the hash with the seal included. This change would be necessary to support tendermint or other PBFT derivates faithfully in Parity as well. |
Also: I think these kinds of internal-communication-heavy consensus play really nicely with the This feature would be orthogonal with #8664 which intends to make block production an asynchronous process within the engine, providing only a stream of network messages and a sink for output messages. |
Thanks, but don't congratulate us too early: Yes, we were thinking of using 2f + 1 (or just f + 1?) signatures as the seal (in an extra message round, which could happen in parallel with the Honey Badger epoch for the next block, I guess), but a threshold signature would make more sense: and Honey Badger uses threshold signatures anyway, so we should have the necessary tools available.
Could these even be targeted, or broadcast-only? Or should we use separate direct connections anyway if we need low-latency and high-bandwith channels? |
It would probably multicast too all authorities (defined by engine), which is the network requirement for HoneyBadger AFAIK, although we could probably make more complex routing as necessary. You're right that only f + 1 are necessary since the agreement has already resolved (under a basic honest-majority assumption). 2f + 1 is necessary if you construct a justification from PBFT-style Commit messages but not here. Although for accountable safety (for e.g. PoS slashing) you might want to use 2f + 1 anyway, since then reversion of a finalized block has to overlap in at least f + 1 authorities. This isn't as conducive to threshold signatures though. |
You're right, maybe 2f + 1 is safer. Honey Badger requires that many honest nodes anyway, so if we fail to collect that many signatures it's better to stop immediately rather than accept a block singned by fewer than that.
Most messages are broadcast, but not all: Crucially, the biggest ones are targeted, i.e. sent from a validator to a single other validator. Honey Badger only achieves a high throughput and low latency if that kind of communication is high-bandwidth (broadcasting all of them would waste a lot of bandwidth) and low-latency (if they are routed via several hops, the block rate would be much lower), so I still think it might be necessary to create a separate set of direct connections. |
We would like to implement a consensus engine based on Honey Badger for the POA Network, and we are wondering whether:
Engine
trait is suitable for this kind of algorithm, and if not,In Honey Badger, in each round/epoch, every node proposes a subset of transactions from its mempool, and the algorithm reaches agreement on a union of some of those subsets. The main differences compared to the existing
Engine
implementations are:Miner
/TransactionQueue
/transaction-pool
functionality — prioritizing transactions and picking the ones to propose — needs to happen before each consensus round, while otherMiner
functionality — producing a new block and processing the transactions — needs to happen after the consensus round has produced an output.The text was updated successfully, but these errors were encountered: