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

Learn Ethereum smart contract programming

ethereumdev.io

Post reply on HN
Print view View original

211–220 of 244 posts

Re: Learn Ethereum smart contract programming

#211

Post by naasking »

mbrock wrote: post #119
kbody wrote: post #109

The sad reality of Ethereum: 1. Bitcoin is slow and expensive, Ethereum is the future 2. Ethereum software has security hole, gets hacked 3. Ethereum fans say it's an experiment there are lots of things that will transform Ethereum (Casper/PoS, Raiden, zkSNARKs, Enterprise Alliance) 4. Low price getting pumped by Ethereum Foundation & big-holder affiliates 5. Back to #1 We've seen it happen again (DAO) and again (Par…

The belief that Turing machines aren't amenable to formal verification is a hobgoblin that shows up in every thread like this, but it's not real. Of course there are limited formalisms that make certain types of verification easier, but proving programs has been possible since, like, the 1960s. A multisig, for example, has a finite number of states when considered under symbolic execution. A model checker can rip thr…

> It's a disaster. But it's a disaster that points the way fairly straightforwardly.

A disaster that could have been avoided if they had done a little more research on security and smart contract languages:

http://lambda-the-ultimate.org/node/5003

Solidity is still clearly focused on programming productivity instead of contract soundness. The built in dynamism is proof of this.

Re: Learn Ethereum smart contract programming

#212

Post by naasking »

roywiggins wrote: post #132
naasking wrote: post #116

Earlier quoted context omitted.

> Smart contracts is probably the key word but I don't understand how it works or how it will benefit me. I virtually guarantee you don't really understand how the regular monetary system works either, but you can still use it and have some idea of how it benefits you. Ethereum can be used to set up another monetary system whose currency flows are guarded by code-driven contracts that anyone can write. So imagine the…

> code-driven contracts that anyone can write Anyone can write a contract, but only a handful of people seem to be able to write correct contracts. And an incorrect contract means your money is gone.

The question is why only a handful of people are able to write correct contracts. The answer is that Ethereum/Solidity didn't create a high-level smart contract language, they created a low-level procedural programming language with some smart contract abstractions. This type of language is already known to pose many difficulties.

If they had started with something like Nick Szabo's smart contract language, which is declarative, temporal and reactive, this would make smart contracts more intuitive and easier to get right. This sort of programming language has been empirically verified to be easier for most people to grasp.

Re: Learn Ethereum smart contract programming

#213

Post by mbrock »

seanwilson wrote: post #207
mbrock wrote: post #203

Earlier quoted context omitted.

The contract coders I work with try as much as possible to avoid loops altogether, because even if they're correct, they'll still have a linear cost, and that's usually not what you want. Almost all contract operations should be O(1). Sometimes we've made fairly large system design changes to avoid a loop in a function.

Interesting. So what's your view about the most practical language for writing contracts in then? For what I've read, having the sender setting gas limits seems really awkward especially when the limit is exceeded. Are there practical alternatives? Even with O(1) you'd need to limit the computation time.

I don't have a fully formed view yet, but I think Solidity is a pretty good prototyping language, disregarding all marketing hype that it's an "easy" language. While developing, you'd also be working on a specification of exactly how the contract shall behahve, and trying very hard to simplify ruthlessly.

The Parity multisig contract is very complex and I wouldn't and didn't trust any funds with it. I hope that the newly deployed fixed multisigs are bug-free but how would you know?

Right now I'm working on tools for static analysis of bytecode and using such tools to verify the correctness of contracts written by hand in assembly, which I think makes a great deal of sense for the simple contracts that we need as utilities (multisigs, tokens, etc).

Re: Learn Ethereum smart contract programming

#214

Post by rdiddly »

ym705 wrote: post #142
rdiddly wrote: post #140

Thread warning: I'm actively downvoting any argument that tries to address (read: not address) a cryptocurrency's flaws by changing the subject. Example: Person A: Cryptocurrency X is insecure isn't it. Person B: So is { the dollar | driving | flying | the internet | * }.

Don't you have anything else to do?

What could be more important than discouraging faulty argumentation techniques on the internet?

Re: Learn Ethereum smart contract programming

#215

Post by Lon7 »

mkagenius wrote: post #75
mbrock wrote: post #30

Earlier quoted context omitted.

You know Bitcoin is useful. One of the useful things in Bitcoin is that you can make a transaction conditional on a multiparty approval ("multisig"). This is used by many organizations to control funds in a safe way. Ethereum lets you construct even more interesting types of transactions. For example you can easily implement the logic of a crowdfunding (unless X is raised by time Y everyone is refunded). In that cont…

> In that context, "smart contract" is just a way of saying that you're not relying on the promise of a third party to perform the refund—it's automatic What if the code is malicious, and instead of auto refund it steals the money? I mean, not everyone would read the code to see what it really does, so what happens in that case?

One approach is that contracts can be associated with their hash. It is a bit silly for everyone to be writing the same smart contract over and over, with some versions being erroneous or malicious. So instead of having to run a potentially malicious contract, you are given a hash that points to one of a few different smart contracts that are known to be safe. The community has "white listed" a bunch of these known contracts and their hashes, so you are relatively safe using any contracts in these lists. Most miners in various cryptocurrencies will only run code that is on their communities version of the whitelist. Of course this only helps with some issues, not all.

*edit: and this is not ethereum specific. This approach was one way bitcoin tried to solve the problem and it has spread to most other cryptocurrencies I believe.

Re: Learn Ethereum smart contract programming

#216

Post by tachyonbeam »

pkulak wrote: post #189
ekidd wrote: post #151

Earlier quoted context omitted.

> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last…

Does Solidity really matter, though? "How's the VM" is the real question. I haven't spent more then 10 minutes looking into it, but it seemed reasonable to me. No heap and 256(?)-bit addressing seem like good ideas to keep execution complexity down.

It does matter if the use of Solidity is being actively promoted. Sure, maybe you're smart and you'll pick safer options, but if a huge percentage of contracts are written in Solidity, it could still mean there are massive security holes everywhere.

Re: Learn Ethereum smart contract programming

#217

Post by airza »

ojr wrote: post #208
kbhn wrote: post #206

Earlier quoted context omitted.

> You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy I would and do, because that's the reality of things. You're discounting the fact that if my bank has a SQL-injection exploit used against it and my account is drained, the federal government will reimburse me up to $250,000. That t…

it is because the federal government mints and controls the currency of dollars, with Ethereum you can create an arbitrary token and mint this token to any amount, essentially be your own federal reserve, Ethereum is an interesting software platform. Coinbase is fully insured all their digital currency is backed if a breach was to happen the customers will be refunded. So I suggest you keep your $250000 in there.

What does this first sentence even mean?

Re: Learn Ethereum smart contract programming

#218

Post by IncRnd »

ekidd wrote: post #151
kbody wrote: post #109

The sad reality of Ethereum: 1. Bitcoin is slow and expensive, Ethereum is the future 2. Ethereum software has security hole, gets hacked 3. Ethereum fans say it's an experiment there are lots of things that will transform Ethereum (Casper/PoS, Raiden, zkSNARKs, Enterprise Alliance) 4. Low price getting pumped by Ethereum Foundation & big-holder affiliates 5. Back to #1 We've seen it happen again (DAO) and again (Par…

> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last…

This! ^^

Solidity code is horrible, especially after looking at concise, maintainable, provably correct code.

Re: Learn Ethereum smart contract programming

#219

Post by orthecreedence »

airza wrote: post #217
ojr wrote: post #208

Earlier quoted context omitted.

it is because the federal government mints and controls the currency of dollars, with Ethereum you can create an arbitrary token and mint this token to any amount, essentially be your own federal reserve, Ethereum is an interesting software platform. Coinbase is fully insured all their digital currency is backed if a breach was to happen the customers will be refunded. So I suggest you keep your $250000 in there.

What does this first sentence even mean?

I translated it as "if there is a market opportunity for there being a private, ethereum-backed federal reserve, one will emerge."

Re: Learn Ethereum smart contract programming

#220

Post by grogenaut »

seanwilson wrote: post #198
grogenaut wrote: post #187

Earlier quoted context omitted.

I'm not sure static typing is tied to formal verification. In fact if you think about it most proofs are basically typeless I a lot of cases.

What proof systems are you thinking about? Strong static types seem the most natural way to introduce formal verification into mainstream programming to me.

Well general mathmatecial proofs or TLA+... or would it be better to define "integer" as a strong type which I'm willing to concede.
Post reply on HN