# ZetaChain:跨链赛道的黑马？

By [0xlukema](https://paragraph.com/@lukema95) · 2023-10-31

---

介绍
==

`ZetaChain` 是一个基于`Cosmos-SDK`开发Layer1公链项目，其主要目标是提供跨链互操作性，其最大特点是不仅支持智能合约链的跨链，更支持BTC等非智能合约链的资产跨链。

如今公链赛道越来越繁荣，不仅是通用的公链，像链游专用链以及近年来火热的Layer2等公链更是如雨后春笋般涌现，随着公链的增加，用户资产会变得更加割裂，这就需要一种方法来将资产方便的在各个公链间快速流转以此来提高资金的利用率，资产跨链便成了刚需，于是便出现个各种跨链桥。但是近年来跨链桥却成了黑客的提款机，屡屡有出现跨链桥被黑的事件，其中不乏有涉及数亿美金损失的案件。同时BTC作为区块链行业的指标，由于其不支持智能合约，而大多数跨链桥核心是基于合约设计的，所以一直无法支持BTC跨链。ZetaChain 的出现，给上述问题提供了一个解决的方案。

目前ZetaChain已经支持Bitcoin，Ethereum，BSC和Polygon链，除了比特币，后三个都是EVM兼容链，可以部署Solidity合约。

整体架构
====

`ZetaChain`是基于`Cosmos-SDK`进行进行开发的，`Cosmos-SDK`是一个模块化的区块链开发框架，其典型架构如下图所示。最上面部分为用户自定义的模块，例如EVM模块。中间层为共识模块，负责对交易达成共识以及区块处理；最下面一层为网络层，用于各个节点之间的网络通信。当交易通过网络层到达共识层，共识层根据不同的交易类型将交易路由到对应的模块进行处理，模块处理完成后将结果返回给共识层，共识层和应用层之间通过ABCI接口进行通信。举个不太恰当的例子方便理解，底下的共识层和网络层可以类比成操作系统，应用层类比成操作系统上安装的应用。这样，特定应用链只要在应用层上进行拓展，增加对应的应用(或者说模块)来完成特定的功能。

![ 图片来源：Cosmos-SDK文档](https://storage.googleapis.com/papyrus_images/03b708a4d062a14767ef23e18574dc12f95649d0fcec9273af6bfe9c217400bf.png)

图片来源：Cosmos-SDK文档

`ZetaChain` 在`Cosmos-SDK`的基础上在其应用层增加了四个模块用来拓展其功能，分别是`crosschain`，`emissions`，`fungible`和`observer`模块。其中`crosschain`是核心模块，主要实现跨链的核心逻辑。`emissions`模块负责协调观察者、验证者和TSS签名者的奖励分配。`fungible`负责提供同质化代币的功能以及提供EVM的操作入口。`observer`模块追踪和处理入站、出站交易等。这个部分下面会具体介绍。

`ZetaChain`的验证者节点 Validator 由两个主要组件组成：`ZetaCore` 和 `ZetaClient`。这两个组件可以分别运行，`ZetaCore` 是上述描述的`Cosmos-SDK` 的拓展，则生成区块并维护复制状态机。`ZetaClient` 是客户端节点，其主要有由`Observer`和`TSS Signer`两个服务组成，前者主要用于观察外部链和ZetaChain的交易信息，后者主要用于对出入站交易和外部链交易进行签名。

`ZetaCore` 和 `ZetaClient` 被捆绑在一起，由节点运营方运行。只要质押足够的资金，任何人都可以成为节点运营方来参与验证。

![图片来源：ZetaChain](https://storage.googleapis.com/papyrus_images/9d05de0a3f8d3bae9dc5e690104a68010219573b90a0d9c23a08d8fc3bbc87d5.png)

图片来源：ZetaChain

Validator 由三种不同的角色组成，分别是Basic Validators, Observers, and TSS signer。

*   Basic Validators - 使用Tendermint共识协议，这是一种部分同步的拜占庭容错(BFT)共识算法。每个验证者节点都可以对区块提案进行投票，其投票权与绑定/委托的质押币(ZETA)成正比。每个验证者节点由其共识公钥标识。验证者需要一直在线，准备好参与不断增长的区块生产。作为服务的交换，验证者将获得区块奖励和交易费。
    
*   Observers - 通过外部链的完整节点观察外部连接链在特定地址的某些相关交易/事件/状态。观察者将分为两个角色：排序者和验证者。序列器发现相关的外部事务/事件/状态并向验证者报告；验证者对ZetaChain进行验证和投票以达成共识。该系统至少需要一个序列器和多个验证器。
    
*   TSS(Threshold Signature Scheme) signer - ZetaChain共同持有标准的ECDSA/EdDSA密钥，用于与外部链进行身份验证交互。密钥在多个签名者之间分发，这样只有超级多数签名者才能代表ZetaChain签名。重要的是要确保任何时候都没有任何单个实体或一小部分节点能够代表ZetaChain在外部链上签署消息。ZetaChain系统使用担保质押和正/负激励来确保经济安全。
    

Observer通过不停的监控外部链的ZETA代币的销毁、铸造、特定的消息以及智能合约的调用等事件，例如当其观察到一笔跨链转账交易时，会构造一笔入站消息`MsgVoteOnObservedInboundTx` ，该交易包含源链、目标链、发送者、接受者以及金额等字段；然后通过TSS signer签名后发往ZetaChain；ZetaChain 中的Observer对到来的`MsgVoteOnObservedInboundTx`进行校验并投票；投票通过后会生成一个跨链交易CCTX；外部Observer通过观察到ZetaChain 中生成的CCTX，根据CCTX中的参数，TSS signer构造目标链的交易(例如转账交易)签名后发往目标链，并记录下该交易的txID；Observer按时查询目标链上的txID，如果该交易已被目标链确认且状态为成功则会构造一笔出站交易`MsgVoteOnObservedOutboundTx` ，交易包含目标链的交易哈希等字段，交易通过TSS signer签名后发往ZetaChain网络；同样这笔出站交易需要Observer进行投票，投票通过后即被标记为交易成功，即完成了一笔跨链交易。

模块介绍
====

前面说过，ZetaChain在Cosmos-SDK的基础和原有模块的基础上添加了`crosschain`，`emissions`，`fungible`和`observer`四个模块。下面主要介绍各个模块主要的功能。

crosschain
----------

`crosschain`模块跟踪入站和出站跨链事务(CCTX)，与`crosschain`模块交互的主要参与者是观察者验证器。观察者运行一个链下程序(称为`zetaclient`)，该程序监视连接的区块链上的入站交易，监视ZetaChain上的待处理的出站交易，并监视连接的链上的出站交易。在观察入站或出站事务之后，观察者参与投票过程。将选票移动到“finalized”状态的最后一次投票触发执行并支付跨链交易的gas成本。

### Inbound Transaction(入站事务)

入站事务是在连接链上观察到的跨链事务，比如一个连接链上的账户与该链上的跨链合约交互并发且了一笔跨链交易，Observer通过事件观察到这笔交易在连接链上已经被确认之后，会通过TSS Signer构造入站消息`MsgVoteOnObservedInboundTx` ，并且广播到ZetaChain，并且由ZetaChain上的Observer校验消息内容后进行投票。其中`MsgVoteOnObservedInboundTx` 的结构如下：

    message MsgVoteOnObservedInboundTx {
        string creator = 1;                // 消息创建者，即Observer
        string sender = 2;                 // 交易发起者，即连接链上的账户或者合约地址
        int64 sender_chain_id = 3;         // 发起跨链交易的链的ID
        string receiver = 4;               // 跨链交易的接受者，可以是合约/账户地址
        int64 receiver_chain = 5;          // 目标链
        string amount = 6;                 // 转账数量
        string message = 8;                // 跨链消息
        string in_tx_hash = 9;             // 发起链发起的交易ID
        uint64 in_block_height = 10;       // 发起链的该交易的区块高度
        uint64 gas_limit = 11;             // Gas限制
        common.CoinType coin_type = 12;    // 代币类型，目前包括Zeta, Gas, ERC20和Cmd四种
        string tx_origin = 13;
        string asset = 14;
    }  
    

如果跨链交易的目的链是ZetaChain，并且CCTX不包含消息，则ZRC20代币将存入ZetaChain上的帐户。

如果跨链交易的目标链是ZetaChain，并且CCTX包含消息，则ZRC20代币被存入ZetaChain，并调用ZetaChain上的合约。消息中包含合约地址和合约调用的参数。

如果跨链交易的目的链不是ZetaChain，则事务的状态更改为“待定出站”(pending outbound)，并将CCTX作为出站事务进行处理。

### Outbound **Transaction(出站事务)**

与上面的入站事务相反，观察者通过观察跨链交易在目标链上完成之后，由TSS Signer构造出站消息`VoteOnObservedOutboundTx` 并发往ZetaChain，并且由ZetaChain上的Observer校验消息内容后进行投票。`VoteOnObservedOutboundTx` 的结构如下：

    message MsgVoteOnObservedOutboundTx {
        string creator = 1;                               // 消息创建者
        string cctx_hash = 2;                             // 跨链交易哈希
        string observed_outTx_hash = 3;                   // 目标链上的交易哈希
        uint64 observed_outTx_blockHeight = 4;            // 目标链上的交易区块高度
        uint64 observed_outTx_gas_used = 10;              // Gas使用数量
        string observed_outTx_effective_gas_price = 11;   // 实际Gas价格
        uint64 observed_outTx_effective_gas_limit = 12;   // 实际Gas限制
        string value_received = 5;                        // 接收的代币数量
        common.ReceiveStatus status = 6;                  // 接收状态
        int64 outTx_chain = 7;                            // 目标链
        uint64 outTx_tss_nonce = 8;                       // TSS Nonce
        common.CoinType coin_type = 9;                    // 代币类型
    }
    

emissions
---------

`emissions`模块负责协调观察者、验证者和TSS签名者的奖励分配。目前，它只向每个区块的验证者分发奖励。TSS和观察者的未分配数量存储在各自的池中。奖励的分配是在开始区块(Begin Blocker)中实现的。 该模块跟踪用于计算奖励的参数:

*   Maximum bond factor
    
*   Minimum bond factor
    
*   Average block time
    
*   Target bond ratio
    
*   Validator emission percentage
    
*   Observer emission percentage
    
*   TSS Signer emission percentage
    
*   Duration factor constant
    

fungible
--------

`fungible`模块有助于在ZetaChain上部署连接区块链的同质化代币(称为”foreign coins”)。外部链代币在ZetaChain上表示为ZRC20代币。当在ZetaChain上部署Foreign币时，将部署ZRC20合约，创建池，将流动性添加到池中，并将外部链币添加到模块状态的外部链币列表中。 该模块包含以下逻辑:

*   在ZetaChain上部署外部链币
    
*   部署系统合约，Uniswap和包装ZETA
    
*   从连接的链中存入和调用ZetaChain上的全链智能合约(`DepositZRC20AndCallContract`和`DepositZRC20`)
    

observer
--------

`observer`模块跟踪投票的选票、链和观察者账户之间的映射、支持的连接链的列表、核心参数(合约地址、出站事务调度间隔等)、观察者参数(投票阈值、最小观察者委托等)和管理策略参数。

选票用于对入站和出站事务进行投票。观察者模块维护选票的创建、读取、更新和删除(CRUD)操作，以及确定选票是否已完成的辅助函数。投票系统由其他模块使用，例如当观察者验证器对事务进行投票时由跨链模块调用。

跨链消息传递(Cross-Chain Message Passing)
===================================

一般说的跨链包括资产的跨链和消息的跨链，跨链桥一般只支持资产跨链，而ZetaChain提供消息跨链功能，应用可以基于消息跨链来开发各种跨链服务，包括资产跨链。因为ZetaChain跨链消息需要借助智能合约实现，所以像BitCoin等非智能合约链是无法实现消息跨链的（但是可以进行资产跨链）。同时，ZetaChain在对消息进行跨链的同时也能携带ZETA进行跨链。

应用要实现消息跨链传递，需要分别在源链和目标链上部署一个支持标准跨链接口的合约，然后通过调用合约的跨链消息函数进行跨链，此时ZetaChain充当一个中继的角色，负责将原链上消息转发到目标链上。

ZetaChain在每条连接它的链(EVM兼容链)上都部署了`ZetaInteractor`合约，该合约包含如下结构和接口：

    interface ZetaInterfaces {
        struct SendInput {
            uint256 destinationChainId; // 目标链ID
            bytes destinationAddress;   // 目标链接收消息的地址
            uint256 destinationGasLimit; 
            bytes message;              // 要发送的消息
            uint256 zetaValueAndGas;    // 发送的ZETA的数量，会从中扣除一部分作为跨链Gas
            bytes zetaParams;           // 参数
        }
    }
    interface ZetaConnector {
        function send(ZetaInterfaces.SendInput calldata input) external;
    }
    

合约要发出跨链消息很简单，只需要继承`ZetaInteractor` 合约，然后在合约里面调用`ZetaConnector` 接口的`send`函数即可，要发送的跨链消息封装在`SendInput`结构体中。

在接收端（目标链），接收合约需要继承ZetaReceiver的接口，接收一个`ZetaMessage` 结构的跨链消息。

    interface ZetaInterfaces {
    struct ZetaMessage {
        bytes zetaTxSenderAddress;   // 发送者
        uint256 sourceChainId;       // 源链ID
        address destinationAddress;  // 目标链接收地址
        uint256 zetaValue;           // 发送的ZETA的数量
        bytes message;               // 具体消息
    }
    }
    interface ZetaReceiver {
        function onZetaMessage(ZetaInterfaces.ZetaMessage calldata zetaMessage) external;
    }
    

最终目标合约的`onZetaMessage` 函数会被调用用来接收跨链消息，应用可以在`onZetaMessage` 实现自己需要的逻辑，ZetaChain只负责发消息转发到发送者指定的合约。

此外，源链发送的跨链消息是可能会失败的，例如目标链的接收合约中的onZetaMessage函数对跨链消息进行校验失败。此时ZetaChain就需要将跨链消息发送的ZETA余额退回给发送者，并起告诉发送跨链消息的合约，这笔跨链消息失败了，以便源链的合约可以执行失败后对应的逻辑。所以源链合约还需要实现如下的接口：

    interface ZetaInterfaces {
    struct ZetaRevert {
        address zetaTxSenderAddress;
        uint256 sourceChainId;
        bytes destinationAddress;
        uint256 destinationChainId;
    /// @dev Equals to: zetaValueAndGas - ZetaChain gas fees -
    /// destination chain gas fees - source chain revert tx gas fees
    uint256 remainingZetaValue;
        bytes message;
    }
    }
    interface ZetaReceiver {
        function onZetaRevert(ZetaInterfaces.ZetaRevert calldata zetaRevert) external;
    }
    

如果跨链消息失败了，ZetaChain会调用源链合约的`onZetaRevert`函数，应用可以在该函数里面处理失败的逻辑，例如如果这是一笔跨链Swap交易，那么合约就需要将对应的Token退款给用户。

下面图片描述了跨链的过程，其中省略了ZetaChain内部的处理过程，暂时把它当成黑盒即可：

![](https://storage.googleapis.com/papyrus_images/28c4c6c5e21cde0abc96a2e68c5ddc34bae07d4c78cb5d8fbb00fb95858170fe.png)

前面提到的跨链消息有一个很重要的应用就是开发跨链DEX，不过你可能也发现了，如果要使用跨链消息的话，需要在每个链都部署对应的合约，这会带来开发和维护上的花销，同时也会带来Gas上的额外花销和跨链等待的时间。那么还有没有什么其他方法可以更方便一点呢？答案是肯定的，这就是全链智能合约。ZetaChain上的全链合约指的是部署在ZetaChain上的智能合约，全链合约拥有如下功能：

*   是任意可编程的，就像zEVM上的常规智能合约一样
    
*   直接管理外部链上的外部资产(同质化代币)
    
*   可以从外部链调用
    

在zEVM上，智能合约可以直接托管这些外链资产，并像它们是本地的zEVM资产一样操纵它们。在外部链上，这些同质化代币由TSS地址控制； 在zEVM的内部，它们被表示为ZRC20——一个与ERC20兼容的合约，但具有处理存款和提款的接口用来管理ZetaChain的本地资产。任何在zEVM上的智能合约都可以通过与这些ZRC20合约交互而成为全链，并实现一个简单的接口，可以从外部链调用：

    interface zContract {
        function onCrossChainCall(
            address zrc20,    // zrc20代币地址
            uint256 amount,   // 代币数量
            bytes calldata message  // 调用合约的信息
        ) external;
    }
    

一个外部链调用ZetaChain的全链合约的步骤如下：

![](https://storage.googleapis.com/papyrus_images/fccbe2613dd45c7f7427c8a01f64c3bc458594628b629ff8d0ed1d34eef23b15.png)

1.  用户将原生资产发送到链A上的TSS地址（对于ERC20，用户需要发送到由TSS地址控制的ERC20托管合约），并通过memo/消息指定`[zEVMContractAddress, message]` ，其中`zEVMContractAddress` 即为要交互的全链合约地址，`message` 为调用的消息。
    
2.  ZetaClient 中的观察者观察到该调用消息，并将它报告给ZetaCore。
    
3.  ZetaCore调用`SystemContract`中的`depositAndCall()`函数，`depositAndCall()`函数内部会再调用`zEVMContractAddress` 中的`onCrossChainCall()` 函数，其调用参数为：
    
    1.  zrc20 - 用户在步骤1中发送的zrc20代币的合约地址
        
    2.  amount - 用户在步骤1中发送的zrc20合约代币的数量
        
    3.  message - 用户在步骤1中交易memo携带的消息
        
4.  应用合约应该在`onCrossChainCall()` 函数中实现自己的逻辑并处理调用。如果此时没有报错则该交易执行完成。
    
5.  如果在调用`onCrossChainCall()` 或者之前的步骤执行失败，系统内部会创建一个CCTX(跨链事务)并将其标记为失败，最终扣除用户的Gas费用后将用户在步骤1中发送的剩余代币返还给用户。
    

`SystemContract` 合约中的`depositAndCall()`函数实现如下：

    function depositAndCall(
            zContext calldata context,
            address zrc20,
            uint256 amount,
            address target,
            bytes calldata message
        ) external {
            if (msg.sender != FUNGIBLE_MODULE_ADDRESS) revert CallerIsNotFungibleModule();
            if (target == FUNGIBLE_MODULE_ADDRESS || target == address(this)) revert InvalidTarget();
                    // 调用转账的zrc20代币合约的deposit进行存款
            IZRC20(zrc20).deposit(target, amount);
                    // 调用用户指定的合约的onCrossChainCall方法
            zContract(target).onCrossChainCall(context, zrc20, amount, message);
        }
    

  
这里“全链”的概念实际上就是将已经连接到ZetaChain的外部链所有的资产都映射到了ZetaChain中的ZRC20中，即使是比特币这种不支持智能合约的链，也可以为它生成一个ZER20合约，这样比特币就可以在ZetaChain上和其他代币一起组成流动性池子。

那么，用户要怎么将上面转入ZetaChain中的资产提取到外部链上呢？其实很简单，ZRC20合约标准有一个`withdraw`函数，用户在ZetaChain调用这个函数就可以将资产提取到外部链。其合约实现如下：

    function withdraw(bytes memory to, uint256 amount) external override returns (bool) {
            (address gasZRC20, uint256 gasFee) = withdrawGasFee();
            if (!IZRC20(gasZRC20).transferFrom(msg.sender, FUNGIBLE_MODULE_ADDRESS, gasFee)) {
                revert GasFeeTransferFailed();
            }
            _burn(msg.sender, amount);
            emit Withdrawal(msg.sender, to, amount, gasFee, PROTOCOL_FLAT_FEE);
            return true;
        }
    function withdrawGasFee() public view override returns (address, uint256) {
            address gasZRC20 = ISystem(SYSTEM_CONTRACT_ADDRESS).gasCoinZRC20ByChainId(CHAIN_ID);
            if (gasZRC20 == address(0)) {
                revert ZeroGasCoin();
            }
            uint256 gasPrice = ISystem(SYSTEM_CONTRACT_ADDRESS).gasPriceByChainId(CHAIN_ID);
            if (gasPrice == 0) {
                revert ZeroGasPrice();
            }
            uint256 gasFee = gasPrice * GAS_LIMIT + PROTOCOL_FLAT_FEE;
            return (gasZRC20, gasFee);
        }
    

可以看到，该函数只是将用户要提取的代币销毁了而已。值得注意的是函数中有个Withdrawal事件，实际上ZetaChain内部在监听到该事件后，最终使用外部链的TSS账户将用户要提取的代币转给了用户。

代币模型
====

ZetaChain使用ZETA作为其原生代币，该代币会同步发行在所有连接到ZetaChain的链（比特币这种不支持智能合约的除外）。ZETA有两种作用，一是用作ZetaChain的Gas费，另一个是用作ZetaChain里和所有ERC20代币组成流动性池子。

首先说第一点，ZetaChain里面的转账、部署合约、合约交互等都需要消耗ZETA作为Gas；此外，ZETA还会用作跨链手续费，比如我要在A链将消息跨链到B链，此时就需要在A链发送跨链交易时顺便携带ZETA到交易中作为此跨链的Gas费。这个跨链手续费主要包含了ZetaChain里面跨链合约调用的手续费以及在目标链将消息发送给目标合约的Gas费。

为什么ZETA能作为目标链的手续费呢？这就要说第二点原因，ZetaChain里面会默认为每个接入的外部链的原生Gas代币和ZETA建立一个流动性池子（采用Uniswap合约），例如ETH/ZETA。当进行跨链时，用户支付的ZETA会通过该池子转换成该目标链对应的Gas，然后再将该代币进行销毁以用作外部链的Gas费。此外，所有部署到ZetaChain中的ZRC20合约都会自动和ZETA组成一个流动性池子。

![图片来源：ZetaChain](https://storage.googleapis.com/papyrus_images/b5ce5eb4626559443ec8e579855ca0415ba2a982d366db9f243600b33c19b3cc.png)

图片来源：ZetaChain

以下流程图展示了跨链消息传递如何使用这些将原生Gas(ZRC-20)与ZETA配对的核心池来支付出站事务。

![图片来源：ZetaChain](https://storage.googleapis.com/papyrus_images/069269d4e5a9b215bbb7026863d7ad0fe798853b07d38fa4bda1406c8a4cfe11.png)

图片来源：ZetaChain

可拓展性
====

前面说过，ZetaChain节点由ZetaCore和ZetaClient两个服务组成，并且他们是分别部署运行的(虽然之间有相互的依赖)，虽然他们的代码都放在了同一个仓库。通过对源码进行编译，可以生成`zetaclientd`和`zetacored`两个可执行文件，这两个服务通过网络通信进行信息交流而不是在同一个进程中。ZetaChain在拓展外部链时可以不用对ZetaCore进行升级，只需要对其配置参数进行更改，例如拓展其所支持链的配置列表等。但是需要对ZetaClient进行升级，添加对其新增外部链的Observer服务，用于监控该链的交易并生成对应的出入站事务消息。另外，对于新增链是EVM兼容链的情况，那么还会在它上面部署对应的必要的系统合约等合约用于执行跨链交易。总体来说可拓展性不用修改共识层，所以拓展不会太复杂，主要是接入链的风险方面需要注意。

风险因素
====

官方白皮书中列出了其认为的主要安全相关的因素，分别是：去中心化、出入站事务安全性、对无限铸币的综合防御和外部链受到攻击的防御，下面展开说明。

去中心化
----

共识层面的去中心化就不用多说了，去中心化程度取决于验证节点的数量以及分散程度。目前最大的中心化风险可能在于TSS(门限签名)的私钥管理，虽然官方说私钥会分散管理，但是当前并没有做到足够的透明，后续可能会引入治理来尽实现尽可能大的去中心化。

出入站事务安全性
--------

ZetaClient通过连接到外部链的节点服务提供商或者全节点来观察外部链的事件，根据链上合约事件和ZetaCore进行交互，所以这里连接的外部节点服务商或全节点必须是值得信任的，这样才能保证外部信息源的可靠性。同时，所有入站出站事务都需要通过TSS、验证以及投票，投票的结果将会记录到链上，这部分是可以追溯的。假设以上都是可以保证的，那么链上的状态修改和安全就可以保证。

对无限铸币的综合防御
----------

由于可以通过ZetaChain跨链移动的唯一原生代币是ZETA，并且ZetaChain实际上只管理从链A到链B的ZETA代币转移，所以Zetachain只需要保证ZETA不会被非法铸造，即防止通过攻击的方式增加跨链的ZETA总供应量。

ZetaChain通过以下方法来实现保护：

1.  ZetaChain节点将在启动ZETA代币的铸造之前检查跨链的总供应量。这可以防止ZetaChain节点软件中的软件错误或漏洞。
    
2.  在链上的代币合约在铸造之前会检查跨链的ZETA的总供应量。ZETA的总供应量由Chainlink提供，并发布在每个连接的链上。这种保护确保了没有人可以随意铸造，而ZETA的总供应量在各个链之间保持不变。
    

值得注意的是，如果攻击者控制了2/3的验证者，或者攻击者能够利用软件中的漏洞，他可以将另一个用户的合法铸造转移到他的钱包。在这种最坏的情况下，影响可以受到控制，因为攻击者只能在特定时间从活跃用户那里窃取，并且一旦用户注意到，系统将会被迅速停止。

对外部链受到攻击的防御
-----------

如果ZetaChain连接的外部链受到攻击，可能会导致以下违规行为：

1.  双花，导致ZETA代币供应量膨胀；
    
2.  审查；
    
3.  回滚导致跨链交易的原子性丧失，因为源链部分信息可能不再存在；
    
4.  硬分叉，链分裂等等。
    

ZetaChain的设计可以减缓其中一些情况，或者控制损害的无限扩散。例如，由于ZetaChain的总供应量检查，外部链导致无限铸造（通过反复回滚和支付）是不可能发生的。此外，使用ZETA代币进行所有跨链价值转移的dApps也受到保护，不会发生无限膨胀。对于其他受到攻击的外部链，ZetaChain应该进入紧急停机状态以评估情况。恢复将由利益相关者和治理机制协调进行。

所以外部链的审查显得格外重要，所有连接到ZetaChain的外部链应该是具有已经验证过的足够的安全性的，不然会给ZetaChain引入风险因素。

其他因素
----

上面讨论的是链系统本身的安全性，对于要在上面做开发的项目方和用户来说，我们还需要考虑其他因素，毕竟这关系到项目未来的发展和用户的资金安全问题，其他因素包括代码逻辑漏洞、团队、社区建设以及生态建设等。下面对这些因素做说明，读者可以自行评判。

先来说团队方面，根据网上公开的披露的信息，ZetaChain主要核心成员包括Ankur Nandwani(前coinbase、Brave、0x和Basic Attention Token的联合创始人)、Panruo Wu (THORchain的早期贡献者)和Brandon Truong(前buzzfeed、Udacity、Yada)。其他核心成员包括Cosmos、Ignite、Consensys和其他多个区块链项目的前雇员。团队核心成员基本都有较为丰富的去区块链领域相关经验，可以说是个足够专业化的团队。不过项目核心团队成员都比较低调，很少看到他们在社媒上公开对ZetaChain进行宣传或者和官媒进行互动，这一点看起来比较让人疑惑。

代码漏洞方面，由于ZetaChain本身的设计已经算足够复杂，随着接入的外部链的增多，系统只会变得越来越复杂，越复杂的系统就越容易出Bug。在接入外部链时，如果因为外部链新增的组件设计不合理导致漏洞的话，这将会直接影响到ZetaChain的安全。这无疑会引进一些不确定的因素。

社区建设方面，目前官方DC频道有超过80W的成员，推特关注数同样超过80万，这在区块链领域无疑已经是非常亮眼的数字，当然不能只通过社交媒体来判断项目的好坏。社区氛围个人体验还不错，会有人专门回复开发者提出的问题。

生态建设方面，根据官网的展示，目前接入ZetaChain的生态并不算多，也还没有较为出圈的项目出现，整体看起来生态还比较早期。

使用场景
====

适合接入ZetaChain的使用场景有：

*   智能合约管理的外部资产
    
*   跨链AMM交易所
    
*   携带数据的跨链消息
    
*   多链NFT
    
*   通用支付
    
*   通用身份和资产
    
*   多链，多签金库
    
*   全链账户抽象或智能合约钱包
    
*   全链DeFi
    
*   全链DAOs
    

项目生态
====

项目生态在前面有提到过，目前生态项目有一百多个，以比较重要的DeFi举例，目前共有20个，大部分为ZetaChain上的原生项目。生态建设是ZetaChain需要加强的地方。如果按照ZetaChain原先的计划在年底上线主网的话，显然现在的生态是不足的。

总结
==

ZetaChain 选择通过使用Cosmos-SDK作为基础层而不是从头开发，大大减少了开发量的同时也增加了安全性。同时其选择作为一个平台而不单单是一个跨链桥，这在当前的跨链赛道是比较少见的，当前跨链赛道还没有一个头部项目，也许ZetaChain会成为那一个。

---

*Originally published on [0xlukema](https://paragraph.com/@lukema95/zetachain)*
