Subscriber providing interface for listening upcoming transactions in Ethereum Network

Current implementation provide 2 usage interfaces: CLI and HTTP Api

To install CLI and use it just install it through go install

go install github.com/bluntenpassant/ethereum_subscriber/cmd/ethereum_subscriber-cli

after you can open user-cli with command

ethereum_subscriber-cli

To install API and use it just install it through go install too

go install github.com/bluntenpassant/ethereum_subscriber/cmd/ethereum_subscriber-api

after you can launch HTTP api server with command

ethereum_subscriber-api

or you can use it as docker image. Dockerfile located in docker/Dockerfile commands for running Dockerfile presented below

docker build -o ethereum_subscriber ./docker
docker run ethereum_subscriber -p 8080:8080

NOTE: If you need to change app configuration that might be very helpful for launch different scenarios, you need to download source code and change configuration directly in app. In further we will provide interface for changing configs directly through CLI, but now... life is life 3>

Ethereum subscriber at the current moment supports 3 methods for interaction

Now Ethereum Subscriber supports two different approaches in transactions handling. You can change current approach with parameter General->Approach

Subscriber uses for a getting a full list of inbound or outbounds transactions by user since subscription. Due to simple transactions in Ethereum Network are not indexed, we cannot get it through simple JSONRPC methods directly, in 1 request. This method uses heuristic approach without having to process the entire chain.

Subscriber in releasing approach mode everytime handling all transactions since subscription time. After handling a bunch of blocks and transactions handler releases all data in runtime and waiting for another task This approach will be suitable in case when you're launching program in a short-term. Approach does not consume many resources and might work fast enough, cause handler does not need to save data in distributed storage everytime, it saves only minimum data about subscription block and count of transactions, you can use memory storage for this approach. In config this approach is chosen by default, because this approach require few resources and does not require distributed side storages. But if you are planning to keep program long keepalive time Greedy approach will be more convenient and effective for you. In average Ethereum Network has 25 TPS(Transaction Per Second) and has 110 bytes per transaction (https://ethereum.stackexchange.com/questions/30175/what-is-the-size-bytes-of-a-simple-ethereum-transaction-versus-a-bitcoin-trans) So, our load is 3KB per second. In a computer with 4GB RAM we will die in 1kk second (4GB/4KB) = 11.5 days. You should consider, that calculated load presented for 1 subscriber with linear traffic, for more subscribers and async requests you will die much faster

In greedy approach handler goes a little different way and trying to save as much as possible transaction in storage to prevent case when we request data, that we already handled. Instead of releasing data after every handling, handler saves data into storage and actively using storage for caching handled transactions. You can configure transaction lifetime with parameter Storage->Redis->data_keep_alive_duration

We have two different processing approaches in handling data

• Synchronous: using for consequentially handling data one by one. This approach guarantees order of every transaction (last -> first)
• Asynchronous: using random handling data. Order of this processing approach is random, and you might need extra sorting operations for handling data correctly

You can choose more convenient parameter for you with parameter General->Processing