这是“深入解读稳定币 QIAN 2.0”系列文章的第三篇，笔者将在这一系列文章里，结合加密货币，去中心化稳定币、DeFi 等领域的发展现状，分析 QIAN 2.0 设计当中的诸多创新，为即将面世的 QIAN 2.0 稳定币作一系列铺垫，欢迎关注 DeFi 、加密开放金融领域的朋友们关注和指正。

你知道吗？其实每一个 DeFi 玩家都冒着有可能损失全部本金的风险。

当前阶段只是 DeFi 领域的发展初期，主流的 DeFi 产品，从产品设计、技术架构、安全性等各个方面，都有非常大的改善空间。

以下 DeFi 安全事故，相信熟悉这个领域的人们都印象深刻。

1. ERC777 标准漏洞
受影响范围：Uniswap、Lendf.me 损失：数千万美元

2. MakerDAO 拍卖合约漏洞
MakerDAO 清算拍卖设计的目的，是尽可能以最少的抵押物回收最大的 DAI，这一机制在正常情况下是可以成功运作的。但是当以太坊系统极其拥堵的时候，或者更极端一点来说，只要竞拍的参与度不足，就很容易被恶意 Keeper 以极低报价获得拍卖物。

3. bZx 漏洞攻击
第一次攻击当中，bZx 代码存在的逻辑错误造成可用于规避风险的代码逻辑没有生效。

第二次攻击当中，黑客通过操纵 Oracle 价格对 bZx 合约进行了“蒙骗”，根本原因主要是由于平台间共享流动性过小以及价格机制设计缺陷。

4. Synthetix 的抵押贷款清算功能漏洞
Synthetix 近期上线了一个合约，用户可以在 3 个月试用期内质押 ETH 获取 sETH，而在试用期结束后，将启动关闭所有贷款功能进行清算，即任意拥有 sETH 的用户都可以通过调用清算接口得到 ETH。

然而，该接口的处理逻辑代码存在一个漏洞会导致任意用户直接 burn 掉借款人的 sETH 资产并获得 ETH。不过由于该功能处于试用期间，并未造成实际损失。

以太坊智能合约是一项伟大的发明，它使分布式账本不再仅仅只是一种电子现金系统，而是成为了拥有程序处理能力的链上计算机。

但是，基于资产安全等多种考虑，以太坊智能合约从一开始就被设计为不可修改不可升级的机制，这就对基于智能合约的应用开发提出了严峻的挑战。

程序设计当中不可避免的会出现 bug，特别是对于金融智能合约当中的一些复杂业务逻辑，很有可能存在无法轻易被察觉的问题，即使经过严格反复的逻辑检查和代码审计，仍然无法确保程序 100% 正确无误。
因此，人们就有了修改智能合约 bug 的潜在需求，但是这又与智能合约的设计理念相违背。
另外，对于金融类产品而言，无论在产品设计的时候考虑的多么周密和详尽，在经过业务运营和用户使用等环节后，一定会发现已经实现的需求当中存在问题，或者发现全新的需求应该被实现，这些都要求智能合约是可持续迭代和升级的。

笔者所在的 The Force Protocol 项目，技术团队带头人 Seamon 大哥是加密资产交易所行业的一员老兵，他带领技术团队，针对以太坊 DApp 开发中存在的诸如合约不易升级迭代、数据结构固化、链上交互速度慢、用户体验差、缺乏必要基础设施、安全问题突出等问题，提出了 The Force Protocol 原创的“基础组件、扩展组件、金融组件”三大加密开放金融（COFi）服务技术组件。

作为 The Force Protocol 在 DeFi 领域的重要布局，QIAN 2.0 在技术底层上也采用了这一套 C OFi 技术组件，即：

• 基础组件：APEC，即 Assets Protected Elastic Contracts，资产安全的弹性智能合约。
• 扩展组件：BEAMS，即 Blockchain Enquiring, Auditing & Messaging System，区块链查询、审计和消息系统。
• 金融组件 ：
• GEL，即 Global Emergency Lockdown，全局紧急闭锁；
• CALM，即 Cooperative Automatic Lockdown Mechanism，协同自动闭锁机制；
• MAK，即 Multisig Admin Keys，多重签名的管理员密钥。

这么多新名词，分别都是什么？笔者接下来逐一进行分析。

一、基础组件 APEC

目前，APEC 作为链上核心架构，基于 Solidity，在坚守去中心化和资产所有权的前提下，对以太坊智能合约开发中的不便之处进行了调整和优化。

APEC 的核心理念是资产安全和组件弹性，在整体上，QIAN 2.0 的智能合约集群分为 3 大模块：

• 数据（Data）：把经典合约结构的数据部分独立出来，做成一个或一组数据合约，用于存储数据，对外只暴露必要的读写接口。
• 逻辑（Logic）：逻辑合约负责纯粹的业务逻辑，不含业务数据。
• 路由（Router）：业务逻辑所需要读写的字段数据，可根据数据模块和字段名称从路由表中查询，再根据定位结果进行访问。

图 1 APEC 技术架构图

1. 路由表

路由表是一个独立合约，内含一个路由对照表，存储逻辑合约和数据合约地址的路由映射，可随 QIAN 2.0 系统升级持续更新。

合约系统在整个部署后，各个逻辑合约的地址就会被存储到路由表中，外部请求可访问路由表，获取逻辑合约的地址映射并调用其接口。数据合约也可以通过查询路由表获取逻辑合约地址，进行业务逻辑的调用或回调。

对于每组数据，都会有一个属于自己的独立的数据合约，数据合约的地址将会在创建时被自动存储到路由表中。逻辑合约在访问指定的数据之前，也会首先从路由表中获取数据合约地址，再通过地址读写数据合约。

2. 逻辑可升级

逻辑合约不存储资产，不含业务数据，因此就不存在资产安全和数据迁移等问题，所以它是可升级和可插拔的。逻辑合约的新版本在经过测试和审计后，即可部署到链上。

部署新合约时会同时更新路由表合约中的映射表数据，更改路由表中该逻辑合约的地址映射指向，以供其它合约或应用前端查询和调用。

3. 数据可扩展

作为一个可迭代升级的应用，它的数据结构往往也要求是可迭代的。但出于数据所有权和资产安全的考虑，数据合约不可升级。

我们采用的解决方案是扩展。

如果业务上需要添加新字段，这些字段会被存储到一个全新的数据合约中。同时，这个新数据合约的地址和内含的字段名称，会被添加和更新到路由表中，业务逻辑通过查询路由表，获取新字段的地址路由进行读写。

数据合约的扩展，应该是节制和有限度的。

一味地增加新的数据合约，会提升整个系统的复杂度和运行效率。数据扩展机制只是把数据结构迭代的需求从不可能变为可能，我们不鼓励频繁和随意地使用这个机制。

在设计和使用数据结构时，仍然需要遵循合约的经典设计原则和最佳实践，设计充足和弹性的数据结构。对于数据的扩展，应始终保持克制的态度，非必要时不使用数据扩展机制。

4. 资产安全

如果逻辑合约可升级，数据合约可扩展，那么随之而来的问题就是，用户的数据所有权和资产安全是否能得到保障。

众所周知，对于传统 DeFi 应用而言，用户的所有资产都被锁定在合约里。智能合约，特别是代码开源的合约，通过代码公开的形式向用户保证，除了用户自己，没有其它任何人或程序可以染指用户锁定在合约中的资产。更进一步地，合约的不可修改性使得合约一旦部署就不会有代码的变动。

APEC 采用了职责分离的方式解决了在可升级架构下的合约资产安全问题。

业务合约是可修改和升级的，数据合约则秉承经典合约的理念，不可修改升级。在初始化时，每份数据集合会自动生成一份初始数据合约，这个合约一旦部署到链上就不可再修改其代码逻辑。

• 数据合约会在内部维护一个用户地址和资产详情的映射表。该映射表在数据合约内部，只提供用户资产的入账和出账两个接口，其它任何接口都无权写入和更新该资产表。
• 用户入账交易，直接发往数据合约地址，调用其入账接口。用户资产锁入合约后，在资产映射表中记录该用户的地址和其资产详情。然后再调用逻辑合约，处理和记录业务逻辑。
• 用户在出账交易时，仍然是直接调用数据合约上的出账接口，合约将校验用户的地址是否存在于资产映射表中，然后调用逻辑合约，计算出账数额，最后把资产直接转账给用户的请求地址。
• 任何不在资产映射表中的地址，出账接口将不响应其资产请求。在逻辑上保证了任何一份出账的资产，都属于当初投资入账的原始地址，确保了用户对投资资产的所有权和用户资产的安全。即使是运营团队自己，也无法篡改和冒领用户的任何锁定资产。

APEC 的安全哲学秉承了智能合约的一贯理念：超越了“不要作恶”（Don't Be Evil），实现了“无法作恶”（Can't Be Evil）。我们在 QIAN 2.0 系统里，通过数据合约严格的所有权约束，保证了用户资产的所有权和安全性。

二、扩展组件 BEAMS

区块链对现实世界几乎是完全割裂的，它无法主动向链下推送消息，如果智能合约的逻辑出现问题或受到攻击，现实世界是无法被动感知的。因此我们需要持续地监控合约的运行，严格地审计合约中的数据和资产，在出现问题时第一时间发出告警，尽最大可能保证应用的安全。

上述问题的存在，促使我们去构建一个连接链上和链下的系统，持续监控合约的运行，审计数据和资产，加快产品的响应速度，使响应速度的波动曲线趋向平滑，让不可避免的异步反馈更加顺滑和流畅。各种由条件触发的状态提醒和消息推送，可以让用户在使用 DeFi 应用解决金融需求的同时，获得更为人性化的产品体验。

1. BEAMS 技术架构

BEAMS 是与合约紧密配合的链下系统，由 3 个模块构成，查询（Enquirer），审计（Auditor）和消息（Messanger）。

图 2 BEAMS 技术架构图

2. 数据查询

涉及 QIAN 2.0 底层资产变动的核心交易，都会触发自定义的链上事件。链下的查询系统持续地监控链上新事件的产生，并根据事件内容去查询相应的数据合约。数据合约向外部提供暴露数据的只读接口，查询系统按照数据模型的要求，从合约中读取相关数据。

读取到的数据都将被整理和聚合到 BEAMS 的数据仓库，并记录其数据变动情况。数据仓库作为整个系统的数据核心，将通过后端 API 接口向前端提供准实时的数据缓存，向消息模块提供计算和触发的所需数据。审计模块也会使用这些数据对链上合约的状态转移和数据变动进行复核和审计。

3. 审计风控

审计风控模块将持续监控每个合约的状态和数据的更改，对于涉及到的资产变动，审计风控模块会使用独立并行的逻辑对资产变动情况进行二次复核，如果出现异常，则实时通知系统管理员进行处理。

审计风控模块会使用资产总量、变动逻辑、状态校验等不同的复核方式从各个方向对合约数据进行实时审计，以提升审计的准确性。审计模块可以对异常情况进行评级和告警，风控模块在判断为极高风险的场景下甚至将有权对链上合约的运行情况进行干涉和管理。

审计风控模块还将担负统计分析的职责，对用户的订单记录，历史收益，资产变化曲线，平台的实时收益指标，历史收益曲线等系统运营数据进行统计和分析，预测和控制风险点，并为产品运营方向提供数据参考。

4. 消息推送

为了提升由于区块链特性导致的异步反馈的用户体验，消息推送模块将在用户使用流程的各个环节起到重要的作用。特别是涉及到用户自身利益的提醒通知和警示消息（例如 QIAN 2.0 的 CSA 资产充足率降低引发的合约状态报警），缺乏基础设施的区块链更需要消息推送系统来配合工作。

在页面一侧，消息推送模块将优先使用 Websocket 长连接模式，通过前端页面和用户建立双向实时链路，在各个需要执行链上交易的环节，监控链上交易执行情况，交易结束后，向用户推送交易结果和链上状态。

而对于资产清算、收益发放、赎回提醒等消息，则由消息推送模块对合约数据进行持续的监控和分析，达到触发条件后，可以使用包括邮件和短信在内的各种方式，实时对用户推送提醒通知和告警信息。细心的用户已经看出来了，拥有了 BEAMS 的支持，QIAN 2.0 在未来就具备了发行移动端用户钱包，打造支付网络的技术基础。

三、金融组件

QIAN 2.0 的安全哲学可以概括为层级防御理念的 COFi 金融安全三定律：

• 保护平台安全，不受攻击和入侵
• 如果受到入侵，保护资产安全
• 如果资产不再安全，把损失降到最低

QIAN 2.0 安全体系是一个多层次全方位的体系。去中心化是核心，是基础，但并不是唯一和全部。一个具备良好可扩展性，能够应对未来可能存在的千万数量级用户，安全可靠具有完备风控能力的开放金融应用，如果仅仅依靠去中心化的基础设施，是不可能建设成功的。

说到这里，部分关注去中心化特性的朋友，可能就会跳出来说，你这思想一点也不清 DeFi！不完全去中心化的 DeFi 和传统金融有什么区别！

大家请听我把话说完，就知道 QIAN 2.0 究竟清不清是不是秉持着 DeFi 的理念了。

QIAN 2.0 的金融组件，包括三个部分：

1. GEL

GEL 即 GlobalEmergency Lockdown，全局紧急闭锁。

在 QIAN 2.0，所有涉及到资产变动的智能合约接口上，都有全局紧急闭锁开关。如果合约出现问题，可以手动或自动触发紧急闭锁，禁止所有的出入账调用，保护合约内锁定的资产安全。

2. CALM

CALM 即 CooperativeAutomatic Lockdown Mechanism，协同自动闭锁机制。

CALM 是链下风控机制，采用金融级风控标准，使用独立的高可用主从热备集群，7x24 小时不间断运行。

CALM 每 5 秒检查一次合约状态，对 QIAN 2.0 合约内所有的金融资产进行严格的记账和对账，一旦发现可能的资产风险，将立即自动触发全局紧急闭锁，禁止受波及资产的所有出入账接口，把资产损失降至最低。同时通知管理人员，启动运营团队快速反应机制，人工介入和排查问题。

3. MAK

MAK 即 MultisigAdmin Keys，多重签名的管理员密钥。

QIAN 2.0 将采用管理员密钥（AdminKey）机制，管理员可使用密钥设置各级权限，如合约路由的更新，预言机的喂价权限，全局闭锁标志位的设置权限，等等。

管理员密钥可以添加、删除和更新下级权限，在下级权限密钥泄漏时，可迅速更换密钥。

为了规避管理员密钥被盗和遗失的风险，我们采用了多签机制。目前使用的是 3-2 多签，随着平台锁定资产的增加，我们还会逐步提升至 5-3 甚至 7-5 机制。

以 3-2 多签为例，合约中保存 3 个管理员密钥，在进行诸如更换管理员密钥等最高安全等级的操作时，必须使用至少 2 个管理员密钥，同时进行多重签名，该操作才可被执行。

管理员密钥的多签机制保证了：

• 如果某个管理员密钥泄漏，攻击者使用这个密钥也无法完成高权限等级的操作。而平台管理员可以使用多签机制将泄漏的密钥删除，使之失效。
• 如果某个管理员密钥遗失，可使用剩余的管理员密钥添加新的管理员密钥，并删除遗失的密钥。
• 管理员密钥多签才能生效的机制，使每一个高等级的权限操作都依赖于集体决策和执行，有效地防范了内控风险，进一步保护了资产安全。

在目前的技术手段制约下，智能合约部署、修改、升级等操作都需要管理员密钥的授权，有其重要意义。QIAN 2.0 一方面保留了管理员密钥的功能，另一方面，我们也设计了多重签名机制，确保其安全性。这一点，也为将来 QIAN 2.0 管理员密钥更加分布式的保存和使用打下了基础。

未来，QIAN 的运营团队、支付网络的核心团队、社区治理委员会等 QIAN 2.0 的利益相关方，在多重签名的机制下，可以各自保管一部分管理员密钥。任何涉及对 QIAN 2.0 的重要变更，必须由 FOR 的投票机制加以确认，并且通过 FOR 的质押锁仓，违约罚没等机制，调动各方严格执行社区决议，促进 QIAN 2.0 的分布式自治组织（DAO）持续运转。

本篇技术解读比较硬核，相信能够坚持看到这里的朋友们，对于 QIAN 2.0 项目严格的风控理念和设计思路，都会有一个清晰的认识。笔者期待着 QIAN 2.0 的早日面世，并在实战中检验一系列安全机制的有效性，为用户的加密资产保驾护航。

如果您对 QIAN 2.0 感兴趣，欢迎联系作者：
david@theforceprotocol.com