Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 17.3K All Categories
- 9.5K Mining
- 573 Pool Discussion
- 374 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 810 Protocol and Client discussion
- 169 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 470 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 225 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 184 Russian
- 230 Spanish
- 47 Turkish
- 125 Watercooler
Why not use a general purpose VM?
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?
Why not use a general purpose VM and let people write code in the language of their choice?
Best Answer
-
Jasper
Eindhoven, the NetherlandsPosts: 514 ✭✭✭
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)
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)