This paper covers explanations of the following technical concepts.

• General Terminology

• MPC Group

• Key Generation With Mnemonic

• Key Generation Without Mnemonic

• Signing (Eddsa/ Ecdsa)

• Key Rotation

• Key Resharing

• Key Backup/Recover

• Key Import

• Key Export

General Terminology

Secret Key

One secret key is the key used by the BlockChains (e.g., Bitcoin, Ethereum) to do transaction signatures and verification. The crypto wallet address in BlockChains is usually derived from this secret key’s public key.

We support the Ecdsa secret key and Eddsa secret key at this moment. The two secret key types are primarily used by BlockChains.

Key Shard

Each secret key has more than 2 (including 2) shards in our MPC system. The shards will be kept in different locations. For example, one shard can be saved on mobile, computer, or cloud. If one device (e.g., one user’s mobile) keeps one key shard, then this device should not have access to other key shards. Other shards should never be sent to this device unless it is in the key export scenario.

The key shard has included the secret key’s public key.

The shard should be kept safely. In case one shard has been revealed or lost, the “key rotation” (see section of “key rotation”) should run as soon as possible.

MPC party

MPC involves multiple parties. For one key, each party will keep only one shard and does not know this key’s other shards. The MPC party could be one mobile, one computer, one cloud server, or one hard device (like a hard wallet device).

One MPC party may keep many keys’ shards. For example, one user’s mobile has installed an MPC wallet app. This user has three wallets (each wallet is in BlockChain Bitcoin/Ethereum/Solana). Each wallet has its secret key. In this case, this user’s mobile will have three key shards. Each shard belongs to one individual secret key.

For one particular key, one MPC party means one key shard.

Threshold

When a secret key’s signature or verification is needed, this secret key’s shards will do the computation jointly. Depending on the MPC configuration, not all the shards are required.

For example, one key has 4 total shards and the MPC threshold number for this key is 2. It means only 3 (threshold number + 1) shards are required to do the signature signing. The number of 2 (equal or less than the threshold number) shards can not work together to do the computation.

We use the phrase “t-n” in this paper to denote the MPC threshold configuration, where “t” equals the threshold number + 1, and “n” equals the total number of MPC parties. For example, “3-4” means the total number of the MPC party/shard is 4, the threshold is 2, and at least 3 of the 4 MPC parties/shards can do the computation successfully. It does not matter which three parties/shards are involved in the computation.

When computation happens, at least “t” parties need to be “active” simultaneously. I.e, they can send messages, receive messages, and do computations together.

MPC Group

Let’s say one secret key has 3 shards and three MPC parties are used to keep each shard. When the computation happens for this secret key, how do the three MPC parties know which shard should be used for the computation, since one party may have many shards for different secret keys? This is where the MPC group comes in.

The MPC group is to identify the key shard. Let’s say, we have one MPC group with ID “group-id-1”. This group has 2 keys, and each key has three shards (i.e., three MPC parties are involved: Party A & B & C). The three parties may keep the shards data for this MPC group “group-id-1” like below:

Party A

{

“key_1_identity”: “key_1_shard_a”,

“key_2_identity”: “key_2_shard_a”,

}

Party B

{

“key_1_identity”: “key_1_shard_b”,

“key_2_identity”: “key_2_shard_b”,

}

Party C

{

“key_1_identity”: “key_1_shard_c”,

“key_2_identity”: “key_2_shard_c”,

}

The key identity “key_1_identity” is to identify the keys within one MPC group.

When the user wants to do computations for key_1. This user will trigger the computation from one party (usually, it is this user’s mobile). This trigger party will send both the MPC group ID “group-id-1” and the key identity “key_1_identity” to the other two parties (we assume this is a “3-3” case). So the other two parties will find the correct shard from their local storage for the computation.

One secret key belongs to only one MPC group. One MPC group may contain more than one secret key. All the keys in one MPC group share the same MPC config (i.e., the total number of MPC parties and the threshold number). All the keys in one MPC group belong to one user.

New keys can be added to one MPC group, and existing keys can be removed from one MPC group. Whenever one key is added or removed from the group, all the parties holding this group should make the same key change.

This MPC group is very flexible. Depending on different applications, we can choose to organize the keys for different purposes. For example, one MPC group can be used to store all the Ecdsa keys, while another group can be used to store the Eddsa keys. One group can be used to store all child keys derived from one mnemonic. One group can also be used to store all keys imported from other wallet vendors.

It's good to set a number limit for keys within one MPC group. Key rotation & resharing will work based on one MPC group, which means all keys within one group will do key rotation or resharing at the same time. This could take too much time or too much computation resources to complete if the number of keys is large.

One new MPC group is registered by all MPC parties. MPC group should be ready to use when we need one group to hold key shards.

Key Generation With Mnemonic

Key generation with Mnemonic is an MPC mode compatible with mnemonic usage. From one trusted dealer (usually, it is one user’s mobile), the user can generate one mnemonic first and then derive the secret keys from this mnemonic for different Block Chains. Once the keys are generated, the trust dealer will generate all the MPC key shards for these keys and send these shards to all MPC parties. The mnemonic is also distributed to these parties, just like the secret keys.

Once all MPC parties have received the shards, the trusted dealer will delete the mnemonic and the original secret keys.

Before the key generation, at least one MPC group has been registered. We can choose which group(s) to keep these key shards. One example usage is we will use one group to keep mnemonic shards, and a different group to keep non-mnemonic shards.

After the key generation, if we want to add new wallets in the future, the trusted dealer can reconstruct the mnemonic from mnemonic shards and derive a new secret key from it. Then distribute the new secret key to all parties. Once the distribution is done, delete the mnemonic and the new secret key in the trusted dealer.

Key Generation Without Mnemonic

Key generation without Mnemonic is an MPC mode incompatible with the mnemonic. One party (usually the user’s mobile) will trigger the MPC key generation. All parties will work together to generate one new secret key. However, this new secret key is actually not revealed in this process. Each party only keeps one shard for this secret key and does not know the real secret key.

One MPC group should be registered already to hold the key shards.

The generated secret key will work as one “Master Key”. We will derive child keys from this master key for different BlockChains. We will not keep the child key shards. Instead, we only keep the child key derivation path.

The derivation will return the child key’s public key, which can be used for wallet address generation.

Signing (Eddsa/ Ecdsa)

After key generation, the key can be used to do the signing for the transaction hash. The user can choose the threshold + 1 number (or all the number) of parties to do the signing. The chosen parties should be “online” to do the computation together.

The MPC system only needs to know the group ID and key identity for this transaction. Then the returned signature of the transaction hash can be submitted to BlockChain.

The real secret key is not revealed in this process.

Key Backup/Recover

The key shard can be backed up on the user’s chosen cloud. In case the user’s device is lost, the key can be recovered from the cloud.

It’s good to do key rotation as soon as possible once key backup is used.

Key Import

The key import is to import the mnemonic provided by the external wallet vendor. The imported keys will use the mode of “Key Generation With Mnemonic”.

Key Export

The key export will export the mnemonic with the mode of “Key Generation With Mnemonic”. For the mode of “Key Generation Without Mnemonic”, it can export the full Ecdsa secret key. The real Eddsa secret key can not be generated, but a “hash version” of Eddsa secret key can be exported. This “hash version” of the Eddsa key is the hash value of the original Eddsa key and it can be used to do key signing as well.