1. Introduction

2. Related works

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

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

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.

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

5. Experiment and Results

6. Conclusion

References

1. Jain, Ankit Kumar, and B. B. Gupta. “A survey of phishing attack techniques, defence mechanisms and open research challenges.”. Enterprise Information Systems 2022, 16, 527–565. [CrossRef]
2. Jeong, Young Ho, Ha, Hyung Joon 2. “Messenger Phishing Crime: Trends and Responses.”. Criminal Investigation Studies 2022, 8, 31–54. [CrossRef]
3. Tama, Bayu Adhi, et al. “A critical review of blockchain and its current applications.” 2017 International Conference on Electrical Engineering and Computer Science (ICECOS). IEEE, 2017.
4. Gad, Ahmed G., et al. “Emerging trends in blockchain technology and applications: A review and outlook.”. Journal of King Saud University-Computer and Information Sciences 2022.
5. Shah, Kaushal, et al. “Exploring applications of blockchain technology for Industry 4.0.”. Materials Today: Proceedings 2022, 62, 7238–7242.
6. Ahmed, Mohammad Rasheed, et al. “Blockchain based architecture and solution for secure digital payment system.” ICC 2021-IEEE International Conference on Communications. IEEE, 2021.
7. F. Vogelsteller, and V. Buterin, “EIP-20: ERC-20 Token Standard,” [Internet], https://eips.ethereum.org/EIPS/eip-20, 2015, Accessed May 2022.
8. Victor, Friedhelm, and Bianca Katharina Lüders. “Measuring ethereum-based erc20 token networks.” Financial Cryptography and Data Security: 23rd International Conference, FC 2019, Frigate Bay, St. Kitts and Nevis, February 18–22, 2019, Revised Selected Papers 23. Springer International Publishing, 2019.
9. Hyeon-ah Moon, Sooyong Park. (2022). A De Facto Standard for ERC-20 API Functional Specifications and Its Conformance Review Method for Ethereum Smart Contracts, korea information processing society. Software and data engineering 11-10, 399p-408p.
10. Gavin wood, gavin@parity.io, ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER BERLIN VERSION beacfbd ,2022-10-24.
11. Symverse. (2022). SymVerse Whitepaper. https://symverse.com/en/learn/whitepaper/.
12. Jihun Son, Jungheum Park. (2022). Forensic analysis of MetaMask cryptocurrency wallet artifacts. Journal of Digital Forensics 2022, 16(4), 151–165.
13. S. Suratkar, M. S. Suratkar, M. Shirole, and S. Bhirud, “Cryptocurrency wallet: A review,” in 2020 4th International Conference on Computer, Commu-nication and Signal Processing (ICCCSP), 2020, pp. 1–7.
14. Praitheeshan, Purathani, et al. “Attainable hacks on Keystore files in Ethereum wallets—a systematic analysis.” Future Network Systems and Security: 5th International Conference, FNSS 2019, Melbourne, VIC, Australia, November 27–29, 2019, Proceedings 5. Springer International Publishing, 2019.
15. Urien, Pascal. “Innovative Wallet Using Trusted On-Line Keystore.” 2021 3rd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS). IEEE, 2021.
16. Lehto, Niko, et al. “CryptoVault-A Secure Hardware Wallet for Decentralized Key Management.” 2021 IEEE International Conference on Omni-Layer Intelligent Systems (COINS). IEEE, 2021.
17. Phuc, Tran Song Dat, and Changhoon Lee. “Password Hashing Algorithms-From Past to Future.”. JOURNAL OF PLATFORM TECHNOLOGY 2015, 3, 63–75.
18. Antonopoulos, Andreas M., and Gavin Wood. Mastering ethereum: building smart contracts and dapps. O’reilly Media, 2018.
19. Coinmarketcap 2023, https://coinmarketcap.com/currencies/symverse/.
20. Symverse SCT Guide. https://github.com/symverse-lab/Document/wiki/SCT-Guide.