明确评价对象和适用条件
区块链评价方案需要注意哪些问题，首先取决于评价对象。底层网络、智能合约和应用系统涉及不同边界，方案应说明检查哪些组件、依赖哪些外部服务，以及结论适用于什么运行条件。
NIST IR 8202将区块链描述为分布式实现、具有篡改可察觉性和抗篡改能力的数字账本，并指出交易记录在网络正常运行的条件下难以更改。评价因此需要说明这些能力成立的条件，避免将其表述为无条件保证。
区分记录可信与输入真实
抗篡改主要涉及记录写入后的完整性，不能直接证明输入内容符合现实。评价方案应分别审查记录如何确认、数据由谁提交，以及错误输入如何处理。对于接收外部数据的应用，还应明确数据提供方的责任与信任边界。
常见问题是用“已经上链”替代真实性判断。更清楚的评价方式是分别描述链上可验证的信息和仍依赖外部证明的信息，避免把两者合并成笼统的可信评分。
检查合约权限与管理责任
以太坊智能合约安全文档强调访问控制、操作条件检查、多种测试方法和独立审查，也明确审计无法发现全部漏洞。这些原则适合用于评价包含智能合约的系统，不宜直接充当所有区块链平台的完整评价标准。
权限评价应落到具体操作：谁能修改参数、暂停功能或升级合约，权限如何授予和撤销。采用角色分工或多签时，还应检查控制者是否实际独立；账户数量增加本身不足以证明管理风险已经分散。
让测试与审计结论对应证据
方案应要求关键功能具有可检查的测试证据，覆盖正常输入、异常输入和权限越界等情况。单元测试、静态分析、模糊测试可以提供不同角度的证据，但不能仅凭工具名称或测试通过就认定安全。
审计报告应对应明确的代码版本和检查范围，并记录问题是否修复及复核。形式化验证的结论也受所定义的属性、模型和假设约束，不能扩展为整个应用不存在任何缺陷。
避免总分掩盖关键缺陷
评价结果宜同时呈现检查项、证据、适用条件和未解决问题。对关键权限缺陷等问题，应单独说明其影响，避免被其他指标的高分抵消。
代码、权限或依赖发生变化后，原结论可能不再适用。方案应预先定义重新评价的触发条件，使评价能够随系统变化更新，而不是形成一次性、永久有效的安全标签。