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

161–170 of 244 posts

Re: Learn Ethereum smart contract programming

#161

Post by lou1306 »

paganel wrote: post #44
omarforgotpwd wrote: post #16

Programmable smart contracts are a great idea in a world where programmers write bug free code. That world does not exist yet. Until we have near-perfect code writing AIs every new smart contract is just a disaster waiting to happen.

> That world does not exist yet With a big emphasis on "yet". Serious question: are the "halting problem" and the "yet" in your sentence dependent on each other? I.e., don't we need to first solve the halting problem before we can manage to write 100% bug-free programs?

I don't see how you can "solve" the halting problem. But there are lots of ways to tiptoe around it and have some kind of formal verification of software.

Re: Learn Ethereum smart contract programming

#162

Post by Jabanga »

justadeveloper2 wrote: post #155
throw2016 wrote: post #112

The problem with crypto coins is some have bought in and thus are vested making balanced discussion impossible. We see even with something as trivial as choice of programming language some can become very religious in their support. When money becomes involved expecting rational discussion is perhaps naive. Money is a social construct that needs societal consent and a framework to manage it that is accountable to the…

Not only is it a social construct, but the concept of money took thousands of years to evolve, with fits and starts, to what it is today. No matter what, some new technology isn't going to just show up all of a sudden and completely revolutionize what is an intrinsic component of human civilization. To think otherwise is to be taken in by scammers. I know that current money systems have flaws and are manipulated by t…

I think you're underestimating the impact of a durable and formal consensus mechanism that can be run by machines and can operate efficiently at a global scale by utilising telecommunication networks. This is orders of magnitude more efficient than traditional governing structures and will displace several core industries over the next few decades in my opinion.

Re: Learn Ethereum smart contract programming

#163

Post by andreasgonewild »

Please, enough with the JavaScript already; there are thousands of saner means of expression already existing or waiting to be discovered. Writing flawless, verifiable contracts is the worst use-case ever for that stinking pile of a language. I wonder how many missing bazillions it's going to take for the world to wake up and move on.

Re: Learn Ethereum smart contract programming

#164

Post by simias »

patrickaljord wrote: post #152
simias wrote: post #145

Earlier quoted context omitted.

I think I'm going to end up pasting this link in all discussions surrounding Ethereum: https://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law >When one obeys the letter of the law but not the spirit, one is obeying the literal interpretation of the words (the "letter") of the law, but not necessarily the intent of those who wrote the law. Conversely, when one obeys the spirit of the law but not the letter, one is…

> "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. It's just a mean to secure a transaction and that's it. There's no contract involved. It's a tunnel for some data. A more apt comparison would be to say that I trust, say, Amazon's website to do the right thing when I give them my credit card infos. But the truth is that I don't even trust them that much, if they abuse it or get compromised I'll just notify my bank (if they don't notice it before I do) and I'm good to go.

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?

>I hope you're aware that the exact same thing happened with these indexed loans where people weren't aware that interests could fluctuate with time, right?

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

If anything that's a very good example about how the average person can be tricked into accepting a terrible contract if they don't know any better. Do you think it would've worked better if the loan was expressed in Solidity code?

Re: Learn Ethereum smart contract programming

#165

Post by dallashoxton »

Jabanga wrote: post #159
paganel wrote: post #44

Earlier quoted context omitted.

> That world does not exist yet With a big emphasis on "yet". Serious question: are the "halting problem" and the "yet" in your sentence dependent on each other? I.e., don't we need to first solve the halting problem before we can manage to write 100% bug-free programs?

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 "run out of gas", exactly?)

Re: Learn Ethereum smart contract programming

#166

Post by DennisP »

KirinDave wrote: post #138
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 other sad thing is that Solidity, the language of Etherium, is a trainwreck. It has tons of bugs, properties that maximize the memory cost of the program, and until ~6 days ago had crazy double init bugs in constructors using "this".

Looking at Solidity's release log, the last update was 18 days ago. It fixed some minor bugs from the previous release three days prior, and none of the bugfixes mentioned in the previous release seem to fit your description. Do you have a link?

https://github.com/ethereum/solidity/releases

Re: Learn Ethereum smart contract programming

#167

Post by mbrock »

ekidd wrote: post #157
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…

Corecursion and codata are cool, and I would trust Solidity vastly more if it were a "total" functional language with no mutable state and aggressive type checking. Or if it were something more like https://www.idris-lang.org/ , where I had abundant tools to rigorously prove that nobody could steal my money. Basically, if I'm going to spend even 5 minutes playing with smart contracts, I want to feel like the language…

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.

Re: Learn Ethereum smart contract programming

#168

Post by JackC »

hackermailman wrote: post #135

If you are considering writing a smart contract, you should read this first https://github.com/ConsenSys/smart-contract-best-practices for Solidity security pitfalls, and hopefully have some idea of invariants/contracts to verify expected properties of your smart contract https://www.cs.cmu.edu/~rjsimmon/15122-s16/lec/01-contracts.... and additionally hope the EVM doesn't have unexpected behavior. Anybody know if the…

> I wonder if somebody who finds a flaw in a smart contract can legally just jack all the coins

One way to interpret this legally is to assume that smart contracts are in fact enforceable legal contracts. (Most promises about exchanging stuff are enforceable legal contracts, so this is plausible.) The general first-year-contracts answer is then that it depends on the expressed intent of the parties.

Take two extreme examples:

(1) I put an ether bounty in a smart contract and say anyone who can exploit the contract can have it. Definitely legal to exploit (and I can be held to the promise).

(2) I hire you to review my smart contract for exploitable flaws, and instead you exploit the flaws. Definite breach of contract.

The real situation is neither of those, but you can see how expressed intent matters.

So the question is what's the actual expressed exchange of promises between the parties to a given smart contract? And here I think some of the code-is-contract statements around Etherium tilt things toward my (1) example - the text advertisements for the DAO have a bunch of stuff to set the expectation that whatever the code says, goes. But that would be up for debate in court.

(And then there's lots of non-contract ways to slice this, from computer fraud to gambling law to securities law to...)

Re: Learn Ethereum smart contract programming

#169

Post by ekidd »

mbrock wrote: post #167
ekidd wrote: post #157

Earlier quoted context omitted.

Corecursion and codata are cool, and I would trust Solidity vastly more if it were a "total" functional language with no mutable state and aggressive type checking. Or if it were something more like https://www.idris-lang.org/ , where I had abundant tools to rigorously prove that nobody could steal my money. Basically, if I'm going to spend even 5 minutes playing with smart contracts, I want to feel like the language…

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

Re: Learn Ethereum smart contract programming

#170

Post by justusw »

elmigranto wrote: post #56
mitchmindtree wrote: post #28

Earlier quoted context omitted.

We put our lives in the hands of code written by humans every day, e.g. cars, planes, trains, etc. Perhaps the permanence of executing solidity contracts will at least motivate some safer, more secure practises, in the same way that the permanence of death does when programming vehicles that carry human lives. It would be cool to see APIs for compiling Solidity contracts from safer languages with more concise type sy…

> We put our lives in the hands of code written by humans every day, e.g. cars, planes, trains, etc. Except that code is regulated and tested to the degree average eth enthusiast making this point either not aware of, or intentionally omits.

Not only is it regulated and tested, the question of liability is easy to answer: Product Liability is regulated by countless national and international laws.

But in the case of Ethereum Smart Contracts, who is liable in the real world?

Post reply on HN