白皮书 | zeppelin_os

zeppelin_os: 基于 EVM，一个安全地开发和管理智能合约应用的开源，去中心化工具和服务的平台。

摘 要

最近，区块链的生态圈中爆发出了许多新的协议。这些协议旨在提供从价值的传统转移到去中心化文件存储中的一切。这是一个激动人心的时代，因为区块链产业能够重新设计和构建很多传统的互联网基础设施。我们有机会能够让它在一个去中心化的环境中，更快，更容易，更安全地在线上部署复杂的应用。

但是，这个产业一直受到安全破坏的困扰，而随着区块链技术的前景变得越来越现象级，安全问题也愈发不可忽视，我们需要十分小心地利用区块链技术。同时，我们又想要尽可能地降低这个技术的门槛，为创新添砖加瓦，加速推动一个去中心化的开放生态。

为了应对这些机遇和挑战，我们提出了 zeppelin_os，一个去中心化应用的区块链操作系统。在为 zeppelin_os 的持续发展创建激励的同时，zeppelin_os 能够让开发者轻松地构建安全应用，这些应用使用并对已有协议进行组合。

zeppelin_os 由三个核心组件构成：内核，市场和软件开发包。我们也提出了 ZEP 代币用以激励 zeppelin_os 生态。代币用于在协议市场中消费和提供服务。它也作为内核升级的主要监管机制，内核会在 OpenZeppelin 升级的时候同时更新，这也是我们提案的一个关键部分。

1 引言

任何人都可以使用像以太坊这样的开放网络来运行软件，并通过代码来形式化合约关系。这些去中心化应用常常会促进某种服务的金融交换。但是，构建这种软件的开发过程常常十分复杂，需要耗费大量时间，并且很容易出错。

保证这些金融交易和智能合约中资金的安全性，对于区块链系统的成功至关重要。不过目前，几乎没有任何标准，也不容易开发高度安全的应用。利用现有的工具，对安全突发事件做出高效响应极具挑战性。

另一方面，去中心化网络并不是共同工作而设计的，它常常需要接入彼此的原生代币进行操作，这使得它很难对外部系统加以利用。

为了解决这些问题，我们提出了 zeppelin_os：一个 EVM 上工具和服务的开源，去中心化平台，用以安全地构建和管理智能合约应用，并且完全免费。

2 核心系统概览

2.1 担保

在 zeppelin_os 中，所谓管理，指的是升级，或是给内核代码打补丁的操作。它通过一个担保机制实现，在该机制下，网络参与者可以锁定 ZEP 代币为一个新的 Kernel 版本进行担保。因为升级到新版本是免费的，所以这个担保机制是网络用以指示最新最优内核版本的一个主要途径，与此同时，会奖励贡献者部分所抵押的代币。

2.2 内核

内核是 zeppelin_os 最重要的一层。作为部署在区块链上的一个智能合约库，它为使用操作系统的智能合约提供了一系列的基础功能和服务。它由一种去中心化的升级机制所支持，而这种升级机制又依托于 ZEP 代币持有者管理的担保机制。zeppelin_os 内核的可升级机制将会基于代理库模式[1]，它由 Zeppelin 和 Aragon 共同开发。开发者不必花费 ZEP 代币即可使用内核功能，它将免费使用。

zepplin_os 内核的目标是，为在内核上运行的智能合约提供一些函数，这些合约可以直接从操作系统请求服务，而不必从头开始重新实现。可重用的合约和函数库大大启发自 OpenZeppelin [2], 并且遵守同样的安全标准。

开发者能够用这些库来做这些事情（包括但不限于）：

• 创建并定制一个 ERC20 代币。

• 创建一个有上限，可退还，且/或有白名单的众筹合约。

• 创建一个无须信任的 bug 奖金。

• 创建一个可暂停，可拥有和余额限制的合约。

• 设置一个代币归属或代币锁定合约。

• 创建无须信任的代币出售或代币购买合约。

• 创建一个具有原子性的代币交换合约。

• 创建一个代币期货合约。

-图1: zeppelin_os在广大的区块链栈上-

2.3 市场

与传统的手机应用市场极其类似，市场作为移动用户浏览和购买所提供服务的中心枢纽，zeppelin_os 的一个重要特性就是智能合约市场，在这里可以购买服务，也可以将服务集成到其他应用中。

今天，与智能合约的大部分交互都由人来触发。我们认为，为了行业的成长，智能合约需要开始进行相互交互。通过由操作系统所提供的不同的标准执行模型，加之由平台的 ZEP 代币执行的支付，从而促进这些服务的交互，进而在服务提供商与客户应用之间，带来一个高效的操作系统内生态。比如，这个模型使得任何智能合约可以同时在 Filecoin 和 Storj 中进行存储，而不必使用其中的任何一种原生代币，都通过 ZEP 进行支付即可。

目前，尽管智能合约与链下世界的交互有着诸多限制，但是现在出现了一些服务，它们提供了执行链下效应的桥梁，可以给真正的去中心化应用在 zeppelin_os 上完整运行提供支持。此类服务的案例有文件存储，邮件发送，推送通知，链下密集计算，机器学习服务等等。

2.4 软件开发包

除了由 zeppelin_os 提供的链上服务，平台还提供了一些链下工具，旨在简化去中心化应用的开发，调试，测试，部署和监控。我们打算通过加速行业的专业化进程，提升智能合约的质量和安全界限。我们将引领创建在传统中心化软件中已有的著名工具，比如持续集成，静态代码分析和健康监控。

3 安全模型

作为智能合约应用与链上进行交互的一层，我们开创了向 zeppelin_os 用户无缝交付升级的先河。一旦发现漏洞，我们能够迅速推出安全维护和补丁，及时保护 zeppelin_os 的所有用户。

内核库的用户将会有一个选项来启用自动升级。比如，用户可能会指定他们使用 ^1.2 版本，这意味着最希望担保的版本是 1.2 及以上，且在 2.0 以下。

对于内核用户，这些升级是可选的，因为在自行对新版本进行评审后，他们可能会选择手动切换到 1.3 ，而无论该版本的担保情况。

ZEP 的持有者对补丁进行评审，并为其正确性担保，会激励系统升级。对于避免中心化机构使用操作系统中可选的自动升级系统升级(比如，更改)所有合约，有一个审查机制是非常必要的，当遇到一个被大部分人确认的重大安全问题时，提供一个快速响应的机制。

经验表明，代码库中无可避免地会出现 bug。因为智能合约变得越来越复杂，出现 bug 的可能性也会越来越大 [3] ,也就会给攻击带来更大的可能性。

为了预防攻击，zeppelin_os 将会提供一个用于攻击响应的工具箱。触发紧急暂停，恢复到之前未受影响的状态，或者分叉一个合约都可能的一些手段。

-图2: 自动更新机制的图示。在前面，1.2 版本是“最新版”，拥有数量最多的担保ZEP。当1.3a 版本和1.3b 版本被引入的时候，使用者将他们的担保token转移到新版本，有80%的担保token放到了版本1.3b 而20%的担保给了版本1.3a 。那么版本1.3b 成为“最新版本”，因为它是拥有最多担保的。-

4 激励和管理

加密经济协议创造了金融激励，它驱使网络中理性的参与者朝着一个共同目标规范自身行为。通常，通过引入一个原生代币可以形成激励规范。zeppelin_os 的原生代币是 ZEP，它的目标是规范网络激励，以期为安全的去中心化应用建立，发展，维护一个更易开发的生态。

从概念上来讲，就升级机制而言，一个内核用户可以执行两种不同的操作：

1) 将他们合约使用的内核从版本 V 更换到 V_0.
2) 授权或示意他们愿意使用 V_0 而不是 V.

考虑到，如果不强制开发者持有 ZEP 代币来使用内核，那么1) 很难（或者不可能）与代币机制进行绑定，因而我们会使用 2) 作为 1) 的代理。为此，我们定义了以下“担保”机制：通过锁定部分代币和指定所担保的具体版本，ZEP 代币的持有者可以批准一个指定的内核版本 V。值得注意的是，内核被升级为一个整体系统，而个体组件通过一种模块化的方式并不会被升级，尽管这可能受制于未来的一些变化。

简单来说，对币进行锁定意味着，用户无法转移这些币，也无法用它们来为其他版本进行担保。这并不意味着代币可以被锁定一个指定时间。

比如，假定一个内核只有 v1.0.0 和 v1.0.1 两个版本，有三个各有 100 个 ZEP 代币的持有者，可能会出现下列情况：

• 持有者 A 为 v1.0.0 担保 50 ZEP, 为 v1.0.1 担保 50 ZEP 代币。

• 持有者 B 没有为任何版本担保。

• 持有者 C 为 v1.0.1 担保 80 ZEP。

在这个案例中，如果持有者 ABC 占据了网络中大部分的担保权，在自动升级的背景下，网络将会接受 1.0.1 作为最新版本。值得注意的一点是，用户可以手动改变他们合约所使用的内核版本，这使得升级内核成为一个可选项。基于开发者设置的策略，zeppelin_os 也会为合约提供工具进行自动升级。

4.1 开发奖励

为了引导 zeppelin_os 内核的发展，同时为了激励贡献者解决出现的问题，操作系统将会提供了一个开发奖励平台。在这个平台上，用户可以提出他们想要的特性，然后为这些特性设立奖励。类似地，也可以针对需要解决的 bug 采取同样操作。除了担保一个已发行版本，会有社区给予的普通奖励，奖金的目的在于推动内核发展，同时成为开发者积极贡献的动力。我们目标是为开发奖励的提案实现一个委托评审过程，不过最初时，这个过程将会通过一个中心化的方式进行管理。

作为这个过程中一个端到端的示例，假设一个开发者正在 zeppelin_os 内核上构建一个项目，而他需要一种还没有构建好的智能合约。通过这个平台，他们可以为该合约的开发公布一个指定数目的 ZEP 代币奖金。其他开发者可能会在未来也有同样的需求，那么就可以将开发奖金进行叠加。开发者可以看到奖金，并宣布他们会该需求进行开发。一旦完成，一个网络委托人将会对提交的内容进行评审。如果实现被接受，那么奖金将会被发放给开发者，而该特性也会被提交给正常的内核升级担保。奖金的其中一小部分将会被奖励给评审员。

注意事项和有待解决的挑战

• 选择网络代理的投票过程的说明书仍尚未确定。最可能的是，这会是一个股权系统，每个代币持有者都会有权锁定代币，然后给一个指定的代表/评审员投票。

• 评审者的激励很容易被网络误导，因为评审者每次评审都应该被奖励，无论提案接受与否。这会给评审者造成一个奖励，他会故意创建大量会被拒绝的提案，因为评审者仍然可以得到奖励，从而耗尽开发者奖金池。

4.2 技术细节

以下技术细节保证了内核升级机制和激励。

基于之前的一个版本，任何开发者都可以提出一个新的内核版本升级。作为一个防止拒绝服务式攻击相关的提案提交的手段，创建新版本提案将会消耗 ZEP 代币。对内核版本开发者的报酬，是那个版本所担保代币总数的一个函数。当开发者基于之前的一个版本提出新版内核时，为了支持新版本，用户可以终止为之前的版本担保。通过创建一种版本的树状结构，多个版本的内核可以并行存在。

根据一个所担保代币的函数，每一个担保操作都将会给新版本的开发者给予补偿。

change_vouching(v_1, v_2, n) 会触发 payout(v_2, f(n)), 这里的 f 是 n 的单调递增函数，n 是代币数量。为了确保激励有序，支出可能也会包含一个时间锁定或者其他额外的安全措施。

无论何时，如果用户为一个新版本担保 t 个代币，那么这 t 个代币的一部分会将会给开发者作为奖励。这会导致 change_vouching(v_1,v_2, n) 从 v_1 中取 n 个代币，将 f(n) 个代币给开发者，并为 v_2 锁定 n-f(n) 个代币，这里的 f(n) = n * (1/k) ，k 是一个自然数。f 的定义与担保的代币总数无关。这意味着支出是所转移代币的一部分，且来自担保者的账户余额。作为奖励给予开发者的代币有一个时间锁定，并且只有当达到一个指定的代币数量阈值时，这些奖励代币才可进行兑换。在锁定期间，担保者可能会改变他们的目标版本。

一个担保变化的时间线示例如下：

• 在 t_0 时间点，发布 2.0.2 版本修复了 2.0.1 版本的一个漏洞。

• 在 t_1 时间点，一个拥有全部担保权 10% 的用户将他们的代币从 2.0.1 移至 2.0.2 (change_vouching(2.0.1, 2.0.2, 10))，这会导致给 2.0.2 开发者的一个补偿(payout(2.0.2, f(10))).

• 在 t_2 时间点，2.0.1 的其他用户将他们的代币移至 2.0.2，这也会导致给开发者进行补偿(payout(2.0.2, f(70))).

4.3 奖励

我们承认，除了由操作系统的用户主观评估，不太可能去衡量一个贡献的价值。即使是小到一个字符的改变，也可能会节省数百万美元，而一个添加了很多合约的大范围改动，也可能并没有什么用处。除了通过有多少人接受改动这一途径，其它并没有一个客观的方式衡量代码本身的变化。

同样地，上述方案的结果就是，假定为它担保的代币数量相同，那么每一个提案的升级都被给予同等奖励。这会导致开发者提出升级来将他们的每个贡献与预期的奖励相适应，而市场将会根据是否担保贡献决定支出是否公平。

比如，如果提出的升级就增加的价值而言太小，就会抑制开发者为它担保，因为给开发者的支出将会变得不公平。这回防止开发者进行无效升级，并且鼓励他们将几个小的改动压缩到一起提交一笔较大的改动，将一个支出地址设置到一个资金分离的合约中。

同时，要注意系统的恶意参与者可能会造成的任何破坏。由于提出新版本的相关成本，和作为改动担保操作花费的部分代币，为自己版本担保的开发者将会最终失去代币。恶意用户为有问题的版本进行担保，试图在内核中引入漏洞，将不会被其他用户所认同，其他用户会为开发树中的一个不同版本进行担保。

总的来说，由于用户担保的动机，是维护操作系统健康的开发循环，并保证底层的内核库安全，所以我们期望每个完成的担保操作都以此为目的，而无论从用户账户中担保的代币有多少小。

5 内核

5.1 标准库

zeppelin_os 将会提供一个可重用合约和函数的链上标准库。zeppelin_os 内核的目标是，提供一个函数集合作为智能合约在上面运行的系统调用，因而只需操作系统请求服务而不必重新实现他们。在操作系统上运行的智能合约将会调用这个库。

5.2 合约可升级

除了 zeppelin_os 内核自身的可升级，对于操作系统的用户来说，底层实现也允许启用他们自己智能合约的可升级。这也就能够推出针对合约的安全补丁，还有特性的逐步部署。

5.3 调度程序

合约代码是同步且线性执行，并且可能会调用其他合约，但是都限制为一个单一持续执行的线程。为了支持更加复杂的操作，应用需要链下的基础设施，以实现完全去中心化应用的终极目的。

为了支持更加丰富的执行模型，通过信号事件的使用标准化，操作系统将会提供一个基于奖励的智能合约异步执行调度器。在这里面，各方可以申请执行异步操作，并且安全地回调合约来恢复操作。通过在回调发起人上添加验证，以保证响应由一个安全的数据库所提供，给从可信和授权资源中请求数据的标准机制开启了新思路。

为此，操作系统将会定义所需标准，并为调度程序客户端和想要提供异步执行操作的提供者，提供简化采用它们的代码，最终能够高效地对节点进行设置，并通过这些节点对分布式调度网络提供支持。

5.4 消息库

操作系统将会提供合约间通信和网络的各种机制，比如发布-订阅消息，消息队列和共享存储。

尽管区块链交易具有去中心化和安全的特性，但是由于挖矿时间和手续费，使得它在频率和成本上有所局限。这导致出现了很多可替代的链下交易系统，它们可以通过多个操作使区块链变得更加强大，比如状态通道 [4]，作为在两个或多个节点间相互通信的最新提案之一，通过一个智能合约作为一个中间桥梁进行验证和加强。

操作系统将会提供状态通道支持，除了常见的协议规范和引用实现，还有状态通道发现，仲裁和巩固所必须的所有链上基础设施。除了提供一个成本更低的通信机制，这也会给未来与平台上链下状态支付网络的直接集成留出了接口。

5.5 可信预言机

操作系统会从智能合约提供一个标准接口获取在区块链上的信息，而这些信息目前从链上的应用中并不可得，比如当前的 ETH 价格，gas 价格，交易池大小，平均出块时间等等。

6 市场

当将不同的协议服务集成到一个去中心化应用后，zeppelin_os 市场将会为开发者创造了一个插件和游戏体验。如果没有它，而开发者想要利用多个协议服务，那么他们将需要提供交换功能。

在 zeppelin_os 之上构建的应用，可能会通过市场包含一个或多个外部协议。因为原生代币 ZEP 被用于执行平台上构建的应用，所以需要有一个机制，通过该机制，外部协议代理将 ZEP 转换成任意一种需要使用该外部协议的代币。市场因此需要有某种交换机制。为了实现这个目标，我们提出了正在实验的三种方法，下面是探索的所有方法。

6.1 交换

这个方法相对简单，因为它不要求市场集成的开发者应用资金来保证应用的功能。交换方法将会利用已有的交换基础设施，管理 ZEP 代币和其他代币之间的转换。

通过市场，提供服务的每个协议将会连接到一个 zeppelin_os 交易集成处，这里能够将 ZEP 转换成其他的协议代币。在未来，通过给交易所创建一个竞争任意给定交易的机制，可以将竞争机制加入到交换过程中。如果向市场开放，贸易商可以提供这项服务，并从通过执行市场操作得益。

6.2 缓冲

提供市场交换的第二个方式，并不需要进行实际交换，只要求开发者通过市场交付服务，将外部协议的代币创建一个缓冲区，然后交给智能合约。这些代币将用于支付给协议服务，与用户使用 ZEP 在应用中为服务付费类似。智能合约将会有一个预言机，指定 ZEP 与外部代币的兑换比率。开发者接收 ZEP ，花费外部代币。集成开发者因而会像一个市场创建者一样。

这个方法可能需要一个集成开发者持有大量的协议代币，这对于保证较低的准入门槛并不适合。但是，这个方法将会启用实时交换，也能够让集成开发者对交易的传播收费，从而产生收入。最终，这样的传播会降到一个最低点，降到提供此类服务的合理价位。在用户端，这个趋向于更低成本的竞争趋势，会随着时间达到一个可接受的最佳价格。

6.3 基于 ZEP 的经济

第三个方案是，对于想要提供服务的开发者，通过市场允许他们的智能合约来接收在 ZEP 支付。虽然价格仍然是在服务的原生代币进行设置，但是支付将会通过与等值的 ZEP 进行交付，使得这成为另一个真正实时的方案，无须在一个缓冲区中储存大量代币。

注意事项和有待解决的挑战

• 交换方案同样受制于任何链上交易的延迟和可扩展性问题。

• 基于 ZEP 的方案需要提供服务的开发者，通过市场修改他们的智能合约来接受 ZEP，所以对于已有项目进入的门槛比较高。

• 缓冲区方案需要市场集成的开发者持有部分相关协议的代币，也可能提高进入的门槛。

-图3: 为外部协议支付的替代性机制-

6.4 市场策展

市场的所有提交将会被仔细评审，以确保最高质量和安全性。最初，这个评审过程将会由 Zeppelin Solutions [5] 团队引导，同时有一个 bug 奖励的公开评审。中心化的市场评审，对于维护内容的质量和评审效率是有益的，但是历史告诉我们，它会让控制方施加非竞争性的影响 [6] 。我们十分清楚这个问题，因此一旦找到最合适的模型，将会全身心投入到转换到去中心化的评审模型中。

注意事项和有待解决的挑战

去中心化的市场评审需要高效，可扩展，并且维护所接受提交的高质量。这可能通过一个代理模型来实现，在这个代理模型中，代理人有激励来评审提交，并且依据由社区投票的指南行事。

7 软件开发包

7.1 分析和监控

与终端用户在一个网页上执行的动作和事件类似，合约交易和事件，给已部署应用的使用提供了非常有价值的洞见。同样的，一个链下分析面板可以收集链上生成的合约事件，作为他们的研究之用。同时，通过追踪每笔交易来源于哪个节点，有可能获得终端用户如何实际连接到网络上，与合约进行交互的信息。

追踪合约生成的事件和交易的另一面，是监控每个合约的健康度，通过交易错误率和失败相关事件的交易记录，然后同时根据一些通用和每个合约定义的规则触发警告。

7.2 合约的持续集成

通过集成测试提供者的自动化测试，已经成为软件行业的一个标准，它是一个通过在一个独立的环境中，在开发的每个阶段，检测测试，提高项目健康度的信息。但是，这需要一个测试环境，并且尽可能与生产环境类似的条件。同样的，zeppelin_os 将会提供高效地测试智能合约的所需服务，以一种持续集成的方式与其他服务进行交互，包括使用更新后的代码库与生成的结果进行比较的重复可操作性。

7.3 自动代码分析

静态分析在学术界是一个长期的研究领域，尽管它的大部分益处在于保证正确性和识别出可能的 bug，但也不时会有一些工业级工具的产出。由于去中心化应用的高安全性要求，智能合约代码应用这些策略是十分有必要的，这也是一个被持续研究和提高的领域。

通过接入智能合约引用的代码，zeppelin_os 会提供自动化的代码分析服务，同时带有不断增强的规则和技术，防止不可避免地部署可能不安全的代码，并向已有运行合约的所有者警示新发现的漏洞。

7.4 去中心化应用的Heroku [7]

为了给普通用户简化部署过程，我们将会提供必要的开源开发工具，简化在智能合约之间高层交互规则的规范，这些合约会在链上执行。如上一章节提到的，向平台提交规则将会触发一个测试和分析过程，随后才被实际部署到区块链上，或者通过之前提到的机制所支持的升级，为程序员最小化去中心化应用的开发复杂度。

平台即服务，同时也作为一个和其他合约集成的一站式平台，为市场服务的发现和管理提供了一个接口，所以去中心化应用的所有者可以插件化，并使用构建的不同基础设施。就像智能合约的 IFTTT 配方 [8]。

参考：

[1] Manuel Araoz, Jorge Izquierdo. Proxy Libraries in Solidity. https://blog.zeppelin.solutions/proxy-libraries-in-solidity-79fbe4b970fd 
[2] OpenZeppelin. https://openzeppelin.org 
[3] A plea for simplicity. https://www.schneier.com/essays/archives/1999/11/a_plea_for_simplicit.html 
[4] State channels. http://www.jeffcoleman.ca/state-channels 
[5] Zeppelin Solutions. https://zeppelin.solutions 
[6] Time for Apple to face the music? http://newsvote.bbc.co.uk/1/hi/technology/7002612.stm
[7] Heroku. https://heroku.com 
[8] IFTTT. https://ifttt.com 
[9] Ethereum. https://ethereum.org

---

原文链接: 

https://zeppelinos.org/zeppelin_os_whitepaper.pdf
作者: Manuel Araoz, Demian Brener, Francisco Giordano, Santiago Palladino, Teemu Paivinen, Alberto Gozzi, Franco Zeoli
翻译: liuchengxu

更多文章：