4 ms·

Afaik, no, proofs of correctness are not currently implemented in the languages that are used. Some of them iirc have a way to do that in part, but currently th

by drdeca 11y ago

Afaik, no, proofs of correctness are not currently implemented in the languages that are used. Some of them iirc have a way to do that in part, but currently the languages aren't set up for full proofs of correctness. (But, iirc, some things can be shown) It is planned though. Ok, yes, I suppose that the contracts will/would eventually get kind of long. As it is now though, It hasn't taken me /all/ that long to read the contracts I've looked at. (But perhaps I've only bothered to look at the ones short enough to read ) Regarding finding security flaws despite people looking carefully: yes, that seems a good point. I think proofs of correctness will be important for important contracts. However, many contracts logic is not really all that complicated. A contract can be powerful without being complicated, I think. Because of this, I think much of the time the proofs should not be too hard to write. Regarding running out of gas: Well, yes, if the transaction you send does not have enough gas, and you needed it to run, that could be a problem. But, if you run the transaction locally, and use that to estimate the amount of gas which needs to be used (might not be exact if the state of the contract changes in a way that your transaction needs more computation, but for reasonable contracts I think this would not be much), and one can provide extra gas in case this happens (the extra gas will be refunded), to have a high confidence that it will be enough. But, if the transaction is important, one would be watching what happened carefully anyway, to make sure the transaction gets in the chain, regardless of the complications from the computations in the transaction. If, counter to your expectations, the gas you provided did not end up being enough, then you would be able to notice this, and, though you would be out that gas cost, you could just send the transaction again with more gas. The block times are very short (under a minute), so you probably wouldn't have to wait long to send the transaction again with more gas. Most of the gas costs shouldn't be too large, so unless the transaction you are sending is very time sensitive, or very computationally expensive, a transaction running out of gas shouldn't be /too/ much of a problem? I think you make some good points btw, just explaining my understanding of how those things are addressed. Also, I'm not sure, but it seems you might have a small confusion about gas. Gas is included in the transaction, not stored by a contract over time. Gas only exists within the context of a particular transaction, the token which is actually exchanged is ether. You might have just been choosing not to mention the details of that though.

nivertech 11y ago
I think @mannykannot misunderstands the purpose of gas in Ethereum. It's only purpose is a solution to the Halting Problem [1]. Alternative solution could be disallowing jumps backwards / loops or limiting time of the computation. Why is it the problem? Because contract with something like while(1){}; will render the entire network of nodes useless. 1. https://en.m.wikipedia.org/wiki/Halting_problem https://en.m.wikipedia.org/wiki/Halting_problem
- mannykannot 11y ago
  I am well aware of the purpose of gas. What I have not seen is any argument (from @drdeca or anyone else) that gas materially simplifies the problem of verifying that a contract behaves properly (from your perspective, as one of the parties to the contract) in all circumstances. The fact that it will always halt is only a tiny step along that road, and if it halts as a result of running out of gas, that is strong evidence that it has not worked as intended. An example may be useful. Suppose I tell you that I have written an Ethereum contract whereby people can loan me money, and after a year, I will pay them back double. Before you enter into one such contract with me, I hope it would cross your mind to wonder if I might actually be running a Ponzi scheme. Don't worry, I say, Ethereum has this gas feature that means the transaction will always halt. How much more confident should that information make you feel? As for your alternatives, gas is essentially the same as limiting the time of computation. If backwards jumps were disallowed, the language would not be even approximately Turing-equivalent.
  - nivertech 11y ago
    1. Gas mechanism has nothing to do with tamper-proofing transactions, thats what blockchain (or more correctly hashchain) is for. 2. There are Turing-complete languages which only allow loops with known number of iterations. 3. Check my presentation, If you want to understand Ethereum programming model: http://www.slideshare.net/mobile/nivertech/ethereum-vm-and-dsls-for-smart-contracts http://www.slideshare.net/mobile/nivertech/ethereum-vm-and-d... IMO Ethereum is just a first step in the right direction, the real solution will need to be much more scalable.

by drdeca 11y ago

nivertech 11y ago

I think @mannykannot misunderstands the purpose of gas in Ethereum. It's only purpose is a solution to the Halting Problem [1]. Alternative solution could be disallowing jumps backwards / loops or limiting time of the computation. Why is it the problem? Because contract with something like while(1){}; will render the entire network of nodes useless. 1. https://en.m.wikipedia.org/wiki/Halting_problem https://en.m.wikipedia.org/wiki/Halting_problem

mannykannot 11y ago
I am well aware of the purpose of gas. What I have not seen is any argument (from @drdeca or anyone else) that gas materially simplifies the problem of verifying that a contract behaves properly (from your perspective, as one of the parties to the contract) in all circumstances. The fact that it will always halt is only a tiny step along that road, and if it halts as a result of running out of gas, that is strong evidence that it has not worked as intended. An example may be useful. Suppose I tell you that I have written an Ethereum contract whereby people can loan me money, and after a year, I will pay them back double. Before you enter into one such contract with me, I hope it would cross your mind to wonder if I might actually be running a Ponzi scheme. Don't worry, I say, Ethereum has this gas feature that means the transaction will always halt. How much more confident should that information make you feel? As for your alternatives, gas is essentially the same as limiting the time of computation. If backwards jumps were disallowed, the language would not be even approximately Turing-equivalent.
- nivertech 11y ago
  1. Gas mechanism has nothing to do with tamper-proofing transactions, thats what blockchain (or more correctly hashchain) is for. 2. There are Turing-complete languages which only allow loops with known number of iterations. 3. Check my presentation, If you want to understand Ethereum programming model: http://www.slideshare.net/mobile/nivertech/ethereum-vm-and-dsls-for-smart-contracts http://www.slideshare.net/mobile/nivertech/ethereum-vm-and-d... IMO Ethereum is just a first step in the right direction, the real solution will need to be much more scalable.