Batched keygen
This page describes the process of batched keygen in the challenge response and non-challenge response mechanisms in Silent Network.
Last updated
This page describes the process of batched keygen in the challenge response and non-challenge response mechanisms in Silent Network.
Last updated
Main steps with challenge response mechanism explained:
1: The user wants to do a Distributed Key Generation (DKG) for 2 keys: secp256k1 and ed25519.
2: WPFE generates two ephemeral keypairs (eph_pk, eph_sk), one for each key, secret part stays on browser side, public part is sent in setup_opts JSON request.
3: WPFE prepares a JSON we call setup_opts for both keys, containing basic information, like n, t parameters, permissions, ephemeral public key eph_pk, the eph_sk will be later used to generate DSG requests without User interaction
4: Websocket connections are established between WPFE, WPBE, Aggregator, Operators. WPBE establishes the connection on /v1/keygen endpoint of the Aggregator and sends the api_key for authentication.
10, 11. After the api_key authentication is done, the WPBE sends the setup_opts and a signature to the Aggregator which verifies the signature
12, 13: Operators send their random challenges for both keys
16, 17: Challenges gets aggregated by WPBE and final_challenges for secp256k1 and ed25519 are sent to the WPFE
WPFE prepares two messages to be signed by the user, one contains final_challenge for secp256k1 key and another one for ed25519 key. We have two methods of authentication:
Passkeys - user signs final_challenge using authenticator (then usk is key on authenticator)
EOA - user signs EIP712 typed message that contains final_challenge , parameters, like n , t , using browser wallet (like MetaMask, then usk is key held by MetaMask)
18, 19: User authenticates the request (clicks “OK” on MetaMask window, or authenticates using passkey) two times
20, 21: Signatures are sent to Aggregator
22, 23: Aggregator creates two setup_msg, a struct that is recognizable by Operators, it contains all data required to start the DKG protocol. Aggregator propagates them to n Operators
24, 25: Each operator validates user signature over the request, the final_challenge, etc
26: Operators communicate with each other using DKLs protocol to produce the key (we call it mpc-key or distributed key). Each of them creates its own keyshare, extracts permissions, eph_pk from setup_msg and stores it in a storage.
27, 28: public_key and key_id of secp256k1 and ed25519 keys come back as a response all the way up to the WPFE
Main steps without challenge response mechanism explained:
1: The user wants to do a Distributed Key Generation (DKG) for 2 keys: secp256k1 and ed25519.
2: WPFE generates two ephemeral keypairs (eph_pk, eph_sk), one for each key, secret part stays on browser side, public part is sent in setup_opts JSON request.
3: WPFE prepares a JSON we call setup_opts for both keys, containing basic information, like n, t parameters, permissions, ephemeral public key eph_pk, the eph_sk will be later used to generate DSG requests without User interaction
4: Websocket connections are established between WPFE, WPBE, Aggregator, Operators. WPBE establishes the connection on /v2/keygen endpoint of the Aggregator and sends the api_key for authentication.
5: Final challenge for bot keys is generated by hashing the appropriate setup_opts
6: WPFE prepares two messages to be signed by the user, one contains final_challenge for secp256k1 key and another one for ed25519 key. We have two methods of authentication:
Passkeys - user signs final_challenge using authenticator (then usk is key on authenticator)
EOA - user signs EIP712 typed message that contains final_challenge , parameters, like n , t , using browser wallet (like MetaMask, then usk is key held by MetaMask)
7, 8: User authenticates the request (clicks “OK” on MetaMask window, or authenticates using passkey) two times
9: setup_opts together with signatures gets sent to the WPBE
14, 15: WPBE sends setup_opts and signature to Aggregator which verifies it
17, 18: Aggregator creates two setup_msg structs that are recognizable by Operators, each of them containing all data required to start the DKG protocol. Aggregator propagates them to n Operators
19: Each operator validates user signature over the request, the final_challenge, etc
20: Operators communicate with each other using DKLs protocol to produce the key (we call it mpc-key or distributed key). Each of them creates its own keyshare, extracts permissions, eph_pk from setup_msg and stores it in a storage.
21, 22, 23, 24: public_key and key_id of secp256k1 and ed25519 keys come back as a response all the way up to the WPFE