Behind the scene of the Ferrum Network token bridge

Published in

FerrumNetwork

5 min readAug 10, 2019

Hello Ferrum Community,

We recently launched our bridge between the FRM ERC20 and BEP2 tokens. In this article, we discuss our architecture and security considerations behind this tool.

One important thing to note here is that our token bridge is not the only one on the Internet. Other projects have also created a token bridge between chains. One of the reasons we choose to write our own bridge has to do with security, and the other has to do with customization and consistency across our product line. However, this does not by any means mean that we think other token bridges out there are not secure. In fact, I have looked at some of them, like the one built by Fantom, and I think it’s quite good. I advise you to use it if you deem suitable.

The point here is that security does not come only from the choice of technology. To ensure the security of your systems, it is also very important to be very consistent, and keep the processes for your developers as simple as possible. This means that we think very hard before introducing and new security model to our ecosystem.

By way of background, we already have a variety of crypto services that run in the cloud for all our signing and crypto needs. A developer that needs to encrypt something or sign a transaction will just ask for an instance of the service and use it. They won’t need to care about any configurations, how to generate or store keys, or how to protect them. The deployed services will automatically use the right config based on where they are running. This allows us to significantly simplify our security model and make it harder to shoot ourselves in the foot, which. happens everyday in the tech industry.

Principles: Reusable Services, and be Paranoid About Security

Reusable Services

At Ferrum, we have a complex suite of products. From the Unifyre and Kudi Wallets to simpler tools such as token swap, we always try to write and utilize reusable services. For example, a service that monitors Ethereum Network and notifies a client that a transaction has deposited some tokens into their account. This service can and should be re-used across all different products. Another example of a service that can be re-used across products is a prayer service. By employing consistent tools across our product line, we are able to reuse these services for the benefit of our engineers and end users.

Principles: Reusable Services, be paranoid about security

Reusable Services

In Ferrum, we have a complicated suit of products. From the unifyre and Kudi wallet to simpler tools such as token swap, we try to write and utilize reusable services. For example, a service that monitors ethereum Network and notifies a client that a transaction deposited some tokens into their account, is re used across all different products. Another example of a service that can be re used across products is a prayer service.

Security by Design

Security cannot be an afterthought. It is tempting to build products first, and figure out how to secure them later, but this is. not the right approach, especially in the crypto industry where we are constantly under attack. That is why we should all be paranoid about security. It is also why we are releasing Unifyre and Sub-Zero wallets, which fill a critical need in providing excellent security, but in a user-friendly way.

Below are four requirements for any design from the security point of view:

User facing applications must never hold or have access to sensitive information. They are the first targets of attack.

Keys must be encrypted at rest and motion, but encryption alone is not enough.

No single encryption key can be used more than on a limited amount of data and keys must be rotated periodically. Master keys must be held on secure hardware modules

Define isolated security zones. Communication between these zones must be done through pub-sub mechanism. Direct access between zones must be limited.

A Secure Token Bridge Consistent with Our Technology

Taken together, we wanted to build an ultra secure token bridge that employed our existing suite of underlying technologies. Using another project’s token bridge might have been a faster solution, but at the risk of sacrificing our underlying values and general approach. These values dictates that is always preferable to utilize Ferrum Network’s existing suite of technology and security, even if it is more difficult in the near term. We believe this approach pays off in the long term in terms of development of our other products, and the benefits to the end users.

Moreover, we wanted the front end of the token bridge to be consistent with our user-experience found in our other products ( simple, user-friendly, attractive designs, etc.). We hope that when you check out our token bridge you immediately get the sense that it is consistent with our values and general approach.

The Future — Open Sourcing the Bridge

Our token bridge uses several parts of our infrastructure to put together a secure and scalable solution. We are working hard to open source these bits and make them suitable for public consumption, and to write documentation and re factor services to be general purpose enough that can be used by others.

If you are a developer that got excited about what you just read, you can approach me directly. We are always looking for great developers to join our team and/or community.

Thank you for taking the time to read this article. We are going to be more consistent with providing updates on our technological development. We look forward to providing you another tech update in the next few weeks.

Very Truly Yours,

The Ferrum Network Team

Very truly yours,

The Ferrum Network Team

Links:

Website: https://ferrum.network/

Telegram: http://telegram.ferrum.network

Twitter: http://twitter.ferrum.network

LinkedIn: http://linkedin.ferrum.network

YouTube: http://youtube.ferrum.network

Reddit: http://reddit.ferrum.network

Bitcoin Talk: http://bitcointalk.ferrum.network