1703865961
1703865962
政府不仅仅对银行进行监管，还会在必要时为银行或储蓄者提供保护。首先，政府会提供储蓄保险。如果一个遵纪守法的银行破产，政府会偿还储户一部分存款。其次，政府有时候也会充当“最后借款人”角色。如果银行短期经营困难，但仍有一定的偿债能力，政府给银行提供贷款，直到银行有足够的资金周转，从而让银行渡过难关。
1703865963
1703865964
传统银行的监管大抵如此，但比特币交易所的监管则并非这样。比特币交易所需不需要被监管，我们会在第7章讨论。
1703865965
1703865966
准备金证明
1703865967
1703865968
比特币交易所或者其他提供比特币管理服务的机构，可以使用一种称为“准备金证明”（proof of reserve）的密码学技术来向储户证明他们留存了一部分储备金——例如，按照储蓄额的25%留存——从而消除投资人的担心。
1703865969
1703865970
准备金证明包括两方面的内容：首先是证明你有多少准备金。这比较容易，交易所只需发起一笔向自己转账的交易，转账的金额等于其公布的准备金金额即可。如果交易所声称留存了100 000个比特币作为准备金，那么它们会发起一笔100 000个比特币的转账交易，收款人就是交易所本身，然后向客户说明这笔交易的有效性。之后，它们会用同一个私钥去为一条查询指令签名，这个查询指令是公正的第三方随意发出的字符串。这样就可以证明出具准备金证明的人至少知晓该私钥（即使他不是私钥的拥有者）。
1703865971
1703865972
我们应注意到两点：首先，严格地说，准备金证明并无法证明交易所真正拥有这些准备金，只能说明真正拥有这笔比特币的人愿意参与准备金证明的过程。换句话说，准备金证明只是证明了某人（交易所）可以控制这一笔钱，或者某人（交易所）所熟悉的人可以控制这一笔钱。其次，准备金是可能被瞒报的，一个交易所可能留存了150 000个比特币的准备金，但只向人们证明它留存了100 000个比特币的准备金。因此，准备金证明不能证明准备金的上限金额，而只能证明其下限金额，即证明某人（交易所）“至少”有多少准备金。
1703865973
1703865974
负债证明（proof of liabilities）
1703865975
1703865976
目前，交易所只证明了留存的准备金规模，为了证明准备金留存比例，还需要证明其吸收的存款规模。知道了准备金规模和存款规模，那么将这两个数相除就得到了准备金留存比例。我们接下来会展示一种方法，可以确保交易所不会瞒报存款规模（但可以多报），这样，由于交易所向人们证明了准备金“至少”是多少，存款规模“至多”是多少，这样，在计算准备金比例时，分子偏小而分母偏大，因此，我们可以得到准备金比例的保守估计。
1703865977
1703865978
对于比特币交易所而言，如果不考虑储户隐私的话，可以将所有的存款记录公布，即公布所有储户的姓名和金额，这样，人们就可以计算交易所的储蓄规模（即交易所的负债规模），而且，如果交易所瞒报数据，那么某些储户将发现自己并不在公布名单内或者发现自己的储蓄额少了，这时，储户就会将此曝光，因此，交易所不可能瞒报存款规模。但是，交易所可以在存款记录中加入一些虚构的客户，这样，由于公布的数据真假掺和，在一定程度上可以保护储户的隐私，只是这么做会使交易所的总负债被高估。这种情况下，只要没有收到储户投诉其储蓄被少报或漏报，人们就可以相信，交易所公布的负债规模肯定不低于实际的负债规模。
1703865979
1703865980
当然，以上做法是以牺牲储户隐私为代价的。实际上，我们会用梅克尔树来证明存款规模。我们在第1章就说过，梅克尔树就是一棵哈希值构成的二叉树，每个指针不仅告诉我们去哪里找到一个信息，而且还告诉我们这个信息的哈希值。交易所想要证明其负债，可以先构建一棵二叉树，二叉树的每个叶节点都代表一个储户，如图4.5所示（当然，这里也同样需要储户来核实自己是否在这棵二叉树上），之后，我们还需要让储户可以核实交易所申明的负债规模，要实现这点，我们需要为每个节点添加一个字段（下文简称为存款金额字段），这个字段显示其最近的两个子节点的存款金额之和。
1703865981
1703865982
1703865983
1703865984
1703865985
图4.5 负债证明
1703865986
1703865987
注：交易所构建这样一棵梅克尔树：每个储户对应一个叶节点，每个叶节点的存款金额字段保存储户存款金额。每个节点的存款金额字段等于与其最相近的两个子节点的存款金额之和，这样，根节点的存款金额字段就代表着存款总规模。每个储户都可以要求交易所证明该储户在梅克尔树上，并且可以核实根节点所显示的总存款规模。
1703865988
1703865989
交易所构建完梅克尔树之后，把根节点的哈希指针和根节点的存款金额字段进行加密签名，然后在网络上广播。根节点的存款金额字段自然就是存款总规模——也就是我们最关心的数据。此外，交易所还需要声明所有储户都可以对应到叶节点上，而且所有储户的存款数据都是正确的，并且每个父节点在加总子节点的存款数据时也没有出现差错，因此，根节点的存款金额字段正确无误地说明了存款总规模。
1703865990
1703865991
现在，每个客户都可以向交易所索取存款证明，交易所也必须向储户出具相应证明。这种证明实际上就是一棵包含该客户所对应的节点的子树，子树应包括根节点和叶节点，如图4.6所示，之后，客户可以核实以下几点：
1703865992
1703865993
1.子树根节点的哈希指针和存款金额字段，与交易所广播的值一致。
1703865994
1703865995
2.从子树的根节点遍历到叶节点，每个节点对应的哈希值确实是其所指向的子节点的哈希值。
1703865996
1703865997
3.每个叶节点对应的客户账号信息（客户名、账号和存款金额）都是正确无误的。
1703865998
1703865999
4.每个节点的存款金额字段正好等于与其最相近的子节点的存款金额之和。
1703866000
1703866001
1703866002
1703866003
1703866004
图4.6 以梅克尔树（子树）的形式提供存款证明
1703866005
1703866006
注：子树包含叶节点、根节点和之间的所有子节点及其兄弟节点。
1703866007
1703866008
上述做法的优点在于，二叉树的每个分支都会被遍历一遍，而且，总有人会核实每个节点的存款金额字段恰恰等于与其相邻的两个子节点的存款金额之和。关键的是，不同的客户获得的子树中，如果有相同的节点，那么这些节点的哈希值以及存款金额字段也必定是相同的，否则就会产生哈希碰撞（hash collision）。
1703866009
1703866010
我们总结一下。首先，交易所为了证明其留存了X比特币的准备金，发起了一笔向自己转账的交易，转账金额为X个比特币，并且在网络上广播这笔交易。之后，交易所证明其吸收的存款规模不少于Y比特币。这样，我们就知道这个交易所的准备金比例至少是X/Y。这意味着，如果一个比特币交易所想向人们证明自己的准备金比例是25%，可以通过上述方法让所有人都可能对此进行独立审计，而不是依靠中央权威机构来验证。