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?
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!
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
I completely agree that the tools and processes for writing and testing smart contracts need to improve.
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.
* Little to none "get up and running" time. Custom tools don't allow for that.
* Provide such tremendous value that it is worth overcoming the initial setup hurdle.
Right now, Ethereum has neither.
I was merely pointing out that nobody is being stopped from improving the situation, if it was as bad as some portrait it.
If there is > 1,000 Ether in this contract address before timestamp x then send the Ether to the project lead, else refund all the users.
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.
The (non-fintec) example I often hear about often is a voting system. (See: https://github.com/stonecoldpat/anonymousvoting , here zk-snarks algorithm is introduced to ensure privacy)
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 })
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.
[1] https://media.consensys.net/an-introduction-to-lll-for-ether...
A poorly written smart contract that handles real money, on the other hand...
Yes, it's crazy, but it's also happening.
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 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.
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?"
A web app might not touch real money, but a leak can still have real money consequences for the users.
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.
- vulnerabilities can be used to attack users directly or through social engineering
- (rare today, but definitely a problem with C++ web apps) you can break through a hole in the app and pwn the whole server
100% bug free software is impossible! As long as they are written by humans? Their will always be bugs. Matter who is writting them.
Smart contracts by composition would be really nice. Like a compile to EVM lisp!
https://github.com/ethereum/solidity/tree/develop/liblll
https://github.com/ethereum/solidity/issues?utf8=%E2%9C%93&q...
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.
how would you even get started for this kind of job? all of the ads popping up seem to be looking for somebody who already has significant experience