Mithril client npm is open to developers on npmjs.com​

The Mithril team has published the first release (v0.1.7) of its mithril-client-wasm npm package on npmjs.com.

The Mithril client npm package allows developers to use all the tooling necessary to manipulate Mithril certified types from a Mithril Aggregator directly in their (web) applications and to develop their own Mithril clients in any supported browser!

Here are some useful documentation that can be used by developers:

• Example of implementations: https://mithril.network/doc/manual/developer-docs/nodes/mithril-client-library-wasm
• Mithril client npm package repository: https://github.com/input-output-hk/mithril/tree/main/mithril-client-wasm
• npm: https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm

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

The Mithril signer node service recommended configuration is updated​

PR: Fix signer service recommended configuration #1419

Issue: Fix signer node service setup #1404

The previous recommended configuration proposed a service restart frequency which was too high. When the service was restarted, and if the Cardano node was not ready yet, the service tried to restart too many times in a short period: thus the service just failed and the service had to be started manually after the Cardano node is up and ready. This lead to some SPOs skipping registrations for some epochs.

The duration before restarting the service is increased to 60s: RestartSec=60.

Below is the new recommended configuration:

[Unit]
Description=Mithril signer service
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=60
User=cardano
EnvironmentFile=/opt/mithril/mithril-signer.env
ExecStart=/opt/mithril/mithril-signer -vvv

[Install]
WantedBy=multi-user.target
EOF'

We highly recommend to update your existing configuration file (/etc/systemd/system/mithril-signer.service) with the values specified in the guide

⚠️ Following this modification, the service needs to be restarted with the following command:

sudo systemctl restart mithril-signer

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

Mithril client library is open to developers on crates.io​

The Mithril team has published the first release (v0.5.7) of its mithril-client library on crates.io.

The Mithril client library allows developers to use all the tooling necessary to manipulate Mithril certified types from a Mithril Aggregator directly in their (Rust) applications and to develop their own Mithril clients!

Here are some useful documentation that can be used by developers:

• Developer documentation: https://docs.rs/mithril-client/0.5.7/mithril_client/
• Example of implementations:https://github.com/input-output-hk/mithril/blob/main/examples/
• Mithril client repository: https://github.com/input-output-hk/mithril/tree/main/mithril-client
• Crates.io: https://crates.io/crates/mithril-client

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

Mithril relay could expose Cardano block producer internal IP when updated (Security Advisory)​

The Mithril team has published a security advisory to destination of SPOs running a Mithril signer/relay on the mainnet infrastructure:

• Identifier: GHSA-9m3h-72xj-x2gq
• Title: Mithril relay could expose Cardano block producer internal IP when updated
• Location: https://github.com/input-output-hk/mithril/security/advisories/GHSA-9m3h-72xj-x2gq
• Severity: High (7.2/10)

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

Update 2023/07/30: The first certificates and snapshots have been produced by the release-mainnet network!

Update 2023/07/25: The Genesis certificate of the release-mainnet network has been successfully created.

Mithril Protocol’s Mainnet Beta is launched 🚀​

The Mithril team is thrilled to announce that the Mithril Protocol’s Mainnet Beta is launched 🎉

Here are the next steps that we will follow in order to get the release-mainnet network producing its first certificates:

1. Open the first signers registrations on the release-mainnet network (1 epoch).
2. Create the genesis certificate of the release-mainnet network (1 epoch).
3. Wait for the first certificates to be produced by the release-mainnet network.

This is an expected timeline, in case of modification, we will amend this post with a new one.

Also, the documentation has been updated with the configuration of the release-mainnet network. It is available here.

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

The new Mithril Signer Deployment Models for SPOs will be introduced soon​

Epic: Prepare Mithril Signer deployment model for SPO #862

⚠️ The Mithril Signer Deployment Models is not deployed yet to the pre-release-preview and release-preprod network. A special announcement will be made on the ask-mithril Discord channel when a new release candidate distribution is ready.

All these information will be available at the updated Run a Mithril Signer node (SPO) guide. In the mean time, a preview of the Mithril signer setup with the production deployment model is available here. In the new production deployment model, a new Mithril Relay has been introduced and requires an extra setup effort versus the naive deployment model that is currently ran by the pioneer SPOs on the Mithril test networks.

Here is the schema of the production deployment for the mainnet:

and the schema of the naive deployment only for the testnet:

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

Mithril client interface is evolving​

For the last few months, we have implemented the capability for the Mithril protocol to sign multiple types of data: on top of the already existing Cardano node database snapshots, the Mithril stake distribution is now also signed on its own. In order to make the client able to work on the different types of data that are certified, we have changed its command line API. For example:

$> ./mithril-client list

This command was previously used to list Cardano node snapshots. It has been abandoned in favor of a more explicit syntax:

$> ./mithril-client snapshot list

Furthermore, the old version had two different subcommands to 1. download and 2. verify a snapshot. These 2 commands have now be merged into one single download command:

$> ./mithril-client snapshot download  5109c1eaa6619bc…

This organization of the client opens the use of a new mithril-stake-distribution sub-command:

$> ./mithril-client mithril-stake-distribution list

Which can be aliased into a handy

$> ./mithril-client msd list

As for the Cardano snapshots, it is possible to download and verify the stake distribution involved in Mithril multi-signatures as a JSON file:

$> ./mithril-client msd download 713e2803e998f…

If the file certification can be verified, it is saved on the disk.

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

Update 2023/03/10: The Era Switch behavior has been activated on the release-preprod network.

Update 2023/03/08: The Era Switch behavior has been activated on the pre-release-preview network.

An new Era Switch behavior will be introduced soon to the Mithril networks​

Epic: Implement eras behavior switch #707](Implement eras behavior switch #707

⚠️ The Era Switch is not deployed yet to the pre-release-preview and release-preprod network. A special announcement will be made on the ask-mithril Discord channel when a new release candidate distribution is ready.

In order to guarantee that any breaking change of the Mithril nodes does not break the Certificate Chain and the that new snapshots are consistently produced, the Mithril team has developped an Era Switch Behavior. This mechanism enables to embed new features in the signer and aggregator nodes prior ro releasing them. Also the activation of these new features will take place in a coordinated manner: all the eligible nodes will hot switch to a new era at the same Cardano epoch transition. To do so, the nodes rely on a transaction that is stored on the Cardano chain that provides era markers with the associated activations epochs for the eras.

🔥 Activating this feature will require an update of configuration of the signer nodes after updating their binary:

• The ERA_READER_ADAPTER_TYPE env var must be set to cardano-chain
• The ERA_READER_ADAPTER_PARAMS env var must be set to the result of the command jq -nc --arg address $(wget -q -O - **YOUR_ERA_READER_ADDRESS**) --arg verification_key $(wget -q -O - **YOUR_ERA_READER_VERIFICATION_KEY**) '{"address": $address, "verification_key": $verification_key}' (the YOUR_ERA_READER_ADDRESS and YOUR_ERA_READER_VERIFICATION_KEY are values provided in the networks configuration matrix)

Here is the configuration values that should be used on pre-release-preview:

ERA_READER_ADAPTER_TYPE=cardano-chain
ERA_READER_ADAPTER_PARAMS={"address":"addr_test1qrv5xfwh043mlc3vk5d97s4nmhxu7cmleyssvhx37gkfyejfe8d38v3vsfgetjafgrsdc49krug8wf04h5rmtengtejqlxrksk","verification_key":"5b35352c3232382c3134342c38372c3133382c3133362c34382c382c31342c3138372c38352c3134382c39372c3233322c3235352c3232392c33382c3234342c3234372c3230342c3139382c31332c33312c3232322c32352c3136342c35322c3130322c39312c3132302c3230382c3134375d"}

Here is the configuration values that should be used on release-preprod:

ERA_READER_ADAPTER_TYPE=cardano-chain
ERA_READER_ADAPTER_PARAMS={"address":"addr_test1qpkyv2ws0deszm67t840sdnruqgr492n80g3y96xw3p2ksk6suj5musy6w8lsg3yjd09cnpgctc2qh386rtxphxt248qr0npnx","verification_key":"5b35352c3232382c3134342c38372c3133382c3133362c34382c382c31342c3138372c38352c3134382c39372c3233322c3235352c3232392c33382c3234342c3234372c3230342c3139382c31332c33312c3232322c32352c3136342c35322c3130322c39312c3132302c3230382c3134375d"}

All these information will be available at the updated Run a Mithril Signer node (SPO) guide.

Here is a schema that illustrates the era switch behavior:

More information is also available at this ADR.

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

Mithril follows a defined release process​

As the Mithril project grew and more and more SPOs became involved in testing Mithril, it became obvious we need clearer identification of artifacts running on various parts of the network. Moreover, on our road towards mainnet availability we'll need to strengthen our testing process in order to validate Mithril network on more realistic environments.

Release Process​

We want our release process to follow some basic principles:

• Continuous Integration: New code is integrated into the main codeline frequently which triggers automated build and test process.
• Continuous Deployment: New artifacts produced by the build process are continuously deployed to a suitable environment where it can be used and tested by an increasing number of parties.
• Deployment Pipeline: The deployment process is embodied in a pipeline that describes and implements all the necessary steps to release a new version of Mithril.
• Artifact Promotion: An artifact is built once and only once and is promoted while travelling through the build pipeline.

Here is a high-level picture of this process:

• We will use a custom version based on SemVer for all the crates, binaries and containers of the repository and for the GitHub release.
• We release a new distribution every 2 weeks (this duration is subject to changes as the project matures)
  • The released version is named after the year and its week number: YYWW.patch (e.g. 2250.0).
  • In case of critical regressions happening in production, a patch version will be released in between "official" releases as a hotfix.
• A new version YYWW.0 will have the following life cycle:
  • A commit abc123 merged on main branch is deployed on the network named testing-preview.
  • A commit def456 tagged with YYWW.0-prerelease is deployed on the network named pre-release-preview.
  • A GitHub release YYWW.0-prerelease is created and linked with the YYWW.0-prerelease tag and marked as pre-release.
  • A tag YYWW.0-prerelease is qualified and selected for release or rejected (and replaced by a YYWW.1-prerelease tag if necessary on a fed789).
  • If the tag YYWW.0-prerelease is selected, a new tag is created and name YYWW.0 on the same commit def456.
  • A GitHub release YYWW.0 is created and linked to the YYWW.0 tag and marked as release.
  • The commit def456 with tag YYWW.0 is deployed to the network named release-preprod.
• The Cargo.toml versions of the crates are updated (if required) just before creating the YYWW.0-prerelease tag .
• The documentation website is also updated at the same time where the next version becomes the current version, leaving future updates be appended to the next version during the upcoming developments.
• In order to simplify the life of Mithril users, we have introduced a version of the Mithril API used between client/signer and aggregators to check if the nodes are able to communicate together (following semver and considering the versions are compatible only if they share the same minor).
• Our main distribution artifact is currently docker (OCI) images. We also provide more packages, eg. .deb packages or compiled binaries (some of them available on multiple platforms, e.g. Windows or macOS) to simplify users' life.
• We also publish some of our crates on the crates.io registry whenever a new version is created (e.g. mithril-stm).

Networks​

• We maintain different Mithril networks (eg. servers, VMs, configurations...) to which artifacts are deployed at various stages of the process:
  • testing-preview: This is an internal environment based on the preview cardano testnet where most of the automated tests happen. It is also used to test features as soon as they are merged on the main branch.
  • pre-release-preview: This is a persistent environment based on the preview cardano testnet. SPOs which are active on preview are welcomed to take part in the Mithril signing process and to test new pre-release distributions deployed there.
  • release-preprod: Another persistent environment, based on the preprod cardano testnet, where more SPOs are expected to join and test, updated less frequently (on actual release distributions).
  • (LATER) mainnet: Production environment where new releases are deployed once qualifed on release-preprod.

Further Reading​

• The Mithril developers have redacted an ADR Release process and versioning that also describes more technically this process.

The Mithril environments are updated​

PR: New hosted environments #561

Issue: Setup new hosted environments for testing-preview, pre-release-preview and release-preprod) with their terraform and GitHub environments #542

On Tuesday, November 1st, 2022 the preview Cardano network will be re-spun and will be unavailable for 48h.

In the mean time, the Mitril team is also implementing a new Release Process that will make use of several new environments.

The Mithril testing environments are thus evolving in this context:

• The current testing environment that runs on preview network and that most of the Pioneer SPOs are running is deprecated and will be decommissioned just after the preview network re-spin.

• This environment will then be replaced by a new pre-release-preview environment open to SPOs that are eager to test pre releases of the Mithril nodes.

• A new release-preprod environment has been launched on the preprod Cardano nework and will become the stable environment on which SPOs are encouraged to run their nodes.

• ⚠️ The new release-preprod environment is in unstable status, therefore it is subject to re-genesis. We expect it to be in stable status within 1-2 weeks.

In the future, when Mithril reaches mainnet, we assume that the release-preprod will be replaced by a release-mainnet environment. This means that we will have the following environments at this time: testing-preview, pre-release-preprod and release-mainnet.

More information about:

• The Mithril Networks and their availability here.

• The Release Process is available in this ADR.

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