先确定应用类型与责任边界
讨论区块链技术的应用类型需要注意哪些问题，可以先从业务动作入手：系统是在接收付款，还是通过合约控制某项操作？前者关注付款信息与订单如何对应，后者关注谁能执行和修改规则。本文讨论支付处理与智能合约权限管理，相关实现不能直接套用于所有区块链系统。
支付处理：金额、订单与请求安全
Bitcoin开发者指南中的支付处理说明强调，付款请求应明确地址、金额和单位，独立收款地址有助于匹配订单。涉及法币换算时，还需关注报价数据和有效期。私钥不宜存放在网页服务器上，付款请求需要安全传输。指南也明确标注BIP70支付协议已弃用，不能仅凭其中较早的功能介绍判断其适用性。
这类设计适用于需要把链上付款关联到业务订单的系统。常见问题是只展示收款信息，却没有明确报价过期、金额不符或退款时的处理责任。订单规则应覆盖这些异常，否则即使能够识别付款，也可能无法确定该怎样继续履约。
智能合约：操作权限与授权权限
OpenZeppelin访问控制文档区分单一所有者管理与按角色授权。Ownable适合单一管理员场景，AccessControl用于细分权限；具备业务角色通常不代表可以向他人授予该角色。默认管理员权限较大，需要重点保护。两步所有权转移要求接收方确认，放弃所有权则会使受onlyOwner保护的操作无法再调用。
选择权限模型时，应先列出业务职责。例如，执行日常操作与调整人员权限属于不同责任，不宜仅因管理方便就合并。对于多人协作的应用，角色划分还需要覆盖人员离任、账户失控和权限交接，避免只考虑部署时的初始配置。
常见误区：把技术组件当作完整保障
支付请求的安全传输和合约的权限检查解决不同问题：前者保护信息传递，后者约束函数调用。两者结合使用时仍需分别验证，不能因为某一环节有保护，就推断整个业务流程可靠。
验收也应贴近具体动作：支付系统检查金额单位、订单关联和异常处理是否一致；合约系统检查无权限账户是否被拒绝，以及交接后新旧账户的权限是否符合预期。应用类型决定检查重点，业务责任决定异常发生后由谁处理。