Share Dialog

Share Dialog

加密货币聚合支付技术方案思考

加密货币聚合支付技术方案思考

<100 subscribers

<100 subscribers

1. 目的在于确认链上的一笔交易是指向到特定用户的(即确认收款方身份)

2. 这个收款账户的控制方是币安，但该地址与特定用户一对一关联

3. 当然这个账户并非是外部账户, 而是一个支持收款的合约账户(通过CREATE2预生成)

1. 交易所是给用户维度(用户对应币种和网络)创建的钱包地址，来保障一个钱包地址的一笔/多笔充值均可以关联到该用户

2. 如果按交易所充值的做法来实现商户的收款，在商户维度创建钱包地址，但同一个商户地址会同时接受不同用户的付款交易，那商户就无法确认交易与用户的关系

3. 中心化支付服务商(如Alipay/Paypal)的做法是在交易信息中增加「商户订单号」的形式来确权的

4. 所以需要在支付单维度为每笔订单生成唯一收款账户，这样就保障了链上交易记录与订单挂钩，订单又与用户挂钩

1. 用户在商户侧购买商品并发起结算生成加密支付的交易单，跳转至聚合支付服务商收银台

2. 用户选择需要支付的加密货币类型(如ERC20网络的USDT)

3. 支付服务商为商户的该笔交易单创建唯一的收款地址(合约地址)

4. 支付服务商开始监测该收款地址的变动

5. 用户向交易单对应的钱包地址进行转账

6. 支付服务商监测到该地址产生了已确认的交易后，向商户进行支付通知

7. 商户侧收到支付通知后标记订单支付

涉及到两个话题，一个是资金安全，另一个是商户的提现流程如何设计，这两个话题之所以一起描述是因为有很紧密的关系

1. 资金安全，或者理解为如何做到商户对支付平台的单向信任，说的直白一点就是钱你平台收了，那会不会跑路或者你的钱包私钥泄露了怎么办

2. 资金入账，即支付服务商收的款项以什么样的流程转移到商家自己控制的钱包里

收款账户的地址可以选择外部账户(Externally-owned account) 和合约账户(Contract account), 我们对比一下选出最优的

1. 外部账户：为每一笔交易创建一个外部账户，支付服务商需要托管账户的私钥

2. 合约账户：为每一笔交易创建一个智能合约并用合约地址作为收款地址，避免保存地址的私钥信息，通过调用智能合约进行资金转移

显然，方案2从资金安全考虑是最优的，但为每一笔交易都部署合约显然是昂贵的，所以最优的方式是通过CREATE2操作码预计算出合约地址，通过此地址先进行收款，等需要转移资金时再部署合约

前文提到为每一笔交易预创建一个合约地址收的资金，会有两个流向：商户的钱包(入账)、服务商的钱包(分佣)，下面讲解如何将合约钱包中的数字货币进行转移的

1. 为预生成的地址实际创建合约，合约中标明资金的转移规则

2. 按平台佣金规则计算出的佣金，转账到平台账户

3. 剩余的资金转账到商户账户

4. 销毁合约(通过自毁函数 selfdestruct)，这将退还部署智能合约部分的Gas费

此时资金已经成功入账和分佣，但是这种方式安全吗？我们会在合约的构造方法里加上入账方的地址参数，这样确保了接受者始终是我们预期的，这样无论如何攻击者都无法使用任何收款来获取资金的控制权。

一笔交易完成后，在很短的时间里会通过智能合约进行资金转移，即资金会入账到商户自己的钱包里，如何保障钱包的安全至关重要

1. 在商户在支付服务商平台首次注册时，在客户端生成钱包(含地址、助记词、私钥)，私钥信息绝对不会发送到服务商的服务端

   1. 当然此时秘钥等信息的安全备份会是商家的重点，否则损失无法挽回

   2. 也可以有加密备份私钥的方式可选，服务商只存储加密密钥，做双重保险（如Coinbase Commerce 提供的将加密版本的私钥存储到Google Drive的方式）

2. 服务商仅将钱包地址存储以进行资金的转入

3. 商户提现，当然此时钱包就是自己也不存在提现一说了，如果就是想将服务商帮创建的钱包余额转移到自己的钱包中

   1. 商户可以将助记词导入到钱包工具中自行转账

   2. 如果需要服务商平台执行，那就需要商户通过自行上传的秘钥在客户端进行对交易进行签名，由服务商把签名后的交易广播出去

这里部署在以太坊测试网上的合约地址为 ：0x4d3e2C755aCCeDb752878b2E025Bdfa2cFE7116C

CREATE2 定义了新的账户生成方式：keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] （其中 Account a = new Account{salt: _salt}(_to); 是 Solidity 0.6.2 加入的支持 CREATE2 的语法糖）。

• Transaction Details：https://rinkeby.etherscan.io/tx/0x3a7027b6c6336f50d71a02eda18e1319f00ccc150912ce52f6ff92c97b4fbf0a

• Contract Address：https://rinkeby.etherscan.io/address/0xdebedc5e19376c4c2c8b365d47cf7dc031cd7a7a

• 通过调用 Wallet 合约的 create 方法来创建 Account 合约：https://rinkeby.etherscan.io/address/0x4d3e2C755aCCeDb752878b2E025Bdfa2cFE7116C#writeContract

• Account 合约创建后在构造方法中直接实现了资金的转移，无需显示调用，验证合约的资金流向：https://rinkeby.etherscan.io/address/0xdebedc5e19376c4c2c8b365d47cf7dc031cd7a7a#internaltx

https://gist.github.com/JingwenTian/f9ce513157bd540511e2577914092304

最后，其实还有很多细节问题没有涉及到，比如小额支付时的佣金无法覆盖创建合约和转账的Gas成本、用户多支付的退款流程、用户商户侧主动发起退款流程、在支付服务中币价波动风险及应对策略等的思考，以后有机会再和大家分享。

感谢阅读！如果有问题交流，可以关注并私信我：微信(jingwentian)、Twitter(@0xDaotian)、微信公众号(北极之野)、Substack邮件订阅(文叔白话WEB3)。

1. 目的在于确认链上的一笔交易是指向到特定用户的(即确认收款方身份)

2. 这个收款账户的控制方是币安，但该地址与特定用户一对一关联

3. 当然这个账户并非是外部账户, 而是一个支持收款的合约账户(通过CREATE2预生成)

1. 交易所是给用户维度(用户对应币种和网络)创建的钱包地址，来保障一个钱包地址的一笔/多笔充值均可以关联到该用户

2. 如果按交易所充值的做法来实现商户的收款，在商户维度创建钱包地址，但同一个商户地址会同时接受不同用户的付款交易，那商户就无法确认交易与用户的关系

3. 中心化支付服务商(如Alipay/Paypal)的做法是在交易信息中增加「商户订单号」的形式来确权的

4. 所以需要在支付单维度为每笔订单生成唯一收款账户，这样就保障了链上交易记录与订单挂钩，订单又与用户挂钩

1. 用户在商户侧购买商品并发起结算生成加密支付的交易单，跳转至聚合支付服务商收银台

2. 用户选择需要支付的加密货币类型(如ERC20网络的USDT)

3. 支付服务商为商户的该笔交易单创建唯一的收款地址(合约地址)

4. 支付服务商开始监测该收款地址的变动

5. 用户向交易单对应的钱包地址进行转账

6. 支付服务商监测到该地址产生了已确认的交易后，向商户进行支付通知

7. 商户侧收到支付通知后标记订单支付

涉及到两个话题，一个是资金安全，另一个是商户的提现流程如何设计，这两个话题之所以一起描述是因为有很紧密的关系

1. 资金安全，或者理解为如何做到商户对支付平台的单向信任，说的直白一点就是钱你平台收了，那会不会跑路或者你的钱包私钥泄露了怎么办

2. 资金入账，即支付服务商收的款项以什么样的流程转移到商家自己控制的钱包里

收款账户的地址可以选择外部账户(Externally-owned account) 和合约账户(Contract account), 我们对比一下选出最优的

1. 外部账户：为每一笔交易创建一个外部账户，支付服务商需要托管账户的私钥

2. 合约账户：为每一笔交易创建一个智能合约并用合约地址作为收款地址，避免保存地址的私钥信息，通过调用智能合约进行资金转移

显然，方案2从资金安全考虑是最优的，但为每一笔交易都部署合约显然是昂贵的，所以最优的方式是通过CREATE2操作码预计算出合约地址，通过此地址先进行收款，等需要转移资金时再部署合约

前文提到为每一笔交易预创建一个合约地址收的资金，会有两个流向：商户的钱包(入账)、服务商的钱包(分佣)，下面讲解如何将合约钱包中的数字货币进行转移的

1. 为预生成的地址实际创建合约，合约中标明资金的转移规则

2. 按平台佣金规则计算出的佣金，转账到平台账户

3. 剩余的资金转账到商户账户

4. 销毁合约(通过自毁函数 selfdestruct)，这将退还部署智能合约部分的Gas费

此时资金已经成功入账和分佣，但是这种方式安全吗？我们会在合约的构造方法里加上入账方的地址参数，这样确保了接受者始终是我们预期的，这样无论如何攻击者都无法使用任何收款来获取资金的控制权。

一笔交易完成后，在很短的时间里会通过智能合约进行资金转移，即资金会入账到商户自己的钱包里，如何保障钱包的安全至关重要

1. 在商户在支付服务商平台首次注册时，在客户端生成钱包(含地址、助记词、私钥)，私钥信息绝对不会发送到服务商的服务端

   1. 当然此时秘钥等信息的安全备份会是商家的重点，否则损失无法挽回

   2. 也可以有加密备份私钥的方式可选，服务商只存储加密密钥，做双重保险（如Coinbase Commerce 提供的将加密版本的私钥存储到Google Drive的方式）

2. 服务商仅将钱包地址存储以进行资金的转入

3. 商户提现，当然此时钱包就是自己也不存在提现一说了，如果就是想将服务商帮创建的钱包余额转移到自己的钱包中

   1. 商户可以将助记词导入到钱包工具中自行转账

   2. 如果需要服务商平台执行，那就需要商户通过自行上传的秘钥在客户端进行对交易进行签名，由服务商把签名后的交易广播出去

这里部署在以太坊测试网上的合约地址为 ：0x4d3e2C755aCCeDb752878b2E025Bdfa2cFE7116C

CREATE2 定义了新的账户生成方式：keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] （其中 Account a = new Account{salt: _salt}(_to); 是 Solidity 0.6.2 加入的支持 CREATE2 的语法糖）。

• Transaction Details：https://rinkeby.etherscan.io/tx/0x3a7027b6c6336f50d71a02eda18e1319f00ccc150912ce52f6ff92c97b4fbf0a

• Contract Address：https://rinkeby.etherscan.io/address/0xdebedc5e19376c4c2c8b365d47cf7dc031cd7a7a

• 通过调用 Wallet 合约的 create 方法来创建 Account 合约：https://rinkeby.etherscan.io/address/0x4d3e2C755aCCeDb752878b2E025Bdfa2cFE7116C#writeContract

• Account 合约创建后在构造方法中直接实现了资金的转移，无需显示调用，验证合约的资金流向：https://rinkeby.etherscan.io/address/0xdebedc5e19376c4c2c8b365d47cf7dc031cd7a7a#internaltx

https://gist.github.com/JingwenTian/f9ce513157bd540511e2577914092304

最后，其实还有很多细节问题没有涉及到，比如小额支付时的佣金无法覆盖创建合约和转账的Gas成本、用户多支付的退款流程、用户商户侧主动发起退款流程、在支付服务中币价波动风险及应对策略等的思考，以后有机会再和大家分享。

感谢阅读！如果有问题交流，可以关注并私信我：微信(jingwentian)、Twitter(@0xDaotian)、微信公众号(北极之野)、Substack邮件订阅(文叔白话WEB3)。