Difference between revisions of "Catch-Up Package"
From Internet Computer Wiki
| (14 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= This Page is Still Work in Progress = | = 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: | 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 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 [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 | + | 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]. | 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
When Recovering Faulty Subnet
Starting a Node from Catch-Up Package
See Also
- The Internet Computer project website (hosted on the IC): internetcomputer.org