Skip to main content

· 2 min read
Sebastian Nagel

High-level summary​

This week, the Hydra team spent significant time opening a head among themselves on mainnet using the release candidate, revealing and addressing lurking bugs such as #1174. Also required was this change to dynamically calculate the min utxo value #1176, a necessary adjustment following the switch to inline datums. The team engaged with cardano-cli / cardano-api maintainers to discuss recent changes and collaborated on drafting feature ideas, including providing Conway support for the Hydra roadmap. As part of ongoing improvements, they experimented with writing the specification in markdown instead of LaTex.

What did the team achieve this week​

  • Opened head among us on mainnet and uncovered a few lurking bugs like #1174 in the release candidate
  • Calculate the min utxo value instead of hard-coding it #1176, which is needed since we switched to inline datums.
  • Met with the cardano-cli / cardano-api maintainers to discuss recent changes and way forward
  • Drafted features ideas to provide Conway support on the Hydra roadmap
  • Experimented in writing the specification in markdown instead of LaTex

What are the goals of next week​

  • Have the Monthly review meeting with several demos
  • Release version 0.14.0 with this scope
  • Complete tidying up chain layer via stateless observation changes in hydra-node #1096
  • Update dependencies to prepare for Conway #1114

· 4 min read
John Lotoski

High level summary​

The SRE team continues work on cardano environment improvements and general environment maintenance.

Some notable recent changes, updates or improvements include:

  • The cardano-node nixos service now supports SIGHUP p2p topology reloading when the useSystemdReload option is enabled

Lower level summary​

Capkgs​

  • Update cardano-db-sync and offchain-metadata-tools package paths and/or references: capkgs-compare

Cardano-node​

  • Optionally have cardano-node nixos service utilize SIGHUP p2p topology reload: cardano-node-pull-5537
    • Creates a useSystemdReload bool option for the cardano-node nixos service
    • This will move the topology file(s) to /etc/cardano-node/topology-$i.yaml and inject systemd reload hooks for p2p configured cardano-node instances
    • Moving topology files to /etc also allows for manual topology updates when a quick test is needed and full service re-deployment isn't desired

Cardano-parts​

  • Adds a metadata server profile and a number of other features and improvements: cardano-parts-pull-20
    • Adds a new metadata-service profile
    • Adds metadata service and pkg configuration options for cardano-groups to utilize the metadata-server profile
    • Adds a cardano-webserver profile for multiple virtualHosts and TLS ACME server aliases for a cluster's static needs, with each cached behind varnish
    • Adds extra node list producers and public producers for cardano-node-topology profile
    • Adds delegation amounts to cardano-postgres psql prepared query show_pools_block_history_in_epoch
    • Adds select systemd metrics reporting to grafana-agent profile
    • Adds a bookRelay multivalue DNS option to disambiguate with groupRelay multivalue DNS
    • Adds an opsLib library to the cardano-parts lib flakeModule and refactors some common code into it
    • Adds support for sops secret traversing from target path up instead of cwd up, thereby supporting secrets use-cases outside of the repo
    • Adds job-gen-env-config for both release and pre-release configuration files to support configuration book generation
    • Adds support for grafana recording rules in the template files
    • Improves cardano-group profile handling of producers with respect to multiple instance nodes
    • Improves grafana-agent profile metrics handling for multi-instance cardano-node servers
    • Improves smash service preStart handling while waiting for a node socket
    • Updates Justfile for ERA_CMD demo support
    • Migrates default grafana cloud node exporter, varnish alert and recording rules to grafana alert and recording rule templates
    • Defaults to using an updated systemd reload nixos service feature for p2p networks in cardano-group profile
    • Defaults cardano-postgres profile psqlrc use to false

Cardano-playground​

  • Adds a new testnet metadata server, cluster webserver, and other improvements: cardano-playground-pull-6
    • Adds a new metadata server
    • Adds a new webserver for the cluster's static virtualhost needs
    • Adds support for sops secret traversing from target path up instead of cwd up, thereby supporting secrets use-cases outside of the repo
    • Adds systemd metrics monitoring to the cluster
    • Resizes sanchonet machines to support the growing chain
    • Completes migration of preprod from world
    • Updates groups to utilize both bookRelay and groupRelay multivalue DNS attributes
    • Updates Justfile for ERA_CMD demo support
    • Defaults to using an updated systemd reload nixos service feature for p2p networks in cardano-group profile
    • Migrates book static code to playground from world, with refactor, cleanup and updates
    • Migrates default grafana cloud node exporter, varnish alert and recording rules to declarative grafana alert and recording rules

Offchain-metadata-tools​

  • Adds db password option with obfuscation plus misc improvements: offchain-metadata-tools-pull-61
    • Adds db password connection option and obfuscates passwords in output for metadata server, sync, webhook services
    • Updates the nixos service for metadata-webhook service to optionally use an environmentFile for secrets: cfg.environmentFile
    • Moves from std use in the nix flake to standard flake schema
    • Fixes hydra CI failures
    • Builds update-docs in hydra to avoid long local build times
    • Removes deprecated tullia
    • Removes deprecated check-hydra from pkgs
    • Removes deprecated bors files and references

· 2 min read
Alexey Kuleshevich

High level summary​

Last two weeks progress was mainly on testing, bug fixes and improvements to clarity of CDDL specification. Important bugfixes include:

  • Fix deserialization of ValueNotConservedUTxO predicate failure that could not previously report zero ADA.
  • Fix deserialization of CostModels in the PParamsUpdate. Invalid CostModels are no longer allowed, only CostModels for unrecognized Plutus versions are allowed starting with Conway
  • Fix returning of Deposits for ProposalProcedures

Testing tooling has been improved and new tests have been implemented for Conway era.

Low level summary​

Conway​

  • pull-3858 - Restructure computing Refunds and Deposits in a TxBody across all eras
  • pull-3860 - Removed mock/crypto.cddl, added optional tag to sets
  • pull-3864 - Fix Proposal deposits and add deposit tests to imp tests
  • pull-3859 - Rename ProposalsSnapshot to Proposals
  • pull-3867 - MaryValue fixes
  • pull-3869 - Indicate that tag 258 is optional for OSet. Fix rational CDDL
  • pull-3863 - Improve deposits refunds re-usability
  • pull-3861 - Fail PParamsUpdate deserialization for invalid costmodels in Conway
  • pull-3875 - Fix cddl spec for CostModels in Conway
  • pull-3876 - Change 4 PParam fields from EpochNo to EpochInterval
  • pull-3884 - Relax requirement on the Set tag 258 to be enforced in the next era

Testing​

  • pull-3868 - Improvements to support property tests on Traces with simple Tx with DRep related Certs
  • pull-3792 - RATIFY and GOV constraint tests
  • pull-3885 - Added a test for genTxAndNewEpoch
  • pull-3886 - QuickCheck Imp integration

Improvements and releasing​

· One min read
Jean-Philippe Raynaud

High level overview​

This week, the Mithril team made progress in decentralizing the Mithril networks with the peer-to-peer (P2P) networking proof of concept, completing the first prototype implementation of the Mithril relay, which enables P2P signature broadcasting. They also made progress in optimizing the performance of the aggregator. Additionally, the team completed some enhancements on the CI/CD that will help manually deploy experimental Mithril networks for SanchoNet, as well as for the new P2P network layer.

Finally, they investigated occasional runtime issues causing delays for certain SPOs and started preparing for the next distribution release.

Low level overview​

  • Completed the issue Prototype a P2P relay with libp2p #1326
  • Worked on the issue Enhance aggregator REST API performances #1327
  • Worked on the issue Signer runtime is stuck for some SPO #1312
  • Completed the issue Manually deploy a test Mithril network #1356
  • Completed the issue Make Cardano node version custom in CI/CD #1355
  • Worked on the issue Support P2P relay in infrastructure #1361
  • Completed the issue mithril-client fails to extract archive #1352

· 6 min read
Kevin Hammond

High level summary​

We have undertaken an initial high-level security analysis of the CIP-1694 design. We summarise the analysis and our responses here.

Initial CIP-1694 Security Analysis and Responses​

Section: The constitutional committee​

  • “For example, if we consider the hypothetical Constitution rule "The Cardano network must always be able to produce new blocks" - In this example, if the governance action to reduce block size to 0 is passed, then there will be no way of passing or enacting further proposals. That is, this governance action is completely non-reversable. Suggestion: Instating a built-in mechanism that checks (and perhaps enforces) that the proposed governance actions, if passed, can be reverted in the future.

There is a 'guardrails document' in preparation which captures issues such as these. Some of them may be automatable, as suggested; others will need to be evaluated by humans.

Section: Size of the constitutional committee​

  • A possible issue with very large committee sizes (or large number of proposals/voters in general) is that it may take longer to have votes appear on-chain, which in extreme cases may require longer voting periods.

Thanks. Yes, we’ve been thinking about this issue for a long time, see for example the section ‘Final safety measure, post bootstrapping’. We don’t consider this as an issue for the CC since they need to be elected while DReps can just register, so we expect the number of CC members to be much less than the number of DReps

Section: Terms​

  • The following sentence is a bit awkward to read: “For example, a committee of size five with a threshold of 3/5 a minimum size of three and two expired members can still pass governance actions if two non-expired members vote Yes.” —> Suggestion: “For example, if we have a committee of size five with a threshold of 3/5, then a committee of three non-expired and two expired members can still pass governance actions if two non-expired members vote Yes.”

Thanks. Yes, that suggestion is a bit easier to read.

Section: Registered DReps​

  • “Additionally, registered DReps will need to vote regularly to still be considered active.” - There is a minor issue with requiring “voting regularly”. That is, if there are no proposals to vote on for a long time, this means that no DRep can vote regularly (or they have to issue bogus proposals just to vote on them).

Thanks. We’ve added a mechanism to prevent that issue in the spec/code where if there’s nothing to vote on for an entire epoch, we increment the epoch that each DRep expires.

Section: Ratification​

  • It is a bit unclear why protocol changes: network group and technical group are two separate groups.

These correspond exactly to the groups that are administered by the Parameter Committee.

  • I didn’t understand the rationale for requiring 100% “Yes” votes to pass “Info” type governance actions? It seems they have the least potential to harm the system.

Yes, it’s not about harming the system, since Info actions have no direct effect on the operation of Cardano. The motivation is simply to record the actual level of support for the action.

Once an action is enacted it’s no longer possible to vote on it. So if there was e.g. a threshold of 50%, then there is no way of telling whether the support for it might eventually have reached 90% or higher if it was not immediately enacted when the threshold was reached.

Section: Content​

  • For Hard-fork initiation, the changed parameters should probably also be required as part of Additional data.

Protocol parameters can be changed in arbitrary ways by the hard fork and new ones might be introduced, so anything this action pins down might not actually be the value that will be present after the hard fork.

Section: Protocol Parameter groups​

  • It is a bit unclear to the reader what some of these parameters mean, for example: monetary expansion (rho) and treasury expansion (tau). Suggestion: Include brief explanations for the non-obvious parameters.

These are existing protocol parameters, described in e.g. https://cips.cardano.org/cips/cip9/9 or The Cardano Protocol Parameters Guide.

  • With the current set of governance actions, it seems that it is not possible to add new types of protocol parameters, or categories of governance voting thresholds. Suggestion: Consider possibility of incorporating governance actions that allow addition of new protocol parameters, deletion of defunct protocol parameters, or modification of governance voting threshold categories.

All of this needs to be done via a hard fork. If we had an action that added a parameter then there is no way of giving it semantics anyway, since that must be done by logic in the code.

Section: Votes​

  • Is a constitutional committee member also a DRep? If so, do they vote twice, once as a committee member and once as a DRep?

They may or may not be (and they could also be an SPO). Note that this is fine, since these are completely separate tallies. This is also not preventable, since we don’t have an on-chain mechanism for identity. And yes, each credential gets to vote on each action for all roles in the governance system it has.

Section: Separation of Hard Fork Initiation from Standard Protocol Parameter Changes​

  • It is unclear whether there would be automated checks for whether a proposal is indeed a soft fork or hard fork, which would reduce human error in categorising proposals.

There is no on-chain mechanism that could enforce this, the best we could do is some kind of certificate. However, this may not be trustworthy, of course. We will consider this in future versions of Voltaire.

Section: Changes post Edinburgh workshop (July 2023)​

  • “All governance actions are enacted one epoch after they are ratified.” - I’m not sure if this line is currently in the main body of the CIP?

It is, but it is phrased differently: ‘All governance actions are enacted on the epoch boundary after their ratification.’

Section: Reduced deposits for some government actions​

  • Another downside of requiring endorsement from the constitutional committee is that this likely does not apply to constitutional committee-related proposals, such as no-confidence votes.

Indeed. We have no plans for this at the moment.