The Semantic Web of Things (SWoT) improves the Internet of Things power by increasing resource representation capabilities through knowledge management and reasoning technologies adapted from the Semantic Web. This promotes information interoperability and decision autonomy. Nevertheless, trust and reliability issues remain basically unsolved. Large-scale, decentralized and dynamic infrastructures su er from unpredictable volatility of nodes, which compromises resource availability. Trust and coordination are still di cult. Blockchain is increasingly used as a transactional data storage solution for distributed ledgers. It enables trustless collaboration by enforcing smart contracts and prevents data tampering by validating transactions through consensus protocols. This paper proposes a blockchain framework for SWoT contexts settled as a Service-Oriented Architecture. Nodes can exploit smart contracts for registration, discovery and selection of annotated services/resources. While semantic matchmaking enables relevant resource retrieval with logic-based ranking and explanation features, blockchain provides reliable transaction storage. A prototype has been developed by enhancing the standard Hyperledger Iroha framework. Application areas are discussed and experimental tests on a cluster of virtual nodes provide early insight on e ectiveness, performance and scalability.
The Semantic Web of Things (SWoT) [
Anyway, IoT su ers from unpredictability of node and resource availability,
due to the volatility of actors and appliances. This makes trust and coordination
management di cult and these limits are inevitably inherited by the SWoT:
their burden is particularly evident when reliable and trustworthy applications
are needed. Blockchain technology is interesting from this perspective. In
conventional distributed databases, a trusted intermediary is needed to guarantee
irreversibility (i.e., committed transactions cannot be altered or reverted) and
prevent censorship (i.e., all valid transactions are committed). Blockchain is a
data structure and protocol for trustless distributed transactional systems: they
avoid intermediaries by approving transactions through a distributed consensus
protocol, which guarantees no single node {or small group of colluding nodes{
can force the addition, removal or modi cation of data [
This paper proposes a framework for SWoT blockchain systems. A
semanticbased resource discovery layer is integrated in a basic blockchain infrastructure,
adding veri able records for every single transaction. A distinguishing feature
of the systems is logic-based explanation of discovery outcomes, grounded on
non-standard inference services for semantic matchmaking [
The remainder of the paper is reported hereafter. Section 2 recalls relevant background, while a functional and architectural description of the proposed framework is given in Section 3. Experimental results are provided in Section 4, followed by an overview of application areas for the approach in Section 5. Conclusion closes the paper. 2
In what follows some relevant background is surveyed in order to make the paper self-contained.
Block n-1
Block n Transactions Hash of block n-1
Block n+1 Transactions Hash of block n
Block n+2 Transactions Hash of block n+1
Block n+3
The blockchain technology was born in 2009 with Bitcoin, an open source
platform for electronic currency exploiting previous theoretical results on
Proof-ofWork consensus algorithms [
Many blockchain-based e-currencies have been proposed in latest years due
to the worldwide success of Bitcoin. Furthermore, nance, industry and research
communities have been increasingly experimenting with blockchain as a
generalpurpose distributed database enabling practical implementations of Smart
Contracts (SCs) [
From a technical viewpoint, blockchain systems can be classi ed based on
the following core design decisions:
{ Network access policy. A blockchain network is permissioned if a white-list
of allowed nodes exists and nodes are uniquely identi ed, or permission-less if
any node can join at any time, even anonymously.
{ Consensus algorithm. Permission-less systems require stricter consensus
methods, such as Proof-of-Work, which is based on solving a cryptographic
problem and guarantee data security unless a large portion of nodes is colluding to
subvert the blockchain. Permissioned systems {where each node is accountable{
may relax consensus constraints in order to reduce the computational load, by
selecting simpler algorithms. State-machine replication protocols such as
Byzantine Fault Tolerance (BFT) variants [
adopted for the experiments of this paper uses a BFT consensus algorithm named
Sumeragi.
{ Transaction model. In typical blockchain systems, assets are registered and
exchanged, so that at any time each node owns some assets in a given
quantity. In the Unspent Transaction Outputs (UTXO) model, a transfer from A to
B consumes (i.e., deletes) records for A's spent assets and produces (i.e., adds)
new ones for B's received assets. In the account-based model, instead, every node
has an account reporting all its assets, which is updated by transactions.
{ Smart contract language. Blockchains can adopt any formalism for SC
speci cation and execution, such as procedural (imperative) languages or
logical (declarative) languages or automata [
Internet of Things (IoT) scenarios are expected to be among the main
application areas in the near future. Blockchain applications in IoT contexts are
mostly focused on supply chain [
Knowledge representation and reasoning in the SWoT are formally grounded on
Description Logics (DLs), a family of logic languages in a decidable fragment of
First Order Logic [
The approach proposed in this paper leverages semantic matchmaking, i.e.,
the retrieval of the most relevant resources for a given request, where both
resources and requests are annotated with concept expressions w.r.t. a common
ontology T . Given a request R and a resource S, subsumption checks whether all
features in R are included in S; satis ability checks whether any constraint in R
contradicts some speci cation in S. Unfortunately these classic inference services
enable only a Boolean \full match or no match" approach. This is inadequate in
complex scenarios, because full matches are rare and incompatibility is frequent
when dealing with detailed resource descriptions. Therefore, non-standard
inferences in [
If R and S are incompatible, the matchmaking process uses Contraction to
extract the compatible part K and then Abduction to obtain the required HK
for reaching a full match. Furthermore, penalty functions are computed based
on the structure and number of elements in G and HK [
In SWoT contexts, computation resources of devices are strictly constrained and require careful software design. Adding more constructors makes DL languages more expressive, but leads to an increase in computational complexity of inference services, hence a tradeo is needed. This paper refers to the moderately expressive Attributive Language with unquali ed Number restrictions (ALN ) DL, which grants polynomial complexity to all the above standard and nonstandard inferences. 3
Semantic-enhanced Blockchain for unpredictable scenarios The proposed framework de nes a semantic-based discovery layer built upon a standard blockchain system, retaining full backward compatibility. 3.1
{ Peer agents registered in the blockchain are identi ed by their public keys and associated with accounts. Each agent can perform a semantic-based resource discovery in order to take ownership and transfer assets between accounts. { Assets are annotated w.r.t. a domain ontology. They can represent physical or digital resources, as well as service instances. Peers can register assets through speci c transactions, and annotations are stored in the blockchain. { Smart contracts are enhanced by exploiting non-standard inference services described in Section 2.2. Particularly, each peer locally integrates an
Semantic
Blockchain Peer 1
Peer 2
Peer N
Peer
Application Programming Interface Smart Contracts
Processor Consensus engine
Reasoning engine
Storage
embedded matchmaking and reasoning engine, allowing semantic-based
resource discovery [
How to make smarter contracts: put semantics in the consensus protocol The SWoT blockchain proposal is intended as a SOA enabling fundamental operations as registration, discovery, selection and nal execution (payment). Such tasks are implemented as smart contracts, i.e., their accomplishment is distributed and validation is reached by consensus. The distinguishing feature of the proposed approach w.r.t. basic blockchain infrastructures is the integration of advanced resource/service discovery grounded on semantic matchmaking. It allows computing a score measuring the semantic distance between the request and each available chain resource, both described w.r.t. the same domain ontology. This logic-based metric induces a relevance-ranked list of annotated elements w.r.t. the request. The non-standard inference services also provide a formal explanation of discovery outcomes, reinforcing user con dence in the discovery process. SOA primitives and corresponding SCs are outlined hereafter.
A. Resource registration. Multiple resource domains can coexist and be tracked in the same blockchain. Each domain is associated to a di erent ontology, providing the reference conceptual vocabulary for annotating resources. Resource instances are characterized by the following attributes: { a Uniform Resource Identi er (URI) featuring the resource unambiguously (and possibly denoting its fruition endpoint, although this is not mandatory); { a semantic annotation in Web Ontology Language (OWL 2)5 describing the resource; { the URI of the reference ontology, in order to cope with the co-existence of several resource domains in the same blockchain; { a resource price: the framework supports any type of currency unit, pecuniary or otherwise (e.g., in SWoT applications energy or time could be chosen).
By means of the Registration SC the owner node will register a resource as an asset on the blockchain storage, in order to make it available for discovery and usage.
B. Resource discovery. In order to search for a (set of) item(s), the requester randomly selects n peers and sends a multicast request specifying: { URI of the reference ontology: this determines the resource domain, i.e., the vocabulary used to express annotations of request and resources to be retrieved; the nodes receiving a request will not process resources annotated w.r.t. other ontologies in the semantic matchmaking; { OWL semantic annotation of the request, specifying desired resource features and constraints; { maximum price pmax the requester is willing to pay; resources with a price higher than this threshold will be skipped from matchmaking in order to reduce computational overhead; { minimum semantic relevance threshold smin, as a oating-point number in the [0; 1] range, where 1 corresponds to a full match and 0 to a complete mismatch (both rare situations in realistic scenarios); after matchmaking, resources with a relevance score below this threshold will not be returned, as deemed irrelevant to the requester; { maximum number of results rmax to be returned; { requester's address.
The proposal adopts a gossip-based (a.k.a. epidemic) approach [
C. Explanation. This is an optional step in a typical discovery process, invoked when a requester needs a justi cation of the matchmaking outcome. This
ommendation 11 December 2012, http://www.w3.org/TR/owl2-overview/
RequesterNode :BlockchainNode
ReceiverNodeN :BlockchainNode
ReceiverNodeN+1 :BlockchainNode towards n peers discovery (ontologyURI, semanticDescription,
maxPrice, minSemanticRelevance,
maxResult, , requesterNodeIP) matchmaking on owned resources return resources ranked list
if m is not reached forward discovery (ontologyURI, semanticDescription,
maxPrice, minSemanticRelevance,
maxResult, requesterNodeIP) matchmaking on
owned resources return resources ranked list
optional explanation (resourceURI,
semanticDescription) return semantic explanation selection (resourceURI)
ACK
can be useful, e.g., to trigger a request re nement process [
D. Resource selection. After receiving all results {or just a subset, if the response delay of some nodes is greater than a xed timeout { the requester selects the best resource(s) by means of select SC. A unicast message is delivered to the resource owner specifying the resource URI and a currency payment. The recipient answers with a properly usable resource representation: this depends on the actual kind of resource and meaning of the URI, e.g., an interface endpoint to access a networked device or a further SC to be invoked. The proposal does not constrain resource fruition in any way, leaving application-speci c details to the semantic annotation of the resources themselves.
The resource discovery and retrieval interaction sequence is shown in Figure 3. Each associated transaction is recorded on the blockchain for robustness, traceability and accountability purposes. 4
In order to assess e ectiveness and scalability of the proposed approach, an
experimental evaluation campaign has been carried out starting from the Iroha
framework from Hyperledger. The implemented prototype enhanced Iroha as in
what follows:
{ the server API has been extended with support for semantic matchmaking;
{ the SCs described in Section 3.2 have been implemented and the Mini-ME
reasoning and matchmaking engine [
In order to reach a quantitative performance analysis, small, medium and large scale chain scenarios have been considered, respectively with 50, 150 and 500 nodes. In each of them nodes have been split in two sets materially executing SC transactions with semantic-based discovery (see Section 3.2): producers, i.e., providers of annotated resources, registered in the blockchain; consumers, i.e., resource requesters.
The following experiment parameters have been set: (i) duration of 300 s; (ii) consumer/producer ratio of 0.1; (iii) 20 randomly-generated annotations per producer; (iv) each consumer sends a new randomly-generated request every 10 s; (v) each request can be forwarded to 4 nodes at most; (vi) a request is aborted if no match is found after 2 hops; (vii) the minimum threshold of semantic a nity is 0.9. Each scenario is executed several times by varying the following parameters: (i) the discovery timeout has been set to 2, 6 and 10 s; (ii) the explanation SC, described in Section 3.2, has been either enabled or disabled.
The experimental campaign has leveraged the adoption of Docker platform to deploy the testbed, by performing the following steps: { the prototype has been compiled as a Docker image, to create all the scenarios; { each node has been executed as a container instance of the compiled image; { a Docker Swarm mode cluster has been deployed on 6 VirtualBox virtual machines running on a workstation7, with an overlay network con gured to allow communications among the Iroha nodes; { the execution of experiments has been managed via the Docker API SDK8.
The following performance metrics have been calculated: (i) average request processing time, both as all-out and split by task; (ii) average hit ratio per node, i.e., percentage of requests with at least one resource satisfying the constraints within the given timeout. Experimental results are reported later on.
Time. Average turnaround times can be deemed as very low in experiments involving 50 and 150 nodes, as Figure 4 and Figure 5 show. the growth exhibits a linear trend, suggesting proper scaling. With 500 nodes, instead, absolute time reach the timeouts as depicted in Figure 6, due to the needed consensus about among a larger number of entities. Furthermore, in all the experiments the time of discovery process dominates the ones of explanation and selection phases. This could be due to the fact that matchmaking is the most computationally intensive task, despite the optimization of the adopted reasoning engine.
7 Intel Xeon E5-2643 CPU at 3.30 GHz, 48 GB of RAM and Ubuntu 16.04 (64bit) operating system.
Hit ratio. Figure 7 shows average results are closely related to the number of nodes. The best outcomes have been obtained in the small and medium scenarios with timeouts high enough. Conversely, in the 500 nodes case the average hit ratio is noticeably lower. The increased resource miss ratio is partially due to Docker Swarm deployment on a single host instead of adopting a more proper cluster computing environment: the large number of containers on the same host led to Docker resource contention issues a ecting the CPU, le system and network load. Furthermore, the inherent complexity of consensus algorithms tends to increase at higher scales, leading to higher processing times and consequent increased probability of timeout expiration.
Early results supported the feasibility of the proposal, as performance is basically satisfactory for small-to-medium permissioned blockchains. Larger-scale scenarios could not be setup on the reference testbed due to the above limits with Docker Swarm deployment in a single-host environment. Testbed migration toward a computer cluster will be performed to re-evaluate semantic-enhanced blockchain performance in the same scenarios as well as to allow larger-scale simulations.
Semantic-enhanced blockchain systems enable discovery infrastructures for
generalpurpose machine-to-machine trustless marketplaces with minimal or no human
intervention across multiple DAOs. This has several possible applications with
potential transformation impact on relevant sectors.
{ Logistics. Asset tracking and supply chain are among the most popular
blockchain applications, due to the easy t with existing industry standards.
The simplest approaches rely on transactional ledgers for asset transfer [
The paper proposed a framework redesigning resource discovery for SWoT scenarios thanks to an underlying blockchain infrastructure. Registration, discovery, selection and nalization tasks have been revisited as smart contracts with opportunistic and distributed execution, exploiting validation by consensus. Logicbased explanation of discovery outcomes is an important feature of the proposal, granted by non-standard inferences for request-resource matchmaking.
Future aims are basically directed to migrate the testbed toward a cluster of physical nodes, in order to remove bottlenecks biasing results and increase simulation scale. Development of case studies within the envisioned application areas is at an early stage and will be completed to fully validate bene ts and possible limitations of the proposal in realistic settings.
This work was supported in part by Italian PON project ERHA (Enhanced Radiotherapy with HAdrons).