Description
Our current signature thresholds are per-node, and static for the lifetime of the node. They allow an operator to coarsely trade-off latency and throughput, with rare signatures supporting high throughput at the cost of high latency (small fraction of time spent signing, long waits between signatures), and frequent signatures offering lower latency at the cost of throughput (shorter waits to the next signature, more execution time spent signing).
There are many workloads where this is insufficiently precise to meet low latency targets. In particular if latency-sensitive transactions are rare, there's no way to efficiently support that at the moment - either every transaction produces wasteful signatures, or the latency-sensitive transactions wait for an amortisation threshold designed for less-sensitive transactions.
A simple solution to meet this kind of workload, would be to allow the application handler to explicitly request a signature immediately once this transaction had committed. The transaction-count based trigger is already in the Frontend flow at this point - we could add an app-controlled flag to trigger this as well.
A related point is that we should revisit how the Raft AppendEntries batching works. This may introduce unhelpful, and uncontrollable, delays, in pessimal cases. We may be able to build simpler batching logic, and guarantee immediate flushes on each signature transaction.
Activity