Normally, if you deal with money, then you try to be extremely careful, right? You have to care much about security, verify that your app is not vulnerable, make an audit etc.
And I think that even beginners know that you can't trust users' input - you have to sanitize it. And under no circumstances you want to execute it!
But here it is the opposite, isn't it? You basically give users ability to run any code within your application (blockchain). And you give them very insecure, confusing and badly designed language.
To me it is an epitome of insecurity. It is like giving a shotgun to a child!
Users cannot run 'any code'. They can run contract code, which can only interact with the underlying application through a protocol. The multisig hack was not a case of the underlying application being compromised. The contract itself was compromised due to a vulnerability in its code. The only parties affected were those that trusted the contract. The rest of the contracts operating on the application were unaffected.
the problem is that the tools don't facilitate writing correct contracts
i don't know how to do this myself, mind your. to be broadly applicable the tech has to be accessible to people who would be writing contracts. a fucking professional using the state of the art for this shit has very little tooling support for checking that the contract actually operates in a particular fashion.
something like an SQL query planner that helps you write contracts
The EVM, which is what executes contracts, has a public spec. It's a bytecode machine and writing a compiler for it should be rather trivial compared to x86.
There are also several other languages you can code in and there are some code verifier tools that allow you to check if your contract is good.
The problem is that despite these tools existing, even if they are used, they are underused.
To be fair, traditional "dumb" contracts written by lawyers also have exploits and loopholes. That's why we have courts with judges and juries that can make subjective decisions based on context outside of the contract. Smart contracts don't allow for that subjective judgment, and thus won't work in a subjective society.
This 100%. I think this becomes evident almost as soon as one tries to do any smart contract coding. It's an entirely different paradigm with considerations that dwarf anything about language syntax and style. In fact I think these considerations are very non-trivial to grasp.
Because it's conceptually more like a contract. Someone writes the contract code, and then by uploading and depositing money into the contract it's as if they signed it. After that point it works without anyone needing to trust the signer.
And they can include conditions about arbitrary information that is reported on the blockchain (weather data, stock prices, etc...)
And multiple people can sign these things. They really are like contracts.
Their main use case is maintaining critical/sensitive state information that you want to protect via rules of interaction between multiple parties (that don't trust each other) without the need for a trusted intermediary. The contract is tamper proof and only via correctly and cryptographically signing messages/transactions intended for the smart contract will the state of the smart contract change, but only according to the rules defined in the smart contract.
Essentially anything that requires co-ordination between parties that don't trust each other over a piece of data (a balance of money, the tally of a ballot) is a perfect use case for smart contracts. But since there is cost to running it on these secure networks it is important that they remain O(1) or at most O(n) time complexity, which for these kinds of applications is often totally enough. (eg. if (the message is signed by the 'owner') { send the funds } else { throw })
Another interesting use case is for supply chain management, since the history of a interactions relating product can be documented in a secure manner Eg. you can buy a nike shoe that you can cryptographically validate that it was signed off by Nike, who made it, when they made it, when it was shipped, and even how much each of these parties got paid for their service. (Take a listen here: https://media.consensys.net/state-change-44-shining-a-light-...)
I view this more as "web apps should not be written in C++ due to security issues that we have long come to understand" than "web apps should be written in C++ due to performance issues we are guessing at"... like, do you believe that in a few years people will decide "no, strongly typed and proof assisted languages were overkill for contracts: it was actually better to code them in a language that has weirdly fluid rules and type semantics for reasons they did not quite grok in 2017"?
I know, and I am very excited for those languages to exist and be usable, and thereby have been tracking a couple such efforts; until then, this is about as useful as pointing out that website development is theoretically possible using a computer. The person did not state that it would always be the case that smart contracts are hard: only that right now, on Ethereum, they are hard, and the comment even used "gotten to the point where" (indicating this is a temporary state) and specifically blamed the "tools", which is all absolutely true and is born out not just in theory but in practice; it doesn't even disagree with your own statements that other different tools would be better. Why are you so defensive about this commentary?
Actually, I didn't mean to come across as defensive. I just like to nerd out about tech.
Once you accept the inherent craziness of the proposal, and go "Ok, this is crazy. What now?" you end up concluding that the future is going to be very interesting. It'd be worth investing some amount (that you can afford to lose!) in ETH on the off-chance that it doesn't suffer a major disaster. There are quite a few interesting applications for this technology, and historically that's been a pretty solid bet.
The main thing to keep in mind at this point in time is that these contracts have very little tolerance for inefficiency, since inefficiency in this case costs money. Even solidity is very inefficient. Sure it would be great to write contracts in Haskell or Coq but can you insure O(1) or at most O(n) run time with little to no constant overhead? For example LLL (Low-Level Lisp-Like Language) produces 70% more efficient code than solidity [1] and thus it is the chosen language for the ENS (Ethereum Name Service) registry smart contract (who wouldn't want to pay 70 less for interacting with a contract?). But no doubt, better languages will come with time :)
The EVM is Turing-complete, so this will be a risk with any language that compiles into a smart contract.
Solidity doesn't appeal to me because its goal seems to be on-boarding JavaScript programmers. But new languages that compile to EVM can be easier to use "safely" and you will see several of these in the next few years.
I'm really excited that a project to embed Turing-complete behavior in a blockchain has actually taken off. It's completely insane from one perspective, but completely awesome from another.
The EVM might be Turing complete but you can still have languages that compile down to only some tractable sub-set of the possible EVM programs.
The interesting question is whether a language can be design which allows the important domain-relevant requirements to written down in an understandable way and also proved rigorously.
So far neither lawyers nor programmers have done a very good job of this in their respective field. Watching people trying to do it in both fields simultaneously sounds like popcorn time to me.
Huh? Lawyers have done an exceptional job. There are huge swaths of activity around which there is consensus about legal dogma.
And huge swaths of activity where programmers have laid out clear deterministic expectations.
If you're saying lawyers have failed to specify the legal ramifications of All Possible Activity then... Sure. So? Even if Ethereum only works for one single narrowly defined contract, it could be immensely useful.
The question for me isn't "where could it fall short" but "where might it measure up?"
The EVM might be turing-complete but since you can only get finite number of execution cycles, you can usually determine the behaviour of your program or if it halts within the current gas limits.
Sure, but in theory I can change passwords and maintain separate credentials for my banking-related needs.
Short of auditing the Solidity contract code myself, there's nothing I can do to protect myself from the hacks themselves because the very mechanism by which money is transferred is riddled with bugs.
This is mostly just semantics anyway - I'm just trying to establish that writing money-transfer software in a poorly designed language is, one way or another, worse than writing a web app in one.
It doesn't need to be bug free if there are checks and balances. Like an independent contract layer that holds funds in escrow for 10 days and allow a third party to cancel fraudulent transaction under certain conditions.
You don't need to prevent all bad behaviors, just slow attackers down.
Of course sometimes they can get through the review process too, but you start having probabilities you can multiply to decrease the likelihood of losses.
Over time we'll start to have good defaults for how those checks work. For now it's the wild west.
This might be possible at some point, but for that we first need to figure out how to formalize intent and meaning. In real-world laws, both are extremely important.
a "smart contract" is a script that runs on a blockchain to execute terms and manage funds.
the problem is that the tools that you use to make these are basically garbage. you don't write fin-tech in what amounts to javascript y'know?