With the advent of blockchain technology, interorganisational collaborative processes that demand trust requirements (e.g., food supply chain, smart grid energy distribution and clinical trials) can be implemented as decentralised applications (DApps) taking advantage of blockchain technology, which provides decentralised control and immutable transaction history, thereby improving security and accountability between parties. In this discussion paper, we consider cooperative processes where a subject, which acts as a regulator of the process, promotes the use of blockchain for increasing transparency, while reducing the burden in controlling trustworthiness among participants. To the scope, the regulator provides a searchable registry of basic smart contracts (i.e., deployed ones and code templates), that can be adopted and possibly extended by the participants of the process to build up DApps. To support semantic-based search in the registry, we propose a multi-perspective framework that, in addition to classification and technical characteristics of smart contracts, takes into account the past experience of developers who have used smart contracts of the registry to develop DApps.
With the advent of blockchain technology (BT), interorganisational collaborative processes
demanding trust requirements (e.g., food supply chain, smart grid energy distribution and clinical
trials) can be implemented as decentralised applications (DApps) [
In this discussion paper, we consider a cooperative process occurring in a domain, e.g., clinical trials, where a subject that acts as a regulator (i.e., that carries out regulatory activities in a given domain) of the process, promotes the use of blockchain for increasing transparency, while
Experience perspective (Developers) Application perspective (DApps) Smart Contract perspective (SCs)
DApp
DApp function call extends
T extenedxstends T
SCs relationship Composed Of Developed By Has Rated
Legend
Deployed
SC Library
SC T Template
SC
improving the trustworthiness among the process participants. In this type of processes, the
regulator is in charge of overseeing the fulfilment of the necessary requirements for safety,
quality and eficacy of the assets being supplied, providing also rules, authorisations and,
possibly, technological frameworks to the involved parties. To the purpose, the regulator subject
may provide a registry of SCs, which can be used and extended by any participant to set up
DApps for automating process activities, where a DApp implements a business logic compliant
with the rules and policies established by the regulator. Actually, developing real-world DApps
is not a trivial task, hence the reuse of SCs published in open access registries has become a
common practice [
In this setting, we propose a multi-perspective framework to support search and reuse of
SCs that, in addition to classification and technical characteristics of SCs, takes into account
the past experience of developers who have used SCs from the registry to develop DApps.
The framework supports semantic-based search and ranking of SCs according to three search
scenarios apt to support development of DApps at diferent phases. An extended version of
this work has been presented in [
We consider a motivating scenario from the healthcare domain, regarding clinical trials. A
clinical trial (CT) is articulated over diferent phases and it is aimed at introducing a New
Chemical Entity (NCE), initially administered to volunteers, to some pharmaceutical markets.
Volunteers may incur in research-related injuries, which should be minimised by researchers
steering the trial. In such cases, individuals would be compensated. As also discussed in a
recent research [
1 1..*
Usage Rating 1..* rating score
* skils 1 Developer associated with 0..1
ABI 1 Endpoint Deployed Contract 1..* 1 address deployed at network_id
chain_id 0..* 0..* Library Contract function cal functions[]
Oracle Smart Contract focus on the following challenges.
Trustworthy inspection of exchanged data. Normally, for compensation to be recognised, data related to the clinical trial (e.g., protocol setup and registration, individuals enrolment, data collection methods) must ensure a transparent and trustworthy inspection by, for example, a Health Insurance Organisation (HIO), which is responsible for corresponding compensations.
Automated compliance to rules and standards. In order to comply with rules and/or standards established and promoted by the regulator, the DApps used in the context of the process should reuse, and possibly extend, SCs provided by the regulator and made available by means of a registry. For example, according to this approach, the implementation of a compensation process as a DApp would favour the automated compliance to rules and standards.
Assisted DApp design. In order to reduce coding time and efort, a developer should be supported in: (a) specifying the features of the SCs to search from the registry; (b) developing with a proactive support, i.e., specifying the characteristics of the DApp under development and then being suggested with SCs from the registry that can be included into the DApp.
In the following, we describe the multi-perspective framework aimed at supporting SC search
for DApps development. The framework (Figure 1) is organised according to three perspectives,
describing: (i) smart contracts; (ii) DApps and (iii) developers. SCs are described in a registry,
containing both SCs specific for the application domain and general purpose SCs (e.g., from
third party registries, such as OpenZeppelin [
Smart Contract Perspective. Let be the set of SCs described in the registry. The types of SCs and their features are represented according to the conceptual model in Figure 2, described briefly in the following, and which considers as reference the Ethereum blockchain. ∙ Smart contracts model. In the model, a SC can be either a TemplateContract or a DeployedContract. A TemplateContract is conceived as a base to build other SCs. In particular, an AbstractSC is a TemplateContract representing a template code pattern (i.e., a partially implemented SC or a SC containing at least one function with no implementation). A TemplateContract is usually part of a registry publicly available on the Web (e.g., the OpenZeppelin registry for the Ethereum blockchain) for which Documentation is also provided. One or more = ⟨ : AbstractSC; : Solidity; 1 : ⟨health, {}, “the general condition of”;
body and mind”; ⟩; 2 : ⟨policy, {insurance}, “written contract or
certificate of insurance”; ⟩; : “The Health Policy SC specifies minimal data
which is mandatory to be recorded for health contracts”; [. . .] = { : {dateStart, dateEnd, liabilityLimit}, . . .}⟩ = ⟨ : AbstractSC; : Solidity; 1 : ⟨health, {}, “the general condition of body and . . . ”⟩; 2 : ⟨ injury, {hurt, harm, trauma}, “any physical
damage to the body . . . ”⟩; : “The Record Injuries Details SC provides base
functions to record injuries-related data”; [. . .] = {functions: {storeInjuryDetails, storeInjuryType}, . . .}⟩
TemplateContract may be employed to build (expressed through the extends relationship in
the model) a DeployedContract. As well, a TemplateContract can also be extended from
one or more TemplateContract. As the name suggests, a DeployedContract resides on
the blockchain. A DeployedContract can be either a ConcreteSC or a LibraryContract,
the latter conceived as a SC containing only callable functions, with no state variables. The
functions contained in a LibraryContract can be called by a ConcreteSC (function call
relationship).
∙ Semantic tags. To provide a semantic characterisation for SCs, semantic tags are fostered to
tackle both polisemy and homonymy issues of traditional tagging when searching SCs from the
registry. Semantic tagging is performed by those developers who add the SC to the registry.
During the assignment of tags, sense disambiguation techniques based on WordNet [
A tuple = ⟨ , { }, , , , ⟩ represents a SC ∈ , where: (i) is the type of the SC; (ii) { } is a set of semantic tags; (iii) is the name of the SC; (iv) is the coding language and (v) is a textual description for the SC. Contract-specific features, depending on , are included in the set (if any) and represented as pairs { : {}}.
Example. Let us consider Alice, a developer in charge of designing a DApp for the compensation process introduced in Section 2, on behalf of a HIO, to deploy the compensation process onchain. Specifically, Alice decides to structure her DApp according to two core SCs providing the functionalities to: (i) retain information regarding the policy terms of health contracts signed by individuals at the beginning of the trial with the HIO (called IndividualsHCContract); (ii) encapsulate all the rules related to compensation logic (called HIOCompensationContract). To develop the two former SCs, Alice resorts to the following two SCs already available in = [ = {IndividualsHCContract : (HealthPolicyContract), HIOCompensationContract : (AccessControlContract, PausableContract, RecordInjuriesDetailsContract)} 1 : ⟨ insurance, {indemnity}, “protection against
future loss”; ⟩; 2 : ⟨ payment, {}, “a sum of money paid or a claim
discharged”; ⟩; 3 : ⟨refund, {return, repay, give back}, “pay back”⟩; : prototype] (a) = ⟨0.8 (high confidence), {⟨HealthPolicyContract, , 0.8 (excellent)⟩, ⟨RecordInjuriesDetailsContract, , 0.7 (very good)⟩}.
(b) the registry: (a) HealthPolicyContract (in brief, HPC) which defines the minimum policy terms each health contract must hold to be eligible within the clinical trial, as demanded by the regulator subject; (b) RecordInjuriesDetailsContract (in brief, RID), providing the functions to record data related to the occurred injuries on the blockchain. An excerpt of the two descriptors for HPC and RID is reported in the Table 1.
Application Perspective. Let be the set of DApps built using SCs from the set . In the model, a DApp ∈ : (i) contains the set used to implement the DApp; (ii) has a set { } of semantic tags and (iii) is associated with technical features like the deployment status (e.g., prototype, live), the description and the URL where the DApp is accessible (if it is not a prototype).
Example. A DApp for the compensation process from Section 2 is described as in Table 2(a). SCs enclosed by round brackets are the ones coming from the registry provided by the trial regulator subject and are used for creating the two core ones. For instance, PausableContract and AccessControlContract are base SCs made available from the OpenZeppelin SCs web registry and are leveraged by Alice for developing her DApp in addition to the HPC and RID ones.
Experience Perspective. Each developer ∈ , who uses the SCs from the registry to
build her DApps, is modelled through: (i) the self-assessed skill in developing DApps; (ii) a set
of usage ratings ⟨ , , ⟩ expressing that the developer rated with a score ∈ [
To develop a DApp with the support of our framework, a developer performs three main steps: (i) assignment of a set of semantic tags to describe the functionalities of the DApp; (ii) search
Simple Advanced (Typified) Proactive (Typified)
Single Selection Target Completion Target
⟨{ }⟩ n.a.
(⟨{ }, {}⟩ ⟨{ }, {}, {}⟩ ⟨ , { }, {}⟩) (⟨ , { }, {}, {}⟩) n.a. ⟨{}, {}⟩ (⟨ , { }, {}⟩) of basic SCs from the registry and composition of these SCs in the DApp; (iii) assignment of a rating to the SCs from the registry used for the DApp. Among the three steps, the challenge we focus on regards the second step, for which we conceive iterative and progressive search scenarios for SCs, to compose incrementally the DApp. In a search scenario, we distinguish between the target and the modality, summarised in Table 3, as explained in the following.
The target of the search task could be a single selection (e.g., when the developer starts the design of a new DApp) or completion (e.g., looking for SCs to complete the DApp). Instead, the modality qualifies how the search is performed: (i) simple search: the developer looks for a SC by specifying only a set of semantic tags and it is meant for DApps in their early stage of development; (ii) advanced search: it is a variant of the simple search, fostered by a developer having in mind also the DApp, specified by a set of semantic tags, where the SC will be used and, possibly, a set of SCs already selected for the DApp. (iii) proactive search: the developer specifies only the semantic tags of a DApp and the set of SCs from the registry included in the DApp, expecting the system to provide suggestions about SCs to be added to the DApp, given similar DApps developed in the past by other developers. Proactive search is suitable for DApps already gathering at least one SC.
For advanced and proactive search, there is also the possibility for a developer to specify the of the desired SCs, thus resulting in a typified search (these variants are conceived for developers with advanced skill, having a clear idea about the type of SC needed). Search scenarios are guided through a set of similarity metrics as explained in the following. The general structure of a Smart Contract search request is defined as: = ⟨ , { }, {}, {}⟩ (1) where: (i) is the type of requested SC (only for typified search variants); (ii) { } is the set of semantic tags for the searched SC; (iii) {} is the set of semantic tags denoting the DApp and (iv) {} is the set of SCs already part of the DApp that is being developed, if any. The actual presence in a search request the of elements of Equation (1) depends on the type of search scenario (Table 3).
Example. If Alice from wants to find a SC aimed at handling exchange rate issues when corresponding the compensation amount for trial individuals in order to add this functionality to the compensation DApp, she may issue a request compliant with the completion target and advanced search: ⟨{ } = {⟨rate, {charge_per_unit}, “amount of a charge [. . . ]”, { }, { }⟩}.
Similarity metrics. SC search leverages the combination of diferent metrics, grounded on the elements of the request and the features retained in the SCs descriptors. In particular, we consider two distinct metrics, the semantic tag similarity and the DApp composition similarity, which are in turn exploited to compute the contract and DApp similarity, as explained in the following.
Semantic tag similarity. The semantic similarity between two tags 1 and 2 is assessed according
to WordNet, relying on hyponymy/hypernymy relationships between synsets and calculated
according to the widely adopted Wu-Palmer semantic similarity score. Based on this, a more
general similarity between two sets of tags 1 and 2, denoted with (1, 2) ∈ (0, 1]
can be be defined [
The overall similarity measure between the request and each SC (denoted with (, ) ∈ (0, 1]) is obtained as: 3 · (, ) + (1 − 3) || (︃ ∑︀|=1|( · (, , ) )︃
∑︁
·
(4)
| |
=1
||
where ∈ and the term multiplied by the factor (1 − 3), with 3 ∈ [
In the literature, recent research eforts have proposed frameworks for modelling SCs features
and enabling their subsequent search for DApps deployment. The reuse of existing SCs code for
the development of real-world DApps has been investigated in [
From a general point of view, our approach shares some issues with [
In this paper, we proposed a framework to search for smart contracts to develop distributed applications (DApps). The considered context is the one of collaborative processes where a regulatory subject, has an interest in stimulating the use of blockchain among the process participants. To this purpose, the regulator provides a searchable registry of basic smart contracts that can be used and extended to set up DApps. The framework, in addition to classification and technical features of smart contracts, takes into account the experience of developers who have already used the smart contracts of the registry to develop DApps. A preliminary implementation and evaluation of the proposed framework is in progress. Future research eforts regard the enrichment of the SCs model. Moreover, experiments will be conducted, comparing the performance of diferent variants of the searching procedure, including other sense disambiguation systems (for instance, DBPedia or Babelfy) for tags.