Blockchain in the context of io t with a focus on monitoring a survey 2017

1. Blockchain in The Context of IoT With A
Focus On Monitoring:
A survey
2017
Ali Alzubaidi
aakzubaidi@gmail.com
@Ali_abdulaziz_
1st of December, 2017
1

2. Problem Statement
• End to end Internet of Things (IoT) applications (I.e. All layers including; sensors,
actuators, network, and cloud) must be continuously monitored to ensure correct
operation.
• Determining when and what to monitor is largely left to the system
administrators, and therefore current monitoring strategies are ad hoc, of
variable quality, and not scalable to large systems.
• Current strategies monitor a single layer in isolation from other layers, thus
solutions are agnostic to policies across dependent IoT components.
• This leads to incomplete and inconsistent monitoring solutions, which is of critical
importance to applications such as health care.
• The aim of this research project is to investigate comprehensive and automated
solutions for end-to-end IoT application monitoring that take into consideration
the policies of all layers and components of an IoT eco-system.
2

3. IoT Architecture
Adapted from Cisco, “The Internet of Things Reference Model”, white paper 2014.
3

4. Where are we now?
• Pendulum swinging between Distributed and Centralized
• Signal machines -> workstations -> client-server -> P2P -> Cloud -> ?
• To Think out the box, we need to subtract somethings and re-think around
of alternatives.
• The Cloud?
• Several challenges are attributed to the cloud:
• Privacy ?
• Latency, processes scheduling, performance, isolation etc..
• IoT Solutions solely based on cloud create big gap. (Chiang M, Zhang T, 2016).
• It is impractical to send every single raw data to cloud.
• A self-driving car generate around 4 TB daily.
4

5. • Although processing capabilities have been consolidated, still the data
transfer size is an obstacle to materialize perfect IoT scenarios.
(A. Brogi and S. Forti, 2017).
• Due to massive number of IoT devices and geo-distribution of them.
• Single point of failure.
• Long continuous connectivity is unreliable
• We need to support storage and data analytics near to the data origin. (A. Brogi and S.
Forti, 2017).
• However, several limitations associated with the edge.
• limited resources.
• Fog architecture could fill the gap.
5

6. Adapted from: https://blog.iota.org/a-primer-on-iota-with-presentation-e0a6eb2cc621
6

7. 7

8. P2P features
• (L, E Keong, et al. 2005) point out that:
• Selection of nearby peers
• Redundant storage
• Data permanence or guarantee
• Hierarchical naming (L. GARCÉS-ERICE, et al, 2003)
• Trust and authentication
• Anonymity
• Optimized cost and resource utilization.
• Peers can share computing resources without [total] dependency on a central
cloud or server (third party). (P B et al., Empowering the Edge)
8

9. Fog Architecture
• It aims at extending the Cloud by bringing computational power, storage, and
communication capabilities to the edge of the network (R. Milito et al., 2014).
• Fog aims at dynamic allocation of workload forth and back in the network,
between the cloud and the edge resources.
• Leverage the resources provided by the edge.
• Nodes can communicate with neighboring nodes through APIs offered by the fog
middleware layer.
• Enabling Device to Device (D2D) communications.
• Dealing with agnostic environment.
• Continuum, end-to-end awareness (Chiang M, Zhang T, 2016).
• Computation near to the cyber-physical systems.
• Real-time decisions.
• Solves the data transfer issues.
9

10. QoS-Aware Deployment of IoT Applications
Through the Fog
• Proposed by (A. Brogi and S. Forti, 2017)
• QoS assurance concerning application deployment over the fog.
• Observation: The majority of tools for automated deployment of
distributed software do not deal with nonfunctional properties to achieve
eligible deployments over available fog nodes.
• Specifically, it concerns segmentation of applications (components).
• Among the possible QoS metrics, they examine latency and bandwidth since nothing
can be done to tame them at the run-time.
• It only proposes best deployment suggestions (environmentally adaptive).
• The select of which particular deployment of a preference is not automated. This is
left to the experts to decide.
10

11. QoS-Aware approach to monitor violations of
SLAs in the IoT (M. Alodib, 2016)
• Discrete EVENT System (DES) to automate generation of QoS awareness and real-time
monitoring.
• A method, which automates the modeling of SLAs, and generates a real-time monitoring service.
• Model Driven Architecture is employed to automate the process of generating a
monitoring service.
• Motivation:
• The absence of standardized mechanisms to represent these requirements.
• The difficulty of declaring SLAs that adapt to dynamic environment.
• Discrete Event System is a diagnostic theory proposed to discover failure.
• Quality of Service (QoS) requirements are declared via Service Level Agreements (SLAs).
• The SoA composite application and user-defined SLAs are mapped into Petri net model.
• Therefor, An algorithm to compute and produce a QoS-Aware service.
• QoS-aware service monitors any violations of SLAs.
11

12. IoT Monitoring Challenges
• Most of the current SLA monitoring tools are provider-dependent(T. Labidi, et al, 2017).
• Heterogeneity
• Data format, communication protocols, OS, policies, batch production, etc.
• Agnostic environment.
• Modern large scale applications are not monolithic anymore.
• An application running over a Fog computing infrastructure can be thought as a set of
independently deployable components that are working together and must meet some QoS
constraints.
• Formal definition of the performance metrics (E. Solaiman et al. 2016)
• Each provider would suggest its own SLA definition, thresholds and provider-dependent
equations.
• Preventing breach occurrence at the first place. Especially to critical systems
• It is of importance to ensure correct operation in advance.
• Distributed nature of IoT complicates the task of breach monitoring (M. Alodib, 2016).
12

13. Blockchain Characteristics
• Blockchain mirrors B2B due to its distributed nature.
• It's a gossip protocol whereby all state modifications to the ledger are
broadcast to all participants.
• To make sure consensus of the state is agreed upon.
• The block size limit reflects on the number of miners involved in the
validation process (J. Poon and T. Dryja, 2016).
• The larger a block limit, the fewer miners are. This encourages centralisation.
• Synchronized global state and the replicated ledger (C. Decker and R. Wattenhofer, 2015).
13

14. How we think of a blockchain?
Blockchain is a shared, replicated transaction system
which is updated via smart contracts and kept
consistently synchronized through a collaborative
process called consensus.
14

15. Why Blockchain Technologies are appealing
• Decentralization
• Can help mitigate the need for centralized authority. (P. Brody et al, 2014)
• Mitigates single point of failure. (IBM Institute for Business Value)
• Secure by design.
• Trustless peer to peer communication
• Permissionless
• Tolerant to node failures.
• Immutability (E. Di Pascale et al., 2017)
• Audibility
• Eliminates the possibility of disputes.
• Review this more detail https://www.slideshare.net/_hd/ibm-adept
15

16. Smart contracts
• Ethereum (GAVIN WOOD, 2014)
• Ether is the digital fuel that motivates the Ethereum network
• Turing-complete programming
• Solidity https://solidity.readthedocs.io/en/develop/
• “Arbitrary contracts can theoretically be created for any transaction type or application”.
(Ethereum: white papre)
• Business logic is expressed as a code (K. Christidis et al, 2016)
• Deterministic behavior
• Same input -> same output
• Smart contracts allows the following:
• Maintaining direct realtime control.
• Governance rules are formalized.
• Contracts are self-enforced and executed.
16

17. • Smart contracts provide controlled access to the ledger.
http://hyperledger-fabric.readthedocs.io/en/latest/blockchain.html#why-is-a-blockchain-useful
17

18. Consensus
• Common truth is called consensus among nodes.
• The process of keeping the ledger transactions synchronized across
the network.
• All appropriate participants agree on the transaction status.
• Consensus has to be Byzantine Fault-Tolerant using the PBFT protocol
and others means depending on the scenario (C. Cachin, 2016).
• Consensus mechanism selection is influenced by whether the
network is private (permissioned) or public (permissionless)(M. Valenta and P.
Sandner, 2017)
18

19. An Automation Method of SLA Contract of Web
APIs and Its Platform Based on Blockchain
Concept
• Proposed by (H. Nakashima and M. Aoyama, 2017).
• Conventionally, server provider platform hosts SLA contracts.
• In order for contracts to be trusted, they should be independent from
involved parties.
19

20. • WSLA is a specification language for web services SLAs.
• SLA contracts can be automated as a smart contract on the Ethereum.
• They share the same interest with regard to SLAs and blockchain.
However, they apply WSLA in which they focus on WSDL and SOAP
messaging.
• Around 80% of web API are RESTful.
20

21. https://www.programmableweb.com/news/which-api-types-and-architectural-styles-are-most-used/research/2017/11/26
21

22. Smart Contract SLAs for Dense Small-Cell-as-a-
Service (E. Di Pascale et al., 2017)
• Smart contracts to implement Service Level Agreements (SLAs) between
small cell providers and Mobile Network Operators (MNOs).
• It also presents an example contract template based on the Ethereum
blockchain.
• Motivations:
• Blockchain Immutability, Non-repudiation, trustless environment, cost-effective, self-
enforcement.
• Demonstration is based on QoS Class Identifiers (QCI), which the later
defines services in terms of priority, packet delay budget and packet loss
rate.
• Key Performance Indicators (KPIs) will be then used to measure the performance.
• Available Online: https://bitbucket.org/edipascale/sla-solidity.
22

23. • Basically, they use blockchain to store events such as
• PeriodicPayout , InsufficientThroughput, throughputBreach etc.
• Event can be locked up and referred to.
• Once a MONITOR in either parties observes a violation,
• It specifies the the breach with respect to the QoS.
• The contract is triggered.
• This contract then will apply penalty.
23

24. • Observations by (E. Di Pascale et al., 2017)
• Advantages:
• The use of smart contracts can automatically impose rewards and penalty mechanisms.
• Complex business models can be easily transformed into automatically enforceable
contracts.
• Limitations:
• Legality issues: no central authority able to rectify a transaction over a permissionless
ledger in case of a dispute.
• Smart contracts: might be vulnerable to bugs and attacks.
• Recommendation:
• It is recommended to include a fail-safe mechanism in the contract to be able to disable
it and recover any outstanding balance in its possession in the event of the discovery of a
vulnerability in the code.
24

25. Blockchain limitations
• The performance is a cost for trustless communication.
• lower transaction processing throughput and higher latencies.
• This is mainly due to proof-of- work mechanisms. (M. Vukolić, 2015)
• A block is created within ~10 min.
• Byzantine failure.
• Latency: due to the fault-tolerant gossip process(broadcasting) (C. Decker and R. Wattenhofer, 2015).
• Scalability
• Centralized platform: Visa can process ~47,000 transactions/s.
• Blockchains: Depending on block size limit, say 1 MB: in Bitcoin -> ~ 7 transactions/s.
• synchronized global state, the replicated blockchain hinder scalability
• How to scale blockchains Without sacrificing the decentralization and security. (J. Poon et al., 2016).
• Unconfirmed transactions https://blockchain.info/unconfirmed-transactions
• Security
• The fact of smart contracts represented as a code, it can be vulnerable to attacks (E. Di Pascale et al., 2017)
.
• Review this more detail https://www.slideshare.net/_hd/ibm-adept
25

26. Empowering the edge: Practical insights on a
decentralized Internet of Things
• Technology vision:
• Autonomous Decentralized Peer-to-Peer Telemetry (ADEPT).
• Jointly developed by IBM & Samsung Electronics.
• Demonstrates a fully distributed proof.
• No centralized computation involved.
• The ADEPT implemented three open source protocols:
• Telehash for messaging
• BitTorrent for file sharing
• Ethereum, a blockchain protocol for autonomous device coordination functions:
• Device registration, Authentication, Proximity-based and Consensus-based rules of
engagement, Contracts and Checklists.
26

27. 27

28. ADEPT
• The paper suggests that, a decentralized IoT must support:
• Trustless, encrypted messaging and transport
• Low latency with guaranteed delivery
• The concept of Distributed Hash Tables (DHTs) can meet requirements
• Telehash is best open source messaging implementation. Thereby, it is used.
• Basically, Notifications among devices without using a centralized server.
• Bit Torrent DHT file sharing protocol
• Used for propagating purposes and content distribution. (No centralization)
28

29. • By not requiring a third-party arbiter of roles and
permissions, an autonomous device coordination
approach empowers owners of devices to define
and manage their own interactions.
• This is implemented using blockchain technology
platform.
• No need for strict mining process in IoT.
• ADEPT selected Ethereum protocol
• Turing complete scripting languages to express
contracts.
• Trust level evolves by the time,
29

30. • Each category can Perform their tasks for their own and for the lower layer
• Each layer has a logical view architecture
• For more detail review (V. P. et al., ADEPT: An IoT Practitioner Perspective, 2015)
• For additional information contact
• Veena Pureswaran vpures@us.ibm.com
30

31. Decentralized Autonomous Organization
(DAO)
• https://www.coindesk.com/information/what-is-a-dao-ethereum/
• https://github.com/CJentzsch/DAO
31

32. Slock.it
• Refer to their white paper (C. Jentzsch, 2016).
• https://slock.it/index.html
• Universal Sharing Network (USN)
• They developed A Decentralized Autonomous Organization (DAO).
https://github.com/slockit/DAO/ written in solidity programming language.
32

33. RSK Bitcoin powered Smart Contracts
• http://www.the-blockchain.com/docs/Rootstock-WhitePaper-
Overview.pdf
• http://www.rsk.co/
33

34. IoTa: The Tangle
• Introductory blog about IoTa
• https://blog.iota.org/a-primer-on-iota-with-presentation-e0a6eb2cc621
• The Tangle structure: refer to (S. Popov, 2017).
• This solution stresses the concept of “Smart Decentralization” for IoT
environment
• The Authors see that the current blockchain lacks scalability.
• A solution towards No Transaction Fees.
34

35. • Tangle is a Distributed Ledger for M2M Payments and interactions:
• Automated execution and security.
• It is based on the concept of Directed Acyclic Graph (DAG).
• There is nether blocks, nor chains.
• No Miners -> Zero-incentive.
• punishment strategy instead of incentives.
• All active participants are directly involved.
• It shares with blockchain essential principals but not necessary the
underlying mechanism:
• Distributed storage and P2P network.
• Consensus and validation.
35

36. • The goal for each transaction is to get confirmed (green).
• Colors indicate the level of consensus (confirmation) achievement.
36

37. • Consensus is no longer decoupled from transaction processes, which
enables a validation without fees.
• A new transaction attests directly other two transactions, and indirectly that a
subsection of the Tangle are valid and conforms to the protocols rules.
• The transaction is signed with private key
• MCMC (Markov chain Monte Carlo) randomly selects existing unconfirmed
transactions (tips).
• Proof of work similar to Hashcash (spam and sybil-resistance).
• New transactions will try to confirm this transaction with same procedure.
• They claim this consensus mechanism allows micropayment with
scalability.
• Consensus is parallelized and is not sequential. Fast
• Test: 250 nodes -> ~ 100 confirmed transaction/s.
37

38. • Offline Transactions (partitioning)
• Branch off and back into the network
• Adaptive to the requirements of an
asynchronous IoT environment.
• Make transactions in an offline environment
• By utilizing different communication
protocols (ZigBee, Bluetooth LE, etc.)
for the P2P communication
38

39. The Bitcoin Lightning Network: Scalable Off-Chain
Instant Payments (J. Poon and T. Dryja, 2016)
• This paper proposes a network of micropayment channels.
• For blockchains to deal with large volume of data and a massive
number of transactions, there has to be a solution that does not
compromise the decentralisation. Otherwise, it is either the
blockchain collapses or the more centralised approach will replace.
• Brining the validation process close to the consumer level.
• So instead of mining every transaction, only mining the channel
opening/closing. https://www.slideshare.net/tm89lee/intro-to-lightning-network-bitcoinlitecoin-blockchain-developers-Malaysia.
• Micropayment channels only create a relationship between two parties.
• Transactions are instantly executed off-chain. No miners involved.
https://www.slideshare.net/meinhard/bitcoin-micropayment-channels
39

40. A Fast and Scalable Payment Network with
Bitcoin Duplex Micropayment Channels
• Proposed by (C. Decker and R. Wattenhofer, 2015).
• Reduces the reliance on the blockchain to further decentralize the
architecture of Bitcoin.
• Using off-blockchain, arbitrary number of transfers can be processed
locally between two users.
• The blockchain is only involved during the setup and the closure of such a
channel, while the vast majority of updates is never committed to the
blockchain.
40

41. Hyperledger Architecture
• https://www.zurich.ibm.com/dccl/papers/cachin_dccl.pdf
• https://www.hyperledger.org/wp-
content/uploads/2017/08/HyperLedger_Arch_WG_Paper_1_Consens
us.pdf
• http://hyperledger-
fabric.readthedocs.io/en/latest/blockchain.html#why-is-a-blockchain-
useful
41

42. Architecture of the Hyperledger Blockchain
Fabric (C. Cachin, 2016)
• Hyperledger project started in December 2015 by the Linux Foundation.
• Several major blockchain initiatives composing the heyperLedger on it including IBM,
Intel, .. and other 50+ members, Hence the name.
• cross-industry blockchain technologies. Standardization
• Open-source Modular Architecture.
• Pluggable implementations of different components.
• It promises high degrees of confidentiality, resiliency, flexibility, scalability.
• performance is achieved due to the obviation of PoW and permissioned
environment.
• Hyperledger Fabric is private and permissioned.
• Membership Service Provider (MSP) instead of Proof of Work.
• determine who participate in the validation process
42

43. 43

44. Comparison of Ethereum, Hyperledger Fabric
and Corda (M. Valenta and P. Sandner, 2017)
44

45. 45https://letstalkpayments.com/what-you-need-to-know-about-the-hyperledger-blockchain-fabric/?utm_content=bufferbd168&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

46. Highlights & Remarks
• Regarding the IoT monitoring with blockchain technology:
• Why blockchain at the first place?
• What should be recorded on the ledger and why?
• Should we have a global ledger or community-based ledger?
• Is smart contracts expression-rich to cover any legal clauses and terms?
• How about the dynamic changes in terms of requirements ( sustainability)?
• What best blockchain architecture and alternatives we should adopt?
• Is blockchain really scalable enough to handle IoT massive interactions?
• Either a unified SLAs formulation or an approach to deal with this
heterogeneity?
• How to scale blockchains Without sacrificing the decentralization and
security?
46

47. Conclusion
• The need to address scalability of blockchain.
• The solution should be incentive free.
• Smart contract can model governance rules.
• A fail-safe mechanism should be introduced into smart contracts.
• In our case, there is no need for strict PoW/PoS.
• Fog/edge computing should be essential to any introduced solution.
• We need stress the significance of decentralized computation.
• Instead of validating every single transaction, We could only validate
channels among things.
• HyperLedger Fabric sounds promising.
47

48. References
• Cisco, “The Internet of Things Reference Model,” 2014.
• P. Brody and V. Pureswaran, ‘‘Device democracy: Saving the future of the Internet of Things,’’ IBM Institute for Business Value, Tech. Rep., Sep. 2014.
• L. GARCÉS-ERICE, E. W. BIERSACK, K. W. ROSS, P. A. FELBER, and G. URVOY-KELLER, “HIERARCHICAL PEER-TO-PEER SYSTEMS,” Parallel Process. Lett., vol. 13, no. 4, pp. 643–657, 2003.
• J. Poon and T. Dryja, “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,” 2016.
• M. Chiang and T. Zhang, “Fog and IoT: An Overview of Research Opportunities,” IEEE Internet Things J., vol. 3, no. 6, pp. 854–864, Dec. 2016.
• T. Labidi, A. Mtibaa, W. Gaaloul, S. Tata, and F. Gargouri, “Cloud SLA Modeling and Monitoring,” in 2017 IEEE International Conference on Services Computing (SCC), 2017, pp. 338–345.
• E. Solaiman, R. Ranjan, P. P. Jayaraman, and K. Mitra, “Monitoring Internet of Things Application Ecosystems for Failure,” IT Prof., vol. 18, no. 5, pp. 8–10, Sep. 2016.
• M. Vukolić, ‘‘The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication,’’ in Proc. IFIP WG 11.4 Workshop Open Res. Prob- lems Netw. Secur. (iNetSec), 2015, pp. 112–125.
• K. Christidis and M. Devetsikiotis, “Blockchains and Smart Contracts for the Internet of Things,” IEEE Access, vol. 4, pp. 2292–2303, 2016.
• Y. Sompolinsky and A. Zohar, “Secure High-Rate Transaction Processing in Bitcoin,” Springer, Berlin, Heidelberg, 2015, pp. 507–527.
• “Ethereum: White Paper.”, https://github.com/ethereum/wiki/wiki/White-Paper.
• GAVIN WOOD, “ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER,” 2014.
• P. B. Veena Pureswaran, Sanjay Panikkar, Sumabala Nair, “Empowering the edge,” IBM Inst. Bus. Value. https://www-935.ibm.com/services/multimedia/GBE03662USEN.pdf
• Lua, Eng Keong, et al. "A survey and comparison of peer-to-peer overlay network schemes." IEEE Communications Surveys & Tutorials 7.2 (2005): 72-93.
• V. P. Sanjay Panikkar, Sumabala Nair, Paul Brody, “ADEPT: An IoT Practitioner Perspective,” IBM Inst. Bus. Value, 2015.
• J. Poon and T. Dryja, “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,” 2016.
• S. Popov, “The Tangle,” 2017.
• https://blog.iota.org/a-primer-on-iota-with-presentation-e0a6eb2cc621
• C. Jentzsch, “Decentralized Autonomous Organization to Automate Governance,” SlockIt, pp. 1–30, 2016.
• A. Brogi and S. Forti, “QoS-aware Deployment of IoT Applications Through the Fog,” IEEE Intfile//campus/home/home2016/b6072750/Desktop/Articles/QoS-aware Deploy. IoT Appl. Through Fog.pdfernet Things J., pp. 1–1, 2017.
• R. Milito, F. Bonomi, R. Milito, P. Natarajan, and J. Zhu, “Big Data and Internet of Things: A Roadmap for Smart Environments,” vol. 546, no. January, 2014.
• M. Alodib, “QoS-Aware approach to monitor violations of SLAs in the IoT,” J. Innov. Digit. Ecosyst., vol. 3, no. 2, pp. 197–207, 2016.
• E. Di Pascale, J. McMenamy, I. Macaluso, and L. Doyle, “Smart Contract SLAs for Dense Small-Cell-as-a-Service,” no. May, pp. 2–4, 2017.
• C. Decker and R. Wattenhofer, “A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels,” in Stabilization, Safety, and Security of Distributed Systems: 17th International Symposium, SSS 2015, Edmonton, AB, Canada, August 18-21, 2015, Proceedings, A.
Pelc and A. A. Schwarzmann, Eds. Cham: Springer International Publishing, 2015, pp. 3–18.
• H. Nakashima and M. Aoyama, “An Automation Method of SLA Contract of Web APIs and Its Platform Basedon Blockchain Concept,” Proc. - 2017 IEEE 1st Int. Conf. Cogn. Comput. ICCC 2017, pp. 32–39, Jun. 2017
48