DAWN-472 ⁃ Bandwidth Rate Limiting & Storage Usage Limits
（EOS创始人BM）
bytemaster opened this issue on 6 Sep 2017
bytemaster 2017年9月6日开始了这个话题
Types of Consensus
1Soft Consensus - enforced only by block producers
2Hard Consensus - enforced by all full nodes
共识类型
1,软共识-只能由区块生产者强制执行
2,硬共识-由所有完整节点强制执行
Resource Types
1Bandwidth (rate limited, soft consensus)
2Computation (rate limited, soft consensus)
3Database (locks tokens until released, hard consensus)
4IPFS (locks tokens until released, hard consensus)
5Print Log (per-contact stdout)
6Event Log (per-contact structured output)
资源类型
1,带宽(限速,软共识)
2,算力(限速,软共识)
3,数据库(锁仓直到代币释放,硬共识)
4,IPFS(锁仓直到代币释放,硬共识)
5,输出记录(每次contact stdout输出)
6,事件记录(每次contact 结构化输出)
Measuring Resources
1Bandwidth - binary size of processed transaction as it exists in block
2Computation - 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
3Database - based on size of created / released records + estimated overhead
4IPFS - 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.
1Bandwidth - the user(s) who authorized the transaction (all billed equally even if it double bills)
2Computation - the user(s) who authorized the transaction (all billed equally even if it double bills)
3Database - the code account which executes the transaction
4IPFS - 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.
1the authorizing accounts are independent of the scopes and we would like to avoid looping them into the scope.
2the code account (used to bill storage) is often different from scope accounts (eg currency contact)
3storage and bandwidth use isn't known until after applying the transaction
4The 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
1resource 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)
2apply 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
1Enable Free Applications for Users
2Enable Developers to cover User Costs
3Don't make developers re-invent rate limiting
4Don't expose users to unexpected fees
5Keep 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
1User's can control if they transact and thus to spam or not to spam
2Application code controls allocation and release of storage
3Most users can transact with a very small balance
4Storage locks tokens until it freed
假定
1,用户可以决定是否交易,是否接收垃圾邮件
2,应用程序的代码可以决定存储的分配和释放状态
3,大多数用户可以小额交易
4,直到代币释放之前,存储需要锁定代币
High Level Approach
1Charge rate-limited resources to users
2Charge database resources to application
3Charge IPFS to user
高级方法
1,向用户收取资源限速的费用
2,向应用程序收取数据库资源的费用
3,向用户收取IPFS的费用
Principles
1User'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网络的人都应该一起抵制滥用行为。
(本文未完待续)
翻译:Lochaiching
校正:Sheldon
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
