[Part 3] Application Example of REMIIT RSC : Technical Issues in RSC

by Noah Kim (Developer)

In the previous post, we introduced the details of how REMIIT RSC combined funding and remittance history, rather than bypassing government regulations. In this post, I will briefly discuss some of the issues that have occurred during the implementation process. This issue is also a common problem when applying blockchain based technologies to a business.

Consequences of Using Blockchain 1 : Costs to Store Vast Quantities of Data

To gain trust through blockchain, you must use a blockchain network that is both public and major. However, the cost per remittance transaction is becomes impractical when you have to record all of the details (sender/receiver, starting from the amount, date, bank, etc.) on a blockchain such as Ethereum or EOS. Also, posting private information on a blockchain that anyone can see is a problem that cannot be ignored. To solve this problem, the REMIIT Team applied the method of recording the transfer data in a database separated from the blockchain and recording the hash value in the ledger. In other words, the details should be retrieved from the service provided by the remittee, and the blockchain ledger is used as a tool to verify the validity of this information. In addition, by classifying access authority levels, you can create notarized information for many blockchain network nodes, without disclosing information to all users.

Consequences of Using Blockchain 2 : User eXperience

The compromise mentioned above is obviously logical in a technical sense, but difficult to understand intuitively by users without relevant knowledge. Moreover, even if you understand the principle and have the ability to do it, it is a hassle to do it yourself. To solve this problem, once again, we used the blockchain technology. We created a smart contract that returns a hash value for the records that we want to check for consistency among the stored records and made it easy to access through Etherscan. This makes it easy to see if the information provided by the service is the same as the information recorded in the ledger. One more thing, the use of the smart contract function to return a hash value was also a concern for the user experience. In order to be intuitive, it was made to return one item per integer, but there was a troublesome issue of having to enter a lot of items one by one. In addition, in the Ethereum Smart Contract’s language Solidity, once the integers went beyond 10, it started to return and create bugs. In order to solve this problem, it is possible to combine each item into one type of string and check it at once with Copy & Paste. Also, even if the contract we created were not used, it can be easily validated with any website that provides keccak256 hashing.

Other

Lastly, I would like to conclude with a few more minor issues in the development of the Ethereum smart contract.

In the process of developing a smart contract to convert the input data into a hash value, there was no built-in conversion function in solidity, and a function had to be created to generate the hash string.

To get a bit more transparency, each user has to communicate directly with the chain, and users have to use Metamask (REMIIT Team is developing a wallet solution to optimize this part). In some cases, the receipt was not returned normally at the completion of the transaction, and the transaction information was periodically inquired and handled directly via web3.

There are many other minor issues, but they are much publicized thus has been omitted. In the future, we will continue to disclose technical issues that can be shared in the process of applying RSC to real business cases.

REMIIT RSC

Link: https://rscmvp.remiit.io