Table of Links Abstract and 1 Introduction 2 Background and 2.1 Blockchain 2.2 Transactions 3 Motivating Example 4 Computing Transaction Processing Times 5 Data Collection and 5.1 Data Sources 5.2 Approach 6 Results 6.1 RQ1: How long does it take to process a transaction in Ethereum? 6.2 RQ2: How accurate are the estimates for transaction processing time provided by Etherscan and EthGasStation? 7 Can a simpler model be derived? A post-hoc study 8 Implications 8.1 How about end-users? 9 Related Work 10 Threats to Validity 11 Conclusion, Disclaimer, and References A. COMPUTING TRANSACTION PROCESSING TIMES A.1 Pending timestamp A.2 Processed timestamp 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 available on arxiv under CC BY-NC-ND 4.0 DEED license. [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 Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Background and 2.1 Blockchain 2 Background and 2.1 Blockchain 2.2 Transactions 2.2 Transactions 3 Motivating Example 3 Motivating Example 4 Computing Transaction Processing Times 4 Computing Transaction Processing Times 5 Data Collection and 5.1 Data Sources 5 Data Collection and 5.1 Data Sources 5.2 Approach 5.2 Approach 6 Results 6.1 RQ1: How long does it take to process a transaction in Ethereum? 6.1 RQ1: How long does it take to process a transaction in Ethereum? 6.2 RQ2: How accurate are the estimates for transaction processing time provided by Etherscan and EthGasStation? 6.2 RQ2: How accurate are the estimates for transaction processing time provided by Etherscan and EthGasStation? 7 Can a simpler model be derived? A post-hoc study 7 Can a simpler model be derived? A post-hoc study 8 Implications 8 Implications 8.1 How about end-users? 8.1 How about end-users? 9 Related Work 9 Related Work 10 Threats to Validity 10 Threats to Validity 11 Conclusion, Disclaimer, and References 11 Conclusion, Disclaimer, and References A. COMPUTING TRANSACTION PROCESSING TIMES A. COMPUTING TRANSACTION PROCESSING TIMES A. COMPUTING TRANSACTION PROCESSING TIMES A.1 Pending timestamp A.1 Pending timestamp A.2 Processed timestamp A.2 Processed timestamp B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY B.1 Sensitivity Analysis on Block Lookback B.1 Sensitivity Analysis on Block Lookback C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS D. POST-HOC STUDY: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS D. POST-HOC STUDY: 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. user transactions contract transactions 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 usage gas price. 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 usag e 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. Gas and transaction fees gas usage gas price gas usag gas price 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 Transaction processing lifecycle. 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. Authors: 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 available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv available on arxiv [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

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

Ethereum Transactions 101

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

Can Blockchains Overcome the Scalability Trilemma?

"DApps!" A New Buzzword, or Here to Stay for Good?

DeFi Due Diligence? Not that hard

DevOps Tooling for Web 3.0: Building, Deploying, and Scaling Decentralized Applications

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

Can Blockchains Overcome the Scalability Trilemma?

"DApps!" A New Buzzword, or Here to Stay for Good?

DeFi Due Diligence? Not that hard

DevOps Tooling for Web 3.0: Building, Deploying, and Scaling Decentralized Applications

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps