admin
ce8e6ceed9
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复： - 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录） - tmp/（32.4 M，按接续棒命名的过程临时区） - .workbuddy/tmp/（39.5 M） - 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物） - tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留 入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与 接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、 .workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。 排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、 打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
336 lines
22 KiB
Markdown
336 lines
22 KiB
Markdown
# 分布式数据链路 · 技术方案与落地路线
|
||
|
||
> 📌 术语：本文以「分布式」指代本项目（2026-09-19 由「去中心化」更名）；引用原文、DAO 专有名词与行业泛指保留原措辞。
|
||
|
||
> 版本 v1.0 ｜ 2026-09-19 ｜ 状态：**待拍板（S0 未开工）**
|
||
> 本文是**决策 + 落地**文档：给出"要不要做、做到哪一档、怎么分步"的判据，不写空泛的区块链科普。
|
||
> 事实依据见 **§10**，其中标注口径与来源；凡实测值均注明"常态/峰值/理论"区别，避免误用。
|
||
|
||
---
|
||
|
||
## 0. 结论先行
|
||
|
||
**三行判定：**
|
||
|
||
1. **若目标只是"防内部篡改 + 可审计"** ⇒ **不用区块链**。透明日志（Merkle 只追加日志）+ 定期把根哈希锚定到公链，即可获得"篡改可检测、且不可抵赖"的效果，成本比自建链低一个数量级。
|
||
2. **若目标要求"多方各自持节点、彼此不完全信任、共同写入"** ⇒ 用**联盟链**（国内合规场景优先 FISCO BCOS），**不要自研链**。自研链的代价不在技术可行性，在运维与团队。
|
||
3. **若目标面向公众、且要求"资产归用户所有、可自由流通"** ⇒ 上**公链 L2**（Arbitrum / Base）。但这意味着**链上数据全网公开** ⇒ **敏感数据永远不上链**（§5 是硬红线）。
|
||
|
||
**一条反判定**：如果做链的理由是"区块链听起来更安全"——**不要做**。链解决的是*信任*问题，不是*安全*问题；对单方持有的数据，链带来的攻击面（合约漏洞、密钥管理、节点运维）大于它消除的风险。
|
||
|
||
---
|
||
|
||
## 1. 范围与前提
|
||
|
||
**覆盖**：数据分层落点 · 三档技术路线选型 · 敏感数据专项 · 准入合规 · 分阶段落地 · 验收判据 · 负面清单。
|
||
|
||
**不覆盖**：具体业务建模、代币经济设计、跨境数据传输安排。
|
||
|
||
**前提假设**（若与实际不符，§2/§4 的选型结论需重算）：
|
||
|
||
| 编号 | 假设 | 若为否则影响 |
|
||
|---|---|---|
|
||
| P1 | 参与方数量为个位数，且各自**有能力运行节点** | ≥数十方 ⇒ 联盟链运维成本失控，转 L2 或托管方案 |
|
||
| P2 | 存在**至少两个互不完全信任**的写入方 | 只有一个写入方 ⇒ 直接走 §4.1 路线 A，不必上链 |
|
||
| P3 | 不对**社会公众**开放节点 / 仅对授权成员开放 | 对公众开放 ⇒ §6 备案为强制前置（详见该节判据） |
|
||
| P4 | 业务在中国境内运营 | 境外运营 ⇒ §6 适用性另判 |
|
||
|
||
---
|
||
|
||
## 2. 第一决策：到底需不需要"链"
|
||
|
||
按目标对号入座，**命中即停**，不要越级选型（越级 = 平白多一条运维线）。
|
||
|
||
| 你的真实目标 | 需要链吗 | 推荐方案 | 关键理由 |
|
||
|---|---|---|---|
|
||
| 防止 DBA / 内部人偷偷改库 | **不需要** | 路线 A：哈希链审计日志 + 锚定 | 你要的是"改了一定被发现"，不是"改不了" |
|
||
| 对外证明"这条记录 X 时间就是这个值" | **不需要** | 路线 A | 第三方时间戳 + 锚定即可，可验证成本近 0 |
|
||
| 多家公司共同记账、要对账分账 | **需要（联盟链）** | 路线 B | 需要多方共同写入与准入控制 |
|
||
| 用户资产要能自由转让 / 跨平台流通 | **需要（公链）** | 路线 C | 只有公链提供无需许可的可组合性 |
|
||
| 数据要"上链才显得可信" | **不需要** | ⛔ 不做 | 信任来自可验证性，不来自"用了区块链"这个词 |
|
||
|
||
**判据句式**：先回答"**谁和谁之间不信任**"。
|
||
- 没有第二个不信任的主体 ⇒ 无需链。
|
||
- 对手是"自己人" ⇒ 检测优先（路线 A）。
|
||
- 对手是"合作方" ⇒ 共同写入（路线 B）。
|
||
- 对手是"任何人" ⇒ 无需许可（路线 C）。
|
||
|
||
---
|
||
|
||
## 3. 数据分层落点（核心模型）
|
||
|
||
一句话：**值钱和要防改的上链，隐私和高频的留在链下，大文件的只有哈希上链。**
|
||
|
||
| 层 | 放什么 | 典型技术 | 不得出现 |
|
||
|---|---|---|---|
|
||
| **链上** | 匿名 ID · 数值状态（余额/积分/等级）· 业务流水 · 大文件的**内容哈希** · 权限变更记录 | 公链 L2 / 联盟链 | 明文密码、卡号、身份证、私钥、邮箱、手机号 |
|
||
| **链下 · 关系库** | 密码哈希（Argon2id）· 卡号 Token · 邮箱 · 实名信息 · 会话与风控 | PostgreSQL / MySQL + 列级加密 + 细粒度访问控制 | —— |
|
||
| **链下 · 对象/去中心化存储** | 3D 资源 · 玩家生成内容 · 详细日志 · 存档快照 | S3 / 自建 MinIO / IPFS / Arweave | 明文敏感字段 |
|
||
|
||
**关键澄清**：**"加密后上链"不等于安全**，理由四条（这是最常见的误区）：
|
||
1. **不可撤** —— 算法破了或密钥泄了，历史区块仍在，无法换算法重来；
|
||
2. **元数据泄露** —— 时间、频率、大小、地址关联性本身就是隐私；
|
||
3. **密钥轮换不可行** —— 轮换后旧密文永久留链，形成"历史数据永远更弱"的斜坡；
|
||
4. **合规冲突** —— 删除权（§6.3）要求真删，链上做不到。
|
||
|
||
**正确姿势**：链上只放**无关联性的哈希 / 匿名 ID**；敏感明文与身份映射**只存关系库**，且二者之间的映射关系本身就是保护对象。
|
||
|
||
---
|
||
|
||
## 4. 三档技术路线
|
||
|
||
### 4.1 路线 A：透明日志 + 锚定（成本最低，优先评估）
|
||
|
||
**组成**：只追加审计日志（RFC 6962 式 Merkle 树）→ 定期（如每小时/每天）计算根哈希 → 把根哈希写入公链交易备注字段，或提交给第三方可信时间戳服务。
|
||
|
||
**为什么够用**：透明日志给的是**篡改可检测性**，且提供两种密码学证明：
|
||
- **包含证明**：某条记录确实在某个版本的日志里；
|
||
- **一致性证明**：新旧两个版本的日志互为前缀（即"只追加、没被改写"）。
|
||
|
||
任何人拿到这些证明都能独立验证，无需信任日志运营方。一旦发现不一致，即构成不可抵赖的证据。
|
||
|
||
| 优点 | 缺点 |
|
||
|---|---|
|
||
| 成本极低（锚定一次几百字节，年成本可忽略） | 只**检测**篡改，不**阻止**篡改（需配合告警） |
|
||
| 无需多节点共识、无需新运维线 | 不提供"多方共同写入"（写入方仍是单一主体） |
|
||
| 可验证性对第三方开放 | 需要**有人真的去验证**（否则形同虚设 ⇒ 必须设外部监督或自动校验） |
|
||
| 可随时升级为路线 B/C 的上层 | —— |
|
||
|
||
**适用**：单组织内部防篡改、存证、日志不可否认、审计留痕。
|
||
|
||
### 4.2 路线 B：联盟链（多方互信，国内合规场景）
|
||
|
||
| 对比项 | FISCO BCOS | Hyperledger Fabric |
|
||
|---|---|---|
|
||
| 定位 | 国产自主可控，金融/政务 | 企业级通用，生态最大 |
|
||
| 共识 | PBFT（秒级确认）· 支持 Raft/PoA | 可插拔：Raft / Kafka / BFT |
|
||
| 国密 | **原生** SM2/SM3/SM4 | 需自行配置国密模块 |
|
||
| 部署难度 | **低**（单机 4 节点一条命令） | 高（依赖较多，链码生命周期复杂） |
|
||
| 合约语言 | Solidity | Go / Node.js / Java |
|
||
| 隐私 | 群签名/环签名 + 权限合约 | **通道（Channel）** + 私有数据集，隔离更强 |
|
||
| 吞吐量 | 单链约 1,000–3,000 TPS，集群可线性扩展 | 优化后 5,000+ TPS |
|
||
| 国内应用 | 金融、政务、医疗广泛 | 医疗、物流、跨境 |
|
||
|
||
**选型建议**：
|
||
- **国内运营 + 需过合规** ⇒ **FISCO BCOS**（国密原生是决定性优势，部署简单对小团队友好）；
|
||
- **已有 Go/Java 团队 + 需要强数据隔离** ⇒ Fabric（通道机制在"不同参与方看到不同数据"上更成熟）；
|
||
- **两者都不要** ⇒ 见 §4.3。
|
||
|
||
**⚠️ 必须承认的局限**：联盟链的"去中心化"是**准入式**的——节点是已知且授权的，共识只在成员间达成。它能解决"合作方互不信任"，**不能**解决"公众可验证"。若后者是硬需求，必须走路线 C。
|
||
|
||
### 4.3 路线 C：公链 L2（面向公众的资产层）
|
||
|
||
**为什么是 L2 而不是 L1**：L2 已是行业主流扩容方案，且费用与延迟已达到日常交互可用。**EIP-4844（2024-03 Dencun）blob** 是改变 L2 经济学的关键升级，数据可用性成本降约 90%，此后 L2 处理了以太坊约 60–70% 的交易量；blob 容量在 2026-01 又扩容过一次。
|
||
|
||
**性能如实说明**（三种口径必须分清，混用是最常见的误导）：
|
||
|
||
| 口径 | 数值 | 说明 |
|
||
|---|---|---|
|
||
| 理论 TPS | 数万 | 营销材料常用，不具备参考价值 |
|
||
| **峰值实测** | 2,000+ | 仅在 meme 币等尖峰时段出现 |
|
||
| **常态实测** | **两位数 ~ 低三位数**（Base ≈ 89、Arbitrum ≈ 57） | **这才是规划容量时应使用的数字** |
|
||
| L1 对照 | 15–25 TPS | —— |
|
||
|
||
**费用与终局性**：
|
||
|
||
| 网络 | 类型 | 常态单笔 | 终局性 |
|
||
|---|---|---|---|
|
||
| Base | Optimistic | < $0.01 | 秒级确认 / 7 天挑战期 |
|
||
| Arbitrum | Optimistic | $0.01–$0.03 | 秒级确认 / 7 天挑战期 |
|
||
| Optimism | Optimistic | $0.01–$0.05 | 秒级确认 / 7 天挑战期 |
|
||
| zkSync / Linea / Scroll / Starknet | ZK | $0.01–$0.10 | **分钟级 ~ 数小时**（无需 7 天） |
|
||
|
||
**🔴 一条常被说反的事实**：ZK 相对 Optimistic 的优势是**终局性**（分钟级 vs 7 天挑战期）与**不依赖"存在诚实少数"这一安全假设**；**不是"验证速度更快"**——ZK 的证明生成反而是额外开销。选型时若"提现到 L1 的等待时间"是硬指标，选 ZK；否则 Optimistic 生态与流动性更成熟。
|
||
|
||
**公链 L2 的代价**：链上数据**全网公开且永久**。因此路线 C 只承载 §3 表格中"链上"那一栏的内容，其余一律不上链。
|
||
|
||
---
|
||
|
||
## 5. 敏感数据专项（硬红线）
|
||
|
||
### 5.1 三类数据的正确做法
|
||
|
||
| 数据 | ⛔ 禁止 | ✅ 正确做法 |
|
||
|---|---|---|
|
||
| 登录密码 | 上链（任何形式，含加密） | **Argon2id** 加盐哈希，存关系库；验证在服务端完成（bcrypt 属次选） |
|
||
| 银行卡 / 支付账号 | 上链、自建存储 | **Tokenization**：经 PCI-DSS 认证的支付网关生成无意义 Token，链上/业务库只放 Token |
|
||
| 实名信息（身份证等） | 上链 | 链下加密存储 + 细粒度权限；链上只放**不可反推**的匿名 ID |
|
||
| 私钥 / 助记词 | 上链、服务端明文保存 | 用户自持（硬件钱包 / 设备安全芯片）；服务端只做签名验证 |
|
||
| 生物特征 | 上链 | 不出设备；仅存比对结果 |
|
||
|
||
### 5.2 零知识证明能做什么、不能做什么
|
||
|
||
**能做**：在不公开明文的前提下证明**某个命题为真**（如"该用户已成年""余额充足""身份已核验过"）。用户本地生成证明，链上只验证证明，看不到原文。
|
||
|
||
**不能做**：
|
||
- ❌ 不能替代密码存储（它证明"我知道密码"，但不解决"密码本身怎么存"）；
|
||
- ❌ 不能防住**输入侧**泄露（客户端被木马，证明生成前原文已丢）；
|
||
- ❌ 不解决**关联性**（同一个证明反复提交仍可被关联分析）；
|
||
- ❌ 引入显著的计算与工程复杂度，**不是免费选项**。
|
||
|
||
**判据**：只有当"必须向链上/第三方证明某个结论、但不想交出原始数据"是硬需求时，才引入 ZK；否则先用 §5.1 的分层方案。
|
||
|
||
### 5.3 私有链为什么也不是隐私容器
|
||
|
||
私有链的"私有"指的是**准入**，不是**可见性**。在"全状态复制型"链上，任何拿到节点访问权的人都能直接读底层状态库（LevelDB / RocksDB 等）拿到全量历史数据，且缺少关系库那种**列级加密与动态脱敏**能力。
|
||
|
||
⚠️ **但不要过度概括**：并非所有联盟链框架都如此——Fabric 的**通道（Channel）**与**私有数据集**、Corda 的 need-to-know 分发，本身就提供可见性隔离。**选型时以具体框架的隔离机制为准，别拿"区块链"这个大类下结论。**
|
||
|
||
---
|
||
|
||
## 6. 准入合规（中国境内运营）
|
||
|
||
### 6.1 适用性判据（**决定成本的第一道闸门**）
|
||
|
||
《区块链信息服务管理规定》第二条界定适用范围为：*基于区块链技术或者系统，通过互联网站、应用程序等形式，**向社会公众提供信息服务***。
|
||
|
||
⇒ **按条文文义**：
|
||
- **对公众开放**（任何人可访问/可参与节点） ⇒ **落入适用范围**，§6.2 全部条款适用；
|
||
- **纯内部使用、不对公众提供任何信息服务** ⇒ 一般不构成该《规定》所称的"区块链信息服务"。
|
||
|
||
⚠️ **边界模糊地带**：对内系统但**对外提供了查询/展示入口**（如"公众可查存证"页面），实务上极易被认定为"向社会公众提供信息服务"。**开做前应就此点取得书面确认**（备案系统咨询或法律意见），不要自行推定。
|
||
|
||
### 6.2 若落入适用范围 —— 强制义务清单
|
||
|
||
| 条款 | 义务 | 时限 / 要求 |
|
||
|---|---|---|
|
||
| 第 11 条 | **备案** | 提供服务之日起 **10 个工作日**内；变更 **5 个工作日**内；终止 **30 个工作日**前注销 |
|
||
| 第 8 条 | **真实身份认证** | 基于组织机构代码 / 身份证号 / 手机号；**未认证不得提供服务** |
|
||
| 第 9 条 | **安全评估** | 开发上线新产品 / 新应用 / 新功能前，报网信办安全评估 |
|
||
| 第 13 条 | **标注备案编号** | 对外服务的网站、应用程序**显著位置** |
|
||
| 第 6 条 | 内容处置能力 | 对禁止内容具备**即时和应急处置**能力；记录备份保存**不少于 6 个月** |
|
||
| 第 12 条 | 备案时限 | 材料齐全 ⇒ 20 个工作日内予以备案 |
|
||
| 罚则 | 未备案或填报虚假信息 | 责令限期改正；拒不改正或情节严重 ⇒ 警告 + **1 万 ~ 3 万元**罚款 |
|
||
|
||
**注意**：备案是**持续义务**（第 14 条定期查验），不是一次性动作。备案制度仍在运行中（网信办已发布至第二十四批境内区块链信息服务备案编号，最新批次 2026-07-21）。
|
||
|
||
### 6.3 删除权 vs 不可篡改（**最难调和的一处冲突**）
|
||
|
||
《个人信息保护法》第四十七条规定：处理目的已实现/不再必要、停止提供产品或服务、个人撤回同意、违法或违约处理等情形下，个人信息处理者**应当主动删除**；未删除的，**个人有权请求删除**。
|
||
|
||
这与链上"不可删除"直接冲突。**三种可选解法**：
|
||
|
||
| 解法 | 做法 | 优点 | 缺点 |
|
||
|---|---|---|---|
|
||
| **① 链上只放无关联哈希**（首选） | 链上不存个人信息，只存与身份无关的 ID 与哈希；个人信息全在链下，删除在链下完成 | 删除权可满足；链上无需改动 | 需要设计好"链上 ID ↔ 链下身份"的隔离，且隔离层本身要防关联 |
|
||
| **② Crypto-shredding** | 敏感数据加密后上链，删除 = 销毁密钥 | 链上数据"逻辑删除" | 密钥管理成为单点；历史密文仍在（若密钥又被恢复则失效） |
|
||
| **③ 不上链** | 涉及个人信息的部分一律留在关系库 | 最干净 | 需要业务上接受"这部分不享链上特性" |
|
||
|
||
**推荐组合：① + ③**。② 仅在"①不可行且必须落链"时启用，并须评估密钥托管风险。
|
||
|
||
### 6.4 数据出境
|
||
|
||
若节点/存储部署在境外，或数据需跨境传输 ⇒ 另需按数据出境相关规定评估。**此项取决于你的部署拓扑，本文不预设结论。**
|
||
|
||
---
|
||
|
||
## 7. 落地路线（S0–S4）
|
||
|
||
**核心原则：不一步到位。** 每阶段独立可验收、独立可回滚；**S1 与 S2 已完成 80% 的目标，S3/S4 只在明确需要时才做。**
|
||
|
||
### S0 · 判定与取证（不写代码）
|
||
|
||
**动作**：按 §1 逐条核对 P1–P4；按 §2 确定"谁和谁不信任"；按 §6.1 确定合规适用性。
|
||
**产出**：一页判定表（含每条的**证据**，不是结论）。
|
||
**验收**：§2 目标表命中唯一一行；P1–P4 全部有证据支撑。
|
||
**退出条件**：若 §2 命中"不需要链"且 P2 不成立 ⇒ **就此结束，不做 S1 之后的任何事**。
|
||
|
||
### S1 · 链路骨架：只追加审计日志（不引入任何区块链）
|
||
|
||
**动作**：建立 Merkle 只追加日志，覆盖关键状态变更（余额、权限、订单、配置）；提供**包含证明**与**一致性证明**的查询/校验接口；建立**自动校验器**（定时重算根哈希 + 与历史比对，不一致即告警）。
|
||
**产出**：日志模块 + 证明接口 + 校验器 + 告警通道。
|
||
**验收判据**（可测）：
|
||
- 篡改任一条历史记录 ⇒ 校验器**在下一轮必报警**（做一次真实的注入测试）；
|
||
- 提供第三方可独立验证的证明（导出原始证明 + 验证脚本）；
|
||
- 日志写入对主流程延迟影响 **< 5 ms**（实测）。
|
||
**回滚**：日志为旁路写入，停用即恢复，业务无影响。
|
||
|
||
### S2 · 敏感数据合规化
|
||
|
||
**动作**：按 §5.1 整改——密码切 Argon2id；卡号切 Tokenization；实名信息与链上 ID 解耦；全库扫描确认**任何链上/日志字段都不含明文敏感数据**。
|
||
**验收判据**：
|
||
- 对全量链上/日志条目做**正则 + 字段级**扫描，敏感模式命中 **0**；
|
||
- 删除请求权可被执行且**可证明**（走一遍真实的删除流程）；
|
||
- 密钥不在代码库、不在日志、只在密钥管理设施中。
|
||
**回滚**：逐项可回退；密码哈希迁移需保留双验证周期。
|
||
|
||
### S3 · 锚定（让第三方可验证）
|
||
|
||
**动作**：定时把日志根哈希锚定到公链交易备注字段，或提交可信时间戳服务；对外提供"如何独立验证"的说明。
|
||
**验收判据**：任取一个历史时间点，第三方仅凭公开信息**可独立验证**该时刻的根哈希与当前日志一致。
|
||
**成本**：取决于锚定频率，按次计费，年成本量级极低（单次仅数百字节）。
|
||
**回滚**：仅停止锚定，已锚定记录无需撤回。
|
||
|
||
### S4 · 按需升级
|
||
|
||
仅在 §2 明确命中"多方互信"或"公众资产"时才做：
|
||
- 多方互信 ⇒ **FISCO BCOS**（部署简单、国密原生）或 Fabric（强隔离）；
|
||
- 公众资产 ⇒ **公链 L2**（Base / Arbitrum 生态成熟；若提现等待是硬指标则选 ZK 系）。
|
||
**前置**：S1–S3 的日志与数据分层**已经是**升级的基础，不要推倒重来。
|
||
**升级判据**：出现"第三方要求共同写入"或"资产需要对外流通"的**书面需求**，且已确认 §6 合规路径。
|
||
|
||
---
|
||
|
||
## 8. 验收判据汇总（便于后续对照）
|
||
|
||
| # | 判据 | 通过标准 |
|
||
|---|---|---|
|
||
| 1 | 篡改可检测 | 注入篡改 ⇒ 校验器下轮必报警 |
|
||
| 2 | 链上无敏感数据 | 全量扫描敏感模式命中 = 0 |
|
||
| 3 | 删除权可执行 | 真实走通删除流程，且链上不留可关联信息 |
|
||
| 4 | 第三方可验证 | 外部方仅凭公开信息可完成验证 |
|
||
| 5 | 性能不退化 | 日志旁路延迟 < 5 ms |
|
||
| 6 | 合规就位（若适用） | 备案编号已下且已公示；实名、安全评估、6 个月留存齐备 |
|
||
| 7 | 有外部监督 | 存在**独立的**验证主体或自动校验，不能只有写入方自己校验 |
|
||
|
||
⚠️ 第 7 条最易被忽略：**没有任何人去验证的透明日志，等于没有**。
|
||
|
||
---
|
||
|
||
## 9. 明确不做（负面清单）
|
||
|
||
- ⛔ **不做"加密后上链"** —— 满足不了删除权，且形成"历史数据永远更弱"的斜坡（§3）。
|
||
- ⛔ **不把"用了区块链"当作安全性的证明** —— 链解决信任，不解决安全。
|
||
- ⛔ **不自研链底层** —— 自研需 20 人以上底层团队、年成本超 500 万量级；用成熟框架可省约 60% 人力。除非业务有成熟框架无法覆盖的硬需求。
|
||
- ⛔ **不为"防内部篡改"引入多节点共识** —— 检测就够了（§4.1）。
|
||
- ⛔ **不在未做 S0 判定前写代码** —— 本方案的最高价值在 §2，不在实现。
|
||
- ⛔ **不把敏感数据交给 ZK 兜底** —— ZK 不解决输入侧与存储侧问题（§5.2）。
|
||
|
||
---
|
||
|
||
## 10. 事实依据与来源
|
||
|
||
**合规**（条文原文，权威性最高）
|
||
- 《区块链信息服务管理规定》第 2/6/8/9/11/13 条 —— 网信办官网 `cac.gov.cn/2019-01/10/c_1123971164.htm`
|
||
- 备案制度运行状态 —— 国家互联网信息办公室境内区块链信息服务备案编号公告（第二十四批，2026-07-21）
|
||
- 《个人信息保护法》第四十七条（删除权）
|
||
|
||
**L2 与费用 / 性能**（⚠️ 均为**公开来源实测值**，非官方；用于量级判断）
|
||
- 常态 TPS 与费用：Base ≈ 89 TPS（峰值 159）、Arbitrum ≈ 57 TPS（峰值 2,000+）、Optimism ≈ 130 TPS —— 2026 年第三方实测汇总
|
||
- EIP-4844（Dencun，2024-03）：L2 数据成本降约 90%，L2 承载以太坊约 60–70% 交易量；blob 容量于 2026-01 再次扩容
|
||
- 终局性：Optimistic 7 天挑战期；ZK 系分钟级 ~ 数小时（各网络实测）
|
||
- ⚠️ 数字口径提示：**理论值（数万）与峰值（2,000+）不可用于容量规划**，规划应用常态值。
|
||
|
||
**联盟链选型**
|
||
- 部署难度、国密支持、共识机制、隐私机制对比 —— FISCO BCOS 与 Hyperledger Fabric 公开技术文档 + 2026 年第三方对比分析
|
||
- 自研链成本量级（20 人团队 / 年 500 万）—— 2026 年行业选型分析，⚠️ 量级参考
|
||
|
||
**透明日志**
|
||
- RFC 6962（Certificate Transparency）—— Merkle 只追加日志、包含证明、一致性证明的规范来源
|
||
|
||
**⚠️ 勘误记录（对 Google AI Mode 原回答的纠正，保留以便溯源）**
|
||
|
||
| 原回答说法 | 勘误 |
|
||
|---|---|
|
||
| L2 现状未提 EIP-4844 | 漏掉改变 L2 经济学的关键升级 |
|
||
| "实际最高可处理 2,000+ TPS" | 混淆**峰值**与**常态**；常态为两位数 |
|
||
| "ZK 的安全性与**验证速度**更具优势" | 优势是**终局性**与安全假设，不是验证速度 |
|
||
| "私有链缺少行级权限、任何节点可读全量" | 对全状态复制型成立，但 Fabric 通道 / Corda 有隔离 ⇒ 过度概括 |
|
||
| "Arbitrum Nova 承载 The Beacon" | 举例错误：The Beacon 在 Arbitrum（后支持 Ronin），已退出 Treasure 生态 |
|
||
| "Sequregator" | 拼写错误，应为 **Sequencer** |
|
||
| 密码哈希仅提 bcrypt/scrypt | 漏 **Argon2id**（当前首选） |
|
||
|
||
---
|
||
|
||
*本文档为决策依据，§0/§2 的判定需结合实际业务形态确认后再进入 S1。*
|