The Procedure of EOScanner Development

The Experience of Developing an EOS Block Explorer

This story of how the EOScanner was developed was written by our developer Dongjun Kwon.

How Did You Get Started Developing EOScanner?

I started studying EOSJS after I joined the ITAM Network team. I’ve been very interested in blockchain and because I had experience developing web3.js on Ethereum and neon-js on Neo, learning EOSJS wasn’t too difficult. After researching EOSJS and while making a simple wallet on the web, the thought of “I think I would be able to make something like Etherscan” ran my mind. I first started with the light mindset of developing for a personal project and for a learning experience, and this grew into what it is today.

eoscanner.io

Any Difficulties Faced While Developing?

1. Lack of Reference

This was the most challenging part while developing. And it’s still true now. Just take a look at EOSJS Github and you can find that it’s not the most friendly place. Now knowing what the meaning of parameters was the most difficult factor, and there’s still a lot that I do not know. Also, it’s hard to know the unit of CPU, NET, and RAM as well. I referenced existing Block Explorers and Wallets and their sources to solve these issues (but of course, not 100%). I also received a lot of help from the followers on the ITAM Network Kakaotalk Openchat.

2. Different Data for Every BP

EOS connects to the nodes operated by the BPs and retrieves the data or pushes the transaction. What’s really interesting is that when you look up the Name Bid Table for each BP, they are all different, which I still can’t understand till this day. If you connect EOSEOUL, EOS New York, etc. and search the appropriate table, you can see that they are different (why do you think this is the case?). Therefore, we decided to use EOS New York as the standard (we couldn’t really do anything about it since we ourselves aren’t a BP).

3. Little to No Support of get_actions between BPs

Not being able to see actions on an EOS Block Explorer is nonsense. In order to make this possible, the appropriate account data must be retrieved with getActions on get_actions EOSJS. What’s really frustrating is that there aren’t many BPs that support get_actions. Furthermore, even if they do support get_actions, they don’t support all actions, which is another hurdle (since you need to check each and every one to see if they support all actions).

4. No Support of https by the BPs

There was only one BP that met the above (#3) requirements while also supporting https. EOS New York. There were very few that met the requirements of #3, too. I’ve researched numerous BPs, including from Japan, China, and Korea, and checked the API of every Korean BPs. Amongst these, only EOS New York and AcroEOS met the standards. Even with AcroEOS it was not possible to access their table, and didn’t provide all the actions. However, they applied it right away once I requested it via Telegram (thank you AcroEOS!). Nonetheless, AcroEOS doesn’t support https. Therefore, only EOS New York was left. Thus, EOSCANNER is connected to EOS New York.

5. The Reality of Being BP Dependent

EOSCANNER does not have Backend and is retrieving EOS information from BPs. Therefore, BP dependency is quite high. To give an example, if the BP’s api server dies, then our service dies along with it (we can trust EOS New York since they are a highly ranked BP, right…?). Furthermore, a major difficulty is that EOS New York is currently the only BP that meets our needs.

6. Limitation on the Data We Can Get

There is a limitation on the data we can get by using EOSJS. If we want to see an account’s custom tokens, there is no way to get that (using actions to check, but there’s a limitation on that as well). It also doesn’t make sense to search for all of the hundreds of custom tokens either. These are some big difficulties for EOSCANNER.

What is the Direction of EOSCANNER for the Future?

1. EOS MainNet Full Node

We are currently preparing an EOS MainNet Full Node at ITAM. Once complete, we won’t have to rely on the BPs, but would be able to retrieve the data on our own, so we expect to be able to get more variety of data at higher speed. Also, we wouldn’t have depend on BPs and not have to worry about our service dying.

2. Transfer Notification

We at ITAM are developing a Chrome Extension Wallet. Using the authentication function of the ITAM Wallet, we will add the ability to receive notifications whenever a transfer is made to the account.

3. UI/UX Improvement

Because the current EOSCANNER was developed by one person (Dongjun Kwon), a lot of attention was not on the UI/UX. We expect to improve the UI/UX to provide a more convenient experience for the users.

Conclusion

This was the first time writing a Development Procedure for me. It was nice being able to look back on the obstacles faced while developing EOSCANNER. I will always work to improve EOSCANNER. Please leave a lot of comments and opinions. Finally, please keep an eye out for ITAM Network as well.