Cardano Layer 2: Hydrozoa protocol for lightweight and flexible Hydra Heads for Cardano

[GENERAL] Name and surname of main applicant

George Flerovsky

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

Individual

[GENERAL] Requested funds in ada

300000

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

9

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language

No

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

Implement an MVP of the Hydrozoa protocol, which improves upon Hydra Head with a direct single-step open transaction, easy commits/decommits, simpler/cheaper L1 code, and flexible membership.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

No

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

Yes

[GENERAL] Please provide here more information on the open source status of your project outputs

As recommended by Cardano CIP-0001, all software and code will be licensed under Apache-2.0, and all docs will be licensed under CC-BY-4.0.

[SOLUTION] 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:

1. Eliminate the initialization phase — open the Hydra Head immediately with an empty L2 active utxo set.
2. Commit utxos on L1 to the head simply by sending them to a native script address controlled by the participants' keys.
3. Transact on L2 like before, using Cardano ledger rules to apply transactions to the L2 active utxo set.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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:

• Hydrozoa: Lightweight and scalable Hydra Heads

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:

• Discussion thread with core devs on the Hydra repository's Ideas forum

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:

1. "Algo_settle" to select the largest prefix of commits to collect per major snapshot and derive settlement transaction trees.
2. "Algo_dissolve-cert" to derive dissolution certificate trees.
3. "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.

[IMPACT] Please define the positive impact your project will have on the wider Cardano community

As we discovered while applying the Hydra Head technology in the development of a non-trivial smart contract application (Hydra auction), 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 first mentioned in the hydra auction whitepaper (Jan 2023), the main obstacles to commercial viability and scalability of a typical hydra-based application are:

1. 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.
2. 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.
3. There is significant overhead in cost and time associated with opening and closing hydra heads.

Hydrozoa addresses all three of these limitations:

1. It has dynamic head membership — members can be added/removed by unanimous consensus while the head is open.
2. It embraces incremental commits/decommits as the default and easiest way to get funds into and out of the head.
3. It simplifies the L1 procedure to open/close a head as much as possible — opening a hydra head is a single-step transaction.

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.

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

Capability

George is the author of the Hydrozoa whitepaper. He has significant experience with the Hydra Head protocol and implementation via his involvement in the Hydra auction project from Sep 2022 to Feb 2024. He has carefully studied the associated research papers and specs, and he has developed an intimate understanding of the Hydra implementation in input-output-hk/hydra repository. He has contributed to discussions about important recent features in the Hydra roadmap (released in version 0.11.0):

• Commits from external wallets
• Allow commits with multiple UTxO
• Support timed transactions on L2

George has been prolific in the smart contract application development ecosystem on Cardano. He has helped develop the design, define the project roadmap and budget, and oversee the successful development of the following applications:

• Hydra auction — an L1/L2 hybrid application that can host the bidding process inside of a Hydra Head, providing a livelier and cheaper bidding experience.
• Grabbit — an L1-based auction platform that allows bidders to participate without interference from each other or the seller (i.e. no utxo contention) and without any privileged third parties (i.e. batchers).
• Cardano Open Oracle Protocol (COOP) — a protocol and SDK for publishing and consuming on-chain data with proof of provenance from the publisher and flexibility in publication cost-sharing between the publisher and consumer of data.
• Equine — an NFT-based horse racing, breeding, and trading game.
• Metera — a decentralized protocol to create tokenized portfolios of assets balanced via a smart-contract-based pricing function that incorporates performance metrics and ESG ratings provided via oracles.
• Optim — liquidity bonds and other innovative yield products built on Cardano.
• LambdaBuffers — a schema language and code generation toolkit that allows developers to define algebraic data types in a language-agnostic format and then derive corresponding code in a plethora of supported languages.
• Dynamic NFT metadata systems for multiple games
• Governance/DAOs

Jonathan and Philip at Anastasia Labs are highly skilled developers who have made significant contributions to various community projects, including Lucid, Agora, Liqwid-Plutarch-Extra. They have had experience developing and publishing end-to-end DApps, including production projects such as Discovery (SundaeSwap Liquidity BootStrapping Mechanism). They have audited a large number of protocols, including MinSwap, Genius Yield, Optim Finance, Wanchain, Lenfi, Encoins, FluidTokens, Spectrum Finance, and Atrium Labs. In addition to their project involvement, they have been actively engaged in the developer experience domain. They have actively participated in educational panels focused on DApp Security Practices and Design Patterns, and they have served as co-chairs of the IOHK developer experience working group.

Furthermore, their collaboration with Emurgo Academy has been instrumental in educating aspiring developers, with their team playing an essential role in this endeavor. We have also recognized and recruited a number of exceptional talents from the courses.

They have developed software development kits (SDKs) that facilitate the integration of existing dApps with other systems through off-chain code. Their team has also designed various protocols, including bridges and staking systems, while also actively contributing to open-source smart contract languages and their associated standard libraries.

[PROJECT MILESTONES] What are the key milestones you need to achieve in order to complete your project successfully?

Specification and architecture:

• Specification document for on-chain validators and minting policies.
• Specification document for the auxiliary deterministic algorithms.
• Specification document for the async messaging protocol.
• Architecture document.
• Open-source project repository and project board.

Basic Head state model and on-chain transitions:

• On-chain and off-chain code for the L1 state of the Hydrozoa protocol.
• Implementation of the L1 state model.

Incremental commits/decommits and other off-chain data systems and ledgers:

• Commit and decommit operations for open Hydrozoa heads.
• Data models and systems that track pending commits, the L2 ledger's active utxo set, utxos decommitted by L2 participants, and other relevant data for the L2 protocol.
• Implementation of the L2 consensus state model.

Snapshots, participant messaging protocols, halting/dissolution:

• Snapshot operations and participant messaging protocol.
• Halting/contestation/dissolution operations.

Dynamic membership and deterministic algorithms for certificate/tx trees:

• Implementation of operations to add/remove members to/from an open head.
• Implementation of the auxiliary deterministic algorithms that allow the L2 utxo set to grow in size and for more decommits to be handled between snapshots.

Public testnet, documentation, and wrap-up:

• Finalized documentation, examples, and tutorials for the project.
• Complete test suite for the major components of the Hydrozoa architecture.
• Public testnet deployment
• Project closeout video
• Project closeout report

[RESOURCES] Who is in the project team and what are their roles?

George Flerovsky, Lead Architect/Developer

Formerly a Delivery Manager at MLabs Ltd (up to Feb 2024)

Twitter: SwiftlyUnmoving

LinkedIn: George Flerovsky

George is the author of the Hydrozoa whitepaper. He has significant experience with the Hydra Head protocol and implementation via his involvement in the Hydra auction project from Sep 2022 to Feb 2024. He has been prolific in the smart contract application development ecosystem on Cardano. He has helped develop the design, define the project roadmap and budget, and oversee the successful development of the numerous Cardano applications.

Philip DiSarro, Smart Contracts Developer

CEO and founder of Anastasia Labs

Twitter: phil_uplc

Philip has an MS in Compiler Development & Programming Language Theory. He was the lead smart contract architect of many features on WingRiders DEX. Philip has also made significant contributions to the Cardano developer ecosystem. As a co-chair of the IOHK developer experience working group he worked to identify and resolve pain points that DApp developers experience in Cardano, and had an integral role in getting Lucid & Plutus Simple Model included in the Plutus Pioneer Program. He has a vast wealth of experience in smart contract security and auditing on Cardano.

Jonathan Rodriguez, Smart Contracts and Typescript Developer

Twitter: solidsnakedev

Jonathan is a highly skilled smart contract developer specializing in Cardano, a blockchain technology that he is deeply passionate about.

His passion in smart contract development drives him to constantly polish his technical knowledge. In the pursuit of that knowledge he obtained the following certifications: Cardano Solution Architect, Cardano Developer Professional, and Associate Certificate.

With an extensive background in Haskell development, which is a critical language for Cardano, he possesses a thorough understanding of functional programming concepts.

His expertise extends to various aspects of the Cardano ecosystem, including the Cardano Toolchain, Transaction Structure, Plutus Smart Contracts, Native Tokens, DApp Connector, and other essential components. 

Jonathan is well-versed in conducting use case analysis and tokenomics, as well as interfacing with decentralized storage, server APIs, and integrating databases.

He is knowledgeable in establishing robust CI/CD (Continuous Integration/Continuous Deployment) flows and integrating them into development processes. Additionally, he is skilled in conducting thorough unit testing to ensure the reliability and security of his smart contract solutions.

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources

Lead Haskell developer - 1 individual - ADA 200K.

Haskell developers - 2 individuals - ADA 100K.

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

The costs described in this proposal's budget breakdown have been developed based on a detailed plan of the activities required to achieve the milestones. We have high confidence in the comprehensiveness and accurate sizing of these activities, as we have engaged in very similar projects at the complexity level and subject domain in the past.

The ADA amounts for the developers on the team are commensurate with the amount of effort that the team members will contribute to the project. They are consistent with those that we and our fellow developers in the smart contracts and dApp sector have used in past projects to provide high-quality services, with a proven track record of delivering projects despite the complexity of viable applications in this space. This requires experts on staff with a diverse range of niche skill sets and deep knowledge of the Cardano and Hydra protocols, the EUTXO model, and the modern practices of dApp design.