Skip to main content

February 2023

· 7 min read
Sebastian Nagel

This report summarizes the work on Hydra since January 2023. It serves as preparation for the monthly review meeting, where the teams update major project stakeholders on recent developments to gather their feedback on proposed plans.

Roadmap​

Looking at the roadmap, there are a few things that changed this month:

  • In general, there will be several items in flux as we align the technical roadmap to support our high-level objectives for the year.

  • Also note that we have not had a release in a while and we want to have smaller faster releasable items again.

  • Aligning implementation with HeadV1 specification #452 was more work than anticipated. There was quite some back and forth with the writing of the specification and discussions with researchers leading to scope creep.
    Most importantly, we made on-chain behavior consistent with specification.

  • Version 0.9.0 will be the first release to be developed against a full technical specification. We expect a release in early March.

  • Version 0.10.0 will be the first mainnet compatible release. For this, we created and groomed the main feature item Mainnet compatibility #713:

    • Not only making it technically compatible but also adding guard rails to limit risk (“not shoot yourself in the foot .. with a real gun now”) and documenting known issues.

  • For a fully maintained version 1.0.0 we still need to address some things, but we aim for an increased rate of planned releases in the next months as we march toward it.

The latest roadmap with multiple new items and starting to reflect Hydra objectives of 2023.

Development​

Issues and pull requests closed since last report

This month, the team worked on the following:

  • Aligning specification and implementation. This major feature item was the topic we worked on over the last couple of months. This time we could finish the major, must-have parts and can continue now on other features. Notable things from this month were:

    Pushing out contestation deadlines: The original paper defined that all participants need to be contesting within the contestation period (after close, before the deadline). In discussions with researchers last year, we identified better semantics: the contestation deadline gets "pushed out" on each contest. This has the benefit that the period needs to only accommodate the minimum time required to get a single contest transaction into the blockchain. Before it was depending on the size of the Hydra head - each participant can contest once.

    Align off-chain protocol logic: While most concerns addressed were about the on-chain scripts of the Hydra protocol, this is about the layer two protocol logic. That is, which messages are exchanged between Hydra nodes and how a node reacts to them. Here we realized that the implementation was slightly different from the formalism used in the paper and specification. This makes it non-obvious whether the behavior is exactly as specified or whether the specification can even be implemented into a working system.

    To clarify this, we put in some effort to align the implementation with the specification and the other way around. This allowed us to reason through our behavior tests whether the protocol as specified is sound as well. Below you see an excerpt of the Haskell code against the LaTeX pseudocode formalism:

  • Profiling Hydra transactions. We will want to maximize the capability of the Hydra Head protocol. This includes writing the on-chain scripts efficiently. Besides having transaction cost benchmarks, we worked on a profiling workflow for Hydra protocol transactions and published a tutorial on the Hydra website. This allows any contributor to Hydra to profile the scripts used in these transactions and identify code that uses a lot of the memory or CPU budget in flame graphs like this:

    [Interactive]Head not closable/limiting script size discussion + acceptance property

Community​

  • Audit guidelines. Hydra is an open-source project and, as such, should be freely used, reviewed and audited. The goal of audits and peer reviews is to increase confidence in the security of a system. However, conducting an audit is also very expensive and not in the scope of our current budget. All the while, the worth of an audit is not the same to all users, some will not even trust an audit they have not paid for themselves, while others do not care at all and would blindly trust the word of the maintainers.

    While the Hydra project continues to seek for funding to eventually pay for an audit of the protocol specification and the hydra-node implementation, it is a prerequisite that the necessary artifacts for such an audit exist. As we have been creating them in recent months, we also worked on guidelines for auditors, now published on our website. These guidelines should serve as a starting point and scope description of what would be most crucial to audit.

  • New tutorial. This month we received a great contribution from @perturbing, who created an end-to-end tutorial on using a hydra-node and opening a Hydra head on the testnet. We gladly adopted this tutorial and aim to keep it up to date with upcoming versions of the hydra-node. It will provide a great starting point for new users and makes the project more approachable. Thanks! 💚

  • Hydra for Payments demo. As we are about to kick off the next phase of the payments use case with Obsidian Systems, they demonstrated the use of hydra-pay in a new backoffice-like view, listing multiple payment channels and providing a great teaser of using payment channels for pay-per-use APIs or cashback use cases (micro-transactions).

  • Hydra for Voting. The project with Catalyst and Cardano Foundation on voting with Hydra (or rather tallying with Hydra) showed some progress. They have contributed Merkle Trees to Aiken, which will be useful to prove the correct tallying of votes in the L2. They started work on a hydra-java-client and provided valuable feedback on the hydra-node API over the last month.

  • Hydra on Demeter. The folks from @txpipe have been working on integrating Hydra into their platform-as-a-service offering, Demeter. This is a great way to get started with running a hydra-node as a service and we plan on integrating one instance into our long-running hydraw demo. It's still not fully released, but the teams are working together to make this integration great. Thanks for providing this service! 💚

  • New discord category. The Hydra project will be using Discord a bit more in the coming weeks and months. For that, a new category on the IOG Technical Discord server has been created. Look out for news and, most importantly, invites for the next month's review meeting in the new Hydra #announcements channel!

Conclusion​

The monthly review meeting for February was conducted on 2023-02-27 via Google Meet - slides / recording.

This month's installment featured two demos, one about the Hydra Payment channels, and another about the progress on the Hydra for Auctions project. It was great to showcase not only core development progress on the specification and protocol implementation in the hydra-node, but also to see contributions from the Community on tutorials and tooling (Demeter integration).

An exciting, but also challenging next step will be to aim for mainnet compatibility and at the same time deliver quick releases to enable these lighthouse projects and the increasing number of use cases explored by the builders of Cardano.