Summary Block

This page is still work in progress

The first block in each epoch is a summary block. A summary block contains special data that will be used to manage the shares of the various threshold signature schemes. There are two threshold schemes:

• one (f + 1)-out-of-n scheme, for which a new signing key is generated every epoch;
• one (n − f )-out-of-n scheme, for which the signing key is reshared once every epoch.

The low-threshold scheme is used for the random beacon and the random tape, while the high-threshold scheme is used to certify the replicated state of the subnet.

The Distributed Key Generation (DKG) protocol requires that for each signing key, we have a set of dealings, and that each replica can non-interactively obtain its share of the signing key from this set of dealings. Also recall that NNS maintains a registry that, among other things, determines the membership of a subnet. The registry (and hence the subnet membership) may change over time. Thus, subnets must agree on which registry version they use at various times for various purposes. This information is also stored in the summary block. The summary block for epoch i contains the following data fields.

• currentRegistryVersion. This registry version will determine the consensus committee used throughout epoch i — all tasks performed by the consensus layer (block making, notarization, finalization) will be performed by this committee.
• nextRegistryVersion. In each round of consensus, a block maker will include in its proposal the latest registry version it knows about (which must be no earlier than the block the proposed block extends). This ensures that the value nextRegistryVersion in the summary block of epoch i is fairly up to date.

The value of currentRegistryVersion in epoch i is set to the value of nextRegistryVer- sion in epoch i − 1.

• currentDealingSets. These are the dealing sets that determine the threshold signing keys that will be used to sign messages in epoch i.

As we will see, the threshold signing committee for epoch i (i.e., the replicas that hold the corresponding threshold signing key shares) is the consensus committee for epoch i−1.

• nextDealingSets. This is where dealings that are collected during epoch i − 1 are gathered and stored.6 The value of currentDealingSets in epoch i will be set to the value of nextDealingSets in epoch i − 1 (which itself consists of dealings collected in epoch i − 2).
• collectDealingParams. This describes the parameters that define the dealing sets to be collected during epoch i. During epoch i, block makers will include dealings in their proposed blocks that are validated relative to these parameters.

The receiving committee for these dealings is based on the nextRegistryVersion value of the summary block of epoch i. For the low-threshold scheme, the dealing committee is the consensus committee for epoch i. For the high-threshold scheme, the shares to be reshared are based on the value of nextDealingSets of epoch i. Therefore, the dealing committee is the receiving committee for epoch i − 1, which is also the consensus committee for epoch i . Also observe that the threshold signing committee for epoch i is the receiving committee in epoch i − 2, which is the consensus committee for epoch i − 1 .