Block Settlement

Block settlement is the process in which the Validators reach an agreement and produce a chain of blocks for the Lightning Pool to finalize. The block settlement algorithm is similar to a new other chain but is built to scale. The SCRIPT blockchain uses a rotating proposer scheme wherein Validators take turns to propose new blocks for validation. To enable such rotation, each proposer maintains a local logical clock called an epoch. Assuming there are m Validators, during epoch t, the validator with index (t mod m) is elected as the proposer for that epoch. The key conditions for such a scheme are that the epoch t should not be stopped, and the epoch t of different Validators should be mostly in sync, i.e., optimally, all Validators have the same t value, so they can agree on which node should produce the next block.

How It Works?

The proposed block settlement process is based on a PBFT voting procedure. The header of each block contains a hash pointer to its parent block (the previous block in the chain), similar to the Bitcoin and Ethereum chains. Suppose neither block is an ancestor of the other, these blocks conflict. An honest Validator is required to keep all conflicting block proposals for the same epoch until one becomes settled, and all contradictory blocks are subsequently discarded.

The block settlement protocol operates from epoch to epoch. The proposer for the current epoch sends a block proposal to all Validators. A Validator reacts by broadcasting a vote for the block. All messages are signed by their senders. The header of the proposed block might carry a commit certificate, which consists of at least (2m/3+1) signed votes for its parent block. Provided that no more than m/3 Validators are faulty, at most one block per height can obtain a commit certificate, which verifies a block and its predecessors will be committed. The proposed block might carry no commit certificate if its parent block did not get ≥ 2m/3+1 signed votes.

The Validators not actively engaged in block proposals are tasked with voting upon proposed blocks. Once a Validator receives the new block, it broadcasts a signed vote to all Validators to be collected by the proposer of the next epoch to form the commit certificate. If two consecutive blocks A and B both receive a committed certificate, then the parent block A and all its predecessors are considered settled. This ensures safety, and those honest nodes never vote for a block that conflicts with a settled block.

In the case of forks (consequential to a faulty proposer or asynchrony), honest nodes are expected to vote for the blocks on the longest fork.

It’s important to note that although these are complex, they are completed automatically through our protocol.