Hacker News Reader

Comment by snake_plissken | Hacker News Reader

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

View on HN

Imagine 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.

Great 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

That's an unfair representation of what actually unfolded.

Unfair enough that you can articulate why?

> (which would be like, the regulators responsible for the computer)

no one is responsible, that's the whole point. The thing runs by itself and game theory keeps it afloat - not a group of people. Else it's just like a company.

That said, the protocol isn't finished and you have people involved in maintaining and upgrading the protocol. Which is in no way forced down upon everyone: once they have an update everyone is free to choose to run it or not.

These people have influence (you could argue too much) about the future of the protocol.

> if your arbitrage trade takes away too much money from an account belong the core devs

This is not why these decisions were made at all, because some core dev instested in the DAO.

To expand:

The decision-making and communities of Ethereum (this goes both for the clients, the blockchain, the foundation and the larger community) looks completely different today compared to 2015. There has been a lot of lessons learnt, debate and churn since.

If they same thing happened today, it'd play out completely differently.

See the Parity Multisig hack, for one.

Finally, it's a stretch to call the dao hack "arbitrage trade".

>Finally, it's a stretch to call the dao hack "arbitrage trade".

It is absolutely not. It is exactly the same from the value judgments of the ETH project, specifically "Code is Law". The DAO specifically went as far as endorsing that the software execution takes precedence over the reading of the English functionality spec.

The ETH system, but the core values of ETH, should do exactly what your arb contract specifies, and exactly what the DAO contracts specify, even and especially if that's not what the writer originally intended. To selectively reneg on that principle would be wrong for the same reason as doing it on an arb contract.

https://www.dictionary.com/browse/arbitrage

> the simultaneous purchase and sale of the same securities, commodities, or foreign exchange in different markets to profit from unequal prices.

What’s being bought and sold? Who’s the counterparty?

I’m not arguing right and wrong, just that you can’t call any permissionless extraction of value from a contract “arbitrage trade”.

And again, incorrectly assuming that 1) it somehow sets a precedent 2) the people making the decision then are the same that would be making it today 3) the overlapping people would make the same decision today as then 4) the EF and core devs have a strong authority on these matters

There’s always ETC if you want to stay on the timeline where the DAO hack executed as specified without being overridden. No one forced anyone to fork.

Bottom line: The core ETH team used their political influence to escape the consequences of "Code is Law", the very same criticism they made of existing legal systems -- that outside parties can come along and void the plain meaning of contracts and laws. That is the height of hypocrisy.

It sounds like the whole system has a huge public goods problem. In the real world stock market, buying TSLA is a signal that you believe the price is good, and if you're a big enough investor, your buy might move prices up before you complete. In this world, other people can steal that signal and move the price before your transaction even starts. Isn't this a design flaw?

There are ways to make marketplace contracts which allow buy and sell orders like this that aren't vulnerable to front-running. It's possible to have the buy and sell orders happen off-chain and then be settled on-chain later (Loopring works this way; there are other benefits to this system too such as speed of execution and lower fees), or for a marketplace contract to require orders to be preceded by a precommitment transaction, which includes a hash of the upcoming order, so the upcoming order can't be frontrun because the frontrunner would need to do their own precommitment transaction first.

Note that a marketplace contract like this isn't the only kind of smart contract; it's not the case that all smart contracts have the potential for front-running vulnerabilities. For example, there are smart contracts that do things like manage community funds and require people to vote on how the funds are spent, which don't do anything that could be vulnerable to front-running.

In the traditional stock market it supposedly works the same way, but the front-running is more well hidden: https://en.wikipedia.org/wiki/Flash_Boys

Great summary of one of the major problems with trading (and related financial activities) on public blockchains. The root of this particular issue is that transactions are not processed sequentially but ordered by how much someone is willing to pay.

Having spent much of my professional life designing and building trading systems, and despite the problems with current blockchains, I’m convinced there’s something here and blockchain technology can massively improve finance in a number of areas (cost, pace of innovation and openness/fairness of access being the big ones). What we’re looking at now on Ethereum and other platforms is a set of early experiments, and some weird (and often unsavoury) artefacts of the fact that technical research and experiments are intertwined with, and creating, financial assets and economic systems.

At my company, we’re working on the hard problems required to do this properly, and one particular area of research that we’ve contributed is a “fairness” protocol that can be added to the consensus layer of decentralised systems to provide a better alternative to ordering by fee for financial trading and that would prevent this sort of issue. We’ve published a paper describing this research at [1] if you’re interested, and a more accessible talk by the author, Klaus Kursawe, on the topic can be found at [2].

Disclaimer: my company is building a decentralised trading protocol for serious, professional use cases, and the linked research is part of our effort to achieve this mission.

[1] https://eprint.iacr.org/2020/885

[2] https://www.crowdcast.io/e/defi-discussions/85

Chainlink Labs is also doing research in this area: https://blog.chain.link/chainlink-fair-sequencing-services-e...

And then the OP is about privately asking some of the slow computer's owners to run your sticky note without showing it to everyone first. If this is good, why not let everyone do it?

It'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.

You 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.

My 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.

I 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.

Arbitrage 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.

Liquidation 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?

> 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.

Basically 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.

Reply on news.ycombinator.com