104 lines
5.1 KiB
Markdown
104 lines
5.1 KiB
Markdown
---
|
|
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.
|