3 ms·

You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You co

You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You could easily build your own gas-focused optimizer for a toolchain like llvm or for a compiler like ocaml's. Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU, or some other metric. Then you wouldn't need to use a specialized bytecode designed for the gas system with its own optimizer. Of course, then people would potentially be tuning for the most common CPUs (or ASICs, or whatever) used by miners. But again, it's not necessary to roll your own solution. Consider also whether gas makes any sense in the long run: Compute power continues to increase, and the cost of compute power continues to drop. If smart contracts are really going to be the foundation of a new economy and people are going to build applications on top of them, does gas make that much sense vs billing for actual compute and network resources like AWS or EC2? Is gas even a meaningful abstraction? I'd argue it isn't. If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction. Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code. Alternate frontends for the EVM potentially address some issues - which is great - but it doesn't get around the fact that EVM itself is poorly designed, and this is reflected in the system all the way from top to bottom. Some of the errata in the post I linked earlier were ways to exploit design flaws in both the VM and compiler to manipulate contracts, and instead of fixing that in the VM they make you put checking prologues in your functions :/

DennisP 9y ago
> Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU No, you can't, because (1) you need consensus on the results, so you can't just have everybody measure CPU cycles on their own machines, and (2) you also can't trust miners to correctly report cycles on their own machines. > cost of compute power continues to drop Which is fine because gas is an abstraction. The price per unit of gas is market based.
- kevingadd 9y ago
  You can absolutely use a consensus model with cycle counting. The cycle count for x86 instructions (ignoring unpredictable factors like cache misses) is well-defined on all the modern architectures, you can find tables of the latencies and everything. There's no reason you couldn't do this instead of gas (though I don't know if I would argue that you should)
  - DennisP 9y ago
    If you are ignoring cache misses, and using a particular CPU architecture instead of whatever is actually running, then you're back to using gas. You still have a fixed list of costs for different operations, it's just a different list. But CPU cycles aren't actually a sufficient cost model, since you also have to pay for storage.
    - kevingadd 9y ago
      The original argument (not yours, to be fair) was that EVM/solidity + an optimizer are necessary because contracts are billed for gas. I was attempting to illustrate that you can build a platform around a more representative billing system (you can pick one!) such that existing, world-class languages can be used instead. This pays security dividends and reduces the cost of your system (for everyone, not just you). Whether or not gas is a useful solution as-is isn't a particularly important question to me, and I don't see any reason why you'd want to replace it now. It's just a poor excuse for Solidity/EVM.
      - DennisP 9y ago
        Sure, but I'm not aware of any language with an optimizer that minimizes permanent storage (for example). The gas model has been forced to be a close representation of actual costs, because last year it wasn't close enough, and someone took advantage of that to launch denial of service attacks. Incidentally, last year someone wrote an Idris backend compiling to EVM for their doctoral thesis. They concluded that it had some benefits but not as much as they expected. [1] There's an effort in progress to migrate from the existing EVM to a modified webassembly [2], which would allow usage of existing languages, and potentially improve performance significantly. It's still experimental and may or may not work out, but seems to be making good progress. [3] With the existing EVM there are new languages in development that may improve matters, including Viper [4] (by Vitalik) and Bamboo [5] (by someone the Ethereum Foundation employs to work on formal proofs). [1] https://publications.lib.chalmers.se/records/fulltext/234939/234939.pdf https://publications.lib.chalmers.se/records/fulltext/234939... [2] https://github.com/ewasm/evm2wasm https://github.com/ewasm/evm2wasm [3] https://blog.ethereum.org/2017/08/23/roundup-5/ https://blog.ethereum.org/2017/08/23/roundup-5/ [4] https://github.com/ethereum/viper https://github.com/ethereum/viper [5] https://github.com/pirapira/bamboo https://github.com/pirapira/bamboo
zodiac 9y ago
> If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction. I think you misunderstand what gas is for. The cost (in terms of transaction fees) to execute something on the EVM is already many many orders of magnitude higher than what it would cost for a single person to run the computation by renting some CPU time from AWS. Think about it in the case of Bitcoin. Simplifying a bit, most Bitcoin transactions just consist of subtracting a number from one account balance and adding it to another account balance. That's an incredibly cheap operation by any metric, yet Bitcoin burns through a million dollars of electricity every day. The reason it costs so much to run code on the EVM is, most of the "cost" goes toward ensuring consensus (or, from the contracting parties' point of view, immutability). Transaction costs and block rewards currently go to miners (in the current PoW world anyway, in PoS this explanation will be slightly different), and miners don't spend most of their CPU cycles running the computation, they spend most of their CPU cycles trying out a hash function (Keccak-256) as directed by ethereum's PoW algorithm (ethhash), and if they're lucky with the values they hash they mine the block. This CPU time only serves to reach consensus, and does not to do any useful work for "just running" the EVM code itself. Another thing that proves that gas does not really correspond to CPU cost directly is that they recently extended it with new primitives (specifically, "elliptic curve multiplication, addition and pairing") as part of a research effort collaborating with zcash (which uses those primtives in their zero-knowledge-proof protocol for allowing private transactions). Of course the EVM could do it before this change (since it's Turing-complete), so if gas = cpu time, why bother adding this primitive? As to what purpose gas serves, the best source is probably http://vitalik.ca/general/2017/09/14/prehistory.html http://vitalik.ca/general/2017/09/14/prehistory.html, but as I understand it it's to prevent DoS attacks and to limit the size of the blockchain (since every contract call ever made, its source code, and hence every EVM instruction executed, is part of the immutable ledger). > Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code. Sure, but it would have to be a core part of the language, it can't be a framework or library. For instance in this contract https://theethereum.wiki/w/index.php/ERC20_Token_Standard#Sample_Fixed_Supply_Token_Contract https://theethereum.wiki/w/index.php/ERC20_Token_Standard#Sa... there's a transfer "function" that addresses call to transfer tokens around. It doesn't run in the context of a "main" function (in the C sense), it just runs and updates some state. So there's some different semantics here (not big differences, just enough that I would call it necessarily a different language). Similarly an event-oriented programming framework for C would probably include a runtime scheduler (probably written in C or assembly), but the EVM and the block-mining framework is the scheduler in EVM's case, it makes no sense to have a runtime scheduler run as "bytecode" or "CPU instructions".

DennisP 9y ago

> Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU No, you can't, because (1) you need consensus on the results, so you can't just have everybody measure CPU cycles on their own machines, and (2) you also can't trust miners to correctly report cycles on their own machines. > cost of compute power continues to drop Which is fine because gas is an abstraction. The price per unit of gas is market based.

kevingadd 9y ago
You can absolutely use a consensus model with cycle counting. The cycle count for x86 instructions (ignoring unpredictable factors like cache misses) is well-defined on all the modern architectures, you can find tables of the latencies and everything. There's no reason you couldn't do this instead of gas (though I don't know if I would argue that you should)
- DennisP 9y ago
  If you are ignoring cache misses, and using a particular CPU architecture instead of whatever is actually running, then you're back to using gas. You still have a fixed list of costs for different operations, it's just a different list. But CPU cycles aren't actually a sufficient cost model, since you also have to pay for storage.
  - kevingadd 9y ago
    The original argument (not yours, to be fair) was that EVM/solidity + an optimizer are necessary because contracts are billed for gas. I was attempting to illustrate that you can build a platform around a more representative billing system (you can pick one!) such that existing, world-class languages can be used instead. This pays security dividends and reduces the cost of your system (for everyone, not just you). Whether or not gas is a useful solution as-is isn't a particularly important question to me, and I don't see any reason why you'd want to replace it now. It's just a poor excuse for Solidity/EVM.
    - DennisP 9y ago
      Sure, but I'm not aware of any language with an optimizer that minimizes permanent storage (for example). The gas model has been forced to be a close representation of actual costs, because last year it wasn't close enough, and someone took advantage of that to launch denial of service attacks. Incidentally, last year someone wrote an Idris backend compiling to EVM for their doctoral thesis. They concluded that it had some benefits but not as much as they expected. [1] There's an effort in progress to migrate from the existing EVM to a modified webassembly [2], which would allow usage of existing languages, and potentially improve performance significantly. It's still experimental and may or may not work out, but seems to be making good progress. [3] With the existing EVM there are new languages in development that may improve matters, including Viper [4] (by Vitalik) and Bamboo [5] (by someone the Ethereum Foundation employs to work on formal proofs). [1] https://publications.lib.chalmers.se/records/fulltext/234939/234939.pdf https://publications.lib.chalmers.se/records/fulltext/234939... [2] https://github.com/ewasm/evm2wasm https://github.com/ewasm/evm2wasm [3] https://blog.ethereum.org/2017/08/23/roundup-5/ https://blog.ethereum.org/2017/08/23/roundup-5/ [4] https://github.com/ethereum/viper https://github.com/ethereum/viper [5] https://github.com/pirapira/bamboo https://github.com/pirapira/bamboo

zodiac 9y ago

> If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction. I think you misunderstand what gas is for. The cost (in terms of transaction fees) to execute something on the EVM is already many many orders of magnitude higher than what it would cost for a single person to run the computation by renting some CPU time from AWS. Think about it in the case of Bitcoin. Simplifying a bit, most Bitcoin transactions just consist of subtracting a number from one account balance and adding it to another account balance. That's an incredibly cheap operation by any metric, yet Bitcoin burns through a million dollars of electricity every day. The reason it costs so much to run code on the EVM is, most of the "cost" goes toward ensuring consensus (or, from the contracting parties' point of view, immutability). Transaction costs and block rewards currently go to miners (in the current PoW world anyway, in PoS this explanation will be slightly different), and miners don't spend most of their CPU cycles running the computation, they spend most of their CPU cycles trying out a hash function (Keccak-256) as directed by ethereum's PoW algorithm (ethhash), and if they're lucky with the values they hash they mine the block. This CPU time only serves to reach consensus, and does not to do any useful work for "just running" the EVM code itself. Another thing that proves that gas does not really correspond to CPU cost directly is that they recently extended it with new primitives (specifically, "elliptic curve multiplication, addition and pairing") as part of a research effort collaborating with zcash (which uses those primtives in their zero-knowledge-proof protocol for allowing private transactions). Of course the EVM could do it before this change (since it's Turing-complete), so if gas = cpu time, why bother adding this primitive? As to what purpose gas serves, the best source is probably http://vitalik.ca/general/2017/09/14/prehistory.html http://vitalik.ca/general/2017/09/14/prehistory.html, but as I understand it it's to prevent DoS attacks and to limit the size of the blockchain (since every contract call ever made, its source code, and hence every EVM instruction executed, is part of the immutable ledger). > Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code. Sure, but it would have to be a core part of the language, it can't be a framework or library. For instance in this contract https://theethereum.wiki/w/index.php/ERC20_Token_Standard#Sample_Fixed_Supply_Token_Contract https://theethereum.wiki/w/index.php/ERC20_Token_Standard#Sa... there's a transfer "function" that addresses call to transfer tokens around. It doesn't run in the context of a "main" function (in the C sense), it just runs and updates some state. So there's some different semantics here (not big differences, just enough that I would call it necessarily a different language). Similarly an event-oriented programming framework for C would probably include a runtime scheduler (probably written in C or assembly), but the EVM and the block-mining framework is the scheduler in EVM's case, it makes no sense to have a runtime scheduler run as "bytecode" or "CPU instructions".