原文标题:《V 神最新发文:针对信标链的终结性模型替代设计构想》 本文提出了一种以太坊信标链(Beacon Chain)的拟议替代设计,在未来长期内可以切换到该设计(取代当前计划切换的 CBC)。该替代设计旨在提供一些关键属性:
准备工作让 CONSENSUS 成为一种异步安全的共识算法(例如 Tendermint、Casper FFG ……)。 我们假设这种共识算法有一些槽(slot)或视图的概念,它在每个固定时间段尝试达成共识。 我们还假设它将一种加权验证器集作为输入(现有的 BFT 共识算法可以轻松修改以添加此属性)。 在下面的设计中,我们修改了 CONSENSUS,以便在每个视图中,需要最终性的集合是不同的。 也就是说,CONSENSUS 将一个函数 get_validator_set(view_number: int) -> Map[Validator, int](代表验证器余额的 int)作为输入,而不是验证器集,它可以为新视图生成验证器集。 get_validator_set 应该具有以下属性:验证器集根据从一个视图到下一个视图的最大 1/r 值进行更改,其中 r (例如 r=8192 )是恢复期长度。 更正式地说,我们想要: 其中 丨 x 丨 返回 x 中值的绝对值之和, diff 返回每个键值的差值(例如 diff({a: 0.1, b:0.2}, {b:0.1, c:0.3}) = {a:0.1,b:0.1,c:-0.3})。 在实践中,两个相邻验证器集之间的差异将包括现有验证器泄漏余额,以及以与泄漏余额相等的速率引入新验证器。 请注意,这意味着如果两个终结性的视图数量相差足够远,则这时候可以在不削减的情况下进行双重终结性确定; 这是有意为之,并且该协议以与当今 Casper FFG 处理不活动泄漏的方式相同的方式围绕它工作。 机制我们使用两级分叉选择: 选择 LATEST_FINALIZED_BLOCK 从 LATEST_FINALIZED_BLOCK,应用一些其他叉选择(例如 LMD GHOST)来选择 head 共识算法的视图在每个插槽都会被尝试,将基于 get_post_state(LATEST_FINALIZED_BLOCK) 数据的验证器集生成函数作为输入传入。 在视图 i 中,一个有效的提案必须包含从 LATEST_FINALIZED_BLOCK 到插槽 LATEST_FINALIZED_BLOCK.slot + i 处的区块的链。 如果提示的父级是分叉选择的赢家,这时验证者才需要准备并提交提案。 (责任编辑:admin) |