Table of Links
2 Background and 2.1 Blockchain
4 Computing Transaction Processing Times
5 Data Collection and 5.1 Data Sources
6 Results
6.1 RQ1: How long does it take to process a transaction in Ethereum?
7 Can a simpler model be derived? A post-hoc study
11 Conclusion, Disclaimer, and References
A. COMPUTING TRANSACTION PROCESSING TIMES
B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY
B.1 Sensitivity Analysis on Block Lookback
C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS
D. POST-HOC STUDY: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS
2 BACKGROUND
In this section, we introduce the key concepts that are used throughout our paper.
2.1 Blockchain
A blockchain is essentially a ledger of all transactional activity occurring on the network. The ledger is stored on the network using blocks: an object which stores a unique set of transactions, all of which are identifiable by their own unique ID. The information within blocks cannot be changed unless all of the blocks that came after it are also changed. As a result, it is common for information in a block to become immutable after a certain amount of blocks have been appended after it.
2.2 Transactions
Transactions are the means through which users interact with a blockchain. In Ethereum, there are two types of transactions: user transactions and contract transactions. User transactions enable users to send cryptocurrency to one another. The cryptocurrency used in Ethereum is known as Ether (ETH). A contract transaction, in turn, enables one to execute a function defined in a smart contract deployed in Ethereum.
As in most blockchain platforms, transactions in Ethereum must be paid for. The transaction fee is given by gas usage Γ gas price. The gas usage corresponds to the amount of computing power that was needed in order to process a given transaction. While this computing power is fixed for user transactions (21 GWEI = 2.1E-8 ETH), it varies considerably for contract transactions. More specifically, each instruction in the bytecode of a smart contract burns a certain amount of gas units [44]. The gas price, in turn, is a parameter set by the transaction issuer. The gas price corresponds to the amount of Ether that one is willing to pay for each unit of burnt gas. In practice, the gas price parameter is a way for users to create an incentive for miners to process transactions at a higher priority [40], as miners are rewarded for their processing efforts with the cost of the transaction fee.
Gas and transaction fees. Transactions sent within the Ethereum blockchain require a transaction fee to be paid before being sent. This fee is calculated by gas usage Γ gas price. The gas usage term refers to the amount of computing power consumed to process a transaction. This value is constant for user transactions, costing 21 GWEI, equivalent to 2.1E-8 ETH. For contract transactions, this value is calculated depending on the bytecode executed within a smart contract, as each instruction has a specific amount of gas units required for it to execute [44]. The gas price term defines the amount of Ether the sender is prepared to pay per unit of gas consumed to process their transaction. This parameter is set by the sender, and allows users to incentivize the processing of their transaction at a higher priority [40], as miners which process the transaction are rewarded based on the transaction fee value.
Transaction processing lifecycle. As illustrated in Figure 1, the lifecycle of a transaction π‘ begins when a transaction issuer submits it. Transaction π‘ is then broadcasted through the blockchain by means of the peer to peer network. Eventually, π‘ is discovered by most mining nodes in the network (each mining node has its own pool of pending transactions, or pending pool for short). We consider π‘ to reach a pending state when its existence is acknowledged by any miner node
in the network. Eventually, a miner wins the Proof-of-Work [22] competition[2], allowing such a miner to append a new block π of transactions to the blockchain. These transactions are chosen from the minerβs pending pool. If π‘ is included in π, we then consider π‘ to reach a processed state as soon as the π is appended to the blockchain (i.e., at the block timestamp of π). We highlight that π blocks need to be appended after π in order for π‘ to be considered confirmed (a.k.a., final). There is no consensus on what the exact value of π should be. The Ethereum whitepaper suggests π = 7 [9], which translates to approximately 01m 45s (since blocks are appended every 15s in average). Practitioners (end-users and developers) commonly use π = 12 as a rule of thumb[3]. Some crypto exchanges use higher thresholds, since they manipulate high-value crypto transactions and thus prefer to be conservative regarding confirmation. CoinCentral, for instance, uses π = 250, which translates to approximately 01h 02min 30s [13].
User-specific transaction ordering (nonce). The nonce is a transaction parameter that records the number of transactions that were previously sent by the transaction issuer (i.e., every time someone sends a new transaction, their nonce is increased by 1). This parameter exists to preserve transaction ordering in Ethereum. Hence, if a transaction issuer Charlie submits a very cheap transaction π‘1 and, after 10 seconds, submits a very expensive transaction π‘2, then π‘2 can only be mined (i.e., added to a block) once π‘1 has been mined. Since π‘1 was submitted with a very cheap gas price, it is possible that π‘2 will take long to be mined. In summary, a transaction with nonce π can only be mined if the transaction with nonce π β 1 has already been mined.
Authors:
(1) MICHAEL PACHECO, Software Analysis and Intelligence Lab (SAIL) at Queenβs University, Canada;
(2) GUSTAVO A. OLIVA, Software Analysis and Intelligence Lab (SAIL) at Queenβs University, Canada;
(3) GOPI KRISHNAN RAJBAHADUR, Centre for Software Excellence at Huawei, Canada;
(4) AHMED E. HASSAN, Software Analysis and Intelligence Lab (SAIL) at Queenβs University, Canada.
This paper is
[2] Proof-of-Work is a consensus protocol that requires nodes to solve a hard mathematical puzzle. The PoW consensus protocol ensures that there is no better strategy to find the solution to the mathematical puzzle than enumerating the possibilities (i.e., brute force). On the other hand, the verification of a solution is trivial and cheap. Ultimately, the PoW consensus protocol ensures that a trustworthy third-party (e.g., a bank) is not needed in order to validate transactions, enabling entities who do not know or trust each other to build a dependable transaction ledger.
[3] https://stackoverflow.com/questions/49065176/how-many-confirmations-should-i-have-on-ethereum