Skip to main content

· 3 min read
Marcin Szamotulski

Network Update​

Key contributions and advances​

We merged light peer sharing feature, which allows to include inbound peers into outbound governor known peers. This is the primary way for new unregistered nodes to enter the network, which then can be shared using peer sharing. Note that peer sharing is an experimental feature which is disabled until genesis & eclipse evasion as fully implemented. See #3596.

We are making progress reviewing eclipse evasion, #3886.

We fixed another bug in local root peers. We found out that if the local roots where ignored until the first domain name was resolved, see #4583. The bug fix was backported and released in ouroboros-network-0.8.1.1.

We re-started working on dynamically enabling block forging to address issue #3159, which will enable us to release P2P on block producing nodes. See #140.

New cardano-ping / cardano-cli ping release​

We prepared a new release of cardano-ping library which supports the new query feature (query supported versions). See #4589, #4593 and #5313. The new version of cardano-cli ping will use ISO8601 formatted timestamps; also the formatting of ping results is slightly improved, and it will introduce the new --query-versions (-Q) switch. If the remote site supports the query parameter, the command will print:

redacted-ip:port network rtt: 0.064
redacted-ip:port handshake rtt: 0.064010896s
redacted-ip:port Queried versions [NodeToNodeVersionV11 764824073 InitiatorAndResponder,NodeToNodeVersionV10 764824073 InitiatorAndResponder,NodeToNodeVersionV9 764824073 Initiat
orAndResponder,NodeToNodeVersionV8 764824073 InitiatorAndResponder,NodeToNodeVersionV7 764824073 InitiatorAndResponder]

otherwise it will print the negotiation results

redacted-ip:port network rtt: 0.045
redacted-ip:port handshake rtt: 0.101867615s
redacted-ip:port Negotiated version NodeToNodeVersionV10 764824073 InitiatorAndResponder

Note that in that case cardano-cli ping offers InitiatorAndResponder, which allows us to detect whether the remote side is an InitiatorOnly or InitiatorAndResponder. Also cardano-cli ping will no longer announce itself as InitiatorAndResponder, except for the case mentioned above.

Other smaller contributions​

On a request from the Marlow Team, we published haddocks of typed-protocols, which are now available here (#40, #41).

We made a new release of strict-stm-1.1.0.1 on Hackage, which fixed a bug in package description file, #101 .

We also helped to debug a deadlock when using named pipes on Windows in the new RawBearer API. The API is being used to store secret keys only in memory. The PR #4395 is under review.

We also have two more PRs which are under review:

  • #4530: enabling ledger peers on a fixed number of slots before the tip of the chain;
  • #4580: a PR which fixes inconsistencies in one of our cddl specs.

· One min read
Iñigo Querejeta Azurmendi

High level summary​

The open fronts that the crypto team is working on are:

  • cardano-base: E2E tests for BLS bindings and KES agent
  • Sidechains: Implement ECC chip and Rescue hash primitives for ATMS
  • mithril: Full node verifier

Low level summary​

cardano-base​

  • RawBearer API in ouroboros-network-framework (https://github.com/input-output-hk/ouroboros-network/pull/4395); blocked due to issue with windows' localSnocket. Trying to resolve.
  • Adapting cardano-base for direct memory transfers between mlocked RAM and file descriptors #317.
  • Above, blocked by the simplification of typeclasses #404.
  • Provided e2e test cases to the testing team with aggregated signatures and schnorr signatures for the BLS bindings

Mithril​

  • Implementation of Full Node Verifier #939

Sidechains​

  • ECC chip implemented for JubJub over BLS12-381
  • Rescue chip implemented for hashing.
  • Currently working on Schnorr signature (which uses the above constraints)

· 3 min read
Moritz Angermann

High level summary​

The Developer Experience team has been devoted to day-to-day troubleshooting and support of various elements including build failures, compiler upgrades, the maintaince of our cardano-haskell-packages (CHaP), and infrastructure like GitHub Actions, iohk-nix, haskell.nix, and devx. Furthermore, we have also contributed to upstream tooling improvements.

Lower level summary​

build support & maintainance​

Our DevX team has been instrumental in troubleshooting and fixing a wide range of issues, from broken windows builds and obscure LoadDLL errors to blst integration across Nix and Github CI. We've also initiated automatic uploads for release assets. Our efforts in streamlining complex CI setups have paid off, with some repositories like cardano-base experiencing significant reductions in CI complexity.

compiler upgrades​

After the support for 9.2 across our libraries, we have started working on 9.6 compabilitiy as well. This move brings us closer to the upstream compiler, facilitating the contribution of patches and enabling early detection of regressions. In addition, we're prioritizing compaining even stronger for better backwards compatibility.

CHaP (cardano-haskell-packages)​

We relocated the underlying tooling, (foliage), for CHaP into the IOG organization. Furthermore, we have introduced improved tooling to quickly add constraints to packages, better error reporting for add-revision and better hackage url compatibility to facilitate easer usage of CHaP.

GitHub Actions​

Our repository, input-output-hk/actions, now houses the necessary actions for installing pre-requisites to build Cardano projects using GitHub Actions. Leveraging the base and haskell install actions has allowed us to simplify workflows in the repos, focusing primarily on invoking cabal.

iohk-nix​

The iohk-nix repository has undergone a major revamp and now provides pre-built packages of the cryptographic libraries IOG utilizes for GitHub Runners. The key components we use, sodium, blst, and secp256k1, are also fixed to certain revisions within the iohk-nix repository.

haskell.nix​

Haskell.nix has been maintained and updated with the addition of GHC 9.6.2 and GHC 8.2.8. After discovering performance regression in the native bignum backend, we switched the default bignum backend to gmp.

devx​

The relatively new devx repository is where we experiment with a single nix development shell that aims to suffice for most use-cases at IOG. This initiative is expected to eliminate a number of CI failures related to project-build and shell interaction problems. The devx repository's readme has been updated to reflect its purpose and usage guidelines.

upstream tooling​

Our team remains committed to enhancing upstream tooling, with ongoing contributions to GHC, Cabal, and Nix.

· 2 min read
Franco Testagrossa

High-level summary​

This week, the Hydra team worked on multiple fronts. They finished the investigation about the broken head on mainnet and re-opened their persistent head instance. The team also fixed the monthly report publication on their website and started sketching ideas and further improvements. Also, they are on the last mile to deliver a new feature which will allow parties to commit funds from extern wallets. Finally the team started to work on optimizing the performance on their benchmarks.

What did the team achieve this week​

  • Finished investigation on broken head on mainnet #897 and re-opened it.
  • Added support for externally committing regular utxo #887
  • Fix monthly report publication on docs website and published the monthly report. Odd problems when publishing monthly report:
    • Make us think about if we should change something about the website #908
    • Open issue to docusaurus #9036
  • Fixed a bug in the benchmark process #910
  • Explored performance of the hydra-node{.verbatim} and identified a bottleneck.
  • Timed transaction feature is being used by the auction project 🎉

What are the goals of next week​

  • Complete performance analysis and start/plan improvements and provide regular benchmarks for Hydra #186
  • Add hydra as tool to developer platform #872.
  • Authenticate network messages #727.
  • Complete journey for external commits using multiple script UTxOs #903
  • Start implementing Option B for external commits #215.

· One min read
Kostas Dermentzis

High level summary​

We've made progress in all high level objectives

  • CIP-1694 integration design
  • UTxO-HD integration proof of concept
  • schema migrations with a focus on speeding up frequent queries is part of release 13.1.1.2
  • A new hire will help us with devx issues.

Lower level summary​