Sentinel Chain State Monitor
Sidechain is a new and revolutionary concept. It is basically a separate blockchain attached to the main one which allows tokens or digital assets from one chain to be used in another through the use of a two-way peg. The benefits of using sidechain are many. For example, faster transactions, better privacy or, in the case of RSK smart contract functionality using Bitcoin as an underlying asset. Sentinel Chain is one such sidechain based on Ethereum Virtual Machine (EVM) that utilises a SENC-pegged cryptocurrency called SENI (Sentinel Chain Internal Token) as transaction payments within the Sentinel Chain itself. However, in order to do this, we implement a Sentinel Chain Bridge — this bridge is a fork of the work done by members of the POA Network, the POA Token Bridge.
The Sentinel Bridge acts as an intermediary between Ethereum Mainnet and Sentinel Chain. This bridge uses a set of contracts to make the cross-chain transactions and regulate the balance between SENC and SENI. In order to convert SENC to SENI, it is necessary to lock the desired amount of SENC in the Foreign Chain (Ethereum). The user must send the tokens to the Foreign Contract address. Once this happens, the Bridge Validators are in charge of validating the transaction, sending the signal to the Home Contract to mint (create) the same amount of SENI in Sentinel Chain, before sending it to the user who performed the cross-chain transaction. As we can see the relation between SENC and SENI is 1:1 and the user can go back and forth to Ethereum following similar steps in reverse order. As it appears in the diagram below, a whitelist contract is used to restrict users and other contracts to charge a toll for the service, you can find the detailed description of this contracts in the Sentinel Chain Network repository.
Problems
The whole process of transferring assets from one chain to another is not trivial. We must bear in mind that trust in the financial sector is based on transparency and on the security guarantees of the architecture. To address this in Sentinel Chain, we carried out a risk analysis on the infrastructure, thus creating preventive processes to re-establish the balance in critical situations. After completing the analysis we identified two main concerns:
1. Problems with the bridge
Like any other computer system, it is necessary to have a monitoring tool either to make observations in real-time or to create metrics and statistics. In this case, to monitor one of the most critical sections within the environment — the Sentinel Bridge. It should be noted that with the information collected by this monitor, it can calculate the metrics of the system and perform evaluations of positive and negative events. These metrics serve to detect components of the bridge that are affected by various factors such as stress due to heavy loads or when they require modifications to fine-tune the performance or safety of the system.
For example, to detect slow performance or component failure, one measurement could be the time it takes to process a cross-chain transaction in each of the components of the bridge. Another measurement could be the price of the toll charged when performing a cross-chain transaction, and adjust the toll based on the fluctuations in the price of the Ether and SENC. It should be noted that the toll is charged so as to enable the execution of transactions required by bridge validators. Therefore, the validators should always have a balance in Ether to pay for the release of SENI currencies. This is another real-time metric to take into account.
2. Problems with the network
Due to the nature of the blockchain technology, chain forks can occur either due to the loss of connection between the peers of the network or due to internal planning to change chain rules. Therefore, it is important to carry out a follow-up of the possible bifurcations of the network to avoid, for example, balance problems between the chains or double-spend attacks.
Let’s suppose that one of our users wishes to convert SENI to SENC, and a fork occurs. The cross-chain validation process is performed without any problem and the SENC is released in Ethereum. After this, a re-organization takes place in the Sentinel Chain. The transaction that was executed to perform the conversion occurred in the shortest chain. This will result in an imbalance between SENI and SENC.
Sentinel Chain Monitor
The architecture of the monitoring system will be divided into the following layers:
All information processed and consumed from the blockchain layer will be stored in a time series database designed for this type of solution. Time series databases are used to store logs in a period of time and it is used to solve the challenge of millions of events coming in. For our monitoring system, we are going to use InfluxDB because it is open-source, it has good performance and uses InfluxQL (the query language).
On the front-end, Grafana will be used as part of the view layer to visualize, filter and analyse the data. It is an open-source with powerful features such as real-time viewing. It also supports native connection to various backend systems that store time series data, including InfluxDB. With it, we can create comprehensive charts with smart axis formats using Grafana’s fast client-side rendering, even over long ranges of time.
Currently to read data from the blockchain in the Sentinel Chain, we are using an internal API. But this data is obtained in real-time and we do not have any feature to get the history of these events. So to create this new monitoring system, we need to make some modifications in the code of this API to send the data in a proper way to the time series database. To solve this, we will create two instances of this new API within the metrics agent layer, one for each chain to divide the reading load.
The proposed monitor system is one of the best ways of being able to peek into the internals of the product and to quietly find out what’s going on. Also, it is a necessary tool for data input within the life cycle of a program, particularly for the stages of requirements analysis, maintenance and support. For these reasons, it will be of exclusive use by the Sentinel Chain team.
Below, we describe the features and functionalities that of the two proposed monitors that will be included in the system.
Bridge monitor
With the data source in the bridge monitor, we are going to create real-time graphs on Grafana to visualize and control our metrics from all the components of the bridge. Grafana has built-in dashboards, which are made up of rows that define panels. A panel can have metric graphs, but also static text or single figure metrics. We can set thresholds on the graph (for example, to highlight warning or critical values). We can also customize the legend to show an aggregate value for each metric and display it in a table or query the past events. Based on this information, we will create alerts that will be sent to the different administrative social networks of the company to be alerted in case of any incident.
These cases can be:
- The number of transactions that a bridge validator can execute fall below a set level (based on the Ether balance).
- Stalled transaction (withdrawal and deposits).
- Incorrect parity in the token total supply on both chains.
- The differences in the list of validators between the chains.
- The difference in the number of signatures required between the chains.
For the alert system, we are going to use Kapacitor. This tool is a native data processing engine for InfluxDB and is an integrated component in the InfluxDB platform. It also has integration capabilities with multiple alerts destinations like Telegram or Slack. In addition, we can store the alert history as time series data in InfluxDB.
Fork monitor
The idea of the fork monitor is to create an integrated solution to notify possible chain re-organization and get a snapshot of historical data during a fork and the possible dropped transactions. All this data will be collected by the Sentinel Chain agent and deposited in the time series database and eventually, used by the dashboards of the view layer. For this, we are going to store and visualize in real-time the connection status between all the consortium nodes and the information of the current state of its internal block structure.
When a fork happens, Kapacitor will process this event and sends the respective notification to the administrators. Based on the information of the notification and the dashboards alerts from Grafana, the administrators will analyse the compatibility of the forks and choose which one is the right one. To quicken the process of re-establishing the normal functionality of the blockchain, we are going to create a set of automated actions that prevent the creation of more forks or lost of transactions.
For example, before a chain re-organization happens:
- A backup of the old chains will be created.
- A comparison should always be made between forks and if the result of a supposed chain re-organization is incompatible (with lost transactions), the service that provides a connection to the blockchain will be closed.
Conclusion
Block finality is probabilistic in EVM-based blockchains, because it takes time for the blocks to percolate through the network. It is easy for different parts of the network to have a different final block in normal operation since the miners often come up with them at roughly the same time. This is what we might call ephemeral forking. However, as mentioned earlier, forks can be caused by connection lost between nodes and can produce two or three different versions of the blockchain and possibly provoke the loss of important transactions when block re-organization occurs. For this reason, we chose to have an off-chain database to provide fault tolerance, redundancy and anti-fragility. With the proposed monitoring tool, we are prepared for any of the aforementioned situations.
As we mentioned earlier, we are using open source code in part of the components that make up the Monitor, so the final product will also be open source and can be found in the Sentinel Chain Network repositories.
InfoCorp Technologies Pte. Ltd. Founded in 2015 with headquarters in Singapore, InfoCorp Technologies’ aim as an integrated FinTech and AgriTech company is to bring inclusive financial services to the livestock industry in emerging markets via its blockchain-based platform, FarmTrek. Bringing together best talent across the globe, InfoCorp has staff in Rwanda, Myanmar, India, Vietnam, Argentina, and the US. FarmTrek was successfully piloted with two Myanmar government agencies and launched in 2019. Its innovation has been acknowledged as one of 10 winning business models for women entrepreneurs, co-funded by the United Nations to improve access to finance for Women micro, small and medium enterprises (MSMEs) via the UN FinTech Innovation Fund.
Sentinel Chain is a blockchain-based international marketplace for cross-border financial services and the world’s first platform to accept the use of livestock as collateral. Taking a unique approach to the last mile problem of financial inclusion, the Sentinel Chain model establishes livestock provenance through the creation of livestock insurance on blockchain — the registration of livestock provenance on blockchain provides the unbanked with a new opportunity: the real possibility of accepting livestock as ‘collateral’ for loans. Sentinel Chain is a project by InfoCorp Technologies.
Website: https://sentinel-chain.org
Website (InfoCorp): https://infocorp.io
Website (InfoCorp) (Spanish): https://infocorp.io/es/
Medium: https://medium.com/sentinelchain
Medium (Chinese): https://medium.com/sentinelchain-cn
Twitter: https://twitter.com/sentinelchain
Reddit: https://www.reddit.com/r/SentinelChain/
Facebook: https://www.facebook.com/SentinelChain/
LinkedIn: https://www.linkedin.com/company/sentinelchain/
YouTube: https://www.youtube.com/sentinelchain
Announcements: https://t.me/sentinel_ANN
Telegram: https://t.me/sentinelchain
