7 ms·
No, the output is guaranteed to be correct. Correct, as in what you specified in the contract, which may not be what you had intended, but that’s besides the po
by halpmeh 4y ago
No, the output is guaranteed to be correct. Correct, as in what you specified in the contract, which may not be what you had intended, but that’s besides the point. Can you explain how the output would differ from the contract specification?
- NovemberWhiskey 4y ago"The code does what it does" is not a useful statement; insisting that a smart contract is an executable specification is not helpful unless there's a really very small semantic step from how the user intentions are formed - which again is not the case here.
- halpmeh 4y agoI think you’re moving the goal post. As I mentioned in my original post, smart contracts allow for the creation of a global computing platform we call a blockchain. Maybe you want formal verification, but not everyone cares about that.
- NovemberWhiskey 4y agoWhat? You're the one with the "output is guaranteed to be correct" line. A smart contract is just code.
- halpmeh 4y agoYes, the output is guaranteed to be correct. Let’s say you give me a program and ask me to run it for you. Can you guarantee that I won’t tamper with the executable? No you can’t. You can’t trust the output of an arbitrary program you give me to run. The only way you could trust my result would be to run the program yourself and verify I provided you the correct output. If you run the program yourself, then what’s the point of paying me to run your code? With a smart contract, you can trust the output. That’s the difference. This brings me back to my main point. You clearly have not implemented a smart contact and have misconceptions about what it does. I suggest you implement one first. You can still think the idea is stupid afterwards. That’s fine. But right now, it seems like you are arguing about how you think the blockchain works, which doesn’t necessarily match how it actually works.
- oblio 4y agoAre smart contracts Turing complete?
- halpmeh 4y agoYes
- oblio 4y agoThen almost by definition I can't really trust your smart contract, except for airtight formal verification, which nobody really does plus I highly doubt smart contract programming languages are formal verification languages. So this: > Yes, the output is guaranteed to be correct. is provably wrong and you either know it and are malicious or you don't know it and this discussion is useless.
- halpmeh 4y agoI think we're talking about two different things. Imagine you have a generic program A that you've formally verified. Now you ask me to execute it for you. I say: "ok, the output of the program is X." Can you trust the output? No, you cannot trust the output even though you've formally verified the program. If you formally verify the smart contract, you can trust the output.
- NovemberWhiskey 4y agoIf your point is that the EVM byte-code that's deployed to the blockchain is immutable and that transactions which don't agree with the results of executing code will be rejected, yes, that is a true statement. I think what everyone is quibbling with is the assertion that this is the same as "correctness", which is (by and large) considered a different property that relates user expectations to actual runtime behavior.
- halpmeh 4y agoSorry but that’s a total straw man. Yes, if you redefine the words I used then you can make any argument you want. In CS, correctness means with “behaves in a consistent manner with respect to a specification”. The smart contract is the specification, so yes the output of the smart contract is guaranteed to be correct with respect to the specification. Of course, there can always be be errors in the specification. If you have another definition of “correct”, let me know.
- habinero 4y agoContracts are agreements between humans. Therefore, the only "correct" outcome is the intended outcome. If your code has bugs or errors or security vulnerabilities, those will all lead to incorrect behavior. That's why smart contracts aren't useful.
- TimJRobinson 4y agoMay as well say "that's why software isn't useful" which obviously isn't true. Most contracts end in the happy case 99% of the time, it seems very worthwhile to automate that happy case and fall back to the traditional legal system in the failure case where either party isn't happy with the outcome.
- habinero 4y agoContracts aren't for when things go right, they're for when things go wrong. It's just as true to say contacts aren't "necessary" 99% of the time, because people follow through on the agreement.
- halpmeh 4y agoI think you’re conflating legal contracts and smart contracts. Legal contracts are instruments used by two or more parties that outlines their responsibilities to one another in a way that is protected by civil law. A smart contract is just a program that runs on the blockchain.
- pooper 4y agoDo you see how the name "smart contract" makes no sense? They aren't smart. In fact, they are obviously dumb. They do what the code says. They aren't a contract in the legal sense. Smart contracts are neither smart, nor contracts.
- halpmeh 4y agoSo we’ve gone from debating the technical merits to debating the name? The name likely comes from options contracts, which are technically contracts but traded like equities. Most options are very simple tuple: (equity, strike price, call / put). The smart in smart contract can mean writing a smarter option contract.