How to design back-end and front-end DApp on POSIChain (Part I)

POSIChain introduction

POSI Chain is a decentralized blockchain with high security and scalability, built as an open network of nodes governed by Posination. It provides 2-second transaction finality with lower fees.

POSI Chain is your open platform for assets, collectibles, identity, and governance. Our secure bridge offers cross-chain asset that transfers with BNB Chain and is expected to become a bridging protocol among several leading blockchains such as Ethereum, Polygon, and Avalanche in the near future.

Decentralized Applications on POSIChain

These secure and unchangeable programs running on a decentralized network (POSIChain) in combination with traditional front-end and back-end technologies are what we call decentralized applications (DApps) today. Though some of them can be semi-centralized, a major part of activities in the truly decentralized application should happen out of a central party’s control.

However, as those networks are not scalable today, we combine different approaches to achieve the maximum decentralization level for our applications. The “traditional” back-end as we know isn’t going anywhere. For instance:

• We use the back-end to host the front-end for a decentralized application.
• We use back-end for integrations with any other existing technologies and services. In reality, world-class applications can not live in an isolated environment.
• We use back-end to store and process anything big enough for a decentralized network (blockchain in particular).
• Not to mention, IPFS and similar storage layers can not guarantee the accessibility of files, hence we can not rely on them without hosting the files ourselves either. In other words, there’s always a need for a dedicated running server.

Decentralized Applications back-end

Here I want to highlight some of the points which arise most of the questions, namely:

• Listening to network events and reading data from the POSIChain and storage in the database
• Publishing transactions & how to do it securely

Listening to Network Events

In POSIChain, as well as in other decentralized networks, the concept of smart contract events (or event logs, or just logs) allows off-chain applications to be aware of what is happening in the blockchain. These events can be created by smart contract developers at any point in the smart contract code.

For example, within the well-known PRC20 token standard, each token transfer has to log the Transfer event, thus letting off-chain applications know that there is a token transfer happening. By “listening” to these events we can perform any (re)actions. For instance, some mobile crypto-wallets send you a push/email notification when tokens are transferred to your address.

In fact, there’s no reliable solution for listening to network events out of the box. Different libraries allow you to track/listen to events, however, there are many cases when something can go wrong, resulting in losing or unprocessed events. To avoid losing events, we have to build a custom back-end, which will maintain the events sync process.

Depending on your needs, the implementation can vary. But to put you in a picture here is one of the options for how you can build reliable POSIChain events delivery in terms of microservice architecture:

Reliable delivery of POSIChain events to all back-end services

These components work in the following way:

• Events sync back-end service constantly polls the network, trying to retrieve new events. Once there are some new events available, it sends these events to the message bus. Upon successful event submission to the message bus, as for blockchain, we can save the last event’s block in order to request new events from this block next time. Keep in mind that retrieving too many events at once may result in requests failed, so you have to limit the number of events/blocks you request from the network.
• The message bus (for example, Rabbit MQ) routes the event to every queue which was set up individually for each back-end service.
• When the message-bus consumes service data successfully, the logic code of the business DApp will handle data. After the data is resolved, we will store it in the database. The database can be used: MySql, PostgreSql, Mongo, Graphql. The database service need to provide enough performance, storage capacity,…

As a result, each back-end service only gets the events it needs. Moreover, the message bus guarantees the delivery of all events once they are published to it. Of course, you can use something else instead of the message bus: HTTP callbacks, sockets, etc. In this case, you’ll need to figure out how to guarantee callback delivery yourself: manage exponential/custom callback retries, implement custom monitoring and so on.

Publishing Transactions

There are a couple of steps we have to perform in order to publish a transaction to the decentralized network:

• Preparing the transaction

Along with transaction data, this step implies requesting the network state in order to find out whether this transaction is valid and is going to be mined (gas estimation in POSIChain) and the transaction’s sequential number (nonce in POSIChain). Some of the libraries try to do this under the hood, however, these steps are important.

• Signing the transaction

This step implies the usage of the private key. Most likely, here you’ll want to embed the custom private key assembly solution (for instance).

• Publishing and republishing the transaction

One of the key points here is that your published transaction always has a chance to get lost or dropped from the decentralized network. For example, in POSIChain, the published transaction can be dropped if the network’s gas price suddenly increases. In this case, you have to republish the transaction. Moreover, you may want to republish the transaction with other parameters (at least with a higher gas price) in order to get it mined as soon as possible. Thus, republishing the transaction can imply re-signing it, if the replacement transaction wasn’t pre-signed before (with different parameters).

The above points regarding POSIChain transaction publishing visualized

By utilising the above approaches you can end up building something similar to the thing which is presented in the sequence diagram below. In this particular sequence diagram, I demonstrate (in general!) how the blockchain recurring billing works (there’s more in a linked article):

The user executes a function in a smart contract, which ultimately allows the back-end to perform a successful charge transaction.

A back-end service responsible for a particular task listens to the event of charge allowance and publishes a charge transaction.

Once the charge transaction is mined, this back-end service responsible for a particular task receives an event from the POSIChain network and performs some logic (including setting the next charge date).