【EOS干货】BM：带宽速率限制和存储使用限制（第三篇)

DAWN-472 ⁃ Bandwidth Rate Limiting & Storage Usage Limits

DAWN-472 带宽速率限制和存储使用限制

BM

bytemaster opened this issue on 6 Sep 2017

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

这是长篇系列中的第三篇，第一篇链接点击此处，第二篇链接点击此处

---

bytemaster commented on 7 Sep 2017

bytemaster在2017年9月7日回复了这个帖子

Database Memory Accounting

Currency Contract - on creation of new balances or emptying of balances

Exchange Contract - no overhead, accounting and app storage already in same scope

Social Media - every post and vote increases storage in scopes other than social

Escrow Contract - can reserve all space at time of creation, subsequent updates need not included Escrow scope.

数据库内记账

货币合约 - 创建余额或清空余额

交易合约 - 没有间接费用，账本和应用程序存储在一起

社交媒体 - 每一个帖子和投票除了增加了社交意义之外，存储在数据库的内容也会相应增加

托管合同 - 创建时保留所有空间，后续更新不涵盖托管范围的内容

Solutions

Make the billing flexible so that developers can pass the expense (and locking requirements) on to their users. In this case the transaction would declare which scope to bill for storage. It can either be the "authorizing account" or the "contract account" as these are the two parties to the execution of the message.

解决方案

为了灵活计费以及方便开发者将费用（和锁定要求）发送给用户。在这种情况下，交易会明确指出需要付费的存储范围有哪些。它们是执行消息的两方，可以是“授权方”也可以是“合同方”。

With this arrangement, an escrow contract could ask the escrow-creator to pay the cost of storage. The creator would know the storage will be freed at the end of the transaction and therefore it will be a net cost of 0 EOS to use the escrow contract.

通过这种设计，托管合同可以要求创建托管的人支付存储成本。在交易结束后，存储将会被释放，因此使用托管合同的成本是0 EOS。

Under this arrangement the "voter" or "poster" would cover the cost of creating the storage for their vote, but again they could recover the cost when the post or vote expires.

这种设计，让“选民”或“广告”承担创建存储的选择投票成本，同时可以在失效后收回成本。

This technique gives contract developers the greatest flexibility, but may push the problem back to user experience in either requiring temporary holding of EOS or requiring locking of the contract scope.

这种技术为合同开发者提供了最大的灵活性，但问题可能会出现在用户体验中，在这两者中，要么需要临时持有EOS，要么需要锁定合同范围。

Note about Design History

Original design of EOS required all contracts to keep their state within their own scope and thus the billing / scoping / parallelism constraints were not a problem. This added design complexity around storage billing is a result of a breakthrough in enabling more scalable apps via user-local storage rather than contract-side storage. Our goal is to keep the performance benefits of user-local storage without abuse-prevention accounting getting in the way.

关于设计历史记录

EOS最初的设计是要求所有合同保持在自己范围内，因此计费 / 范围 / 并行约束的问题不需要担心。由于通过用户本地存储而不是合同存储，实现了更多可扩展性应用的突破，这也增加了有关存储计费设计的复杂性。我们的目标是保持用户本地存储的性能优势，防止出现滥用账户的问题。

（本文未完待续）

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

翻译：Lochaiching

校正：Sheldon

扫描二维码，关注“EOS技术爱好者”！

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

二维码原文地址：0xBdE77CaFFf33970322c0F1f59F6B047de3AC88F9