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.

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

Optionally resolve commits under consensus conflict #3057

Open
m0ar opened this issue Dec 7, 2023 · 0 comments
Open

Optionally resolve commits under consensus conflict #3057

m0ar opened this issue Dec 7, 2023 · 0 comments

Comments

@m0ar
Copy link

m0ar commented Dec 7, 2023

Description

Implement backwards compatible, opt-in load behavior that enables returning commits that have been consensus-pruned from stream state.

Background

At @desci-labs, we have strong needs to maximize determinism in state resolution. One area where this could be improved is under the effects of late-publishing attacks, because if this is performed, nodes will stop resolving any pruned commitID. We would like to be able to optionally resolve these pruned commits, if the node has knowledge about it. This would allow us to build truly stable references to historical stream state, reducing the impact of late publishing attacks.

At the present time, this would require the node to have been alive and well during the attack. In a CIP-145 future, new nodes would automatically be made aware of these historical forks, and hence could resolve pruned commits even if they were not online at the time.

These two changes together make for a dramatically improved resilience against late-publishing attacks, as they would not be able to prevent resolution of previously valid state.

Technical Information

This is the function that loads streams at a CommitID, and it currently hard-codes throwOnConflict to true:

const opts = { throwOnInvalidCommit: true, throwOnConflict: true, throwIfStale: false }

This can be made a function argument, threaded through the caller all the way up to the HTTP API. There, it can be added as a property in LoadOptions that can be passed from the HTTP client.

Thanks to @stbrody for suggesting an implementation path 🧁

Note that it is my intention to contribute the code for this enhancement, if there are no objections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant