0x 协议治理体系，Part-2：Q&A
常见问题
本文是否会试图给出 ZRX 的估值呢？
并不！
但 MV=PQ...
译者注：公式中字符的含义：P商品价格、Q商品量、M货币数量、V货币流通速度（一定时间内货币转手几次）。这一公式起源于一个不可能错的套套逻辑（Tautology）：交易额必定一面等于商品数量与其价格的乘积和，一面等于用于媒介交易的货币量乘以货币流转的速度。问题的含义在于，只要确定了 ZRX 的数量、交易的商品（代币）数量 Q，以及 ZRX 转手的速度 V，就可以确定 P，亦即用 ZRX 来表示的商品（代币）价格水平，然后反推出 ZRX 的价格。
最近关于代币机制的讨论将交易速率作为代币价值随时间推移的关键驱动力（参见 Vitalik、Multicoin）。总之，因为例如 0x 的去中心化交易解决方案会将交易速率提升到近乎无穷大，代币纯粹作为交换媒介的价值接近于零。
网络平均价值 = 总交易数 / 交易速率
尽管 0x 协议的临时用户可能会选择多出一些钱以尽快购买 ZRX（撰写本文时约 $0.11 gas/trade + 交叉传播成本），持续使用 0x 协议进行交易的“重度用户”将通过持有一定数量的 ZRX 代币来支付交易费，并在每笔交易中保存此金额。由此可见，交易者选择持有的 ZRX 代币的美元价值与他们计划在一段时间内产生的交易费用的美元价值成正比，并根据波动风险进行调整。从终端用户中抽象出交易媒介代币是 0x 协议的核心用例，ZRX 代币将在更大的总交易量中收获一些价值。
抛开交易速率，ZRX 本身就是一种治理代币。ZRX 代币的主要价值使其绝不会成为交易媒介。价值来源于围绕流动性的网络效应，这些效应由 0x 协议的开放式设计及长久治理来实现。
好了，还是回到技术问题上来吧。
哪些类型的以太坊计划修改（提案）将影响到0x协议？
-
新的加密原语。加密抽象（EIP101）与账户抽象（EIP86）将允许开发者使用新的签名方案（RSA，环签名，Schnorr，BLS，SNARKS/STARKS）以及哈希算法（BLAKE2b）。
-
新的 EVM 功能。从增加 REVERT指令到类似于并行化，SIMD操作及允许静态分析新操作码等基础功能变化。
-
新的 Solidity 特性。Solidity 是编写以太坊智能合约最成熟的高级编程语言，然而，它仍很年轻且在不断发展。随着 Solidity 语言逐渐成熟，0x 协议有可能会更加高效，模块化划分更好且增强可扩展性。例如，在合约 ABI（EIP50）中支持结构化数据，最近才在 Solidity v0.4.20 版本中发布——依旧是实验性的——但在合约之间传输结构化数据（如 0x 订单）时允许更高层次的抽象。
-
新型高级编程语言。尽管Solidity是目前最流行的编程语言，但并不代表以后总是如此。如果类似 Vyper 的替代编程语言越来越普遍，那么将 0x 移植到新语言上，对于支持新功能和/或确保开发人员可以继续丰富 0x 代码库是非常有意义的。
-
从 EVM 迁移到 eWASM
0x 核心功能可以进行哪些方面的更改？
-
支持新的代币标准。社区已经提出了 ERC721、ERC821、ERC223、ERC777 以及许多其他新代币标准的提案，这些标准可以解决现有代币标准的不足或允许新的使用案例。
-
更高效的交易结算。
-
更高级的交易功能及费用分享功能。
-
修改代币机制。
-
修改治理过程。
如果 0x 不支持升级会怎么样？
虽然以太坊区块链尚处于起步阶段，但还是有很多智能合约需要升级并经历颠覆性的迁移过程。
示例1：Augur REP 代币
2015 年 8 月，Augur 首次在以太坊区块链上进行代币销售。Augur 的信誉币（Reputation token, REP）是一种智能合约示例，但由于编译合约使用的工具集中存在无法预料的漏洞，需要大规模的迁移。简而言之，原始 REP 代币合约是使用 Serpent 编程语言编写，并使用 Serpent 编译器编译，（该编译器）是早期的默认开发工具。一年后，Augur 团队将 Serpent 编译器的安全审计外包给了 Zeppelin，后者发现了造成 REP 代币缓冲区溢出的漏洞。
最终，Augur 团队不得不冻结 REP 合约——保护交易者——并将成千上万的 REP 持有者的余额复制到使用更现代的开发工具构建的新 ERC20 代币合约中。旧版的 REP 代币当时在超过 20 个不同的中心化加密货币交易所进行交易。他们都被要求冻结交易，以等待迁移操作完成。这是一个（对市场）极具破坏性且混乱的过程。
为更快完成迁移，这个过程是以中心化的方式进行的。然而，情况可能会更糟糕。如果 Augur 预测市场平台已部署上线，迁移过程会导致市场停摆，并由于使用 REP 代币解决预测市场结果，而造成严重后果。
示例2：EtherDelta
EtherDelta 是存续时间最久的去中心化应用程序之一。在 EtherDelta 运行的 18 个月里，智能合约升级了四次。交易者被要求将其在旧版 EtherDelta 合约中的代币取出，并将代币存入新版智能合约中。这是一个单调且高成本的过程：交易者必须完成三笔交易才能将一种 ERC20 代币转移到新的智能合约。如果最终会有数百万交易者和数百万代币加入 0x 智能合约中，那么这样的迁移过程可能会堵塞区块链数月并产生高昂成本。
链上治理 vs. 社会共识？
两者都是必要的。应该使用社会共识推动正式提案的制定，然后在链上进行表决（接受或拒绝）。
从技术角度来看，0x 的治理是如何开展的？
0x 通道被划分成多个模块：
- 交易订单发送给
Exchange模块，该模块包含用于验证订单和结算交易的业务逻辑。 - 治理（
Governance）包含通过正式链上治理过程检证提案，并从通道添加/移除合约的业务逻辑。 - 广义代理（
GeneralizedProxy）将Exchange与Governance模块合并，并允许Exchange模块通过子代理访问用户代币。 - 在 0x 协议版本 2 中，每种数字资产的代币标准或类都将拥有自己的子代理（
SubProxy），通过该代理访问用户的交易余额。
Governance 模块用于重新映射通道中不同以太坊智能合约间的连接关系。
-为 0x 添加对新代币标准的支持。Governanace 模块向在 GeneralizedProxy 状态保存的白名单中，添加新子代理（SubProxy）及 ExchangeV3 合约。-
围绕代币机制有哪些新的想法？
考虑到如何将代币与核心协议耦合，并让代币分布逐步与有代表性的利益相关者样本一致，我们探讨了一系列可能性，以及一些通货膨胀模型：
- 增加中继者补贴，每笔由中介促成的交易都产生新的 ZRX 代币。
- 增加市场创建者补贴，向提供流动性（资金）的市场创建者给予新的 ZRX 代币。
通货膨胀模型非常有趣，因为代币可以促使人们为协议提供效用，补贴可以引导早期用户。然而，如果没有一种不可欺诈的机制，比如工作量证明，中继者或市场创建者就会通过冲交易量拿交易补贴，造成代币不断通胀直至一文不值。我们确定了可能的解决方案，但从实施的角度来看，它们是不切实际的。
投票率低是否会造成“理想”代币分布成为判断治理系统强健性的无效指标？
我们认为投票率是由 治理机制 等因素决定的。无论何种治理机制，对于任何依赖代币投票的治理系统，将代币分布稳定状态推向与有代表性的利益相关者样本一致，客观上来说总是会更好。
我们能够通过尽可能简化投票者参与投票的过程，从而提升投票率。投票过程应该像手机上接收推送后点击按钮一般简单。或者将投票权交给能够代表投票者观点的专家。
有些中继者不使用 ZRX 代币收费。怎么做到的，又为什么要这么做？
0x 协议的版本 1 未针对使用订单匹配策略的中继者进行优化（可通过该链接查看其它策略）。因此，对于匹配者来说，以转播形式而不是 ZRX 代币形式来收取交易费，更节约 Gas。下图展示了一个来自公开订单簿中介的交易以及一个来自订单匹配中介的交易；在使用ZRX代币收费的情况下，订单匹配交易需要两个额外的状态改变。
-通过 Etherscan 网站查看来自订单匹配中继者的交易。代币通过订单匹配在挂单者及吃单者间转移。订单匹配者对交易各方均收取少量代币。如果费用是以 ZRX 代币形式收取的，挂单者和吃单者均需要一笔额外的交易，将 ZRX 代币支付给订单匹配者（总共 6 笔代币转移）。-
-通过 Etherscan 网站查看来自公开订单簿中介的交易。代币直接在挂单者与吃单者间转移。如果存在（中介）费用，创建者和接收者均需要一笔额外的 ZRX 代币交易给订单匹配者（总共4笔代币交易）。-
0x 协议的版本 2 中将添加对于原子订单匹配的支持，这将使得匹配者（或套利者）能够在市场对侧添加有效交叉订单，而不需要预付资金及达到最小代币转移数量。
要求交易者预先购买 ZRX 代币不会产生阻碍么？
会的，需要 ZRX 代币支付交易费会给刚开始使用 0x 协议的新用户带来额外的影响。有许多方法可以减少这种影响。例如，0x 交易控件将启用“一键式代币购买”，并对 WETH 和 ZRX 的需求进行抽象。对于临时的、对价格不敏感的用户来说，这会让他们更容易获得中继者提供的流动性，而无需通过链上交易过程。
抢先看：0x 交易控件
0x 核心团队将试图强制中继者使用 ZRX 代币收取交易费么？
不会的。虽然我们认为 ZRX 代币的广泛分布对于治理非常重要，并将 ZRX 代币作为默认支付代币，但重要的是 0x 协议需要尽可能具有可扩展性。如果阻止中继者围绕 ZRX 路由意味着协议给开发者更小的创新空间，我们就不会在 0x 协议中增加额外的限制。
未来的区块链会不会吸收像 0x 一样的特性，进而创造原生的交易协议？（参见： Chris Burniske 的推特）
首先，现在有没有区块链这么做？有的。BitShares 使用特殊交易类型来构建底层区块链中的原生 DEX。Stellar 包含本地 DEX，采用链上订单簿的形式。Waves 采用与 0x 设计相似的链下订单匹配模型，但交易是以叫做 ExchangeTransaction 的特殊交易形式被添加到 Waves 区块链中。
将交换功能硬编码进基础协议中存在严重的缺陷。最明显的缺点是整个网络必须通过分叉才能修改交换功能。与此相反，修改 0x 协议无需以太坊区块链硬分叉。关注点的不同使得 0x 社区能够专注于提升交换功能，而无需依赖以太坊社区，或者说与更广泛的以太坊社区一致。
此外，在基础协议中硬编码交换功能也无法促进形成创新生态系统。将技术栈分成单独的层让每一层都更易于升级，不必受相邻层的拖累。
感谢 Alex Xu、Fabio Berger、Tom Schmidt、Linda Xie、Amir Bandeali、Jill Carlson、blakehendo、Zack Skelly 以及 Luke Duncan 提供的帮助。
校对按：个人认为，0x 团队这篇博文有两个亮点：1. 在 Part-1 中提出的，从系统升级受影响最大的群体（交易者群体）推理出理想的代币（即治理权力）分布：让交易者尽可能多地持有 ZRX，以此阻止对交易者不利的提案通过；2. 0x 协议并不担心自身会因为区块链在协议层整合交易功能而失去价值，因为后者的升级将会更为艰难。就第 1 点而言，虽不能说这样的想法就很系统或者说很坚实了，但起码不是异想天开的；而第 2 点，则见出 0x 团队的技术经验，没有丰富的开发经验，往往不会从技术迭代这个角度来考虑。这个回答，再好不过地提醒了我们，应该不断反思底层协议在技术栈中的位置及开发方向。