# Reduce block time tasks breakdown

**Disclaimer**: these optimisations are mainly intuition-based and must be treated as such by being confirmed both by observations and by a candidate fix.

## Task: Dissociate block production from block injection

Assignees: Albin & Ryan (& Vincent?)

Estimated difficulty: 2.7/5
Estimated PoC time: 2 weeks

Each new block production starts at the exact beginning of each
Tenderbake round. However, depending on the signer's delay and the
computation required to produce a block, produced blocks may result in
being injected in their local node later in the round: usually 1s and
2s since the round's start. Hence, the consensus game for this block
is effectively delayed by this much delay.

The idea of this task is to adapt the baker in order to allow it to
prepare a block slightly *before* the start of the consensus round; as
long as the conditions for production are met (i.e., consensus for the
previous block is reached). The injection itself, however, must be
done after the start of the round otherwise the block will be
considered "in the future" by the node and dismissed. This delay
should be either hard-coded, e.g., 1/5th of a consensus round
duration, 2s, ... or determined empirically during the baker
initialization by simulation how much time the baker needs to validate
a block and produce a signature for it.

Future work: this approach may also be generalized to (pre)attestation
production.

## Task: Make persistent consensus states optional

Assignees: Gabriel & Albin

Estimated difficulty: 1.6/5
Estimated PoC time: 1 week

Every time a consensus baker commits to a value, for instance,
whenever a vote quorum is reached, the baker saves all the necessary
information that's related to this event to be capable of providing
the proof that we indeed reached this event. Saving this state means:
waiting to acquire a concurrent mutex, serializing this proof to
binary and performing the I/O to write this value on disk. The last
part is especially costly and, has a side-effect to retain the mutex
for a extended period of time, potentially slowing down other
components.

As the persistent-state mechanism is a way to provide a strong
guarantee with regards to the consensus algorithm, the idea of this
task is to relax this inexpensive security mechanism and to only
maintain the proof in memory. Crashed and restarted bakers would reset
their state but this is a reasonable compromise. Achieving this should
disable most of the inexpensive I/Os and increase the overall
performance in the baker.

## Task: Disable pipelining safety nets

Assignees: Andrea & Vincent

Estimated difficulty: 3/5
Estimated PoC time: 2 weeks
Depends on 'Make persistent consensus states optional'

One of the outcomes of the Pipelining project was to speed up the
consensus vote start by an early notification to the baker that a
**valid** block arrived. This notion of validity for blocks states
that this block will correctly be **applied** and the chain will be
able to progress with it. However, as this safety property is
guaranteed by tests only, it is not a fully safe one. Hence, we left
some safety-nets to make sure that even if this property was broken,
it would still be possible to unlock the chain by discarding a faulty
transaction, for example. One of the safety net is to delay the start
of the second consensus vote (attestations) and, more importantly,
wait to *lock* our consensus state on this specific block. This safety
net's delay consists of waiting from the node the confirmation that
the block was successfully applied. As gas-heavy blocks may take
several seconds to be applied, the second consensus votes would be
delayed by as much.

The task then consists of removing this safety net. This concerns the
attestation production only: in order to produce the next level block,
we still need to make sure that the node correctly applied its
predecessor. To be fully integrated, this task depends on the previous
one as, if the pipelining property broke and we were not protected by
this safety net, halting the chain would not require asking bakers to
delete internal files but it would simply require them to restart
their bakers to make the chain recover.