🥑原文： Toward Achieving Anonymous NFT Trading
🥑吐槽： 这论文怎么老有描述不清、前后不一致的地方😇

正文

在本节中，我们将具体展示我们方案的构建。我们将基于一个示例来描述我们方案的工作流程，该示例中 Alice 是 NFT的所有者，而 Bob 想要购买它。交易是通过采用我们提出的方案的市场进行的。

该论文的创新点就是对 NFT 市场的交易流程进行了修改。

我们还假设所有链下的通信都是通过端到端的安全通道进行的，以抵御监听攻击。此外，市场选择了一个有限椭圆曲线域上的群 $G$，该域的阶为 $q$，两个生成元 $G$ 和 $H$，以及一个抗碰撞哈希函数 $h()$，并将这些作为公共参数发布。

下图展示了我们方案的框架：

其中，NFT 的转移是通过智能合约执行的，而 ETH 的支付则是通过市场控制的假账户进行的。

下图展示了我们方案是如何工作的：

请注意，仅卖方需要代理服务，并且卖方与代理之间不存在直接交互。

A 代理的注册

在我们的方案中，区块链上部署的 代理注册合约 负责新代理的注册，它还用于记录代理和对应所有者之间的映射关系，这点与 Wyvern 协议相同。

在后文中，代理注册合约又被简称为注册表😇

在 Wyvern 协议中，是通过用户和注册表的直接交互来注册代理的。而在我们的方案中，是通过市场和注册表的交互来注册代理的。接下来，我们将具体介绍注册一个代理的流程。

首先，每个用户通过以太坊的密钥生成算法生成一个新的密钥对 $(p{k}_t,s{k}_t)$，称为 临时密钥。$s{k}_t$ 是需要保密的私钥，而公钥 $p{k}_t$ 用于生成临时地址 $add{r}_t$。到时候，市场将使用临时地址为用户创建一个新的代理。注意：临时密钥对的格式与区块链密钥对的相同。但是，用户只应该在 NFT 交易中使用它，而不应该用于其他场合。

公钥 $p{k}_t$ 用于生成临时地址 $add{r}_t$？

接着，假设 $U$ 表示所有区块链用户，$T$ 表示所有临时地址 $add{r}_t$，那么市场记录了用户和临时地址之间的映射关系 $UT\subseteq U\times T$。关系 $UT$ 由 市场的数据库 保密保存，意味着用户和临时地址之间的映射关系仅被市场和临时地址的所有者本人所知。

随后，市场将调用注册表的函数，以创建一个新的代理。在此过程中，市场传入的是临时地址，而非所有者的真实地址。由此一来，新代理所有者的地址将被记录为临时地址 $add{r}_t$。通过这种方式，代理与所有者之间的关系将由对一个临时密钥的知识来维持。

简而言之，为了不暴露真实的所有者地址，要求一个由临时密钥对生成的临时地址来充当所有者地址。

B NFT 所有权

使用 关于所有者地址的承诺 来将 NFT 的所有权绑定到某个用户。

假设 NFT M 的所有者是 Alice，且她的地址为 $add{r}_1$。生成承诺的流程如下：

首先，给定一个阶为 $p$ 的公共组 $(G,\cdot )$，市场随机选择两个生成元 $g$ 和 $h=g^{\alpha }$，并将 $(G,g,h,p)$ 作为公共参数发布，其中 $\alpha$ 作为秘密保存。

接着，Alice 随机选择一个秘密值 $r_1\in Z_p$ 并计算：

$$C_{Alice}=g^{add{r}_1}{h}^{r_1}$$

在非匿名模式下，NFT 合约存储了一个包含相应所有者地址的 代币 ID 列表。在匿名模式下，代币 ID 列表 中存储的是 $C_{Alice}$，以表示 M 的所有者存在但保持身份隐藏。

简而言之，使用 Pedersen 承诺为 Alice 的真实地址 $add{r}_1$ 生成一个承诺值 $C_{Alice}$。将承诺值保存在 NFT 的 ID 列表中，既能隐藏所有者的地址，又能在揭示阶段证明所有者的身份。

C 订单生成

订单生成始于链下。

1 卖方 + 销售订单

对于卖方 Alice，她将生成一个 销售订单。该订单包括如下信息：

• 目标 NFT 的 ID
• 价格
• 上架时间
• 到期时间
• calldata
• 用于承诺的知识证明

上述信息都将由 Alice 的临时私钥 $s{k}_{t,Alice}$ 进行签名。

用于承诺的知识证明的生成过程如下：

1. $x,y\leftarrow Z_q$
2. $P=xG+yH$
3. $t\leftarrow h(order)$
4. $x^{\prime }=x+tm$，$y^{\prime }=y+tr$
5. $Proof=(P,x^{\prime },y^{\prime })$

$Proof$ 是在承诺的揭示阶段使用的，这里只是在讲它是如何生成的，和上文没有太大联系。

接着，Alice 通过一个安全的端到端通道将销售订单提交给市场。市场接收到销售订单后，将继续完善这笔销售订单，如下表所示。最后，市场将销售订单提交给交换协议。

市场在 Alice 填写的销售订单的基础上，增加了 Alice 的临时公钥、注册表和 Alice 对应的代理。

2 买方 + 购买订单

对于买方 Bob，他首先与市场的前端通信，以获得假账户的地址。在向市场提交购买订单之前，Bob 必须将足够的 ETH 转账到这个假账户。

Bob 将生成一个 购买订单。该订单包括如下信息：

• 目标 NFT 的 ID
• 出价
• 上架时间
• 到期时间
• 关于 Bob 地址的承诺

上述信息都将由 Bob 的临时私钥 $s{k}_{t,Bob}$ 进行签名。

比起 Alice 少了 calldata 这一信息。

原文把 关于 Bob 地址的承诺 写错了，我改成了：

$$C_{Bob}=g^{add{r}_2}{h}^{r_2}$$

请注意，我们不要求 Alice 和 Bob 同时向市场的提交订单，Bob 也可以提前提交购买订单。

接着，Bob 通过一个安全的端到端通道将购买订单提交给市场。在接收到 Bob 的购买订单后，市场首先会检查 Bob 是否已经将足够的 ETH 转入了指定的假账户。然后，市场也会完善购买订单，如下表所示。

市场在 Bob 填写的购买订单的基础上，增加了 Bob 的临时公钥。

最终，两个订单都会存储在市场的链下数据库中，等待上传到交换协议。

D 给代理授权

除了生成订单之外，Alice 还生成了另一条带有她签名的消息，以授权代理访问目标 NFT 。为此，Alice 生成了关于订单的消息，并使用临时私钥对其进行签名：

$$\begin{array}{rl}{m}_{au}& ="AUTH"||targetNFT||timestamp\\ si{g}_{au}& =sign(m_{au},s{k}_{t,Alice})\end{array}$$

貌似 Alice 就只会告诉代理目标 NFT 的 ID 是什么😇

具体来说，Alice 首先通过链下通道将 $(m_{au},si{g}_{au})$ 发送给市场。然后，市场通过调用相关函数将其转发给注册表。

Alice 是通过临时地址才和代理联系起来的，而这个映射关系又是由市场数据库保存的。因此，市场不仅需要告诉注册表 $(m_{au},si{g}_{au})$ 是什么，还要告诉注册表 Alice 的代理是谁。否则，注册表怎么知道 Alice 的代理是哪个。

注册表在收到消息 $m_{au}$ 和签名 $si{g}_{au}$ 后，首先检查时间戳是否有效，接着验证签名 $si{g}_{au}$。如果验证通过，那么注册表将添加 Alice 对应的代理和目标 NFT 到列表中。该列表用于存储所有被委托的代理和它们的目标 NFT 。

为了检验消息是否被篡改，在发送消息的时候都会附上一个数字签名。

E 交换

如果根据目标 NFT 的 ID、价格等条件匹配到了两个订单，那么市场就会将 销售订单、卖家签名、购买订单、买家签名 打成一个捆绑包，并提交给交换协议。

匹配这一工作不是交换协议在做的吗？怎么市场也来掺一脚？

交换协议收到这个捆绑包后，将按以下步骤进行处理：

1. 通过比较目标 NFT 的 ID、价格和出价、有效期来检查两个订单是否匹配。
2. 锁定目标 NFT 的交易状态。
3. 验证卖方签名、买方签名的有效性。
4. 验证卖方提供的证明。
5. 检查卖方的代理是否已被认证。
6. 如果上述任何步骤失败，交易阶段将中止并发出错误信息。如果所有上述步骤都成功，交换协议将检查卖方是否认证了代理。如果是，它将调用卖方代理并传入 calldata 参数以执行。
7. 代理执行 calldata，并将目标 NFT 的所有权字段替换为 $C_{Bob}$。然后作为交易收据发出此次交易完成的事件。

太离谱了，明明说了买方不使用代理，原文却在第 5 步说要检查买方的代理是否被认证😇

算法 1 展示了定义在交换协议中的交换函数：

Upon receiving(Order1, Order2):Assert message.sender = marketplace  // 验证消息发送者是否是市场Assert Order1.target = Order2.target  // 验证目标NFT是否一致Assert Order2.bid >= Order1.price  // 验证出价是否大于等于价格Assert t > listing.time || expiration.time > t  // 验证时间戳是否处于有效期内Lock(Order1.target)  // 锁定目标NFTVerify(Order1.sig)  // 验证卖家签名Verify(Order2.sig)  // 验证买家签名Assert VerifyProof(Order1.proof) = 1  // 验证卖家证明Assert Registry[proxy] = approved  // 验证代理是否已被认证r = Call(proxy, Order1.calldata, Order2.commit)Unlock(Order1.target)  // 解锁目标NFTReturn r and emit event

代理的过程在算法 2 中展示：

Upon receiving(calldata, commit):Verify(calldata.sig, pkt)calldata.receiver = commitr = Proxy(calldata)Return r

说明：

• 参数：order1 的 calldata、order2 的 commit
• 第一步：检验？？
• 第二步：将 calldata 的接受者设置为关于 Bob 地址的承诺
• 第三步：进行 NFT 所有权的转移

其中，Proxy() 是由 Wyvern 库定义的，以允许代理执行 Alice 创建的所有权转移命令。在检测到完成事件后，市场使用假账户向 Alice 支付以太币，作为出售 NFT 的收入。

什么是 Alice 创建的所有权转移命令？答：Alice 销售订单里写的 calldata 定义了所有权转移命令。