术语的适用范围
区块链客户管理系统相关术语，需要结合具体功能理解。以下以以太坊智能合约及OpenZeppelin权限机制为范围，客户管理中的例子仅用于解释概念，不代表某个产品已经实现这些功能。阅读系统说明时，可以先区分业务规则、操作权限和数据来源。
智能合约、状态与交易
以太坊开发文档将智能合约解释为部署在特定链上地址的程序，其中包含代码和状态。代码规定如何处理操作，状态保存程序当前记录；用户可以提交交易调用合约功能，部署和链上执行涉及Gas费用。合约也能调用其他合约，这种能力称为可组合性。
放在客户管理场景中，可以把某项链上服务资格理解为状态，把变更资格的条件理解为规则。业务中的一次“修改客户资格”，可能对应一次合约调用。交易在这里是链上操作的技术概念，不必然指商品买卖。
所有者、角色与管理员
OpenZeppelin访问控制文档介绍了两种机制：Ownable由所有者承担受限管理操作；RBAC按角色划分权限，AccessControl提供角色检查、授予和撤销能力。持有业务角色并不自动获得分配该角色的权限，角色管理员负责授权管理。最小权限原则强调只授予职责所需的能力。
例如，若系统分别设置客户资格审核和权限管理职责，审核人员可以获得审核权限，管理员负责人员授权。理解“管理员”时，应看其能管理哪些角色，不能直接推断其拥有全部业务操作权。
多签与预言机
以太坊开发文档还说明，多签合约要求达到预设数量的有效签名才能执行操作；预言机则向合约提供链外信息，因为合约本身不能主动读取现实世界数据。
两者解决的问题不同。涉及多人审批的客户管理操作，可以采用多签机制表达共同授权；需要依据外部审核结果更新链上资格时，则需要外部数据输入机制。签名数量足够不代表审核内容真实，数据进入合约也不意味着其准确性得到自动保证。
常见问题与理解边界
有访问控制是否就能隐藏客户资料？功能调用权限与数据保密是不同问题。仅凭“只有审核员能修改”这一规则，无法推断相关数据只有审核员能查看。
用了智能合约是否就能完成整个客户管理流程？还需明确哪些判断由链上程序执行，哪些信息来自外部系统，以及谁能授权变更。评价术语是否落到实处，应对应到具体功能和权限条件，不能仅凭“上链”或“自动执行”认定系统完整可靠。