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

Do we need to generate Evidence for provably invalid messages? #39

Open
fjarri opened this issue Oct 21, 2024 · 2 comments
Open

Do we need to generate Evidence for provably invalid messages? #39

fjarri opened this issue Oct 21, 2024 · 2 comments
Labels
API Involves backwards-incompatible changes of the public API security Counteracting malicious behavior
Milestone

Comments

@fjarri
Copy link
Member

fjarri commented Oct 21, 2024

We currently distinguish "provable" errors that can occur when we receive a message - that is, some fault that is not only attributable, but can be proven to have been caused by some party. The question is: why do we care?

If some node is actively malicious and for some reason wants to send a garbage message, it can just send garbage (say, a message with an incorrect signature), or not send anything at all. Why expose itself by signing an invalid message and thus making a verifiable offense? The only attack vector I see here is that a message with a verifiable offense will take more time to process (everything needs to be checked, evidence generated etc), but DoS seems unlikely since the set of nodes that can possibly send messages is already limited at the start of the protocol.

Another possibility is a node sending an invalid message by mistake (e.g., running an old version of the code). This will probably happen more often in real-life applications than an attack. On the other hand, it seems strange to punish nodes more harshly for negligence compared to malicious actions.

Of course, we still need correctness proofs, which are used to identify a malicious party at finalization time, that is when there is no specific message known that triggered an error.

If we do not in fact need to generate evidence of malicious actions when receiving messages, it will greatly simplify the session logic (which is already getting complicated).

@fjarri fjarri added API Involves backwards-incompatible changes of the public API security Counteracting malicious behavior labels Oct 21, 2024
@fjarri fjarri added this to the v0.1.0 milestone Oct 21, 2024
@dvdplm
Copy link
Contributor

dvdplm commented Oct 29, 2024

The only counter argument that comes to mind here is:

While your assertions are true for the protocols of synedrion, I'm not sure they hold for all possible protocols. So if manul aims to be a general purpose library for any round based protocol, perhaps it's wrong to assume Evidence is unneeded work. (OTOH I do not think making manul work for all possible protocols is a good idea.)

--

Is there anything that stops us from marking an error as "Provable" but not do the work to generate evidence? If a node claims a provable error happened it could just make sure the transcript contains what's needed and outside observers can generate the evidence if they so desire (the "chain governance" could be one such outside observer).

@fjarri
Copy link
Member Author

fjarri commented Oct 30, 2024

I'm not sure they hold for all possible protocols.

I actually think that they do, and would be very interested to learn of a protocol that involves scenarios where these proofs are useful (other than the mentioned punishing of nodes with obsolete software).

Is there anything that stops us from marking an error as "Provable" but not do the work to generate evidence?

The steps still necessary in this case, checking that the error occurred and collecting the messages, already constitute most of the work. The time-intensive evidence generation happens when creating correctness proofs, which is a whole different thing.

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 security Counteracting malicious behavior
Projects
None yet
Development

No branches or pull requests

2 participants