EIP-1011: 混合 Casper FFG
Authors | Danny Ryan (@djrtwo), Chih-Cheng Liang (@ChihChengLiang) |
---|---|
Created | 2018-04-20 |
Discussion Link | https://github.com/djrtwo/EIPs/issues/5 |
简单总结
指定以太坊主网从工作量证明 (PoW) 过渡到权益证明 (PoS) 的第一步。由此产生的共识模型是 PoW/PoS 混合模型。
摘要
该 EIP 指定了以太坊主网的混合 PoW/PoS 共识模型。现有的 PoW 机制用于创建新区块,并且使用智能合约在顶层分层了一个名为 Casper the Friendly Finality Gadget (FFG) 的新型 PoS 机制。
通过使用以太币存款、罚没条件和修改后的分叉选择,FFG 允许底层 PoW 区块链被最终确定。由于网络安全已从 PoW 大幅转移到 PoS,因此 PoW 区块奖励会减少。
该 EIP 不包含安全性及活性证明或验证者实现细节,但这些内容可以在 Casper FFG 论文 和 验证者实施指南 中找到。
词汇表
- epoch (纪元):检查点之间的区块跨度。纪元从混合 Casper 分叉开始编号,并在每个纪元开始时递增 1。
- finality (最终性):客户端决定区块_永远_不会回滚的点。工作量证明没有最终性的概念,只有更深层的区块确认。
- checkpoint (检查点):对于给定的纪元,正在考虑最终确定的区块/哈希。此区块是前一个纪元的_最后_一个区块。Casper FFG 不处理每个区块,而是仅考虑检查点以进行最终确定。当显式确定检查点时,该检查点的所有祖先区块都会被隐式地确定。
- validator (验证者):Casper FFG 共识的参与者,他们在 Casper 合约中存入了以太币,并负责投票和最终确定检查点。
- validator set (验证者集合):在任何给定时间在 Casper 合约中的验证者集合。
- dynasty (王朝):链中从根到区块父级的已最终确定的检查点数。王朝用于定义验证者何时开始和结束验证。当前王朝仅在检查点被最终确定时才会递增,而纪元编号则会递增,而不管最终性如何。
- slash (罚没):销毁验证者一定数量的存款,并立即从验证者集合中注销。当验证者签署两个违反罚没条件的冲突
vote
消息时,会发生罚没。有关罚没条件的深入讨论,请参见 Casper FFG 论文。
动机
自该协议启动以来,以太坊网络从 PoW 过渡到 PoS 一直在路线图和黄皮书中。尽管在达成去中心化共识方面有效,但 PoW 消耗了大量能源,没有经济上的最终性,也没有抵抗卡特尔的有效策略。过度的能源消耗、平等获取挖矿硬件的问题、矿池中心化以及新兴的 ASIC 市场都提供了尽快进行过渡的独特动机。
直到最近,进行此过渡的正确方法仍然是一个开放的研究领域。在 2017 年 10 月,发布了 Casper the Friendly Finality Gadget,通过验证者存款和加密经济激励解决了经济最终性的开放性问题。有关“可问责的安全性”和“看似合理的活跃性”的详细讨论和证明,请参见 Casper FFG 论文。
Casper FFG 合约可以分层在任何区块提议机制之上,从而为底层链提供最终性。该 EIP 建议将 FFG 分层在现有的 PoW 区块提议机制之上,作为向完全 PoS 过渡的保守的逐步方法。新的 FFG 质押机制只需要对协议进行最小的更改,从而使以太坊网络能够在转移到基于验证者的区块提议机制之前,充分测试和评估 PoW 之上的 Casper FFG。
参数
HYBRID_CASPER_FORK_BLKNUM
:待定CASPER_ADDR
:待定CASPER_CODE
:见下文CASPER_BALANCE
:1.25e24 wei(1,250,000 ETH)MSG_HASHER_ADDR
:待定MSG_HASHER_CODE
:见下文PURITY_CHECKER_ADDR
:待定PURITY_CHECKER_CODE
:见下文NULL_SENDER
:2**160 - 1
NEW_BLOCK_REWARD
:6e17 wei(0.6 ETH)REWARD_STEPDOWN_BLOCK_COUNT
:5.5e5 个区块(约 3 个月)CASPER_INIT_DATA
:待定VOTE_BYTES
:0xe9dc0614
INITIALIZE_EPOCH_BYTES
:0x5dcffc17
NON_REVERT_MIN_DEPOSIT
:wei 中的金额,可由客户端配置
Casper 合约参数
EPOCH_LENGTH
:50 个区块WARM_UP_PERIOD
:1.8e5 个区块(约 1 个月)WITHDRAWAL_DELAY
:1.5e4 个纪元DYNASTY_LOGOUT_DELAY
:700 个王朝BASE_INTEREST_FACTOR
:7e-3BASE_PENALTY_FACTOR
:2e-7MIN_DEPOSIT_SIZE
:1.5e21 wei(1500 ETH)
规范
部署 Casper 合约
如果 block.number == HYBRID_CASPER_FORK_BLKNUM
,则在处理任何交易之前的区块时:
- 将
MSG_HASHER_ADDR
的代码设置为MSG_HASHER_CODE
- 将
PURITY_CHECKER_ADDR
的代码设置为PURITY_CHECKER_CODE
- 将
CASPER_ADDR
的代码设置为CASPER_CODE
- 将
CASPER_ADDR
的余额设置为CASPER_BALANCE
然后执行 CALL
,并在执行任何正常区块交易之前,使用以下参数:
SENDER
:NULL_SENDER
GAS
:3141592TO
:CASPER_ADDR
VALUE
:0NONCE
:0GASPRICE
:0DATA
:CASPER_INIT_DATA
此 CALL
不使用任何 gas,也不会增加 NULL_SENDER
的 nonce
初始化纪元
如果 block.number >= (HYBRID_CASPER_FORK_BLKNUM + WARM_UP_PERIOD)
并且 block.number % EPOCH_LENGTH == 0
,则在执行任何正常区块交易之前,执行 CALL
并使用以下参数:
SENDER
:NULL_SENDER
GAS
:3141592TO
:CASPER_ADDR
VALUE
:0NONCE
:0GASPRICE
:0DATA
:INITIALIZE_EPOCH_BYTES
后跟floor(block.number / EPOCH_LENGTH)
的 32 字节编码
此 CALL
不使用任何 gas,也不会增加 NULL_SENDER
的 nonce
Casper 投票
vote
交易定义为具有以下参数的交易:
TO
:CASPER_ADDR
DATA
:以VOTE_BYTES
开头
如果 block.number >= HYBRID_CASPER_FORK_BLKNUM
,则:
- 到
CASPER_ADDR
的有效vote
交易必须满足以下每个条件:- 必须具有以下签名
(CHAIN_ID, 0, 0)
(即r = s = 0, v = CHAIN_ID
) - 必须具有
value == nonce == gasprice == 0
- 必须具有以下签名
- 在生成和验证区块时,在处理到
CASPER_ADDR
的vote
交易时:- 仅包括上面定义的“有效”
vote
交易 - 将所有
vote
交易放在区块的末尾 - 通过
vote_gas_used
跟踪vote
交易使用的累积 gas,与正常交易使用的累积 gas 分开 vote
交易的总vote_gas_used
不能超过block_gas_limit
,与正常区块交易使用的 gas 无关
- 仅包括上面定义的“有效”
- 在将
vote
交易应用于CASPER_ADDR
到 vm 状态时:- 将发送者设置为
NULL_SENDER
- 将
vote
的 gas 计入vote_gas_used
- 不要将
vote
的 gas 计入正常的gas_used
。对于所有vote
交易收据,累积 gas 使用量等于最后一次非vote
交易收据的使用量 - 不要递增
NULL_SENDER
的 nonce
- 将发送者设置为
- 所有到
CASPER_ADDR
的不成功的vote
交易都无效,不得包含在区块中
分叉选择和最终确定
如果 block.number >= HYBRID_CASPER_FORK_BLKNUM
,则分叉选择规则是由以下伪代码表示的逻辑。请注意,选项 --casper-fork-choice
和 --exclude
将在下面的“客户端设置”中讨论。
def handle_block(new_block):
if not is_new_head(new_block):
return
set_head(new_block)
if --casper-fork-choice is on:
check_and_finalize_new_checkpoint(new_block)
def is_new_head(new_block):
if --casper-fork-choice is off
# 旧的纯 PoW 链评分规则
return new_block.total_difficuty > current_head.total_difficulty
if new_block is in --exclude list or one of its descendants
return false
# 不要回滚已最终确定的区块
if db.last_finalized_block is not in new_block.ancestors:
return false
# 新的 casper 链评分规则
return highest_justified_epoch(new_block) * 10**40 + new_block.total_difficuty >
highest_justified_epoch(current_head) * 10**40 + current_head.total_difficulty
def highest_justified_epoch(block):
casper = block.post_state.casper_contract
return casper.highest_justified_epoch(NON_REVERT_MIN_DEPOSITS)
def check_and_finalize_new_checkpoint(new_block):
casper = new_block.post_state.casper_contract
# 如果没有最终确定的区块,则 db.last_finalized_epoch 初始化为 -1
finalized_epoch = casper.highest_finalized_epoch(NON_REVERT_MIN_DEPOSITS)
if finalized_epoch > db.last_finalized_epoch:
finalized_hash = casper.checkpoint_hashes(finalized_epoch)
# 确保不是简单地最终确定
if finalized_hash == b'\x00' * 32:
return
db.last_finalized_epoch = finalized_epoch
db.last_finalized_block = finalized_hash
新的链评分规则查询 Casper 合约,以找到满足客户端最低存款要求 (NON_REVERT_MIN_DEPOSITS
) 的最高合理纪元。10**40
乘数确保合理的纪元优先于区块挖矿难度。如果所讨论的两个区块具有相等的 highest_justified_epoch
,则 total_difficulty
仅用作决胜局。
注意:如果客户端没有合理的检查点,则合约会将 highest_justified_epoch
返回为 0
,从而有效地将分叉选择规则恢复为纯 PoW。
在评估新区块作为链的头时,客户端_绝不能回滚已最终确定的区块_,如代码注释为“don’t revert finalized blocks”所示。
当将新区块添加为链的头时,客户端会检查是否有新的已最终确定的区块。这由上面的 check_and_finalized_new_checkpoint(new_block)
方法处理。如果 Casper 合约中最高的已最终确定的纪元大于先前已最终确定的纪元,则客户端将最终确定哈希为 casper.checkpoint_hashes(finalized_epoch)
的区块,并将此区块及相关的纪元号作为已最终确定的区块存储在客户端数据库中。
仅当存款_在相关纪元期间_大于 NON_REVERT_MIN_DEPOSIT
时,客户端才会认为检查点是合理的或已最终确定的。此逻辑分别封装在 casper.highest_justified_epoch(NON_REVERT_MIN_DEPOSIT)
和 casper.highest_finalized_epoch(NON_REVERT_MIN_DEPOSIT)
中。
区块奖励
如果 block.number >= HYBRID_CASPER_FORK_BLKNUM
,则 block_reward
由以下逻辑定义,并利用相同的 ommer 奖励公式,但使用更新后的 block_reward
。
if block.number < HYBRID_CASPER_FORK_BLKNUM + REWARD_STEPDOWN_BLOCK_COUNT:
block_reward = 5 * NEW_BLOCK_REWARD
elif block.number < HYBRID_CASPER_FORK_BLKNUM + 2*REWARD_STEPDOWN_BLOCK_COUNT:
block_reward = 4 * NEW_BLOCK_REWARD
elif block.number < HYBRID_CASPER_FORK_BLKNUM + 3*REWARD_STEPDOWN_BLOCK_COUNT:
block_reward = 3 * NEW_BLOCK_REWARD
elif block.number < HYBRID_CASPER_FORK_BLKNUM + 4*REWARD_STEPDOWN_BLOCK_COUNT:
block_reward = 2 * NEW_BLOCK_REWARD
else:
block_reward = NEW_BLOCK_REWARD
验证者
验证者的机制和职责未在此 EIP 中指定,因为它们依赖于网络交易到 CASPER_ADDR
合约,而不是协议级别的实现和更改。
有关验证者详细信息,请参见验证者实施指南。
MSG_HASHER_CODE
MSG_HASHER_CODE
的源代码位于此处。
在为该 EIP 确定字节码之前,源将迁移到 Vyper LLL。
EVM 初始化代码为:
TBD
合约应设置为的 EVM 字节码为:
TBD
PURITY_CHECKER_CODE
PURITY_CHECKER_CODE
的源代码位于此处。
在为该 EIP 确定字节码之前,源将迁移到 Vyper LLL。
EVM 初始化代码为:
TBD
合约应设置为的 EVM 字节码为:
TBD
CASPER_CODE
CASPER_CODE
的源代码位于
此处。
该合约将在为该 EIP 最终确定字节码之前进行正式验证和进一步测试。
具有上述指定参数的 EVM 初始化代码为:
TBD
合约应设置为的 EVM 字节码为:
TBD
客户端设置
客户端应使用以下可配置设置来实现:
启用 Casper 分叉选择
启用/禁用 Casper 分叉选择的能力。建议的实现方式为 --casper-fork-choice
。
在初始 Casper 分叉期间,此设置应在客户端版本中默认禁用。此设置应在后续客户端版本中默认启用。
NON_REVERT_MIN_DEPOSIT
客户端必须在 FFG 合约中观察到的最小总存款额,才能使合约状态影响客户端的分叉选择。建议的实现方式为 --non-revert-min-deposit WEI_VALUE
。
建议客户端使用的默认值至少为 2e23 wei(200K ETH)。
有关更多详细信息,请参见“分叉选择”。
排除
将指定的区块哈希及其所有后代从客户端的分叉选择中排除的能力。建议的实现方式为 --exclude BLOCKHASHES
,其中 BLOCK_HASHES
是要排除的区块哈希的逗号分隔列表。
注意:通过设计,这_可以_覆盖客户端的分叉选择并回滚已最终确定的区块。
加入分叉
手动加入由区块哈希指定的分叉的能力。建议的实现方式为 --join-fork BLOCKHASH
,其中客户端自动将头设置为由 BLOCKHASH
定义的区块,并在本地将其最终确定。
注意:通过设计,这_可以_覆盖客户端的分叉选择并回滚已最终确定的区块。
监视投票
监视传入的 vote
交易是否存在罚没条件,如果找到,则将证据提交给 Casper 合约以收取发现者费用。建议的实现方式为 --monitor-votes
。
该设置应默认为禁用。
以下伪代码定义了两个 vote
消息何时违反罚没条件。vote
消息是包含在 vote
交易中的唯一参数。
def decode_rlp_list(vote_msg):
# [验证者索引、目标哈希、目标纪元、源纪元、签名]
return RLPList(vote_msg, [int, bytes, int, int, bytes])
def same_target_epoch(vote_msg_1, vote_msg_2):
decoded_values_1 = decode_rlp_msg(vote_msg_1)
target_epoch_1 = decoded_values_1[2]
decoded_values_2 = decode_rlp_msg(vote_msg_2)
target_epoch_2 = decoded_values_2[2]
return target_epoch_1 == target_epoch_2
def surrounds(vote_msg_1, vote_msg_2):
decoded_values_1 = decode_rlp_msg(vote_msg_1)
target_epoch_1 = decoded_values_1[2]
source_epoch_1 = decoded_values_1[3]
decoded_values_2 = decode_rlp_msg(vote_msg_2)
target_epoch_2 = decoded_values_2[2]
source_epoch_1 = decoded_values_1[3]
vote_1_surrounds_vote_2 = target_epoch_1 > target_epoch_2 and source_epoch_1 < source_epoch_2
vote_2_surrounds_vote_1 = target_epoch_2 > target_epoch_1 and source_epoch_2 < source_epoch_1
return vote_1_surrounds_vote_2 or vote_2_surrounds_vote_1
def violates_slashing_condition(vote_msg_1, vote_msg_2):
return same_target_epoch(vote_msg_1, vote_msg_2) or surrounds(vote_msg_1, vote_msg_2)
Casper 合约还提供了一个辅助方法 slashable(vote_msg_1, vote_msg_2)
,用于检查两个投票是否违反了罚没条件。在决定是否向合约提交 slash
时,客户端应结合使用上述伪代码和 casper.slashable()
作为最终检查。
--monitor-votes
设置用于希望监视投票交易是否存在罚没条件的客户端。如果发现罚没条件,则客户端会创建交易并将其发送到 Casper 合约上的 slash
。第一个包含罚没条件证明的交易将罚没相关验证者,并将 4% 的发现者费用发送给交易发送者。
理由
自早期区块链时代以来,就存在朴素的 PoS 规范和实现,但大多数都容易受到严重的攻击,并且经不起加密经济分析。Casper FFG 通过要求验证者发布可罚没存款并通过定义经济最终性来解决诸如“无利害关系”和“远程攻击”之类的问题。
最小化共识更改
最终确定工具旨在最大程度地减少跨客户端的更改。因此,FFG 在 EVM 中实现,因此合约字节码封装了分叉的大部分复杂性。
做出的大多数其他决策都是为了最大程度地减少跨客户端的更改。例如,每次 CASPER_ADDR
支付奖励时,都可以允许其铸造以太币(与使用 CASPER_BALANCE
创建合约相比),但这将比依赖现有 EVM 机制更具侵入性和易于出错。
部署 Casper 合约
MSG_HASHER_CODE
和 PURITY_CHECKER_CODE
都不需要任何初始化,因此 EVM 字节码可以简单地放置在 MSG_HASHER_ADDR
和 PURITY_CHECKER_ADDR
上。另一方面,Casper 合约_确实_需要传入参数和初始化状态。该初始化通常会通过与 CREATE 操作码交互的 EVM 初始化代码来发生。由于此合约是在正常区块交易之外且在特定地址部署的性质,因此 EVM 初始化代码/CREATE 方法需要客户端特定的“hack”才能使其工作。为了简化跨客户端的指定,EVM 字节码 – CASPER_CODE
– 被放置在 CASPER_ADDR
上,然后显式 CALL
Casper 合约上的临时 init
方法。init
处理构造函数通常会处理的所有逻辑,接受合约参数作为参数并设置初始变量值,并且只能运行_一次_。
CASPER_INIT_DATA
由 Casper 合约的 init
方法的字节签名与以下变量的 32 字节编码(按以下顺序)连接而成:
EPOCH_LENGTH
WITHDRAWAL_DELAY
DYNASTY_LOGOUT_DELAY
MSG_HASHER_ADDR
PURITY_CHECKER_ADDR
BASE_INTEREST_FACTOR
BASE_PENALTY_FACTOR
MIN_DEPOSIT_SIZE
整个数据都作为字节串提供 – CASPER_INIT_DATA
– 以减少跨客户端的编码错误的可能性,尤其是在 vyper 中较新且尚未被所有客户端支持的定点十进制类型。
Casper 合约参数
EPOCH_LENGTH
设置为 50 个区块,以平衡最终确定时间和消息开销。
WARM_UP_PERIOD
设置为 1.8e5 个区块,以为验证者提供大约 1 个月的时间来进行初始存款,然后再开始完全的合约功能和投票。这有助于防止简并的情况,例如在初始王朝中只有极少数甚至只有一个验证者。这 1 个月的时间也使网络有时间观察有多少验证者最初将参与共识。 如果由于某种原因,投票率出乎意料地低,则社区可能会选择延迟验证并考虑其他设计方案。
WITHDRAWAL_DELAY
设置为 15000 个纪元,以在注销后冻结验证者的资金约 4 个月。这允许至少 4 个月的窗口来识别和罚没试图最终确定两个冲突检查点的验证者。这也定义了客户端由于弱主观性而必须登录才能同步网络的时间窗口。
DYNASTY_LOGOUT_DELAY
设置为 700 个王朝,以防止在遭受攻击时立即注销成为可行的策略。
BASE_INTEREST_FACTOR
设置为 7e-3,这样如果总存款约为 1000 万 ETH,则在最佳 FFG 条件下,验证者每年可赚取约 5% 的 ETH 奖励。
BASE_PENALTY_FACTOR
设置为 2e-7,这样如果 50% 的存款离线,则离线验证者将在大约 3 周内损失一半的存款,此时验证者的在线部分将成为 2/3 多数,并且可以再次开始最终确定检查点。
MIN_DEPOSIT_SIZE
设置为 1500 ETH,以在验证者的总数上形成一个自然的上限,从而限制了由于 vote
消息引起的开销。使用此处在“从验证者计数到最小抵押 ETH”下找到的公式,我们估计在假定的总存款约为 1000 万的情况下,以 1500 ETH 的最小存款额,在任何给定时间将大约有 900 个验证者。vote
仅在纪元的第一个季度之后发送,因此 900 个投票必须适合 37 个区块中,即每个区块约 24 个 vote
。我们已经尝试了更动态的 MIN_DEPOSIT_SIZE
模型,但是这些模型往往会引入很大的复杂性,并且在没有来自实时网络的数据的情况下,似乎为时过早的优化。
初始化纪元
在每个纪元开始时,在 CASPER_ADDR
上对 INITIALIZE_EPOCH_BYTES
方法的调用是对 Casper 合约中 initialize_epoch
方法的调用。该方法每个纪元只能被调用一次,并且协议保证由 NULL_SENDER
在每个纪元的开始区块被调用。此方法执行许多围绕递增变量,更新奖励等的簿记任务。
在 WARM_UP_PERIOD
结束之前,对该方法的任何调用都将失败。因此,该协议在 block.number >= HYBRID_CASPER_FORK_BLKNUM + WARM_UP_PERIOD
之前不会开始执行 initialize_epoch
调用。
发行
选择了 125 万 ETH 的固定金额作为 CASPER_BALANCE
,以为 Casper 合约提供资金。这使该合约有足够的运行时间约 2 年(假设验证者存款中约有 1000 万 ETH)。与“难度炸弹”类似,这种“资金短缺”迫使网络在相对较近的将来进行硬分叉,以进一步为合约提供资金。未来的硬分叉是升级合约并过渡到完全 PoS 的机会。
PoW 区块奖励在大约一年的时间内从 3.0 减少到 0.6 ETH/区块,因为链的安全性已从 PoW 难度大大转移到了 PoS 最终确定性,并且现在也向验证者和矿工发行奖励。奖励每 3 个月(REWARD_STEPDOWN_BLOCK_COUNT
)减少 0.6 ETH/区块,以为从完全 PoW 过渡到混合 PoS/PoW 提供保守的过渡期。这使验证者有时间熟悉新技术并开始登录,并且还为网络提供了更大的余地,以防出现任何意外问题。如果确实出现了任何重大问题,以太坊网络仍将拥有大量的 PoW 安全性来依靠,同时做出决策和/或部署补丁。有关当前 PoW 安全性以及在混合 Casper FFG 的情况下减少 PoW 区块奖励的影响的进一步分析,请参见此处。
除了区块奖励之外,矿工现在还可以获得发行奖励,以按时将成功的 vote
交易包括到区块中。该奖励等于验证者成功进行 vote
交易所得奖励的 1/8。在进行小组验证者奖励调整后的最佳 FFG 条件下,矿工大约获得 Casper 合约发行的以太币总量的 1/5。
以下是一个存款规模表,其中包含相关的年利率和直到发生资金短缺的大约时间:
存款规模 | 验证者年利息 | 资金短缺 |
---|---|---|
250 万 ETH | 10.12% | 约 4 年 |
1000 万 ETH | 5.00% | 约 2 年 |
2000 万 ETH | 3.52% | 约 1.4 年 |
4000 万 ETH | 2.48% | 约 1 年 |
Gas 更改
正常的区块交易不会影响 casper vote
验证结果,但是 casper vote
验证结果会影响正常的区块交易执行。由于这种不对称关系,如果 vote
交易放置在所有正常区块交易之后,则可以与正常区块交易并行处理 vote
交易。由于 vote
交易可以与正常的区块交易并行处理,因此 vote
交易对验证者花费 0 gas,从而确保即使在高度拥塞或高 gas 价格时期,验证者也可以提交投票。
引入了 vote_gas_used
,以确保 vote
交易不会给区块处理带来过多的负担。来自 vote
交易的额外开销被限制为与正常的区块交易相同的限制,这样,在并行运行时,这两组交易都不会超过由 block_gas_limit
定义的开销。
在每个纪元开始时调用 initialize_epoch
需要 0 gas,因此此协议状态转换不会占用正常交易的任何 gas 允许量。
NULL_SENDER 和帐户抽象
此 EIP 为的验证者的 vote
交易实现了有限版本的帐户抽象。通用设计借鉴自 EIP-86。每个验证者不是依赖本机交易签名,而是在将 deposit
发送到 CASPER_ADDR
时指定一个签名合约。在进行 vote
时,验证者会根据其签名合约的要求捆绑和签名其 vote
的参数。Casper 合约的 vote
方法根据验证者的签名合约检查参数的签名,如果签名未成功验证,则退出交易,使其不成功。
这允许验证者自定义其自己的投票签名方案。用例包括:
- 量子安全签名方案
- 多重签名钱包
- 阈值方案
有关验证者帐户抽象的更多详细信息,请参见验证者实施指南。
客户端设置
启用 Casper 分叉选择
发布最初默认禁用 Casper 分叉选择的客户端版本可以更保守地过渡到混合 Casper FFG。在正常的运行条件下,PoW 分叉选择和混合 Casper FFG 分叉选择之间没有差异。只有在 51% 的矿工或 51% 的验证者发生故障时,这两个分叉选择规则才会不同。
验证者将开始登录,投票并在网络中的大多数明确依赖新的最终确定机制之前,最终确定 FFG 合约。一旦有大量的验证者登录并且已在实时网络上测试了最终确定机制,将会发布新的更改了默认设置为启用的客户端软件版本。
NON_REVERT_MIN_DEPOSIT
NON_REVERT_MIN_DEPOSIT
由每个客户端本地定义和配置。客户端负责确定他们将接受链作为最终确定状态的最小存款(安全性)。通常,在此局部常数的选择中使用不同的值不会创建任何分叉不一致,因为具有非常严格的最终确定要求的客户端将恢复为遵循最长的 PoW 链。
有人主张将值硬编码到客户端或合约中,但是我们无法合理地定义所有客户端所需的安全级别,尤其是在以太币价值大幅波动的情况下。
排除
在多数勾结的情况下,此设置对于协调少数派分叉很有用。
加入分叉
首次同步网络的的新客户端应使用此设置。由于弱主观性,因此在首次启动节点时,应提供区块哈希以成功同步网络。
在多数勾结的情况下,此设置对于协调少数派分叉也很有用。
监视投票
监视网络是否存在罚没条件是 Casper FFG 的“可问责的安全性”的关键,因为提交恶意活动的证明会烧毁验证者的存款。
建议默认禁用此设置,因为区块生产者几乎肯定会抢先其他人提交 slash
交易。为防止网络上的每个客户端在发生罚没条件时都提交 slash
交易,只有区块生产者和那些明确选择监视投票的客户端才应启用此设置。
向后兼容性
此 EIP 不向前兼容,并且在某些交易的状态,分叉选择规则,区块奖励,交易有效性和 gas 计算中引入了向后不兼容性。因此,所有更改都应包含在 HYBRID_CASPER_FORK_BLKNUM
处的计划硬分叉中。
版权
通过 CC0 放弃版权和相关权利。
Citation
Please cite this document as:
Danny Ryan (@djrtwo), Chih-Cheng Liang (@ChihChengLiang), "EIP-1011: 混合 Casper FFG [DRAFT]," Ethereum Improvement Proposals, no. 1011, April 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1011.