在Namada上使用IBC

Namada使用CometBFT共识引擎，这允许集成跨链区块链通信（IBC）系统的可能性

我们来谈谈 IBC

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

什么是IBC？

解释IBC的一个最佳类比是将区块链看作是各自主权的国家，而IBC则是一种共同语言。尽管每个国家都有自己的习惯、安全执行方式和能力，但这种共同语言可以让它们就一些共同信息达成协议。

在每个IBC连接的核心是三个基本实体：数据包、通道和端口。端口可以被看作是“我期望讨论的内容”，数据包是“我在说什么”，通道是“我打算如何表达”。在两个国家的情境中，"通信渠道"可以是使用共同的电子邮件协议、固定电话、普通邮件，或者每周一次的面对面会议，国家将规定通过这种通信方式发送多少通信，以及在什么时间发送。在这种情况下，端口将是谈话的主题，因此区块链将就另一侧的数据包"表示什么"达成协议。数据包将是交换的文字本身。

同样重要的是，这些区块链要“确认”一方是否已收到数据包，因为它们的状态现在互相依赖。此外，重要的是要知道发送的数据包是否以“有效”的方式创建，IBC通过密码学证明来检查此有效性。

这些IBC交易由一个称为“中继器”的参与者提交，并由账本验证，账本保持更新的“客户端”以表示其他链的状态。

IBC 如何在 Namada 上发挥作用？

心灵传动战斗规则

每当建立一个通道时，Namada区块链上都会预先构建一个轻量级客户端（后文将称之为“客户端”），该客户端跟踪区块链B需要的关于区块链B的重要信息，以便验证和执行通过通道发送的数据包。有关此信息的更多详细信息，请参考MsgUpdateClient

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

传递 Namada

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

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

在 Namada 上使用 IBC

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

Namada Multitoken

Namada上的所有可互换代币共享一个称为多代币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

需要注意的事项：

- 在这种情况下，源地址可以是原始链上的任何地址。它可以是存储在钱包中的地址的别名（在本例中是Albert），或者它可以是原始地址本身。但是，对于“接收地址”，它必须是在目标链上指定的原始地址。如果没有正确指定，资金可能会丢失。

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

一旦执行了此交易，就会发出CometBFT事件，并在存储中存储一个待处理的执行，中继器可以随时中继。此时，资金将从账户的源地址中扣除，但在成功中继事件的确认收到之前，扣除是不会最终确定的。

一旦中继器提供了具有链-B上已验证状态更改的相应证明的MsgAcknowledgement，Namada验证了它，状态更改就会在Namada上最终确定。如果没有中继器提供证明来确认链-B上的状态更改，状态更改将保持为待处理状态，直到Namada要么收到MsgTimeoutOnClose，要么收到MsgAcknowledgement。

请注意，无法关闭ICS20转账端口的IBC通道，因此其中的任何一个必须在某个时候发生。

什么是隐私操作呢？

那么，首先什么是"shielded action"（隐私操作）呢？

"Shielded action"是一种IBC操作，其中用户的资金起源于和/或最终存入隐私池。

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

备忘录字段是解决这个问题的重要部分，因为它可以允许目标地址是一个隐私地址，尽管最初接收资金的内部地址是一个透明账户，但它可以存在的唯一目的是将资金路由到备忘录部分指定的隐私地址。

结论

IBC是Namada提供区块链生态系统中用户的多链隐私解决方案的重要组成部分。没有它，用户将受限于与今天大多数（至少是基于零知识证明的）现有隐私解决方案类似的隔离隐私环境。

从这个意义上说，IBC可能是Namada最出色的特点，因为它将Namada从竞争性解决方案转变为协作性解决方案，可以与现有项目（如Osmosis、Cosmos Hub、Akash Network等）以及未来的项目（如Penumbra、DYDX等）进行互操作，甚至可能是Zcash，如果社区选择走这条路。

附录

“客户端”

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

1. ClientState

2. ConsensusState

ClientState

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

• chain-id

• latest_height- 最新区块高度

• trust_threshold- 来自另一条链上验证者的（加权）签名的一部分

• proof_specs- 指定中继者必须提供的证明结构，以便 Namada 认为任何 IBC 交易有效。Namada 符合ICS023 规范。这种技术性阻碍了拜占庭中继者恶意影响状态。通过这种方式，链间网络的安全性保持不变（尽管活性可能会受到影响，直到诚实的中继者介入并提供有效的证明）。

ConsensusState

• root_hash- 默克尔树根哈希

• next_validator_hash- 下一个纪元的验证器地址串联的哈希值

• timestamp- 最后一次更新的时间

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

握手

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

IBC 有效性谓词 (VP)

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

1. 伪执行验证。

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

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

• 附加了 B 链状态的有效向量承诺

• 消息有效（未超时）

• 发送消息的通道确实是开放的

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