EOS创始人BM最新文章：重构 EOSIO 资源分配

来源：MEET.ONE

编者注：原标题为《BM：重构 EOSIO 资源分配》

今天，BM 在 Medium 上发表了关于《重构 EOSIO 资源分配》的文章，针对 CPU 问题提出了全新的方案，编者简要概括要点如下：

原模式的弊病：

1. 当前 REX 出现的问题是由于设计理念和现实情况有差距，例如赎回或购买REX都是二八分布而不是正态分布；
2. 原模式下，未来特定时间能分到的 CPU 时间数是不确定的，受多个因素干扰；

因此，需要重构整个 EOSIO 的资源分配。

新模式：

1. 所有要用 CPU 的人，都需要去新的 CPU 租赁市场租，取消抵押 EOS 获取 CPU 的分配机制（但不是立刻取消，而是缓慢过渡）
2. CPU 租赁成本变得可预测，所有人可根据公式计算不同出租率下，需要支付的租金
3. CPU 出租获得的收益，甚至可以抵消 EOS 网络通胀率，替代支付节点的出块奖励；
4. 新 CPU 租赁市场的收入依然可能转入 REX 池，但未来 REX 的功能更趋向于吸引用户抵押，但不主导 CPU 租赁市场的价格；
5. 虽然所有人去新市场租CPU是需要花费的，但由于租金收入转入 REX 池，所以会变相回到 EOS 持有者的口袋，用得多花得多，用得少有收入。

编者评价：

BM 今天的文章非常长，可能很多人乍一听觉得 EOS 又复杂了，但其实对于普通用户而言，应该是好事：

首先，就是因为用 EOS 交易的人越来越多了，所以才堵了，那怎么办呢，开始采取更合理的市场调控手段，也就是说你单看每笔转账，确实需要向一个“统一的 CPU 租赁市场”买 CPU 才能操作，也就是单笔转账是要付钱了。

但是，如果你持有 EOS 并抵押到 REX 的池子里，你就能按抵押的 EOS 的比例获得全网的手续费。这跟以太坊不同，人家是矿工都拿走了，而 EOS 是 token holder 也有获利。而且 EOS 网络越繁荣，交易越多，越是普通的持有者（自己不需要高频转账交易）就应该笑开花了，租金收益是指数增加的。甚至节点收入都能 cover ，如果节点收入越来越多，那节点就会更专心的做贡献。

而且现在 EOS 钱包功能升级这么快，底层改了对应的钱包功能很快会跟上，没有太大的学习门槛。

那下面呢就是原文翻译，为了帮助大家阅读，我适当增加了标题及白话解释。

原文如下：

EOS 是第一个广泛被采用的公链，它最近的数据是每秒处理 800 次转账交易，人们对交易的需求是如此之高，以至于 REX 里可以租赁的 CPU 消耗殆尽。本文旨在探讨为什么 REX 出现无法出借 CPU 的问题，并提出一种新的解决方案，确保 CPU 按合理的市场价格稳定分配。

原 CPU 机制 1 ——抵押 EOS 获得对应 CPU

当用户质押 EOS 后，可以分配到对应比例的 CPU。但当前 CPU 使用价格已经被市场高估，也就是说大多数人需要使用 EOS 来租赁所需的 CPU。如果是自己抵押 EOS 获取 CPU ，则需要非常多的 EOS ，且需要承担 EOS 价格波动带来的风险。

原 CPU 机制 2 ——REX 租赁市场

REX 的目的是设计一个自动分配 CPU 使用权的市场，让那些没有太多 EOS 但想要使用 CPU 的人可以使用整个网络。这就带来了新的挑战——既要保证合理的 CPU 租赁价格，又要维护 EOS 持有者的权益。如果价格太高，那么没人愿意租赁，这样网络资源利用率并不高，而如果定价过低，则 EOS 上可用的资源过度消费，最终反而也导致了 CPU 不可用的问题。

我们设计 REX 时使用的算法是当可供租用的 EOS 的剩余供应量接近 0 时，将租赁价格提高到无穷大。但最近 REX 陷入了不管什么价格，都没有余粮可以租的情况，这是因为那些提供可租 EOS 的人可以随时随时赎回 EOS， 我们没考虑到现实中 REX 会有如此巨额的赎回发生。

但是不必担心，REX 目前是正常运行的。 虽然目前大家在排队等赎回，但是最终当 REX 里租出去的 CPU（ 30 天到期后），用户是可以赎回自己的 EOS 的（本金不会有损失的风险）。

REX 为何出现当前的状况？

REX 之所以发生这样的情况，是因为当初的设计算法是这样考虑的：

1. 用户对 EOS 租金的需求是正态分布的；
2. REX 借贷的需求是正态分布的；
3. 租金上涨将催生更多的人向 REX 提供新的 EOS, 即供应更多 CPU;
4. REX 的赎回支出可被产生的租金收益所抵消，总体维持稳定的供应。

但事实上：

1. 存入 REX 的数额受到二八分布规则的约束；
2. 赎回 REX 的资金也受二八分布规则影响；
3. 向 REX 租用 CPU 的需求也是二八分布；
4. 出租者可以在 30 天租赁期到期前提取已经获得的租金收入；

因为理论和现实有差异，所以导致了目前 REX 存在的问题。

全新设计的 CPU 分配

REX 的当前状况是 EOS 公链网络资源分配策略逐渐演变的结果，为了最大程度地发挥设计解决方案的灵活性，我们希望考虑如果不 受 过去设计的限制，可以采取哪些不同的措施。如果可以构想出更好的解决方案，那我们可以进一步加以设计，即基于现有的 REX 衍生出更好的方案。

目前我们看到社区最大的抱怨是 CPU 太贵了，其次是抱怨特定时间下，能分配到的带宽时间是不可预测的（增加了太多不可知变数）。鉴于高昂的持仓成本和低利用率，这些抱怨的根源可能与先前想要降低 CPU 价格有关。EOSIO 想要用 token 来实现资源定价，比如你有 1% 的 EOS 就意味着您可以永久拥有 1% 的 CPU 资源使用权，类似于购买永久居住的房屋。

不可否认的是， 现有的 CPU 所有权模型为 EOS 带来了巨大的实用性，但也不可避免的造成了用户必须拥有大量的 EOS 才能使用网络。而现今的市场环境下，所有可以交易的加密资产都被赋予了超过“预期使用价值”的“投机价值”，也就是说对于一个开发者而言，如果他只是想要使用 CPU ，而为了使用 CPU 去买大量的 EOS， 他承担了 EOS 价格剧烈波动的巨大风险。而且当 EOS 价格波动剧烈时， CPU 的真实成本将随之不可预测的波动。

因此在原有模型下，为了降低 CPU 成本，我们还引入了“部分备用 CPU”的概念。（小编备注其实就是说类似峰谷电的 CPU 分配机制，当网络空闲时，用户可用的 CPU 放大了 1000 倍，当忙碌时，又恢复正常分配）。但这也不可避免的给 CPU 分配增加了不可预测性。

上个月，我们推出了将任意账户列入灰名单的可选项，并且取消了 1000 倍放大分配的机制，鼓励用户使用 REX. 因为和自己抵押 EOS 获取 CPU 相比，直接去 REX 里租非常便宜。但即便这样做了，每个 EOS 对应的 CPU 时间的可预测性仍然取决于放在 CPU 上的 EOS 的百分比。

这是什么意思呢？可以想象一下，你是唯一一个质押 EOS 获得 CPU 的用户，那么您就获得了100% 的 CPU 分配，假定另外一个用户抵押的 EOS 数量是你的 100 倍，那你这边分配到的 CPU 马上就变成了原来的 1%。这就是当前 REX 里的 CPU 分配和 CPU 原抵押分配机制存在的矛盾。

此外，除了 1000 倍放大机制，没抵押的 EOS 也随时可以抵押到池子里，这些变量全部导致了 CPU 分配的不确定性和不可预测性。

理想算法

在理想算法下，CPU 没有投机价值，并且您保留的 CPU 时间将是固定的和可以预测的。此外，您依然可以租赁 CPU ，而不用花大量的 EOS 获取，减少二级市场波动带来的风险。

最后，市场上总会有可用的 CPU ，只是价格不同，因此在一段时间内 CPU 的租赁价格将趋于稳定。

那么，要实现这一目标，应该怎么做呢？

所有的 CPU 资源都应该从 系统合约中租赁， 租金 以 EOS 定价， 且 这个价格随着 CPU 对外租赁出去的百分比的增加而呈指数增长。

而 CPU 租赁获得的收入 将分配给 EOS 抵押池 （例如 REX）。这一模型通过将 抵押 EOS 获得的 收益和CPU租赁 支出 两相抵消，从而保留了 CPU 分配给抵押 EOS 用户的理念。

例如，你质押的 EOS 每个月可以获得1 EOS 的收入，而你可以拿这 1 EOS 去租赁市场得到对应的 CPU。而你能获得的 CPU 数量则是根据市场价格所变动。显而易见的是，在这样的情况下，部分的 CPU 租赁收入将根据您抵押 EOS 的占比返还给您（也就是抵押 EOS 获得收益）。

通过将 100% CPU 全部分配到租赁市场，您就不需要抵押自己的 EOS 来获取 CPU ，也不需要担心有人从 REX 赎回导致 CPU 定价机制波动。

此外， CPU 变得不可转让，因为您所获得的 CPU 时间是系统合约中租赁而来的，并不是通过抵押 EOS 分配的。这消除了 CPU 定价的投机成本，确保每个人都在同样的资源模型下运行。

这样一来，你要租赁多少比例的 CPU 时间，都可以根据一个确定的公式快速计算得出（一切可预测）。

下面这张图显示了 1亿 EOS 的总池子下，不同的出租比例下，CPU 的价格。如果用了这个算法，也就是说当 10% 的 CPU 被租出的时候，租金收入将开始超过 EOS 的通胀率。 也就是说，未来版本的 EOSIO 治理模式可能是选择向节点支付一定比例的租金收入，这将使得他们利益一致，能够尽力提升网络效用价值。

理论上而言，社区可以使用任意的参数来确定 CPU 租赁价格曲线的指数形态，较高的指数将允许低成本利用大量的网络资源，但随着利用率接近 100%，价格将显著增加。理想指数将平衡供求关系，以使总租金和区块链运营成本之后的差额最大化。

因为租用 CPU 的人是二八分布的，所以我们预料到会有大量同时租用和/或续租的大型租户。这可能会导致租金突然下降后又突然上升。如果没有一个“订单薄”来捕捉租金下降的趋势，这可能会给大型租户带来不受欢迎的定价优势。

因此，我们建议租金下降的速度要慢于租金上升的速度。给定定价函数 P (TotalUsage )，一个新的 CPU 租用率下的租赁价格是 MAX  (P(CurrentUsage)，P(DailyAvgTotalUsage))。即分别取 当前用量(CurrentUsage）下的定价和当天平均用量(DailyAvgTotalUsage)的定价这两者之间的最大值。

如果租金价格太高， 当前用量将下降，并且随着时间的推移，当天平均用量也下降，如果 当前用量突然增加，则价格迅速攀升，以防过度消耗。

我们也可以考虑这个算法的变体，例如 当 CurrentTotalUsage 大于 DailyAvgTotalUsage 时，将 DailyAvgTotalUsage 重置为 CurrentTotalUsage 。如果没有新的需求，这将导致平均算法快速响应需求的增长，同时仍会在24小时内逐渐降低价格。

如果你想要在30天内获得1％的CPU资源，则你要支付的价格等于：MAX(P(CurrentTotalUsage + 1％)，P(DailyAvgTotalUsage + 1％)))— MAX(P(P(CurrentTotalUsage)，P( DailyAvgTotalUsage))

或更简单地说，他们将需要支付预期的 EOS = 新使用率水平收集的租金收入总额 -当前使用率收到的租金收入总额。比如当前网络租用率为 20%，您要租用 1% 的CPU，则费率是 21% 的租金总收入-20%的租金总收入。

从 REX 迁移

之所以能够这样设计，是因为整个定价模型和 REX 是不同的，出租者不能将“CPU”从 REX 市场赎回，REX 要平衡出租方和租赁方的需求，在 REX 里，租客要等待 30 天后租赁到期，或者是因为巨额赎回导致想租的人租不到 EOS，因此 REX 并没有实现想象中的，同时给租户和贷方带来便利。

最直接的解决方法是随着时间的推移，逐渐增加 CPU 供应，将 CPU 算法从旧模式平稳过度到新模式。可以通过在系统合约中新增一项操作来实现，即允许租赁方式分配 CPU，随后分配“虚拟抵押的 CPU ”，从而将总的 CPU （无论是拥有还是租赁）稀释为现有 CPU 中。

这不会增加 EOS 的供应量，而是仅仅调整决定分配给每个账户的 CPU 比率的参数。当前，系统合约只知道相对 CPU 权重（分配给您账户的权重÷分配给所有账户权重之和），是根据您抵押 EOS 占比来 1:1 进行 CPU 占比的分配。

如果由新的资源市场创建的“CPU”的供应量逐渐增长到抵押 EOS 获取 CPU 的 100 倍，那么新的租赁市场将有效的控制 99% 的 CPU 资源。随着每个人都采用这个新市场，那么原有的抵押 EOS 获取 CPU/NET 的模式就可以弃用或删除。

紧接着就可以把新的 CPU 租赁市场的收益转给 REX 相关的人，就像短账户竞拍和 RAM 市场一样。这一解决方案将使得 CPU 价格恢复合理，随着时间的流逝，REX 里的 CPU 资源利用率将不断下降，由新的 CPU 资源市场取代。

如果这个新方案被社区采用，那么拥有 EOS 的人将不得不转头去这个新市场租 CPU， 因为他们可以从新市场租到更合理价格的 CPU。我建议在一年内将 CPU 逐步引入新的市场，改变旧机制。

这个方式不仅在 CPU 市场适用，对于 NET 这个资源的分配也同样适用。

终端用户的可用性

许多应用程序和钱包已经采用了“the first-authorizer-pays”的 CPU 模式，从而解决了用户不得不租用 CPU 的烦恼。我的这份新资源分配方式的提案反映了类似的方式，即应用程序开发者可以从云服务商那里租用服务，通过订阅、广告和产品销售等多种策略覆盖其成本。

结论

本提议中的新 CPU 租赁市场将有助于稳定 CPU 价格，降低 CPU 租赁成本，提高使用 CPU 支付成本的确定性。CPU 和 NET 资源所获得的租金收益依然会分配给 REX 持有者，但是最大的变化是 EOS token 是共享整个 EOSIO 网络 CPU 等资源的工具，而用户不再抵押 EOS 获得自己的 CPU。结合服务提供商以每次交易为基础，为用户支付 CPU 成本的能力，这将使得 EOSIO的网络成为市场上最易使用且最具效益的解决方案。