这两天看Ontology公布了自己的MultiChain TestNet，附了一篇文章介绍了这个多链的设计架构，于是就决定读一读，顺便梳理一下自己对跨链交易的认知。对于一些对跨链协议早有研究的读者而言，这里的技术内容会稍嫌不足，有兴趣更深入的朋友可以到他们GitHub去看原文（or程式码），或是用它们的Sample Code玩玩看真正跨链的交易。

Ontology. Source: UTB

对于为什么需要开发跨链协议有诸多出发点，对于单个区块链项目而言，它可以做到大幅度的扩容，像我们常常听到的ETH Plasma 扩容，也可以是为了支援多个不同区块链的沟通，如旨在打造区块链生态系的Cosmos。Ontology的设计中，也跟这些项目有许多相似之处。

Ontology Multichain Architecture

Ontology的多链架构包含了ONT主链(main net)以及其他侧链(side chain)，侧链必须要透过注册才能与主链连接。在一个完整跨链交易中，一共有五个角色共同维系其运作：

Multi-chain Management Contract:多链管理合约，这是一个主链上的合约，负责管理Side Chain的注册，抵押(Staking)以及其ONG fund pool。
Block Header Synchronization Contract : Block Header同步合约，负责同步重要的Block Header (后面称这些区块为key blocks)，用以确认其他链上的交易资讯。侧链之间并不会直接进行同步，所有侧链都只会接收主链来的Block Header。主链以及每一个侧链上都会有一个同步合约。
Cross-chain Management Contract :跨链管理合约。对于每一条链上的其他合约而言，当需要做到跨链交易时，只要跟自己链上的跨链管理合约沟通就可以了，剩下的事情会由这个合约完成。
ONG & ONGx Contract :主链上负责ONG资产管理的称为ONG Contract，而其他每条侧链上也会有负责管理帐户ONG资产的合约，为了不与主链混淆，称为ONGx Contract，负责管理主链与侧链之间ONG的转移，包括lock/unlock，侧链Mining Fee支付等等。
Relayer :这里的Relayer不是一个合约，而是一个不断监听不同链上Event，并且负责在不同链上触发key block header同步以及跨链交易的系统。我们都知道区块链的天性之一就是只认链上的事实，对于其他链发生了什么交易，智能合约是无法主动得知的。因此在设计当中必须要有这么一个Relayer的角色来当作沟通的桥梁。

Ontology Multichain Design

从上图中我们可以看到，在一条链中，基本上是由Cross-chain Management Contract作为管理所有跨链行为的核心。Relayer则不属于链上范畴，但却是唯一跟其他链沟通的管道。

Life Cycle Management

看完了基本成员之后，我们再来看看Side Chain的Life Cycle。

侧链的注册 Side-Chain Registration
要如何在ONG主链上注册成为一个合格的侧链呢？首先要呼叫主链上的Multi-chain管理合约，告知侧链的基本讯息、Validator名单等等，接着合约就会检查所有Validator是不是有符合规定抵押了足够的ONG(Stake)在主链上。抵押的意义就类似ETH Casper，是用以制衡恶意Validator的一个手段，若是做了什么坏事，主链上的ONG就会被拿走作为惩罚。最后，会依照侧链Stake的数量，分配一个Fund Pool，用来让使用者进行资产转移。Fund Pool的初始余额也就是侧链上ONGx初始的余额。
跨链资产转移 Cross-Chain Asset Exchange
侧链注册完成后，使用者就可以藉由将ONG锁(lock)至主链Fund Pool，到侧链上去领取ONGx。要注意的是，每条侧链的Fund pool都会有个上限，也就是不能大于现在所有Validator Stake的数量，因为如果Fund Pool大于Stake总数，表示Validator可以使坏移走fund pool所有的钱，即使被惩罚没收所有的Stake仍然赚钱。因此Fund Pool若达到上限，就需要Validator抵押更多的主链ONG。

Cross-Chain Asset Exchange

最后，当一个Side Chain想要收工不干了，也可以透过向主链的管理合约申请Log out，主链管理合约则会保证有一段时间，让所有侧链上的使用者将其上资产转回主链。

Block Header Synchronization

介绍完了侧链的产生以及主链到侧链的资产转移，我们终于可以进入重点，了解一下一个跨链交易要怎么进行了。

在一笔跨链交易中，最重要的元素就是验证其他链的状态。当A链发起一比跨链交易给B时，B链要有办法确认这个交易的合法性。我们都知道Block Header中储存了某个区块高度时整个区块链的讯息，藉由同步部分的Block Header，我们可以验证来自其他链的交易合法性。但是区块这么多，哪些区块需要同步成了重要的问题。

在Ontology的VBFT共识演算法当中，区块的产生是由一个Validator Set中的候选人轮流产生，每经过一段时间(Epoch)才会更换Validator Set。Validator Set对于区块头的验证非常重要，因此这些更换Validator Set的区块— Epoch Switch Blocks，后面称为Key Blocks，必需要同步到侧链的同步合约当中。

除了Key Block之外，我们只要再同步所有「包含跨链交易的区块」，就可以保证侧链拥有所有需要用来验证的讯息了。至于怎么同步，是由Relayer在监听到Key Block或是有跨链交易的区块时，主动帮忙提交至主链，所以会有手续费付给Relayer。

Key Block Header Synchronization

我们可以从上图看出，每隔一个Epoch，就一定会有一个Key Block的同步。若是主链上在超过一个Epoch没有收到Key Block同步，则与侧链的连线就会终止。

在一个链的同步合约成功获得同步的Block Header后，其他的所有智能合约都可以来同步合约中存取最新的Header资讯，以便对各自收到的Contract Call做验证。

Cross-Chain Interaction

所有需要跨链的交易，都只需要透过呼叫自己链上的跨链管理合约 (Cross-Chain Management Contract)来完成，由Relayer送至目标链后，也会由该链上的跨链管理合约来负责呼叫其他合约。这边我们先来看看Main Chain — Side Chain的跨链交易流程。

Zilliqa的原理与创新

Zilliqa是一个好像始终没什么名气的专案。这几天抽空读完了它的白皮书，其实已经是一年前的产物了，但里面有许多的想法我觉得非常有趣，就来跟大家简介一下Zilliqa的运行逻辑

在某一个合约呼叫自己链上的跨链管理合约后，跨链管理合约会Assign给这笔交易一个交易ID，并且把该笔交易存到Merkle Tree (State Root Hash)中，让下一个区块Header附上。同时呼叫者需要burn/lock一定的ONG作为支付Relayer传送讯息的手续费。
Relayer的职责就是监听这些跨链交易，当一笔跨链交易发生时，Relayer需要同步两边的Block Header同步合约(同步发生跨链交易的区块)，同时将交易附上Merkle Proof，提交至目标链的跨链管理合约。
在目标链的跨链管理合约收到交易讯息后，它会先透过Block Header同步合约取得来源链的Block Header，与Merkle Proof进行验证该交易合法性后，才会呼叫链上对应的智能合约进行后续动作。
成功执行完成后，Relayer可以拿到手续费，根据不同的交易方向可能是于主链上收到ONG，也可能是由侧链的ONGx合约发放。值得注意的是，Relayer在进行跨链的交易提交以及同步时，实际上都是去呼叫智能合约，因此是需要手续费的。跨链交易的手续费就是用来涵盖Relayer的成本，同时给予Incentive让它继续运作。
如果是主链呼叫侧链的例子，手续费的支付流程则会如下图所示：呼叫者于主链上锁住ONG，侧链则会在成功执行后释放ONGx给Relayer。反之则会是在侧链上burn ONGx，主链上由Fund Pool释出。

若是侧链与侧链的跨链交易，会跟主链-侧链的交易模式有两大不同：第一是关于Block Header的同步方式，由于侧链与侧链之间不会直接的同步Block Header，因此唯一的改变就是两个侧链需分别将Block Header与主链的同步合约同步，再由主链那边获取对方Block Header讯息。要注意，需要通过主链的只有Block Header的同步资讯，如果Relayer监听到跨链交易，还是会直接提交交易到目标链上的跨链管理合约。唯独验证时所需要的Block Header需要从主链获取。

第二个不同点则是Mining Fee的收取，侧链至侧链的交易手续费将会在同一条链上完成：若有一笔由侧链A至侧链B的交易，发起者会lock 侧链A上的ONGx，Relayer完成交易之后则会提交B链完成的证明，并unlock 侧链A上对应的ONGx做为手续费。这么一来，就不用牵扯到复杂的Main Chain Fund Pool 资产转移。

Relayer

我们最后再来整理一下这个Relayer的角色。Relayer的工作一共有两个，一个是进行主链-侧链的Block Header同步，另一个则是负责监听并提交跨链交易。Block Header同步的部分是没有手续费的，而且就算没有跨链交易发生，上面有提过被称为「key block」的重要区块还是要不断的由Relayer进行同步。因此若是侧链与主链的交易很不频繁，没有人支付跨链交易的手续费的话，Relayer就会一直亏钱啰。

Malicious Acts

接近最后，我们要来了解一下Ontology对于多链协议常见的问题，提出了哪些解决办法。所有多链的Protocol都会面临一样的问题：侧链的Validator可以随时使坏。从主链上来看，这个侧链的所有资产都由侧链的Validators管理，当一个侧链上的总资产大于抵押的Stack 数量时，Validator就有充分的利益动机卷款而逃。

Malicious State Root

使坏的方法就是制造假的State Root。State Root代表了整个侧链的现况，也纪录了每个帐户的余额等等资料，通常在每一个Block中都会要求带上这个State Root，以便验证大家对于交易完成后的区块链状态(State )达成共识，Validator也需要对State Root进行签名。但在侧链Validator Set决定做坏事的情境下，他们有十足的权力改写State Root进行获利。

Ontology目前提出的解决方法是透过设计一段challenge period，让所有发现State Root被窜改或是主链/侧链Header不同的Relayer或是其他使用者，可以透过到主链「告状」的方式，来举报不合法的Validator。告状的流程大概就是提供恶意区块前一个State Root，交易内容，以及证明正确State Root执行结果后与Validator提交不相符。

当然了，这样的设计方式相对简单，但也就需要增加系统外的复杂度来进行监控。实际运作上，这些监控者的存在就等于变相的要求更多的人一起验证每一个侧链产生的每个区块，这又回到了最初的问题，透过Side Chain分散流量很重要的一点就是提高效率，因此Validator Set降低是必然的，若是在这种情况下又要求等同原先的去中心化程度，确实有点矛盾。因此对于恶意侧链Validators，Ontology也在文件中写到，还在研发更好的应对方法。

小结

这篇文件中没有提到太多的技术细节，只有比较笼统的架构。在我看来最重要的就是对于Block Header Synchronization Contract以及Cross-Chain Management Contract的分工，个人觉得清楚明了好理解。这里附上一张官方比较图，让各位欣赏一下Ontology的优点。

在文件的Future Work中也有提到几点未来的开发方向，我这里就一并分享：

Multi-Layer Architecture

除了上述的恶意侧链解决方法外，有另一个比较大的问题在于目前架构仅有一条主链以及多条侧链。这样的架构所能达到的拓展性是有限的，所以未来我们可以持续期待Ontology提出Multi-Layer的架构。

Non-Finality Blockchain

在与目前现有其他区块链的衔接上，Ontology的作法只适用于有Finality特性的区块链，就是宁可出不了块也不存在分叉的区块链，例如NEO。而对于现在势力最大的Etheruum与Bitcoin这些都常存在分叉的公链而言，Ontology并没有提出跨链的验证方法。因此我是以类似ETH Plasma扩容的角度来看待Ontology提出的跨链方案，包括一个拓展性的结构以及部分的侧链客制化，而不是以「连接所有区块链」为其主要目的。