Below is a simulation of HotStuff, a Byzantine fault-tolerant consensus algorithm. Usually consensus algorithms order transactions, or commands to modify a shared state. For visual simplicity, here we are ordering a sequence of coloured blocks to form a rainbow. Each circle represents one node. The protocol proceeds in rounds. In each round there is a leader (shown in purple), who can propose a new colour for the rainbow, extending some previously proposed colour. Blue nodes are replicas, who vote on proposals from the leader. You can configure networking reliability, timeouts, and firewall rules. Hovering over a control will show additional instructions for what it does. Clicking on a node will show its view of the current state (rainbow) and allow configuring individual settings. The default settings are for a healthy network: all proposals will succeed and the state will look like a flat list with no forks. By adjusting the controls, you can force some rounds to fail or isolate some nodes from the network. This will result in competing proposals for the next colour in the rainbow (forks in the state). Have fun! import HotStuffCanvas from "../../components/HotStuffCanvas" /* can't be near top else will appear in summary text */ <HotStuffCanvas client:only="react" /> <br/> ### Nerdy Technical Details The simulation implements [HotStuff 1](https://arxiv.org/abs/1803.05069). It uses a 3-chain finalization rule with a passive constant-timeout pacemaker. This is the same algorithm (though a very different implementation of course) originally used in [Flow](https://flow.com/), except for the pacemaker. Flow used a more sophisticated exponential-backoff pacemaker. Flow was upgraded to use the [Jolteon](https://flow.com/engineering-blogs/jolteon-advancing-flows-consensus-algorithm) algorithm with an active pacemaker in 2023. The number of tick marks around each node show the current round, modulo 10. Although there can only be one valid leader for each round, you may notice multiple nodes can be purple at the same time. This is because each node has its own view of the world, which depends on what messages it has received at a given time. So nodes transition between rounds at different times. When there is more than one leader, it means those nodes are in different rounds. The simulation uses a very simple synchronization mechanism. If a node receives a proposal for which it does not know the parent, it will send a sync message to one other node at random (displayed as a ?). That node will then respond with a list of all its known un-finalized proposals (displayed as 4 small coloured blocks).

There are many optimizations that can be made to consensus "followers"--nodes that observe but do not participate in consensus. While making large changes to Flow's consensus to implement [Jolteon](/blog/2023-04-23-jolteon-upgrade), we took the opportunity to implement many of these optimizations at the same time. The article discusses these changes, with a focus on how they enable extremely low-resource light clients.

Jolteon is an extension to HotStuff that reduces time-to-finality and improves failure recovery. In addition to summarizing Jolteon's algorithmic changes, the article aims to provide a high-level intuition for how the HotStuff family of consensus algorithms work more broadly.

Dapper Wallet was one of the first smart contract wallets on Ethereum, and was designed to make using blockchain applications easier. This article discusses the product features and goes fairly deep in the weeds on the technical design.