goshawk-3

> Modification to Peer Response Behavior: Currently, a peer ignores a request_block if it does not have the requested block. We propose that instead of ignoring the request, the peer...

**Additional context:** In case of a consensus split, the number of nodes that do not know the `requested` block (that belongs to the `main branch`) is usually high.

> the new consensus protocol will use a "naive" definition of rolling finality: after N Attested blocks, we finalize all previous non-finalized blocks. Do you mean N Attested Blocks in...

What you're proposing is what we already have with so called Agreement Loop. Agreement loop has `collect_inbound_msg` (behaves as `on_event`) handler that waits for an Agreement that can originate from...

> The main change I would do, a part from change naming, would be to implement the handler not as a consensus step. Current implementation has an agreement_msg handler that...

Confirmed! Running it locally showed the bottleneck is probably in `verify_block_header` but also `abort_and_wait` should be taken into account. This needs to be cpu-profileed and eventually optimized. Bootstrapping of 30...

 CPU-profiling data attached proves that the bottleneck is in APK::aggregate.

Certainly. Yes, each certificate contains two signatures, and a block can have anywhere from two to (RELAX_ITERATION_THRESHOLD+2) certificates. In simpler terms, we can anticipate a block having between 4 and...

FYI @fed-franz @herr-seppia What is your opinion on the second approach? ``` Another approach could be: Add a master key (Dusk Block Generator) in the Genesis state. This key is...

> > FYI @fed-franz @herr-seppia What is your opinion on the second approach? > > What if that generator is missing? > > Another solution could be: > > *...