feat: adding reconstruction threshold in node - #3640
Conversation
…same number of participants
… possible value due to 60%-80% range
…_bound as helpers
…nstructionthreshold
…inator) Colleagues did not agree on an 80% upper bound for the GovernanceThreshold, so set MAX_THRESHOLD_NUMERATOR = MAX_THRESHOLD_DENOMINATOR (5/5 = 100%). The relative upper cap structure is kept but never binds below the absolute `k <= n` check, so the GovernanceThreshold may again go up to the participant count. The cross-domain rule (GovernanceThreshold >= max(ReconstructionThreshold)) is unchanged. Revert the test changes that were only needed to satisfy the 80% cap (dropping thresholds / raising participant counts) and remove the now-meaningless dedicated upper-cap tests: - thresholds.rs: restore 5/5-participant thresholds; drop reject-above-cap test - dto_mapping.rs / lib.rs: drop the upper-cap rejection tests - lib.rs verify_tee: rework the kickout-refusal fixture to break the relation via the participant-count ceiling instead of the cap - running.rs: make the reconstruction>governance test regenerate until gov < n - sandbox + e2e + node resharing tests: restore original participant/threshold values - docs/design/domain-separation.md: describe the cap as disabled (100%) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…hreshold' of github.com:near/mpc into 3499-correlate-governancethreshold-with-reconstructionthreshold
…hreshold' of github.com:near/mpc into 3499-correlate-governancethreshold-with-reconstructionthreshold # Conflicts: # crates/contract/src/dto_mapping.rs
Co-authored-by: Mårten Blankfors <marten@blankfors.se>
gilcu3
left a comment
There was a problem hiding this comment.
LGTM
Left only minor comments. Slightly concerned about some tests becoming flaky, but that's all.
| c.triples_to_buffer = 2; | ||
| c.presignatures_to_buffer = 2; |
There was a problem hiding this comment.
we usually put enough triples in the buffer for all the signatures in the test to try to avoid flakiness as much as possible.
| tokio::select! { | ||
| res = wait_metric_on_nodes( | ||
| &cluster, | ||
| &[0, 1, 2, 3, 4], | ||
| metrics::TIMEOUTS_INDEXED, | ||
| |v| v >= 1, | ||
| CLUSTER_WAIT_TIMEOUT, | ||
| ) => res.unwrap_or_else(|_| panic!( | ||
| "{} did not reach 1 on the surviving nodes — Cait-Sith request was answered \ | ||
| despite only 5 of its 6 required signers being alive", | ||
| metrics::TIMEOUTS_INDEXED | ||
| )), |
There was a problem hiding this comment.
How long will this take? The timeout of a signature, 60 seconds?
There was a problem hiding this comment.
No, it's the default 200 blocks of yield_timeout_length_in_blocks
kevindeforth
left a comment
There was a problem hiding this comment.
found a comment that wasn't addressed.
| /// Sign with every scheme in `running`, asserting each request succeeds. | ||
| pub async fn sign_all_schemes( | ||
| cluster: &MpcCluster, | ||
| running: &RunningContractState, | ||
| rng: &mut impl rand::Rng, | ||
| ) { |
There was a problem hiding this comment.
@SimonRastikian I don't think this comment was addressed.
kevindeforth
left a comment
There was a problem hiding this comment.
Thank you, looks good.
I still have one file to review, but please proceed by resolving conflicts with the base branch.
| debug_assert_eq!( | ||
| participants.len(), | ||
| threshold.value(), | ||
| "triple routing infers t from channel size (see run_triple_generation_follower)" | ||
| ); |
There was a problem hiding this comment.
yes, please remove it. We run tests in release mode in CI, so I doubt this will do anything.
|
|
||
| pub const SUPPORTED_TRIPLE_GENERATION_BATCH_SIZE: usize = 64; | ||
|
|
||
| const TRIPLE_METRICS_REPORTING_INTERVAL: Duration = Duration::from_millis(500); |
There was a problem hiding this comment.
This seems a bit aggressive for a pure monitoring function. We lock a mutex each time we call this.
I think every 5 seconds is sufficient here.
gilcu3
left a comment
There was a problem hiding this comment.
Thank you again for the hard work. If we have still some doubts after this big change, we can always add more test coverage before the next release if needed.
Closes #3164
Closes #1680 in 0b8b201