Native Multisig accounts#
Note
This page provides reference documentation for native multisig accounts, available starting with protocol S. For step-by-step instructions on how to stake and bake with multisig accounts, see User stories for staking and baking multisigs .
Tezos accounts are defined by a pair of secret and public keys. Users use their secret keys to sign operations and blocks (or any other message), and the resulting signature is validated against the account’s public key. While this model is simple and effective, it presents two main challenges:
The entire security of the account relies on a single secret key. If this key is compromised, an attacker can gain full control of the account.
The model is not well-suited for organizations or shared accounts, as it does not allow for multiple users to manage the account collectively.
Both problems are usually solved by using a multisig contract, that allows to share its ownership and its associated balance or assets, between several participants. Tezos provides specific support for multisig contracts in the form of a builtin multisig contract and even a set of related client commands to interact with it. However, this solution is not applicable in all use cases, and most importantly in the case of collectively staking or baking. This is because in Tezos, a smart contract cannot be a delegate, and not even a staker.
Native multisig accounts address the above limitations with a
cryptographic solution based on BLS multi-signature schemes. BLS
signatures are particularly well-suited for this purpose due to their
aggregation properties. Tezos supports BLS signatures
with tz4 address accounts,
and starting with protocol S, these adopt a
proof-of-possession (PoP) scheme. As a result, protocols starting with S
can benefit from faster verification of multiple signatures of the
same message without breaking compatibility with the existing support
for BLS (and tz4 accounts).
The multisig accounts implementation offers RPCs and client
commands to facilitate the signing of
operations in a native multisig setup. As a result, the protocol does
not need to differentiate between a tz4 address belonging to a single
user account and one associated with a multisig account.
Enshrined multisig signing scenarios#
A (native) multisig account is a tz4 address managed collectively by N participants (also called members).
Multisig accounts support two different multi-signature schemes, which provide different scenarios based on the requirements for signing an operation:
N-of-N scenario (signature aggregation): All N members must sign every operation for it to be valid. In this scenario, users derive a multisig account by aggregating the public keys of their existing
tz4addresses without the need for sharing secrets or trusted parties.M-of-N scenario (threshold signature): A threshold number of participants is required to sign the operation. Here, M denotes the minimum number of signatures required to create a valid signature, out of the total of N members. In this scenario, users generate a new unencrypted secret for the multisig account, which is then split into secret shares that need to be distributed among the participants along with a public identifier (a natural number between 1 and N). This entails that all participants must trust the honesty of the party in charge of splitting the secret key and distributing the secrets.
The workflow for signing operations is as follows:
The participants decide a priori which scheme to use: either N-of-N or M-of-N.
The participants reveal the resulting public key of the multisig account on-chain.
The participants inject operations signed with the multisig accounts’s signature scheme.
For example, a multisig account can stake 10,000 tez following
almost the same process as if it were carried out by a single
staker. The only difference is the signing process: signatures (for
each operation) must first be collected from the required members, and
then aggregated into a single signature based on the chosen
scenario. The resulting operation is identical to a staking operation
signed by a single implicit tz4 account. For instance, the JSON output
of a multisig stake operation would look like this:
(the source and destination are both the address of the multisig account, because staking is implemented by a pseudo-operation consisting in sending a transaction to oneself).
Octez CLI commands and RPC endpoints#
Multisig accounts introduce the following Octez client commands and/or associated RPC endpoints to facilitate the creation of multisig accounts and the aggregation of signatures.
Setting up a multisig account#
N-of-N (signature aggregation) |
M-of-N (threshold signature) |
|
|---|---|---|
Client command |
|
|
RPC |
|
No RPC as it would require sending a secret key. |
Parameters |
|
|
Output |
|
|
Example output |
{ "public_key": "BLpk...",
"public_key_hash": "tz4..." }
|
{ "public_key": "BLpk...",
"public_key_hash": "tz4...",
"proof": "BLsig...",
"secret_shares":
[ { "id": 1, "secret_key": "BLsk..." },
{ "id": 2, "secret_key": "BLsk..." },
{ "id": 3, "secret_key": "BLsk..." },
// ...
] }
|
When aggregating public keys, the N-of-N scenario must also check a proof-of-possession (PoP) to mitigate rogue key attacks. For creating a PoP, the dedicated client command is:
N-of-N (signature aggregation) |
|
|---|---|
|
|
On sharing secrets. The current implementation of M-of-N Scenario relies on Shamir’s Secret Sharing algorithm to share an unencrypted master secret key between participants – i.e. it returns a public key and unencrypted secret keys for each of the multisig account participants. We envision implementing support for further key-generation mechanisms in future, notably Distributed Key Generation, if there is sufficient ecosystem interest.
Proof of possession#
For revealing tz4 accounts a proof of possession is required.
N-of-N (signature aggregation) |
M-of-N (threshold signature) |
|
|---|---|---|
Client command |
|
|
RPC |
|
No RPC as it would require sending a secret key. |
Parameters |
|
N/A |
Output |
Proof of possession |
N/A |
Example output |
|
N/A |
For N-of-N Scenario, it requires to create proof_i_pk_multisig for
a multisig account’s public key pk_multisig:
N-of-N (signature aggregation) |
|
|---|---|
|
|
Signing operations with multisig accounts#
N-of-N (signature aggregation) |
M-of-N (threshold signature) |
|
|---|---|---|
Client command |
|
|
RPC |
|
|
Parameters |
|
|
Output |
Valid aggregated signature of a message |
idem |
Example output |
|
idem |
In both scenarios, multisig participants may use the existing sign bytes client
command to produce their own signature signature_i:
octez-client sign bytes '<unsigned_operation>' for <pk_i>
Signature shares can also be verified using the existing check
bytes client command:
octez-client check that bytes '<unsigned_operation>' were signed by <pk_i> to produce <signature_i>