Table of Links Abstract/Zusammenfassung Abstract/Zusammenfassung Publications Publications Acknowledgements Acknowledgements CHAPTER 1: INTRODUCTION CHAPTER 1: INTRODUCTION Introduction
1.1 Overview of thesis contributions
1.2 Thesis outline Introduction
1.1 Overview of thesis contributions
1.2 Thesis outline Introduction Introduction 1.1 Overview of thesis contributions 1.1 Overview of thesis contributions 1.2 Thesis outline 1.2 Thesis outline CHAPTER 2: BACKGROUND CHAPTER 2: BACKGROUND 2.1 Blockchains & smart contracts 2.1 Blockchains & smart contracts 2.2 Transaction prioritization norms 2.2 Transaction prioritization norms 2.3 Transaction prioritization and contention transparency 2.3 Transaction prioritization and contention transparency 2.4 Decentralized governance 2.4 Decentralized governance 2.5 Blockchain Scalability with Layer 2.0 Solutions 2.5 Blockchain Scalability with Layer 2.0 Solutions CHAPTER 3. TRANSACTION PRIORITIZATION NORMS 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 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 Transaction Prioritization Norms Transaction Prioritization Norms 3.1 Methodology 3.1 Methodology 3.2 Analyzing norm adherence 3.2 Analyzing norm adherence 3.3 Investigating norm violations 3.3 Investigating norm violations 3.4 Dark-fee transactions 3.4 Dark-fee transactions 3.5 Concluding remarks 3.5 Concluding remarks CHAPTER 4. TRANSACTION PRIORITIZATION AND CONTENTION TRANSPARENCY 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 Transaction Prioritization and Contention Transparency
4.1 Methodology
4.2 On contention transparency
4.3 On prioritization transparency
4.4 Concluding remarks Transaction Prioritization and Contention Transparency Transaction Prioritization and Contention Transparency 4.1 Methodology 4.1 Methodology 4.2 On contention transparency 4.2 On contention transparency 4.3 On prioritization transparency 4.3 On prioritization transparency 4.4 Concluding remarks 4.4 Concluding remarks CHAPTER 5. DECENTRALIZED GOVERNANCE CHAPTER 5. DECENTRALIZED GOVERNANCE Decentralized Governance
5.1 Methodology
5.2 Attacks on governance
5.3 Compound’s governance
5.4 Concluding remarks Decentralized Governance
5.1 Methodology
5.2 Attacks on governance
5.3 Compound’s governance
5.4 Concluding remarks Decentralized Governance Decentralized Governance 5.1 Methodology 5.1 Methodology 5.2 Attacks on governance 5.2 Attacks on governance 5.3 Compound’s governance 5.3 Compound’s governance 5.4 Concluding remarks 5.4 Concluding remarks CHAPTER 6. RELATED WORK CHAPTER 6. RELATED WORK 6.1 Transaction prioritization norms 6.1 Transaction prioritization norms 6.2 Transaction prioritization and contention transparency 6.2 Transaction prioritization and contention transparency 6.3 Decentralized governance 6.3 Decentralized governance CHAPTER 7. DISCUSSION, LIMITATIONS & FUTURE WORK CHAPTER 7. DISCUSSION, LIMITATIONS & FUTURE WORK 7.1 Transaction ordering 7.1 Transaction ordering 7.2 Transaction transparency 7.2 Transaction transparency 7.3 Voting power distribution to amend smart contracts 7.3 Voting power distribution to amend smart contracts Conclusion Conclusion Appendices Appendices APPENDIX A: Additional Analysis of Transactions Prioritization Norms APPENDIX A: Additional Analysis of Transactions Prioritization Norms APPENDIX B: Additional analysis of transactions prioritization and contention transparency APPENDIX B: Additional analysis of transactions prioritization and contention transparency APPENDIX C: Additional Analysis of Distribution of Voting Power APPENDIX C: Additional Analysis of Distribution of Voting Power Bibliography Bibliography 2.3 Transaction prioritization and contention transparency The rate at which users issue transactions in permissionless blockchains, e.g., Bitcoin (Nakamoto, 2008) and Ethereum (Wood et al., 2014), is often much higher than the rate at which miners can include them in a block (Easley et al., 2019; Huberman et al., 2021; Lavi et al., 2019; Messias et al., 2020, 2021). Figure 2.2 shows that 50% of all Bitcoin transactions were added to the blockchain in just 3 years. Similarly, in Ethereum, 80% of the transactions were added in just 1.5 years. Users typically issue transactions using a wallet software, whose primary functionality is determining an “appropriate” fee for a given transaction. This (prioritization) fee varies, unsurprisingly, as a function of the level of congestion in the blockchain (Messias et al., 2021) as well as the distribution of fees across available transactions. Inferring either of these is, however, deceptively complicated. At first glance, these tasks appear straightforward, since every transaction is broadcast to all miners in the blockchain. A user could simply gather all transactions broadcast over time and reconstruct the set of uncommitted transactions available to a miner (i.e., contents of the miner’s Mempool) at any point of time (Messias et al., 2020). We refer to this assumption of a public and uniform view (across miners) of all available transactions as contention transparency. If contention transparency exists, a user could rank order available transactions by their fee (based on which miners should select transactions for inclusion) and estimate the commit delay of any transaction (Messias et al., 2021). Consequently, they could determine the fee that they must pay to guarantee inclusion of their transaction in a given block. We label this assumption that the (prioritization) fee offered by a transaction is only that publicly declared by that transaction as prioritization transparency. Neither the contention transparency nor the prioritization transparency, however, holds today in permissionless blockchains. 2.4 Decentralized governance Smart contracts underpin many DeFi applications today (Adams et al., 2021; Daian et al., 2020; Ethereum Foundation, 2023c; Perez et al., 2021; Qin et al., 2021), and it is only natural to have a mechanism for updating these (software) contracts to fix bugs or evolve them over time to cater for new use cases (David Siegel, 2013; Liu et al., 2018; Zhou et al., 2023). If decisions concerning such updates are made in a centralized manner, e.g., by a regulatory body, or a cabal of developers or miners, it undermines users’ trust in the applications that these contracts support. The updates could, for instance, be tailored to benefit the centralized regulatory body at the expense of others. Governance protocols address this issue by distributing the decision-making power among all the users of the application or smart contract being updated. A governance protocol establishes rules and (transparent) mechanisms for changing smart contracts. It defines the required procedures for creating, voting on, and executing proposals to amend smart contracts. It facilitates users of a protocol (or, more aptly, token holders who hold one or more tokens of the protocol) to propose changes. The changes are then vetted by and voted by other users, and implemented only if the proposals receive the majority of favorable votes. The protocols also grant voting power to a user based on the number of tokens held by them—typically one token equals one vote, essentially capturing the user’s stake and/or participation in the protocol. Some protocols such as Compound (Leshner and Hayes, 2019) and Uniswap (Adams et al., 2021) allow token holders who do not wish to exercise their voting power to delegate their voting power (i.e., tokens) to others. This delegation is a form of liquid democracy, where voters can participate in decision-making either directly by voting or indirectly by delegating their voting rights to trusted representatives (Behrens, 2017; Blum and Zuber, 2016; Carroll, 1884). Governance protocols give every participant the right to propose, support, or oppose any proposal. They are, hence, crucial for ensuring absolute decentralization of applications running atop blockchains. 2.4.1 Voting modalities 2.4.1 Voting modalities Proposals to change a governance protocol takes birth in the protocol’s community forum. Community members suggest and discuss potential changes to the protocol in the forum and may even conduct an informal poll to gauge the community’s support for a proposal. The proposer then either amends the proposal to incorporate the community’s feedback and submit it for a formal vote, or simply abandon it. The formal voting on the proposal has two modes: on-chain and off-chain voting. On-chain voting In this voting system, participants make all governance decisions via smart contracts on a blockchain. Under this system, participants cast a vote by issuing a transaction (and paying a fee for committing it) to the blockchain. The system allows only participants with at least a threshold amount of (governance) tokens to create a proposal, albeit any token holding participant can vote on that proposal. It executes the proposal on the blockchain only if it receives a significant number of votes in favor and reaches a quorum. [8] This voting system thus facilitates making transparent and tamper-proof changes to the protocol. Decentralized governance protocols such as AAVE (AAVE, 2023), Compound (Compound Labs, Inc., 2022a), and Uniswap (Uniswap Labs, 2023) use on-chain voting. On-chain voting On-chain voting Off-Chain Voting This system conducts voting on an off-chain third-party platform and, as a consequence, also establishes the rules for voting, aggregating votes, and determining the results off-chain. Protocols such as Balancer (Balancer.fi, 2023) and Convex Finance (Convex, 2023a), for instance, use Snapshot (Labs, 2023b) for off-chain voting. Snapshot stores the voting data on a P2P network called InterPlanetary File System (IPFS) (Labs, 2023a). The voting process does not require voters to pay any fees and (unlike on-chain voting) promotes participation across all participants, regardless of their level of participation or investment in the protocol. After the voting, this system uses a multi-signature contract to enact the off-chain voting outcome on the blockchain. Typically, an n-of-m multisig contract requires the transaction to be signed by at least n out of the m “admins” to be executed on-chain. The system trusts the multisig “admins”, who are well-known in the community, to implement the voting outcome on the blockchain truthfully. The admins can also, however, refuse the proposal. In Convex Finance, for instance, the admins can choose not to execute a proposal if they deem it harmful, even if it had received the majority of votes and reached a quorum (Convex, 2023b). On-chain voting systems, in contrast, prevent such manipulation of voting outcomes by one or more individuals (after the voting process), since all governance decisions (e.g., voting and execution) happen on the chain. Off-Chain Voting Off-Chain Voting Token delegations Some governance protocols (e.g., Compound, Uniswap, and AAVE) require a user to own a certain amount of governance tokens for casting a vote. Users must delegate their tokens either to themselves or, if they do not wish to vote, delegate them to others. The ability to delegate voting power to others facilitates a form of liquid democracy; the token holder who delegates or sells their tokens to another loses their voting power. Delegations allow anyone to buy (or sell) tokens and gain (or lose) voting power instantly. Justin Sun, the founder of (stablecoin) TrueUSD (TrueUSD, 2023), for instance, allegedly borrowed COMP tokens to create and vote for Compound proposal #84 (team, 2022), resulting in a governance attack (Thurman, 2022); this proposal was, however, defeated. Token delegations Token delegations Token “locking” Protocols such as Balancer and Curve (Curve, 2023) mandate that a user “lock” their tokens into a smart contract for a specified period of time to gain their right to vote. The user cannot withdraw the locked tokens until the lock-up period expires. The voting power of a user in this system is proportional to the amount of tokens locked as well as the lock-up period. In Balancer, for instance, a user receives 1 unit of voting power if they lock 1 token into the contract for 1 year, and only half that voting power if they lock it instead for 6 months. Token “locking” Token “locking” Continuous voting A few protocols (e.g., MakerDAO (MakerDAO, 2023)) allow voters to change their votes at any time during the voting period. Users propose a protocol change by developing a new implementation via a smart contract. The new implementation is accepted if it receives more votes than the current one, i.e., the winning implementation must always receive the majority of the votes (or tokens). MakerDAO requires a user to deposit their (MKR) tokens into the (Maker) Governance contract for casting a vote. The more tokens they deposit, the more voting power they obtain, and they vote for their desired implementation by specifying it as a protocol parameter in the smart contract. Since the voting process is continuous, if a user withdraws their MKR tokens from the governance contract, their vote will no longer count towards the implementations for which they previously voted. Continuous voting Continuous voting We refer the reader to §C.4 (particularly Tab. C.1) for a characterization of the voting methods, delegation approaches, and proposal executions in various other governance protocols. Understanding how voting is conducted (i.e., whether it is on-chain or offchain) and proposals are executed is fundamental for analyzing how voters, proposers, and others interact with these governance protocols. 2.5 Blockchain Scalability with Layer 2.0 Solutions As observed in Figure 2.2, 50% of all Bitcoin transactions were added to the blockchain in just 3 years. Meanwhile, in Ethereum, 80% of the transactions were added in just 1.5 years. This highlights a crucial scalability challenge inherent in blockchains: blocks will not be able to accommodate all transaction available. Unfortunately, this issue is projected to aggravate each year. Consequently, the need for Layer 2.0 solutions has arisen to mitigate the escalating blockchain scalability dilemma. Layer 2.0 consists of an off-chain network, system, or technology that is built on top of a blockchain (Chainlink Foundation, 2023). In other words, this approach execute transactions in batches, together, and off-chain. This process helps accelerate the execution of the transactions leaving the main blockchain for persisting the validity (or proofs) that the transactions were correctly executed. As a result, this method accelerates both transaction execution and confirmation processes. There are two most popular types of Layer 2.0 solutions: Zero Knowledge (ZK) (Goldreich and Oren, 1994; Goldwasser et al., 2019) and Optimistic (Ethereum Foundation, 2023d) rollups. Within the Zero Knowledge (ZK) rollup, transactions are grouped into batches for execution, leading to a reduction in execution costs. The outcome, which is a proof of transaction validity, gets stored back on the main blockchain (or Layer 1.0). Therefore, rather than persisting the complete transaction data for each individual transaction on the blockchain, this approach conserves space by storing only a proof that verifies the validity of an entire batch of transactions executed on Layer 2.0. Example of ZK rollup is ZKSync (Matter Labs, 2023). On the other hand, within the Optimistic rollup, it operates under the assumption that all transactions are valid by default, unless certain participants provide evidence to the contrary. Therefore, it is an optimistic approach. Examples of Layer 2.0 using Optimistic rollups are Optimism (Optimism Foundation, 2023) and Arbitrum (Offchain Labs, 2023). In this thesis, we delve into a Layer 2.0 solution designed for Bitcoin, known as Omni Layer (Omni Layer, 2023). This aims to shed light on off-chain transaction acceleration facilitated by miners. Unlike the batch approach used in both ZK and Optimistic rollups, Omni Layer does not batch transactions. Instead, it creates a Bitcoin transaction for every transaction issued on its layer. This enables us to analysis the extent to which miners accelerate the inclusion of these individual transactions. Author:
(1) Johnnatan Messias Peixoto Afonso Author: Author (1) Johnnatan Messias Peixoto Afonso This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Maker

Chainlink

Convex Finance

Aave

TrueUSD

Uniswap

Ethereum Foundation

UnderstandingBitcoin’s “Fast Pass” for High‑Fee Transactions

How Miners Select and Order Transactions in Bitcoin

EScholar Technologies

Too Long; Didn't Read