EspressoSystems / EspressoSystems/timeboost

Behavior on Crash and Recovery

Open
#277 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
5
Forks
20
PR merge metrics
No merged PRs in 30d

Description

Even if we view the committee as non-changing, I understand that we want the system to behave properly even if some honest parties crash and recover.
I'm not sure what state is retained (if any) between a crash and recovery.
It seems like very little state is retained.
By "retained", I would mean written to disk in some solid, "journaled" fashion.

I'm worried about corner cases, such as the following:
1. A node crashes and recovers, and now proposes a second vertex in the same round. To the rest of the committee, this would appear to be incorrect behavior.
2. A node crashes and recovers, and even though it had sent an ACK for a message M it had previously received, it has completely forgotten about M and ACK. Other parties who received the ACK will not know that they need to resend M.
3. A node crashes and recovers, and it sent a VOTE for a proposal in a given round and from a given party before crashing, but after recovery, it might send a VOTE for a different proposal from the party in the same round. (This relates to another issue I raised, whre I pointed out that a party really should only vote for one proposal per round per party).

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.