Table of Links Abstract and I. Introduction II. Background III. Problem Definition IV. DAG-Oriented Solutions V. Game Theoretical Analysis VI. Simulation Model VII. Evaluation VIII. Countermeasures IX. Discussion and Future Work X. Related Work XI. Conclusion and References VIII. COUNTERMEASURES Our experiments supported Hypothesis 1. The main problem is not sufficiently enforcing the RTS, i.e., verifying that transaction selection was indeed random at the protocol level. Therefore, using the RTS in the DAG-PROTOCOL that does not enforce the interpretation of randomness will never avoid the occurrence of attackers from greedy transaction selection that increases their individual (or pooled) profits. Enforcing Interpretation of the Randomness. One countermeasure how to avoid arbitrary interpretation of the randomness in the RTS is to enforce it by the consensus protocol. An example of a DAG-based design using this approach is Sycomore [2], which utilizes the prefix of cryptographically-secure hashes of transactions as the criteria for extending a particular chain in DAG. The PoW mining in Sycomore is further equipped with the unpredictability of a chain that the miner of a new block extends, avoiding the concentration of the mining power on “rich” chains. Note that transactions are evenly spread across all chains of the DAG, which happens because prefixes of transaction hashes respect the uniform distribution – transactions are created by clients different from miners, and clients have no incentives for biasing their transactions. Fixed Transaction Fees. Another option how to make the RTS viable is to employ fixed fees for all transactions as a blockchain network-adjusted parameter. In the case of the full block capacity utilization within some period, the fixed fee parameter would be increased and vice versa in the case of not sufficiently utilized block capacity. In contrast to the previous countermeasure, this mechanism does not enforce the interpretation of randomness while at the same time does not make incentives for greedy miners to follow other than the RTS strategy. Therefore, miners using other than the RTS would not earn extra profits – we demonstrate it in Fig. 12 and Fig. 13, considering one honest vs. one greedy miner and one greedy vs. 9 honest miners, respectively. Note that small deviations from the baseline are caused by the inherent simulation error that is present in the original simulator that we extended. On the other hand, greedy miners may still cause increased transaction collision rate, and thus decreased throughput. Therefore, we consider the fixed transaction fee option weaker than the previous one. Authors:
(1) Martin Peresıni, Brno University of Technology, Faculty of Information Technology (iperesini@fit.vut.cz);
(2) Ivan Homoliak, Brno University of Technology, Faculty of Information Technology (ihomoliak@fit.vut);
(3) Federico Matteo Bencic, University of Zagreb, Faculty of Electrical Engineering and Computing (federico-matteo.bencic@fer.hr);
(4) Martin Hruby, Brno University of Technology, Faculty of Information Technology (hruby@fit.vut.cz);
(5) Kamil Malinka, Brno University of Technology, Faculty of Information Technology (malinka@fit.vut). This paper is available on arxiv under CC BY 4.0 DEED license. Table of Links Abstract and I. Introduction Abstract and I. Introduction II. Background II. Background III. Problem Definition III. Problem Definition IV. DAG-Oriented Solutions IV. DAG-Oriented Solutions V. Game Theoretical Analysis V. Game Theoretical Analysis VI. Simulation Model VI. Simulation Model VII. Evaluation VII. Evaluation VIII. Countermeasures VIII. Countermeasures IX. Discussion and Future Work IX. Discussion and Future Work X. Related Work X. Related Work XI. Conclusion and References XI. Conclusion and References VIII. COUNTERMEASURES Our experiments supported Hypothesis 1. The main problem is not sufficiently enforcing the RTS, i.e., verifying that transaction selection was indeed random at the protocol level. Therefore, using the RTS in the DAG-PROTOCOL that does not enforce the interpretation of randomness will never avoid the occurrence of attackers from greedy transaction selection that increases their individual (or pooled) profits. Enforcing Interpretation of the Randomness. One countermeasure how to avoid arbitrary interpretation of the randomness in the RTS is to enforce it by the consensus protocol. An example of a DAG-based design using this approach is Sycomore [2], which utilizes the prefix of cryptographically-secure hashes of transactions as the criteria for extending a particular chain in DAG. The PoW mining in Sycomore is further equipped with the unpredictability of a chain that the miner of a new block extends, avoiding the concentration of the mining power on “rich” chains. Note that transactions are evenly spread across all chains of the DAG, which happens because prefixes of transaction hashes respect the uniform distribution – transactions are created by clients different from miners, and clients have no incentives for biasing their transactions. Enforcing Interpretation of the Randomness. Fixed Transaction Fees. Another option how to make the RTS viable is to employ fixed fees for all transactions as a blockchain network-adjusted parameter. In the case of the full block capacity utilization within some period, the fixed fee parameter would be increased and vice versa in the case of not sufficiently utilized block capacity. Fixed Transaction Fees. In contrast to the previous countermeasure, this mechanism does not enforce the interpretation of randomness while at the same time does not make incentives for greedy miners to follow other than the RTS strategy. Therefore, miners using other than the RTS would not earn extra profits – we demonstrate it in Fig. 12 and Fig. 13, considering one honest vs. one greedy miner and one greedy vs. 9 honest miners, respectively. Note that small deviations from the baseline are caused by the inherent simulation error that is present in the original simulator that we extended. On the other hand, greedy miners may still cause increased transaction collision rate, and thus decreased throughput. Therefore, we consider the fixed transaction fee option weaker than the previous one. Authors: (1) Martin Peresıni, Brno University of Technology, Faculty of Information Technology (iperesini@fit.vut.cz); (2) Ivan Homoliak, Brno University of Technology, Faculty of Information Technology (ihomoliak@fit.vut); (3) Federico Matteo Bencic, University of Zagreb, Faculty of Electrical Engineering and Computing (federico-matteo.bencic@fer.hr); (4) Martin Hruby, Brno University of Technology, Faculty of Information Technology (hruby@fit.vut.cz); (5) Kamil Malinka, Brno University of Technology, Faculty of Information Technology (malinka@fit.vut). Authors: Authors: (1) Martin Peresıni, Brno University of Technology, Faculty of Information Technology (iperesini@fit.vut.cz); (2) Ivan Homoliak, Brno University of Technology, Faculty of Information Technology (ihomoliak@fit.vut); (3) Federico Matteo Bencic, University of Zagreb, Faculty of Electrical Engineering and Computing (federico-matteo.bencic@fer.hr); (4) Martin Hruby, Brno University of Technology, Faculty of Information Technology (hruby@fit.vut.cz); (5) Kamil Malinka, Brno University of Technology, Faculty of Information Technology (malinka@fit.vut). 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.

Preventing Greedy Transaction Selection: RTS and Fixed Fee Solutions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Comparative Analysis of Crypto API Misuses Across Programming Languages

7 Consensus Mechanisms Developers Must Know to BUIDL for Web3

BFT Consensus: Will Your Car Full of Passengers Turn Right, Left, or Fly Over a Cliff?

Consensus Protocol in Blockchain

ConsensusPedia: An Encyclopedia of 30+ Consensus Algorithms

A Comparative Analysis of Crypto API Misuses Across Programming Languages

7 Consensus Mechanisms Developers Must Know to BUIDL for Web3

BFT Consensus: Will Your Car Full of Passengers Turn Right, Left, or Fly Over a Cliff?

Consensus Protocol in Blockchain

ConsensusPedia: An Encyclopedia of 30+ Consensus Algorithms

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps