Ethereum White Paper

https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-White-Paper

94 31 12 years ago

mquandalle2• 12 years ago

This version contains some mistakes and approximations. For a more up-to-date paper you should take a look at the White paper v2 draft [1].

A more formal and technical description is presented in the Yellow paper (also draft) [2].

[1] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft

[2] http://gavwood.com/Paper.pdf

terhechte3• 12 years ago

The explanation of all the opcodes for the contact script does not list any IO operations for external (non-storage) data (at least none that I could see). However, in the list of Ethereum examples, the following is given:

"Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well."

Does somebody know how the contract would be able to read a data feed? I did not find anything in the language spec. Such a feature would be really interesting. On the one hand it would allow for a ton of interesting options (binding contracts to stock markets, emails, political events) on the other hand how would a contract behave if the required data url is gone (i.e. the weather data feed changed from weather.php?v1 to /v1/weather). Whats more, wouldn't there be strong incentives for man in the middle attacks to deliver wrong data? This sounds like a very powerful yet dangerous feature, so I'd love to learn more about the spec and reasoning behind this.

bertil• 12 years ago

binding contracts to stock markets, emails, political events) on the other hand how would a contract behave if the required data url is gone (i.e. the weather data feed changed from weather.php?v1 to /v1/weather

Butekin’s answer to that appears to be that providing the information at the right format should also be an Ethereum contract: users (both participants of your option) would enter another secondary contract with a weather service and pay a small sum is the information is properly available.

wouldn't there be strong incentives for man in the middle attacks to deliver wrong data?

Yes, but I’m guessing not more than now… Ethereum offers to automate and lower the cost of such contracts, i.e. replace back-ends. You can imagine testing services remain active on both sides, checking from a distinct source that payments match; that is already what is in place, it’s just a fairly boring activity at the moment.

terhechte3• 12 years ago

Thanks! So by that you mean the weather service would be a contract / company that would encode the current weather into the blockchain with a transaction? So effectively a server-sided solution that would use the blockchain as the data endpoint so that other contracts can access the data?

mquandalle2• 12 years ago

There will be no IO function like `http_get_content` because we can't securely rely on them. Instead the method will be to rely on a trusted entity (or a group of trusted entities) to sign an ethereum transaction containing some data that will be used by the contract. For instance you could take a look at Reality Keys, a "trusted data feeds" platform [1].

If you want to reduce the need to trust a single party you can also use a SchellingCoin system, described as a "decentralized data feed" in the ethereum white paper v2 [2].

[1] http://forum.ethereum.org/discussion/comment/180/#Comment_18...

[2] http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...

terhechte3• 12 years ago

Thanks, that totally makes sense.

nullc4• 12 years ago

You cannot do external IO in a consensus system.

(This is one reason why I think a lot of fancy contracts are best done using a quorum of external oracles, since you have no better security than that in anything that does external IO, and it's much more scalable (and works great in Bitcoin already))

jaibot• 12 years ago

"Quorum contracts" could also be a thing - contracts that exist solely to aggregate data from multiple sources, so you don't have to request data from each source every time you want to check something.

jamespitts• 12 years ago

For cases like this, a trusted, external system would post data into the contract.

bachback4• 12 years ago

anyone who thinks GHOST is a good idea, has not understood Bitcoin at all. the whole point of the blocks is that nodes can work on the global state in a chain. so the idea that nodes should work on greedy subtrees is about the worst possible idea. Bitcoin solves not only the Byzantine generals problem, but a latency variance problem, to achieve logical broadcast. anyway, the author of this paper also believes that "anyone with reasonably high intelligence could have invented Bitcoin by random luck" [1]. well, no. there are many hidden problems which Bitcoin solves. the literature on quorum systems, distributed applications, etc. is very deep.

[1] http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_an...

oleganza• 12 years ago

Could you pls expand on this: "Bitcoin solves also a latency variance problem, to achieve logical broadcast"?

bachback4• 12 years ago

how does one node know what other nodes are doing if latency between the messages could be anything between 50ms and 5000ms? if one node has a good position in the network it would know more than other nodes and outpace the network. which is exactly what would happen with ghost. the ghost authors have bound estimations on latencies, overlooking the possibility of information arbitarge. somebody would figure out where the most information comes from and arbitrage the network. so besides hashing attacks there are "latency attacks", but they don't even appear in Bitcoin, because blocks solve that issue. latency is negligible vs. the 10-minute block time. this could be shown with a timing attack on an alt-coin with < 60 sec blocktime.

Lamport's work make this connection obvious. He invented the Byzantine Generals Problem and wrote this paper: "Time, Clocks, and the Ordering of Events in a Distributed System", Communications of the ACM 21, July 1978 http://research.microsoft.com/en-us/um/people/lamport/pubs/t...

logical broadcast means: every node has the same state (time invariance). the only thing that matters is hashing power.

gone35• 12 years ago

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

vbuterin5• 12 years ago

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.

Umm... that's exactly one of the issues that we're cargo-culting about the most. There are two general categories of solutions to this problem: technical increments (ie. a better constant factor), and fundamental cryptographic upgrades (eg. the stacktrace challenge-response concept we have been talking about on our blog). The first category we are not yet doing because we are following the well established advice of "don't prematurely optimize". The second category, well, that's why we're thinking of ideas like distributed blockchain storage, clever algorithms to force more people to be full nodes, and challenge-response protocols. There is also another idea I was thinking of, which I'll have a post up over the next week or two.

In the long term, we are already beginning the development of a very widespread collaboration with academic groups to try to tackle the problems in cryptocurrency, and at this point we fully expect we'll end up releasing Ethereum 2 at some point in 2016 which would take a lot of new cryptography into account.

bachback4• 12 years ago

I believe a solution would look more like what Hal Finney called transparent servers [1]. This would be a way to solve the issue of scaling (and getting rid of mining oligarchs), but also dealing with the necessary privacy issues of contracts. Also DNS is not really a contract between 2 parties, but N parties, and there is a relationship between DNS and contracts (more on that per PM by request).

[1] http://www.finney.org/~hal/rpow/security.html

vbuterin5• 12 years ago

Bitcoin "solves" the problems behind Byzantine fault tolerance, quorum systems, etc by completely ignoring the past 30 years of research on the topic, and introducing a very simple construction that bypasses all of the issues entirely by using the concept of proof of work. Don't get me wrong, Bitcoin is a brilliant idea, but it's the sort of brilliant idea which is actually more likely to come to you if you were NOT bogged down by existing research on how to do things. Satoshi's primary gift was not deep knowledge, it was a fresh perspective.

And I am not saying these things because Ethereum is a super-magic-brilliant protocol that involves deep knowledge about thirty years of development in multiple fields; it's not. It's also an ultimately fairly elementary idea that I still remain surprised that nobody tried to seriously push before me. In fact, at least two other groups got very close in 2012-2013, and a few weeks ago at the payments innovation conference in Boston I learned that apparently the concept sans blockchain was around in the 1990s; but for some reason they did not take the idea to its logical conclusion.

Also, our implementation of GHOST does not in any way compromise the concept of global state; blocks are required to specifically include uncle headers in order to benefit from them.

bachback4• 12 years ago

I would suggest to run a simulation where nodes are globally distributed and have various latencies with high variance, and then study this problem of non-uniform distribution of information. with GHOST nodes would cluster in physical locations (say Iceland). the latency between those heavy nodes would be very low, and the latency to say Australia very high. the heavy nodes could then co-opt the network. it does not help if the authors proves a bound of latency, because this imbalance would destroy the network. with geographically skewed distribution of information, one can imagine all kinds of weirds effects and attacks. perhaps I'm wrong and will find out this actually works, but even then robustness requires safety over the longterm in very unexpected cases.

higherpurpose• 12 years ago

I hope they focus more on their Go client than the C++ one. Something like this needs to be as secure as it can get. No reason to have it vulnerable to memory leaks and such, if they don't have to.

ixmatus• 12 years ago

If that's your reason for trusting an implementation in Go over C++ then I would say they should level up and use Haskell. Or even better, Agda. There's also ATS but I think the community around Haskell and Agda is more populous.

A garbage collected language is an improvement over possible memory leaks due to human responsible memory allocation, but I think a larger problem is most programmer's (very human) inability to separate pure from impure code. Languages with very strong type guarantees do it for you and give you the tools to protect yourself from a lot of problems that are common in any language from Assembly all the way through to Go (I think Rust is actually well suited as well since it has a better type system than Go, but I haven't used the language so I can't speak to that).

[EDIT] minor edits.

mrec• 12 years ago

The Rust folk tend to avoid talking in terms of purity nowadays. Graydon had a good writeup of the pitfalls: http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focu...

adamfeldman• 12 years ago

The 2007 book Rainbows End by Vernor Vinge addresses this topic from a science fiction perspective. A major plot element is the ability of individuals to enter into "affliances": digital, automatically-escrowed contracts between individuals providing small services in networks created on-demand to produce larger-scale goods and services. https://en.wikipedia.org/wiki/Rainbows_End (copied my past comment at https://news.ycombinator.com/item?id=7287584)

Also, here's a related past HN thread: https://news.ycombinator.com/item?id=7287155

thecopy• 12 years ago

Began reading on the tram home.. need to read up on basic crypto currencies

rsync• 12 years ago

I can't decide if I want to see ethereum implemented in dwarf fortress ... or dwarf fortress implemented in ethereum ...

Ethereum White Paper

Related Stories