Hacker News Reader

Comment by ddtaylor | Hacker News Reader

> Smart contracts basically throw all of your consensus guarantees out the window because they can cause arbitrary exchanges of value in the application layer, which can be used to incentivize miners into all sorts of shenanigans.

Do you have an example?

View on HN

So glad you asked:

1. https://eprint.iacr.org/2019/748.pdf 2. https://arxiv.org/pdf/1810.11605.pdf 3. https://eprint.iacr.org/2019/775.pdf 4. https://users.encs.concordia.ca/~clark/papers/2019_wtsc_fron... 5. http://homepages.cs.ncl.ac.uk/patrick.mccorry/minerbribery.p...

This one isn't an attack per se, it is mostly an exploration of arbitrage bots in decentralized exchanges running on Ethereum smart contracts. However, they point out that miners can trivially capture the value of the arbitrage transactions by front-running, and that this "free money" is like a bonus block subsidy that falls outside of the PoW consensus models:

6. https://arxiv.org/pdf/1904.05234.pdf

This one actually operates through transaction fees only, so it doesn't depend on smart contract functionality. However, it is waaaaay more expensive (for the attacker) than the others:

7. https://www.cs.umd.edu/~jkatz/papers/whale-txs.pdf

You're using a poor implementation of an app as a reason why smart contracts are bad. I hope you realize this is the same thing as saying databases are bad because of the Equifax hack.

I don’t think you understand. The arbitrage bots aren’t exploiting poorly written contracts, they are capturing free value that users of a dApp have opened up. This free value is available to miners as well, and could be used to subsidize an otherwise-unprofitable double spend attack.

But more to the point: allowing smart contracts in a blockchain introduces all of the complexity of trying to make any other piece of software secure. Except... now it’s on a blockchain where the code is open source and mistakes can allow adversaries to steal money, not just data. How is this an improvement?

I do understand. I work in the industry, specifically with decentralized exchanges. Both the order book and the order matching should be P2P with 0 conf transactions and client side verification. The fees paid by the user should be top off fees for the contract balance rather than pay to play fees.

I did about 0.1% of the amount of research you did a few years ago and was really struck by the irreversibility of mistakes. Other engineering domains can have irreversible (e.g. fatal) mistakes as well, but they don't have as many enthusiasts jumping in to the field.

Our CTO likens developing a smart contract to civil engineering. Our CTO also remembers what it was like to ship your software in its final form on a floppy disk!

I think it’s great that more and more people are jumping in and learning what it’s like to develop in such an unforgiving domain (no point here, I just think it’s great!)

I completely agree! It's sparked an interest in formal methods and learning more about how engineering takes place in other disciplines to improve their product quality.

Learning on the job in an unforgiving domain can be costly.

The blockchain is indeed fraught with peril. Code review, audits, and bug bounties are an absolute necessity when it comes to smart contracts! Learning in a high stakes situation seems pretty good as long as you have a robust support structure.

I haven't read all those papers, but basically you could always bribe miners, even without smart contracts, just by giving them money outside the blockchain they mine.

One of the ideas of PoW is that if you have enough money to bribe the miners, it's better for you to be a miner yourself. Is this the principle your examples weakens? I may have misinterpreted them.

Bribing outside of the system (i.e. in real life) could be a tremendous coordination and logistical challenge, especially given the amounts needed to make these attacks profitable. Smart contracts can make all of that trivially easy.

It’s like... the people most interested in trustless collaboration are people who are untrustworthy. A trustless settlement layer seems fine, but any real human application is going to have an element of trust and doesn’t belong alongside settlement.

Reply on news.ycombinator.com