You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

162 lines
6.0 KiB

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