Celo Optics Bridge 代码解析

Posted 2022-02-27 mutourend

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Celo Optics Bridge 代码解析相关的知识，希望对你有一定的参考价值。

1. 引言

Celo系列博客有：

前序博客有：

Optics Bridge：Celo ＜-＞以太坊

Optics Bridge开源代码见：

https://github.com/celo-org/optics-monorepo（Rust & Solidity等）

Optics中：

以Solidity语言实现了链上合约
以Rust语言实现了链下系统agents

未来将针对NEAR和Solana实现Rust版本的链上合约。

Optics Bridge当前已部署在Celo、以太坊和Polygon主网上。
Celo、以太坊、Polygon主网上的Home及其它核心合约地址见 https://github.com/celo-org/optics-monorepo/tree/main/rust/config/mainnet。

Optics会在链之间建立communication channels，但是这些channels由xApp（又名“cross-chain applications”） developers来使用。
在 https://github.com/celo-org/optics-monorepo 提供了标准的模式来集成Optics channels，来确保communication是安全的。

集成过程中，需要以下关键要素：

1）已部署在链上的一个Home合约和任意多个Replica合约。这些合约管理Optics communication channels，可由xApp用于send and receive messages。
2）XAppConnectionManager合约：将xApp连接到Optics，允许xApp admin 注册新的Home和Replica合约。对channel进行注册和取消注册是确保xApp正确处理消息的主要方法。xApp可部署自己的connection manager，或者与其它xApps共享connection manager。
3）Message库：Optics在链之间发送的是raw byte arrays。xApp必须定义一种message specification，使得发送时可serialized，在remote chain上进行处理时可deserialized。
4）Router合约：Router合约会在Optics cross-chain message format 与本地链合约调用之间进行转换。Router合约中同时实现了xApp的business logic。Router合约：
- 公开了面向用户的接口
- 处理来自其它链的messages
- 派发将要送到其它链的messages

Solidity开发者若有兴趣实现自己的Message库和Router合约，可参看optics-xapps中的例子。

当前测试网的部署配置可参看rust/config/目录。

强烈建议xApp admins运行一个watcher进程来维护其XAppConnectionManager合约并 guard from fraud。

1.1 Optics关键点

Optics系统sketch为：

1）A “home” chain commits messages in a merkle tree
2）A bonded “updater” attests to the commitment
3）The home chain ensures the attestation is accurate, and slashes if not
4）Attested updates are relayed on any number of “replica” chains, after a time delay

结果通常为二者之一：

1）All replicas have a valid commitment to messages from the home chain。
2）Failure was published before processing, and the updater can be slashed on the home chain。

尽管Optics的安全保证要弱于header-chain validation，但是，可满足大多数应用场景的要求。

Optics为一种新策略，可在不validate header的情况下，进行跨链通讯。
Optics的目标是：

创建a single short piece of state（为32字节hash），并定期更新该state。

该hash值对应为a merkle tree root，在该merkle tree中包含了a set of cross-chain messages being sent by a single chain（在Optics系统中对应为“home” chain）。home chain上的合约可提交messages，这些messages会被放入a merkle tree（可称为“message tree”）。该message tree的root可传送到任意数量的"replica" chains。

相比于对该commitment进行validity prove，Optics选择了put a delay on message receipt，以保证failures are publicly visible。这样可保证协议的参与者有机会在产生实际伤害之前，对failure进行响应。也就是说，相比于阻止the inclusion of bad messages，Optics可确保message recipients可感知该inclusion，并由机会拒绝对bad message进行处理。

为此，home chain中会指定a single “updater”。该updater需质押bond以确保其good behavior。该updater负责为new message tree root生成signed attestation，以确保其为a previous attestation的extend，同时包含了a valid new root of the message set。这些signed attestation会被发送到每个replica。

Replica：会accept an update attestation signed by the updater，并将其放入pending state。当挑战期过后，Replica会接收该attestation中的update，并存储a new local root。由于该root中包含了a commitment of all messages sent by the home chain，因此，这些messages可be proven (using the replica’s root)，然后派发到replica chain上的合约。

为new update设置挑战期主要有2个目的：

1）可保证updater的任何misbehavior都可在message被处理之前公开。This guarantees that data necessary for home chain slashing is available for all faults.
2）使得message recipients可选择不对update中的message进行处理。 If an incorrect update is published, recipients always have the information necessary to take defensive measures before any messages can be processed.