What's the difference between sharding & a payment channel, & how does Hydra compare?

Question

The question is all in the title.

My take: sharding is a base level solution which ideally a programmer using a sharded system shouldn't need to interact with (but I think this probably isn't true, which is why sharding is often considered inelegant). Whereas a payment channel is also a method of scaling, but is a temporary thing that is opened for a period of time and then closed, with a settlement to the main chain which happens when the channel is closed.

So, sharding is at infrastructure level (programmers using the system should not be involved in creating shards), whereas to use a channel it's more likely that a programmer is going to open & close one.

Sharding has its own issues; putting transactions on a payment channel means that anything that happens on the channel will not be visible on-chain until the channel is closed, or at least until it issues a settling transaction on-chain, so visibility will be reduced.

Reason I'm asking this question is I'd like to establish whether a (very) fast L1 actually has an advantage of any kind over Hydra (which I'm also seeking to understand here). Apologies the question is very incomplete at present, and this is just a draft note, can update it as we learn more.

Answer 1

First lets imagine a state channel, which is similar to a payment channel, only that in addition to basic transactions, it can contain arbitrary business logic. As you've said, it helps to think of such channels as sort of "black boxes" that can be periodically settled on the main chain, so long as the inputs match the outputs.

Below is an infographic example of such channels (not by me)

In global account ledgers like Ethereum or Solana, smart contract logic exists outside of individual transactions and must be "called" by every transaction wishing to make use of it. This means that when state channels are created, it isn't easy to port over smart contract logic into the channel, without either rewriting the code inside the channel, or by having a complex setup where the channel isn't really a black box but more of a gray box that allows some level of constant exposure to code on the main chain. Either way, not very elegant and perhaps overly complicated.

The full power of state channels is only realized when they are used in a blockchain with a UTXO accounting style, such as Cardano. Since smart contract validator logic exists on the UTXO itself, and the entire UTXO is used as a channel input, contract composability becomes a natural byproduct, rather than a complex workaround, of the state channel.

And so we have Hydra - Isomorphic (native composability) State (arbitrary logic) Channels (Off-chain/L2).