Learn Ethereum smart contract programming
ethereumdev.io
ethereumdev.io
We've seen it happen again (DAO) and again (Parity) and it will keep happening, because it's broken by design. 90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification.
I appreciate the experimentation, but the takeover-the-world echo-chambers of ethereum that don't focus at all on the real tech behind it and ignore everything negative is pretty disappointing. Especially because we keep getting new people buying this and becoming the greater fools.
When talking about engineering on such a critical subject, people should be way more responsible. If Bitcoin had the same attitude regarding security like Ethereum does, we wouldn't be here and cryptocurrencies would be a joke.
Lazy engineering comes at great cost as time goes by and the illusion of security is unveiled.
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 through it and prove whatever properties you want.
Is the Ethereum world right now full of buggy contracts that haven't been proven correct? Yes, absolutely. It's a disaster. But it's a disaster that points the way fairly straightforwardly.
Should Ethereum not have been launched until it had solid methods for auditing and proving? Maybe, but that's not how the world works, typically. Worse is better and all that.
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 more and more convinced that Turing completeness is highly overrated. Almost all code wants to do finite and/or structurally inductive operations. The only case that doesn't fall in that are things like request loops where you want to "infinitely" wait, process request, loop back to waiting. But even those things can be done in total languages via co-induction, so exactly why do we want to make our analysis/verification work more difficult by using a non-total language for things like Ethereum?
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 properties automatically about arbitrary programs, but you can still prove properties about specific programs.
I'm pretty sure that MOST research on program verification has been done in the context of Turing complete systems, from the work of Floyd and Hoare, to the symbolic execution of Deutsch and King, to temporal logic, TLA+, etc.
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.
General mathematical proofs? If you mean paper proofs they wouldn't be considered formal as they don't go down to the axiom level.
Exactly, knowing that the contract code will eventually halt is nice to know but knowing that it will halt after a reasonable CPU cost seems much more important in this case (which is really interesting).
From what I've seen from example contracts, it doesn't seem like the chance of infinite loops is that high. Personally, I find that in mainstream languages, if you accidentally write an infinite loop you find out very quickly on the first few runs and code that could be hiding an infinite loop stands out. The vast majority of loops just iterate from the start of a collection to the end.
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.
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).
Yeah...any ideas why they didn't go with a language that had an easier route for formal verification? It seems like an ideal application and the contract specifications seem like they would be fairly straightforward to prove (compared to what you'd see in most journal papers for instance). I'm guessing the designers just weren't aware of theorem provers but I'm puzzled why they didn't go with a language with strong static typing where private access and immutability are the defaults plus avoiding anything to do with the mechanism they have for picking default handling functions when a message isn't understood. Great experiment to watch though!
Basically, if I'm going to spend even 5 minutes playing with smart contracts, I want to feel like the language designers were incredibly paranoid and aware of just how good modern languages can be at provability and security.
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.
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.
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.
Jack Petterson and Robert Edström did a master's thesis about retargeting the Idris compiler to emit EVM code, with a custom effect type to express smart contract effects. They ended up modestly skeptical of functional programming as a paradigm for EVM, instead looking toward process calculi. https://publications.lib.chalmers.se/records/fulltext/234939...
Yoichi Hirai's summary of his research into Ethereum formal verification as a full-time formal methods researcher at the Foundation: https://github.com/pirapira/ethereum-formal-verification-ove...
See especially his formalization of the EVM as Hoare triples in Lem, which is usable from Isabelle: https://github.com/pirapira/eth-isabelle -- very cool stuff, although I have to say that the ostensible complexity and difficulty of his proof verifying an utterly simple wallet contract makes me a bit skeptical of this approach to smart contract correctness: https://github.com/pirapira/eth-isabelle/blob/master/example...
Solidity doesn't have a problem with formal verification of programs. Check their bug tracker: you can't even trust the runtime to do what it claims to do. On several levels.
As a platform for experimentation that's fine. As a platform for doing real things with meaningful amounts of money, it's madness.
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.
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 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 the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out.
This is the exact spiel we're all sick of hearing.
The people writing programs on it are writing bad programs.. but even if they write them well the environment has vulnerability built into it .
>Why are you even in this thread?
Why are you here? it's one of the top posts on this site today.
You opened by explain how you clearly have an interest in this, you got in, and since you are saying you bought during a "decent dip" that means you only got in recently.
The rest of your post would be shilling only that you disclosed your interest.
So I would be shilling in a hypothetical scenario, and that's the problem?
OK, whatever. Have a nice day.
I'm sorry, 18 days, not ~6. I said 1/3rd the real duration. Since Solidity has only been around about 800 days, 12 days is a non-trivial error.
Still: my complaint that the language is poorly architected and dubiously implemented and tested stands.
Solidity definitely has design warts; possibly Viper will end up the leading language, once it's production-ready.
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 30 years. Samples:
- "Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0."
- "All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default"
- "Order of evaluation is not defined for expressions. This in a language that has value-returning mutating operators like ++!"
I wouldn't trust a Solidity smart contract with $100.
Edit: And again erlang people can't take a joke. I'm literally making fun of myself for having an invalid bias and erlang folks take it as an attachment on the language.
It's also a commentary on how long it takes for devs to mind shift and incorporate new ideas.
Immutability prevents things like in-place appending to an array, or in-place modification of a string.
Single-assigment means that the value bound to "someVariable" cannot be changed. E.g. `someVariable = new String("hello"); someVariable = new String("goodbye");` is illegal. But it still may be possible to mutate the value `someVariable.substitute("hello", "goodbye")` if the language allows mutation.
A new monetary system created 3 years ago and is highly demanded might have some growing pains
You hold $0 of Ether but suggest on how to spend it, you wouldn't send ether to a contract that was coded poorly or vulnerable so the language is not as important as you make it seem.
Ethereum has a great bug bounty program so contracts that are vulnerable get exposed fast. Each new smart contract should learn lessons for previous contracts and the software will improve over time, imagine that...
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 type of peace of mind does not come with Ethereum; in fact it's billed as a feature.
Solidity code is horrible, especially after looking at concise, maintainable, provably correct code.
Or some other ideas that aren't currently implemented?
The exploits so far were NOT security holes in ethereum, they were poorly written smart contracts by third parties.....
https://github.com/pirapira/bamboo
This one takes a strict state machine approach, and aims to solve some of the tricky reentry and state tracking problems of Solidity.
Literally no one within Ethereum calls it an experiment. You have to cherry-pick from population and then ascribe it to the whole for this to be even sensical.
Essentially every technology we can think of can be rooted back to the 90s, or really any period we want to look at since that is how knowledge works. If you've got a particular, say it...rather than just this poor, lazy attempt at a sort of character assassination by employee (fairly inaccurate) appeal to oldness.
It is thoroughly _without merit_ to suggest that the analogous components of ETH and BTC have BTC being more secure. In fact, the opposite is true by any reasonable measure. Further, there are indeed things that Ethereum tries to do that add complexity, but if they come with value we shouldn't then find ourselves saying things like you do that amount to a sort of "my abacus is more secure than quickbooks online" - different purposes, solving different problems and creating different sorts of value. Even beyond that BTC holds all records for security events and $ cost of them, coin-loss amounts of of them, and so on.
This is the sole reason why I don't think it will be successful in it's current state. With most successful tech or services or whatever the core idea is often super simple to grasp and you can instantly see the benefit. I don't see this with Ethereum.
Even with bitcoin which is complex the benefits are instantaneous for the common man. Decentralized system, no single entity controls it. It is a fixed amount of bitcoins so like a mineral it's value is probably going to be stable in the long run and also each bitcoin will increase in value when more people get interested. It's easy to send coins to anyone in the world, at any time.
What does Ethereum do? Smart contracts is probably the key word but I don't understand how it works or how it will benefit me. Why bother?
Do you really think I should have to?
No you don't have to. You just have to trust that the community has provided you with a secure, usable tool.
It is unreasonable to expect you to understand the engineering that goes into this kind of thing, if you are not a computer science educated individual. That is not the point of participation though. Developers don't have an intrinsic right to participate.
The exclusion because of complexity is unfortunate, but necessary. Making something that is decentralised, distributed, trustless, useful, simple (in terms of contract execution) and secure is nearly impossible without technical feat.
But you don't need to understand the mechanics of Ethereum or the EVM. The minimum you need to understand is tha Ethereum is used like fuel to pay for contract execution (GAS).
Solidity is not a hard language to grasp. It has simple inputs and outputs. Why not try playing with solidity code on the testnet compiler if you don't want to read the whitepaper.
https://ethereum.github.io/browser-solidity/
Or do a Udemy course.
:)
This argument can get dangerously close to 'clever people have invested a lot of time and effort into this, so you should either invest the same amount of time and effort or trust that the whole thing is safe.'
Not sure this holds up, especially when increasingly people are being asked to trust Ethereum, but anything, like Parity, that interacts with it.
Have you flown anywhere lately? Inspected the plane before you took off?
It's true for the risk you take you must be assured that engineers are making things safe.
Lots of planes crashed before we got to the incredible safety record we have today, which is paid for by people having trust in airlines, who employ competent engineers.
The only difference here is that the organisation is a decentralised one. The engineers are not paid but are incentivised by the network.
It will take time to remove errors from the network and for best practices to emerge. As for novices making basic errors and losing money. The internet is littered with problems like that in all languages.
This is not a reason to not attempt to do something new.
> The only difference here is that the organisation is a decentralised one. The engineers are not paid but are incentivised by the network.
ETH Engineers are also disincentivized from refactoring code / doing CD, as they have to pay a fee for every deploy. I'd imagine that the safety record for airlines would not look as it is today if engineers had to pay a small fee for every safety modification they wished to make.
The analogy with airlines is also faulty. There is no real financial incentive for a bad actor to find a software bug that is capable of crashing an airliner. There's nothing financially they can gain out of it. However, with the amount of money bound up in the ETH network even currently, any bug found by a bad actor could potentially land millions of dollars. Almost any amount of time spent pen-testing is trivial compared to that, so you will find a lot of bad actors actively seeking to find software vulnerabilities.
Not heard of plane hijacking?
ETH engineers are totally incentivised to write the most perfect code possible. With a world of people wanting disintermediation, the rewards for getting and keeping it right and safe are incredible. Partly because the penalties are too.
The compensation for running and maintaining good secure contracts is exactly the incentive needed. You should try and understand the workflow before blindly critiquing it. CD is not a real feature of blockchain technology, and neither should it be. Does NASA run CD on satellite software? Can you run CD on a plane in mid flight?
It is exactly the same thing as flight and space software. You get one chance to get it right. You get paid for doing good work - by the network.
I've never ever heard an ethereum developer complain about the cents they have to pay to deploy a contract, after having extensively tested it on the testnet for free.
Another version of that could be that the logic is sent out to all interested peers and they only actually send Ethereum to the correct wallet after the logic in the contract they got sent is executed.
This is the parts of Ethereum that is so very confusing. People are simply swinging around with words like "smart contracts" but there are little to no actual description on how it actually works.
But in many cases you do want some ability to upgrade the code, and then you simply program in that ability by creating a repointable proxy with whatever authorization logic you want.
If you are a big name in the Ethereum community, they will soft fork Ethereum so that your mistake is rolled back.
Precedent seems to indicate otherwise.
[1] https://www.theregister.co.uk/2017/07/20/us30_million_below_...
Some clarifications: Ethereum = the project or the foundation itself Ether = unit of (crypto)currency used in Ethereum
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?
This is true with real world contracts too, that's why people hire lawyers - they understand the "code" of contract law.
It may be less attractive recourse than exists with plain contracts for many potential participants, though.
Unfortunately, that they failed to see it doesn't mean it isn't so, and now every new conflict among blockchain participants is an exciting new opportunity to reinvent another piece of several hundred years' worth of too hastily discarded prior art.
In 1931 Britain floated the pound, which arguably the US ought to have done too. Suddenly, your paper is no longer convertible to gold at a fixed rate. That's an even more dramatic change than the Ethereum fork.
*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.
It's a programmable decentralized escrow
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?
The blockchain tracks the program's state and handles state transitions. Read-only functions are free to execute; functions that alter the program's state cost Ethereum to run.
That's it. It's quite powerful and conceptually simple, but the phrase "smart contract" seems to throw a lot of people off.
The issue with the system is that you can't update the contract, which means it has to be perfect when it is distributed on the blockchain. 1 bad mistake away from loosing maybe the entire wallet and it seems to already have happened several times.
The main issue that it is a big incentive to find bugs since you can make a lot of money from it and the contracts are vulnerable since they can't be updated.
But people in favor of this system, Ethereum, seems to just wave shit like that off with fancy words. If some system handles my money, it better be damn secure and the only way to be secure IMO is constantly updating it.
And the recent hack exploited exactly this: a harmless-looking piece of code that turned out to have a serious bug allowing re-initialization of a wallet. The exploit allowed black hats to take control of certain unpatched wallets.
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 planning to do, issuance could well go to close to zero, zero or even below zero once proof of stake is introduced: https://twitter.com/VitalikButerin/status/879858608091144193
As long as you only ask him to do it, it will be fine. What if everybody using bitcoin did it though?
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-...
I understand why they would want to do this but I think it gets the priorities wrong. It prioritizes features and functionality over security and reliability. Given how hostile the Internet has become I think this is a mistake.
My guess is that Ethereum is only a couple of scandals away from being perceived as a fundamentally insecure platform. Bitcoin has its own problems and it may not survive either. Perhaps another cryoto currency can learn from the mistakes of both and deliver something better?
Also known as Zawinski's law: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
I have no problem with JavaScript itself, it allows developers to build some amazing web applications. What I object to is the default use of JS for every web site. I would rather see JS limited to a small set of trusted sites and HTML (with server side rendering if needed) for everyone else.
Then, think of Etherium as: decentralized virtual slot machines no single entity controls
So visualize a slot machine: it advertises only the various ways you could win (in fact it never discloses the number of non winning combinations which are far greater in number) in other words manufacturers advertise only the possible upside to get you to put your money in. At best the thing being advertised happens at worst something else occurs which wasn't advertised, namely you lose your money.
The big difference between smart contracts and slot machines, is the ownership, in theory the casino owns the slot machines or at least leases the slot machine from the manufacturer, and so the casino gets the profits guaranteed by the code of the slot machine. Similarly smart contracts are crated/manufactured by an individual or groups of individuals, But here is where is gets tricky...instead of a casino hosting slot machines, smart contracts will live in perpetuity hosted on a blockchain. So whereas the slot machine directs funds that aren't wins to the casino, where do such funds in the smart contracts go? To wherever the smart contract tells the funds to go, even if it's an anonymous account (really owned by the smart contract creators) or the ability for any 3rd party to claim said funds. This little trick of anonymity allows the contract manufacturers to at least claim ignorance of the location of the funds.
There is one more thing to remember, Proponents of the smart contract somehow believe between the step the manufacturer creates the contract and releases said smart contract in the wild in perpetuity, by placing the smart contract on the blockchain, they somehow become indemnified legally (both civilly and criminally) from any damages the smart contract causes. In a most extreme example proponents i talk to believe you could build a bomb coded to go off upon a funding event, and once placed on the blockchain they would have no liability for the damage caused by the bomb because they claim the bomb was controlled/detonated by the code.
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 e-bay auction process as a smart contract that's controlled directly by the monetary framework, without involving Paypal or credit card companies, or any other centrally managed financial institutions.
The core idea behind Ethereum is sound and first envisioned a long time ago [1], but the current implementation leaves a lot to be desired. The Ethereum languages are being designed by programmers who try to address the needs one encounters in programming, like delegation patterns and some types of dynamism that makes extension and reuse easier.
Unfortunately, this is often the opposite of what you want for robust contracts, where writing the contract is not the important part, it's understanding all of the possible outcomes and what causes them. The dynamism makes static analysis hard, so understanding the behaviour of the complete system is too difficult, and vulnerabilities proving this point will continue to crop up.
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.
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.
Anybody know if the legality of exploiting leaky smart contracts has been tested? Since a lawyer can exploit a badly written contract I wonder if somebody who finds a flaw in a smart contract can legally just jack all the coins or alternatively, write purposely obfuscated contracts (underhanded Solidity contest) to run a scam.
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...)
Just one example: "Our function EndLottery() must be only accessible by the owner of the lottery." [0]
function EndLottery() public { if (msg.sender == owner) { ... } }
What about code guards? Not to speak of decent typing, etc. etc.
[0] https://ethereumdev.io/managing-multiple-users-a-simple-lott...
But the main question remains: Why don't they utilize the progess we made in decades of research for better programming languages?
The argument that Solidity should be useable by the average programmer doesn't hold, in fact, typing makes programming easier since it clarifies data structures that are implicit in languages like JS.
A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues for background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211
Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).
And then they succeeded at failing.
for(var i=0; i<arr.length; ++i) {
Because the program author has no admin privileges, users don't have to worry about the service provider abusing their admin privilages to secretly modify the database (which may otherwise be a concern for high-value applications such as, e.g. vote-counting, e.g. a database that stores bank account balances, etc).
The disadvantages are (1) it is much more expensive compared to other cloud computing services, (2) since the uploader doesn't have admin access, they can't fix bugs, and since everything is transparent, it's hard to store secrets.
But as you said writing your own is also error prone.
I'm pretty sure that developing your own has much, much higher risk than using some pre-existing solution.
If I understand correctly, these are a way to automate the execution of the financial part of normal contracts without the need for undue trust between parties. Some simple examples that might help (and I invite correction):
• I and a few investors agree to buy into an enterprise in several installments. A contract can be written to the blockchain that automates these payments. Should a majority of the investors decide to withdraw support, the payments will cease, but while more than 50% wish to continue support, everyone will continue.
• I have an enterprise that I am highly confident will generate profit. I can establish a smart contact that guarantees my investors a minimum ROI at specific intervals; should the balance fail to grow by the agreed margin, all investors will instead be refunded (in full or part) based on a scheme agreed a priori to be fair — say, a function of shares owned for how long.
• I and several other Ethereum miners agree to develop a scheme built on top of Ethereum for, say, a specific method of interoperability between the Ethereum blockchain and traditional futures markets. We have a specific idea for this, but agree we need to ensure that there is momentum in the project, and want those participating to have 'skin in the game'. We build a tontine such that all of us invest a non-trivial amount, and any investor becomes ineligible for payout if their hash power abandons the protocol. If this falls below a certain threshold, remaining investors can vote to continue or divide the pot and abandon the project.
It is possible to create a smart contract, like the DAO, which implements the rules of a joint stock company. But stockholders are not concerned about the risk that these rules will be broken. The risk is that the company fails and there is nothing to distribute according to the rules. Replacing the general meeting of stockholders with a smart contract doesn't change the economics of collective investment – it just adds the risk of losing everything to a bug in the contract.
without the need for undue trust between parties
The idea of people coding up weekend projects on Ethereum, putting them behind flashy websites and encouraging large scale adoption terrifies me, to be honest.
It's a near certainty that I won't get hit by a car tomorrow - people do get hit by a cars but most people don't get hit by cars most of the time. There is a risk (a fraction of percent), but it's acceptable.
It's an even larger certainty that code will have bugs. As far as I've seen, all code will have bugs, as experience shows, even security oriented code carefully made and reviewed by experts tends to have bugs, but it is possible (though not as likely) that a small piece of carefully audited code will be bug-free. That's a bit different than the risk of getting hit by a car; it might be more fair to say that you have a "risk" of being bug-free comparable to the "risk" of winning a lottery.
If smart contracts are at all useful, they most definitely will be useful before we have near-perfect code writing AI's.
It's also possible (and I feel that this will be the case) that in the end the risks will be too large anyway for large adoption, so we'll collectively decide that for most use cases smart contracts are useful only with a "social" mechanism for overriding them, contrary to the current "code is law" policy of Ethereum.
Before you write a comment with "why not", apply that to eth first.
Granted, bugs are much more common than legal loopholes, but in the same way an operating system's APIs and constraints are tested until it becomes reliable enough for other people to rely on it, I can see some standard types of contracts (in the same way as in the traditional legal system) becoming recognized for their robustness and used for common operations.
Furthermore, a contract, or at least a clause, will become invalid if it goes against existing law in a country (at least this applies to the EU). E.g, I cannot sign a contract in which I sell my kidney to you, as commercial organ trading is outlawed in many countries.
Is a smart contract able to make this distinction? I suppose as soon as it develops a moral consciousness it does.
However, if you want contracts that cannot be overridden and are enforced by machines as written (not as intended, as in the legal system), then the bar becomes much higher, then you must get all the details explicitly right the first time and ensure that people don't sign fraudulent contracts, and I'm not sure if this is possible at all.
>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 doing what the authors of the law intended, though not necessarily adhering to the literal wording.
This is a very ancient concept and like all ancient concepts it's bound to be rediscovered every other decade on average.
"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.
"Thank you for subscribing to our contract for your $2 weekly subscription. By the way through a clever loophole obfuscated in our code the amount actually doubles every week. Freedom is Slavery, Ignorance is Strength, Code is Law. Have a good day sir".
In the real world you have a safety net for these types of things, in many case you can break an abusive contract because society has created regulations that ban certain tactics. Ethereum has no such thing. A single mistake or intentional deception and like that, you've lost all your money. The code is law, nothing we can do sir. How is that a feature exactly?
Look at how dumb the average spam is, and yet there's no shortage of people falling for them. Yet it seems like the ethereum crowd genuinely believes that my mother is suddenly going to be able to proof Solidity scripts, something I wouldn't even trust myself to do with decades of programming experience behind me. I don't know if Ethereum is an economic bubble but it definitely is an intellectual one.
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 90's and early 2000's remembers how people were scared to death of online payment security and now it happens every millisecond). Ethereum is just a distributed version of that with no middle man, that is to say it can fail like SSL can when compromised but it doesn't mean we should throw it out the window just because it could sometimes fail. By that logic we should still be cavemen and forget about any technology ever.
> "Thank you for subscribing to our contract for your $2 weekly subscription. By the way through a clever loophole obfuscated in our code the amount actually doubles every week. "
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?
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?
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.
Yes, but "there" is only a small part of the full story. When I make a payment over SSL I don't make an immutable, untraceable and irreversible transaction. In order to be able to receive the payment the other party has to register with a bank and other legal entities etc... Putting money to an ethereum contract is closer to sending cash in an envelope to some PO box in a foreign country. Good luck getting it back if something goes wrong.
>Hopefully after said compassionate human had their lunch break.
Humans make mistakes, humans are unreliable. That's why we have a bunch of checks and balances in any decent justice systems to avoid miscarriages of justice. They're still possible, doesn't mean that the right solution is to get rid of it altogether.
>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.
So code isn't law, law is law? I think my point is perfectly clear, you just keep moving the goalpost. My point is that those "smart" contracts are great for thieves but of dubious values
Regardless, do you think those people whose wallet was compromised because of the faulty contract will manage to get their money back? Who are they suing, the thieves? The wallet company who wrote the faulty contract? How you do get the money back? Can you freeze the account? Reverse the transactions? Blacklist the coins? The whole cryptocurrency system is designed to make those things impractical, if not downright impossible.
Again, great for thieves and black market sellers but if I just want to buy a laptop on amazon why would I ever bother with this? What's the use case?
This shows either little understanding of smart contracts or little imagination. Retailers could make each of their sells contract a 3 party multi-sig contract where the three parties would be you, the retailer and your bank and if you complain to your bank and your bank accepts your request after reviewing the retailer's claim then the money would go back to your account. There could also be other legal entities in the multi-sig contracts such as insurances or others.
> My point is that those "smart" contracts are great for thieves but of dubious values
See my previous point and why this is not correct.
> Regardless, do you think those people whose wallet was compromised because of the faulty contract will manage to get their money back? Who are they suing, the thieves? The wallet company who wrote the faulty contract? How you do get the money back? Can you freeze the account? Reverse the transactions? Blacklist the coins? The whole cryptocurrency system is designed to make those things impractical, if not downright impossible.
They won't get their money back because they didn't pay for an insurance. Coinbase for example guaranties US$ 100k in case of theft. If Ethereum becomes a thing, there would be a whole market of insurances offering what Visa or Coinbase or your local bank offers today.
Last but not least, you're getting robbed every day with fiat money with inflation policies, only you don't see it but it is happening. Inflation lowers the value of your fiat money and that's like robbing you a part of your money without your consent. And you pay a fee for that insurance you mention every time you use your credit card, so not free either and again, any ethereum or bitcoin provider could offer the same insurance for a fee (and coinbase already does to some extend).
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 systems like Idris[1]. That said, I haven't had a proper dig into Solidity myself yet so it could very well offer some of these features. I'd love to hear some experiences from devs who have written a significant amount of code in it.
Except that code is regulated and tested to the degree average eth enthusiast making this point either not aware of, or intentionally omits.
But in the case of Ethereum Smart Contracts, who is liable in the real world?
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'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?)
Granted, the requirement for NASA-level code correctness would make smart contracts expensive to develop and put them out of reach of average developers.
also the intent of the programmer, right?
Money is a social construct that needs societal consent and a framework to manage it that is accountable to the societies rules and regulations. So a random person can't just create money or value out of thin air. There is no value being created here.
They can make a private coin, and convince others to use it between themselves, there were and still exist many such private arrangements in traditional economies, but the value only exists for those who choose to trust this system, and can never hope to replace the main economic currency.
Bitcoin and other coins exists in this space of a private coin based on mutual trust and of no real value to the main economy. Holders of such coins would of course love for it to become a real currency and continue making outlandishly self serving arguments about the economy so they can gain something out of nothing. But that begins to resemble a pyramid scheme powered exclusively by greed and self interest to the exclusion of that society's interests.
I know that current money systems have flaws and are manipulated by the elites. Crypto won't end up being any different in that regard, however. Inflation is a tactic utilized within the current flawed system to move wealth to the top without your bank balance displaying the change. Cryptos will end up having their own flaws to be exploited.
[1] https://eos.io/
(eos.io)
In development now, but a development environment will be up and running by the end of the summer; testnet coming in the fall. Full release next summer.
Does this mean I will be "charged" right in the moment I "store" money in the contract?
Or does it mean I'll be charged when the contract gets "destroyed" and the money "in the contract" is sent to some address?
I'm asking because both sides have problems.
If I don't get charged when storing money in the cotract, I could spend it elsewhere until the contract resolves.
If I get charged when storing money, someone could write contracts that never resolve to purge money.
The short answer is contracts are accounts. Just like your normal ethereum accounts. When you invoke a method marked as payment, you are essentially transferring some ether from your account to the contract. If someone wrote contract from which you can't withdraw and you send ether to it, thats stupidity - even fiat can be destroyed by stupidity.
Stupidity? Doesn't Ethereum want to prevent all money getting locked up somewhere?
[1]: https://ethereumdev.io/managing-multiple-users-a-simple-lott...
Also, is the last byte of the blockhash function return value guaranteed to be equidistributed?
[1]: https://ethereum.stackexchange.com/questions/191/how-can-i-s...
Step 1, install wallet. Step 2, deploy contract. Step 3, learn about Solidity. ... Testing? Nah.
Person A: Cryptocurrency X is insecure isn't it.
Person B: So is { the dollar | driving | flying | the internet | * }.