Help with a simple proof of Authority example based on LocalMiner.

[andy-thomason]

To all consensus buffs out there - I'm writing a little POA consensus example - I could contribute this when it is done but would appreciate some help in understanding the engine API.

We have one block producer node based on LocalMiner which does the following using ConsensusEngineHandle

• Call fork_choice_updated with the current head and PayloadAttributes to get a payload id.
• Use the payload id with new_payload to create a new block.
• From time to time call fork_choice_updated with no attributes on the current head.

What would be the corresponding flow for a follower node? I'm guessing that we would only have to share the block hash from the new payload and call fork_choice_updated, but I've had some cases where fork_choice_updated is stuck in the Syncing status on one or more nodes.

[mattsse]

what could work here if you write a simple delegate script that does

• subscribe newHeads on leader
• submits FCU{newhead} to follower
• and peer leader with follower over p2p

the last step is important, you can wire them with trusted-peers for example

another option could be wiring the follower to the leader with

reth/crates/node/core/src/args/debug.rs

Lines 40 to 47 in 5f38ff7

	/// Runs a fake consensus client using blocks fetched from an RPC `WebSocket` endpoint.
	#[arg(
	long = "debug.rpc-consensus-ws",
	help_heading = "Debug",
	conflicts_with = "tip",
	conflicts_with = "etherscan"
	)]
	pub rpc_consensus_ws: Option<String>,

so that it pulls the blocks from the leader over rpc

[andy-thomason]

Thanks @mattsse I should have spotted this before.

I'll take a look at the logic of DebugConsensusClient which seems to be exactly the droid I'm looking for.