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 still 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. However, the widespread adoption of blockchain-based distributed ledgers has been limited by the complexity of private key management and the burden of gas coin management and gas costs incurred by transactions [3,4].

This paper proposes a new non-face-to-face P2P real-time token payment system that overcomes limitations while leveraging the benefits of blockchain technology. The proposed system effectively minimizes the risk of losing private keys by utilizing a server-based key management module to securely store private keys in keystore files and databases. In addition, a server-based token management module simplifies token generation and management and enables smooth token transactions without the burden of gas cost management by implementing an automatic gas charging function [5].

The system’s transaction verification module ensures transaction integrity and non-repudiation using transaction IDs without disclosing personal information. Furthermore, it realizes the protection of user data by use of advanced security measures, such as blocking foreign access IP and implementing DDoS protection. The proposed system aims to provide a convenient and safe online payment solution to the general public by implementing self-verification functions using web applications which restricted by types of smartphones and platforms [6].

In Section 2, an overview of the challenges faced by remote transactions and existing solutions is examined, and the potential of blockchain technology to solve these challenges is discussed. In Section 3, we introduce our proposed remote P2P real-time token payment system. Section 4 confirms the service availability through performance testing, and Section 5 evaluates the real-time token payment system.

2. Related Works

In this section, we examine previous research and solutions proposed to address the issues of remote transactions, with a particular focus on customer identity verification, transaction integrity, and prevention of transaction rejection. We also discuss the potential of blockchain technology in addressing these issues and emphasize the limitations of current blockchain-based solutions [7].

2.1. Customer Identity Verification

As non-face-to-face transactions become more popular, verifying the identity of customers has become an important factor in maintaining the security of financial systems. To address this issue, various technologies such as two-factor authentication (2FA), biometric authentication, and digital identity solutions have been proposed [8]. While these approaches have shown promise, they can be limited in adoption and effectiveness due to the need for additional hardware, software, or user intervention. In this context, using a web application that is not restricted by smartphones or platforms for identity verification can provide a more accessible and user-friendly solution, as proposed in the system described by Twitter [9,10].

2.2. Transaction Integrity and Non-Repudiation

Transaction integrity and non-repudiation capabilities are essential for preventing fraud and maintaining trust in financial systems. To achieve these goals, traditional methods such as digital signatures and cryptographic hashing have been widely used. However, these methods can be resource-intensive and may not be suitable for all remote transaction scenarios. Blockchain technology, which has unique characteristics such as immutability and transparency, is being proposed as an alternative. Smart contracts and consensus algorithms have been developed to enforce transaction rules and maintain system integrity. Nevertheless, the adoption of blockchain-based solutions is limited by issues such as personal key management and gas fee management [11].

2.3. Blockchain-Based Distributed Ledger

Blockchain technology is receiving significant attention as a potential solution to various challenges in the financial sector, such as decentralization, security, and transparency. Several blockchain-based platforms, such as Ethereum and Hyperledger, have been developed, enabling the creation and management of decentralized applications, including financial transactions. While these platforms have demonstrated potential, they have been limited in widespread adoption due to the difficulty of managing personal keys and the burden of gas costs. Furthermore, scalability and interoperability issues between different blockchain platforms remain significant challenges [12,13,14].

2.4. Limitations of Existing Solutions

While existing solutions have addressed some issues with remote transactions, they often fall short in providing comprehensive, user-friendly, and secure access. Blockchain-based solutions are limited in adoption due to the complexity of managing personal keys and the burden of gas costs. Traditional methods for identity verification and transaction integrity enforcement may be resource-intensive and cumbersome [15]. In light of these limitations, the proposed remote P2P real-time token payment system aims to leverage the advantages of blockchain technology and integrate user-friendly features for identity verification, transaction integrity, and non-repudiation, while resolving the issues of personal key management and gas costs to bridge this gap. Additionally, we will examine the background technical details of the system and explore the use of Ethereum’s keystore and the SCT and transaction generation of the Symverse blockchain in its actual implementation.

2.5. Background Technology

2.5.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 [16,17]. 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 [18].

• 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 [19].

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 Figure 4.

• 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 [20].

Figure 5. Decrypt Cipher.

Figure 5. Decrypt Cipher.

2.5.2. Symverse

Symverse is a blockchain platform with near 1-second finality based on a self-sovereign distributed ID system. 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 [21].

• 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. In Ethereum, the ERC-20 protocol involves writing smart contracts in Solidity and registering them on the blockchain, allowing them to be operated by the EVM. However, in Symverse, SCT-20 provides standard input and output, as shown in Table 1, and allows for the creation of token smart contracts via an RPC protocol in JSON format, making it simple to use. To create and use an SCT contract, SYM coins, which are used as gas, are required, and calling SCT functions consumes SYM coins as shown in Table 2.

• Transactions

A transaction is an act of recording ledger within a block on the blockchain, and once a transaction is recorded, it cannot be modified or deleted. In Symverse, there are three types of transactions: general transaction, SCT transaction, and deposit transaction [24]. The required data in a transaction is as shown in Table 3.

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

Figure 6. Calculate consume gas.

Figure 6. Calculate consume gas.

Transactions can be processed in the order shown in Figure 7, allowing for the execution of one transaction.

The transaction Raw DATA is sent to nodes through a signature procedure,

Figure 8. Transaction signing process.

Figure 8. Transaction signing process.

The executed transaction returns a Transaction Receipt, which can be used to verify the information from blockchain data in the node.

The next section will introduce the details and architecture of the proposed system in this paper, as well as various modules that solve the problems discussed in this section. In addition, we will provide an evaluation of the system’s performance, security, and usability, demonstrating the 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 9 shows the module-by-module configuration and interconnection of the system that enables P2P real-time payments based on the server.

3.2. The Control Flow of the Proposed System

The control flow of the proposed system is as follows: 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.

Figure 10. Control Flow of System.

Figure 10. Control Flow of System.

3.3. 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.

Figure 11. Transaction creation process through private key signature.

Figure 11. Transaction creation process through private key signature.

3.4. 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 12. Token management module.

Figure 12. Token management module.

3.5. 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 using their private key. The gas consumed by the transaction is then calculated. If there is no 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 13. Token transfer module.

Figure 13. Token transfer module.

3.6. 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 14. DDos Block Module.

Figure 14. DDos Block Module.

3.7. 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 15. real name authentication module.

Figure 15. 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 (Table 4) lists the environments and libraries used in the implementation.

4.2. Token

The EST token used in the system implementation obtained a smart contract ID of “0x4801e91a5068757a9484” generated through SCT-20, and can be reviewed through the Symverse Scanner as shown in Figure 16. (https://scan.symverse.org/v2/sct2x_token/SCT20/0x4801e91a5068757a9484)

The token minting process utilizes on Symverse’s SCT. The minting process is initiated by creating information about the token in an array called sct_data, as shown in Figure 17.

Sct_data is processed by RLP (Recursive Length Prefix) Encoding and the result is as shown in Figure 18.

The transaction is signed and sent to the work node and the result can be verified after block is confirmed, as shown in the example of Figure 19.

4.3. 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 5 summarizes the database table list for system implementation to operate a service.

4.4. User Interface of Client Side

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

The interface for the wallet user who receives payment is composed of menus that allow them to view transaction history (as in Table 7) 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 8.

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

The history of conversion transaction can be confirmed in the deposit history as shown in Figure 21, 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 22 interfaces.

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

4.5. External interface

External interfaces are represented by three interfaces as shown in Table 9, 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.

Figure 24. Experiment Environment.

Figure 24. Experiment Environment.

Table 10. Test environment.

Table 10. Test environment.

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 11.

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

Under the same conditions, the results of processing with DDos blocking turned off are shown in Table 12. 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.

Figure 26. TC2 Active Number of Thread vs Response Time (with DDos protection).

Figure 26. TC2 Active Number of Thread vs Response Time (with DDos protection).

5.2.2. Balance Inquiry Response Time

W 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 13. 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.

Table 13. TC3 Response time of balance inquiry (without DDos protection).

Table 13. TC3 Response time of balance inquiry (without DDos protection).

Figure 27. TC3 Active Number of Thread vs Response Time (without DDos protection).

Figure 27. TC3 Active Number of Thread vs Response Time (without DDos protection).

Under the same conditions with DDos blocking turned on, the results are as follows. The DDos defense logic has an impact of approximately 220 TPS in the number of transactions per second. Specifically, in User50, the TPS decreased from 560.73 to 247.34. In User100, it decreased from 565.55 to 252.31. In User200, it decreased from 482.36 to 250.26. In User300, it decreased from 475.01 to 251.95.

Table 14. TC4 Response time of balance inquiry (with DDos protection).

Table 14. TC4 Response time of balance inquiry (with DDos protection).

Figure 28. TC4 Active Number of Thread vs Response Time (with DDos protection).

Figure 28. TC4 Active Number of Thread vs Response Time (with DDos protection).

6. Conclusions

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.