适用范围：先区分技术层次
围绕“尹鹏飞区块链技术需要注意哪些问题”这一问题，可以讨论区块链的通用安全要求，但现有证据不足以确认尹鹏飞的身份、技术主张或项目情况。以下内容分别以比特币账本机制和以太坊智能合约安全为背景，两者的具体规则不能直接混用。
理解风险时，应先问清楚：需要保障的是交易记录的一致性，还是应用执行规则的正确性？节点认可一笔交易符合协议规则，并不意味着合约设计满足了全部业务要求。
共识与确认：记录为何难以修改
比特币开发者指南介绍，节点独立验证区块，区块通过前一区块头的哈希相连。工作量证明增加了改写历史的成本；出现有效分支时，节点依据累计工作量选择链。区块高度可能重复，不能充当全局唯一标识。
这些机制说明，“难以篡改”有具体的协议条件，不能理解为任何时刻都不存在分支。应用处理交易状态时，需要区分已传播、已进入区块以及后续确认等情况，也要考虑链发生重组后记录状态变化的问题。上述讨论针对比特币机制，不代表所有区块链采用同样的确认方式。
合约安全：权限与校验是否完整
以太坊智能合约安全文档强调访问控制、条件校验、多种测试及独立审查。敏感操作需要明确授权；多签可要求多方同意。审计能够补充检查，但无法保证发现全部缺陷，已部署代码的修复也受到合约设计限制。
落实这些原则时，应把业务要求转成可检查的问题：谁能修改关键参数？谁能暂停功能？异常输入是否会被拒绝？角色分工可以限制各账户的职责，但若某个角色仍能独自执行高风险操作，其权限风险依然存在。
公开可调用的函数也可以设置权限检查；函数可见性与业务授权是不同概念。不能仅凭函数名称、界面限制或前端隐藏按钮，就判断敏感操作已受到保护。
常见问题：测试和审计能证明什么
正常流程测试通过，说明已覆盖的场景符合预期，未覆盖的边界条件仍需检查。例如，应验证无权限调用是否失败，以及异常操作后关键状态是否保持一致。
形式化验证的结论受规范、模型和假设范围约束，不能扩大成整个系统绝对安全的证明。同样，评估一份审计结论时，需要明确它对应哪个代码版本、检查了哪些范围，以及后续修改是否经过复核。底层共识可靠与应用代码可靠，应分别建立证据。