Hydra is cool: You don't need Hydra

Hydra is cool

Hydra¹ 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. 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. 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.