Jack pfp
Jack
@jmcph4
@bayardo.eth how amenable do you think the current Commonware consensus engine would be to a HotStuff implementation?
1 reply
0 recast
2 reactions

Roberto Bayardo 🎩 pfp
Roberto Bayardo 🎩
@bayardo.eth
Simplex (which we've implemented in commonware) is all-to-all and HotStuff is a all-to-one consensus protocol .. so there would be some work involved. But you'd just be making the algo worse :) Why do you ask?
2 replies
0 recast
1 reaction

patrickogrady.xyz pfp
patrickogrady.xyz
@patrickogrady
Some Additional Context: The Commonware Library (https://github.com/commonwarexyz/monorepo), unlike other stacks/frameworks, doesn't have a single consensus engine or a required consensus interface that you'd need to fit HotStuff in. Like we did with Simplex/Threshold Simplex/Ordered Broadcast, you speedrun an implementation of HotStuff with runtime::tokio, p2p::authenticated, journal::variable, and cryptography::{bls12381, sha256}). We've recommended that all devs working on new primitives implement them externally (importing primitives from the Commonware Library). If someone builds something awesome and they don't want to maintain it, we'll merge it into the monorepo. TL;DR we'd love to see an implementation of HotStuff 2 (for teams that want to trade some latency for lower bandwidth usage). Hope that helps!
1 reply
0 recast
2 reactions

Jack pfp
Jack
@jmcph4
Honestly just recency bias, I only got around to reading the HotStuff paper this week
0 reply
0 recast
1 reaction