Difference between revisions of "Catch-Up Package"

From Internet Computer Wiki
Jump to: navigation, search
 
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
A 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:
+
= This Page is Still Work in Progress =
* The root of a Merkle hash tree for the entire replicated state (as opposed to the partial, per-round certified state as in Section 6.1).
+
 
* The summary block for the epoch.
+
== 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 [https://wiki.internetcomputer.org/wiki/Replicated_state_structure entire replicated state] (as opposed to the partial, per-round certified state).
 +
* The [https://wiki.internetcomputer.org/wiki/Summary_Block summary block] for the epoch.
 
* The random beacon for the first round of 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.
 
* 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 [https://github.com/dfinity/ic/blob/master/rs/types/types/src/consensus/catchup.rs github].
 +
 +
== 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 ===
 +
[[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]'''

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

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

Consensus proceeds until cup 1.png Consensus proceeds until cup 2.png

When Recovering Faulty Subnet

Starting a Node from Catch-Up Package

See Also