|
Merkle 树方法的优点在于只需要向支付池中写入 32 字节的 Merkle 根，并且收款人数量没有上限。 原文标题：《利用 Merkle 树低成本实现可扩展支付池》 我最近一直在研究一个有趣的问题：支付池（payment pool）- 实现仅需少量 gas 的多方支付。 支付池是一种通用机制，可用于模拟「一对多」或「多对多」支付通道。这个想法是，可以从各种来源将通证存放到池中，然后根据「规则」(在链上或链外实施) 将池中的通证分配给许多接收者。本质上，我们的方法有能力就按大量小额付款汇总到一个结算中，从而节省了大量的 gas 。 考虑一个类似于 Spotify 的场景，在此案例中，每当有人听一首歌，就向音乐家支付版税。流媒体服务可以用大量通证为音乐家的支付池提供资金。然后，当人们播放音乐时，这些播放日志将在每个付款周期中汇总，汇总的付款金额将被反馈到支付池，从而以比在链上交易（每次听歌时都触发交易）少的 gas 消耗的方式来支付音乐家之间的版税。 先看看：基于数组的支付池我们最初对这种链上支付池智能合约的构想非常简单。 在我们的 Tally 协议，协议通过「分析」矿工贡献的 GPU 周期来计算奖励，和流媒体场景很类似，开始的想法是支付池智能合约将从各种通证收集智能合约接收 ERC-20[3] 通证，通过分析签名的应用程序使用日志和其他链上信号来确定支付池内的通证分配。分析矿工将就支付池中的付款金额达成共识，并通过提交一系列收款人地址和付款金额的形式提交给支付池，这些地址和付款金额将写入支付池管理的帐本中。 此解决方案最明显的缺点是，支付池处理的是无限的收款人及其付款金额，这意味着这种交易可能会超出 gas 限值。这将需要支付池能监控 gas 预算，并跟踪收款人列表，以便如果超出 gas 预算时，以便可以在后续交易中继续执行。 我们进行了一些实验，在当前的区块 gas limit 下，可以支持 200 多名收款人，再多就会超出 gas 限制，假设按 gas 价格为 35 gwei ， gas 限额为 10,000,000，需要耗费 0.35 个 ETH （当前大约 1000 块），相当于存储每个收款人支付的 gas 费是 5 块。 显然，这种方法无法扩展。 Merkle 树在寻找更好的方法时，我们受到这篇以太坊研究文章 [4] 的启发 这个想法是，与其让支付池管理收款人及其付款金额的帐本，不如建立一个保存收款人及其付款金额的 Merkle 树[5]，然后收款人通过提交 Merkle 证明来提取相应的金额。然后，Merkle 证明将成为仅适用于收款人的密钥，该密钥可在支付池中解锁收款人的通证。 (责任编辑：admin) |