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

Implement failure/correctness proof checking for identifiable aborts #43

Open
fjarri opened this issue Nov 5, 2023 · 1 comment
Open
Labels
API Involves backwards-incompatible changes of the public API cryptography Needs cryptographic expertise enhancement New feature or request
Milestone

Comments

@fjarri
Copy link
Member

fjarri commented Nov 5, 2023

With #39 and #41 merged, we now have a (draft) proof generation on errors. A node may return either a proof of misbehavior of another node, or a proof of its own correct behavior.

What is currently missing is an API to verify these proofs. We need to decide what should be attached to them (the relevant signed messages by other nodes, certainly, but is there anything else?), and how can a third party verify them.

In the paper the error path is a part of the protocol, but since in practice we have a global state (blockchain) and, possibly, an independent arbiter (the user initiating the signing process), we can perhaps simplify things and decouple this verification from the happy path of the protocol execution.

Even if we did have only the nodes with no global state, it may still be worth it to keep the verification external to the happy path, because otherwise the message routing would get complicated (and it is complicated enough already), and every round would have to branch out depending on what path it received messages from, for each node - a generalization nightmare.

@fjarri
Copy link
Member Author

fjarri commented Oct 12, 2024

Needs a CorrectnessProof trait in manul (see entropyxyz/manul#2), and then we can implement verification there.

@fjarri fjarri modified the milestones: v0.2.0, v1.0.0, v0.3.0 Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Involves backwards-incompatible changes of the public API cryptography Needs cryptographic expertise enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant