适用范围：技术流程不等于开票规范
区块链商户开票流程相关术语如何理解，首先要分清业务层与技术层。业务层关注开票主体、票面内容和票据效力；技术层关注数据如何提交、记录和核验。以太坊交易文档与W3C可验证凭证规范分别说明链上操作和凭证验证，均不能直接作为某个商户开票平台的操作规程或税务依据。
交易、地址与签名
以太坊文档中的交易，是经签名、用于改变网络状态的指令，也可以用于调用合约。地址用于标识链上账户；签名用于验证授权；nonce是账户交易的顺序计数。
放在开票场景中，“提交交易”不必然表示付款，也不必然表示已开票。发送地址不应直接理解为销售方身份，接收地址也可能只是处理请求的合约。技术账户与商户身份之间如何对应，需要业务系统另行建立规则。
哈希、确认与Gas
交易哈希用于标识交易，Gas用于计量执行所需的计算资源。广播、纳入区块和最终确定属于不同的链上处理阶段。
交易哈希不是发票号码，拿到哈希也不足以证明开票完成。判断结果时，需要分别核对链上执行状态与业务开票状态；即使交易已被纳入区块，也仍须检查执行是否成功。Gas费用则应与票面金额、税额及平台服务费分开理解，不能混为一项。
可验证凭证及其角色
W3C规范中的可验证凭证，是发行者对某个主体作出的声明的数字化表达。持有者保存或出示凭证，验证者核验凭证并按自身规则判断是否接受。“可验证”不等于其中的声明必然真实。
若开票系统采用这种模型，可以用这些角色理解凭证交付和核验关系，但不能直接认定凭证发行者就是法定开票主体。签名核验、发行资格审查和票面内容核对，解决的是不同问题。
常见问题：上链是否代表有效
上链是否自动赋予发票效力？不能这样推断。链上记录本身不足以说明开票主体有资格、业务真实或票据满足适用要求。
可验证凭证是否必须上链？不是。W3C模型中的注册机制也可以使用可信数据库等系统。是否使用区块链，与是否能够验证凭证，是两个不同的设计问题。
阅读具体平台的流程说明时，应分别找出申请受理、凭证生成、链上记录和业务核验的含义。只有平台明确说明各状态的对应规则，才能判断界面上的“成功”究竟代表哪一步完成。