先明确技术能力与适用范围
区块链等数字化技术需要注意哪些问题，首先取决于系统承担什么任务。自动执行业务规则的智能合约，与负责查询和验证区块链信息的客户端，面对的风险并不相同。前者要关注谁能改变状态、代码是否符合预期；后者要关注信息如何取得、验证覆盖哪些内容。
以下讨论主要适用于智能合约及区块链客户端。评估具体系统时，需要把安全目标落实为可检查的要求，例如敏感操作是否经过授权、异常输入能否被拒绝、信息来源失效后能否继续核验。
权限设计需要考虑密钥失陷
以太坊开发文档的智能合约安全内容强调访问控制、运行条件检查、测试和独立审查。公开可调用的函数若涉及敏感操作，需要额外校验权限；角色分工和多签可以降低单一管理账户带来的风险。
常见问题是：设置多个管理员就足够安全吗？关键还在于各账户能做什么，以及关键操作需要谁共同批准。角色分工用于限制权限范围，多签用于要求多个签名共同授权，两者解决的问题不同，均不能替代对权限配置的检查。
测试与审计要有明确边界
智能合约部署后的修复可能受限，因此上线前需要检查正常流程、边界条件和异常路径。单元测试、静态分析、模糊测试与独立审计各有作用，不能把其中任何一种视为安全保证。
审查结果需要对应明确的代码版本和检查范围。形式化验证同样依赖所定义的性质与模型：证明某项性质成立，并不意味着所有业务风险都已排除。对于允许升级的设计，升级权限本身也应纳入检查。
轻量验证有资源优势，也有信任边界
比特币开发指南区分全节点与简化支付验证客户端。全节点按共识规则验证区块和交易；简化支付验证主要依靠区块头及包含证明，减少资源需求，但证明交易被收录不能替代完整的有效性验证。
选择运行方式时，需要结合设备资源与验证要求。还应区分“没有查到记录”和“记录不存在”：提供信息的节点可能遗漏内容。连接多个节点可以减少对单一来源的依赖，但仍需考虑网络隔离等情况。
隐私也取决于查询方式
客户端向外部节点查询特定交易时，可能暴露地址与查询者之间的关联。因此，隐私评估除了检查保存了哪些数据，还要检查查询请求透露了什么。
资源节省、独立验证和隐私保护之间存在取舍。适用方案应能清楚说明哪些信息由本地验证、哪些依赖外部节点，以及查询会暴露哪些关联。只有明确这些边界，才能判断技术配置是否满足实际业务要求。