【EOS干货】带宽速率限制和存储使用限制（第五篇）

bytemaster opened this issue on 6 Sep 2017

bytemaster在2017年9月6日开始了这个话题

本文是本系列文章的第5篇，也是最后一篇。

bytemaster commented on 8 Sep 2017

bytemaster在2017.9.8回复了这个帖子：

The atomic algorithm above can get quirky and may impact overall performance by forcing cache syncs. To avoid atomics all together each cycle will need to be generated in phases:

1 apply all transactions in cycle and calculate storage delta (store on context)

2 apply map reduce techniques to sum all storage deltas

3 identify any accounts that exceed their storage allocation

4 if any fail then undo all threads in cycle that reference over used contract

5 reapply transactions in those threads skipping transactions that participated in overflow

上面的原子算法可能会变得有点奇怪，可能会因为强制同步缓存而影响整体性能。为了避免所有原子撞在一起，需要分阶段运行：

1，应用流程中的所有交易，并计算存储增量（存储在环境中）

2，应用地图缩减技术来总和所有存储增量

3，记录所有超出其存储分配量的帐号

4，一有失败，就撤消流程中所有被参考使用合约的线程

5，在线程中重新应用之前跳过溢出的交易

This multi-step process makes the cost of producing a block more expensive in the failure event (forcing an undo of a cycle), but should result in relatively simple execution path in the nominal case where it can be pipelined.

这种多步骤的过程使得在故障事件中出块的成本更高（强制撤销整个流程），但在某种程度上它像流水线一样，产生相对简单的执行路径。

Transactions that can assert 0 changes in storage usage are an order of magnitude more efficient because they can be scheduled without the need to sum deltas or the potential for undoing. In fact, transactions that can assert that they will only reduce storage usage can enable potential optimizations by eliminating the potential for failing all transactions.

存储使用情况没有变化的交易可以提高一个数量级的效率，因为它们可以进行调度，无需对累计或撤销的可能性进行求和。事实上可以断言，他们只会减少存储使用量的交易，通过消除可能失败的交易来实现更大的优化。

bytemaster commented on 8 Sep 2017

bytemaster在2017.9.8回复了这个帖子：

Conclusions:

1 each message shall specify the account to bill storage adjustments to

◦ must be either the code account or one of the authorities authorizing the transaction

2 block producers will do a two-phase cycle production process

◦ apply all of the transactions

◦ adjust all of the storage usage if success

&＃x25aa; mark accounts and threads that exceed limits

&＃x25aa; if any marked then reapply transactions discarding those that failed

3 non producers will do a two-phase application process

◦ apply all of the transactions

◦ adjust all of the storage used fail block if this does not succeed.

&＃x25aa; alternatively, if they trust the producers, they can simply skip the usage check.

4 Replay

◦ during replay it should not be necessary to track all adjustments every block, instead it may be more efficient to do an accounting of size one time at the end.

结论：

1，每条信息应该让指定账号调整记账存储

◦ 必须是代码账户或者其中一个授权交易的授权方

2，出块者将需要两个阶段的生产流程

◦ 申请所有交易

◦ 如果申请成功，调整所有存储的使用情况

&＃x25aa; 标记超出限制的账户和线程

&＃x25aa; 如果已经被标记过了，重新申请那些之前被丢弃的交易

3，非生产者将需要两个阶段的申请流程

◦ 申请所有交易

◦ 如果不成功，调整所有存储失败的块

&＃x25aa; 或者，它们信任出块者的话，可以直接跳过这个过程使用检查

4，重播

◦ 在重播期间，没有必要追踪每一块的所有调整，在最后计算大小会更有效率

learnforpractice commented on 13 Sep 2017

learnforpractice在2017.9.13 回复了这个帖子

Should we limit the creation of account name too? Without limitation, good names will soon be exhausted.

我们是不是也因要限制账号的注册？没有限制的话，好名字很快就会被用完了。

（本长篇译文完结）

本文链接：https：//github.com/EOSIO/eos/issues/353

翻译：Lochaiching

校正：Sheldon

更多内容，扫描以下二维码关注“EOS技术爱好者”！

这篇文章对你有用的话，可以用ERC-20钱包扫描以下地址给我们赞赏哟〜

二维码原文地址：0xBdE77CaFFf33970322c0F1f59F6B047de3AC88F9