应用边界由分析对象和证据决定
区块链安全分析架构可以理解为组织分析对象、检查方法和验证证据的一套方式。讨论它的应用边界，首先要明确检查的是区块与交易、合约逻辑，还是管理权限。不同层次的检查只能支持相应范围的结论，不能把某一层验证通过，直接解释为整个应用安全。
共识层：验证账本规则
Bitcoin开发者指南说明，全节点独立验证区块，交易输入受未花费输出等规则约束；链分叉时，节点在有效链中依据累计工作量选择链。区块高度可能重复，区块哈希更适合作为标识。
因此，账本分析适用于检查交易是否符合协议规则、记录属于哪个区块，以及分叉对记录状态的影响。它无法仅凭交易有效性判断一笔操作是否符合业务意图。例如，符合协议规则的支出，本身不能证明账户管理过程没有问题。
合约层：检查逻辑和权限
以太坊智能合约安全文档介绍了访问控制、条件检查、测试、静态与动态分析，以及独立审计等方法，同时强调审计不能发现所有缺陷。这些方法适合交叉使用，帮助识别代码和设计中的问题。
合约分析需要明确代码版本、权限配置和预期行为。权限检查可以判断某个地址是否有权调用敏感函数，却不能单凭这项检查证明该地址的密钥始终安全。多签和角色划分可以降低部分管理风险，实际效果仍取决于签名门槛、角色权限及其控制关系。
验证方法：结论受覆盖范围约束
单元测试主要覆盖已编写的案例；模糊测试通过多样输入寻找异常，但未发现异常不能等同于不存在漏洞。形式化验证的结论也限于所建立的模型、假设和明确描述的安全性质。若业务要求没有写入规范，证明通过仍可能遗漏业务层面的错误。
适用条件应随结论一起记录，包括分析版本、检查目标和未覆盖部分。代码或权限配置变化后，需要重新判断原有结论是否仍然适用。
常见问题：不同层次能否互相替代
合约审计通过，是否意味着底层链也安全？不能，合约逻辑审查与共识机制分析的对象不同。比特币的工作量证明和未花费输出规则，也不能直接充当以太坊合约执行的验证标准。
发现问题后能否直接修复或撤销交易？分析能力不等于处置权限。修复取决于系统是否预设升级、暂停等机制及相应授权；安全报告本身不会改变已部署代码，也不会自动撤销链上记录。