github.com/pokt-network/tendermint@v0.32.11-0.20230426215212-59310158d3e9/docs/architecture/adr-019-multisigs.md (about)

     1  # ADR 019: Encoding standard for Multisignatures
     2  
     3  ## Changelog
     4  
     5  06-08-2018: Minor updates
     6  
     7  27-07-2018: Update draft to use amino encoding
     8  
     9  11-07-2018: Initial Draft
    10  
    11  ## Context
    12  
    13  Multisignatures, or technically _Accountable Subgroup Multisignatures_ (ASM),
    14  are signature schemes which enable any subgroup of a set of signers to sign any message,
    15  and reveal to the verifier exactly who the signers were.
    16  This allows for complex conditionals of when to validate a signature.
    17  
    18  Suppose the set of signers is of size _n_.
    19  If we validate a signature if any subgroup of size _k_ signs a message,
    20  this becomes what is commonly reffered to as a _k of n multisig_ in Bitcoin.
    21  
    22  This ADR specifies the encoding standard for general accountable subgroup multisignatures,
    23  k of n accountable subgroup multisignatures, and its weighted variant.
    24  
    25  In the future, we can also allow for more complex conditionals on the accountable subgroup.
    26  
    27  ## Proposed Solution
    28  
    29  ### New structs
    30  
    31  Every ASM will then have its own struct, implementing the crypto.Pubkey interface.
    32  
    33  This ADR assumes that [replacing crypto.Signature with []bytes](https://github.com/tendermint/tendermint/issues/1957) has been accepted.
    34  
    35  #### K of N threshold signature
    36  
    37  The pubkey is the following struct:
    38  
    39  ```golang
    40  type ThresholdMultiSignaturePubKey struct { // K of N threshold multisig
    41  	K       uint               `json:"threshold"`
    42  	Pubkeys []crypto.Pubkey    `json:"pubkeys"`
    43  }
    44  ```
    45  
    46  We will derive N from the length of pubkeys. (For spatial efficiency in encoding)
    47  
    48  `Verify` will expect an `[]byte` encoded version of the Multisignature.
    49  (Multisignature is described in the next section)
    50  The multisignature will be rejected if the bitmap has less than k indices,
    51  or if any signature at any of the k indices is not a valid signature from
    52  the kth public key on the message.
    53  (If more than k signatures are included, all must be valid)
    54  
    55  `Bytes` will be the amino encoded version of the pubkey.
    56  
    57  Address will be `Hash(amino_encoded_pubkey)`
    58  
    59  The reason this doesn't use `log_8(n)` bytes per signer is because that heavily optimizes for the case where a very small number of signers are required.
    60  e.g. for `n` of size `24`, that would only be more space efficient for `k < 3`.
    61  This seems less likely, and that it should not be the case optimized for.
    62  
    63  #### Weighted threshold signature
    64  
    65  The pubkey is the following struct:
    66  
    67  ```golang
    68  type WeightedThresholdMultiSignaturePubKey struct {
    69  	Weights []uint             `json:"weights"`
    70  	Threshold uint             `json:"threshold"`
    71  	Pubkeys []crypto.Pubkey    `json:"pubkeys"`
    72  }
    73  ```
    74  
    75  Weights and Pubkeys must be of the same length.
    76  Everything else proceeds identically to the K of N multisig,
    77  except the multisig fails if the sum of the weights is less than the threshold.
    78  
    79  #### Multisignature
    80  
    81  The inter-mediate phase of the signatures (as it accrues more signatures) will be the following struct:
    82  
    83  ```golang
    84  type Multisignature struct {
    85  	BitArray    CryptoBitArray // Documented later
    86  	Sigs        [][]byte
    87  ```
    88  
    89  It is important to recall that each private key will output a signature on the provided message itself.
    90  So no signing algorithm ever outputs the multisignature.
    91  The UI will take a signature, cast into a multisignature, and then keep adding
    92  new signatures into it, and when done marshal into `[]byte`.
    93  This will require the following helper methods:
    94  
    95  ```golang
    96  func SigToMultisig(sig []byte, n int)
    97  func GetIndex(pk crypto.Pubkey, []crypto.Pubkey)
    98  func AddSignature(sig Signature, index int, multiSig *Multisignature)
    99  ```
   100  
   101  The multisignature will be converted to an `[]byte` using amino.MarshalBinaryBare. \*
   102  
   103  #### Bit Array
   104  
   105  We would be using a new implementation of a bitarray. The struct it would be encoded/decoded from is
   106  
   107  ```golang
   108  type CryptoBitArray struct {
   109  	ExtraBitsStored  byte      `json:"extra_bits"` // The number of extra bits in elems.
   110  	Elems            []byte    `json:"elems"`
   111  }
   112  ```
   113  
   114  The reason for not using the BitArray currently implemented in `libs/common/bit_array.go`
   115  is that it is less space efficient, due to a space / time trade-off.
   116  Evidence for this is outlined in [this issue](https://github.com/tendermint/tendermint/issues/2077).
   117  
   118  In the multisig, we will not be performing arithmetic operations,
   119  so there is no performance increase with the current implementation,
   120  and just loss of spatial efficiency.
   121  Implementing this new bit array with `[]byte` _should_ be simple, as no
   122  arithmetic operations between bit arrays are required, and save a couple of bytes.
   123  (Explained in that same issue)
   124  
   125  When this bit array encoded, the number of elements is encoded due to amino.
   126  However we may be encoding a full byte for what we actually only need 1-7 bits for.
   127  We store that difference in ExtraBitsStored.
   128  This allows for us to have an unbounded number of signers, and is more space efficient than what is currently used in `libs/common`.
   129  Again the implementation of this space saving feature is straight forward.
   130  
   131  ### Encoding the structs
   132  
   133  We will use straight forward amino encoding. This is chosen for ease of compatibility in other languages.
   134  
   135  ### Future points of discussion
   136  
   137  If desired, we can use ed25519 batch verification for all ed25519 keys.
   138  This is a future point of discussion, but would be backwards compatible as this information won't need to be marshalled.
   139  (There may even be cofactor concerns without ristretto)
   140  Aggregation of pubkeys / sigs in Schnorr sigs / BLS sigs is not backwards compatible, and would need to be a new ASM type.
   141  
   142  ## Status
   143  
   144  Proposed.
   145  
   146  ## Consequences
   147  
   148  ### Positive
   149  
   150  - Supports multisignatures, in a way that won't require any special cases in our downstream verification code.
   151  - Easy to serialize / deserialize
   152  - Unbounded number of signers
   153  
   154  ### Negative
   155  
   156  - Larger codebase, however this should reside in a subfolder of tendermint/crypto, as it provides no new interfaces. (Ref #https://github.com/tendermint/go-crypto/issues/136)
   157  - Space inefficient due to utilization of amino encoding
   158  - Suggested implementation requires a new struct for every ASM.
   159  
   160  ### Neutral