Research Pulse #75 07/25/2022

  1. A ZK-SNARK based Proof of Assets Protocol for Bitcoin Exchanges
    Author: Swaroopa Reddy B

This paper proposes a protocol for proof of assets of a bitcoin exchange using the Zero-Knowledge Succinct NonInteractive Argument of Knowledge (ZK-SNARK) without revealing either the bitcoin addresses of the exchange or balances associated with those addresses. The proof of assets is linked to proving the total value of bitcoins the exchange has authority to spend using its private keys. We construct a ZK-SNARKS system to verify the knowledge of the private keys corresponding to the assets of the exchange. We show that the proof generation time, proof size, and verification time are efficient in practice through the simulation results.

Link to Paper (Research Gate)

  • Centralized exchanges serve as a stepping stone into the crypto economy, but very little is known about their operations, especially as it relates to their solvency.

  • Proof-of-Reserves (PoR) is a schema that enables any entity holding cryptoassets on behalf of third parties to prove the number of assets held in reserves. With this information, market participants can have assurances about the third party’s ability to meet their obligations if there is a run for liquidity (i.e. a bank run).

  • Nevertheless, PoR has not been widely adopted because of privacy concerns. Even exchanges that embrace transparency are unwilling to report their reserves as this information can be used to infer their profitability and operations.

  • This paper introduces an interesting PoR schema that uses zk-SNARKs to protect the privacy of the third party. It enables entities such as exchanges to prove that they are solvent without revealing critical information about their operations.

  1. An Exploratory Study on Solidity Guards and Ether Exchange Constructs
    Authors: Darin Verhejike and Henrique Rocha

Ethereum is a blockchain platform that enables the use of smart contracts. Smart contracts will execute a set of instructions without an intermediary party when called upon. The possibility to make calls to another contract or exchange cryptocurrency allows for potential exploits to occur, most notable reentrancy. The Solidity language for coding smart contracts has syntactic constructs created to be safer alternatives, and guards to aid in securing code against exploits. In this paper, we collect a total of 26,799 verified Solidity smart contracts from Etherscan, to analyze the language constructs used in calling another contract or exchanging ether. We also analyze the usage of guards to make the code more secure. For instance, even though call is the unsafest function, it is still used by 50% of the contracts in our dataset. The safe method transfer is used by approximately one-third of contracts, and send is rarely used. We noticed that contracts using call have a higher average and median size in Lines of Code than normal. We also found an increased percentage of call contracts using more guards. Moreover, 97% of all contracts are using the require guard, with 23 uses of require on average per contract. This may be an indication that Solidity developers are using more guards to prevent exploits in their contracts.

Link to Paper (IEEE Xplore)

  • Reentrancy bugs have led to multi-million-dollar losses like the notorious The DAO hack in 2016 – an event that was a turning point in the history of smart contract development and entailed a complete re-evaluation of how applications are written.

  • This paper analyzes the different constructs employed by smart contract developers to enable their applications to call third-party contracts and, more critically, approve the transfer of funds held in escrow.

  • Interestingly, the authors find increased usage of guards against such exploits which is a good sign that the smart contract development ecosystem is evolving.

  1. HuntFlow: Search the Arithmetic Vulnerability in Ethereum Smart Contract
    Authors: Ke Zhou, Jieren Cheng, Le Liu, and Victor S. Sheng

With the development of blockchain technology, smart contracts have been applied in more and more industries. Smart contracts are immutable once deployed, so unaudited smart contracts can easily cause economic losses. Arithmetic vulnerabilities usually refer to integer overflow vulnerability in smart contracts, and integer calculations in smart contracts are usually related to the transfer of digital assets. However, most of the existing smart contract auditing methods are inefficient and cannot be applied to the rapidly developing blockchain technology. To address these problems mentioned above, we propose a lightweight Ethereum smart contract arithmetic vulnerability detection model called HuntFlow, which can automatically detect the arithmetic vulnerabilities in the smart contract on a lightweight computer without expert knowledge. We first obfuscate 142 original opcodes into a set of 28 vulnerability features based on the characteristics of arithmetic vulnerabilities. And then we use Long-Short-Term-Memory (LSTM) network with attention mechanism for training and testing. The experimental result shows that the vulnerability features is better than original opcode for detecting arithmetic vulnerabilities. Moreover, the detection time of HuntFlow is greatly shortened than traditional tools, it costs only 0.028 s for each smart contract.

Link to Paper (Springer)

  • Integer overflow bugs are another type of critical vulnerability that has affected many ERC20 contracts over time.

  • This paper introduces a vulnerability detection model called HuntFlow that can automatically detect the arithmetic vulnerabilities in a smart contract.

  • The authors claim that HuntFlow is a considerable iteration upon previous vulnerability detection models for arithmetic bugs, as it uses less gas and can be run on lightweight computers.

  1. Zswap: zk-SNARK Based Non-Interactive Multi-Asset Swaps
    Authors: Felix Engelmann, Thomas Kerber, Markulf Kohlweiss, and Mikhail Volkhov

Privacy-oriented cryptocurrencies, like Zcash or Monero, provide fair transaction anonymity and confidentiality, but lack important features compared to fully public systems, like Ethereum. Specifically, supporting assets of multiple types and providing a mechanism to atomically exchange them, which is critical for e.g. decentralized finance (DeFi), is challenging in the private setting. By combining insights and security properties from Zcash and SwapCT (PETS 21, an atomic swap system for Monero), we present a simple zk-SNARKs based transaction scheme, called Zswap, which is carefully malleable to allow the merging of transactions, while preserving anonymity. Our protocol enables multiple assets and atomic exchanges by making use of sparse homomorphic commitments with aggregated open randomness, together with Zcash friendly simulation-extractable non-interactive zero-knowledge (NIZK) proofs. This results in a provably secure privacy-preserving transaction protocol, with efficient swaps, and overall performance close to that of existing deployed private cryptocurrencies. It is similar to Zcash Sapling and benefits from existing code-bases and implementation expertise.

Link to Paper (Proceedings on Privacy Enhancing Technologies)

  • MEV is perhaps one of the fastest-growing segments in this industry with hundreds of millions of dollars extracted last year alone via sandwich attacks, which is a type of front-running strategy.

  • Many see this type of attack as a privacy failure and various solutions have been proposed over the years to diminish, or outright eliminate, the ability to perform front-running in Decentralized Exchanges (DEXs).

  • This paper introduces a schema that uses zk-SNARKs to implement a swap (exchange) protocol that replicates Automated Market Makers (AMMs) in a private setting.

4 Likes

those are very interesting use cases of ZK crypto!

4 Likes

There’s a more recent version of the first ZK paper that can be viewed here [2208.01263] A ZK-SNARK based Proof of Assets Protocol for Bitcoin Exchanges

(The author has also recently published a summary of it on our forum: