With the previous launch of Instant Finality, we decreased the confirming time for cross-shard and trade transactions. The producing block is guaranteed to be finalized in several scenarios as discussed in this post Introducing Instant Finality.
In some circumstances, when block finality can not be guaranteed, more blocks must be created to have instant finality. In the unshielded flow, regardless of whether the block is finalized or not, funds will be released for users in the bridge if there are enough signatures. So, there is a possibility that the fork shard and fork beacon will lead to 2 branches that one of which confirms the unshield transaction, while the other does not. That explains why all unshield transactions from shard currently need to be delayed to generate proof until the beacon block (confirming that shard block) is finalized.
To confirm unshield tx faster (immediately at the same block), we modify our beacon consensus protocol to work as Tendermint Consensus protocol. The tradeoff is we need one more phase, total of 4 instead of 3 as in our multiview version. The basic idea is:
- The protocol has 4 phases: propose, prevote, vote, and commit.
- Propose: Proposer will propose its block if current time is in his timeslot.
- Prevote: Validators receive,validate the block and send prevote message.
- Vote: if there are â…”+ valid prevotes, then the validators send vote message. It also locks the blockhash, so that it will not send prevote for other blockhash which has the same height.
- Commit: if â…”+ valid vote is received, then validators commit the block (store to database).
In addition, we implement “Proof-of-lock-change” (POLC) to prevent deadlock, as some nodes could be locked for certain blockhash, and cannot make the chain continuous.
POLC is the list of prevote signature, which indicates there is â…”+ prevote for a blockhash at certain timeslot (for Tendermint it is round)
When a validator is locked for blockhash A and timeslot T, it is still permitted to send prevotes for a new blockhash B if the proposer can provide a valid POLC, which indicates block B has â…”+ prevote at timeslot T+x.
Please refer Tendermint protocol for more understanding of our protocol. https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html#consensus-overview
When this feature is triggered, we can guarantee the created beacon block is finalized and there is no other block that can revert the blockchain state. Consequently, we now can process the unshield instruction in the same beacon block, immediately providing proof to unshield assets.
As a result, there is a 1 block time reduction in the time it takes from the unshield request being sent to its arrival at the destination chain.