Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Handle rollbacks II #185

Open
1 task
ch1bo opened this issue Jan 30, 2022 · 0 comments
Open
1 task

Handle rollbacks II #185

ch1bo opened this issue Jan 30, 2022 · 0 comments
Labels
💭 idea An idea or feature request

Comments

@ch1bo
Copy link
Collaborator

ch1bo commented Jan 30, 2022 •
edited by pgrange
Loading

What & Why

The hydra-node is directly connected to the Cardano network via the cardano-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 of hydra-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.
@ch1bo ch1bo mentioned this issue Jan 30, 2022
Closed
6 tasks
@ch1bo ch1bo added 💬 feature A feature on our roadmap amber ⚠️ Medium complexity or partly unclear feature labels Jan 30, 2022
@ch1bo ch1bo mentioned this issue Jul 21, 2022
Merged
@ch1bo ch1bo mentioned this issue Sep 27, 2022
Closed
7 tasks
@ch1bo ch1bo added 💭 idea An idea or feature request and removed 💬 feature A feature on our roadmap amber ⚠️ Medium complexity or partly unclear feature labels Mar 21, 2023
pgrange added a commit that referenced this issue Apr 24, 2023
@pgrange
Problems with rollback management
d0b8df6 
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
@pgrange
Problems with rollback management
89b8ce0 
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 pgrange mentioned this issue Apr 25, 2023
Merged
4 tasks
v0d1ch pushed a commit that referenced this issue Apr 26, 2023
@pgrange @v0d1ch
Problems with rollback management
bce9249 
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
abailly-iohk pushed a commit that referenced this issue Apr 27, 2023
@pgrange @abailly-iohk
Problems with rollback management
b9c525e 
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
abailly-iohk pushed a commit that referenced this issue Apr 27, 2023
@pgrange @abailly-iohk
Problems with rollback management
c4f8793 
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
@pgrange
Problems with rollback management
20fbc40 
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
@pgrange @ch1bo
Problems with rollback management
f6cbb91 
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
@pgrange
Problems with rollback management
6afdcc4 
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
@ffakenz ffakenz mentioned this issue Jul 9, 2023
Closed
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
💭 idea An idea or feature request
Projects
Hydra Head Roadmap
Status: No status
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ch1bo