大多数区块链遇到大规模节点离线,只有两条路:要么硬撑着按原计划出块,选出的验证人凑不齐就干脆卡住等下一轮;要么彻底停摆,等人工介入。Dusk在这两者之间,专门设计了第三种答案。
白皮书Section 3.6写得很具体:如果大部分Provisioner离线或者被隔离,连续多轮迭代都没能选出出块人、凑不齐投票委员会,达到失败阈值(当前设为16次)之后,协议会切换进紧急模式。
这个模式下,原本的超时机制被关闭,迭代持续进行,直到真的产出候选区块并且在验证、批准两步都凑够法定人数,而且允许多个迭代同时并行运作,提高在极端情况下产出有效区块的概率。
如果连这套机制都撑不住,协议还留了最后一道保险——由持有多数质押量的Provisioner联合发起请求,生成一个不含任何交易、只带新种子的"紧急区块",让链能先往前挪一步,不至于无限期停摆。
我自己的判断是,这套设计本质是拿"分叉风险"换"网络存活",允许多个并行迭代同时跑,分叉概率确实会上升,得靠后续的回退规则清理战场,但这个代价换来的是网络不会因为极端情况彻底死机。
对机构来说,这种边缘场景的处理方式,可能比日常的秒级结算更值得纳入尽调——正常状态下的表现,多数金融级公链都能做到,真正拉开差距的是系统失灵时,给出的到底是"降级但继续运转"还是"直接卡死"。
#dusk $DUSK @Dusk
你们觉得,评估一条链的可靠性,极端情况下的应对设计,该占多大权重?
白皮书Section 3.6写得很具体:如果大部分Provisioner离线或者被隔离,连续多轮迭代都没能选出出块人、凑不齐投票委员会,达到失败阈值(当前设为16次)之后,协议会切换进紧急模式。
这个模式下,原本的超时机制被关闭,迭代持续进行,直到真的产出候选区块并且在验证、批准两步都凑够法定人数,而且允许多个迭代同时并行运作,提高在极端情况下产出有效区块的概率。
如果连这套机制都撑不住,协议还留了最后一道保险——由持有多数质押量的Provisioner联合发起请求,生成一个不含任何交易、只带新种子的"紧急区块",让链能先往前挪一步,不至于无限期停摆。
我自己的判断是,这套设计本质是拿"分叉风险"换"网络存活",允许多个并行迭代同时跑,分叉概率确实会上升,得靠后续的回退规则清理战场,但这个代价换来的是网络不会因为极端情况彻底死机。
对机构来说,这种边缘场景的处理方式,可能比日常的秒级结算更值得纳入尽调——正常状态下的表现,多数金融级公链都能做到,真正拉开差距的是系统失灵时,给出的到底是"降级但继续运转"还是"直接卡死"。
#dusk $DUSK @Dusk
你们觉得,评估一条链的可靠性,极端情况下的应对设计,该占多大权重?
A. 权重很高,失灵表现最见真章
B. 权重一般,正常表现更常用
C. 得看具体业务场景需求
6 ساعة (ساعات) مُتبقية
