币圈活动项目早知道今日讯:凭借零知识证明,在不知晓陈述内容的情况下,一方(验证者)可以确定另一方(证明者)给出的陈述是否有效。例如,假设币安要证明平台拥有充足的储备金能完全支撑用户的资金,但又无需透露每位用户的个人余额。
“储备金证明”可以由默克尔树构建,以防止内部数据造假。在这种情况下,客户净余额总额即为交易平台对用户的负债。这之后可以与zk-SNARK(零知识证明协议)相结合,确保用户可以在不知晓个人余额的情况下,核实自己的余额在用户总净资产余额中的占比。
简介
鉴于各种市场事件,加密货币资产托管的安全性已成为重大课题。区块链用户高度重视透明度和开放性,但也支持隐私性和保密性。这让托管方在证明所持储备金资金时陷入了困境。透明度、信任度与数据保密性之间总有取舍。
但是,这也不尽然。通过将zk-SNARK等零知识证明协议与默克尔树相结合,我们可以为各方找到有效的解决方案。
什么是零知识证明?
凭借零知识证明,在不知晓陈述内容的情况下,一方(验证者)可以确定另一方(证明者)给出的陈述是否有效。我们简单举例说明。
某人有个上锁的保险柜,开锁密码只有本人知道。假设这个保险柜除了能用密码打开,无法用其他方式撬开或强行打开。参与该实验的其他好友也都知晓、证实和验证过这一事实。
此人告诉好友自己知道密码,但不想透露密码,也不想当着其他好友的面打开保险柜。保险柜顶部有个孔,好友可以往里面塞一张便条。好友只需在便条上写下给定陈述,无需过多了解整个过程的其他信息,这张便条就成了零知识证明。
要向好友证明自己知道密码,此人可以打开保险柜,念出好友写在便条上的内容,并再次锁上保险柜。在整个过程中,此人都未泄露密码。
为何要使用零知识证明?
零知识证明适用于证明不宜泄露敏感信息或细节的内容。如果担心提供的财务或个人信息遭到不当使用,这时零知识证明就能派上用场。
在加密货币领域,用户无需透露私钥或电子签名即可证明自己拥有私钥。加密货币交易平台则也希望能在不泄露用户机密信息(个人账户余额等)的情况下证明平台储备金的状态。
在各种示例中,零知识证明均采用接受数据输入,并返回“true”(真)或“false”(假)输出的算法。
用专业术语定义“零知识证明”
用专业术语来表达,零知识证明遵循具有特定标准的具体结构。我们已经介绍过证明者和验证者角色,但零知识证明还应涵盖三个标准:
-
完整性。如果陈述真实,无需辅助其他信息或验证,验证者就会相信所提供的证明。
-
可靠性。如果陈述是假的,验证者不会因为提供的证明就相信陈述的真实性。
-
零知识证明。如果陈述真实,验证者无需了解陈述真实性以外的任何信息。
什么是zk-SNARK?
zk-SNARK(零知识简明非交互式知识证明)是一种遵循上述零知识原则的证明协议。借助zk-SNARK,用户可证明自己知道经哈希处理的原始值(下文将进一步讨论),而无需透露该值的具体内容。在不透露具体金额、数值或地址等相关信息的情况下,用户还可以证明某笔交易的有效性。
在区块链和加密货币领域,zk-SNARK受到了广泛使用及讨论。但有人会疑惑,用公钥和私钥配对的简单方法就能保障信息安全,为何还要这么麻烦去用zk-SNARK呢?那是因为我们无法用数学证明来确保不含负余额和默克尔树总和。
就交易平台的储备金而言,我们希望在不公开各个账户标识符和余额的情况下,证明客户余额有1:1的资金支撑。此外,zk-SNARK技术让数据伪造变得更加不可能。
什么是默克尔树?
要显示币安用户的账户资金总和需要处理大量的数据集。使用默克尔树即为以加密方式呈现如此大量数据的一种方式。大量数据能够高效存储其中,并且默克尔树具有加密特性,因此很容易验证其完整性。
哈希函数
默克尔树利用哈希函数来简化输入的编码。简言之,哈希运算是可变大小的输入生成固定大小的输出的过程。换句话说,任何长度的输入通过算法进行哈希处理后,就将生成固定长度的加密输出。
只要输入保持不变,输出也将保持不变。这意味着,我们可以获得海量交易数据,并经过哈希处理后成为可管理的输出。如果输入中的任何信息发生变化,输出就会截然不同。
例如,我们将100本书的内容输入到SHA-256哈希函数中,生成的输出大致如下所示:
801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea
如果我们更改该输入(这100本书)中的某个字符,哈希值将彻底改变,如下所示:
abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410
这是哈希函数的一个重要属性,因为可以借此轻松验证数据的准确性。如果有人用SHA-256算法复制这100本书的哈希运算过程,将会得出与输出完全相同的哈希值。假设输出有所不同,则可以肯定输入发生了改变。这意味着,根本无需劳心费力去单独手动核实输入之间的差异。
加密货币领域的默克尔树
在区块链中存储交易数据时,每笔新交易都通过哈希函数提交,从而生成唯一的哈希值。假设我们有八笔交易(A至H),分别进行哈希处理后获得各笔交易的哈希输出。这些输出即为“默克尔树叶节点”。如下图所示,每个字母的唯一哈希值:hA代表A、hB代表B、hC代表C,以此类推。
随后我们可以取成对的哈希输出,重组后获得新的哈希输出。例如,hA与hB的哈希值合并哈希处理后,得到hAB这个新的哈希输出,即称为“默克尔分支”。请注意,根据所用哈希函数,每次生成的新输出均为固定长度和大小。
现在,我们将A和B两笔交易的数据合并为一个哈希值,即hAB。请注意,如果我们更改A或B中的任何信息并重复此步骤,哈希输出hAB将完全不同。
我们合并新的哈希值对再进行哈希处理,继续这个流程(见下图)。hAB与hCD哈希处理获得唯一的哈希值hABCD,hEF与hGH如法炮制得到hEFGH。最终,我们得到一个哈希值,即代表此前所有交易哈希值的哈希输出。换言之,哈希输出hABCDEFGH等于此前的所有信息。
上方显示的图形称为“默克尔树”,而哈希输出hABCDEFGH则是默克尔根。区块头以简洁的方式对区块中的所有交易数据进行加密汇总,因此用默克尔根再合适不过。我们还可以快速验证区块中是否有任何数据遭到篡改或变更。
默克尔树的局限性
我们回到中心化交易平台储备金的例子。中心化交易平台希望证明所有客户的资产均获得1:1的资金支持,就要将平台客户的用户ID及其持有的代币净资产(扣除资产和负债)合并进行哈希处理,构建默克尔树。默克尔树发布(以及签署证明所提供默克尔根的所有权)后,个人用户不访问所有输入,就无法核实默克尔树是否有效。
交易平台可能会遗漏一些输入,还可能创建余额为负的虚假账户来篡改总负债。例如,客户的总资产为100万美元,虚假账户余额为-50万美元,这样就能伪造只需50万美元的储备金目标。
储备金证明与区块的默克尔根情况有所不同,原因是用户可以在区块链浏览器中查看某个区块包含的所有交易。然而,出于安全和数据隐私原因,中心化交易平台不希望披露各账户余额。客户也不会乐意看到自己的账户余额公之于众。在这种情况下,用户余额不可见,中心化交易平台无法证明用户余额相加总数是否准确无误。
交易平台考虑的一种解决方案是聘用值得信赖的第三方审计机构。审计机构可以核查个人账户和储备金,之后最终证明所提供默克尔根的有效性。但是,这种方法需要用户信任审计机构和用于审计的数据。如果可以信任数据,就不必依靠第三方。
zk-SNARK与默克尔树并用
上述问题是能用zk-SNARK解决的完美案例。我们要证明储备金可以全额覆盖用户负债,并且没有造假。但是,出于隐私和安全原因,我们不希望向验证者展示用户余额和储备金的具体构成。
加密货币交易平台采用zk-SNARK,即可证明所有默克尔树叶节点的余额集(即用户账户余额)构成了交易平台对外公布的用户资产余额总量。叶节点已经包含在该流程中,每位用户均可轻松访问自己的叶节点。zk-SNARK还确保生成的任何默克尔树不包含总净资产余额为负的用户(借币均为超额抵押,可能意味着数据造假)。币安还使用全局状态计算,即每位币安客户所持有每种资产的总净余额列表。
以下是币安处理此类情况的方式。首先,币安定义了要证明的计算过程中的约束,并将其定义为可编程环路。下方是币安在其模型中使用的三个约束集。
针对每位用户的余额集(默克尔树叶节点),我们的环路确保:
-
用户的资产余额包含在币安的用户总净余额求和计算中。
-
用户的总净余额大于或等于零。
-
用户信息更新至叶节点哈希值后,默克尔树根的更改生效(即不使用伪造信息)。
随后,币安可以根据环路生成构建默克尔树的zk-SNARK证明。这需要交易平台执行繁重的计算,对用户的ID和余额进行哈希处理,同时确保证明通过约束。
验证者将检查证明(及其公开发布的开源代码),以确信计算是在满足所有约束的情况下执行的。与证明花费的时间相比,验证计算耗时极短。
每次发布储备金证明,交易平台都将对外公布:
1.每位用户的默克尔证明。
2.zk-SNARK证明和所有用户环路的公共输入(每种资产总净余额列表的哈希值和默克尔根)。
相关各方可验证默克尔根,确保个人余额计入到默克尔树根中。他们还可以验证zk-SNARK证明,确保默克尔树的构建满足环路中定义的约束。
结语
zk-SNARK提供了同时兼顾数据完整性与隐私性的必要技术。这种技术应用到储备金证明和中心化交易平台的透明度提升中,将有助于区块链行业的信任度构建。对很多人来说,这样的发展期盼已久,并且正好出现在中心化交易平台的关键时期。