守株阁

与前面开放成员网络不同，Fabric 以组织身份与许可规则限定参与者。卖家提交合成订单更新请求，背书 peer 先在当前状态下模拟并签名读写集，排序服务把交易排进块，提交 peer 再核查背书策略、读版本和相同块中先前有效写入是否造成冲突。拿到排序块不意味着这笔订单已经有效写入 world state。 sequenceDiagram participant C as 订单客户端 participant E as 多组织背书 peer participant O as 排序服务 participant P as 提交 peer C->>E: 提案/模拟 E-->>C: 带签名读写集 C->>O: 组装交易 O-->>P: 有序区块 P->>P: 背书与 MVCC 版本检查 P-->>C: 有效写入或无效标记 反例一：只取得组织 A 背书却需 A+B，模拟结果相同也应因策略不符而无效。反例二：两笔交易都读取订单版本 v，第一笔有效提交写成 v+1 后第二笔的旧读版本不再匹...

证明系统的公开 statement 可以是“给定旧状态根、交易数据承诺及新状态根，存在符合约束的私有执行 witness”。witness 是满足电路/约束的输入，不等于用户一定拿到了数据，也不一定是加密了隐私的交易。区块链（33）：状态可验证、数据可取得与跨域可领取各有门槛要求恢复用户可用数据，本篇只考察约束是否真的由验证器确认。 flowchart LR W[witness: 执行路径/私有输入] --> P[真实证明器] S[statement: 公开根、批次承诺] --> P P --> Z[proof] Z --> V[按冻结验证密钥执行密码学验证] S --> V V -->|仅接受指定命题| L[链上状态更新] 电路若漏了输入金额守恒约束，完美的密码学证明也只能证明“不完整的电路被满足”；验证密钥若由可升级治理控制，还要检查改变约束的权力。SNARK/STARK 是证明技术家族而非每条 rollup 的同一成本曲线。有效性证明可以是零知识的，也可以只追求简洁验证；“zk-rollup”名称不等于公开交易数据...

一个汇总状态根可以被验证，却不包含恢复每个用户余额所需的全部原始数据。rollup 发布 calldata 或 blob 等承载方式时，要区分“证明此时数据已公布”与“未来可以从什么地方取回”，尤其是 blob 数据保留期限之外的历史重建责任。区块链（32）：Optimistic rollup 的挑战窗口给谁留时间的挑战方拿不到输入字节，就无法重算错误状态；有效性证明通过，也不自动替用户解决数据取得问题。 flowchart TD E[L2 执行与状态承诺] --> P[证明或争议路径] E --> D[数据发布: calldata/blob 等] P --> L[L1 结算合约] D --> R[历史保留/恢复服务] L --> M[跨域消息: 源域、目标、nonce、状态] M --> X[目标域核对一次性领取] R --> X 桥锁定一侧资产再在另一侧铸造或释放，必须证明源消息在认可的历史里成立，并绑定源链、目标链、桥合约、资产、金额和一次性消息标识；从另一个域复制相同字节、或重新播放旧事件，不可再次领取...

把 L2 批次提交到底层链不代表批内每条交易在提交时都已由底层逐笔重算。Optimistic rollup 在规定前提下允许提出执行结果，并给有资格的挑战者机会提交反例或交互争议；最终用户退出依赖争议规则、可用数据、合约配置和挑战窗口。区块链（31）：通道、侧链与 rollup 把哪些责任移出主链的“结算位置”不能简化为“一发批次立即无条件终局”。 sequenceDiagram participant S as 排序器/批次提出者 participant L as 底层结算合约 participant C as 挑战方 participant U as 退出用户 S->>L: 提交批次状态主张与数据关系 L-->>C: 在挑战期检查主张 C->>L: 若错误，按协议提交争议证据 L-->>U: 解决后按退出规则领取 安全需要至少有能取得所需数据、能参与且愿意发起挑战的诚实观察者；活性还需排序器或替代包含/退出路径不会永久受阻。部分系统允许用户在 L2 被审查时向 L1 强制纳入，具体权限与等待期必须...

提高吞吐量前要分清瓶颈在执行、数据公布、结算还是用户退出。区块链（30）：同一组有效交易也能产生不同经济结果的排序约束不会因为把交易移到另一层就消失。状态通道先锁定资产，参与者链下更新状态，争议时依赖底层链处理退出；侧链自己定义验证者、执行与资产桥；rollup 在链外组织执行，把所需状态承诺、证明或数据关系提交到底层结算链。三者都不能用“二层”一个词概括继承了多少安全。 flowchart TD U[用户订单] --> C[通道: 双方在线更新/可退出] U --> S[侧链: 独立成员、执行与桥] U --> R[rollup: 排序与链外执行] C --> L[底层链: 开关通道与争议] S -->|跨域桥控制| L R -->|承诺/证明/可用数据/退出| L 询问一笔订单何时完成，应分别列出链外接收、排序器确认、执行成立、数据可取得、底层结算和业务兑现；链下吞吐提高不等于每一层即时终局。若排序器停机，用户是否有强制包含通道？若验证器出错，能否挑战或验证证明？若数据被扣留，拿什么重建余额并退出？若管理员可单方面暂...

预言机给出价格后，两笔交换交易单独看都签名有效；若攻击者观察到大额兑换并在它前后各放一笔订单，用户实际执行价格可能恶化。区块链（29）：预言机能提交数据，不能把现实交付变成定理讨论输入真实性，交易排序问题则发生在输入都有效的情况下。谁能提议/选择区块内容、能看到待处理交易、能为顺序出价，决定可提取的价值与攻击面。 sequenceDiagram participant U as 用户 participant S as 搜索者/排序者 participant P as 交易池与区块生产者 U->>P: swap(数量、最低可得) P-->>S: 可见待处理交易 S->>P: 前置交易 P->>P: 用户交易（价格已变化） S->>P: 后置交易 防线不能只写“加密交易池”：协议必须处理排序权、撤回权与延迟。应用可设置最小输出、有效期、批量撮合或承诺—揭示，但最小输出只是让超过滑点的交易 revert，不能保证成交价格最好。把所有 MEV 都称为抢跑也会漏掉跨域套利、清算和用户主动寻求的合理排...

卖家给托管合约一个签名过的交付凭证，链上能验证凭证格式、签名和有效期，仍不能从这些字节推导包裹真的抵达。区块链（28）：索引器怎样在断线与重组后重算订单解决观察可靠性，本篇要说明“观察的到底是不是外部事实”。预言机将外部数据带入合约；其数据采集、发布权限、时间窗口与争议处理构成另一层信任。 flowchart LR F[链外交付或报价来源] --> C[采集与多源核对] C --> O[预言机报告: 值/时间/签名] O --> V[合约: 身份、序号、时效和范围] V --> D[托管释放或拒绝/暂停] A[作假、延迟或数据源故障] --> C “多签名报告”不是“多个独立事实来源”：若签名节点都读同一错误 API，汇聚仍不正确。超时策略要区分“没有新数据，冻结领取”与“使用最后一次旧数据”；用旧价结算时必须定义最大可接受陈旧时长、极端波动或冲突报告如何处理。对于订单交付，链外争议机制可比自动放款更诚实；不要把真实世界结果简单命名 verifiedDelivery 就当作已核验。 将“交付”拆成可判的几条谓词 一份报告可以包含订...

合约事件订阅停止五分钟，重连后只恢复 WebSocket 会漏历史；仅从上次高度回填又可能把已处理事件算两次。区块链（27）：响应丢失时不能凭交易哈希重做订单保存的是发送意图，本篇保存可撤销的链上观察。索引应把 cursor（高度+块哈希）、事件定位键和业务投影更新放进同一数据库事务；回填按块哈希验证祖先，必要时撤销断开的分支再重放新链。 flowchart LR B[按高度拉块/收订阅] --> H[核对父哈希与本地游标] H -->|连续| T[事务写事件键、订单投影和 cursor] H -->|分叉| U[按分支撤销投影] U --> B T --> R[对账: 当前合约状态和资产余额] 事件唯一性不能只用 txid：同笔交易可有多个日志，重组后同逻辑交易还可能进入另一块。至少记录链身份、区块哈希、交易/日志位置和合约地址，并规定同一订单只被现行规范历史上的合法事件推进。数据库事务提交前宕机应重新读本块；提交后回放应被唯一键去重。若订单已发货又遇撤销，只回滚数据库标签不足以追回实物，需风险窗口与人工补偿。 重组撤销的是来源...

00 篇的数据库基线把重复请求压成同一笔结算。接上区块链（26）：代理升级把信任转移给了谁的教学托管后，服务可能已经广播交易但 RPC 响应丢失；重新生成一笔、抢用同一账户 nonce，可能替换旧交易，也可能在旧交易已入块后因 nonce 过期被拒。业务订单 ID、发起意图、nonce 与多个候选交易哈希不能放进同一个“交易完成”字段。 stateDiagram-v2 [*] --> Prepared: 原子保存订单意图 Prepared --> Signed: 保存可恢复的待发送字节标识 Signed --> Submitted: 向节点发送 Submitted --> Unknown: 响应丢失 Unknown --> Submitted: 按原字节或可验证策略重试 Submitted --> Included: 核对回执/区块 Included --> Reconciled: 执行、终局、业务对账 待发送账本应先持久化可验证的订单意图、发起账户、nonce、目标合约、chain ID、数据摘要与发送状态，...

教学托管即使合约地址不变，代理也可以将调用委托给新实现。delegatecall 使用实现代码，却在代理的存储与上下文中执行；旧版 slot 装了订单 owner，新版把同一 slot 解释为 amount，就可能在不动用户地址的情况下破坏资产授权。区块链（25）：把 ERC-20 接进托管后，“收到 70”仍要核算的余额约束并不能阻止管理者换上恶意或布局错误的新代码。 flowchart LR U[用户调用固定代理地址] --> P[Proxy: 管理升级槽/委托] P --> I1[实现 v1: 订单布局] P -->|治理批准并迁移| I2[实现 v2: 必须保持旧字段语义] I1 --> S[代理持久 storage] I2 --> S G[升级管理员/治理] --> P 初始化函数若公开且可再次执行，攻击者可能夺取管理员或重置订单状态。实现合约自身的初始化锁与代理首次初始化是两个不同检查；升级前后的权限、债权之和、已关闭订单不可重开以及 EIP-712 域/nonce 迁移，都应有回归。升级权限要写清控制者、延...