协议演进 / BIP/比特币改进提案 / BIP-103

BIP-103 随技术增长的区块大小

按带宽等技术进步的速率缓慢扩容:2017 年起每约 97 天上调一档 4.4%,年增 17.7%,一直排到 2063 年。本 BIP 目前处于已关闭状态。

一、档案卡

档案卡
编号BIP-103
标题Block size following technological growth
作者Pieter Wuille <[email protected]>
指定日期2015-07-21
层级Consensus (hard fork)(共识(硬分叉))
类型Specification(规范类)
状态Closed(已关闭)
阅读版https://bips.dev/103
官方原文https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki

二、放在哪一族

2015 年区块大小之争的硬分叉提案组,分类背景见 BIP-99。五份提案里,它是增速最克制、论述最“立场化”的一份:BIP-100 交矿工投票、BIP-101 以每两年翻倍冲到 2036 年的约 8.192GB、BIP-102 一次性到 2MB、BIP-104 按满载率自动调节;BIP-103 则主张上限只能随技术进步的实测速率走,且在 Motivation 里直言扩容之争的前提需要检讨——手续费市场与适应块空间竞争的生态是健康的,不必用快速扩容去回避它。作者 Pieter Wuille 同时也是 BIP-101 所提的版本位机制的提出者,但在本篇里他给出的是全组最慢的一条曲线。

三、它要解决什么

原文 Motivation 的推理链条值得完整转述:人们希望比特币随时间扩容、承载更多链上交易,代价是中继节点的带宽、处理与存储,以及区块在网络中的传播速度;但技术本身也在进步——当所依赖的各项技术及其市场可得性都改善后,没有理由让比特币的基础交易速率不按比例改善。因此,扩容的正当尺度是“与技术增长同步”,而不是满足某种需求预期:任何放宽上限的硬分叉都无法保证满足全部、乃至某个特定需求(除非预期挖矿生态高度中心化),手续费市场的形成应视为健康。

更深一层,它反对以扩容换时间:比特币相对中心化系统的优势不在规模,而在透明与无需信任;用快速扩容买时间,等于回避这一现实。由此得出对硬分叉的总体态度——硬分叉力量极大,必须极负责任地使用,只应限于无争议变更,否则会侵蚀系统赖以成立的低信任预期;正因扩容之争已有争议,本篇刻意让改动渐进、且起点推到足够远的未来。

四、规则本身

4.1 上限函数

区块大小上限改为一个函数,输入是前 11 个块时间戳的中位数(median time past):GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()),sigops 上限按比例缩放。原文给出的代码要点,逐项核对如下:

4.2 参数依据

Rationale 照原文:等 1.5 年再启动硬分叉,是为把风险降到最低(前提是它届时被证明无争议);每档仅 4.4% 的小步,使市场或技术突变的风险最小化;17.7% 的年增速与近年带宽的平均增速一致,而带宽被视为瓶颈——若日后实际技术跟不上这一增速,意向是用软分叉再把上限收紧;用基于时间的检查,是因为实现简单、上下文需求少、高效且易于审查;用“前一块的中位过去时间”保证单调递增、且能提前知道每个块的上限,不依赖该块自身的时间戳。

五、谁必须动

普通持币人:自跑全节点者须在这次硬分叉生效前升级;原文 Compatibility 明言这是打破与旧全节点兼容性的变更,不应在缺乏广泛共识时部署——持币人“不动”本身即构成对部署的约束。

钱包开发者:不直接校验块大小者无需改代码,但所依赖节点的链视图取决于其是否升级,须确认基础设施的跟进安排。

全节点与矿工:节点要实现以中位过去时间为输入的上限函数及成比例的 sigops 上限;由于起点被推到 2017 年,升级窗口长达约 1.5 年,这正是本提案部署设计的一部分。

共识层:1MB 常量被时间函数取代,但函数的每一步都写死在代码里,不依赖投票或链上数据——决定权既不在矿工(不同于 BIP-100),也不看需求(不同于 BIP-104),只锚定事先假定的技术增速。

六、现在算不算数,以及一个常见误读

状态为 Closed(已关闭):提案未获采用、已经关闭。它的 2017 年 1 月起点从未在主网生效;后来主网的实际扩容路径是 SegWit 的区块权重,与这条 46 年曲线无关。

常见误读:“BIP-103 是五份提案里的‘温和扩容派’,只是涨得慢一点。”只对了一半。它在数字上最慢,但文本立场并不温和:它明确说手续费市场健康、扩容不应以满足需求为目标、硬分叉只应用于无争议变更——按 BIP-99 的框架,它实际上是在质疑同组其他提案的部署正当性,而不只是给出另一个参数。

七、延伸

本页内容整理自 bitcoin/bips 仓库与 bips.dev,事实已与仓库核对;解读仅供学习参考。