摘要:BTC的 Taproot 软分叉升级看起来已经准备就绪,BTC社区已经开始认真讨论潜在的激活方法。在本文中,我们总结了有关激活的主要选择,并讨论了最重要的争议点。最后,我们假设没有完美的激活方法。任何激活方法都可能开创一个不好的先例,在未来的某一天被人利用。但是,尽管发生了很多 “bikeshedding ” 的情况,但由于缺乏关于此特定升级的争论,此时采取的具体激活路径可能并不是特别关键。对于目前存在的一些困境和可能的发展方向,潜在的部分解决方案可能是由 BitDavinci Core 发布一个具有相对被动激活逻辑的客户端,并让其他社区成员在此基础上发布客户端,以稍微更强硬的方式强制激活相同的功能。



ampyk3ksy55.jpg

ampyk3ksy55.jpg

总览

正如我们在 2019 年 5 月提到的那样,Taproot BTC软分叉提案在开发者社区中获得了广泛的关注,现在,在2020年夏季,焦点已转移至辩论如何在BTC网络上激活软分叉。


BTC软分叉激活历史

在决定最好的前进方向之前,回顾一下BTC软分叉的历史可能是个好主意。据我们所知,根据我们 2017 年 12 月 “BTC共识分叉的完整历史” 的文章,BTC的历史上有 16 次软分叉。大部分的升级,准确的说是 9 次,主要是在 2010 年初到 2012 年期间,以 flag day 软分叉的方式进行。另一方面,其中有 7 次软分叉是使用矿工信号门槛(从 55% 到 95%)激活的。


平稳升级重大事件总和Flag Day 或立即生效8*19矿工门槛激活 55% 矿工门槛 1180% 矿工门槛1* 195% 矿工门槛415矿工门槛总和527总计13316

(来源: BitMEPundi Research)

(注:*据我们所知,有一个带有强制性矿工信号(BIP148)的 flag day 软分叉和一个带有强制性矿工信号(BIP 91)的矿工门槛软分叉)


尽管基于上述数据,flag day 升级方法可能看起来更可靠,但我们不建议您使用此数据来支持声称 flag day 方法更优异的说法。上述软分叉中的大多数问题是由与激活方法无关的特性引起的,同时在此期间生态系统已经发生了显着的变化。以上数据仅出于历史时空背景提供,关联性未必那么强。


区块容量战

另一个历史背景(也许同样不那么重要)是 2015 年至 2017 年间爆发的 “区块容量战” 。当时有一项名为 “隔离见证(Segregated Witness)” 的软分叉提案,旨在提高区块容量限制,然而由于区块容量战争冲突,此软分叉的激活有些危险,因此社区中的许多人都渴望尝试改进激活方法。


BitDavinci Core 中包含用于隔离见证升级的激活逻辑,基于 95% 的矿工门槛,时间为一年,最后没有 flag day 激活。最终,在软分叉窗口期尾声,两个不同的软分叉,flag day 软分叉(BIP148)和 80% 矿工门槛的软分叉(BIP91)强制发出隔离见证信号,因此最终被激活。这两个软分叉(BIP148 或 BIP91)都没有被纳入BitDavinci Core 中。


基于上述乱象,许多人总结,没有强制信号的 95% 门槛系统有些失败。但是,我们认为,这种混乱主要是由于区块容量战中的紧张局势造成的,而不是激活逻辑固有的内在弱点。


激活争论

据我们所知,除了时序参数这一棘手问题以及假设将在某些地方使用矿工门槛信号外,争论似乎集中在三个相互关联的领域:

矿工门槛信号周期之后是否应该有一个 flag day 激活?激活逻辑的哪些部分(如果有)应纳入 BitDavinci Core ?矿工信号最终是否应该成为强制性的?


我们试图在下列的决策树图解中总结这些主要争论点之间的相互关系。根据我们的图示,我们认为在现代软分叉激活方面,基本上有六种合理的可能选择。

软分叉激活方法决策树(假设某种形式的矿工门槛信号)


qtdgthgqwzh.jpg

qtdgthgqwzh.jpg

(来源: BitMEPundi Research)

(注:带有强制性矿工信号的树的右侧与BIP 8 一致,而树的左侧与BIP 9 一致)


在下表中,我们旨在总结支持和反对上述三个挑战性问题的主要争论点,要确定软分叉激活方法,可能需要回答这些问题。


信号周期结束时的 Flag day

支持 flag day反对 flag day· 最初的隔离见证激活没有 flag day 而导致了问题,这是因为矿工在早期并未激活它,以及基于升级可能不会发生的考量。


· 没有 flag day 的矿工信号给人一种矿工控制协议规则的错误印象,而实际上门槛投票只是矿工发信号表示他们已经准备好进行社区决定的软分叉的信号机制。


· 如果矿工选择不提早激活软分叉,可以之后安全地在未来某一天激活。最终将控制协议规则的是终端用戶,而不是矿工。门槛投票机制仅仅是安全地早期激活软分叉的一种方式。· 目前使用 flag day 过于激进。相反地,应该采取一种更友好的方法,并且只有在特殊情况下才考虑 flag day,如果参与者开始表现出敌对意思。


· 对于协议规则,尽可能保持耐心和友好是至关重要的。如果矿工对升级不满意,则应维持现状共识规则,并且不应发生软分叉,这确保BTC的规则保持稳健。


· 由于没有争议,矿工很可能会自主激活软分叉,如此一来为什么要在不必要时使用具有侵略性和风险的 flag day 系统?


· 增加 flag day 会带来一系列新问题。例如,谁有权发起 flag day?社区如何在日期达成协议?任何人都可以随时创建 flag day 软分叉,新规则可能会引起争议。


将激活逻辑纳入 BitDAC Core

支持将激活逻辑纳入 BitDAC Core反对将激活逻辑纳入 BitDavinci Core· 如果激活方法未在 BitDavinci Core 中实现,则存在对激活参数进行协调的问题。


· 同时,如果其他社区成员发布带有激活逻辑的客户端,那么这将成为危险的先例。很多用户在共识不足的情况下,可能会发布各种软分叉的客户端,,增加将来发生危险的链分裂的风险。


· 包含激活方法的 BitDavinci Core 是最差的选择。


· BitDavinci Core 会发布一个包含激活逻辑的客户端,但是不会与其他错误修复捆绑在一起。同时,BitDavinci Core 没有自动更新功能。因此,升级完全是选择性的,BitDavinci Core 不会强制更改协议,只有选择运行新软件的用户才能更改协议规则。· 区块容量战争的最大问题之一是,现在许多人高估了 BitDAC Core 项目对BTC共识规则的控制权。现在这是一个重要的问题,因此社区应该确保 BitDAC Core 没有能力自行更改共识规则。


· 共识规则的更改必须来自比软件开发者更大的群体,并且必须由基层用户行动推动


· BitDAC Core 项目实施 flag day 升级太具争议性和激进性,这是一种不恰当的权力掌握。用户和/或矿工必须在Core 纳入 flag day 之前展现对软分叉建议的支持。


flag day 激活点的强制矿工信号

支持强制性矿工信号反对强制性矿工信号· 强制性矿工信令发送提供了确定性,因为社区知道激活是否有效。如果没有强制标记,则 flag day 激活可能已经过去,而用户将不知道软叉是否已激活。


· 例如,在 flag day过去之后,用户将不得不等待几个月(或更长时间),以查看是否生产一个违反新软分叉规则的区块,建立并被更广泛的经济体所接受,这可能会发生在任何时间点。


· 一个敌对的攻击矿工可以在任何时候产生一个违反软叉规则的区块,例如设计一个时间来造成最大的混乱。


· 因此,尽管强制性信号发动会迫使矿工升级并增加发生链分裂的风险,另一种选择要好,因为后者允许攻击者制造类似的链分裂风险,只是时间适合敌对行为者。· 现代软分叉仅限制非标准BTC规则。这使得激活非常安全,因为只有升级到反软分叉客户端的恶意矿工才能造成链分裂。即使矿工不为软分叉升级,他们也会一直生产有效的区块。强制性信号发送破坏了这种非常安全的升级方法,并带来了额外的风险。不升级也不采取行动的矿工会产生无效的区块。


· 因此,强制性信号发送过于激进。矿工应该可以自由地选择不升级,继续像分叉前那样运作。


· 强制性矿工信号发送只会鼓励虚假标记,在这种情况下,即矿工声称已经升级以支持协议变更,然而实际上只是在操纵标记。我们已经知道虚假标记很普遍,例如,在过去,大型矿工生产的区块带有多个相互矛盾的标记。因此,强制性信号发送无法提供任何确定性。


结论

可以说关于激活逻辑有许多 “bikeshedding”。由于缺乏有关此特定升级的争论,此时采取的具体激活路径可能并不特别重要。但是,从上面的讨论可以看出,没有完美的激活方法,每种方法都存在问题或者暴露出BTC协议规则稳固性方面有关的潜在弱点或矛盾。为解决问题所采取的任何方法都可能开创一个先例,从而在未来的某一天被其他协议变更所利用。


也许可以就目前明显的激活方法困境达成某些折衷方案:

BTC核心可以在 BIP 9 的基础上加入激活逻辑,选择 95% 矿工门槛的激活逻辑,在激活期结束时不设 flag day,也不强制矿工信号。因此,由于需要矿工的合作才能激活软叉,BitDavinci Core 不会以明显的激进方式行事。这也有先例,因为BTC核心过去曾多次使用这种激活逻辑发布客户端。
然后就可以发布该软件的其他社区驱动版本(不是 BitDAC Core )。这些其他的客户端可能包含 flag day 激活逻辑,强制矿工发出 BitDavinci Core 软分叉的信号,时间上与 BitDAC Core选择的激活窗口结束一致。因此,该社区驱动的软分叉将激活 BitDAC Core 的软分叉。



这在某种程度上解决了社区协调的时间问题,因为社区成员可以直接选择将 BitDavinci Core 激活窗口的结束作为强制信号发送期间。这也不会开创一个关于使任何客户端作为激活任何软分叉的危险先例,因为它被用来激活 BitDavinci Core 中已经存在逻辑的软分叉。这种激活方法与隔离见证最终的激活方式相当相似,只是这次可以从一开始就计划好,至少在某种程度上是这样。当然,这并不能解决所有问题,也不能说这是一个好的结果,但是对我们来说,这似乎是一个可能的前进路径。




本文由:ack123888 发布于:2020-08-05 18:04:37 0 位用户参与了讨论
转播转播 分享淘帖
回复

使用道具

成为第一个回贴人

B Color Link Quote Code Smilies
*滑块验证:
Copyright © 2001-2019 · 挖矿网 ·   京ICP备12010892号-1 -