4 ms·
It seems pretty clear to me that crypto-currencies and blockchain apps, as a technology, are quite unlike anything that have come before it, and fundamentally d
by etaioinshrdlu 9y ago
It seems pretty clear to me that crypto-currencies and blockchain apps, as a technology, are quite unlike anything that have come before it, and fundamentally don't integrate well with the wider world of technology (at least right now).
An obvious issue is that smart contracts cannot make use of information from the outside world (unless of course, fed from a single centralized party). Perhaps this can one day be worked around with some innovations from game theory, but I have not seen it. This demonstrates a lack of integration with the rest of humankind's technology.
A smart contract, once published, cannot be amended. Let that sink in for a while. This breaks the most basic assumption people have about software companies: that they can be agile, move fast, push updates, and fix things.
As far as I can tell, due to the halting problem, one can never actually prove that a sufficiently complex smart contract will not be explosively broken at some point in the future. (The fix for contracts being explosively broken is a hard fork, which only works if you are explosively broken enough to convince a global majority of the network to go along. Your own token probably isn't important enough.)
Immutability provides a lot of interesting benefits of course, but let's not forget how explosively wrong it can go as well.
It all seems like the kind of tech you wouldn't trust to a bunch of fast moving startups, many of which now have actual VC's invested in their outcomes and will put time pressure on them.
It seems most of the HN crowd is well aware of this stuff. But I think it bears repeating, because man, this fishy odor is intense.
- gfodor 9y agoI don't see how the halting problem has anything to do with validating smart contracts. Ethereum burns gas as it runs and there's a gas limit so that is the solution to the problem wrt contracts that don't halt.
- etaioinshrdlu 9y agoThe risk is not that a contract will run forever, but that it may be intractable to exhaustively predict all possible outcomes or prove much of anything about a contract even given the computational time afforded to it.
- gfodor 9y agoSure, that isn't due to the halting problem though. It's certainly trivial to show that any solidity program running on the ethereum VM will halt. What you're saying is that the current ether VM languages don't have much in the way of formal proofs to support understanding their behavior, but that is an area of active work afaik and doesn't fall out from the halting problem.
- readams 9y agoIt actually is related to the halting problem. Rice's theorem is the directly relevant result though. Formal verification of more constrained systems is possible though.
- deleted 9y ago[deleted]
- archgoon 9y agoConsider the following program (in pseudopython, not solidity) function transfer_on_counterexample(int n): # assume n is a counterexample until proven otherwise goldbach_counterexample = true # run through all numbers less than n for prime1 range(n): if is_not_prime(prime1): continue # do it again for another one for prime2 in range(n): if is_not_prime(prime2): continue # check if conjecture is satisfied if prime1 + prime2 == n: # this number does not refute the goldbach conjecture goldbach_counterexample = false return # didn't find p1+p2? goldbach's conjecture is false. # provide a finder's fee if goldbach_counterexample == true: transfer_ethereum() The above program is guaranteed to halt after about O(n^2 * sqrt(n)) (depending on how great the is_not_prime function is). However, it is unknown if there is any input that causes `transfer_ethereum` to be executed. So if I find a counterexample, I can compute how much gas I need to pay to win my finder's fee. So sure, it runs in finite time for a given input, but you have to guarantee it won't ever execute the transfer_ethereum function for all inputs if you want to ensure you never pay out. And that, in general, for a general program (even if guaranteed to halt) is equivalent to the halting problem. Now, I believe that solidity has an upperbound on the size of it's inputs, so the parameter space is bounded, and we return to your original argument that it is a large, but exhaustible, search space.
- wmf 9y agosmart contracts cannot make use of information from the outside world (unless of course, fed from a single centralized party). There has been some work on taking the median of multiple oracles, requiring oracles to post collateral that will be forfeited if they disagree too much with the others, and using attested hardware (SGX) to make oracles more auditable.
- stri8ed 9y agoA smart contract, once published, cannot be amended. Not entirely true. You can have storage variable pointing to an external contract which contains the logic, and this variable can be updating after deployment.
- strangetypes 9y agoCorrect, but it's only the case if one has thought of this scenario in advance and cared to instrument the contract with this indirection via mutable state. That said, this logic will still be fixed once the contract is deployed.