HTTP/REST integration possible?

tym4t

I could see this being an important part of the programming language. What if a specific contract requires integration with a 3rd party system as part of its operation (i.e. checking a USPS tracking number's status for delivery etc...) to verify a state outside of its own system.

mquandalle

See the "Networking daemon" in the "Layers" section of the white paper:
https://github.com/ethereum/wiki/wiki/[English]-Layers#wiki-networking-daemon

tym4t

That seems to be related to node-to-node communications. I am talking about giving the scripting language the ability to consume 3rd party API endpoints.

There was a discussion about trusted data feeds in the white paper as well as on a different forum thread[1] but I can't seem to find further details on it. So I'm starting a new thread in hopes that it gets some attention from the core team. There is going to be a concern on whether or not a miner/node should be made to access an external site due to obvious security reasons but we also need some kind of flexibility for contracts to be truly useful. For example what if the contract requires that an item needs to be shipped so we need to verify through the shipping provider the status of the tracking number and the way we would do that is to use the shipping provider's API to see the status.

[1] http://forum.ethereum.org/index.php?p=/discussion/31/what-would-a-trusted-data-feed-look-like

Jam10o

It would, like you mentioned, be incredibly unsafe to allow contracts to access outside APIs. Of course, there is nothing stopping contracts from reading data that is sent directly to them, and therefore contracts themselves don't connect to the outside world, but rather, external apps do, and pass that information on to contracts in a way that can be trusted (ie, signed data).

If a contract needs to know whether a package is delivered, either the package itself must have a hardware component that is connected to the blockchain (ideal), or an external server must constantly check the status of the package, and send the information on to the blockchain once it arrives (which is likely going to be the case until we get our ether-enabled hardware). Pipe dreams aside, it won't be anywhere near as hard to get trusted data to contracts as people are making it out to be, albeit it may be slightly less "decentralized" than everyone seems to imagine. At least for the time being.

oliverkx

Wasn't a premise of block-chain technology that it would not require trust relationships anymore? The entity that is feeding the data to the contract has immense power over that contract's behavior. A fake gold price, or a made-up Superball score could make some people very rich at the expense of others. So, who are these entities going to be that are feeding data to the contracts, and how can the contract's users trust them?

chris613

@oliverkx? Once the data is in the blockchain the dissemination and certification of transactions that depend on it is a trustless process, but there is no way to introduce external facts without trusting their source. One way to minimize required trust and is to have several sources and only accept it if M of N agree within some bounds; take the average, etc.

@tym4t? AFAIK there are no plans for this sort of external call inside contract code. One reason is that if the target API ever goes away then the consequences of the contract can never be checked or replayed to validate the blockchain. Likewise if the API returns different values to different clients (for whatever reason) they will disagree on the outcomes. The most glaring problem is that the target API will face a deluge of traffic from ethereum nodes, and it would likely be possible to use contracts as a DDOS, scanning, or exploit tool. Like I said though, I don't think there are plans for this in ethereum; so far the blockchain itself, including contracts, is self-contained and deterministic, with no way for contracts to read or write outside the confines of the VM.