储备证明

审核

了解Kraken的审核流程

Kraken储量验证审核流程  

简介

本文档提供了有关Kraken审计流程的背景和指导。

Kraken拥有完整的储备金,我们采用经过加密验证的独立审计,向第三方(包括我们的客户)证明客户资金已得到妥善保管。 透明度和独立验证的审核对于确保公司持有全部客户资金储备至关重要。 公共储备证明计划在技术上可以实施,但在公共储备证明计划的具体实施中,必须仔细考虑重要的外部因素,即用户隐私。 我们认为,交易平台和电子钱包必须通过问责制建立信任,我们有责任解决大众对透明度的需求。

在过去的几周里,Kraken成功开发并完成了行业领先的、经过加密验证的独立审计。 我们很自豪地向全球数字货币社区提交我们的流程概述。 我们相信比特币行业能够提供超越传统金融服务行业的相当程度的保证和责任,我们的目标是引导收费达到最佳透明度。

目前的形式

这一举措的推动力是Greg Maxwell关于交易平台/钱包证明其比特币储备的提议。 [1]

迄今为止,比特币行业的审计一直是不透明的,粗浅的,没有可公开查看和可独立验证的加密认证。 Kraken致力于提供概念证明,设定行业标准,以提高其他人可以遵循和改进的数字货币生态系统的透明度和问责制。

流程的质量

Maxwell 提议要求比特币公司披露所有有储蓄的地址。这种方法将导致交易所或钱包提供商的比特币钱包和总持有量的信息公开,这些信息具有商业敏感性,对企业和用户构成潜在的安全风险。更糟糕的是,这将导致不可容忍的用户隐私被侵犯,在这种情况下,个人持股和金融活动的历史和轨迹可以由第三方在没有理由的或通过不正当程序进行跟踪。

我们的流程不要求我们向公众披露我们的总余额、地址或密钥。通过结合和利用可信的审计人员和公开可验证的加密技术的优点,Kraken审计代表了隐私和透明性之间的理想平衡。

由于比特币是占主导地位的加密货币,我们的初步审计将只涵盖比特币储备。不过,今后的发展将考虑对其他资产进行审计。

处理概览

  • 第1阶段 - 审计员检查Kraken整个钱包的资金

    Kraken向审计员提供我们所有的公共地址并签名。 签名时的块哈希是签名消息的一部分,可以用作签名时的时间戳。 然后将验证这些公共地址的签名,并且审计员将使用比特币区块链来提取某个时间点在这些地址处可用的总金额。

    此阶段所需的代码由Payward首席运营官Michael Gronager撰写,未来可能是开源的。 但是,大多数代码都是开源的,因为代码是基于libcoin的。[2]

  • 第2阶段 - 审核员检查Kraken用户的余额是否与Kraken钱包的资金相匹配

    Kraken为审核员提供每个用户的BTC余额,并生成Merkle树。 审计员将发布根节点哈希以供所有人查看,并确认,如果为真,则根哈希表示的总持股量与他在区块链中看到的值非常接近。 此流程还确保Kraken不会在通向根节点的任何节点中隐藏任何内容。

    对于此阶段的审核,审核员可以访问树生成程序的源代码和个人帐户余额数据文件。 Kraken在MIT许可下发布了此阶段的C ++代码: https://github.com/payward/krakendb

  • 阶段3 - 用户独立验证其帐户余额是否包含在审核员使用的数据中

    Kraken向用户提供我们向审计员报告的金额,以及从他们的帐户到根(与审计员发布的帐户相匹配)的节点(和相邻节点)。 我们还公开了用于为其节点生成散列的散列方法,以便他们可以验证节点是否确实代表了我们声称的数量。

    这将使用户能够独立地检查他们的帐户是否包含在审核员验证的数据中。

缺陷

在本节中,我们将介绍该审计的一些缺点。 请注意,这显然不是一个详尽的弱点列表。 但是,由于我们重视对用户的透明度,因此我们提供了迄今为止在审计过程中确定的具体缺点的非正式背景。

与实物资产不同,信息不需要从一个人的财产中移除而被另一个人占有。 因此,Kraken或其他采用此审计方法的公司无法证明私钥未被攻击者复制。 我们也无法证明我们拥有经审计的资金。 我们只能证明,在审计时,我们是私钥的拥有者之一。

未经事先通知,可能无法按需执行完整审核。 鉴于此时所需的信息,审计结构和行业标准冷存储安全实践,没有预先通知的当天审计是不可行的。 我们设想一个潜在的“轻量级”审计建立在先前的完整审计之上,依赖于先前生成的签名,这也许更常见。

审核员必须被信任并且能胜任。 社区必须相信,审核员重视自己的声誉且具备技术能力。 在这个审计过程中有几个环节,受审核方可以欺骗技术性较差或不太多疑的审核员。 审计员还有机会有意或无意地泄露机密的公司和客户信息。 审核员和受审核方都必须考虑谁提供计算机,审核空间,区块链,互联网连接,路由器,DNS等。如果目标是隐藏数十亿美元的欺诈行为,可以想象一个人一定会想要蒙混过审计。

审核不会实时更新。 自上次审核时间以来,密钥可能丢失或资金被盗。 完整的审核更新了密钥没有丢失的现状,尽管它会产生更大的威胁暴露,因为有必要利用冷存储密钥进行审核。

受审核方可以临时借入资金或与真实资金所有者共享密钥以通过审核。

审核员可能会与受审核方的威胁勾结或屈服。

持续进行

我们希望持续进行定期审核。由于没有普遍信任的审核员,我们可能每次都使用不同的审核员或多名审核员。这会抵消那些对某个审计员资格的怀疑。

未来的变化和改进

我们期待收到来自业内的反馈及意见,以帮助我们和其他人改善提高这一用于日后审计的程序。作为行业成员,我们还希望与业内组织,如与DATA合作(www.datauthority.org)以协助开发基本准则、可拓展工具以及综合手册供行业内其他人执行此类审计工作。

参考资料

[1] Zak Wilcox总结: https://iwilcox.me.uk/2014/proving-bitcoin-reserves 我们要对Greg Maxwell提出的理念致谢。

[2] libcoin是将比特币转变为模块化、可重用的数据库: https://github.com/libcoin/libcoin

如何在Kraken审核中认证您的个人帐户余额

同时请参考:Kraken证明保留审核流程。

这些说明解释了如何以加密方式验证您的Kraken帐户余额以及将其纳入审计。

此验证将反映审核时您帐户的比特币(XBT)余额。

 

  • 步骤1

    如果您尚未登录,请登录您的Kraken帐户

    访问 https://www.kraken.com/ 并确保您的浏览器的地址栏显示 "https://www.kraken.com/"

  • 步骤2

    点开资金 -> "审计" 子菜单 -> 在左边选择"比特币 (XBT)"

    图1Kraken 比特币审核

  • 步骤3

    查看审核员验证的有关您帐户的信息

    • 审计的时间,是指核数器的时间轴

    • 提交代码, 是一种64位的盐(密码学)

    • 在审计时您账户上的比特币的金额 这是我们向审核员提供的帐户余额值

    • 记录包括来自核数器的信息,证明用于审计的根哈希。 还提供了指向已签名详细报告的链接

    • 哈希是指从您的节点哈希到根哈希,包括相邻的哈希。直接路径中的哈希值以星号(*)显示,以区别于相邻节点哈希。 使用这些哈希,您可以验证您的节点是否包含在根目录中:

    • 第一行应与审计员给出的根哈希值匹配

      如果要验证自己的节点哈希值(列表中带有*的最后一个哈希值),请执行以下操作:

      
      sha256(sha256(<submission code> || ":" || <amount with decimal point removed and leading>))</amount></submission>

      该值应与哈希值中给出的最后一个值匹配

      示例代码

      提交代码379377cd8190f9bf

      数额:0.01500000

      Python

      
      import hashlib; print(hashlib.sha256(hashlib.sha256(b'379377cd8190f9bf:1500000').digest()).hexdigest());
      

      PHP

      
      echo hash('sha256', hash('sha256', '379377cd8190f9bf:1500000', true));
      

      Result

      
      66b51ba0f4a5cf8278acac6782ffdfb9a64b9f7c895bc308266b0757c7025b27
      

      您可以通过对每对哈希(或“元组”)进行哈希来完全验证您的Merkle分支。 格式为:

      
      sha256(left-hash || right-hash)
      

      结果应该与前面的元组哈希(或根哈希)匹配,其中包含*。 这将针对所有元组完成。

      除了根哈希之外,所有哈希都以元组的形式给出,表示该顺序的左哈希和右哈希。 A *被赋予代表您的直接节点的哈希值。

      示例代码:

      Hashes:

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3* c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b* 5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c
      

      Python

      
      import hashlib; print(hashlib.sha256(b'c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'.decode('hex'))).hexdigest();
      

      PHP

      
      echo hash('sha256', hex2bin('c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'));
      

      Result

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3