github.com/cosmos/cosmos-sdk@v0.50.10/docs/architecture/adr-036-arbitrary-signature.md (about)

     1  # ADR 036: Arbitrary Message Signature Specification
     2  
     3  ## Changelog
     4  
     5  * 28/10/2020 - Initial draft
     6  
     7  ## Authors
     8  
     9  * Antoine Herzog (@antoineherzog)
    10  * Zaki Manian (@zmanian)
    11  * Aleksandr Bezobchuk (alexanderbez) [1]
    12  * Frojdi Dymylja (@fdymylja)
    13  
    14  ## Status
    15  
    16  Draft
    17  
    18  ## Abstract
    19  
    20  Currently, in the Cosmos SDK, there is no convention to sign arbitrary message like on Ethereum. We propose with this specification, for Cosmos SDK ecosystem, a way to sign and validate off-chain arbitrary messages.
    21  
    22  This specification serves the purpose of covering every use case, this means that cosmos-sdk applications developers decide how to serialize and represent `Data` to users.
    23  
    24  ## Context
    25  
    26  Having the ability to sign messages off-chain has proven to be a fundamental aspect of nearly any blockchain. The notion of signing messages off-chain has many added benefits such as saving on computational costs and reducing transaction throughput and overhead. Within the context of the Cosmos, some of the major applications of signing such data includes, but is not limited to, providing a cryptographic secure and verifiable means of proving validator identity and possibly associating it with some other framework or organization. In addition, having the ability to sign Cosmos messages with a Ledger or similar HSM device.
    27  
    28  Further context and use cases can be found in the references links.
    29  
    30  ## Decision
    31  
    32  The aim is being able to sign arbitrary messages, even using Ledger or similar HSM devices.
    33  
    34  As a result signed messages should look roughly like Cosmos SDK messages but **must not** be a valid on-chain transaction. `chain-id`, `account_number` and `sequence` can all be assigned invalid values.
    35  
    36  Cosmos SDK 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES.
    37  
    38  A spec should include an `auth_info` that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO.
    39  
    40  Create the `offchain` proto definitions, we extend the auth module with `offchain` package to offer functionalities to verify and sign offline messages.
    41  
    42  An offchain transaction follows these rules:
    43  
    44  * the memo must be empty
    45  * nonce, sequence number must be equal to 0
    46  * chain-id must be equal to “”
    47  * fee gas must be equal to 0
    48  * fee amount must be an empty array
    49  
    50  Verification of an offchain transaction follows the same rules as an onchain one, except for the spec differences highlighted above.
    51  
    52  The first message added to the `offchain` package is `MsgSignData`.
    53  
    54  `MsgSignData` allows developers to sign arbitrary bytes valid offchain only. Where `Signer` is the account address of the signer. `Data` is arbitrary bytes which can represent `text`, `files`, `object`s. It's applications developers decision how `Data` should be deserialized, serialized and the object it can represent in their context.
    55  
    56  It's applications developers decision how `Data` should be treated, by treated we mean the serialization and deserialization process and the Object `Data` should represent.
    57  
    58  Proto definition:
    59  
    60  ```protobuf
    61  // MsgSignData defines an arbitrary, general-purpose, off-chain message
    62  message MsgSignData {
    63      // Signer is the sdk.AccAddress of the message signer
    64      bytes Signer = 1 [(gogoproto.jsontag) = "signer", (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress"];
    65      // Data represents the raw bytes of the content that is signed (text, json, etc)
    66      bytes Data = 2 [(gogoproto.jsontag) = "data"];
    67  }
    68  ```
    69  
    70  Signed MsgSignData json example:
    71  
    72  ```json
    73  {
    74    "type": "cosmos-sdk/StdTx",
    75    "value": {
    76      "msg": [
    77        {
    78          "type": "sign/MsgSignData",
    79          "value": {
    80            "signer": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr",
    81            "data": "cmFuZG9t"
    82          }
    83        }
    84      ],
    85      "fee": {
    86        "amount": [],
    87        "gas": "0"
    88      },
    89      "signatures": [
    90        {
    91          "pub_key": {
    92            "type": "tendermint/PubKeySecp256k1",
    93            "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9"
    94          },
    95          "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg=="
    96        }
    97      ],
    98      "memo": ""
    99    }
   100  }
   101  ```
   102  
   103  ## Consequences
   104  
   105  There is a specification on how messages, that are not meant to be broadcast to a live chain, should be formed.
   106  
   107  ### Backwards Compatibility
   108  
   109  Backwards compatibility is maintained as this is a new message spec definition.
   110  
   111  ### Positive
   112  
   113  * A common format that can be used by multiple applications to sign and verify off-chain messages.
   114  * The specification is primitive which means it can cover every use case without limiting what is possible to fit inside it.
   115  * It gives room for other off-chain messages specifications that aim to target more specific and common use cases such as off-chain-based authN/authZ layers [2].
   116  
   117  ### Negative
   118  
   119  * Current proposal requires a fixed relationship between an account address and a public key.
   120  * Doesn't work with multisig accounts.
   121  
   122  ## Further discussion
   123  
   124  * Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content laying in `Data` non-replayable when, and if, needed.
   125  * the offchain package will be further extended with extra messages that target specific use cases such as, but not limited to, authentication in applications, payment channels, L2 solutions in general.
   126  
   127  ## References
   128  
   129  1. https://github.com/cosmos/ics/pull/33
   130  2. https://github.com/cosmos/cosmos-sdk/pull/7727#discussion_r515668204
   131  3. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-722478477
   132  4. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923