1 Z- ], S+ E; i
更有野心的是,交易所可以建立一个未经储户同意无法提取储户资金的系统。我们可以尝试探索「不作恶」有职业素养的 CEX 与「无法作恶」却泄漏隐私的低效链上 DEX 之间的界限。这篇文章将深入探讨让 CEX 更加去信任的历史尝试,与其采用技术的局限性,以及一些依赖 ZK-SNARKs 等先进技术的有力手段。# C/ T% o7 Q: i+ K: h. [6 B
+ u+ a: V, U9 Y& w' |
余额表和 Merkle 树:传统的可偿付证明交易所试图用密码学来证明自己没有欺骗用户的最早尝试可以追溯到很久以前。2011 年,当时最大的比特币交易所 MtGox 通过发送一笔移动 424,242 个 BTC 到预先公布地址的交易来证明他们拥有该笔资金。2013 年,大家开始讨论如何解决该问题的另一面:证明用户存款的总规模。如果你证明用户的存款等于 X (负债证明 proof of liabilities),并证明拥有 X 个代币的私钥(资产证明 proof of assets),那么就提供了可偿付证明(proof of solvency):你证明了交易所有足够的资金偿还给储户。. X% S* t- w0 q
提供存款证明的最简单方法是公布一个列表。每个用户都可以检查他们在列表中的余额,而且任何人都可以检查完整的列表:(i)每项余额都是非负的;(ii)总额是宣称的金额。
4 }( l( r1 U8 J. D3 H
当然,这会破坏隐私,所以我们可以稍微改变一下该方案:发布一个 列表,并私下给用户发送 salt 值。但即使这样也会泄漏余额与其分布。为了保护隐私,我们采用了后续技术:Merkle 树技术。; c- r( I/ M! y6 [' N
` m" q0 o6 }& e& O+ u# J
绿色:Charlie 的节点。蓝色:Charlie 收到用于证明的节点。黄色:根节点,向所有人公布( ^3 h5 u7 K# s$ H
% I- Z# ~8 s; y$ I0 ?/ g* h
Merkle 树技术会将用户余额表放进 Merkle 总和树。在 Merkle 总和树中,每个节点都是对。底层叶子节点表示各个用户的余额以及用户名的加盐哈希。在每个更高层的节点中,余额是下面两个节点余额的总和,而哈希是下面两个节点的哈希。Merkle 总和证明和 Merkle 证明一样,是一个由叶子节点到根节点路径上所有姐妹节点组成的「分支」。
首先,交易所会向每个用户发送一份其余额的 Merkle 总和证明。然后,用户能够确定其余额作为总额的一部分而被正确地包含。可以在这里找到简单的示例代码。0 _/ s `' ]* j
5 u0 ~1 ~- M5 n9 A7 T9 s9 j
- # The function for computing a parent node given two child nodes: F" u9 K7 f2 l/ C
- 7 O4 ^ `* {/ n# \6 ?6 B
- def combine_tree_nodes(L, R):! [. g f: J0 F8 }
- L_hash, L_balance = L
- % z* D; i* p4 K6 \4 v; @1 f; R- R6 d
- R_hash, R_balance = R' K8 H/ m4 a9 U( Y1 i
- ( ^+ H, l# s4 k0 V6 f) H' g
- assert L_balance >= 0 and R_balance >= 0; b0 e+ F( i* g; T6 `
- 3 w/ U; o6 z! g/ S* n, c
- new_node_hash = hash(
- M; i8 x/ s0 w# Y4 r
- L_hash + L_balance.to_bytes(32, 'big') +7 i1 s/ J7 j. `2 N7 j D
- 9 o0 ?. M7 c5 e+ K; g
- R_hash + R_balance.to_bytes(32, 'big')5 n' u6 a, a5 v9 X
- ), l. Y* E; U$ S
- return (new_node_hash, L_balance + R_balance)- }) H" ~+ M0 r7 Z4 x! p; q. x
- # Builds a full Merkle tree. Stored in flattened form where' a3 Y/ f# T$ h
- # node i is the parent of nodes 2i and 2i+12 U7 H$ h. t2 `6 M
- def build_merkle_sum_tree(user_table: "List[(username, salt, balance)]"):
- tree_size = get_next_power_of_2(len(user_table))) I* c! m/ v3 u6 J: u; P9 q9 O
- tree = (* d8 ?) ~: Q4 Z& E6 y
- 8 o. e$ I; C' w
- [None] * tree_size +
- [userdata_to_leaf(*user) for user in user_table] +
- ! o. v; E5 \* |9 ~, Y
- [EMPTY_LEAF for _ in range(tree_size - len(user_table))]
- )
- for i in range(tree_size - 1, 0, -1):; i2 @ X/ K f2 x! \3 E3 ~# J9 D
- ; `% X, y4 v9 B, r, o( s
- tree = combine_tree_nodes(tree[i*2], tree[i*2+1])8 D) R6 O$ B! t6 ^1 {/ D
- return tree1 P0 D+ G( J8 O$ V1 T; d
- , u [4 D% g; L4 K
- # Root of a tree is stored at index 1 in the flattened form
- 3 w8 |8 K7 @( ^* F! D# I* c
- def get_root(tree):$ w4 H! f: x8 W+ E: C1 y
- return tree[1]
- # Gets a proof for a node at a particular index" j- I, X" o7 U+ M# i
- def get_proof(tree, index):
- branch_length = log2(len(tree)) - 1
- # ^ = bitwise xor, x ^ 1 = sister node of x! I F- h4 s, M1 M; S- B
- index_in_tree = index + len(tree) // 2
- 0 J9 t1 N, F, M% J
- return [tree[(index_in_tree // 2**i) ^ 1] for i in range(branch_length)]
- 4 a- ?9 P+ N2 R" m
- # Verifies a proof (duh)
- 1 L+ X8 T/ w: D6 b
- def verify_proof(username, salt, balance, index, user_table_size, root, proof):/ V B% d8 H% n4 C+ ]2 N+ P6 R4 J
- leaf = userdata_to_leaf(username, salt, balance)
- , T, Q3 G3 K* C ^7 @. x0 J
- branch_length = log2(get_next_power_of_2(user_table_size)) - 1
- : K9 s. P6 z7 r( u# M- I3 f
- for i in range(branch_length):. C7 z; z* ^5 U# f" X
- if index & (2**i):
- leaf = combine_tree_nodes(proof, leaf)
- 8 r; b6 H4 t; {1 `5 c/ o; r
- else:! W5 J( \5 v; L* O5 t- Z
- leaf = combine_tree_nodes(leaf, proof)
- " _; `0 h+ M4 D3 B5 ~ d1 i2 H
- return leaf == root