原文链接：https://near.org/papers/economics-in-sharded-blockchain/
翻译：Marco 校对：Sissi 编辑：Buster
由于本文包含较多Ketex格式的公式，推荐戳这里查看完美编辑版。
文章目录
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−1coinbaseRewardi，意味着它是在给定周期 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−epochFeestepockFeest≥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}
validatorvRewardt=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−onlineThresholduptimePcttv<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 validatorvRewardt加到指定验证人已有的 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 开发者商业模型
应用程序及其开发人员可以在区块链上拥有以下几种业务模型：
- 用户支付的交易费中包含开发者附加的部分。
- 用户购买某些物品（例如NFT或token通行证）。
- 用户通过订阅或其他类型的收费模式支付固定费用。
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或存储资源、管理负载和系统伸缩成为可能。
533
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
