feat(consensus): add opt-in asynchronous block event publication - #6040

Summary

Block events are currently published synchronously at the end of ApplyBlock. For blocks containing many transactions, event construction and publication remain on the consensus critical path.

Increasing event_bus_buffer_capacity reduces subscriber backpressure, but does not remove this processing cost from ApplyBlock.

This issue was previously observed in crypto-org-chain#4 (comment), where profiling showed synchronous fireEvents delaying block execution. That observation motivates this work, while the benchmarks added by this PR provide reproducible evidence across controlled scenarios.

This PR adds opt-in asynchronous block event publication while preserving the existing synchronous behavior by default. Block-event tasks are processed in submission order through a bounded serial runner, and accepted work is drained before the EventBus and indexer are stopped.

Event ordering

When asynchronous publication is enabled, block events may temporarily lag behind block execution and other synchronously published EventBus events.

FIFO ordering is preserved between queued block-event tasks. However, global ordering across different EventBus publishers is not guaranteed. For example, after the block events for height H are queued, consensus may publish NewRoundStep for height H+1 before clients receive NewBlock or transaction events for height H.

This does not affect consensus, block execution, or persisted state. Event consumers using asynchronous mode should rely on event heights and must not assume delivery order across different event types.

Benchmarks

The benchmarks compare synchronous and asynchronous publication across several scenarios:

• Blocks with 0, 100, and 1,000 transactions, showing how publication cost scales with block size.
• A delayed event publisher, showing the impact of slow event processing on ApplyBlock.
• The real EventBus with unbuffered, indexer-style consumers.
• EventBus capacities of 0, 128, 1,024, and 2,048, covering both subscriber backpressure and sufficiently buffered publication.

The most relevant case uses 1,000 transactions and an EventBus capacity of 2,048. The buffer can hold all 1,003 events emitted for the block, so EventBus backpressure is not the bottleneck.

Representative results on Apple M4:

This reduces the measured ApplyBlock critical-path time by approximately 3.5–4x, demonstrating that increasing the EventBus buffer alone does not eliminate the benefit of asynchronous publication.

This optimization moves event processing out of the consensus critical path. It does not reduce the total event-processing work, and event consumers may temporarily lag behind block execution.

Testing

Unit and lifecycle tests cover:

• Synchronous publication remaining the default.
• FIFO asynchronous block-event processing.
• Block events potentially arriving after later synchronous EventBus publications.
• Draining accepted work during shutdown.
• Keeping the EventBus available until queued work completes.

go test ./consensus ./state ./node

PR checklist

• Tests written/updated
• Changelog entry added in CHANGELOG.md
• Updated relevant documentation (docs/ or spec/) and code comments