Taraxa’s fully Permissionless Ficus Root cross-chain Bridge
Introducing Taraxa’s Ficus Root Bridge, a native, generalized, fully permissionless bridge connecting the Ethereum and Taraxa ecosystems!
Ficus Root Bridge Enriches and Secures the Taraxa Ecosystem
The Ficus Root Bridge (the Bridge) enables the bridging of assets, data / signals, helps to harden Taraxa’s network security, enables a network of networks in the future, and is one of the foundational building blocks of a modern DeFi ecosystem.
The Bridge enables dApps and users on Taraxa to access assets and liquidity on Ethereum, making it possible to run a wide range of DeFi applications. DEXs with the right incentives can attract liquidity and trading activities into Taraxa’s faster & cheaper Layer-1, re-staking protocols can help secure Taraxa dApps with native tokens from other networks (e.g., ETH), and lending protocols can help Taraxa users gain exposure in a wide range of assets while holding onto staked Taraxa assets. Of course, bridging of stable coins are also made possible by the Bridge!
Since the Bridge is generalized, its cross-chain functionalities aren’t limited to just assets, but also arbitrary signals. For example, one could potentially build an on-chain oracle that sends Taraxa’s Echo platform’s AI-generated social signals to other networks, where protocols could make use of these signals to make automated trading decisions. Any arbitrary signal or data could be bridged!
With the Bridge deployed, Taraxa network’s security is strengthened. Since Taraxa’s state roots are now anchored onto the Ethereum network, this makes orchestrating a long-range attack on Taraxa’s network prohibitively expensive, as the attacker now also needs to orchestrate an attack on Ethereum, effectively nullifying the economic incentive to do so.
Last but not least, the Bridge enables a network of networks on Taraxa called subgraphs. This can effectively 1000x the Taraxa network’s overall throughput by creating a network of sharded subgraphs. Following the trend of successful dApps deploying their own Layer-1 networks, subgraphs allows any dApp to deploy their own subgraph network, bootstrap their subgraph security via re-staked TARA, and further secure their subgraph with their own native staked assets.
Ficus Root Bridge’s Fully Permissionless Architecture
The Bridge was designed to ensure that it is fully decentralized. So much of today’s web3 infrastructure, from Layer-1’s, to Layer-2’s to bridges, are unfortunately centralized, requiring the permission of one or a small group of individuals. Taraxa has always been fully committed to building infrastructure technologies that are fully decentralized and permissionless, and the Bridge is no different.
The Bridge has a few core components, every one of which was designed to ensure that the entire architecture is fully permissionless,
- Relayers are the messengers of the Bridge, they periodically package state roots and state changes from both Ethereum and Taraxa networks and then send them to the other side, i.e., sends Ethereum state roots & changes to Taraxa, and Taraxa state roots & changes to Ethereum. Anyone can run a Relayer.
- Light Clients are on-chain smart contracts that validate the state roots submitted by the Relayers. There’s an Ethereum Light Client contract deployed on the Taraxa network, and a Taraxa Light Client contract deployed on the Ethereum network. Light Clients are on-chain autonomous smart contracts, and will accept any valid state change submissions from any Relayer.
- Connectors are on-chain smart contracts which are customized to interface with existing on-chain assets or signals. In the case of an ERC-20 asset for example, the Connector on the source network locks and unlocks an asset, so that they may be minted or burned on the destination network, effectively bridging the asset. Connectors are on-chain autonomous smart contracts, and anyone can deploy new Connectors to connect new assets or data into the Bridge.
- Bridge Contracts are on-chain smart contracts that collect and distribute specific state changes across a set of Connectors (for specific assets or signals). Bridge Contracts are pushed (collect) updated changes from Connectors whenever a bridging transaction occurs, and the Bridge Contracts distribute (update) state changes submitted by the Relayers and verified by the Light Clients to their respective Connectors. Bridge Contracts are on-chain autonomous smart contracts.
Not only is every component and every process of the Bridge architecture permissionless, they’re also open source, just like everything Taraxa builds,
- Bridge core: https://github.com/Taraxa-project/bridge
- Relayer: https://github.com/Taraxa-project/relayer
- Bridge UI: https://github.com/Taraxa-project/bridge-ui
Let’s dig into a simple example.
A Simple Example on the Ficus Root Bridge
To help illustrate the workflow of the Bridge, we examine an example where 1 USDT is bridged from Ethereum to Taraxa.
The User in this example is trying to bridge 1 USDT from Ethereum to Taraxa.
Step (a)
The User locks 1 USDT into the USDT ERC-20 Connector contract on Ethereum. The Connector then informs the Bridge Contract of the lock. All the while, the Relayer is listening for changes on Ethereum and periodically packages and submits them into the ETH Light Client and Bridge Contract deployed on Taraxa.
Step (b)
After the User has locked their 1 USDT on the Ethereum side, the Bridge UI is waiting to hear that this locking has been received and verified by the Taraxa side from the USDT Connector on Taraxa. Once the Relayer has submitted its package of state changes from Ethereum into Taraxa, the ETH Light Client on Taraxa verifies that the state root is valid, and informs the Bridge Contract on Taraxa of the validity. The Bridge Contract, having received a set of state changes from the Relayer as well as confirmation of the state root’s validity, then pushes the updated state changes into the various Connectors it’s aware of, including the USDT Connector. Once the USDT Connector receives the updated state changes, it checks to see if the User’s 1 USDT locking is among the updated state changes. If it is, the USDT Connector asks the taraUSDT contract on Taraxa to mint 1 taraUSDT.
Step (c)
After the UI has received confirmation from the USDT Connector contract that the User’s 1 USDT locking is valid and that 1 taraUSDT has been minted, it will prompt the User to claim that minted taraUSDT.
To summarize, 1 USDT was locked on Ethereum, this state change was relayed to Taraxa and verified, and a corresponding 1 taraUSDT was minted on the Taraxa side, completing the bridging. To bridge it back, the whole process would be reversed, whereby the 1 taraUSDT would be burnt on Taraxa, and 1 USDT would be unlocked on Ethereum.
