Repository navigation
id: mutual-concession match attestation PoC on tic-tac-toe (#2248) - #2854
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 18 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f2633ac94f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| /// As [`GenesisAgreement::body`]. | ||
| pub fn agreement_hash(&self) -> Result<Hash, serde_json::Error> { |
There was a problem hiding this comment.
When the same players play another match with the same game logic, witness, and objection window, the agreement body—and therefore agreement_hash()—is identical. Claim association in compute_state uses only that hash, so previous claims can satisfy a new match before either player submits a new result, or turn both matches into Disputed when their outcomes differ. The documented game_id identifies the game, not the match. Include a jointly signed match identifier or nonce so claims cannot cross match boundaries.
Useful? React with 👍 / 👎.
| let genesis_ok = agreement.players.iter().all(|player| { | ||
| genesis | ||
| .iter() | ||
| .any(|(author, signed)| author == player && signed == agreement) | ||
| }); |
There was a problem hiding this comment.
If an agreement contains players: [p, p], a single genesis signature passes both iterations of this check, and a single claim from p subsequently populates both per_player entries. The viewer therefore returns Agreed with only one signed claim, contrary to the two-player mutual-concession requirement and the documented single-claim behavior. Reject agreements whose two player identities are equal before evaluating genesis or claims.
Useful? React with 👍 / 👎.
PoC for #2248 (queue task 3953), implementing the #2037 mutual-concession attestation shapes on the tic-tac-toe example. Proof of concept only — no production attestation feature is claimed or built here.
Object shapes (new
pkgs/id/src/attestation.rs, additive)attestation.genesis, body{game_id, logic_hash, players, witness, objection_window_secs}. Both players sign the identical body;logic_hashis the hash of the example'smain.roc. The witness slot is present and unused; the objection window is a parameter only (objection handling is id: investigate: match audit — netcode log format, replay validation, and cheating signals #2038/id: design: match attestation + audit v1 #2039, out of scope).attestation.claim, body{agreement, outcome, final_state_hash, frontiers}: the agreement hash answered, the asserted outcome, the hash of the final game state (the board/plays/winner JSON the example publishes), and both chain frontiers.compute_stateis a pure function of the objects (authors taken from signature-verified decoded events): no complete genesis pair or only one claim →Proposed; concurring claims →Agreed; differing claims →Disputed, neverAgreed. A player claiming twice with different claims also computesDisputed.Demonstration (
pkgs/id/tests/attestation_poc.rs, 3 tests, green on the laptop)Agreed.Disputed.Proposed.What this does not prove
Witness decisions, objections, audit replay, and fork-proof voiding of claims are untested here; bodies travel beside headers in the demonstration rather than through the content/blob layer; the viewer trusts
chain::decode's signature verification and does not itself re-verify. Findings note with the full proved / did-not-prove list is on #2248.Existing suites: the crate builds with no new warnings; clippy clean on the new files. Full
pkgs/idCI on this PR is the gate for the existing event_store/chain suites.Need help on this PR? Tag
@codesmith-botwith what you need.