DAWN-472 ⁃ Bandwidth Rate Limiting & Storage Usage Limits

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

---

bytemaster opened this issue on 6 Sep 2017

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

Types of Consensus

1 Soft Consensus - enforced only by block producers

2 Hard Consensus - enforced by all full nodes

共识类型

1，软共识-只能由区块生产者强制执行

2，硬共识-由所有完整节点强制执行

Resource Types

1 Bandwidth (rate limited, soft consensus)

2 Computation (rate limited, soft consensus)

3 Database (locks tokens until released, hard consensus)

4 IPFS (locks tokens until released, hard consensus)

5 Print Log (per-contact stdout)

6 Event Log (per-contact structured output)

资源类型

1，带宽（限速，软共识）

2，算力（限速，软共识）

3，数据库（锁仓直到代币释放，硬共识）

4，IPFS（锁仓直到代币释放，硬共识）

5，输出记录（每次contact stdout输出）

6，事件记录（每次contact 结构化输出）

Measuring Resources

1 Bandwidth - binary size of processed transaction as it exists in block

2 Computation - all transactions assumed to consume max quantum (1 ms) of CPU.

    ◦ Each scope has its own measure of average use and all scopes (read or write) charge for 1 ms

3 Database - based on size of created / released records + estimated overhead

4 IPFS - based on the size of the declared file and only after producer confirms it as stored

资源测量

1，带宽- 已经在区块中打包处理的交易用二进制格式

2，算力- 假设所有交易都需要用到最大量程（1毫秒）的CPU

    ◦ 每一级别都有平均使用的测速器，所有级别（包括输入和输出）的负载都在1毫秒的范围内

3，数据库- 基于创建／发布记录的规格+预算

4, IPFS- 基于公告文件的大小，并在区块打包者确认存储之后

Who to Bill

In this case billing applies to which account has their resource usage adjusted.

1 Bandwidth - the user(s) who authorized the transaction (all billed equally even if it double bills)

2 Computation - the user(s) who authorized the transaction (all billed equally even if it double bills)

3 Database - the code account which executes the transaction

4 IPFS - the user who requests the file be stored in their account and can delete at will

谁来付费

以下资源使用情况有变动的用户需要付费：

1，带宽- 授权交易的用户（每一个账单权重相当，即使总数翻倍）

2，算力- 授权交易的用户（每一个账单权重相当，即使总数翻倍）

3，数据库- 执行交易的代码账户

4，IPFS- 允许文件存储并有删除权限

Challenges

The biggest challenge with all resource usage is to perform these calculations in a way that does not force everything into a single thread. The second biggest challenge is how to build blocks incrementally while doing resource calculations in parallel.

1 the authorizing accounts are independent of the scopes and we would like to avoid looping them into the scope.

2 the code account (used to bill storage) is often different from scope accounts (eg currency contact)

3 storage and bandwidth use isn't known until after applying the transaction

4 The order in which transactions are applied impacts the global usage and therefore the fractional reserve status on the various resources. This means there must be a deterministic means of updating this data.

挑战

所有资源使用最大的挑战是不强制用单线程的方式执行，第二大挑战是怎么在计算资源的同时逐步构建每一部分的架构。

1，授权账户独立于应用范围，我们希望它们能避免循环到应用范围中

2，代码账户（用于记账存储）通常和应用范围的账户（例如资金联系人）不同

3，直到申请交易后才知道使用的存储和带宽

4，需要解决的交易顺序会影响全局的使用情况，也会影响各种资源的预留情况。这需要有确定性的手段来及时更新这些数据

Potential Solutions

1 resource usage data is "constant" during a block and updated "between" blocks.

◦ this works well for rate limiting

◦ this does not work for storage (people can get double storage)

2 apply resource usage as a 2nd pass validation over the elements in a cycle

◦ this allows us to pipeline resource usage updates with the next cycle

◦ this may cause us to invalidate previously included transactions

▪ this is like a branch miss-prediction and forces us to reset and re-apply a cycle and every cycle after it.

潜在的解决方案

1，在一个区块中，资源使用数据是 “ 恒定的 ” 并会在区块 “ 之间 ” 更新

  ◦ 这对限速很有用

  ◦ 这对存储不管用（大家可以得到两份存储）

2，在流程中将资源使用情况作为二次验证

  ◦ 这允许在下一次流程中加入资源使用更新情况

  ◦ 这会导致之前的交易失效

      ▪ 这就像是一个预测错误的分支，驱动我们在每一个周期结束之后都重新设置架构流程，加快迭代

Goals

1 Enable Free Applications for Users

2 Enable Developers to cover User Costs

3 Don't make developers re-invent rate limiting

4 Don't expose users to unexpected fees

5 Keep things as soft consensus and not part of validation consensus

From a platform perspective these goals are conflicting. If applications cover the costs then applications must implement their own rate limiting algorithm to prevent abuse and that also means the rate limiting is part of the hard consensus.

目标

1，让用户免费使用应用程序

2，让开发者承担用户成本

3，不让开发者重新定义限速

4，不公开用户意料之外的费用

5，保持一致的软共识，而不是验证其中的共识

从平台角度来看，这些目标是自相矛盾的。如果应用程序承担费用，那它们肯定需要执行自己的限速算法来防止被滥用，这也意味着限速是硬共识的一部分

Assumptions

1 User's can control if they transact and thus to spam or not to spam

2 Application code controls allocation and release of storage

3 Most users can transact with a very small balance

4 Storage locks tokens until it freed

假定

1，用户可以决定是否交易，是否接收垃圾邮件

2，应用程序的代码可以决定存储的分配和释放状态

3，大多数用户可以小额交易

4，直到代币释放之前，存储需要锁定代币

High Level Approach

1 Charge rate-limited resources to users

2 Charge database resources to application

3 Charge IPFS to user

高级方法

1，向用户收取资源限速的费用

2，向应用程序收取数据库资源的费用

3，向用户收取IPFS的费用

Principles

1 User's initiate consumption of resources and are

Each write-scope implies a single-threaded throughput limit and maintains its own independent accounting of how many computation units an individual user has consumed in that scope.

Note: this issue is still under development and will need to be defined in greater detail before work can begin.

原则

1，用户开始资源消耗，每一个纳入范围的用户都意味着是限制于单线程吞吐量的，并且自己维持独立核算单个用户在该范围内消耗的单数。

注意：这个问题仍在讨论中，在开始运行之前需要定义更多细节。

---

bytemaster commented on 6 Sep 2017

bytemaster 在2017年9月6日回复了帖子

Proposed Design

Bandwidth rate limiting (BRL) will automatically limit computational usage if we assume that each message uses the maximum allowed computational time. If BRL is not part of hard consensus, then it can be implemented using any algorithm that an individual producer wants, including billing bandwidth sequentially as transactions come in, using locks, etc.

Each transaction contains a number of messages and each message defines a set of provided permissions which include the account authorizing the transaction.

  for each authorizing_account

    decay_bandwidth_used_since_last_update

    increment_bandwidth_used by trxsize / num_auth_accounts

    assert( bandwidth_used < allowed_bandwidth_per_staked_token )

提出设计

假设每一条信息处理用最快的计算时间，带宽速率限制（BRT）将自动限制计算的使用。如果带宽速率限制不是硬共识的一部分，生产商可以使用任何算法来实现，包括交易时按照带宽计费，使用锁定功能等等。

每个交易包含的大量信息中的每一条，都决定着一系列提供的权限，其中包括授权交易的账户。

All of these calculations should be implemented in the producer plugin and not in the chain plugin.

The only consensus state information needed for this is the current staking balance. All other information can be tracked by nodes outside the consensus process.

All full nodes need to run this, not just producers. Anyone participating in P2P network needs to help limit abuse.

所有的算法都应该在生产者插件而不是在链上插件中实现。

目前唯一的共识状态信息是找到平衡点，在达成共识的进程之外的节点再逐一解决。

不仅仅是生产者，所有完整的节点都需要用到它。每一个参与P2P网络的人都应该一起抵制滥用行为。

（本文未完待续）

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

翻译：Lochaiching

校正：Sheldon

本文首发于“EOS技术爱好者”微信公众号

这篇文章对你有用的话，可以用erc-20钱包扫描以下二维码给我们赞赏哟～

二维码原文地址：0xBdE77CaFFf33970322c0F1f59F6B047de3AC88F9