Security analysis of smart contract based rating and review systems: the perilous state of blockchain-based recommendation practices

Abstract

Nowadays, Blockchain-based rating/review systems are gaining popularity as a backbone for recommender systems due to the inherent cryptographically secured decentralised architecture, immutability, user anonymity, and inclusion of smart contracts. However, the existing Blockchain-based rating/review systems address resistance to the standard attacks, i.e. collusion attack, user threatening, and unfair rating. Still, they do not present security analyses of smart contracts that may result in substantial threats to the users of the systems. This manuscript presents an in-depth study of twelve publicly available security analysis tools and standard vulnerabilities in smart contracts and reviews. The experimental setup uses a two-step approach for selecting the security analysis tool. The first step identifies the seven tools their proposers or independent researchers have compared, and the second step proposes a new method for selecting tools based on continuous improvement. Our experimental results show security issues in 51.72% of the analysed smart contracts of four Blockchain-based rating/review systems. 6.67% of vulnerable smart contracts exhibit high-level severity threats that raise an alarming condition for the current state of system developments.

KEYWORDS:

• Recommender
• smart contracts
• security
• rating
• review

1. Introduction

Nowadays, the digitalisation of commercial and non-commercial activities with the ease of internet reachability has resulted in the unprecedented growth of online information (Zhou et al., 2021). Users of the system can use this data in decision-making (e.g. which movie should I rent? Which book should I purchase? Which food should I order?). It is cumbersome for the users to investigate the vast amount of data. Recommender systems ease consumers’ tasks by suggesting more relevant items using the ratings and reviews provided by users, preferences, and personal information (Beloglazov et al., 2012). The well-known commercial systems, e.g. YouTube, Amazon, etc., widely use recommender systems (Liu et al., 2021). On the other hand, service providers may get increased revenue per their ranking and cross-product references. Most of these systems focus on accuracy of recommendations. The current types of threats e.g. modifying user ratings, promoting paid products in cross reference have drawn the attention of researchers.

The efficiency of the recommender system depends on the underlying used algorithm to compute the score and the collection of user ratings (e.g. ordinal range [1,5] or unary [Like]) and user feedback (Kalaï et al., 2018) showing the opinion of the users. Thus, A rating and review framework is an integral part of recommender systems. Most of the currently used frameworks and systems have a centralised architecture that presents substantial threats to the system users, e.g. falsifying recommendations, deletion of negative feedback, user retaliation, etc. The unprecedented growth in data volume leads to outsourcing the data on cloud storage. It introduces data integrity verification issues due to a third-party auditor (Li et al., 2021).

Blockchain is a near relative of the early age research on cryptocurrencies that introduces decentralisation, transparency, immutability, auditability, and anonymity (Zheng et al., 2018). Data on blockchain is scattered on each node. A new node in the network can sync itself and download the longest chain of blocks, making it a completely decentralised and transparent system. Blocks in the chain are linked using the previous block's hash, which requires iterative modification of all blocks before the attacked block of data making it immutable. The accounts in blockchain are identified by a pair of public and private key pair that introduces anonymity in the system. It implements decentralised trust using consensus protocols and gets manifested as the first secure generation of a cryptocurrency named bitcoin, which addresses two significant issues of double spending and the byzantine general's problem (Alharby & van Moorsel, 2017; Khan & Salah, 2018).

Smart contracts are programmes on blockchain that exhibit self-verifying and self-executable behaviour and can model a paper contract digitally. In simpler words, it is a programming code that executes in the backend of Dapps and alters Dapp's state (Borges et al., 2022). It extends blockchain applications in domains, e.g. security, IoT, public service, finance, healthcare, vehicle ad-hoc networks, and reputation systems (Khan & Salah, 2018; Martínez et al., 2022; Tewari & Gupta, 2020; Zhang & Xu, 2022). This incorporation is still required to find the applicability to address issues, e.g. rumours preventions, adversarial attacks, Botnets, etc. (Mani et al., 2021; Martínez et al., 2022; Srinivasan & LD, 2019; Alieyan et al., 2021), in the parental systems. There is no need for cryptocurrency to create and function a blockchain (Christidis & Devetsikiotis, 2016).

1.1. Motivation

A smart contract consists of account balance and storage, which can be read and written by sending a message or a transaction to that contract. In addition to that, it can send messages to other contracts resulting activation of a new contract.

It creates a layer of issues related to code a valid smart contract on the complex state machine. The first issue is that a smart contract has unintended behaviour, and it may be a result of a logical error in the code that can cause a leak of currency in corner cases (Bhargavan et al., 2016; Bigi et al., 2015; Delmolino et al., 2016; Frantz & Nowostawski, 2016). The second issue is sending the input in cleartext. It gives opportunities to malicious users on the network to see the input as transactions are broadcasted on the network (Delmolino et al., 2016). The third issue lies in the immutability feature of Blockchain, which thwarts modification and termination of smart contract, which is applicable on paper contract under legal laws (Bhargavan et al., 2016). The fourth issue is the under-optimized smart contracts where costly gas patterns inhabit and result in more gas consumption than necessary (Chen et al., 2017). Researchers found that more challenging issues mean severe vulnerabilities, leading to an attack, resulting in substantial financial losses.

Recent studies showed a decentralised control model for the recommenders by adopting blockchain technology using smart contracts. Following that, a few decentralised rating/review systems have been proposed gaining an advantageous view of the immutability. The downside of this is that developers ignore the security drawbacks in smart contract code, which results in security attacks on Blockchain platforms and smart contracts (DAO) by exploiting vulnerabilities (e.g. reentrancy). The current state of the art for developing a Blockchain-based rating review system addresses the incentive mechanisms and standard attacks, e.g. user retaliation, collusion attack, deletion of negative feedback, and unfair rating. These systems do not present security analyses of their smart contracts. This research presents a security analysis of smart contracts of rating/review-based recommender systems on permissionless blockchains.

The integration of blockchain with other domains to explore future possibilities is still in the developing phase and being addressed by introducing new programming constructs for writing smart contracts. The researchers have proposed several security analyses tools during the last couple of years. The challenging issues for the developers of blockchain-based systems are the following. First, finding support for the current programming language versions, second, the ability to detect the current security threats, and third, identifying deprecated tools. The continuous advancement in a security tool is the key that keeps the security tool more effective in the timeline and can help users to filter out obsolete security tools. This research work presents a novel approach for selecting the relevant security tools.

1.2. Our contribution

The main contributions of this research work are twofold.

• First, this research article presents a detailed study of known vulnerabilities in smart contract execution. It reviews twelve publicly available security analysis tools in-depth by reviewing peer-reviewed journals, articles, conference papers, and GitHub repositories. The continuous advancement in the tools is necessary to address the new threats, and this paper presents a novel approach to deal with this issue.

• Second, this research article presents a security analysis of smart contracts of blockchain-based rating and review systems using security analysis tools. It also discusses the severity level of the detected threats. To the best of our knowledge, it is the first work in this application domain of Blockchain. This work will motivate the developers of rating/review systems to focus on the security flaws in smart contract programming.

We extensively searched academic and non-academic proposed or working prototypes, frameworks, and systems for rating/review using the keywords, e.g. blockchain-based recommender system, decentralised system, reward mechanisms, and identified the systems that have their smart contracts on public repositories. This experimental work is limited to the security analysis of blockchain-based rating or review applications and does not propose any new recommender system. This research work analyses smart contracts and finds vulnerabilities in the programming codes and does not address the standard security attacks, e.g. collusion attacks, user retaliation, and bad-mouthing in recommendation systems.

The rest of this manuscript is structured as follows. Section 2 summarises the basics of blockchain technology. Section 3 and 4 provide an in-depth survey of security vulnerabilities in the smart contracts and a detailed study of the publicly available security analysis tools. Section 5 focuses on the selected decentralised blockchain-based rating/ review systems and prototypes. Section 6 presents the experimental setup and results. Finally, section 7 concludes the findings. First, Table 1 lists notations and acronyms used in the rest of the research article for ease of expression.

Table 1. Summary of acronyms and notations.

Acronym or Notation	Description
B^i	Set of blocks
HL^i	Set of hash links to the previous block
NASDAQ	National Association of securities dealers automated quotations
DAO	Decentralised autonomous organisation
Txn Hash	Transaction hash
Txn Fee	Transaction fee
TOD	Transaction ordering dependence
PoWH	Proof of weak hand coins
CFG	Context-free grammar
XML	Extensible Markup Language
ANTLR	Another tool for language recognition
SMT	Satisfiability modulo theories
EVM	Ethereum virtual machine
RAF	Review automatic filtering
IPFS	Interplanetary file system
ci	Number of contributors for i^th tool
mi	Number of active months for i^th tool
P^i	Popularity score of i^th tool
FNR	False negative rate
FPR	False positive rate
TP	True positive
TN	True negative

2. Background

Blockchain technology is a cryptographically secured decentralised system that answers double-spending and decentralised trust problems. Blockchain network identifies an actor using the pair of the public-private key generated by elliptic curve cryptography variants $y=x^3+ax+b$ (Kumar et al., 2020). Equation (1).

An actor initiates a cryptographically signed transaction (e.g. cryptocurrency transfer to another actor). Miners collect transactions using the data structure Merkle tree and confirm a valid block consisting of Merkle root hash, previous block hash, and other header information using a consensus algorithm. It may result in an inconsistent interpretation of blockchain at a time t by a node having an i^th local view of the blockchain resulting in a tree structure (Zanzottera et al., 2018). $Bchai{n}_i=(B^i,H{L}^i)$ where $B^i$ is a set of blocks and $H{L}^i$ is a set of hash links to the previous blocks. (2) $\begin{array}{rl}{B}^i& =\{b_0^i,b_1^i,\dots \dots \dots \dots \dots \dots \dots ,b_n^i\}\end{array}$(2) (3) $\begin{array}{rl}H{L}^i& =\{(b_0^i,b_1^i),(b_1^i,b_2^i),\dots \dots \dots \dots \dots \dots \dots \dots .,(b_{n-1}^i,b_n^i)\}\end{array}$(3) A node reaches the global view by selecting a tree path of maximum length or choosing the view at t agreed by the maximum number of nodes.

2.1. Progression of blockchain

Blockchain progression is analogous to the world wide web. Blockchain is a layer on the internet and does not require the world wide web and has the same potential similar to the web in 1993–1994 (Mougayar & Buterin, 2016).

2.1.1. Blockchain 1.0 (Cryptocurrency)

In 2008, a pseudonym Satoshi Nakamoto introduced blockchain allocation named bitcoin. Satoshi Nakamoto mined the genesis block containing the first bitcoin transaction in January 2009 between Satoshi Nakamoto and Hal Finney (Peterson, 2014). First-generation systems were developed for decentralised digital payment systems, and more than 1500 cryptocurrencies are available in the market, which can be mined and exchanged by people.

2.1.2. Blockchain 2.0 (Smart contracts)

This generation started with the proposal of Ethereum by Vitalik Buterin in 2013 and became operational on 30 July 2015 (Tapscott & Tapscott, 2016). It introduced a new concept of self-verifying, self-executable, and non-editable small programmes on blockchain named smart contracts. In addition, the smart contract provided new capabilities to researchers for applying blockchain in different application domains other than cryptocurrencies like health care, IoT, supply chain, verifiable keyword search in OSN, etc. (Zhang et al., 2021).

2.1.3. Blockchain 3.0 (DApps)

This generation introduced permissioned blockchains and restricted blockchain applications to authenticated and authorised users in contrast to the permissionless Blockchain. These advancements, in addition to full-fledged decentralised applications, started a new non-intermediary age of technology.

2.1.4. Blockchain 4.0 (Industrial applications)

The current direction of blockchain research is to make it adaptable in real-life business towards industry automation where data from different locations use an open channel (Bodkhe et al., 2020).

2.2. Categories of blockchains

There blockchains systems are of four types based on the governance of the system:

2.2.1. Public blockchain

It is permission-less, so it does not restrict the system access and allows anyone with an internet connection to join and interact with it. Bitcoin blockchain, Ethereum are examples of a public blockchain. However, some public blockchain imposes restrictions on just reading and writing. Although public blockchain needs high computational capacity and power for the mining of blocks but is very secure (Attaran & Gunasekaran, 2019).

2.2.2. Private blockchain

Unlike a public blockchain, it is permissioned, and a company sets roles for the users to participate in the network. The only administrators can perform the verification of the nodes (Zanzottera et al., 2018). Several key features like the privacy of data contents, fast transaction speed, and a controlled environment are making it more favourable for the legal entities of a single business unit. For example, New Stock Exchange, NASDAQ is replacing paper-based and manual transactions by testing private blockchain technology (Lakhani & Iansiti, 2017, january 01). Multichain is an example of this category.

2.2.3. Hybrid blockchain

The hybrid approach provides the benefits of both private and public blockchain. It enables control over nodes’ roles and visibility with the flexibility of providing data on a shared ledger to all nodes. XinFin is an example of this category.

2.2.4. Consortium blockchain

In consortium blockchain, the consensus is restricted to a set of pre-defined nodes by the company. Corda is an example of consortium blockchain.

3. Security vulnerabilities in smart contracts

This section emphasises the open research findings of Ethereum smart contracts vulnerabilities. Ethereum experiences genetic vulnerabilities from its predecessors’ blockchain systems and individual vulnerabilities in smart contracts. Private key security, Eclipse attack, Selfish mining, 51% attack, and Double spending are some examples of genetic vulnerabilities. What does make Ethereum different from its ancestor bitcoin blockchain is the smart contract that is a digitised version of a paper contract and adds the power of Turing Completeness, value awareness, and blockchain state awareness (Wood, 2014).

The essential components of a paper contract are parties, consent, object, consideration, notice, confidentiality, and indemnification. Thus, a paper contract has multiple clauses which need to be translated successfully into smart contract code, but it imposes privacy set back on the Ethereum blockchain (Egbertsen et al., 2016). All transactions, including balance transfer and account balances, are stored in a shared ledger on blockchain systems and available publicly in financial applications; this imposes two privacy concerns; first, lack of transactions privacy (Kosba et al., 2016; Watanabe et al., 2015) and lack of data feed privacy (Zhang et al., 2016).

Ethereum is built on a state machine concept where one smart contract can execute at a time. The miners make the order of execution using consensus and follow a sequential order. It limits the throughput that becomes inversely proportional to the latency of execution (Vukolić, 2017). The well-known and current security threats that can act as a source of vulnerabilities are explained as follows.

3.1. Re-entrancy

If a function in contract P interacts with another untrusted contract Q, a recursive call from P into Q is possible before completing this interaction and can leave the account empty. The DAO attack exploited this vulnerability and accounted for 60 million US Dollars (Luu et al., 2016). Accuracy in the recommender systems depends on the number of user ratings and reviews. The current systems employ a reward mechanism to increase user interaction by giving monetary incentives. So, e.g. the smart contract function for transferring rewards recursively called from an owner contract may be susceptible to the reentrancy attack. The Reentrancy attack is of two types: the first type is a single function Reentrancy attack where the vulnerable function and the function intended to call recursively are the same. The second type is a cross-functional Reentrancy attack, where both functions are not the same, and the vulnerable function shares its state with the function exposed to an attacker.

3.2. Transaction ordering dependence

Ethereum updates the state when new blocks containing transactions get added to the chain. The only miner decides the order of transactions, and an owner can gain malicious benefit from the time gap between the transaction broadcast and inclusion in the block. The owner can change the order of transactions by setting a higher gas price for the malicious transaction to get the chance of execution first and result in a race condition (Luu et al., 2016) Figure 1.

Figure 1. A special block with only transactions to the same address^a.

Note. ^aThe image is from a blog on Medium “A special block with only 3 txns to the same addr,” by Coinmonks educational publication, SECBIT Labs, 2018. (https://medium.com/coinmonks/how-the-winner-got-fomo3d-prize-a-detailed-explanation-b30a69b7813f.).

Attack on the “Fomo3d” game is an example of TOD. A malicious user-set high gas price and high gas limit prioritise the transaction order and consume all the gas by sending multiple transactions to the smart contract. Some blockchain-based applications in marketing and bidding allowing users to bid services based on their reputations, ratings, or reviews may be vulnerable to the change in the service or product price before another bid request gets executed.

3.3. Overflows and underflows

Solidity supports up to 256-bit numbers. When the number increases over the maximum, it results in the overflow condition, and the underflow condition is just reverse of the previous. The group of 4 chan's/biz/ created “Proof of Weak Hand coins” that was a Ponzi scheme. Due to a flaw in the code, an unknown hacker stole 2000 ETH worth ∼$2.3 million.

Implementing ERC20 in PoWH (Secbit Laboratories, 2018; Banisadr, 2018, February 1) allows for selling from the first account on behalf of the second account. It results in the debit of tokens from the second account's balance. For example, let the account is out of coins, and a user attempts through the second empty account; in that case, one PoWH coin transfer results in the underflow and credits the second account with a maximum balance (value). A blockchain-based rating/review system may implement arithmetic functions for calculating, e.g. reputation score and weighted ratings in the contracts in a controllable environment that could manipulate the passed parameter and return to zero due to overflow.

3.4. Call-stack depth

The maximum call-stack depth in Ethereum is 1024. So, a malicious user can trick a recursive call by 1023 times before posting a transaction to the intended function and ensures the call-stack depth gets 1024. Due to the full stack, the attacked function will fail to send the ether using send() or call.value(). In rating/review systems, an owner may use this attack to fail the benefits transfer for negative feedback from the users.

3.5. Tx.origin

A contract P can call contract Q, which can call another contract R. In this case, Q is msg.sender in R, which means immediate sender of the transaction, and P is tx.origin in R, which means original sender of the transactions. A rating/review system should use an authentication mechanism for the user accounts. In blockchain-based applications use of tx.origin for authentication objectives may reveal the original sender of the transaction, and the user account may become a victim of the phishing attack.

3.6. Call to the unknown

There are two ways to call a contract from another contract, first, by using a hard-coded address, and second, by user-provided address. A malicious user can use this flexibility to call a malicious contract in a user-provided address. In the rating/review system, a malicious contract may add higher ratings for a product/service to raise the overall rating without using the services.

3.7. Short transfer address

In Solidity, the address type address holds a 20-byte value. If we invoke a transfer method: transfer (address a, uint v), it will pass 68 bytes consisting of three parts. The first part is method ID of 4 bytes, the second part is address padded to 32 bytes with leading zeros, and the third part is transfer value of 32 bytes. The complete transaction would therefore look like this:

a9059cbb000000000000000000000000abcabcabcabcabcabcabcabcabcabcabcabcabca0000000000000000000000000000000000000000000000000de0b6b3a7640000 (Bylica, 2017). If a user inputs an address less than 20 bytes, the transfer value shifts to the left, increasing the value larger and leaving the account empty. In an e-commerce environment, the rating/review system's third-party applications that do not validate inputs may be subject to this attack. If the attacker succeeds in generating a user address using brute-force ending with 0's could steal more amount from the forged exchange.

3.8. Function and variable visibility

Solidity supports three visibility levels. By default, Solidity considers by default public visibility for a function. So payable function without explicit declaration may become a cause of substantial financial losses (Tikhomirov et al., 2018). The current rating/review systems employ a user reputation function for increasing user trust in the system that all parties may access within and outside the contract without explicit declaration and may get hampered.

3.9. Mishandled exception

Exceptions may arise in the Solidity code due to many situations, e.g. a transaction posted using a send instruction to a contract address may require more gas than a typical transaction, resulting in execution failure. So, a callee may not be aware of the exception if it does not check the return value and is subject to attack (e.g. loss of ether). In rating/review systems, a user can set a rating variable using a contract that may call another contract's function to set the value. One gives a value inside the call method to set the rating but doesn't know that function has done its job precisely or not and may be subject to a change of ratings.

3.10. Denial of service by external contract

A dependency of a conditional statement (if, for, while) an external call may result in the permanent failure (throw or revert) of the callee that thwarts the caller from carrying out the execution (Tikhomirov et al., 2018). A rating/review system smart contract may use a for loop to send rewards to users. In this case, a single failed send may leave the reward system inoperable, and no one will get an incentive due to an unexpected revert.

4. Publicly available security analysis tools

Different researchers proposed several methods and tools in past years to reveal the security issues in deployed contracts or the contracts in the early pre-deployment phase. In this section, we focus on the publicly available tools. Security tools can be grouped into two categories based on analysis type: static and dynamic.

• Static: These tools analyse the contract without executing it. It reveals security vulnerabilities by using the CFG, decompiled outputs and code structure, etc.

• Dynamic: These tools analyse the contract at run time in its original context. It discovers vulnerabilities using symbolic execution, fuzzing, and taint tracking.

4.1. Oyente (Luu et al., 2016; yu, 2016)

It inputs solidity code and uses a solidity compiler to convert that into bytecode. It uses Go-Ethereum and executes bytecodes symbolically. A path condition is formulated using constraints, and each path is traced using path conditions and discovered as a feasible path if it satisfies the condition otherwise infeasible path.

4.2. Remix-IDE (Ethereum, 2016; Ethereum, 2020)

It supports different Solidity versions to compile smart contracts and a lightweight static analysis tool that includes control flow analysis. In addition, it detects various syntactical errors and warnings in the code during compilation. The warnings cover different security vulnerabilities.

4.3. Solgraph (Revere, 2016)

It converts solidity code in the graph G =  (V, E), where a node represents a function, and a directed edge means a function call. It uses GraphViz for visualising the graph.

4.4. Vandal (Brent et al., 2018; usyd, 2018)

It uses \souffle language to analyse the security vulnerabilities. It converts smart contracts into logic relations. It uses a pipeline approach where bytecode is fed to Scrapper, Disassembler, Decompiler, and Extractor successively and results in logic relations. The executable programmes, written in Souffle language, analyse these logic relations.

4.5. Manticore (Trail, 2017)

It uses Solidity compiler to convert the code into bytecode and explores unique computation paths in EVM using symbolic execution. It evaluates these computation paths using SMT solver Z3 and uncovers the vulnerabilities like reentrancy, self-destruct, tx.origin, etc.

4.6. Porosity (Comae, 2017)

It disassembles bytecode to generate CFG and decompiles bytecode to pseudo-code. It uses GraphViz to visualise the CFG.

4.7. SmartCheck (SmartDec, 2018; Tikhomirov et al., 2018)

It converts the Solidity code into an XML syntax tree and detects vulnerabilities using XPath queries on the XML syntax tree. In addition, it can support other smart contract languages by adding ANTLR grammar and pattern databases.

4.8. Mythril (ConsenSys, 2017)

It uses the SMT solver Z3 and analyses the CFG where a node represents the disassembled code, and an edge represents the path formula.

4.9. MAYAN (Nikolic, 2018; Nikolić et al., 2018)

It compiles solidity code and executes generated EVM bytecode symbolically. It checks the execution paths to find out the lost Ether from haphazard addresses, self-destruct operations, or unchecked calls. It uses a private blockchain to dynamically analyse the contracts and results in the rejection of false positives.

4.10. Osiris (Torres, 2018; Torres et al., 2018)

It visualises CFG and performs symbolic execution. In addition, it uses taint analysis to differentiate benign and malicious overflows.

4.11. Securify (Sankov et al., 2018; SRI, 2019)

It consists of two steps. The first step takes two inputs first: the contract's bytecode and the second, security patterns. Then it decompiles bytecode in static-single assignment form and analyses contract dependency graph to infer semantic facts. The second step checks for the violation and compliance of security patterns. It highlights the instruction for any match of violation.

4.12. Slither (Feist et al., 2019)

It consists of three stages. The first stage creates CFG, a list of expressions, and an inheritance graph. In the second stage, slither coverts code into internal representation language SlithIR instructions. In the third stage, it computes security analyses. It also supports the other smart contract languages.

5. Smart contract-based review or rating systems on the public blockchain

This subsection presents a detailed study of four blockchain-based rating and review systems. Smart contracts of these systems are available on the public repositories. Table 2 summarises the current state of security analyses of these systems. Developers of Friendz, Revain, and Decentralised rating platforms didn't present security analyses of their systems’ smart contracts. Blockchain-review-systems (Salah et al., 2019), the author analysed smart contracts using only the Oyente tool and found it bug-free. As discussed in the previous subsection, the recently recognised threats and standard set of attacks on smart contracts motivate the security analyses of rating/review systems using different security tools.

Table 2. The current state of security analyses of the selected rating/review systems.

System	Security Analysis	Tool used	Reference
Friendz	✗	✗	(Revain, 2017)
Revain	✗	✗	(Friendz, 2018)
BlockChain-Review-System	✓	Oyente	(Salah et al., 2019)
Decentralized-Rating-Platform	✗	✗	(Lisi et al., 2021)
Dentacoin	✗	✗	(Dentacoin, 2018)

5.1. Friendz (Friendz, 2018)

The system purposes decentralisation of the advertising process and content creation and validation on social media. It is a community-based digital marketing platform built on blockchain technology and introduces a new digital currency, Friendz Coins, to digital services. It consists of three actors: Clients, Users, and Approvers. Clients are the brands who wish to advertise their products. Clients purchase a campaign for advertisements on the Friendz platform based on the following parameters: budget, size, target users, social network, creativity, and campaign concept. The platform computes rewards for creativity approvers, users, and content approvers. Users are community-based and can choose and participate in a campaign, but participation is limited and based on a first-come, first-served. They get rewards for creating and posting the content as per the guidelines. Approvers get rewards for the number of contents approved. It uses a 1–5 stars scale for rating where 1 star is rating for the worst contents and 5-star rating for the best quality. A user can act as an approver after participating insufficient numbers of the campaign and passing an initial approval test. It has the following features: 1. Increasing Transparency: The advertising spending will be registered on the Blockchain in complete transparency. 2. Decentralised validation system: it provides content validation where the platform automatically shows contents to experience users as soon as they are uploaded.

5.2. Revain (Revain, 2017)

The purpose of the system is to facilitate users to submit feedback on goods and services. It is a combination of three components: the first component is a token system. The second component is the review automatic filtering, and the third component is the Blockchain to record all reviews. The token system uses two types of tokens, R and RVN. R tokens are limited and are used as a currency to raise funds using crowdfunding. RVN tokens are used for the interactions between the platform, users, and companies. 1 RVN token is equal to .0001BTC. The formula for computing the value of 1 R token can is: (4) $1Rtoken=\left(\frac{Rvalue(inBTC)}{.0001}\right)RVNtokens$(4) The company pays a fee to the Revain system, which calculates the user reward and platform fee for each submitted review. The maximum 10 RVN review fee can be charged and limited by the following formula: (5) $RF(x=reviewnumberperlast2weeks)=\{\begin{array}{l}Ceil{\left(\frac{e}{2.65}\right)}^{-1+x}x<90\\ 10RVNx\ge 90\end{array}$(5) The amount for user reward is charged from the Revain fee and calculated as follows: (6) $Userreward=(0.9\times Revainfee)$(6) Users are restricted to write a maximum of 5 reviews per day and get rewards if the company approves their feedbacks. The cycle of the rewards is once every two weeks, and the reward amount is: (7) $Rewardtoeachuser=\left(\frac{Amountofrewardtoekns}{Totalnumberofusersbeingrewarded}\right)$(7) Thus, it shows that each rewarded user is entitled to an equal amount of incentive. The second component is review automatic filtering (RAF) which uses the IBM Watson platform to identify quality reviews on three parameters: emotions, language style, and social tendencies. The third component uses the Ethereum blockchain to store the snapshot of reviews that have passed RAF and the manual filtration process.

5.3. BlockChain-review-system (Salah et al., 2019)

This framework aims to deliver trusted reviews and reward reviewers. It constitutes three significant components: service provider, reviewers, an inter-planetary file system, and smart contracts to regulate the system. The service provider offers the services to the users, expects a review for the service, and motivates the users to actively participate in the system by awarding tokens with a unique number for the reviews. The reviews get stored on the IPFS, and the smart contract stores the IPFS hash and reviewer's Ethereum address and later use it with the conjunction of token to validate the review.

5.4. Decentralised-rating-platform (Lisi et al., 2021)

The purpose of the framework is twofold first is the inclusion of token-based reward to increase the users’ participation, and second is the inclusion of ranking for items on the Blockchain. It does not include any specific reputation system but ensures the increase in the reputation of users for every newly submitted review. It consists of six major components which constitute this framework: items, skills, users, tokens, reviews, user reputation, and rating function and uses smart contracts to regulate the system. An item is an object with a set of properties. A skill is correspondent to the property of the object and has a nominal value.

A user can review and rate a used item and earn skills and get a reward in terms of tokens. A token represents the digital currency and can be used to get discounts on future spending. The reputation is a numeric value. A user can choose a rating function to calculate the ranking of the items. It uses a local token management system that makes the framework complex and requires an off-chain agreement between the consumer and item owner to leave a rating.

5.5. Dentacoin (Dentacoin, 2018)

The purpose of the system is to provide an ecosystem for the dental industry through a cryptocurrency named Dentacoin (DCN). It facilitates users to submit their reviews on the platform. It allows anyone to write a standard review and introduces a notion of trusted reviews written by only actual patients and pay rewards to the users.

6. Experimental setup and results

The experiments use publicly available security tools for vulnerability detection and possible threats in publicly available smart contracts of rating/review systems. The selection of security tools is pivotal for the trusted results as some of the tools are published and compared while others are not. So, we begin with the tools given in Table 3 and follow a two-step process for selecting the security analysis tools for our experiments. The first step searches the security tools published in peer-reviewed journals, articles, and conference papers. Although this step does not contribute new comparative results but considers and analyses the findings of security tools given by their authors and independent researchers.

Table 3. Publicly available security tools for smart contracts.

S. No.	Security tools	Preprocessing Methods	Year of published	Interface	Programming language for development
1.	Oyente	Contextualization, Disassembly, Control Flow Graph	19 Jun. 2017	Command-line	Python
2.	Remix IDE	Contextualization	13 Feb 2018	Web-based IDE	JavaScript
3.	Solgraph	Contextualization, Call graph, AST analysis	6 Jul. 2016	Command-line	JavaScript
4.	Vandal	Disassembly, Control Flow Graph, De-compilation	11 Sept. 2018	Command-line	Python
5.	Manticore	Contextualization, Disassembly	27 Apr. 2017	Command-line	Python
6.	Porosity	Disassembly, Control Flow Graph, De-compilation	3 Aug. 2017	Command-line	C++
7.	SmartCheck	Contextualization, AST analysis	27 May 2018	Command-line	Java
8.	Mythril	Contextualization, Disassembly, Control Flow Graph	4 Oct. 2017	Command-line	Python
9.	MAIAN	Disassembly, Control Flow Graph	14 Mar. 2018	Command-line	Python
10.	Osiris	Contextualization, Disassembly, Control Flow Graph	11 Sep. 2018	Command-line	Python
11.	Securify	Contextualization, Disassembly, De-compilation	22 Jan. 2019	Web-based	Java
12	Slither	AST analysis, Control Flow Graph, De-compilation	19 Oct. 2018	Command-line	Python

In the second step, we propose a novel method to calculate the popularity score of the security tools by collecting data from Github repositories to determine the active months from the publishing date given in Table 3 and the continuous support team for the tools selected from the first step. Thus, popularity score identifies the regular updates in the security tool.

6.1. Selection of security analysis tools for experimental work

6.1.1. First step: quantitative reviews of tools

The first step presents a detailed study and analysis of the results contributed by the tool's authors and independent researchers at different points in time. The extensive search finds five published articles for seven tools from Table 3. The seven tools: SmartCheck, Mythril, Securify, Oyente, Porosity, Remix, and Slither, were evaluated and compared with their competitors. In (Parizi et al., 2018), the authors selected ten smart contracts written in Solidity, and the experimental environment was set up on an Intel Core i7 at 2.9 GHz and 16 GB RAM under MacOS using solc compiler (v0.4.21).

They selected four security tools: SmartCheck, Mythril, Securify, and Oyente, under consideration for analysis. Their experimental results in Table 4 show that SmartCheck was more effective in vulnerability detection with 83.35% average effectiveness, and Mythril was more accurate in vulnerability detection with 76.95% average accuracy.

Table 4. Comparisons of tools on effectiveness and accuracy^b.

Tool Name	Effectiveness %	Accuracy %
SmartCheck	83.35%	71.91%
Mythrill	71.88%	76.95%
Securify	62.34%	62.05%
Oyente	56.56%	54.68%

Note. ^bThe data are adapted from Empirical Vulnerability Analysis of Automated Smart Contracts Security Testing on Blockchains, by Parizi et al. (2018).

In (Fontein, 2018) author selected nine smart contracts written in Solidity and performed security analysis using three security tools: Oyente, Mythril, and Porosity. His experimental results in Table 5 show that the Oyente tool successfully detected four out of five claimed vulnerabilities but failed to detect timestamp dependency. Similarly, Mythril detected nine out of ten, and Porosity detected one out of three vulnerabilities.

Table 5. Comparisons of tools on effectiveness^c.

Tool Name	Accuracy %
Oyente	75%
Mythril	90%
Porosity	33%

Note. ^cThe data are adapted from Comparison of static analysis tooling for smart contracts on the evm, by Fontein (2018).

In (Sankov et al., 2018), the authors selected two data sets, the first EVM dataset and the second Solidity dataset consisting of 24,594 and 100 smart contracts. They compared Oyente, and Mythril security tools contracts on TOD, Reentrancy, Handled Exception, and Restricted Transfer vulnerabilities in Solidity dataset. Their experiments show that Oyente reported 27.1% of TOD violations, and Mythril reported 34.4% of RT violations.

In (Tikhomirov et al., 2018), authors compared Oyente, Remix, Securify, and SmartCheck security tools on three projects. Their experimental results in Table 6 show 47.06% FNR and 68.97% FDR for the SmartCheck, which was better than its competitor.

Table 6. Overall comparative results of tools^d.

Tools	True Positive	False Positive	False Negative	False Discovery Rate (%)	False Negative Rate (%)
Oyente	0	19	51	100	100
Remix	4	111	47	96.52	92.16
Securify	0	70	51	100	100
SmartCheck	27	60	24	68.97	47.06

Note. ^dThe data are adapted from SmartCheck: Static Analysis of Ethereum Smart Contracts, by Tikhomirov et al. (2018).

In (Feist et al., 2019), the authors conducted two sets of experiments. The first experiment was used to test whether the security tools detect reentrancy in two famous contracts DAO and SpankChain, or not. The second experiment used 1000 contracts with the most significant number of transactions and calculated the false positive rate. Their experimental results in Table 7 show that Slither successfully detected reentrancy in both contracts and had a lower false-positive rate than two other tools.

Table 7. Comparative results of security tools^e.

Tool	False Positive Rate (%)	DAO	SpankChain
Slither	10.9	✓	✓
Securify	25	✗	✗
Smart Check	73.6	✓	✓

Note. ^eThe data are adapted from Slither: A Static Analysis Framework for Smart Contracts by Feist et al. (2019).

Tables 4 and 5 show that Mythril is more accurate than SmartCheck, Securify, Oyente, and Porosity. Table 6 result shows that only Remix and SmartCheck detected true positives. SmartCheck and Remix had a low false negative rate compared to other tools, and Remix succeeded in finding true positives in the populous contracts. Table 7 signifies the ability of Slither to find out the new types of threats, e.g. (DAO, SpankChain) with less false positive rate than its competitors that places it in the list of candidature for security analysis. Malicious users always try to find new security leaks as time passes to gain malignant benefits in the security domain. The continuous advancement in a security tool is the key that keeps the security tool more effective in the timeline and can help users to filter out obsolete security tools. So, the first step focuses on only finding out the tools compared in the near past, while the second step focuses on the continuous advancement in the security tools.

6.1.2. Second step: popularity of tools

The second step proposes a new method for finding out continuous advancement in the tool and names it the popularity of the tools. The popularity score is calculated based on the number of contributors and active months. It is further used to compare the security tools. The number of contributors is active participants in the open-source environment who have been adding new functionalities to the security tools. Active months are the number of months from the published date to the latest update date of the security tool.

To calculate the tools’ popularity, we normalise the data by using sum normalisation for the number of contributors and active months and then add both parameters to sort the result. (8) $\begin{array}{rl}{C}_i& =\frac{c_i}{{\sum }_{i=1}^n{c}_i}\text{where }{c}_i\text{is the number of contributors for }{\text{i}}^{\text{th}}\text{tool}\end{array}$(8) (9) $\begin{array}{rl}{M}_i& =\frac{m_i}{{\sum }_{i=1}^n{m}_i}\text{where }{m}_i\text{is the number of active months for }{\text{i}}^{\text{th}}\text{tool}\end{array}$(9) (10) $\begin{array}{rl}{P}_i& =C_i+M_i\text{where }{P}_i\text{is the popularity score for }{\text{i}}^{\text{th}}\text{tool}\end{array}$(10)

Table 8 lists the number of contributors and active months. This data is recorded from the respective tool's GitHub repository and is used to calculate the popularity score of a security tool that shows the continuous update in the security tool. We calculated the popularity score of each tool using Equations (8) to – (10), which are given in Figure 2. The vulnerabilities and threats checked by the first five tools are listed in Table 9.

The second step results show that the maximum popularity score 0.66 is for Remix with 89 contributors in 73 months, solidifying the tool's continuous advancement. Slither's popularity score is closer to Oyente. Still, Slither has attracted 31 more contributors than Oyente in 28 months only, which shows it as a fast adapting and growing tool compared to its competitors. Securify and Porosity were published in 2019 and 2017, but the results show only 7 and 8 contributors with 16 and 22 active months, respectively. So, Remix, Mythril, and Slither are the tools, each having more than 50 contributors, and numbers are increasing with time.

Figure 2. The popularity score of security tools.

Table 8. Security tools details.

Tools	Tool Membership	No. of Contributors	First Contribution Date	Active Months	Reference
Oyente	Community	20	3 Jan. 2016	58	(Yu, 2016)
Remix	Community	89	16 Nov. 2014	73	(Ethereum, 2016)
Porosity	Company	08	26 Feb. 2017	22	(Comae, 2017)
SmartCheck	Academic	11	14 May 2017	20	(SmartDec, 2018)
Mythril	Company	57	17 Sep. 2017	39	(ConsenSys, 2017)
Securify	Academic	07	23 Sep. 2018	16	(SRI Lab, 2019)
Slither	Academic	51	2 Sep. 2018	28	(Crytic, 2018)

Table 9. Vulnerabilities and threats checked by security tools.

Tool	Vulnerabilities and Threats
Oyente	• Integer underflow • Integer overflow • Parity multisig • Callstack depth attack• Transaction-ordering dependence • Timestamp dependency • Re-entrancy
Remix IDE	• Unchecked-send. • Block timestamp • Tx.origin usage • Re-entrancy • Self-destruct • Inline assembly • Blockhash usage • Gas costly patterns • This. on local calls • Constant functions • Similar variable names • Checkeffects-interaction. • Low-level
SmartCheck	• Hardcoded address • Strict balance equity • Byte array Transfer • forwards all gas. • Overpowered role • DoS by external contract • Token API violation • Costly loop • Integer division • Locked money • Malicious libraries • Style guide violation • Timestamp dependence • Compiler version not fixed. • Private modifier • Redundant fallback function • Re-entrancy • Send instead of transfer. • Tx.origin usage • Unchecked external call • Unchecked math • Unsafe type inference • Implicit visibility level Prefer external to public visibility level.
Mythril	• TOD • Random number • Timestamp • Callstack depth • External call to user-supplied address • Unchecked math • Reentrancy • Unchecked calls • Tx.origin • Bad coding pattern • Deprecated • Assertion violation
Slither	• Re-entrancy, reentrancy-no-eth, reentrancy-benign • Tx-origin • Block Timestamp • Uninitialized-state, uninitialized-local, uninitialized-storage • Suicidal • Assembly • Deprecated standards. • Solc-version • Calls loop, Costly gas-consuming • Arbitrary-send. • Incorrect equality • Unused-return, low-level-calls • Shadowing built in, shadowing-local, shadowing-state • Controlled delegate call • Locked Ether • Dangerous strict equalities • Tautology or contradiction • Divide before multiplying

6.2. Experiment results

From the experimental setup, the first step results show that Mythrill, Slither, Remix, and SmartCheck tools perform more accurately than other tools. SmartCkeck has been deprecated since 2020. The first three security tools showing continuous advancements in the second step are Mythril, Remix, and Slither. Thus, we selected Mythril, Remix, and Slither for the security analysis of four Blockchain-based rating/review systems. The two systems, BlockChain-Review-System (Salah et al., 2019) and Decentralized-Rating-Platform (Lisi et al., 2021), mentioned the GitHub repository links in their research papers. For Friendz and Revain, we searched GitHub and considered the repositories, which contain links to their web pages. The number of available smart contracts for each system is listed in Table 10.

Table 10. The number of available smart contracts on Github repositories.

Name of System	Number of Smart Contracts	Reference
Friendz	01	(Friendz, 2018, May 16)
Revain	11	(Revain, 2019)
BlockChain-Review-System	01	(Alfalasi, 2018, April 29; Salah et al., 2019)
Decentralized-Rating-Platform	13	(Lisi et al., 2021; Lisi & Fabrizi, 2020)
Dentacoin	03	(Dentacoin, 2017)

Table 11 summarises our experimental results. The results show that Slither does not detect any vulnerability and threat in Revain and Mythril in the system BlockChain-Review-System. The other tools report vulnerabilities in these systems because different tools check different threats, as given in Table 9, covering a standard set of threats. Table 12 lists the details of reported vulnerabilities and threats in the systems.

Table 11. Vulnerability and threat detection.

Tools \ Systems	Friendz	Revain	BlockChain-Review-System	Decentralized-Rating-Platform	Dentacoin
Slither	✓	✗	✓	✓	✓
Remix	✓	✓	✓	✓	✓
Mythril	✓	✓	✗	✓	✓

Table 12. Detected vulnerabilities and threats details.

	Vulnerabilities and Threats
Systems	Slither	Remix	Mythril
Friendz	Block timestamp	Block timestamp	Assertion violation
Revain	None	Block HashCheck-effect-interaction	External call to user-supplied address
BlockChain-Review-System	Reentrancy	Check-effects-interaction.Block timestampLow-level calls	None
Decentralized-Rating-Platform	Dangerous strict equalitiesTautology or contradictionDivide before multiplying	Costly loopCheck-effect-interaction.Selfdestruct	Assertion violationExternal call to user-supplied address
Dentacoin	Block timestamp	Check-effects-interaction.Block timestampLow-level calls	Assertion violation

The results in Table 12 are as follows. Friendz suffers from block timestamp and Assertion violation vulnerabilities. Use of now, that is the alias of block.timestamp in contract code is a timestamp comparison that the miners can influence to a certain degree. It can be prevented by using block.number approximating 60480 blocks in one week with a block time of 10 s. The assert () statement to constrain user inputs or enforce conditions can result in assertion violation. Instead, require() can be used to prevent this and authenticate the information from both callers and callees. Slither does not detect any vulnerability in the Revain, but Remix and Mythril detect BlockHash, Check-effect-interaction, and External call to user-supplied address. A miner calculates a block hash by adding up the information in the presently mined block. The last 256 block hashes can be accessed using blockhash(uint blockNumber). So a miner can cleverly sum up the information to affect the result of a transaction in the current block, and it is easier in the case of a small number of similarly possible outcomes. An external message call to the address provided by the user may lead to reentering any function of an arbitrary contract code resulting in unexpected behaviour.

Slither detects Reentrancy in BlockChain-Review-System, while Mythril does not uncover any threat in the system. Remix identifies Check-effects-interaction, Block timestamp, and Low-level calls. In case of failure, send does not throw an exception, so it is needed to manage the failure cases accordingly. Decentralized-Rating-Platform system suffers from Dangerous equalities, Tautology or contradiction, Costly loop, Check-effect interaction, Selfdestruct, Assertion violations, and External call to user-supplied address. Attackers can easily manipulate strict equalities by always reaching false or true, resulting in a non-ending contract function. Tautologies or contradictions must be fixed by changing the value type or the evaluation. When other contracts use a contract, Selfdestruct can block calling contracts unexpectedly and leave callers in an inoperable state.

In Figure 3, results show that the Remix detected the highest 37.93%, and the Mythril detected the lowest 20.68% of the total smart contracts experiencing vulnerabilities and threats.

Figure 3. The number of vulnerable smart contracts detected by the individual tool.

In Figure 4, results show the number of reported issues by each tool. from Figure 3 and 4; the following results are drawn: The Slither reports the maximum of five different security issues in 27.58% of the total smart contracts. Remix and Mythril report the six and two various security issues in 37.93% and 20.68% of the total smart contracts, respectively.

Figure 4. The number of vulnerabilities and threats detected by the individual tool.

Figure 5 shows the number of vulnerable smart contracts reported by individual security tools in each system. Remix detects five vulnerable contracts in Revain system, while Mythril and Slither detect three and five vulnerable contracts in the Decentralized-Rating-Platform, which is maximum compared to other systems.

Figure 5. The number of vulnerable smart contracts detected by an individual tool in each system.

We adopted the taxonomy of vulnerabilities presented in (Dika & Nowostawski, 2018), Slither documentation (Crytic, 2018), code issues detected by the SmartCheck (Tikhomirov et al., 2018), and smart contract issue count and severity presented in (Min & Cai, 2019) for the classification of reported security issues in three levels of severity types. Table 13 shows the categorisation of the detected vulnerabilities in low-level, medium-level, and high-level severity types.

Table 13. Severity levels of detected vulnerabilities.

LOW-LEVEL	MEDIUM-LEVEL	HIGH-LEVEL
Block timestamp	Assertion Violation	Reentrancy
Block Hash	Dangerous strict equalities
Check-effect-interaction	Tautology or contradiction
External call to user-supplied address	Divide before multiplying
Low-level calls
Costly loop
Selfdestruct

Figure 6 shows that the Remix reports only low-level severity issues, and the Slither reports one high-level severity issue. Mythril and Slither identify one and three medium-level severity issues, respectively.

Figure 6. Severity classification of security issues- from tools’ view.

Figure 7 shows that the BlockChain-Review-System system suffers from one high-level severity issue and three low-level severity issues. Revain suffers from only low-level severity issues, while Friendz, Decentralized-Rating-Platform, and Dentacoin systems suffer from medium and low-level severity issues.

Figure 7. Severity classification of security issues- from the system's view.

Low severity type issues reflect minimal effects and act as a request to improve the code. The medium-level concerns are due to shortcomings in the smart contract and can drive the system into the perils of financial losses and performance deprivation; thus, the programmer should correct these to avoid challenges. High severity issues are critical to the systems. A malicious user can use a high severity code to exploit the system.

The overall results in Figure 8 show that 51.72% of total smart contracts of rating/review systems suffer from security issues. Out of that, 46.67% are suffering from low severity levels, 46.66% from medium severity levels, and 6.67% from high severity level issues, raising a dire state of blockchain-based rating/review systems.

Figure 8. Overall results.

7. Conclusion

Blockchain technology introduces its inherent features to decentralised rating/review systems, but at the same point, the substantial security issues in smart contracts raise alarming situations. Our work carefully reviewed the publications that provide quantitative insight into the security tools and entitles those as candidate tools. The candidate tools have been further evaluated based on the continuous improvements using the number of contributors and active months and termed as popularity. We chose the first three most popular tools, Remix, Mythril, and Slither, for the security analysis of smart contracts of four rating and review systems.

Our security analysis results emphasise the security issues in 51.72% of the total analysed smart contracts. Out of that, 46.67% of issues are of low severity type and indicate minor impacts and act as improvement requests. The medium-level issues arise due to flaws in the smart contract and can push the system into the risks of financial leakage and performance degradation; thus, the programmer should fix these to avoid problems. The results show that 6.67% of vulnerable smart contracts are of high severity type and can be exploited by malicious users. This paper focuses on recommender systems based on rating and review storage models on the blockchain using smart contracts. It highlights the vulnerabilities in the smart contracts of these systems, thus presenting potential research opportunities for future researchers who would work in blockchain and recommender systems as a whole.

Disclosure statement

No potential conflict of interest was reported by the author(s).