I've seen a lot of talk about smart contracts that can facilitate distributed markets such as Filecoin. In the words of Protocol Labs:

Filecoin is a cryptocurrency powered storage network. Miners earn Filecoin by providing open hard-drive space to the network, while users spend Filecoin to store their files encrypted in the decentralized network.

In a bitcoin transaction the miner earns their bitcoin by doing computational tasks that are core to the bitcoin network. The completion of the tasks are inseperable from the assertion that they've been done and therefore the payment of Bitcoin for doing them. You literally can't claim the Bitcoin without doing the work required.

What happens when the work required to earn the contract fee isn't so intrinsically provable though?

How does Filecoin verify that a file really has been stored and really hasn't been deleted afterwards? What's to stop a node on the network announcing that it's stored a file but not doing so? Or has stored it but then deletes it?

How would even more decoupled marketplaces work?

I can see (at a stretch) how you could make filecoin transactions intrinsically coupled to the release of the Ether but what happens when it gets more abstract. If you wanted to create a decentralised energy marketplace and pay Ether for using electricity / earn Ether for producing it, how would the contract verify that the electricity really had been produced or the right quantity really had been consumed?


I'm only going to provide a high-level summary of an Ethereum-based protocol token so this doesn't get too tangled.

I think it will be helpful to separate concerns. Let's start with the "token".

You could power the App with Ether, but you've decided to define your own token. For that, you set up a "minter" contract whose main concerns are issuance, enabling transfer and tracking balances. Importantly, nothing to do with the App.

You bootstrap it with a structure along these lines:

mapping(address => uint) balances;

You create an initial supply in the constructor:

balances[aliceAdddress] = 1000000;

There. Alice has 1,000,000.

Alice can send some to Bob with the transfer() function. The transfer function checks the msg.sender's (Alice) balance and does a little math to subtract from Alice and add to Bob (recipient), assuming Alice still has enough. Google ERC20 for an emerging standard interface that makes this token compatible with exchanges.

The App

The App can extract a toll from any function. It might help to imagine midway coupons at a fair that were required to ride the roller coaster. The guy running the coaster doesn't handle cash ... you go back to the Exchange or cash booth to get more. Coaster guy just collects tokens.

So, your App is just taking signed transactions from users who want to do stuff, and delegating the transfer of a token from the rider (Bob) to the App. You decide what's fair and sensible. Your App can also award tokens. The rules are completely up to you. Think of designing the rules of the game. Your users can pack up their score and head to an exchange to "cash out."


This is an entirely App-level concern. It may be that verification is self-evident as something has unfolded inside the App (touchdown!) or it may be very abstract and external.

Abstract/External is harder. For something like storage, there might be verification bot that does a challenge/response interrogation of nodes to see if they can prove they can recover a shard. For a betting App, it might be an Oracle that feeds a trustworthy game result.

For IoT you might consider why the App should trust the meter. This varies on a case by case basis. For example, if the meter is known to be certified accurate/trustworthy then perhaps its data feed can be trusted. You could represent that with an access control list; let's only listen to vetted trustworthy sources.

In the case of a highway toll booth, perhaps your deployment scenario involves two IoT devides, both with wallets, both connected; one in the gate and one in the car. Perhaps naive and superficial but maybe the gate allows one car to pass for each payment received; generally the car standing there, but maybe the payment comes from mom who is far away and that's permissible.

So, for emphasis, verification is very much an app-level concern. You're right to identify it as a vital aspect of any design, or else the public will reject the app design, correctly recognising a garbage in, garbage out scenario. It has to be both believable and tamper-resistant.

Hope it helps.

  • Hi @rob thank you for your answer, it educated me a lot. But it does leave me feeling that perhaps the harder part of all of the "smart contract" applications isn't solved. It's all very well having a distributed payments system for these type of systems but they in turn then require a further trust system for the meters that they interact with. It would be easy to simply call "blockchain" and assume this is a solved matter but it feels more challenging than that. Can you recommend any reading around how to build trust in the apps/meters themselves? – Peter Jun 19 '17 at 9:31
  • @Peter. Please find my contact info on my profile. Let's take this offline in a more conversational style. – Rob Hitchens B9lab Jun 19 '17 at 14:29

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.