传统法币支付交易中，一笔交易订单会经历如下几个状态：业务订单创建->待支付（用户选择支付方式）->支付中（跳转支付渠道）->支付成功/失败->业务订单成功/失败。除了正常状态变化外，还有退款、冲正、对账后导致支付状态变化的情况，但不影响这里讨论。
可以说：在法币支付中，业务订单成功/失败必须发生在支付成功/失败后，也即业务状态的终态发生在支付状态的终态后。
但在区块内支付中，由于Bitcoin、Ethereum等主要公链都存在共识协议协商过程，需要等待一定的区块确认数才能确认交易状态不可再更改。例如在安全性要求较高的情况下，一般情况下对接收方要确认Bitcoin 为6个区块，Ethereum为36个区块。
这就导致一个巨大问题：用户和商家需要等待极其漫长的区块确认过程，才能确认是否支付成功。与法币支付基本上实时完成相比，支付等待时间成为加密币支付大规模普及的一个障碍。
为了解决支付确认时间过长的问题，一般的解决方案包括：
1、赌51%攻击的概率，减少区块确认数
例如很多交易所对Bitcoin入金操作，确认区块数为1个。
各家交易所的确认区块数可以参考这篇文章《盘点46家交易所的充值区块确认时间和攻击成本》。
2、区块零确认方案
区块零确认方案，又可以分为四类
a、中心化权威机构方案，例如公认具有信用的中心化机构，由其信用担保用户不会双花，例如coinbase
b、联盟链方案，例如blockstream liquid侧链
c、来自多签名钱包服务商的可信地址，例如 greenaddress（Blockstream Green）
d、风控反欺诈引擎
具体可以参考《比特币零确认（实时支付）方案》
3、Lighting Network、State Channel等二层网络
由于Lighting Network、State Channel等二层网络基本上可以作到实时支付，支付速度在体验上与法币支付相差不大。但二层网络目前应用在小额支付上，且主流钱包尚未支持。
而对多签名方案，需要依赖于特定的多签名钱包服务商，主流钱包也不提供多签名支付方案，使用场景有一定局限性。
因此在实际应用中，像Alchemy Pay这样的加密币支付服务提供商会同时组合几种方案同时使用，以满足不同场景的需要。
这样就导致一个现实问题：业务状态的终态确认时间会早于区块内终态的确认时间，这就存在较大交易风险。
a、业务终态
为避免用户等待，提升用户体验，对小额支付支持零区块确认。通过风控引擎，对每一笔交易风险等级打分。对通过评分的交易，会确认交易成功，同时通知商家、合作伙伴。此种情况下交易的业务状态为终态，不会再撤销。会按照成功交易与商家结算，零区块确认的风险由支付服务商来承担，以保证商家、用户的利益和支付体验。
b、区块链终态
对应交易在区块链上状态变为终态，也即对应交易的状态被更改的概率极低，例如BTC为6个区块，ETH为36个区块。
为规避交易业务状态为终态，但区块链状态尚未终态的情况下，用户双花、51%攻击等风险。一般采用的方案：根据交易金额、交易场景等因子，对交易分层级确认。
例如根据不同的金额，采用不同的风控策略。
对小额支付且采用二层网络的用户，实时支付，同时确认业务终态。
对小额支付，基于风控反欺诈引擎，实现零区块确认，同时确认业务终态。
对使用指定多签名支付钱包的用户，通过多签名地址服务，完成实时支付，确认业务终态。
对大额支付，但未使用指定钱包的用户，按照业内标准的确认区块数，确认业务终态。
转载请注明：虚拟号之家 » 区块链支付中交易终态方案分析