-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle rollbacks II #185
Labels
💭 idea
An idea or feature request
Comments
7 tasks
pgrange
added a commit
that referenced
this issue
Apr 24, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * remove rollback and forward function from BehaviorSpec as it's not used * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
pgrange
added a commit
that referenced
this issue
Apr 25, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
v0d1ch
pushed a commit
that referenced
this issue
Apr 26, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
ghost
pushed a commit
that referenced
this issue
Apr 27, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
ghost
pushed a commit
that referenced
this issue
Apr 27, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
pgrange
added a commit
that referenced
this issue
Apr 27, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
ch1bo
pushed a commit
that referenced
this issue
May 8, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
pgrange
added a commit
that referenced
this issue
May 9, 2023
We do not handle rollbacks correctly: * a client would not now what to do with a rollback event * we do not handle these events correctly [#185](#185) is about dealing appropriately with the rollback. With [#185](#185) we will be able to really solve the issues in an appropriate way for both, the client using a hydra-node and the internals of our system. In the mean time, we remove the rollback logic from Hydra head so that: * we do not send rollback events to the client * we _bet_ that the seen transactions will be seen again in the new fork of the chain TODO: * add the chainState to the rollback event so that we remove all the rollback logic from HeadLogic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What & Why
The
hydra-node
is directly connected to the Cardano network via thecardano-node
. As we submit & observe blocks containing Hydra protocol transactions, these blocks can also be rolled back as Cardano is based on the Ouroboros consensus.Within this feature we want to make the
hydra-node
robust against rollbacks having it re-establish the last-known Hydra Head state by re-submitting Hydra protocol transactions if needed. This might be unsuccessful, in which case clients ofhydra-node
need to be notified of the rollback via the API.To improve user/developer experience we aim to also provide a "maturity" of the Hydra Head via the API to indicate a measure of "how settled" the Hydra Head is. When a Head is fully mature / settled, i.e. it is open for longer than x blocks on the Cardano network, the Head will 100% open until closed and clients can submit transactions to a Hydra Head without the need to handle rollbacks.
The text was updated successfully, but these errors were encountered: