1. CoinON官网首页
  2. 新闻
  3. 头条

Aztec：私有状态的 UTXO 并发问题

Bob鲍师傅 • • 头条 • 阅读 514 
原文标题：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 表示感谢）。

这假设每次调用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 的反馈！

转载声明：本文 由CoinON抓取收录，观点仅代表作者本人，不代表CoinON资讯立场，CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据，请自行承担全部责任。

声明：图文来源于网络，如有侵权请联系删除

风险提示：投资有风险，入市需谨慎。本资讯不作为投资理财建议。

赞 (0)
打赏 微信扫一扫 微信扫一扫
Bob鲍师傅Bob鲍师傅
0
上一篇 2023年7月6日 下午10:32
下一篇 2023年7月7日 下午1:32

相关推荐

Aztec：私有状态的 UTXO 并发问题

星期五 2023-07-07 13:32:05

注意 – “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 表示感谢）。

这假设每次调用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 的反馈！

主页
快讯
精选
电报