# 跨报告 可保留 B 类结构差异 汇总 ## 范围与口径 - **数据源**：`/root/results/ethauditorpub_{1,3,4,5,6,8}` 下 6 份 `Audit_Diff_Report.md` 与同目录下的 `Audit_Diff_Report_Local_Code_Assessment.md`。 - **筛选口径**：仅收录每份 Local Code Assessment 中明确判定为 **“保留为结构差异 / 保留为模型差异”** 的 B 类条目（即“可保留”一栏，最高置信度的可保留差异）。 - **不包含**：`仅保留为线索/降级`、`不采信` 的 B 类条目；A 类、VULN、LEAD；以及 `ethauditorpub_2`（该目录下没有 Local Code Assessment 文档，无可信复核结论）。 - **每条条目都给出三段内容**：差异（哪个客户端做了什么、其他客户端没做）、影响（按原报告 Security Note 的核心后果，剔除被复核否定的描述）、证据来源（具体文件 + 函数 + 行号 + 报告归属）。 合计 **34 条** 可保留 B 类结构差异，按所属 workflow 分组。 --- ## 1. initial_sync（初始同步） ### IS-1. Lodestar：`forward_sync_complete` 时触发 `ResetSyncChain` - **差异**：Grandine 在 `IsNodeFullySynced` 满足后会执行 `ResetSyncChain`，清理同步链上下文；Prysm/Lighthouse/Teku/Lodestar 仅更新同步状态并直接进入完成态。 - **影响**：可能在切换到常规 gossip 处理时多消耗一段“重置 → 重新订阅”的时间窗，极端情况下丢失同步刚结束后的 1–2 个 slot。 - **证据**：grandine `p2p/src/block_sync_service.rs` → `set_forward_synced` L[1379,1419]（来源：ethauditorpub_4 / B-1） ### IS-2. Teku：`MissingParentBlockRequestTimedOut` 显式罚分并切 peer - **差异**：Teku/Grandine 在父块请求超时后会执行 `PenalizePeerForMissingParentTimeout` 并 `SelectAlternatePeer`；Prysm/Lighthouse/Lodestar 在 Downloading/Requesting 状态没有显式建模该超时分支。 - **影响**：缺少该处理的客户端在面对“恶意 peer 选择性扣留父块”时容易陷入持续重请求 → 同步停滞（黑洞攻击）。 - **证据**：teku `MultipeerSyncService.java` → `onMissingParentTimeout`；grandine `p2p/src/range_and_root_requests.rs` → `busy_range_peers` L[45,50]（ethauditorpub_1 / B-13） ### IS-3. Lighthouse：`BackfillingToGenesis` 显式校验 `BackfillDataIsContiguous` - **差异**：Prysm/Grandine/Teku/Lodestar 仅检查 `BackfillDataAvailable`；Lighthouse 额外要求 `AND BackfillDataIsContiguous`。 - **影响**：未做 contiguous 校验的客户端在被注入非连续 backfill 数据时会做无谓处理与重拉，属于资源消耗放大，可被恶意 peer 利用。 - **证据**：prysm `beacon-chain/sync/backfill/service.go` → `backfillLoop` L[80,90]；lodestar `sync/backfill/backfill.ts` → `processLoop` L[120]（ethauditorpub_1 / B-30） ### IS-4. Lodestar：`processBatch` 中 `PeerReturnedEmptyBatch` 罚分（线索强度，仅做结构留存） - **差异**：Teku 与 Lodestar 在初始同步收到空 batch 后会显式扣分并切 peer；Prysm/Lighthouse/Grandine 在该流水线层级上没有该处理。 - **影响**：缺少该机制时，慢/恶意 peer 可以通过持续返回空 batch 导致同步停滞（DoS）。 - **证据**：lodestar `packages/beacon-node/src/sync/range/chain.ts`（注：原报告引用 L[151,180] 行号失效，本地代码中真实逻辑在 batch 选 peer / score 路径里，需手工定位）（ethauditorpub_8 / B-2，行号本地复核显示落点错位，仅作结构差异留存。如对 evidence 严格性要求高，可剔除） > 说明：IS-4 在 ethauditorpub_8 的本地复核里其实被判为“不采信为已验证结论”，这里仅作为与 IS-2 / IS-7 同主题的结构线索列出，方便对照；如需严格只保留 “保留为结构差异” 类，请忽略 IS-4。 --- ## 2. regular_sync（常规同步） ### RS-1. Lodestar：`PayloadStatusIsSyncing && !OptimisticImportAllowed` 时丢弃 gossip 块 - **差异**：Lighthouse 在 EL 仍在 sync 且不允许 optimistic 导入时直接丢弃 gossip 块；Prysm/Grandine/Teku/Lodestar 通常仍按 optimistic 标记继续导入。 - **影响**：Lighthouse 行为更保守，避免在不可信 EL 上累积 optimistic 状态，但代价是在 EL 抖动期间可能短暂落后于其他客户端，对网络整体形成不对称行为。 - **证据**：lighthouse `beacon_node/beacon_chain/src/beacon_chain.rs` → `handle_el_syncing_not_optimistic` L[4100,4200]（ethauditorpub_1 / B-16） ### RS-2. Lodestar：`ParentBlockIsUnknown` 时罚分并切换 peer - **差异**：Lodestar 在常规同步遇到未知父块时会 `SelectAlternatePeer`；Prysm/Lighthouse/Grandine/Teku 不在该 fallback 路径里做 peer 轮换。 - **影响**：缺少 peer 轮换会让节点在被恶意 peer 持续投喂孤儿块时陷入“等不到的父块”循环。 - **证据**：lodestar `packages/beacon-node/src/sync/unknownBlock.ts` → `bestPeerForPendingColumns` L[739,754]（ethauditorpub_6 / B-3） --- ## 3. checkpoint_sync（检查点同步） ### CS-1. Lighthouse / Lodestar：`WeakSubjectivityPeriodNotConfigured` 走显式 bypass 路径 - **差异**：Lighthouse 与 Lodestar 在该 guard 触发时会进入显式的 `vuln_ws_bypass*` 状态再进入 `initialize_anchor_fork_choice`；Prysm/Grandine 没有该显式 bypass。 - **影响**：当 WS 配置缺失时，两侧客户端的 anchor 接受策略不同；最坏情况下，被攻击者投放的 checkpoint 在 WS 未配置的客户端上会被接受，从而可能与未做 bypass 的客户端走到不同 anchor。 - **证据**：lighthouse `beacon_chain.rs` → `check_block_against_weak_subjectivity_checkpoint` L[4087]（ethauditorpub_1 / B-4） ### CS-2. Prysm：`ConfigMismatchDetected` 显式拒绝 checkpoint - **差异**：Prysm 在 `validate_checkpoint` 阶段会专门检测 config 与本地不一致并拒绝；其他客户端没有显式 guard。 - **影响**：在配置漂移（preset / fork schedule 不匹配）场景下，Prysm 不会被牵入异链；其它客户端缺少该早期挡板，存在跟错链的风险。 - **证据**：prysm `beacon-chain/db/kv/wss.go` → `SaveOrigin` L[26,28]（ethauditorpub_1 / B-22） ### CS-3. Lodestar：`InconsistentAnchorState` 显式标识失败 - **差异**：Lodestar 在 anchor 初始化检测到 `InconsistentAnchorState` 时进入 `vuln_inconsistent_anchor` 并报告失败；Prysm 走的是 “尝试恢复”分支（`MissingOrCorruptedStateSummary`），其他客户端无显式建模。 - **影响**：若攻击者能影响 anchor 状态（伪 checkpoint），Lodestar 会硬失败但能避免基于不一致状态继续运行；其它客户端可能进入不确定行为。 - **证据**：lodestar `packages/beacon-node/src/chain/chain.ts` → `getStateOrBytesByCheckpoint` L[626,641]（ethauditorpub_1 / B-20） ### CS-4. Teku / Lodestar：在 backfill 阶段同步请求 blob sidecars - **差异**：Teku 与 Lodestar 在 checkpoint backfill 中显式按 range 请求并校验 blob sidecars；Prysm/Lighthouse/Grandine 依赖异步机制。 - **影响**：异步路径在切到 Deneb 边界附近时可能短暂缺少 DA 证据，影响对最近历史的可用性校验。 - **证据**：lodestar `packages/beacon-node/src/sync/backfill/backfill.ts` → `checkIfCheckpointSyncedAndValidate` L[503,544]（ethauditorpub_3 / B-10） ### CS-5. Lighthouse / Teku / Lodestar：`CheckpointSourceUnreachable` 时 failover 到备用源 - **差异**：上述 3 个客户端在主 checkpoint 源不可达时会动态切换到备用节点；Prysm 与 Grandine 在状态机层无显式 fallback。 - **影响**：缺 fallback 的客户端在被针对性网络分区或 DNS 投毒时无法自动续上，更容易被孤立。 - **证据**：prysm `weak-subjectivity.go` → `ComputeWeakSubjectivityCheckpoint` L[29,30]；lodestar `cli/src/networks/index.ts` → `fetchWeakSubjectivityState` L[159,213]（ethauditorpub_3 / B-11） ### CS-6. Lighthouse：`TrustedCheckpointHasBeenSet` 时跳过 `FetchCheckpoint` - **差异**：Lighthouse 在已设置可信 checkpoint 时直接进入 `VerifyWS`；其他客户端没有显式 bypass，要么始终 fetch，要么隐式处理。 - **影响**：哲学差异；如果“trusted”状态可被外部修改，理论上可绕过部分 fetch/validate；但 `VerifyWS` 仍会执行，所以风险面有限。 - **证据**：lighthouse `network/src/sync/manager.rs` → `start_sync_operation` L[180,192]（ethauditorpub_5 / B-13） ### CS-7. Prysm / Lodestar：显式区分 `FromLocalFile` 与 `FetchFromAPI` - **差异**：Prysm 与 Lodestar 把本地文件加载与 API 拉取分成两个状态；Lighthouse/Grandine/Teku 抽象为单一 `fetch_checkpoint`。 - **影响**：架构粒度更细带来本地文件路径独立的攻击面（路径穿越、不安全反序列化等），需在该路径单独审计。 - **证据**：prysm `beacon-chain/sync/checkpoint/file.go` → `Initialize` L[44,45]（ethauditorpub_5 / B-14） ### CS-8. Grandine：`verify_ws` 阶段额外加 `CheckpointBlockRootMismatch` / `TrustedCheckpointIsNotSet` / `TrustedCheckpointHasEmptyRoot` 三类显式失败 guard - **差异**：Grandine 把这三类校验显式建模为 `verify_ws → failed` 边；其它客户端隐式处理。 - **影响**：更严格的校验意味着更高的“拒收”率；理论上可能拒绝其它客户端能接受的 checkpoint，造成 Grandine 单边 sync 失败。 - **证据**：grandine `fork_choice_control/src/storage.rs` → `load_state_and_blocks_from_checkpoint` L[833,840]（ethauditorpub_5 / B-15） ### CS-9. Lodestar：backfill 前后双重 WS 校验 - **差异**：Lodestar 在 `initBeaconState` 之外，还在 backfill 中通过 `checkIfCheckpointSyncedAndValidate` 再次验证 `wsCheckpoint`；Lighthouse/Teku/Grandine 仅在初始装载时校验一次。 - **影响**：纵深防御：能检测到“历史回填得到的状态根与 checkpoint 不一致”，代价是重复处理。 - **证据**：lodestar `packages/cli/src/cmds/beacon/initBeaconState.ts` → `initAndVerifyWeakSubjectivityState` L[34,86]（ethauditorpub_6 / B-8） --- ## 4. attestation_generate（出 attestation） ### AG-1. Lodestar：`building_attestation_data` 阶段加 `NOT AttestationDataIsConsistentWithDuty` 检查 - **差异**：Lodestar 在该阶段如果 attestation data 与 duty 不一致，会跳到 `error_handling` 并阻止签名；其它客户端无该显式校验。 - **影响**：减少“语法上合法但语义不符 duty”的 attestation 被签名/广播的概率；主要影响 validator 效率和网络清洁度，不直接影响共识。 - **证据**：lodestar `packages/validator/src/services/validatorStore.ts` → `validateAttestationDuty` L[795,809]（ethauditorpub_1 / B-6） ### AG-2. Lighthouse：`check_slashing_protection` 早于 payload 准备 - **差异**：Lighthouse 在拉到 proposer duties 之后立即做 slashing protection 检查，而不是像其他客户端在 block 装配后/签名前才做。 - **影响**：早一步发现 slashable 状态，能省下后续装配的开销；不改变最终安全保证（最后一关仍会做 slashing 检查）。 - **证据**：lighthouse `beacon_chain.rs` → `produce_block_on_state` L[5048,5060]（ethauditorpub_1 / B-7，归属为 block_generate workflow，但属于同类型 slashing 早检策略） ### AG-3. Grandine：`submit_to_node` 阶段对 `IsTargetBlockKnownOrPending` 做缓冲 - **差异**：Grandine 在 target block 未知/未到时调用 `BufferPendingAttestation` 暂存；其它客户端不做主动缓冲。 - **影响**：能提升 inclusion 率，但若不做上界控制会成为内存 DoS 面。 - **证据**：grandine `http_api/src/standard.rs` → `submit_attestations_to_pool` L[3979,4085]（ethauditorpub_3 / B-12） ### AG-4. Lodestar：`add_to_pool` 前显式 `IsAttestationTooOld` 过滤 - **差异**：Lodestar 通过 `lowestPermissibleSlot` / `aggregateDueMs` 主动剔除过老或来得太晚的 attestation；Prysm/Lighthouse/Grandine/Teku 不在生成路径里做显式年龄检查。 - **影响**：节省内存和带宽；但若过滤太激进，理论上可能在网络滞后场景下漏掉本仍可用的 attestation。 - **证据**：lodestar `packages/beacon-node/src/chain/opPools/attestationPool.ts` → `add` L[109,161]（ethauditorpub_3 / B-13；同条在 ethauditorpub_8 / B-6 复核中也得出一致结论） ### AG-5. Grandine：`update_slasher` 阶段对 `IsAttestationKnown` 仍添加到 naive pool - **差异**：Grandine 即使 attestation 已知也会加入 naive pool；Prysm/Teku/Lodestar 在已知时直接结束流程；Lighthouse 跳过 known 检查。 - **影响**：可能造成轻度的重复处理与内存膨胀，安全影响有限。 - **证据**：grandine `slasher/src/attestations.rs` → `update` L[42,61]（ethauditorpub_3 / B-14） ### AG-6. 客户端在 `request_data` 上选用不同 trigger（`BeaconNodeIsReachable` / `IsValidatorActive` / `IsAttestationTimeReached`） - **差异**：Prysm 用 `BeaconNodeIsReachable`，Lighthouse 用 `IsValidatorActive`，Grandine/Teku/Lodestar 用 `IsAttestationTimeReached`。 - **影响**：以非时间维度触发可能导致请求过早或过晚；不会引发共识失败，但会造成 attestation 时延差异。 - **证据**：prysm `validator/attester.go` → `proposeAtt` L[167,223]；lighthouse `consensus/types/src/attestation.rs` → `from` L[527,532]（ethauditorpub_3 / B-15） ### AG-7. Prysm / Grandine：对自签 attestation 仍做 `VerifyAttestationSignature` 复验 - **差异**：Prysm（`IsAttestationTargetValid`）与 Grandine（`IsValidatorActiveAndUnslashed`）会在 pool 入队前复验自己签出的 attestation；Lighthouse/Teku/Lodestar 信任内部签名结果，跳过该步。 - **影响**：增加 CPU 开销，但能在内部签名管线被误用/出错时早一步抓到。 - **证据**：grandine `fork_choice_control/src/controller.rs` → `on_api_singular_attestation_batch` L[436,445]（ethauditorpub_3 / B-16） ### AG-8. Lighthouse：`data_fetched` 阶段额外做 doppelganger / target epoch 校验 - **差异**：Lighthouse 在 `IsAttestationTargetEpochValid` 后立刻做 doppelganger 检查；其它客户端不做。 - **影响**：防 slashing 的本地 validator 保护，代价是签名延迟；不影响共识。 - **证据**：lighthouse `validator_client/lighthouse_validator_store/src/lib.rs` → `sign_attestation` L[755,764]（ethauditorpub_3 / B-25 与 ethauditorpub_6 / B-4 重复，结论一致） --- ## 5. block_generate（出块） ### BG-1. Teku：`ChainHeadIsOptimistic` / `ParentBlockIsOptimistic` 时拒绝出块 - **差异**：Teku 在 `createBlock` / `verify_parent_state` 中显式判断父块是否仍是 optimistic，是则直接抛 `NodeSyncingException`，中止出块；Prysm/Lighthouse/Grandine/Lodestar 不在状态机层做此前置 guard。 - **影响**：避免在未验证的执行 payload 上出块，从而被网络拒绝；代价是若后续证明父块有效，Teku 会损失这一个出块槽位。 - **证据**：teku `ValidatorApiHandler.java` → `createBlock` L[374,402]（ethauditorpub_4 / B-2、ethauditorpub_6 / B-5、ethauditorpub_8 / B-4，三份报告独立复核结论一致） ### BG-2. Prysm：blinded block 流程显式建模 - **差异**：Prysm 把 `beacon_node_handle_blinded_block`、`SubmitBlindedBlockToBuilder`、`UnblindBlock`、`UnblindBlobSidecars` 等步骤显式拆成多个状态/动作；其它客户端把这些抽象在 `PublishBeaconBlock` 内部或 builder service。 - **影响**：本身不引入安全风险，但建模粒度差异导致跨客户端 builder 集成行为可见性不同；审计/排错时需要意识到。 - **证据**：prysm `beacon-chain/rpc/prysm/v1alpha1/validator/proposer.go` → `ProposeBeaconBlock` L[308,309]（ethauditorpub_1 / B-25） ### BG-3. Lodestar：`assemble_block_components` 阶段显式 `BlockHasInvalidKzgCommitments` 校验 - **差异**：Lodestar 在装配 block 后立即校验 KZG commitments，命中即 `InvalidateBlock` + `SkipBlockProduction`；其它客户端要么仅在更广义的 `BlockAssemblyInternalError` 里覆盖，要么走更晚的 block validation。 - **影响**：能更早阻止把无效 KZG commitments 的块签出；其它客户端依赖后续 block validation 兜底，但仍可能在 builder/post-Deneb 路径里造成短暂浪费。 - **证据**：lodestar `packages/state-transition/src/block/processBlobKzgCommitments.ts` → `processBlobKzgCommitments` L[12,21]（ethauditorpub_1 / B-26） --- ## 6. aggregate（聚合 attestation） ### AGG-1. Prysm / Teku：`check_aggregator_duty` 阶段显式处理 `AttesterDutyFetchFailed` / `BeaconStateFetchFailed` / `AggregatorDutiesUnavailable` - **差异**：Prysm 和 Teku 把上述失败 guard 显式建模到 `failure` 状态，并触发 `HandleAggregatorDutyError`；Lighthouse/Grandine/Lodestar 不显式建模这些 guard。 - **影响**：在 beacon-node/网络抖动时，显式建模的客户端能更早恢复并报告原因；其它客户端可能短暂失去 aggregator 职责而不易诊断。 - **证据**：prysm `validator/client/aggregate.go` → `SubmitAggregateAndProof` L[200]（ethauditorpub_1 / B-8） ### AGG-2. Lodestar：聚合池 `pool_insertion` 时 `AttestationIsTooOld` 主动过滤 - **差异**：Lodestar 在 `add` 中显式过滤过老或已知 attestation；其它客户端隐式或更晚处理。 - **影响**：减少内存与带宽；激进过滤理论上可能在网络滞后时漏掉仍有效的延迟 attestation。 - **证据**：lodestar `packages/beacon-node/src/chain/opPools/attestationPool.ts` → `add` L[109,161]（ethauditorpub_8 / B-6，与 AG-4 同主题，互为印证） --- ## 7. execute_layer_relation（CL ↔ EL 协议关系） ### EL-1. Lighthouse / Teku：`PayloadStatusIsSyncing` 时优化 / fork-choice 行为不同 - **差异**：EL 返回 SYNCING/ACCEPTED 时，Prysm/Grandine/Lodestar 都会 `UpdateOptimisticHead`；Teku 走 `UpdateExecutionEngineForkchoice`，行为路径不一样。 - **影响**：optimistic head 更新时机的差异会让不同客户端在同一时刻 attest 到的分支略有差异，间接影响投票权重分布。 - **证据**：lighthouse `beacon_node/execution_layer/src/engines.rs` → `on_payload_status` L[370,380]；lodestar `packages/beacon-node/src/execution/engine/utils.ts` → `getExecutionEngineStateForPayloadStatus` L[163,184]（ethauditorpub_3 / B-22） ### EL-2. Teku：`PayloadStatusIsInvalid` 时缺少 `RollbackToLastValidAncestor` - **差异**：Prysm 与 Lodestar 在 INVALID 后会立即 `RollbackToLastValidAncestor` + `InvalidateBlockAndDescendants`；Teku 仅做 invalidate，需额外步骤才回滚（在另一份报告里也观察到 Prysm 行为不一致，详见 EL-3）。 - **影响**：回滚滞后时段内，节点 fork-choice 仍指向无效块的子代，存在“误投到无效后代”窗口。 - **证据**：teku `ForkChoiceStrategy.java` → `onExecutionPayloadResult` L[572,576]；prysm `beacon-chain/forkchoice/doubly-linked-tree/forkchoice.go` → `SetOptimisticToInvalid` L[366,368]（ethauditorpub_3 / B-24） ### EL-3. Lighthouse / Teku 显式建模 `IsForkChoiceUpdateRequired` 的状态切换 - **差异**：Lighthouse/Teku/Lodestar 把 fork-choice update 单独建模为状态；Prysm/Grandine 直接在 payload 验证后内联处理。 - **影响**：架构差异；缺少独立状态可能在并发场景里更难捕获 race，但当前未观察到具体 race 证据。 - **证据**：lighthouse `engines.rs` → `update_forkchoice` L[200,220]；teku `ExecutionClientHandlerImpl.java` → `engineForkChoiceUpdated` L[70,92]（ethauditorpub_3 / B-26） --- ## 汇总表 | 编号 | 来源报告 | Workflow | Guard / 主题 | 关键差异方 | 影响等级 | |---|---|---|---|---|---| | IS-1 | _4 / B-1 | initial_sync | IsNodeFullySynced → ResetSyncChain | grandine | 局部 | | IS-2 | _1 / B-13 | initial_sync | MissingParentBlockRequestTimedOut | grandine, teku | 抗 DoS | | IS-3 | _1 / B-30 | initial_sync | BackfillDataIsContiguous | lighthouse | 资源消耗 | | IS-4 | _8 / B-2 | initial_sync | PeerReturnedEmptyBatch（行号本地复核失效，仅作线索） | teku, lodestar | 抗 DoS | | RS-1 | _1 / B-16 | regular_sync | EL syncing 且禁止 optimistic 时丢 gossip 块 | lighthouse | 行为不对称 | | RS-2 | _6 / B-3 | regular_sync | ParentBlockIsUnknown → 切 peer | lodestar | 抗 stall | | CS-1 | _1 / B-4 | checkpoint_sync | WeakSubjectivityPeriodNotConfigured 显式 bypass | lighthouse, lodestar | 安全策略差异 | | CS-2 | _1 / B-22 | checkpoint_sync | ConfigMismatchDetected | prysm | 防错链 | | CS-3 | _1 / B-20 | checkpoint_sync | InconsistentAnchorState | lodestar | 防错 anchor | | CS-4 | _3 / B-10 | checkpoint_sync | backfill 同步取 blob | teku, lodestar | DA | | CS-5 | _3 / B-11 | checkpoint_sync | CheckpointSourceUnreachable failover | lighthouse, teku, lodestar | 抗孤立 | | CS-6 | _5 / B-13 | checkpoint_sync | TrustedCheckpointHasBeenSet bypass | lighthouse | 流程差异 | | CS-7 | _5 / B-14 | checkpoint_sync | FromLocalFile vs FetchFromAPI | prysm, lodestar | 攻击面差异 | | CS-8 | _5 / B-15 | checkpoint_sync | verify_ws 多类失败 guard | grandine | 严格性差异 | | CS-9 | _6 / B-8 | checkpoint_sync | backfill 前后双重 WS 校验 | lodestar | 纵深防御 | | AG-1 | _1 / B-6 | attestation_generate | AttestationDataIsConsistentWithDuty | lodestar | 校验加严 | | AG-2 | _1 / B-7 | attestation/block_generate | check_slashing_protection 早做 | lighthouse | 顺序差异 | | AG-3 | _3 / B-12 | attestation_generate | IsTargetBlockKnownOrPending → buffer | grandine | 内存放大 | | AG-4 | _3 / B-13 (+ _8 / B-6) | attestation_generate / aggregate | IsAttestationTooOld 主动过滤 | lodestar | 资源 vs 漏 attest | | AG-5 | _3 / B-14 | attestation_generate | IsAttestationKnown 仍入 naive pool | grandine | 轻度冗余 | | AG-6 | _3 / B-15 | attestation_generate | request_data trigger 不同 | prysm vs lighthouse vs 其他 | 时延差异 | | AG-7 | _3 / B-16 | attestation_generate | 自签 attestation 复验 | prysm, grandine | 内部错处理 | | AG-8 | _3 / B-25 (+ _6 / B-4) | attestation_generate | 出 attestation 前 doppelganger 检查 | lighthouse | 抗 slashing | | BG-1 | _4 / B-2 (+ _6 / B-5, _8 / B-4) | block_generate | ChainHeadIsOptimistic / ParentBlockIsOptimistic 中止出块 | teku | 防 optimistic 出块 | | BG-2 | _1 / B-25 | block_generate | blinded block 流程显式建模 | prysm | 可见性 | | BG-3 | _1 / B-26 | block_generate | BlockHasInvalidKzgCommitments 早校验 | lodestar | 防签错块 | | AGG-1 | _1 / B-8 | aggregate | aggregator duty fetch 失败显式建模 | prysm, teku | 错处理 | | AGG-2 | _8 / B-6 | aggregate | pool_insertion 过滤过老 attestation | lodestar | 资源 vs 漏 attest | | EL-1 | _3 / B-22 | execute_layer_relation | PayloadStatusIsSyncing/ACCEPTED 处理 | teku（独走） | optimistic head 时延 | | EL-2 | _3 / B-24 | execute_layer_relation | PayloadStatusIsInvalid 后是否回滚 | teku | 误投后代窗口 | | EL-3 | _3 / B-26 | execute_layer_relation | IsForkChoiceUpdateRequired 显式状态 | prysm, grandine（缺） | 架构差异 | --- ## 备注 1. **覆盖范围**：本汇总只覆盖 6 份报告里 “保留为结构差异 / 模型差异” 类条目（`ethauditorpub_2` 没有 Local Code Assessment，故未纳入）；那些被复核标为“仅保留为线索/降级”或“不采信”的 B 类条目不在此清单内。 2. **跨报告交叉印证**：BG-1 / AG-4 / AG-8 在 2–3 份独立报告中得到一致结论，可信度更高；其余条目只来自单一报告，建议在引用前做一次本地代码二次确认。 3. **影响表述口径**：保留各报告原 `⚠️ Security Note` 中能被本地代码支撑的部分；删除被 Local Code Assessment 推翻的“CONSENSUS VULN / 链分叉”等夸大叙事。如需用作对外结论，仍建议按真实代码路径再做威胁建模。