You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user of Hydra I would like to use real Ada in a Hydra head.
As the Hydra team it would demonstrate the maturity of the product. It would be an opportunity to get feedback from users using it for real.
This could (or not) unleash potential adoption and experiments.
It could also raise interest into people wanting to assess actual mainnet Hydra heads security (it's not a hack, it's a pentest).
Anyway, let's see what surprises it could bring.
What
Currently, Hydra software would only run on preview network. It prevents testers from shooting themselves in the foot in case of problematic situation at this stage of development. Which made sense while this project was still named hydra-poc.
We should keep in mind the idea of limiting the risk for people to shoot themselves in the foot. In the meantime, we should not prevent people to make experiments with Hydra on main net once they're happy with what they've seen on preview.
Make it technically feasible to run on mainnet
Hydra node can connect to a cardano node running on mainnet
The smoke tests can run on mainnet
The documentation explains how to run a hydra-node on mainnet
Move the Hydraw team's instance to mainnet
Risk limitation features
In the same way lightning used to have a hard-coded limit of 4,390,000 satoshis, we might consider introducing a hard-coded limit for the amount of Ada one can lock with a commit transaction. Today we are only limiting the number of UTxO allowed in a commit. We could consider adding a hard-coded limit on the quantity of Ada in this UTxO. We don't need to enforce that on-chain. Enforcing that in the hydra-node software would be good enough. If one wants to change this limit, recompile and run it, they take their chances.
Implement a 100 Ada hard-coded commit limit in the hydra-node (off-chain code)
Known issues we're ok with
There will be a set of known issues/out of scope items. We make sure that the issues are documented, explained why we are okay with these known issues and in general that users are informed we are releasing a beta product, that we will be continuously fixing them (until it's not beta anymore?). We should try to turn the argumentation on it's had that we are happy to be exploited as we can learn from any successful hacks.
ch1bo
changed the title
Put something on main net
Mainnet compatibility
Feb 14, 2023
pgrange
added
💬 feature
A feature on our roadmap
green 💚
Low complexity or well understood feature
amber ⚠️
Medium complexity or partly unclear feature
and removed
💭 idea
An idea or feature request
green 💚
Low complexity or well understood feature
labels
Feb 21, 2023
Why
As a user of Hydra I would like to use real Ada in a Hydra head.
As the Hydra team it would demonstrate the maturity of the product. It would be an opportunity to get feedback from users using it for real.
This could (or not) unleash potential adoption and experiments.
It could also raise interest into people wanting to assess actual mainnet Hydra heads security (it's not a hack, it's a pentest).
Anyway, let's see what surprises it could bring.
What
Currently, Hydra software would only run on preview network. It prevents testers from shooting themselves in the foot in case of problematic situation at this stage of development. Which made sense while this project was still named hydra-poc.
We should keep in mind the idea of limiting the risk for people to shoot themselves in the foot. In the meantime, we should not prevent people to make experiments with Hydra on main net once they're happy with what they've seen on preview.
Make it technically feasible to run on mainnet
Risk limitation features
In the same way lightning used to have a hard-coded limit of 4,390,000 satoshis, we might consider introducing a hard-coded limit for the amount of Ada one can lock with a commit transaction. Today we are only limiting the number of UTxO allowed in a commit. We could consider adding a hard-coded limit on the quantity of Ada in this UTxO. We don't need to enforce that on-chain. Enforcing that in the hydra-node software would be good enough. If one wants to change this limit, recompile and run it, they take their chances.
Known issues we're ok with
There will be a set of known issues/out of scope items. We make sure that the issues are documented, explained why we are okay with these known issues and in general that users are informed we are releasing a beta product, that we will be continuously fixing them (until it's not beta anymore?). We should try to turn the argumentation on it's had that we are happy to be exploited as we can learn from any successful hacks.
Known issues and a list of things we likely see not part of the first mainnet beta release:
How
The text was updated successfully, but these errors were encountered: