Skip to main content

· 2 min read
Michael Karg

High level summary​

  • Benchmarking: We're adjusting the benchmarking cluster to handle runs for node version 8.2.0.
  • Tracing: We've finished optimization of the new tracing system and added extra robustness with regard to namespacing.
  • Infrastructure: We've been working on making all benchmarking code compliant with the latest GHC9.6.
  • Nomad backend: The new backend has seen adjustments due to a change of underlying hardware. Additionally, we've successfully performed various benchmarking runs on it.

Low level overview​

Benchmarking​

The 8.2.0 version of cardano-node required adjustment of some of the sanity checks that are part of our benchmarking cluster automation. We've pinpointed the necessary changes and are currently setting up the cluster for the new node version.

Tracing​

The optimization efforts for the new tracing system have been completed and have significantly reduced the resource footprint when using it as default for a running node.

A linchpin of the new system is the organization of traces into a namespace hierarchy. This affects configuration, self-documentation as well as rendering of desired trace messages. The new system is now equipped to detect any inconsistency in the whole set of tracers, defined across all components, even if they are never turned on in a running node. This feature adds another layer of robustness to the whole system.

Infrastructure​

A potential switch to GHC9.6 (or higher) required some work on our code bases to make it compliant with recent compiler versions. We've future-proofed our benchmarking code.

Nomad backend​

The hardware cluster that our nomad backend was accessing has been changed, and we were able to adjust our backend accordingly without touching its higher level abstractions and functionality. Moreover, with the new hardware and cluster setup, certain tasks such as retrieving run artifacts or healthcheck monitoring have become more performant.

The validation phase is ongoing. We were able to perform successful runs and analyses for various 8.x node versions, including 8.2.0-pre. With parallel runs on the current cluster, we hope to measure the same effects we've observed with the nomad backend - which will be a big step towards production use.

· One min read
John Lotoski

High level summary​

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

Some notable recent updates or improvements include:

  • Preprod and preview envionments were updated to 8.1.2.
  • Sanchonet and shelley-qa environments were updated to 8.2.0-pre.
  • Work on a new cardano performance repo which utilizes a lightweight Cloudformation/Rain to Terraform infra bootstrap and Nomad environment has begun.

Lower level summary​

Cardano-ops​

Cardano-perf​

Cardano-world​

· 2 min read
Carlos LopezDeLara

2023-07-19 - 2023-08-01

High level summary​

  • Release of Node 8.2.0
    • Updates to the ledger packages extend progress on the Conway ledger era to support new governance features via CIP-1694.
    • This release is phase 1 of the SanchoNet roll out
    • Allows SPOs to vote on changes to the on-chain constitution.
    • Ability to start the node in block production mode with no secrets loaded using the --non-producing-node flag.
    • Updates to the networking packages prepare the road for peer sharing.
  • cardano-cli and cardano-api continue to integrate Conway era features
  • Continue refactoring of cardano-testnet

cardano-cli​

cardano-api​

cardano-node​

cardano-testnet​

docs​

CI & project maintenance​

· 3 min read
Marcin Szamotulski

Network Update (Sprints 39 & 40)​

The network updates got distracted. Mostly because of me leaving for the meeting in Edinburgh, Scotland and the being away. It was great to see and talk to so many of the community members.

Sprint 39 (Jun 26 - Jul 09)​

Major changes​

Now the following list of traces will be turned on by default:

node-to-client protocol​
  • LocalConnectionManagerTracer
  • LocalInboundGovernor
  • LocalHandshake
  • LocalServer
node-to-node protocol​
  • Server

See cardano-node#5353. This will be released in node-8.2.0.

We made sure that cardano-client-0.1.0.x library (which is db-sync) is not using the experimental node-to-client protocol. The cardano-client-0.2.0.0 was not affected. See ouroboros-network#4612.

We merged the dynamic block production feature to ouroboros-consensus (also available in the cardano-node-8.2.0 release). Dynamic block production enables hot-swap p2p nodes, which are important for the p2p deployment of block-producing nodes. See ouroboros-network#3159, [ouroboros-consensu#140].

We continued to review the implementation of big ledger peers for eclipse evasion, see ouroboros-network#4462.

Minor changes​

Sprint 40 (Jul 09 - Jul 23)​

Major changes​

We integrated ouroboros-network-0.8.2.0 with the master branch of cardano-node for the 8.2.0 release (the version match between ouroboros-network and cardano-node is purely accidental). This includes:

  • integration with dynamic block production feature. This feature is documented in the following PR.
  • Warm valency for local root peers (see below).

For the full list of features included in the 8.2.0 release from the network side, please take a look at the pre-release nodes.

We improved the memory footprint of peer metrics measured by the P2P stack. Peer metrics are used to decide which peers to demote every churn interval (roughly every hour with some probabilistic fluctuation). See ouroboros-network#4620. The improvement will be available in cardano-node-8.2.0.

We added an optional explicit warm valency to local root peers of the P2P topology file. Previously we used an implicit valency, e.g. the node keeps connections to all of the local roots; with local warm valency the node will pick only that many peers from the local root peers group to connect to. The hot valency (previously known simply as valency) hasn't changed, but it must be smaller than the warm valency as hot peers are selected from warm ones. Warm valency is a useful feature to limit resource consumption if one of the domain names in the local root peer group resolves to many IP addresses. See ouroboros-network#4575, cardano-node#5409.

· 2 min read
Sebastian Nagel

High-level summary​

During this week, the Hydra team achieved significant progress in various areas. They conducted the monthly review meeting for July, which continously ensures transparent communication and project evaluation. The team migrated the core logic of the node to an event-sourced architecture and incremental writes of events to persistence, enhancing the project’s performance and maintainability. Furthermore, the team added the ability to read protocol parameters via the API and fixed the CI workflows to support pull requests from forks of external contributors, streamlining the development process for community involvement.

What did the team achieve this week​

  • Held the monthly review meeting for July (recording)
  • Migrate the core logic of the node to an event-sourced architecture #999
  • Updated persistence to faster incremental writes of events #1000
  • Added ability to read protocol parameters via API #735
  • Fix CI workflows to support pull requests from forks of external contributors #993
  • Updated to GHC 9.2.8 #1005
  • Prepared an updated use cases section on https://hydra.family (published with next release)

What are the goals of next week​

  • Publish monthly report
  • Complete user transaction submission work #966
  • Remove commit from internal wallet (deprecated) #954