译文/Translated：
EOS区块链用户面对的主要挑战之一便是CPU资源的匮乏。有两种途径可以解决这个问题：增加CPU处理能力或拥有更高的功效从而降低CPU需求。Block.one正致力于增加CPU的能力，但却依仗应用开发人员编写出更高效的合约，以降低需求。
我最近查阅了一个采用单一操作的单一交易，该操作延伸出了28个子操作，这些子操作包括10次转移（及通知发送者/接收者），3次发布操作以及4个内在关联合约的沟通。该应用的设计在其代币合约中采用了许多复制粘贴代码，再结合诸多原子操作的微小支付，其中包括EOS及其自身的DICE代币。此模块化设计拥有一些安全优势（尽可能降减少了智能合约管理代币的时间），但这些优势是以CPU负重使用为代价。每一次操作必须建立并拆除其自身的执行文本，验证自身的许可并进行其他多余的运算。众人皆知该操作花费了CPU5.37毫秒的时间（平均每个内联操作0.2毫秒）。
进行以下改变可获得同样的功效：
1.将独立合约（betdicetoken、betdicegroup和betdicelucky）合并为单一合约。
2.一旦完成合并，便可消除所有内部合约沟通。DICE代币可发放并记入各自账户持有者的余额中，而不产生任何内联操作。
3.允许用户使用betdicegroup维持账户余额。如此，用户可以存入一次，下注多次，然后一次退出。不再需要多次与eosio.token合约进行沟通。用户账户余额可在betdice合约内部快速且高效更新，而无需通知发送者/接收者每一笔微小支付。
在应用层面稍作优化，我怀疑这款骰子游戏所需的CPU可降低80%，或者更多。在CPU时间耗尽之前，用户可重复玩耍5次。
在EOSIO不远的更新中，我们将允许应用开发人员以每笔交易为基础支付CPU的使用。这意味着用户玩游戏将不再需要任何CPU资源，而开发者能够通过其他途径将CPU的使用货币化。据此，高效合约开发将为应用开发者节省80%乃至更多的成本。如今的app将这些成本推给用户承担，用户必须购买或借用。
应用开发者是时候开始仔细思考设计的效率了，否则他们将被更高效且更节约成本的替代应用淘汰。
英特尔、苹果和微软只能通过提升硬件和操作系统来优化应用性能。而最大的性能扩充却掌握在应用程序开发者的手中。对于区块链应用而言也是如此。标题：
原文/Original：
One of the major challenges facing users of the EOS blockchain is the scarcity of CPU resources. There are two approaches to resolving this scarcity: increase CPU capacity or reduce CPU demand through higher efficiency. Block One is working to increase capacity, but it is up to application developers to write more efficient contracts to reduce demand.
I recently reviewed a single transaction with a single action which spawned 28 child actions. These child actions included 10 transfers (and related notifications to sender/receiver). 3 issue actions, and communication between 4 inter-related contracts.
The design of this application uses a lot of copy-n-paste code for their token contract, combined with a lot of atomic micro-payments involving EOS and their own DICE token. This modular design has some security benefits (minimizing the amount of time tokens are under management of the smart contract), but it comes at the price of heavy CPU usage. Each action must set up and tear down its own execution context, validate its own permissions, and perform other redundant computations. All told this operation was billed 5.37 ms of CPU time (an average of 0.2 ms per inline action).
The same effect could be achieved with the following changes:
- merge the independent contracts (betdicetoken and betdicegroup and betdicelucky) into a single contract.
- Once merged all of the inter-contract communication can be eliminated. DICE tokens can be issued and deposited into respective account holder’s balances without creating any inline actions.
- Allow users to maintain a deposit balance with the betdicegroup. This way users can deposit once, bet many times, withdraw once. This will eliminate the need to communicate with the eosio.token contract multiple times. User account balances can be updated quickly and efficiently internal to the betdice contract without having to notify sender / receiver for every micro-payment.
With a few small optimizations at the application level, I suspect the CPU required to play this dice game could be reduced by 80% or more. Users could play 5x as much before running out of CPU time.
In a not-to-distant upgrade to EOSIO we will enable the application developer to pay for the CPU on a per-transaction basis. This means that users will not require any CPU resources to play the game and the developer can monetize the CPU usage by other means. Under this world, efficient contract development will reduce the capital costs of the application developer by 80% or more. Today’s apps push these costs on to the user which must either buy stake or borrow it.
It is time for application developers to start carefully considering the efficiency of their designs or they will be outcompeted by more efficient and cost effective alternatives.
Intel, Apple, and Microsoft can only improve application performance so much though improving their hardware and operating systems. The largest performance gains are in the hands of application developers. The same applies to blockchain applications.
原文链接/Original URL:
