安全二字需要具体化
Ethereum形式化验证资料将验证描述为检查系统是否满足预先定义的规格。这意味着阅读报告时，首先要寻找被证明的性质，而不是停留在采用了数学方法的宣传语。可以把性质改写成普通语言，例如某种状态变化必须满足哪些条件，并检查报告是否真的讨论了它。若目标只涉及一个模块，就不能把结论扩展为整个产品没有风险；形式严谨和范围完整仍是两个不同问题。
假设不是可以忽略的脚注
模型通常需要对外部输入、依赖组件或执行环境作出约定。本文建议把这些约定放进阅读笔记的主栏，逐项询问它们在实际部署中如何得到满足。还要核对报告所指的代码版本与当前实现是否一致，后续修改是否改变已证明性质。看不懂的符号可以先保留原始定位，请有能力的人解释，不必用肯定语气掩盖理解空白。没有核到的部分，应明确标记为未确认。
让不同证据互相补充
形式化证明、测试结果、代码审查和运行观察各自回答不同问题。整理时可以用证据说明支持什么、没有支持什么，而不是简单排列几个工具名称作为安全分数。若发现规格本身没有覆盖某种业务期待，应将其作为新的问题，而不是认为已有证明必然失效。准确理解报告，有助于承认技术工作的价值，也防止把有限结论包装成绝对承诺。本文不对任何具体合约出具安全意见。