A Usability Analysis of the DAO Concept Based on the Case Study of a Blockchain Game

Abstract

Games based on a blockchain exist in all variants and facets, mostly as single- or multiplayer games. This chapter deals with the implementation of a multiplayer strategy game (Connect Four), using blockchain technology for decentralized data storage and the entire game logic. The focus is on the use of the decentralized autonomous organization (DAO) principle, for coordination and voting within the teams. The chosen game just stands as an example; other games or gamification approaches in which users can take decisions collaboratively can be used here. A web application was implemented acting as a central interface between players and the blockchain. Hence, it was possible for players to compete against each other in teams and to collectively decide the next move by participating in a roundly voting. With the help of a standardized questionnaire, answered by each player after each match, possible impacts of the voting mechanism on the usability were determined.

1. Introduction

In 2008, the white paper for peer-to-peer payments was published by Satoshi-Nakamoto [1]. Various blockchains have been developed since then and are always discussed as financial innovation. Besides the FinTech aspect, however, there are also other possible purposes.

As Vitalik Buterin described in 2014, blockchains can also serve as decentralized autonomous organizations (DAOs) [2]. DAO refers to an association of like-minded members who control and manage it. A DAO is based on a set of rules in which the basic rules of the organization and its financial management are defined. Once this set of rules—for example, in the form of a smart contract via a blockchain—has been made accessible to members, these publicly visible rules can no longer be changed, except by a vote of the members [2].

A DAO is, therefore, not controlled by a central authority, but by the member collective itself. It can, for example, be a donation organization in which the donors can vote on to whom the collected sum should be donated. Voting can be viewed in a similar way to stock corporations. The weighting of the votes depends on the amount of money previously paid in. The voting can be executed via the so-called governance tokens [3].

The goal of this thesis is the investigation and implementation of a multiplayer game based on the DAO principle. The main idea is that a collective of players makes decisions together. Using the example of “Connect Four,” in which two teams with any number of players compete against each other, the next move of each team is decided democratically by voting using governance tokens.

To add excitement to the game, the winning team should be rewarded with the deposits (governance tokens) of the opposing team at the end of a match. A key aspect to consider when implementing such a community game is that a game is chosen where all the moves can be made public and there is no need for additional encryption of data on the blockchain. This is deliberately chosen so that the focus of this work is only on the implementation of the community game and more complex problems regarding data encryption are avoided, which could affect the implementation of the project in terms of time or even prevent it. The game “Connect Four” fulfills these requirements and is, therefore, a suitable candidate for this elaboration. Another challenge is to implement the game in a completely decentralized way so that all the calculations, data transformations, and game moves can be publicly viewed via the blockchain at any time, thus ruling out any manipulation of the game flow. Another key aspect to consider when implementing such a community game is whether both the specific nature of decision-making and the use of a blockchain can lead to unforeseen problems in the game flow for the participating players. Therefore, the research question can be described as follows:

RQ: What difficulties arise with regard to the usability of the game due to the use of the DAO principle and how do they affect the players’ experience?

To answer this question, a webapp will be developed, which implements the multiplayer game and communicates with the blockchain. Blockchain applications offer the advantage of creating pseudoanonymity between participants. More precisely, this means that although all the transactions and rules are visible within the blockchain, the transaction partners are anonymized by unique keys [1]. In this way, a blockchain offers a high level of transparency and, at the same time, a high level of anonymity [4].

This work is divided into four parts. In addition to related work and the architecture of the decentralized application (in short: dApp), the implementation and a subsequent evaluation are described. There, the usability of the application is evaluated and discussed by using a questionnaire. A conclusion and an outlook conclude this work.

2. Related work

Games based on blockchains, such as Bitcoin or Ethereum, are already popular today and do not represent a novelty. They are particularly popular because their rules are stored within the blockchain and are, therefore, transparent for all the participants [5]. There is a distinction between fully decentralized implemented games and a traditional game design approach paired with blockchain technology [6]. The former is characterized by a simple game structure, with clear rules and low complexity. An example is the game CryptoKitties [7]. A hybrid approach is often used, consisting of a combination of traditional methods and the blockchain.

As described earlier, the DAO approach is not a fundamental innovation within the blockchain environment (see Section 1). For example, Soichiro Takagi describes numerous use cases for DAOs in 2017. Among them are approaches such as Arcade City² (a ride-sharing platform), Open Bazaar³ (an e-commerce platform), and The DAO, which is an investment fund that invests in various companies while letting shareholders (DAO token holders) participate in votings [8]. The DAO has since been discontinued due to security vulnerabilities and the resulting loss of trust toward the DAO [9].

At the time of writing, no references to a game that uses the DAO principle as a central game feature could be found; therefore, it can be assumed that the influence of the DAO principle on usability has not been investigated so far. Thus, this relation represents an innovation within blockchain games as well as a clear differentiation from other papers.

3. Architecture

For the implementation of a DAO game based on a blockchain, several components are needed, which are described below. As shown in Figure 1, the user first communicates with a web server to obtain the required static files that provide the presentation logic in the browser. The business logic is split into three different dApps on the Waves blockchain.

Figure 1.

Architecture of the DAO game.

3.1 Web application

All the files implementing the presentational logic are delivered via a static web server. To maintain a fully decentralized approach, no business logic is implemented at this point.

This strategy allows a fully decentralized implementation of the game, but can be extended for new platforms, such as iOS or Android, if needed.

3.2 Blockchain

Since low transaction fees and fast processing speed of business logic are the primary concerns when implementing a multiplayer game, the Waves blockchain was chosen, which offers significantly shorter confirmation times and lower transaction fees than conventional blockchains, such as Ethereum or Bitcoin.⁴

Each dApp may have a maximum script complexity of 10,000 and script size of 32,768 bytes.⁵ For this reason, the business logic was divided into three different dApps.

3.2.1 dApp - main

The Main dApp acts as a unified interface and persistent data store. To perform an action within the game, players must communicate directly with this dApp. Each time the dApp is called, various checks are performed to verify the correctness of the request.

3.2.2 dApp - voting

The Voting dApp is called exclusively from the Main dApp and calculates the final result of the current round based on all votes that have been submitted. If there is no clear result, the first vote submitted will be used to decide which move will be made for the respective team.

The result of the calculation is then transferred and written to the data storage of the Main dApp.

3.2.3 dApp - inspector

The Inspector dApp is called by the Main dApp at each completed turn and then checks whether a team has fulfilled all criteria for a win or whether a draw has occurred. The result is also transferred and written to the Main dApp’s data store.

4. Implementation

Owing to the decentralized implementation of the game, different problems arise within the individual components. This section will give a general overview of the implementation and will address particular problems that occurred during the implementation.

4.1 Web application

The following section will mainly address the frameworks used for implementing the user interface (see Figure 2).

Figure 2.

User interface.

4.1.1 Next.Js

Since a game based on modern browser technologies requires a very dynamic display logic, the Next.js framework was used for this specific use case. With the aid of this framework, the implementation of very dynamic and interaction-intensive user interfaces can be greatly simplified. To ensure that each player always has a current state, the current game state is regularly queried via the Waves Node REST API and transferred to the player’s local cache. Next.js displays the current game board based on this data.

4.1.2 Waves-transactions

For the interaction of the individual players with the game, the library “waves-transactions” is used. With the help of this library, transactions to the Waves blockchain can be created and signed in the browser.

4.2 Blockchain

This section covers the specifics of the Waves blockchain. A special focus lies on the problems of the individual dApps. It is noticeable that there were frequent problems with control structures such as loops during the implementation. Since Ride is not Turing-complete, some steps within the game logic had to be implemented in a completely different way. The following section will give an insight into some of these problems.

4.2.1 dApp - main

Since there is no way to perform event- or time-based actions on a blockchain, a mechanism had to be developed to determine if a team had exceeded the maximum allowed round duration.

To do this, each transaction, regardless of which team it came from, was checked to see if the team currently taking its turn had taken longer than the current block height + 5 blocks (1 minute per block). If this is the case, the current team’s turn will automatically end as soon as a player from the other team makes a new transaction. The user interface calculates these values in real time and automatically indicates to the waiting team that it may now vote again if the other team timed out.

4.2.2 dApp - voting

The Voting dApp must calculate how many times a single field has been voted for each players submitted vote. This is problematic because Ride does not implement a native counting function.

First, all votes are collected in a single entry in the data store with the following format: “walletId_fieldNumber, walletId_fieldNumber.” After all players have voted, the previously generated entry is split by the delimiters “,” and “_” into a new list containing only the voted field numbers. Up to this point, it has not been necessary to use a loop, since Ride provides native functions for splitting strings. Since the new list can only be as large as the number of players, the FOLD function can be used to determine which field got the most votes. This value is returned to the Main dApp after the calculation.

4.2.3 dApp - inspector

The inspector must check at each completed turn whether a team has won the game or whether it has come to a draw. In doing so, he must examine the entire board for the previously defined victory conditions. As soon as there is a sequence of four game tokens from the same team on the board, the team has won the game.

To realize this requirement, the entire board is split into a multidimensional array (seven rows, six columns). This array is then traversed with two nested FOLD functions, and it is checked on a horizontal, vertical, and diagonal levels whether a team has won or whether there is a draw. For this purpose, each of these conditions is checked using index queries. By using index queries, the need for an algorithm that is entirely based on loops is eliminated and, thus, can be implemented in Ride.

5. Evaluation

This section presents the evaluation strategy and explains how it will be conducted. Subsequently, the research results are presented and discussed.

5.1 Evaluation strategy

Typically, the usability for human-technology interaction is described by means of ISO 9241-11 [10]. Since this is difficult or poorly measurable, the system usability scale questionnaire (short SUS) is used to answer the question of whether the DAO principle has an impact on usability [11, 12]. This questionnaire was provided to each user in the follow-up of each game.

Each participant was asked to state whether the DAO principle had an impact on usability and if so, what that impact was. For this purpose, a mixture of quantitative (Likert scale of the SUS questionnaire incl. SUS score) and qualitative (free text fields for a question) questions had to be answered within the questionnaire.

After all participants had completed the questionnaire, the questionnaire was evaluated descriptively in order to be able to measure the influence. The qualitative statements were evaluated and presented by a quantitative content analysis (SUS score for usability classification).

The results of this survey will be discussed within the upcoming sections after the successful completion of the statistical analysis.

5.2 Results

The following section will describe, evaluate, and then discuss the results of the evaluation. In the period from January 31, 2022 to February 13, 2022, the questionnaire was answered. Within this period, 42 persons answered the questionnaire, of which 34 were male and 8 were female. Twenty-seven of the 42 respondents were under the age of 30; the remaining were evenly distributed up to the age of 64. Approximately 83% of the respondents had at least a general qualification for university entrance (e.g., A-level).

The SUS score is determined from all the answers given in the questionnaire and is intended to provide a quick overview on the usability of the project. Its reliability, measured in the Cronbach’s alpha, is 0.92 (out of a maximum of 1). This means that the questionnaire has a very high reliability and, thus, fulfills one of the most important quality criteria that a questionnaire must fulfill [11, 13]. Questions are asked about the ease of use, the feeling of security, the complexity of the application, and the need for any support during use. The SUS score is a number that can have a value between 0 and 100. Basically, the higher this value, the better the usability. As shown in Figure 3, all values smaller than 50 are to be considered as awful. From 68 onwards, usability is considered okay. Everything else after that is rated as good or excellent. In this work, a score of 70 could be achieved. Thus, the usability of the Connect Four game can be rated as good. In addition to the questionnaire for the SUS score, free text fields were also evaluated. For example, 17 of the 42 respondents stated that they liked playing as a team. Likewise, the fun of the game (12 out of 42) as well as the design (four out of 42), the handling (four out of 42), and the low requirements for participation (one out of 42) in the game were explicitly emphasized. Four people did not provide any further information.

Figure 3.

SUS score.

Thirty-four people used the free text fields to indicate what could be improved. It is striking that 16 of the 42 people found the long delay after placing a vote to be annoying. Communication within the teams (two out of 42) and the design (seven out of 42) and the cryptic user names (six out of 42) were also rated as poor. Three people found playing in teams to be not good and would have liked to play on their own.

5.3 Discussion

As the results show, the DAO concept can be integrated very well into games that are based on a blockchain. Thus, the application was able to achieve an SUS score of 70 points and can be considered good, as already described. The score is comparable to the Facebook app for iOS from 2018, as described in [14]. Many of the respondents stated that the collaborative decision-making approach had been the most exciting and fun aspect.

The evaluation of the free text fields shows that there is potential for improving usability in the way communication is handled within the teams. A chat could satisfy this need and make the game more fun. Likewise, assigning user names would simplify the identification of players. As a result, the SUS score can be sustainably improved after the implementation of these functions. Since the game has been implemented almost entirely in a decentralized manner, as described in Sections 3 and 4, the long waiting times after a vote has been submitted cannot be prevented or can only be prevented with difficulty. This is because the performance of the game correlates with the performance of the blockchain.

When evaluating this application, it should always be kept in mind that it is a minimum viable product (MVP) whose goal has only been to investigate the DAO concept with regard to the usability of a game.

Moreover, as described in Section 5.1, the population of respondents consisted of known individuals. Similarly, the number of respondents was so small, 42, that the representativeness of the quantitative survey could be questioned. In addition to the size of the population, the homogeneity of the group may also have played a role. As described, it consisted mostly of people who were under the age of 30 and male. All these factors could have contributed to the good SUS score. Thus, it is not possible to clearly assess whether the created application could achieve an SUS score of 70 with a different constellation of respondents.

6. Conclusion and outlook

Based on the previously described sections, both a conclusion and an outlook are now presented. A description is given of how the application could be further developed and also which difficulties might have to be expected.

6.1 Conclusion

The goal of this work was to create a blockchain-based game that uses the DAO concept as a central element. The aim was to investigate the influence of the DAO concept on the usability of the game. For this purpose, the game was implemented in a fully decentralized way using the Waves blockchain. Based on a survey of the players, it was found that the DAO concept has an influence on usability that can be considered positive. The game achieved an SUS score of 70 points, which can be classified as good. Likewise, it was stated within the free text fields that the game, which is typically played as a two-person strategy game, definitely has potential with its multiplayer approach. It remains questionable whether the game would achieve a consistent score with a different group of players. The group of people surveyed was very homogeneous and known to the authors of this work. Nevertheless, it can ultimately be stated that the DAO concept has a positive influence on the gaming experience.

6.2 Outlook

The causal relationship of the DAO concept on the usability of games was answered within this manuscript. The game selected for this purpose has the property that all information is always available to all the players. Since all information is always on the blockchain, visible to all, the DAO concept cannot be applied to games such as sink ships or hangman without endangering cheat safeness.

It is, therefore, necessary to investigate which properties these games must fulfill, especially with regard to aspects of security, respectively, the encryption of data, so that they can be implemented in a practical way. This aspect is particularly important because, as described in Section 1, the winning team receives the stake of the opposing team.

Other areas of application for the DAO are also to be investigated. Can entire elections for municipalities, states, and the federal government be implemented via a DAO without the possibility of election manipulation? For this, the performance of the blockchain and the guarantee of voter anonymity must be carefully investigated. It, therefore, remains to be seen how and in what form the DAO principle will be used in the future.

Abbreviations

DAO	Decentralized autonomous organization
dApp	Decentralized application
SUS	System Usability Scale
MVP	Minimum viable product