Please describe your proposed solution.
This project will implement the Hydrozoa protocol — an adaptation of the Coordinated Hydra Head protocol with more lightweight and scalable Hydra Heads.
Hydrozoa introduces cheap and deterministic state update transactions as the default way to commit utxos to and decommit utxos from the Hydra Head. A similarly cheap finalization procedure can be used to stop operating the head if consensus can be maintained throughout its life. The halt and dissolve procedures are an alternative workflow available if L2 consensus breaks down — optimized analogs to the close and fanout operations in the Coordinated Hydra Heads protocol.
Introduction
The Hydra Head protocol allows a group of participants to temporarily transfer control over a subset of utxos from the Cardano mainnet (L1) ledger to a private unanimous consensus protocol (L2) run by the participants instead of the Ouroboros consensus protocol running on the whole Cardano mainnet. While the Hydra Head controls these utxos, transactions involving them are quickly broadcast among the participants and then confirmed with immediate finality as soon as all participants sign a corresponding snapshot. The utxos resulting from the L2 transactions can be brought back under L1 control by finalizing an L2 snapshot (via Close/Contest transactions) and then fanning them out on L1 from the state utxo.
The protocol was developed before Plutus was added to mainnet, effective design patterns emerged for building dApps in the eUTXO model, and the Vasil enhancements enabled a completely different approach to dApp design on Cardano. It can be improved by applying the lessons learned over the past year.
Design
The main design ideas of Hydrozoa are:
- Eliminate the initialization phase — open the Hydra Head immediately with an empty L2 active utxo set.
- Commit utxos on L1 to the head simply by sending them to a native script address controlled by the participants' keys.
- Transact on L2 like before, using Cardano ledger rules to apply transactions to the L2 active utxo set.
- Decommit utxos via a new L2 request to remove certain utxos from the L2 active utxo set, validated like an input-only transaction via modified Cardano ledger rules.
- While the head is open, periodically collect commits and release decommits on L1, updating the major version in the L1 head state. Semantic versioning is used because these updates are backward incompatible with previous snapshots — updates change the balance of funds at the head state utxo.
- If participants can maintain L2 consensus, finalize the head, and release its L2 active utxo set on L1 just as cheaply and efficiently as if all utxos decommitted.
- If L2 consensus breaks down, halt the head and dissolve its remaining funds to produce outputs corresponding to the L2 active utxo set of the snapshot with which it was halted. Dissolution is specified and authorized via multi-signed certificates instead of multi-signed transactions.
- Spin off the contestation mechanism so that it can only affect the head state when the contestation deadline elapses, or all participants have exercised their right to contest.
- Updates should be used during normal operation to commit and decommit utxos, finalization should be used if the participants want to stop operating the head, and the contestation mechanism should only be used to halt the head if consensus breaks down.
The L1 component of the Hydra Head protocol becomes simpler, cheaper, and more scalable. In exchange, the L2 component is somewhat more complicated. However, managing complexity in the L2 and off-chain components is usually easier and cheaper than in the L1 components, which incur transaction fees and often use smart contracts that must be carefully developed and audited.
The full design of the Hydrozoa protocol has already been meticulously thought-out and described in the following whitepaper:
The paper has been shared with the Hydra core dev team and was well-received by them. They have forwarded it to the IOG researchers who developed the original Hydra Head protocol for further comment. In principle and at a high level, the participants in the discussion thread agree that the features described in the Hydrozoa paper make technical sense and could be feasible:
Project scope
The whitepaper has described the mechanisms of the protocol in great detail so that a technical reader can form a concrete understanding of its operation. To this, a full specification would add concrete definitions for the following parts of the design:
- The validators and minting policies – datums, redeemers, local utxo logic, etc.
- The auxiliary deterministic algorithms:
- "Algo_settle" to select the largest prefix of commits to collect per major snapshot and derive settlement transaction trees.
- "Algo_dissolve-cert" to derive dissolution certificate trees.
- "Algo_dissolve-tx" to derive dissolution transaction trees from dissolution certificate trees.
- The asynchronous messaging protocol used by participants in the Hydrozoa head.
Once the above is sufficiently specified, a smart contract dev team can proceed with implementation. The on-chain logic is expected to be straightforward (its simplicity was an explicit goal of the design). However, the off-chain logic is significantly more complex than in the Hydra Head protocol currently implemented in the input-output-hk/hydra repository. This is where the bulk of the Hydrozoa project's effort will be directed.
The Hydrozoa project will be developed with the Hydra repository in mind, and the deliverables of our project should strive to be applicable to that repository. To the extent possible, we will contribute PRs and ideas wherever appropriate.
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
As we discovered while applying the Hydra Head technology in the development of a non-trivial smart contract application, the Hydra Head still has a few major limitations that are an obstacle to its widespread adoption in commercially viable apps on Cardano mainnet.
As we mentioned in the hydra auction whitepaper (Jan 2023), the main obstacles to commercial viability and scalability of a typical hydra-based application are:
- The set of participants in a Hydra Head is fixed before the head opens – no new participants can enter the head while it is open, and no participant can leave the head without causing the head to close.
- The set of utxos and funds in a Hydra Head is fixed before the head opens – no new funds can be brought into the head or withdrawn out of the head until it is closed.
- There is significant overhead in cost and time associated with opening and closing hydra heads.
Hydrozoa addresses the second limitation directly by embracing incremental commits/decommits to/from open heads at the core of the protocol. Furthermore, the first limitations can potentially be lifted via the "major snapshot" mechanism that Hydrozoa introduces – through the implementation of dynamic membership within a head will be left for a future project.
Lifting these restrictions will allow a diverse range of L2-enabled applications to flourish on Cardano because it will become cheap and easy to open and operate hydra heads for short periods of time or as persistent services. Furthermore, these lightweight hydra heads will make launching a network of heads more feasible, similar to Bitcoin's Lightning network.
How do you intend to measure the success of your project?
The success of this project will be determined by whether the mechanisms contemplated in the Hydrozoa protocol design bear out in practice, providing the following improvements over the current Hydra Head implementation:
- An easier and cheaper process to open, operate, and close hydra heads.
- Easy and cost-effective commit and decommit transactions to move funds in and out of open hydra heads.
These improvements should be compared against the additional complexity and computational resources required to run the L2/off-chain part of the Hydrozoa protocol relative to the Hydra Head protocol.
We will keep these benefit/cost metrics in mind during the project timeline and develop benchmarks to monitor them as early as feasible in the project roadmap.
Please describe your plans to share the outputs and results of your project?
The entire project will be open source and richly documented. It will be pursued with regular communication with relevant stakeholders like the Hydra core dev team, the Cardano developer community, and entrepreneurs in the ecosystem.
It is anticipated that many spinoff applications of the Hydrozoa application may form from the usage examples that we will develop during the course of the project – we already have informal concepts/designs for auctions, voting, stablecoins, and other applications that use the Hydrozoa features. We are well-connected with the Cardano entrepreneurs and developers who may be interested in pursuing these new designs.