​
变更记录

  • 2022-02-08：初稿

​
状态

已接受，并已在 v7 中应用

​
背景

截至 ibc-go v7，06-solomachine 实现一直使用 DataType 来构造签名字节，该字段用于描述被签名的数据类型。 这一设计决策源于对其安全影响的误解。 有人指出，proto 定义本身并不提供唯一性，而唯一性是确保针对不同数据类型的两个签名永远不会相同的必要条件。 此前忽略的一点是，唯一性并不是由 proto 定义本身提供的，而是由 proto 定义的使用方式提供的。 core IBC 提供的路径将是唯一的，并且已经被编码进签名数据中。 因此，即使两个不同路径具有相同的数据值，它们的编码结果也会不同，从而保证签名的唯一性。 此外，当前的构造方式不支持规范仓库中为支持通用验证函数而提出的变更。 这是因为，为了验证一条新路径，必须为该路径新增一个 DataType。

​
决策

移除 DataType，并将 SignBytes 和 SignatureAndData 中的 DataType 替换为 Path。 新的 Path 字段应为 bytes。 除 HeaderData 外，移除所有 ...Data proto 定义。 这些 ...Data 定义此前是为每个 DataType 分别创建的。 solo machine proto 定义的 proto 版本应提升为 v3。 这样可以去除签名构造中的一层额外复杂性，并支持通用验证。

​
影响

​
正面

  • 简化 solo machine 的签名构造
  • 支持通用验证

​
负面

  • 会以非向后兼容的方式破坏现有签名构造
  • solo machine 必须更新以处理新格式
  • solo machine 的客户端状态和共识状态需要迁移

​
中性

无显著影响

​
参考

​
Changelog

  • 02-08-2022: Initial draft

​
Status

Accepted, applied in v7

​
Context

The 06-solomachine implementation up until ibc-go v7 constructed sign bytes using a DataType which described what type of data was being signed. This design decision arose from a misunderstanding of the security implications. It was noted that the proto definitions do not provide uniqueness which is a necessity for ensuring two signatures over different data types can never be the same. What was missed is that the uniqueness is not provided by the proto definition, but by the usage of the proto definition. The path provided by core IBC will be unique and is already encoded into the signature data. Thus two different paths with the same data values will encode differently which provides signature uniqueness. Furthermore, the current construction does not support the proposed changes in the spec repo to support Generic Verification functions. This is because in order to verify a new path, a new DataType must be added for that path.

​
Decision

Remove DataType and change the DataType in the SignBytes and SignatureAndData to be Path. The new Path field should be bytes. Remove all ...Data proto definitions except for HeaderData These ...Data definitions were created previously for each DataType. The proto version of the solo machine proto definitions should be bumped to v3. This removes an extra layer of complexity from signature construction and allows for support of generic verification.

​
Consequences

​
Positive

  • Simplification of solo machine signature construction
  • Support for generic verification

​
Negative

  • Breaks existing signature construction in a non-backwards compatible way
  • Solo machines must update to handle the new format
  • Migration required for solo machine client and consensus states

​
Neutral

No notable consequences

​
References