105 lines
5.1 KiB
Markdown
105 lines
5.1 KiB
Markdown
---
|
|
title: "Hydra is neat: You don't need Hydra"
|
|
date: 2023-09-20
|
|
---
|
|
|
|
## Hydra is neat
|
|
|
|
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'.
|
|
|
|
## 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; 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 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 scripts 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 is 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 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 its 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 its 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 on interesting applications where
|
|
its far easier and more effective to reuse Hydra infra and modify it than creating your own L2 from scratch.
|
|
|
|
[^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).
|
|
|