您好!刚知道Zcash吗?
The Zcash network is young, but evolving quickly! Sign up and we'll be in touch with monthly highlights on ecosystem growth, network development and how to get started with Zcash!

语言

在隐藏地址之间如何进行交易

Ariel Gabizon | Nov 29, 2016

'Zcash 交易剖析' 中,我们对于 Zcash 交易给出了总体概述。本篇博文的目的,是解释在 Zcash 中 保护隐私 的交易时如何实现的,同时还包括零知识证明是如何在 Zcash 交易中被使用的。在本篇博文中的术语,我们将在此处着重介绍隐私地址之间的交易(通常称为 z-addrs)。

如果要理解保护隐私方面的知识,让我们先把我们了解的使用工作量证明实现的区块链共识知识放在一边,并只关注于一个获得未花费交易输出列表的节点。

让我们首先来回顾这个列表在比特币网络中的样子。 每一笔未支付的转账输出 (UTXO)可以被想象为未支付的‘票据’,这个票据描绘了这笔转账的地址/公钥中所包含的 BTC 数量。 为了表述渐变,每一个这样的票据都包含 1 BTC,同时每一个地址仅对应一个票据。因此,在某一时刻,一个节点数据库包含未支付票据列表,而其中的每一个票据都能够由其拥有者简单的描述出来。 比如,数据库可能看起来会是这样。

\(\mathsf{Note}_1=\) \((\mathsf{PK}_1)\), \(\mathsf{Note}_2=\) \((\mathsf{PK}_2)\), \(\mathsf{Note}_3=\) \((\mathsf{PK}_3)\)

假设 \(\mathsf{PK}_1\) 是 Alice 的地址,她希望发送 1 BTC 的票据给 Bob 的地址 \(\mathsf{PK}_4.\)。 她所发送的消息传向所有节点,表达出的意思是“发送 1 BTC 从 \(\mathsf{PK}_1\)\(\mathsf{PK}_4\)”。 她使用与 \(\mathsf{PK}_1,\) 对应的密钥 \(\mathsf{sk}_1\) 来签署这条消息,这样做证明了她可以使用 \(\mathsf{PK}_1.\) 地址内的资金。 在检查完节点签名之后,也就是检查了确实由 1 BTC 的票据存放在 \(\mathsf{PK}_1.\) 地址内之后,数据库将会根据以下条件被更新:

\(\mathsf{Note}_4=\) \((\mathsf{PK}_4)\), \(\mathsf{Note}_2=\) \((\mathsf{PK}_2)\), \(\mathsf{Note}_3=\) \((\mathsf{PK}_3)\)

现在,假设每一个票据同样包含一个随机的'序列号' (aka 唯一标识符) \(r.\)。我们将很快意识到这个功能有益于保护隐私。因此,数据库将变为如下形式。

\(\mathsf{Note}_1=\) \((\) \(\mathsf{PK}_1\) \(,\) \(r_1)\), \(\mathsf{Note}_2=\) \((\) \(\mathsf{PK}_2\) \(,\) \(r_2)\), \(\mathsf{Note}_3=\) \((\) \(\mathsf{PK}_3\) \(,\) \(r_3)\)

保护隐私自然的第一步使节点仅存储“加密的信息”,或仅仅存储票据的哈希,而不是票据本身。

\(\mathsf{H}_1=\) \(\mathbf{HASH}(\mathsf{Note}_1)\), \(\mathsf{H}_2=\) \(\mathbf{HASH}(\mathsf{Note}_2)\), \(\mathsf{H}_3=\) \(\mathbf{HASH}(\mathsf{Note}_3)\)

保护隐私的第二步,是即使票据 已经被花费掉,节点仍然存储票据的哈希。因此,它已经不是由未花费票据组成的数据库,而是 所有之前存在的票据 构成的数据库。

而现在,首要问题是如何在不侵害隐私的前提下,区分哪些是已经被花费的票据,而哪些又是未被花费的票据。 这就是为何需要引入 否决器装置。 这是有关所有已经被花费的票据哈希序列号的列表。 每个都存储着否决器装置和一套哈希过的票据。 比如,在 \(\mathsf{Note}_2\) 被花费之后,节点数据库会变成如下形式。

哈希过的票 据否决器装置
\(\mathsf{H}_1=\) \(\mathbf{HASH}(\mathsf{Note}_1)\) \(\mathsf{nf}_1=\) \(\mathbf{HASH}(\mathsf{r}_2)\)
\(\mathsf{H}_2=\) \(\mathbf{HASH}(\mathsf{Note}_2)\)  
\(\mathsf{H}_3=\) \(\mathbf{HASH}(\mathsf{Note}_3)\)  

交易如何产生?

现在假设 Alice 拥有 \(\mathsf{Note}_1\) 并期望发送给 Bob,Bob 的公钥是 \(\mathsf{PK}_4.\)。我们为求简便,假设 Alice 和 Bob 拥有一个隐私的支付通道,而这个通道并不一定粗你在于 Zcash 中。 基本上,Alice 将在发布否决器之后作废她的票据,而与此同时将产生一个由 Bob 控制的新票据。

更加精确的来说,她做了以下的工作。

  1. 她随机选择了新的序列号 \(r_4\) 并且定义新的票据 \(\mathsf{Note}_4=\) \((\) \(\mathsf{PK}_4\) \(,\) \(r_4).\)
  2. 她将 \(\mathsf{Note}_4\) 秘密地发送给了 Bob。
  3. 她将 \(\mathsf{Note}_1\) 的否决器 \(\mathsf{nf}_2=\) \(\mathbf{HASH}(\mathsf{r}_1)\) 发送给所有节点。
  4. 她将新票据的哈希 \(\mathsf{H}_4=\) \(\mathbf{HASH}(\mathsf{Note}_4)\) 发送给所有节点。

现在,当某个节点收到 \(\mathsf{nf}_2\)\(\mathsf{H}_4,\) 它会检查这个与 \(\mathsf{nf}_2\) 对应的票据是否已经被花费出去,想要完成这个检查,只需查看否决器装置中是否存在 \(\mathsf{nf}_2\) 。 如果不存在,则这个节点会添加 \(\mathsf{nf}_2\) 到福崛起装置,并添加 \(\mathsf{H}_4\) 到哈希过的票据中;从而验证了 Alice 和 Bob 之间转账的有效性。

哈希过的票 据否决器装置
\(\mathsf{H}_1=\) \(\mathbf{HASH}(\mathsf{Note}_1)\) \(\mathsf{nf}_1=\) \(\mathbf{HASH}(\mathsf{r}_2)\)
\(\mathsf{H}_2=\) \(\mathbf{HASH}(\mathsf{Note}_2)\) \(\mathsf{nf}_2=\) \(\mathbf{HASH}(\mathsf{r}_1)\)
\(\mathsf{H}_3=\) \(\mathbf{HASH}(\mathsf{Note}_3)\)  
\(\mathsf{H}_4=\) \(\mathbf{HASH}(\mathsf{Note}_4)\)  

... 但是等一下,我们检查了 \(\mathsf{Note}_1\) 并没有在之前被花费掉,但我们并未检查它是否属于 Alice。事实上,我们并没有检查它是否是一份 ‘真实的’ 票据,票据的真实性在于它的哈希是否保存在哈希后的票据列表中。 解决这个问题的简单方法是让 Alice 发布 \(\mathsf{Note}_1,\) 而不是它的哈希;但同样,这将破坏我们想要保护的隐私。

这就是 零知识证明 所要保护的地方:

在以上的步骤中,Alice 将会发布一个证明字符串 \(\pi\) 用于说服节点 谁发布了这个交易谁就知道交易数额\(\mathsf{PK}_1,\) \(\mathsf{sk}_1,\) \(r_1\)如此,则

  1. 票据的哈希 \(\mathsf{Note}_1=\) (\(\mathsf{PK}_1,\) \(r_1)\) 保存在哈希后的票据中。
  2. \(\mathsf{sk}_1\) 是于 \(\mathsf{PK}_1\) 对应的私钥,(因此,谁知道它就享有 \(\mathsf{Note}_1\) 的使用权)。
  3. \(r_1\) 的哈希是 \(\mathsf{nf}_2\),(因此,如果 \(\mathsf{nf}_2\) - 我们知道它是 \(\mathsf{Note}_1\) 的否决器 - 并没有在当前的否决器装置中,则 \(\mathsf{Note}_1\) 仍不能被花费出去)。

零知识证明的特性保证了 \(\mathsf{PK}_1,\) \(\mathsf{sk}_1,\)\(r_1\) 的信息不能被 \(\pi\) 所公开。

以上的内容,我们忽略了细节

我们强调以上是非常简单的功能描述,并推荐阅读 协议细则 来了解所有细节内容。

以下是我们主要在本文略去的内容:

  1. 哈希过的票据不光需要以列表形式保存,并且需要存放于 Merkle 树中。这样做对于使得零知识证明更加高效的被使用非常重要。此外,我们需要存储票据的 隐藏的计算和捆绑的承诺,而不是仅仅存储哈希。
  2. 否决器需要以一种更加复杂的形式被定义,这样做用来保证接收方与发送方之间保密的联系。
  3. 我们并没有阐述如何在发送方和接收方之间消除一个隐私交易通道的细节。