Raiden Map: State Cacher

It is in Raiden Map: State cacher where magic happens! In this article will be explain how this service has been implemented and how it works.

Main idea

The State Cacher is designed to process the events produced by the Poller — that is, each event present in the smart contract of the several tokens registered in Raiden — returning the data of the respective token network and concerning the general status of Raiden Network. These data will then be shown in the Raiden Map interface as described in our Raiden Map: Mockups article:

Raiden Map: Mockups

We used Kafka Stream library for Java 8 to create a Stream Processing Topology that enables, in real-time, to consume events, transform and analyze data in them and produce new ones; the events are serialized with Avro, you can find all events schemas in our repository; last but not the least, it is used Maven to manage all library dependecies.

State Cacher Objects

There are four events that describe the network behavior:

• Token Network Delta: this events are high frequency products, report the latest actions performed in a token network and its characteristics: info about the Token, number of users, number of channel opened, closed, etc.
• Token Network Snapshot: they give a more general idea of ​​the token network and maintain a list of Token Network Delta with which you can see throughout history how this has changed
• Raiden Delta: they describe the entire state of Raiden Network giving informations about number of active token networks and their last activities, through a list of Token Network Delta, number of users and prices of main cryptocurrencies
• Raiden Snapshot: these objects illustrate Raiden Network giving informations about token networks, endpoints and them localization, and mantain a list of Raiden Delta with which show through the GUI the trend of Raiden Network

We used Kafka Stream DSL with Processor API integration to create stateful transformation and to have more control over the data. Every State Cacher event is connected to one or more state store to manage every event to produce and guarantee fault-tolerance.

Stream Topology example:

Examining Token Network Delta and in particular the events consumed from ChannelOpenedTopic — a similar behavior occurs for the other topics — this happens:

1. The events are consumed by the topic created in the Poller service
2. Through the implementation of the interface Transformer<K, V, R> the data is managed and then organized in the state store with a Token Network Address as key and Token Network Delta object, defined by the relative avro scheme, as value
3. The events are sent to the related topic according to the rules defined in the .punctuator() function

Here a brief example of the topology:

A piece of Token Network Delta topology