💡 自学入门
Web3不是一件容易的事，作为一个刚刚入门 Web3 的新人，梳理一下最简单直观的Web3小白入门教程。整合开源社区优质资源，为大家从入门到精通 Web3 指路。每周更新 1-3 讲。欢迎关注我的推特：@bhbtc1337
进入微信交流群请填表：表格链接
文章开源在 GitHub：Get-Started-with-Web3
- [前言：比特币为什么需要「减肥」？](# 前言比特币为什么需要减肥)
- [交易延展性：快递包裹被恶意篡改的烦恼](# 交易延展性快递包裹被恶意篡改的烦恼)
- [隔离见证：巧妙的包装分离术](# 隔离见证巧妙的包装分离术)
- [权重系统：重新定义区块「大小」](# 权重系统重新定义区块大小)
- [费用优化：为什么 SegWit 更便宜](# 费用优化为什么 segwit 更便宜)
- [技术实现：深入 SegWit 机制](# 技术实现深入 segwit 机制)
- [向后兼容：软分叉的智慧](# 向后兼容软分叉的智慧)
- [常见问题](# 常见问题)
- [结语](# 结语)
想象你经营一家快递公司，每天要处理数万个包裹，但运输车辆的载重有限。随着业务增长，你面临了两个严重问题：
** 问题 1：包裹太重了 **
- 每个包裹里有 50% 是商品，50% 是各种证明文件（收据、签名、身份证复印件等）
- 运输效率低下，成本居高不下
- 客户抱怨运费太贵
** 问题 2：包裹编号不稳定 **
- 包裹编号基于整个包裹内容计算
- 恶意的人可以修改证明文件的格式（不影响有效性）
- 导致包裹编号改变，追踪系统混乱
这就是 2017 年比特币面临的现实问题：
- ** 交易拥堵 **：1 MB 区块限制导致网络拥堵
- ** 手续费暴涨 **：从几美分涨到几十美元
- ** 交易延展性 **：影响闪电网络等技术发展
比特币需要一次「减肥手术」，这就是隔离见证 (SegWit) 的诞生背景。
想象你寄了一个快递包裹：
包裹内容：一台笔记本电脑
包裹编号：ABC123（基于整个包裹内容计算）
证明文件：收据、保修卡、发票
** 延展性攻击场景：**
1. 你：寄出包裹，记录编号 ABC123
2. 恶意快递员：修改收据的字体格式（内容不变，但外观不同）
3. 结果：包裹编号变成 XYZ789
4. 你：用 ABC123 追踪包裹 → 查不到！
5. 但是：包裹内容完全没变，笔记本电脑安全送达
** 比特币中的实际情况：**
1. Alice：发送交易，交易 ID = A1B2C3...
2. 恶意节点：修改签名的 DER 编码格式
3. 结果：交易 ID 变成 D4E5F6...
4. Alice：用 A1B2C3 查询交易 → 查不到！
5. 但是：转账成功，Bob 收到了比特币
** 对普通用户：**
- 交易追踪困难
- 钱包显示错误
- 用户体验差
** 对开发者：**
- 无法依赖交易 ID 构建应用
- 闪电网络等 Layer 2 技术无法实现
- 智能合约功能受限
** 数学原因：**
传统交易 ID = SHA256 (版本 + 输入 + 输出 + 锁定时间 + 签名数据)
↑
可被修改的部分
继续快递公司的比喻，SegWit 提出了巧妙的解决方案：
SegWit 的创新包装方式：
主包裹：📦 [笔记本电脑 + 基本信息]
证明袋：📋 [收据 + 签名 + 身份证明]
包裹编号：只基于主包裹内容计算
优势：
- 证明文件被修改不影响包裹编号
- 主包裹更轻便，运输效率更高
- 但所有东西都还在，没有丢失任何信息
** 传统交易：**
{
"txid": "计算时包含签名",
"vin": [{
"scriptSig": "签名 + 公钥 + 其他证明" // 很长的证明数据
}],
"vout": [...]
}SegWit 交易：
{
"txid": "计算时不包含 witness",
"vin": [{
"scriptSig": "简短的 witness 程序引用"
}],
"vout": [...],
"witness": [
["签名", "公钥", "其他证明"] // 证明数据被「隔离」
]
}- ** 不是删除 **：witness 数据依然完整存储在区块中
- ** 不是压缩 **：数据大小本身没有变小
- ** 而是分离 **：改变了数据的组织和计算方式
** 比喻说明：**
就像重新设计包裹格式：
原来：[商品 + 证明文件] 混合打包
现在：[商品] + [证明文件] 分开包装
好处：
- 商品包裹编号稳定（交易 ID 稳定）
- 证明文件占用「便宜运输」（费用降低）
- 整体运输效率提升（容量增加）
SegWit 引入了一个全新概念：** 权重 (Weight)**，重新定义了区块的「大小」限制。
** 传统限制：**
区块最大限制 = 1,000,000 字节
SegWit 新规则：
区块最大限制 = 4,000,000 权重单位
权重计算公式：
权重 = (基础交易数据 × 4) + (witness 数据 × 1)
** 设计思路：给不同数据不同的「价格」**
基础交易数据：每字节 = 4 权重单位（昂贵）
Witness 数据：每字节 = 1 权重单位（便宜）
就像航空行李收费：
- 必需品（衣服）：正常价格
- 非必需品（礼品）：优惠价格
** 实际计算例子：**
一笔简单的 SegWit 交易：
- 基础数据：118 字节 × 4 = 472 权重
- Witness 数据：107 字节 × 1 = 107 权重
- 总权重：579 权重
- 等效大小：579 ÷ 4 = 144.75 字节
对比传统交易 225 字节，节省约 35%！
** 完整权重计算公式：**
对于每个交易：
if (交易有 witness 数据):
base_size = 交易大小 - witness 数据大小
witness_size = witness 数据大小
weight = base_size × 4 + witness_size × 1
else:
weight = 交易大小 × 4
区块权重 = sum (所有交易权重)
区块权重限制 = 4,000,000
** 虚拟大小 (vSize) 概念：**
vSize = ceil (weight / 4)
意义：等效的传统交易大小
用途：费用计算和容量估算
** 传统费用计算：**
矿工费 = 交易字节数 × 费率 (sat /byte)
例子：225 字节交易 × 20 sat /byte = 4,500 sat
SegWit 费用计算：
矿工费 = 虚拟大小 (vSize) × 费率 (sat /vbyte)
例子：579 权重 ÷ 4 = 145 vbytes × 20 sat /vbyte = 2,900 sat
节省：4,500 - 2,900 = 1,600 sat (35%)
| 交易类型 | 传统大小 | SegWit 权重 | vSize | 费用节省 |
|---|---|---|---|---|
| 简单转账 | 225 字节 | 579 权重 | 145 字节 | 35% |
| 2-of-3 多签 | 400 字节 | 1,312 权重 | 328 字节 | 18% |
| 复杂脚本 | 500 字节 | 1,400 权重 | 350 字节 | 30% |
** 长期累积效应：**
- 个人用户：每年节省数十美元手续费
- 企业用户：每年节省数千美元
- 全网络：每天节省数百万美元
** 三种 SegWit 地址格式：**
| 格式 | 前缀 | 全称 | 特点 |
|---|---|---|---|
| P2WPKH | bc1q | Pay to Witness PubKey Hash | 原生 SegWit，最高效 |
| P2WSH | bc1q | Pay to Witness Script Hash | 原生 SegWit 多签 |
| P2SH-P2WPKH | 3 | SegWit wrapped in P2SH | 兼容旧钱包 |
** 原生 SegWit 交易 (P2WPKH)：**
{
"txid": "c3d4e5f6a7b8...",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"witness": [
"3045022100d1e2f3a4b5c6...", // 签名
"0279be667ef9dcbb..." // 压缩公钥
],
"sequence": 4294967293
}** 关键观察：**
- **scriptSig 为空 **：所有证明数据都在 witness 中
- **witness 数据 **：包含签名和公钥，但不影响交易 ID
- **sequence 值 **：4294967293 表示支持 RBF (费用替换)
P2WPKH 脚本执行过程：
传统 P2PKH 需要的脚本：
scriptSig: [签名] [公钥]
scriptPubKey: OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG
SegWit P2WPKH 的简化：
scriptSig: 空
scriptPubKey: OP_0 <pubkey_hash>
witness: [签名] [公钥]
执行时：将 witness 数据作为 P2PKH 脚本执行
** 安全性保障：**
- 相同的签名验证算法
- 相同的密码学安全性
- 只是数据组织方式不同
** 技术对比：**
传统交易 ID 计算：
txid = SHA256 (SHA256 (完整交易数据))
SegWit 交易 ID 计算：
txid = SHA256 (SHA256 (交易数据 - witness 部分))
结果：
- witness 数据修改不影响 txid
- 为 Layer 2 技术提供稳定基础
- 解决了延展性问题
比特币网络有数万个节点，强制所有人同时升级是不现实的。SegWit 通过软分叉实现了优雅升级：
** 软分叉的巧妙设计：**
老节点看 SegWit 交易：
「这个交易的输出脚本是 OP_0 < 数据 >」
「我不认识这个新格式，但协议说这种交易『任何人都可以花费』」
「既然有人花费了，说明是有效的，我接受」
新节点看 SegWit 交易：
「这是 SegWit 格式，我需要验证 witness 数据」
「签名正确，公钥匹配，交易有效」
SegWit 采用时间线：
2017 年 8 月：SegWit 激活（0% 使用率）
2018 年：约 15% 使用率
2019 年：约 40% 使用率
2020 年：约 60% 使用率
2024 年：约 80% 使用率
** 采用障碍：**
- 钱包软件需要更新支持
- 用户教育和接受过程
- 交易所和服务商迁移
| 发送者 | 接收者 | 兼容性 | 费用效率 |
|---|---|---|---|
| 传统 | 传统 | ✅ | 正常 |
| 传统 | SegWit | ✅ | 正常 |
| SegWit | 传统 | ✅ | 部分优化 |
| SegWit | SegWit | ✅ | 最优 |
# 生成 native SegWit 地址
segwit_address = rpc.getnewaddress ("","bech32")
print (f"SegWit 地址: {segwit_address}")
# 地址特点：bc1q 开头，费用最低# 费用节省计算
def calculate_fee_savings (traditional_size, segwit_weight, fee_rate):
traditional_fee = traditional_size * fee_rate
segwit_fee = (segwit_weight / 4) * fee_rate
savings = traditional_fee - segwit_fee
return savings, (savings /traditional_fee) * 100
# 示例：简单转账
savings, percentage = calculate_fee_savings (225, 579, 20)
print (f"费用节省: {savings} sat ({percentage:.1f}%)")** 绝对是的！** 这是最常见的误解。
误解：SegWit 把签名数据存储在区块链外
事实：所有数据都在区块链上，只是组织方式不同
比喻：
误解的想法：把快递包裹拆分，一部分寄丢了
实际情况：重新包装，但所有东西都在同一辆运输车上
** 设计哲学：**
基础交易数据（输入输出）：核心信息，全价收费
Witness 数据（签名证明）：辅助信息，折扣收费
目的：
1. 激励使用 SegWit 格式
2. 提高网络整体效率
3. 为未来升级留出空间
** 数学逻辑：** 权重系统确保：
- 老交易：权重 = 大小 × 4（没有变化）
- 新交易：权重 = 基础 × 4 + witness × 1（更优惠）
** 容量提升机制：**
理论最大：4 MB（如果区块只包含 witness 数据）
实际情况：1.7 - 2 MB（混合交易类型）
计算例子：
传统 1 MB 区块：约 4,400 笔交易
SegWit 区块：约 6,900 笔交易
提升：约 55%
** 为什么不是 4 倍提升？**
- 不是所有交易都使用 SegWit
- SegWit 交易仍有基础数据部分
- 实际使用中的混合情况
** 关键作用：**
闪电网络需要：
- 稳定的交易 ID 来跟踪通道状态
- 预签名交易不被延展性攻击
- 安全的资金托管机制
SegWit 提供：
✅ 交易 ID 稳定性
✅ 费用降低
✅ 容量提升
✅ 为 Layer 2 奠定基础
** 技术依赖：**
闪电网络的承诺交易 (Commitment Transaction)：
- 必须有稳定的交易 ID
- 需要预先签名但延后广播
- 任何 ID 变化都会破坏安全模型
SegWit 解决了这个根本问题！
** 迁移策略：**
个人用户：
1. 升级钱包软件
2. 生成 SegWit 地址
3. 将资金转移到 SegWit 地址
企业用户：
1. 评估现有系统兼容性
2. 测试环境验证
3. 分批迁移资金
4. 更新内部系统
** 迁移收益：**
- 立即享受费用折扣
- 提高交易优先级
- 支持未来新功能
SegWit 技术展现了比特币社区解决复杂技术问题的智慧和能力：
- ** 问题解决 **：优雅地解决了交易延展性和容量问题
- ** 向前兼容 **：为闪电网络和 Taproot 等技术铺平道路
- ** 经济效益 **：降低了用户的交易成本
- ** 技术示范 **：证明了软分叉升级的可行性
SegWit 体现了几个重要的设计理念：
- ** 渐进改进 **：不是推倒重来，而是优化现有系统
- ** 向后兼容 **：确保网络稳定，避免分裂
- ** 经济激励 **：通过费用优势推动技术采用
- ** 长远视野 **：为未来技术发展预留空间
SegWit 的成功激活证明了：
- 比特币可以在保持去中心化的同时实现重大升级
- 技术社区能够达成共识并推动创新
- 软分叉是处理争议性升级的有效方式
当你使用 bc1 开头的 SegWit 地址时，你不仅在节省手续费，更是在参与一个历史性的技术升级。每一笔 SegWit 交易，都是对比特币技术进步的贡献。
在 Web3 的世界里， SegWit 代表着这样一种精神：通过巧妙的技术创新，我们可以在不牺牲安全性和去中心化的前提下，持续改进和优化系统。
🌟 ** 完整代码示例 **：本章涉及的所有 SegWit 操作代码实现请查看：segwit_examples.py