Security of Decentralized Financial Technologies

We review the succession of work leading to concrete bounds for the failure probability of Bitcoin’s proof-of-work mechanism in adversarial synchronous networks. While Bitcoin uses proof-of-work sequentially, we propose to study concrete bounds for state replication protocols using non-sequential proof-of-work. Numerical analyses suggest that after the typical interval of 10 minutes, a novel parallel proof-of-work protocols offers two orders of magnitude more security than sequential proof-of-work. This means that state updates could be sufficiently secure to support commits after one block (i.e., after 10 minutes), removing the risk of double-spending in many applications.

Front-running attacks, which benefit from advanced knowledge of pending transactions, have proliferated in the blockchain space since the emergence of decentralized finance. Front-running causes devastating losses to honest participants and continues to endanger the fairness of the ecosystem. We present Flash Freezing Flash Boys (F3B), a blockchain architecture that addresses front-running attacks using threshold cryptography. In F3B, a user generates a symmetric key to encrypt their transaction, and once the underlying consensus layer has committed the transaction, a decentralized secret-management committee reveals this key. F3B mitigates front-running attacks because an adversary can no longer read the content of a transaction before commitment, thus preventing the adversary from benefiting from advanced knowledge of pending transactions. Unlike other threshold-based approaches where the user encrypts their transaction based on the key of a future block, F3B enables the user to generate their key for each transaction. This feature ensures the confidentiality that all uncommitted transactions are not revealed, even if they are delayed. F3B addresses front-running at the execution layer; thus, our solution is agnostic to the underlying consensus algorithm and compatible with existing smart contracts. We evaluated F3B based on Ethereum, demonstrating a 0.05% transaction latency overhead with a secret-management committee of 128 members, indicating our solution is practical at a low cost.

Within just four years, the blockchain-based Decentralized Finance (DeFi) ecosystem has accumulated a peak total value locked (TVL) of $253 billion USD. Unfortunately, this increase in DeFi’s popularity has been accompanied by a number of attacks that have cost at least $3.24 billion USD between 2018 and 2022. In this talk, we offer a method for measuring, analyzing, and comparing DeFi attacks. By presenting cutting-edge defense strategies that go beyond the conventional smart contract code auditing approaches, we also hope to summarize the insights discovered to strengthen DeFi security.

Blockchain protocols’ primary security goal is consensus: one version of the global ledger that everyone in the network agrees on. Their proofs of security depend on assumptions on how well their peer-to-peer (P2P) overlay networks operate. Further, the Defi ecosystem built on top of these protocols also explicitly and inexplicably make similar assumptions.Yet, surprisingly, little is understood about what factors influence the P2P network properties. In this talk, I present work where we extensively study the Ethereum P2P network’s connectivity and its block propagation mechanism. We gather data on the Ethereum network by running the official Ethereum client, geth, modified to run as a “super peer” with many neighbors. We run this client in North America for over seven months, as well as shorter runs with multiple vantages around the world. Our results expose an incredible amount of churn, and a surprisingly small number of peers who are actually useful (that is, who propagate new blocks). We also find that a node’s location has a significant impact on when it hears about blocks, and that the precise behavior of this has changed over time (e.g., nodes in the US have become less likely to hear about new blocks first). Our results motivate questions on how these open systems can be manipulated and whether we should move to more structured/purposeful networks.

Bitcoin and other cryptocurrencies have recently introduced support for Schnorr signatures whose cleaner algebraic structure, as compared to ECDSA, allows for simpler and more practical constructions of highly demanded “t-of-n” threshold signatures. However, existing Schnorr threshold signature schemes still fall short of the needs of real-world applications due to their assumption that the network is synchronous and due to their lack of robustness, i.e., the guarantee that honest signers are able to obtain a valid signature even in the presence of other malicious signers who try to disrupt the protocol. This hinders the adoption of threshold signatures in the cryptocurrency ecosystem, e.g., in second-layer protocols built on top of cryptocurrencies.

In this work, we propose ROAST, a simple wrapper that turns a given threshold signature scheme into a scheme with a robust and asynchronous signing protocol, as long as the underlying signing protocol is semi-interactive (i.e., has one preprocessing round and one actual signing round), provides identifiable aborts, and is unforgeable under concurrent signing sessions. When applied to the state-of-the-art Schnorr threshold signature scheme FROST, which fulfills these requirements, we obtain a simple, efficient, and highly practical Schnorr threshold signature scheme.

Support for Schnorr signatures has been activated in Bitcoin in the as part of “Taproot” softfork. This talk sheds light on the motivation behind this technical change, namely a better provably security as compared to ECDSA, improved efficiency, and most importantly the possibility to construct more practical variants of advanced signature protocols such as multisignatures, threshold signature and blind signatures.

We then give an overview of the state-of-art in these areas, touching upon recent results in the area of Schnorr multisignatures signatures (e.g., MuSig2, FROST, ROAST) as well as blind signatures (e.g., Fuchsbauer, Plouviez and Seurin 2020). We also discuss open research questions in this area, e.g., how multisignatures and threshold signatures can be nested (with a tree-style key setup) while maintaining security under concurrent sessions and privacy, and whether the practicality of distributed key-generation protocols can be improved.

The Decentralized Finance (DeFi) ecosystem has proven to be immensely popular in facilitating financial operations such as lending and exchanging assets, with Ethereum-based platforms holding a combined amount of more than $30$ billion USD. The public availability of these platforms’ code together with real-time data on all user interactions and platform liquidity has given rise to sophisticated automatic tools that recognize profit opportunities on behalf of users and seize them.

In this work, we formalize three core DeFi primitives which together are responsible for a daily volume of over 100 million USD in Ethereum-based platforms alone: (1) lending and borrowing funds, (2) liquidation of insolvent loans using swaps, and (3) using flashswaps to close arbitrage opportunities between cryptocurrency exchanges. The profit which can be made from each primitive is then cast as an optimization problem that can be solved.

We use our formalization to analyze several case studies for each primitive, showing that popular platforms and tools which promise to automatically optimize profits for users, actually fall short. In specific instances, the profits can be increased by more than $100\%$, with the highest amount of “missed” revenue by a single suboptimal action equal to $428.14$ ETH, or roughly $517$K USD.

Finally, we show that many missed opportunities to make a profit do not go unnoticed by other users. Indeed, suboptimal transactions are sometimes immediately followed by “trailing” back-running transactions which extract additional profits using similar actions. By analyzing a subset of these events, we uncover that users who frequently create such trailing transactions are heavily tied to specific miners, meaning that all of their transactions appear only in blocks mined by one miner in particular. As a portion of the backrun non-optimal transactions are private, we hypothesize that the users who create them are, in fact, miners (or users collaborating with miners) who use inside information known only to them to make a profit, thus gaining an unfair advantage.

In this discussion group, we considered decentralized finance systems and cryptocurrencies from the point of view of a (human) user. We identified a number of interesting topics that can guide future research, as well as some related challenges.

Trust of users in the system seems crucial for their participation. A tentative list of factors influencing trust may include “fairness” of transaction ordering, which influences who can buy rare goods (such as NFTs). The presence of MEVs, and the fact that currently mostly powerful market players can utilize those, could be adverse for the trust; and obviously “stability” as discussed in another group. Another topic may be privacy related concerns, and the question with regards to which entities users wish privacy of financial transactions. Governance and decision making in the DeFi & cryptocurrency space is another interesting factor in itself, and may again influence trust in a system. The usability of crypto-wallets provides some very interesting use-case for user authentication, due to their pronounced requirements in availability.

We also identified a number of challenges that need to be overcome to conduct research. Recruitment of users for surveys or user studies is not easy as central methods to directly contact such users are rare, and for services claiming to sample from blockchain users it’s not easy to (non-intrusively) verify those claims. This is additionally complicated by the high heterogeneity of the user-base of cryptocurrencies/DeFi (found by previous studies) and wrong mental models. In many fields, recruitment of decision makers as research subjects (here miners or developers) is even more difficult. It is quite unclear at the moment how a sensible sample of miners could be recruited. This is related to similar problems for sampling decision makers in software design.

In this work, we propose Peacock Mantis Shrimp, a checkpointing mechanism onto Bitcoin for any PoS consensus scheme. It supports PoS schemes with an arbitrary number of validators, and has an efficient checkpoint verification requiring auditors to download only a small number of Bitcoin full blocks. Peacock Mantis Shrimp achieves this by randomly sampling validators into subgroups which then commit a previously agreed-upon checkpoint onto the Bitcoin blockchain using specially crafted threshold signed transactions. Peacock Mantis Shrimp improves on the state-of-the-art that either suffers from scaling constraints, supporting only a limited number of validators, or requires auditors to examine the full Bitcoin chain. We analyze parametrizations and show the overall failure probability can be driven as low as desired.

Cross-Chain Communication received a lot of attention recently due to growing interoperability needs in DeFi and major security flaws in existing protocols that had caused significant financial loss for their users. This session came forth due to a recently published work, zkBridge [5], that improves the safety of cross-chain communication by replacing trusted committees (a single point failure) with zero-knowledge proofs (ZKP). While improving safety is crucial, the privacy implication of bridges received much less attention. Most deployed systems do not provide privacy guarantees and in particular allow an observer to link bridged assets to the original ones. Such linkage could affect the frangibility of assets (since minted coins inherit their history from the source chain) and even erode user privacy (e.g., deanonymization attacks on one chain could now impact other chains through bridges).

This article provides a summary proposed solutions for privacy-preserving, and discusses the opportunities and challenges. The discussion evolved around (i) the current solution space for privacy in cross-chain solutions, (ii) unique use-cases for private cross-chain communication, (iii) potential pitfalls in privacy preserving cross-chain solutions with regard to interoperability of private and public blockchains and (iv) alternatives to zkSNARK based solutions for private cross-chain bridges.

Generally, cross-chain exchanges of assets can be facilitated by either atomic swaps or bridges. (Here we leave sidechains (such as [6]) out of scope since we target solutions that can bridge two existing blockchains.) Depending on whether the source/destination blockchain provides native privacy guarantees, such exchanges can happen in one of the following scenarios:

1. 1.

   public $\to$ public

2. 2.

   public $\to$ private

3. 3.

   private $\to$ public

4. 4.

   private $\to$ private

Further, we find that the following (rather informal) privacy goals are essential – (i) hiding the fact that a swap/bridge of an asset takes place, (ii) hiding the amount / type of the involved asset and (iii) ensuring unlinkability between participants. We elaborate on privacy-preserving approaches to cross-chain communication that use atomic swaps and bridges, and in which scenarios each of them are applicable as well as sufficiently researched, in the following.

In an atomic swap, Alice intends to exchange X tokens A (native to blockchain A) for Y tokens B (native to blockchain B), such that the asset exchange is included atomically in both blockchains. Simply, this exchange can be achieved with HTLCs. However, HTLCs do not provide privacy, such that recent work proposed adaptor signatures to atomically release secrets whilst assuring privacy [1, 4]. However, we find that applying an atomic swap based on adaptor signatures inherently depends of the confidentiality of the underlying blockchain. Further, we find that such a construction only works if blockchain A is public (i.e. the transaction where the first transaction is included, case 1 + 2). If the sender blockchain is private (e.g., for shielded addresses in Zcash), there is no way to guarantee atomic inclusion in existing constructions. [4] suggests that that their method can be extended to shielded coins with 2PC generation of SNARKs, though details are not specified.

While atomic swaps allows a pair of users to exchange assets, a bridge can enable arbitrary message passing between two chains (thus atomic swaps can be seen as a specific application of a bridge). Typically bridges either depends on (i) a committee or (ii) a relayer network that relays the block header. Alternative approaches also provide cross-chain capabilities through TEEs and MPC [2, 3]. As the current state-of-the-art converges on a construction based on a relayer network, we discussed potential extensions to bridges in this domain. As a result, we find that bridges relying on a relayer with an updater contract are inherently incapable of obfuscating the fact that a bridging of assets took place. However, by applying a blockchain mixer on both the source and receiver chain, one can hide the amount transferred as well as provide unlinkability of sender and receiver accounts. Note, that a single mixer on the source chain is sufficient to ensure unlinkability, whereas a second mixer on the receiving chain can ensure confidentiality of the received amount by the receiver. Note that a private bridge is currently only possible for cross-chain communication between two public chains (Case 1), due to non-existent deployments of privacy-preserving smart contract enabled blockchains (which may change in the future).

In comparison, existing proposals for both private atomic swaps and private bridges face unique limitations that are partially exclusive. We also noted that performing generalized, privacy preserving smart contract function calls, where the invoked function resides on a different chain and the result of the function call needs to be returned to the invoker, can be especially challenging and is an equally unsolved problem, even in a case that involves no privacy. In general, it depends on the use-case at hand, whether one needs to apply a privacy preserving atomic swap or bridge. We deem further investigation of hybrid approaches, that leverage the benefits of both privacy preserving atomic swaps and bridges, an interesting area of future work.