ADR 036: Arbitrary Message Signature Specification

变更记录

28/10/2020 - 初始草案

作者

Antoine Herzog (@antoineherzog)
Zaki Manian (@zmanian)
Aleksandr Bezobchuk (alexanderbez) [1]
Frojdi Dymylja (@fdymylja)

状态

草案

摘要

当前，在 Cosmos SDK 中，还没有像以太坊那样对任意消息签名的约定。我们通过本规范，为 Cosmos SDK 生态系统提出一种对链下任意消息进行签名和验证的方法。本规范旨在覆盖各种使用场景，这意味着 cosmos-sdk 应用的开发者可以自行决定如何序列化 Data 并将其呈现给用户。

背景

能够在链下对消息进行签名，已被证明几乎是所有区块链的基础能力之一。链下签名带来了许多额外好处，例如节省计算成本，以及减少交易吞吐和系统开销。在 Cosmos 的语境中，此类数据签名的重要应用包括但不限于：提供一种密码学安全且可验证的方式来证明验证者身份，并可能将其与其他框架或组织关联起来。此外，还应具备使用 Ledger 或类似 HSM 设备对 Cosmos 消息进行签名的能力。更多背景和使用场景可参见参考链接。

决策

目标是能够对任意消息进行签名，包括使用 Ledger 或类似 HSM 设备时也能实现。因此，签名后的消息在形式上应大致类似 Cosmos SDK 消息，但绝不能是合法的链上交易。chain-id、account_number 和 sequence 都可以被赋予无效值。 Cosmos SDK 0.40 还引入了 auth_info 的概念，可用于指定 SIGN_MODES。规范应包含一个支持 SIGN_MODE_DIRECT 和 SIGN_MODE_LEGACY_AMINO 的 auth_info。创建 offchain proto 定义；我们通过扩展 auth 模块中的 offchain package，提供验证和签名离线消息的功能。一笔链下交易需遵循以下规则：

memo 必须为空
nonce、sequence number 必须等于 0
chain-id 必须等于 ""
fee gas 必须等于 0
fee amount 必须为空数组

链下交易的验证规则与链上交易相同，唯一例外是上述规范差异。加入 offchain package 的第一个消息是 MsgSignData。 MsgSignData 允许开发者对仅适用于链下的任意字节进行签名。其中，Signer 是签名者的账户地址；Data 是任意字节，可表示 text、files、object。在具体上下文中，如何反序列化与序列化 Data，以及它可以表示什么对象，由应用开发者自行决定。如何处理 Data 同样由应用开发者决定；这里的“处理”是指序列化与反序列化过程，以及 Data 应表示的对象。 Proto 定义：

// MsgSignData defines an arbitrary, general-purpose, off-chain message
message MsgSignData {
    // Signer is the sdk.AccAddress of the message signer
    bytes Signer = 1 [(gogoproto.jsontag) = "signer", (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress"];
    // Data represents the raw bytes of the content that is signed (text, json, etc)
    bytes Data = 2 [(gogoproto.jsontag) = "data"];
}

已签名的 MsgSignData JSON 示例：

{
  "type": "cosmos-sdk/StdTx",
  "value": {
    "msg": [
      {
        "type": "sign/MsgSignData",
        "value": {
          "signer": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr",
          "data": "cmFuZG9t"
        }
      }
    ],
    "fee": {
      "amount": [],
      "gas": "0"
    },
    "signatures": [
      {
        "pub_key": {
          "type": "tendermint/PubKeySecp256k1",
          "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9"
        },
        "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg=="
      }
    ],
    "memo": ""
  }
}

影响

对于那些并非用于广播到运行中链上的消息，应如何构造，现在有了相应规范。

向后兼容性

由于这是一个新的消息规范定义，因此保持了向后兼容性。

正面影响

提供了一种可被多个应用用于签名和验证链下消息的通用格式。
该规范足够基础，因此能够覆盖各种使用场景，而不会为了适配某种形式而限制其可能性。
它也为其他链下消息规范留下了空间，这些规范可以面向更具体、更常见的使用场景，例如基于链下的 authN/authZ 层 [2]。

负面影响

当前提案要求账户地址与公钥之间存在固定关系。
不适用于多重签名账户。

进一步讨论

关于 MsgSignData 的安全性，使用 MsgSignData 的开发者需要负责在必要时确保 Data 中承载的内容不可重放。
offchain package 将进一步扩展，加入更多面向特定使用场景的消息，包括但不限于应用中的认证、支付通道，以及更广义的 L2 解决方案。

参考资料

Changelog

28/10/2020 - Initial draft

Authors

Antoine Herzog (@antoineherzog)
Zaki Manian (@zmanian)
Aleksandr Bezobchuk (alexanderbez) [1]
Frojdi Dymylja (@fdymylja)

Status

Draft

Abstract

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. 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.

Context

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. Further context and use cases can be found in the references links.

Decision

The aim is being able to sign arbitrary messages, even using Ledger or similar HSM devices. 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. Cosmos SDK 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES. A spec should include an auth_info that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO. Create the offchain proto definitions, we extend the auth module with offchain package to offer functionalities to verify and sign offline messages. An offchain transaction follows these rules:

the memo must be empty
nonce, sequence number must be equal to 0
chain-id must be equal to “”
fee gas must be equal to 0
fee amount must be an empty array

Verification of an offchain transaction follows the same rules as an onchain one, except for the spec differences highlighted above. The first message added to the offchain package is MsgSignData. 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, objects. It’s applications developers decision how Data should be deserialized, serialized and the object it can represent in their context. 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. Proto definition:

// MsgSignData defines an arbitrary, general-purpose, off-chain message
message MsgSignData {
    // Signer is the sdk.AccAddress of the message signer
    bytes Signer = 1 [(gogoproto.jsontag) = "signer", (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress"];
    // Data represents the raw bytes of the content that is signed (text, json, etc)
    bytes Data = 2 [(gogoproto.jsontag) = "data"];
}

Signed MsgSignData json example:

{
  "type": "cosmos-sdk/StdTx",
  "value": {
    "msg": [
      {
        "type": "sign/MsgSignData",
        "value": {
          "signer": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr",
          "data": "cmFuZG9t"
        }
      }
    ],
    "fee": {
      "amount": [],
      "gas": "0"
    },
    "signatures": [
      {
        "pub_key": {
          "type": "tendermint/PubKeySecp256k1",
          "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9"
        },
        "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg=="
      }
    ],
    "memo": ""
  }
}

Consequences

There is a specification on how messages, that are not meant to be broadcast to a live chain, should be formed.

Backwards Compatibility

Backwards compatibility is maintained as this is a new message spec definition.

Positive

A common format that can be used by multiple applications to sign and verify off-chain messages.
The specification is primitive which means it can cover every use case without limiting what is possible to fit inside it.
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].

Negative

Current proposal requires a fixed relationship between an account address and a public key.
Doesn’t work with multisig accounts.

Further discussion

Regarding security in MsgSignData, the developer using MsgSignData is in charge of making the content laying in Data non-replayable when, and if, needed.
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.

​变更记录

​作者

​状态

​摘要

​背景

​决策

​影响

​向后兼容性

​正面影响

​负面影响

​进一步讨论

​参考资料

​Changelog

​Authors

​Status

​Abstract

​Context

​Decision

​Consequences

​Backwards Compatibility

​Positive

​Negative

​Further discussion

​References