针对这些挑战，我们引入了将元数据附加到证明本身的想法。我们可以将付款周期号和收款人可收到的累计通证数量 (用于在 Merkle 树中生成收款人的付款叶子节点) 合并到证明中。这样，收款人调用 paymentPool.withdraw() 函数指定提取最多金额，该金额不超过证明的通证数量。

简单吧？收款人正在调用 paymentPool.withdraw()，其中包含所需的通证数量以及一个特殊的密钥，该密钥仅对他们有效，以从支付池中解锁这些通证。

这是它的工作方式：正如我在上面提到的，证明实际上只是一系列已被序列化为十六进制格式的姑妈及叔叔哈希的数组。为了将元数据包括在证明中，我们需要向该证明数组添加几个额外的项。

具体来说，要添加与 Merkle 根相对应的付款周期号 (我们可以在将 Merkle 根提交给合约之前，在 PaymentPool 智能合约上调用 paymentPool.numPaymentCycles() 来获得该值) 以及收款人可提取的累计通证数量。在 paymentPool.withdraw() 函数中，需要从证明中剥离元数据，以便 paymentPool.withdraw() 函数知道证明所涉及的支付周期以及通证的数量是此收款人 Merkle 树中叶节点的一部分。

这样 paymentPool.withdraw() 函数才能查找到正确的 Merkle 根用作证明，同样通过 msg.sender 及在出现在证明元数据中的通证数量来正确构造叶节点哈希。

出现在 paymentPool.withdraw(amount，proof) 中的金额 (amount) 是收款人希望从所证明的通证总数中提取的通证数量。

图：Cardstack 通过元数据验证的 Merkle 树实现的支付池

这种方法还需要提供一个链上函数，允许任何人通过证明的收款人来查看可用于特定证明的通证数量。

重要注意事项

我曾在此解决方案中提到过几次，默克尔树需要跟踪通证的累计数量，这意味着收款人列表及其数量只能随时间增长-我们永远都不会看到收款人的累计数量在随后的付款周期中减少。

这是为什么呢？这是这种特定方法的细微差别：我们为每个付款周期构建的 Merkle 树需要反映收款人的累计付款金额，并且应在支付池中保留取款额的映射，其差额是可以允许收款人提供的任何有效证据提取的部分 (当差额为负时，显然不允许提取)。

如果后续付款周期中的累计付款额减少了，则意味着计算可用提取的通证数量（已提取的金额与证明元数据中的累计总数之差）将是不正确的，并对可用余额产生影响导致他们无法提取所有通证。

该解决方案也很依赖于链下技术，尤其是需要发布收款人的证明 (IPFS 可能是不错的地坊)。你可能还希望发布收款人在付款周期中可以收到的通证数量，甚至可能需要提供 dApp 的链接，该链接可以显示支付池中证明可用的余额。 (责任编辑：admin)