Table of Links
Abstract/Zusammenfassung
Publications
Acknowledgements
CHAPTER 1: INTRODUCTION
-
Introduction
1.1 Overview of thesis contributions
1.2 Thesis outline
CHAPTER 2: BACKGROUND
2.1 Blockchains & smart contracts
2.2 Transaction prioritization norms
2.3 Transaction prioritization and contention transparency
2.4 Decentralized governance
2.5 Blockchain Scalability with Layer 2.0 Solutions
CHAPTER 3. TRANSACTION PRIORITIZATION NORMS
-
Transaction Prioritization Norms
3.1 Methodology
3.2 Analyzing norm adherence
3.3 Investigating norm violations
3.4 Dark-fee transactions
3.5 Concluding remarks
CHAPTER 4. TRANSACTION PRIORITIZATION AND CONTENTION TRANSPARENCY
-
Transaction Prioritization and Contention Transparency
4.1 Methodology
4.2 On contention transparency
4.3 On prioritization transparency
4.4 Concluding remarks
CHAPTER 5. DECENTRALIZED GOVERNANCE
-
Decentralized Governance
5.1 Methodology
5.2 Attacks on governance
5.3 Compound’s governance
5.4 Concluding remarks
CHAPTER 6. RELATED WORK
6.1 Transaction prioritization norms
6.2 Transaction prioritization and contention transparency
6.3 Decentralized governance
CHAPTER 7. DISCUSSION, LIMITATIONS & FUTURE WORK
7.1 Transaction ordering
7.2 Transaction transparency
7.3 Voting power distribution to amend smart contracts
Conclusion
Appendices
APPENDIX A: Additional Analysis of Transactions Prioritization Norms
APPENDIX B: Additional analysis of transactions prioritization and contention transparency
APPENDIX C: Additional Analysis of Distribution of Voting Power
Bibliography
3.2 Analyzing norm adherence
In this section, we analyze whether Bitcoin miners adhere to prioritization norms, when selecting transactions for confirmation. To this end, we first investigate whether transaction ordering matters to Bitcoin users in practice, i.e., are there times when transactions suffer extreme delays and do users offer high transaction fees in such times to confirm their transactions faster? We then conduct a progressively deeper investigation of the norm violations, including potential underlying causes, which we investigate in greater detail in the subsequent sections.
3.2.1 Does transaction ordering matter?
A congestion in the Mempool leads to contention among transactions for inclusion in a block. Transactions that fail to contend with others (i.e., win a spot for inclusion) experience inevitable delays in commit times. Transaction ordering, hence, has crucial implications for users when the Mempool experiences congestion. For instance, the Bitcoin Core code and most of the wallet software rely on the distribution of transactions’ fee rates included in previous blocks to suggest to users the fees that they should include in their transactions (bitcoin.org, 2023; Coinbase, 2021; Lavi et al., 2019). Such transactionfee predictions from any predictor, which assume that miners follow the norm, will be misleading.[9] Below, we examine whether Mempool in a real-world blockchain deployment experiences congestion and its impact on transaction-commit delays. We then analyze whether, and how, users adjust transaction fees to cope with congestion, and the effect of these fee adjustments on commit delays.
Congestion and delays
Bitcoin’s design—specifically, the adjustment of hashing difficulty to enforce a constant mining rate—ensures that there is a steady flow of currency generation in the network. The aggregate number of size-limited blocks mined in Bitcoin, consequently, increases linearly over time (Figure 2.2a). Transactions, however, are not subject to such constraints and have been issued at much higher rates, particularly, according to Figure 2.2a, since mid-2017: 60% of all transactions ever introduced were added in only in the last 3.5 years of the nearly decade-long life of the cryptocurrency. Should this growth in transaction issued continue to hold, transactions will increasingly have to contend with one another for inclusion within the limited space (of 1 MB) in a block. Below, we empirically show that this contention among transactions is already common in the Bitcoin network.
Using the data sets A and B (refer §3.1.1), we measured the number of unconfirmed transactions in the Mempool, at the granularity of 15 s. Per Figure 3.2a, congestion in Mempool is typical in Bitcoin: During the three-week period of A, the aggregate size of all unconfirmed transactions was above the maximum block size (of 1 MB) for nearly 75% of the time; per data set B the Mempool was congested for nearly 92% of the time period. Figure 3.2b provides a complementary view of the Mempool congestion in A, by plotting the Mempool size as a function of time. The measurements reveal a huge variance in Mempool congestion, with size of unconfirmed transactions at times exceeding 15-times the maximum size of a block. Transactions queued up during such periods of high congestion will have to contend with one another until the Mempool size drains below 1 MB. These observations also hold in data set B, the details of which are in §A.1.
The Mempool congestion, which in turns leads to the contention among transactions for inclusion in a block, has one serious implication for users: delays in transactioncommit times. While 65% (60%) of all transactions in data set A (B) get committed in the next block (i.e., in the block immediately following their arrival in the Mempool), Figure 3.3a shows that nearly 15% (20%) of them wait for at least 3 blocks (i.e., 30 minutes on average). Moreover, 5% (10%) of the transactions wait for 10 or more blocks, or 100 minutes on average, in data set A (B). While no transaction waited for more than a day in data set A, a small percentage of transactions waited for up to five days (because of the high levels of congestion in June 2019) in data set B.
Takeaways. Mempool is typically congested in Bitcoin. Transactions, hence, typically contend with one another for inclusion in a block. The Mempool congestion has nontrivial implications for transaction-commit times.
Transaction fee rates and delays
To combat the delays and ensure that a transaction is committed “on time” (i.e., selected for inclusion in the earliest block), users may include a transaction fee for incentivizing the miner. While the block reward from May 11, 2020 is 6.25 BTC, the aggregate fees accrued per block is becoming considerable (i.e., 6.29% of the total miner revenue in 2020 per Table A.1 in §A.2). Prior work also show that revenue from transaction fees is clearly increasing (Easley et al., 2017). With the volume of transactions growing aggressively (Figure 2.2a) over time and the block rewards, in Bitcoin, halving every four years, it is inevitable that transaction fees will be an important, if not the only, criterion for including a transaction, leading possibly to undercutting attacks (Carlsten et al., 2016). Below, we analyze whether Bitcoin users incentivize miners via transaction fees and if such incentives are effective today.
Our premise is that the (high) fee rates correlate with the level of Mempool congestion. Said differently, we hypothesize that users increase the fee rates to curb the delays induced by congestion. To test this hypothesis, we separate the Mempool snapshots (cf. §3.2.1) into 4 different bins. Each bin corresponds to a specific level of congestion identified by the Mempool size as follows: lower than 1 MB (no congestion), in (1, 2] MB (lowest congestion), in (2, 4] MB, and higher than 4 MB (highest congestion). The fee rates of transactions observed in the different bins or congestion levels, in Figure 3.3c, then
validates our hypothesis: Fee rates are strictly higher (in distribution, and hence also on average) for higher congestion levels.
3.2.2 Do miners follow the norms?
Whether miners follow the transaction prioritization norms (as widely assumed) has implications for both Bitcoin and its users: The software used by users, for instance, assumes an adherence to these norms when suggesting a transaction fee to the user (bitcoin.org, 2023; Coinbase, 2021; Lavi et al., 2019). Deviations from these norms, hence, have far-reaching implications for both the blockchain and crucially for Bitcoin users.
Fee rate based selection when mining new blocks
Our finding above show that transactions offering higher fee rates experience lower confirmation delays suggests that miners tend to account for transaction fee rates when choosing transactions for new blocks. We now want to check, however, if transaction fee rate is the primary or the sole determining factor in transaction selection. To this end, we check our data sets for transaction pairs, where one transaction was issued earlier and has a higher fee rate than the other, but was committed later than the other. The existence of such transaction pairs would unequivocally show that fee rate alone does not explain the order in which they are selected.
Another potential source of violations is Bitcoin’s dependent (or, parent and child) transactions, where the child pays a high fee to incentivize miners to also confirm the
parent from which it draws its inputs. This mechanism enables users to “accelerate” a transaction that has been “stuck” because of low fee (CoinStaker, 2018). As the existence of such child-pays-for-parent (CPFP) transactions (formally defined in §A.5) would introduce false positives in our analysis we decided to discard them. Figure 3.5b shows that the violations exist even after discarding all such dependent transaction pairs.
Fee rate based ordering within blocks
Figure 3.6a shows the cumulative distribution of PPE values for each block in our data set C, containing 53,214 blocks. 80% of the blocks have PPE values less than 4.03%. The mean PPE across all blocks is 2.65%, with a standard deviation of 2.89. Per this plot the position of a transaction within a block can be predicted with very high accuracy (within a few percentile position error), suggesting that transactions are by and large ordered within a block based on their fee rate. Figure 3.6b shows PPE values separately for each of the 6 largest mining pools in data set C. The plots show that all mining pools by and large follow the norm, though some like ViaBTC seems to deviate slightly more from the norm compared to the other mining pools.
Fee rate threshold for excluding transactions
We collected data set A using a default Bitcoin node, and our node, hence, did not accept or record low-fee transactions. When gathering data set B, however, we configured our Bitcoin node to accept all transactions, irrespective of their fee rates. In data set B, our node, consequently, received 1084 transactions that offered less than the recommended fee rate and 489 (45.11%) of them were zero-fee transactions. From these low fee rate transactions, only 53 (4.89%) were confirmed in the Bitcoin blockchain; 9 (16.98%) were confirmed months after they were observed in our data set. In contrast, the vast majority (99.7%) of the transactions that offered greater than or equal to the recommended fee rate were all (eventually) confirmed. Interestingly, the low-fee transactions were confirmed by just three mining pools: F2Pool, ViaBTC, and BTC.com included 38, 14, and 1 lowfee transactions, respectively. Our findings suggest that while the norm of ignoring transactions offering less than the recommended fee rate is being by and large followed by all miners, a few occasionally deviate from the norm.
Author:
(1) Johnnatan Messias Peixoto Afonso
[9] Coinbase, one of the top cryptocurrency exchanges, does not allow users to set transaction fees manually. Instead, it charges a fee based on how much they expect to pay for the concerned transaction, which in turn relies on miners following the norm (Coinbase, 2021).
