Latest revision as of 10:25, 27 February 2023

This Page is Still Work in Progress

Structure of Catch-Up Package

A Catch-Up Package (CUP) is a special message (not on the blockchain) that has (mostly) everything a replica needs to begin working in a given epoch, without knowing anything about previous epochs. It consists of the following data fields:

The root of a Merkle hash tree for the entire replicated state (as opposed to the partial, per-round certified state).
The summary block for the epoch.
The random beacon for the first round of the epoch.
A signature on the above fields under the (n − f)-out-of-n threshold signing key for the subnet.

To generate a CUP for a given epoch, a replica must wait until the summary block for that epoch is finalized and the corresponding per-round state is certified. As already mentioned, the entire replicated state must be hashed as a Merkle tree — even though a number of techniques are used to accelerate this process, this is still quite expensive, which is why it is only done once per epoch. Since a CUP contains only the root of this Merkle tree, a special state sync subprotocol is used that allows a replica to pull any state that it needs from its peers — again, a number of techniques are used to accelerate this process, but it is still quite expensive. Since a high-threshold signature is used for a CUP, it is assured that there is only one valid CUP in any epoch, and moreover, there will be many peers from which the state may be pulled. Also, since the public key of the threshold signature scheme remains constant over time, the CUP can be validated without knowing the current participants of the subnet.

The code to manage the Catch-Up Package can be found on github.

Use Cases of Catch-Up Package

Subnet Creation

@@ Line 1: / Line 1: @@
-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:
+= This Page is Still Work in Progress =
-* 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.
+== Structure of Catch-Up Package ==
-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.
+A Catch-Up Package (CUP) is a special message (not on the blockchain) that has (mostly) everything a replica needs to begin working in a given epoch, without knowing anything about previous epochs. It consists of the following data fields:
-The summary block for epoch i contains the following data fields.
+* The root of a Merkle hash tree for the [https://wiki.internetcomputer.org/wiki/Replicated_state_structure entire replicated state] (as opposed to the partial, per-round certified state).
-* 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.
+* The [https://wiki.internetcomputer.org/wiki/Summary_Block summary block] for the epoch.
-* 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 random beacon for the first round of the epoch.
-The value of currentRegistryVersion in epoch i is set to the value of nextRegistryVer- sion in epoch i − 1.
+* A signature on the above fields under the (n − f)-out-of-n threshold signing key for the subnet.
-* 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.
+To generate a CUP for a given epoch, a replica must wait until the summary block for that epoch is finalized and the corresponding per-round state is certified. As already mentioned, the entire replicated state must be hashed as a Merkle tree — even though a number of techniques are used to accelerate this process, this is still quite expensive, which is why it is only done once per epoch. Since a CUP contains only the root of this Merkle tree, a special state sync subprotocol is used that allows a replica to pull any state that it needs from its peers — again, a number of techniques are used to accelerate this process, but it is still quite expensive. Since a high-threshold signature is used for a CUP, it is assured that there is only one valid CUP in any epoch, and moreover, there will be many peers from which the state may be pulled. Also, since the public key of the threshold signature scheme remains constant over time, the CUP can be validated without knowing the current participants of the subnet.
-* 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 code to manage the Catch-Up Package can be found on [https://github.com/dfinity/ic/blob/master/rs/types/types/src/consensus/catchup.rs github].
-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.
+== Use Cases of Catch-Up Package ==
-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 .
+=== Subnet Creation ===
+=== Protocol Upgrades ===
+=== Adding New Nodes to a Subnet ===
+=== Recovering a Failed Node ===
+=== Recovering a Failed Subnet ===
+== Generation of Catch-Up Package ==
+=== During Subnet Creation ===
+=== During Consensus ===
+[[File:Consensus proceeds until cup 1.png|700px|frameless]]
+[[File:Consensus proceeds until cup 2.png|700px|frameless]]
+=== When Recovering Faulty Subnet ===
+== Starting a Node from Catch-Up Package ==
+==See Also==
+* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

Difference between revisions of "Catch-Up Package"

Latest revision as of 10:25, 27 February 2023

Contents

This Page is Still Work in Progress

Structure of Catch-Up Package

Use Cases of Catch-Up Package

Subnet Creation

Protocol Upgrades

Adding New Nodes to a Subnet

Recovering a Failed Node

Recovering a Failed Subnet

Generation of Catch-Up Package

During Subnet Creation

During Consensus

When Recovering Faulty Subnet

Starting a Node from Catch-Up Package

See Also