An Analysis of Tokenbridge Value Transfer

Author: IOBC Capital

Recently, the underlying blockchain network of Axie Infinity, Ronin Network, was hacked for 600 million USD, and the theft was only discovered when users were unable to withdraw from the cross-chain bridge Ronin Bridge. The asset security issues of cross-chain bridges have once again sparked heated discussions.

After the incident, Sky Mavis COO Alexsander Larsen stated, "The attack on Ronin Bridge was not due to vulnerabilities in the smart contract, but related to social engineering and human error." Yat Siu, co-founder of Axie Infinity's investor Animoca Brands, mentioned in an interview, "If a bridge can mint tokens, it is like a minting machine… Bridges are authoritative, but if they are poorly designed or have vulnerabilities, they pose a significant risk to the ecosystem."

In this article, we will specifically discuss the working principles of Tokenbridge and how to ensure reliability and security.

1. Features and Models of Tokenbridge

In the Ethereum ecosystem, Tokenbridge allows users to transfer data across two chains and provides a fast and secure link. As a bridge between the main chain and side chain, Tokenbridge plays a decisive role in the transfer of assets and data.

1. Definition of Chains and Networks

Native (Home): The local chain (side chain) is a fast and inexpensive network where all validator-collecting bridge operations are executed on the native side.

Foreign (Main Chain): This can be any chain, but usually refers to the Ethereum mainnet.

ERC20: In the ERC20-ERC20 bridge model, ERC667 as an implementation of ERC20 can be created and destroyed on the Native Side.

2. Bridge Modes

The bridge can be configured in various network modes. The currently supported modes include Native-to-ERC20 mode, ERC20-to-ERC20 mode, ERC20-to-Native mode, and AMB (arbitrary message bridge) mode.

ERC20 to ERC20: Compatible ERC20 tokens are locked on the foreign network while an ERC20 token (ERC677 token) is created on the native side; when transferring from native to foreign, the ERC677 token is destroyed, and the ERC20 token (foreign) is unlocked.

ERC20 to Native: Coins are locked on the foreign side while an ERC20 token is created on the native side. xDai uses this mode.

AMB Bridge: Allows arbitrary data to be transmitted between two chains. For example, it allows the transfer of NFT tokens and their metadata.

3. Bridge Components

The bridge also includes several components, as follows:

Tokenbridge: Listens for events and sends transactions to authorize asset transfers;

Bridge UI Application: A DApp GUI tool for transferring tokens and coins between chains;

Bridge Monitor: A tool for checking balances and unprocessed events;

Bridge Deployment Playbooks: Optional playbooks. For remote deployment, it can manage the configuration of the token bridge;

Bridge Smart Contract: Manages the bridge's validators, collects signatures, and confirms asset transfers and discards.

To facilitate understanding, let's look at a user case:

This ERC20-to-ERC20 mode token bridge demonstrates how users can transfer funds directly between the main chain and side chain. The specific process is as follows:

1. The user purchases the required tokens through an exchange;

2. The user locks the purchased tokens in the smart contract of the foreign bridge, and this event is transmitted through the token bridge, creating an ERC677 standard token in the native bridge contract, which is then sent to the user's account;

3. The user uses the DApp provided by the side chain;

4. The user wants to transfer assets from the side chain back to the main chain by burning the ERC677 token, and the token bridge transmits the message to the foreign bridge contract, unlocking the token in the smart contract;

5. The user sells the unlocked tokens through an exchange.

Having introduced the basic definition, concepts, and processes of the token bridge, how do we manage a token bridge? This includes upgrades, maintenance, configuration, etc. Here we need to introduce the roles within the token bridge.

2. Token Bridge Roles

The administrator on the token bridge is responsible for the security, upgrades, and deployment of smart contracts for the bridge. The administrator's operations are secured through multi-signature.

Administrative Groups and Roles

Administrators manage the smart contracts of the bridge and are responsible for validator management. Administrators are divided into the following three groups:

1. Group A - Responsible for managing the collection of validators

• Adding or removing validators;

• Setting the minimum required number of signatures for validators.

1. Group B - Responsible for managing bridge parameters

• Setting daily limits for users and validators;

• Setting minimum and maximum limits for each transaction;

• Setting gas price fallback;

• Setting termination thresholds.

1. Group C - Managing upgrades

• Upgrading smart contracts;

• Unlocking funds.

Validators Roles

Provide 100% uptime for transaction transmission;

• Listen for UserRequestForSignatures events on the native side and sign an approval for the assets being transferred on the foreign side;

• Listen for CollectedSignatures on the native side. Once enough signatures are collected, transmit all collected signatures to the foreign side;

• Listen for UserRequestForAffirmation or Transfer events on the foreign side and send an approval to the native side for assets from foreign to native.

The main role of validators is to listen to events on both sides and validate and transmit transactions.

In the Ronin hack incident, the attacker stole assets by controlling the validator nodes. The Ronin chain has 9 validator nodes, and depositing or withdrawing encrypted assets requires 5 out of 9 validator signatures. The attacker managed to control 4 of Sky Mavis's Ronin validators, while another was controlled by a third-party validator operated by Axie DAO. Sky Mavis is the developer of Axie Infinity.

Understanding the working mechanism of cross-chain bridges, we have the following thoughts on how to avoid similar cross-chain bridge security issues like the Ronin incident from a social engineering perspective:

1. Cross-chain bridge projects should focus on the security of signature validation nodes to ensure sensitive information is securely stored;

2. If the signatures of the cross-chain bridge project are conducted offline, the network must update the security policies for signatures, shut down related service models, and consider the risk of signature account address leakage;

3. Validating signatures should not only adopt a multi-signature approach but also ensure that multi-signatures are effectively isolated, and the verification process of the signature content must be conducted independently.

User Roles

There is no need for extensive explanation here; the main role is to initiate asset transfer requests between the main chain and the side chain.

3. Component - Monitor

The main role of the token bridge monitor is to identify data inconsistencies and anomalies that occur during the token bridge oracle process. The monitor retrieves data from the token bridge contract and transactions within the bridge, analyzes their health status, and presents it in JSON data format.

4. Conclusion

We have shared the relationship between side chains and main chains from another perspective, where the transfer of assets and data between the two chains is ensured by the token bridge:

• Tokenbridge manages the roles and configurations of the bridge through a permission role model and multi-signature;

• Validators are responsible for confirming and transmitting transactions on both sides;

• Monitors are responsible for monitoring data consistency and anomalies.

However, this also exposes a problem: the management authority of the token bridge lies in the hands of the admin, and the admin's actions are secured through multi-signature, which is a form of weak centralization in management. Therefore, managing the security of the admin's private keys becomes the core security issue of the entire token bridge.