Donec elementum justo quis mollis aliquam. In nec velit ultricies, hendrerit nulla ac, volutpat magna. Quisque ac efficitur magna, laoreet pretium est. Ut eu mauris odio. Pellentesque malesuada augue velit, non semper sapien finibus at. Sed finibus iaculis massa. Morbi nec elementum massa. Aenean eu feugiat leo, vel commodo purus. Quisque eu suscipit nisi, sed lacinia augue. Proin iaculis, dolor in eleifend pulvinar, est quam euismod eros, ut rhoncus diam nisi eu ipsum. Proin vel ante est. Nullam nibh metus, tristique non scelerisque et, efficitur et massa. Mauris euismod nisl vel aliquet vestibulum. Ut massa nibh, luctus at gravida nec, malesuada ac elit.

Ut pellentesque sem id nunc fermentum malesuada. Nulla vel metus nibh. Sed quis lorem eget augue gravida molestie molestie ut felis. Duis a nisl in eros vestibulum tempor. Cras fringilla euismod turpis sed sollicitudin. Sed diam elit, iaculis vitae pellentesque id, efficitur a ipsum. Aenean sagittis nibh rutrum semper tincidunt. Integer cursus accumsan elit vitae molestie. Nunc ac nisi ut nisi cursus molestie vitae quis metus. Fusce faucibus tellus eros, eu ultrices tortor egestas ac. Vestibulum sit amet convallis sapien. Ut pulvinar vestibulum interdum. Fusce id sapien tempus, posuere felis sit amet, tincidunt eros.

Cras tempor, turpis nec eleifend viverra, ex est convallis sapien, sit amet accumsan nisi sapien porttitor nulla. Donec et cursus arcu, at feugiat risus. Sed ac accumsan diam, quis semper lorem. Morbi eros arcu, feugiat ac viverra et, lacinia ut felis. Aliquam tortor libero, bibendum ut consequat nec, ultricies in mauris. Donec mollis mauris vitae turpis congue bibendum. Phasellus erat nunc, faucibus a libero et, dictum tincidunt tellus. Phasellus consequat vestibulum purus, accumsan aliquam dui dictum suscipit. Integer tincidunt, nunc quis ullamcorper facilisis, purus justo commodo eros, eu rutrum augue eros ut mauris. Nam pharetra velit sit amet nulla suscipit, nec tempor nisi euismod. Nunc rhoncus gravida est, nec finibus elit finibus in.

Integer cursus sollicitudin ligula a ornare. Morbi sollicitudin congue ipsum, maximus mollis velit finibus eu. In tellus ligula, euismod mollis ultricies in, egestas eget nisi. Proin maximus nunc euismod mattis ullamcorper. Aliquam convallis ullamcorper tortor, et ullamcorper erat cursus non. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Fusce scelerisque velit in neque tincidunt, ac efficitur mauris suscipit.

Provisions consists of three main protocols:

1. Proof of assets: The exchange assembles a set of public keys and yields a Pedersen commitment to each public key in the set, and a homomorphic addition yields a commitment to its total assets. Through an interactive zero-knowledge proof, the prover convinces the verifier that for \(i \in [1, n]\) when \(s_i = 1\), the exchange knows the private key \(\hat x_i \in \mathbb{Z}_q\) such that \(g^{\hat x_i} = y_i\). The proof is an honest-verifier zero-knowledge and can be made non-interactive using the Fiat-Shamir heuristic. The verifier then computes \(\Pi_{i=1}^{n} p^i\) to ensure that the sum of the balances is equal to the committed value without knowing which public keys the exchange has the corresponding private keys to. This proof size is linear in the size of the anonymity set \(n\).
2. Proof of liabilities: Every customer should have an entry in a clash-attack-resistant list of liabilities, and the apparent liabilities of the exchange should be greater than or equal to its actual total liabilities. To ensure that there are no negative numbers, the sum of the total liabilities should not exceed the order \(q = 2^{256}\) of the group \(G = secp256k1\). A range proof that proves the account balance is at most 51-bits long by a bitwise commitment is used to enforce this. A fresh identifier (a commit to the username) is generated for each customer by applying a collision-resistant hash function to the concatenation of the username and a random nonce. A customer can check that its entry is included in Liablist with the correct balance, and a public auditor will verify all commits for all users. The proof size is linear in the number of customers \(c\).
3. Proof of solvency: A difference between assets and liabilities is computer homomorphically from the two protocols above. If \(Z_{\text{assets} - \text{liabilities}}\) is a commitment to 0, the proof is a simple Schnorr ZK proof of knowledge of \(k\) where \(Z_{\text{assets} - \text{liabilities}} = g^0h^k\). If fractional reserve banking is used, a modified balance can be used in place of the true balance.

To prevent cabals of insolvent exchanges from colluding, a list \(L\) of the public keys but computed using the base \(w\) instead of \(g\) is published, and auditors can check if the lists of different exchanges are disjoint ignoring the identity element. The correctness of \(L\)’s construction is proved through a Neff-like ZKP.

To ensure that different anonymity sets between audits do not leak information regarding the exchange’s holdings, the different sets used should be similar and grow over time with new addresses.

If the exchange chooses to fraudulently omit some liabilities, assuming the exchange has \(U\) users and \(F\) entries and a random subset \(A \subset U\) users perform audits, the probability of not being caught is \(\frac{U-F \choose A}{U \choose A}\), which is upper-bounded by \(min[(1 - \frac{A}{U})^F, (1 - \frac{F}{U})^A]\).

The inherent limitation of this work is that a proof of solvency does not guarantee honest behavior in the future; nevertheless, frequent monitoring of the financial health of exchanges can help mitigate losses through early detections.

Some future work includes:

• Extending provisions to support proof of ownership of unused pay-to-pub-key hash, unused pay-to-script-hash address, or multisig addresses through using zk-SNARKS
• Developing and analyzing a heuristic for forming an anonymity set
• Designing a proof-of-assets protocol that is compatible with HSMs that only perform complete ECDSA signatures and do not support an isolated addition with the key
• Taking into account the age of each UTXO to allow exchanges to demonstrate stability

Data distribution happens by exchanging blocks via the BitSwap Protocol inspired by BitTorrent; however, the BitSwap protocol enables nodes to acquire any blocks they need rather than being limited to the ones in a single torrent. BitSwap operates as a barter system where nodes have a “have list” and a “want list” which they need to “work” for. To prevent leeches, the probability of a node sending to a debtor node decreases and the debt increases. In practice, a sigmoid function can be used: \(P(\text{send} | r) = 1 - \frac{1}{1+e^{(6-3r)}}\), where \(r\) is the debt ratio and defined as \(\frac{\text{bytes_sent}}{\text{bytes_received+1}}\).

The protocol happens in several stages for a successful exchange, including sharing ledgers, sharing want lists, sending blocks, and closing the connection.

Data is stored in a Merkle DAG structure that enables content addressing, tamper resistance, and deduplication. The object model of IPFS is similar to that of Git’s, so version control tools can be available to IPFS users. IPFS objects can be traversed with a string path API and the lookup performance can be improved by caching or flattening trees.

The Merkle DAG contains permanent objects and IPNS enables mutable pointers to the Merkle DAG. Mutable, self-certified names can be constructed in a cryptographically assigned global namespace. IPNS is not inherently human-friendly, and this issue can be mitigated through solutions such as peer links, name shortening, pronounceable identifiers, and DNS TXT records.

IPFS offers benefits such as being DDoS-resistant, being censorship-resistant, saving bandwidth, preventing hotspots from becoming bottlenecks, and making content permanent.

The paper does not seem to address security issues related to IPFS. Based on the design of IPFS, anyone with the hash of a file can acquire the contents of the file. There’s currently no mechanism for managing file permissions, and it is up to the user to encrypt confidential files themselves. Deduplication and encryption can be conflicting goals. On the other hand, an opposite problem can be content discovery and indexing content without knowing hashes, which can make it difficult to build a search engine.

Another challenge of IPFS is serving dynamic websites. It seems that IPFS is better suited for transferring static files rather than supporting real time interactive applications.

In addition, IPFS is only useful when users actually participate in the network. Currently, to incentivize adoption, filecoin can be earned by users hosting files, and it seems to be a more environment-friendly mining mechanism than the proof of work mechanism used by Bitcoin.