Namada上的IBC

Namada 使用 CometBFT 共识引擎，可以集成区块链链间通信（IBC）系统。

本文翻译自官方博客，请以官方原文为准。

本文旨在做两件事：
1. 介绍 IBC
2. 解释如何将 IBC 与 Namada 一起使用

什么是IBC？

我听过的解释 IBC 的最好比喻就是将区块链视为自己的主权国家，将 IBC 视为一种共同语言。尽管每个国家都有自己的海关、安全执法和能力，但共同语言可以让两国就一些共同信息达成一致。

每个 IBC连接的核心在于三个基本实体：数据包、通道和端口。端口可以​​被认为是“我期望谈论什么”，数据包可以被认为是“我要说什么”，通道可以被认为是“我将如何说它”。在两个国家/地区的情况下，“沟通渠道”可能是使用通用电子邮件协议、固定电话、蜗牛邮件或每周一次的面对面会议，并且各国将指定通过电子邮件发送多少通信量这种沟通方式以及在什么时间进行。在这种情况下，端口将成为对话的主题，因此区块链将就另一端的数据包“意味着什么”达成一致。数据包将是正在交换的字面意思。

同样重要的是，这些区块链“acknowledge”一侧何时收到数据包，因为它们的状态现在相互依赖。此外，重要的是要知道发送的数据包是以“有效”方式创建的，并且 IBC 通过加密证明检查这种有效性。

这些 IBC 交易由称为“中继者（relayer）”的参与者提交，并由ledger进行验证，ledger保留更新的“client”来代表另一条链的状态。

IBC 如何在 Namada 上发挥作用？

Telekinetic Battles rule

每当建立通道时，就会在 Namada 区块链上（预先）构建一个轻客户端（以下称为“客户端”），用于跟踪区块链所需的有关区块链 B 的重要信息，以便验证和执行数据包通过通道发送的。有关这方面的更多信息，请参阅MsgUpdateClient参考资料。

技术细节在附录中进行了解释。

在Namada上中继

为了运行中继器(relayer)，涉及打开通道、启动握手和更新“客户端”，建议使用Hermes的 Heliax 分叉，它是 IBC 中继器的 Rust 实现（由 InformalSystems 开发）。

您还可以在这里找到 Hermes 官方文档。

在Namada使用 IBC

这些技术细节对于理解幕后发生的事情非常有用，但用户究竟如何在 Namada 上进行此类交易呢？

Namada Multitoken

Namada 上的所有可互换代币共享一个单一的有效性断言（VP），称为 Multitoken VP。然而，Namada 上的存储区分了 IBC 资产和非 IBC 资产。IBC 资产是可互换的，但仅限于它们来源的链和端口内。这为本来看似可互换的资产提供了故障隔离。

在Namada进行IBC转账

ibc 转账

现在我们已经介绍了基础知识，现在是时候深入了解用户如何继续进行首次 IBC 转账了。

Namada 客户端( `namadac` ）实现了函数 `ibc-transfer` ，该函数适当地执行 IBC 转移信息。函数的参数在下面的示例函数中列出：

namadac ibc-transfer \
--token NAM \
--amount 100 \
--source albert \
--receiver atest1d9khqw36g56nqwpkgezrvvejg3p5xv2z8y6nydehxprygvp5g4znj3phxfpyv3pcgcunws2x0wwa76 \
--signing-keys albert \
--channel-id channel-0 \
--node 127.0.0.1:27657

需要注意的是：本例中
的source是来源链上的任意地址。这可以是存储在钱包中的地址的别名（在本例中为 Albert），也可以是原始地址本身。但是，对于“receiver”，它需要是目标链上指定的原始地址。如果未正确指定，资金可能会丢失。

这channel-id将对应于中继器在过去某个时刻已经建立的通道 ID。参数node指定来源链节点的IP地址和端口。当使用相同的 Namada 客户端与两个不同的链交互时，这特别有用。

一旦执行该交易，就会发出 CometBFT 事件，并且在链上的存储中存储了一个待执行的操作，随时可以由中继者转发。此时，原链账户的余额将被扣除，但是扣除操作直到链上收到事件成功转发的确认后才最终确定。

一旦中继者提供了一个 `MsgAcknowledgement` 及其相应的链-B上已验证状态变更的证明，并且 Namada 对其进行了验证，Namada 上的状态变更就被最终确定。如果没有中继者提供确认链-B上状态变更的证明，那么状态变更就会保持在待处理状态，直到 Namada 收到 `MsgTimeoutOnClose` 或 `MsgAcknowledgement` 为止。

请注意，ICS20 端口转账的 IBC 通道不能关闭，因此上述两种情况中的任何一种最终都必须发生。

屏蔽操作呢？

那么，首先什么是屏蔽操作？

屏蔽操作是一种 IBC 操作，其中用户的资金源自和/或最终进入屏蔽池。

对于特定的链，例如 Osmosis，将为此目的设置一个特定的端口，该端口调用每个链上的适当函数，并且就可以通过通道发送哪些数据包和数据达成一致，并最终成为有效的 IBC 操作。

memo字段是实现这一点的关键部分，因为它可以允许目标地址成为屏蔽地址，尽管最初接收资金的内部地址是透明帐户，但它可以为了负责将资金路由到本memo中指定的屏蔽地址单独存在。

结论

IBC 是 Namada 为整个区块链生态系统的用户提供多链隐私解决方案的使命的重要组成部分。如果没有它，用户将被限制在一个孤立的隐私环境中，类似于当今大多数（至少基于零知识证明的）现有隐私解决方案。

从这个意义上说，IBC 可以说成为 Namada 最大的功能，因为它将 Namada 从另一种竞争解决方案转变为合作解决方案，可以与 Osmosis、Cosmos Hub、Akash Network 等现有项目以及 Penumbra 等未来项目进行互操作、DYDX，甚至 Zcash，如果社区选择走这条路的话。

附录

“The Client”

Namada 上的 IBC 客户端由 2 部分组成：

1. ClientState
2. ConsensusState

ClientState

存储ClientState有关其他链的信息，包括但不限于：

• chain-id
• latest_height- 最新区块高度
• trust_threshold- 来自另一条链上验证者的（加权）签名的一部分
• proof_specs- 指定中继者必须提供的证明结构，以便 Namada 认为任何 IBC 交易有效。Namada 符合ICS023 规范。这种技术性细节阻碍了拜占庭中继者恶意影响状态。通过这种方式，Interchain的安全性保持不变（尽管活性可能会受到影响，直到诚实的中继者介入并提供有效的证明）。

ConsensusState

• root_hash- 默克尔树根哈希
• next_validator_hash- 下一个纪元的验证者地址串联的哈希值
• timestamp- 最后一次更新的时间

这些字段的值会随着每笔 IBC 交易而更新，并且每笔此类交易均由中继者提交（并支付）。

握手

为了建立连接，Namada 和 Chain B 之间进行 4 次握手，这建立了客户端并确保就通用语言达成一致。Namada 的握手程序的实施符合 ICS 3 和 ICS 4中指定的定义。

IBC 有效性断言 (VP)

IBC 有效性断言的存在是为了验证 Namada 上任何与 IBC 相关的状态执行。
IBC 有效性断言主要验证两件事：

1. 伪执行验证。

在伪环境中（不以任何方式更改真实存储），会检查执行情况，以便结果状态更改与 IBC tx 一致。一个重要的区别是，此步骤不会以任何其他方式检查 IBC 相关数据的有效性。当链上允许任意 WASM 执行且没有白名单时，这一检查主要是必需的。

2. 验证 IBC tx 是否以有效方式提供。这包括：

• 附加了 B 链状态的有效向量承诺
• 消息有效（未超时）
• 发送消息的通道确实是开放的

正如本文前面提到的，Namada 上的 IBC VP 保证了 IBC 交易的安全。