使用非监管智能合约大规模处理ERC20付款

目录

- 简介
- Coinbase Commerce如何运作 - 30k英尺概述
- 非托管设计
- 天真的解决方案 - 转发合同
- 减少交易规模
- 尽可能优化脱链
- 最大限度地降低部署成本
- 结论

Coinbase Commerce的使命是成为企业接受加密货币的最简单方式。我们在2018年2月推出了支持BTC，ETH，LTC和BCH，使任何人都可以在几分钟内开始接受加密货币。虽然我们的商家喜欢在世界任何地方与客户进行即时交易的能力，但许多人表示担心加密货币的波动性，因为以法定计价的商业成本。

与传统的加密货币不同，美元硬币（ USDC ）等稳定币的设计明确是为了避免这种波动。几个月前我们发布了USDC支持，为我们的商家提供了一种无波动的方式来接受加密货币。 USDC以美元一对一支持，使其价格稳定，并使其成为商业的绝佳选择。 USDC作为ERC20令牌实施，生活在以太坊区块链上。在这里，我将讨论我们在平台上支持USDC的方法。这篇文章面向任何对Coinbase Commerce内部感兴趣的人。对于dapp开发人员来说尤其有用，他们可能会发现围绕create2的想法和实现以及与他们的工作相关的最小代理协议。

Coinbase Commerce如何运作 - 30k英尺概述

当客户想要向Coinbase Commerce商家付款时，我们会创建一个收费对象 ，用于跟踪客户想要购买的商品，成本，他们需要支付的区块链地址以及其他元数据。我们为每笔费用生成一个唯一的区块链地址，作为收费和付款的规范标识符。当客户支付费用时，他们通过从任何钱包或交换机向其中一个地址发送资金来支付费用。通过持续监控区块链以支付这些地址，我们知道客户是否支付了费用以及他们支付了多少费用，从而推动了费用的完成以及发送相应的webhook和电子邮件。

我们的工作流程 - 生成一个唯一的地址，让客户支付到该地址，并让我们的系统检测到区块链上的付款 - 只是区块链支付处理器的一种设计方式。其他工作流程基于JSON支付协议 ，其中客户的钱包向处理器的服务器发送RPC调用并交换必要的信息以进行支付。另一种方法是使用ETH的Web3界面要求客户签署自定义的非标准交易。虽然这些方法具有独特的优势，但对我们而言，保持简单的仅地址接口非常重要。绝大多数客户使用交易所或托管钱包，因此只能将资金发送到地址 - 他们无法启动RPC调用或签署自定义交易。因此，对我们来说，最重要的是我们的解决方案不需要任何简单的地址，每个人都可以使用并发送付款。

非托管设计

Coinbase Commerce的部分价值主张是我们作为非托管服务运营，这意味着我们不会充当中间人，所有交易都直接在客户和我们的商家之间进行。非监管意味着一旦付款启动，任何人（包括Coinbase Commerce）都无法阻止资金的流动。我们从不让任何私钥袭击我们的服务器，因此我们无法审查或恢复交易。作为非监管解决方案，需要进行一些权衡。从积极的方面来说，这意味着：

• 它增加了权力下放
• 它增加了与其他钱包和工具的互操作性
• 它降低了使用该服务的风险

但是，我们试图减轻一些缺点：

• 私钥意外丢失（如果使用加密备份功能，则可恢复）
• 难以自动化某些活动，如退款或预定提款

鉴于Coinbase Commerce如何运作的背景，让我们深入研究我们的USDC解决方案的设计和实施。我将从一个天真的解决方案开始，传达一般的想法，并迭代地解决它的缺点，最终到达我们今天在Coinbase Commerce使用的生产版本。我将介绍几种技术 - 工厂模式，create2操作码，最小代理合同 - 这使得部署ETH合同的规模可行。这些技术可用于各种业务设置。

天真的解决方案 - 转发合同

我们的解决方案基于以下理念：我们创建智能合约，可以像接受普通账户一样接受资金，唯一的功能是将接受的资金转发到属于商家的固定预定地址。这样，客户仍然可以使用简单的仅限地址的界面进行支付，并且商家可以确定他们的资金不会被任何人滥用。事实上，客户和商家可能都不会意识到智能合约逻辑一直存在！这是一个这样的货代合同：

虽然合同达到了我们的要求，但是从这些转发器中创建生产系统是不可行的。对于已启用USDC付款的每个商家，我们需要抢先将多个转发器部署到区块链，以确保在客户启动付款流时存在可用的地址池。在我们检测到对其中一个已部署合同的付款后，我们（或商家）可以调用刷新功能将令牌转发到商家的目的地并完成资金的移动。

然而，管理这些池非常昂贵（每个合同创建都需要在区块链上公布燃气费），非常繁琐并且导致网络不必要的拥塞，使得它们对于任何生产设置都不起作用。

减少交易规模

以太坊交易的成本主要与该交易中执行的逻辑的复杂性有关 - 交易需要处理其逻辑的CPU时间越多，交易消耗的气体就越多。但是，对于执行重复，简单任务的合同，事务成本由事务使用的空间而不是其运行时逻辑支配。

工厂模式显着有助于降低这些交易的成本。我们可以部署一个知道如何实例化新转发器的ForwarderFactory，而不是在部署新的转发器时多次编码相同的逻辑。我们不再需要在每次部署转发器时复制完整的源代码 - 相反，我们只能编码指向已部署代码的指针。这导致燃气成本降低47％;事实上，完全实现的天真事务重1783字节，其中仅包含函数参数的工厂事务仅重175字节。

尽可能优化脱链

部署转发器的工厂的副产品是我们现在能够在将它们部署到区块链之前计算转发器的地址。这可以实现与为每个商家抢先部署转发合同相同的用户体验，而不会产生在区块链上部署这些合同的费用。

在以太坊中，创建的合同的地址是确定性的 - 它们可以从发件人的地址（即创建合同的帐户，在我们的情况下是工厂）和发件人的nonce（计算器跟踪从该帐户发起的交易数量）计算得出）。然而，这在实践中效果不佳，因为随机数是一个不断增加的全球反击。如果客户支付到第100个生成的地址，我们仍然需要部署最初的99个合同，这样我们就可以部署预期的第100个转发器，我们需要按照确定的顺序执行此操作。当我们需要部署合同以达到预期的现状时，这些差距是不可避免的，因为客户可能会产生费用但却从不付费。

这是一个困扰以太坊社区很长一段时间的问题，并且一直是许多dapp开发人员的愿望清单。幸运的是，在君士坦丁堡网络升级中引入create2操作码解决了这个问题。与使用不断增加的发送者的随机数的create不同，create2使用参数指定的salt。这使得许多工作流程在以前变得不可能或不切实际 - 我们现在可以完全模拟出复杂的工作流程;无需跟踪自生盐之外的任何状态。只有当我们需要进行链式结算时，我们才能安全地与区块链进行交互。以下是我们如何使用create2操作码来部署转发器。

请注意，现在initForwarder在隐式nonce执行其功能之前需要额外的salt。这允许我们明确决定在区块链上部署哪些合同，因此如果第100个客户支付但初始99不支付，我们可以按顺序部署第100个转发器，而无需首先部署初始99。

查看计算地址的代码是有用的：

除了使用盐之外，地址生成算法中的一个关键安全特性是使用字节码。将字节码作为参数之一可确保无法在指定地址部署“错误”合同。对于我们的示例，这意味着只有一个目标和salt的组合可以导致在计算地址处部署合同。恶意攻击者不可能将他们自己的逻辑或目的地的合同部署到我们已经计算过的地址。因此，我们可以向客户提供这些未部署的地址，并确保攻击者无法通过将他们自己选择的合同部署到该特定地址来超越我们。

这可以实现我们在Commerce使用的新工作流程。现在可以在完全脱链的情况下创建和模拟不可变的工作流程，并且只有在客户已经支付了发票后才在区块链上进行“结算”阶段。

最大限度地降低部署成本

我们可以通过使用另一种称为最小代理合同的新技术来进一步降低解决方案的成本。最小代理合同允许部署合同，该合同是另一个现有合同的精确副本，但是部署起来非常轻。它们代表了以太坊区块链的符号链接 - 它们有自己的地址，但是它们将所有功能推迟到它们指向的原始合同。这些代理合同包括精心设计的“魔术”字节码，用于更改执行堆栈并使用delegatecall操作码将实现委托给目标合同。在我们的情况下，我们可以为该商家部署单个转发器，并从该点开始使用其克隆，而不是在客户向同一商家付款时部署新的转发器。与工厂解决方案相比，使用克隆可将燃气成本进一步降低61％。

您可以在此处查看我们在生产中使用的合同。该链接暗示了我们采取的方法的几个缺点：

• 单身工厂减少了隐私
• 由于额外的冲洗呼叫，增加最小结算时间

工厂，create2操作码和最小代理契约是可以应用于各种情况的模式。在Coinbase Commerce，我们应用这些模式使资金流动尽可能简单和便宜，但任何其他需要模拟与多个合同交互的工作流程，只需部署一个子集就可以从中受益。

区块链工程中的许多模式都能实现新颖的工作流程，但这些模式带来了自己的陷阱和惊喜。作为一个年轻的生态系统，其文档和最佳实践落后于协议层面的进步。

USDC转发是我们日常加密技术工作的一个很好的例子，也是构建复杂生产系统的有趣挑战。如果您喜欢在有趣，高能量的环境中工作并希望轻松接受加密货币，那么请在此处查看所有未结头寸。我们很乐意听取您的意见。

Coinbase Commerce中的USDC支付处理最初发布在The Coinbase Blog on Medium上，人们通过突出显示和回应这个故事来继续对话。