---
title: "Hydra is cool: You don't need Hydra"
date: 2023-09-20
---

## Hydra is cool

Hydra[^1] is a very cool project. It is a layer 2 for Cardano that is
_isomorphic_ to the L1. Here isomorphic means that Plutus runs in Hydra just
like it does on the L1. That dapp you've just toiled over for months to run on
the L1 can be put in Hydra and 'just work'.

[^1]:
    This post does not distinguish between Hydra and Hydra Head referring to
    both as Hydra. If you want to know more about Hydra, then check out their
    [explainers](https://hydra.family/head-protocol/core-concepts).

## Hydra's compromise

Hydra boasts it can achieve higher throughput and lower transaction fees
compared to the Cardano L1 as well as near instant settling and no roll-backs.
You may be asking _If my dapp just works on Hydra and it's better in all key
respects, then why don't we all just use Hydra?_. The answer is because these
improvements come at a cost. Consensus in Hydra differs from that on the L1.
Hydra doesn't use ouroboros. Instead all participating hydra nodes must sign-off
on all updates to the chain state. Practically speaking, far fewer nodes can
participate in Hydra and one quiet node stops the whole Hydra chain updating.
Not great for an L1.

## You don't need Hydra

Hydra is an example of a way to do state channels. A state channel relies on the
integrity of the L1, while accumulating state separately from it (L2). At some
point the layers are brought into sync. This is when funds on the L1 can be
unlocked, and/or the state of the L2 updated.

Hydra could be thought to be providing some future-proofing. It is possible for
a Hydra instance to run indefinitely and Plutus scripts not yet written will be
executable in some already running instance. However, because Hydra's consensus
is so brittle the longevity of an instance is not something to depend on. Each
and any transaction may be its last.

A key question when considering Hydra is _Do I need isomorphic-ness?_. If you
know all your business logic before instantiation then the answer is **no, you
don't care for isomorphic-ness**. Instead, you can roll-your-own L2. It depends
on your use case as to how much work that ends up being. It can be very simple.

## You don't want Hydra

In Hydra, the latest agreed state in the L2 is the one that the L1 will accept
as the most legitimate. This is a sensible default.

Suppose however you have a game of poker where one player learns that they've
lost and rage quits. From the game's perspective, that final transaction should
be forced through - the player's loss is inevitable. At present this isn't
possible with Hydra. If a party doesn't sign, then a state isn't valid.

In another use case, suppose there is some particularly intense on-chain
verification that would be prohibitive on the L1 but that you'd like the results
of which to persist onto the L1 and/or be recovered in future L2 instances. This
could be done with validity tokens but anything minted in the L2 won't persist
onto the L1.

Another key question then is _What is the right way to sync the L1 and L2
states?_. Hydra has a way of it doing it which might or might not be appropriate
for your use case. Rolling your own L2 means that the sync logic can fit your
business needs. Both the cases above are resolvable with custom sync logic.

## An Example: Subbit.xyz

Probably the simplest, non-trivial example using state channels is
[Subbit.xyz](https://subbit.xyz). Subbit.xyz is premised on the observation that
subscription is a very common use case: there are two parties where one pays the
other incrementally. It sacrifices generality to gain absolutely minimal
overhead for both parties.

In Subbit.xyz, Alice, a consumer, subscribes to some service of Bob, a provider.
Alice instantiates the channel by locking funds, similar to Hydra. There are
only two mechanisms for unlocking - one for Alice and the other for Bob. All
logic is known at instantiation.

A consumer needs only to keep track of their account balance, ascertain the cost
of each outgoing request, and produce valid signatures for a few dozen bytes of
data at a time. They don't need to watch the L1 and it's a non-chatty protocol.
The low resource needs opens it up to applications on intermittently connected
user devices such as laptops and mobile, and even micro-controllers. High
throughput remains achievable.

A provider must track each subscriber's account, and periodically check the
state of the L1. This could conceivably be as little as once a week or once a
month. The low resource needs for a provider means they have the ability to
serve more with less.

## Hydra for QoL

When Hydra reaches a point of maturity that it's plug and play, it's potentially
far easier to deploy with Hydra then roll-your-own L2. Isomorphic-ness gives
Hydra incredible flexibility and generality. You don't need isomorphic-ness but
because of it, Hydra could be an easy and convenient solution.

As for custom sync logic, it is surely the case that there is a tranche of
interesting applications where it's far easier and more effective to reuse Hydra
infra and modify it than creating your own L2 from scratch.
