While working on our MVP it became quite clear from the start that we would need a connection between our smart contracts and our Java backend. To be able to implement notifications, authentication and verification, we need a microservice that interacts with the Ethereum blockchain.

Introducing Azrael

Instead of implementing web3 interaction in each of our microservices that need to talk to the Ethereum blockchain, we chose to extract this functionality into a new microservice and coined it Azrael.

Azrael is a Java microservice, written in spring-boot, leveraging the library Web3J to interact with the Ethereum blockchain. It has a rest-API specifically written to interact with the FundRequest smart contracts.

Event Bridge🌉

We created Azrael to act upon the events that are being thrown whenever there is an event in our contracts. One of these events is the Funded event.

The Funded event, only thrown when a particular object is being funded on FundRequest

Whenever this event is thrown, we want our backend services to be able to notify users and cache state. To be able to act upon these events, we created a model of our Solidity contracts and actively listen to all events that are thrown on the Ethereum blockchain, using web3 filters.

RabbitMQ — Our choice of messaging.

We put these generated events on a RabbitMQ topic. This way, any microservice that could be interested in these events can register on this topic.

State Bridge🌉

We decided to make Azrael not only an event bridge, but also state bridge. At all times we try to use in-browser communication when it comes to fetching data from the blockchain. We use javascript and a web3 provider in order to live-update our states. However, we want our initial state to be independent of an injected web3 component and there should be a fallback if the public Web3 RPC be unavailable.

We created a rest-api on top of Azrael, which fetches the FundRequest data from the blockchain and transforms it into a readable and transferable model. This data can be cached on several layers and will be readily available, due to “High Availability parity nodes” (We’re planning a new blog post to explain how we’ll maintain HA Parity and Geth nodes as an alternative to Infura).

Action Bridge🌉

The last responsibility of Azrael is an offline signature module. Whenever we perform actions on the blockchain — actions that modify state and cost gas — this module is used. The action bridge makes Azrael the oracle of our contracts. Azrael has the power to interact with the contracts in the form of an administrator, if necessary. Therefore, intense security measures are taken to only implement what will be necessary, to restrict access to who and what can access this microservice, and to use vaults in protecting our encrypted private keys. Until now, we didn’t need this module yet, but as we’re working on the claim flow, we’ll implement this security-centric functionality using Azrael.

Future Plans and decentralization

Currently, everything Azrael can do is geared towards the core business of FundRequest. As we continue developing Azrael further, our aim is to make this solution a lot more generic.

When users are able to specify generic rules and outputs to act upon blockchain events, Azrael can evolve into the IFTTT of the Ethereum blockchain.Get to Know FundRequest

Get to Know FundRequest

Website | White paper | Dev Updates | Sign up

Never Miss An Update By Following FundRequest’s Channels

Blog | Telegram | Github | Reddit | Twitter