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?
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.
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.
*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.
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.
Some clarifications: Ethereum = the project or the foundation itself Ether = unit of (crypto)currency used in Ethereum
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.
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.
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.
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.
:)
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-...
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.
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.
Solidity code is horrible, especially after looking at concise, maintainable, provably correct code.
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.
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.
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.
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.
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.
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.
As a platform for experimentation that's fine. As a platform for doing real things with meaningful amounts of money, it's madness.
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.
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.
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.
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.....
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.
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?
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.
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?)
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.
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?
Before you write a comment with "why not", apply that to eth first.
But as you said writing your own is also error prone.
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
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.
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...
And then they succeeded at failing.
for(var i=0; i<arr.length; ++i) {
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.).
[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.
[1]: https://ethereumdev.io/managing-multiple-users-a-simple-lott...
[1]: https://ethereum.stackexchange.com/questions/191/how-can-i-s...
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?
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.
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...)
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.
Person A: Cryptocurrency X is insecure isn't it.
Person B: So is { the dollar | driving | flying | the internet | * }.
Step 1, install wallet. Step 2, deploy contract. Step 3, learn about Solidity. ... Testing? Nah.