Please describe your proposed solution
This project will implement the Hydrozoa protocol — an adaptation of the Coordinated Hydra Head protocol with more lightweight and flexible 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. Lastly, Hydrozoa allows the Hydra Head participants to add/remove members by unanimous consensus while the head is open.
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.