Maybe it's a naive question and maybe it's been answered a million times, but I haven't found it asked/answered explicitly. If it has, please give a link.
Why not use a general purpose VM and let people write code in the language of their choice?
No problem linking to hackernews, exposure is good
Every full node has to run all contracts, and anyone can submit a contract. So it is about 'the number of full nodes' times less efficient. And each time a contract is run the result has to be the same, as should the gas calculations.(and it has to stop and revert when gas runs out) So the surface area is quite enormous, i think an interpreter VM is needed.
So a snapshot at each transaction/block would be space-inefficient? Maybe you could try storing the diff and compressing it otherwise. And i dont see how to make the 'key-value merkle tree' to make SPVs, although you could add a library for 'special storage' that implements this.
A true 'consensus VM' that is actually basically the same as the operating systems we run would be very cool. Of course it would only be able to do things that are deterministic.(the RANDAO idea helps get in random values) That said, having the existing languages compile to EVM bytecode would largely accomplish what you'd want for that?
Read/heard about docker, sounds real interesting. There is another place Ethereum might be able use it; you know Eris, it basically talks to ethereum, and looks for magnet links on it. It also runs a local server which the browser then looks at contracts on Ethereum, and uses that to implement a forum-like thing. Basically, instead of Ethereum being a browser and javascript having bindings to data and transaction, you could run docker images. Both at the same time are possible, infact one of the docker images could be a javascript-bindinged ajax server. If people consciously install docker images security-wise i think that is totally acceptable.
Could even have one docker image per website. But i dont know if that is acceptable security-wise, because then deciding to install those isnt a conscious choice.(but it gives a far smaller attack surface than using docker for every contract)
JasperEindhoven, the NetherlandsMemberPosts: 514✭✭✭
If you mean stuff like virtualbox, remember, Ethereum is for very small amounts of calculation that has to be done with consensus to be useful. General purpose programs are too slow. Also, stuff like virtualbox probably have some bugs.
Otherwise, there are (at least)two reasons.
It has to run identically, exactly. On all full nodes. Otherwise you get a fork. Even in the face of attack, and anyone can put arbitrary EVM code on there.
We need to keep track of how much computation effort it is to run, otherwise attacks would try to. To do this, we keep track of gas, and at the beginning, the user indicates how much it at max costs. If it doesnt reach that, the difference is refunded, otherwise, all gas is still bought and burned. (This ensures that infinite loops and stuff isnt cost-effective at attacking, aswel as regulating the level of activity on Ethereum.)
We need to keep track of an Ethereum state, and it has to be rewindable. We also want to be able to have lightweight client. This puts additional contracts.
So to keep good control on those issues, we basically to do it ourselves. A stack machine isnt that complicated a thing, btw.(infact bitcoin has one too) That said, if you(/anyone) can retarget existing languages to Ethereum, you're welcome
Finally, libraries arent exactly aimed at what we want. Infact Bitcoin was kindah stung by this, with transaction mallabilty. Basically, the openssl does make signatures properly, and it does check properly, however you can fiddle a bit at 'unimportant' bits of data and it will still find the signature correct. However, parts bitcoin assumed you could not fiddle at it.
Suppose we would use Docker containers instead of Ethereum's custom VM. Bear with me as I explore this hypothesis, and tell me where it would break.
1. It has to run identically on all full nodes.
Docker provides images capability. Images are built deterministically with a script. Every full node can start with the same base image, and dapps/contracts would be installed on top of that shared image with a publically available script. Each dapp/contract would run in a separate Docker container.
2. We need to keep track of how much computation effort a contract uses.
Docker provides monitoring and resource limiting tools for RAM, I/O and disk. The same approach of max-gas and upfront gas payments with the reimbursement at the end of transaction, or a transaction rollback if it ran out of gas, could apply. If a Docker container uses too many resources, it can be paused and rolled back to a previous snapshot.
3. We need to keep track of Ethereum state, and it has to be rewindable.
Docker provides copy-on-write instant snapshots. We could do a snapshot after each transaction, and after each block. So we could rollback both individual transactions and block chains that lost proof-of-work race with other nodes.
Jasper, do you mind if I link to this discussion on hackernews? I feel like this could benefit from some discussion from the rest of the Bitcoin community.
What Jasper said, plus, remember the VMs in Ethereum are barebone by design: they need to run fast, be very easily audited, and have no requirements for 'bells and whistles'. That's why we didn't opt for the JVM.
I've heard of plans to potentially standardize through http://llvm.org/, but nothing concrete. Right now I think the VMs are appropriate, even ideal, for the job.
JasperEindhoven, the NetherlandsMemberPosts: 514✭✭✭
Kindah think you're underestimating the problem. *Anyone* can throw in his program and have a go at taking down the entire system if it goes wrong once.
Dont really know how to say more than i already said. (Well, native extensions are sort of a related topic.)
I get it, resource management is a big a problem that applies to CPU, RAM and storage. Capabilities to do such resource management exist, though they may not be refined to the extent the blockchain needs. We will be reaching out to ZeroVM, Docker and other sandboxing projects to better assess the ETA of feature-completeness in this domain.
Answers
Otherwise, there are (at least)two reasons.
- It has to run identically, exactly. On all full nodes. Otherwise you get a fork.
- We need to keep track of how much computation effort it is to run, otherwise attacks would try to. To do this, we keep track of gas, and at the beginning, the user indicates how much it at max costs. If it doesnt reach that, the difference is refunded, otherwise, all gas is still bought and burned. (This ensures that infinite loops and stuff isnt cost-effective at attacking, aswel as regulating the level of activity on Ethereum.)
- We need to keep track of an Ethereum state, and it has to be rewindable. We also want to be able to have lightweight client. This puts additional contracts.
So to keep good control on those issues, we basically to do it ourselves. A stack machine isnt that complicated a thing, btw.(infact bitcoin has one too) That said, if you(/anyone) can retarget existing languages to Ethereum, you're welcomeEven in the face of attack, and anyone can put arbitrary EVM code on there.
Finally, libraries arent exactly aimed at what we want. Infact Bitcoin was kindah stung by this, with transaction mallabilty. Basically, the openssl does make signatures properly, and it does check properly, however you can fiddle a bit at 'unimportant' bits of data and it will still find the signature correct. However, parts bitcoin assumed you could not fiddle at it.
Suppose we would use Docker containers instead of Ethereum's custom VM. Bear with me as I explore this hypothesis, and tell me where it would break.
1. It has to run identically on all full nodes.
Docker provides images capability. Images are built deterministically with a script. Every full node can start with the same base image, and dapps/contracts would be installed on top of that shared image with a publically available script. Each dapp/contract would run in a separate Docker container.
2. We need to keep track of how much computation effort a contract uses.
Docker provides monitoring and resource limiting tools for RAM, I/O and disk. The same approach of max-gas and upfront gas payments with the reimbursement at the end of transaction, or a transaction rollback if it ran out of gas, could apply. If a Docker container uses too many resources, it can be paused and rolled back to a previous snapshot.
3. We need to keep track of Ethereum state, and it has to be rewindable.
Docker provides copy-on-write instant snapshots. We could do a snapshot after each transaction, and after each block. So we could rollback both individual transactions and block chains that lost proof-of-work race with other nodes.
Jasper, do you mind if I link to this discussion on hackernews? I feel like this could benefit from some discussion from the rest of the Bitcoin community.
I've heard of plans to potentially standardize through http://llvm.org/, but nothing concrete. Right now I think the VMs are appropriate, even ideal, for the job.
Let's continue on https://news.ycombinator.com/item?id=8292916
Dont really know how to say more than i already said. (Well, native extensions are sort of a related topic.)
(reposting to https://news.ycombinator.com/item?id=8292916)