1. JSON-RPC

JSON-RPC is a method of communicating through data structure and rules specified in node through http environment. It is an approach that is widely used in the development of server-client, which allows access to Ethereum network through HTTP communication as it is.

In fact, XMLHttpRequest via httpprovider.js is used as a way to access nodes from web3.js, and Metamask also seems to use this method to communicate between their server and clients.

However, in order to use this method, you have to think a lot about security. To use your own assets on Ethereum network, you need authentication information for the account, and SSL is needed for this. To do this, you will need to configure the SSL proxy on your web server, create a server and SSH tunnel to communicate, or use authentication methods such as OAuth.

This means that DDoS attack can be performed like existing server-client development, and there is dependency on external server, which means that maintenance of server is necessary. In other words, it is not a complete form of decentralization.

2. Web Socket

Web socket is a model that subscribes events that occur on the node instead of performing continuous polling to retrieve the log from the JSON RPC. This model has the advantage of node-side notification and reducing node and DApp resources, but it has a problem of poor stability in mobile environment. As the network environment changes, there is a possibility that the connection of the web socket is disconnected or the connection of the web socket is rejected by the wireless internet service provider. Another disadvantage is that we can not support all features because the development of web socket is not done much yet.

3. Inter-Process Communication

Finally, IPC is a way to use the Ethereum API by creating an IPC pipe on a unix system. This is a kind of RPC, but it uses a pipe inside the device, not in the http environment. Therefore, it enables a lighter communication. However, this method is only possible when node and client are running on the same device. In other words, it can not be used in web environment or mobile environment where it is difficult to run a node on Ethereum network.

The Light Ethereum Subprotocol (LES) is the protocol used for the “light” client. This takes the form of downloading only the block header and then receiving the other part of the blockchain “on-demand”. The protocol is fully functional and securely accessible throughout the blockchain, and it does not participate in the mining and consensus processes thus allowing “light” access.

At present go-ethereum has developed a cross-compiling LES based client through gomobile, which makes it easy to access Ethereum network from mobile. However, in an article on the Light client in the Ethereum blog, there are some things that DApp developers should be aware of about “lightness”.

To summarize what they’re saying, you can not get a pending transaction other than the transaction you have generated, and you can not find a transaction through the transaction hash. In addition, there are performance considerations as follows: First, if you process a lot of requests sequentially, you need to query the light servers, so the response may be late. Also, due to the nature of the light client, which only has a header, it takes a lot of time to look up the block history to find the event.