@@ -48,22 +48,89 @@ module aptos_framework::keyless_account {
4848 struct Configuration has key , store , drop , copy {
4949 /// An override `aud` for the identity of a recovery service, which will help users recover their keyless accounts
5050 /// associated with dapps or wallets that have disappeared.
51- /// IMPORTANT: This recovery service **cannot** on its own take over user accounts; a user must first sign in
51+ /// IMPORTANT: This recovery service **cannot**, on its own, take over user accounts: a user must first sign in
5252 /// via OAuth in the recovery service in order to allow it to rotate any of that user's keyless accounts.
53+ ///
54+ /// Furthermore, the ZKP eventually expires, so there is a limited window within which a malicious recovery
55+ /// service could rotate accounts. In the future, we can make this window arbitrarily small by further lowering
56+ /// the maximum expiration horizon for ZKPs used for recovery, instead of relying on the `max_exp_horizon_secs`
57+ /// value in this resource.
58+ ///
59+ /// If changed: There is no prover service support yet for recovery mode => ZKPs with override aud's enabled
60+ /// will not be served by the prover service => as long as training wheels are "on," such recovery ZKPs will
61+ /// never arrive on chain.
62+ /// (Once support is implemented in the prover service, in an abundance of caution, the training wheel check
63+ /// should only pass if the override aud in the public statement matches one in this list. Therefore, changes
64+ /// to this value should be picked up automatically by the prover service.)
5365 override_aud_vals: vector <String >,
66+
5467 /// No transaction can have more than this many keyless signatures.
68+ ///
69+ /// If changed: Only affects the Aptos validators; prover service not impacted.
5570 max_signatures_per_txn: u16 ,
56- /// How far in the future from the JWT issued at time the EPK expiry can be set.
71+
72+ /// How far in the future from the JWT's issued-at-time can the EPK expiration date be set?
73+ /// Specifically, validators enforce that the ZKP's expiration horizon is less than this `max_exp_horizon_secs`
74+ /// value.
75+ ///
76+ /// If changed: Only affects the Aptos validators; prover service not impacted.
5777 max_exp_horizon_secs: u64 ,
58- /// The training wheels PK, if training wheels are on
78+
79+ /// The training wheels PK, if training wheels are on.
80+ ///
81+ /// If changed: Prover service has to be re-deployed with the associated training wheel SK.
5982 training_wheels_pubkey: Option <vector <u8 >>,
83+
6084 /// The max length of an ephemeral public key supported in our circuit (93 bytes)
85+ ///
86+ /// Note: Currently, the circuit derives the JWT's nonce field by hashing the EPK as:
87+ /// ```
88+ /// Poseidon_6(
89+ /// epk_0, epk_1, epk_2,
90+ /// max_commited_epk_bytes,
91+ /// exp_date,
92+ /// epk_blinder
93+ /// )
94+ /// ```
95+ /// and the public inputs hash by hashing the EPK with other inputs as:
96+ /// ```
97+ /// Poseidon_14(
98+ /// epk_0, epk_1, epk_2,
99+ /// max_commited_epk_bytes,
100+ /// [...]
101+ /// )
102+ /// ```
103+ /// where `max_committed_epk_byte` is passed in as one of the witnesses to the circuit. As a result, (some)
104+ /// changes to this field could technically be handled by the same circuit: e.g., if we let the epk_i chunks
105+ /// exceed 31 bytes, but no more than 32, then `max_commited_epk_bytes` could now be in (93, 96]. Whether such a
106+ /// restricted set of changes is useful remains unclear. Therefore, the verdict will be that...
107+ ///
108+ /// If changed: (Likely) requires a circuit change because over-decreasing (or increasing) it leads to fewer (or
109+ /// more) EPK chunks. This would break the current way the circuit hashes the nonce and the public inputs.
110+ /// => prover service redeployment.
61111 max_commited_epk_bytes: u16 ,
112+
62113 /// The max length of the value of the JWT's `iss` field supported in our circuit (e.g., `"https://accounts.google.com"`)
114+ ///
115+ /// If changed: Requires a circuit change because the `iss` field value is hashed inside the circuit as
116+ /// `HashBytesToFieldWithLen(MAX_ISS_VALUE_LEN)(iss_value, iss_value_len)` where `MAX_ISS_VALUE_LEN` is a
117+ /// circuit constant hard-coded to `max_iss_val_bytes` (i.e., to 120) => prover service redeployment..
63118 max_iss_val_bytes: u16 ,
119+
64120 /// The max length of the JWT field name and value (e.g., `"max_age":"18"`) supported in our circuit
121+ ///
122+ /// If changed: Requires a circuit change because the extra field key-value pair is hashed inside the circuit as
123+ /// `HashBytesToFieldWithLen(MAX_EXTRA_FIELD_KV_PAIR_LEN)(extra_field, extra_field_len)` where
124+ /// `MAX_EXTRA_FIELD_KV_PAIR_LEN` is a circuit constant hard-coded to `max_extra_field_bytes` (i.e., to 350)
125+ /// => prover service redeployment.
65126 max_extra_field_bytes: u16 ,
66- /// The max length of the base64url-encoded JWT header in bytes supported in our circuit
127+
128+ /// The max length of the base64url-encoded JWT header in bytes supported in our circuit.
129+ ///
130+ /// If changed: Requires a circuit change because the JWT header is hashed inside the circuit as
131+ /// `HashBytesToFieldWithLen(MAX_B64U_JWT_HEADER_W_DOT_LEN)(b64u_jwt_header_w_dot, b64u_jwt_header_w_dot_len)`
132+ /// where `MAX_B64U_JWT_HEADER_W_DOT_LEN` is a circuit constant hard-coded to `max_jwt_header_b64_bytes`
133+ /// (i.e., to 350) => prover service redeployment.
67134 max_jwt_header_b64_bytes: u32 ,
68135 }
69136
0 commit comments