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

BIP-102 区块扩容至 2MB

最简的一次性扩容：满足旗日时间与 95% 信号两个触发条件后，把区块上限从 1MB 提到 2MB，sigops 上限同比例放大。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

2015 年区块大小之争的硬分叉提案组，分类背景见 BIP-99。它是同组五份里刻意做到最简的一份，也与作者自己的另一份提案形成对照：Jeff Garzik 在 BIP-100 里主张上限由矿工投票逐期决定，到 BIP-102 则收成一个写死的数字、一次到位的改动。与 BIP-101 的 20 年指数曲线、BIP-103 跨 46 年的慢爬坡、BIP-104 的自动调节公式相比，它不回答“以后怎么办”：BIP-101 原文正是以此为由批评一次性方案——新上限一到，同样的争论就得重来。本篇的立场恰恰相反（见第三节）：先让网络完成一次硬分叉升级的演练，并维持当下的手续费与块空间经济政策。

三、它要解决什么

原文 Motivation 只列两条，照录其意：其一，延续当前的经济政策；其二，演练一次硬分叉网络升级（Exercise hard fork network upgrade）。Discussion 一节展开：短期看，需要一次扩容来维持手续费与块空间方面的现行经济政策、符合市场预期、防止市场紊乱；长期看，上限应当反映网络工程所能承受的最大值。换言之，它要解决的不只是“块不够大”，还包括“比特币从未认真做过一次有计划的硬分叉”——用最小幅度的改动，把升级流程本身走通一遍。这正是它在 BIP-99 框架里的位置：挑一个最可能达成无争议的变更，做无争议硬分叉的先例。

四、规则本身

全文规范只有三条，逐项照原文：

4.1 规范要点

1. 在触发点把 MAX_BLOCK_SIZE 提高到 2,000,000 字节；
2. 最大块 sigops 上限按相同倍数提高，保持 SIZE/50 的既有公式；
3. 触发条件须同时满足：（1）区块时间到达旗日（flag day）当天的 00:00:00；（2）最近 1,000 块中 95% 已信号支持。

4.2 兼容性

原文 Backward compatibility 写明：全量校验的旧客户端与此变更不兼容；第一个超过 1,000,000 字节的块，会把旧客户端从新网络中分区出去。

全文未再给出更多参数：没有增长曲线、没有后续调整机制、没有单独的测试网安排。实现为作者仓库中的 2015_2mb_blocksize 分支。这种“少即是全部”本身就是它的设计主张——把争论面缩到最小，只问社区一个问题：2MB，能不能先过。

五、谁必须动

普通持币人：硬分叉无例外——自跑全节点者须在触发前升级，否则第一个超 1MB 的块出现时即被分区到旧链。

钱包开发者：依赖全节点校验的钱包须确保后端已升级；本提案不改交易与地址格式，钱包自身的构造逻辑无需改动。

全节点与矿工：节点改两处常量（块大小上限与 sigops 上限）；矿工在触发前以信号表明支持，1,000 块窗口内达到 95% 是激活的必要条件之一。

共识层：上限从 1,000,000 字节改为 2,000,000 字节，仅此一处及其 sigops 连带项；规则形状（固定常量）不变，这使它成为五份同组提案里对共识层改动面最小的一份。

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

状态为 Closed（已关闭）：提案未获采用、已经关闭。它的旗日与 95% 信号触发从未在主网凑齐，1MB 上限此后是经 SegWit 的区块权重安排被绕开的，并非被提到 2MB。

常见误读：“BIP-102 失败是因为 2MB 这个数字太小、没人支持。”原文并不支持这种读法，也不要替它补史实：本页只按档案记其状态为未获采用、提案关闭。它真正的文本特点在另一面——它是五份提案里唯一把“完成一次硬分叉演练”与“扩容”并列为动机的，理解它要连同 BIP-99 关于无争议硬分叉需预留普遍升级时间的讨论一起读。

七、延伸

• 阅读版：https://bips.dev/102
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki
• 相关：BIP-99 分叉分类、BIP-100 矿工投票、BIP-101 定时增长、BIP-103 随技术增长、BIP-104 Block75
• 仓库总目录：https://github.com/bitcoin/bips

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