waalge
/
kompact-io-landing
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

hydra is cool

This commit is contained in:
waalge 2023-09-20 13:20:11 +00:00
parent c3f39d430d
commit 712c7cac44
1 changed files with 104 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

104
content/posts/hydra-is-cool.md Normal file
View File

@ -0,0 +1,104 @@
---
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).