W3C home > Mailing lists > Public > public-wot-ig@w3.org > August 2016

Re: Blockchains and the Web of Things?

From: Drasko DRASKOVIC <drasko.draskovic@gmail.com>
Date: Tue, 30 Aug 2016 15:23:41 +0200
Message-ID: <CAEk6gTCgehD=tHT5ingA-5UujkAjCbxNvex=6Fs-y=rJkBLEow@mail.gmail.com>
To: "Tibor Z. Pardi" <tibor@zovolt.com>
Cc: Dave Raggett <dsr@w3.org>, Public Web of Things IG <public-wot-ig@w3.org>
Hello Tibor,
thanks for answering all these questions in details. However, you
opened new ones ;).

On Tue, Aug 30, 2016 at 12:21 AM, Tibor Z. Pardi <tibor@zovolt.com> wrote:
> Hi Drasko,
> 1) In blockchain security depends on computing nodes to calculate the
> blocks. How do you solve this problem with low-power devices - i.e.
> who is calculating the blocks? Is it maybe gateway? I am asking this
> because whoever can have big processing power on the network can take
> over the whole network.
> That's correct, in "traditional" blockchain systems the blocks are
> calculated and then generated by nodes using different type of collaborative
> methods such as PoW, PoS, PoC, etc. Some blockchains simply use practically
> centralized trusted nodes to generate the blocks and speed up transaction
> times. It is not feasible to run such blockchain nodes on low power,
> constrained IoT devices. As you said, and that's what I try to point out as
> well to users, a blockchain based implementation can run only on a gateway
> device. I think there is definitely a place for decentralized computing and
> P2P within IoT, but blockchain provides lot less benefits. We can achieve
> decentralized and P2P IoT device control without a blockchain. For instance
> Streembit uses the lot simpler distributed hash table (DHT) for
> decentralized device discovery and facilitate peer-to-peer related tasks.
> Blockchain could be useful in several use cases where a distributed ledger
> function is required (e.g to audit devices or microtransactions), but it can
> be a lot simpler implementation than the BTC or ETH blockchains that require
> PoW, PoS, etc.. A simple merkle tree can do the job without the ethical,
> legal, computing and processing issues of PoW and PoS.

Would a simple merkle tree be as secure (i.e. prevent tampering)?

Does Streembit uses blockchain at all (even on Gateways)?

Do you know if how Telehash is using Blockchain (I think they are
using Bitcoin blockchain, and only for DNS resolvin that they call
"blockname": https://github.com/telehash/blockname)? On gateways? Even
these gateways would not be sufficient for hash calculation IMHO and
the network can be taken over with 51%.

> Terms of taking over the network. of course the majority of processing power
> can take over the network. The 51% attack and the Byzantine generals problem
> are well documented and unsolved weaknesses of popular blockchain projects
> like Bitcoin and Ethereum. We are having a debate about this for many years
> within the cryptocurrency community. I propose in the quoted white paper to
> address these problems using private networks which is very doable in an IoT
> project as e.g I know what is my garage door controller and I can handle
> that in a decentralized, P2P manner without the complexity and issues of
> Bitcoin and Ethereum. Again, I don't think majority of IoT projects will
> have this issue ever, as the aforementioned problems are related only to
> block generations.

If IoT networks are using Blockcain block generation on Gateways then we have:
1) Semi-centralized network and
2) Possibility that network will be taken over - if somebody comes
with greater computing power than 51% of your nodes.

Let's say that you will eliminate Byzantine generals attack by having
a private network. But what are then real benefits to decentralized
private network? Easier discovery? Lower deployment cost?

Speaking about private mesh, I know we talked about this before, but
Telehash has this option now from v3:
https://github.com/telehash/telehash.org/blob/master/v3/intro.md -
"supports bridging and routing privately by default and optionally via
a public DHT (draft)".

> 2) Did you try to leverage existing Blockchains - Bitcoin or Ethereum
> ones? I am asking this because I suppose that these networks are now
> practically impossible to take over.
> You are correct, BTC and ETH networks are matured networks, but in my
> opinion these aren't optimal at all for IoT projects. No wonder, after many
> years of hype there is no commercial implementation exist for BCT or ETH in
> IoT. There is no need to use the bloated Bitcoin or Ethereum to open a
> garage door or turn on the light with a relay switch. Even IoT
> microtransactions or device auditing could use a lot simpler blockchain or a
> straight forward merkle tree implementation without the complexity,
> problems, legal and ethical issues of Bitcoin and Ethereum.

I saw in Adept that they are using Microtransactions a lot. They are
also demonstrating this on new MTN project:

Slock.it is using microtransactions over Ethereum. Fillament is using
Pennybak: http://quartzjer.github.io/pennybank/.

That means that all of these solutions are using Blockchain of some
kind, and I am really wondering where and how they are calculating
blocks... Because if Slock.it lock is calculating blocks that does not
make sense IMHO...

> 3) Did you examine Hyperledger project for the possible use of their
> Fabric blockchain?
> Thanks for pointing this out. It will be interesting to see how this project
> will address 51% attack and the Byzantine generals problem and at the same
> time keep the permissionless, decentralized and P2P implementation.

Actually what I find interesting is maybe approaching Hyperledger
project which actually just collects various Blockchains from the
industry and see with them about embedded variant. Beacuse, as I
pointed out - all these companies are using blockchain of some kind,
and as you pointed out - none of the blockchains is currently adapted
for embedded use.

Maybe we can have some skinny blockchain, just merkle tree - suited
for embedded use and microtransactions?

Received on Tuesday, 30 August 2016 13:24:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:06 UTC