Building a Sustainable Token Bridge
Due to the conceptual nature of decentralisation, communication between blockchains is notoriously difficult. Any such communication must be mediated. This in itself may be a decentralised network vis-à-vis the Cross-Chain Interoperability Protocol (CCIP) by ChainLink, currently in development.
This brings into question, what is decentralisation? At what point does a centralised network become decentralised? Not only is this a highly subjective question, it’s also a question based on trust. As our founder and CTO has said before, a DAO (decentralized autonomous organization) is nothing more than a state of parity between the trusted and the trustless. Trustlessness is therefore nothing more than the removal of the requirement to trust those whom you do not.
This concept is therefore critical when building a token bridge between two blockchains. A token bridge is conceptually simple. It consists of three fundamental parts and three important steps. There is code on each chain required for the bridge, and a server that talks to both chains. The steps are:
- Tokens to be sent are marked by the holder by interacting with the source chain.
- The server detects sent tokens and interacts with the target chain.
- The holder interacts with the target chain to receive their tokens.
Steps 2 and 3 may be in either order, and this is a key point as will be explained later.
The most basic architecture of a token bridge and how to build it can be found on this tutorial page by Moralis (see basic architecture diagram below). Bear in mind that this does not include step 3 above, but this results in the server incurring all fees which may be suitable for some use cases.
Token Bridge First Implementation
In late January, Schnoodle Finance received the code from our partner B&R Group in Russia for a SNOOD token bridge between Ethereum and BNB Smart Chain (BSC). Since then, our intrepid lead developer Jason Payne has been refactoring this code to make it fit for purpose and to the Schnoodle coding standards which is a very high bar. The code they provided works as it is, but it is based on the premise that trust is placed on holders to complete their token transfer which is step 3 above where the holder pays a fee. In the order that the steps are above, the server has already incurred a gas cost in step 2. This could prove problematic if more holders have not completed their transfer than are able to be covered by the server in terms of gas costs. In fact, a bad actor could force this situation by triggering many transfers and not completing them.
This is further exacerbated in the code by an exploit whereby a user could reduce the fee they pay as the amount of the fee is not stored on the blockchain. The server passes the fee amount to the frontend of the DApp and relies on the user honouring this fee when receiving their tokens. Most users would not know how to exploit this as it requires JavaScript and/or technical blockchain knowledge. But this is now a situation where holders are being “trusted” to not notice or not use or not know how to use the exploit. For those who did, it could be a minor loss under normal circumstances, and the treasury would have to cover it. However, a bad actor bridging from a cheap gas chain to an expensive gas chain, and with enough tokens and enough willpower, could attack the bridge and disable it indefinitely. 😱
There are semi-solutions such as requiring a minimum token amount for sending, and also requiring a minimum fee. But what if the token value changes significantly compared to the equivalent gas? And how does a minimum fee account for wildly fluctuating gas prices. The minimum fee could be too low to cover the gas, or too high to make the bridge cost-effective for users. In other words, problem and these solutions don’t scale well.
Token Bridge Rearchitect
At this point, we began ideating the rearchitecting of the bridge. The exploit is easily resolvable by storing the fee in the target chain when the server interacts with it (step 2 above). Obviously, this must be an estimate because the gas used cannot be accurately determined until the transaction is mined. However, it can be estimated beforehand with a margin added for changes, and this set as the gas limit. The user must then pay this fee (step 3), or the function to receive their tokens reverts.
One problem solved. 🚀
However, this only ensures that fees are correctly paid. It doesn’t prevent a bad actor from executing a series of incomplete transfers by not paying the fee on any of them, while the server incurs gas fees for all of them.
The solution is to swap steps 2 and 3 around so that the holder interacts with the target chain and pays the fee before the server does. This isn’t as simple as it sounds, though. For this to work, there is an extra off-chain step where the fee is estimated and stored in the server along with the identity of the holder (their account address). The server then informs the frontend about the fee, and the user then pays it via the DApp. This interaction with the smart contract is where the amount paid is also stored on-chain. The server then interacts with the target chain to release the tokens to the holder. The payable fee is passed to the smart contract which ensures that this is what was paid by the user, and reverts if it wasn’t.
These are now the steps (with additional detail):
- Tokens to be sent are marked by the holder by interacting with the source chain.
- The holder interacts with the target chain to pay the fee advised by the server. The fee amount paid is stored in the contract.
- The server interacts with the target chain to release the tokens to the holder ensuring the fee stored in step 4 from the previous bridge is at least the amount advised in step 2.
- The server stores the gas fee that was paid — for its interaction with the target chain — less the fee that was paid in step 2.
What we have now is a cost-efficient, fully sustainable, scalable and secure token bridge, the only one of its kind in existence. The Fully Autonomous Bridge (FAB) will never require the team to add more native tokens to cover gas, and there will never be a situation where the bridge could become disabled by a bad actor, or an unanticipated future event or state such as an influx of holders using the bridge simultaneously, or an excessive number of holders not completing their transfers than the system can handle (it should be expected that a certain rate of users will leave their tokens in limbo indefinitely due to forgetting or some other reason).
Again, Schnoodle Finance has proven once again that it will continue to trailblaze the blockchain and cryptocurrency space with its groundbreaking technology to solve problems in new and innovative ways.
Trust is Shifted
Trust is now shifted. There is now a requirement to trust the server to complete step 4, instead of entrusting the treasury and the sustainability of the bridge to a growing number of unknown holders in the anonymous world of cryptocurrency. Of course, the first time the server fails to complete step 4 in a timely manner or at all will be visible in the blockchain, so this can only happen once and to only one user in theory. The question is, is this the state of parity between the trusted and the trustless that the community is comfortable with?
Welcome to decentralisation. Where the lines between trustlessness and centralisation are blurred. Even with a blockchain, we trust the miner network to operate scrupulously, and they are governed by code. But can code detect what the miners are discussing offline? A blockchain is only as decentralised as the trust you give its network. Where’s the trustlessness in that? A blockchain is therefore only as good as the next coup d’état or insurrection.
Until then, Schnoodle Finance will continue to raise the standard of what it means to be truly decentralised and truly trustless. At least, as much as any token can be. Trust the team, trust the process. 🤝
