Skip to main content

3 posts tagged with "certificate"

View All Tags

· 2 min read

Update: The Stake Distribution computation is evolving with the release of Cardano node 8.0.0: the computation now relies on the new cardano-cli query stake-snapshot --all-stake-pools command that retrieves the Stake Distribution all at once and that is way faster. Prior versions of the Cardano node 1.35+ are backward compatible and will keep implementing the algorithm detailed below.

The way the Mithril nodes retrieve the Stake Distribution is changing

PR: Fix Stake Distribution retrieval #499

Issue: Stake distribution discrepancy #497

We have noticed that the way the Mithril nodes computed the Stake Distribution was erroneous: the epoch that was used to make the computation was the current epoch instead of the previous epoch. This has lead to some de-synchronization between the Signers and the hosted GCP Aggregator for a few epochs.

Indeed, the Stake Distribution retrieved from the Cardano node depended on the time at which it was done: the nodes where having differents values that prevented them from being able to work together to produce valid multi-signatures. The problem is related to the epoch that is used (current epoch) to make the computation of the Stake Distribution when the cardano-cli query stake-distribution command is ran, whereas the Mithril protocol needs to work with the previous epoch.

A workaround is being implemented in this fix that will compute differently the Stake Distribution to target the previous epoch. To do so, the Stake value that is now retrieved sequentially for each pool available in the cardano-cli query stake-distribution by using the command cardano-cli query stake-snapshot --stake-pool-id **pool-id*. This guarantees that the Stake Distribution is computed deterministically on all nodes of the Mithril Network.

We will continue our efforts to enhance the way the Stake Distribution is retrieved in the future, and so that it works smoothly on the mainnet (where the numbers of pools is bigger ~3,000 vs ~100 on the preview network).

The SPOs need to recompile their Signer node in order to compute correctly the Stake Distributions on their node (as in this guide). It should then take up to 2 epochs before they are able to successfully register their individual signatures with the Aggregator.

More information about the Certificate Chain and the epochs retrieval requirements is available here.

Feel free to reach out to us on the Discord channel for questions and/or help.

· One min read

The way the Signers list is computed inside a Certificate on the Mithril Aggregator is changing

PR: Implement filtered Signers in Certificate #494

Issue: Record 'contributing' Signers only in Certificate #495

Before this change, the list of Signers displayed in the Certificate detail of the Mithril Explorer was the list of all eligible Signers of the epoch used for signing (those who have successfully registered with the Mithril Aggregator 2 epochs earlier).

Now that this change has been merged, the list of Signers displayed will only include the contributing Signers, which means only those who have successfully sent individual signatures.

Note that the already existing Certificates will not be updated as this would break the Certificate Chain and therefore would involve the bootstraping of a new Genesis Certificate.

This change is transparent to the Signer nodes runned by the SPOs and does not require any specific action from them.

Feel free to reach out to us on the Discord channel for questions and/or help.

· 2 min read

Update: The PR has been merged and the feature is being deployed on the GCP Mithril Aggregator.

This afternoon, we plan to merge the PR that activates the Genesis Certificate feature on the GCP Mithril Aggregator

PR: Implement Real Genesis Certificate #438

Issue: Bootstrap Certificate Chain w/ Genesis Certificate #364

This will involve some manual operations that will prevent temporarily the service to be running:

  • We will have to reset the stores of the Snapshots and Certificates. This means that the Mithril Explorer will display a No snapshot available message.

  • The Mithril Signers will have to wait until the next epoch #30 to be able to sign. This means that we should see the first available Snapshot 1 hour after the epoch transition.

The SPOs that are currently running a Mithril Signer will have to recompile their node in order ot take advantage of the latest improvements (such as the registration of the nodes that will take few minutes instead of few hours). However, the previously compiled node will be able to contribute to signatures.

In order to restore a Mithril Snapshot, a Mithril Client will now need access to the Genesis Verification Key by adding an environment variable when running: GENESIS_VERIFICATION_KEY=$(wget -q -O - https://raw.githubusercontent.com/input-output-hk/mithril/main/TEST_ONLY_genesis.vkey).

Feel free to reach out to us on the Discord channel for questions and/or help.