Skip to main content

Β· 9 min read
Sebastian Nagel
Jean-Philippe Raynaud

This is a monthly report of progress on 🐲 Hydra and πŸ›‘ Mithril projects since February 2024. These reports have recently moved to https://cardano-scaling.org/monthly (more details here).

This document serves as a preparation for and a written summary of the monthly stakeholder review meeting, which is announced on our Discord channels and held on Google Meet. This month, the meeting was held on 2024-03-27, using these slides and you can see the recording here.

Mithril​

Issues and pull requests closed in March

This month, there has been a noticeable increase in SPOs joining the Mithril protocol. In particular, many new multi-pool operators have set up the Mithril signer in their infrastructure. At the end of epoch #475, there were 230 pools registered with 4.6Bβ‚³ stake involved representing approximately 20% of the total active stake. We will continue to provide regular updates to the community to encourage their participation in the protocol.

We have released the new Mithril distribution 2412.0. This release includes several critical updates and enhancements, such as support for Prometheus metrics endpoint in signer, deprecation of the snapshot command in the client CLI, full Pallas based implementation of the chain observer, and support for Cardano node version 8.9.0.

Transaction signatures​

We have developed a signing structure that enables quick proof generation while maintaining a light footprint on the signer for the mainnet. This is crucial as we need to handle a vast amount of transactions (100 million). To achieve this, we created a block range Merkle tree, which stores transactions in a Merkle tree and uses its root to create another Merkle tree. According to the our benchmark tests, a batch proof for 100 transactions can now be created in less than 250 ms.

We have also completed the roadmap of the MVP that will be released on mainnet:

Transaction verification in frontend​

The Mithril client WASM library has been used to implement a Cardano transaction verifier inside the Mithril explorer. This feature is currently available only on the testing-sanchonet network and will be progressively rolled out to the other Mithril networks. Wallet and DApp developers could leverage the client WASM library to implement a security layer that verifies transactions provided by a third party.

Prometheus metrics​

We have released a new Prometheus endpoint with the latest stable version of the signer. The feature can be easily activated by the SPOs as explained in this developer blog post.

Additionally, we created a Grafana template to easily set up a dashboard for this Prometheus endpoint: https://grafana.com/grafana/dashboards/20776-mithril-signer/

Pallas updates​

The latest stable distribution now includes a fully implemented chain observer powered by the pallas crate. Additionally, we have been collaborating with TxPipe to implement the chainsync mini-protocol with Pallas. This will significantly reduce the latency of signatures for Cardano transactions.

Deprecation warning​

We have deprecated the snapshot command of the Mithril client CLI as explained in this developer blog post.

We recommend using the replacement cardano-db snapshot command for users of the client CLI.

Hydra​

Issues and pull requests closed in March

Hydra project roadmap did not change much this month:

The roadmap with features and ideas

The latest roadmap with features and ideas

Notable updates​

Conway support​

As mentioned in previous roadmap updates, we separated work to support the upcoming Conway era on Cardano in two:

While the former was already merged and is currently released in version 0.15.0 onwards, the team prepared the latter this month.

Ideally switching the transaction format in the hydra-node is as simple as setting the type alias type Era = Conway. However, the code was Babbage-specific in several areas and work on this resulted in various pull requests making switching easier in several places: #1326, #1327, #1328, #1334, and #1342.

The result is a relatively simple switch in this draft pull request and available on branch lc/conway-support, which we intend to bump and merge once the public Cardano networks hard fork.

Having full Conway era support, including PlutusV3, on the Hydra layer 2 already prepared on a branch allows early adopting users from the community to explore and use this already. Modulo-P has been on the forefront here by developing zero-knowledge hybrid DApps and wrapping the Hydra branch up in this example repository.

info

A full-on Conway hydra-node can be used on SanchoNet already and the Hydra protocol scripts did not change from master / the upcoming 0.16.0. However, note that the Hydra explorer shows such Conway-built heads only as Initializing. More details about why can be found in this pull request.

Streaming plugins​

SundaeLabs is working on a Hydra-based layer two protocol (gummiworm) that requires the usage of hydra-node components in a different way than the default setup. As part of this development, SundaeLabs submitted a Fund10 Catalyst proposal to enhance the Hydra node by adding features that would facilitate not only their work but also the work of everyone building on Hydra.

They have been working on a plugin architecture to enable the infiltration and exfiltration of events, which enables hygienic forks of Hydra that feature additional connections to the outside world. They are interested in consuming the Hydra event stream via Amazon Kinesis and storing transaction archives on S3 for later reference.

After an initial design phase resulting in ADR29, they contributed the event source and sink abstractions, and refactored the Hydra node to use these new extension points together with core contributors. The EventSource and EventSink interfaces, along with the configurable list of eventSinks in the main HydraNode handle, allow to extend the hydra-node with any external system. It also paves the way for more scalable persistence methods on the mainline Hydra node, and might even allow refactoring the existing API server as an EventSink.

Community​

Mithril office hours​

As the Catalyst project of TxPipe on Mithril is completed, we want to build upon this initial maintenance work in a more open format. For this, we are transforming our alignment calls into a public weekly office hour where we invite the community to join and discuss concrete pull requests, issues and questions on Mithril.

πŸ‘‰ Mithril office hours happen every Tuesday at 16:00 UTC on the #mithril-live Discord channel.

Hydra governance walkthrough​

This month, the Hydra team has been asked to provide a walkthrough of how we use GitHub to run and govern the project. We have prepared a video that explains how we use Github issues, pull requests, discussions, and projects to manage the development of the Hydra project. However, it is important to note that this information represents only a current view and we are enthusiastic about continuously improving the processes to make them more transparent.


We are excited to announce that we are looking to establish a Hydra working group at Intersect. This group will aim to involve more community members in proposing feature backlogs, roadmaps, and RFPs. Initially, the focus of this working group will be on the concrete Hydra Head protocol (state channels). However, variations such as Hydrozoa, and combined scalability protocols like Gummiworm, Lightning-like payment channel networks, or the Hydra Tail protocol (~ rollups) will also require more community involvement. Stay tuned for more updates on this in the upcoming months.

Conclusion​

We held the monthly review meeting for March 2024 on 2024-03-27 via Google Meet, presenting these slides and this recording.

This month we have made significant progress on Mithril transaction signatures, while the Hydra team has been busy working on the incremental commits/decommits features. Both projects are fully prepared for the upcoming Conway hard fork on Cardano and continuously demonstrate user experience improvements.

Besides the Hydra explorer user interface, the teams also showcased the Mithril transaction verification feature in the Mithril explorer frontend. This demonstrates that Cardano transactions can be additionally verified using Mithril certificates from within a web browser. Taking this even further, we believe that such a "Verified with Mithril" checkmark can provide additional level of confirmation for users of light wallets and Cardano DApps!

Besides these, Modulo-P showcased their early adoption of Hydra heads using Conway and PlutusV3 for their quite involved zero-knowledge protocols. Briefly after the meeting they released a first look on their zkMastermind DApp. Also, SundaeLabs presented their streaming plugins for Hydra. Both are examples of how the Hydra protocol can be extended and used in different ways, and we are excited to see more community contributions in the future.

As a closing remark, we see the trend of decentralizing governance on both projects, Hydra and Mithril, while at large the overall 'age of Voltaire' is unfolding. Consequently, we anticipate moves, merges, or restructuring of repositories, projects, and working groups. What an exciting time to be a part of this big Cardano community!

Β· 8 min read
Sebastian Nagel
Jean-Philippe Raynaud
Sasha Bogicevic

This is the first joint report of the 🐲 Hydra and πŸ›‘ Mithril projects, which summarizes the teams' progress since January 2024.

Previously, both teams had been releasing progress updates in different formats and intervals within their respective repositories:

Both sites are created from the individual project repositories. However, it is not ideal to keep 'procedural' documents as part of the code base, since it requires special handling when building versioned, published documentation. For example, this workflow in the Hydra project which publishes to https://hydra.family required several attempts to work around how Docusaurus websites are built. Consequently, we introduced a dedicated repository that builds into a website. This not only helps keep the original product repositories clean of inherently dated information, but also serves as a new home for joint reports, announcements, or occasional articles.

This monthly report serves as preparation for the monthly stakeholder review meeting (see slides and recording). At the meeting, the teams update stakeholders on recent developments and gather feedback on proposed plans.

Mithril​

Issues and pull requests closed in February

Release and publication​

This month, the Mithril team released distribution 2408.0 and published two blog posts:

Signing Cardano transactions proof of concept​

The team has been working on implementing a proof of concept of a new data type that will enable the certification of Cardano transactions within Mithril networks. Last month, the team extended the Mithril client library to support the certification of Cardano transactions. This month, the team have upgraded the client CLI and introduced a new cardano-transaction command that can list snapshots and certify a list of Cardano transactions. Additionally, they have implemented the same API surface on the WASM client that now supports transaction certification in the browser.

Enhanced support for Conway and SanchoNet​

The team has conducted thorough testing on the upcoming Conway era and are confident that Mithril networks will transition smoothly to this new era. Additionally, the team have released a new testing-sanchonet network that has been opened to SPOs to enable collaborative testing of the upcoming and experimental features (eg the aforementioned signature of the Cardano transactions).

Hydra​

Issues and pull requests closed in February

This month, the Hydra project roadmap underwent a few changes:

The roadmap with features and ideas

The latest roadmap with features and ideas

Notable updates​

Contest after fanout bug hunt​

While working on hydra-chess, the team encountered a bug in the Hydra node. In the two-party Hydra Head, nobody was able to perform a Fanout. This happened because one of the nodes was in the initial Snapshot state and missed the request for a new Snapshot, while the other node already had one confirmed Snapshot locally.

When the Close was posted, the Head was closed with the initial Snapshot and then contested by the node that saw a newer Snapshot. After the contest, the team observed a strange behavior where both nodes could not Fanout. We expected this failure in the node that only had the initial Snapshot since it did not have the correct UTxO locally to Fanout. However, the failure in the other node with the newer Snapshot should not have happened.

Fanout after contest bug sketching

While reviewing the code, the team discovered that the Contest observation was not extending the deadline after the contestation was made. As a result, the Fanout transaction was invalid because the validator checks that the Fanout transaction's lower validity bound is higher than the deadline to contest. This check ensures that one can only fan out after the contestation period is over.

Before fixing this bug, the team tried reproducing it using the MBT (Model Based Tests) framework, one of the tools in the test suite. However, to do that, they needed to complete modeling the entire head lifecycle and the specific scenario they observed in real life and arbitrary actions in all head states did not reveal this bug.

After also improving the framework itself to correctly validate transactions and a fix for simulating rollbacks, the team was able to fix the bug easily. However, it proves that being able to reproduce a bug is not only improving the code, but also allowed the team to gain knowledge and improve their test suites.

Hydra explorer supporting multiple versions​

This month, the team deployed the hydra-explorer to serve data under http://explorer.hydra.family/heads. Alongside this, they upgraded the Hydra scripts and switched to the latest pre-release version of cardano-node for Conway, and the system is currently running on the sanchonet network.

The Hydra explorer currently has the capability to support only one version on a single network. The reason for this limitation is that the Hydra scripts are compiled into two binaries- hydra-node and hydra-chain-observer - and the observer is connected to a single cardano-node that operates as a client on one network.

To support multiple versions of the protocol #1282, the team needs to compile the scripts of each version into individual chain observer binaries. These binaries can then communicate with the hydra-explorer components through an API. While Plutus validators change with any modification (thus affecting their hashes and addresses), this API can serve as an integration point that the team can support through multiple versions of the protocol.

Community​

Both projects saw community contributions this month:

TxPipe on Mithril​

The TxPipe team has kept working on the implementation of the Pallas Chain Observer for Mithril nodes and has contributed to retrieving the stake distribution and Mithril era markers (stored in the UTxOs of the chain) directly from the Cardano node with mini-protocols.

Ikigai auctions on Hydra​

As it also was briefly shown in the review meeting, Ikigai continued work on Hydra for Auctions in their Catalyst-backed project. Their use case is about starting auctions on the Cardano mainnet, but then collecting bids off-chain and only committing the final result on-chain. This is a perfect use case for Hydra, as it allows for a large number of off-chain transactions to be processed in parallel and then committed to the blockchain in a single transaction.

Conclusion​

We held the monthly review meeting for February 2024 on 2024-02-26 via Google Meet, presenting these slides and this recording.

This month, both projects focused on preparing for Conway and the upcoming hard fork combinator event. Preparations for the hard fork made the cardano-node a moving target, but the teams believe that early integration is key. Unexpected issues popped up in both projects, but they were able to address them.

New feature development is progressing well, with Mithril's transaction signing now available to early adopters. This feature opens up the possibility of making hydra-nodes more lightweight, as they won't need to rely on a single third party for trusted chain data. Instead, they can verify on the client (the Hydra node) using Mithril certificates. Additionally, Hydra's incremental decommit feature is in progress. While there's still significant work to be done on the on-chain parts, the teams have already implemented the off-chain workflow for incremental commits. Making both features available for users to try out will help validate the API changes. However, this cannot be released to mainnet without completing the required on-chain security work. During the review meeting, the teams sought feedback on a potential simplification of the Hydra on-chain protocol to have 'directly open' heads. Any thoughts or feedback on this fresh feature idea #1329 would be appreciated.

In general, if you read this far we would like to hear from you, dear reader, on any of our communication channels on Discord or a shout out on twitter. Maybe along with some feedback on the new, common website and the joint monthly report format? πŸ™

We are looking forward to the next month and when it happens, the Conway hard-fork on the first public testnets (no date yet) when πŸ›‘ Mithril serving certificates and 🐲 Hydra heads remaining open throughout.

Β· 5 min read
Sasha Bogicevic
Franco Testagrossa
Daniel Firth
Sebastian Nagel

This report summarizes the work on Hydra since November 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

The Hydra team restructured several items on the project roadmap this month.

The roadmap with features and ideas

The latest roadmap with features and ideas

Notable updates​

Hydra development​

Issues and pull requests closed since the last report.

This month, the team worked on the following:

API changes: dropping JSON Tx​

The Hydra API now utilizes a TextEnvelope containing the upstream CBOR encoding from cardano-api for the Tx type and removes the JSON representation from the API #1240. This ensures that transaction types have a fixed canonical encoding that will not change between versions. As a result, consumers of the Hydra API will need to deserialize CBOR to inspect transactions.

This representation mirrors the TextEnvelope produced by the cardano-cli, with the addition of an txId field, which is guaranteed to match the transaction ID within the CBOR object.

Breaking change

We do not plan to go through a deprecation cycle on this breaking change to the API. If you are affected and see a problem updating your Hydra client to use CBOR, please open an issue on GitHub.

Hydra Chess​

We team began developing a game on Hydra, leveraging dogfooding to uncover suboptimal elements or stumble upon bugs requiring resolution. Hydra Chess exemplified this process, offering valuable lessons during DApp development.

While refining the details, the team aims to improve the workflow of running hydra-node within a full peer-to-peer DApp framework. The objective is to ensure user-friendly accessibility while also providing an example for Hydra developers. You can access the source code here.

Hydra Explorer​

To measure the progress and success of Hydra, we require tools that provide insights into its usage. For this, the team initiated work on #696, enabling anyone to track Hydra heads throughout their entire life cycle and observe the growth of the Hydra ecosystem.

In this initial phase, the team has implemented a basic backend service #1235 that can track all heads on-chain within a devnet network. This service establishes a baseline and utilizes the hydra-chain-observer package, exposing a REST API for querying and retrieving information about all observed heads and their current states.

Community update​

TapTools recently published a summary of the project's progress over the last two months, which complements the updates provided above. Check it out here!

Besides the contributed offline mode mentioned above, Sundae Labs is also implementing a streaming API as designed in ADR29 in the course of this Catalyst project.

Also funded through Catalyst is a continuation of the Hydra auction project by Ikigai and MLabs. The Hydra team has not yet re-engaged in a regular exchange, but they expect to support the project with features as needed as they kick off this work.

As also pointed out in the review session, some of the team members have been involved in organizing the first Cardano Buidler Fest - happening on April 23-24 in Toulouse, France. This event will be a prime chance to connect with the people building (on) Cardano and inspire new ways of collaboration. At the time of publishing, tickets are already sold out, but we hope to see many Cardano builders there!

Conclusion​

We held the monthly review meeting for January 2024 on 2024-01-19 via Google Meet, presenting these slides and this recording.

This month, the teams demonstrated various Hydra and Mithril features. Additionally, Juan MagΓ‘n and his team from Modulo-P showcased a compelling demo on utilizing zero-knowledge cryptography in a Hydra head for a mastermind game. This work is a Catalyst Fund 10 accepted proposal.

Besides providing the usual status and roadmap updates on both Hydra and Mithril, several interested community members, including Tudor, joined the discussion to share their use case ideas. Tudor presented his proposal for supply chain tracking of Moldavian wine, which is currently running as a Catalyst proposal in Fund11. The proposal aims to leverage Hydra for CIP-68 NFT updates in a head, requiring wallet/app support. We also discussed a potential CIP to standardize asset access if held on layer 2 ledgers.

Charles provided feedback on considering Cardano block extensions as a potential core protocol change, enabling various proof systems and new consensus algorithms to support partner chains. We further emphasized collaborative efforts with the community to explore and develop the user space, determining which aspects could evolve into marketplaces and what should be integrated into core protocols. Processes like CIPs play a vital role in standardizing and facilitating technology transfer from the 'user space' to the 'kernel space'.

These discussions will inform the team's roadmapping sessions for the year, focusing not only on building essential features for the Hydra Head protocol but also on experimenting with new approaches to enhance Cardano's efficiency and accessibility.

Β· 6 min read
Sebastian Nagel
Arnaud Bailly

This report summarizes the work on Hydra since October 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

This month, several items were restructured on the project roadmap:

The roadmap with features and ideas

The latest roadmap with features and ideas

Notable updates​

  • Release of version 0.14.0 is imminent as most of the stateless chain observation #1096 feature is done and only some internal refactoring missing.

  • The user-submitted feature idea on supporting extended keys, #1141, has been refined. The purpose of this item is now clear, and although it's not currently a priority, work on it can be started.

  • Two new items were created to improve the developer experience of the Hydra build toolchain #1146. Additionally, a follow-up on things learned by hydra-poll aims to create a full end-to-end example of a two-player game in a Hydra head #1098.

  • There was already an item about reacting to main chain parameter changes on the roadmap, which included not only protocol parameter updates, but also hard-fork events. With the upcoming hard fork into Conway, the team split off the changes needed to navigate the hard fork and clarified them:

  • Substantial updates were made to the design of the next major feature Incremental decommit #1057, and work on it can be started.

  • In general, the team prepared several of these πŸ’­ idea items and many of them will turn into πŸ’¬ features soon.

Hydra development​

Issues and pull requests closed since the last report

This month, the team worked on the following:

MeshJS + Hydra​

At the beginning of month, the team attended the Cardano Summit in Dubai where they held the Hydra MasterClass workshop. There they also presented the Hydra-Poll dApp which is using MeshJS to build Hydra transactions on the frontend.

The Hydra team collaborated closely with the MeshJS team and as the outcome of this work The MeshJS team added some Hydra specific features to the MeshJS SDK. There is a nice low level API for building custom transactions which is pretty similar to what cardano-cli does.

Now you can use isHydra field which you can pass to this API which then uses another set of protocol paramters suitable for Hydra (eg. usually in Hydra we want to have zero transaction fees, reduce script execution units etc.).

Big thanks to the MeshJS team on giving much needed support. They were presenting these changes in the monthly review meeting so make sure to watch the recording.

Rendering the Hydra specification​

Besides working on the design of incremental commits itself, the team also tidied up the way the Hydra protocol specification is written.

So far, the specification was written in LaTex and rendered to a PDF. LaTeX was a good choice because of its expressiveness on math expressions, but not so great a choice for pull requests and the entry barrier is quite high. The majority of documentation around Hydra and Mithril is written using Markdown and rendered into a webpage using a static site generator, currently Docusaurus. Most modern Markdown renderers do support LaTeX-style math nowadays, even the normal GitHub file preview.

Hence, the team experimented with using the more standard Markdown format to write the specification, but still being able to use LaTeX math and LaTeX macros (which are still heavily used in the spec). The aim is to have both, a PDF and HTML rendering.

While not yet finished, the GIF above shows the progress being made using pandoc to resolve macros, producing a PDF via xelatex and Docusaurus compatible markdown. Using powerful extensions of pandoc one can even convert TikZ, GraphViz and Mermaid into both target formats.

Community update​

Beside the great work done by the MeshJS team towards supporting Hydra in the browser, here are some news and updates on community-led work streams related to Hydra:

  • SundaeLabs has made good progress on their offline mode PR which should hit the main branch soon,

  • TxPipe has been collaborating with IOG's creative engineering team to build Cardaminal, a command-line wallet, and demonstrated it during the monthly review meeting. Cardaminal is built in Rust, leveraging Pallas libraries, and is aimed at being a fully-fledged scriptable wallet providing users with powerful stateful transaction edition capabilities, native assets management, chain synchronisation, etc.

    The plan is to make Cardaminal compatible with Hydra - to be able to use it to interact with a head - and Mithril - using snapshots to synchronise the wallet.

  • The team behind ZK Snarks in Hydra Catalyst proposal is making good progress and should be able to give a demo at the next monthly review meeting

Conclusion​

The monthly review meeting for November 2023 was held on 2023-11-27 via Google Meet with these slides and the recording.

The Hydra team is thankful to have again had so many great demos from the numerous projects in and around Hydra and Mithril projects - we should really schedule it to be one hour planned duration. Also, if you have not watched it already, make sure to check out the recording, the written report is merely expanding on a couple of topics but cannot render the cool demonstrations.

At first look, the demonstrated projects may appear not related - we even had a minimal command-line wallet on the show after all. But as we went on, these impulses spark discussions and it becomes clear that all of these projects are connected.

For example, the terminal-based wallet 'Cardaminal' as it was presented the first time in public this month, could itself become a Mithril client for faster synchronizing or even light-mode using the recently published Rust client library for Mithril. Furthermore, such a minimal wallet would be a great testing ground for a Hydra-aware wallet. The MeshJS integration also has further potential of Hydra specific fetcher and submitter providers.

On the other hand, we also stumbled over not-so-optimistic sentiment even in much more mature scaling solutions like the Bitcoin Lightning Network. This tweet summarizes that creating non-custodial [scalability/LN] solutions 'feel like the most thankless thing in the world'.

It is an exciting ride still, but events like this monthly review meeting with its colorful demonstrations of small steps to improve the usability and scalability of Cardano piece by piece with often unknown synergies is also empowering. This month again made us feel not 'only a tribe', but more a working group across the Cardano community .. the Cardano Scaling group!?

Β· 7 min read
Arnaud Bailly
Sebastian Nagel

This report summarizes the work on Hydra since September 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

This month, the team released version 0.13.0, and updated the project roadmap to include the next planned version 0.14.0:

The roadmap with features and ideas

The latest roadmap with features and ideas

Release 0.13.0​

  • Implemented security fixes to Hydra on-chain scripts, all of which are only exploitable by other head participants (not any attacker)

  • Added support for (externally) committing inline datums

  • Improved stability by querying the cardano-node at the tip

  • Improved state persistence

  • See full release notes and a list of delivered features.

Notable updates​

  • Moved the network resilience #188 issue out of version 0.13.0 to allow for a quick release of the security fixes. This feature has been split in two parts, both of which are completed and will soon be included in the 0.14.0 release.

  • A new user submitted a feature idea about supporting extended keys #1141. Initially urgent, it's no longer a priority and requires further clarification.

  • Although not part of Hydra version 0.14.0, the team completed the integration of Hydra support in Kupo #1078, which can already be used with Kupo version 2.7.0

  • Implemented a new Hydra Poll DApp feature, which is an example to be demonstrated at the Cardano Summit 2023.

  • Realized stateless chain observation #1096 as a dedicated feature, which will add a hydra-chain-observer tool and simplify upcoming feature implementation related to layer 1 transactions.

  • Created a feature idea item to migrate all validators to Aiken #1092. This was moved to 1.0.0 though, as it would require a complete re-audit of the scripts and and there is no urgent requirement for performance improvements at this stage.

Hydra development​

Issues and pull requests closed since the last report

This month, the team worked on the following:

Network resilience to node crash​

Last month, the team worked on making the Hydra network resilient to transient network connectivity failure (see #188). However, this was just one aspect of the larger effort to improve the overall stability and reliability of the network. By completing #1079, the team also made the network resilient to arbitrary node failures, which is a much more likely event to happen should the network run for a significant amount of time.

Hydra nodes now persist the network messages they send to peers and together with the already present acknowledgment mechanism, this means a node recovering from a crash can resend messages which were not received by their peers.

Hydra Poll DApp​

As the Hydra team seeks to adhere more to the principles of dogfooding, we wanted to upgrade our basic Hydraw application to something more interactive. We, therefore, built a poll DApp with the goal of demonstrating how one can build an application living entirely in the frontend that can interact directly with a hydra-node, using its websockets-based API. This application was also showcased at the Cardano Summit 2023, where the Hydra team delivered a masterclass.

Upgrade to GHC 9.6 & Brick 1.10​

This month, we were able to update our compiler toolchain from GHC 9.2.8 to 9.6.3. This also required us to upgrade the hydra-tui from Brick 0.73 to 1.10 to stay compatible with the new version of the mtl.

The update to Brick necessitated a complete rewrite of the hydra-tui which greatly simplifies the application logic, using Brick's new elm architecture style combined with microlens-mtl.

Community update​

This month, the monthly review meeting was almost completely covered by demonstrations from the various teams working on and with Hydra. Don't miss out on the demonstrations of the various community contributions and make sure to also view the recording.

Hypix​

Hypix is a continuation of the 'Hydraw' demonstration the team used throughout development. The project is spear-headed by Trym Bruset and will integrate CIP-68 NFTs with instant transaction processing in a Hydra head to realize collaboratively created art pieces. The project is progressing great with an open beta available soon.

Hypix user interface

The Hypix user interface

Kupo x Hydra​

Indexers of chain data, like Kupo, are useful to enable lightweight decentralized applications like Hypix. As the application state of Hypix, for example, is not only on the Cardano layer 1, but also in the Hydra head, Kupo was enhanced to run 'in front of' a hydra-node and provide the same API for UTXOs indexed from a Hydra head. This was a joint effort between @KtorZ, @v0d1ch and @ch1bo and has been released in version 2.7 of Kupo.

Kupo indexing data

Kupo indexing a Hydra head

Offline-mode Hydra node​

Ledger-only mode for Hydra was one of the Catalyst Fund10 projects that got funded and work is underway to make it an integral part of Hydra software components. A new ADR has been proposed which details the rationale behind this new feature and an overview of what it brings and what impacts it will have on the hydra-node.

Moreover, this implementation is underway and should be part of the next release. This will enable running a single hydra-node as a kind of 'ledger-as-a-service', priming it with some UTXOs and allowing clients to submit and validate transactions without any relationship to layer 1.

Voting on Hydra​

The Hydra-for-voting project has been started earlier this year as a proof-of-concept to explore how a Hydra Head could help improve the voting or rather tallying process for Catalyst and other large-scale on-chain decision-making process. It's been on pause for a few months due to other priorities but it's been revived recently and put to use to tally votes for the Cardano Summit's awards recipients.

This development effort led to a couple of new features and fixes:

Hydra voting UI

Hydra Tallying UI

ZK Snarks on Hydra​

The team has initiated discussions with another funded Catalyst Fund10 project, exploring the implementation of a zero-knowledge proof system for Cardano, utilizing Hydra and ZK Snarks. At this early stage, there is minimal progress to display, but the team is eager to start the development of this promising tool.

Conclusion​

The monthly review meeting for October 2023 was held on 2023-10-30 via Google Meet with these slides and the recording.

As mentioned above, the meeting was about 45 minutes of demonstrations - which clearly shows that we are in the wake of Catalyst Fund10 where several project proposals involving Hydra and Mithril got funded and at the same time everyone was preparing for the Cardano Summit 2023.

With this many community contributions and projects moving forward, there was not much time to discuss the Hydra roadmap or go into details about Mithril project status. This is great!

Besides, the project roadmaps seem to be well aligned where our next features in-line are most anticipated (incremental de-/commits) and the adoption of Mithril is showing a healthy level with clear next steps and features ahead.

It is getting increasingly hard to keep track of all the new developments around Hydra. However, that is also often not needed and the Cardano builders just set off and build things using Hydra these days.

November will start with the Cardano Summit, likely yielding even more feedback and feature ideas from users. Following this, there will be several productive weeks focused on feature development before the usual Christmas and New Year breaks across the teams.

Β· 9 min read
Sebastian Nagel

This report summarizes the work on Hydra since August 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

This month, the roadmap has not changed much as the team mostly clarified upcoming features.

The roadmap with features and ideas

The latest roadmap with features and ideas

Notable updates​

Cardano Scaling workshop in Nantes, France​

From 2023-09-12 to 2023-09-14, most of the Scaling Tribe members, that is the two Hydra and Mithril teams, met for a three-day workshop in the beautiful French city of Nantes. This workshop was run following the Open Space technique which makes room for every participant to experiment and focus on what's of interest for them at the time while being engaging for the whole team. Here is a selection of topics covered that were most relevant to Hydra.

Aiken validator experiment​

As part of thw workshop, we explored how hard it would be to implement one of the Hydra validators in aiken. After roughly two hours of work we had a hydra-node running, tests passing and benchmarks of verifying one step in the Hydra protocol using aiken.

The hydra-node just uses the UPLC binary and its hash to construct transactions, we could rely on the same interface, with the difference that the script binary gets produced by aiken. Aiken does produce a socalled blueprint plutus.json containing the contract. We staged that file into git and embedded it into a Haskell interface to be able to reference the compiled script as SerialisedScript from hydra-node.

Next, we ported the simplest contract we have, namely the Commit validator, to Aiken. This was fairly straight-forward and we test were passing after some fiddling with internal representations of data strctures (plutus-tx is encoding triples as Constr data on-chain).

The results? A significant reduction in script size, cpu and memory usage on collect and abort transactions - or in different words, doubling the supported number of parties in a Head. πŸŽ‰

Shallow cardano-node experiment​

Running a hydra-node requires running a cardano-node, and running a cardano-node requires synchronisation with the chain and about 150 gigabytes of data to be downloaded and verified, which is a significant barrier to quickly spin-up hydra-node and Hydra Heads. Given a Hydra node does not need to look at the history of the chain, a Shallow cardano-node that can run without the full database of immutable files would be fine, assuming we can retrieve a recent state of the chain with the same security guarantees than a fully synchronised chain. This is exactly what Mithril can provide!

We ran a small experiment, trying to start a cardano-node manually removing all but the last files from the immutable DB and it worked as long as one does not query the node for a block too old in the past. This lead us to envision an improved user experience for installing and running a hydra-node, by packaging it with a cardano-node and a mithril-client to retrieve only the minimum needed state and be able to start a fully functioning hydra-node in minutes.

Other topics​

  • We continued working on Kupo x Hydra integration, benefiting from the presence of Kupo's creator and former Hydra team member, Matthias Benkort
  • We brainstormed possible synergies between the Hydra and Mithril projects, something that solidified into the desire to explore this concept of "Shallow node" and its integration within Hydra
  • We discussed and clarified our new Security Vulnerability Disclosure Policy
  • Discussing the idea of a joint documentation effort, we realised the existing documentation of both teams could be improved, for example by following a Standard documentation framework.

Hydra development​

Issues and pull requests closed since the last report

This month, the team worked on the following:

Network resilience to disconnects #188​

If a Hydra node crashes, it can recover its state from disk thanks to the event-sourced persistency mechanism in place. But if a peer inside the head sends messages while the node is down, these messages are lost for this node and this can well lead to the head being stuck.

For instance, in the following picture, we see that if Bob was down when Alice acknowledged snapshot 10, then it will wait forever for this acknowledgement and will refuse to move forward with the head, making it stuck.

Head stuck because of lost message

Head stuck because of lost message

Hydra is designed to deal with non-cooperative peers in a very safe way: close the head! And this situation could be generalized as a non cooperative peer situation. So the safe move is to just close the head.

But practically speaking, closing the head every time a node restarts or a network connection is interrupted can lead to an operations nightmare. So the question we're exploring is, can we distinguish between non cooperative peer or just transient communication issue?

  • ADR 27 gives details about our current strategy
  • #1074 is a first implementation of this strategy
  • #1080 should specify the resulting network protocol so that others could implement compatible hydra nodes

Incremental commits and decommits #199​

In the beginning of this month, some progress on incremental commits and decommits was made. An early experiment about the off-chain / node logic showed that we can re-use the /commit validator and motivated design work on the feature items.

As mentioned above, the protocol extension was split into two items Incremental commits #199 and [Incremental decommits

1057. Both items contain

high-level description, interaction outline and a first design of the on-chain validators which is currently getting discussed by the Hydra contributors and researchers.

Especially the incremental commit is not trivial as the interaction between layer 1 and layer 2 is quite intricate. Observing a deposit on the Cardano mainchain may not be seen by all parties at the same time and this should not lock up the layer 2 process of transactions, while premature usage of committed funds is to be avoided. On the other hand, each step in the protocol needs to be secure in presence of an adversary and unlocking of committed funds must always be possible.

Once this validator design is clear, we can get started implementing one or both of the features to enable more flexible usage of the Hydra head protocol.

Refactored chain state #1049​

Following up the implementation of ADR#24, this marks the first enhancement in a series of refinements, and our goal was optimization.

We eliminated the need for recursive types in persisted chain states, transitioning to a non-empty history model, preserving full backward compatibility with existing systems.

Importantly, throughout this refactor, we've kept the interface between the chain and logic layers entirely unchanged. This ensures a smooth transition and seamless integration with existing components.

One of the notable advantages of this refactor is a reduced persistence footprint. We now store individual points of the chain state, enhancing storage efficiency.

Community​

Open source contributions​

This month some open source contributions were received, and the team was able to contribute back to one project:

Current scaling use cases being tracked​

Hypix​
  • An update of hydraw with improved usability to stimulate user engagement
  • A showcase for Hydra, with an option to productize
Book.io​
  • A Web3 marketplace for tokenized digital eBooks and Audiobooks
  • Requires NFT minting and distribution at scale (for each copy/instance of a book)
  • Opened a discussion to investigate possible approaches to scaling their operations on Cardano
Midnight​
  • DUST airdrop and side-chain operation
SingularityNet​
  • A Web3 marketplace for AI services offered and consumed through a pay-per-use API
  • Discussion ongoing about porting an existing Ethereum solution to Cardano
  • A chance to build on previous Hydra Pay efforts and upgrade the design to support unidirectional micropayments channels
SundaeLabs​
Emurgo​
  • Initial discussions to evaluate building a payments channel network using Hydra
  • Could leverage work done on Hydra Pay by Obsidian

Conclusion​

The monthly review meeting for September 2023 was held on 2023-09-20 via Google Meet with these slides and the recording.

This concludes yet another fully-packed month, this time not only focusing on Hydra but also encompassing Mithril and the broader goal of supporting Cardano's scaling effort to the best of our ability. Meeting and working together in person demonstrated once more, if this were needed, how much a small group of highly motivated people can achieve. It also fueled our desire and consolidated our vision of being a small group of engineers with a clear purpose, scratching our "own itch", contributing to the whatever projects and tools is needed and best for the job at hand, relentlessly prototyping and experimenting collectively to find the best solutions solving actual people's problems.

It is also worth mentioning that Catalyst's Fund 10 outcome shoudl result in more contributions to Hydra (and hopefully Mithril!) in the near term.

Β· 6 min read
Pascal Grange
Sasha Bogicevic
Franco Testagrossa
Sebastian Nagel

This report summarizes the work on Hydra since July 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

This month, the team released version 0.12.0, and the project roadmap has been slightly updated to focus 0.13.0 on network resiliency and bump incremental commit and decommit in priority:

The roadmap with features and ideas

The latest roadmap with features and ideas

Release 0.12.0​

  • Support cardano-node 8.1.2

    • Updated client and Plutus versions

  • Layer 2 protocol changes

    • Authenticated messages
    • Removed redundancy

  • Event-sourced persistence

  • New API endpoints

  • Removal of internal commit endpoint

  • Improved off-chain transaction processing performance

  • Security fixes

  • See full release notes and a list of delivered features

Development​

Issues and pull requests closed since the last report

This month, the team worked on the following:

Update the tutorial and include Mithril #997​

To prepare for the Hydra master class at RareEvo, the team has taken the originally written tutorial for Hydra version 0.8.0 and updated it to work with the latest versions.

The challenge was to write content that is both easily comprehensible and functional across a wide range of user platforms, including operating system and processor architectures.

Besides writing the tutorial, it is essential to ensure that it is kept up-to-date (eg, using continuous integration).

Support cardano-node 8.1.2 #1007​

To be able to use the latest Mithril snapshots to bootstrap a cardano-node for the hydra-node, we needed to make some updates.

The hydra-node uses the cardano-api to establish a connection with the node using the node-to-client protocols. The format there has slightly changed (although versioned), necessitating an update to the version of cardano-api used within the hydra-node.

The way Haskell dependencies are managed required an adjustment of the versions for both cardano-ledger and plutus. These versions are used to construct our off-chain ledger and on-chain Hydra Head protocol scripts, respectively.

As a result, this process has proven to be more intricate than it might initially sound. However, it has ultimately resulted in enhancements to the efficiency of our on-chain scripts.

TODO: how much?

Event-sourced persistence #913​

We want the hydra-node to be efficient in processing events to yield high throughput on processing transactions off-chain.

Work done as part of #186 has demonstrated that the primary bottleneck to faster transaction processing inside the node was the state persistence logic, which simply overwrites the full state with whatever new state has been produced.

For that reason, we changed the persistent state to a sequence of events according to ADR24. Persistence is now done incrementally by saving only the StateChanged deltas.

As a consequence, the first spike confirmed the following performance improvements: master ~300ms β†’ spike ~6ms.

TODO: what are the numbers on master before/after?

Finally, this also opens up interesting possibilities for state observation in clients.

New API endpoints​

This release also includes several additions to the Hydra API. We added the /cardano-transaction endpoint to submit a transaction to the layer 1 network. This feature improves developer experience as Hydra clients do not need direct chain access (eg, connect to cardano-node) to be able to submit transactions.

The other new /protocol-parameters endpoint serves the currently configured protocol parameters used in hydra-node. This provides more flexibility when creating transactions for the head on the client side and avoids configuration or hard-coded values.

On top of this, we also included the hydra-node version inside of the Greetings message. This is very useful for debugging purposes and detecting possible version mismatches.

Removal of 'internal commit' endpoint #1018​

In the previous release, we made an announcement regarding the deprecation of committing to the head through the websocket command. Subsequently, we have taken steps to eliminate this client command, which in turn resulted in the removal of the fuel markers that were previously used to mark the UTXO of the internal Hydra wallet meant for use in the Head.

This simplifies the setup needed to run the Head protocol and improves security since users can directly commit funds from their wallets without sending them to the Head operator beforehand.

Community​

Hydra master class at RareEvo​

We were happy to run a Hydra master class session at RareEvo 2023. The session attracted 30+ attendees for the introductory parts including a presentation on Hydra and Mithril. About 10-15 participants remained for the practical part and following discussion.

We also streamed the event live on Discord, but were not able to interact much there. The responses were positive though and we should be doing more things in the public on this #hydra-live channel.

Several participants managed to use Mithril and synchronize a pre-production cardano-node; two teams effectively initiated Hydra heads, conducted fund transactions within them, and subsequently closed them. The major challenges, as expected, concerned installation and networking. In the future, we intend to ensure the availability of prebuilt binaries catering to a wider range of platforms.

Catalyst Fund10​

The team screened all the proposals mentioning Hydra and Mithril. We submitted 11 community reviews and noticed, in particular, the following proposals:

Conclusion​

The monthly review meeting for August 2023 was held on 2023-08-23 via Google Meet with these slides and the recording, 'broadcasting live from warm and sunny Colorado'!

It has been an interesting and unusual month. Some of the team had been in Longmont, CO to prepare for the RareEvo event and we used the chance to have the meeting in a hybrid setting with some IO stakeholders attending live on-site and about 20 community members online.

This time, the demo was about the updated tutorial and demonstrating the full setup of the cardano-node, opening a Hydra head on the pre-production network, and submitting transactions off-chain in 15 minutes!

The feedback we received included inquiries about the timing, method, and extent of the audit for the Head protocol. While we will have an internal audit, which is already helping us improve the protocol, there are no plans for a significant external audit with funding. We also had the chance to look into and learn about some Catalyst Fund10 proposals involving Hydra. Hopefully, some or all of them get funded and we are looking forward to testing the Hydrazoa concept, implementing the ledger-mode operation, enabling federated Heads, and achieving other objectives.

At the RareEvo event, we had the chance to meet and communicate with various people from the community. This ranges from known Hydra collaborators to tech-savvy stake pool operators, to representatives of successful applications running on Cardano for scaling purposes like book.io.

Also with a new full-time contributor on board, we are keen to add more functionality while the first applications prepare to utilize Hydra in production on mainnet.

Β· 9 min read
Sebastian Nagel
Arnaud Bailly
Sasha Bogicevic

This report summarizes the work on Hydra since June 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Starmap update​

Every couple of months, the team reflects on the themes identified for 2023 (as presented in January), and creates a high level list of possible deliverables, eg using impact maps. This time, the team has come up with the following items:

  • Sustainable open-source πŸ’š

    • Hydra master-class workshop: A concrete session we aim to conduct in an upcoming event or online as a fallback. This will also be a motivation to update our existing tutorials and improve the first-start experience.

    • Engage and support developer community on Catalyst proposals: There are around 30 proposals mentioning Hydra in the current Catalyst funding round and we want to review, comment, try to align, and maybe even promote some proposals. The goal is to provide a platform for many new ideas while avoiding fragmentation and maximizing the reuse of work.

    • Further open up GitHub repositories: We want to provide a welcoming experience to non-IOG contributors and provide an easy-to-navigate group of repositories relating to Hydra.

  • Mainnet mature application πŸ’œ

    • Make Hydra trivial to use: To enhance user and developer experience, we aim to enable a quick and frictionless setup of Hydra, possibly involving Mithril to get started. Our goal is to facilitate the opening of a distributed Hydra head with two nodes on a testnet within just a few minutes.

    • Build a basic head explorer: We have previously experimented with the explorer, and now we are looking to set it up for the long term. The goal is not only to assess Hydra adoption but also to provide a valuable tool for DApp developers. Additionally, we aim to create a visualization that end users can use to answer important questions, such as 'who is running this head?'

  • Drive adoption πŸ’™

    • Deliver the first version of HydraNow to mainnet: It's important that the very promising use case of payments using Hydra is made available to first users on mainnet. As a concrete example, this would be a mobile application 'HydraNow', which uses a hydra-pay service to enable peer-to-peer payment channels.

    • Enable uni-directional payment channels: This will expand the capabilities of any payment channel created using Hydra, allowing deposits and withdrawals while keeping the head open.

Work packages related to these items appear on the technical roadmap (especially in this view) and in our community activities.

Roadmap​

This month, the team released version 0.11.0, which shifts the way Hydra clients need to interact with the hydra-node when committing funds. The project roadmap was also updated to reflect the latest developments and ideas from the starmap:

The roadmap without idea items

The roadmap without idea items

Release 0.11.0​

  • Completes the layer 2 ledger isomorphism with timed transaction support

  • Adds commit from external wallets API, which allows to:

    • Commit multiple UTXO
    • Commit from scripts
    • Commit directly from any key

  • Deprecated: Internal commits via the WebSocket API

  • See full release notes and a list of delivered features

Notable updates​

  • Two new items _elevated from user ideas and improved the API capabilities:

  • [Removing commit from internal wallet #954](Submit layer 1 transactions through hydra-node#954) is a consequence of deprecating this functionality in the previous 0.11.0 release. This will make the code base and documentation cleaner as there will be only one way to commit funds to a head.

  • The first new item derived from the starmap is to Update tutorial and include Mithril #997. The tutorial is already a bit outdated, this will slim it down and incorporate Mithril to get the fastest (secure) bootstrap possible of a hydra-node.

  • As a result of focusing on the very concrete use case of payments for mainnet deployment (and hence 1.0.0 release), multiple items need to (and can) get reprioritized to match the requirements of this use case.

The latest roadmap with features and ideas

The latest roadmap with features and ideas

Development​

Issues and pull requests closed since last report

This month, the team worked on the following:

Authenticate network messages #727​

The Hydra Head protocol paper states:

Each party then establishes pairwise authenticated channels to all other parties.

Hydra: Fast Isomorphic State Channels, p.14

Guaranteeing the authenticity and integrity of the messages received from one's peers is critical to the security of the Head protocol. Initially, we considered deferring this responsibility to the transport layer, for example, leaving it to Hydra node operators to use TLS or other encrypted channels to communicate with their peers. However, this introduced an additional and unnecessary operational burden on operators.

It appeared simple enough to reuse the existing Hydra keys (using Ed25519 curve), which need to be passed to the node, to:

  • sign all messages sent to peers
  • verify all messages received from peers

The net benefit of this feature is to increase the life expectancy of a head, preventing some forms of denial of service attacks or wrongly configured nodes that would lead to a stalled head.

ReqSn only sends transaction IDs #728​

This feature aligns the current implementation better with the original paper, as it requests snapshots using only the transaction identifiers, rather than the full transactions.

The motivation to implement this feature came from different directions:

  • Improve the performance of the protocol by reducing bandwidth usage
  • Make it possible to have 'atomic' transaction sets submitted (#900),
  • Prevent 'front-running' from the current leader which, in the previous implementation, could inject arbitrary (but valid) transactions that peers had never seen before into a snapshot.

ReqSn's snapshots now contain only the list of transaction IDs and each hydra-node validates the snapshot by resolving those ideas against the set of transactions they have seen (through ReqTx). A consequence is that this introduces the possibility of space leak in the event a submitted valid transaction never gets included in a snapshot, but this should not be a problem in practice.

Note that the specification has been updated to reflect this change.

GitHub security advisories​

There was a bug in the multi-signature verification which could compromise off-chain security of a Hydra Head protocol. Although the fix was quite simple, we decided to use a new GitHub feature to create the first GitHub security advisory for Hydra.

The process creates a separate GitHub repository where potential security issues could be discussed privately (between the reporter and the maintainers) since potential attackers should not be aware of any issues until they are fixed. The team scored this issue using CVSS (The Common Vulnerability Scoring System), the score was moderate (5.5), and they didn't request a CVE (Common Vulnerabilities and Exposures) for this (yet).

The process overall works well, but Hydra CI is not checking the builds in these private, one-off forks so there is a risk of merging code that doesn't compile.

Moving to GHC 9.2.7 #841​

GHC 9.2 series have been around for more than a year and the whole Cardano ecosystem is gradually moving to use this new compiler version. Moreover, GHC 8.10.7 does not work reliably on aarch64 architectures, eg Mac M1/M2.

Moving to this new version entailed some significant changes in the code and also in the Plutus scripts:

NameAfter (bytes)Before (bytes)Ξ”size
Ξ½Initial42894621- 7%
Ξ½Commit21242422- 12%
Ξ½Head91858954+ 3%
ΞΌHead41494458-7%

Community​

Hydra master-class​

As already mentioned above in our starmap update, we aim to have an educational session at the upcoming Rare Evo event:

Whether you are building decentralized applications which need to be fast and scale well, or you are creating infrastructure for other builders on Cardano, we will show you how to use Hydra to make your applications and platforms utilize fast off-chain transaction processing via the Hydra Head protocol.

In this session you will learn what Hydra is all about, how to build scalable applications in a live coding session, get to know the hydra-pay and hydra-auction projects, and be guided through exercises to get your hands on these APIs and early SDKs.

We are currently putting together a detailed outline and will send out communications on how to register for this exclusive session within the next 1-2 weeks. Stay tuned.

Conclusion​

The monthly review meeting for May was held on 2023-07-26 via Google Meet with these slides and here is the recording.

Although we had planned an awesome demo for this month's review meeting, showcasing a Hydra head hack without the authenticated messages feature, we encountered some live demo problems (lesson learned: always record a backup!). While we might present it next time, this situation emphasizes the need for continuous improvement in developer and user experiences.

We haven't received many questions on our journey to further mature the Hydra software stack to support various use cases building on it. However, the recently kicked-off Catalyst Fund10 sparked a nice discussion on how to handle all these great new ideas while being mindful not to fragment the scaling efforts too much.

Open protocols mean that new ideas can be incorporated not only into the various code bases, but also in the specification and standards which ensure interoperability. We discussed means to ensure adherence to standards in a light-weight agile way and the challenges of educating potential contributors in specification-driven development.

Next month we'll be at RareEvo, but might have the monthly just before in a hybrid session from Colorado. Until then, we'll make Hydra trivial to use and get started on our new objectives.

Β· 7 min read
Sasha Bogicevic
Sebastian Nagel

This report summarizes the work on Hydra since May 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

While there was no release this month, the team implemented several notable features, which will be released soon as version 0.11.0:

The roadmap without idea items

The roadmap without idea items

Notable roadmap updates​

The latest roadmap with features and ideas

The latest roadmap with featuresand ideas

Development​

Issues and pull requests closed since last report

This month, the team worked on the following:

Commits with multiple UTXO #774​

One of the early adopting projects is exploring how to move scripts from layer 1 to layer 2. For that purpose, it was necessary to not only commit the actual script UTXO, but also a "regular" UTXO holding only ada to be used as collateral (the cardano-ledger always requires collateral although it would not be necessary on a layer 2).

To enable this, the specification and on-chain protocol needed updating. Before a protocol participant could commit zero or one UTXO, which changed now to a list of UTXO. As the specification is now part of the repository, it could be kept consistent within the same pull request.

Despite being a breaking change, leading to new Hydra script hashes to be published and used starting with version 0.11.0, this change was suprisingly easy to do and demonstrated the amenability of the Head protocol and the system architecture.

Commits from external wallet #215​

The team started to mark fuel some time ago as it was an easy workaround to distinguish UTXOs that can be committed into a head apart from regular outputs holding ada to pay for fees - the so-called fuel. However, this required users to "send funds" they want to commit first to the hydra-nodes internal wallet and involved additional steps in tagging such outputs with a special datum hash

To commit from external wallets, a new API endpoint was introduced for the purpose of drafting a commit transaction. The clients would request such draft transaction by sending a POST request to /commit and the hydra-node would respond with a transaction already authorized by the internal wallet. If the commit involved user funds (empty commits are still possible), then the client application would need to sign the transaction using the corresponding signing key. Also, submitting this transaction has shifted from hydra-node to the client.

This removes direct custody of hydra-node over user funds since clients can now use whatever key they own, not known to the hydra-node, to do a commit step and no single hydra-node has access to user funds used in the Head protocol.

Within this work package, marking fuel became deprecated and all UTXOs owned by the internal wallet are considered fuel. Fuel marking wil be completely removed in the future. Furthermore, a good old HTTP-based API is now used for the new query (so far it was only WebSocket-based), which prompts a potential shift to using OpenAPI as API specification since AsyncAPI does not describe synchronous requests well.

Benchmark performance of Hydra Head #186​

Low confirmation time is a key feature of Hydra Head protocol and is needed for some use cases. The existing end-to-end benchmarks have been revived and tailored for a baseline scenario, one with a single hydra-node and a single client. While this scenario is not representative of target deployments, it's interesting as it gives us an upper bound on the performance of a Hydra Head network.

The results have been somewhat disappointing, and further investigations lead to a few insights:

  • There was a misconfiguration in the RTS of the hydra-node executable which was therefore not taking advantage of parallelism
  • We identified the main bottleneck to be persistence of the node's state, which is currently done by overwriting a single file with the JSON content of the full state on state change which is pretty inefficient. As a consequence, the team will work on improving the persistence strategy as described in this ADR
  • More benchmarks:

Operating hydra nodes​

As a "dogfooding" exercise, the Hydra team is operating a Hydra Head on mainnet on top of which is running our hydraw application. The Head protocol got stuck a couple of times and post-mortem investigations lead to a few improvements in how to operate a hydra-node and network:

  • Better reporting on the version of executable hydra-node and hydra-tui which now report the Git SHA1 at which they were built
  • Reduction in the volume of logs emitted by hydra-node by removing some chatty network-related logs and using ids to link Begin/End pairs
  • Rework the log-filter tool to provide timings for various events and effects keyed by transactions

Community​

Hydra hackathon / workshop​

The Hydra team is considering holding a workshop at/around Rare Evo at the end of August and is in contact with the event teams at IOG and the Rare Evo organizers. The concrete format, scope and agenda is still a bit unclear as we are contemplating whether to do a workshop/tutorial style or rather a introduction + challenge setting event. If it does not work out for Rare Evo, we will find another event or do it ourselves.

If you are reading this and would be interested in joining such an event please drop us a line on discord or DM @ch1bo! Ideally along with some thoughts on preferred format or what you would be interested in.

Hydra for Auctions contributions and closing of project​

One of the Hydra lighthouse projects is slowly coming to an end. The collaboration project between IOG and MLabs on using Hydra for auctions is currently finalizing documentation and creating demonstration running the whole thing on a public testnet. Although the demo video was not available at the copy deadline of this report, watch this space for more about this next month.

The project yielded multiple github issues containing ideas and sparked great discussions on improving Hydra like reported last month. It is also the first project which demonstrates how to move smart contracts from the layer 1 (L1) to the layer 2 (L2)! Overall it is a great example of establishing crucial state on L1 and achieving scalability through Hydra as L2.

The code is fully open source and available on Github hydra-auction.

Conclusion​

The monthly review meeting for May was held on 2023-06-21 via Google Meet with these slides and here is the recording.

It was a fairly straight-forward month and consequently unexciting review meeting this month. Unfortunately, we could not release 0.11.0 yet, but we wanted to get the quite significant change of supporting commits from external wallets done first. This feature in particular was more involved than expected, but as the demonstration in the meeting showed, we are in the final stages of getting this over the line.

Besides some nice findings to potential performance improvements for layer 2 transaction processing, there was not much to announce this time around. Behind the scenes, however, there have been great progress on the Hydra for Payments project and the next updates are going to be more interesting again.

Despite holiday season approaching, we will march on, steadily adding features and enabling more and more use cases to scale through Hydra.

Β· 9 min read
Sebastian Nagel
Pascal Grange
Franco Testagrossa

This report summarizes the work on Hydra since April 2023. It serves as preparation for the monthly review meeting (see slides and recording), where the team updates project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

This month the team released version 0.10.0 which includes many important features. The project roadmap was only slightly updated this month and already saw one more feature completed:

The roadmap without idea items

The roadmap without idea items

Release 0.10.0​

  • First mainnet compatible release of hydra-node including technical changes and documentation

  • Mainnet exposure currently limited to 100β‚³ per participant

  • Added some missing features to the client API (short-term solutions)

  • Some quality of life improvements in running the hydra-node

  • Full release notes and a list of delivered features

Notable roadmap updates​

  • Got new input and a concrete scenario for benchmarking (off-chain) performance of a Hydra head. As it is a very basic one, we moved the item from an idea to a feature and started work on it.

  • Added a new feature item to add Hydra as a tool to developer platforms within our agenda of promoting Hydra as an open-source platform for scalability on Cardano.

  • Already completed a first feature for 0.11.0 and considering whether to release it as early as possible with latest advances.

The latest roadmap with features and ideas

The latest roadmap with features and ideas

Development​

Issues and pull requests closed since last report

This month, the team worked on the following:

Timed transactions #196​

To realize the Hydra Head protocol, a hydra-node observes and follows the chain progress on the layer 1 (L1). Until now, this component was only observing protocol related transactions. Now, on every block roll forward, a Tick event carrying the notion of time from L1 is observed by the hydra-node and is used to validate transactions in a Hydra head. This means that clients can submit time bounded transactions to an open head and expect them to be validated using the same slot that would be used on L1. It is important to mention that time only advances on L1 when a block is produced.

Timed transactions in a Hydra Head state channel

Timed transactions in a Hydra Head state channel

This feature will make the Hydra L2 ledger now en-par with UTXO features available on the Cardano L1. A logical next step in this direction could be to make time in the state channel advance every configured slotLength (e.g. every second) using the system clock in between blocks as a form of dead reckoning.

Removing --ledger-genesis #863​

The hydra-node had two command line options to configure the ledger used for validating layer 2 (L2) transactions: --ledger-protocol-parameters and --ledger-genesis. The former option, which is self-explanatory, allows configuration of the Cardano protocol parameters to be used. Often, the same parameters as those on L1 are configured, or similar parameters with reduced fees, for example. On the other hand, the second option required the genesis-shelley.json file previously used to initialize the Shelley era by the cardano-node.

When we started using the current slot in the L2 ledger (see above), we realized that only the start time and slot length are effectively used from that configuration file. Moreover, it would be quite surprising if those were different and slots would be longer or shorter on L2 (unless explicitly configured). We opted to remove the option altogether and have the hydra-node fetch the genesis parameters from the Cardano network. This makes the system easier to configure and more isomorphic to L1.

Improving CI runtime​

The Hydra project embraces Test Driven Development and implements Continuous Integration (CI), checking all these tests pass and more.

The CI could sometimes take as long as an hour or more to run, which has a negative impact on the project's workflow. For instance, all the project's branches have to be fast-forward with master before being merged. So if all the tests on a branch are green and the pull request has been approved but is lagging a bit behind master, it has to be rebased, so the CI has to run again, incurring a one hour or so delay in this case before being able to merge it. The situation becomes worse when several pull requests are ready to be merged.

Analyzing the run from May, 10th we can see that:

  • Building and testing takes 19 minutes for the longest
  • Generating haddock documentation and running the benchmarks takes 28 minutes for the longest
  • Documentation (which will need artifacts generated in previous steps) will take 14 minutes
  • In total, this run took 1 hour and 16 minutes.

Let's focus on the build and the testing stage first. We're expecting the plutus-merkle-tree to run fast but it took 8 minutes and 52 seconds , 7m and 11 seconds being spent setting up the build environment. In other words, 81% of the build time is downloading binary dependencies from some nix cache.

Compiling the code requires cabal and other nix dependencies that will trigger massive downloads. Instead, let's, straight on, run the tests with nix and let nix decide what needs to be compiled. Sometimes, most of the code will not have changed and the test binary will already be available in some nix cache to be run without any compilation step.

This has been done in #867. Merging this PR, the build on master took 45 minutes and, specifically, the same plutus-merkle-tree job only took 1 minute and 44 seconds, only 20% of the time observed before.

Then, let's focus on documentation (14 minutes). Most of the time spent by this process is website optimization. It makes sense for the documentation that will actually be published on the website (master or release). But what about all the builds in branches for which the website will never be published? We need to keep this documentation step in branches because it gives us sanity checks, preventing broken links, for instance. But we can definitely remove the optimization step.

This has been done in #880 and it saves 10 minutes from this step.

Our first goal was to reduce CI execution time when pushing on branches and this has been improved. We're now having execution time significantly under 30 minutes where it used to be 45 minutes or even an hour.

We had some issues with compilation output, obfuscated by nix, which have been solved by #889.

Every morning, we rebuild our master branch and we can observe the whole execution time on the following graph (in seconds):

CI perf

C.I. execution total execution time

Although we observed performance improvements on branches CI execution time, master execution time has not been reduced that much. We may save 10 minutes from the documentation step because optimizing the unstable documentation is maybe not worthwhile. But what's more problematic here is the process variability.

This variability can be explained by nix cache misses. That's something we need to investigate. It's hard to optimize a process with buffers, especially here where in case of a cache miss, recompilation has to happen and takes time. So every cache miss introduces several minutes of overhead which explains why we observe so much variation between two days with this master execution time.

Next steps:

  • Inspect why we have an unexpected random cache miss
  • Improve haddock generation time (15 minutes)
  • Reduce bench time (we probably don't want to run the whole benchmark suite for every single commit, or a smaller one)
  • Focus on the changed area (do not compile everything to generate the monthly report)

Community​

Hydrozoa #850​

This month, the project saw a new kind of contribution from the community. @GeorgeFlerovsky has written a research piece about an adaptation of the (Coordinated) Hydra Head protocol into a new flavor - Hydrozoa. The article is currently being examined and discussed on GitHub. Feedback so far has been positive. Of course, one does not simply change the Hydra Head protocol (pun intended), but the ideas contained could drive evolution and be followed up with concrete protocol extensions. Very much like the ideas presented in the original paper.

Hydra for Payments project update​

In this collaborative effort between IOG and ObsidianSystems, we are pushing the frontiers of using Hydra in payment use cases. It will lower the entry barrier for developers and ultimately users to leverage Hydra L2 for sending and receiving ada and Cardano native assets with very low fees and sub-second finality.

The project is in its second phase where the open-source hydra-pay library is being expanded with necessary features while the team pushes for building a dedicated mobile application.

With the recently released hydra-pay version 0.2.0, an end-to-end workflow of the Android App nicknamed "HydraNow" can be realized. This app will act as a layer 2 wallet quite like a Bitcoin Lightning Wallet and drives feature development in both hydra-pay and hydra in the background.

Two instances of HydraNow (in browser) connected via a hydra-pay channel

Two instances of HydraNow (in browser) connected via a hydra-pay channel

Spanish translation​

Last, but not least, we would like to thank @Agustinblockchain for their contribution of a Spanish translation #866 of the hydra.family website πŸ‡ͺπŸ‡Έ πŸŽ‰

Conclusion​

The monthly review meeting for May was held on 2023-05-24 via Google Meet with these slides and here is the recording.

The monthly review meeting was lively and we had stakeholders from IOG as well as interested community members join. They were well served by two very nice demos shown by ObsidianSystems and IOG teams.

After having dealt with some issues last month, we are happy to have the first mainnet-capable version released and have already another feature completed this month.

It is great to see that more and more contributors from the community are stepping up to become advocates of the technology. A community is forming and we realize that the project could need some help from someone dedicated to keep track of all the great things happening. What a great problem to have!