Dear Mr. Ngaboyindekwe ,

actually I had a similar idea a while ago. My idea was to use block chain to guarantee the integrity of communicated sensor data, i.e, to keep "bad" people from sending wrong information.

However, I came to conclude that this can't work as all other participants need to be able to verify the data transmitted. Taking Bitcoin as an example, every participant sees the whole blockchain and is therefore able to verify its integrity. New transactions are also visible to all participants. In case there's some abuse, every participant sees that. The "good" participants will therefore reject the block containing the abuse. The consensus protocol leads to the sane branch of the block chain becoming dominant, i.e., longest, over time - as long as the "good" participants control more than half the hashing power.

Getting back to the sensor data, it's obvious that not every participant can verify every item of data (e.g., due to location constraints). Therefore the concept doesn't work.

The way to "guarantee" (I put this in quotes as you can never be 100% sure due to error sources in sensing and processing) is to define participants as trusted entities. This is commonly achieved using cryptographic certificates, where a commonly trusted entity says that a client is trustworthy by issuing a certificate to her. This is very similar to a bank or a lawyer. This, in a first step, is the statement that "this client will not knowingly transmit wrong data".

However, this doesn't help against wrong data injected into the system due to errors. This is commonly tackled using data fusion mechanisms and statistical mechanisms (while data fusion usually builds on statistical mechanisms, too).

Data fusion in this context means that, roughly speaking, you don't blindly trust others but compare the data available in the system with your own.

Statistical mechanisms can be thought of as a kind of consensus protocol. You determine the likelihood of different events given the available data and, possibly, a system model. Taking a very much simplified example, your vehicle and three others sense the same region. One of the other vehicles states that there's a pedestrian in that region, yours and the two others say there's nothing. You know that sensing systems sometimes "see" things where there are none (so-called clutter), but may also miss things which actually are there. You can now conclude that the likelihood of a pedestrian being in that region is pretty low as the probability of one sensor system seeing clutter is higher than three sensor systems missing a detection.

The statistical nature of these mechanisms explains why above I wrote that you can never be 100% sure of anything.

Unfortunately, many proponents of block chain market it as a kind of magic solution to any problem. However, if you take some time to consider it, you find that actually it's just applicable to a limited number of use-cases.

Furthermore, using block chain for things which are just valid, existent or useful for a limited time span doesn't make sense. A block chain is a complete history of the evolution of some system. It therefore only makes sense if the system's components don't vanish over time, as otherwise you would carry a huge amount of useless data. Cryptocurrencies are designed such that their "entities" (the "coins") exist forever. They may be created but never cease to exist; they're just exchanged between participants.

Best regards,

Johannes

Dear Kay, thanks for linking those papers. I just read the first two, but actually they don't have any reasonable argument for using block chain in ITS. I'll point out why.

The first one, while that system would work (which I never questioned) doesn't provide any benefits over using cryptographic signatures. Actually, it's just that plus the additional overhead of the block chain. You need to invest computational power for the proof of work. They need additional infrastructure for that, too! While ITS could run as a self-dependent system with just ad-hoc communication, in all of these concepts you need internet access and servers. For a block chain to work you need to get every update to all participants within reasonable time, and the amount of operations per unit of time you can do on the blockchain is limited. And it has to be, otherwise the proof of work wouldn't work. The first paper just has two example applications - tolling and ticketing. These are classical transactions, which are just implemented differently using the block chain. The only benefit the paper presents is that, if using block chain, the system would be decentralised. However, in reality it would be an oligopoly at best due to infrastructure costs, interoperability requirements and regulations.

It's also funny that they speak of anonymity while requiring anybody to have a unique, non-exchangable private key. This implies that anonymity is easily broken by matching different data pools against each other.

The second paper - please excuse the hard words - is just hilarious. The authors obviously haven't understood what makes the block chain tamper-proof in crypto currencies. That's not an inherent property of a block chain but game theory. Participants are discouraged from behaving "bad" as they know they have no chance of tampering the system unless they control more than 50% of the hashing power (the 51% rule). And even if they did, all others would retreat from the system and they would have no means for monetarizing their gain.

This is what builds trust in a crypto currency. The knowledge that tampering would require an attacker to make huge investments which he could never transform back into some "real world" things.

However, as I pointed out before, this concept of trust isn't applicable to systems in which the correctness of transactions can't be checked by any participant.

To me it seems that few people are actually aware of the limitations of the concept of trust behind crypto currencies. This is a philosophical rather than a technical problem.

Please share me the best answer might you get...