得到如下所示的列表：

请注意，这些并不是这些节点的实际 Merkle 证明，而是一些随机的十六进制来传达想法

然后，收款人可以使用金额和证明作为函数的参数来调用支付池合约上的函数，以便提取其通证。

思路是 paymentPool.withdraw() 函数将通过 msg.sender 及通证数量重建叶子节点。withdraw 函数可以哈希该叶节点并将哈希的叶节点添加到证明 (这是构成证明的哈希的十六进制表示)。如果哈希叶节点和提供的证明之和的哈希值等于合约所有者提交的 Merkle 根，那么 paymentPool.withdraw() 函数可以允许将通证从支付池转移到 msg.sender。

此外，我们需要跟踪每个收款人的提款，以便 msg.sender 无法重复调用 paymentPool.withdraw() 函数。

因此，这种方法是一个好的开始。我们已经解锁了从支付池中支付收款人所需数量通证的功能，而不必产生大量的 gas 费，此外，这意味着我们支付池中收款人的数量和所需要的 gas 费解耦了。收款人的证明基本上就像钥匙一样，仅用于从收款人的地址发起的交易，可用于从池中解锁该收款人的通证。

但是我们仍然面临一些挑战。

1. 如果收款人只想提取一部分通证怎么办？
2. 如何表示链上某个地址可用的通证数量及证明？
3. 多个付款周期呢？Merkle 根更新后，我们可以使用旧的证明吗？

改进

为了解决上述挑战，我们在每个收款人的证明中添加了元数据，并在支付池中引入了「付款周期」的概念。

付款周期

在支付池智能合约中，我们跟踪每个 Merkle 根提交所描绘的付款周期。合约所有者向支付池提交 Merkle 根表示当前付款周期已结束，新的付款周期开始。

在支付池智能合约中，我们维护一个映射属性，该属性将付款周期映射到管理该付款周期中在该支付池的 Merkle 根。这样，当用证明调用 paymentPool.withdraw() 函数时，如果我们知道生成证明所依据的付款周期，则可以使用正确的 Merkle 根来验证证明。

这使收款人可以使用旧的证明来提取付款。同时，这确实意味着证明与特定数量的通证相关。你无法提取超过在叶子节点的哈希值对应的通证数量。

只要支付池跟踪每个收款人已提取多少通证，就可以确保从分配给该收款人的累计通证中减去已提取的通证数量。

证明元数据

要克服的另一个挑战是如何提取少于创建证明时的通证数量。此外，我们如何使用户更容易将证明与特定付款周期相关联，以便可以使用正确的 Merkle 根来验证提款请求？ (责任编辑：admin)