6 ms·
I still don't understand what's happening at the core of this and the other dark forest post from a few weeks ago. How exactly are these bots front-running/ste
by snake_plissken 6y ago
I still don't understand what's happening at the core of this and the other dark forest post from a few weeks ago. How exactly are these bots front-running/stealing the ethereums?
My understanding:
-these bots scan the smart contracts that are waiting to be executed by the miners
-the bots find vulnerabilities (another grey area in my mind) in the contract
-the bots adjust the destination address of where the contract is supposed to send the the ethereums
-then the bots continually execute the vulnerable smart contract code
- schoen 6y agoMy understanding of the front-running issue in these two cases is that a human being found vulnerabilities in particular smart contracts, which would allow anyone to claim the value protected by a particular contract. The human beings wanted to use these vulnerabilities to transfer the value somewhere, such as to an escrow account or to the original owners of that value. However, since the vulnerabilities allow anyone to do this, the front-runners could take this value for themselves by noticing the humans' attempt to execute the transactions, and then more quickly executing the exact same transaction with a different destination. You can't take advantage of a "normal" cryptocurrency transaction this way because the "normal" transaction is like a super-minimal smart contract that's designed to pay only one hard-coded recipient. Therefore, that transaction either happens or doesn't happen, but its recipient can't be altered. Nor can you take advantage of a non-vulnerable smart contract this way, because the non-vulnerable smart contract can't be triggered to perform an action that its creators would consider inappropriate. But for a vulnerable smart contract, there's a series of events that would cause it to send value to an arbitrary address (and not in exchange for some other adequate compensatory value). It's this case where the front-runners want to find a way to swap in their own addresses for these transactions, and that's also why obfuscation could deter that -- making it hard for the front-runners to notice that that was possible.
- AgentME 6y agoI think it's an important detail to point out that legitimate transactions mostly aren't vulnerable to the "Dark Forest" issue. A lot of comments I'd seen on the original "Ethereum is a Dark Forest" blog post seemed to be under the impression that this was a general Ethereum issue affecting normal users.
- 3np 6y agoArbitrage trades and related activities like MakerDAO keepers would be legitimate transactions vulnerable to this (essentially someone else extracting the value from their discovery). Granted that is a very small subset of users.
- nonsens3 6y agoLiquidation contracts and Arbitrage contracts do check the caller and would not allow to be executed by non-approved senders. This raises the bar, so that you can front run only contracts that you can implement and deploy. If anyone could just replace an address and execute a profitable transaction by being first on existing contracts, surely miners would be doing it already, no?
- 3np 6y ago> If anyone could just replace an address and execute a profitable transaction by being first on existing contracts, surely miners would be doing it already, no? To a large degree not yet.
- drchopchop 6y agoBasically a human realizes that smart contract X is broken, and tries to enlist others to fix it. However, given the decentralized and generally shady nature of crypto, the process of disclosure also means a bad actor could get wind of the bug before it's addressed, and use the exploit to steal all of the money. Thus, you have white hats racing to siphon money out of a buggy, immutable contract which also happens to be worth millions of real dollars. It'd be funny if there wasn't so much real money involved.
- renewiltord 6y agoYou put your gold in a box and stuck it in the ground in a ranch in the middle of nowhere. No one knows there is gold in a box in the ground so it's safe. But people know that other people but gold in boxes and stick it in the ground. One day you go to get it so you load up your pickup with gold digging equipment and drive to the ranch. On the way are spotters. They see your truck has gold digging equipment. They see that the road you're going down leads to the ranch. It's obvious what you're going to do. They load up their faster Ford Ranger and blaze down the road. You can't catch up. They have a faster car. You get there. They have taken your gold. If you hadn't gone there, the gold was relatively safe. Maybe some day someone happens on it but realistically probably not. But you went. By looking for it you revealed you were looking and you revealed where you were looking.
- Sniffnoy 6y agoIt's much simpler than that. (Also, you appear to have a few concepts mixed up. For instance, one doesn't execute smart contracts, but rather transactions. Smart contracts just sit there until someone sends a transaction to one, at which point it executes that transaction.) What the bot does is that it checks each transaction that is waiting to be executed and simulates sending that transaction itself on a private blockchain forked from the real network. If the simulation results in a profit, it frontruns that transaction -- i.e., it sends the transaction itself for real, but bidding a higher price than the original sender did, so that its transaction will get executed rather than the the original transaction it's copying. It doesn't need to perform any sort of vulnerability scan; it just mimics other people exploiting arbitrage or vulnerabilities and pays more to get there first. Similarly, it doesn't need to adjust any destination addresses. It's just looking for arbitrage opportunities or vulnerabilities that will direct ether to the sender. Smart contracts are entirely capable of getting the address of the message sender, and using that as a destination to send ether to. So the bot doesn't need to adjust the transaction data at all, which would be substantially more complicated.
- danielvf 6y agoImagine that everyone agreed that just one slow computer would handle banking, contracts, and the stock markets for the entire world. This gets rid of any pesky concurrency issues. To move money from person to person, or to execute contracts or programs, you write up a sticky note with what you want to have done, sign it, and attach some money to it. Once every couple minutes, the computer administrators come out, collect a couple notes with the most money on them, and feed those into the computer. The Dark Forest attack is possible because everyone can see all the notes on the board waiting to be processed, and everyone can simulate exactly, precisely what the really slow computer will do with a given note. Suppose you found someone wanting to sell TSLA stock for $5 and someone wanting to buy it for $400. You would write up a note to buy it for $5 and sell it for $400, and stick it on the board. However, the moment you put the note on the board, the attackers and their automated telescopes have simulated that this note results in the holder having $395 more than they started with, and gave nothing away in return. The attacker then simulates an alternate future in which they post the note instead, and verify that they get the money. It works! So the attacker copies your note, signs it themselves, puts a much bigger wad of cash on it than you did, and slaps it up on the board. When the operators come out, they collect the attackers note first (more cash) and by the time your note is run, the opportunity is no longer there.
- SilasX 6y agoGreat analogy! The only thing I would add is that, if your arbitrage trade takes away too much money from an account belong the core devs (which would be like, the regulators responsible for the computer), they would retroactively undo that transaction in the computer's logic (force a hard fork). https://news.ycombinator.com/item?id=14819268 https://news.ycombinator.com/item?id=14819268