Skip to content

Conversation

@DSharifi
Copy link
Contributor

closes #1629

@DSharifi DSharifi linked an issue Dec 15, 2025 that may be closed by this pull request
3 tasks
/// The digest of the MPC image running.
pub launcher_compose_hash: [u8; 32],
/// Unix timestamp for when the attestation was created.
pub creation_time_stamp_seonds: u64,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where do we get the time from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment is s currently misleading. The timestamp is taken from "now" time argument during the initial verification, so it's the timestamp of when the contract first saw the attestation and not the creation date.

In a follow up PR we should refactor this internal implementation to use the timestamp embedded in the attestation instead.

clean_tee_status_tera_gas: Some(10),
cleanup_orphaned_node_migrations_tera_gas: Some(3),
remove_non_participant_update_votes_tera_gas: Some(5),
attestation_max_validity_duration_seconds: Some(1912312),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this equals to 22 days, why did you choose this number?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is just testing a serialization and deserialization works as expected. The values are not used for anything here.

/// The digest of the MPC image running.
pub launcher_compose_hash: [u8; 32],
/// Unix timestamp for when the attestation was created.
pub creation_time_stamp_seonds: u64,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pub creation_time_stamp_seonds: u64,
pub creation_time_stamp_seconds: u64,

you will need to change in 5 places

}

pub fn validate_tee(
pub fn re_veirfy_participants(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pub fn re_veirfy_participants(
pub fn re_verify_participants(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also since this method also does cleanup
consider caliing it:

reverify_and_update_participants
or
validate_and_cleanup_participants

}

pub fn validate_tee(
pub fn re_veirfy_participants(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you also add a Rust doc comment for the method?

…ion' of github.com:near/mpc into 1629-contract-should-not-store-full-attestation-submission
Copy link
Contributor

@barakeinav1 barakeinav1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall look good,
I requested some changes (mainly nits, typo name etc..) ,
I also think you should add another test: (I didn't see something like it)

#[test]
fn re_verify_fails_after_allowed_hash_is_cleaned_up() {
// 1. Add allowed MPC hash H1 at time T0
// 2. Add participant attested with H1
// 3. Add new MPC hash H2 (upgrade)
// 4. Advance time > tee_upgrade_deadline_duration
// 5. cleanup_expired_hashes removes H1
// 6. re_verify_tee_participant fails
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

contract should not store full Attestation submission

3 participants