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

171–180 of 244 posts

Re: Learn Ethereum smart contract programming

#171

Post by DennisP »

VMG wrote: post #104
jesusthatsgreat wrote: post #86

Earlier quoted context omitted.

Maybe if you actually used it you'd see the benefits of it... try transferring any amount of value with Bitcoin.. take note of how much it costs and how long it takes. Then do the same with Ethereum. You'll start to learn pretty quickly what some of the main differences are. Regarding the 'fixed amount of Bitcoins' argument, I'd agree it's a nice simple marketing message but if you look in to what Ethereum is plannin…

> Then do the same with Ethereum. As long as you only ask him to do it, it will be fine. What if everybody using bitcoin did it though?

As of a couple months ago, Ethereum was averaging 50% of Bitcoin's transaction volume[1]. On June 11, Ethereum did more transactions than Bitcoin[2]. It managed this even though many of Ethereum's transactions are much more complex than Bitcoin's simple value transfers. According to the devs, the current version will top out around 10 to 12 tx/sec; Bitcoin has been stuck at 3.

So I think it's safe to say that Ethereum could easily absorb Bitcoin's transaction volume, even without Ethereum's planned scalability upgrades.

[1] http://www.trustnodes.com/2017/05/17/ethereum-reaches-50-bit...

[2] http://cryptoeconomy.info/2017/06/12/day-ethereum-processed-...

Re: Learn Ethereum smart contract programming

#172

Post by guscost »

lawless123 wrote: post #144
guscost wrote: post #126

Earlier quoted context omitted.

> the takeover-the-world echo-chambers of ethereum You toss out this pejorative description, and then in the next paragraph : > When talking about engineering on such a critical subject, people should be way more responsible. This is absurd. How could it ever become critical without a lot of research and development first? I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't sp…

>"I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other. Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in t…

Which part do you have a problem with?

Re: Learn Ethereum smart contract programming

#173

Post by patrickaljord »

simias wrote: post #164
patrickaljord wrote: post #152

Earlier quoted context omitted.

> "The code is law" is a wet dream for a dystopic authoritarian state and I don't understand why anybody, much less actual coders, would think that's a good idea. How is that dystopic and authoritarian? Looks like you're throwing a bunch of buzz words for shock value with little argument to back it up. We already trust code as contract everyday every time you make a payment through SSL (anyone who lived through the 9…

I gave some examples (that you quickly dismissed). Having a recourse through an other, hopefully compassionate and empathetic human being is not something I'm willing to give up on. If things go awry to the point where I could go bankrupt because of a small lapse in judgment I want to have recourses. That's why we have we have consumer laws. That's why we have the notion of abusive contracts. SSL is hardly related. I…

> hopefully compassionate and empathetic human

Hopefully after said compassionate human had their lunch break.

http://blogs.discovermagazine.com/notrocketscience/2011/04/1...

> That's why we have we have consumer laws. That's why we have the notion of abusive contracts.

That could still exist with Ethereum.

> SSL is hardly related. It's just a mean to secure a transaction and that's it.

Your browser's code trust the code on the server hosting the SSL cert and authority server. So, it's just code involved here.

> If I buy a laptop on amazon and they sneakily bill me for two tons of whole grain rice flour and when I complain they said "but it was in the terms and conditions", do you think it would hold up in court

Again, you could also sue someone for tricking you into a bad ethereum contract and it would not hold in court either. Not sure what your point is here.

> Ah, and it's clearly something we aim to emulate, right?

No it is not, my point is that bad things happen no matter who's involved (humans or code) and just because some bad things may happen doesn't mean we should stop using it, but we should go with the most efficient and secure one, which for now is probably humans of course. See also plane crashes.

Re: Learn Ethereum smart contract programming

#174

Post by Jabanga »

dallashoxton wrote: post #165
Jabanga wrote: post #159

Earlier quoted context omitted.

My understanding is that the halting problem does not prevent formal proofs of Ethereum contract correctness because Ethereum contracts have gas limits that make them terminating.

And the entire concept of 'gas' to me seems to be a hacky work-around in order to implement a Turing-Complete language on the blockchain. I'm not even sure it is needed -- the whole 'Turing-Complete' aspect of the EVM seems to be an engineering solution in search of a problem. And 'gas' is certainly not intuitive as a metaphor for end-users of Ethereum who would use it as a currency (how does a financial transaction…

Gas is analogous to cycles of the EVM that the contracts uses when it executes. Someone suggested 'gas' should have been called 'cycles' to more clearly convey its meaning and avoid a lot of confusion. Anyway, gas/cycles must be limited given there are no access controls on use of the EVM. It's an effective DoS control. It's also orthogonal to Turing Completeness.

Re: Learn Ethereum smart contract programming

#175

Post by seanwilson »

mbrock wrote: post #136
merijnv wrote: post #130

Earlier quoted context omitted.

Sure, you CAN verify Turing machines, but verifying languages that AREN'T Turing complete is sufficiently simpler. So why not make your verification work easier by using a total language? The only real argument against that would be "we can't do what we want in a total language". I don't buy the argument that what people want to do with smart contracts requires Turing-completeness. In fact, as time goes on I become m…

The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine. But those total systems are, of course, subsets of Ethereum, which means that if you write your program in an obviously finite way, you can use the same inductive proofs you would use for a total language. Turing completeness makes it hard to prove propertie…

> The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine.

I'm not an expert on Ethereum, but even if they did pick a total language, how would you deal with bounding the CPU cost of complex contracts? Even if you could formally verify a loop would eventually terminate, wouldn't long running loops or those with expensive computations have bad impacts on the network? Their "gas" system is their way of dealing with that and perhaps you would still need something similar even with a total language.

I can't think of program verification research where both termination and CPU cost is verified. I can think of some papers that deal with identifying Big Oh growth rates though.

Either way, smart contracts sound like one of the top tier areas where you want strong static typing that has a route to be formally verified.

Re: Learn Ethereum smart contract programming

#177

Post by masklinn »

dallashoxton wrote: post #147
masklinn wrote: post #43

Earlier quoted context omitted.

I understand the eth VM is pretty limited and limiting, but Solidity is just sad, it's like somebody saw Javascript and thought "ok that's a pretty terrible basis for writing contracts, but surely we can make it even worse ?" And then they succeeded at failing.

Can't remember where I read it, but someone put it best during the DAO fiasco last year when they wrote "Imagine Javascript but your bank account accessible through the Document Object Model."

Even that's only scratching the surface of how awful Solidity is. An example of minor security detail straight from the documentation is this:

    for(var i=0; i
Solidity is a "statically typed language" with "type inference". In most of these, you'd expect i to be typed as whatever the type of arr.length is, but Solidity does not care, it sees `var i = 0`, 0 fits into a uint8 so a uint8 i is, it'll get promoted during the comparison and if arr has more than 255 elements it'll overflow and the loop is infinite.

Re: Learn Ethereum smart contract programming

#178

Post by pmoriarty »

maneesh wrote: post #92
ericfrederich wrote: post #87

Earlier quoted context omitted.

Just shifting the problem. Okay, so the money is raised... you still never get your vaporware product.

You could program a smart contract to say "unless greater than half of funders agree tbat the product was shipped, refund everyone's money" It's a programmable decentralized escrow

What incentive do the funders have to agree that the product was shipped?

I mean, it's pretty obvious that such agreement on the part of the funders increases the likelihood that they will lose their money. So why agree?

I guess the person shipping the product could hope that the funders aren't assholes or theives and actually will agree that the product was shipped when it ships, but isn't the smart contract supposed to make such human signs of good will unnecessary? Otherwise, why have a smart contract (or any contract, really), as you can just rely on the good will of the participants?

Re: Learn Ethereum smart contract programming

#179

Post by seanwilson »

ekidd wrote: post #169
mbrock wrote: post #167

Earlier quoted context omitted.

If you're competent with proofs in Idris, you can write your EVM programs as an Idris DSL. But, I mean, there's no proof that the Idris compiler does what it's supposed to do, so you'd still have a huge trusted base.

> If you're competent with proofs in Idris, you can write your EVM programs as an Idris DSL. Yeah, all my formal proof experience is with Coq, which is just a bit too idiosyncratic and difficult for this sort of thing. But I seem to remember that—especially if you're willing to certify specific results , and not necessarily the program in general—you can make your trusted computing base very small indeed. I mean, if…

> I mean, if the CompCert C compiler can be as thoroughly verified as it is (http://compcert.inria.fr/compcert-C.html), there's no reason why it shouldn't be possible to verify smart contracts.

Hmm, so from the smart contract examples I've seen, I would have thought writing them in something like Coq would be quite feasible. The code examples I've seen tend to only have simple loops if any, basic conditions and the code is short (e.g. compared to something like web development or mobile apps). Writing anything inside a theorem prover is very challenging though but it seems a compelling application.

If you were implementing a smart contract in something like Coq, I'd be interested to read about what kind of specifications you would typically want to verify. I guess properties like "the owner of this wallet cannot be changed" and "the owner of this wallet can only accept money but not give it away" would be good ones.

Re: Learn Ethereum smart contract programming

#180

Post by hellbanner »

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…

"90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification" - are you referring to Bitcoin?

Or some other ideas that aren't currently implemented?

Post reply on HN