区块链支付中交易终态方案分析-出家如初,成佛有余

区块链支付中交易终态方案分析

区块链 admin 183浏览 0评论

传统法币支付交易中,一笔交易订单会经历如下几个状态:业务订单创建->待支付(用户选择支付方式)->支付中(跳转支付渠道)->支付成功/失败->业务订单成功/失败。除了正常状态变化外,还有退款、冲正、对账后导致支付状态变化的情况,但不影响这里讨论。

可以说:在法币支付中,业务订单成功/失败必须发生在支付成功/失败后,也即业务状态的终态发生在支付状态的终态后。

但在区块内支付中,由于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%攻击等风险。一般采用的方案:根据交易金额、交易场景等因子,对交易分层级确认。

例如根据不同的金额,采用不同的风控策略。

对小额支付且采用二层网络的用户,实时支付,同时确认业务终态。

对小额支付,基于风控反欺诈引擎,实现零区块确认,同时确认业务终态。

对使用指定多签名支付钱包的用户,通过多签名地址服务,完成实时支付,确认业务终态。

对大额支付,但未使用指定钱包的用户,按照业内标准的确认区块数,确认业务终态。

转载请注明:出家如初,成佛有余 » 区块链支付中交易终态方案分析

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址