# A Model for Deriving Trust and Reputation on Blockchain-Based e-Payment System +
## 2 Related Work
### Blockchain System and Caching  
Our overall system is designed as follows. There is a blockchain-based electronic payment (escrow) system on which users can purchase products, make payments, and transfer money. In addition, the system allows the participating users to evaluate each other based on their satisfaction after every transaction. Then, not only the transaction data, but also the 'rating' information is recorded into the blockchain. These ratings are linked to their corresponding transactions within the blockchain after every transaction gets validated as if it is a transaction of its own in its virtual \"ratings\" currency. Once we have the transaction and rating information in the blockchain, trust and reputation can be calculated simply by parsing those information in the blockchain and applying our model in Sections 3.1-3.3. For example, Figure 4 shows the web interface screenshot for the list of all wallets and their respective reputation/trust model values in our prototype escrow system based on blockchain. Furthermore, Figure 5a is the web screenshot for the detailed trust/reputation information of an user, and Figure 5b lists all transaction history of that user. We have built our model into a real blockchain-based prototype system for online transactions (including escrow service and money transfer), and this system is now evolving into a new blockchain-based platform ([[http://nodehome.io](http://nodehome.io)]([http://nodehome.io](http://nodehome.io))) that is preparing to launch soon as a commercial service. Blockchain guarantees immutability, and thus the history is secure and reliable. However, parsing the whole blockchain for every transaction update would require significant amount of computation and time. For this reason, we propose to use a local cache that requires only a small footprint of key values for fast updates without the need for parsing all the previous transaction data per every transaction update that took place. However, there is a danger of local cache being out-of-sync with the original blockchain DB due to reasons such as system reboot, network disconnection, or even manipulation. To address this challenge, our system periodically validates and verifies the cache data in the _background_ for reliability without deteriorating user experience. Figure 4: Web interface screenshot for listing all wallets in our blockchain system. Figure 3: An example of indirect trust calculation between the “user” and the “target”, given that there is no direct trust (past transaction and evaluation) between the two. In this example, user A will be selected as the broker to calculate the indirect trust. If any inconsistency is found between the cache and the blockchain data, new information derived from the blockchain DB overrides the cache. This is based on the fact that we are using blockchain; an immutable and irreversible distributed legder, given that concensus has been made and longest chain has been selected. In our prototype implementation, this periodic refresh and update occurs every 5 min, in addition to whenever the system admin triggers an manual update. However, this period is configurable based on the application requirement and load on the system. Figure 6 illustrates this design where the cache is periodically updated from the blockchain DB. The user can access the cache for fast query response instead of parsing the whole blockchain which may take significant time depending on the amount of data. To give an idea of the impact of using cache, we measured the actual transaction update latency (which includes trust and reputation calculation) on our system with the dataset used in Section 4. Figure 7 plots the distribution of those latency measurements with (Figure 7b) and without (Figure 7a) the local cache. The two figures may look similar, but note the units of x-axis; they are three orders of magnitude different (seconds vs. milliseconds). This shows how critical it is to use the cache when looking up data in the blockchain DB.