2

Very new to this space, so forgive the lack of foundation knowledge. Looked at the yellow paper, but honestly the set theory in it is a bit more than I want to bite off right now.

I think I have an ELI5 understanding of DApps. They react to deposits (entry) of ETH, I understand that. They can do some process while they have ETH (execute), I think I get that. But what are their exit conditions? I guess for something like a ticketBooth.Dapp I get it, but for something like a crowdfund, what verifiable proof does the Dapp have to trigger its exit on.

For example... let's say I want a Dapp to fund a feature I want in some game. So I do same marketing and convince enough people to send the Dapp ETH. Now, presumably it will start a timer to refund the ETH if the time runs out, or reward it to the company that release the feature update for the game.

This is all well and good, but without centralized control, how does the Dapp know

  1. That the feature was really implemented and is not just shell-ware.
  2. Where to send the money when done.

Do the Dapp developers need to pre-seed these conditions into the Dapp before it is launched, and if so, how would it verify something like softwareQuality == GOOD?

Malone
  • 1,590
  • 12
  • 23
Dan
  • 133
  • 6

1 Answers1

2

If I'm understanding your question correctly, you'll want to be looking at Oracles. In particular there is a service called Oraclize who seem to be leading the way in this area.

Many other answers explain in great detail how these Oracles work. But a short synopsis would be:

Smart contracts live like in a walled garden, they cannot fetch external data on their own. Oraclize is here to help. We act as a data carrier, a reliable connection between Web APIs and your Dapp. There is no need to open additional trustlines as our good behaviour is enforced by cryptographic proofs.

So, for your example:

How does the DApp know that the feature was really implemented and is not just shell-ware?

You'll need to provide a trusted API that all users know will give the correct response once an Oracle fetches data from it. This API could give the public key of the developer's/company who implemented the feature. Thus acting as an identifier of the rightful recipient of the Ether.

If the idea of trusting one API isn't an option, you could see if there are multiple API's that could provide the data. The more data sources you have then the less likely it is for all parties to conspire by sending incorrect responses.

Hope this helps.

Malone
  • 1,590
  • 12
  • 23