Being able to scan the blockchain and log all transactions and events from a specific contract or multiple contracts has many advantages. To do that, we built Smart Contract Watch. It gives you a better overview of whats going on and reliably indicates whether everything is running as it should.

If you connect Smart Contract Watch with a logging tool like Graylog, then you are already close to your contracts. However, you can get even closer by setting up real time alerts based on your smart contracts, e.g. failed transactions. It is the natural next step towards robust smart contract monitoring.

Graylog logging the smart-contract-watch data

Setting up Graylog

Connecting the Smart Contract Watch with Graylog is straightforward. Just follow these steps:

Prepare Graylog communication ports

Clone the Smart Contract Watch repo git clone https://github.com/Neufund/smart-contract-watch

Create a new docker compose file using ./docker-compose.example.yml

Run docker build ./smart-contract-watch -t <add your own tag>

Once you have a dockerized image on docker, copy the image id into the docker compose file and run docker-compose up

Smart Contract Watch should start sending UDP messages to graylog

Streams

Once you have set up your Graylog to work with Smart Contract Watch, and once all messages are passing through your global stream, then you can build different streams for your incoming messages based on specific criteria. This is especially powerful since it works with different types of specific queries, whether simple logical queries or more complex expressions.

Additionally, any stream can be combined with alerts. For example, configure an email alert to be notified every time a transaction fails for a specific reason.

Let’s take a look at some examples. For the purposes of this post, we take three simple streams representing three real world use cases from our ICBM crowdsale contract:

Empty Transactions

Failed Transactions

Low gas Transactions

We will walk through these use cases in depth soon, but what is important for now is that setting streams is simple. The only challenge lies in deriving meaningful information from the blockchain.

For example, we can easily identify the number of commitment attempts from unsupported wallets like exchanges by scanning for any transaction that includes 0x in the inputData field. This helps us because it indicates how many people, approximately, didn’t read our commitment guide.

Graylog streams

Smart Contract Watch Graylog output

The output module stores all extracted information as a JSON object presented the following way:

networkId: Network id can be mainet, ropsten, kovan ,etc blockHash: Block hash number blockNumber: Block number/nonce fromAddress: Public address of transaction sender toAddress: Public address of transaction receiver transactionHash: Transaction hash number input: Data input sent with the transaction gasUsed: Gas used gasPrice: Gas price status: Status of transaction success/failure value: Amount of ether sent transactionType: Normal transaction / Contract creation transaction contractAddress: Address of Created contract methodName: Name of method called, This value is decoded methodParameters: Parameters and values used during method call etherscanLink: Link of transaction in etherscan events: List of events emitted by target smart contract

We can have Graylog automatically extract this JSON object as long as it is stringified and we have setup an extractor for the message field in graylog.

Use cases

Let’s take a look at the three streams presented above and their use cases.

Empty Transactions stream

Our smart contracts are designed to reject default calls “any transaction without data input ”. This is because — most of the time — users of an exchange have no access to private keys, nor do they have any control over any tokens sent to them. When committing from an exchange, the exchange will receive the tokens instead of the user. So there is no way for the smart contract to know exactly who committed what from an exchange. The only parameter it can relay is “sender address” msg.sender and inputData “data field with a custom method call in the smart contract”.

By looking into the number of investors attempting to commit without using a proper wallet, we can easily determine the number of users who didn’t follow our guidelines. (This information is useful for modifying our website so that more people actually do read them, or even have to in order to participate)

In order to find this, we will need to set simple rules for our empty transaction stream . Specifically, we will look for all transactions that fulfill one of the following two criteria:

1 — Failed transaction

2 — A transaction where inputData is empty (equals 0x )

Failed Transactions stream

There are many reasons why transactions can fail: calling a method without correct privileges, transaction is out of gas, etc. In this case the stream is set for investors who attempt to commit before the ICBM starts.

In order to find them we need to set some simple rules for our failed transaction stream . Specifically, we will look for all transactions that have the following criteria:

1 — Time of transactions is before the ICBM

2 — The user used a default call or tried to call the commit method in the ICBM Crowdsale smart contract

Low gas Transactions stream

Estimating the gas price can be a tricky task. Set the gasPrice too high and you find yourself having very expensive transactions. Set your gasPrice too low and you risk having your transaction failing to get mined. In our commitment page, we recommended specific a specific gas price and adjusted it as necessary — especially during the congestion caused by the CryptoKittie craze.

This use case is a good indicator for how accurate our estimation of the gas price is, since it is always better to have as low a gas price as possible as long as the transaction gets mined. This stream can show us whether our estimation for 15Gwei of gasPrice is in the lower safe limit of committing, or whether users are committing with a lower gasPrice .

In order to find this we need to set simple rules for our Empty transaction stream . We look for all transactions that have the following criteria:

1 — Transaction was successful

2 — gasPrice < 15Gwei

Conclusion

Real-time alerts for your smart contracts are the next step towards more robust smart contract monitoring. It saves you lots of time and effort. If you have more questions about this or Smart Contract Watch, please ping @moe in our public Slack. Or submit a feature request at our Github page