5 ms·

Ethereum White Paper

mquandalle 13y 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 https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft [2] http://gavwood.com/Paper.pdf http://gavwood.com/Paper.pdf
terhechte 13y 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 13y 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.
  - terhechte 13y 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?
- mquandalle 13y 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_180 http://forum.ethereum.org/discussion/comment/180/#Comment_18... [2] http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...
  - terhechte 13y ago
    Thanks, that totally makes sense.
- nullc 13y 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 13y 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.
    - nwh 13y ago
      How do you verify that the information is correct independently?
      - iambot 13y ago
        see @mquandalle's reply re schelling coins, blog post by @vbuterin here: http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...
- jamespitts 13y ago
  For cases like this, a trusted, external system would post data into the contract.
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
bachback 13y 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_and_comprehensive_smackdown_of_leah/cg5ikzo http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_an...
- oleganza 13y ago
  Could you pls expand on this: "Bitcoin solves also a latency variance problem, to achieve logical broadcast"?
  - bachback 13y 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/time-clocks.pdf 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.
- 13y ago
higherpurpose 13y 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 13y 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 13y 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/focus=3855 http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focu...
adamfeldman 13y 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 https://en.wikipedia.org/wiki/Rainbows_End (copied my past comment at https://news.ycombinator.com/item?id=7287584 https://news.ycombinator.com/item?id=7287584) Also, here's a related past HN thread: https://news.ycombinator.com/item?id=7287155 https://news.ycombinator.com/item?id=7287155
thecopy 13y ago
Began reading on the tram home.. need to read up on basic crypto currencies
rsync 13y ago
I can't decide if I want to see ethereum implemented in dwarf fortress ... or dwarf fortress implemented in ethereum ...

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 https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft [2] http://gavwood.com/Paper.pdf http://gavwood.com/Paper.pdf

terhechte 13y 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 13y 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.
- terhechte 13y 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?
mquandalle 13y 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_180 http://forum.ethereum.org/discussion/comment/180/#Comment_18... [2] http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...
- terhechte 13y ago
  Thanks, that totally makes sense.
nullc 13y 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 13y 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.
  - nwh 13y ago
    How do you verify that the information is correct independently?
    - iambot 13y ago
      see @mquandalle's reply re schelling coins, blog post by @vbuterin here: http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...
jamespitts 13y ago
For cases like this, a trusted, external system would post data into the contract.

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]

bachback 13y 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_and_comprehensive_smackdown_of_leah/cg5ikzo http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_an...

oleganza 13y ago
Could you pls expand on this: "Bitcoin solves also a latency variance problem, to achieve logical broadcast"?
- bachback 13y 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/time-clocks.pdf 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.
13y ago

higherpurpose 13y 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 13y 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 13y 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/focus=3855 http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focu...

adamfeldman 13y 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 https://en.wikipedia.org/wiki/Rainbows_End (copied my past comment at https://news.ycombinator.com/item?id=7287584 https://news.ycombinator.com/item?id=7287584) Also, here's a related past HN thread: https://news.ycombinator.com/item?id=7287155 https://news.ycombinator.com/item?id=7287155

thecopy 13y ago

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

rsync 13y ago

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