展望比特币未来的升级之路

作者:Shinobi

来源:https://bitcoinmagazine.com/technical/how-to-upgrade-bitcoin

过去 5 年来,比特币领域最具争议的问题之一是如何激活软分叉。自诞生以来,比特币曾采用过很多不同的机制来在网络上激活新的功能,其迭代通常以让功能部署尽可能安全平稳为目标。在 2017 年以前,在激活机制变化的过程中,人们普遍达成了共识,没有很多分歧,但是在 SegWit(隔离见证)部署期间,情形发生了变化。

SegWit 是最先导致人们在激活方式上产生分歧和争议的事件。最初基于 BIP 9 的激活方式需要矿工发送信号来锁定执行规则;但在该流程部署之后,绝大多数矿工和矿池都拒绝在区块中表态支持。当时,很多用户不满于矿工延迟激活新的功能并以此为要挟、提出通过硬分叉来增加区块容量的要求(当时,SegWit 通过软分叉实现了区块扩容)。整个生态充斥着关于 SegWit 的不实信息,试图以谣言煽动人们反对这一功能。

BIP148 和 UASF(用户激活软分叉)最终迫使矿工激活了 SegWit,大区块的两大支持力量之一离开了社区,另一大力量则走向分叉,最终成了无关紧要的链。从那时起,比特币用户通常会避免讨论应该如何部署和激活新功能。这个话题争议性太强,以至于在某种程度上成了一种禁忌。

我认为,在阐述我个人对于未来应该如何进行升级的看法之前,有必要先回顾一下过往提议和采用过的激活机制。请注意,这些机制同时适用于硬分叉和软分叉。唯一的区别在于,硬分叉一定会导致链分裂,而软分叉只有在出现问题时才会导致链分裂。

预定时间点激活

“可以分阶段推行,例如:

if(blocknumber > 115000)

​ maxblocksize = largerlimit

(意思是当区块话大于 115000 时,就为区块上限参数赋予一个新的值,使之提高)

因此,一旦达到该区块高度,新的区块大小上限就会生效,旧版本就会被淘汰。”

—— BitcoinTalk,2010 年 10 月 4 日

上面这段饱受诟病的引文是中本聪在原始区块大小上限实施后写下的,讲的是日后用户认为有必要之时,可以采用何种方式提高区块大小上限。(同样值得一提的是,当人们在早期提出提高区块大小上限的要求时,中本聪不仅表示反对,还特意引用了上面那段话来解释为什么不到必要关头不应该这么做。中本聪最后关于区块大小问题的评论(点击此处查看)也明确承认最终选择权在用户手中。)

这就是“预定时间点激活”,即,选定一个区块高度或时间戳,已升级节点会在到点后开始执行新的规则。这里面既没有公开信号,也没有肉眼可见的协调活动。人们可自由选择是否下载新的客户端,已完成升级的人会在选定时间点开执行新的规则,没有完成升级的人不会。

P2SH(pay to script hash)就是通过这种机制激活的。从技术角度来说,预定时间点激活是一种用户激活软分叉,因为需要依靠网络中的节点来激活新功能并执行其规则。这种激活机制的问题在于,不会有任何公开信号显示宣称执行新规则的矿工人数占比,因此每个人都各自猜测潜在风险和链分裂的可能性。这种激活方式已经有一段时间没有采用了。

BIP 9

为了进一步降低部署软分叉时出现链分裂的风险,BIP 9 提案诞生了。BIP 9 提案背后的构想是让矿工在他们挖出的区块中包含一个信号,只有在单个难度调整周期内发送功能激活信号的矿工占比达到 95% 的阈值时,新的节点软件才会激活新功能。这样可以公开显示有多少矿工愿意在节点开始执行新规则之前激活新功能。显然,矿工可以撒谎并发送虚假信号,但是根据 BIP 9,这种做法从经济层面上来说是不理性的。CheckLockTimeVerify 和 CheckSequenceVerify 都是按照 BIP 9 提案部署的。SegWit(隔离见证)实现的原始版本同样如此。

正如 SegWit 所反映的那样,BIP 9 式部署的最大缺点是少数派矿工可以通过拒绝发送信号来拖延功能激活。BIP 9 实际上赋予了矿工否决权,可防止一项新功能在比特币网络上激活,无法通过另一种激活机制进行二次部署。因此,这一激活机制让矿工在激活新功能方面享有过高的控制权。作为用户和持币者的服务提供方,矿工不应该对功能激活拥有过大的影响力。

BIP148 和 UASF

BIP 148 开创了一个伟大的先例,实现了前所未有的新型激活机制。它的目的不单是部署激活新的功能,还有确保之前 BIP 9 部署的 SegWit 完成激活。这就是截止日期定在 8 月 1 日的原因。从 2017 年 8 月 1 日开始,就进入到了 SegWit 激活窗口期结束前的最后一个难度调整周期(为期两周),也是供矿工表态的最后一段时间。BIP 148 客户端将在共识上要求:在最后窗口期挖出的所有区块都要包含 SegWit 激活信号。

这一机制是以往不需要也从未使用过的新型激活设计,专门用来纠正 BIP 9 的主要缺陷:矿工能够阻碍原本已经达成共识的功能的激活。

BIP 91

BIP 91 是 2017 年部署的另一个特殊的激活机制,同样与 SegWit 有关。当时的矿工不愿意屈服于 BIP 148 的最后通牒,同时又担心如果 BIP 148 在未得到矿工信号的情况下激活新功能会导致比特币分裂成两条平行链。BIP 91 的创建初衷是为了找到一种折中方案,让所有人都在同一条链上保持同步。

BIP 91 设置了 80% 的阈值,只要在激活 SegWit 前的单个难度调整期间发送信号的矿工比例达到该阈值,就会开始孤立所有未包含信号的区块(就像 BIP 148 那样)。其目标是确保 BIP 91 被激活时,能与 BIP 148 兼容并行,然后触发 BIP 9 的 SegWit 部署,让所有人都待在同一条链上。BIP 91 的主要目的是给矿工一个“参与触发激活”的理由。

BIP 8

鉴于 SegWit 激活期间发生的情况,有人提议用 BIP 8 代替 BIP 9。BIP 8 的设计目标是创建一个部署机制,只要发送信号的矿工占比在激活窗口期内达到阈值(90%),即可在任意时间点激活该提案;并且,在足够多矿工拒绝发送信号的情况下,也能保证分叉被激活。

BIP 8 用到了“lockinontimeout”变量。如果该变量被设置为 true,在最后一个信号发送期内,共识规则会强制要求所有区块 必须 发送激活信号,以确保新功能激活,就像 BIP 148 那样。

SPEEDY TRIAL

Speedy Trial 是最终用来成功激活 Taproot 的机制。毫不夸张地说,Speedy Trial 在一众激活机制中被选中在当时是饱受争议的。归根结底,Speedy Trial 的功能类似 BIP 9 激活部署,区别在于前者的激活窗口期短得多,信号发送阈值与 BIP 8 一样(90%)。使用 Speedy Trial 的部分原因是,如果某个达成共识的功能未能激活,之后可以发布 BIP 8 LOT = True 部署。

包括我自己在内的很多人都将 Speedy Trial 视为优化功能激活机制的倒退。

现在呢?

2017 年 SegWit 激活失败证明了,少数派矿工能够干预网络共识和功能部署,只能通过同时部署多种不同的激活机制来彼此推动这种极其复杂的方式纠正。这是相当危险的情况,幸好最后解决了,否则后果将不堪设想。

我个人认为,跳过 BIP 9 的意义在于避免这类情况再度发生。有人认为,Speedy Trial 起到了同样的作用,因为在激活窗口期结束前的预备阶段短得多。对此,我不敢苟同。Speedy Trial 依然存在因极少数矿工作恶或不回应而导致激活失败的风险,而且更重要的是,它产生了一种社会印象,即,矿工能够“否决”其它网络参与者之间达成的共识。

我认为从长远来看,激活机制都要回归到一个终极问题上。随着比特币不断发展壮大,越来越多小白用户涌入这个生态。这些用户会在学习的过程中亲眼目睹比特币的发展进程。更重要的是,他们会带着这样的疑问来看待激活机制:“这是怎么回事?激活功能的决定权在谁手上?”开发者?矿工?企业?这些都是答案。我认为当我们在网络上部署新功能和升级时,大多数新用户就会在脑子里过一遍这个问题。

人们最终得出的答案将成为自我应验的预言:如果用户将矿工视为最终决策者,大多数用户就会将目光投向矿工;如果用户将开发者视为最终决策者,大多数用户就会将目光投向开发者。当前比特币用户是如何处理这个问题的,未来用户也会有样学样。人们对于应该如何处理激活有很多不同的意见,但为了不让别人代表我,我想自己说出我的看法。

我认为在参与激活流程时,Bitcoin Core (软件的开发者)或矿工既不应该承担部署新版本的职责,也不应该有能力否决或阻碍激活流程。我认为今后所有新功能都要使用 BIP 8 LOT = True 通过 UASF 部署。我认为,很重要的是,我们要以一个草根组织的形象为未来树立先例,这个组织的成员背景多种多样,并不都来自同一个被视为比特币协议升级内容仲裁者的可辨识群体。

如果我们将来开创了让 Bitcoin Core 以外的人能够提议激活新功能的先例,就是史无前例地将对变革的怀疑态度推向了更高的层次。这样可以避免让后来的用户产生一种社会认知,即,开发者能够决定变革走向。这将极大提高变革的标准,并确保这个标准始终处于高位,而非变成用户听从专家决定的局面。激活可以通过外部客户端进行,如果新功能已经由打了补丁的客户端成功激活,就会在下一个 Core 版本激活。

这样一来,每个 “激活客户端” 都能在功能部署期间发挥临时作用,每个人都在成功激活后切换回 Core,以免要长期维护 Core 以外的客户端,同时让激活流程脱离 Core 开发者的掌控。

有人可能会反驳说,这在软分叉期间有引发链分裂的风险,但是事实上在软分叉期间总有可能发生链分裂。有了 LOT = True,我们就能提前知道分叉发生的时间点。如果比特币区块链即将分裂,会发生在激活前的最后一个信号发送期,即,第一个没有发送激活信号的区块被挖出之时。这成功将分叉时间点锁定在了一个可预测的时间段内,以免部分矿工在新功能激活后挖出违反规则的区块,导致分叉有可能在任意时间点发生。

如果某个新功能确实赢得共识,比特币经济体中的绝大多数参与者都会运行客户端来激活它。在这种情况下出现的链分裂只会带来轻微的破坏和不便。如果某个新功能没能赢得共识,这种情况下出现的链分裂同样只会带来轻微的破坏和不便,因为只有极少数人会分叉出去。这些人将面临一个抉择:继续坚守在分叉链上,还是回到比特币网络上。

归根结底,比特币是一个以市场驱动的系统,共识是自愿达成的。我认为,如果人们一直试图避免在共识建立过程中出现任何混乱局面,不仅会产生误导性,偏离比特币系统的本质,还会不可避免地造成更加集中化的社会控制和自上而下的决策印象。我们应该拥抱这一过程,不再试图控制它。

最后,这只是我个人对于应该如何激活新功能的看法,还有很多人持有其它不同的看法。人们不应该在这种事上迟迟不肯表态。现在,我们应该积极展开对话,而不是继续拖延,任由生态慢慢牵引着我们做出选择。

(完)

https://www.btcstudy.org/2022/06/07/how-bitcoin-should-be-upgraded-in-the-future/

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇

您不能复制本页内容(。・_・。)ノI’m sorry~