0

Let's say I own a smart home ecosystem and a mobile app that users can use to turn on their air conditioner.

Is there a way to incorporate blockchain so that no one else can turn on that air conditioner besides the whitelisted user?

1) If I put the private key as a config in the app itself, is that dangerous? To my knowledge, having the private key allows the app to sign my transactions allows me to safely with my smart contract. But does that make my app hackable?

2) One concern I have is that it would be too slow to mine the transaction. No one wants to wait a minute to turn on their air conditioner.

1

One of the most important aspects of blockchain based development is knowing when stuff should go on-chain and when something shouldn't go on-chain. Ownership is something that's perfect for being on-chain, e.g. this address owns this air conditioner. A solution using this on-chain/off-chain separation would be like this:

  1. Air conditioners have a private key on a secure element at manufacture time.

  2. The user sets up the AC by pairing it to local network. The user generates a private key/address locally and the address to the AC locally.

  3. The AC signs the users address and sends it to your server. (Since the AC signed the user's address, the server knows the AC is speaking for itself.)

  4. The server creates a tx pairing the AC's address -> the user's address on-chain.

  5. The user can now send a message to the server asking it to control the AC. The server then forwards the message to the AC and the AC can verify on the blockchain that the signing address is the address that has access to it. Alternatively the user can send the message directly to the AC.

The AC can either use your server, a node on the user's local network, or any other node to verify the address signing the message is authorized to control it.

  • Oooo thanks! By "server" do you mean an actual server? Isn't that defeating the point of using blockchain? – bigpotato Nov 24 '17 at 19:20
  • @Edmund Yeah, an actual server. The point of the blockchain isn't to do away with servers, in this context it's to make them no longer hold all the power, e.g. the server can't make your AC do anything unless your private key signs a message telling it to. You could take out the server in this scenario so the AC or user creates the tx linking the user and AC's addresses and the user sends the signed messages directly to the AC, but then the user pays the tx fee for linking. – flygoing Nov 24 '17 at 19:40
  • So in this context, are we just using blockchain for authentication? So after creating the private key / address and linking that to the AC on my server, when the user tries to control the AC through the app, it makes a request to the server, the server checks the blockchain to see if the user is allowed to control that AC, and then either accepts or rejects it. Is that correct? – bigpotato Nov 24 '17 at 19:43
  • Yes, the blockchain is just for authentication in this case. As I said before, you can leave the server just for initial pairing so the user doesn't pay the tx fee. After that you can have the user send messages directly to the AC and the AC can check the blockchain to see if the signer is the owner of the AC – flygoing Nov 24 '17 at 19:46
  • Awesome!! However, even with this infrastructure I still have the same concern about how long it would take. So lets say the user has been linked to the AC. If they try to, say, turn on the AC, would that take a long time? When the server performs a READ on the blockchain to see if the user is linked to the AC, is that basically as fast as a SQL operation? – bigpotato Nov 24 '17 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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