Unirep是什么? 怎么用?UniRep 是一个使用零知识证明(Zero-knowledge Proof)而达到具有隐私保障的评价 (reputation) 系统。使用者有权利享有多个暂时性的身份，但又同时能提出证明，让其他人可以验证评价是否符合自己宣称的数量。此外，使用者也无法拒绝接收对自己不利的评价。

想像一个情境：如果Alice是Airbnb的使用者，Alice常常透过Airbnb租房，且Alice曾经获得获得许多Airbnb房东的好评；有一天Alice想透过Booking.com订房，但Alice是第一次使用Booking.com，所以在Booking.com上没有任何评价，万一Booking.com的房东不想把房子租给来路不明的客人，那Alice要如何向Booking.com的房东证明她其实都是用Airbnb租房，且获得许多好评？

Alice虽然可以透过截图或公开自己的资讯向Booking.com的房东证明自己拥有这些好评，但这样Alice的隐私或许会被泄漏，例如Alice不想让Booking.com的房东知道自己去过哪些地方、住过哪些民宿；或者Alice有可能伪造截图，或者伪造评价，那Booking.com的房东要如何相信Alice所提供的证明文件是真的来自Airbnb的房东？除此之外有没有更弹性的方式，Alice可以选择性地向Booking.com的房东证明，自己至少有10个好评，但不透露自己总共有多少好评？

使用Unirep协定就可以解决这个问题。UniRep 取名自 Universal Reputation，希望透过区块链上智能合约的可互用性 (interoperable，指智能合约容易被多方呼叫且容易透过智能合约与对方互动)，让不管是Airbnb的房东、Booking.com的房东或是Alice都能很容易地透过Unirep的智能合约与对方互动，且透过零知识证明的方式，让Alice的评价具有隐私的保障，Alice不用明确地向Booking.com的房东说这些评价是怎麽获得、是什麽时候获得，也可以弹性的证明自己至少有多少好评，或者最多有多少差评。

密码学

Unirep主要用到的密码学方法有

• 哈希函数hash：若有一个哈希函数 f(x) = y 则由x可以很轻易的用f算出y，但从y推回x是几乎不可能的，且要找到两个不同的x对应到相同的y也是几乎不可能的(没有碰撞问题)。
• 零知识证明zero-knowledge proof：可以将複杂的运算逻辑转成容易验证且具有隐私保障的验证问题，使用者只要将变数输入，这个零知识证明的演算法就会产生对应的证明且计算出对应的结果，使用者只要将此证明和运算结果输入验证的程序中，其他人就能验证使用者是不是提出正确的证明，若验证成功，则验证者就能相信提出证明者高机率拥有正确的知识，也就是在计算证明时的输入变数。

• Semaphore：semaphore 是设计为可以用零知识证明验证的身份认证系统。Unirep 中用来产生私钥 (identity) 和公钥的 hash 值(identity commitment)，让使用者不必公开 identity 仍能透过零知识证明验证其公私钥的对应性。
• 哈希树Merkle trees：Unirep 中大量运用哈希树的方式确保评价纪录，而其中用到的哈希树又分两种：Incremental merkle tree 和 Sparse merkle tree

1. Incremental merkle tree：从 index 0 开始依序插入哈希树中的树叶。为了使 ZKP 的 circuit 大小固定， Unirep 中使用固定高度的 Incremental merkle tree。
2. Sparse merkle tree：在特定的 index i 插入树叶

UniRep中用到的名词定义

Epoch

• 指一段特定的时间，例如7天
• UniRep 的Epoch 从1 开始计算，7天过后Epoch数加一，即Epoch 变为 2

Epoch Key

• 每个使用者在每个Epoch 都能产生n 把Epoch key，用来收取评价 epoch_key = hash (id, epoch, nonce)
• id: 这里指用semaphore 产生的identity
• epoch: 表示这是在第几个epoch 产生的epoch key
• nonce: 若Unirep 规定使用者能在一个epoch 产生5 把epoch key，则使用者可以选从0 到4 为此nonce
• 因为哈希函数的性质，算出来的epoch key 很难推回原本的id, epoch, nonce， 所以看到epoch key 并不能推回使用者是谁。

以Alice为例，当Alice住完Airbnb，房东会透过epoch key 给予Alice 评价，但房东无法知道Alice 在同个epoch 的其他epoch key 是哪一把，也无法知道Alice 在别的epoch 获得的评价，除非Alice 在这个epoch 重复使用同一把epoch key 收取评价。

User 使用者

• 用semaphore 产生identity 并使用此identity 注册的使用者
• 使用者是接收评价、证明评价、或是花费评价的人，用 epoch key 跟其他人互动，因为 epoch key 会随著 epoch 增加而改变，所以对使用者来说每个 epoch 能产生的 epoch key 都不同，具有保护隐私的效果。

在上面的例子中使用者指的是Alice, Bob, Airbnb 的房东, Booking.com的房东

Attester 证人

• 用Ethereum address 或smart contract address 注册的用户
• 是会被使用者记录下来的评价给予者
• Unirep 会给这些address 一个attester ID，而这个attester ID 不会随着epoch 增加而改变，使用者可以知道这个评价是来自哪一个attester。

在上面的例子中指的是Airbnb 跟Booking.com，因为attester ID 不变，所以使用者可以证明这些评价是来自于Airbnb 或是Booking.com

User State Tree (UST)

• 是一Sparse merkle tree
• 每个使用者都有自己的User State Tree，其中树叶表示所收到的评价的hash值，而叶子的 index 表示 attester ID，UST 树叶的定义为：USTLeaf = hash(posRep, negRep, graffiti)

例如Airbnb 的ID 是1，Booking.com 的ID 是3，那Alice 的User State Tree 中index 为1 的地方会有自己在Airbnb 获得的总评价的hash 值，而index 为三的地方则为空的评价。另一个使用者Bob 的User State Tree 亦同，在index 为1 的地方会有自己在Airbnb 获得的评价，在index 为3 的地方会有自己在Booking.com的评价。

Global State Tree (GST)

• 是一固定树高的Incremental merkle tree
• Global State Tree 的叶子到树根都是公开的资讯，当有使用者注册或者更新 User State Tree 时会在 Global State Tree 裡新增一个新的树叶，GST 树叶的定义为：GSTLeaf = hash(id, USTRoot)

• 先送出的树叶先插入到较前面的index，之后的树叶依序插入GST 中。

以Alice的例子来说，当Alice跟Bob注册Unirep时，都会产生一个GST的树叶，更新GST的树根，若Alice先注册，则Alice的index会较Bob前面。注意，这边的Airbnb 和Booking.com 等attester 并不是用这棵Global State Tree注册。

Epoch Tree

• 是一个Sparse merkle tree
• Epoch Tree 跟Global State Tree 一样从叶子到树根都是公开的资讯，Epoch Tree 中树叶的index 为epoch key，而树叶的值为该epoch key 的sealed hash chain
• 每个epoch key 都有一个hash chain，hash chain 的定义为

hashedReputation = hash(attestIdx, attesterID, posRep, negRep graffiti)
hashChain[epochKey] = hash(hashedReputation, hashChain[epochKey])

• 此 hash chain 是为了防止使用者漏收了哪一笔评价，如果使用者少收了其中一笔评价，则 hash chain 的结果会完全不同。最后验证时如果其中一个 epoch key 的 hash chain 改变，会造成 epoch tree 树根跟原本的 epoch tree 的树根不同。
• 而Sealed hash chain 是在每个epoch 结束后，Unirep 智能合约会再将这条hash chain 再hash 一次

sealedHashChain[epochKey] = hash(1, hashChain[epochKey]) isEpochKeyHashChainSealed[epochKey] = true

• 需要再把这条hash chain 封起来的用意是，避免这把epoch key 过了这个epoch 之后再继续接收评价，所以epoch tree 会用这个epoch key 最后的sealed hash chain 去计算树根。

Nullifier

• 中文翻译为注销符，当我们要防止一件事情重複发生时，就可以使用这个 Nullifier
• Unirep 中使用到Epoch key nullifier：此nullifier 是用来限制使用者不能在不同的epoch 使用重复的epoch key 去收取评价，也不能被其他使用者使用；此外也可以用来检视使用者是否重复执行UST 的更新
• Nullifier 也用hash 计算，但多使用一个domain 变数，避免与epoch key 产生相同的nullifier 而泄露自己拥有的epoch key，也可以用不同的domain 产生不同用途的nullifier

epochKeyNullifier = hash(EPOCH_KEY_DOMAIN, id, epoch, nonce)

Epoch Transition

• 一个epoch 结束过后，要透过epoch transition 的步骤，更新Unirep 及使用者的状态
• 其中要做的事包含将智能合约上的epoch 数加一，还有将所有epoch key 的hash chain 封起来
• 接着使用者就可以执行User State Transition 更新自己的UST

User State Transition

• 到下一个epoch 后，使用者可以透过自己的identity，找出自己在前一个epoch 所有的epoch key，并根据每把epoch key 收到的评价更新到自己的UST，最后计算出最新的评价状态，产生一个 GST的树叶，插入 GST 中 (如同注册时一样)。
• 使用者之后如果要花费评价或者产生下一个epoch 的epoch key 时，因为必须确认自己的UST 在当前的epoch，所以需要经过User State Transition 确保自己有一个GST 的树叶在GST 中。

Unirep 协定

有了Unirep 的名词定义后，接着介绍Unirep 是如何运作的。

注册

Unirep 的user 和attester 的注册方式不同：

User

• User 透过semaphore 产生identity 和identity commitment，identity 就如同私钥，identity commitment 就如同公钥

1. 将identity commitment 和预设的UST 树根经由hash 计算得GST 的一个树叶
2. 若使用者要证明自己在某个epoch 有注册或者有更新自己的UST，则证明自己是GST 的某一个树叶，利用零知识证明的方法，输入identity、UST 树根，还有merkle tree 中要计算hash 值的相邻节点，则最后可得到一个GST 的root，其他人可以验证这个GST 的root 是否符合这颗公开的GST。

Attester

• Attester 则是用自己的钱包，或者用智能合约的地址注册，呼叫attester sign up 的function 后，Unirep 会指定一个attester ID 给这个地址，往后attester 用相同钱包或合约地址给予评价时，Unirep 会检查此地址是否被注册，若有注册则可以给予epoch key 评价。

以Alice 和Bob 为例，Alice、Bob、Airbnb的房东、Booking.com的房东会产生identity 并且透过Unirep 合约用user 的注册方式获得一个GST 的树叶代表自己；而 Airbnb 和 Booking.com 会透过 attester 的注册方式，使用特定的钱包地址或是撰写智能合约呼叫 Unirep 的 attester sign up function。当然Alice 或Bob 如果想用自己的钱包注册为attester 也是可以，这时合约就会纪录Alice 和Bob 的钱包地址，并给予一个新的attester ID。

给予评价

在Unirep 中评价的接收者是epoch key，接着介绍user 和attester 是如何互动。

• Alice 在Unirep 注册过后，就可以产生epoch key 接收评价

epochKey = hash(identity, epoch, nonce)

• 但Airbnb 的房东看到这把epoch key，要如何知道Alice 确实是Unirep 的合法使用者，且epoch key 的是合法的，例如nonce 小于5，或者epoch 是当前的epoch？
• 如果Alice 直接提供epoch 和nonce，别人没有identity 也无法计算此epoch key，更不用说如果Alice 提供identity 会造成Alice 完全没有隐私可言，所有人都可以计算出Alice 收过哪些评价。
• 因此我们用一个零知识证明，证明此 epoch key 是合法的。细节请参考 epoch key proof，主要是证明使用者有一个合法的 GST 树叶在 GST 中，并且 epoch 和 nonce 也都符合。

房东得到Alice 提供的epoch key 和epoch key 的证明，并且透过Unirep 的合约验证通过之后，就可以给予评价。

• 获得空投评价、使用者可以给予评价的限制(例如必须消耗自己的正评才能给予其他人评价) 可以由各个应用自行定义，例如Airbnb 可以决定空投30 个正评给使用者， Booking.com 可以决定空投20 个正评给使用者。
• 另外，为了确认房东也是合法的使用者，也为了防止房东重复花费(double spending) 自己的评价点数，Unirep 上的应用也可以用reputation nullifier 及其proof 去证明使用者合法使用自己的评价。
• 例如，此reputation nullifier 可以用下列计算方式取得：

reputationNullifier = hash(REPUTATION_DOMAIN, id, epoch, nonce)

• 当reputation nullifier 及proof 产生后，就会与房东要给的评价一起发送到Airbnb 的智能合约上，智能合约会验证proof 是否合法，nullifier 是否有被发送过，若检查都通过的话则Unirep 会纪录此评价给epoch key，并将hash chain 更新。

接收评价

使用者即使可以证明自己拥有哪一把epoch key 并且大家都知道这把epoch key 有多少评价，但这有可能造成使用者故意忽略其他把epoch key 中对自己不好的评价，因此Unirep 限制使用者只能在每个 epoch 结束，每把 epoch key 都封起来之后，才能用 User State Transition 更新自己的评价。

这里也是用 User State Transition Proof 去保证使用者是根据正确的方式计算出最新的 UST，且用 epoch tree 限制使用者必须处理每一把 epoch key 的结果。

亦即，需要等到epoch 结束后，Alice 才能透过User State Transition 获得Airbnb 房东的评价，更新自己的使用者状态。

证明评价

当使用者通过 User State Transition 之后会有最新的 UST 状态，此时 Alice 就可以透过 reputation proof 向 Booking.com 宣称她有来自 Airbnb 的评价，在reputation proof 中检查使用者是否有其宣称的 UST (例如总共有多少好评、多少差评来自哪一个 attester ID)，并且此 UST 的状态储存在当前 epoch 的 GST 中。

在生成reputation proof 时，即使Alice 总共有100 个好评，但Alice 仍可以产生「至少有10个好评」的证明，Booking.com 的房东若验证成功，则只能知道Alice 宣称的「至少有10 个好评」而不能知道Alice 总共有100 个好评。

常见问题

Alice 能不能给Airbnb 的房东评价？Alice 能不能给Bob 评价？

可以。

Airbnb 的房东和Bob 也都能产生epoch key，因此如果Alice 有两者的epoch key 及合法的proof 则可以给予评价。此时Alice 可以选择透过Airbnb、Booking.com、或什至自己的Ethereum account 当作证人给予评价(也必须选择一个证人)。

Alice 可以透过Unirep 给Airbnb 评价吗？

如果Airbnb 也透过Unirep 注册为使用者，并且产生epoch key 的话就可以。但如果Airbnb 只注册为证人的话不行。

Alice 可以证明评价来自哪一个Airbnb 房东吗？

如果Airbnb 的房东没有注册为证人，则Alice 不能证明评价来自哪个房东。

若Airbnb 的房东用自己的Ethereum account 注册为证人，则Alice 只能证明评价来自这个Ethereum account，但无法知道这个account 是一个Airbnb 的房东。

从Airbnb 获得的评价可以在Booking.com 花费吗？

需看Booking.com 的智能合约如何定义，但一般来说不行，因为attester ID不同，但未来可能会开发各个应用程序之间的兑换评价功能。

如果迟迟不执行User State Transition 会发生什么事？会不会收不到之前的评价？

若Alice 在第一个epoch 注册，并在第一个epoch 产生epoch key 接收评价，但Alice 到第五个epoch 才执行User State Transition，那Alice 会根据第一个epoch 的GST、epoch tree 执行User State Transition，因此仍然可以在第五个epoch 收到来自第一个epoch 的评价；而在第二到第四个epoch 因为Alice 无法产生出合法的epoch key proof，因此无法接收评价。

User State Transition 可以自动执行吗？

不行。

只有使用者主动给出私钥，即semaphore 的identity，才可以产生合法的User State Transition proof，若将私钥交给第三方帮忙执行可能会侵害使用者的隐私。

结论

Unirep 是一个具有隐私保障的评价系统，透过ZKP 的保护使用者可以在匿名的情况下收取评价、给予评价、并且向他人证明自己的评价。Unirep 可以用于跨应用程序间的评价证明，可以在A 应用程序中获得评价，并向B 应用程序证明在A 应用程序中获得多少评价。

本文链接地址：https://www.wwsww.cn/qkl/10359.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。