EOS創(chuàng)始人BM:帶寬速率限制和存儲(chǔ)使用限制（第一篇）

DAWN-472 ? Bandwidth Rate Limiting & Storage Usage Limits

（EOS創(chuàng)始人BM）

bytemaster opened this issue on 6 Sep 2017

bytemaster 2017年9月6日開始了這個(gè)話題

Types of Consensus

1Soft Consensus - enforced only by block producers

2Hard Consensus - enforced by all full nodes

共識類型

1,軟共識-只能由區(qū)塊生產(chǎn)者強(qiáng)制執(zhí)行

2,硬共識-由所有完整節(jié)點(diǎn)強(qiáng)制執(zhí)行

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,數(shù)據(jù)庫(鎖倉直到代幣釋放,硬共識)

4,IPFS(鎖倉直到代幣釋放,硬共識)

5,輸出記錄(每次contact stdout輸出)

6,事件記錄(每次contact 結(jié)構(gòu)化輸出)

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,帶寬- 已經(jīng)在區(qū)塊中打包處理的交易用二進(jìn)制格式

2,算力- 假設(shè)所有交易都需要用到最大量程(1毫秒)的CPU

?每一級別都有平均使用的測速器,所有級別(包括輸入和輸出)的負(fù)載都在1毫秒的范圍內(nèi)

3,數(shù)據(jù)庫- 基于創(chuàng)建/發(fā)布記錄的規(guī)格+預(yù)算

4, IPFS- 基于公告文件的大小,并在區(qū)塊打包者確認(rèn)存儲(chǔ)之后

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

誰來付費(fèi)

以下資源使用情況有變動(dòng)的用戶需要付費(fèi):

1,帶寬- 授權(quán)交易的用戶(每一個(gè)賬單權(quán)重相當(dāng),即使總數(shù)翻倍)

2,算力- 授權(quán)交易的用戶(每一個(gè)賬單權(quán)重相當(dāng),即使總數(shù)翻倍)

3,數(shù)據(jù)庫- 執(zhí)行交易的代碼賬戶

4,IPFS- 允許文件存儲(chǔ)并有刪除權(quán)限

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.

挑戰(zhàn)

所有資源使用最大的挑戰(zhàn)是不強(qiáng)制用單線程的方式執(zhí)行,第二大挑戰(zhàn)是怎么在計(jì)算資源的同時(shí)逐步構(gòu)建每一部分的架構(gòu)。

1,授權(quán)賬戶獨(dú)立于應(yīng)用范圍,我們希望它們能避免循環(huán)到應(yīng)用范圍中

2,代碼賬戶(用于記賬存儲(chǔ))通常和應(yīng)用范圍的賬戶(例如資金聯(lián)系人)不同

3,直到申請交易后才知道使用的存儲(chǔ)和帶寬

4,需要解決的交易順序會(huì)影響全局的使用情況,也會(huì)影響各種資源的預(yù)留情況。這需要有確定性的手段來及時(shí)更新這些數(shù)據(jù)。

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,在一個(gè)區(qū)塊中,資源使用數(shù)據(jù)是 “ 恒定的 ” 并會(huì)在區(qū)塊 “ 之間 ” 更新

?這對限速很有用

?這對存儲(chǔ)不管用(大家可以得到兩份存儲(chǔ))

2,在流程中將資源使用情況作為二次驗(yàn)證

?這允許在下一次流程中加入資源使用更新情況

?這會(huì)導(dǎo)致之前的交易失效

?這就像是一個(gè)預(yù)測錯(cuò)誤的分支,驅(qū)動(dòng)我們在每一個(gè)周期結(jié)束之后都重新設(shè)置架構(gòu)流程,加快迭代

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.

目標(biāo)

1,讓用戶免費(fèi)使用應(yīng)用程序

2,讓開發(fā)者承擔(dān)用戶成本

3,不讓開發(fā)者重新定義限速

4,不公開用戶意料之外的費(fèi)用

5,保持一致的軟共識,而不是驗(yàn)證其中的共識

從平臺角度來看,這些目標(biāo)是自相矛盾的。如果應(yīng)用程序承擔(dān)費(fèi)用,那它們肯定需要執(zhí)行自己的限速算法來防止被濫用,這也意味著限速是硬共識的一部分。

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,應(yīng)用程序的代碼可以決定存儲(chǔ)的分配和釋放狀態(tài)

3,大多數(shù)用戶可以小額交易

4,直到代幣釋放之前,存儲(chǔ)需要鎖定代幣

High Level Approach

1Charge rate-limited resources to users

2Charge database resources to application

3Charge IPFS to user

高級方法

1,向用戶收取資源限速的費(fèi)用

2,向應(yīng)用程序收取數(shù)據(jù)庫資源的費(fèi)用

3,向用戶收取IPFS的費(fèi)用

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,用戶開始資源消耗,每一個(gè)納入范圍的用戶都意味著是限制于單線程吞吐量的,并且自己維持獨(dú)立核算單個(gè)用戶在該范圍內(nèi)消耗的單數(shù)。

注意:這個(gè)問題仍在討論中,在開始運(yùn)行之前需要定義更多細(xì)節(jié)。

bytemaster commented on 6 Sep 2017

bytemaster 在2017年9月6日回復(fù)了帖子

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 )

提出設(shè)計(jì)

假設(shè)每一條信息處理用最快的計(jì)算時(shí)間,帶寬速率限制(BRT)將自動(dòng)限制計(jì)算的使用。如果帶寬速率限制不是硬共識的一部分,生產(chǎn)商可以使用任何算法來實(shí)現(xiàn),包括交易時(shí)按照帶寬計(jì)費(fèi),使用鎖定功能等等。

每個(gè)交易包含的大量信息中的每一條,都決定著一系列提供的權(quán)限,其中包括授權(quán)交易的賬戶。

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.

所有的算法都應(yīng)該在生產(chǎn)者插件而不是在鏈上插件中實(shí)現(xiàn)。

目前唯一的共識狀態(tài)信息是找到平衡點(diǎn),在達(dá)成共識的進(jìn)程之外的節(jié)點(diǎn)再逐一解決。

不僅僅是生產(chǎn)者,所有完整的節(jié)點(diǎn)都需要用到它。每一個(gè)參與P2P網(wǎng)絡(luò)的人都應(yīng)該一起抵制濫用行為。

(本文未完待續(xù))

翻譯:Lochaiching

校正:Sheldon

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。