Non-Face-to-Face P2P (peer-to-peer) Real-time Token Payment Blockchain System

1. Introduction

The rapid advancement of technology and widespread adoption of digital financial services have opened up a new era of convenience and efficiency in transactions. However, along with these benefits, the possibility of financial fraud has also increased, and the risk of financial fraud is increasing as the sophistication of voice phishing and the dependence on open banking systems increase [1]. Since these kinds of systems integrate information from various financial institutions, the criminals create potential opportunities to exploit vulnerabilities that may result in significant financial losses to individuals whose personal information is inadvertently exposed [2].

In the area of non-face-to-face transactions, challenges such as customer identity verification, ensuring transaction integrity, and preventing transaction refusal remain. These obstacles hinder the introduction of safe and smooth financial services that protect users from fraud while maintaining ease of use. Blockchain technology, with its unique characteristics of decentralization, immutability, and transparency, has been proposed as a potential solution to resolve these challenges. Fintech technology using blockchain can be used as a means of small payments at lower fees than bank transactions on a platform based on trust, as an automatic payment method to respond to recurring payments, as a safe transaction service to prevent fraudulent transactions in second-hand transactions, including bank inspection hours, and to respond to bankbook blackmail, a new type of voice phishing that sends random transmissions to bankbook account numbers exposed to online shopping malls.

A coin in a blockchain is a value object for transactions created by a blockchain mainnet project and transmitted on the mainnet and is used as a fee to record them. Since transactions use both value and cost, it is difficult to transfer full value, and since value fluctuates across exchanges, it is difficult to apply in real life. Blockchain mainnets are enabling the creation of tokens for various purposes to enable fintech, with the Ethereum mainnet providing a way to create ERC-20 tokens, and ERC-721 tokens for NFTs. The token is used as a proof of value, and Ethereum can be used as the gas that powers smart contracts (a fee for the transfer) to transfer the full value through a wallet. (A wallet is a set of programs that store your address and private key on the blockchain and sign transactions as they occur). Therefore, each wallet you use requires gas, which is used as a fee, to send tokens, and if you don’t have gas or don’t have enough, you can’t create transactions and therefore can’t send tokens. These gas shortage issues add to the complexity of use and have been a barrier to widespread blockchain adoption, and the risk of exposing and losing private keys due to changes or loss of the device that created the wallet has also been passed on to the user, limiting widespread adoption of blockchain-based distributed ledgers [3,4].

This paper proposes utilizes the key management module of a server-based blockchain wallet to securely store private keys in keystore files and databases, effectively minimizing the risk of loss, and since the web UI is used even when changing devices, there is no requirement to move private keys, so there is no risk of private key exposure. Also, by implementing the gas auto-charging function of the token transfer module, it automatically charges and transfers transactions when the gas is low, allowing users to transact smoothly without the burden of managing gas costs [5]. The system’s transaction verification module, Transaction Explorer, utilizes transaction ID to ensure transaction integrity and non-repudiation without exposing personal information. It also introduces advanced security measures such as blocking overseas access IPs and DDoS defense to safeguard user data. It aims to provide a P2P online payment blockchain system that the public can use conveniently and safely by implementing an identity authentication function using smartphones and a platform-independent web application [6].

This paper is organized as follows In Chapter 2, we review existing research and solutions in blockchain technology that can address the challenges and issues faced in blockchain transactions. Chapter 3 introduces our proposed face-to-face peer-to-peer real-time token payment system. In Chapter 4, we demonstrate the implementation principle of the main functions of the system through implementation, and in Chapter 5, we verify the operation of the service through performance testing and analyze the implemented functions and performance. Finally, we evaluate the proposed system and conclude in Section 6.

2. Related works

This chapter introduces ERC-20 and MetaMask as the underlying technologies of existing blockchains proposed to solve the problem of non-face-to-face transactions and examines their limitations. It also describes the underlying technologies used to develop the application proposed in this thesis and explains the improvements made to improve the limitations of the existing underlying technologies.

2.1. ERC-20

Ethereum’s ERC-20(Ethereum Request for Comment 20) was first proposed by Vitalik Buterin as an API standard for creating, managing, and using tokens [7]. The purpose of the ERC-20 API was to create a standard interface for blockchain users to create tokens and send and receive them [8]. It is typically used in wallets like MetaMask. The ERC-20 API consists of six mandatory functions (totalSupply, balanceOf, transfer, transferFrom, approve, allowance) and two events (Transfer, Approval), as listed in Table 1 [9].

This approach uses smart contracts that run on the Ethereum EVM, written in the programming language Solidity, compiled, and registered on the Ethereum blockchain via transactions [10]. Creating and managing multiple tokens requires a lot of work, as you need to develop and manage solidities individually, and there are limitations that make it difficult to manage as there are no guarantees on behavior. To improve these issues, this paper presents an easy way to create ERC-20-like tokens using SCT-20 proposed by the Symverse blockchain [11].

2.2. MetaMask

In blockchain, a wallet is an application designed to generate, store, and manage private keys and to send and receive coins and tokens, which are assets on the blockchain. Once a user creates a private key through their cryptocurrency wallet, they can generate a public key, and the hash value of the public key creates an address on the blockchain. Transactions can be made through this address, and all transactions are recorded on the blockchain network and can be viewed through the Explorer. MetaMask is a web browser plugin application used by most users as a cryptocurrency wallet for storing ERC-20 based tokens that operate on top of Ethereum and the Ethereum blockchain. MetaMask allows you to store and trade Ethereum, integrate MetaMask into decentralized financial applications, and manage and trade various tokens and NFTs. MetaMask stores wallet settings, transaction data, and more in the form of LevelDB. The path to the LevelDB in the most popular browsers Chrome and Edge is shown in Table 2. In Table 2, PROFILE refers to the user profile set in the browser, which has the value ‘Default’ when the user does not use multiple profiles. The ID is a unique ID given to the browser extension, with different values depending on the browser: ‘nkbihfbeogaeaoehlefnkodbefgpgknn’ for Chrome and ‘ejbalbakoplchlghecdalmeeeajnimhm’ for Edge [12].

MetaMask expose your private key when you change devices, and while the “Clear browsing data” feature doesn’t delete the extension’s data, removing the extension directly from the browser deletes the entire folder containing LevelDB, which is irreversible and irreparable. To improve this problem, this paper does not store the private key on the device, but on the server’s keystore for safe storage.

2.3. Limitations of Existing Solutions

A blockchain wallet is used to store private keys, generate signatures, and create transactions on behalf of users. In short, it’s an application that allows you to make real-time payments on the blockchain. If we divide wallets into categories, the first case is web wallets, which are available through any web browser and are convenient and easy to use. The web interface has compatibility issues with mobile devices such as smartphones and is vulnerable to DDoS attacks over the Internet. In addition, it is necessary to secure the user’s key due to the exposure of the private key when moving the key. In the second case, when using web browser extensions such as MetaMask, the problem of deleting private keys that are difficult to recover due to browser deletion or extension deletion is the biggest blind spot, as pointed out in Section 2.2. In the third case, a mobile wallet using a smartphone is highly portable, but puts the user in control and responsibility of their keys. The worst-case scenario for the security of your keys is that if you lose your smartphone, you won’t be able to get them back, or if you change your smartphone, your keys will be exposed to the outside world, and you’ll have a hard time figuring out how to move them. In the fourth case, if you use a desktop wallet, your private keys are either stored on your PC or hosted by a third party, such as a service provider. The disadvantages of storing your keys on your PC are that they may be compromised or deleted, and if they are hosted by a company that offers customization services or hardware wallet services, you may have to pay for them [13].

The wallets listed above are storage wallets used to store coins or tokens. Therefore, it is inconvenient to manage the coins used as gas to transfer tokens, and there is also a difficulty in purchasing and transferring through the exchange when there is a shortage of gas. This causes great inconvenience in the use of payment transactions between individuals and is a major obstacle to blockchain activation. In this paper, we implemented the core function of automatic gas charging in the token transfer module in Section 3.4, so that gas is automatically charged when transferring tokens, so that token transactions between individuals can be carried out without the need to manage gas, eliminating the obstacles to token transactions.

In addition, we propose a web app wallet so that various types of wallet applications can be applied to various devices (smartphones, tablets, PCs, etc.), and this web app method can be used with the same interface on all devices, and there is no key exposure when changing the wallet due to device change, and there is no key loss when the device is lost, and it is designed to protect against DDos attacks that are vulnerable to server-based wallet services using 3. 5 DDos protection module is used to defend against DDos attacks that are vulnerable to server-based wallet services, and 3.2 Key management module creates a wallet using a low-capacity keystore such as list 1 and stores a secondary backup in the DB to protect against key loss.

2.4. Background Technology

2.4.1. Ethereum Keystore

Ethereum Keystore is a means of authenticating oneself for a specific Ethereum address, and it is a file that encrypts Private Key with Passphrase [14,15]. To obtain a Private Key, one must know both the Keystore file and the Passphrase, and for usability purposes, the Private Key is not directly exposed and instead, the Keystore and Passphrase combination is used to create a secure standard for transactions [16].

• Generating a Keystore

The Ethereum platform generates a Private Key and a Public Key using the ECDSA (Elliptic Curve Digital Signature Algorithm). The passphrase is encrypted using a one-way cryptographic algorithm called “Scrypt” to generate a Derived Key, as shown in Figure 1 [17].

For the decryption of the Private Key, it is encrypted using the AES algorithm as shown in Figure 2 and then it needs the generation of Cipher Text.

The MAC for verifying whether the user-input Passphrase matches is stored in the keystore by concatenating the last 16 bytes of the Derived Key (32 Bytes) with the Cipher Text and hashing the result using the SHA3-256 hash function, as shown in Figure 3.

The resulting keystore file created in this way is shown in list 1.

• Decrypting Keystore

To decrypt the keystore, you must first verify that the entered passphrase is correct. Based on the entered passphrase, a new Derived Key and MAC are generated and checked for a match with the MAC within the keystore. If a match is confirmed, the new Derived Key, Cipher text, and cipher parameters information within the keystore are input into the AES decryption algorithm to decrypt the ciphertext into the private key, as shown in Figure 4 [18].

2.4.2. Symverse

Symverse is a layer-1 blockchain platform with one-second block finality based on self-sovereign distributed identities, using the SYM coin [19]. It uses a unique 10-byte ID system with an ID document which contains 20-byte Public Key Hash used as an address and a 10-byte ID system consisting of a network identifier (SymID, 2 bytes), CitizenID (6 bytes), and account identifier (2 bytes). Symverse is a collaborative blockchain service that can be extended to independent blockchain platforms based on the Symverse platform. Its block creation method is an enhanced BFT (Byzantine Fault Tolerant) appling strategic voting theory and PoS (Proof of Stake) to achieve fast block finality [11].

• SCT-20

SCT (Symverse Contract Template) is a template protocol designed to make it easy to create and operate smart contracts within the Symverse blockchain [20]. In the case of Ethereum, the ERC-20 protocol allows you to write a smart contract with Solidity and register it on the blockchain through a transaction, and operate the smart contract through the EVM [20], but in Symverse, SCT-20 is a template that provides standard inputs and outputs as shown in Table 3 to easily create a token smart contract on the blockchain with data type JSON via RPC. To create an SCT contract, use the SCT_CREATE Function in Table 4 and pay the transaction fee of 0.8049 SYM coins. The SCT contract generates a transaction using the RLP (Recursive Length Prefix) encoded value of array (“0x14”, 0, array (“SYMBOL NAME”, “SYMBOL”, convertEth2WeiHex(10000000000, 18), SymID)) in the input parameter of Table 5, converted to Hex, and sends it to the Symverse blockchain to create a token smart contract. To transfer the generated token, we use the SCT_TRANSFER function in Table 3 and set the gasPrice in Table 4 to 7,000 to transfer the token.

• Transactions

A transaction is an act of recording a ledger in a block on the blockchain, and once a transaction is recorded, it cannot be modified or deleted. In Symverse, transactions include normal transaction behavior, SCT transactions, and Deposit transactions [17]. The data required for a transaction is shown in Table 5.

The transaction of general transaction behavior is to transfer SYM coins, SCT transaction is to transfer smart contracts, and Deposit transaction is for interest distribution. The gas consumed by a transaction is calculated by the following formula.

The gas consumed in a transaction is calculated by the following formula.1:

Consumed_gas = base_gas

+ (number of none-zero-byte) *680

+ (number of zero-byte) *40

+ contract_operation_gas

Formula 1. Calculate consumed gas.

Consumed Gas is calculated as the base gas rate (base_gas) set in the blockchain plus the number of non-zero bytes of input_data*680, and the number of zero bytes*40 plus the contract operation gas rate.

The token transfer transaction (1) prepares a private key corresponding to the sender’s SymID, (2) retrieves the recent transaction nonce in the SymID’s blockchain, and (3) prepares the raw transaction data as follows.

a. Add 1 to the recent transaction nonce. b. Prepare $input = array (“0x14”, “0x1”, array(“Receiver SymID”, convertEth2WeiHex(1000000000, 18))) to be used as transaction input and prepare, RLP-encode the sct_data d.Prepare the transaction data. $tx_req = array (“from” => “Sender SymID”,”to” => “Contract ID”,”gasLimit” => bcdechex(2000000), “gasPrice” => bcdechex(100000000000), “value” => 0x0, “nonce” => LatedNonce+1, “type” => “1”, “workNodes” => array(“Work Node SymID”), “input” => “0x”.RLP(sct_data)) e. Sign the transaction data. (4) Send an RPC from the signed data as a JSON data type. $param_arr = array (“jsonrpc” => “2.0”, “method” => “sym_sendRawTransaction”, “params” => array($tx_raw), “id” => 1) Use the returned transaction hash to get a transaction receipt to check if the transaction was processed successfully. You can see the transaction processing flow in Figure 5.

The next chapter will introduce the details and architecture of the system proposed in the thesis, and the various modules that address the problems discussed in this chapter. We will also provide an evaluation of the system’s performance, security, and usability, demonstrating its potential to provide a comprehensive solution for non-face-to-face financial transactions.

3. Token Payment Blockchain System

The proposed token payment blockchain system is a secure system that enables real-time token transfers between individuals or parties without exposing personal information. Once the transaction is completed, the transaction history can be verified by anyone using a wallet or using a separate blockchain scanner. This architecture consists of five modules: a module for wallet owners to generate and store private keys in the keystore, a module for checking and charging insufficient gas in the wallet, a module for sending and receiving tokens, a module for DDoS defense of the system, and a module for real-name authentication of the keystore.

3.1. Overall Architecture

The blockchain system consists of key management module, token management module, token payment module, DDos defense module, and real-name authentication module for legacy system. The key management module efficiently generates, changes, and retrieves private keys in conjunction with the keystore, while the token management module manages tokens by creating, querying, minting, and burning them. The token payment module automatically charges and sends gas when a general user has no gas. The DDos defense module is composed of distributed attack prevention and blocking of overseas access to protect the server, and the real-name authentication module authenticates the wallet according to domestic law. Figure 6 shows the module-by-module configuration and interconnection of the system that enables P2P real-time payments based on the server.

The control flow of the proposed system is as shown in Figure 7. When the user requests to send tokens by entering the blockchain address and token amount of the recipient on their smartphone, the key management module reads and decrypts the user’s keystore to extract their private key for transaction signing. The signed transaction is then sent to the token transfer module. When the token payment is made, the gas of the sender’s blockchain address, SymID, is checked. If the gas is insufficient, the gas is automatically recharged to sender’s SymID account and the transaction is sent to the nodes of the blockchain. The transaction sent to the blockchain in the nodeis recorded in a block and, after going through the PoS (Proof of Stake) consensus, the block is confirmed and permanently stored on the blockchain. When the recipient requests to check their token balance in their wallet, they query the node through the token management module and he receive the balance information data.

3.2. Key management module

The key management module generates a Private Key as a 32-byte hexa code by creating a 256-bit random number when the user requests to create a wallet by entering a passphrase. It also generates a corresponding Public Key and Public Key Hash and stores them in the file system as a keystore. The generated Public Key Hash and the user’s ID are sent to the Certificate Authority Server of the Symverse blockchain to create a SymID, which is an address used in the Symverse blockchain, and store it in the DB. Users can send tokens with just their ID and passphrase at login without having to remember their SymID. The passphrase for the keystore can be changed, but the Private Key and SymID cannot be changed. When a user requests to sign a transaction Raw Code, they enter the passphrase to decrypt and extract the Private Key from the keystore, sign the Raw Code, and create a transaction.

3.3. Token management module

The token management module is responsible for creating tokens that represent the initial supply quantity and can mint or burn the token amount as needed. Token minting on the Symverse blockchain can be done using the SCT-20 template, which has a minting function to increase the total token issuance amount and a Burn function to decrease it. To create a token, you need to input the token symbol name, symbol, total issuance quantity, owner SymID according to the JSON convention of SCT-20 and sign the generated bytecode with the private key extracted from the keystore using a passphrase. The bytecode is then converted into a transaction and permanently registered on the blockchain. To retrieve information such as the token contract address, you can query the blockchain using the hash value of the returned transaction receipt.

Figure 9. Token management module.

Figure 9. Token management module.

3.4. Token transfer module

The Token Transfer Module is responsible for transferring tokens between users. When a user sends tokens, gas is consumed to execute the smart contract, and the user must manage the gas separately, making it difficult to use. To make it easier for users, a module is provided so that it manages the gas consumption payment instead of users. To transfer tokens, the user generates bytecode and signs it is using their private key. The gas consumed by the transaction is then calculated. If there is not enough gas, the Contract Owner requests that SYM coins has to be automatically recharged to the SymID account on the blockchain. In the next step, the transaction is sent to the node and permanently recorded in the block through consensus algorithm so that the tokens ae transferred to the recipient.

Figure 10. Token transfer module.

Figure 10. Token transfer module.

3.5. DDos protection module

The current token payment system has been developed for the purpose of actual use in Korea, so the module aims to block overseas IPs so as to comply to Korean laws for real-name authentication and to indiscriminate attacks from overseas. Based on the built-in database of global IP address allocation, it extracts IP address allocated to Korea and allows access only if it is included within the Korean IP address range. It also manages DDoS source IPs separately in the database to block access, and effectively defends against DDoS by handling traffic from the built-in database without traffic increase on the main DB during multiple loads.

Figure 11. DDos Block Module.

Figure 11. DDos Block Module.

3.6. Real name verification module

The real name verification module interfaces with external legacy systems. When a smartphone user enters their name, phone number, date of birth (6 digits), and the first digit to denote the sex code in the resident registration number, the server converts it into the format requested by the related institution and sends a response code to the smartphone number via SMS (Short Messaging System). The user inputs the response code, and the module verifies their real name by receiving a response from the credit information management institution and performs real-name verification for the keystore.

Figure 12. Real name authentication module.

Figure 12. Real name authentication module.

4. Implementation

The proposed system is composed of the commonly used server module, CentOS, and Apache, PHP, and mySQL. The overseas IP blocking database is separately configured using SQLite. The blockchain is integrated with the Symverse mainnet through a service node installed for the users’ convenience. Especially, the user interface is programmed by using Flutter language framework provided by Google so that it enables various devices such as smartphones, tablets, and PCs to utilize the proposed system.

4.1. System Environment

The implementation system consists of a web service server and a blockchain work node, called gsym. The web service is installed with CentOS as the operating system, Maria DB as the database, Apache as the web server, and PHP as the scripting language to implement the REST server. The user interface is developed in Flutter language using Android Studio and is released as a web version uploaded to the server for users’ convenience through web browsers. The overseas IP blocking database is implemented using SQLite3 to avoid affecting the internal logic of the main database. The table below lists the environments and libraries used in the implementation.

Table 6. List of environments and libraries.

OS	Centos 7.4.17	Database	mySQL 5.7.36sqlite3
Language	PHP/HTML/Dart/Javascript	Webserver	Apache 2.4.52
Webserver-plugin	Php 7.4.1Scrypt 1.4.2	Blockchain	symverse
UI framework	Flutter/Bootstrap		gsym
Test tool	JMeter V5.5	Browser	Chrome version 111.0.5563.66 (build) (64bits)

Table 6. List of environments and libraries.

OS	Centos 7.4.17	Database	mySQL 5.7.36sqlite3
Language	PHP/HTML/Dart/Javascript	Webserver	Apache 2.4.52
Webserver-plugin	Php 7.4.1Scrypt 1.4.2	Blockchain	symverse
UI framework	Flutter/Bootstrap		gsym
Test tool	JMeter V5.5	Browser	Chrome version 111.0.5563.66 (build) (64bits)

4.2. Wallet Creation

To use the wallet, generate a private key for each user who has completed smartphone authentication, save it as a keystore in the filesystem, and send the key hash to the Symverse CA server (https://mainnet-ca.symverse.com/ca/v1/citizenInfo) corresponding to IF_003 in Table 9 to generate a SymID by sending JSON data {“id”: {number},”mobileNum”: “{smartphone number}”, “publicKeyHash”: “{key hash}”, “userNm”: “{user name}”, “verificationType”: “CELL_PHONE”} as a POST request and get back the generated SymID and store it in the user table to map the user ID and SymID. In this case, the keystore stored in the file system is re-stored in the backup table corresponding to the SymID, so that the keystore in the file system is redundant. This is used as a backup in case of accidents such as bulk deletion of keystores stored on the server.

4.3. Token Creation

The smart contract used in this paper is created by the smart contract by creating a transaction using the list 2 Array of SCT-20 input parameters and sending it to the Symverse blockchain. In other words, instead of writing smart contract code in Solidity like Ethereum, it creates an SCT-20 contract on the Symverse blockchain using the SCT-20 contracts and transactions described in Section 2.4.2. As a result, a smart contract ID of “0x4801e91a5068757a9484” was created link (https://scan.symverse.org/v2/sct2x_token/SCT20/0x4801e91a5068757a9484).)

The smart contract ID is a required parameter when searching for the corresponding token or putting a transaction according to the transaction, Sct_data is encoded with RLP (Recursive Length Prefix) as shown in list 3.

If you put this as the input value of Table 5 and sign the array of Table 5 and send it to the work node as a transaction, the block is confirmed, and you can see that the token is created as shown in list 4.

In addition, another token can be created in the same way, and the implementation system is designed to store the smart contract ID in the DB as a separator so that all token transactions can be operated.

4.4. Balance inquiry

This is the most used feature of the wallet, and it calls the balance corresponding to the blockchain address, SymID. The data flow for the balance inquiry is shown in figure. 13, and the client to make the call is a web app developed using Flutter, (1) the web app completes authentication for the user ID; (2) the web app returns the balance for the user ID as JSON-formatted data {“act”:”actGetBalance”, “domain”:”NooWeb”, “user_id”:”doltwo”}. as an asynchronous HTTP request (3) A REST API written in PHP that first checks for DDos Protection on the server and then looks up the SymID DB corresponding to the authorized user ID, (4) Request this as JSON data {“jsonrpc”:”2.0”, “method”:”src_getContractAccount”, “params”:[“0x0ced1024eed02b234df2”,”0x00000000000000000001”,”lastest”], “id”:1} to the Symverse node gsym using RPC (5) The node responds with {“jsonrpc”:”2.0”,”id”:1,”result”:{“balance”: 10000000000000}} and (6) sends this returned data to the webapp as JSON as {“est_id”:”0x00000000000000000001”,”balance”: 10000000000000}} to display the SymID address and balance in the web app.

Figure 13. Control flow diagram for a balance inquiry.

Figure 13. Control flow diagram for a balance inquiry.

4.5. Token transfer

Token transfer is a user transfer function and is shown in Figure 14 as a diagram. (1) A sender with a user ID token authenticated through a web app written in Flutter checks the recipient’s SymID by looking up the phone number or name, and adds the number of tokens, and (2) requests token transfer to the REST API server with JSON type data. (3) The server looks up the sender’s SymID, (4) checks the balance of the SymID, (5) checks if the sender has more than the number of tokens to transfer, and (6) creates a raw transaction through the private key management module, signs it, and requests transfer to the token transfer module. (7) Check the gas of the SymID of the sender of the transmitted raw transaction, and if there is insufficient gas to transmit, (8) Send an amount calculated by a formula from the token transfer module to the blockchain node to automatically charge the sender’s gas, (9) Confirm the receipt for this operation, and (10) Send the raw transaction data to the blockchain node, GSYM. (11) Retrieve the receipt for the transaction, and (12) send the result to the web app.

The token transfer module automatically recharges SymID that are low on gas, eliminating transfer errors due to low gas and allowing users to transfer tokens without considering gas.

4.6. DDos protection

DDos defense consists of two components: a part that checks the nationality of the IP and blocks access if it is not an authorized nationality, and a DB that maintains a blacklist of IPs for brute force attacks on the web server and blocks access. In this case, the nationality and blacklist for IP use sqlite3, which is a separate DB separated from the main DB, and only sqlite3 works in case of an accidental attack to protect the main DB, mysql. Specifically, when a web app makes a connection using the following table specification, the REST API server can determine the connection IP using the PHP environment variable $_SERVER[‘REMOTE_ADDR’]. The corresponding nationality search uses the following SQL query written in PHP language to check the table of IP bands for each country entered in sqlite3.

Block international access using the country code and allow only local users. Also, check the access IP $_SERVER[‘REMOTE_ADDR’] against the blacklist and allow only if it is not applicable. DDos Protection imposes a load on the server by investigating every connection, and we will cover load testing for wallet creation and balance retrieval in Chapter 5 of this paper.

4.7. Database

The database consists of tables for user information, wallet, and transfer, as well as tables for token, real-name authentication logs, and IP for DDoS defense. Table 7 summarizes the database table list for system implementation to operate a service.

4.8. User interface of client side

The user interface of the client used by wallet users is organized as shown in Table 8.

The interface for the wallet user who receives payment is composed of menus that allow them to view transaction history (as in Table 9) and exchange the received tokens into fiat currency.

The platform operator’s interface is configured with menus such as statistics management, member management, and deposit/withdrawal management, as shown in Table 10.

To convert fiat currency to tokens in order to transfer tokens, users make a request for conversion through an interface depicted in Figure 15a, which shows the actual usage example.

The history of conversion transaction can be confirmed in the deposit history as shown in Figure 15b, and it checked whether the conversion has been completed.

After depositing tokens, users can transfer tokens to a specified seller after confirming the transfer address, using the Figure 15c interfaces.

All the transaction history (deposit/convert/payment) are displayed as a list as shown in Figure 15d to represent the result of the transaction.

4.9. External interface

External interfaces are represented by three interfaces as shown in Table 11, and each interface communicates using the JSON RPC method.

5. Experiment and Results

To evaluate the proposed system, we measured it using JMeter, which uses the BMT tool to test the HTTP protocol.

5.1. System environment

For performance evaluation, the system environment consists of a physical node with a main web server environment with one CPU (AMD Ryzen 5 PRO 3400GE) and 8GB DDR4 main memory and an SSD of 240GB, a physical node as a Symverse work node with server environment consisting of one CPU (Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz) and 8GB DDR4 main memory and an SSD of 240GB, and a client system with one CPU (Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz) and DDR4 16GB memory so that it can perform the evaluation of various experiments.

5.2. Performance testing

The token payment system is a system that provides services through JSON format using RPC, not web page calls, as it is composed of a web application server. We implement performance testing on wallet creation response and balance inquiry. where both systems call and result are representing as a simple JSON format.

5.2.1. Wallet creation response time

Wallet creation requests are sent to the server and the results are stored in the database. First, the results up to key store creation are tested. Then, to measure the pure wallet creation time, the IP blocking for DDoS prevention is turned off. For the user10 scenario, assuming a loop of 100 requests with 10 threads, the ramp-up is set to 0, allowing only up to 10 requests per second. For the user20 scenario, assuming a loop of 100 requests with 20 threads, the ramp-up is set to 0, allowing only up to 20 requests per second. For the user50 scenario, assuming a loop of 100 requests with 50 threads, the ramp-up is set to 0, allowing only up to 50 requests per second. The summary of the test results for the three scenarios is shown in Table 13.

Average response time corresponding to the variation of the number of threads are depicted in Figure 17a.

Under the same conditions, the results of processing with DDos blocking turned off are shown in Table 14, and the graphical representation of the results is shown in Figure 17a. The DDos blocking logic showed an impact of approximately 2 transactions per second, with 1.61 for User10, 1.9 for User20, and 2.0 for User50, in terms of transactions per second. However, for User50, there was a significant variation in response time.

In Figure 17a and Figure 17b, the difference in results is due to the same condition, but when DDos blocking is turned off and DDos blocking is not turned off, the result of transactions per second is different, such as 1.61 for User10, 1.9 for User20, and 2.0 for User50, as shown above. However, the difference between the two conditions is not significant, which shows that the performance of the proposed technique is excellent.

5.2.2. Balance inquiry response time

Balance response is the process of querying SymID from the blockchain node and delivering the balance to the client in JSON format. To measure the balance response time, DDos defense IP blocking was turned off, and a scenario was assumed where user50 generates 50 threads with 100 loops of requests, setting the ramp-up to 0 so that only up to 50 requests can be made per second. User100 assumes a scenario where 100 threads with 100 loops of requests are generated, setting the ramp-up to 0 so that only up to 100 requests can be made per second. User200 assumes a scenario where 200 threads with 100 loops of requests are generated, setting the ramp-up to 0 so that only up to 200 requests can be made per second. User300 assumes a scenario where 300 threads with 100 loops of requests are generated, setting the ramp-up to 0 so that only up to 300 requests can be made per second. The summary report of the test is shown in Table 15. The transactions per second (TPS) were 560.73 without errors in 50 threads, 565.55 TPS with 0.01% errors in 100 threads, 482.35 TPS with 0.09% errors in 200 threads, and 475.0 TPS with 0.7% errors in 300 threads, indicating an increase in errors as the number of threads increases.

The results of processing with DDos blocking enabled under the same conditions are shown in Table 16, and the DDos defense logic is impacted by about 220 TPS in transactions per second: 313.39 for User50, 313.24 for User100, 232.1 for User200, and 223.06 for User300.

In Figure 18a and Figure 18b, the results are different when DDoS blocking is turned off and when DDoS blocking is not turned off, even though the conditions are the same. However, the difference between the two conditions is not significant, which shows that the performance of the proposed technique is excellent.

6. Conclusion

This paper has proposed a new server-based real-time P2P token payment blockchain system designed to address the problems of non-face-to-face transactions in the financial sector, especially in the situation where sophisticated voice phishing is spreading and reliance on open banking systems is increasing. This solution overcomes the limitations of private key management difficulties and gas fee management while utilizing the advantages of blockchain technology.

The server-based key management module effectively minimizes the risk of loss by securely storing private keys in keystore files and databases. The server-based token management module simplifies token generation and management, ensuring smooth token transactions through automatic gas charging. The transaction verification module, which utilizes transaction IDs without exposing personal information, guarantees transaction integrity and non-repudiation. In addition, advanced security measures such as external access IP blocking and DDoS protection are introduced to keep user data safe.

It also aims to provide convenient, secure and accessible online payment solutions to the general public by implementing identity verification using smartphones and platform-agnostic web applications. This comprehensive approach has the potential to innovate non-face-to-face transactions in the financial sector by providing user-friendly and secure alternatives to traditional methods. As the digital environment continues to evolve, the non-contact P2P real-time tokenized payment system can become an important tool for protecting users from financial fraud and creating a more inclusive and flexible financial ecosystem.

Through this research, it was demonstrated that blockchain token payments can be utilized as an anti-voice phishing technology by blocking the possibility of exposure to crime through transparent transactions where all details can be made public and both the payer and the payee can be verified. Third-party authentication for non-repudiation is also possible. Furthermore, it is expected to create business opportunities for innovative finance, such as IoT automatic regular payments, small loan services, and 24-hour uninterrupted payment services. The feasibility and efficiency of the proposed system were confirmed through experimental results, and it is expected to have a significant impact on the financial industry.