Skip to main content

· 3 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:

  • Cardano-node 8.9.2 is now deployed to mainnet, preprod, preview and shelley-qa environments.

  • Cardano-node 8.10.1-pre is now deployed to sanchonet and also to one-third of IOGs preprod environment nodes and two-thirds of IOGs preview environment nodes.

  • Private chain for Voltaire team was paused with plans for a future respin.

  • The network team's ouroboros-network-ops machine cluster was re-written using the cardano-parts stack to upgrade from the nixops/terraform/niv stack it was previously using.

Lower level summary​

Cardano-parts​

  • Sets cardano-node to 8.9.2, dbsync-ng to sancho-4.2.0; mithril to 2412.0, iohk-nix to include new peerSharing defaults and introduce a new block producer config. Adds a new truncate-chain recipe and improves mithril related services. More detail is available in the PR description: cardano-parts-pull-38

  • Sets cardano-node pre (-ng) to 8.10.1, dbsync to 13.2.0.2; mithril pre (-ng) to unstable, iohk-nix and iohk-nix-ng pin includes new Cardano Foundation bootstrap relays. Adds new aws machine management and other recipes, metadata job support for pool creation, misc fixes and improvements. More detail is available in the PR description: cardano-parts-pull-39

Cardano-mainnet​

  • Sets cardano-node to 8.9.2, mithril to 2412.0, iohk-nix to include new peerSharing defaults and colmena.nix cluster refactor for peerSharing adjustments and implements all updates in cardano-parts PR#38. See the PR description for more details: cardano-mainnet-pull-12

  • Sets dbsync to 13.2.0.2, iohk-nix and iohk-nix-ng to include new CF relays, adds new aws machine management recipes and implements all updates in cardano-parts PR#39. See the PR description for more details: cardano-mainnet-pull-13

Cardano-node​

  • Default peerSharing true and add block producer config to release binaries. See the PR description for more details: cardano-node-pull-5789

Cardano-ops​

Cardano-perf​

  • Adds a caddy webserver for run reviews and tunes the NVME FS mounts for performance: cardano-perf-compare

Cardano-playground​

  • Sets cardano-node to 8.9.2, mithril to 2412.0, iohk-nix to include new peerSharing defaults, refactors mdbook out of docs dir, adds example chain manipulation doc and implements all updates in cardano-parts PR#38. See the PR description for more details: cardano-playground-pull-21

  • Sets cardano-node pre (-ng) to 8.10.1, dbsync to 13.2.0.2, mithril pre (-ng) to unstable, iohk-nix and iohk-nix-ng to include new CF relays, adds a public TLS dbsync user connection option, stops private chain cluster and implements all updates in cardano-parts PR#39. See the PR description for more details: cardano-playground-pull-22

Iohk-nix​

Ouroboros-network-ops​

Sanchonet​

Sanchonet-demo​

· 2 min read
Alexey Kuleshevich

High level summary​

Ability to specify CostModel for PlutusV3 in the genesis file was implemented, which will allow us to execute PlutusV3 as soon as we enter Conway era, which is essential for guardrails script. Important bugs that have been fixed:

  • Invalid reporting of InsufficientCollateral and ValueNotConservedUTxO predicate failures. In case of validation failure a confusing deserialization was reported instead of those predicate failures.
  • Calculation of votes for Constitutional Committee Members did not consider expired members correctly.
  • Useful function redeemerPointer was deprecated without good justification.

Besides bugfixes there was a lot of work done on the testing side. Constraint based data generation is receiving continuous improvements. More unit and property tests for Conway era functionality.

Low level summary​

Conway​

  • pull-4259 - Undeprecate redeemerPointer and expose it in cardano-ledger-api
  • pull-4252 - Add PlutusV3 CostModel to UpgradeConwayPParams
  • pull-4247 - Change the balance in InsufficientCollateral to DeltaCoin
  • pull-4267 - Expand TxAuxData interface
  • pull-4265 - Inline UTxO and UTxOW PredFailure for Conway
  • pull-4281 - Discount expired CC from CC-size calculation
  • pull-4290 - Add NoThunks instance for UTxO pred failures
  • pull-4288 - Fix burning tokens predicate failure

Testing​

  • pull-4241 - Add fixup combinators to ImpTest framework
  • pull-4229 - Shrinking for constrained-generators
  • pull-4244 - Imptests: CommitteeMinSize affects in-flight props
  • pull-4269 - Fix generation bug for sums of positive member spec
  • pull-4266 - Add imptest to propose and enact unknown costmodels
  • pull-4261 - constrained-generators cleanup for hackage
  • pull-4279 - constrained-generators: Fix bug in toPreds for maps + add additional tests
  • pull-4272 - simplify foldMap interface to higher order syntax
  • pull-4283 - constrained-generators: add new test to test suite
  • pull-4286 - constrained-generators: refactor reify to reduce the number of binding sites + delay simplification more to avoid variable capture in higher order syntax

Infrastructure and releasing​

  • pull-4260 - Bump idna from 3.3 to 3.7 in /doc
  • pull-4277 - Fixed formatting in HowToProfileLedger.md
  • pull-4282 - Bump plutus deps to 1.26
  • pull-4294 - Avoid cancelling scheduled CI when a new merge happens on master

· 2 min read
Jean-Philippe Raynaud

High level overview​

This week, most of the Mithril team attended the Cardano Buidler Fest #1 in Toulouse, France. They also continued implementing the certification of Cardano transactions in Mithril networks and worked on scaling the signature and proof generation for mainnet by compressing the transaction Merkle tree using sub-Merkle trees based on transaction block ranges. The team identified the source of an issue preventing proper memory release during the signing/proving of a large set of transactions and developed a fix for it. Additionally, they completed the prototype for decentralizing signer registration with the relay and a peer-to-peer (P2P) network.

Finally, the team implemented a configurable feature for test networks to log unparsable blocks instead of panicking and investigated some unexpected error logs occurring on the Cardano node when the signer and aggregator connect to the mini-protocols.

Low level overview​

  • Completed the issue Mithril relay broadcasts signer registrations with P2P PubSub #1587
  • Worked on the issue Store Block Range Merkle roots in signer and aggregator databases #1633
  • Worked on the issue Stream import of Cardano transactions #1646
  • Worked on the issue Memory leak in Cardano transactions signature/proof #1629
  • Worked on the issue ChainObserver supports retrieving the Chain Point of the tip of the chain #1589
  • Worked on the issue Add section for manual setup of squid in SPO guide #1610
  • Worked on the issue Mithril Signer Local Error Policy : Error 182 - MuxError #1632

· One min read
Sebastian Nagel

High-level summary​

This week, the Hydra team refactored the heartbeat logic to prepare for the versioned network protocol. They have also switched http://explorer.hydra.family to run on the preview network. Additionally, the team has added property tests to the /commit endpoint changes.

What did the team achieve this week​

  • Refactor heartbeat logic to prepare for versioned network protocol.
  • Switch http://explorer.hydra.family to run on preview network.
  • Add property tests to /commit endpoint changes

What are the goals of next week​

  • Attend and connect with community on Cardano Builder Fest
  • Merge new /commit endpoint changes

· 3 min read
Michael Karg

High level summary​

  • Benchmarking: We've performed benchmarks and analyses for Node versions 8.9.2 and 8.10.0.
  • Development: Design phase for implementing quick queries in the analysis pipeline has begun.
  • Workbench: We're finishing up the new features for the reporting pipeline; Haskell profile definition work is ongoing.
  • Tracing: Improving the Prometheus output is ongoing; the node's build info will be accessible as a Prometheus label.
  • UTxO Growth: Our tooling has been augmented to support benchmarks starting with a non-empty chain.

Low level overview​

Benchmarking​

We've performed a full set of release benchmarks for Node 8.9.2. Comparing with release 8.9.1, we could not detect any performance risks for that version.

The benchmarks for 8.10.0 have shown a slight improvement in the time the block forging loop needs to evaluate, whilst additionally, resource usage of the cardano-node process was also slightly reduced - a nice performance improvement.

Development​

Our analysis pipeline is based on batch analysis of data from over 50 cluster nodes; it consumes very large amounts of trace output ex post facto, when the actual benchmark has terminated. This is very time-intensive, and not viable for obeserving an additional metric that you later on determine might need consideration.

We're planning to add quick queries into a benchmarking run's trace data to our analysis pipeline. These will be structured such that parameterizable, ad-hoc querying is supported. Initial tests showed that evaluation speed of such queries is fast enough to merit designing a principled, and generalized, syntax for them - and a subsequent implementation.

Workbench​

The reporting pipeline has been augmented with direct support for customizable, and stylable, TeX rendering - currently receiving final touches.

Porting our performance workbench's profile definitions to Haskell, and providing them with an appropriate test suite, is ongoing work. It is our goal to both increase reliable profile definition and validation, and facilitate usage by engineers less familiar with the workbench.

Tracing​

The work to improve system metrics as presented to Prometheus is still ongoing. Type annotations, as well as introducing Prometheus labels for certain metrics to convey (like e.g. build information), will make that interface more versatile. It also facilitates configuration of monitoring or dashboards like Grafana on top of those Prometheus metrics.

UTxO Growth​

For the UTxO scaling benchmarks, we've augmented the workbench with the capability to support injection of a custom synthesized chain into the deployment, and start a benchmark only after replaying that chain - whereas our benchmarks usually start just with a genesis block.

To achieve that, different components of our tooling needed addition of features: distributing that chain to the node cluster, having analysis work without necessarily providing trace evidence of each block in the chain being forged by a benchmarking node. Cluster timing had to be adjusted to account for the gap between genesis start time and the chain tip. However, this entire mechanism opens up the possibility of having a very distinct ledger state at hand for a benchmark - one, that's been particularly crafted via a series of pre-defined transactions constituting the blocks during creation of the synthesized chain.

In the future, we plan to flesh out a more general design of that mechanism, which currently is tied to a very specific use case only.