A Blockchain-based Trust System for Decentralised Applications: When trustless needs trust

Blockchain technology has been envisaged to commence an era of decentralised applications and services (DApps) without the need for a trusted intermediary. Such DApps open a marketplace in which services are delivered to end-users by contributors which are then incentivised by cryptocurrencies in an automated, peer-to-peer, and trustless fashion. However, blockchain, consolidated by smart contracts, only ensures on-chain data security, autonomy and integrity of the business logic execution defined in smart contracts. It cannot guarantee the quality of service of DApps, which entirely depends on the services' performance. Thus, there is a critical need for a trust system to reduce the risk of dealing with fraudulent counterparts in a blockchain network. These reasons motivate us to develop a fully decentralised trust framework deployed on top of a blockchain platform, operating along with DApps in the marketplace to demoralise deceptive entities while encouraging trustworthy ones. The trust system works as an underlying decentralised service providing a feedback mechanism for end-users and maintaining trust relationships among them in the ecosystem accordingly. We believe this research fortifies the DApps ecosystem by introducing an universal trust middleware for DApps as well as shedding light on the implementation of a decentralised trust system.


Introduction
The turn of the last decade brought us to the disruptive Blockchain technology (BC) that provides a trusted infrastructure for enabling a variety of decentralised applications and services (DApps) without the need for an intermediary. To actualise this vision, Smart Contracts (SCs) technology is consolidated into the BC-based infrastructure: SCs are programmed to perform services' business logic, compiled into byte-code, and deployed onto a BC platform (i.e., replicated into full-nodes in the platform) so that a user can create transactions to execute the business logic implemented in the SCs in a decentralised fashion [9]. This infrastructural BC platform offers some advanced features including immutability, transparency, trace-ability, and autonomy that are promising to effectively implement plentiful DApps from financial services (i.e., cryptocurrencies trading) to numerous services such as digital asset management [1], provenance tracking in logistics and supply-chain [14,21], and data sharing and processing in the Internet of Things (IoT) [28,22].
Indeed, various DApps have already been developed and employed into the real-world. For instance, there are over 4000 DApps deployed on top of the Ethereum, Tron, and EOS platforms, serving about 150 active users daily in 2019 1 . This is a considerable ecosystem and a huge decentralised peer-to-peer (P2P) marketplace. Although there are numerous challenges due to the limitation of the current BC technology hindering the advancement of DApps, we believe

Features of DApps
There are different perspectives of DApps definition and system development among the cryptocurrency space. Nonetheless, mutual perceptions were pointed out that a DApp must satisfy some requirements: ( ) open source so that participants can audit the system, ( ) application operations and data are recorded and executed in a decentralised BC (e.g., using SCs), and ( ) a crypto token is used to access the service and to contribute to the operations (e.g., token reward) [18,8]. As of these features, ideally, DApps have the ability to operate without human intervention and to be selfsustaining because the participation of stakeholders is continuously strengthening the systems. According to Vitalik Buterin, DApps generally fall into two overlay categories, namely fully anonymous DApps and reputation-based ones [8]. The first category is DApps which participants are essentially anonymous and the whole service business logic is autonomously executed by a series of instant atomic operations. Pure financial services such as Bitcoin are examples of this. Another example is digital assets trading DApps such as software license, data, and digitised properties in which the ownership can be impeccably transferred once a contract (defined and implemented using SCs) has been performed [32].
The second category refers to a type of DApps which business logic requires a reputation-like mechanism to keep track of participants' activities for trust-related purposes. For instance, DApps for data storage and computation, similar to and in the centralised space, do require to maintain reputation-like statistic record of peers for service quality and security-related purposes (e.g., anti-DDoS). This requirement of trust is irrelevant to BC technology which supposedly ensures only data security (e.g, for distributed ledgers), autonomy and integrity of the business logic execution programmed in corresponding SCs. The quality of service (QoS) of such a DApp also depends on the service itself (i.e., how well the service handles the business logic defined in the SCs and caters to customers).

Necessity of a Trust System in DApps Ecosystem
DApps usage always comes with token movement from end-users to service contributors as a result of an incentive scheme, which is crucial to maintaining the service. However, due to the immutable nature, it is practically impossible to revoke any transaction once it is settled onto BC. Thus, a DApp has to make sure that end-users are dealing with trustworthy counter-parties before invoking any SCs' functions that can lead to a token payment. Intuitively, end-users tend to look for an indication of 'assurance' before using any services. Indeed, a variety of DApps share the same stance on a challenge of lacking a unified decentralised framework to evaluate the trustworthiness of participants (for instance, decentralised storage and computing (similar to cloud storage like and ), home-sharing (similar to ), car-sharing (similar to ), or a hotel distribution and reservation service (similar to . ) backed by a BC platform). Consequently, a trust middleware that supports DApps' end-users to transact with trustworthy counterparts is of paramount importance as it penalises deceptive participants while encouraging authentic ones. As illustrated in Fig. 1, DApps, built upon a BC platform empowered by a decentralised trust system, naturally build up trust with clients and create a virtuous cycles that bolster the whole DApps ecosystem growth.

Objectives and Contributions
Our objectives are to envision and develop a universal decentralised system that operates along with any DApps to evaluate trust relationships between entities in the ecosystem. This trust system plays as middleware between a BC platform and DApps that provides mechanisms for DApps' end-users to build up and maintain a trust relationships network among the users. Operations of the system are fully decentralised, transparent, and accessible to all of the participants which are autonomously and flawlessly executed in a trustless fashion. It is also expected to effectively prevent from reputation attacks (e.g., Sybil, White-washing, Selfpromoting, and Bad&Good-mouthing) and to dismiss masquerading hostile participants.
The main contributions of this paper are three-fold: • Introduction to the concept and provision of a universal decentralised trust system that can be integrated into any DApps sharing a same Blockchain platform.
• A decentralised trust model with theoretical analysis, algorithms, and simulations.
• Providing the whole agenda of the real-world development of the system including technical solutions, implementation reference, as well as performance evaluation.
The rest of the paper is organised as follows. Section II briefly brings up background and related work and presents the provision and conceptual model of a decentralised trust system. Section III describes a system design with a trust evaluation model for the proposed system. Section IV provides the algorithms and the theoretical analysis of the trust evaluation model. Section V is to discuss on the technical solutions and the implementation reference for the system development. Section VI is dedicated to the system analysis and discussion. Section VII concludes our work along with the future research directions.

Decentralised Trust System Provision for DApps Ecosystem
To craft a BC platform into a mature DApp development environment, fundamental elements must be incorporated such as an Identity Management (IdM), a name registry, a wallet, a P2P messaging for end-users, a browser, and a decentralised trust/reputation system [8]. These elements are core built-in services of a BC-based infrastructure for DApps development.

Related Work
A large number of trust management mechanisms that have been proposed in various environments including social networks [34], P2P or ad-hoc networks [2], and IoT [37,31,30]. Those trust models could be adapted to different scenarios including BC-related environment. However, as the emerging BC technology is in the early stage, there is limited research on trust management for DApps. Most of the related research is to develop a trust or reputation management platform leveraging the advantages of BC such as decentralisation, immutability, trace-ability, and transparency. In this respect, researchers have proposed BC-based trust mechanisms to fortify specific applications in various environments including vehicular networks and intelligent transportation systems [38,12], wireless sensor networks [24,29], or IoT [13,20]. For instance, W. She et al. in [29] have proposed a BC-based trust model to detect malicious nodes in wireless sensor networks by implementing a voting mechanism on-chain, ensuring the trace-ability and immutability of voting information. M. Debe et al. have developed a reputation-based trust model built on top of Ethereum platform for fog nodes in a Fog-based architectural system [6]. The idea is similar in that a reputation mechanism, comprising of several SCs, is implemented on top of Ethereum platform so that clients can give feedback as ratings toward a Fog node when using a service provided by such node. The reputation of a fog node is simply accumulated on-chain from users' ratings. Being executed on-chain, such ratings and reputation values are immutably recorded in a decentralised fashion, thus ensuring data integrity as well as preventing from Denial of Service (DDoS) attack.
We, instead, look at a different angle of trust in BC-based applications in which a trust system plays a complementary component of the BC platform that cooperates with DApps to empower the ecosystem built on top of the platform. We target to develop a trust system for decentralised services in a BC ecosystem (e.g., Ethereum) in which participants (clients and service providers) interact with each other on-chain in a P2P manner. Our system plays as a unified trust solution working with any DApps. Our previous research in [32] has presented an introductory concept of a unified trust system to strengthen a BC platform. However, it has come without detailed analysis, algorithm, and technical solutions for the development of the decentralised trust system. In this paper, we further explore the concept and the feasibility of a unified trust system as middleware between a BC platform and DApps, as well as provide a proof-of-concept of the decentralised trust system along with the system design, algorithms, technical solutions and implementation reference.

High-level architecture of BC-based infrastructure and Trust System
For a better understanding of the big picture of the whole BC-based infrastructure including the proposed trust system, we represent the high-level architecture of a full-stack IoT infrastructure by harmonising these components to the IoT and Smart Cities & Communities reference model 3 . As can be seen in Fig. 2, the BC platform is located in the Service Support and Application Support layer, which is a layer between the Application and Network layers in the IoT architecture. DApps is located in the Application layer. Unlike clientserver applications and services whose reputation/trust systems are separately developed, we envisage that DApps in 3 http://itu.int/en/ITU-T/studygroups/2017-2020/20/Pages/default. aspx the same ecosystem could leverage a universal trust system, which serves as a fundamental service for the BC-based infrastructure (Fig. 2). This trust middleware exists because DApps' end-users in an ecosystem are identified by the same IdM and a name registry, and use the same cryptocurrency (e.g., provided by a BC platform) to consume the services.

High-level Architecture of Trust System
In this sub-section, fundamental elements of a decentralised trust middleware between a BC platform and DApps are described. As can be seen in Fig. 3, the proposed system consists of two basic components named Data Collection & Extraction and Trust Evaluation that collect and aggregate necessary trust-related information and evaluate trust relationships, respectively. These two components are along with North-bound and South-bound APIs for providing trustrelated services to DApps and for collecting data from a BC or applications and services, respectively.

Trust Evaluation Mechanism
We adopt the REK trust model proposed in [31,30] to the DApps ecosystem scenario in which both and are end-users of DApps. In the REK model, a trust relationship is evaluated by assembling three indicators called Reputation (of the trustee), Experience and Knowledge (of the trustor toward the trustee). In DApps scenarios, there is limited availability (or difficult to obtain) of off-chain information (i.e., information that is recorded outside BC) of endusers for evaluating Knowledge indicator as users' identity is normally pseudo-anonymised and challenging to link to outside world [23]. Instead, transactions between end-users are immutably recorded (and publicly available) on-chain, which can be leveraged for Experience and Reputation evaluations. As a result, in this paper, we employ an adoption of the REK trust evaluation model called DER which only utilises two indicators Experience and Reputation in decentralised environment. Details of the DER trust system is described in the next section.
Generally, after each transaction between entities in a DApp, the trust system enables a participant to give feedback toward its counterpart, thus establishing and updating the Experience relationship between the two. By doing this, the trust system maintains an Experience network among participants, which is publicly recorded on-chain. This Experience network is autonomously updated whenever an entity gives feedback to the other. Reputations of all participants are then calculated accordingly, following the idea of Google Rage-Rank algorithm. Finally, the trust value between two entity is calculated as composition between Experience and Reputation.

Data Collection and Extraction
By nature, a BC is a record of a continuous growing list of transactions among end-users which can be analysed to extract a network topology of end-user interactions. Nonetheless, further information about QoS is required to be collected and aggregated in order for the DER trust evaluation mechanism to be performed. Therefore, a decentralised feedback mechanism associated with DApps in a BC platform is required to reflect QoS once end-users (e.g., service clients) successfully carry out transactions with their counterparts (e.g., DApp providers). This mechanism creates a distributed ledger that logs users' feedback (toward a DApps service) along with the information about associated transactions (e.g., end-user ID ( address), counterpart ID ( address), and ). Feedback can be either implicit or explicit which may or may not require human participation [17]. The trust system then extracts feedback and transactions information recorded in BCs as inputs for the DER trust evaluation model (i.e., calculate the Experience and Reputation indicators) in order to evaluate trust relationships between any two peers in the decentralised ecosystem.

Use-cases
For better explanation and clarification, we scrutinise the decentralised data storage services (DDS), in regard to some projects being developed and implemented in the real-world like Storj 4 , Sia 5 , and Filecoin 6 (built on top of the Inter-Planetary File System 7 (IPFS)). Decentralised storage is a promising solution to cooperate or even to take over the conventional centralised cloud storage where data is split into multiple chunks and distributed to storage nodes across a P2P network. These storage nodes, as DDS providers, are expected to reliably store the data as well as provided reasonable network bandwidth with appropriate responsiveness for data owners to retrieve their data. As a reward, such storage nodes are incentivised by crypto tokens. It is worth noting that end-users in DApps ecosystem can be both data owners (DDS clients) and storage nodes (DDS providers). The decentralised storage concept is similar to the legacy P2P file sharing such as BitTorrent 8 but fortified with advanced cryptography and encryption mechanisms as well as incentive schemes built upon a BC platform. It is expected to solve the long-standing challenges of single-point-of-control and -failure in centralised data silos, and to bring essential control of data back to the owners whilst discharging full control of cloud server managers. The DDS deploys necessary SCs on top of a BC platform to execute the business agreement between DDS clients (i.e., data owners) and DDS providers (i.e., storage nodes) such as storage space and period, guaranteed performance (e.g., availability, throughput, bandwidth, and latency), and the Incentive scheme (i.e., Token Reward) (Fig. 4). Unfortunately, such SCs are unable to ensure the QoS of the DDS service provided by a set of storage nodes because (i) it is impractical for the SCs to monitor and enforce the performance of the DDS providers, and (ii) the guaranteed performance can only be measured once the SCs are already invoked. In this regard, a trust system that manages the performance history of the storage nodes and ranks them in order of trustworthiness (to provide high QoS) is of paramount importance. 4 https://storj.io 5 https://sia.tech 6 https://filecoin.io 7 https://ipfs.io 8 https://en.wikipedia.org/wiki/BitTorrent

DER Trust Model
In the proposed DER model, trust relationship between two entities is a compound of two elements: Experience (of the trustor toward the trustee) and Reputation (of the trustee). This section describes the mechanisms to calculate such two elements.

Experience mechanism
Experience is an asymmetric relationship from an entity to the another which is built up from previous transactions between the two. Experience is an indicator of trust [31]. For instance, an experience (denoted as ( , )) is constituted from a DDS client (i.e., a data owner, denoted as ) to a DDS provider (i.e., a storage node, denoted as ) once invokes an SC to use the storage service offered by . Higher ( , ) value represents higher degree of trust from to . Essentially, ( , ) increases if provides high-quality storage service to (which is reflected by a feedback score ) and vice versa. It is worth noting that feedback can be provided by either clients (e.g., ) or an authorised third-party who is monitoring performance of service providers (e.g., ). Also, ( , ) gets decay if no transactions taken place after a period of time or a transaction is neutral (i.e., neither cooperative nor uncooperative). The amount of increase, decrease and decay depends on intensity of transactions, feedback scores , and the current value of ( , ) which can be modelled by linear difference equations and a decay function as follows (notations are denoted in Table 1) [31,30]: • Increase model

The current
( , ) (denoted as −1 ) increases when there occurs a cooperative transaction (at the time , indicated by the feedback score ≥ ) that follows the linear difference equation: where Δ is defined as follows: • Decrease model Similarly, ( , ) decreases if the transaction is uncooperative (indicated by the feedback score ≤ ), following the equation: in which Δ is specified in Equation (2). The decrease rate > 1 implies that it is easier to lose the ( , ) value due to an uncooperative transaction than to gain it (by a cooperative transaction).
• Decay model ( , ) decays if there is no transaction after a period of time or a feedback is neutral (i.e., < < ) and the decay rate is assumed to be inversely proportional to the strength of the experience relationship (i.e., value) [27]. Based on these observations, the Decay model is proposed as follows:

Reputation mechanism
The reputation of an entity represents the overall perception of a community regarding the characteristic of the entity such as trustworthiness. In the DApps ecosystem, the reputation of an end-user (denoted as ( )) can be calculated by aggregating ( , ), ∀ are users who have already been transacted with . To calculate the reputation of end-users, we utilise the model proposed in [31,30] which is based on the standard PageRank [7] and the weighted PageRank [35,33].
Let be the number of end-users in the DApps ecosystem, an directed graph ( , ) is constructed in which is a set of users, ( , ) satisfying ( , ) < , where is a predefined threshold. parameter is a damping factor (0 < < 1) introduced in standard PageRank [7]. The reputation for each sub-graph is then calculated as follows: • Positive Reputation representing the sum of all positive experience values that the end-user holds (toward other end-users).
• Negative Reputation in which representing the sum of all complements of negative experience values (i.e., 1 − ( , )) that the end-user holds (toward other end-users).

Trust Aggregation
Trust relationship between trustor and trustee is a composite of ( , ) and ( ): in which 1 and 2 are weighting factors satisfying 1 + 2 = 1. It is worth noting that any end-user once signing up for a DApp is assigned a default value at bootstrap (e.g., 1 ). If and have no prior transaction then ( , ) = 0. In this case, 1 = 1 and 2 = 0; thus, ( , ) = ( ).

Trust Model: Evaluation and Simulation
This section provides detailed evaluation of the DER trust model including model equations analysis, algorithms, and simulation of the Experience and Reputation models.
As the Increase model is monotonically increasing, it is obvious that the Decrease model defined in Equation 3, which is based on Δ in Equation 2, is decreasing. The decrements depend on the current value and the uncooperative feedback score. The decrease rate depicts the ratio of the decrements compared to the increments, which is normally greater than 1 as the current experience is "difficult to gain but easy to loose".
The Decay model defined in Equation 4 ensures that an experience relationship gets weakened if there is no or neutral transactions after a period of time. This is because the decay value Δ specified in Equation 5 is always > 0 as 0 < −2 < 1 ∀ ≥ 2; and it is inversely proportional to −2 , implying that a strong relationship persists longer than a weak one.

Algorithm and Simulation
Based on the Experience model defined in Section 3.2.1 along with the analysis, the algorithm calculates experience value ( , ) of entity toward entity is demonstrated in mathematical-style pseudo-code as in Algorithm 1. It is worth noting that the parameters controlling the Experience model are preset for our demonstration and should be optimised for specific scenarios.
For demonstration purposes, the algorithm is implemented in with different controlling parameters settings. As The initial value is preset 0 = 0.5. As can be seen in Fig. 5, the results show that both increase model curves are asymptotic to 1, which is already proven in the theoretical analysis, at different rates depending on the controlling parameter . The results also indicate that stronger experience relationships require more cooperative transactions to achieve. For instance, with = 0.05, expe-rience value increases from 0.5 to 0.7 after 12 consecutive transactions whereas it increases from 0.9 to just 0.94 after the same number of transactions.
The simulation results of the Decrease model show that experience relationships are prone to uncooperative transactions suggesting that a strong tie is hard to attain but easy to lose, particularly with higher decrease rate . For instance, with = 0.05 and = 4.0, it takes 50 consecutive cooperative transaction to increase the experience value from 0.5 to 0.9 but takes only 22 uncooperative transactions to drop from 0.9 to 0.5. As can also be seen from the figure, both decrease and decay models exhibit a same behaviour that a strong tie is more resistant to uncooperative transactions/decay whereas a weaker one is more susceptible. These characteristics of the experience model manifest the human social relationships, showing the practicability of the proposed model.

Analysis
Denote ( ×1) column vectors , , and whose elements are overall reputation, positive reputation, and negative reputation of end-users in DApp ecosystem, respectively. As specified in Equation 6, ( ) of the user is calculated from others' positive reputations ( ) ∀ holding positive experience ( , ) with . Consequently, there would be correlations among the positive reputations, which would lead to the fact that might not exist or might be ambiguous (i.e., there exists more than one values for a user that satisfy Equation 6). The same condition could happen for , and for , as a consequence.

Lemma 4.2. The reputation vector exists and is unique.
Proof. According to Equation 8, exists and is unique if both and exist and are unique. The positive experience × matrix is constituted as follows: Let us constitute an × diagonal matrix  whose diagonal elements = ( ), ∀ ∈ {1, .., } and a matrix  is a × all-ones matrix.
Based on Equation 6, can be represented in matrix notation as follows: Let us define the matrix as follows: Thus, Equation 16 can be re-written: From Equation 18, we can see that is the of matrix with the = 1. Let us define a matrix = ; thus = . Therefore, Equation 18 can be re-written as follows: Equation 19 implies that is the stationary distribution of a chain whose transition probability matrix is . Let us constitute a discrete-time chain with the transition probability matrix = consisting of states and the probability to move from state to state is ( , ). Note that ∀ , ∈ {1, .., }, we have: The Markov chain can then be constructed as follows: where is the threshold to differentiate positive and negative experiences. This chain is a model of random surfer with random jumps over the experience relationships directed graph ( , ) [25,5,10]. The graph ( , ) is strongly connected with no dangling nodes. This is because any two nodes ( , ) with no prior transaction is set ( , ) = 0, implying that the edge weight is 0; it does not mean there is no connection. This random surfer Markov chain, apparently, is a weighted PageRank model; as a result, its stationary distribution, , exists and is unique [5,10,15].
Similarly, vector exists and is unique. Therefore, the overall reputation vector exists and is unique.

Algorithm and Simulation
As the existence and the uniqueness are proven, the reputation vector of end-users in DApps ecosystem can be calculated by solving the matrix equations defined in Equations 6, 7. The traditional algebra method to solve an matrix equation (e.g., Equation 6 or Equation 7), whose the complexity is ( 3 ), is impractical when the size of the DApp ecosystem is enormous (e.g., in millions). Instead, the reputations of the end-users can be approximately calculated with a predefined accuracy tolerance using an iterative method, which is much more efficient [3,19]. Thus, the latter approach is utilised to solve Equations 6 and 7, demonstrated by the following pseudo-code (Algorithm 2). As defined in Equation 8, the overall reputation for end-users (i.e., × 1 column vector ) is then simply obtained by adding two vectors and , which are the outputs of Algorithm 2.
The simulation of the proposed reputation calculation algorithm are conducted for different DApp ecosystem sizes (i.e., = 1000, 4000, 8000 and 16, 000) with the error  Figure 6: Convergences of the reputation algorithm using interactive method with different sizes of DApp ecosystem tolerance = 10 −5 , which is accurate enough to rank end-users in the DApp ecosystem. As depicted in Algorithm 2, the total error is calculated as the Euclidean norm of the vector difference of the vector in two consecutive iterations. Fig. 6 illustrates the convergence rate of the algorithm, showing the rapid reduction of the total error as more iterations are carried out. As can be seen from the figure, the algorithm converges in less than 70 iterations (to be exact: 54, 61, 64, and 66 iterations) for four DApps ecosystem sizes = 1000, 4000, 8000 and 16, 000, respectively. These results suggests that the reputation model well scales for a huge network as the scaling factor is roughly linear in .

Technical Solutions and Implementation
This section provides a real-world demonstration for the proposed decentralised trust system and how a decentralised storage service interacts with it. The demonstration is carried out on top of the Ethereum permissionless BC platform in which system components, functionality, technical challenges and solutions are identified as the implementation reference for developers who wish to build a similar system. Source-code of the demonstration can be found here 9 . Smart Contracts source-code is in the ∕ ∕ ℎ − folder of the repository.

System Setup
The DDS service and the proposed decentralised trust system are implemented on top of the permissionless Ethereum platform to which fundamental elements for developing a DApp have already been deployed. For instance, in our platform setup, Ethereum and are leveraged for IdM, 10 is for BC browser and a wallet service, and 3∕ 3 11 are DApps APIs for interacting 9 https://github.com/nguyentb/Decentralised_Trust_Eth_IPFS.git 10 https://metamask.io/ 11 https://github.com/web3j/web3j with Ethereum network (e.g., SCs and end-users). SCs are implemented in Solidity using Truffle suite framework 12 and deployed in an Ethereum test-net (i.e., we use several testnets including , , and ) for real-world experience. We assume that IPFS storage nodes are also clients of the DApps ecosystem (e.g., Ethereum clients in , or test-net) that get incentivised once providing storage capability (e.g., IPFS storage nodes ℎ and the hash of requested files from data owners). The overall procedure of the setting system is illustrated in Fig. 7. As can be seen in the sequence diagram, a client starts to use the DDS service by making a transaction to a DDS SC (step (1)), which invokes enFeedback function in FeEx SC of the trust system to grant the client permission to give feedback to the DDS nodes ((step (3)), (4))). Once getting feedback from the end-user (step (5)), experience relationships between the user and the DDS nodes are updated on-chain by executing expCal function in FeEx SC (step (6)). On the contrary, as the reputation calculation is resource-intensive, it is impractical to implement the algorithm (i.e., Algorithm 2) on-chain; instead, only the results (i.e., reputation values of entities) are publicly recorded onchain. This challenge can be circumvented by using Oraclize service, as demonstrated in step (7-1), (7-2), and (7-3) in Fig.  7. With the same reason, Rep SC is not invoked whenever an experience relationship is updated; instead, it is periodically self-executed -for example, for every 100 blocks.

Feedback and Experience Smart Contract
This SC, denoted as FeEx, contains feedback information and experience relationship of any entity (i.e., a DDS client) toward entity (an IPFS storage node) where a transaction between and has been carried out (i.e., uses the DDS service provided by depicted by step (1) and (2) in Fig. 7).
SC also provides functions for end-users to give feedback and to update experience relationships accordingly. Note that and are identified by Ethereum in the ecosystem.

Ledger Data Model
Necessary information about users' feedback and experience relationships is permanently recorded on-chain using state variables defined in FeEx SCs. These state variables are as a public distributed ledger comprised of the full history of state transitions of all experience relationships between any two entities. It is convenience to obtain the latest information of any experience relationship as Ethereum supports key-value data format and the latest state of the ledger (recording the most recent experience relationships information) can be found in the most recent block.
FeEx SC stores a state variable, called FeExInfo, in its contract storage in form of nested key-value pairs using Ethereum built-in type as follows: struct FeExStrut { uint expValue; uint fbScore; bool perFlag; } mapping (address=>mapping (address=>FeExStrut)) public FeExInfo; FeExInfo consists of information about the relationship from toward , specified in FeExStrut data structure: (ii) ( , ) value, (iii) feedback score, and (iv) a flag indicating whether has permission to give feedback. Any parties or SCs can easily access FeExInfo recorded on-chain to obtain desired information for their purposes.

Functionality
The FeEx SC contains two main functions: (i) enFeedback enables/revokes permission of a data owner to give feedback to storage node by updating the permission flag in FeExInfo with associated transaction ID; and (ii) calculates ( , ) value and updates FeExInfo whenever gives feedback to . The enFeedback function is called by by an SC of the DDS service once a transaction has been carried out (illustrated by step (3) in Fig. 7).
The implements the experience calculation function following Algorithm 1 proposed in Section 4.1. It is worth noting that as there is no global time server synchronised among nodes in the Ethereum BC platform so that the implementation of the decay model is not straightforward. To circumvent this challenge, determines in Algorithm 1 using block height ( . property) so that ( , ) decays every a number of blocks if no transaction occurred between and during the period.

Ledger Data Model
Reputation SC, denoted as , records positive reputation and negative reputation of all users (e.g., IPFS storage nodes) using two state variables RepPosInfo and Rep-NegInfo, respectively. The data model for the two state variables is a mapping between a user' address and a value: mapping (address => uint) public RepPosInfo; mapping (address => uint) public RepNegInfo; These two state variables play the role of a public distributed ledger permanently recording a full history of state transitions of the positive and negative reputation of all users.

Functionality
The reputation calculation algorithm (Algorithm 2) performs matrix multiplication with numerous iterations that requires a large number of operations and local variable manipulations. Consequently, the resource-consumption and the cost for executing this algorithm on-chain are extremely high, which is infeasible to be implemented in SC. To bypass this challenge, off-chain storage and calculations appear as a promising solution. The catalyst of this solution is that high-volume data and resource-intensive tasks should be stored and processed off-chain; only results of the off-chain tasks are piggybacked for on-chain ledgers and/or calculations. However, as an SC must be deterministically executed, there might be a room for ambiguity if SC executions rely on information from off-chain sources. In addition, this practice could turn a decentralised system into a centralised one due to the dependency on an external source of information. This dilemma is known under the term: "Oracle problem" [36]. The following section will describe in detail how SC can accomplish the off-chain reputation calculation while mitigating the Oracle problem.

Off-chain Computation for Reputation
Oracle problem could be mitigated by leveraging a decentralised trusted provider to feed required data into SCs. For instance, Oraclize 13 deploys an SC on Ethereum platform as an API for other SCs to interact with the outside world 14 . The Oraclize SC works as a bearer that gets required data from an external source and delivers the data to the requested SCs in a decentralised fashion. Furthermore, to alleviate the ambiguity, it (ii) provides authenticity proof as an assurance for data integrity. In the implementation, we follow this Oraclize solution to calculate users' reputations off-chain.
Assume that there is already an off-chain server, called RepCalService, that implements Algorithm 2 to calculate positive and negative reputations and provides an API (e.g., REST API) to retrieve the calculation results. The implementation of this off-chain service is straightforward: it queries the Ethereum BC to obtain experience relationships stored in FeExInfo and the current reputations values from RepPos-Info and RepNegInfo state variables as inputs for Algorithm 2.
SC then periodically calls this service to update the reputation values in a decentralised fashion using Oraclize solution. The below implementation reference shows how to execute these tasks.

Integration of DDS service and Trust System
Supposedly, the DDS service implements some SCs for data storage business logic between data owners and storage nodes, which is out of the scope of this paper. The main focus of the paper is that once a transaction has been accomplished between a client and an IPFS storage node, the en-Feedback function in the is invoked that enables the owner to give feedback to its counterpart, which will establish experience and trust relationships (step (2) in Fig. 7). For this reason, a DDS SC (i.e., the caller SC) defines an interface of SC (i.e., the callee SC) and calls it with the callee's contract address as demonstrated as follows: Similarly, when a data owner gives feedback toward a storage node (with value ), DDS invokes function that calculates the experience relationship between the two and updates FeExInfo accordingly. In the demonstration, feedback scores are randomly generated; however, in the real-world scenarios, a function to measure DDS QoS shall be implemented to correctly reflect the service quality. As Solidity supports interactions between SCs deployed on Ethereum platform, the proposed trust system is feasibly actualised as any DApps including DDS can be incorporated by invoking public functions or accessing trust-related information from state variables defined in the SCs of the proposed trust system.
Finally, to reinforce service quality for a client, the DDS service queries RepPosInfo, RepNegInfo and FeExInfo stored at and SCs, respectively, to receive reputation and experience values related to this client. The DDS service then aggregates this information for finalising trust values between the client and the storage nodes and provides the most trustworthy counterparts to the client.

System Analysis and Discussion
The demonstration system presented in Section 5 is a proof-of-concept of a universal decentralised trust system which is incorporated into a BC infrastructure as an underlying service for supporting DApps. This section investigates and discusses on the practicality, performance, and securityrelated aspects of the proposed trust system.

Feasibility and Performance Evaluation
Practically, a variety of factors should be taken into account when deploying the trust system into real-world usages. For instance, cost for SC execution in Ethereum Virtual Machine is high as such SCs requires high volume storage for the state variables, as well as numerous operations and local variable manipulations in SC and the cost for using Oraclize service in SC. This calls for further research on SC optimisation [11] and better off-chain storage and calculation solutions.
As most of SCs, including and SCs, are dedicated to performing critical tasks with minimal storage and computation, the performance of a DApp is heavily dependent on the BC platform but not the application built on top. At present, permissionless BC platforms offer limited performance in terms of both throughput and/or scalability. For instance, Bitcoin and Ethereum main-net only handle about 7 and 15 transactions per second 15 ). In order to illustrate the real-world performance, we deploy our system to different BC platforms, i.e., Ethereum test-nets namely Ropsten, Kovan, Rinkeby, and Goerli. We carry out latency measurement of both READ and WRITE transactions to the ledger FeExInfo in the FeEx SC in the four test-nets. The results are shown in Fig. 8. The performance measurement script can also be found at the same repo 16 .
It is worth noting that in READ transactions, an Ethereum platform does not perform the consensus mechanism; instead, in WRITE transactions, consensus mechanism (i.e., Proof-of-Work (Ethash) in Ropsten, Proof of Authority (Authority Round) in Kovan, Proof of Authority (Clique) in both Rinkeby, and Goerli) is carried out as the state of the ledger is changed. In details, WRITE transactions require further complicated processes including block formulation and mining, broadcast the mined block to peers in the network, block verification, and updating the ledger. This is why the latency of READ transactions is much smaller than WRITE transactions, reassured by the results in Fig. 8. As can be seen in the figure, the average latency of READ transactions is roughly the same in all four test-nets at around 350-420ms with relatively small standard deviations. This indicates the consistency when querying data from the ledger. Compared to READ transactions, the average latency in WRITE transactions is significantly risen to 6013, 10376, 16973, and 17727 , which is 15 to 42 times higher, in Kovan, Rinkeby, Goerli, and Ropsten, respectively. The standard deviations, however, are different in the four test-nets: Ropsten and Goerli introduce considerably higher WRITE latency compared to Kovan and Rinkeby (2 − 3 times) but WRITE transactions are more stable as the standard deviations are small. Particularly, in Rinkeby test-net, the standard deviation is substantially high -The latency spreads out in a wide range, from 4500 to 17350 ms.
Results also show the block latency 17 in WRITE transactions in the four test-nets. In Kovan and Rinkeby, WRITE transactions are almost appended and confirmed in the next block demonstrated by block latency is close to 1 whereas in Goerli and Ropsten, it could take one or two more blocks before the transaction is written onto a new block. This is probably one of the reasons that the latency in Goerli and Ropsten is higher than in Kovan and Rinkeby.
Results of the system latency indicate the technical barrier on Ethereum-based system performance, which limits the usability of the proposed decentralised trust system to serve only small-scale services. Note that unlike the other test-nets, Ropsten performs Proof-of-Work consensus mech- 17 The number of blocks increase counted when a transaction is broadcasted to the network until it is confirmed (written in the latest block). anism, similar with the Ethereum main-net, thus, it best reproduces the Ethereum production environment. Nevertheless, besides SC optimisation for individual DApp, system performance immensely relies on an underlying BC network which requires further research on consensus mechanisms [40], off-chain [26] and sharding solutions [39], etc. for a better DApp ecosystem.

System Security
The advanced capability of BC platform plays a key role in providing a secure and trustworthy environment for DApps. Although current BC and SC technologies still pose both performance limitations and security threats, we assume that the decentralised nature of the BC ensures there is no adversary can corrupt the BC network and change the content of the ledgers as this would imply majority of the network's resources are compromised. Besides, there is no adversary who can impersonate another entity as the public-key cryptography (e.g., Elliptic Curve Digital Signature Algorithm (ECDSA) used in Ethereum) cannot be forged.
Security threats in our proposed decentralised trust system are from typical reputation-related attacks such as Selfpromoting, Slandering (good/bad mouthing), and Whitewashing [16]. In our system, in order to be able to provide feedback, entity is required to make a transaction toward the counterparty, which costs some fee, at least transaction fee. Importantly, the proposed reputation mechanism itself can mitigate such reputation attacks. For instance, if a newly-created entity (thus its reputation value is minimal), makes a transaction, and then gives bad/good feedback toward a victim; the contribution of this feedback to the reputation value of the victim is minimal. This is because the reputation value of the victim is calculated based on both experience and reputation score of participants who transact with the victim (indicated in Equation (6) and (7) ). Obviously, if an entity is high-reputed (thus, probably not malicious) then the contribution (to one's reputation) is huge. Generally, our reputation mechanism shares the same characteristics to Page-rank algorithm in Google web-ranking engine: it is not easy to increase the ranking of a web-page by creating lots of new web-pages and link to it [4]. The nature of any feedbackbased reputation systems is that it is impossible to fully prevent from such reputation attacks; however, we believe our approach can well mitigate these behaviours.

Conclusion
In this paper, we have provided a comprehensive concept, system model and design of a decentralised trust system for DApps ecosystem along with detailed analysis, algorithms, and simulations actualise the DER trust model. Foremost, we have developed a proof-of-concept system implementing the DER trust model on top of the Ethereum permissionless BC. The trust system is then able to incorporate with the DDS service for supporting data owners to select trustworthy storage nodes.
We have also provided technical difficulties along with prospective solutions as well as the implementation refer-ence in the development of the proposed decentralised trust system. Existing technical barriers are also outlined which need further efforts to be successfully solved. We believe our research significantly contributes to further activities on trust-related research areas and open some future research directions to strengthen a trustworthy DApp ecosystem. Dr