It’s difficult to attack a moving target, even more so when it’s fast.
Easy Targets
Cryptocurrency traders, especially high-frequency traders who trade multiple times a day, are well-versed in the risks of trading decentralized cryptocurrencies. One of these risks is the potential for front-running, where someone takes advantage of a slow consensus system to manipulate or replace a transaction.
This is a known problem in decentralized systems where everyone can see the transaction before it’s actually processed. For example, in Ethereum, a transaction can take up to 15 seconds to be mined. During this time, internet bots can look at the transaction, potentially manipulate it, or replace it. This problem is mainly due to leader-based consensus (the designated leader is responsible for coordinating the process), which can be slow and give rise to front-running opportunities.
Sandwich Attack
A “sandwich attack” is one way a bad actor can simultaneously take advantage of front-running and back-running a transaction within this slow process. By doing so, the attacker tries to interfere with the communication between two parties(sender & receiver), typically by inserting themselves between the two parties and relaying the communication in an attempt to gain access to sensitive or manipulatable information. The attacker essentially “sandwiches” themselves between the two parties. This attack generally aims to place two orders surrounding the pending transaction to manipulate the asset’s prices.
Example: You are the attacker and walk into a busy deli. You see someone else placing an order for a sandwich. You quickly jump in front of the customer and place an order for the same sandwich, but now with added ingredients to make it more expensive. As the sandwich shop prepares your order, you step away, leaving the original customer empty-handed or with a pricer sandwich.
A mechanism is needed to solve this problem, which circumvents the mempool, allowing transactions to be sent to a single operator in secret without exposing it to the entire network before processing. In addition to this process, network speed is necessary to protect users and traders by decreasing the window of opportunity for front-running and other attacks.
Speed = Security
Kaspa is addressing this issue with asynchronous consensus/parallel consensus. With the Rustlang rewrite estimation of 32 blocks per second and a goal of 100 BPS, transactions can be processed within less than a second before propagating to the network. This will help prevent manipulation and front-running, making cryptocurrency trading a more secure and reliable experience for all users.
As the renowned Kaspateer @DesheShai recently Tweeted, “…speed is not just a nice feature to have, but absolutely essential for the long term sustainability of a decentralized proof of work chain.” That being the case, it’s reasonable to add that speed is also essential for security.
Another point for Kaspa in the speed/security category.
Special thanks to Discord user @ZEPP8S for the idea and for sharing this video find: DeFi Ecosystem Is Fragmenting | Dr. Yonatan Sompolinsky — DAGlabs | REIMAGINE v9.0 #33
Tip: This ‘sandwich attack’ is one of several front-running attacks. Some others include order book sniping, transaction replay, and block withholding.
Comment below or find me on the Kaspa discord — Bubblegum Lightning