首页 > 比特币 > 正文
技术 - 主根即将到来:它是什么

Taproot于2020 年 10 月合并到 Bitcoin Core中,只剩下这个备受期待的协议升级的激活方法,专注于为比特币增加智能合约灵活性和更多交易隐私。

上周,比特币开发社区通过互联网中继聊天 (IRC) 聚集在一起,讨论了 Taproot 激活的参数和 BIP 8 信号机制的两个代码拉取请求 (PR)。

比特币开发组织者迈克尔福克森通过比特币开发邮件宣布: “为了让这更接近终点线,我们将在 2 月 2 日星期二 UTC 时间 19:00 在##taproot-activation 频道上组织 IRC 会议。”列表。“主要目标将是最终确定修订后的 BIP 8 激活方法……”

最终,那次会议让我们更深入地了解了自 SegWit 以来比特币最重要的协议可能会如何向前发展。

比特币开发者现状

比特币开发商Anthony Towns为 Taproot 的激活编制了提案和可能的方案。在 2 月 2 日的会议上,似乎支持率最高的是“BIP 8 (false, 1y)”和“BIP 8 (true, 1y)”。但是,没有进行投票,只是讨论了每种替代激活方法。

但是,这是什么意思?BIP 8 是一种机制,允许通过软分叉升级比特币网络中的共识,特别是矿工激活的软分叉或 MASF,可以选择在一段时间后添加用户激活的软分叉(UASF)。在上一次共识更新(SegWit)中,除了BIP 9 的MASF之外,还使用了用户激活的软分叉(UASF)。然而,对于矿工来说,Taproot 似乎没有争议,所以这次似乎不太可能需要 UASF。

回到提案,参数是“lockinontimeout”和“timeout”,其中lockinontimeout基本上意味着是否会强制激活,“超时”意味着它将被激活的窗口。另一个没有得到足够讨论的相关参数是“startheight”。

如果 lockinontimeout 为假,并且更新没有足够的支持,它会被取消并定义一个新的提案。(比特币开发者

澄清
一下:BIP8 w/LockinOnTimeout 是 MASF w/UASF 回退。
只要矿工激活,就不会发生 UASF。

预先计划的 UASF 还确保 MASF 发生:
它避免赋予矿工否决权,并创建适当的激励措施以确保 MASF 发生。#Bitcoin #Taproot

- Luke Dashjr (@LukeDashjr) 2021 年 2 月 2 日

">Luke Dashjr 将 lockintimeout=false 描述为赋予矿工一种他们从未打算拥有的额外权力),

“如果你从(timeout=T , lockinontimeout=false)开始,当 T 被击中时有三种可能性:激活失败,你用新的激活重试(timeout=T+1yea r, lockinontimeout=true,例如);在此之前,您告诉每个人将他们的软件切换到(timeout=T , lockinontimeout=true),此时您已将 MASF 升级为 UASF,”Towns 在 IRC 上写道。“还有可能让每个人都升级到指定的软件(超时=T-6 个月,lockinontimeout=true) 在这种情况下,升级的人将在 T-6 个月开始拒绝区块,如果最长的链在那时激活,则新旧软件都将激活软分叉。”

然而,Dashjr 不同意 lockinontimeout=false:

“……我们对lockingtimeout = false 总体上满意吗?”比特币开发者Maxim Orlovsky问道。

“是的,”闪电开发人员Rusty Russell回应道。“如果需要,我们有一把 UASF 锤子,但最好不要使用它。”

“lot=true 并不意味着我们使用它,lot=false 意味着意图是让矿工决定,”Dashjr 写道。“BIP8(false) 是一种回归。”

但拉塞尔反对他认为是开发人员强加的做法:“我觉得避免开发人员授权出现在协议上很重要,而且如果在激活之前发现问题,我也喜欢有一个逃生口,”他写道。“因此,我更喜欢从 lockin=false 开始,如果它没有激活,则在 6 个月后重新访问。”

“没有开发人员的要求……在相同的 1 年期间执行 1y,false 然后 1y,true 更有意义[在两个后续部署的情况下],”Dashjr 回应道。

但罗素似乎并没有动摇:

“我不同意,”他写道。“矿工获得协调能力是因为我们可以以分散的方式可靠地衡量他们,这与其他群体不同。这意味着*不*协调的能力,是的。但我们也有一个计划,因为 BIP-8 使 UASF 不太可能导致分裂。这是我们能做的最好的。”

“lot=true 是在为此计划,”Dashjr 回应写道,“它并没有阻止矿工做 MASF。”

聊天中的其他人建议将 lockinontimeout=false 设为可选,但默认为:

CoinSwap 开发人员Chris Belcher写道:“lot=false 比 lot=true 更安全,因此考虑到我们知道哈希算力已经有大约 90% 的人支持主根,因此值得先做 lot=false 。”

如果用户可以在某个时候轻松地将 lot=false 更改为 lot=true 而不需要新的核心版本,我会支持将 lot=false 保留为默认值,” Keagan McClelland写道。

UASF 锤子

Dashjr 希望使用“BIP 8 (true)”,UASF 的后备机制,作为一种博弈论设备,以确保矿工将激活 Taproot,并让他们无法选择“否决”权力,就像 SegWit 发生的情况一样。

“鉴于信号要求,如果矿池重视拖延主根,他们可以实现什么类型的拖延或悲痛攻击?” 2 月 2 日,一位名为“gloved”的用户在 IRC 上提问。“例如,滥用激活所需的边际算力。”

提醒一下,信号是关于降低分叉风险,与政治支持或投票无关。

“MASF 是首选路径,如果矿工未能发出信号,UASF 将作为后备,”Dashjr 写道。“如果很明显有人在拖延它,社区可以更快地移动 UASF。”

PR 1020 和 1021

要使 BIP 8 发挥作用,必须对其进行修改。这意味着信号机制的变化,这些是旨在这样做的代码 PR:

  • 1020:在 LOCKED_IN 阶段之后不需要矿工信号,因为到这个阶段软分叉肯定会被激活。
  • 1021:允许某些 MUST_SIGNAL 块不发出信号。

1020 在 2 月 2 日的会议上获得了认可,最初认为 1021 没有必要。

Dashjr 写道:“好的,所以 1021 仅在矿工没有激活分叉时才有意义。” “1021 仅在 UASF 场景中……它允许多达 5% 的块丢失所需的信号……IMO 这毫无意义,只会增加复杂性。”

但后来在交流中,Blockstream研究员尼克·乔纳斯指出,1021年可能是必要的。

“Re #1021,如果你决定在大多数节点仍然运行 bip8(false) 的情况下运行 bip8(true),你真的不会运行没有实现 #1021 的代码,否则你可能会在错误的链上结束,”乔纳斯写道.

“尼克有一个强项,”Dashjr 回应道,后来在 IRC 上。“没有 1021,你可以运行 LOT=true 并且无法遵循 Taproot 激活的链!”

在与这些 PR 相关的另一次交流中,Towns 指出这些 PR 如何与不良行为者的潜力相关。

“(1)这里的论点是,在 UASF 期间,要求发出信号会产生链分裂的风险——如果一个区块没有发出​​信号,非 UASF 矿工将以此为基础,但每个人都知道这两个区块都将被拒绝,所以这是攻击者双花的机会。接受尽可能多的非信令块(即最多 5%)限制了这种攻击,”汤斯写道。“(2) 另一个考虑是如果你从更长的超时开始(timeout=2 年,lockinontimeout=true/false)然后想加快激活,因为每个人都升级了,市场说他们想要它,有 6%试图说服每个人比特币很烂的矿工,我们应该转移到另一个链,然后我们可以设置(超时 = 1 年,lockinontimeout = true)。”

“但无论如何,一旦我们达到 5%,这些矿工就会产生问题,对吧?” 达什吉尔问道。

“‘一旦我们达到 5% 就制造问题’——是的,”唐斯回答说,“如果有超过阈值的矿工,他们就可以制造问题;如果只有 2% 左右,这可以避免出现问题,如果我们使用 lockinontimeout=true 进行更短的超时,那么如果我们达到超时,并获得 98% 的块发信号而不是 100%,这将确保每个人都保持共识,而且即使是 98% 的链以最长的权重持续下去,做 bip148 式快速 UASF 的人也不必降级他们的软件。”

“鉴于 1021 是 UASF 方案,它是否只需要合并直到需要它的不太可能的点?” 福克森问道。

“是的,只有'旧'节点运行此代码才有意义,”用户ghost43 回答。

最后,两个 PR 合并了。

总之

BIP 8(它是 BIP 9 的变体)似乎是目前最严重的激活机制。但是对于激活是否应该坚定存在争议,即使它代表了 UASF 的风险,拒绝了矿工的否决权;在信号不足的情况下,以延迟激活的概率安全地进行;或将 false 设置为默认值,如有必要,激活 true。第一个选项的支持者认为矿工不应该破坏社区进程,而第二个选项的支持者认为 UASF 回退是不必要的,并且显示出不合理的强加,因为矿工已经表示接受 Taproot。

PR 1021 是 BIP 8 的一个更安全的通用错误修复,因为它可以防止在某些情况下链分裂,其中超过 95% 但小于 100% 的所有哈希算力支持软分叉。

下一次 Taproot 激活会议(UTC 时间 2 月 16 日星期二 19:00)将重点关注代码审查,随后将召开另一次会议来讨论参数。随着讨论的继续,比特币越来越接近其多年来最重要的协议升级。

猜你喜欢
发表评论

电子邮件地址不会被公开。 必填项已用*标注

评论信息