​
变更记录

  • 28-01-2022：初始草案

​
状态

已接受

​
背景

在接收到一个 IBC 数据包后，IBC 应用可以选择性地返回一个确认。 该确认会被哈希并写入状态。因此，确认中所包含信息的任何变更都会破坏状态机兼容性。 ICS27 代表控制链执行交易。诸如消息结果或消息错误之类的信息，可能由 ICS27 模块无法控制的其他 SDK 模块返回。 如果能在 ICS27 确认中返回消息执行信息，将非常有价值，因为这样控制链的跨链账户认证模块就可以基于这些信息执行相应逻辑。 只有消息执行过程中返回的确定性信息才允许写入数据包确认，否则网络将因预期 app hash 分叉而停机。

​
决策

在撰写本文时，Tendermint 会在 ABCI.ResponseDeliverTx 中包含以下信息： 
// deterministicResponseDeliverTx strips non-deterministic fields from
// ResponseDeliverTx and returns another ResponseDeliverTx.
func deterministicResponseDeliverTx(response *abci.ResponseDeliverTx) *abci.ResponseDeliverTx {
  return &abci.ResponseDeliverTx{
    Code:      response.Code,
    Data:      response.Data,
    GasWanted: response.GasWanted,
    GasUsed:   response.GasUsed,
  }
}

​
成功确认

成功确认应返回有关交易执行的信息。 鉴于 abci.ResponseDeliverTx 中的字段具有确定性，可以使用交易 Data 来表示交易执行信息。 在交易执行成功时，abci.ResponseDeliverTx.Data 将被写入 ICS27 数据包确认中。 abci.ResponseDeliverTx.Data 的格式由 SDK 构造。 在撰写本文时，SDK 的下一个主要版本将更改交易响应数据的构造格式。

​
v0.45 格式

当前版本 v0.45 按如下方式构造交易响应： 
proto.Marshal(&sdk.TxMsgData{
  Data: []*sdk.MsgData{msgResponses...}, 
}
其中，msgResponses 是由 *sdk.MsgData 组成的切片。 MsgData.MsgType 包含正在执行的 sdk.Msg 的 sdk.MsgTypeURL。 MsgData.Data 包含对应已执行消息的 proto 编码 MsgResponse。

​
下一个主版本格式

下一个主版本将按如下方式构造交易响应： 
proto.Marshal(&sdk.TxMsgData{
  MsgResponses: []*codectypes.Any{msgResponses...}, 
}
其中，msgResponses 是打包进 Any 的一组 MsgResponse 切片。

​
前向兼容方案

前向兼容方案被认为不可行。 MsgServiceRouter 提供的 handler 只会包含 *sdk.Result 和一个错误（如果发生错误）。 在 SDK v0.45 中，*sdk.Result.Data 将包含经过编码的 MsgResponse 数据。 但是，MsgResponse 并未被打包并编码为 *codectypes.Any，因此从通用角度来看，不可能对这些字节进行反序列化。 如果这些字节可以被反序列化，那么就可以预先将其打包进 *codectypes.Any，以适配即将到来的新格式。 要在 MsgResponse 被编码之前拦截它，需要复制这段代码。 甚至可能根本无法复制所链接的代码，因为还需要以某种方式访问方法处理器。 基于这些原因，尝试采用前向兼容方案被认为不可行。 ICA 认证开发者可以通过检查 sdk.TxMsgData.Data 字段是否非空，来判断构造交易响应时使用了哪种格式。 如果 sdk.TxMsgData.Data 字段非空，则说明使用的是 v0.45 的格式；否则，ICA 认证开发者可以认为交易响应使用的是较新的格式。

​
决策

复用当前 SDK 版本提供的交易响应格式。 当 SDK 版本发生变化时，调整交易响应格式以使用更新后的交易响应格式。 在结果通道确认中包含交易响应字节。 已编写一个测试，如果 MsgResponse 不再被包含在共识中，该测试将失败。

​
错误确认

如上所述，abci.ResponseDeliverTx.Code 是确定性的。 当交易执行出错时，应返回包含 abci code 的错误确认。 已编写一个测试，如果 ABCI code 不再具有确定性，该测试将失败。

​
影响

本节描述应用该决策后的影响。所有影响都应在此汇总，而不仅仅是“正面”影响。

​
正面

  • 跨链账户认证模块可以基于交易结果执行相应逻辑，而无需依赖查询模块
  • 交易结果与执行普通 SDK 消息时返回的结果保持一致。

​
负面

  • 该决策的安全性假设依赖于 Tendermint 创建的 ResponseDeliverTx 哈希中包含 ABCI 错误码和 Msg response
  • 事件是非确定性的，不能包含在数据包确认中

​
中性

没有中性影响。

​
Changelog

  • 28-01-2022: Initial Draft

​
Status

Accepted

​
Context

Upon receiving an IBC packet, an IBC application can optionally return an acknowledgement. This acknowledgement will be hashed and written into state. Thus any changes to the information included in an acknowledgement are state machine breaking. ICS27 executes transactions on behalf of a controller chain. Information such as the message result or message error may be returned from other SDK modules outside the control of the ICS27 module. It might be very valuable to return message execution information inside the ICS27 acknowledgement so that controller chain interchain account auth modules can act upon this information. Only deterministic information returned from the message execution is allowed to be returned in the packet acknowledgement otherwise the network will halt due to a fork in the expected app hash.

​
Decision

At the time of this writing, Tendermint includes the following information in the ABCI.ResponseDeliverTx: 
// deterministicResponseDeliverTx strips non-deterministic fields from
// ResponseDeliverTx and returns another ResponseDeliverTx.
func deterministicResponseDeliverTx(response *abci.ResponseDeliverTx) *abci.ResponseDeliverTx {
  return &abci.ResponseDeliverTx{
    Code:      response.Code,
    Data:      response.Data,
    GasWanted: response.GasWanted,
    GasUsed:   response.GasUsed,
  }
}

​
Successful acknowledgements

Successful acknowledgements should return information about the transaction execution. Given the deterministic fields in the abci.ResponseDeliverTx, the transaction Data can be used to indicate information about the transaction execution. The abci.ResponseDeliverTx.Data will be set in the ICS27 packet acknowledgement upon successful transaction execution. The format for the abci.ResponseDeliverTx.Data is constructed by the SDK. At the time of this writing, the next major release of the SDK will change the format for constructing the transaction response data.

​
v0.45 format

The current version, v0.45 constructs the transaction response as follows: 
proto.Marshal(&sdk.TxMsgData{
  Data: []*sdk.MsgData{msgResponses...}, 
}
Where msgResponses is a slice of *sdk.MsgData. The MsgData.MsgType contains the sdk.MsgTypeURL of the sdk.Msg being executed. The MsgData.Data contains the proto marshaled MsgResponse for the associated message executed.

​
Next major version format

The next major version will construct the transaction response as follows: 
proto.Marshal(&sdk.TxMsgData{
  MsgResponses: []*codectypes.Any{msgResponses...}, 
}
Where msgResponses is a slice of the MsgResponses packed into Anys.

​
Forwards compatible approach

A forwards compatible approach was deemed infeasible. The handler provided by the MsgServiceRouter will only include the *sdk.Result and an error (if one occurred). In v0.45 of the SDK, the *sdk.Result.Data will contain the MsgResponse marshaled data. However, the MsgResponse is not packed and marshaled as a *codectypes.Any, thus making it impossible from a generalized point of view to unmarshal the bytes. If the bytes could be unmarshaled, then they could be packed into an *codectypes.Any in anticipation of the upcoming format. Intercepting the MsgResponse before it becomes marshaled requires replicating this code. It may not even be possible to replicate the linked code. The method handler would need to be accessed somehow. For these reasons it is deemed infeasible to attempt a forwards compatible approach. ICA auth developers can interpret which format was used when constructing the transaction response by checking if the sdk.TxMsgData.Data field is non-empty. If the sdk.TxMsgData.Data field is not empty then the format for v0.45 was used, otherwise ICA auth developers can assume the transaction response uses the newer format.

​
Decision

Replicate the transaction response format as provided by the current SDK version. When the SDK version changes, adjust the transaction response format to use the updated transaction response format. Include the transaction response bytes in the result channel acknowledgement. A test has been written to fail if the MsgResponse is no longer included in consensus.

​
Error acknowledgements

As indicated above, the abci.ResponseDeliverTx.Code is deterministic. Upon transaction execution errors, an error acknowledgement should be returned including the abci code. A test has been written to fail if the ABCI code is no longer deterministic.

​
Consequences

This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the “positive” ones.

​
Positive

  • interchain account auth modules can act upon transaction results without requiring a query module
  • transaction results align with those returned by execution of a normal SDK message.

​
Negative

  • the security assumptions of this decision rest on the inclusion of the ABCI error code and the Msg response in the ResponseDeliverTx hash created by Tendermint
  • events are non-deterministic and cannot be included in the packet acknowledgement

​
Neutral

No neutral consequences.