Scavenger Hunt: Utilization of Blockchain and IoT for a Location-Based Game

Distributed Ledger Technology, has been gaining enormous attention in areas beyond cryptocurrency. Industries such as energy, transportation, and healthcare are already integrating DLTs into their operations. On the other hand, recent advances and the increasing popularity of the Internet of Things (IoT) technologies are also enabling new and exciting ways of interaction and sensing for mobile device users. Mobile gaming is another prominent industry that can be benefited from these technological developments and has the potential to create business opportunities. In this paper, we explore the uses of Distributed Ledger Technology in Mobile Gaming and for this purpose, we have taken a location-based IoT mobile gaming use case and propose new gaming features for the players by the addition of the DLT. We propose a platform for creating and playing scavenger hunt games using low-power BLE beacons. It allows smartphones to interact with the predetermined real-world locations and players can observe the surrounding environment looking for “clues” in the game. At the end of a hunt, the player receives rewards that are stored on a distributed ledger as Non-Fungible Tokens (NFT) and can bring in-game advantages for the next hunts. The proposed system is implemented using off-the-shelf devices and IoT beacons. We implemented our hybrid architecture by using AWS Lambda, Hyperledger Fabric managed blockchain and DynamoDB. We performed multiple experiments measuring the time taken for the end-to-end process, IoT beacon response times and the throughput of the Fabric network. Using the performance results, we estimated the maximum number of active players that can be supported by the game. Finally, we discuss business opportunities and limitations of the proposed proof of concept.


I. INTRODUCTION
When mobile phones were just phones, users played simple games that were embedded in their handsets. The complexity of the games was fundamentally restricted due to the limited graphical and processing power capabilities of the handsets. Mobile gaming possibilities changed in 2006-07 with the introduction of the first wave of smartphones [1]. The combination of new possibilities in the handset such as touch screen, sensors, precise location system, enhanced display and the ubiquitous connection to the network allowed many innovations, including application stores, playing while on the move, multi-player games, and location-based gaming.
The associate editor coordinating the review of this manuscript and approving it for publication was Zhipeng Cai .
Mobile devices became a viable alternative to other gaming platforms.
The number of Internet of Things (IoT) devices globally is increasing exponentially [2]. Signal-broadcasting devices, such as Bluetooth Low-energy beacons, can be used to coarsely approximate a mobile user's location. The recent emergence and increased deployment of IoT technologies are opening new avenues of research and development opportunities in context-aware games design. Therefore, very soon, many applications will possibly revolve around the interaction with smart things, and games will be no exception. Over the years games have seen transitions from PCs to mobile devices, and, recently, into our everyday spaces. IoT devices may provide mobile devices aid in positioning players both outdoors and indoors VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ The interest in blockchain technology has been increasing since the first decentralized distributed currency Bitcoin was launched in 2008 [3]. Blockchain technology has attracted a lot of attention as a financial platform, but its capabilities extend far beyond that. Such decentralized blockchain systems may change the way we transact with businesses, manage assets, vote, rent, and even prove who we are. The Openness attitude of blockchain can provide transparency in data and due to this strength, it can be utilized in diverse areas.
The blockchain tehcnology fulfills the ultimate dream of many game players: the items they own in the virtual world are non-fungible, exchangeable, inheritable, and independent of the game service provider. Game developers can even leverage blockchain to design an ecosystem that allows players to reuse their characters and virtual items across different games. Bringing blockchain technology to the way virtual items are stored promises to create an entirely new platform for value and exchange. Blockchain can help maintain the scarcity of a virtual item in a secure and verified way. Due to the transparent characteristic of blockchain data, players or third-party organizations can audit the smart contractbased games rules, which are hidden in a centralized server in traditional games. In spirit of the advantages descried above, the industry has started its venture on integrating blockchain into gaming systems. The Blockchain Game Alliance [4] was formed in September 2018 in order to explore alternative uses of blockchains in video games.
Mobile gaming has typically been an indoor activity, but some games that are being rolled out today are distinctive from their earlier counterparts. The era in which contextaware games will be part of our daily lives is already starting [5], and with these new IoT technologies, the gameplay possibilities can be extended even further. In our context, physical objects from the physical world, powered with IoT technology, would be used as interactive elements in a digital gaming environment. The interactive part of the game would run on the mobile device while the intelligence concerning the game mechanics would be part of the gaming platform hosted in a cloud environment.

A. MOTIVATION
The multi-billion dollar mobile gaming industry is booming and attracting numerous stakeholders. The global mobile gaming market is estimated to grow to $102.8 billion by the end of 2023 [6]. Furthermore, the recent technological developments, such as 5G, augmented/virtual reality, Internet of Things, Distributed Ledger Technologies (DLT) and cloud services, among others, are generating additional business opportunities by creating novel use cases in the current gaming industry. For example, 5G and Multi-access Edge Computing (MEC) paradigms are expected to enable lowlatency based features which will enhance user experience. Similarly, Blockchain technologies may be vital in bringing transparency and provide a reliable link between the networks. Therefore, in this article, we explore the uses of DLT and Internet of Things in mobile gaming and for this purpose we implement and test a real-world Scavenger Hunt mobile game prototype, evaluating the potential and challenges that such a game brings with it.

B. OUR CONTRIBUTION
Our Contributions in this paper are as follows: • We propose a novel architecture that uses a traditional centralized backend server in combination with a Hyperledger Fabric blockchain network. This approach divides the game-related tasks accordingly without compromising the gaming experience for the player.
• Distributed Ledger Technology is used for adding extra features to the core game such as user-generated content, true ownership, trading, or even interoperability of in-game assets between multiple games.
• Introduction to the SOFIE framework and it's components, which is an example implementation for connecting IoT platforms with the help of Distributed Ledger Technologies.
• Utilizing parts of the SOFIE components that bring added benefits and transparency for the mobile game proof of concept.
• In order to verify the viability of the proposal, a prototype implementation of the hybrid architecture is done on a testbed using off-the-shelf devices.
• We evaluate the performance of the proposed architecture and simulate active player supported by the system.
• To further understand the benefits of such a system, we look at the business opportunities and also discuss their limitations in the end.

C. ORGANIZATION OF THE PAPER
The remainder of this paper has the following structure. Section II gives an overview of the SOFIE platform framework along with its mobile gaming pilot and Section III presents related work. The proposed architecture of the scavenger hunt game is explained in Section IV. Section V discusses the implementation details of the proposed architecture. Section VI presents the results from the performance and security analysis from testing the proposed system. Potential business opportunities are discussed in Section VII. Practical limitations are presented in Section VIII. Finally, Section IX presents our conclusions and discusses future work.

II. BACKGROUND
A. SOFIE SOFIE (Secure Open Federation for Internet Everywhere) is a three-year EU Horizon 2020 research and innovation project [7] that provides interoperability between existing IoT platforms openly and securely, thus simplifying the reuse of existing infrastructure and data, and allowing the creation of open business platforms. Blockchains and distributed ledgers form a natural basis for building trust between different parties by providing transparency and accountability to operations. Moreover, smart contracts allow the automation of many transactions and, thus, lower the operating costs of the system. The SOFIE architecture is a way of overcoming the lack of interoperability by federating the actions between different IoT systems using Distributed Ledger Technologies (DLTs). Figure 1 provides a functional overview of SOFIE architecture. It depicts the main functional components of the SOFIE framework, interfaces and cross-domain interactions with external components.

1) SOFIE FRAMEWORK COMPONENTS
The SOFIE Federation Framework is an example implementation of the SOFIE Architecture developed to support the SOFIE pilots and to serve as an example for future Architecture implementations. In the Architecture, the internal components describe types of functions, which can be implemented as separate components or as part of the interface components. The 6 internal components are: • Interledger, which provides support for operations spanning two or more ledgers, including support for atomic transactions over multiple ledgers.
• Identity, Authentication and Authorisation, which provides IAA functionalities for the different entities in the system by supporting multiple authentication and authorisation techniques.
• Privacy and Data Sovereignty, which provides mechanisms that enable data sharing in a controlled and privacy preserving way.
• Semantic Representation, which is used to enable interoperability between different IoT devices, services, and data by describing what functions they provide and what interfaces and formats they utilize.
• Marketplace, which allows participants to trade resources by placing bids and offers in a secure, auditable, and decentralized way.
• Discovery and Provisioning, which provides functionality for the discovery and bootstrapping of IoT devices, services, and data.

B. SOFIE MOBILE GAME PILOT
The focus of the mobile game pilot is to explore how DLTs can be used to provide new gaming features for players, as well as to validate the potential of location-based IoT use cases. It seeks to overcome known technical issues; in principle, the ability of DLTs to scale to cost-effectively support millions of active users per day with hundreds of transactions per second. Multiple use-cases that leverage IoT and blockchain technology are studied and implemented throughout the pilot to test their technical fit and performance for mobile gaming For research purposes, we have developed a prototype to understand the use of DLTs for content ownership by players, enabling them to collect and trade in-game content with other players (e.g. characters, weapons, equipment, parts). DLT provides player ownership of the asset, transparency, and consistency of asset attributes and transactions.
This paper presents our second use-case, utilizing a context-aware scavenger hunt game prototype using IoT beacons and an ecosystem backed by DLT. In the prototype, the player needs to solve riddles using received clues to reveal the location of the next IoT beacons. These beacons are used to provide the proximity location of the players when they visit the Point of Interests (POI). At each correct POI, the player answers a question, deducing the answer by observing their physical surroundings. If they answer the question correctly, the player receives the riddle regarding the next correct location. After visiting all locations in a hunt, the player is rewarded with in-game coins and item rewards, which are stored on a DLT.
The gaming pilot will also leverage SOFIE components to provide new gaming features and enhance player experience. Table 1 shows the usage of those components and their respective benefits.

III. RELATED WORK
Mobile gaming has undergone massive change and overhaul in the last decade. Mobile games that are being rolled VOLUME 8, 2020 out today are distinctive from their earlier counterparts, and are generally free-to-play. A number of new technologies that have come up in recent years are allowing the game developers to build games with better graphics, performance, intelligent bots, and immersive experiences.

A. BLOCKCHAIN
Blockchain, a peer-to-peer network introduced in 2008 [8], could be regarded as a shared digital ledger, in which all committed transactions are stored in a chain of blocks. These blocks hold the records of the transactions such as the exchange of assets or data between the peers, in a private or a public network. The ledger is shared, replicated, and synchronized among the member nodes in the network. Each transaction in the public ledger is verified by a consensus of a majority of the participants in the system and cannot be altered or reversed unless the change is agreed by the majority of all members of the network in a subsequent transaction [9].
Blockchain is enabled by integrating several core technologies such as cryptographic hash, digital signature, and consensus mechanism [10]. The blockchain leads to increased trust and integrity in the flow of transaction information among the participating nodes [9]. Bitcoin [3] is the first and most popular application of blockchain technology [11] and since its release in 2009, blockchain has attracted a lot of attention and has been applied to both financial and nonfinancial world applications.

B. INTERNET OF THINGS
IoT beacons have been adopted quickly over the last few years. With big industrial players, such as Google and Apple pushing for new standards (Eddystone and iBeacon, respectively), BLE beacon-based services are now more accessible to both the public and developers than ever before [12].
Localization is one of the most important applications of the beacons. Global Positioning System (GPS), which has revolutionized outdoor localization, has proven to be ineffective in indoor environments. Recently, such systems have been deployed to navigate in indoor facilities, such as museums and airports. For example, Hamad [13] and Houston [14] International Airports have deployed IoT beacons to aid passengers in navigating in unfamiliar spaces. Besides providing users with positional information, IoT beacons can also convey contextual information by measuring proximity to an object or an area. A bean can be attached to a nonstationary object, and the proximity information may trigger an event, allowing interaction between a user and the object. Ito et al. [15] implemented a proximity detection-based tour and navigation system that provides the timetable of nearby bus stops and the distances to nearby subway stations to the tourists. Similarly, Estimote implemented a Bluetooth beacon-based system in a museum to provide detailed information about artworks to nearby users [16]. The system employs a pull mechanism, where information is only provided on the user's request. Apart from localization and context-aware services, IoT beacons can also be used to better identify the activities of users. Vigneshwaran et al. [17] used beacons to detect fine-grained location and movement to better identify the activities of users. Similarly, Kashimoto et al. [18] implemented a system to keep track of senior citizens' activity information. The system requires users to wear a Bluetooth tag equipped with an accelerometer that is scanned by pre-deployed fixed scanners to identify the location of the users, while the built-in accelerometer identifies simple activities such as sitting, standing, and walking.
Specifically focusing on scavenger hunt games using IoT devices, initiatives can be found mainly in industry, although such approaches do not provide users with the ability to create their quests or games as we propose in our approach. One example of such type of game is Google Emoji Hunt [19], which was played by participants of Google I/O in 2018. By using the mobile phone camera, the player has to locate the emoji shown in the real world. Munzee [20] is another scavenger hunt game where players track down QR Codes hidden in the real world and capture them for points. The items are virtually collected using smartphones and the player wins badges and increases their level by collecting the items.
Blockchain is an emerging technology and the above works illustrate the advantages and potential for using blockchain technology in mobile gaming. In this paper, we discuss and evaluate the application of blockchain and IoT technologies to mobile gaming ecosystems. The use of IoT beacons in the context of games, in which real-world objects would be tagged, would enable mobile devices to interact with these beacons to get information. This possibility significantly expands the scope of opportunities, including the notion of playable Cities. The combination of Blockchain and IoT in mobile games is relatively new, and this paper proposes a novel scenario where players can create their hunt, involving areas from the physical world in a digital game.

C. BLOCKCHAIN IN MOBILE GAMES
The area of Blockchain in mobile gaming is still in its infancy, with not much of market research results. In order to support games, the system needed to provide high performance, and early blockchains failed to satisfy those needs due to their consensus protocol limitations. With time, new blockchains with improved consensus protocols were proposed, including EOS [21], Tron [22] and Nebulas [23]. Different from traditional games, the new blockchain games leverage a game server to perform core functions of the game and smart contracts on the blockchain network to process business logic transparently and autonomously [24]. Such a hybrid approach enables a game to utilize blockchain technology only for those features that benefit the game, while leaving everything else to the traditional game server, where performance is not hindered.
Casino and gambling games have become one of the most active decentralized applications in the blockchain ecosystem. These gambling games involve virtual currency that can be purchased with real currency. The transparent characteristic of blockchain technology improves the trustworthiness of gambling games. Santosi Dice [25], the very first gambling game on blockchain, was launched in 2012. The rules of the game were simple: the player places their bet on the number and the system randomly chooses a lucky number. If the number chosen by the player is smaller, they win, and if otherwise, they lose. Although the game mechanism is simple, it's a milestone for blockchain games. Afterwards, many similar gambling games flowed into the market, such as BetDice [26] and FarmEOS [27] on EOS, and TRONBet [28] on the TRON blockchain. Smart contracts on the blockchain are used to implement critical game rules and guarantee the randomness of the game.
As the blockchain technology is evolving, many companies from the gaming industry want to utilize the technology in mobile gaming. Blockchain offers genuine ownership of the virtual item in the game. It allows players to trade their items as cryptocurrencies, and the items can be circulated on the internet. CryptoKitties [29], one of the first blockchain games, was launched in November 2017 and at one point had more than 500,000 users. CryptoKitties is a simulation game about breeding, collecting, and trading kitties, which are indivisible and unique ERC-721 tokens implemented on Ethereum. The operations on kitties, such as selling and breeding, are functions implemented in smart contracts. Another blockchain game, Gods Unchained [30], is similar to the traditional Trading Cards Games that give players true ownership of their in-game items. In Gods Unchained, players completely own their digital items, giving them the freedom to trade, sell, and use their cards any way they like, just like owning real, tangible cards. Each set of cards are issued by smart contracts in limited quantity by minting them to the Ethereum network.
In contrary to the centralized database server of traditional games, the blockchain is a more open platform for game players and developers. User-Generated Content in games gives a lot of value to developers and players as endless content created by the community keeps the game everchanging and interesting. Cell Evolution [31], is one such game that uses blockchain to form a player community. Each player in this game acts as an individual and decides their evolution strategies. Players explore the evolution and mutation patterns to gain score and at the end of the game, they can upload their DNA information to the simulated world. Another such blockchain game, Last Trip [32], is a game where the developer only provides the basic framework of the story, while the players continuously contribute their content to the game by themselves.

D. HYPERLEDGER FABRIC
Hyperledger Fabric is a permissioned blockchain platform and one of the Hyperledger projects hosted by the Linux Foundation [33]. Fabric consists of various components such as endorsers, validators, the ordering service, and committers. Its modular architecture delivers a high degree of confidentiality, resiliency, flexibility, and scalability [34]. In a permissioned network, the identity of each participant is known and authenticated cryptographically such that the blockchain can store the information about who performed which transaction. Also, Fabric has extensive access control mechanisms built-in to limit who can (a) read and append to ledger data, (b) issue transactions, and (c) administer participation in the blockchain network [35].
Hyperledger Fabric supports modular consensus protocols, which allows the system to tailor to particular use cases and trust models. The fabric runs distributed applications written in standard, general-purpose programming languages, without systemic dependency on a native cryptocurrency [34]. It provides various configurable parameters such as block size, endorsement policy, channels, and database. Hence, one of the main challenges in setting up an efficient Fabric network is finding the right set of values for these parameters, depending on the application and its requirements [35].

IV. PROPOSED ARCHITECTURE
In this section, we present our hybrid architecture for the blockchain based scavenger hunt game prototype that utilizes IoT beacons. We consider four entities in the system: Game Developer, Game Player, Point of Interest (POI), and the Blockchain, as shown in Figure 3.

A. STAKEHOLDERS AND THEIR ROLES 1) GAME DEVELOPER
The game developer is responsible for developing and maintaining the scavenger hunt game. It provides an interface for playing the game pilot and using its services. The developer has complete access to the game data and can view or edit all the challenges, player profiles, and related information. Game developers are also responsible for setting up and administering the IoT beacons. They also provide services and tools for the development of new challenges.
2) GAME PLAYER Game players can access the game from the mobile application. They can join any challenge using the nearby scanning. They need a user account to access the data and play the game. Players can also participate in the creation of new challenges by using Web API (a Web app could serve as a user-friendly interface for this). This means creating new tasks and clues for existing beacons. However, a player would need to have developer account to access the restricted data and submit new challenges. Players can also customize their characters through the Blockmoji companion app and also list their creation for the trade on the SOFIE platform.

3) POINT OF INTEREST
A Point of Interest owner can access the system using a Web API. They can add hunts and challenges added by the POI company. They can monitor the offered rewards or also add new ones. They can access the system by having a valid account.

4) BLOCKCHAIN
A known and trusted decentralized application that shares and synchronizes transaction data across multiple nodes. It interacts with all the entities in the system and logs those interactions in the form of transactions. It allows organizations or members to come together as a consortium and collaborate to define the policies to control the network. It provides channels for efficient sharing of data and private communication for the users. There is a certificate authority that issues authentication keys to ensure secure communication. Chaincodes only live in the blockchain context and are used for accessing data stored in the blocks.
The blockchain is responsible for tracking the in-game assets that are stored as NFTs. They are used for issuing and managing rewards from the hunts and POIs. Player profiles and their respective data is also managed by the blockchain. Moreover, blockchain is also used as an ecommerce platform for trading of the in-game assets.

B. ARCHITECTURE FUNCTIONS 1) PLAYING THE SCAVENGER HUNT GAME
In the beginning, the player downloads and installs the Scavenger Hunt game application on their mobile phone. They accept location and Bluetooth permissions requested and logs to their account. If the player is using the application for first time, a new account is created by generating a user account and a Decentralized Identity (DID) for the blockchain wallet and it is stored on the game server. 2 illustrates the flow of the game from the player's perspective. While playing the game, the steps are as follows (following screenshots of Figure 5): (a) The mobile game requests for the location of the user by accessing mobile Global Positioning System (GPS), and displays hunts that start near the user location (note: playing the hunt works with BLE localization, but coarse GPS localization is used to present the player with the most relevant nearby hunts). (b) After selecting the hunt, the player is shown the details of the hunt such as the difficulty and rewards given upon the completion of the hunt. (c) After starting the hunt, the player receives the clue that points towards the location of the first point of interest. The game also activates the Bluetooth scanning for the discovering of IoT beacons. (d) As the player reaches the correct POI, the game detects the IoT beacon through Bluetooth and downloads the relevant task from the game server. Player needs to solve the task, which, in this implementation, is to answer a question about the player's physical surroundings. Solving the task will reveal the clue that points toward the location of the next POI. (e) The player progresses through the hunt by performing a series of such tasks and physically visiting multiple POIs. The user can skip any task or get relevant hints by using in-app tokens, which are received as rewards from completing hunts in general. (f) After performing the last task, the rewards are moved from the hunt escrow to the player's wallet address.
If the hunt gives non-fungible assets as rewards (Blockmoji items), they will also be moved to the player's wallet as well.

2) HUNT CREATION
(a) In the scavenger hunt game, anyone with a DID can create a hunt using the Web API. (b) The user can create a hunt by essentially defining a list of Beacon ID, clue, task and answer combinations. By linking each clue with a Beacon ID, each step in a hunt points toward a physical location. (c) After defining all steps in a hunt, the user needs to add custom rewards for the challenge. This reward can be game assets or in-app tokens. All the assets need to be a Non-Fungible Token (NFT) minted before creating the hunt. At the submission, the smart contract will move the assets from the creator account to the escrow from where they will be transferred to the player after hunt completion. (d) After checking all the requirements, the game server generates a Hunt ID. Hunt details are saved on the game server and only the information regarding the rewards is saved on the blockchain. (e) The hunt is published, and by using the coarse starting GPS coordinates, it will be shown to nearby users in the nearby hunt tab of the mobile client.

3) BLOCKMOJI
Blockmoji is a simple companion app to the main game prototype, and is part of the proposed ecosystem. The Blockmoji was also developed in Unity, and it serves the following pusposes: (a) Hunt rewards may include non-fungible Blockmoji item rewards. After the player has received an item reward from completing a hunt in Scavenger Hunt, the item appears in the player's Blockmoji collection. introduce its own game design issues. In our implementation, we're researching the simplest form of this idea (only two apps: Scavenger Hunt and this Blockmoji item management app). In our Scavenger Hunt game prototype, the Blockmoji items do not bring ingame benefits, but instead, the game acts as a source of these items. From this proof of concept we can see that such interoperability is at least possible, and one of the potential benefits DLT may bring.

V. IMPLEMENTATION
In this section, we demonstrate the feasibility of the system design with the prototype implementation containing a permissioned Hyperledger Fabric blockchain, IoT beacons, Mobile client and a server for the Scavenger Hunt game and the Blockmoji companion application.

A. MOBILE GAME CLIENTS
The Scavenger Hunt and Blockmoji clients were developed with the Unity game engine for Android and iOS mobile devices. The game is UI-based with text clues and tasks. The device's unique ID is used for identifying and signing in on the game server for both client applications.
In the Scavenger Hunt client application, the list of nearby hunts are regularly polled from the server based on the device's GPS location. In the response, the server includes all hunts whose starting GPS location is within a few kilometers radius from the player's location. In the current implementation, for testing purposes, the radius is a as wide as 12 kilometers. In a real life scenario, the range would be smaller by default.
While playing a hunt, the client regularly checks for nearby BLE beacons, with a scan period of 3 seconds and a detection timespan of 6 seconds (screenshot (a) of Figure 5). For this, a third-party Unity plugin was utilized, which is capable of detecting both iBeacon and Eddystone beacons. In this implementation, the game uses beacons that utilize the Eddystone protocol (the beacon aspect of this work is examined in more detal in the ''IoT Beacons'' sub-section below). Every time a new BLE beacon is detected nearby, the Scavenger Hunt client inquires from the server whether the detected beacon's ID matches the next POI's beacon ID. If it does, the game deems that the player is located in the correct physical location, and the client presents them a text question ( Figure 5 (d)). After answering the question correctly, the client downloads and displays the clue for the next POI. This continues until the player visits all POIs in the hunt. After the player completes the hunt, the client downloads the reward information and displays it to the player, as seen in screenshot (f) of Figure 5. If the experience gained surpasses a certain threshold, the player levels up and the client reflects that in its top header.
The Blockmoji client is very simplistic. After logging in, the player sees their character and can browse their items that they have received from the Scavenger Hunt game (more precisely, items received from all games using our standard are displayed, but, at the moment, Scavenger Hunt game prototype is the only source of these items). Each item has a slot, such as ''head'', or ''legs'' or ''pet'', to which the player can equip the item. Each item has an image, which the client downloads from the URL that is a property of every item. Each item is downloaded from the server as a JSON object, where the image URL and the slot are fields in that object. A list of attributes is an additional field. Attributes are a list of string name and number values. For instance, if an ''Investigator's Hat'' has an attribute named ''Deduction'' with a value of 10, a game that uses this standard may, if its designers wish so, interpret the hat in such a way that it would  give the player relevant in-game advantages, such as finding hidden objects more easily.

B. GAME SERVER
We developed a hybrid game server as part of our architecture that consists of a traditional backend server which is further connected to the blockchain network. Most of the game logic is run on the backend server for performing core game-related tasks without compromising the experience for the users. Blockchain is used for adding extra features to the core game such as user-generated content, ownership, trading, or even interoperability of game assets. If some game assets could be used across multiple games, even if a game server is discontinued, the asset could still preserve its value and continue existing on the blockchain.
The game server was developed on the Python Flask framework and deployed on AWS Lambda. It can be accessed through the REST APIs from any web or mobile application. It is also connected to a database to store the information related to the game and players. AWS DynamoDB was selected to address the database needs. Amazon DynamoDB is a key-value and document database that is fully managed and durable database with built-in security.
In order to interact with the Fabric network, we used Node.js Fabric SDK running on the AWS EC2 instance to interact with the chaincode, which exposes chaincode functions to the players. This allows loose coupling between the game application and the underlying Fabric network.

C. BLOCKCHAIN
We prototyped our scavenger hunt game pilot with a permissioned Hyperledger Fabric blockchain. We used AWS managed blockchain to implement the minimum required VOLUME 8, 2020  blockchain architecture for a working demo. Figure 6 illustrates the setup of the Fabric network with two organizations in the consortium with one peer node each. The network also includes one orderer node, two certificate authorities (CA) and one channel to log all the transactions. Table 2 summarizes the device types and their capabilities that were used to implement the Fabric network.

1) ORGANIZATIONS
Hyperledger Fabric allows organizations or members to come together as a consortium and collaborate in the formation of the blockchain network. The proposed network consists of two organizations, one for the game company who develops the game and another for the POI partner. For the purposes of this proof-of-concept, we control both imagined organizations. An organization joins a network by adding its Membership Service Provider (MSP) to the network. The consortium manages the Fabric network by establishing the policies that control the network. Organizations can be added or removed from the consortium through a proposal that is accepted with majority network members.

2) PEERS
A peer node in the Hyperledger Fabric network is an essential element that maintains a local copy of the ledger and runs chaincode containers to perform read/write operations to the ledger. Each organization has one peer node acting as the gateway for performing transactions. Peers are owned and maintained by members of the organization. These peer nodes also expose a set of APIs that enable the applications to interact with the network and its resources.

3) CHANNEL
A channel is the primary communication mechanism by which all the members of the network can communicate with each other. In the proposed system, there is only one channel and all the transactions between the members are recorded inside this channel. All the peer nodes and applications can join this channel. Channel are very useful as they provide private communication between the members. Channels provide an efficient sharing of infrastructure while maintaining data and communications privacy.

4) ORDERER
In Hyperledger Fabric there is a node called an orderer that performs the transaction ordering. Along with the other ordering nodes, they form ordering service. This ordering service is responsible for creating the blocks and adding them to the ledger. Any block generated by the ordering service is guaranteed to be final and correct. In our prototype, there is only one ordering node that validates the block and updates them in the ledger.

5) CERTIFICATE AUTHORITY
Hyperledger Fabric Certificate Authority (CA) issues Public Key Infrastructure (PKI) based certificates to the network member organizations and their users, who then use them to authenticate themselves in the messages they exchange with their environment. The blockchain network relies on these PKI standards to ensure secure communication between various participants. In our system, each organization has its own certificate authority to identify the users from the respective organization and grant the rights over the blockchain network.

6) APPLICATION
We connected the game application to the blockchain network through the channel. Just like the peers and orderer, the application will also have its identity that is associated with the organization. In our proposed architecture, we have two different APIs associated with their respective organizations. The game API acts as the interface for the backend for the scavenger hunt game and transactions by the players and game developers are submitted through this API. Another API is for the POI partners to interact with the network. All the transactions done through these APIs are be recorded on the channel and shared with other members of the network.

D. IoT BEACONS
Bluetooth Low-Energy (BLE) beacons are used in determining the player's physical location. BLE beacons are harder to spoof than GPS. That translates into less cheaters, which is important for competitive games, especially when monetary rewards are involved. In addition, beacons are more suitable for indoor positioning than GPS, whose altitude accuracy is generally not good enough for multi-floor positioning. Beacon signals do not travel well through thick floors, so beacons are located on. For our purposes we used the iBKS105 model by Accent Systems. However, any BLE device (even a Raspberry pi) can serve as a beacon in the game as long as it is configured as described below.
Beacons compatible with the Scavenger Hunt prototype use the Eddystone UID protocol. Each beacon has the same 10-byte namespace component, which signifies that the beacons are used for the Scavenger Hunt game. The mobile game client filters detected beacons based on this namespace. Each beacon also has a unique 6-byte instance ID, which is used to identify which location the player is in. To balance the battery life and detectability of the beacons, we use an advertising interval of 950 ms and a calibrated power of -21 decibelmillwatts. With these settings, a beacon can last for up to a year with a fresh battery (this varies between beacon models). We found this power level to be the most suitable one on average across different locations. Some locations are more open than others, where the beacons are detected more easily, and other locations have more walls and obstacles. Too high of a power is also not desired, as we do not want to detect the beacons from too far away. In fact, the mobile client filters out beacons that are detected from too far away. We use a Unity plugin named ''iBeacon'' by Kaasa solution GmbH. The plugin provides a coarse distance estimation functionality that detects whether a beacon is ''Immediate'', ''Near'' or ''Far''. The detected power levels compared to the calibrated power used in these three coarse estimations is not documented by the plugin provider, however, through experimentation we concluded that filtering out ''Far'' beacons did the most adequate job at preventing players from being incorrectly positioned when located in an adjacent room.
In theory the non-spoofability of beacons can be improved by utilizing Eddystone's time-varying EID (ephemeral identifier) instead of a static UID instance. This would render setting up impostor beacons non-trivial.
The imagined scenario for this use case is that the game developer or hunt designers wouldn't always have to acquire and set up their own beacons. Any IoT devices with a BLE capability and Eddystone support can be utilized for a game like Scavenger Hunt. Today, these kinds of devices are used for various purposes, such as measuring temperature, moisture, or proximity sensing. An existing infrastructure of such devices could be additionally used for a location-based games such as the Scavenger Hunt prototype. Such devices often support multiple broadcast channels, and can be used for games and other applications simultaneously. SOFIE's Discovery and Provisioning component (discussed above) can facilitate and automate the process of detecting suitable beacons, configuring them and adding them to the game database. It is conceivable that smart contracts could also be deployed for transferring micropayments to the holders of these devices according to their usage.

E. SMART CONTRACTS
Smart contracts for the game on the Fabric network is written in Go Lang using Algorithms 1 and 2. Smart contracts are used to help generate transactions that can be subsequently distributed to every node in the network. After developing the contracts, they were installed on the peer node that is connected to the channel. For other components of the network to interact with a smart contract, it needs to be instantiated on the channel. After instantiating, the contract is logically in Figure 6. There is one channel where all the entities perform the transactions and also one solo ordering node for the creation of the blocks. The chaincode for Scavenger Hunt was written in the Go programming language using Algorithm 1. We performed multiple experiments to test the performance of Fabric with ''creating new data'', ''querying data'' and ''updating data'' using the custom chaincode written for the game.
A. RESPONSE TIME For a quantitative system performance evaluation, various measurable metrics are required. The most common performance metric of any system is the response time required by the system to execute read and write requests. In our case, where the game system utilized a hybrid architecture of a centralized backend and a distributed ledger, the response time metric corresponds to the time that the system performs read or write transactions of the various game functions. We ran the experiment 50 times before taking averages for read and write requests. We found that it takes on average 2.247 s for a write request with a confidence interval of 0.011 s, and on average 0.026 s for a read request take with a confidence interval of 0.0007 s.  This delay is closely linked with the average time for block generation in the Fabric network, i.e. 2 s. This concludes that block generation has the highest impact on the write requests.

B. THROUGHPUT
In order to determine the throughput of the proposed architecture, we used Hyperleder Caliper, a blockchain performance benchmark framework, which allowed us to test different blockchain solutions with custom use cases and get a set of performance test results.

1) FIXED RATE
In the first experiment, we measured the throughput of the architecture by submitting multiple transactions to the blockchain at the Fixed Rate. We performed separate tests for creating, querying, and updating the data.
We ran the ''Create'' function test with a fixed rate of 250 transactions per second (TPS) until the total number of transactions reached 10000. With a fixed transaction arrival rate, the throughput for writing new data on the blockchain increased linearly as expected until it flattened out at approximately 177 TPS, the saturation point. When the arrival rate was close to or above the saturation point, the latency increased (i.e., from an order of few ms to around 1.5s).  Table 3, the send rate for querying the blockchain was set to 500 and it reached its saturation point at approximately 351 transactions per second with the latency increasing significantly around that point. In the last test, with a fixed send rate of 250 TPS, throughput for updating the data on the blockchain was 191 TPS, which is mainly depended on for writing the new data on the blockchain.

2) LINEAR RATE
In the second experiment, we explore the performance limits of the system architecture with a linear increasing of load intensity. However, finding the tipping point of the system this way is not easy, as it is more alike to a trial-and-error method. The linear rate controller linearly changes the TPS rate between a starting and finishing value (in increasing manner). This makes it easier to find the workload rates that affect the system performance. We performed separate tests for creating, querying, and updating the data, and the results can be seen in Table 4.

3) COMPOSITE RATE
In the second experiment, we ran the tests to determine the throughput of the architecture by submitting transactions at the Composite Rate. This was done to simulate a real-life scenario and benchmark the blockchain network. We performed these tests with a duration-based round, a total of 100 seconds. In this case, an initial 30 seconds of normal workload was followed by a 30 seconds of intensive workload, which was followed by 10 seconds of low workload and ended with another 30 seconds of normal workload. We performed separate tests for creating, querying, and updating the data, and the results can be seen in Table 5.

C. MODELING ACTIVE PLAYER SUPPORT
In order to estimate the maximum number of active players that can be supported in the game without any performance degradation, we calculated the daily active number of users supported by our hybrid architecture and maximum number of concurrent users at any given time. We make the following assumptions without loss of generality: (a) Ideal network conditions of the Player.  Table 5. These transaction frequency assumptions are consistent with early play tests that were performed for the game prototype. This number of transactions translates to completing one hunt in an hour, on a daily average. This means that the maximum amount of users supported per hour is the maximum number of transactions per hour, divided by the average number of transactions per hour. Table 6 shows the maximum number of users supported per hour, based on read and write transactions separately. VOLUME 8, 2020 From the calculation above, it can be seen that the major limiting factor are the write transactions on the blockchain. Using that, and with the earlier assumption that one play session lasts one hour, we calculated the maximum number of players that can play the game throughout the day without any delays: Maximum players / day = 76, 800 * 24 = 1, 843, 200 (1) This means that the maximum supported number of users is 1,843,200 daily active users, or 76,800 concurrent users.

D. BEACON DETECTION TIME
The detection time of beacons is very visible to the player. If the player is clearly in the correct room, and it takes too long for their mobile device to detect the beacon, it affects the gameplay experience negatively. As such, we targeted a maximum delay of 4 seconds. We tested beacon performance in various scenarios, and the results are presented in Table 7. The mobile phone model used for beacon detection testing was Huawei Nova 3. The detection times in the table do not include the centralized backend delay, which was 0.5 seconds on average. The real delay that the user experiences in the game is the beacon detection time plus this server delay to get the text task. The detection times may also vary depending on the phone model, and we also found that performing an identical test case at a different time of day can also produce different results (cases 1 and 2 in Table 7). This shows that beacon detection can be heavily sensitive to varying background noise signals, and the quality of the player experience may be inconsistent across many play sessions.
It is important to notice the high variance in the detection time results. In the first detection case (where the beacon is located at the same table as the phone) the longest recorded time it took to detect it was 35.0 seconds, while the average was only 6.7 seconds. In total, the average detection time was 5.8 across all cases. This is above our target of 4 seconds, but the game was still playable. In addition, the huge variance of the detection time negatively affects the player experience. If the player is used for a six second delay, and if in one unfortunate instance they have to wait more than 30 seconds (which happened in the beacon performance tests), then the player may start wondering if they even solved the clue correctly and whether they even are in the correct location, potentially feeling an urge to walk out of the correct area and try another location.
The detection times were measured by a mobile device that was already located in the correct room, and timing how long does it take to detect the room's beacon. In reality, the user walks into the room from another room, and sometimes the beacon is detected even before the user enters the correct room, resulting in a ''negative'' detection time. This may further affect the gameplay experience adversely through confusion, as players would receive location-based tasks while being located in the incorrect room.

E. SECURITY
In this section, we will be discussing the security features of the proposed architecture.
• In order to protect the game server from any security breaches, we make sure that the connection to the server is always secured. This uses security tokens and with a restricted sign-in. We set up the SSH Key authentication for remote access of the game servers that also disabled password-based authentication.
• Firewalls were used to block access to every port except for those that should be publicly available. We configured a firewall that serves as an extra layer of protection, limiting the components that are vulnerable to exploitation.
• As we used IoT Beacons for the scavenger hunt game, we protected them using a password for changing any properties of those individual Beacons. As we used Eddystone firmware for the beacons, it uses cryptography to further secure communication between a beacon and a service application when exchanging information.
In addition, as mentioned before, it is theoretically possible to improve beacon non-spoofability by using the Eddystone EID protocol, which would render setting up alias beacons harder.

VII. BUSINESS OPPORTUNITIES
It is possible that location-based IoT gaming would need to involve many entities. Our hypothesis is that such an ecosystem with different actors would gain from trust created through distributed ledger technologies. The potential different actors and their potential gains are as follows: • Providers of IoT beacons: From navigation beacons to temperature and quality assurance meters, the world is filled with various IoT devices-both stationary and mobile. In 2018 there were 23.14 billion connected IoT devices worldwide [2]. Holders of such devices have the opportunity to receive passive income as their beacons are used for location-based games. This process can be facilitated and automated with distributed ledger technologies and the Discovery and Provisioning component. In order to grow the domain of utilized IoT devices, mobile device users could scan for suitable beacons with the Discovery and Provisioning component. In the current implementation, this involves deliberate searching from the user. However, in practice, a Discovery and Provisioning-like software could run as a background process, even within a location-based game. When an IoT device is detected and deemed to be suitable for the game, it would be configured and provisioned to the game infrastructure through a smart contract on the blockchain. This smart contract would ensure that the game developer pays micropayments for the device providers as their beacons are used.
• Game Developers: Multiple game developers can utilize the same IoT beacons for different games. They can also partially share the same economy and in-game assets, such as currency and even virtual items. If they wish so, multiple game developers can make their games support inter-game non-fungible tokens. For instance, a reward item in one game could provide the player functional benefits in the Scavenger Hunt game, and a reward received from a hunt can be used as a cosmetic item in another game. DLT allows for such shared items to exist on a blockchain outside of the games themselves. In the gaming pilot, the Blockmoji companion application was developed as a proof of concept for an inter-game item management application.
• Players: Player play the game(s) and earn rewards from them. The awarded items can be used as cosmetics in the games or as items that provide benefits in a game. Players can trade these rewards with each other on a marketplace of non-fungible tokens, and earn money.
• Advertisers: In a complex network of mobile game advertising, blockchain technologies could potentially help combat fraud by offering more transparency in attribution metrics. In addition, distributed identity technologies could facilitate the anonymity of users and let them be in control of their data. By resetting decentralized identifiers, users can revoke the access to their ad profile from AdTech companies. A framework like this would facilitate AdTech companies' compliance with regulations such as GDPR.
• Points of Interest: Businesses such as restaurants, cafes, museums and malls (any businesses with a physical location interface with customers) could benefit from the traffic to their locations generated through a location-based game such as the Scavenger Hunt game experiment. When a player visits a point of interest to complete a task, they simultaneously become a potential customer. For instance, a cafe can design a hunt whose last task is at their shop, or a museum can design a hunt inside their exhibition, potentially making the tour more entertaining.

VIII. LIMITATIONS
One limitation of using IoT beacons for positioning is that one has to trust that they will not be physically moved in the future. For instance, if a cafe uses a small detachable BLE beacon for hosting a POI location, the beacon could be stolen, and cheaters could earn rewards unfairly. Combining BLE positioning with another positioning method, such as GPS, would improve the validity of positioning.
On the blockchain side, the race conditions must be handled properly. If two players complete the same hunt at the same time, rewards should be moved from escrow to players' account so that the global sum of coins remains the same as before.
Blockchain only works well where latency is not a factor, limiting the amount of available gameplay features. Almost all of the current Blockchain games do not have real gameplay and suffer from having a simple play mechanism and a short life cycle. Our proof of concept tries to solve this by adding a centralized server for most of the game operations and blockchain for added functionalities, but the theoretical maximum number of concurrent players still remains a significant limitation. Despite their potential, blockchains are having trouble effectively supporting a large number of users on the network. The technical debate to improve scalability has been hindered by the trade-off between the performance and security goals of the blockchain system.
For the game to be fun, the technology must not stand in the way of player experience. Transaction latency, wallet creation and other possible quirks of DLTs are possible pain points for the players. Moreover, a network transaction fee in a Blockchain can become problematic and some games may require necessary transactions for which fees are simply unacceptable to the players. If making a game for the masses, the benefits of DLTs should outweigh their shortcomings, and preferably be invisible to the player. Popular game markets, such as Google Play and Apple App Store currently do not accept cryptocurrencies as a payment method. Games or applications that accept cryptocurrencies need to perform payments using third-party exchanges, increasing security risks and costs. For the player, if it is harder to participate in the game economy than in a traditional system (banks, simple virtual currencies), then the game would not necessarily appeal to the masses other than DLT enthusiasts.

IX. CONCLUSION AND FUTURE WORK
An overview on the SOFIE framework, along with its components and the mobile gaming pilot was provided. A locationbased game that utilizes IoT beacons and DLT was developed for exploratory purposes, its architecture was described and the smart contract algorithms utilized in it were described. This Scavenger Hunt game prototype is a bare-bones example of a location-based game that uses beacons for positioning the player. The gameplay itself is extremely minimal, revolving around reading text tasks and answering questions. As such, the focus of this experiment was more on the technical side, investigating the performance and limitations of the technologies utilized in the game. Through performance tests, we estimated that the current blockchain architecture of the game prototype could support 1,843,200 daily active users or 76,800 concurrent users, limited by Hyperledger Fabric's write frequency. In addition, the performance of BLE beacons was evaluated, and it was concluded that their slow and irregular detection latency posed an impediment to player experience.
In the future, we plan to address the issues and challenges identified. We plan to extend the proposed system with an implementation on a different blockchain platform e.g. EOSIO blockchain. We also plan to extend our architecture by adding more games using the assets from the current games. We also need to evaluate the impact of the different SOFIE components on the performance of the mobile gaming pilot. In addition, it would be worthwhile to investigate the business opportunities and benefits of the SOFIE components and the whole platform.
This proof-of-concept may serve as a template for future researchers who wish to investigate IoT and blockchain technologies in the context of gaming. We described an example implementation of such an architecture. The performance may be improved, the adverse aspects of these technologies may be combated, and their additional yet unseen benefits may be discovered by future developers, designers and problem-solvers.