Gavin Wood's personal site, hosting the Ethereum Yellow Paper and his early essays on Web 3.0.
HN links it for the Ethereum Yellow Paper as a technical reference, which commenters cite when discussing gas costs, code execution and the need for cryptographers' review.
> there's a lot of people building things for ethereum.
Are you sure it's ready? There seem to be critical pieces missing in the execution model. Specifically, arbitrary code execution by strangers.
From the white-paper: http://www.gavwood.com/Paper.pdf
"the Ethereum Virtual Machine (EVM) is a quasi-Turing-
complete machine; the quasi qualification comes from the
fact that the computation is intrinsically bounded through
a parameter, gas, which limits the total amount of com-
putation done."
This all sounds very interesting and novel. You buy credits for hosting, this goes further then using Bitcoins to rent bare metal servers. It's integrated in the architecture.
Reading on in that whitepaper. "The machine does not follow the standard von Neumann architecture. Rather than storing program code in generally-accessible memory or storage, it is stored separately in a virtual ROM interactable only through a specialised instruction."
Quite exotic and no re-usage of existing code. What does that mean for IO and networking? Are you allowed to create TPC/IP listen sockets? This is undefined.
Moreover, "For the release series, we use a more complex proof-of-work. This has yet to be formally defined, but involves two components; firstly that it concerns the evaluation of programs on the EVM."
The developers aims for an ASIC-proof proof-of-work system and link it to their arbitrary code execution ability (EVM). However, they are still working on this.
Conclusion, it is an…
>NFTs and crypto currencies are a part of what people think the Web 3.0 will be, but they are definitely not synonyms. The author, however, seem to have did that.
Regardless of the original or intended definitions of "Web3", it will end up being whatever the masses think it is. To recap some history:
- "web3" circa ~2014 when coined by Gavin Wood covered 3 concepts without mentioning NFTs : (1) hash-ids of static content instead of urls (2) p2p encrypted messaging (3) consensus engine. (One of the earlier essays from 2014: https://gavwood.com/web3lt.html)
- "web3" circa ~2021 emphasizing the "token economy" (e.g. NFTs) popularized by Chris Dixon (a16z VC): this is the current news mania with celebrities selling jpgs, etc
Therefore "web3==NFTs" narrative has overtaken the original Gavin Wood narrative.
Analogous situation of evolution of terms was the "internet". In the 1980s, "internet" included Gopher, telnet, USENET, ftp. (E.g. I used to be able to telnet into public computers before all firewalls and Linux configs shut off telnet access.) But Gopher/USENET/etc faded and HTTP became the dominant idea of what "internet" is.
NFTs now have constant press coverage of eye-popping sale amounts from celebrities and OpenSea founders are now paper billionaires. Therefore, NFTs dominate the meaning of "web3" because getting rich is more sexy to talk about than encrypted-p2p-communications-based-on-hash-identities.
Completely agree.
Judging from the technical description [1] and the most recent version of the draft white paper [2] alone, I think the project would benefit greatly from more substantial input and expertise from the academic cryptography community. I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification.
To be more precise: The metered computation mechanism is a very clever solution for dealing with unrestricted computation and unbounded data storage, but their proposed solution does not convincingly address the inevitable increase in space required. Hand-waving about greedy subtree verification without actual numbers/scenarios that shows this could work at all (which would be very surprising to say the least) is not convincing.
In all a great idea, though. It would be great if it works out.
[1] http://gavwood.com/Paper.pdf
[2] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft
> Right, but the gas cost cannot be distributed over _all_ nodes
All computation on the Ethereum blockchain is done through the Ethereum Virtual Machine (EVM). The protocol defines a gas cost for each opcode in the EVM, hence the gas cost is distributed across all nodes.
Any singular node can change the gas cost in their client, but if they pay less than the cost that the miners expect then their transactions will not be processed - as it typical with distributed consensus systems.
> I'll keep looking around for more info, but I do hope Ethereum people realize that YouTube videos are not the same thing as proper documentation
There is a lot of documentation on their Github page. I would recommend starting with the white paper, then check the wiki and if you are still not convinced (and also brave) check the yellow paper:
-https://github.com/ethereum/wiki/wiki/White-Paper
-https://github.com/ethereum/wiki/wiki/Design-Rationale
-https://github.com/ethereum/wiki/wiki/FAQ
-http://gavwood.com/Paper.pdf
I really feel frustrated by your lack of search/manual-crawling/link-clicking/understanding capabilities. He was the official security reviewer of Bitcoin and Ethereum. Then some extra references so you can continue your own search:
- "MPF (Mental Poker Framework): A new family of practical and secure Mental Poker protocols" http://www.dc.uba.ar/inv/tesis/licenciatura/2010/lerner
- MAVEPAY: a new lightweight payment scheme for peer to peer currency networks: https://bitslog.files.wordpress.com/2012/04/mavepay1.pdf
- Strict Memory Hard Hashing Functions: http://www.hashcash.org/papers/memohash.pdf referenced in the Ethereum original paper: http://gavwood.com/paper.pdf
The spec [http://gavwood.com/Paper.pdf] has been to revert on errors since day 1:
> Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. σ).
The Oct 4 commit just optimizes the way that reverts are implemented in go-ethereum (use a journal rather than deep copies).