In the rst case, the Linera client must upload missing certicates in the chain id (and possibly its ancestors) as described in the previous paragraph, until next-heightid() > n. In the second case, the client must upload missing certicates in the chains that have sent the messages m I to id. When B has been correctly constructed (i.e. is not trying to receive messages that were never sent), the set I is necessarily covered by the certicates listed in the union receivedid() where ranges over any quorum of validators.

Importantly, uploading a missing block to a validator benets all clients. To maximize liveness and decrease the latency of their future operations, in practice, it is expected that users proactively update all the validators when it comes to their own chains, therefore minimizing the need for synchronization by other clients. However, the possibility of synchronization by everyone is important for liveness. It also allows a certicate to act as a proof of nality for the certied block. In practice, a client should execute the optional synchronization step ( 0 ) and the voting step ( 1 ) on a separate thread for each validator. To prevent denial-of-service attacks from malicious validators, a client may stop synchronizing validators as soon as enough votes are collected ( 2 ).

The steps 1 2 3 used to decide a new block in a single-owner chain constitute a 1.5 round-trip protocol. Inspired by reliable broadcast, this protocol does not have a notion of view change to support retries. In other words, a chain owner that has started submitting a (valid) block proposal B cannot interrupt the process to propose a dierent block once some validators have voted for B. Doing so would risk blocking their chain. For this reason, Linera also supports a variant with an extra-round trip (Section 2.9).

2.9 Extensions to the core protocol We now sketch a number of important extensions to the core Linera multi-chain protocol. Permissioned chains. The protocol presented in Section 2.8 allows extending a singleowner microchain optimistically in 1.5 client-validator round trips. Linera also supports a more complex protocol with 2.5 round trips to address the following use cases: A single chain owner wants to be able to safely interrupt ongoing block proposals while they are in progress. Operations in blocks depend on external oracles (e.g. Unix time) and include conditions that may become invalid after being valid. Multiple owners wish to operate the chain (assuming minimal o-chain coordination). A single chain owner wishes to delegate maintenance operations related to validator recongurations. We omit the details of the 2.5 round-trip protocol for brevity. It can be seen as a simplied partially-synchronous BFT consensus protocol with view changes (aka rounds) but 13