towards a design philosophy for interoperable smart

85
Towards a design philosophy for interoperable smart contracts to secure IoT communications by Vasileios Siopidis Master thesis in Advanced Computer and Communication Systems ARISTOTLE UNIVERSITY OF THESSALONIKI SCHOOL OF ELECTRICAL AND COMPUTER ENGINEERING Supervisor Professor Dr. Konstantinos Votis Thessaloniki, July 2021

Upload: others

Post on 27-Oct-2021

6 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Towards a design philosophy for interoperable smart

Towards a design philosophy for

interoperable smart contracts to secure

IoT communications

by

Vasileios Siopidis

Master thesis in Advanced Computer and Communication Systems

ARISTOTLE UNIVERSITY OF THESSALONIKI

SCHOOL OF ELECTRICAL AND COMPUTER ENGINEERING

Supervisor Professor Dr. Konstantinos Votis

Thessaloniki, July 2021

Page 2: Towards a design philosophy for interoperable smart

1

Acknowledgments

Firstly, I’d like to express my thanks to my patient and supportive supervisor, Konstantinos V., who

has supported me throughout this research project.

Moreover, from the bottom of my heart I would like to say big thank you Sofia T. for her support,

guidance and overall insights in this field have made this an inspiring experience for me. The

meetings and conversations were vital in inspiring me to think outside the box, from multiple

perspectives to form a comprehensive and objective critique. I am extremely grateful for our

friendly chats and your personal support in my academic and business endeavours.

I would like to express my deep and sincere gratitude to my brothers for their continuous and

unparalleled love, help, patience, encouragement and support. I am grateful to my brothers for

always being there for me as my best friends.

Finally, this thesis is dedicated to my mother's memory for her love, caring and sacrifices for

educating and preparing me for my future. I am forever indebted to my mother for giving me the

opportunities and experiences that have made me who I am. She encouraged me to explore new

directions in life and seek my own destiny. This journey would not have been possible without her

advices, and I dedicate this milestone to her.

Page 3: Towards a design philosophy for interoperable smart

2

Abstract

The aim of this thesis was to be combined the Internet of Things industry with the blockchain

technology in order to secure IoT communications through interoperable smart contracts. On the

one hand, this survey analyzes the challenges of ensuring IoT security. On the other hand,

investigates the blockchain interoperability issues, challenges and existed solutions. Moreover, the

advantages and the disadvantages of the relationship between IoT devices and blockchain

technology are examined. As a consequence of the above, the idea of DAML programming

language as a solution for secured IoT communications and the development of a transferable

application is introduced. This thesis illustrates the consequences and reasons why is needed a new

programming language for distributed applications. Moreover, is described a portable application

in multiple blockchain networks which concerns a weather forecasting application on Hyperledger

Fabric network in which DAML offers a solution to IoT security issues and at the same time offers

an insight into blockchain interoperability. The functionalities of the application that have been

developed, user interactions with the application and the components that are required in order to

be deployed a DAML smart contract on a Hyperledger Fabric network are explained. Furthermore,

have been developed a proof of concept for oracles approach. In a more detailed manner, the

DAML smart contract and its ledger api transfer data from the destination chain (Hyperledger

Fabric) to the origin chain (Hyperledger Sawtooth). In this research was created the need to develop

a mechanism for moveable Smart Contracts. In a more detailed manner, this mechanism assists

transferable smart contracts from one blockchain framework to another. Finally, this proposal

might be addressed in future studies for different IoT applications that have been deployed on

different blockchain networks in order to assist cross-blockchain communications with a secured

manner.

Page 4: Towards a design philosophy for interoperable smart

3

Table of Contents Introduction ................................................................................................................................ 7

1 Introduction to blockchain ................................................................................................... 8

1.1 Understanding a blockchain application ........................................................................ 8

1.1.1 What blockchain is ................................................................................................ 8

1.1.2 Principles of developing a blockchain application .................................................. 9

1.1.3 Blockchain fundamentals ..................................................................................... 10

1.2 Smart contract ............................................................................................................. 11

1.3 Consensus ................................................................................................................... 13

1.3.1 Proof of work (PoW) ........................................................................................... 13

1.3.2 Proof of Stake (PoS) ............................................................................................ 13

1.3.3 Practical Byzantine Fault Tolerance (PBFT) ........................................................ 14

1.4 The three pillars of Blockchain technology ................................................................. 14

1.4.1 Decentralization ................................................................................................... 14

1.4.2 Transparency ....................................................................................................... 15

1.4.3 Immutability ........................................................................................................ 15

1.5 Introduction to blockchain interoperability .................................................................. 16

1.6 Historical timeline of blockchain platforms and interoperable protocols ...................... 17

1.7 Blockchain is a revolutionary technology .................................................................... 21

2 IoT-Interoperability-Blockchain: A survey ......................................................................... 23

2.1 IoT state of the art ....................................................................................................... 23

2.1.1 IoT architecture ................................................................................................... 24

2.1.2 Proposed IoT architecture .................................................................................... 25

2.1.3 Internet of Things (IoT) Communication Protocols .............................................. 26

2.1.4 Privacy Concerns in IOTs .................................................................................... 29

2.2 Interoperability state of the art .................................................................................... 31

2.2.1 Chain Interoperability-use case ............................................................................ 31

2.2.2 Techniques for an interoperable system................................................................ 32

2.2.3 Towards a Design Philosophy for Interoperable Blockchain Systems ................... 33

2.3 Blockchain in Smart environments .............................................................................. 38

2.3.1 Proposed architecture involving blockchain in an IoT system .............................. 38

2.3.2 Blockchain versus Cloud Services........................................................................ 40

Page 5: Towards a design philosophy for interoperable smart

4

2.3.3 Vulnerabilities on a hybrid system ....................................................................... 40

2.4 Related work ............................................................................................................... 41

3 An approach to develop application in multiple blockchain platforms ................................ 46

3.1 Comparative analysis of blockchain frameworks ......................................................... 46

3.1.1 Ethereum ............................................................................................................. 46

3.1.2 Corda ................................................................................................................... 46

3.1.3 Quorum ............................................................................................................... 47

3.1.4 Hyperledger Fabric .............................................................................................. 47

3.1.5 Hyperledger Sawtooth ......................................................................................... 48

3.1.6 Hyperledger Indy ................................................................................................. 48

3.1.7 Hyperledger Iroha ................................................................................................ 48

3.1.8 Hyperledger Burrow ............................................................................................ 49

3.1.9 Hyperledger Besu ................................................................................................ 49

3.2 Opportunities and challenges for an interoperable application ..................................... 49

3.3 The Digital Asset Platform .......................................................................................... 51

3.3.1 The Distributed Ledger in the DA Platform.......................................................... 51

3.3.2 A generic architecture overview ........................................................................... 51

3.3.3 One language for multiple platforms/applications/people ..................................... 52

3.3.4 DAML: A moveable smart contract to many backend .......................................... 52

3.3.5 Smart contracts need a new interoperate programming language .......................... 54

4 Interoperable blockchain solutions .................................................................................... 55

4.1 One portable application in multiple blockchain networks ........................................... 55

4.1.1 Datasets ............................................................................................................... 55

4.1.2 DAML smart contract for smart city .................................................................... 56

4.1.3 Authorization through DAML .............................................................................. 58

4.1.4 Portable functionalities ........................................................................................ 59

4.1.5 DAML on Hyperledger Fabric ............................................................................. 62

4.2 A proof of concept for oracles ..................................................................................... 64

4.2.1 An interoperable application ................................................................................ 64

4.2.2 Architecture for oracles approach ......................................................................... 67

4.3 A proof of concept for moveable Smart Contracts ....................................................... 69

4.3.1 The mechanism for moveable Smart Contracts .................................................... 69

Page 6: Towards a design philosophy for interoperable smart

5

4.3.2 From Hyperledger Fabric to DAML environments ............................................... 72

Conclusion ................................................................................................................................ 76

Future work .............................................................................................................................. 77

References ................................................................................................................................ 78

Page 7: Towards a design philosophy for interoperable smart

6

List of images

Figure 1: A generic architecture overview of DAML application ............................................. 52

Figure 2: DAML Smart contract................................................................................................ 57

Figure 3: DAML parties ............................................................................................................ 58

Figure 4: Dazl application queries data based on date ................................................................ 60

Figure 5: Dazl application invokes weather data ........................................................................ 60

Figure 6: DAML Navigator template info ................................................................................. 61

Figure 7: DAML Navigator contracts ........................................................................................ 61

Figure 8: DAML Navigator template ........................................................................................ 62

Figure 9: DAML on Hyperledger Fabric ................................................................................... 62

Figure 10: DAML on oracles .................................................................................................... 65

Figure 11: Oracles-DAML on Sawtooth .................................................................................... 66

Figure 12 :Oracles-DAML on Fabric ........................................................................................ 67

Figure 13: Architecture for oracles approach ............................................................................. 69

Figure 14: Activity diagram for the mechanism of transferable smart contracts ......................... 71

Figure 15:The output DAML smart contract ............................................................................. 73

Figure 16: The input golang smart contract (part 1) ................................................................... 74

Figure 17: The input golang smart contract (part 2) ................................................................... 75

List of tables

Table 1: A Comparative analysis of BC platforms ..................................................................... 50

Table 2: Functionalities of DAML application .......................................................................... 59

Page 8: Towards a design philosophy for interoperable smart

7

Introduction

This research constitutes a relatively new area which has emerged from the continuous

development of blockchain applications. It is noted that applications are being created on various

platforms and many new platforms are being developed for application development with

blockchain technology. Therefore, it is inevitable that arises the need for cross-chain

communication. This is the field of study that deals with blockchain interoperability.

“An interoperable blockchain architecture is a composition of distinguishable blockchain systems,

each representing a unique distributed data ledger, where atomic transaction execution may span

multiple heterogeneous blockchain systems, and where data recorded in one blockchain are

reachable, verifiable, and referenceable by another possibly foreign transaction in a semantically

compatible manner.” (Hardjono, Lipton, Pentland)

A challenging problem which arises in this domain is the development of a secure architecture in

order to achieve blockchain interoperability as a service solution. This remains an open problem in

the IT area as there is a variety of blockchain platforms where they differ in fundamental things

such as consensus algorithm, storage method and cryptography. However, has received substantial

interest as in addition to the technology industry it also concerns business logic, data ownership

and governance.

As far as we know, no previous research has investigated DAML smart contract as a service for an

interoperable blockchain application. There has been less previous evidence for tangible results on

the proposal for a solution to the problem of blockchain interoperability. DAML has been used in

applications so far to enhance the business logic of the application and not as a proposal to the

discussed problem. However, there are techniques such as relays, oracles, sidechains, notary

schemes and hash-locking, that have been developed to solve this problem. Moreover, some

platforms have developed protocols that offer the ability to have its own blockchain network that

is interoperable with other networks. Ark Ecosystem is a typical example to illuminate this

uncharted area.

Page 9: Towards a design philosophy for interoperable smart

8

1 Introduction to blockchain

1.1 Understanding a blockchain application

Why a technological breakthrough called "blockchain"? Blockchain is literally just a chain of

blocks, but not in the traditional sense of the word. Essentially, the words "block" and "chain" refer

to digital information stored in a public database [1].

1.1.1 What blockchain is

Blockchain blocks consist of digital pieces of information. Specifically, they have three [2] parts:

1. Stores transaction information, for example the date, time or transfer of an amount.

2. Stores information about who is involved in the transactions. Of course, the real name is not

going to be used but the transaction is recorded without identifying information using just a

single digital signature.

3. Identify the blocks. Moreover, each block stores a unique code called a "hash" that separates

it from each other.

It is also noteworthy that a block in blockchain can store a set of information. Depending on the

size of the data, this means that a single block can host several thousand pieces of information.

Finally, if a block is filled with information then the next entries will be placed in a new block and

with this way the resulting blocks will form a chain as the blocks are interdependent [3].

Furthermore, some definitions for understanding blockchain technology.

"An open, distributed ledger that can record transactions between two parties efficiently and in a

verifiable and permanent way". (Marco Iansiti & Karim R. Lakhani)

“The blockchain is an incorruptible digital ledger of economic transactions that can be programmed

to record not just financial transactions but virtually everything of value.” (Don & Alex Tapscott)

“A blockchain originally block chain is a growing list of records, called blocks, that are linked

using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp,

and transaction data (generally represented as a Merkle tree).” (Wikipedia)

Page 10: Towards a design philosophy for interoperable smart

9

As mentioned, when a block stores new data, it is added to the blockchain [4]. The blockchain, as

its name implies, consists of multiple blocks that are interconnected. To add a block to the chain

block, however, the following must happen:

Initially, a transaction must be made. Next, the transaction must be verified. In the real world, someone

in charge of reviewing the new listings would be needed to supervise the transactions. However, with

blockchain, this task is implemented by a computer network. These networks often consist of thousands

of computers spread all over the world. Then this block has to be given a hash. The block also has the

hash of the most recent blockchain added to the blockchain [5].

Therefore, there is an archive of blocks that automatically creates dependency links between the

blocks. Once all of the above is implemented correctly the block can be added to the blockchain.

1.1.2 Principles of developing a blockchain application

How is a blockchain application design to be structured? What factors are affected? What values

does it serve? A blockchain-based application should certainly not be confined to a specific

approach and addressed unilaterally. The goal of a blockchain application should be a rational and

organized mindset to identify possible shortcomings and make suggestions for continuous

improvement. Therefore, a number of factors must be considered before deciding on the model

structure [6].

Philosophy: It aims to develop a theoretically consistent articulation capable of governance.

Through a system of values and beliefs that ensure rational development and the primary

contribution of participants.

Methodology: It deals with the development of theoretical information that provides high-level

guidance on the design, analysis, development and evolution of the governance of a blockchain

application in different systems.

Axiom: It is about exploring emerging principles, concepts and laws that determine the scope

and breadth of knowledge in the field of a blockchain application.

Page 11: Towards a design philosophy for interoperable smart

10

Method: Focuses on developing specific models, technologies, standards, and exploit specified

tools. In essence, it deals with a number of tools and opportunities for research and development

of an appropriate decentralized application.

Implementation: Practical implementation of systems and services provided by blockchain

technology through the development of scientific technologies and methods.

1.1.3 Blockchain fundamentals

Distributed database: Every participant in a blockchain network has access to complete information. A

key principle is that no participant controls the information or data. On the contrary, everyone has the

power to directly validate transaction records without a third part [7].

Peer to peer transmission: In blockchain technology, data transmission occurs directly between

users rather than through a centralized server. Each node saves and shares information with any

other node or even all alternative nodes [2].

Transparency with pseudonymity: Any action taken on the network and associated values is visible

to anyone with access to the system. Each node or user signs digitally from a unique alphanumeric

address. To give some idea of the benefits of this method is that users have the option to remain

anonymous and authenticate their identification by signing in with other users [7].

Irreversibility of records: One of the primary benefits of blockchain technology is that once a

transaction is registered on the blockchain network, the files cannot be corrupted. More

specifically, every record made on the ledger is in some way linked to entries already on the ledger,

so the definition of "chain" also emerges. The key contribution of irreversibility is that provides a

number of algorithms ensure that information is stored in a chronologically prioritized way and

readily available to anyone on the network [7] .

Computational Logic: The existence of a ledger could be thought of as a digital book that could

mean that transactions take on a computational logic. Therefore, users use predefined algorithms

and rules that are required to implement inter-node transactions [2].

Page 12: Towards a design philosophy for interoperable smart

11

1.2 Smart contract

In 1994, Nick Szabo first mentioned the concept of smart contracts. He is a computer scientist, a

cryptologist and a lawyer. Initially, the concept of smart contracts was aimed at secure online

transactions between strangers. In essence, it was intended to secure transactions under certain

conditions to avoid fraud. Next, are some definitions for understanding the definition of smart

contracts:

“These new securities are formed by combining securities (such as bonds) and derivatives (options

and futures) in a wide variety of ways. Very complex term structures for payments can now be

built into standardized contracts and traded with low transaction costs, due to computerized

analysis of these complex term structures." (Nick Szabo, 1994)

“The program runs this code and at some point it automatically validates a condition and it

automatically determines whether the asset should go to one person or back to the other person, or

whether it should be immediately refunded to the person who sent it or some combination thereof.”

(Vitalik Buterin)

“Smart contracts monitor the negotiated conditions and automate payments as soon as these

conditions are met. A smart contract can be considered a syntax that is capable of entering,

executing and enforcing (some or all terms of) an agreement using blockchain technology”

(Lafarre, Van der Elst, 2018)

“A smart contract is a self-enforcing piece of so ware that is managed by a P2P network of

computers. Smart contracts are e cient rights management tools that provide a coordination and

enforcement framework for agreements between network participants, without the need of

traditional legal contracts. They can be used to formalize simple agreements between two parties,

the bylaws of an organization, or to create tokens.” (Shermin Voshmgir, 2019)

“A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the

negotiation or performance of a contract. Smart contracts allow the performance of credible

transactions without third parties. These transactions are trackable and irreversible.” (Wikipedia)

Page 13: Towards a design philosophy for interoperable smart

12

The aim here is to investigate smart contracts which are about the codification of simple contracts

that are executed in cases where specific conditions are met. In addition, there are many platforms

supported by a multitude of companies that support blockchain technology. Each platform provides

the capability of various programming languages already existing or having created a programming

language to implement a smart contract [8].

In recent years technology has been growing rapidly, which has resulted in the modernization of

entrepreneurship. On the one hand, the use of smart contracts in business can reduce the cost of

various activities as bureaucratic slavery often involves a large number of staff.

Blockchain technology combined with the multitude of machine learning algorithms can automate

many different activities needed [9]. In addition, the use of smart contracts can also be introduced in the

industry [10]. Hence, the Internet of things industry is booming and there are sensors that can meet

almost any need [11]. Therefore, a system designed with the right architecture, that is, with a series of

properly positioned sensors and using a proper smart contract can automate the processes and the

immutability that characterizes blockchain-based applications ensures validity information for industry

executives. It is noteworthy that many users with different authorization can participate in the same

application [12]. For example, in an industrial application, suppliers can receive information about their

industry, workers are informed about their work, managers are informed about productivity and

customers receive information about the products they will receive. Finally, smart contracts ensure that

the terms of the contract are continually maintained and that they are validly enforced or avoided in the

event that a participant fails to comply.

On the other hand, there are doubts that any smart contract cannot meet the requirements of any

real-world application [13]. Perhaps, some requirements that can be expressed in a natural language

may not be exactly the same as a programming language. In addition, smart contracts do not refer

to any institutional framework and they are not certain to comply with the laws of each state. On

the contrary, lawyers and notaries are obliged to enforce the laws of each state for the contracts and

contracts they draw up [14]. Of course, that can be expressed in a programming language is clear

and unambiguous while the natural language can create doubts and some terms are unclear [15].

Page 14: Towards a design philosophy for interoperable smart

13

In conclusion, a smart contract should cover all the technical requirements and requirements for

proper operation. It must be in line with the prefectures and institutions of each region. Finally, it

must be financially viable for its continued implementation.

1.3 Consensus

One of the most important elements of blockchain technology is the use of consensus algorithms.

Consensus algorithms are a mechanism that defines the process of evaluating the block's validity by

nodes. Blockchain technology addresses the management of its data through a distributed system [16].

Of course, there is also the possibility of a blockchain platform not just using a consensus algorithm

but more than one, in this case adopting a hybrid model of consensus algorithms [17]. Therefore, it is

understood that the use of consensus algorithms is necessary. The following are the most well-

known consensus algorithms.

1.3.1 Proof of work (PoW)

This is the algorithm used by Bitcoin [18]. The PoW algorithm is simple to understand but requires

very high computational power. Each node is called to compute a hash value, these nodes are called

miners. Once the computations are completed, the values are added to the block and the remaining

miners must validate the block to be added to the chain and save all the remaining nodes in the last

block. It is considered impossible for a malicious node to falsify already registered information as

it has to recalculate all the old activities which requires enormous computing power [19]. In

addition, blocks have an interdependence since the hash of the previous block is required for the

hash of the next. PoW uses SHA-256 for the necessary cryptography [20]. This is not enough as

most miners must have the same intentions as each miner represents a vote to validate the block.

That is, at least 51% of miners must have the same intentions. More specifically, there may be

many blocks in the PoW processed by different participants, but unanimity will lead to maintaining

only one. Finally, the miner who finishes his job faster and correctly receives a monetary reward.

1.3.2 Proof of Stake (PoS)

The PoS algorithm is similar to the PoW algorithm but focuses on financial power rather than

computational power [20]. More specifically, the strongest miners are the ones with the most

currencies and not the ones with the computing power [21]. Indeed, it is also important how long

Page 15: Towards a design philosophy for interoperable smart

14

they maintain their wealth as they must maintain their financial strength for at least 30 days to sign

a block. The more they maintain their wealth over time, the greater their power [19]. It is noteworthy

that each miner can vote more than one block for the correct one. Therefore, increases his chances

of being rewarded.

1.3.3 Practical Byzantine Fault Tolerance (PBFT)

The Practical Byzantine Fault Tolerance algorithm has a completely different mindset from PoW and

PoS. This algorithm focuses on providing a practical Byzantine state replication machine that tolerates

Byzantine faults [22]. Initially, no hash method is used but the nodes must validate the identity of the

node that sent the message and also make sure that the message is not differentiated by the sender.

There is a leader node that receives the message and is asked to send it to the backup nodes to evaluate

the sender's identity as well as the integrity of the message as mentioned above [19]. When the nodes

end up in unity then the block is added to the chain. Finally, to complete the process, at least 2/3

of the nodes must be unanimous [20] .

1.4 The three pillars of Blockchain technology

Blockchain is a breakthrough technological breakthrough as it possesses some of the key attributes

that have made it possible to gain widespread recognition. The pillars of blockchain technology

are:

1. Decentralization

2. Transparency

3. Immutability

1.4.1 Decentralization

Bitcoin could be described as a technological revolution as it shook the established institution of

centralized services. Maybe the idea is too simple. A central entity stores all the data and other

stakeholders need to interact exclusively with that entity to obtain the information they need [23].

A typical example of a central system administrator is the banks. The banks are responsible for

Page 16: Towards a design philosophy for interoperable smart

15

storing all the money and guaranteeing the correctness of the transactions regarding the identity of

the clients and the transfer of the right amounts. In addition, a more recent example is the client-

server model. During the search the client sends a query to the server, who is asked to provide the

relevant information according to the client's query.

It is understood that the central systems have been sufficiently responsive for many years, but they

have many vulnerabilities [24]. Initially, all data is stored in a single location. It therefore makes

them easy targets for possible attacks by cybercriminals. It is reasonable to ask what happens if the

central entity is terminated for any reason. Thoughts are automatically generated that there is no

way to access the information managed by the system. The worst case scenario might be what

happens if this central entity is completely destroyed or overwhelmed and malicious.

Of course, on the other hand would be the question of what would prevail in the replacement of the

central entity by a decentralized philosophy. In a decentralized system information is not stored by

a single entity but all network participants hold information. Typically, in a decentralized network,

if they want to interact with two users, they do not need to be supervised by a third party who has the

role of ruling class [25].

1.4.2 Transparency

Perhaps one of the most interesting but at the same time misunderstood concepts in blockchain

technology is "transparency". There is a debate about whether blockchain provides privacy or

ensures transparency [2]. In blockchain technology, a person's identity is concealed through

sophisticated cryptography and is only represented by his public exposure. Thus, it is understood

that the term transparency has never existed within a financial system.

1.4.3 Immutability

Immutability, in the context of blockchain, means that once something enters the blockchain, it

cannot be violated [24]. Perhaps the following concept may shake the digital world in terms of

security. A typical example is tax evasion. In the business sector, various cases of misappropriation

or alteration of accounting books have been reported.

Page 17: Towards a design philosophy for interoperable smart

16

The reason why blockchain acquires this property is because of the cryptographic hash function.

In more detail, hashing means that an input string of any length is converted to a fixed length

output. In the context of cryptocurrencies such as bitcoin, transactions are taken as input and run

through a hash algorithm, bitcoin uses SHA-256, which gives a constant length output always. In

particular, in the case of SHA-256, no matter how large or small the input is, the output will always

be 256 bits in length. Therefore, the user does not have to deal with input data that could be huge,

as long as the emphasis is on hash.

A cryptographic hash function relates to a specific class of hash functions which has various

properties making it ideal for cryptographic uses. The most important feature is that even if the

slightest change in input occurs, the changes reflected in the hash will be huge.

A key component of blockchain deals with a linked list containing a dataset and a hash index that

indicates the previous block, resulting in the creation of a chain. In more detail, a hash index refers

to the address of the previous block as well as the hash of the data of the previous block. This

interplay makes blockchains so amazingly reliable [2].

More specifically, if one tries to change the data, then due to the hash properties mentioned above,

any change in the data will completely change the hash. This means that any minor changes made

to the block will change the hash stored in the previous block. Therefore, this will change the data

and hash of the even more previous block that will result in the previous block and so on [25]. The

result of all this will be to modify the chain. In conclusion, this is how blockchain technology

achieves immutability.

1.5 Introduction to blockchain interoperability

Blockchain is an innovative technology that is increasingly popular in various sectors voting

systems, IOT applications, supply chain management, banking, healthcare, insurance, etc [26]. It is

noted that applications are being created on various platforms and many new platforms are being

developed for application development with blockchain technology. Therefore, it is inevitable that

there will be a need to communicate transactions on the platforms that support blockchain [27]. The

answer in this area is to be addressed by blockchain interoperability research.

Page 18: Towards a design philosophy for interoperable smart

17

“Interoperability is a characteristic of a product or system, whose interfaces are completely

understood, to work with other products or systems, at present or in the future, in either

implementation or access, without any restrictions.” (Wikipedia)

“An interoperable blockchain architecture is a composition of distinguishable blockchain systems,

each representing a unique distributed data ledger, where atomic transaction execution may span

multiple heterogeneous blockchain systems, and where data recorded in one blockchain are

reachable, verifiable, and referenceable by another possibly foreign transaction in a semantically

compatible manner.” (Hardjono, Lipton, Pentland)

1.6 Historical timeline of blockchain platforms and interoperable protocols

In the aftermath of blockchain, most think of Satoshi Nakamoto as the creator and combine

blockchain technology with bitcoin [18]. The truth is that the blockchain pioneers were Stuart Haber

and W. Scott Stornetta in their work How to Time-Stamp a Digital Document, published in 1991.

Strange though it may sound, the launch kick was made 17 years before Satoshi's mysterious

appearance. Stuart Haber and W. Scott Stornetta had the ultimate goal of introducing a model to

safeguard the timing of digital files [28]. It is recommended to use hash functions to reduce data

volumes and to identify the user. Given that the result of the hash function is unique, it is not

necessary to save the entire document but the result of the function. Additionally, the concept of

digital signature is introduced which is called to accompany the hash value by confirming the time

and date. At this point, the concept of the chain is introduced as the results of the hash functions

also include data from the previous registrations and thus the linking of the files. In fact, their

research also mentions the idea of a consensus protocol as it refers to the ability of other participants

to verify the files. So are a bunch of hassle functions, digital signatures, data chain and consensus

protocol referring us to Bitcoin or downstream blockchain platforms?

In 2008, Satoshi Nakamoto's article titled Bitcoin: A Peer-to-Peer Electronic Cash System came out to

shake the scientific community. This research analyzes an electronic payment system based on a

combination of cryptographic methods. Allowing two interested parties to trade directly with each other

without the need for supervision by a third member. In fact, a solution to the double spending problem

is proposed using the timestamp verification from a set of users who have shared the information. It is

Page 19: Towards a design philosophy for interoperable smart

18

emphasized that the system is secure as sincere nodes have more computing power than any other

cooperating group of nodes that wish to invade and alter the chain. One year later the application was

implemented and the genesis block of Bitcoin was created. It is an application that uses a peer to peer

network with the logic of proof of concern. In more detail, the transactions are distributed to the users

participating in the network and they in turn are required to verify the transaction details, so that in

order for a block to be accepted by the network participants, the miners must prove that their data

is valid. block. The difficulty of this task is adjusted so as to limit the rate at which new blocks can

be created from the grid to every ten minutes. Due to the very low probability of successful

production, this makes it unpredictable which computer on the network will be able to create the

next block. Indeed, for proof of work we could say that a CPU corresponds to a vote. In addition,

each block contains the hash of the previous block, so each block has a chain of blocks that together

contain a large amount of work [29]. Changing a block requires the regeneration of all successors.

In this way, the chain is protected against infringement.

In 2013, Vitalik Buterin announces in his article “A Next Generation Smart Contract &

Decentralized Application Platform” his ideas for implementing a new platform for developing

decentralized applications. Ethereum was born as an open source blockchain platform with

additional features compared to Bitcoin. This is a development that has been a turning point in

Blockchain's history. Buterin expresses Ethereum's differentiation from Bitcoin by introducing the

ability to create smart conracts for users [30]. The purpose of smart contracts is to create a convention

between users to interact beyond the exchange of cryptocurrencies that had been established so far. The

new feature has expanded Ethereum's capabilities as a platform for deploying decentralized

applications. In 2015, the Ethereum genesis block is created. Ethereum has now ceased to be just an

idea thanks to Vitalik Buterin, Gavin Wood and Joseph Lubin, and sets the stage for the development

of decentralized applications [31]. It is clarified that the major advantage of the platform is the

introduction of smart contracts written in solidity language. It is an object-oriented programming

language developed exclusively for this purpose [32].

In December 2015, the Linux Foundation announced the creation of the Hyperledger Project but

the makeup of the governing board was announced on 29 March 2016. It is about a worldwide

project which concerns open source frameworks and tools [33]. Hyperledger has grown rapidly in

the last few years and many organizations are interested about these projects, such as Airbus. Most

Page 20: Towards a design philosophy for interoperable smart

19

importantly, the project is not limited to the creation and management of cryptocurrencies. It

provides a range of independent open protocols and templates through a different framework in

each case. Every framework includes its own blockchains and storage routines, as well as

authentication, access control, and smart contracts. In Hyperledger frameworks smart contract is

called chaincode [34]. Αs mentioned, there are many different projects on the Hyperledger but the

most popular are Sawtooth and Fabric. Sawtooth’s core design allows applications to choose the

transaction rules, permissioning and consensus algorithms that support their unique business needs.

At the end of 2016 Gavin Wood announced the idea of another one project, Polkadot [35]. It is

about a protocol to introduce the community to interoperability technology. At 10 November 2016

released a proof of concept to determine the goals of the project. After all, Polkadot is a

heterogeneous multi-chain technology in which different blockchain platforms are allowed to

exchange information.

In 21 May 2017, ARK blockchain ecosystem [36] launched the mainnet. The key contribution of

this work is the solution it provides public, blockchain-based distributed computing platform

featuring smart bridges functionality. Αpart from the genesis block announced the ARK tokens.

The main advantage of this project is the ARK Smart Bridge in which is used two protocols to

allows data and asset transfer to third parties. On the other hand, does not provide scalability and

secure solutions for member chains. To sum up, Ark is cryptocurrency designed to connect all

blockchains of every cryptocurrency in the world.

In 30 Jan 2018, was released version 1.0.1 of Hyperledger Sawtooth [37]. It is about a project which is

proposed by Intel. It is about a user-friendly platform and offers many different options because its

design allows admins to choose the transaction rules, permissioning, and consensus algorithms that

support their unique business needs. However, Sawtooth platform has a unique characteristic from the

other blockchain platforms. The Sawtooth-Ethereum integration project, Seth. It is important to note

that Seth is not a complete Ethereum implementation. Seth extends the interoperability of the Sawtooth

platform to Ethereum. Moreover, Seth is to make it easy to port existing EVM smart contracts and

DApps that depend on them to Sawtooth.

Page 21: Towards a design philosophy for interoperable smart

20

In the second quarter of 2018, announced the idea of the multichain platform of the Block Collider

[38]. The aim of this project is to contribute to interoperability of the different blockchain platforms.

It is about is a high-speed distributed ledger built on sets of blocks from other blockchains. Block

Collider is dedicated to the idea of Nakamoto’s consensus approach, Proof of Distance. It is

noteworthy that aggregate block of chains faster than the fastest member chain.

In January of 2019, was released the first long-term-support version of Hyperledger Fabric [39]. It is

about a project which is proposed by IBM. The concept of Hyperledger Fabric concerns applications

or solutions with a modular architecture. It is about a distributed operating system for permissioned

blockchains applications. The chaincodes could be written in a variety of programming languages, like

Go, Java, Node.js. The most important in Hyperledger Fabric is that separates transaction execution

from consensus and enables policy-based endorsement.

Ιn 2019, Polkadot’s Genesis block will be launched. The consensus algorithm is used from this

protocol to achieve his goals is a hybrid consensus. Hybrid consensus is a beneficial way to produce

new blocks and also having a universal agreement on the canonical chain. One unique approach to

solve the interoperability problem involves the use of parachains. This is about a protocol in which

is used the name from the concept of parallelized chains that run parallel to the relay chain. Due to

their parallel nature, they are able to parallelize transaction processing and achieve scalability of

the Polkadot system.

In 13 March 2019, Cosmos [40] launched the network for first time. However, the idea announced

6 April 2017. The idea of this project is similar to the Polkadot. Cosmos is an ecosystem built on a

set of modular, adaptable and interchangeable tools. Cosmos allows multiple parallel blockchains

to interoperate while retaining their security properties. The consensus protocol which is used

called Tendermint. It is about a simple distributed protocol and his benefit is that is a partially

synchronous with Byzantine Fault Tolerance algorithm.

In 4 April 2019, Digital Asset announced the open source programming language DAML [41]. One

of the key benefits of the language is that focuses on the smart contracts. It is about an innovative

programming language used to digitize multi-party agreements and automate transactions. It is

noteworthy that DAML add a security layer where such information is only accessible to authorized

Page 22: Towards a design philosophy for interoperable smart

21

parties. Finally, DAML is human friendly because the smart contract is automated executed from

the engine and readable from the people also.

1.7 Blockchain is a revolutionary technology

In modern history, the first theories of decentralized government were supported by Marx's position on

the form of the state and the establishment of a peaceful, disorderly society without a state, with the

ultimate aim of bringing about justice [42]. Then, the most ardent supporter of Marxist theory was

Lenin, who left his mark as a revolutionary and a strategic mind but also a great scientist and thinker.

It provided radical answers, which still have an impact today, on key issues of the modern era.

Continuation of the work and theories of Marx and Lenin is called upon by blockchain technology.

Essentially, this is an anti-government political thought in which society could be self-governed by

a series of social contract contracts [43].

In countries like Greece, perhaps all of the above seem stranger or paradox to each other as the

prevailing mentality is patriarchal and structured with a strict hierarchy. The Greek society

ostracizes and refuses to take away from its morals the slavery and deny the favor of the powerful.

The years of enslavement and successive wars have left their mark and the class struggle is reflected

in modern day life. Finally, it is understood that blockchain technology is contradictory and does

not find suitable ground in Greek society as it is intertwined with capitalist theory and favors the

imposition and prosperity of the ruling class.

Does the state concern an oppressive factor? Is it the source of the necessary evil? Does it create a

sense of coercion? Does it enhance individual thinking? Does it endorse the strict hierarchy? Are

citizens dominating themselves? Do they feel equal? Do they want conscious and responsible

behavior?

According to Marx, the state cannot be abolished from one moment to another, but if its sovereignty

declines then society will be forced to restructure. "The State is the executive committee of the

ruling class" (Marx, 1984). The unintended consequence of these circumstances will be that the

majority of the population goes hand in hand with the new way of managing with maturity and

responsibility. “Without a revolutionary theory there cannot be a revolutionary movement”

(Lenin).

Page 23: Towards a design philosophy for interoperable smart

22

It is clear that blockchain technology is at first glance contradictory and ideologically innovative.

Its application and social process could shake the world like Marx's theories and Lenin's attempts

to get rid of them. For Marxism, of course, the collapse of the state is the natural consequence of

the disruption of capitalism. "While the State exists there can be no freedom; when there is freedom

there will be no State." (Lenin, 1917) On the other hand, the staunch supporters of blockchain argue

that it rather represents the victory of the free market and its own interests over public institutions,

in a process of economic liberalization that can best be defined as a combination of theories,

anarcho-capitalism [44].

Page 24: Towards a design philosophy for interoperable smart

23

2 IoT-Interoperability-Blockchain: A survey

2.1 IoT state of the art

In modern times, there is a view that a new world war can begin not for wealth but for the

acquisition and exploitation of information. Of course, human beings are as natural as the

environment they live in everyday as economics, industry, and society are not just an idea but their

structure derives from objects or otherwise. In addition, the development of technology is rapid

and computers, as well as the internet, have become established in people's lives and contribute to

improving society and the business sector. Remarkable is the fact that the introduction of "things"

in the control of electrical and electronic equipment began in the early 1990s, but failed to be

introduced and developed in all societies [45]. The Internet of Things offers users the ability to

manage both electronic and electrical equipment using the Internet. However, one of the major

challenges of the Internet of Things is to bridge the gap between the natural world and the

information world. Nowadays, the majority of communications are implemented between

computers as the internet and countless sensors exist provide the user with information reducing

human interactions. The sensors have the capability of collecting real raw physical data in real time

and converting it into a comprehensible machine format so that it can be easily switched between

different "Things". Finally, here are some definitions for a better understanding of the Internet of

Things.

“Today computers—and, therefore, the Internet—are almost wholly dependent on human beings

for information. Nearly all of the roughly 50 petabytes (a petabyte is 1,024 terabytes) of data

available on the Internet were first captured and created by human beings—by typing, pressing a

record button, taking a digital picture or scanning a bar code. Conventional diagrams of the Internet

include servers and routers and so on, but they leave out the most numerous and important routers

of all: people. The problem is, people have limited time, attention and accuracy all of which means

they are not very good at capturing data about things in the real world” (Kevin Ashton, 1999)

"In the next century, planet earth will don an electronic skin. It will use the Internet as a scaffold

to support and transmit its sensations. This skin is already being stitched together. It consists of

millions of embedded electronic measuring devices: thermostats, pressure gauges, pollution

detectors, cameras, microphones, glucose sensors, EKGs, electroencephalographs. These will

Page 25: Towards a design philosophy for interoperable smart

24

probe and monitor cities and endangered species, the atmosphere, our ships, highways and fleets

of trucks, our conversations, our bodies--even our dreams." (Neil Gross, 1999)

"A new dimension has been added to the world of information and communication technologies

(ICTs): from anytime, any place connectivity for anyone, we will now have connectivity for

anything. Connections will multiply and create an entirely new dynamic network of networks – an

Internet of Things" (International Telecommunications Union, 2005)

“Internet of Things can be realized in three paradigms—internet-oriented (middleware), things

oriented (sensors) and semantic-oriented (knowledge). Although this type of delineation is required

due to the interdisciplinary nature of the subject, the usefulness of IoT can be unleashed only in an

application domain where the three paradigms intersect.” (Atzori, 2010)

“The Internet of Things (IoT) is a system of interrelated computing devices, mechanical and digital

machines, objects, animals or people that are provided with unique identifiers (UIDs) and the

ability to transfer data over a network without requiring human-to-human or human-to-computer

interaction.” (Wikipedia)

2.1.1 IoT architecture

The concept of IoT may be too broad and cannot be covered precisely. Now, almost all people have

easy access to the internet and the use of smart devices is constantly increasing. Therefore, it is

understood that the Internet of Things with its applications is established in the daily life of man.

On the one hand, the introduction of a standard architecture sets some horizons for common

acceptance, easier development and acceptance by all. On the other hand, future extensions and

possible vulnerabilities that may arise should be offset. Each architecture can vary depending on

the needs of the application. Of course, every architecture has to cover the following areas [46]:

Distributivity: A key feature of Internet of Things is the existence of a distributed environment. In

most applications, the data that it manages requires that it be collected from different sources, for

example sensors scattered around the area of interest, in order to be collected and processed.

Interoperability: The concept of interoperability in IoT deals with the utilization of information

gathering by devices that need to work together to achieve the goal. In addition, appropriate

communication systems and protocols must be defined in order to exchange information in a

distributed environment.

Page 26: Towards a design philosophy for interoperable smart

25

Scalability: In the course of time, billions of objects are expected to be part of the network.

Therefore, existing IoT applications will be faced with managing an uncontrolled volume of data.

Resources scarcity: The scarcity of energy has been plaguing society for a long time, and with the

introduction of smart devices it is becoming clear that the issue of energy consumption is being

addressed. Also, as data volumes increase, the computational power requirements fluctuate.

Security: From a user perspective, summarizing the concepts of distributed environment,

interoperability, and upgrading an application to a web-based framework, security for IoT

prosperity should be ensured.

2.1.2 Proposed IoT architecture

2.1.2.1 Perception Layer

The perception layer is called upon to understand the physical properties of things involved in an

integrated application. This process focuses on communication protocols and how to detect devices

that are required to transfer data [46]. The perception layer is intended to convert information into

digital signals. The development of nanotechnology contributes to the smooth operation of the

perception layer as some objects may not be immediately perceptible but with the attachment of

microchips improves detection and signal processing capabilities. In conclusion, the perception

layer concerns the management of 2D labels, RFID tags and readers and in general all the sensors

that the application may contain [47]. In the light of the perception layer, it deals with identifying

devices and then gathering information.

2.1.2.2 Transport Layer or Network Layer

This layer includes the valid transmission of data resulting from the perception layer. The

information must be transmitted to the processing center via a wireless or wired network or even

from a local area network [46]. Broadcast modes concern all possible communication protocols that

can be used in an IoT application such as Bluetooth, Zigbee [48]. Thus, the main function of the

transport layer. Understanding the development of IoT applications, it is understood that there is

an innumerable volume of things that require multiple networks for successful data transfer [49].

Therefore, we conclude that the transport layer or network layer is crucial for the communication

of all participants through the networks.

Page 27: Towards a design philosophy for interoperable smart

26

2.1.2.3 Processing Layer or Middleware layer

This layer stores, analyzes and processes large data from a transport layer or network layer. This

is a key layer that is overlooked in many IoT architectures [48]. Of course, one has to understand

the continuous download of big data and the number of devices involved, as it affects the processing

and storage. This layer deals with a wide range of services in the next layers. More specifically, it

involves the use of technologies such as databases, cloud computing etc [49].

2.1.2.4 Application Layer

This layer deals with the processing of data from the processing layer or middleware layer and is

then called upon to develop various applications of the Internet of Things [47]. In more detail, the

application layer aims to forward all the information from the previous layers to the user. The IoT

sector aims to develop smart applications. For example, a smart application may be about managing

a home, a transportation system, a city, a health system [46].

2.1.2.5 Business Layer

This is the last and highest layer of architecture. Basically, it's about managing the whole IoT

system [48]. It manages all the applications that may exist and defines all the business requirements

that the model requires. Remarkable is the fact that the success of a technology stands out from the

logic and innovations it can implement. In the meantime, this layer manages the privacy of end

users and ensures their security [49].

2.1.3 Internet of Things (IoT) Communication Protocols

2.1.3.1 Radio Frequency Identification (RFID)

Radio Frequency Identification is a technology based on the use of wireless sensors to detect radio

frequencies for the purpose of identifying objects or even humans. The essentials for a smooth

operation are 3 [50]. Initially, an antenna or coil of the correct range is required. Next, the

transponders often referred to as RFID tags are needed. Basically, these are microchips with

memory so they can store information. Finally, transceiver with decoder is required for smooth

operation. Transceivers are responsible for retrieving information. That is, the antenna

communicates with the transceiver and the decoder ensures that the message is read.

2.1.3.2 RFID tags

RFID tags include consist of an integrated circuit and an antenna. The integrated circuit consists

of the microprocessor, memory and an antenna. It is the antenna that will determine the reading

range of the label. In fact, RFID tags are divided into two categories according to data storage

Page 28: Towards a design philosophy for interoperable smart

27

capability. The categories that distinguish them relate to reading information and reading /

recording information [51]. The first category is for read-only labels and does not have data storage

capacity. Of course, they only have a unique pre-registered ID to communicate with a database.

Therefore, this provides them with information about the object that is associated with that label.

Next, RFID tags can be categorized as active and passive [51]. Passive tags depend on the

electromagnetic field created by the RFID reader to be activated. Unlike active batteries that have

built-in batteries. In this way, the range is increased, since the electromagnetic field does not affect

the tags for their activation as the labels do not depend on the electromagnetic field strength to be

activated.

2.1.3.3 RFID readers

RFID readers deal with devices that communicate wirelessly with tags to identify the connected

item that may be associated with each tag and its corresponding data. The tag and the reader to be

able to communicate must be based on the same standard [51]. More specifically, if a tag concerns

an improvised template, then the reader must support the same communication protocol to achieve

communication.

2.1.3.4 Near Filed Communication (NFC)

It is a method of short-range wireless technology implemented over a few centimeters [52]. NFC

technology works in a messy environment, no visual contact is required and the connection is

simple enough. NFC uses similar technology principles in RFID. However, it is noteworthy that it

is used not only for identification but also for two-way communication. It has a label that may

contain a relatively small amount of data [52]. This label may be read or modified later.

2.1.3.5 6LoWPAN

IPv6 over Low ‐ power Wireless Personal Area Network 3 is used to closely interoperate existing

web and smart objects, determining how IPv6 packets will be transmitted over an IEEE 802.15.4

network. 6LoWPAN acts as a layer between the IP layer and the connection layer that compresses

the IP headers and performs fragmentation when necessary [53]. The maximum transmission unit

(MTU) of 802.15.4 is 127 bytes. If 802.15.4 is enabled, the maximum payload is reduced to 81

bytes, 40 of which will be consumed with uncompressed IPv6 headers. By compressing the IPv6

header, 6LoWPAN increases the load being transferred to 802.15.4 frames [52]. When data cannot

Page 29: Towards a design philosophy for interoperable smart

28

fit into a single frame, 6LoWPAN performs the hash [53]. All nodes in a 6LoWPAN network

perform compression / decompression and fragmentation / reassembly.

2.1.3.6 Bluetooth

BLE is a technology designed to reduce energy costs, discover and identify a device for the purpose

of data exchange. Its operating range is 10-100 meters and communication error is too low [55]. In

addition, the adjustment and recognition time is very short but also allows for many different nodes

to be involved in the communication. Of course, as the number of participating devices increases,

so does the response time. In order to clarify the situation, one must understand the mode of

operation. Passive devices send periodic short messages, while passive scans receive the message

according to the scan rules but do not respond [54].

2.1.3.7 ZigBee

The ZigBee application ensures high level communication with the use of radio frequencies. These

are small radios with extremely low power consumption and low cost. It features a very low data

rate and has a large battery [56]. It is applicable to many IoT applications as low power consumption

and strong battery allow data monitoring and control. The transmission range is from 10 to 100

meters [56].

2.1.3.8 SigFox

It is a protocol that uses radio frequencies with a very wide object-free signal, called "Ultra

Narrowband" [52]. The main feature is the consumption of very low energy, called LPWAN.

SigFox is widely used in wireless sensor or machine-to-machine communication networks. The

data transfer contains packets of very small quantities, while the communication range is up to 50

kilometers [52].

2.1.3.9 Cellular

A cellular network or a mobile network is a communication network for wireless communications.

An important feature is the distribution of the network in areas called "cells" [52]. Each cell each

ensures its communication with a transceiver. It thus ensures the connection to GSM / 3G / 4G

networks, where it takes advantage of high speed internet [52]. On the other hand, high power

consumption is required. It is understood that the cellular communication protocol is suitable for

applications involving mobile devices.

Page 30: Towards a design philosophy for interoperable smart

29

2.1.4 Privacy Concerns in IOTs

With the widespread acceptance and development of the Internet of Things industry, both at the

program and device level, new vulnerabilities and threats have been created. New vulnerabilities

arise from the design and implementation of programs and applications and threats from intruders.

The key factors responsible for the new security issues can be divided into two main categories,

based on the different security issues that each one addresses. The first is about the diversity of the

devices and the second is about the communication between them. As for the first, security issues

mainly come from careless programmatic design, which results in the program being vulnerable to

possible malware (back door installation, etc.). Also given the multitude of devices and the

diversity among them, the new security problems are more complex than the problems encountered

so far. Regarding the second category, again due to the diversity of the devices we expect variations

in the means of communication between the devices as well as different data structures. Different

media will face different security problems, which will often jeopardize device availability. Also,

different data structures and communication protocols will make content protection more complex.

2.1.4.1 Privacy in Device

For an IoT application that typically operates in a distributed environment and gathers information

from many different devices, securing data is a key issue. Usually devices in IoT applications are

small and because of their limited size they are unable to ensure their security and the information

they collect and send. There are many solutions, but they are due to different. It is understood that

the devices that collect and send data, so they are called upon to have a breach resistance. To

safeguard device privacy, many privacy issues are addressed, such as the device's hidden location,

protection of identifying the exact nature of the device, protection of personal information in the

event of theft. The Multi-Routing Random walk algorithm ensures the secure location on the WSN

is achieved by using it on wireless sensors in case of privacy of the screen and protection of

personally identifiable information (PII) in the event of loss of device, achieved by using the QR

Code [Quick Response Code] technique. In the case of unrecognizable behavior and side-channel

attacks that add random or noise, having synchronized CPUs, blind values used in the calculations

could be used [57].

2.1.4.2 Communication Security

The most common way to ensure smart devices communicate when transferring data is to use

cryptography. In this way, the data packets acquire an identity or a way of detection, for example

Page 31: Towards a design philosophy for interoperable smart

30

sequence number, IPsec-SecurityParameterIndex, etc. Therefore, it is necessary to establish a

secure communication protocol according to the requirements of the application, so that during

communication the data will not be found by an unauthorized user. Additionally, communication

uses aliases for both users and devices, where it is desirable to be encrypted in order not to reduce

communication vulnerabilities. The most common technique for encrypting aliases is Temporary

Mobile Subscriber Identity (TMSI). It is worth noting that when there is no need for communication

then the devices should not communicate. Of course, in 3GPP type communications, the devices

are prudent to disconnect from the network after some time to avoid unnecessary information

gathering. Of course, in environments where there is continuous traffic, such as railroad cars,

airplanes, boats, IoT devices can move fast enough, making it difficult to locate [57].

2.1.4.3 Data Integrity

It is noteworthy that most IoT research focuses on privacy. In any application, integrity is the most

crucial issue and outweighs availability or even privacy. For example, altering the integrity of data

in a medical application can cause further health problems or cost one's life. The most common

technique for ensuring security is the use of public key infrastructure (PKI) and Keyless Signature

Infrastructure (KSI), where they operate in a complementary way. KSIs are also used for data

security and have complementary roles. PKI is used to transfer data to authenticate. On the other

hand, KSI is used to demonstrate integrity. In conclusion, it is worth noting that data storage should

be done consciously as the amount of data in an IoT application can reach a huge point [57].

2.1.4.4 Privacy Processing

The management and storage of personal data must be done responsibly and in a way that is

intended for an essential purpose. In addition, personal data must not be disclosed to third parties

with express consent. With this in mind, Digital Rights Management (DRM) is a solution that

controls and defends illegal redistribution. This is an important tool as privacy policies can be set.

Of course, reliable and secure devices are needed to operate efficiently and efficiently. More

specifically, the user's permission is required both for the distribution of personal data and in case

of data leakage the user receives a notification [57].

Page 32: Towards a design philosophy for interoperable smart

31

2.2 Interoperability state of the art

Blockchain technology is an achievement that has been developed in recent years. It has been

studied for many aspects and the scientific community is trying to take advantage of the benefits

of blockchain by using it in different applications. The concept of interoperability in a blockchain

application is a field that is intensively studied and an important area of research. In order to

implement an interoperable blockchain application one must understand the possible application

cases, existing techniques and system philosophy.

2.2.1 Chain Interoperability-use case

2.2.1.1 Atomic swaps

Atomic swaps [58] is a cross-chain communication protocol that is often encountered in

decentralized applications. Initially, it allows for coordination between the parties to exchange

relevant information while participating in different blockchain platforms. Its operating principles

are based on the compliance of all parties and compliance with the protocol so that transactions

can be carried out. Of course, in the event that one deviates, the transaction cycle cannot be

implemented. The remarkable thing about atomic swaps is that all transactions are executed

simultaneously on all the blockchain platforms that are involved.

2.2.1.2 Asset portability

Asset portability [59] addresses the interoperability of a blockchain system from a different

perspective. It deals with the transfer of the user's own tokens without interacting with another user

on a different blockchain. In essence, the transfer relates to the user's own data simply on a different

platform and the reverse path is also possible. In fact, they are not subject to any time constraint.

2.2.1.3 Asset encumbrance

Asset encumbrance [59] could be likened to a 'lock'. In more detail, it gives the ability to lock assets

from one blockchain and unlock them to another if necessary. For example, an asset can be locked

in blockchain A if there are conditions that require it in the activities of blockchain B. Implementing

such a need is found in court orders, banks, bankruptcies, etc. [60].

2.2.1.4 Cross-chain oracles

In a cross-chain system [59], it is understood that the data in the blockchain is derived from another

blockchain. For example, Oracle monitors the activities performed on a blockchain when executing

a smart contract and locates the reference of a unique address of a different blockchain [60].

Page 33: Towards a design philosophy for interoperable smart

32

2.2.1.5 Cross-chain contracts

In an interoperable blockchain system where the interaction of chains is required under certain

conditions it is wise to use cross-chain contracts [59]. To better understand, let's say one asset

belongs to many owners and a smart contract is executed that sets out the payment to the owners,

who are on a different blockchain than the smart contract was executed [58]. Then, a cross-chain

contract is required to locate the owners and give them the appropriate price.

2.2.2 Techniques for an interoperable system

2.2.2.1 Notary Schemes

The use of notary schemes [61] is a simple technique to achieve the interoperability of a cross-chain

system. This is a relatively simple method where changes in the underlying blockchains are not

implemented, but there is a need for a trusted entity to ensure successful communication between

the two blockchains. However, the question arises as to when the notary can be trusted. Of course,

it is worth noting that there is no need to have only one entity but there may be more than one.

Finally, there may be more than one notary in the system that can meet the needs of the system

without compromising confidence. A consensus algorithm could be adopted by the participating

notaries so that the solvency of the majority could be guaranteed.

2.2.2.2 Sidechains

Sidechains [62] in the concept of interoperability are used to monitor the status of the main

blockchains with the transactions being implemented. One notable fact is that the transfer of data

from one blockchain platform to another does not raise any issues of confidentiality and data

tampering as strong cryptography is already being used and data corruption will result in the

transaction being rejected.

2.2.2.3 Pegged sidechains

Pegged sidechains [59] are a special category of side chains. Essentially, pegged sidechains focus

on securing the data in the blockchain that is sent, creating proof that they are encrypted.

Subsequently, the proof generated by the pegged sidechain will be transferred and verified by

sidechains. By extension, it is possible for a blockchain header to be received from another

blockchain and verified through a consensus algorithm.

Page 34: Towards a design philosophy for interoperable smart

33

2.2.2.4 Relays

Another method for achieving interoperability in a blockchain system is to use relays [59]. Using

relays does not require a mediator to communicate with blockchains but communicate directly with

each other. A prerequisite for using relays is that blockchain technology uses block headers. Using

cryptography in the block header secures the data contained in the block and at the same time

acquires a unique identity. Essentially, the relay validates the block header finalization and is then

able to verify any transaction as the structure used in blockchain technology is tree-based.

2.2.2.5 Hash-locking

Hash-locking [62] is a technique for achieving individual cross chains. Its mode of operation

involves activating one action at a time on two blockchains. The energy is delivered directly

between the blockchains and there is no need for an intermediate. In addition, Hash-locking is a

technique widely used in decentralized systems. In this way it also works on blockchain

interoperability as it is something like a binding or link between blockchains. The following

explanation makes it understandable:

Initially, at least two different parties are required on two different blockchains. Party A belongs

to one blockchain and Party B to another blockchain.

1. Party A creates a secret s and after computing hash h (s) sends it to party B belonging to another

blockchain.

2. Both A and B keep their assets in a separate smart contract as long as the following rules are

followed.

3. Party A must transfer s to B within a time frame of 2 * X seconds. If it fails, s is sent back to A.

For its part, B must transfer s to A within X seconds, otherwise it is sent back to B.

4. Party A reveals s in X seconds to be notified to B and to claim it.

2.2.3 Towards a Design Philosophy for Interoperable Blockchain Systems

2.2.3.1 Survivability of an interoperable system

One of the most important terms for the interoperability of a blockchain system is the definition of

survivability [63]. The survival term for blockchain systems could be understood by the success of

a blockchain application to securely complete a transaction either on a blockchain platform or in

more than one.

Page 35: Towards a design philosophy for interoperable smart

34

One unanswered question about blockchain technology is the tolerance in an attack. Blockchain

is based on the use of the Internet, so partial Internet attacks also employ blockchain technology.

Of course, blockchain is based on the utilization of the distributed network, so the main problem is

the attacks on the network nodes and how the nodes work according to the consensus algorithm.

Reliability in a blockchain application deals with the effort to complete a transaction in a reasonable

amount of time. Of course, it is worth noting that a transaction may require the completion and

confirmation of many individual transactions. In more detail, in a blockchain application the

individual transactions can be implemented on different platforms but the interest of the users is to

focus on the resulting transaction.

A better understanding of the challenges of survival would help to study a case. Initially, a

blockchain application aims to capture data in the ledger. This study overlooks the difference

between the two major categories of permissionless/permissioned. It is worth noting which

blockchain does not record the data as the transactions that have been executed will be found, used

and verified later by a different blockchain.

In more detail, we have to assume that there is an original blockchain system that accepts data from

the application. The original blockchain system records the data to the ledger and confirms

successful registration. If the data is not successfully registered to the ledger after a predetermined

time frame, then the data is transferred to a different blockchain system to be registered to its own

ledger. This process is repeated until they are successfully registered in a blockchain system.

Therefore, the concept of survivability is understood in this case by following the process of

entering a transaction into the ledger and confirmation by all nodes. In conclusion, the most

important thing is to register the transaction regardless of which blockchain system will be

implemented.

2.2.3.2 Service types

An important element to consider for interoperable blockchain systems are the factors that can

affect the trading process. Initially, the number of nodes in a blockchain system can affect its

operating speed. This also has an impact on the speed of transaction confirmation. Then, another

key factor affecting the interoperability of a blockchain system is the directions that transactions

follow. That is, if only one application is involved or the request-response procedure needs to be

implemented in order to transfer the information to third parties. In an application where no post-

Page 36: Towards a design philosophy for interoperable smart

35

response response is required, the transaction is characterized as uni-directional. On the other hand,

in an application where the entry requires a user's response, then the transaction is called bi-

directional. Finally, the most important issue of an interoperable blockchain system is the

consensus algorithm. The questions to be answered relate to immediate access at any time to the

information registered in the ledger, the number of nodes associated with the information, and their

proper authorization [63].

2.2.3.3 Variety of blockchain systems

Therefore, the factors to be considered regarding Variety of blockchain systems are 3 [63]. Initially,

the minimum assumption to be put into an interoperable blockchain system relates to the flow,

processing and understanding of transactions from more than one blockchain system.

The two major categories of blockchain platforms are unauthorized / unauthorized, which defines

the authorization and interaction of users with the system. However, interoperability on

permissioned platforms raises doubts about how data will be recorded on the ledger and how users

of another blockchain platform will access it. Finally, anonymity is a feature of blockchain

technology that is defined as an advantage, but for the concept of interoperability it may be a

disadvantage. Anonymity in blockchain technology can affect both the users and the nodes

processing the transactions. It is understood that different combinations of anonymity can be

created in one system.

The concept of interoperability would be prudent to allow the user to choose on which platform he

wants to keep his data but also to be able to transfer his data to another platform at any time. In

addition, with the discovery of a new blockchain platform, users who want it should be able to

transfer their data to the new platform if they feel that its capabilities are superior to others [64].

2.2.3.4 Cross- Blockchain reachability

When transferring information from chain to chain, the information must remain unchanged or the

cryptocurrencies must be correctly matched. A key factor in an interoperable blockchain

application is the synchronization of all blockchain systems to properly handle and manage

transactions. In such an application, of course, the cost of doing so must be considered. Finally, the

operation of blockchain is based on a number of cryptographic systems. However, each platform

has its own cryptographic systems and a different way of managing digital signatures. Therefore,

Page 37: Towards a design philosophy for interoperable smart

36

a blockchain interoperable application also raises the question of managing digital signatures that

will result from different blockchain platforms [64].

The issue of routing between systems deals with packet routing from the point of entry to the

correct destination. Proper communication between applications is crucial to the proper operation

and interception of information. The information routes are implemented by the gateway routers,

where they send the information exclusively to parts of the system. Local hosts receive the

information through portals. A series of algorithms and tools implements the traffic exchange

agreement to disseminate information to third parties [63].

2.2.3.5 Cross-Blockchain interconnecting Values

From the outset, the architecture of the internet split the message into smaller packets, and the

information was transmitted by sending packets from different packets until it reached the recipient.

The internet is also used on blockchain platforms.

Inter-Ledger Protocol (ILP) refers to a transport protocol that transmits the message from the

sender to a blockchain platform through a series of feeds. Perhaps the Inter-Ledger Protocol (ILP)

may be similar to the Reservation Protocol (RSVP), where the two-way path is bound by the sender

and the recipient. In order to achieve this goal, the inputs and outputs of the connections of each

router are kept with respect to the paths it implements from the sender to the recipient.

Remarkable for interoperability is the fact that in the ILP protocol the sender and the recipient can

be on different blockchain systems. At the application level, the ILP protocol architecture uses a

value as a link between two blockchain systems. Requires a currency conversion function to

convert from one currency to another. To better understand the protocol it could be likened to the

operation of a currency exchange where the person wants to change one currency to another and

the store must have enough stocks to give the right proportions to the individual concerned.

Important in this protocol is to avoid overloading. Overload occurs by blocking all possible paths.

In case of overload the link can reject requests as long as routes and free resources are available

[63].

2.2.3.6 Transferable Smart Contracts

One of the innovations that blockchain has introduced in the field of technology is the use of smart

contracts. Smart contracts are a type of contract that enables the nodes of the blockchain platform

to perform certain processes programmatically. The problem that arises is the possibility of nodes

Page 38: Towards a design philosophy for interoperable smart

37

being attacked and essentially inactivating the system. The concept of interoperability raises the

question of "moving" the smart contract from one platform to another without compromising its

functionality. Subsequently, the application must be able to identify on which blockchain platform

the smart contract has been executed. Another emerging research question concerns the timeframes

for transferring the smart contract to the new blockchain platform. Response time is crucial as in a

blockchain interoperable application, too many of the platforms are likely to be implemented, so

the question of modern or asynchronous communication for smart contract data verification arises

[63].

2.2.3.7 Cryptographic Survivability

When transferring information from chain to chain, the information must remain unchanged or the

cryptocurrencies must be correctly matched. A key factor in an interoperable blockchain

application is the synchronization of all blockchain systems to properly handle and manage

transactions. In such an application, of course, the cost of doing so must be considered. Finally, the

operation of blockchain is based on a number of cryptographic systems. However, each platform

has its own cryptographic systems and a different way of managing digital signatures. Therefore,

a blockchain interoperable application also raises the question of managing digital signatures that

will result from different blockchain platforms [64].

A key element of blockchain technology is cryptography. Most blockchain platforms typically use

multiple cryptographic systems. However, the security of the cryptographic systems is not lifelong

as one cannot guarantee that there will be no intrusion in the future. In more detail, symmetric

cryptographic algorithms, such as DES, AES etc., have been used safely for several years and offer

a secure process. However, the disadvantages of cryptography are encountered in asymmetric

cryptographic algorithms, such as RSA, which require the extension of the key length, such as

NIST SP 800-175B [63].

2.2.3.8 Security in multi-chain ecosystem

Security is an issue that concerns every application created as it must protect both personal data

and the information it deals with. In particular, in a blockchain application where data transmission

is implemented between cross-chains. Usually, data comes from an original chain and is destined

for another chain or even more than one. It is therefore understood that some safeguards must be

taken. The necessary measures that a cross-chain system must meet are: [65]

Page 39: Towards a design philosophy for interoperable smart

38

• The nodes registering the transaction in the source chain must be selected at random.

• The solvency of the data during the transfer must be ensured by digital signature.

• The data chain must be capable of receiving the data and registering it in its own ledger.

2.3 Blockchain in Smart environments

The use of smart devices is increasing rapidly. On the one hand, it contributes to the management

of autonomous systems and the collection of information. On the other hand, system security

vulnerabilities arise mainly in identifying devices, in securely transporting and securing data. Some

questions may arise, how can an IoT application architecture contribute? What are the reasons for

using blockchain? Enhances system security;

2.3.1 Proposed architecture involving blockchain in an IoT system

2.3.1.1 IoT Layer

The Internet of Things implements the connectivity of many devices over the Internet for the

purpose of continually collecting and processing information. First, IoT sublayers should be

studied. “Sublayer Things” includes many smart devices that can be used as sources of information,

such as smartphones, smart watches, sensors, air conditions etc. Then, the “sublayer Data

Acquisition” should detect all the smart devices that will send information such as images, videos

etc. Next, “sublayer Fog Networking” aims at successfully connecting all smart devices and

securely transferring information. “Sublayer Data Aggregation” refers to the communication of the

system, that is the use of protocols for the edge networking capabilities. In more detail, the device

communication portals are defined. In “sublayer Data” centralization, infrastructure is networked.

Subsequently, “sublayer Data Analytics and Storage” uses the appropriate methods so that the data

is formatted properly so that it can be processed and can be stored. Finally, the “sublayer interface”

provides a user-friendly and understandable presentation of the data [66].

The Internet of Things implements the connectivity of many devices over the Internet for the

purpose of continually collecting and processing information. In particular, the sensing layer must

detect all smart devices that send the information. Next, the network layer aims at successfully

connecting all smart devices and securely transferring information. The service layer uses

appropriate methods so that the data is formatted properly so that it can be processed. Finally, the

interface layer gives a user-friendly presentation of the data [67].

Page 40: Towards a design philosophy for interoperable smart

39

2.3.1.2 Service Layer

Separate from the IoT service layer, the entire application service layer should be studied. The

application's service layer is derived from the Service-oriented architecture (SOA) that provides a

general framework for application components based on a communication protocol. In such an

application, the service layer is called upon to achieve interoperability by implementing all the

necessary protocols and APIs. Of course, in an IoT application, cloud infrastructures or the use of

the internet cannot be omitted. The purpose of all of the above is to implement a range of services

for easier interaction. Finally, it should be mentioned that the possible services will be selected

based on the Quality of Service of the application to satisfy the necessary requirements [67].

2.3.1.3 Workflow Modeling Layer

Workflow Modeling Layer may be the most important layer in an application. It concerns the

modeling of the structure of business processes according to the necessary requirements. In

particular, the system processes are defined for autonomous systems that may exist and specify

how they operate or terminate in an undesirable situation [67].

2.3.1.4 Blockchain Layer

Blockchain technology designed to deliver distributed functionality can provide data transfer

security to any layer of an IoT application related to workflow modeling. It is understood that

blockchain omits the existence of a central authority so that it is necessary to properly plan

collaborative processes as communication takes place between unknown services. The biggest

advantage of blockchain technology is the implementation of smart contracts that allow many

services with specific rights to participate and all services to be coordinated accordingly. Lastly,

smart contracts offer automation as they can be activated under specific conditions and respond

automatically as well [67].

In particular, blockchain technology can increase security for IoT sublayers and reduce system

vulnerabilities. In more detail, at "Device-level", "Site-level", "Gateway-level", "Analytics /

storage-level" and "End-to-end" where interconnecting a large number of smart devices, data

acquisition and the proper communication of all layers hierarchically can ensure device

identification, appropriate authorization of the device concerned, data being transferred securely,

stored in a way that ensures their immutability and easy access. All of this is achieved thanks to

the cryptography systems used in blockchain technology, the management of cryptographic keys,

strict authentication and user rights, the interdependence of data entry, and the democratic approach

Page 41: Towards a design philosophy for interoperable smart

40

of validating transactions with consensus algorithms. Finally, it is a flexible technology as smart

contracts can be used for any use case, such as managing a health system, smart city, transportation

system, etc. [66].

2.3.2 Blockchain versus Cloud Services

Beyond the theoretical level, it is worth analyzing blockchain technology and cloud services in

realistic environment. The survey [68], compares the cost of computing and storage for both

technologies. The Ethereum platform has been chosen to be studied as blockchain technology while

the Amazon SWF as a cloud infrastructure. It should be noted that two different architectures are

being studied. There are 256 transactions on the Ethereum platform, with each transaction costing

0.032 Ether or $ 0.36, corresponding to the date of the rates on 26/8/2016. On the other hand, are

implemented in Amazon SWF 1000 process instances in one day at a total cost of $ 0.925.

Comparing the two implementations makes it clear that the cost of blockchain is much higher than

the cloud. However, it is worth noting that the data is stored on the blockchain while the platform

is still running and has not been withdrawn from the market. On the other hand, SWF provides 90

days data retention capability.

In summary, it is currently accepted that the introduction of blockchain into the architecture of an

application is increasing the cost. This study demonstrates that an Ethereum transaction costs $

0.36 compared to Amazon SWF the cost of a process instance is $ 0.001. However, the study

addresses only one case in a business model and it would be good not to generalize the conclusion.

In addition, cost is an important factor for entrepreneurship but for the design of an architecture it

is a non-functional factor. By reducing data entry and utilizing the absolutely necessary

information, it can be understood that cost can be reduced. Finally, blockchain is a recent

technological breakthrough compared to cloud services, so it may be logical for the time being to

be more expensive. Like all goods, technology implies the laws of “supply and demand”.

2.3.3 Vulnerabilities on a hybrid system

2.3.3.1 DoS/DDoS attack on IoT system

In October 2016, perhaps the largest DDoS attack took place. The company that controls much of

the Internet's DNS infrastructure, Dyn, has been the victim of the attack. As a result, platforms such

as Twitter, Netflix, Reddit, etc. were hit. The attack was carried out by botnets of an IoT system.

Mirai malicious software infiltrates computers and then forces them to scan part of the internet to

Page 42: Towards a design philosophy for interoperable smart

41

find vulnerable devices such as security cameras, digital cameras, home appliances, smoke

detectors, etc. If connected to smart devices, it forces them to operate as “zombie” in the impending

DDos attack [69].

2.3.3.2 Dos/DDoS attack on public-private blockchains

An important fact in private blockchain is that the number of nodes involved in the network are

known and are several hundred in number so that attackers can identify the bandwidth. In addition,

the PBFT consensus algorithm used mainly in private blockchain can be subject to a DDoS attack

if malicious users acquire 33% of the network nodes. Therefore, if the necessary percentage of

nodes is overrun, the system will collapse and transactions will not be possible. In conclusion, the

system will be attacked by DDoS as it cannot cope [70].

In public blockchains, such as Bitcoin, there are more than 10,000 nodes, and more can be

constantly added, so it is understood that malicious users cannot know the multitude of nodes. In

particular, to gain control of the network more than 50% of the nodes must be captured. Therefore,

it is obvious that malicious users have to spend a lot of money to launch a DDoS attack in order to

attack the network [70].

2.3.3.3 Defence against DoS/DDoS attacks using blockchain

In an IoT application where many smart devices are involved, it is important to manage resources

to avoid overloading. In such cases, the way the data can be transmitted can be set, either allowing

all devices to send information together or having a hierarchy in the transmission mode. In this

study, the Ethereum platform is used to set a gas threshold so that transactions cannot be executed

if the gas threshold is exceeded. Contributing to this deal is the smart contract that controls the gas

limits and is not executed when the limits are exceeded to avoid overloading the system.

Specifically, when a DoS / DDoS attack occurs on the system malicious devices will consume their

corresponding gas until they run out. This will stop malicious devices and counteract DoS / DDoS

attack [71].

2.4 Related work

This article [72] addresses the safe implementation of interoperable smart contracts in a health

application. The issues that bother with such an application are data access, data management and

proper storage. The health sector is a highly profitable sector but at the same time it must safeguard

privacy. It is understood that data validity is a key factor for an application as there may be many

Page 43: Towards a design philosophy for interoperable smart

42

malicious users who wish to access or alter the data. Therefore, interoperability is called upon to

ensure the smooth operation of a health application that requires the introduction of the Internet of

things to import and transmit sensitive information. For this implementation, it is suggested to use

a public blockchain network for patient data access, while for all other users the structure of a

private blockchain network is proposed. In fact, the concept of interoperability has to be met by

the automatic execution of smart contracts. In more detail, calling a smart contract can

automatically execute another smart contract whether it is in the public or private blockchain, to

carry out the necessary process. It is emphasized that a key factor in an interoperable blockchain

application is the use of the consensus algorithm, as different blockchain platforms adopt separate

consensus algorithms. This implementation is based on Ethereum using the Proof of Work

algorithm. This approach suggests registering the patient's request for access to his medical record.

The vendor then processes the request and is required through the smart contract to automatically

upload the file to a local database. In more detail, in the first stage a smart contract is required to

identify the patient's request. In a second step, another smart contract is required to send an

encrypted message containing the link to the file. In the last step, a transaction is called that will

give access to the file. The role of the private blockchain is the most important in this

implementation. More specific, the supplier will manage the request to create a new patient medical

record and execute a transaction on the private blockchain for registration. Therefore, it is

understood that in order to access his medical history, the patient must use both his signature and

the hash value of the file and after receiving the patient's user interface will receive the appropriate

message. Five smart contracts have been used to run the application smoothly, three of which are

executed on the private blockchain, while the other two are executed on the public blockchain. The

first smart contract to run is called Enroller. The purpose of the Enroller is to transmit encrypted

data from the private to the public blockchain. The second smart contract that is executed is called

File Linker Contract. This smart contract has the obligation to cross check if the user is referring

to the correct folder according to the hash value they enter. Next, the Request Validator smart

contract is executed on the public blockchain and its use is to confirm the identity of the user who

has made a request. In the next step, the private blockchain runs Verify Request Contract, which

aims to enhance application security. Accepts the signature and hash value of the file as input. Its

function is to evaluate the data of previous smart contracts. In case of successful execution, it refers

to the latest smart contract located on the public blockchain otherwise the execution is interrupted.

Page 44: Towards a design philosophy for interoperable smart

43

In the final stage, the Notifier Smart Contract is executed where it notifies through the patient

interface of the request it has made. The message that arrives is obvious to everyone, but only the

patient with the right privacy can decrypt the message and gain access to the link. In conclusion,

this study does not support a hybrid architecture but uses a public blockchain, a private blockchain,

and a local database for the safe operation of the interoperable application

This publication [73] analyzes the development of an interoperable blockchain application called

EduCTX. It uses the open-source Ark blockchain platform to achieve interoperability. The purpose

of the application is easy access to training certificates. More specifically, it aims to store and

provide services related to the curriculum that each student has attended, the detailed course grades,

the ECTS concentration, the acquisition of diplomas, etc., irrespective of the university the student

has graduated from. In addition, it aims to constantly update data and record changes. Of course, it

is not only beneficial for students but also for universities as they can access validated and unaltered

data. Regarding bureaucracy, it will help reduce it, as it will not be necessary for passwords and

usernames for every employee working at the university and not for students. Also, no printed

certificates will be required and it will be easier for everyone to complete the procedures required

for a job or master's degree. For better understanding we need to delve into how EduCTX works.

In particular, every Higher Education Institution is able to join the network as long as it creates its

own node system. For the purpose of registering transactions and creating blocks, it is

recommended to use the Delegated Proof-of-Stake Consensus (DPoS) consensus algorithm, in

order to make the HEIs' space available to distinguish continuously operating institutions on the

platform. On the other hand, students register with HEI to obtain their public and private key.

Specifically, a 2-2 multisignature blockchain address is used for both the EI public key and the

student public key. The transaction process is accomplished using the student's address, so it is

clear that there is complete transparency and anonymity for the students. The same procedure

applies if an employer or another organization wants to receive the documents. That is, the student

must send his blockchain address and through the 2-2 multisignature address to show the validity

of the data. In conclusion, it turns out that blockchain applications as well as interoperable

blockchain applications are not only suitable for cryptocurrency but can also be used in other fields.

The use of DPoS brings a more democratic perspective compared to PoW and PoS algorithms. The

use of the APK blockchain platform offers flexibility as it supports 12 different programming

languages and is permissionless which means it offers the ability to participate as anyone wishes.

Page 45: Towards a design philosophy for interoperable smart

44

This article discusses [74] the development of an interoperable blockchain application using the

Transwarp-Conduit (TWC) protocol. The purpose of the Transwarp-Conduit Protocol (TWC) is to

increase the flexibility of deploying applications involving more than one blockchain platform. Its

successful operation is based on three principles. Initially, the concept of Time Locks (Hash

Locking) is analyzed, that is, a hash value is required for the time signaling corresponding to the

transfer between the two chains. Next, the concept of Relaying is defined, which requires the

smooth operation of different consensus algorithms as each platform has its own approach to

consensus algorithms. Therefore, there is a concern about performance and data management as

the operation of a blockchain platform is directly affected by the consensus algorithm it uses.

Finally, the role of the Notary Schemes on the issue of trust is affected. In more detail, it is

explained that the issue of trust must be secured by each platform separately as the other

communicating platforms can simply assume rather than evaluate validity. The successful

operation of the Transwarp-Conduit (TWC) protocol is based on the implementation of four

components. The first essential element is the creation of an interoperable smart contract. The

purpose of an interoperable smart contract in this protocol is to create a transaction on the platform.

The Adapter Contract is then required to send the smart contract to the right nodes for validation.

Essentially, it's the interface of the application. TWC Bridge Node offers interoperability between

blockchain platforms. Bridges control the state of the chains of each blockchain platform.

Additionally, bridges are required to handle all requests generated in the application. They accept

the information of each blockchain platform and create a serial queue for the data transfer.

Consequently, it is necessary to manage digital signatures in order for the information to be sent to

the correct chain. Finally, they confirm that the data has been correctly sent to the correct

destination. In the next step, as in any application, digital signatures must be used to confirm the

transfer. Their digital signatures of the TWC protocol are used to register requests, to validate the

transaction and finally to confirm the transfer. Based on the above, it is understood that the data

present at the nodes of the participating blockchain platforms must be the same as those of the

TWC protocol. This article states that the failures of an interoperable application are related to the

vulnerabilities of each platform separately, the failure to connect to the Internet as it is a necessary

factor for the proper functioning of the blockchain. To sum up, TWC is a protocol that deals with

the transmission of messages between blockchain platforms. As with any blockchain technology,

TWC protocols can contain malicious users who want to transmit incorrect messages, but the use

Page 46: Towards a design philosophy for interoperable smart

45

of bridges provides another safeguard as it is possible to detect malicious users and reorganize

them.

This survey [75] examines the management of robots and the sending of data using blockchain

technology. In autonomous systems, the reception and processing of information is extremely

important as it leads to conclusions that guide the robot. Especially in an environment like an

industry it can lead to catastrophic errors in production and even endanger people's lives.In

particular, open source software Black Block Recorder used for robots is used as middleware.

ROS2 is used for secure networking while modularROSBag2 is used to power all robots. To

support blockchain technology, the Hyperledger Sawtooth platform uses the BFT algorithm that is

characterized for its energy efficiency. Additionally, Digital Asset Modeling Language (DAML)

is used to implement the smart contract. The purpose of the application is to execute multiple

transactions at the same time. The model is based on the proposed Hyperledger Sawtooth supply

chain model. It adopts the advantages of provenance, tracing and other information about the

chronological order of the assets. Important for the smooth operation of the system is the creation

of the smart contract in the Daml programming language which adds a rational mode of operation

and rigorous authorization to users. The first template shows the parties as signatories and then the

data is transferred to a second template where the data is checked. At this point the owner has the

choice to finalize or reject the transaction. It is understood that, in a decentralized environment,

options can be created and subordinated smart contracts and finally registered in an unchanged

manner. However, doubts are raised about implementing a smart contract in Daml programming

language and implementing it in Sawtooth as it is a new programming language and its

vulnerabilities are unknown since it has not been implemented in many different cases with

different requirements. Finally, the combination of the above tools and platforms ensures robots

are managed in a decentralized environment and data entry is immutable to ensure system security.

Page 47: Towards a design philosophy for interoperable smart

46

3 An approach to develop application in multiple

blockchain platforms

3.1 Comparative analysis of blockchain frameworks

Although blockchain is a technology that has been recently explored, many platforms have been

developed that support this technology. Each platform has its own advantages and disadvantages

that favors the development of applications according to the required features. Frameworks

obviously apply the fundamental principles of blockchain technology but as discussed below there

are noticeable differences in the architecture, the consensus algorithm, the provided tools, and the

supported programming languages.

3.1.1 Ethereum

Ethereum is a distributed public blockchain network. Ethereum platform works quite similar to

bitcoin. It is used a Proof of work consensus algorithm to be determined the longest chain in which

is used sequential single signature blocks according the weighted importance from the miners.

Miner is called each node with the appropriate computing power that solves those math problems

with the aim to verify Ether transactions. Miners receive rewards in Ether for successfully

completing a proof of work task. To be executed successfully a smart contract on Ethereum

platform is required to consume gas. The gas is referred to the fee or pricing value. The price of

the gas is set from the miners and they can decline to process a transaction if it does not meet their

price threshold. Finally, for a user to be allowed to interact with smart contracts on the Ethereum

network is necessary to have a wallet. There are many different types of wallets such as smart

contract wallets, hardware wallets, phone and other mobile device-based wallets, desktop wallets

and web wallets. Finally, Solidity is the programming language of Ethereum for blockchain

applications. [76]

3.1.2 Corda

Corda is an open-source blockchain platform. On corda network there is no need to be verified the

transactions from all the nodes. So, the consensus is achieved on transaction level, instead of ledger

level as Ethereum. In addition, there is no specified consensus algorithm that can be used but there

is variety like BFT, Raft and many others. Ιt is noteworthy that the involved parties receive directly

the individual transactions and there is no entity that maintains the entire history of all the

transactions. However, the current state is known to the notaries while they act as validators of the

Page 48: Towards a design philosophy for interoperable smart

47

transactions. A transaction is digitally signed from the notary, but is a prerequisite that any of the

same inputs has not been previously signed by the Notary, and the transaction timestamp is within

the permitted limits. In conclusion, Corda network transmits responsibilities between the parties

and works according with the terms of the underlying agreement. There is no need of trust between

the members just a reliable organization which runs the notary. [77]

3.1.3 Quorum

Quorum is an enterprise blockchain platform which has been developed from ethereum client to

empower businesses to embrace and benefit from distributed applications. Compared to Ethereum,

Quorum provides privacy and permissioned network. Ιnstead of using Proof-of-Work like

Ethereum, consensus is achieved with different consensus mechanisms such as RAFT which is a

Crash Fault Tolerant (CFT) consensus model or Istanbul BFT Consensus which is a Byzantine

Fault Tolerant (BFT) algorithm. Moreover, smart contracts are written in the solidity language.[78]

3.1.4 Hyperledger Fabric

An important feature of the Fabric framework is that the ledger is managed by peers where there

are 2 basic categories. A validating peer is a node in the network that is responsible for the

execution and validation of transactions. In addition, they keep a copy of the legder as they also

participate in the consensus process. Peers that simply validate transactions on the network but do

not execute transactions are called non-validating peers. Is a node that acts as a proxy to connect

clients to validating peers.

Another feature of the Fabric is that are created channels. For each channel that is created there is

a separate ledger where its data are accessible only to the members who participate in the specific

channel and thus the privacy of the channel is obtained. However, it presupposes trust between the

peers. Concluding, the Fabric platform is permissioned as it should the participants are known to

each other. [79]

Smart contracts are called chaincodes in the Fabric framework. In more detail, the chaincodes in a

Fabric network can be written in many different programming languages. However, it is impossible

to have direct access to the ledger state. Ιt should be mentioned that many chaincodes can be run

in a Fabric network simultaneously and can be deployed dynamically. In addition, there is a variety

of database management systems that can be used for a Fabric ledger. Finally, the ordering service

Page 49: Towards a design philosophy for interoperable smart

48

depends from the needs of each application that aimed to be developed. The platform currently

offers a range of tools and algorithms that support CFT (crash fault-tolerant) consensus. [80]

3.1.5 Hyperledger Sawtooth

Hyperledger Sawtooth is developed as an open source modern enterprise platform for business

supply chain. Τhe biggest advantage of Sawtooth platform is that executes transactions in parallel.

The integrity of the batch is ensured from the validator’s transaction processor. Aftewards, the

transactions is commited to the ledger. There is a variety of consensus algorithms that can be used

such as PoET, PoET-Simulator, RAFT and Dev_mode. Multiple languages are supported from

transaction processor SDK that can be used from programmers to interact with the Sawtooth

blockchain platform. These languages are Python, JavaScript, Go, C++, Java, and Rust. Finally, is

provided a REST API which contributes to validator communication with standard HTTP/JSON

format.[81]

3.1.6 Hyperledger Indy

Hyperledger Indy is another one blockchain project powered by the Linux Foundation. It is about

a private distributed ledger that are provided a variety of tools, libraries, and reusable components

for contributing on the management of digital identities rooted on blockchains or other distributed

ledgers. The ledger is based on the Merkle tree, so all the nodes have replicas. The consensus

algorithm that is used on Indy platform is called Plenum which is about an improved version of

Redundant Byzantine Fault Tolerance (RBFT). The state of the Indy network is quite similar to

Ethereum, it concerns a combination of Merkle Tree and Radix Tree. In addition, is offered an

implementation with of value/key database with leveldb or ordered mapping. Some benefits about

users of Hyperledger Indy is that the information on the ledger is visible to everyone but is

encrypted, every user has access to his/her data, with the consent of the user another member can

have access to a certain information and is allowed to have password-less authenticating process.

[82]

3.1.7 Hyperledger Iroha

Hyperledger Iroha is an open source blockchain platform that focuses on the creation of mobile

applications. Iroha applications are permission-based while is used Crash fault-tolerant consensus

which is called Yet Another Consensus (YAC). It is about a system that is used to manage digital

assets, identity, and serialized data. Iroha network is benefited compared to other frameworks

Page 50: Towards a design philosophy for interoperable smart

49

while has a powerful licensing system, are allowed to set permissions for all commands, queries

and joining of the network. In addition, concerning the smart contract complexity and risk are

reduced by using the built-in commands. Finally, the supported client libraries for an Iroha

application can be found on programming languages such as Java JS and Python. [83]

3.1.8 Hyperledger Burrow

Hyperledger Burrow a Distributed ledger software in which are operated permissioned smart

contracts. Burrow supports EVM and WASM based smart contracts. In addition, acts as a node in

the Ethereum network while EVM executes Ethereum smart contracts. Finally, Burrow ledger is

working with Byzantine Fault Tolerant consensus that uses Tendermint consensus. In order to work

securelly the application is essential to do not fail more than 2/3 of the machines. Tendermint is

working like a voting system for the process of committed blocks [84]. More specific, the

participants are called validators who are voting the proposed blocks of transactions. Thus, is

created a chain of blocks. There are 2 stages for a successful commit which are called pre-vote and

pre-commit. Finally, when more than 2/3 of validators pre-commit for the same block in the same

round then the block is commited. In order to make progress is relied on timing assumptions based

on real time network speed instead of system parameters.[85]

3.1.9 Hyperledger Besu

Hyperledger Besu is an open source blockchain platform. Besu can be run on the Ethereum public

network or on private permissioned networks while it is about an Ethereum client developed under

the Apache 2.0 license. There are several consortium environment including Ethash which is Proof

of Work consensus algorithm and Clique, IBFT 2.0 and Quorum which are Proof of Authority

consensus algorithms. In addition, RocksDB key-value database is used to persist chain data

locally. Finally, the deployment and execution of smart contracts within an Ethereum network are

allowed with the Ethereum Virtual Machine (EVM). [86]

3.2 Opportunities and challenges for an interoperable application

The biggest advantage of blockchain is the security and the validation of transactions. In order to

achieve cross-platform communication between different blockchain platforms, the architecture

and the way it operates must be studied [87]. Initially, a key function of a blockchain application is

Page 51: Towards a design philosophy for interoperable smart

50

to properly send and manage tokens from one participant to another. An important problem that

arises in such cases is the synchronization of transactions as new blocks are constantly being

created and the information situation is likely to change. Then perhaps the biggest innovation that

blockchain applications have adopted is the use of smart contracts. Of course, there is no common

programming language for writing smart contracts. Therefore, perhaps transferring a smart contract

from one platform to another may not make it executable in its full operation. Finally, there are a

number of variations on the consensus algorithms, time and method of transaction confirmation,

data management, block size, hash process and more generally the architecture adopted by the

platform. To sum up, all of the variations mentioned in the structure of each platform and the

different way a blockchain application is deployed raises questions about the success of

interoperable blockchain applications.

Observing and understanding even more detailed and thoroughly that above mentioned, it becomes

clear that is not allowed diverse blockchain systems to communicate with each other and make

cross-chain transactions seamlessly. More specifically, table 1 provides a comparative analysis of

the variety of blockchain platform features and some of the reasons that security issues may arise

in a blockchain interoperable application.

Ethereum Corda Quorum Fabric Sawtooth Indy Iroha Besu Burrow

Status Active Active Active Active Active Active Active Active Incubation

Consensus PoW

(Ethash),

PoS

(Casper)

Supporti

ng

various

Consens

us

algorith

ms

Istanbul

BFT, CFT

(RAFT)

SOLO,

KAFKA ,

SBFT

PoET,

PoET

simulator,

dev mode,

RAFT

RBFT

(plenum)

BFT

(YAC)

PoW

(Ethash),

PoA

(Clique ),

IBFT 2.0

PoS

Types of

Consensus

Mining

based

App

Depende

nt

Voting

Based

App

Dependent

Lottery

Based,

or

Voting

based

Voting

Based

Voting

Based

Mining

Based

or

Voting

Based

Voting

Based

Cryptograph

y

ECDSA SHA256 SHA3-512 ECDSA

SHA256

SECP256K

1 ECSA

ED25519 ED25519

SHA512

SECP256K

1

ALTBN128

ED25519

SHA512

Smart

Contract

Funcionality

Yes Yes No Yes Yes No No Yes Yes

Ledger Type Per/less Per/ned Per/ned Per/less

Per/ned

Per/ned Per/ned Per/ned Per/less

Per/ned

Per/ned

Programmin

g Languages

for Smart

Contracts

Solidity Kotlin,

Java

- Go,

Java,

Javascript,

DAML

Python,

JavaScript,

Go, C++,

Java, Rust,

DAML

- - Solidity,

DAML

Solidity

Table 1: A Comparative analysis of BC platforms

Page 52: Towards a design philosophy for interoperable smart

51

3.3 The Digital Asset Platform

3.3.1 The Distributed Ledger in the DA Platform

The Distributed Ledger in the DA Platform is a permissioned ledger in which only the pre-approved

parties have the right to read and write in the ledgers in contrast to permissionless ledger, like

Ethereum. The Global Synchronization Log (“GSL”) and the Private Contract Store (“PCS”) are

the main components [88].

3.3.1.1 Private Contract Store

All validated contracts in which the participant is a party are contained to the private contract store.

Moreover, emphasis should be given in the fact that all the executable active and inactive smart

contract are contained in the private contract store. However, is insufficient to construct a segment

of the ledger without corresponding proofs in the GSL[88].

3.3.1.2 Global Synchronization Log

Τhe necessary integrity and auditability are provided from the Global Synchronization Log. Ιn

more detail, it is about a communication layer responsible to ensure the integrity of transaction

commitments and notifications. Finally, is established the demanded set of valid transactions that

are correlated to the private contract data in the PCS [88].

3.3.1.3 DAML Execution Engine(“DAMLe”)

Each participant on the network has his independent DAMLe in which has the ability to re-execute

and verify the contracts. In this way, is ensured that there is a kind of unanimity that the results of

a command are pursuant with the results of any other DAMLe held by a participant who is

performing or validating the same choice [88].

3.3.2 A generic architecture overview

Τhe architecture of a DAML ledger can be backed by a distributed ledger or just a database. The

image 1 clarifies a general architecture that can be applied to a ledger. In more detail, the DAML

Ledger API servers is denoted as ‘DALM on X server ‘which concerns the provided services by

the ‘Participant node of X network’. In this architecture, the transaction validation process is

denoted as ‘DAML X validator’ in which is provide the ability for nodes to validate DAML

transactions. However, this is not a universal need as it matters in which network the application is

running. More specifically, if the nodes need to validate transactions, how will it happen and at

what stage depends on the application's ledger.

Page 53: Towards a design philosophy for interoperable smart

52

Figure 1: A generic architecture overview of DAML application

3.3.3 One language for multiple platforms/applications/people

DAML [89] is an open source programming language created for distributed ledgers. Its important

features are the clarity in the structure of the smart contract that gives a rational application in real

time, that is, the rights, obligations and parameters needed to execute a transaction can be defined.

In addition, it is a programming language that is obviously understandable by machines but also

readable by the user.

“We have business analysts at our clients who maybe are not technical enough to write DAML

code, but they can definitely read DAML code, so the iterations in building new functionality are

very quick.”( Digital Asset CTO Shaul Kfir)

3.3.4 DAML: A moveable smart contract to many backend

A DAML smart contract that is created for an application for a blockchain network can be

transferred to another blockchain network or even to a database without compromising any

functionality. More specifically, the rules that have been established, the obligations, the

prohibitions and the rights of each participant are applied even in the new environment where the

smart contract will be implemented [90]. In fact, nothing is required to change programmatically to

transfer the smart contract. It is an important advantage that without knowing the programming

languages that required for each framework but learning only DAML or even without being

blockchain developer can lay the groundwork for applications in different blockchain networks or

databases. Another benefit of DAML is that can be used in any backend and does not requires a

specific consensus algorithm. In more detail, the runtime runs outside of the ledger and from the

one side of DAML Code and to the other JSON APIs serve the application to communicate to a

specific ledger and understand the desire state. As a result, it is not required to be understood the

way of how each platform stores, adds and retrieves data [91].

Page 54: Towards a design philosophy for interoperable smart

53

3.3.4.1 DAML enables private transactions

Compared to other programming languages, DAML has a unique feature. DAML has the ability to

identify which parties are authorized to trade and access information. The information is then

transferred to the appropriate blockchain system and the data ends up in the appropriate nodes of

the network so that only authorized users can access it. Finally, it is noteworthy that the history of

transactions, both active smart contracts and archived, can be obtained [91].

3.3.4.2 DAML: A scalable and interoperable tool

DAML offers the opportunity to write an application for the ledger API in other languages [91]:

Java bindings: are achieved by RxJava-based Ledger API client application, a library for

synthesizing asynchronous programs and event-based programs using observable sequences for

Java VM. It provides a custom way to register Ledger DAML applications

Scala bindings: is also a client application of the API Ledger. Is a library that allows applications

that are linked to digital asset allocation software using the Scala programming language.

Node.js bindings: provides the opportunity to interact with a DAML application through the

Node.js platform software applications.

gRPC: there is another option to write an application for the API in other languages using general-

purpose Remote Procedure Calls (gRPC).

Python bindings: this is not the official bindings yet, but is an alternative way to access Ledger

API-based applications. To achieve python bindings it is necessary to import dazl library [92].

3.3.4.3 Supported DAML ledgers and environments

It is not enough to simply create a smart contract in DAML. It must be applied to a ledger or

environment, however, it can be applied to more than one ledger or environment at the same time.

The compatible blockchain frameworks to date are Hyperledger Fabric, Hyperledger Sawtooth,

Corda, Amazon QLDB, VMware Blockchain, Hyperledger Besu and Ethereum [93]. In addition,

DAML is not only compatible with ledgers but also with cloud services such as MySQL and

PostgreSQL databases. Finally, another very important tool is the Canton Interoperability Protocol.

It is about extending and synchronizing an application with other ledgers without requiring

centralized management or global in-network consent.

Page 55: Towards a design philosophy for interoperable smart

54

3.3.5 Smart contracts need a new interoperate programming language

As blockchain technology becomes more and more popular with the scientific community and

blockchain applications are increasing, it is understood that requirements and flexibility are

growing at the same time. Some reasons for choosing DAML:

It is open source

Is a language of ledgers

One common language for many different blockchain frameworks/databases

Can be used in various architectures

Applies the same API to a variety of blockchain platforms

Moveable smart contracts

It is not specified to work with a specified consensus algorithm

Can be used with the same method to different backend

Create a true global network of networks

Enables private transactions

Adds business logic with the enforced rules

Specifies permissions according to the actions of the smart contract

Simplifies the specification of the signatory/signatories of each contract and who is allowed to see

the action

All the rule and the permissions can be applied to other platforms

Readable from humans and machines

Easy to build and integrate a smart contract

Page 56: Towards a design philosophy for interoperable smart

55

4 Interoperable blockchain solutions

4.1 One portable application in multiple blockchain networks

In this section, is examined the creation of an interoperable application and the actual transfer of

the entire application from the Fabric network to another blockchain network. In fact, it is about

transferring exactly the same smart contract but also exactly the same user interaction functions.

This is achieved with the Daml smart contract and the dazl library which concerns python bindings

for accessing Ledger API-based applications.

Ιt is proved that has been developed an application that ensures data security and integrity from

IoT devices. In addition, DAML smart contract strengthens and ensures the business logic of the

application. It defines the control access of the users and authorizes them with different rights.

Finally, the Hyperledger Fabric network is used as an infrastructure layer.

As described in the previous section, DAML is a permissioned programming language with that

can be applied to databases and blockchain platforms. As proof of concept, has been developed a

DAML application on Hyperledger Fabric network that ensures controlled access and data

immutability. Furthermore, it is noteworthy that as a Proof of Concept have not used real IoT

devices but a dataset that concerns weather metrics.

Finally, a smart contract was created at DAML, which is being developed at Hyperledger Fabric

to be portable on a variety of blockchain platforms. Regarding the implementation of DAML, a

template was created that contains all types of variables related to weather forecasting.

4.1.1 Datasets

In this research, 2 different datasets have been used. The first concerns data collected from sensors.

These sensors generally capture the indicated measurements hourly while the sensors are in

operation during the summer. Furthermore, the dataset concerns the fields:

Station Name, Plain Text

Measurement Timestamp, The date and time when the measurements were taken, Date &

Time

Humidity, Percent relative humidity, Number

Air Temperature, Air Temperature in Celsius degrees, Number

Wind Speed, Wind speed in meters per second at the time the record was reported, Number

Page 57: Towards a design philosophy for interoperable smart

56

Wind Direction, Wind direction in degrees, Number

Maximum Wind Speed, Maximum wind speed in the two-minute period immediately

preceding the time the record was reported, Number

Rain Intensity, Rain intensity in mm per hour, Number

Solar Radiation, Solar radiation in watts per square meter, Number

Battery Life, Battery voltage, an indicator of remaining battery life, Number

Measurement ID, A unique record ID made up of the Station Name and Measurement

Timestamp, Plain Text

The second dataset concerns weather images. In a more detailed manner, the dataset features 5

different classes of weather which it's real life data. The dataset contains about 1500 labelled

images including the validation images. Images are not of fixed dimensions and the photos are of

different sizes. Each image has only one weather category and are saved in separate folder as of

the labelled class. The existed classes of weather are cloudy, foggy, rainy, shine and sunrise.

4.1.2 DAML smart contract for smart city

The measurements concern the transmission of environmental data from various weather

substations to a central meteorological station. As shown in the figure 2, the collected

measurements concern humidity, temperature, rain intensity, wind direction, wind speed,

maximum wind speed and solar radiation. In addition, each entry made is accompanied by the

indication of time, date, a unique ID and the sensor battery. In addition to sensor measurements, it

is possible to send photos from cameras that can be placed in more inaccessible places.

Page 58: Towards a design philosophy for interoperable smart

57

Figure 2: DAML Smart contract

Page 59: Towards a design philosophy for interoperable smart

58

4.1.3 Authorization through DAML

The goal of the project is to transform a city into a smart city and at the same time secure the data

with blockchain technology. However, an important difference with other programming languages

is that the group of users that will be allowed to make a transaction must be included in the template

and the user statement must be clearly marked as "signatories". Any template created in a smart

contract must state the "signatory" field. Of course, it is not necessary for the "signatory" field to

have only one user group, as it may involve more than one user group, but in this case the

transaction will not be valid if not all the signatories sign the transaction. In addition, another

important difference is the scope of the "observer". This is another addition that strengthens the

business logic as it gives the right to a group of users or even more than one group to have access

to the transactions that are applied, but cannot make any transaction or even set any transaction as

archived. In this research, the "signatory" is the meteorological substations that collect information

from their sensors. While, as an "observer" is the central meteorological station that collects and

has access to all measurements but does not have the right to renew or delete any entry. For a smart

DAML contract "observer" is not a mandatory field like "signatory" but is an option that gives the

right to monitor transactions for that template for application users. Examining this research in

more depth, there is a user/weather substation who is responsible for registering transactions, ie

"signatory", and a user/weather station who simply has access to the recorded data in the journal,

ie "observer". The parties for a DAML application must be declared into a yaml file, as is depicted

in figure 3.

Figure 3: DAML parties

Page 60: Towards a design philosophy for interoperable smart

59

4.1.4 Portable functionalities

4.1.4.1 Access through dazl

The proposed solution is beneficial because the functionalities can be transferred to a different

blockchain framework. The table 2 shows the functionalities and the roles that are authorized to

have access. More specifically, meteorological substations have the right to create new transactions

to the DAML application. Moreover, all users are authorized to search on the ledger under various

conditions. The daml parties are able to search for images based on the name of the weather

substation and based on the date. For the raw weather data, the DAML parties can query based on

the name of the substation, the temperature range, the date and the entire history of the data. In

figures 4 and 5 are depicted a query request based on date and the automation process for the

transmit of the weather data from the substations.

Role Functionality

Signatory Upload raw weather data

Signatory Upload weather image

All Query all raw data

All Query raw data based on date

All Query raw data based on weather substation

All Query raw data based on range temperature

All Query images based on date

All Query images based on weather substation

Table 2: Functionalities of DAML application

Page 61: Towards a design philosophy for interoperable smart

60

Figure 4: Dazl application queries data based on date

Figure 5: Dazl application invokes weather data

4.1.4.2 Access through Navigator

In the image, it appears the automated entries from a csv file that are created through dazl library.

In the picture, is depicted a query based on the date. The functionalities that described above,

interact with the application via the terminal. However, there is also the option to use the navigator,

as shown in the picture. A logged in DAML party has a visualization through navigator for the

fields and their values. Also, an authorized user can create new entries to the ledger via navigator

or to gain access to further information such as transaction ID.

In this case, if it was not a required to use automated transactions for the IoT devices the DAML

navigator could be more useful. However, the observers can manage some functionalities and

access some information through DAML navigator. The logged in user can fill in the fields in order

to create a new transaction, in figure 6. In the figure 7, the user has the ability to see the transactions

that have been made. The user is able to see more details for the transactions such as transactions

ID, timestamp and template ID. Moreover, in the figure 8 is depicted the data entry template, where

the fields are displayed.

Page 62: Towards a design philosophy for interoperable smart

61

Figure 6: DAML Navigator template info

Figure 7: DAML Navigator contracts

Page 63: Towards a design philosophy for interoperable smart

62

Figure 8: DAML Navigator template

4.1.5 DAML on Hyperledger Fabric

In this section, is analyzed the implementation of the DAML on Hyperledger Fabric network. In

figure 9, are depicted the subcomponents of the application. It is noteworthy that the Hyperledger

Fabric works as an infrastructure layer for the DAML application.

Figure 9: DAML on Hyperledger Fabric

4.1.5.1 Dazl Application

Dazl application is a local component that interacts with the application. Creates and manages end-

user functionalities.

Page 64: Towards a design philosophy for interoperable smart

63

4.1.5.2 DAML Ledger API

The local API is controlled by DAML Ledger API. Acts as a connector in order to send or retrieve

data from the ledger.

4.1.5.3 DAML ledger server

DAML ledger server is consisted from 2 major subcomponents. The subcomponents are the DAML

on Fabric Server and the Fabric Adapter.

DAML on Fabric Server acts as a buffer for the submitted requests. The incoming requests are

parsed and put into queues in order to be pushed to Hyperledger Fabric SDK

Fabric Adapter is a component that is builded from the Hyperledger Fabric Java SDK. Through

this component is “translated” the DAML business logic to Hyperledger Fabric demands and

executed into the Hyperledger Fabric network.

4.1.5.4 Endorsement System Chaincode (ESCC)

Endorsement System Chaincode (ESCC) is a subcomponent of Hyperledger Fabric system

chaincode that used to endorse the transaction by digitally signing the response.

It is a part of chaincode authorization. In a more detailed manner, verifies if the client is authorized

to invoke transaction/transactions on the Hyperledger Fabric channel. Finally, is created a

read/write(R/W) set when is executed the chaincode. As a result, is signed the transaction with

peer’s identity and the response is sent back to client.

4.1.5.5 Hyperledger Fabric peers

A peer is a node is responsible to store its own data in a separate ledger. The applications connected

through the peers in order to query or invoke data into ledgers. The query process demands the

peers. However, the invoke process demands the peers as an intermediate layer then the transaction

is created and sent to the orderer node for ordering. Finally, is passed and then committed to the

ledger.

4.1.5.6 Hyperledger Fabric orderer

The orderer node or ordering service offers a broadcast service for messages containing

transactions. Moreover, is responsible to enforce basic access control for the channel. Manages the

endorsed transactions and send them back into blocks to all the connected peers for validation.

Page 65: Towards a design philosophy for interoperable smart

64

4.1.5.7 Validation System Chaincode (VSCC)

VSCC: Validation System Chaincode is a subcomponent of Hyperledger Fabric system Chaincode

validates the transaction according to the endorsement policy of the channel. As a result, VSCC is

responsible to validate the signature of the endorsers.

4.2 A proof of concept for oracles

This research aims to contribute to blockchain interoperability issue with an external service that

acts as oracles between heterogeneous blockchain networks. The goal of the application is to

execute transactions among multiple blockchain platforms in which the recorded data are

accessible, verifiable and referenceable by foreign transaction.

4.2.1 An interoperable application

In this section a proof of concept for oracles approach is described. There are two blockchain

networks that store the same information in their ledgers. In a more detailed manner, an application

has been developed, that through the DAML smart contracts and the DAML API, transfers weather

data from Fabric network to Sawtooth network. The weather substations create invoked requests,

connect to Fabric network as DAML signatories and put raw weather data and weather images to

Fabric state. The operator, as DAML observer on Hyperledger Fabric, creates query requests based

on date for raw data and images data. Moreover, the operator receives the transaction id from the

Hyperledger Fabric ledger for each transaction which is a unique value. In addition, the operator

acts as signatory on Hyperledger Sawtooth network. Furthermore, each time retrieves new data

from Fabric ledger, creates a new query request to Sawtooth ledger based on the received

transaction from the Fabric ledger. In case that the query returns an empty object, then it is ensured,

that the specific transaction has not been transferred to Sawtooth ledger. Finally, creates an invoke

request for the received weather data on the Sawtooth ledger. As a result, the DAML parties that

act as observers on Sawtooth network can create query requests in order to retrieve the weather

data that transferred from the origin ledger to destination ledger. In Figure 10 is depicted the flow

of the application.

In conclusion, this oracles approach proof of concept, satisfies the blockchain interoperability. An

external service that has been developed with the DAML ledger API Python bindings, manages the

requests on both networks. Finally, the same data exists and is accessible on two 2 blockchain

Page 66: Towards a design philosophy for interoperable smart

65

platforms in which different DAML parties have access. Finally, the DAML smart contract on

Fabric is depicted in Figure 11 and the DAML smart contract on Fabric is depicted in Figure 12.

Figure 10: DAML on oracles

Page 67: Towards a design philosophy for interoperable smart

66

Figure 11: Oracles-DAML on Sawtooth

Page 68: Towards a design philosophy for interoperable smart

67

Figure 12 :Oracles-DAML on Fabric

4.2.2 Architecture for oracles approach

In this section is described the architecture of the interoperable application. In a more detailed

manner, two different blockchain networks have been combined, in which the DAML ledger API

is used as an external service in order to transfer data from the original ledger to the destination

ledger. The Hyperledger Fabric is the original ledger, while the Hyperledger Sawtooth is the

Page 69: Towards a design philosophy for interoperable smart

68

destination ledger. The architecture for the DAML on Hyperledger Fabric described in the previous

section.

The DAML on sawtooth architecture concerns a sawtooth network in which the DAML-RPC

subcomponent is added in order to implement the DAML ledger API gRPC services. In a more

detailed manner, the DAML-RPC is about a set of services that manages the interactions with the

network. the DAR file is the output of the built DAML smart contract which is uploaded to the

network through the DAML-RPC. In addition, the native components of the sawtooth network are

used. The Sawtooth REST-API interacts with the validator using common HTTP/JSON standards.

Through the REST-API, data access is achieved and transactions are submitted. The validator on

a Sawtooth network is responsible to maintain consensus, validates batches of transactions and

combines the batches into blocks. The specific deployment concerns a single validator with

DevMode consensus engine for testing purposes. The consensus engine is a validator’s

subcomponent that declares the consensus algorithm of the network. The validation must adhere to

the specific business rules that are defined into the Transaction Processor. Finally, a PostgreSQL

is used for data storage. In conclusion, the architecture for the oracles approach is depicted in Figure

13.

Page 70: Towards a design philosophy for interoperable smart

69

Figure 13: Architecture for oracles approach

4.3 A proof of concept for moveable Smart Contracts

In this research was created the need to develop an application that assists the development of

blockchain interoperable applications. To be more precise, a PoC that converts a Golang Fabric

smart contract into a DAML smart contract has been developed. This mechanism assists

transferable smart contracts from one blockchain framework to another.

4.3.1 The mechanism for moveable Smart Contracts

Initially, the user enters the name of the file that wants to convert into a DAML smart contract. The

application searches for the file that must be stored locally. In case it does not find the file, it warns

the user that the file was not been found. If the file is found by the application, then opens the file

and deletes all comments and empty lines. Afterwards, searches for the name of the smart contract

Page 71: Towards a design philosophy for interoperable smart

70

and counts the number of functions in order to create a file for each function. The same procedure

is followed for the creation of separate files regarding the information of the structs, in order for

all the files that have been created to be processed and transferred to the DAML smart contract. A

loop process reads the generated files related to the structs that created to the previous step, where

the application searches for the names of the structures, the names of the fields and the data types.

The information about the found data from the Fabric smart contract is converted into DAML and

entered in the new smart contract. Once the loop process for the structs files is completed then a

loop process for reading the function files begins, in which a search is done about the function

name. Moreover, a mechanism has been developed that recognizes which of the existed structs are

called from the function. The application transfers the information regarding the functions of the

Golang smart contract to DAML templates in the new smart contract. At the next step, a complex

process is taking place, which recognizes the functions that does not create a new entry but updates

an existing one. In this case, functions that update existing entries are not transferred by the

application to the DAML smart contract as DAML templates but as DAML choices. More

specifically, a file is generated where the application writes the DAML options according to the

DAML programming language. The generated files with the DAML options merged with the

DAML smart contract. When the loop process that parses the files is over, then the DAML smart

contract is completed. Finally, in order for the generated intermediate files to be parsed separately,

they are deleted, since they are of no use to the user after the creation of a new DAML smart

contract. .Figure 14 depicts the processes of the conversion of the smart contract.

Page 72: Towards a design philosophy for interoperable smart

71

Figure 14: Activity diagram for the mechanism of transferable smart contracts

Page 73: Towards a design philosophy for interoperable smart

72

4.3.2 From Hyperledger Fabric to DAML environments

It is noteworthy to mention that the aim of this PoC is to be used in a dynamic manner. As a result,

a blockchain developer can develop a blockchain application to a framework and through this

conversion can transfer the business logic to another framework that is compatible with DAML.

Finally, the DAML ledger API must be developed in order to be achieved an entire movable

application that can be deployed to any framework, satisfies the desired architecture, consensus

algorithm and access control.

In Figure 15 is depicted the output of the mechanism while in Figures 16 and 17 is depicted the

input. As it is obvious, the Golang smart contract has 4 functions and 3 structs. The DAML smart

contract recognizes and converts the structs and their fields to DAML data. Regarding the

functions, it finds the function that initializes a struct and converts the Golang function to DAML

template. Moreover, it is noteworthy that the mechanism recognizes the functions that update an

entry and create the appropriate DAML choice. Finally, the DAML roles (signatory, observer,

controller) need to be added.

Page 74: Towards a design philosophy for interoperable smart

73

Figure 15:The output DAML smart contract

Page 75: Towards a design philosophy for interoperable smart

74

Figure 16: The input golang smart contract (part 1)

Page 76: Towards a design philosophy for interoperable smart

75

Figure 17: The input golang smart contract (part 2)

Page 77: Towards a design philosophy for interoperable smart

76

Conclusion

This research aimed to identify issues and challenges for cross-blockchain communication. In this

thesis, is proved by using a DAML smart contract for a weather forecasting application, that is

possible to be transferred with an easy way to another environment, without any omission of the

access control and the functionalities of the application. In addition, the application is fully

functional to another environment as the ledger API is also portable. It is not inferior to other

programming languages as it can support all types of data, converts a permissionless environment

to a permissioned one and can support many programming languages in order to develop the ledger

API. The results indicate that the portable smart contracts are a secure solution to achieve an

interoperable distributed application. In addition, the DAML ledger API has been used as an oracles

solution in order to execute transactions between heterogeneous blockchain systems where the

stored data are accessible, verifiable and traceable. So, DAML can be used as an oracles solution

with the compatible frameworks. At this stage, the oracles approach deployed among Hyperledger

Fabric network and Hyperledger Sawtooth network but could be on each other DAML compatible

environment. Moreover, the mechanism that convert smart contracts from Golang smart contract

to DAML aims to contribute to blockchain interoperability issues as a solution for portable smart

contracts. A primary advantage of this mechanism is that the smart contract is converted without

any human interaction and the business logic remains unaffected as it provides a potential

mechanism for transferable applications without violating access control rules or to alter the

functionalities. Τhe mechanism is dynamic so it can convert any Hyperledger Fabric Golang smart

contract regardless of the defined business logic. In conclusion, DAML is an interoperable solution

to the problems that have been created by the different features existed blockchain platforms. To

sum up, a weather forecasting application has been developed, but more IoT implementations could

be realized. Finally, one can deduce with a fair amount of certainty, that the aforementioned

premises support any rational argumentation on the prospective evolution of DAML from a regular

programming language to the universal language for smart contract development. The source code

exists in the following repository https://github.com/vsiop/Interoperable-Smart-Contracts-DAML.

Page 78: Towards a design philosophy for interoperable smart

77

Future work

Future investigations are necessary to validate the kinds of conclusions that can be drawn from this

study. However, the results of this master thesis provide a basis for the development of

interoperable distributed applications. Having a glimpse into the future, further attempts could

prove quite beneficial for delving into the research field even more. A further investigation could

be enlightening regarding the efficiency issues. A major factor that demands further research, is

the validation time on each blockchain network and the synchronization time among the

heterogeneous platforms which affects the performance of the system. Moreover, more theoretical

research is needed to be applied and tested regarding the block size, the architecture, the consensus

algorithm and the hardware as those parameters have major impact. In addition, another issue that

needs to be resolved may concern the benchmarking among native Smart Contract programming

languages and DAML. The DAML ledger API, which used as oracles solution, should be tested on

more DAML compatible environments as it can manage the off-chain and on-chain data, while

apart from blockchain framework is compatible with databases also. Finally, regarding the

conversion mechanism, it would beneficial, if was enriched with more capabilities in order to be

able to translate more smart contract programming languages to DAML smart contract.

Page 79: Towards a design philosophy for interoperable smart

78

References

[1] Davidson, S., Filippi, P. D., & Potts, J. (2016). Disrupting Governance: The New Institutional

Economics of Distributed Ledger Technology. SSRN Electronic Journal. doi: 10.2139/ssrn.2811995

[2] Drescher, D. (2017). Blockchain Basics. doi: 10.1007/978-1-4842-2604-9

[3] Ølnes, S., Ubacht, J., & Janssen, M. (2017). Blockchain in government: Benefits and

implications of distributed ledger technology for information sharing. Government Information

Quarterly, 34(3), 355–364. doi: 10.1016/j.giq.2017.09.007

[4] Shier, C., Mehar, M. I., Giambattista, A., Gong, E., Fletcher, G., Sanayhie, R., … Kim, H. M.

(2017). Understanding a Revolutionary and Flawed Grand Experiment in Blockchain: The

DAO Attack. SSRN Electronic Journal. doi: 10.2139/ssrn.3014782

[5] Yermack, D. (2017). Corporate Governance and Blockchains. Review of Finance. doi:

10.1093/rof/rfw074

[6] Polinpapilinho F. Katina, C. B. (2019). Blockchain governance. Int. J. Critical Infrastructures,

121-135.

[7] Iansiti, M., K. R. (2017, January-February). The Truth About Blockchain. Harvard Business

Review.

[8] Munindar, P. Singh, A. K. (2018, January 8). Violable Contracts and Governance for

Blockchain Applications.

[9] Huh, S., Cho, S., & Kim, S. (2017). Managing IoT devices using blockchain platform. 2017

19th International Conference on Advanced Communication Technology (ICACT).

doi:10.23919/icact.2017.7890132

[10] Allen, D., Lane, A., & Poblet, M. (2019). The Governance of Blockchain Dispute Resolution.

SSRN Electronic Journal. doi: 10.2139/ssrn.3334674

[11] Christidis, K., & Devetsikiotis, M. (2016). Blockchains and Smart Contracts for the Internet of

Things. IEEE Access, 4, 2292–2303. doi: 10.1109/access.2016.2566339

[12] Howell, B. E., & Potgieter, P. H. (2019). Governance of Smart Contracts in Blockchain

Institutions. SSRN Electronic Journal. doi: 10.2139/ssrn.3423190

[13] Raskin, M. (2017). The Law and Legality of Smart Contracts. Georgetown Law Technology

Review.

Page 80: Towards a design philosophy for interoperable smart

79

[14] Lafarre, A., & Elst, C. V. D. (2018). Blockchain Technology for Corporate Governance and

Shareholder Activism. SSRN Electronic Journal. doi: 10.2139/ssrn.3135209

[15] Frantz, C. K., & Nowostawski, M. (2016). From Institutions to Code: Towards Automated

Generation of Smart Contracts. 2016 IEEE 1st International Workshops on Foundations and

Applications of Self* Systems (FAS*W). doi: 10.1109/fas-w.2016.53

[16] Baliga, A. (2017, April). Understanding Blockchain Consensus Models. Persistent.

[17] Ittai Abraham, D. M. (n.d.). The Blockchain Consensus Layer and BFT.

[18] Nakamoto, S. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System

[19] Bach, L. M., Mihaljevic, B., & Zagar, M. (2018). Comparative analysis of blockchain

consensus algorithms. 2018 41st International Convention on Information and Communication

Technology, Electronics and Microelectronics (MIPRO). doi: 10.23919/mipro.2018.8400278

[20] Mingxiao, D., Xiaofeng, M., Zhe, Z., Xiangwei, W., & Qijun, C. (2017). A review on

consensus algorithm of blockchain. 2017 IEEE International Conference on Systems, Man, and

Cybernetics (SMC). doi: 10.1109/smc.2017.8123011

[21] Sunny King, S. N. (2012, August 19). PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-

Stake.

[22] Castro, M., & Liskov, B. (n.d.). Byzantine fault tolerance can be fast. Proceedings

International Conference on Dependable Systems and Networks. doi:10.1109/dsn.2001.941437

[23] Yang Zhao, J. Z. (2019, June 26). Mobile Edge Computing, Blockchain and Reputation-based

Crowdsourcing IoT Federated Learning A Secure, Decentralized and Privacy-preserving

System.

[24] Zheng, Z., Xie, S., Dai, H. N., Chen, X., & Wang, H. (2018). Blockchain challenges and

opportunities: a survey. International Journal of Web and Grid Services, 14(4), 352.

doi:10.1504/ijwgs.2018.095647

[25] Zheng, Z., Xie, S., Dai, H., Chen, X., & Wang, H. (2017). An Overview of Blockchain

Technology: Architecture, Consensus, and Future Trends. 2017 IEEE International Congress on

Big Data (BigData Congress). doi: 10.1109/bigdatacongress.2017.85

[26] Saraf, C., & Sabadra, S. (2018). Blockchain platforms: A compendium. 2018 IEEE

International Conference on Innovative Research and Development (ICIRD).

doi:10.1109/icird.2018.8376323

[27] Koens, T., & Poll, E. (2019). Assessing interoperability solutions for distributed ledgers.

Pervasive and Mobile Computing, 59, 101079. doi: 10.1016/j.pmcj.2019.101079

Page 81: Towards a design philosophy for interoperable smart

80

[28] Haber, S., & Stornetta, W. (1991). How to time-stamp a digital document. Journal of

Cryptology, 3(2). doi: 10.1007/bf00196791

[29] Ølnes, S. (2016). Beyond Bitcoin Enabling Smart Government Using Blockchain Technology.

Lecture Notes in Computer Science Electronic Government, 253–264. doi: 10.1007/978-3-319-

44421-5_20

[30] Buterin, V. (2013). A Next Generation Smart Contract & Decentralized Application Platform.

[31] Wood, G. (2017, April 12). Ethereum: A decentralized Generalised Transaction Ledger.

[32] Buterin, V. (n.d.). Ethereum: Platform Review-Opportunities and Challenges for Private and

Consortium Blockchains.

[33] Dhillon, V., Metcalf, D., & Hooper, M. (2017). The Hyperledger Project. Blockchain Enabled

Applications, 139–149. doi: 10.1007/978-1-4842-3081-7_10

[34] Tamas Blummer, S. B. (2018, July). An Introduction to Hyperledger.

[35] Wood, G. (n.d.). Polkadot: Vision for a Heterogeneous Multi-Chain Framework.

[36] ARK Ecosystem Whitepaper. (2019, September 27).

[37] Kelly Olson, M. B. (2018, January). Sawtooth: An Introduction.

[38] team, B. C. (2018, January 17). Block Collider Whitepaper.

[39] Androulaki, E., Manevich, Y., Muralidharan, S., Murthy, C., Nguyen, B., Sethi, M.,

Laventman, G. (2018). Hyperledger fabric. Proceedings of the Thirteenth EuroSys Conference

on - EuroSys 18. doi: 10.1145/3190508.3190538

[40] Jae Kwon, E. B. (n.d.). Cosmos: A network of Distributed Ledgers.

[41] team, D. A. (n.d.). Digital Asset Open Sources its Smart Contract Language, DAML, to

Enable Integration with Other Platforms.

[42] Atzori, M. (2015). Blockchain Technology and Decentralized Governance: Is the State Still

Necessary? SSRN Electronic Journal. doi: 10.2139/ssrn.2709713

[43] John, T., & Pam, M. (2018). Complex Adaptive Blockchain Governance. MATEC Web of

Conferences, 223, 01010. doi: 10.1051/matecconf/201822301010

[44] Davidson, S., Filippi, P. D., & Potts, J. (2016). Economics of Blockchain. SSRN Electronic

Journal. doi: 10.2139/ssrn.2744751

[45] Suresh, P., Daniel, J. V., Parthasarathy, V., & Aswathy, R. H. (2014). A state of the art review

on the Internet of Things (IoT) history, technology and fields of deployment. 2014 International

Conference on Science Engineering and Management Research (ICSEMR). doi:

10.1109/icsemr.2014.7043637

Page 82: Towards a design philosophy for interoperable smart

81

[46] Abdmeziem, M. R., Tandjaoui, D., & Romdhani, I. (2015). Architecting the Internet of

Things: State of the Art. Robots and Sensor Clouds Studies in Systems, Decision and Control,

55–75. doi: 10.1007/978-3-319-22168-7_3

[47] Alaba, F. A., Othman, M., Hashem, I. A. T., & Alotaibi, F. (2017). Internet of Things security:

A survey. Journal of Network and Computer Applications, 88, 10–28. doi:

10.1016/j.jnca.2017.04.002

[48] Wu, M., Lu, T.-J., Ling, F.-Y., Sun, J., & Du, H.-Y. (2010). Research on the architecture of

Internet of Things. 2010 3rd International Conference on Advanced Computer Theory and

Engineering (ICACTE). doi: 10.1109/icacte.2010.5579493

[49] Sethi, P., & Sarangi, S. R. (2017). Internet of Things: Architectures, Protocols, and

Applications. Journal of Electrical and Computer Engineering, 2017, 1–25. doi:

10.1155/2017/9324035

[50] Roberts, C. (2006). Radio frequency identification (RFID). Computers & Security, 25(1), 18–

26. doi: 10.1016/j.cose.2005.12.003

[51] Domdouzis, K., Kumar, B., & Anumba, C. (2007). Radio-Frequency Identification (RFID)

applications: A brief introduction. Advanced Engineering Informatics, 21(4), 350–355. doi:

10.1016/j.aei.2006.09.001

[52] Al-Sarawi, S., Anbar, M., Alieyan, K., & Alzubaidi, M. (2017). Internet of Things (IoT)

communication protocols: Review. 2017 8th International Conference on Information

Technology (ICIT). doi: 10.1109/icitech.2017.8079928

[53] Pongle, P., & Chavan, G. (2015). A survey: Attacks on RPL and 6LoWPAN in IoT. 2015

International Conference on Pervasive Computing (ICPC). doi:

10.1109/pervasive.2015.7087034

[54] Iii, A. F. H., Khanna, V., Tuncay, G., Want, R., & Kravets, R. (2016). Bluetooth Low Energy

in Dense IoT Environments. IEEE Communications Magazine, 54(12), 30–36. doi:

10.1109/mcom.2016.1600546cm

[55] Raza, S., Misra, P., He, Z., & Voigt, T. (2017). Building the Internet of Things with bluetooth

smart. Ad Hoc Networks, 57, 19–31. doi: 10.1016/j.adhoc.2016.08.012

[56] Elarabi, T., Deep, V., & Rai, C. K. (2015). Design and simulation of state-of-art ZigBee

transmitter for IoT wireless devices. 2015 IEEE International Symposium on Signal Processing

and Information Technology (ISSPIT). doi: 10.1109/isspit.2015.7394347

Page 83: Towards a design philosophy for interoperable smart

82

[57] Sathishkumar, J., & Patel, D. R. (2014). A Survey on Internet of Things: Security and Privacy

Issues. International Journal of Computer Applications, 90(11), 20–26. doi: 10.5120/15764-

4454

[58] Herlihy, M. (2018). Atomic Cross-Chain Swaps. Proceedings of the 2018 ACM Symposium

on Principles of Distributed Computing - PODC 18. doi: 10.1145/3212734.3212736

[59] Vitalik Buterin. Chain Interoperability. 2016. url: https://static1.squarespace.

com/static/55f73743e4b051cfcc0b02cf/t/5886800ecd0f68de303349b1/1485209617040/Chain+I

nteroperability.pdf

[60] Hegnauer, T. (2017, February 17). Design and Development of a Blockchain Interoperability

API. In T. Hegnauer. Zür Hegnauer. Zürich.ich.

[61] Deng, L., Chen, H., Zeng, J., & Zhang, L.-J. (2018). Research on Cross-Chain Technology

Based on Sidechain and Hash-Locking. Edge Computing – EDGE 2018 Lecture Notes in

Computer Science, 144–151. doi: 10.1007/978-3-319-94340-4_12

[62] Sandra Johnson, P. R. (2019, March 22). Sidechains and interoperability.

[63] Hardjono, T., Lipton, A., & Pentland, A. (2019). Toward an Interoperability Architecture for

Blockchain Autonomous Systems. IEEE Transactions on Engineering Management, 1–12. doi:

10.1109/tem.2019.2920154

[64] Schulte, S., Sigwart, M., Frauenthaler, P., & Borkowski, M. (2019). Towards Blockchain

Interoperability. Business Process Management: Blockchain and Central and Eastern Europe

Forum Lecture Notes in Business Information Processing, 3–10. doi: 10.1007/978-3-030-

30429-4_1

[65] Jin, H., Dai, X., & Xiao, J. (2018). Towards a Novel Architecture for Enabling Interoperability

amongst Multiple Blockchains. 2018 IEEE 38th International Conference on Distributed

Computing Systems (ICDCS). doi: 10.1109/icdcs.2018.00120

[66] Minoli, D., & Occhiogrosso, B. (2018). Blockchain mechanisms for IoT security. Internet of

Things, 1-2, 1–13. doi: 10.1016/j.iot.2018.05.002

[67] Viriyasitavat, W., Xu, L. D., Bi, Z., & Pungpapong, V. (2019). Blockchain and Internet of

Things for Modern Business Process in Digital Economy—the State of the Art. IEEE

Transactions on Computational Social Systems, 6(6), 1420–1432. doi:

10.1109/tcss.2019.2919325

Page 84: Towards a design philosophy for interoperable smart

83

[68] Rimba, P., Tran, A. B., Weber, I., Staples, M., Ponomarev, A., & Xu, X. (2017). Comparing

Blockchain and Cloud Services for Business Process Execution. 2017 IEEE International

Conference on Software Architecture (ICSA). doi: 10.1109/icsa.2017.44

[69] Ahmed, M. E., & Kim, H. (2017). DDoS Attack Mitigation in Internet of Things Using

Software Defined Networking. 2017 IEEE Third International Conference on Big Data

Computing Service and Applications (BigDataService). doi: 10.1109/bigdataservice.2017.41

[70] Saad, M., Spaulding, J., Njilla, L., Kamhoua, C., Shetty, S., Nyang, D. H., & Mohaisen, D.

(2020). Exploring the Attack Surface of Blockchain: A Comprehensive Survey. IEEE

Communications Surveys & Tutorials, 1–1. doi: 10.1109/comst.2020.2975999

[71] Javaid, U., Siang, A. K., Aman, M. N., & Sikdar, B. (2018). Mitigating loT Device based

DDoS Attacks using Blockchain. Proceedings of the 1st Workshop on Cryptocurrencies and

Blockchains for Distributed Systems - CryBlock18. doi: 10.1145/3211933.3211946

[72] Gaby G. Dagher, C. L. (2017). Towards Secure Interoperability between Heterogeneous

Blockchains using Smart Contracts. Future Technologies Conference. Vancouver.

[73] Turkanovic, M., Holbl, M., Kosic, K., Hericko, M., & Kamisalic, A. (2018). EduCTX: A

Blockchain-Based Higher Education Credit Platform. IEEE Access, 6, 5112–5127. doi:

10.1109/access.2018.2789929

[74] Shidokht Hejazi-Sepehr, R. K. (2019, January 25). Transwarp-Conduit: Interoperable

Blockchain Application Framework.

[75] White, R., Caiazza, G., Cortesi, A., Cho, Y. I., & Christensen, H. I. (2019). Black Block

Recorder: Immutable Black Box Logging for Robots via Blockchain. IEEE Robotics and

Automation Letters, 4(4), 3812–3819. doi: 10.1109/lra.2019.2928780

[76] Ethereum. (2020, August 10). Retrieved from https://ethereum.org/en/learn/

[77] Corda. (2020, August 10). Retrieved from https://docs.corda.net/docs/corda-os/4.5.html

[78] Quorum. (2020, August 11). Retrieved from http://docs.goquorum.com/en/latest/

[79] Benhamouda, F., Halevi, S., & Halevi, T. (2018). Supporting Private Data on Hyperledger

Fabric with Secure Multiparty Computation. 2018 IEEE International Conference on Cloud

Engineering (IC2E). doi:10.1109/ic2e.2018.00069

[80] Hyperledger Fabric. (2020, August 13). Retrieved from https://hyperledger-

fabric.readthedocs.io/en/release-2.0/whatis.html

[81] Hyperledger Sawtooth. (2020, August 13). Retrieved from

https://sawtooth.hyperledger.org/docs/core/releases/latest/introduction.html

Page 85: Towards a design philosophy for interoperable smart

84

[82] Hyperledger Indy. (2020, August 14). Retrieved from https://indy.readthedocs.io/en/latest/

[83] Hyperledger Iroha. (2020, August 14). Retrieved from https://iroha.readthedocs.io/en/master/

[84] Hyperledger Burrow. (2020, August 15). Retrieved from

https://www.hyperledger.org/use/hyperledger-burrow

[85] Tendermint. (2020, August 15). Retrieved from

https://docs.tendermint.com/master/introduction/what-is-tendermint.html

[86] Hyperledger Besu . (2020, August 17). Retrieved from https://besu.hyperledger.org/en/stable/

[87] Schulte, S., Sigwart, M., Frauenthaler, P., & Borkowski, M. (2019). Towards Blockchain

Interoperability. Business Process Management: Blockchain and Central and Eastern Europe

Forum Lecture Notes in Business Information Processing, 3–10. doi: 10.1007/978-3-030-

30429-4_1

[88] Asset, D. (2016, December). The Digital Asset Platform Non-technical White Paper.

[89] Asset, Digital. “A New Language for a New Paradigm: Smart Contracts.” Medium, DAML

Driven, 13 May 2019, medium.com/daml-driven/a-new-language-for-a-new-paradigm-smart-

contracts-648cc30294ad.

[90] O’Prey, D. (2019, April 16). Hyperledger.

https://www.hyperledger.org/blog/2019/04/16/daml-smart-contracts-coming-to-hyperledger-

sawtooth

[91] “DAML Documentation.” Overview of DAML Ledgers - DAML SDK Documentation,

docs.daml.com/deploy/index.html.

[92] GitHub. 2020. Digital-Asset/Dazl-Client. [online] Available at: <https://github.com/digital-

asset/dazl-client> [Accessed 26 July 2020].

[93] Insights, Ledger. “Smart Contract Language DAML Now Works with Ethereum Compatible

Hyperledger Besu.” Ledger Insights - Enterprise Blockchain, 3 Mar. 2020,

www.ledgerinsights.com/daml-smart-contract-hyperledger-besu/.