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.

High-level summary​

This week, the Hydra team made several impactful updates. They addressed misleading errors regarding collect com transactions, resolved a security advisory (CVE-2023-42806), and simplified the Hydra Head protocol by using inline datums. The team also tackled minor inconsistencies in specifications and implementation, documented reasons for potentially dropped close transactions by the cardano-node, and collaborated with SundaeLabs on an offline mode for hydra-node. Additionally, they engaged in discussions with researchers about incremental de-/commits.

What did the team achieve this week​

• Removed misleading errors about collect com transactions #839
• Addressed security advisory CVE-2023-42806 in PR #1161
• Changed the head protocol to use inline datums, simplifying things in the hydra-node #1162
• Addressed minor inconsistencies in spec and implementation #1104
• Documented why close transacations might be dropped by the cardano-node (can’t fix) #1039
• Tidy up a few things here and there
• Worked with SundaeLabs on the offline mode for hydra-node
• Discussed incremental de-/commits with researchers

What are the goals of next week​

• Start work on incremental decommits protocol specification #1057
• Provide support to Hypix
• Address all open bugs
• Release version 0.14.0 with this scope
• Update dependencies to prepare for Conway #1114
• Shepherd off-line mode PR over the finish line
• Complete tidying up chain layer via stateless observation changes in hydra-node #1096

High level summary​

• Benchmarking: Release benchmarking for node 8.6.0 as well as benchmarks scrutinizing GHC versions and the new tracing system.
• Development: PlutusV3 capability of our workload generator has been implemented.
• Tracing: First round of optimization of the cardano-tracer service has completed, awaiting validation.
• Nomad backend: A significant PR has landed addressing automation features and debugging capabilites.
• Workbench: Configurable remote environments and improvements to run documentation have been merged to master.

Low level overview​

Benchmarking​

We've performed and analyzed a full set of benchmarks for node 8.6.0, both in comparison to recent release tags and mainnet version 8.1.2. A lot of development work has entered the system since then, so it is crucial we can rule out any potential performance risks for the next mainnet release.

Additionally, we've been benchmarking GHC9.6.3 builds of cardano-node. Overall, we've observed reliable optimization behaviour by that compiler version - which is much more in line with expectations than what we've seen on GHC9.2.7. Getting evidence on how predictable (and malleable, by code annotations) performance is when building with a certain compiler version is essential for settling on a version as supported release platform.

A last set of benchmarks was dedicated to the new tracing system with node 8.6.0. We were able to show that there is no performance risk to enabling the new system, even when forwarding all trace messages to a cardano-tracer service on the receiving end. Key metrics for block forging, as well as block diffusion, did not exhibit any regression.

Development​

For future benchmarks to be built around PlutusV3, we've equipped our transaction generator with basic integration and tests for the upcoming Plutus version. This enables us to target the new cost model and potential changes to the execution budgets by developing specialized workloads.

Tracing​

The cardano-tracer service has received its first batch of optimizations. Profiling output is promising; to measure performance for a long service run time, we're currently equipping the service binary with the same capability to emit regular resource traces as cardano-node. Analysis of those will be the basis for validating this and possible future optimization efforts.

Nomad backend​

Many improvements for the nomad backend have been implemented and merged to master. This encompasses a unified naming schema for all nomad profiles, improved internal management of cluster topology, a more fine-grained healthcheck service, more detailed automated documentation of underlying hardware, as well as lazy resource release. The latter enables our team to investigate and debug interrupted runs for the exact moment and in the exact cluster state a potential failure occurred.

Workbench​

Our performance workbench has seen upgrades in documenting and reporting cardano-node builds. This ranges from capturing package versions and commit ids of key dependencies, to querying a deployed node for its build compiler. When alternating between compiler versions and benchmarking custom built branches, automating such documentation is essential.

Furthermore, the workbench is now able to access several remote deployments on all active clusters. This allows for fetching data, analyzing, comparing and reporting on all benchmarks from just one centralized workbench instance.

High-level overview of sprint 48​

Bootstrap Peers​

We continued reviewing bootstrap peers, ouroboros-network#4555.

IOClasses / IOSim​

We prepared slides for a Haskell meetup were we presented a talk on IOSimPOR. The recording will be availble on YouTube.

We also used the opportunity to do some refactoring of the IOSim code base: io-sim#117. We released io-sim-1.3.0.0 on Hackage: io-sim#119.

We also added forkFinally to MonadFork (not included in 1.3.0.0 release): io-sim#123.

Tech debt​

We refactored Resource used by the DNS subsystem: ouroboros-network#4707. We continued reviewing the ouroboros-network#4625 PR, which refactors RootPeersDNS module.

High level summary​

Over the last two weeks, we managed to run a UTxO-HD capable node in legacy mode, which maintains the baseline memory usage while keeping all the ledger state in memory (as the current node does). This legacy mode could provide an alternative for releasing a UTxO-HD capable node where people can choose whether to store the large part of the UTxO set on disk or not. However, legacy mode involves code duplication, requires several weeks of work before it is production ready (more integration and testing). Moreover, we will not release UTxO-HD before Conway to avoid the risk of delaying the latter. On the other hand, to integrate the LSM-tree backend for UTxO-HD we need to redesign the Consensus storage layer, and this new design might enable us to implement an alternative in-memory backing store that will have a very similar performance and resource requirements as the current Cardano node. Therefore, during the coming months we will focus our efforts on the redesign of the storage layer and the LSM-tree backend.

On the Genesis front, we reviewed the peer simulator for Genesis tests, which was implemented by Tweag and was signed-off by the Consensus team.

We also continued our work on improving the handling of blocks from the future. We presented possible approaches to handling blocks from the future in the Chief Scientist Meeting at IOG, which was very well-received. The discussion with the IOG scientists touched upon the relationship of this approach to Ouroboros Chronos.

Javier Sagredo continues his cycle as release engineer, and he is working on version 8.7 of Cardano node.