- Bitcoin Security-Latency Under Network Delay
Authors: Mustafa Doger and Sennur Ulukus
We improve security-latency bounds of Nakamoto consensus by analyzing the race between adversarial and honest chains in three different phases: pre-mining, confirmation and post-confirmation. We find the probability distribution of the length of the adversarial chain and the rigged adversarial chain under jumper models during the confirmation interval. We analyze certain properties of this race to model pre-mining and post-confirmation phases with random walks that provide tighter bounds than existing results. Combining all three phases provides novel upper and lower bounds for blockchains with small λ∆.
-
Public blockchains operate in adversarial environments and are susceptible to a plethora of attacks. Many attacks involve reorganizing the blocks in the blockchain with so-called reorgs, which can impact recently added transactions.
-
As such, users are encouraged to wait for a number of blocks to be mined atop the block with their transaction before considering it final. For example, the popularized rule of thumb for bitcoin is to wait for 6 blocks to elapse before considering a transaction final.
-
This paper provides a fascinating model which attempts to quantify the factors involved when considering a transaction final. Instead of a fixed number, the paper proposes a system of upper and lower bounds to reason about confirmation requirements.
- Topological Evolution Analysis of Payment Channels in the Lightning Network
Authors: Gustavo F. Camilo, Gabriel Antonio F. Rebello, Lucas Airam C. de Souza, Maria Potop-Butucaru, Marcelo D. Amorim, Miguel Elias M. Campista, and Luís Henrique M. K. Costa
Payment channel networks (PCN) offer a fast, secure, and distributed alternative payment method while avoiding slow consensus mechanisms of blockchains. Nonetheless, the PCN topology directly influences the performance, cost, and payment success rate. This paper analyzes the evolution of the Lightning Network topology, which is currently the leading payment channel network. We reconstruct the network graph using real data from a set of channel announcement messages collected between January 2020 and August 2021. Our analysis uses typical graph metrics, such as transitivity, diameter, and degree centrality, to evaluate the state and evolution of the network. The results show a strong trend in resource and connectivity centralization. Only 0.38% of nodes concentrate 50% of the network capacity, exposing a vulnerability to targeted attacks. As with the Bitcoin cryptocurrency, the centralization of the Lightning PCN directly contrasts with the original goal of a fully-decentralized network. Moreover, the low network transitivity compromises channel rebalancing techniques, which contribute to the stability of the system. This trend evidences the need for new attachment policies prioritizing greater network decentralization and robustness.
-
The Lightning Network has experienced various changes over the past year, both in terms of liquidity and channel dynamics.
-
These changes have been predominantly driven by users leveraging the technology for new use cases as well as centralized companies more actively relying on it.
-
This paper presents some fascinating insights into the topology of the network as it experienced these changes between 2020 and 2021.
-
In order to reason about Lightning as a network, they employed traditional graph theory metrics and real messages collected from the network.
- Finding the Right Curve: Optimal Design of Constant Function Market Makers
Authors: Mohak Goyal, Geoffrey Ramseyer, Ashish Goel, and David Mazières
Constant Function Market Makers (CFMMs) are a crucial tool for creating exchange markets, have been deployed effectively in the context of prediction markets, and are now especially prominent within the modern Decentralized Finance ecosystem. We show that for any set of beliefs about future asset prices, there exists an optimal CFMM trading function that maximizes the fraction of trades that a CFMM can settle. This trading function is the optimal solution of a convex program. This program therefore gives a tractable framework for market-makers to compile their belief-distribution on the future prices of the underlying assets into the trading function of a maximally capital-efficient CFMM.
Our optimization framework further extends to capture the tradeoffs between fee revenue, arbitrage loss, and opportunity costs of liquidity providers. Analyzing the program shows how consideration of profit and loss qualitatively distort the optimal liquidity allocation.
Our model additionally explains the diversity of CFMM designs that appear in practice. We show that careful analysis of our convex program enables inference of a market-maker’s beliefs about future asset prices, and show that these beliefs mirror the folklore intuition for several widely used CFMMs. Developing the program requires a new notion of the liquidity of a CFMM at any price point, and the core technical challenge is in the analysis of the KKT conditions of an optimization over an infinite-dimensional Banach space.
-
Unlike Centralized Exchanges (CEXs), Decentralized Exchanges (DEXs) make use of no order books. Instead, DEX trades are priced on the basis of a relatively straightforward constant function.
-
Much has been written on the trade-offs of different constant functions, and there are many live implementations that take advantage of these trade-offs. This construct has been generalized as the Constant Function Market Maker (CFMM), but implementations can differ considerably.
-
For example, the Curve exchange uses a pricing function better suited for stablecoins, whereas Uniswap is better positioned for more volatile assets.
-
This paper does a fantastic job discussing the mathematical underpinnings of CFMMs and the trade-offs at play. The authors also provide an interesting CFMM function that prices DEX swaps more efficiently so that liquidity is better accounted for.
- Measuring Polkadot: The Impact of Tor and a VPN on Polkadot’s Performance and Security
Author: Just van Stam
Begun in 2020, Polkadot is one of the largest blockchains in market capitalization and development. However, privacy on the Polkadot network has yet to be one of the key focus points. Especially unlinkability between the user’s IP address and Polkadot address is essential. Without this unlinkability, users are vulnerable to targeted ads, manipulation, blackmail, reputational damage, financial loss, physical harm, discrimination, and more. This thesis investigates the viability of Tor or a VPN with Polkadot as external privacy-enhancing tools to hide the user’s IP address, as users aiming to achieve unlinkability cannot easily change the Polkadot code.
To analyze the viability, we set up a measurement study to examine the performance of a Polkadot full node behind Tor or a VPN. We investigated, among other things, the latency, throughput, and the number of discovered and connected peers to determine the performance of three Polkadot full nodes located in London, Seoul, and North California. Furthermore, we did a security analysis to determine any vulnerabilities that could emerge from using Polkadot with either of the network environments. And we investigated in-depth the susceptibility of the Polkadot node to an Eclipse attack, as previous research has shown that Bitcoin with Tor was vulnerable to an Eclipse attack.
Our results show that a Polkadot node with Tor has considerably high latency and cannot maintain long-lasting connections. The short connection time decreases the time to perform an Eclipse attack on a Polkadot node from a couple of months and weeks for the normal and VPN environment to potentially six days or less for the Tor environment. We calculated the cost of running an Eclipse attack to be approximately €482 per week. The Polkadot node behind the VPN does perform considerably better. The Polkadot node in London, behind the VPN located in Frankfurt, performed similarly in terms of latency to the Polkadot node in a normal network environment. However, the Polkadot nodes in both the Tor and VPN environment have only outgoing connections. If too many nodes ran behind one of these environments, fewer peers would be able to establish connections with one another, resulting in network partitions or network failure.
This study emphasizes the importance of unlinkability between a Polkadot user’s address and IP. However, using Tor or a VPN as privacy-enhancing tools could impact the security of the Polkadot node and the whole Polkadot network. So users should avoid using Tor with Polkadot and carefully consider the tradeoff between privacy and security when using a VPN. The security issues mentioned in this thesis should be further investigated and tested. Furthermore, a default solution built into the Polkadot source code should be investigated.
- Polkadot is a nascent smart contract platform that implements a sharded architecture natively. As a new network, there aren’t sufficient metrics to contextualize its health, capabilities, and growth.
- This paper sheds light on Polkadot via a network-wide analysis and showcases interesting metrics related to node performance when running Polkadot using a VPN.