From 712c7cac44b1d9a141ef231a17f54d378f9b1a97 Mon Sep 17 00:00:00 2001 From: waalge Date: Wed, 20 Sep 2023 13:20:11 +0000 Subject: [PATCH] hydra is cool --- content/posts/hydra-is-cool.md | 104 +++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 content/posts/hydra-is-cool.md diff --git a/content/posts/hydra-is-cool.md b/content/posts/hydra-is-cool.md new file mode 100644 index 0000000..7bbed18 --- /dev/null +++ b/content/posts/hydra-is-cool.md @@ -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). +