1. Introduction

2. Related Works

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

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

5. Experiment and Results

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

References

1. Jain, A.K.; Gupta, B.B. A survey of phishing attack techniques, defence mechanisms and open research challenges. Enterprise Information Systems 2022, 16, 527–565. [Google Scholar] [CrossRef]
2. Jeong, Y.H.; Ha, H.J. Messenger Phishing Crime: Trends and Responses. Criminal Investigation Studies 2022, 8, 31–54. [Google Scholar] [CrossRef]
3. Tama, B.A.; Kweka, B.J.; Park, Y.; Rhee, K.H. A critical review of blockchain and its current applications. In Proceedings of the 2017 International Conference on Electrical Engineering and Computer Science (ICECOS); IEEE, 2017. [Google Scholar]
4. Gad, A.G.; Mosa, D.T.; Abualigah, L.; Abohany, A.A. Emerging trends in blockchain technology and applications: A review and outlook. Journal of King Saud University-Computer and Information Sciences 2022. [Google Scholar] [CrossRef]
5. Shah, K.; Patel, N.; Thakkar, J.; Patel, C. Exploring applications of blockchain technology for Industry 4.0. Materials Today: Proceedings 2022, 62, 7238–7242. [Google Scholar] [CrossRef]
6. Ahmed, M.R.; Meenakshi, K.; Obaidat, M.S.; Amin, R.; Vijayakumar, P. Blockchain based architecture and solution for secure digital payment system. In Proceedings of the ICC 2021-IEEE International Conference on Communications; IEEE, 2021. [Google Scholar]
7. Villanueva, N.E. Blockchain Technology Application: Challenges, Limitations and Issues. Journal of Computational Innovations and Engineering Applications 2021, 5. [Google Scholar]
8. Cho, S.I. A Study on Factors Affecting the Intention to Use of New Access Media in e-Financial Transactions. Doctoral Dissertation, Graduate School of Soongsil University, 2018. [Google Scholar]
9. Seibert, J.; Michael, D. Inter-application delegated authentication. U.S. Patent No. 11,025,624, 1 June 2021. [Google Scholar]
10. Hinkes, A.M. Throw away the key, or the key holder? coercive contempt for lost or forgotten cryptocurrency private keys, or obstinate holders. Nw. J. Tech. & Intell. Prop. 2018, 16, 225. [Google Scholar]
11. Yang, R. Development and Supervision of Financial Technology Based on Blockchain. Computational Intelligence and Neuroscience 2022, 2022. [Google Scholar] [CrossRef] [PubMed]
12. Chen, Y.; Bellavitis, C. Decentralized finance: Blockchain technology and the quest for an open financial system. Stevens Institute of Technology School of Business Research Paper. 2019. [Google Scholar]
13. Ostern, N.K.; Riedel, J. Know-your-customer (KYC) requirements for initial coin offerings. Business & Information Systems Engineering 2021, 63, 551–567. [Google Scholar]
14. Sable, N.P.; et al. The Secure E-Wallet Powered by Blockchain and Distributed Ledger Technology. In Proceedings of the 2022 IEEE Pune Section International Conference (PuneCon); IEEE, 2022. [Google Scholar]
15. Praitheeshan, P.; et al. Attainable hacks on Keystore files in Ethereum wallets—a systematic analysis. In Proceedings of the Future Network Systems and Security: 5th International Conference, FNSS 2019, Melbourne, VIC, Australia, 27–29 November 2019; Proceedings 5. Springer International Publishing, 2019. [Google Scholar]
16. Urien, P. Innovative Wallet Using Trusted On-Line Keystore. In Proceedings of the 2021 3rd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS); IEEE, 2021. [Google Scholar]
17. Lehto, N.; et al. CryptoVault-A Secure Hardware Wallet for Decentralized Key Management. In Proceedings of the 2021 IEEE International Conference on Omni-Layer Intelligent Systems (COINS); IEEE, 2021. [Google Scholar]
18. Phuc, T.S.D.; Lee, C. Password Hashing Algorithms-From Past to Future. JOURNAL OF PLATFORM TECHNOLOGY 2015, 3, 63–75. [Google Scholar]
19. Antonopoulos, A.M.; Wood, G. Mastering ethereum: building smart contracts and dapps. O’reilly Media, 2018. [Google Scholar]
20. Symverse. SymVerse Whitepaper. 2022. https://symverse.com/en/learn/whitepaper/.
21. Symverse SCT Guide. https://github.com/symverse-lab/Document/wiki/SCT-Guide.