economics_in_sharded_blockchain

分片鍊的經濟

原著：Illia Polosukhin 和 團隊 推特：/ilblackdragon 郵箱： [email protected] 2019年8月

原文連結：https://near.org/papers/economics-in-sharded-blockchain/

翻譯：Marco     校對：Sissi     編輯：Buster

由于本文包含較多Ketex格式的公式，推薦戳這裡檢視完美編輯版。

文章目錄

• 1 導言
• 2 背景
• 3 獎勵
• 4 交易和存儲費
• • 4.1 算力與帶寬的定價
  • 4.2 計算限制
  • 4.3 狀态存儲的定價
• 5 驗證人
• • 5.1 驗證人選擇
  • 5.2 獎勵
  • 5.3 權益的罰沒
  • 5.4 權益的撤回
  • 5.5 委托
• 6 開發者商業模型
• 7 協定财庫
• 8 未來工作
• 參考文獻
• 名詞解釋
• • 驗證人
  • 開發者
  • 使用者
  • Token持有者
  • 協定治理實體
  • 動态分片

1 導言

激勵在任何去中心化協定中都是一個至關重要的部分。這些激勵要在為所有協定參與者提供價值和確定協定的未來發展之間找到平衡。

由于分片智能合約鍊的目标是從根本上為使用者和開發者提供一個可用性最佳的網絡，在設計系統時要加入許多考量，以確定所有參與者的積極行為。下面我們回顧特定的，不可或缺的經濟決策及其背後的邏輯。

在第二節，我們回顧動态分片PoS鍊（參見定義2.1）、目前主流PoW鍊以及PoS鍊的差異。在背景一節的許多定義都将參考夜影協定[4]。

在PoS平台中有一些不同的角色。這些角色之間并不是完全互斥（例如，一個驗證人也可以是一個開發者），但因為各方關注點和目标的不同，這種（角色的）差別是有益的。

• 驗證人 - 提供網絡上的計算能力、存儲能力和安全性，同時根據協定獲得回報。
• 開發者 - 在協定底層基礎設施上建構有益的應用。
• 使用者 - 應用和平台自身的使用者，他們受利益的趨勢。而利益來自于（使用）應用和平台的那些互動。
• 代币持有人 - 協定（本地）代币的持有者，要麼為了将來的使用要麼提供了流動性。
• 協定治理實體 - 負責網絡發展和治理的實體。可以是個DAO和/或一個非營利性的基金會。

顯式地分離出協定治理實體，使我們可以在設計獎勵系統時，将其資本需求列入（詳情參見第7節）。

在管理各方各種各樣的優先權時，需要仔細的平衡。下面我們将在第5節介紹驗證人的經濟激勵，在第6節介紹開發者的。

2 背景

研究最多的區塊鍊網絡是比特币和以太坊。這些系統存在固有的網絡能力限制（交易吞吐量和存儲方面），因為它們工作起來類似單台計算機。

與這些網絡相反，分片區塊鍊的擴充能力與參與節點的數量呈線性相關 - 各個分片可以并行地接受和處理交易。特别是動态分片區塊鍊，能夠通過在變化的環境中再平衡負載的方式管理網絡，使其幾乎不再面臨性能問題。

定義 2.1. 動态分片。一個動态分片系統是指一個系統，可以動态地重新配置資料分區和處理，而無需關閉作業系統。這使得它能平衡CPU/存儲資源以維持負載水準，并根據需求的變化擴充或縮減規模。

我們将着重介紹“夜影”的分片設計細節（Skidanov and Polosukhin [4]）的細節，它試圖以一個有效的方式解決“權益分片”的問題。

因為重新分片的存在，一個應用（或賬戶）并不是由它所在的分片定義。這與靜态分片相反，在那種系統中，開發者可以決定将自己的應用部署到哪個分片。在靜态分片系統中，由于其資料和資産的依賴關系，我們會觀察到應用在單個分片上的集中現象。

例如，許多應用會想與MakerDAO位于同一個分片，為使用者提供一種可與DAI互動且無需額外間接費用的方式。這就意味着在那個分片上會有相比其他分片更多的DAI需求。同時，也會有更多的ETH需求，因為MakerDAO的使用者需要在價格變動時能快速的反應，結束他們的抵押債務頭寸。這些（需求）都産生了非常執着的刺激，違背了網絡擴充的想法。

由于動态分片系統中的再平衡，該問題得到了緩解。因為“紮堆”部署應用的動機已不存在。

為了解決“權益分片”的問題，也就是每個分片隻有整個系統安全性的一個小子集。“夜影”的設計中将選中的驗證人分成兩個組：出塊人（或收集人）和“隐藏的”驗證人。

出塊人負責接收交易，産生段，互相間交換段以及段中的顆粒，同時保持對系統中其他各方的資料可用性。

“隐藏的”驗證人分布在所有的分片，檢查出塊人，確定他們建立正确的塊，以及資料是切實可用的。以此為系統提供安全性。

因為驗證人是隐藏的，也不出塊。例如，在驗證人額分片之間沒有已知的配置設定關系。協定實際上無法在出塊的時刻直接配置設定獎勵給驗證人。取而代之，驗證人在周期的尺度上獲得他們的工作獎勵。詳情參見5.2節。

盡管分片系統要求分片内的交易和跨分片的交易（大部分都是）差別定價，動态分片支援統一收費，移除了跨分片和分片内交易之間的價格差異。

3 獎勵

任何區塊鍊協定中，驗證人（或PoW中的礦工）提供他們的資源（算力，存儲，網絡），換得獎勵。這些獎勵通常是coinbase（鑄造出的新的内置代币）與交易費的結合。

在“夜影”設計中，作為上述内容的細節，所有的邏輯都在“周期”層面。每N個塊，驗證人被選出并輪換。是以，我們也定義了每個周期的獎勵。每個周期的末尾，獎勵會在驗證人，開發者和協定财庫之間配置設定。

總的周期獎勵如下計算：

e p o c h R e w a r d t = c o i n b a s e R e w a r d t + e p o c h F e e s t (1) epochReward_t = coinbaseReward_t + epochFees_t \tag{1} epochRewardt​=coinbaseRewardt​+epochFeest​(1)

這裡， e p o c h F e e s t epochFees_t epochFeest​是來自周期 t t t中所有塊裡的費用，包括交易費和狀态租金。注意： e p o c h F e e s epochFees epochFees中不包括使用者支付費用中直接歸屬應用的那部分。有關費用是如何定價和計算的更多細節請看 第4節 費用。

因為鑄造新的代币實際上是對代币持有者（尤其那些不是活動驗證人的使用者和開發者）抽稅。一般來說傾向于最小化coinbase。然而，過小的coinbase加上不足的費用，可能減少驗證人提供算力和資本的興趣，而那些是安全性所需的。

以比特币為例，初始設計是讓coinbase每四年減半，目的是最終徹底通過費用維持網絡。但由于目前最長鍊網絡的激勵機制，交易獎勵隻給出塊人，當coinbase達到0時，存在衆所周知的不穩定性問題(Carlsten et al. [2])。

是以，我們建議一個系統設定一個最大coinbase作為頂，然後根據系統中總費用的數量動态減少coinbase。這樣可以保證有一個最小的周期獎勵，然後随着使用量的增加，減少通脹。

要計算實際的coinbase獎勵，我們首先計算每個周期的最大通脹：

m a x C o i n b a s e = t o t a l S u p p l y t × ( 1 + m a x I n f l a t i o n n u m E p o c h s P e r Y e a r − 1 ) (2) maxCoinbase = totalSupply_t \times (\sqrt[numEpochsPerYear]{1+maxInflation} - 1) \tag{2} maxCoinbase=totalSupplyt​×(numEpochsPerYear1+maxInflation

​−1)(2)

這裡， t o t a l S u p p l y t = i n i t i a l S u p p l y + ∑ i = 0 t − 1 c o i n b a s e R e w a r d i totalSupply_t = initialSupply + \sum_{i=0}^{t-1}coinbaseReward_i totalSupplyt​=initialSupply+i=0∑t−1​coinbaseRewardi​，意味着它是在給定周期 t t t時，系統中代币的總數量。

有了 m a x C o i n b a s e maxCoinbase maxCoinbase，我們可以計算給定周期的 c o i n b a s e R e w a r d coinbaseReward coinbaseReward：

c o i n b a s e R e w a r d t = { 0 e p o c k F e e s t ≥ m a x C o i n b a s e m a x C o i n b a s e − e p o c h F e e s t o t h e r w i s e (3) coinbaseReward_t = \begin{cases} 0 & epockFees_t \geq maxCoinbase \\ maxCoinbase-epochFees_t & otherwise \end{cases} \tag{3} coinbaseRewardt​={0maxCoinbase−epochFeest​​epockFeest​≥maxCoinbaseotherwise​(3)

意思是，如果給定周期的總費用大于coinbase的最大值，費用本身就提供了足夠的激勵，該周期的coinbase實際上可以為0。否則，總的費用将使通脹減少相應的數量。

4 交易和存儲費

每筆交易的開銷都有若幹不同的部分組成：接受和發送交易的開銷（帶寬），處理的開銷（尤其一個複雜的狀态轉換/智能合約時）（CPU），以及狀态存儲（為了一直保持資訊往前更新）的開銷。

由于算力和帶寬可以與每筆交易同時收取，是以可組合成一個量，通常稱為交易費（transaction fee），記做 t x F e e i n d e x txFee_{index} txFeeindex​。

另一方面，狀态在交易之間持久地儲存，我們需要負責某個分片的所有驗證人都保證狀态是可用的。這個動态租用本身天然就是個“租賃模型”，這裡面，機關時間存儲資料的費用由賬戶（accounts）支付。我們在4.3節詳細介紹 s t a t e R e n t stateRent stateRent的機制。

第3節中，我們用 e p o c h F e e t epochFee_t epochFeet​，代表周期（epoch）結尾時要給與驗證人的所有獎勵。這個值是由該周期中所有的狀态租賃費和 ( 1 − d e v e l o p e r P c t ) (1 − developerPct) (1−developerPct)的交易費組合而成：

e p o c h F e e t = ∑ i = f i r s t B l o c k t l a s t B l o c k t ( 1 − d e v o l o p e r P c t ) × t x F e e i + s t a t e F e e i (4) epochFee_t = \sum_{i=firstBlock_t}^{lastBlock_t}(1-devoloperPct) \times txFee_i + stateFee_i \tag{4} epochFeet​=i=firstBlockt​∑lastBlockt​​(1−devoloperPct)×txFeei​+stateFeei​(4)

4.1 算力與帶寬的定價

如上所述，算力和帶寬組合成一個量，通常用“gas”表示，定義了每筆交易使用的資源數量。

1條CPU指令與1個位元組帶寬之間的确切關系留給細節實作。一般來說，指定交易的總“gas”可以如下計算：

g a s t x = n u m b e r O f C P U I n s t r u c t i o n s ( t x ) + α × S i z e O f ( t x ) (5) gas_{tx} = numberOfCPUInstructions(tx) + \alpha \times SizeOf(tx) \tag{5} gastx​=numberOfCPUInstructions(tx)+α×SizeOf(tx)(5)

這裡 α \alpha α代表一個機關算力與一個機關帶寬之間的相對關系。通常這是個常數（如果其關系有徹底的改變，可以通過治理調整它）。 S i z e O f ( t x ) SizeOf(tx) SizeOf(tx)代表占用線路（比如：帶寬）傳輸交易時以位元組為機關的大小。

每筆交易必須在其資料中指定它需要的gas數量。這能讓出塊人在實際執行一個塊之前就粗略估算到時會用到多少gas（比如，他們要先建立一個塊，之後才執行它）。

這個數量可以比預期使用的量高一些，因為未使用的gas會在所有交易完成（所有分片上的全部收據處理完畢）後傳回給交易的支付者。如果一筆交易包含的gas（在處理時）不足以執行某個方法，交易将提前終止并失敗，但已使用的gas不會返還。

給定某筆交易的gas數量之後，我們使用一個系統範圍的變量 g a s F e e gasFee gasFee，以NEAR代币計算費用。這個變量定義了以原生代币計量的一機關gas目前價格。

關于該變量有以下一些考量：

• 不同的分片可能會有不同的交易負載，但由于存在跨分片互動，價格因分片而異對開發者來說是極度不友好的。例如，一個通路3-4個分片的交易需要支付每個分片上不同且不可預測的交易費。
• 動态分片（在2.1中定義）提供了再平衡技術，可以在分片間維持一個大略平衡的負載。除此以外，考慮到再平衡不是一個立即結束的過程，是以在短期内，會有一些分片遭遇堵塞。
• 開發者和使用者希望一個低廉的 g a s F e e gasFee gasFee，但是可預測性相對來說更重要。類似系統使用者的主要關切之一就是gas價格的高度不可預測性。
• 對每個塊 i n d e x index index，區塊鍊上可以觀察到以下兩個内容：
  • g a s L i m i t i n d e x gasLimit_{index} gasLimitindex​, 該index下每個分片允許的最大gas數量（所有分片都一樣）
  • g a s U s e d i n d e x , s h a r d gasUsed_{index,shard} gasUsedindex,shard​, 該index下每個分片實際使用的gas數量
• 為了幫助預測gas價格，我們定義一個“滑動價格”： g a s P r i c e = g a s P r i c e × ( 1 + ( g a s U s e d g a s L i m i t − 1 2 ) × a d j F e e ) gasPrice=gasPrice\times(1+(\frac{gasUsed}{gasLimit}-\frac{1}{2})\times adjFee) gasPrice=gasPrice×(1+(gasLimitgasUsed​−21​)×adjFee)這裡的 a d j F e e adjFee adjFee定義了經過每個塊後 g a s P r i c e gasPrice gasPrice可以變動多少。

這與Buterin [1] 裡的定價模型類似，差別是我們不用 m i n P r i c e + minPrice+ minPrice+ 小費（tip），僅定義 g a s P r i c e gasPrice gasPrice作為标準價格。

另一種可能的攻擊來自于驗證人積累了大量的交易并用它們沖擊區塊，以此提高 g a s P r i c e gasPrice gasPrice。可以在交易上附加嚴格的過期時間（TTL）以解決該問題。這将使在一個長的時段内收集交易成為無用功。

有個需要考慮的問題是， g a s P r i c e gasPrice gasPrice可能低于接收交易和傳播它給其他驗證人的邊際成本（例如，帶寬成本）。（盡管）驗證人此時仍然會接收交易，其動機是：讓交易費實際回升，保持網絡運作（從長期看，這對他們以及系統中的持币者有利）以及降低他們質押資産的通脹速度。（但）為了防止這個問題（gasPrice過低），我們定義 m i n G a s P r i c e minGasPrice minGasPrice作為gas價格的底限。這也有助于防止價格計算中的取整錯誤（價格過低可能導緻取整為0的問題）。

值得強調的是，這個價格是所有分片統一的。這樣就簡化了網絡的使用，因為現在發起一個跨分片的交易時，能提前知道價格，并且易于計算（費用）。

這種做法的負面效果是，如果一個（或若幹）分片已達到其容量而其餘的分片很空，gas價格不會上漲。然而，我們相信，最好是依賴于一段時間之後的動态再分片技術去平衡分片，以減輕該問題。而不是為了該問題而引入一個更複雜的機制去調整gas價格。

4.2 計算限制

當加入網絡的因素，我們預期網絡可以處理的計算量也會變化。我們系統節點的主要目标是低端伺服器和桌面終端，當然我們也意識到随着時間流逝，驗證人可用的資源會增加。例如，幾年前的一台高端計算機在現在看來不過是塊廉價的硬體。另外，我們預期軟體将會持續改進，即使相同的硬體，我們計算一個特定任務所占用的實際時間（wall time，linux下程序占用的實際時長）也許會變少。

為了應對該問題，我們建議每個塊上，出塊人投票決定 g a s L i m i t gasLimit gasLimit，在其上附加一個±0.1%的浮動範圍，特别是目前一個塊的 g a s U s e d > 0.9 ∗ g a s L i m i t gasUsed > 0.9 ∗ gasLimit gasUsed>0.9∗gasLimit。

例如，若第 i n d e x index index個塊的 g a s L i m i t gasLimit gasLimit為50,000，則驗證人可以提議的新值範圍是[49,950; 50,050]。

節點為了确定這個限制值該升還是該降，我們要衡量前一個區塊的驗證耗時。如果比預期出塊時間的90%還長，就要降低；否則當花費的比預期時間要短，就要增加該限制值。

這樣就使系統能動态确定一個限制值，而超過50%+1的出塊人都能接受它。

4.3 狀态存儲的定價

由于存儲是與算力、帶寬（它們對驗證人和其他節點是種一次性承擔的開銷）完全不同的資源，狀态空間必須在所有節點上前向存儲。

是以，存儲資源通常會被定錯價格。如果在收錄交易的時候一次性收取，獎勵就歸屬出塊人而其他節點需要繼續儲存資訊。比特币就是個特别明顯的例子，每個節點都要維護全部的UTXO曆史，而隻有收錄交易的礦工收到獎勵。

為了解決這個問題，我們遵循 Buterin [1]中關于狀态租賃的建議。每個賬戶的每個區塊時間都被收取 S t o r a g e P r i c e × S i z e O f ( a c c o u n t ) StoragePrice × SizeOf(account) StoragePrice×SizeOf(account)枚代币。這裡， S i z e O f ( a c c o u n t ) SizeOf(account) SizeOf(account)是賬戶以位元組計數的長度。

如果賬戶餘額低于 m i n B a l a n c e = p o k e T h r e s h o l d × s t o r a g e P r i c e × S i z e O f ( a c c o u n t ) minBalance = pokeThreshold×storagePrice×SizeOf(account) minBalance=pokeThreshold×storagePrice×SizeOf(account)，任何人都可以發送一個特殊交易，清除該賬戶的狀态。作為獎勵，該人獲得一些來自遺留餘額的 p o k e R e w a r d pokeReward pokeReward作為獎勵。并采用下述一些規則：

• 若某筆交易将導緻賬戶餘額低于 m i n B a l a n c e minBalance minBalance，不管是因為轉出資産還是增加賬戶規模，該交易都被視為失敗。
• 如果賬戶有權益抵押，也即， s t a k e d > 0 staked > 0 staked>0，就不能僅僅移除賬戶。取而代之，我們要求一個權益抵押賬戶的 m i n B a l a n c e minBalance minBalance為 m i n B a l a n c e minBalance minBalance 為 4 × e p o c h L e n g t h × s t o r a g e P r i c e × S i z e O f ( a c c o u n t ) 4 × epochLength × storagePrice × SizeOf(account) 4×epochLength×storagePrice×SizeOf(account)。如果再周期的邊界，驗證人的餘額 b a l a n c e < m i n B a l a n c e balance < minBalance balance<minBalance，就取消它的驗證人參選或輪換。

每次（按塊收取狀态租賃費）都更新餘額是不現實的，我們隻在餘額因某個交易産生變動時，才更新賬戶：

• 每個賬戶建立一個字段 S t o r a g e P a i d A t StoragePaidAt StoragePaidAt。
• 目前餘額這樣計算： b a l a n c e − S t o r a g e P r i c e × S i z e O f ( a c c o u n t ) × ( c u r B l o c k − S t o r a g e P a i d A t ) balance−StoragePrice×SizeOf(account)×(curBlock−StorageP aidAt) balance−StoragePrice×SizeOf(account)×(curBlock−StoragePaidAt)
• 更新賬戶時，我們重新計算狀态的尺寸，按上面的公式更新 b a l a n c e balance balance，并更新 S t o r a g e P a i d A t StoragePaidAt StoragePaidAt為目前塊。

盡管存儲的開銷會随着時間變化，但這是個緩慢的過程，并可被網絡參與者的決策（通過一個治理流程）修改。

另一方面，原生代币的價格、驗證人實際支付的價格以及使用者/開發者的預期，它們之間的關系并不穩定。

目前的工作中，我們将 S t o r a g e P r i c e StoragePrice StoragePrice定為常量，不穩定性的問題留待将來解決。

值得一提的是，也有一種休眠賬戶的方式。即折疊其狀态至默克爾樹根。如果後面需要恢複該賬戶，可以取出原始資料（通過周遊曆史區塊資料等方式），默克爾樹根足夠驗證那些資訊，将資料恢複過來。目前，我們并沒有該功能，但預期會在釋出後不久添加進去。

5 驗證人

驗證人在任何區塊賬本系統中都扮演着核心角色。他們收集和排序交易，計算新狀态（執行智能合約）以及為系統中的其他參與者提供資料。

在PoS模型中，系統的安全性和女巫攻擊抗性都來自“權益抵押”機制。這就要求驗證人是持币者，并在賬戶中保持一定數量的餘額。

另外，驗證人在被選中的那段時間中需要保持線上。在（夜影）設計中，我們要求驗證人線上時間超過該門檻值 o n l i n e T h r e s h o l d onlineThreshold onlineThreshold。

5.1 驗證人選擇

通過一個競拍機制選擇驗證人。要成為一個驗證人，節點必須發送一個簽名交易，包含他們要抵押的權益數量以及一個新的用來簽名區塊的公鑰。該秘鑰可以獨立于使用者賬戶的通路秘鑰。這就能将驗證工作和資産保管解耦，還能支援其他用例場景，例如，5.5節介紹的委托。

對目前的驗證人集體來說，收集這些權益抵押交易是沒有動力的。因為這實際上加劇了他們的競争。我們為目前驗證人收集這些交易提供額外的激勵：新的權益抵押人在交易中定義 i n c l u s i o n F e e % inclusionFee\% inclusionFee%，表明下一次将把自身獲得獎勵的該比例給與收集該交易的出塊人。

以一個周期作為收集權益抵押交易的時間視窗。在周期 T − 1 T − 1 T−1的末尾，網絡上的每個人都執行驗證人選擇過程（競拍），以決定周期 T + 1 T + 1 T+1的驗證人。因為，作為驗證人選擇過程的一部分，我們也會在分片間混洗（shuffle）驗證人，這就要求驗證人預先知道其指派的分片以執行分片狀态同步。随着網絡的增長，狀态同步将花費相當的時間，是以我們提前一個周期計算驗證人。

給定收集到的參選人集合，加上已經成為周期 T T T的驗證人，進行以下過程。

• 周期 T T T的驗證人也視為參選人，将其目前抵押的權益視為參選權益，如果有驗證人送出了更高的參選權益，就用其參選權益。
• 對于那些線上時間低于 o n l i n e T h r e s h o l d % onlineThreshold \% onlineThreshold%，或明确表示退出驗證的參選人，移除他們。

• 确定門檻值 s e a t P r i c e seatPrice seatPrice，使所有抵押權益高于該門檻值的抵押權益之和，大于（驗證人）席位數：

  s e a t P r i c e = arg max ⁡ x ∈ V ( ∑ v ∈ V ⌊ s t a k e v x ⌋ ≥ n u m S e a t s ) (6) seatPrice = \argmax_{x\in V} \bigg ( \sum_{v\in V} \lfloor \frac{stake_v}{x} \rfloor \geq numSeats \bigg) \tag{6} seatPrice=x∈Vargmax​(v∈V∑​⌊xstakev​​⌋≥numSeats)(6)

• 對每個滿足 s t a k e v ≥ s e a t P r i c e stake_v \geq seatPrice stakev​≥seatPrice的驗證人，為其配置設定 ⌊ s t a k e v s e a t P r i c e ⌋ \lfloor \frac{stake_v}{seatPrice}\rfloor ⌊seatPricestakev​​⌋個席位，并随機混洗該集合。
• 若結果個數仍然超過 n u m S e a t s numSeats numSeats，則丢棄多餘的。

結果得到一個有序的驗證人指派序列，接下來将其分為兩組：出塊人/出段人，和“隐藏的”驗證人。

5.2 獎勵

為了計算每個驗證人的個體獎勵，先要計算每個周期所有驗證人的總獎勵，是一個百分比形式的 e p o c h R e w a r d epochReward epochReward：

t o t a l V a l i d a t o r R e w a r d t = ( 1 − p r t o c o l P c t ) × ( c o i n b a s e R e w a r d s t + e p o c h F e e s t ) (7) totalValidatorReward_t = (1-prtocolPct) \times (coinbaseRewards_t + epochFees_t) \tag{7} totalValidatorRewardt​=(1−prtocolPct)×(coinbaseRewardst​+epochFeest​)(7)

然後在驗證人中按相同比例配置設定 t o t a l V a l i d a t o r R e w a r d totalValidatorReward totalValidatorReward，不管他們實際是出塊人還是“隐藏的”驗證人。這也意味着，節點參與分片的不同也不會帶來差異（對“隐藏的”驗證人而言，我們也許永遠也不知道其參與的分片）。

驗證人獎勵确實會被該周期其線上時間百分比，以及他所持有的的席位數所影響。驗證人 v v v的獎勵為：

v a l i d a t o r v R e w a r d t = u p t i m e t v × t o t a l V a l i d a t o r R e w a r d t n u m V a l i d a t o r s × n u m S e a t s v (8) validator_vReward_t = uptime_t^v \times \frac{totalValidatorReward_t}{numValidators} \times numSeats_v \tag{8} validatorv​Rewardt​=uptimetv​×numValidatorstotalValidatorRewardt​​×numSeatsv​(8)

這裡 n u m S e a t s numSeats numSeats是該驗證人基于其抵押權益而獲得的席位數： s t a k e v / s e a t P r i c e stake_v/seatPrice stakev​/seatPrice。而線上時間 u p t i m e v uptime_v uptimev​如下計算：

u p t i m e t v = { 0 u p t i m e P c t t v < o n l i n e T h r e s h o l d u p t i m e P c t t v − o n l i n e T h r e s h o l d 1 − o n l i n e T h r e s h o l d o t h e r w i s e (9) uptime_t^v = \begin{cases} 0 & uptimePct_t^v \lt onlineThreshold \\ \frac{uptimePct_t^v-onlineThreshold}{1-onlineThreshold} & otherwise \end{cases} \tag{9} uptimetv​={01−onlineThresholduptimePcttv​−onlineThreshold​​uptimePcttv​<onlineThresholdotherwise​(9)

這裡， u p t i m e P c t t v uptimePct_t^v uptimePcttv​是需要由該驗證人簽名建立或驗證的區塊數百分比（也就是線上時間uptime）。這意味着，如果該驗證人在周期 t _t t​沒有建立足夠的區塊，就不會受到任何獎勵，并且會被移出即将到來的周期 E p o c h t + 2 Epoch_{t+2} Epocht+2​的驗證人池。

獎勵是自動再抵押的，将在下個周期，把 v a l i d a t o r v R e w a r d t validator_vReward_t validatorv​Rewardt​加到指定驗證人已有的 s t a k e v stake_v stakev​餘額上。

5.3 權益的罰沒

權益抵押基于以下兩點提供安全性：

• 抗女巫攻擊，防止單個實體接管所有的驗證人席位并控制出塊活動。
• 防止惡意行為，因為它将罰沒一定量的權益抵押代币（重新配置設定給報告惡意行為的節點）。

我們定義的惡意行為是可以被密碼學證明的：

• 在相同高度上進行雙簽
• 簽署包含無效後繼狀态根的塊（即，無效的狀态轉換）。

注意，我們不對掉線的節點進行懲罰。如果驗證人參與出塊少于 o n l i n e T h r e s h o l d onlineThreshold onlineThreshold，則在周期結尾，它會自動被踢出下一輪驗證人競拍的輪換池。

為了不至于因丢掉驗證人池的席位而導緻的機會成本，驗證人傾向于保持線上時間高于 o n l i n e T h r e s h o l d onlineThreshold onlineThreshold。否則将導緻至少損失2個周期的獎勵。高于百分之 o n l i n e T h r e s h o l d onlineThreshold onlineThreshold後，驗證人的激勵主要來自于（希望）擷取更多的獎勵（正如公式8所示，驗證人漏的塊越多，獎勵就越少）。

5.4 權益的撤回

任何時候，驗證人都可以發起一筆交易，把自己撤出驗證人池（與更改權益抵押數量的方法相同）。這筆交易記錄上鍊。在周期

E P O C H T EPOCH_T EPOCHT​

，當執行新的驗證人競拍時，我們将這種交易視為以0權益抵押的參選。

競拍結束後，送出0枚代币進行權益抵押的驗證人就不會在周期

E P O C H T + 2 EPOCH_{T+2} EPOCHT+2​

的驗證人集體中。之前抵押的權益會在周期

E P O C H T + 2 EPOCH_{T+2} EPOCHT+2​

傳回到他們的賬戶上。

如5.3節所述，如果一個驗證人，作為出塊人卻沒有建立足夠的區塊，或作為“隐藏的”驗證人沒有提供足夠的确認簽名，它抵押的權益會自動撤回，驗證人身份也會在下輪競拍中移除。

5.5 委托

參與驗證工作直接使持币者受益，一方面作為驗證人有獎勵；另一方面，間接吸引更多人參與進網絡，因為它更有經濟保障。然而，不是所有的持币者都有能力或意願去做驗證人。

并沒與為委托定義一個特定協定，我們的智能合約平台提供的基礎工具允許其他人建立權益抵押智能合約。例如，一個驗證人可以建立這樣一個智能合約，定義資本的位置以及參與權益抵押而獲得獎勵的配置設定。這就能讓其他持币者委托他們的權益給合約建立人（以參與PoS挖礦）。

相同的模式有着廣泛的潛在用途，包括一個所謂的“衍生權益”（詳情見參考文獻[3]）。

6 開發者商業模型

應用程式及其開發人員可以在區塊鍊上擁有以下幾種業務模型：

1. 使用者支付的交易費中包含開發者附加的部分。
2. 使用者購買某些物品（例如NFT或token通行證）。
3. 使用者通過訂閱或其他類型的收費模式支付固定費用。

NEAR已經通過開發AccessKeys功能使得采用第二和第三類模型以及其他應用程式和使用者之間不同類型的互動變得更加容易。

另一方面，如果使用建立在交易之外的收費模型，開發人員可能最終會遇到這樣的情況，即他們的合約因為分叉而收不到費用。 為了平衡這一點并考慮應用程式為鍊上資料支付存儲租金的需求，我們添加了“開發者費用”——将交易費用的一部分直接計入應用程式的賬戶。

d e v e l o p e r R e w a r d i n d e x a c c o u n t = d e v e l o p e r P c t × t x F e e i n d e x a c c o u n t (10) developerReward_{index}^{account} = developerPct \times txFee_{index}^{account} \tag{10} developerRewardindexaccount​=developerPct×txFeeindexaccount​(10)

這裡

t x F e e i n d e x a c c o u n t txFee^{account}_{index} txFeeindexaccount​

是指定 a c c o u n t account account 在特定 i n d e x index index 上的gas費用總開銷。 d e v e l o p e r R e w a r d developerReward developerReward 是按每個帳戶的每個塊配置設定的，因為每次合約處理交易或收據（跨片）時，它們都可以有效地結算。

配置設定這筆錢的方法有多種，這取決于應用程式的開發人員來如何在維護應用程式的同時進行規劃。

通過此獎勵計劃，我們還調整了開發人員的激勵措施，以吸引平台上更多使用者進行更多交易。

7 協定财庫

為了給協定和生态系統的持續發展提供資金，我們将按照第3節中讨論的數額為 p r o t o c o l P c t protocolPct protocolPct 比例的周期總獎勵配置設定給指定帳戶。 該帳戶的治理和管理細節不在本文讨論範圍之内。

p r o t o c o l R e w a r d t = p r o t o c o l P c t × ( c o i n b a a s e R e w a r d t + e p o c h F e e t ) (11) protocolReward_t = protocolPct \times (coinbaaseReward_t + epochFee_t) \tag{11} protocolRewardt​=protocolPct×(coinbaaseRewardt​+epochFeet​)(11)

8 未來工作

此設計提供了一種一般性指導，在驗證人激勵與開發者和使用者需求之間實作平衡，進而為廣泛性的應用提供穩定性和可預測的價格機制。我們希望對各利益方之間的激勵機制進行更多研究，以提供一個平衡的系統，同時又不受博弈的影響。

我們建議未來的方向是研究使用算法穩定token來為資源定價，使用stake作為抵押品為該穩定token提供抵押品債務頭寸。

參考文獻

[1] Vitalik Buterin. Blockchain resource pricing. https://github.com/ethereum/research/blob/master/papers/pricing/ethpricing.pdf, 2019.

[2] Miles Carlsten, Harry Kalodner, S. Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 154–167, New York, NY, USA, 2016. ACM. ISBN 978-1-4503-4139-4. doi: 10.1145/2976749.2978408. URL http://doi.acm.org/10.1145/2976749.2978408.

[3] Illia Polosukhin. Staking and delegation via smart contract. https://research.nearprotocol.com/t/staking-and-delegation-via-smart-contract/43, 2019.

[4] Alex Skidanov and Illia Polosukhin. Nightshade: Near protocol sharding design. https://nearprotocol.com/downloads/Nightshade.pdf, 2019.

名詞解釋

驗證人

提供網絡中的算力、存儲與安全性，同時從協定中獲得獎勵作為回報。

開發者

基于協定底層基礎設施，建構有益的應用程式。

使用者

應用程式以及平台自身的使用者，寄望于從這些互動中獲得利益。

Token持有者

協定原生token的持有人，為了提供流動性或今後的使用。

協定治理實體

負責網絡發展和管理的實體。可以是一個DAO亦或非營利性的基金會。

動态分片

動态分片系統能夠動态的對資料和處理重新分區，而無需關閉作業系統。這使得根據需求變動而平衡CPU或存儲資源、管理負載和系統伸縮成為可能。