🥑原文： Toward Achieving Anonymous NFT Trading
🥑吐槽： 这论文怎么老有描述不清、前后不一致的地方😇
正文
在本节中，我们将具体展示我们方案的构建。我们将基于一个示例来描述我们方案的工作流程，该示例中的 Alice 是 NFT 的所有者，而 Bob 想要购买它。交易是通过采用我们提出的方案的市场进行的。
该论文的创新点就是对 NFT 市场的交易细节进行了修改。
我们还假设所有链下的通信都是通过端到端的安全通道进行的，以抵御监听攻击。此外，市场选择了一个有限椭圆曲线域上的群 G G G，该域的阶为 q q q，两个生成元 G G G 和 H H H，以及一个抗碰撞的哈希函数 h ( ) h() h()，并将这些作为公共参数发布。
下图展示了我们方案的框架：
其中，NFT 所有权的转移是通过「Exchange Protocol，交易所协议」这一智能合约执行的，而 ETH 的支付则是通过市场控制的「Decoy Account，假账户」进行的。
本文中提到的加密货币、以太币都指的是 ETH😇
下图展示了我们方案是如何工作的：
图中名词的含义：
- server 是指市场的服务器，后文简称市场
- decoy 是指假账户
- proxy 是指代理注册合约，或称注册表
- smart contract 是指交易所协议
注意：只有卖家需要使用「代理」提供的 NFT 所有权转移服务，因为只有卖方拥有 NFT 的所有权。值得强调的是，卖家与「代理」之间不存在直接交互，而是依靠市场这一中介进行交互的。
A 代理的注册
异同之处
在我们的方案中，区块链上部署的「Proxy Registry Contract，代理注册合约」负责新「代理」的注册，它还记录了「代理」及其所有者之间的映射关系，这点与 Wyvern 协议相同。
个人理解：「代理」本质上就是一个智能合约的实例，它也是有地址的。
区别在于，在 Wyvern 协议中，用户通过与「Registry，注册表」的直接交互来注册「代理」。而在我们的方案中，用户借助市场和「注册表」的交互来注册「代理」。
代理注册合约和注册表应该就是同一个东西😇
注意：每个 OpenSea 的用户都会注册一个「代理」，因为每个用户都有可能成为卖家。只是在一笔交易中，只有卖家会使用到「代理」的 NFT 所有权转移服务罢了。
具体流程
接下来，我们将具体介绍注册一个「代理」的流程。
首先，每个用户通过以太坊的密钥生成算法生成一个新的密钥对 ( p k t , s k t ) (pk_t,sk_t) (pkt,skt)，称为 临时密钥。 s k t sk_t skt 是需要保密的私钥，而公钥 p k t pk_t pkt 用于生成临时地址 a d d r t addr_t addrt。到时候，市场将使用临时地址为用户创建一个新的「代理」。注意：临时密钥的格式与区块链密钥对的相同。但是，用户只应该在 NFT 交易中使用它，而不应该用于其他场合。
公钥 p k t pk_t pkt 用于生成临时地址 a d d r t addr_t addrt？
假设 U U U 代表所有的区块链用户， T T T 代表所有的临时地址 a d d r t addr_t addrt，那么市场记录了用户和临时地址之间的映射关系 U T ⊆ U × T UT ⊆ U × T UT⊆U×T。关系 U T UT UT 由「Marketplace DB，市场数据库」保密保存，意味着用户和临时地址之间的映射关系仅被市场和临时地址的所有者本人所知。
市场记录的映射关系是：所有者地址 × 临时地址、临时地址 × 代理、所有者地址 × 代理
注册表记录的映射关系是：临时地址 × 代理
最后，市场将调用「注册表」的「Register Proxy，注册代理」函数，以创建一个新的「代理」。在此过程中，市场传入的是临时地址，而非所有者的真实地址。由此一来，新「代理」的所有者地址将被记录为临时地址 a d d r t addr_t addrt。通过这种方式，「代理」与它的所有者之间的关系将由对一个临时密钥的知识来维持。
简而言之，为了不暴露真实的所有者地址，使用一个由临时密钥对生成的临时地址来充当所有者地址。
B NFT 所有权
使用「a commitment to the owner’s addres，关于所有者地址的承诺」来将 NFT 的所有权绑定到某个用户身上。假设「NFT M」的所有者是 Alice，且她的地址为 a d d r 1 addr_1 addr1。
这里说的地址是所有者的真实地址，而非临时地址。
具体流程
首先，给定一个阶为 p p p 的公共组 ( G , ⋅ ) (G,\ ·) (G, ⋅)，市场随机选择两个生成元 g g g 和 h = g α h = g^α h=gα，并将 ( G , g , h , p ) (G, g, h, p) (G,g,h,p) 作为公共参数发布，其中 α α α 作为秘密保存。
然后，Alice 随机选择一个秘密值 r 1 ∈ Z p r_1 ∈ Z_p r1∈Zp 并计算：
C A l i c e = g a d d r 1 h r 1 C_{Alice} = g^{addr_1}h^{r_1} CAlice=gaddr1hr1
最后，每个 NFT 合约中都存储着「a list of token IDs，一个代币 ID 列表」，其中包含了每个代币的 ID 及其所有者的地址。在非匿名模式下，列表中存储的是所有者的真实地址。在匿名模式下，列表中存储的是「关于所有者地址的承诺」。比如「NFT M」对应的所有者地址就应该是 C A l i c e C_{Alice} CAlice，以表示 M 的所有者存在但保持身份隐藏。
简而言之，使用 Pedersen 承诺为 Alice 的真实地址 a d d r 1 addr_1 addr1 生成一个承诺值 C A l i c e C_{Alice} CAlice。将承诺值保存在 NFT 的代币 ID 列表中，既能隐藏所有者的地址，又能在揭示阶段证明所有者的身份。
C 订单生成
🥕订单的生成发生在链下。
C-1 卖方 & 出售订单
对于卖方 Alice，她将生成一个「出售订单」，该订单包括如下信息：
- 目标 NFT 的 ID
- 售价
- 上架时间
- 到期时间
- calldata：用于调用 NFT 所有权转移函数
- 用于承诺的知识证明
上述信息都将由 Alice 的临时私钥 s k t , A l i c e sk_{t,Alice} skt,Alice 进行签名。
貌似是分别对各个信息进行签名，而不是把信息打包到一起再签名。
用于承诺的知识证明的生成过程如下：
- x , y ← Z q x, y ← Z_q x,y←Zq
- P = x G + y H P = xG + yH P=xG+yH
- t ← h ( o r d e r ) t ←h(order) t←h(order)
- x ′ = x + t m x' = x + tm x′=x+tm， y ′ = y + t r y' = y + tr y′=y+tr
- P r o o f = ( P , x ′ , y ′ ) Proof = (P, x', y') Proof=(P,x′,y′)
P r o o f Proof Proof 是在承诺的揭示阶段使用的，这里只是在讲它是如何生成的，和上文没有太大联系。
接着，Alice 通过一个安全的端到端通道将「出售订单」提交给市场。市场收到「出售订单」后，将继续完善这笔「出售订单」，如下表所示。最后，市场将「出售订单」提交给「交易所协议」。
市场在 Alice 填写的「出售订单」的基础上，增加了 Alice 的临时公钥、注册表和 Alice 对应的代理。可以看出，市场是知道所有者地址和代理之间的映射关系的。
C-2 买方 & 购买订单
对于买方 Bob，他首先与市场的前端通信，以获得「假账户」的地址。然后，Bob 必须将足够的 ETH —— 大于等于目标 NFT 的售价即可 —— 转账到这个「假账户」，否则前端的代码规则不会允许 Bob 提交「购买订单」。
我在 OpenSea 网站注册了一个账户后，显示我的账户地址为 0 x 399 f . . . 47 e c \mathrm{0x399f...47ec} 0x399f...47ec，这个不会就是传说中的「假账户」吧？账户里没有 ETH 就买不了 NFT，因此需要花现实中银行卡里的钱去买 ETH 。如下图所示：
Bob 将生成一个「购买订单」，该订单包括如下信息：
- 目标 NFT 的 ID
- 出价
- 上架时间
- 到期时间
- 关于 Bob 地址的承诺
上述信息都将由 Bob 的临时私钥 s k t , B o b sk_{t,Bob} skt,Bob 进行签名。
比起「出售订单」少了 calldata 这一信息，这是因为 NFT 所有权的转移只能由卖方发起。此外，由于在匿名模式下，NFT 的代币 ID 列表记录的是「关于所有者地址的承诺」，因此这里 Bob 给出了关于自己地址的承诺。
原文貌似把「关于 Bob 地址的承诺」写错了，因此我改成了：
C B o b = g a d d r 2 h r 2 C_{Bob} = g^{addr_2}h^{r_2} CBob=gaddr2hr2
请注意，我们不要求 Alice 和 Bob 同时向市场的提交订单，Bob 也可以提前提交「购买订单」。
接着，Bob 通过一个安全的端到端通道将「购买订单」提交给市场。在接收到 Bob 的「购买订单」后，市场首先会检查 Bob 是否已经将足够的 ETH 转入到了指定的「假账户」中。然后，市场会完善「购买订单」，如下表所示。
市场在 Bob 填写的「购买订单」的基础上，增加了 Bob 的临时公钥。
最终，「出售订单」和「购买订单」都会被市场存储在「市场数据库」中，等待上传到「交易所协议」中。
所以我就说这篇论文前后矛盾啦，明明 C-1 中没有说要存到「市场数据库」中。
D 给代理授权
除了生成一个「出售订单」并对其中的信息进行签名以外，Alice 还生成了一条带有她签名的消息，以授权「代理」访问目标 NFT 。为此，Alice 生成了一条关于订单的消息，并使用临时私钥对其签名：
m a u = " A U T H " ∣ ∣ t a r g e t N F T ∣ ∣ t i m e s t a m p s i g a u = s i g n ( m a u , s k t , A l i c e ) \begin{alignat}{2} m_{au} &= "AUTH"\ ||\ target\ NFT\ ||\ timestamp \\ sig_{au} &= sign(m_{au}, sk_{t,Alice}) \end{alignat} mausigau="AUTH" ∣∣ target NFT ∣∣ timestamp=sign(mau,skt,Alice)
貌似 Alice 就只会告诉「代理」目标 NFT 的 ID 是什么😇
具体来说，Alice 首先通过链下通道将 ( m a u , s i g a u ) (m_{au}, sig_{au}) (mau,sigau) 发送给市场。然后，市场通过调用相关函数将其转发给「注册表」。
市场还需要告诉「注册表」Alice 的代理是谁，否则「注册表」怎么知道 Alice 的「代理」是谁。
收到消息 m a u m_{au} mau 和签名 s i g a u sig_{au} sigau 后，「注册表」首先检查时间戳 t i m e s t a m p timestamp timestamp 是否有效，然后再验证签名 s i g a u sig_{au} sigau。如果验证通过，那么「注册表」将为对应的「代理」及其目标 NFT 生成一条新条目，并存储到一个列表当中。该表专门用于存储被委托的「代理」及其目标 NFT 。
验签的时候会使用到 Alice 的公钥啊，这个公钥也是市场帮忙发过去的吗？
E 交换
如果根据目标 NFT 的 ID、售价和出价等条件匹配到了一对「出售订单」和「购买订单」，那么市场就会将「出售订单、卖家签名、购买订单、买家签名」打成一个「捆绑包」，并提交给「交易所协议」。
匹配这一工作不是「交易所协议」在做的吗？怎么市场也来掺一脚？
「交易所协议」收到这个「捆绑包」后，将按以下步骤进行处理：
- 通过比较目标 NFT 的 ID、价格和出价、有效期来检查两个订单是否匹配。
- 锁定目标 NFT 的交易状态。
- 验证卖方签名、买方签名的有效性。
- 验证卖方提供的证明。
- 检查卖方的代理是否已被认证。
- 如果上述任何步骤失败，交易将立即中止并报错。如果上述所有步骤都成功，那么交易所协议将检查卖方是否认证了代理。如果是，它将调用卖方代理并传入 calldata 参数以执行。
- 代理执行 calldata，并将目标 NFT 的所有权字段替换为 C B o b C_{Bob} CBob，然后作为交易收据发出此次交易完成的事件。
太离谱了，明明说了买方不使用代理，原文却在第 5 步说要检查买方的代理是否被认证😇
算法 1 展示了定义在「交易所协议」中的「Exchange Function，交易函数」：
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) // 锁定目标NFT
Verify(Order1.sig) // 验证卖家签名
Verify(Order2.sig) // 验证买家签名
Assert VerifyProof(Order1.proof) = 1 // 验证卖家证明
Assert Registry[proxy] = approved // 验证代理是否已被认证
r = Call(proxy, Order1.calldata, Order2.commit)
Unlock(Order1.target) // 解锁目标NFT
Return r and emit event
代理的过程在算法 2 中展示：
Upon receiving(calldata, commit):
Verify(calldata.sig, pkt)
calldata.receiver = commit
r = Proxy(calldata)
Return r
函数说明：
- 参数：「出售订单」的 calldata、「购买订单」的 commit
- 第一步：使用 Alice 的临时公钥对 calldata 上的数字签名进行验证
- 第二步：将 calldata 的 NFT 所有权接收者设置为「关于 Bob 地址的承诺」
- 第三步：进行 NFT 所有权的转移
其中，Proxy() 是由 Wyvern 库定义的，以允许「代理」执行 Alice 创建的 NFT 所有权转移命令。在检测到完成事件后，市场使用「假账户」向 Alice 支付以太币，作为出售 NFT 的收入。文章来源：https://www.toymoban.com/news/detail-857868.html
什么是 Alice 创建的所有权转移命令？答：Alice 销售订单里写的 calldata 定义了所有权转移命令。文章来源地址https://www.toymoban.com/news/detail-857868.html
到了这里，关于区块链 | OpenSea 相关论文：Toward Achieving Anonymous NFT Trading（二）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
