BM：两大方式可解决EOS CPU资源短缺问题

译者前言：对于EOS而言，当前最需要解决的问题就是CPU资源的短缺，其生态里的很多组织也因此推出了CPU租赁服务，然而，这一解决方案也只是治标不治本，而对此，EOS创始人Daniel Larimer在其最新发布的文章《开发有效的合约》中提到了两种解决方案，一是增加CPU容量，二则是应用开发人员需编写更有效的合约来减少对CPU的需求。

 （图片来自：bytemaster）

以下为译文：

EOS区块链用户面临的主要挑战之一，在于CPU资源的短缺问题。有两种方法可以解决这种稀缺性问题：通过提高效率来增加CPU容量或降低CPU需求。Block One正在努力增加容量，另一方面则是应用开发人员需编写更有效的合约来减少对CPU的需求。

我最近审查了一笔只有单一活动的交易，其生成了28个子活动。这些子活动包括10次传输（以及给发送者/接收者的相关通知），3笔发布活动，以及4个相关合约之间的通信。

这一应用的设计使用了大量拷贝而来的代码来作为其token合约，其结合了大量涉及EOS和DICE token的原子微支付。这种模块化设计具有一些安全好处（这使得token在智能合约管理下的时间量最小化），但是它是以大量CPU使用为代价的。每个操作必须设置和拆卸自己的执行环境，验证自己的权限，并执行其他冗余计算。所有被告知的操作，都需要消耗5.37 ms 的CPU时间（平均每个内联操作消耗0.2ms）。

而通过以下改变，我们可实现相同的效果：

1. 将独立合约（betdicetoken、betdicegroup以及betdicelucky）合并为单个合约。
2. 一旦合并之后，所有合约间的通信都可以消除。DICE token可以在不创建任何内联操作的情况下实现发行，并存入各个账户持有人的余额当中。
3. 允许用户用betdicegroup维持存款余额。通过这种方式，用户可存款一次，押注多次，取款一次。这将消除多次与eosio.token合约通信的需要。用户账户余额可在betdice合约内部快速而有效地更新，而不必为每次小额支付通知发送方/接收方。

在应用层进行少量优化之后，我猜这个骰子游戏所需的CPU可能减少80%或更多。在CPU时间用完之前，用户可较之前玩5倍的游戏。

在不久之后的EOSIO升级中，我们将使应用程序开发人员能够按每笔交易支付CPU，这意味着用户不需要任何CPU资源来玩游戏，并且开发人员可通过其他方式货币化CPU使用。在当前世界，有效的合约开发将减少80%或更多的应用开发人员的资本成本。而今天的应用程序将这些成本推给了用户，用户必须购买或借入股份才能使用应用。

现在是应用开发人员开始仔细考虑其设计效率的时候了，否则他们将被更有效和更具成本效益的替代方案所超越。

英特尔、苹果和微软只能通过改进硬件和操作系统来提高应用程序性能。最大的性能收益，掌握在应用程序开发人员手中，这同样适用于区块链应用。