Aztec：私有状态的 UTXO 并发问题
一个简单的答案是在你的黑色智能合约中拥有一个不受约束的函数，它可以获取用户的多个注释，并让 dapp 开发人员以这种方式确定它。
原文标题：UTXO Concurrency Issues for Private State
原文作者：rahul-kothari
原文来源：Aztec
编译：Lynn，MarsBit
注意 - “UTXO”、“注释”和“承诺”一词可以互换使用。
背景
Aztec 正在将 UTXO 用于其私有状态。 这让我们面临一些其他也实现可编程 UTXO 的可编程区块链所面临的 UTXO 并发问题。
比如说，我在智能合约中有一堆私人票据（就像私人存储余额的代币合约），并且我在交易中使用其中一些。 当从数据库中获取笔记时，我们总是获取前 X 个尚未被取消的笔记（参考 12 和参考 2），即默认情况下我们不使用偏移量。
一旦这些票据在交易中使用，它们就可以被视为待处理，直到状态更新（当区块在 L1 上最终确定时发生），这可能需要 2-10 分钟（取决于我们的证明者网络证明的速度） 。 但在那之前，交易仍然悬而未决，承诺也没有被取消。
因此，当该交易处于待处理状态时，如果用户再次在同一合约上获取票据，他们将获得相同的票据（因为它们尚未被作废）。 这意味着用户每个区块每个合约只能进行 1 笔交易（对于需要访问票据的交易）。 这类似于基于 Cardano 构建的 DEX 所流行的问题，如果天真地实现，每个区块只能允许每个池进行 1 次交换（因为池中的 UTXO 可以被另一笔交易使用，因此池中的所有其他交易都会失败，因为原始 UTXO 现已被销毁）。
这很糟糕，并且是一个根本性的挑战，不仅是 Aztec 的可扩展性，而且是所有尝试利用可编程 UTXO 的区块链都需要解决的挑战。
我们目前正在做什么？
有一个 PR 可以在任意偏移处获取可变数量的音符（感谢 Leila！）。 这在诸如我知道我的前两张票据卡在待处理交易中的情况下很有用。 然后，当我为下一个交易获取另外两个注释时，我只需传递两个偏移量。 现在我得到了两张不同的票据，我可以并行使用它们（使 4 个票据处于待处理状态）。
一种解决方案是由 Aztec RPC Server 进行偏移计算。 另一种选择是让 dapp 开发者拥有自己的特定于他们的应用程序的算法（这需要对 UTXO 进行深入的了解，并对如何使用他们的 dapp 进行大量建模）。 我个人认为前者（RPC Server 进行偏移计算）更好，因为它提供了更简单的开发方式。
RPC 服务器可以通过以下方式进行计算——典型的事务将获取笔记然后使用它们。 这会在 Noir 上调用“compute_nullifier()”，它会获取用户的密钥并通过对 RPC 服务器的 oracle 调用来计算 nullifer。 每次调用此方法时，节点都可以告诉 RPC 服务器移动偏移量（对此想法请向 @jaosef 表示感谢）。
关于【Aztec：私有状态的 UTXO 并发问题】的延伸阅读
比特币生态的 Pendle？一文读懂 Master Protocol
Master Protocol是比特币生态中的新兴利率互换市场和积分Farm加速器，旨在解决比特币可编程性的挑战。它的价值在于为比特币生态的Wrap生息资产定价，目前处于测试网阶段，支持Botanix的mpBTC和Bouncebit的stBBTC。Master Protocol团队正在与Babylon和Bouncebit谈判合作，并计划在6月上线主网版本。它也是比特币生态的LST和Restaking协议的重要组成部分。
探索自治世界：数字物理法则和自然可组合性
本文总结了笔者在AW/FOCG领域实践的经验和思考，包括自治世界的起源、定义和现状，自治世界与全链游戏的关系，以及最具原语性的自治世界PixeLAW及其Solidity实现。还分享了智能合约的可组合性和互操作性。详细内容可在链接中查看。
这假设每次调用compute_nullifier() 时，都会删除注释。 有没有什么情况你会调用这个方法来不使无效？
可是等等！ 还有更多！
上述解决方案并不能完全解决问题。
**假设用户在多个设备上拥有钱包（读取其 rpc 服务器/模拟器的实例）。**他们从一台设备进行交易，但交易仍处于待处理状态。 如果您现在转到另一个设备在同一个合约上进行另一笔交易（如今天所实施的那样），它将最终获取相同的注释（因为偏移量仅在第一个设备上本地更正）并且内核证明将正确构建 。 当然，当通过我们的汇总电路发送时，事务将恢复，但这是糟糕的用户体验。
以太坊也存在这个问题，但由于 Aztec 拥有长达 10 分钟的出块时间，这可能导致 20 分钟的协调时间（最坏情况），而以太坊理论上可以提供 20-30 秒的时间。 因此，有更多的动力来确保阿兹特克人做到这一点。 等待 10 多分钟才发现您的交易正在恢复，这可能会非常令人沮丧。
未解答的问题
- dapp 开发人员如何在运行时通过算法确定将用户（或合约）余额分割成的最佳票据数量？
待定承诺允许用户有效地将大笔记分割成多个较小的笔记或将多个小笔记合并成一个大笔记。 但是如何确定如何拆分/合并它们呢？ 假设一份合约有 1 张价值 10 ETH 的票据。 假设我想从中取出 1 eth，而 Jake 想要取出 2 eth。 这两项交易都是私下进行的，即在用户设备本地进行。 我会将合约的 utxo 分别拆分为两个值 1 eth 和 9 eth，而 Jake 会将其拆分为 8 和 2。当然，只有一笔交易成功（比如我的），但现在 Jake 失败了，即使合约有足够的资金来处理 我们双方的交易！
优秀的 dapp 开发人员需要创建算法来确定如何存储用户的余额以及合约池。 大多数基于 UTXO 的 DEX 都使用链下聚合器将所有交易合并为一个（有自己的代币经济模型）。 参考资料 1
更多相关问题：
- 关于 dapp 开发人员如何以编程方式计算出要获取用户的多少笔记的良好算法设计？
- …或者何时分割/合并笔记？
- ...或者如何确定正确的偏移量？
一个简单的答案是在你的黑色智能合约中拥有一个不受约束的函数，它可以获取用户的多个注释，并让 dapp 开发人员以这种方式确定它。 不知道如何保护隐私……
DevRel 的最后一点说明
- 我们还需要做好提供文档和示例的工作，证明如果简单地处理 UTXO 并发问题会对用户体验产生负面影响。
感谢 @cooper-aztecLabs 和 @suyash67 的反馈！
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：rahul-kothari，如有侵权请联系删除。转载或引用请注明文章出处！
