Isomorphic state channels are fantastic. We believe they would not just scale dApps, but to obsolete the account-based state-driven DeFi as we know it today, to build new multi-layer highly-parallel decentralized economies cross-chains. That said, we fear the current direction of Hydra would not scale dApp, or even progress with real-life rational parties. The original paper requires all parties to be not only honest but also online to progress. We attempt to show inherent problems to this requirement in this Github issue.

Keys

The protocol setup clearly shows that each head party generates and maintains its own keys for both on-chain and off-chain verification. The commit transaction that locks UTxO from the main chain to commit it to a Hydra head indeed is signed by this party key.

This design means an end-user would have to run head nodes or send assets to other custodians that run them. The first question is then how easy is it to run head nodes? Will they be supported in Mobile Apps? If not, Hydra will serve centralized institutions more than individuals who have already given up ownership of the cryptocurrencies pre-Hydra. Cheaper fees and faster settlement for centralized users would still be excellent, but Hydra would not help dApps much.

Also, this suggests more overheads to join new heads, having to fund new UTxOs with each new key, then to commit it? Combined with the shared state machine fees, there is a lot of wasted resources if a dishonest party blocks any progress.

Time-based Risks

Hydra's security is absolute. A party would not sign transactions that steal their assets. If nothing goes well, an honest party could close the head and leave with the initially locked assets in place. This guarantee on the deposited capital may give a false sense of security against time-based attacks, in that the locked assets are not as valuable as when it was locked anymore.

For instance, a professional liquidator may open heads with slyly long contestation time to increase the locked time of deposited assets. Joined parties who have deposited asset C as collateral to borrow or mint asset A face worse liquidation risks when C suddenly drops in price while A skyrockets, now that a quick returning A to close the debt position option are locked longer than expected.

On the other hand, head members needing deposited assets early to pay a debt effectively kick everyone else. Again, a head with too few transactions is even more expensive and prolonged than pure on-chain transactions.

Impossibility to Progress

A Hydra head can only progress when all parties are online and honest. This assumption is very unrealistic for blockchain technologies. If parties do not trust each other by default on layer one, there is no reason to do so on layer two. Not losing funds is nice, but not making any progress goes against the fundamental goal of scalability.

Poker

A typical example of Hydra is a group of people playing Poker together. I hope I am missing something here, but why would the loser sign the transaction that renders him lost? The best thing the rest can do is close the head and unlock everyone's assets back on-chain. Since the on-chain validator script does not get a signed result, it cannot decide who loses. If players can vote on-chain to dispute the loser, are there any gains in bringing the game off-chain? Also, in games with only one or fewer winners than losers, how can the minority of winners out-dispute losers?

It also gets exciting off-chain. Who deals the cards? Is it through transactions or offline? Regardless, it is just too easy to dismiss a new card if someone loses from it, and it is hard to see the point of playing in a Hydra head. If all parties are supposed to trust each other, the loser would honestly admit a loss of assets, and they can play offline, expecting the loser to transfer crypto directly. I would not need a particular on-chain validator when transferring assets with friends or partners under a paper contract.

Democratic Voting

Similarly, why would a voter sign a vote that would render his side lost? Also curiously, in a non-congested design validated by a minting policy, a voter only needs to pay a transaction to deposit some stake to cast a vote on layer-one. The shared fees to operate the Hydra state machine and the time for all voters to finally commit staked seem to outweigh that. It is only proper, then, if it counts votes faster to settle way faster through Hydra. However, no, a dishonest party on the losing side would block that forever.

AMM

Hypothetically, someone owns and can commit an AMM to a Hydra head, an asset pool of two types with a pre-defined bonding curve. Every time a swap happens, the asset going in gets cheaper against the asset going out. The question is then, why would a party with the asset going in sign a significant swap transaction that would sink its net worth?

It also seems relatively easy for snapshot leaders to front-run in their turn. Given that they can consume the shared pool UTxO and include that transaction in T_R and toss the original one in \hat{R} to try later next turn.

Parties generate snapshots in a strictly sequential round-robin manner, so nodes can even prepare funds beforehand. This property also means there is a front-run risk for every single snapshot.

P2P Trading

With the current design, the more parties are involved, the more honest parties are required to make progress. It then suggests that a two-party head is the most stable one. A party can then propose to trade assets at a specific rate for the other to confirm and counter-sign. The question is then, how much is this solution better than on-chain atomic swaps? The counter-party can still monitor price changes before accepting the proposed exchange rate, while state machine overheads should cost more than the raw and minimal atomic swap script. I guess a head between two relatively big exchanges, custodians or traders who trade often, would make much sense. Then again, it is not for scaling dApp.

Actually...

Our current ad-hoc isomorphic state channel design relies a lot on these small-scale transactions. For example, let users lock and commit assets to layer-two and then frictionlessly update their exchange rates off-chain. Two users can then algorithmically match and lock on each other's rate to sign the transaction that would reflect the trade or loan on-chain. It is not easy to generalize the on-chain validator script to allow arbitrary application logic in this scenario. However, we could formalize just enough for the bottom economics layer of our layered decentralized economies to build almost any financial services on top of it. I think Hydra should be configurable by end dApp developers anyway?

More Generalized Models

In a Hydra head setting where an actual transaction improves gains for a set of parties but reduces gains for the others, it is straightforward to see that the Nash equilibrium of the game is that everyone passes all transactions. This result renders the head a waste of time and fees to set up the state machine and run head nodes. Such a setting is widespread. Most if not all games like Poker, voting, trading where a trade can change the supply and demand of assets that effectively makes a group of people more prosperous, and another poorer, and more.

P2P transactions that both parties believe they gain something out of them, one-direction transactions like donations, tips, are a few cases where we can dodge the problem. It is hard to see how frequent parties have to emit transactions to justify the cost of running head protocol instances, potentially many for P2P cases.

Also, one could argue that a tip for streamer A is a net loss for a competing streamer B. The streamer B is then incentivized to join streamer A's heads to block tips. Similarly, a seller B can anonymously act as a buyer joining a competing A's heads to block his P2P sales. Too low of a barrier to entry yields global blockers who pay a few transaction fees to block more valuable competitor transactions potentially. Too high of a barrier to entry makes it costly to maintain too many heads. I do not find this as an easy balance to solve at all.

Finally, there are several cases where people want to act honestly to get things to progress for good. That said, the current design only requires one party to block everything. Many would block when faced a constant net loss had they signed.

Better Communication on the Expected Performance

The paper assumes complete trust to benchmark a TPS of 800 across distributed nodes around the globe. Many unofficial sources have circulated 1-2 million TPS when many heads are run in parallel. It depends on many factors, but we need to communicate better, so developers and users are more aware of the scaling challenges they will face and that Hydra is not a plug-and-play that solves all problems. One could argue Hydra's actual TPS is zero. It only requires one dishonest or offline party to stop the head from any progress. This zero-TPS includes the worst-case scenario, the average-case scenario, and even the near-perfect n - 1 online honest parties scenario. Anything but the perfect best-case scenario has any TPS at all. It is somewhat like claiming an algorithm that generates a random list of the same size in O(n) has that complexity for sorting because there is this one chance the first random list is indeed the input list, sorted.

I guess the main problem is that many people, if not the mass still believe that Hydra would solve the scalability problem on Cardano very well, and for good. While in fact, much more work still needs to be done, and more patience and support must be shown towards developers. On the other hand, investors and users should have better perspectives to plan their things.

Conclusion

We firmly believe in the future of isomorphic state channels. We are unsure if the current Hydra design is practical and can scale dApps with rational but not necessarily honest parties. We have provided several case studies across gaming, governance, and DeFi and would love to hear your responses on it. It is possible that I misunderstood things left and right and need some clarification.

Also, since we are already working with other partners on different layer-two solutions, isomorphic state channels included, I wonder if you would be open to working together on this open-source Hydra core for isomorphic state channels? We would love to join the conversations and contribute in many different ways.

The paper is about Hydra Head protocol which indeed, has some limitations: It guarantees safety but not liveness, and requires all parties to be online to provide those guarantees. We are well aware of those limitations but strongly believe the current Hydra Head Node is a necessary stepping stone that will still provide value while enabling more sophisticated and scalable constructions. Will it solve all scalability problems for all users for the foreseeable future? No, but "Rome wasn't built in a day". Hydra is more a family of protocols than a single thing and I agree we should communicate better and manage the community expectations. Anyhow, thanks for your contribution. We'll review it and come back to you asap.

Yes, I have skimmed through the Interhead one, would love to post more questions on that this or next week as well. All these research efforts are very inspiring, and I totally agree that we have to make incremental steps.

The thing that excites me the most is the insane level of parallelism here. When n is 1, I should be able to commit my assets away to my layer two storage to mend, decorate, set price, fine-tune lending terms, etc. in a very frictionless way without having to care about the rest of the world. When n is 2, I and anyone can negotiate over complex terms that both can co-sign to propagate back to layer one, all negotiations are unaffected by the rest of the world. And then it gets crazy when n is 3, where I can finally convince our researchers to do more game theory!

Also, feel free to assign me anything well-scoped that the team feels comfortable outsourcing :+1:.

I was also thinking about how someone on a mobile wallet can have their transaction confirmed on their behalf while they are offline, as well as how you can prevent someone from blocking transactions. I thought of an easy solution, but I might be missing something. Let's say we have a head with 4 parties. A, B, C and D. If I understand correctly, A has to sign the transaction when I send funds from A to B. But the transaction is only confirmed and a snapshot created when all participants sign this. At this point in time C and D might be offline. Why can't the transaction be sent to the staking pool of C and D for signature, allowing transactions that do not concern those parties, in this case C and D, be signed by the private key of their chosen stake pool. C and D might even not be allowed to sign this transaction to prevent them from blocking it. The stake pools would not be allowed to sign on behalf of A or B in this scenario. SPO blocking transactions (for C and D) could then be punished, as there is never a reason for a stake pool not to sign such a transaction. When the head is closed, the stake pools of the parties may then also contest the closing.

I have not thought through what would happen if someone would change stake pools, but this could be solved by declaring the stake pool of each participant when opening the head.

I also thought about security of the SPO. I run a stake pool myself, but my stake pool private key only contains a few ADA for transactions of the stake pool. All other pledged funds are on hardware wallets. Even if for some reason a hacker would make it sign a wrongful transaction, there would be no money to steal.

@chirkunov Head parties have to sign transactions with their registered keys, a party cannot delegate assets or signing privilege to another verification key, like an SPO, for example. In your proposed scenario, A could only send to B what he has locked on layer one to Hydra. That is the case for everyone, B, C, D, included. C and D's stake pools could only sign for them, had they sent locked assets to the stake pools in a custodial way in the first place. If custodial is required, it should be a lot more efficient if the dApp itself (not the stake pools) runs its typical centralized backend services to handle application logic (think Celsius), instead of doing things in a frictional way like in Hydra. Hydra is supposed to be more meaningful to the end-users, to do P2P negotiations and progress states in a decentralized way without being affected by the rest of the world.

Also, your scenario is one of the simplest forms of state progress in a party, which is simply payments. Payment channels have solved that for a long time now because payments only affect the involved parties, hence a path of A -> B -> C only needs the signatures of the three, or more aggressively of the first two. The generalized state channels cannot guarantee this neat property, as an arbitrary change to the originally committed state might affect the parties in different ways. Take voting as an example, a user casting a yes vote doesn't directly reduce the net worth of anyone else, but it still requires the people voting no to double-check if that user update the vote count in the shared UTxO correctly, or does that user do a +1000 votes when he, per the validator rule on layer one, can only vote one. Requiring all signatures in the head guarantees the security of the state progress (we haven't enough time to formalize proof, but do feel that there are undiscovered corner cases too). The most serious problem at the moment, though, is why would a party on the losing side sign the transaction that would render his side lost. So per the Nash equilibrium, most states wouldn't progress. No one would lose anything, but the committed state wouldn't progress. It is also extremely difficult to generalize a design for arbitrary dApp logic had not all signatures are required.

Many people are pushing these researches so the future is bright though, thank you too for joining the conversation!

Hi @kk-hainq, thanks for reaching out and taking the time to go through all this. I'll try to address most of your points, but before anything, keep in mind that "Hydra" is a long-term vision that includes a variety of protocols and solutions.

Our current focus with the Hydra team at the moment is to build a strong foundation to enable the creation of solutions on top of that primary building block. As we've repeated on multiple occasions (e.g. during the Goguen summit), Hydra heads aren't magical unicorns and have limitations (that you also pointed out), namely:

All participants must be honest to make progress
Head Participants must be online all the time to guarantee safety
The set of participants can't be changed once the head is started (existing participants can't leave, and new ones can't join)

For several use-cases, these limitations are too restrictive, and we have already many ideas which we are working on with researchers. I'll touch a bit on that at the end.

About time-based risks and impossibility to progress, Hydra heads indeed require all participants to be honest for liveness, The funds are however never compromised or put at risk, which is one of the main goals of heads. Now, whether a participant could leverage that as a form of attack is rather unlikely: participants of a head know each other and have chosen each other. So the setup scheme is quite different from your scenario where someone would create a head and, a completely foreign party would join the head in an attempt to stall it. Participants of heads have a common interest in collaborating, but they don't trust each other enough to process funds correctly that they resort to a head to cope with that lack of trust. A typical use-case illustrating this is a handful of financial institutions exchanging funds at a high rate between each other with clearly defined settlement times. A head becomes a handy solution for book-keeping those fast-paced transactions, but at no time has any participant any interest in stalling the head. If they do, other participants will just stop doing business with them.

About AMM, I do not feel confident fully answering this point because I do not have detailed knowledge about how AMM works in general. Incidentally, this is why we have reached out to teams building out DEXs on Cardano at the moment, to understand their solutions but also challenges they are facing and what they would expect from a L2 solution. A basic head is unlikely to be the answer to all their challenges, but again, it's a building block to enable more complex solutions. Heads aren't the final answer.

On P2P Trading, the main benefits of running a head are to get fast throughput, short settlement time and low/zero fees. If none of these is on the table, then using a head provides arguably no benefits indeed. So, in the case of P2P trading, establishing a head between two parties for a single trade would be a waste of resources/efforts. If however, the two parties indeed perform many trades between each other, then it definitely makes sense, if only for the fees. What costs fees is the head establishment, as it has to go through several L1 transactions, but once established, all transactions go through a separate network and are "invisible" to the L1. Plus, while the ledger rules and transaction format are isomorphic, parameters may be slightly different inside the head (e.g. no fee, bigger max transaction size, larger script execution units, etc...). Since the head also supports multi-asset UTXOs, the use-case of two exchanges or two large traders opening a head to one another is very sensible.

About Better Communication on the Expected Performance. Yes. I face-palm myself every time I read "1 million TPS". Actually, any TPS-argument reasoning is bonkers, because even with Heads able to run only at 0.5 TPS, we could end up to 1M TPS with the same reasoning.

Rather, we find that more relevant metrics to evaluate the "performance" of L2 solutions are, for example, the average settlement time of transactions or the time needed to get in and out of a L2 solution.

Regardless, the head paper's results were also obtained from a simulation of the protocol. We are actually working on benchmarks to establish measures of the real implementation to get clear numbers on the solution from an engineering standpoint.

At the same time, we have been engaging with the community quite a lot on these topics recently, might it be at the summit, on Discord, on Twitter or the stack exchange. We are also planning some blog posts, later on, to be very clear on what we are building and what the roadmap for Hydra will look like.

In conclusion and, as said in the introduction (and also said earlier by @abailly), Hydra heads are only a first step towards scalability in Cardano. It's exploring the path of state channels and we intend to iterate on top of the head to make the most of it. In particular, we have a few emerging ideas that will concretise into actual projects/products -- either by us or by other team building in parallel. Without going too much into the details yet (we will eventually), but still, to give a short overview of the long-term landscape:

Custodial heads

This is low-hanging fruit, not fully satisfactory from a decentralization standpoint but, which has good use-cases already. In this setup, head participants are "trusted" authorities having shared custody of end-users funds, but, enabling them to transact via a head in a cheap and fast manner. You could imagine light wallet providers running in this sort of setup; users already trust their wallet provider to some extent and moving some funds into their custody for fast payments across all light wallets would be neat. From an end-user perspective, no need to maintain any infrastructure. It is however only slightly better than a centralized solution in the sense that, it's shared custody but if all head participants collude, everything falls apart. So as I said, low hanging fruit, but unsatisfactory.

Managed heads

Or, head-as-a-service. One of the pain-point of the heads is this requirement to (a) run a hydra node + Cardano-node, and (b) be online all the time. We could imagine a scenario where a service provider provides the infrastructure, but, leave full custody of the head management and funds to the end-user; The end-user keeps the ability to forcefully close a head if needs be. There are several Lightning-enabled wallets in the Bitcoin realm which operates in this manner.

Star-shaped heads

This approach really makes heavy use of the head as a building block to construct a network of 2-party heads around one "central" multi-party head. For each 2-party head, one participant is also a member of the central multi-party head. The central multi-party head can be managed by parties that are indeed online all the time (e.g. SPOs), while other side heads (the branches of the star) are mostly driven by end-user clients. For Alice to send to Bob, she wouldn't need to share a head with Bob, but only to share a head with the central head, and Bob to also share a head with that central head. Then, using mechanisms such as HTLC, enable creating virtual channels from within this central head and between Alice and Bob.

Deposit heads

Once we have a working head, we can start thinking about building extensions using more smart-contract logic. One idea we are exploring is the ability for any user external to the head to still leverage the head for payment by depositing funds into a special script address, which isn't the head, but, grants authorization to the head to withdraw funds from this deposit account under special conditions. In short, if Alice asks the head to broadcast a transaction on her behalf, she also authorizes the head to withdraw the required amount from this deposit account. This type of approach makes it quite flexible and secure for external participants to join and leverage heads which would in this scenario, would be run by parties that can be online all the time (e.g. SPOs).

Inter-connected heads

This is the interhead paper giving a protocol to inter-connect heads together, allowing to create a network of heads. This, combined with a managed heads approach can lead to pretty massive scalability where most of the complexity is hidden from end-users which remains in complete control of their funds at all time. Similarly, it would allow to also connect star-shaped heads together to make it a real network.

In addition to Hydra heads, researchers are also exploring other solutions/protocols taking drastically different approaches. It's not impossible that rollups also get on the table at some point. Yet, we do believe that there's a fair amount of things we can already do with Heads and their derivative. Will heads solve Cardano scalability fully?

No. But it's a step in the right direction.

@KtorZ Thank you very much for the detailed answers!

The funds are however never compromised or put at risk, which is one of the main goals of heads.

I believe "never" is a strong word in this context. When I said Hydra's security is "absolute" it was mainly to support the false sense of security against time-based risks statement afterwards. Head parties can exploit time-based validation rules or values of others' locked assets over time like in the collateral liquidation scenario. Another naive one is for P2P lending: A lender opens a head with a long contestation time with the reasoning that it takes time for a contest transaction to be confirmed on layer one, that it is a secure choice for everyone. Borrowers then submit Hydra transactions that deposit collateral to a locking script address, to borrow assets worth half the collateral from the lender. Everyone signs, no problem. But after a while, the lender stops signing repayment transactions due to "technical difficulties" or whatever. Given the previous history, the borrowers still wait for the lender who never responds. A borrower eventually gets tired of it and decommit to face a long contestation time. After all the wasted time, the repayment plus interests on layer one is now more expensive given that the loan duration is longer. The collateral might even be collected if it's overdue or had crashed in value while being locked. The scary part is that lenders can choose not to sign transactions that deposit more collateral on layer two from borrowers to hunt the collateral on layer one. DeFi exploits can get very creative if you follow the scene.

I'm not even sure if we could design a protocol that is both useful and absolutely secure against these risks. At the end of the day, the risk of assets losing value over time is still there even when they are stored in your physical wallets. The point of that section was to mainly raise awareness, and the importance of documentation and communication so users know what the contestation time is, what risks they may face using Hydra, etc. To both protect users and the image of the protocol.

Now, whether a participant could leverage that as a form of attack is rather unlikely: participants of a head know each other and have chosen each other. So the setup scheme is quite different from your scenario where someone would create a head and, a completely foreign party would join the head in an attempt to stall it. Participants of heads have a common interest in collaborating, but they don't trust each other enough to process funds correctly that they resort to a head to cope with that lack of trust.

The definition of "know"/"choose" is extremely vague on the blockchain. For example, does algorithmic matching count? It's easier to reason when we simply ask a binary question if we trust the other parties or not. If not then the current limits will prevent progress. If yes then aren't there more lightweight off-chain solutions for balancing invoices? When there is enough traffic to qualify, the use case becomes extremely niche. Also, the requirement to "know"/"choose" who to transact with sounds exactly like a problem that dApp solves, not needs. The point of having a decentralized exchange, for example, is to help you rapidly trade with a deep amount of capital, without the waste of time to know, find, or choose who you are transacting with.

A typical use-case illustrating this is a handful of financial institutions exchanging funds at a high rate between each other with clearly defined settlement times. A head becomes a handy solution for book-keeping those fast-paced transactions, but at no time has any participant any interest in stalling the head. If they do, other participants will just stop doing business with them.

If however, the two parties indeed perform many trades between each other, then it definitely makes sense, if only for the fees. What costs fees is the head establishment, as it has to go through several L1 transactions, but once established, all transactions go through a separate network and are "invisible" to the L1. Plus, while the ledger rules and transaction format are isomorphic, parameters may be slightly different inside the head (e.g. no fee, bigger max transaction size, larger script execution units, etc...). Since the head also supports multi-asset UTXOs, the use-case of two exchanges or two large traders opening a head to one another is very sensible.

This is indeed the best use case I could give in the original post. However, this is highly centralized, institutional, identity/reputation-driven, and has little to do with scaling dApps.

About AMM, I do not feel confident fully answering this point because I do not have detailed knowledge about how AMM works in general. Incidentally, this is why we have reached out to teams building out DEXs on Cardano at the moment, to understand their solutions but also challenges they are facing and what they would expect from a L2 solution. A basic head is unlikely to be the answer to all their challenges, but again, it's a building block to enable more complex solutions. Heads aren't the final answer.

Yeah, I think the true answer is to drop the account-based state-centric liquidity pools and design brand new ones specialized for the UTXO ledger. We're not a DEX but could achieve that on paper with ad-hoc state channels. Also, isomorphic state channels are definitely powerful enough to scale even things like Uniswap on UTXO. It's hard to commit script-locked assets to Hydra, but people can still gather together to commit their assets to the head first, then provide liquidity to new pool UTxOs at the liquidity pool script. Rebuilding liquidity pools every head is annoying but might be useful if the head lasts long enough.

Hydra would be crazy once it can progress with dishonest parties, and that a few parties cannot casually decommit to kick everyone.

Yes. I face-palm myself every time I read "1 million TPS". Actually, any TPS-argument reasoning is bonkers, because even with Heads able to run only at 0.5 TPS, we could end up to 1M TPS with the same reasoning.

Rather, we find that more relevant metrics to evaluate the "performance" of L2 solutions are, for example, the average settlement time of transactions or the time needed to get in and out of a L2 solution.

I still find the methodology to measure the TPS in the paper useful for institutional usage or something like that. But I agree, TPS is misleading in most contexts. Also as a user, I cannot care less what happens on this second or the next, but more on if I do this when does it get reflected, yeah.

We are actually working on benchmarks to establish measures of the real implementation to get clear numbers on the solution from an engineering standpoint.

At the same time, we have been engaging with the community quite a lot on these topics recently, might it be at the summit, on Discord, on Twitter or the stack exchange. We are also planning some blog posts, later on, to be very clear on what we are building and what the roadmap for Hydra will look like.

Awesome!

Custodial heads

Yeah, this is such a natural step forward given the current state of the project. I could definitely see centralized microtransaction services scale on this setup, quite exciting to be honest.

Managed heads

This is also very nice. If we package and document well enough in the future more and more users would be able to run stake pools and Hydra nodes.

Star-shaped heads

Stake pool operators are scary people. Many are technical enough to customize the head node. Many are public enough to be found and bribed to do so. Do we have a plan to also support pure payment channels? State channels in this case are still prone to a single dishonest party. While payments require fewer honest parties on their specific path.

Deposit heads

This would be very nice. If the fund is guarded by specific rules like can only be used to interact with a specific loan (deposit more/withdraw back collateral, borrow more, repay) then we don't even need to whitelist the head! I need to sleep more on this but synchronization doesn't seem to be trivial. If the fund is also spent on layer one afterwards but differently than on layer two, wouldn't the decommit fail and all progress is nuked?

Inter-connected heads

I've only skimmed through this paper but I don't think security can be easily guaranteed on this setup. Will post more questions once I finish reading it.

In addition to Hydra heads, researchers are also exploring other solutions/protocols taking drastically different approaches. It's not impossible that rollups also get on the table at some point. Yet, we do believe that there's a fair amount of things we can already do with Heads and their derivative.

Nice. Just curious but are you also building pure payment channels? Metadata can be embedded directly on TokenName so one can transfer more concepts and logic with Cardano native tokens than just pure payments. Also, can we call our own variant Hydra something and add it to the family here?

@kk-hainq Is your code visible somewhere?

@abailly-iohk No, we have only been working on a paper draft. It is non-trivial to develop a node, off-chain communication channels, mainchain scripts, and all. That is why I hoped we could build the foundation together. If not we'll still fork this repository as a starting point when we start implementing our proof-of-concept.

I definitely agree all this stuff is non-trivial :) The great thing with open-source is that, well, it's open for everyone to see and contribute so we'll certainly not stop you from contributing. But I think, and I believe this is shared by my teammates, that right now we want to finish what we started together namely to have a production-ready Hydra Head node. This is not a huge footprint codebase so there are few opportunities for distributing and parallelising work at this stage. It's only a few months away to be able to run Hydra Head nodes on a testnet or even mainnet, and then there will be plenty of opportunities to collaborate on expanding on this solid foundations. As for your question about calling your own variant "Hydra something", I can't tell: Do you mean from a legal standpoint, or just if we don't mind?

@abailly-iohk That sounds great, thanks! I firmly believe many from the ecosystem, ourselves included, would join the conversations and submit pull requests if the team posted more open issues here. As long as we don't spam or distract you too much, I think we'd be able to contribute non-trivially.

As for your question about calling your own variant "Hydra something", I can't tell: Do you mean from a legal standpoint, or just if we don't mind?

From both standpoints. The context is that we needed to design our own Hydra variant to scale our decentralized economies, which share many ideas with Nervos's (they were a few years ahead of us) multi-layered architecture. I believe our ad-hoc design would fit both perfectly and am pitching the idea to them. The name is of the least important at the moment but I would love to keep Hydra in the name as a tribute to the source of inspiration. Just hope it wouldn't end up being Nervous Hydra...

Just hope it wouldn't end up being Nervous Hydra... 🤣

cardano-scaling / hydra

How can Hydra scale dApps? #108

Keys

Time-based Risks

Impossibility to Progress

Poker

Democratic Voting

AMM

P2P Trading

More Generalized Models

Better Communication on the Expected Performance

Conclusion

Custodial heads

Managed heads

Star-shaped heads

Deposit heads

Inter-connected heads