Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reviewing Ethereum Smart Contracts

blog.gdssecurity.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Reviewing Ethereum Smart Contracts

#11

Post by zeroxfe »

kevingadd wrote: post #8

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, battle-tested verifiable programming languages out there. Honestly, they could have used C and been better off because of the amount of C verification tools out there - Solidity hardly seems safer than C and its compiler has a history of potentially catastrophi…

Whoa there! Sure Ethereum has it's problems, but going as far as "the people running Ethereum have incredibly bad taste and make poor decisions", displays a huge amount of ignorance towards some incredible engineers who have built a fantastic (and very successful) platform.

Ethereum is far more than just the contract language -- it's the distributed consensus system, the merkle-tree backed blockchain, the p2p network, the cryptographic transaction ledger, the virtual machine, and much more. It is way more complex and sophisticated than you're giving it credit for.

There have been multiple languages to target the EVM, and they're been getting incrementally better, and will continue to evolve rapidly as more PL experts have gotten involved.

So for all the things they've got wrong, they've got lots more right -- and it's only been a bit over two years since the initial release. Give them a break!

Re: Reviewing Ethereum Smart Contracts

#12

Post by UncleMeat »

zeroxfe wrote: post #11
kevingadd wrote: post #8

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, battle-tested verifiable programming languages out there. Honestly, they could have used C and been better off because of the amount of C verification tools out there - Solidity hardly seems safer than C and its compiler has a history of potentially catastrophi…

Whoa there! Sure Ethereum has it's problems, but going as far as "the people running Ethereum have incredibly bad taste and make poor decisions", displays a huge amount of ignorance towards some incredible engineers who have built a fantastic (and very successful) platform. Ethereum is far more than just the contract language -- it's the distributed consensus system, the merkle-tree backed blockchain, the p2p network…

The EVM itself is fucked, not just Solidity. It has poorly defined semantics and has a number of strange behaviors that you don't want in high integrity systems.

Re: Reviewing Ethereum Smart Contracts

#13

Post by DennisP »

wruza wrote: post #6

Imagine if Windows 95 stored your payment data and was bridge-connected to the internet. This will give you an idea of how I look at these smart contracts. Is there any reason to think of it another way?

Yes: smart contracts are extremely short programs, usually doing very simple things. A thousand lines is a fairly large contract. It's feasible to spend a lot of time refactoring to make them as simple and clear as possible, to unit test extensively, and then pay several expert parties to review them in detail.

We're not quite at the point of being able to do formal proofs of their properties, but that's on the way, and also relatively practical given how short the contracts are.

We can see whether contract authors have done these things because unlike Win95, smart contract source code is always published, since everyone knows a closed-source contract could trivially steal their money.

Re: Reviewing Ethereum Smart Contracts

#14

Post by DennisP »

UncleMeat wrote: post #12
zeroxfe wrote: post #11

Earlier quoted context omitted.

Whoa there! Sure Ethereum has it's problems, but going as far as "the people running Ethereum have incredibly bad taste and make poor decisions", displays a huge amount of ignorance towards some incredible engineers who have built a fantastic (and very successful) platform. Ethereum is far more than just the contract language -- it's the distributed consensus system, the merkle-tree backed blockchain, the p2p network…

The EVM itself is fucked, not just Solidity. It has poorly defined semantics and has a number of strange behaviors that you don't want in high integrity systems.

For example?

Re: Reviewing Ethereum Smart Contracts

#15

Post by DennisP »

kevingadd wrote: post #10
zodiac wrote: post #9

Earlier quoted context omitted.

> Note that some of these bugs are in an optimizer, something a security-focused package handling money shouldn't even need Contract callers pay gas fees to execute the contract so inefficient contracts literally waste transaction fees - if anything optimizers are even more important here. > Any claims that performance justifies the use of a home-grown language are also absurd: High-performance trading firms like Jan…

You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You could easily build your own gas-focused optimizer for a toolchain like llvm or for a compiler like ocaml's. Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU, or some other metric. Then you wouldn't need to use a speci…

> Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU

No, you can't, because (1) you need consensus on the results, so you can't just have everybody measure CPU cycles on their own machines, and (2) you also can't trust miners to correctly report cycles on their own machines.

> cost of compute power continues to drop

Which is fine because gas is an abstraction. The price per unit of gas is market based.

Re: Reviewing Ethereum Smart Contracts

#16

Post by kevingadd »

DennisP wrote: post #15
kevingadd wrote: post #10

Earlier quoted context omitted.

You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You could easily build your own gas-focused optimizer for a toolchain like llvm or for a compiler like ocaml's. Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU, or some other metric. Then you wouldn't need to use a speci…

> Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU No, you can't, because (1) you need consensus on the results, so you can't just have everybody measure CPU cycles on their own machines, and (2) you also can't trust miners to correctly report cycles on their own machines. > cost of compute power continues to drop Which is fine because gas is an abstraction. The price per…

You can absolutely use a consensus model with cycle counting. The cycle count for x86 instructions (ignoring unpredictable factors like cache misses) is well-defined on all the modern architectures, you can find tables of the latencies and everything. There's no reason you couldn't do this instead of gas (though I don't know if I would argue that you should)

Re: Reviewing Ethereum Smart Contracts

#17

Post by fsiefken »

kevingadd wrote: post #8

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, battle-tested verifiable programming languages out there. Honestly, they could have used C and been better off because of the amount of C verification tools out there - Solidity hardly seems safer than C and its compiler has a history of potentially catastrophi…

As an alternative you could write your smart contracts with NEO in C#, F#, Java or Kotlin http://docs.neo.org/en-us/sc/introduction.html

Re: Reviewing Ethereum Smart Contracts

#18

Post by kevingadd »

zeroxfe wrote: post #11
kevingadd wrote: post #8

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, battle-tested verifiable programming languages out there. Honestly, they could have used C and been better off because of the amount of C verification tools out there - Solidity hardly seems safer than C and its compiler has a history of potentially catastrophi…

Whoa there! Sure Ethereum has it's problems, but going as far as "the people running Ethereum have incredibly bad taste and make poor decisions", displays a huge amount of ignorance towards some incredible engineers who have built a fantastic (and very successful) platform. Ethereum is far more than just the contract language -- it's the distributed consensus system, the merkle-tree backed blockchain, the p2p network…

I'm not willing to "give them a break" if they ignored decades of existing academic research and production software to roll their own low-quality packages that actively cost users money through bugs and footguns. Ethereum is not breaking new ground all over the place to the extent that would justify overlooking quality issues, even if it's the first to do particular things.

I'm sure the Ethereum ecosystem as a whole contains some clever designs or even good engineering by the people who back it, but that doesn't excuse the fact that they overestimated their competence and their customers are paying for it. It's not "more complex and sophisticated than I'm giving it credit for": I'm giving it "credit" for being too complex and too sophisticated, creating a huge attack surface for security vulnerabilities and lots of space for bugs to dwell because the developers insisted on NIHing things they had no reason to.

Complex and Sophisticated is not a good thing in mission-critical software. You want code that is as simple as possible, does the job correctly, and is easy to understand and audit. Complex and Sophisticated is what you write when tackling an incredibly difficult problem or when you're trying to get a promotion.

You seem to be confusing the (no personal opinion on this statement) "fantastic and successful" nature of the Ethereum platform with its quality. There's no intrinsic correspondence between success and quality. JavaScript is wildly successful and the experience of using it in 2017 is (thanks to modern tooling and browsers) pretty good, some people might even call it fantastic. But that doesn't erase the long history of defects in the language, defects that people continue to pay for. People invested sweat and blood to turn it into a successful thing.

Likewise, sweat and blood is being invested to compensate for Ethereum's numerous deficiencies. Some of those investments were made by the Ethereum developers - props to them - but a lot of that cost is being paid by end users, security researchers, and investors.

Tony Hoare calls nulls his 'billion dollar mistake'. How much do you think the cost of Ethereum's numerous design and engineering errors will add up to when all is said and done?

Re: Reviewing Ethereum Smart Contracts

#19

Post by DennisP »

kevingadd wrote: post #16
DennisP wrote: post #15

Earlier quoted context omitted.

> Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU No, you can't, because (1) you need consensus on the results, so you can't just have everybody measure CPU cycles on their own machines, and (2) you also can't trust miners to correctly report cycles on their own machines. > cost of compute power continues to drop Which is fine because gas is an abstraction. The price per…

You can absolutely use a consensus model with cycle counting. The cycle count for x86 instructions (ignoring unpredictable factors like cache misses) is well-defined on all the modern architectures, you can find tables of the latencies and everything. There's no reason you couldn't do this instead of gas (though I don't know if I would argue that you should)

If you are ignoring cache misses, and using a particular CPU architecture instead of whatever is actually running, then you're back to using gas. You still have a fixed list of costs for different operations, it's just a different list.

But CPU cycles aren't actually a sufficient cost model, since you also have to pay for storage.

Re: Reviewing Ethereum Smart Contracts

#20

Post by kevingadd »

DennisP wrote: post #19
kevingadd wrote: post #16

Earlier quoted context omitted.

You can absolutely use a consensus model with cycle counting. The cycle count for x86 instructions (ignoring unpredictable factors like cache misses) is well-defined on all the modern architectures, you can find tables of the latencies and everything. There's no reason you couldn't do this instead of gas (though I don't know if I would argue that you should)

If you are ignoring cache misses, and using a particular CPU architecture instead of whatever is actually running, then you're back to using gas. You still have a fixed list of costs for different operations, it's just a different list. But CPU cycles aren't actually a sufficient cost model, since you also have to pay for storage.

The original argument (not yours, to be fair) was that EVM/solidity + an optimizer are necessary because contracts are billed for gas. I was attempting to illustrate that you can build a platform around a more representative billing system (you can pick one!) such that existing, world-class languages can be used instead. This pays security dividends and reduces the cost of your system (for everyone, not just you).

Whether or not gas is a useful solution as-is isn't a particularly important question to me, and I don't see any reason why you'd want to replace it now. It's just a poor excuse for Solidity/EVM.

Post reply on HN