先明确服务的适用范围
新区块链技术服务需要注意哪些问题，首先取决于服务解决什么业务需求。这里讨论新上线或新引入的区块链服务，不涉及某个具体品牌的能力认定。NIST《区块链技术概述》将区块链描述为分布式实现、具有篡改可察觉性和抗篡改能力的数字账本，在网络正常运行的条件下，已发布的交易记录不能被随意修改。
据此评估服务时，应先说明哪些参与方需要共享记录、如何确认记录，以及各方承担什么责任。如果业务需求仅是保存数据，就需要进一步解释引入分布式账本的必要性。
区分记录稳定与数据真实
常见问题是：信息上链后是否就可信？账本保护的是已经记录的内容，不能仅凭抗篡改特性证明输入内容真实。例如，业务人员录入错误信息，记录得以保留，也不意味着错误自动得到纠正。
服务设计应明确数据由谁提交、依据什么核验、错误如何补充说明。涉及外部业务数据时，还应交代数据来源及责任边界，避免把账本层面的技术特性扩大成对全部业务事实的保证。
核查敏感操作与管理权限
以太坊智能合约安全文档强调访问控制、充分测试和独立代码审查，并指出审计无法发现所有缺陷。这些原则尤其适用于通过智能合约执行规则、管理数据或控制资产的服务。
评估时应关注谁能升级、暂停或执行其他敏感操作，以及账户失陷后可能影响哪些功能。角色分工可以限制各账户的权限，多重签名可以让关键操作需要多方同意；具体效果仍取决于权限配置和签名账户的管理。合约函数标记为私有，也不能据此认为链上数据具有保密性。
检查测试与审查覆盖什么
仅验证正常流程能够完成，难以充分判断安全性。应检查异常输入、越权调用和边界状态是否纳入测试，关键规则是否有明确的验证目标。单元测试、静态分析和模糊测试关注不同问题，可以结合使用。
常见问题是：通过审计是否等于没有漏洞？审计只是增加一次独立检查。阅读审查结果时，应核对覆盖的代码版本、发现的问题和修复状态。形式化验证的结论同样受规格、模型和假设限制，不能扩大为整个服务绝对安全。
明确上线后的变更责任
部署后的合约通常难以像普通应用一样直接修改，因此应提前说明故障发生时如何处置。如果采用可升级设计，需要交代升级权限和变更规则；如果无法升级，则应明确缺陷处理及迁移安排。服务的安全边界还应与实际部署方式对应，不能把以太坊合约的具体机制直接套用于所有区块链系统。