Honestly, I can’t help but to feel very bearish on ETH. I really like the idea, but I think the implementation is poor, and the community is poorly aligned in values to making it a success.
The most important construct in ETH that sets it apart from other currencies is the Smart Contract. I don’t believe though that these are either smart, nor contracts. Whether or not you agree with the resolution of the DAO hack or not, the fact that we consider it a hack to be in some way resolved indicates we do see smart contracts as programs that can and should be changeable to better meet the intent.
Based on the DAO and a number of other issues with smart contracts, I don’t think they are smart based on the design of the language being so poorly adapted for the kind of verification needed to make robust contracts. It isn’t smart.
Based on the communities willingness to fork over contract actions they don’t agree with means they aren’t contracts. In real life, if you’re duped by a creative but legal (as judged by the legal process, or in this case the execution on the blockchain) interpretation, you need to suck it up and move on. In Ethereum, you can fork, and in practice the group that lead to the fork of ETH were a minority. Smart contracts aren’t contracts because by the decision of a few they can be rewritten without the agreement of all involved parties.
Ultimately, if I were looking to do non-hobbyist business, either as the business or a customer, for these reasons I wouldn’t feel comfortable using Ethereum.
I am not a lawyer, but I did grow up with one, and I’m pretty sure a legal but clever and tricky contract has legal grounds to be thrown out in court.
As a kid I was curious if the “tiny fine print that you couldn’t read” could really be used to trick someone. It can’t. The legal system is very aware of the distinction, it’s called acting in good faith.
Again, not a lawyer, not legal advice, don’t make choices based on what I’ve said, but it’s not as cut and dry as you claim it is.
And contracts with “bugs” in them (i.e., that don’t accurately represent the intent of the parties) aren’t taken literally either. There are rules/principles about how to interpret them that are much more nuanced than that. Only a programmer who doesn’t get out much would think that a better approach is to eliminate the potential for ambiguity and then always interpret contracts literally.
I generally understand your point and agree with it, but what I’m suggesting is that the execution of a smart contract is the legal process in this context.
It’s not that it’s right or wrong that the contract was interpreted/executed in a given way, it’s that after the field has been set and the dice cast, then going back in time and writing out the execution because some definition of majority (usually a minority in practice) didn’t win is the issue.
Changing how the outcome played out after the fact that it was interpreted and executed feels (in the context of a smart contract being interpreted by the legal process of the block chain) like an extrajudicial action by people who lost out.
The legal system has been dealing with smartasses since before your ancestors were deloused.
Think of it like the efficient market hypothesis: People have been banging on legal systems for so long that you can reasonably assume that all of the interesting stuff has been found, and is either a known technique or is already illegal. There might be exceptions to this, but the fact the system is administered by humans who exercise human judgement closes a lot of novel loopholes, as well.
I’d go one step further and assert that, in legal systems that have been functioning for centuries and are thoroughly debugged, some obvious glaring flaws will continue to exist, but they are those that are actively maintained by some group which has an extraordinary amount of power and stands to gain an extraordinary amount of wealth from them.
I used to think this way, until I realized that all these high-profile bugs in applications on Ethereum have very little to do with the code in Ethereum.
The DAO is a good example. It was not written by the core Ethereum project. It was a distributed application written by unrelated developers, and crowdfunded by a token sale. Blaming the Ethereum project for DAO’s code quality is like blaming the Unix developers for a segfault in some third-party app.
You don’t have to blame the core developers for the DAO contract code’s bugs to blame them for forking the block chain to “fix” the bugs for THE DAO developers.
Those are two separate acts from two separate groups of people.
I agree with you but think the conclusion you draw is incorrect. While Solidity itself is not a bug, the language itself is part of the design of Ethereum, and by using a language (Solidity) that is so poorly adapted to verification, it’s made it easier for users to write buggy contracts.
C isn’t buggy. Solidity isn’t buggy. Their use in the systems mentioned have lead to more bugs, and an environment more user- and developer-hostile than had they instead been replaced with other languages.
I agree that Solidity won’t kill Ethereum, but a credible competitor will. I think it is almost a certainty that the biggest shining star of a more mature smart contract blockchain system will be better verifiability in the language. It might not be the immediate killer of Ethereum, it might not even be the technology that kills the Ethereum killer, but I really do think that a verifiable in practice language will be a requisite feature for a smart contract technology that isn’t as known for being a massive footgun as Ethereum is.
While C itself is not a bug, the language itself is part of the design of Unix, and by using a language (C) that is so poorly adapted to verification, it’s made it easier for users to write buggy programs.
Buggy programs didn’t kill Unix, so I doubt Ethereum is in danger.
Honestly, I can’t help but to feel very bearish on ETH. I really like the idea, but I think the implementation is poor, and the community is poorly aligned in values to making it a success.
The most important construct in ETH that sets it apart from other currencies is the Smart Contract. I don’t believe though that these are either smart, nor contracts. Whether or not you agree with the resolution of the DAO hack or not, the fact that we consider it a hack to be in some way resolved indicates we do see smart contracts as programs that can and should be changeable to better meet the intent.
Based on the DAO and a number of other issues with smart contracts, I don’t think they are smart based on the design of the language being so poorly adapted for the kind of verification needed to make robust contracts. It isn’t smart.
Based on the communities willingness to fork over contract actions they don’t agree with means they aren’t contracts. In real life, if you’re duped by a creative but legal (as judged by the legal process, or in this case the execution on the blockchain) interpretation, you need to suck it up and move on. In Ethereum, you can fork, and in practice the group that lead to the fork of ETH were a minority. Smart contracts aren’t contracts because by the decision of a few they can be rewritten without the agreement of all involved parties.
Ultimately, if I were looking to do non-hobbyist business, either as the business or a customer, for these reasons I wouldn’t feel comfortable using Ethereum.
I am not a lawyer, but I did grow up with one, and I’m pretty sure a legal but clever and tricky contract has legal grounds to be thrown out in court.
As a kid I was curious if the “tiny fine print that you couldn’t read” could really be used to trick someone. It can’t. The legal system is very aware of the distinction, it’s called acting in good faith.
Again, not a lawyer, not legal advice, don’t make choices based on what I’ve said, but it’s not as cut and dry as you claim it is.
And contracts with “bugs” in them (i.e., that don’t accurately represent the intent of the parties) aren’t taken literally either. There are rules/principles about how to interpret them that are much more nuanced than that. Only a programmer who doesn’t get out much would think that a better approach is to eliminate the potential for ambiguity and then always interpret contracts literally.
I generally understand your point and agree with it, but what I’m suggesting is that the execution of a smart contract is the legal process in this context.
It’s not that it’s right or wrong that the contract was interpreted/executed in a given way, it’s that after the field has been set and the dice cast, then going back in time and writing out the execution because some definition of majority (usually a minority in practice) didn’t win is the issue.
Changing how the outcome played out after the fact that it was interpreted and executed feels (in the context of a smart contract being interpreted by the legal process of the block chain) like an extrajudicial action by people who lost out.
The legal system has been dealing with smartasses since before your ancestors were deloused.
Think of it like the efficient market hypothesis: People have been banging on legal systems for so long that you can reasonably assume that all of the interesting stuff has been found, and is either a known technique or is already illegal. There might be exceptions to this, but the fact the system is administered by humans who exercise human judgement closes a lot of novel loopholes, as well.
I’d go one step further and assert that, in legal systems that have been functioning for centuries and are thoroughly debugged, some obvious glaring flaws will continue to exist, but they are those that are actively maintained by some group which has an extraordinary amount of power and stands to gain an extraordinary amount of wealth from them.
I used to think this way, until I realized that all these high-profile bugs in applications on Ethereum have very little to do with the code in Ethereum.
The DAO is a good example. It was not written by the core Ethereum project. It was a distributed application written by unrelated developers, and crowdfunded by a token sale. Blaming the Ethereum project for DAO’s code quality is like blaming the Unix developers for a segfault in some third-party app.
You don’t have to blame the core developers for the DAO contract code’s bugs to blame them for forking the block chain to “fix” the bugs for THE DAO developers.
Those are two separate acts from two separate groups of people.
On the other hand, one of the Ethereum founders was responsible for the Parity bug.
I agree with you but think the conclusion you draw is incorrect. While Solidity itself is not a bug, the language itself is part of the design of Ethereum, and by using a language (Solidity) that is so poorly adapted to verification, it’s made it easier for users to write buggy contracts.
C is buggy, but that didn’t kill Unix.
Unless a credible competitor appears, I think Ethereum will continue to dominate the smart contracts space.
C isn’t buggy. Solidity isn’t buggy. Their use in the systems mentioned have lead to more bugs, and an environment more user- and developer-hostile than had they instead been replaced with other languages.
I agree that Solidity won’t kill Ethereum, but a credible competitor will. I think it is almost a certainty that the biggest shining star of a more mature smart contract blockchain system will be better verifiability in the language. It might not be the immediate killer of Ethereum, it might not even be the technology that kills the Ethereum killer, but I really do think that a verifiable in practice language will be a requisite feature for a smart contract technology that isn’t as known for being a massive footgun as Ethereum is.
Wait, since when is C buggy?
I should have been more precise.
Buggy programs didn’t kill Unix, so I doubt Ethereum is in danger.