3.2.1. Blockchain

Blockchain technology, which gained popularity with the invention of Bitcoin, began to be used in applications because it offers some different solutions compared to database management systems created with SQL and NoSQL databases.

In general, the blockchain is used as an alternative to traditional databases and/or together with traditional databases, providing peer-to-peer transactions without the need for a central authority, keeping the data in pairs with a distributed ledger, linked in a chained manner in a Merkle-tree structure (Merkle 1980; Nakamoto 2008).

The blockchain technology has various advantages and disadvantages compared to applications working with traditional databases. While examining the characteristics of these differences, the types of blockchains and the architectures of the structures that have been created with the blockchain should be examined.

3.2.2. Blockchain types

Public/permissionless blockchains: structures where anyone can participate, create transactions, verify these transactions and update the state of the blockchain. All transactions and the state of the chain are transparent and accessible to everyone.

Private/permissioned blockchains: structures that have the opposite characteristics to public chains. Private blockchains are structures where only authorized users can access the blockchain and data is hidden from public access.

3.2.3. Blockchain-based web applications

Blockchain-based web applications can be examined from an architectural point of view with application, consensus and networking layers, as shown in Figure 3.1.

Application layer: the structure that defines the business part of the blockchain and regulates state transitions.

Consensus layer: the layer that enables the nodes to agree on the state of the blockchain and creates the decision-making mechanism of the decentralized structure.

Networking layer: the layer responsible for the reproduction and propagation of transactions, state transition messages and consensus messages (https://v1.cosmos.network/intro).

3.2.4. Blockchain consensus algorithms

The choice of a blockchain algorithm – like the choice between building a blockchain-based system and using traditional data management systems – is a fundamental choice point. It radically affects the capabilities, performance, security and operation of the application.

Proof of work (PoW): blockchain state changes are performed using computing power resources. The source of evidence required to establish a new ring or a new transaction is greater than that required to verify an established evidence. The idea behind this asymmetry is to prevent the system from being deceived by a fraudulent transaction.

Bitcoin, the most popular blockchain, also works with the PoW algorithm. In 2021, the daily average confirmation time (the average time for a transaction with miner fees to be included in a mined block and added to the public ledger) exceeded the monthly average of 800 minutes (Blockchain.com n/a).

Proof of stake (PoS): against the limits of the PoW algorithm, the proposal of the PoS algorithm, which was first suggested in a forum in 2011, is based on the concepts that a new node that wishes to participate in the block creation process must first prove that they have a certain number of relevant value tokens and lock/stake a certain amount of value into the escrow account. The locked amount is an escrow in order to ensure the security of the transaction. If the node performing the relevant transaction behaves inappropriately, it may lose the value it has locked in escrow and is not allowed to participate in any of the transactions to change the block state again, according to the rules.

3.2.5. Other consensus algorithms

Applications are being developed that use PoW and PoS algorithms in a hybrid way or with consensus algorithms that are developed with different mechanisms from start to finish. While these algorithms are sometimes developed based on users’ needs, sometimes they have to be used by considering the restrictions on the business logic side. Blockchain applications are brought to life with new algorithms every day and offered to the masses to use (Ferdous et al. 2020).

3.3.1. Art Shop web application

The art gallery application, with an inventory of artworks, was created with both MySQL(SQL), MongoDB(NoSQL) and a blockchain-based structure. With the art gallery application, the gallery owner can add and delete new artworks to their inventory and update the specified information of the works.

3.3.2. SQL-based application

Relational database management system MySQL 8.0.21 and PhpMyAdmin 5.0.3 were used to implement the SQL database structure created with the tables in the diagram shown in Figure 3.2. Apache 2.4.41 is used for server management, and PHP 7.4 is used for applications. As for servers, DigitalOcean’s servers with 2 GB memory/1 CPU were used with Ubuntu 20.04 operating system.

3.3.3. NoSQL-based application

For the NoSQL version of the Art Shop application, Mongo Atlas and MongoDB version 4.4.6 were used. On the server side, Ubuntu 20.04 operating system and DigitalOcean’s 2 GB memory/1 CPU system were used. Strapi 3.6.5 was used as the content management system.

Three main collections were created on the Strapi in MongoDB: customers, artworks and transactions.

3.3.4. Blockchain-based application

For the blockchain-supported version of the Art Shop web application, the Ubuntu 20.04 operating system was used in DigitalOcean’s 2 GB memory, 1 CPU droplet. Starport 0.16 was used to create and manage the blockchain. Go 1.16 was installed to run Starport. Starport’s frontend application works with “Vue.js”. “Node.js” and “npm” were also installed to run these packages on the server.

3.4.1. Adding records

In the Art Shop application, the shop owner has three main options when they want to add pieces of art to the inventory:

1. 1) adding data directly to the database with the command interface;
2. 2) adding data using the graphical interface of the database management systems;
3. 3) adding data using the specially developed application user interface.

The SQL- and NoSQL-enhanced custom commands can be used to add inputs in bulk with a json file or comma-separated values.

Adding new inputs is one of the tasks that can compare the performance of the systems. The scenario of a 150-line comma-separated values (CSV) file, seen in Figure 3.3, as sample data, and the art shop owner adding their inventory to the web application in one go, was implemented using the command interface. The SQL and NoSQL systems task was performed without any problems. It was completed in the times that can be seen in Figures 3.4 and 3.5. The SQL system performed the task of adding bulk data faster than the NoSQL system. While the “LOAD DATA LOCAL INFILE” command is used directly on the server for SQL, the “mongoimport” command, which provides connection to MongoDB Atlas servers via a local computer, is used for the NoSQL structure.

Multiple data were used in the SQL and NoSQL systems in order for the performance test to be meaningful during the addition of the entries, but since the Starport infrastructure used in the blockchain-supported system – as in all popular algorithms – actually uses Tendermint’s consensus algorithm, called BFT POS, the inputs must be added one by one (Ferdous et al. 2020). In order for a node to add more than one entry, the messages must be added to the Merkle-tree structure with unique hashes and proven one at a time.

An input has been added to the blockchain for the blockchain-based system that uses the Starport infrastructure, in which data is added one by one, due to its structure. This addition first required the creation of functions for the CRUD (Create, Read, Update, Delete) actions of the digital asset. The creation of the artwork structure as a digital asset on the blockchain was accomplished with the Starport command “starport type artwork Arttype name artist year owner”. Adjustments were then made to various proto and structural files for the API system for Starport’s web application. Then, with the command “artshopd tx artshop create-artwork ‘Painting’ ‘Name2’ ‘Artist 2’ ‘1999’ ‘0’ --from=dbtests”, the first registration of the blockchain was made on behalf of the user “dbtests”. Figure 3.6 shows the time associated with the record added to the blockchain by the validator of the chain.

Since there will be a query test later in the analysis, adding 150 records to the blockchain-based system and running the queries one by one, which took a total of 450 seconds, were both fully achieved.

According to the tests made, the order in time taken to add inputs, from fastest to slowest, is SQL, NoSQL, blockchain.

3.4.2. Query

Figure 3.7 shows the queries and operation times to query the names of the artworks starting with the expression “Name 1” among 150 lines, which are the sample data containing the artworks in the Art Shop application, from the relevant table in the database.

The detailed operation time was not displayed in the MongoDB command interface used for the NoSQL system. Before the query, the “setVerboseShell(true)” command was run to show the operation time at the end of the operation.

In Starport, which is used for the blockchain-based database system, only the following commands are available on the query side of the CRUD functions created with the “type” command by default. In order to run the query carried out in this system, which was created using the GO language, the query must be added to the system by developing it.

Query commands that come by default with the “type” command in Starport are:

“list-artwork”: outputs all entries; “show-artwork”: if there is an entry with the submitted id number, it sends a single entry as output.

3.4.3. Functionality

The first published version of MySQL database used for SQL was published in 1995, and MongoDB, used for the NoSQL system, was published in 2005. Starport, the open-source code developed by the Tendermint company, which is used for the blockchain-supported system, released its first version at the beginning of 2020.

There are database management systems applications that have been developed for traditional database systems that are legacies from the past, server files that are installed with one click in server companies, and ready-made database servers managed by the cloud. On the blockchain side, there are limited alternatives that provide managed server service in the cloud server. These are Oracle (Oracle.com n/a) and Amazon Web Services (AWS.amazon.com n/a) solutions.

For software development, the legacy from the past and SQL- and NoSQL-related resources are more. For blockchain-based database systems, the Tendermint consensus algorithm, Cosmos SDK and Starport solutions offer a start for application, consensus and network layers, but it is necessary to develop improvements and arrangements according to application needs. With its API support and frontend application, Cosmos SDK has facilitated the development of blockchain-based web applications in web applications.

3.4.4. Security

In web applications, management and functionality in parts such as membership and transaction authorizations are based on basic issues such as choosing a blockchain type and choosing an algorithm. With the Tendermint BFT POS consensus algorithm used, memberships to the application are started with the definitions in the config.yml file shown in Figure 3.8. As required by the algorithm’s working logic, nodes holding a certain digital unit stake perform asset transfer and transfer confirmation and earn rewards. In other words, the public id numbers of everyone who is a member of the system should be shared with all nodes. For an entry in the system to be approved to the blockchain, at least 2/3 of all validators must approve the transfer (Kwon 2014).

In SQL and NoSQL systems, IP addresses that can be connected to the database server can be defined in the database management systems layer. All requests can be blocked except requests from these IP addresses. In addition, by defining user accounts other than IP addresses, authorization can be made for users coming from a specific IP address and authorized with a username/password. In the PoS algorithm on the blockchain side, if a fraudulent transaction is detected, then the staked value may not be returned to the node and the account may be deleted from the chain completely.

In blockchain-based databases, the data history is completely original and cannot be changed, thanks to the blockchain technology. That is, system users cannot change the history of the created and branched chain. Historical data can be changed if firewalls in SQL and NoSQL systems are broken. This can be noted on special inspection that it has been changed on systems with a huge number of rows.

While the blockchain-based systems are being installed, the architectural structure can be designed uniquely to each chain. However, if the server running the blockchain system developed using Starport is shut down and the files are not backed up, the chain and the status of the chain will be permanently deleted. This also applies to SQL and NoSQL databases. For all database systems, at least one application must be running on a server to maintain the final data. The Cosmos SDK key-value store uses the Go language version of LevelDB (Github.com n/a). The state of the blockchain (key-value store) can be backed up by writing to an SQL or NoSQL database, so that even if no node is running in the system, it can be started again with the backup in the database.