Batched keygen

This page describes the process of batched keygen in the challenge response and non-challenge response mechanisms in Silent Network.

Challenge response mechanism

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:

1. Passkeys - user signs final_challenge using authenticator (then usk is key on authenticator)

2. 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

Non-challenge response mechanism

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:

1. Passkeys - user signs final_challenge using authenticator (then usk is key on authenticator)

2. 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