This article delves into historical attempts to make transactions more trustless, the limitations of these technologies, and newer, more robust ideas relying on ZK-SNARKs and other advanced cryptographic techniques. Adapted from Vitalik Buterin's original piece, "Having Secure CEXs: Proof of Solvency and Beyond," this exploration sheds light on how exchanges can enhance transparency and security.
Balance Sheets and Merkle Trees: Traditional Proof of Solvency
The earliest cryptographic attempts by exchanges to prove they weren’t deceiving users date back over a decade.
- 2011: Mt. Gox, then the largest Bitcoin exchange, proved its holdings by moving 424,242 BTC to a publicly announced address.
- 2013: Discussions began about proving client deposit totals (liability proof). Combining this with asset proof (demonstrating ownership of reserves) creates a proof of solvency.
How It Works
Merkle Sum Trees
- Client balances are stored in a Merkle sum tree, where each node includes a balance and a hash.
- Leaves represent individual salted username hashes and balances.
- Higher nodes aggregate balances and hashes from child nodes.
User Verification
- Each user receives a Merkle proof of their balance.
- This ensures their balance is correctly included in the total.
Example Code: Merkle Sum Tree Implementation
Limitations
- Privacy Leaks: Users can infer others’ balances (e.g., “someone has 164 ETH”).
- Negative Balances: Exchanges might fake solvency by hiding negative balances, but Merkle sum trees expose such fraud.
Enhancing Privacy and Robustness with ZK-SNARKs
Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (ZK-SNARKs) revolutionize privacy for proof of liabilities.
Key Improvements
KZG Commitments
- Replace Merkle trees with polynomial commitments to hide individual balances.
- Prove total balances and non-negativity without revealing details.
Special-Purpose ZK-SNARKs
- Example: A polynomial checks that all balances sum correctly and are non-negative.
- Extend to complex constraints (e.g., margin trading).
Long-Term Vision:
- Extend ZK proofs to loans, creating an on-chain reputation system via “soulbound tokens” (SBTs).
Proof of Assets
Simple Method
- Movement-Based Proof: Transfer funds to a pre-announced address or sign off-chain messages.
Challenges
Cold Storage
- Offline setups complicate frequent proofs.
Solutions:
- Reuse long-term public addresses.
- Random audits of subsets of addresses.
- ZK proofs for aggregate balances.
Collateral Reuse
- Exchanges might shuffle funds to fake solvency.
- Fix: Real-time proofs or synchronized schedules.
Fiat Reserves
- Requires trust in banks/auditors but is still valuable.
Plasma and Validiums: Toward Non-Custodial CEXs
Modern approaches like validiums (ZK-rollups with off-chain data) eliminate theft risk while keeping user funds accessible.
Tradeoffs
- Pros: No theft by operators.
- Cons: Funds may get stuck if operators vanish.
- User Recovery: Self-custody with social recovery wallets (long-term) vs. centralized recovery for convenience (short-term).
Conclusion: The Future of Exchanges
Short-Term:
- Custodial exchanges improve with proof of reserves (asset + liability).
- Open-source tools benefit all exchanges.
Long-Term:
- Non-custodial exchanges dominate, with recovery handled at the wallet level.
- Fiat on-ramps via asset-backed stablecoins (e.g., USDC).
👉 Explore Secure Exchange Solutions
FAQ
Q: How can users verify an exchange’s solvency?
A: Check Merkle proofs/KZG commitments for their balance and total reserves.
Q: Can exchanges fake proof of reserves?
A: Only if they control enough users’ validation checks—ZK-SNARKs reduce this risk.
Q: What’s the biggest hurdle for proof of assets?
A: Cold storage logistics and preventing collateral reuse.
Q: Will non-custodial exchanges replace custodial ones?
A: Yes, but hybrid solutions will bridge the transition.
Further Reading:
Special thanks to Balaji Srinivasan and teams at Coinbase, Kraken, and Binance for insights.