State Machine Complaint Flow Specification

[nlordell]

This PR implements the complaint flow in the state machine.

[gemini-code-assist]

Summary of Changes

Hello @nlordell, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the robustness of the key generation process within the state machine by implementing a comprehensive complaint flow. It introduces new states and functions to manage accusations and responses during the collection and confirmation of secret shares. The author notes that the design of the complaint mechanism is largely stateless, which facilitated its integration with minimal additional state requirements, ultimately aiming to ensure the integrity and reliability of the key generation ceremony.

Highlights

• Complaint Flow Implementation: The pull request integrates the complaint handling mechanism into the key generation state machine, allowing participants to raise and resolve issues during the secret share collection process.
• New Data Type for Rollover State: A new record type, rollover_secret_shares, has been introduced to consolidate and manage the state associated with collecting secret shares during the key generation rollover.
• Refactored Secret Share Handling: The logic for generating and encrypting secret shares has been updated, moving from a batch secret_shares function to an individual secret_share function, and introducing a register_secret_share helper.
• Key Generation Confirmation State: A new key_gen_confirm function and modifications to the Confirming_key_gen state now manage the confirmation phase of key generation, transitioning to signing once all participants have confirmed.
• Type-Safe Comparisons: Comparisons for GroupId.t, SignatureId.t, and string types have been updated to use dedicated equality functions (GroupId.equal, SignatureId.equal, String.equal) instead of the generic == operator, enhancing type safety.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the key generation process within the validator.ml module, introducing a new rollover_secret_shares type and a Confirming_key_gen state to manage the collection and confirmation of secret shares. The spec/crypto.ml file was updated to change the secret_shares function to secret_share, now generating individual shares instead of a list. Key changes include the introduction of register_secret_share, key_gen_confirm, key_gen_complaint, and key_gen_complaint_response functions to handle the new key generation flow, including complaint mechanisms. A significant portion of the changes, highly praised by reviewers, involves replacing physical equality (==) with structural equality (=, GroupId.equal, SignatureId.equal, String.equal) across various comparisons, addressing potential bugs and improving code correctness and consistency.

[rmeissner]

Shouldn't we only mark the participant as unhonest and trigger keygen only after the timeout (in case that there are more unhonest participants)?

[nlordell]

We discussed this in person, and ideally we should. I tried to implement this but it turns out to be a bit more complicated than expected. You can also get away Scott-free if you get a complaint but another participant times out secret sharing, and I want to deal with these cases more holistically in a follow-up.

[rmeissner]

so do you want to keep this implementation, or do we go with that we handle a invalid response like not responded (so merging the two branches)?

Note: asking so that we can handle it the same way in the validator code

[nlordell]

Captured here: #69

[nlordell]

I would personally leave it as-is for now. There are a lot of other cases where we are suboptimal with removing as many dishonest participants as possible at once related to the complaint flow, and would tackle this separately.

I can add the "invalid responses are no responses" for now, but there are still cases where you might not remove the optimal number of dishonest participants.

In particular with the "invalid response is no response", then a dishonest participant may not be removed if they provide an invalid complaint response but another participant times out during secret sharing. I think for this to be implemented correctly, we need to track more state and potentially make the state machine handle these edge cases better.