Cross chain technologies
Last updated by Thomas Coratger 4 months ago
Position of the problem
More blockchains are currently being developed based on technological innovations unique to each product. In decentralized systems, the inability of independent blockchains to communicate with one another is an inherent problem. The lack of appropriate inter-blockchain communication limits the possibility of collaboration between various projects . A major limitation for the end user is the inability to exchange tokens without going through a trading platform. To put things into perspective, the DeFi sector currently encapsulates over a trillion dollars, spread across a crypto ecosystem that consists of over 5,000 cryptocurrencies operating in isolated infrastructures that cannot access the liquidity offered by one another.
As a result, having multiple blockchains that can communicate with one another may allow blockchain technology to reach its full potential. To address this scenario, a mechanism to port liquidity across blockchains and increase capital efficiency in the system is becoming increasingly important. We may be able to communicate with a blockchain system in the future in the same way that we send emails between networks.
Similarly to the Scalability Trilemma, introduced by Vitalik Buterin , based on scalability, security and decentralization, there exists an interoperability Trilemma. The interoperability Trilemma is based on the following principles (interop protocols can only have two of the following properties).
Trustlessness: having equivalent security to the underlying blockchains. Extensibility: able to be supported on any blockchains. Generalizability: capable of handling arbitrary cross-domain data.
Locally verified: only parties involved in a given cross-chain interaction verify transactions (Connext, Hop, and other simple atomic swap systems).
Because security is supported by the underlying chain and locally validated systems are very simple to expand to additional blockchains, they are trustless. This system cannot provide generic data transmission between chains due to its local property.
Natively verified: all validators of the two blockchains involved in a transaction verify the message (examples: Cosmos IBC, Near RainbowBridge or Rollup entry/exits). The most significant benefits are the generalized messages that may be sent between chains and the trustless interoperability that is induced by the underlying verifiers that are directly accountable for bridging.
Externally verified: an external validator set is used to verify transactions between chains (Thorchain, Anyswap, Biconomy, Celer, Synapse, PolyNetwork, EvoDeFi, and many others).
The ability to send generalized messages and the simplicity of extension to other blockchains are the major benefits. Users and/or LPs must have total trust in the external verifiers with regard to their money and data. Some initiatives strive to increase user security by using additional staking or bonding mechanisms, although doing so can weaken the trilemma's trustless component and is less practical given the size of the blockchain industry.
The Router Protocol , as a cross-chain communication mechanism, initially focuses on bridging assets across multiple layer 1 and layer 2 networks by using stablecoins as the medium of value transfer. The protocol also enables the flow of arbitrary messages across chains. To justify the new strategy, Router Protocol highlights the drawbacks of the existing solutions (but this is only their point of view, and their findings must be moderated in relation to the observations established earlier in this document):
Cross-chain infrastructures rely on 1-to-1 bridges, so every time a new chain needs to be added, N individual bridges must be established (where N denotes the number of chains in the network). Most protocols are limited only to ERC20 states. Lack of transparency in accounting: all transactions passing across bridges are not clearly and publicly recorded.
With a novel architecture, the Router Protocol aims to increase the functionality of the current cross-chain solutions. Router creates a mesh network where all chains are connected to one another via the same set of router nodes. They have the ability to read and publish transactions on all blockchains that are part of the Router network. With the Router protocol, it is easier to add a new blockchain to the network (with just a few configuration settings) than for other 1-to-1 bridges or ERC20 limited bridges.
Blockchains are a part of Router's liquidity 'super mesh.' Bridge contracts for every chain supported by Router Protocol are used to link the source and destination chains, via contract aggregation votes from Router nodes on proposals relayed from the source chain. Creating a record of all the incoming cross-chain transactions. Executing all outgoing cross-chain transactions based on the voting process Fee Manager Module to choose the token to use for the transaction: Native gas token on the source chain (default) ROUTE (50% concession in transaction fees) DFYN (20% concession in transaction fees)
The fee manager module estimates the transaction fees every 30-60 minutes depending on the congestion on different networks.
Router's UI: the interface where users can interact with Router’s bridge contracts. Pathfinder Algorithm to find the optimal route to move assets from the source chain to the destination chain. Aggregator Contract to carry out the trades specified by the pathfinder algorithm. Event Handlers allow for customizable behavior upon receiving transactions from the ParaRouter. Router Nodes that listen for events on the source chain, generate proposals for those events, and submit signed proposals on the destination chain as a vote. The nodes are composed of four modules: Connector to connect a route node to all chains. Listener actively observes chain state transitions to listen for initiated transfers. Router receives constructed messages from listeners and forwards them to the writer. Writer parses the bridge message into a valid transaction and submits it to the destination chain. Voting Module: once a proposal is created on the destination chain, other router nodes vote on it by signing the proposal.
Ethereum - ETH
Fantom - FTM
Optimism - ETH
Arbitrum - ETH
Cronos - CRO
Avalanche - AVAX
BNB Chain - BNB
Aurora - ETH
Polygon - MATIC
Harmony - ONE
Considering that the security of cross-chain projects is of utmost importance, Router Protocol completed audits from different sources (Certik, Halborn and Hacken). Bug bounty program (Immunefi). Proxy Contract Implementation. Isolated Execution Pallet.
My concerns about Router Protocol for Grindery project
Router Protocol is an innovative and new cross chain protocol. As it is recent and under development, few blockchains are supported and this might delay the expansion of Grindery, especially with the primary partners (Flow for example).
However, the fee manager module seems to be fully modulable and able to support multiple tokens. The Grindery project can definitely take advantage of this modularity.
Router Protocol uses a pathfinder algorithm to find the most optimal route to move assets from the source chain to the destination chain. The idea is to facilitate easier use of the pathfinder algorithm, and one of the things they have done is abstracting it and making it available in the form of an API, Widget, SDK and Cross library framework.
To perform a cross-chain transaction using Router's asset-swap API involves four steps:
Request a Quote
Check and Set the Allowance
Execute the Transaction
Router Protocol also has developed a widget that can be used by other projects to give their users an option to perform cross-chain transactions directly from their interfaces.
Router Protocol has SDk to simplify the process of carrying out cross-chain swaps in the bid to simplify the process of interacting with Router's bridge contracts
CrossTalk is a smart contract library that allows users to build cross-chain applications using the Router infrastructure. It primarily facilitates cross-chain communication amongst smart contracts, which helps developers with use cases like:
Native cross-chain applications like cross-chain lending and borrowing platforms, and cross-chain governance systems, among others. Port a single chain dApp to multiple chains Launch chain agnostic NFTs Create stablecoins with built-in cross-chain capabilities
While CrossTalk is relevant to dApps looking to leverage cross-chain technology for broader use cases, JS SDK and asset-swap API are specific to the cross-chain swap functionality. It’s relevant for use-cases including but not limited to:
Capturing cross-chain arbitrage. Providing cross-chain swap as a service inside existing projects, particularly wallet providers, multi-chain DEXes, and other multi-chain applications. Customizing user flow for cross-chain swaps in existing cross-chain bridges that only have cross-chain transfers as a functionality.
Celer Network is a tool that can be used by developers to build inter-chain-native decentralized applications to gain access to efficient liquidity utilization, coherent application logic, and shared states.
Celer Inter-chain Message
Celer IM offers a single-click user experience to benefit from a higher liquidity efficiency and coherent application logic. Let us make a special focus on decentralized exchanges that are one of the main applications involved.
Building liquidity pools for the same key asset pairs on every chain is particularly inefficient. Celer IM offers a better trading experience by concentrating the farming incentives for a pair of tokens on a single pool, creating deeper liquidity with low-slippage.
User initiates a transaction to dApp via a new dApp Plug-in contract to express an intention of cross-chain logic execution. dApp Plug-in sends a message and associated cross-chain fund transfer. The message is sent to the Message Bus contract. The fund transfer is sent via an asset bridge. State Guardian Network (SGN = Proof-of-Stake blockchain built on Tendermint with CELR as the staking asset) routes the message and cross-chain fund transfer. The SGN staking nodes are continuously monitoring the transactions happening on all of the connected chains. Executor performs cross-chain application logic: the Executor’s task is to read the stake-weighted multi-signature attestation from the SGN blockchain and simply relay it to the Message Bus on the destination chain.
Users of Celer IM are required to pay fees to the SGN in return for its services of reaching consensus and storing attestations of the source chain messages, as well as the fund transfer. The fee amount is calculated by:
Executors charge fees to submit and execute message transactions. These executor fees are decided at the application level without any enforcement coming from the Celer IM framework.
Architecture and benefits
Architectural benefits mostly concern the support of larger transfer sizes and the improvement of the user experience via a single click operation. The extension of the service to more tokens and chains is at the center of the 2.0 architecture.
Crab Smart Chain
Kava EVM Co-Chain
My concerns about Celer Network for Grindery project
Celer Network is a protocol for interoperability that seems particularly well suited to tackle large transfers. As a result, the architecture may differ from what we need at Grindery to handle micro payments.
Celer Network was developed and created with a specific use case to push the use of blockchain to the mainstream through the use of interoperability and layer-2 infrastructure on top of blockchain platforms such as Ethereum and Polkadot. The main goal is to enable cross-chain and multi-chain support for decentralized app developers and allow fast, secure, and cost-efficient transactions while creating a cryptocurrency economy that incentivizes network participants.
The Network is a layer-2 scaling platform for deploying decentralized applications on various blockchains, which enables interoperability within the ecosystem and network incentives.
It exists as smart contracts on top of other blockchain structures such as Ethereum and Polkadot, though the team is said to be leading layer-2 scaling research and building applications that foster functionalities for the Celer Network ecosystem.
Celer has the main goal of providing smooth operations for smart contracts, fast off-chain transactions, and offering a secure environment for dApps on all types of blockchain platforms. The idea behind this is to help developers scale their dApps through the layer-2 protocol while providing all the necessary tools and functions to solve some of the biggest issues that smart contract platforms currently experience. As a solution framework, Celer Network acts as a support for scaling and securing some of the biggest smart contract platforms, such as Ethereum.
Architecture Details and How the Network works:
Celer Network is a layer-2 protocol built on top of other blockchain platforms to enable scaling and secure operations through off-chain transactions for platform users and dApp developers. The anatomy of layer-2 platforms presents a solution for scaling and interoperability, with these being two of the biggest problems for many blockchain-based networks.
Layer-2 protocols represent a great solution for scalability as the base protocol of the underlying network doesn’t have to be changed or updated for the protocol to work. Instead, a layer-2 protocol operates as a smart contract on top of a blockchain like Ethereum and interacts with off-chain applications. The core technologies that make up the Celer Network are Side Chain technology and the Generalized State Channel Network . With the help of side chains, Celer Network facilitates interoperability while enabling off-chain operations through the use of the GSCN. The GSCN is fairly complex but it can be compared to the Lightning Network. Just as the Lightning Network enables faster and more cost-effective transactions on the Bitcoin blockchain, the GSCN enables fast off-chain operations for blockchains like Ethereum, allowing dApps to scale. The unique thing about Celer Network is, it is not the only layer-2 scaling platform but it provides support for multiple blockchain platforms and environments.
For example, DFINITY’s Internet Computer and Ethereum are substantially different platforms, but Celer Network works efficiently on both networks. Moreover, Celer Network supports off-chain smart contract operations and payments, using an optimal state algorithm for routing which provides 15 times higher throughput than other state-of-the-art solutions.
Celer Network is believed to be the first and only solution of its kind to enable dispute resolution, connectivity, state availability, and excess liquidity for off-chain operations.
After understanding the protocol architecture design, what comes to mind is the security,
Celer Network and its off-chain and on-chain operations are secured through the use of the delegated Proof of Stake protocol, which facilitates the system of voting and staking. The system rewards stakeholders who work on securing the network by staking the native token CELR.
However, Delegated Proof of Stake as one of the consensus mechanisms is said to be one of the most secure and cost-effective solutions among blockchain-based protocols, which enables Celer Network to offer top security for developers and network users.
Since the launch of Celer IM Mainnet, a few projects and developers has built inter-chain dApps using the Celer Inter-chain Message SDK with efficient liquidity utilization, coherent application logic, and shared states across multiple blockchains.
ChainHop : is a composable inter-chain liquidity protocol built using Celer IM. Using ChainHop , users and developers can easily convert a token on one chain into another token on the other chain with just a single transaction. In addition to ChainHop , there are other 8 projects: SynFutures , Mystiko , Swing , FutureSwap , Ooki , Rubic , Solace , and Aperture that are building inter-chain native dApps in the spaces of cross-chain governance, cross-chain yield aggregators, cross-chain synthetic asset trading, cross-chain privacy and other innovative use cases.
These use cases are using the Celer IM framework because it is very easy-to-use and allows a “plug’n’play” upgrade that often requires no modifications with already deployed code. So engineers integrate Celer IM by going through the documentation, smart contract framework, and sample application code.
Synapse Protocol offers an extensible cross-chain messaging protocol. This consists of a messaging framework and an economically secure method to reach consensus on the validity of cross-chain transactions. This is based on three main principles:
Security: cross-chain transactions are validated by an optimistic verification system in which off-chain actors coordinate to identify malicious transactions. Composability: Synapse is designed with the intent to eliminate today's interoperability roadblocks and to make composability a first class citizen in cross-chain application development.
Cross-chain messaging: applications can be deployed on a single chain and communicate with other chains. Optimistic verification: this mechanism adds a significant layer of security to the network, making it far more costly for a bad actor to conduct an attack versus the existing M of N mechanism. Naturally, the added security requires a trade-off here, latency. Synapse AMM pools (on each chain that the Synapse Network is interconnected with) employ a stableswap algorithm (a mathematical model for assets that are intended to have prices that remain stable relative to one another) to price transactions and incentivize asset rebalancing in the process of swapping and bridging. Fees: the stableswap fee is applied to received assets, with some percentage of this fee reserved for the protocol as an admin fee.
In the mechanics of depositing and withdrawal, virtual swaps are performed in order to make the proportion of assets equal to the ideal proportions of the pool following a function of multiple parameters:
These operations require fees that are on average 50% of the usual swap fee, but it will depend on the balance of assets in the pool.
My concerns about Synapse Protocol for Grindery project
Synapse Protocol, via the stableswap pool, tends to make the proportion of the supplied assets equal to the ideal proportions of the pool. For this, fees are required. At the end, swap and bridge fees must be considered and the costs can vary depending on the performed transactions (Bridging USDT from Ethereum to non-Ethereum chains / Bridging USDT from non-Ethereum chains to non-Ethereum chains / Swapping USDT for USDC on the same chain). This can result in complicated and expensive fees calculations.
Moreover, the networks of proposed blockchains does not include all of Grindery partners.
The Synapse protocol is a cross-chain bridge that allows for the transfer of assets between blockchains, securely and efficiently. In other words, it exists to solve the problem of cross-chain interoperability by enabling core blockchain activities like asset transfers, swapping, and messaging by offering decentralized, permissionless transactions between L1, L2 and sidechain ecosystems.
People can use Synapse Bridge to transfer stablecoins from blockchains such as Ethereum, Polygon, Avalanche, Harmony and more. Developers can also use the Synapse protocol to create useful cross-chain applications such as cross-chain DEXs, derivative markets, and landing platforms.
Architecture Details and How it works:
The Synapse Network
The Synapse network is a decentralized, leaderless platform. It is secured by cross-chain multi-party computation (MPC), which operates using threshold signature schemes (TSS) which are private and public keys used to authenticate transactions.
This is how it ensures high security standards : When on-chain events are received on any of the chains being tracked by the MPC validators, each validator runs the same process, and when two-thirds of the validators have signed the transaction, the network reaches a consensus, the transaction is validated and sent to the destination chain.
Synapse users reach out to the community to become validators. In order to participate in the validation process, validators must stake SYN to help secure the network. If they engage in dishonest or malicious behaviours, validators’ staked balances will be penalized, just like how other proof-of-stake chains work.
Cross Chain AMM
The Synapse automated market maker (AMM) technology transforms tokens from one blockchain into the native of tokens of a destination chain through the use of stable swap algorithms, which is responsible for determining an exchange price for assets within the cross-chain liquidity pools. This ensures a smooth transfer of assets between different platforms and ecosystems with minimal inefficiencies, losses and slippages.
The SYN token is the native token of the Synapse protocol, used to access services on the network. Core functionalities of the SYN token include:
Staking : Validators stake SYN tokens to become a part of the network and earn rewards. Protocol fees and gas fees : Fees for executing transactions on the network are paid in SYN tokens. This includes fees for creating and interacting with smart contracts, fees for cross-chain swaps, and fees for ensuring the security of the network. Incentives and rewards : The SYN token is used to incentivize good behaviour on the network such as providing liquidity, maintaining high-quality data, and participating in governance. Governance : SYN token holders can vote on platform governance decisions.
There are 6 types of fees on the Synapse protocol:
Swap Fee : A fee charged when users want to swap assets between different blockchains that are connected to Synapse. Bridge Fee : Charged when users want to move assets from one blockchain that is not connected to Synapse, to another blockchain that is connected to Synapse. Admin Fee : Charged by the network in order to pay for the costs of maintaining and developing the protocol. Deposit Fee : Charged when users want to deposit assets into the network in order to be able to swap them. Withdrawal Fee : Charged when users want to withdraw assets from the network. The fees collected by the protocol will be used to pay for the costs of maintaining and developing the network, as well as to pay for the rewards given to validators. Validator Fee : Charged by the validators for their services in verifying and validating transactions on the network.
What is Synapse Chain?
The Synapse Chain is creating a proof-of-stake (PoS) based smart contract platform that secures the protocol’s messaging system. The Synapse chain aims to increase capital efficiency and cut SYN emissions on the Synapse platform by eliminating AMM pools on each chain and replacing that with liquidity on the Synapse chain. The chain also allows developers to build new sets of protocols which will be able to interact with assets on other blockchains.
In addition, the Synapse ecosystem will eventually include core DeFi features such as a decentralized exchange (DEX), derivatives and lending platforms.
The Synapse bridge is designed to be a secure and efficient way to transfer assets between different blockchains. The project has also been audited by multiple security firms. It is constantly being monitored by the team to guard against security vulnerabilities.
At the moment, Synapse Protocol currently supports most of the popular chains and assets, one of its weaknesses is that Synapse only supports a limited number of chains and assets. The team is continuously working on adding more assets and chains to the protocol but it will take some time before Synapse is able to support all assets and chains.
Maplabs - Map Protocol
Map Protocol is the omnichain layer of Web3 for dApps with highly secure cross-chain communication built on light-client and zk-SNARK, with five advantages:
Security: self- verification cross-chain Cost efficient: no additional cost for cross-chain transactions other than gas fees. By zk-SNARK, gas fee is further reduced to minimum. Instant confirmation: confirms cross-chain transactions instantly. Confirmation speed for cross-chain transactions is only limited by each chain's block time. dApp Developer ready: effortless integration via SDKs for straightforward omnichain app deployment.
Application layer (Fungible Token Bridge, NFT bridge, Omnichain Swap, On-chain Oracle, Derivatives, Omnichain DAO, Omnichain Lending, Omnichain Gamefi). Cross-chain Services layer (similar to Google Mobile Services to Android ecosystem). Protocol layer: Verification Finality Network and dApp Deployment. EVM and non-EVM chains: cross-chain execution and verification via on-chain smart contracts, and cross-chain messenger inter-chain program. Security: Light-client independent self-verification mechanism and zk-SNARK. Fully EVM compatible: Proof-of-Stake mechanism and Byzantine Fault Tolerant consensus. Heterogeneous expansion on the EVM level: minimization of the gas fee for cross-chain verification between heterogeneous chains. SDKs for dApp developers: dApps do not need to deploy on MAP Relay Chain in order to connect to MAP's omnichain network. Cross-chain Services similar to Google Mobile Services. Support of assets and data cross-chain. Supports the development of all omnichain dApps.
Gas Fee Model
MAP Protocol will only charge the gas fee produced on MAP Relay Chain for each cross-chain transaction. Maintainers can get extra rewards from MAP Protocol for updating and maintaining Light-Clients.
My concerns about Map Protocol for Grindery project
This project seems to be very well documented with an extension to many blockchains including partner networks. The decentralized security and the instant cross-chain communication can be seen as significant advantages in the scope of micro payments and for the Grindery project where the efficiency and the rapidity of the network are of paramount importance.
The low gas fees must also be considered but they are attributed to dApps and not to the end users which can be a hindrance to the development of the project.
MAP Protocol is a blockchain interoperable protocol designated for cross-chain Dapps, application-ready, all-chain coverage, cost-efficient, and security-finality.
MAP Protocol provides verification finality by Light-client, supports smart contract development on Map Relay Chain, offers cross-chain services components for Dapp's convenient deployment, and enables universal connections with all chains by proactively embedding other chains' feature as pre-compiled contracts in EVM layer of Map Relay Chain. MAP Protocol maintains a cost-efficient network by simply charging Map Relay Chain's gas fee for cross-chain transactions.
While cross-chain bridges can be easily built with MAP protocol, the protocol itself targets a more fundamental problem and pursues grander vision: boosting the whole cross-chain ecosystem by building a solid cross-chain Dapp infrastructure. Any Dapp built with the infrastructure automatically inherits the cross-chain nature of MAP protocol without requiring the developers to tackle the error-prone cross-chain communications. With the technical threshold of building cross-chain Dapp reduced, the ecosystem shall thrive.
Architecture details and How it works:
While cross-chain bridges can be easily built with MAP Protocol, MAP Protocol itself tackles a more fundamental problem and pursues a larger vision: boosting the whole cross-chain ecosystem by building an omnichain network infrastructure. Any dApp built with the infrastructure automatically inherits the omnichain nature of MAP Protocol without requiring the developers to tackle the error-prone cross-chain communications.
With the technical threshold of building omnichain dApp reduced, the ecosystem thrives in the following:
MAP Protocol is structured in three layers: Protocol Layer, Cross-chain Services Layer (MCS), and Application Layer. MAP Protocol achieves omnichain interoperability with all EVM and non-EVM chains by deploying cross-chain execution and verification via on-chain smart contracts, and cross-chain messenger inter-chain program. MAP Protocol's cross-chain verification network has security finality by adopting the Light-client independent self-verification mechanism. MAP Relay Chain is fully EVM compatible built upon Proof-of-Stake mechanism and **Byzantine Fault Tolerant consensus. MAP Relay Chain accomplished heterogeneous expansion on the EVM level, which simplified the complexity of engineering and minimized the gas fee for cross-chain verification between heterogeneous chains. By connecting with MAP Relay Chain, EVM and non-EVM chains form a cross-chain execution and verification network. MAP Protocol provides SDK for the inter-chain communication component - Messenger to dApp developers. Each dApp can have its own Messenger and tailor-make their reward scheme, which facilitates cross-chain transactions to be completed. MAP Protocol provides developers with MAP Cross-chain Services similar to Google GMS. It is convenient for developers to develop and share omnichain asset liquidity and data. MAP Protocol supports both assets and data cross-chain. MAP Relay Chain supports the development of all omnichain dApps, including omnichain oracle, omnichain swap, cross-chain bridge for tokens and NFTs, decentralized derivatives, omnichain DAO, and omnichain GameFi, etc.
The Three Layers Technical Structure Architecture
MAP Protocol is structured in three layers: MAP Protocol Layer, MAP Cross-chain Services Layer(MCS), and MAP Application Ecosystem Layer .
MAP Application Layer
Assets and data originated from dApps assembly on MAP Relay Chain DApps can achieve interoperability because of MAP Cross-chain Services (MCS) The finality of omnichain data and asset verification network by MAP Protocol Layer empowers dApps to grow limitless.
MAP Cross-chain Services Layer (MCS)
It f acilitates dApp developers to build applications, similar to Google Mobile Services to Android ecosystem. Consists of Vaults and Data deployed on each chain, and Messenger Program to transmit messages between chains. The execution layer for omnichain asset and data. DApp developers can build their components or use MCS. Developers can utilize Vaults and Data in MSC and share Vaults and Data liquidity with other applications. Messenger Program is an SDK deployed, operated, and maintained by dApp developers. DApp developers can also independently and flexibly incentivize messenger contributors for transmitting omnichain messages for the dApp. The self-verification mechanism of the Light-client on the MAP Protocol Layer assures the invalidity of malicious attacks from messengers.
Protocol Layer - Construct the CORE of Omnichain Network Infrastructure: Verification Finality Network and dApp Deployment
This protocol c onsists of: MAP Relay Chain, Light-Client deployed on each chain, and inter-chain Maintainer Program to update and maintain Light-Client status.
MAP Relay Chain proactively extends and supports heterogeneous blockchains' features in virtual machines, which construct a gas-efficient Light-Client verification network. Light-Client deployed on each chain has the characteristics of independent self-verification and verification finality, which becomes the verification network for cross-chain assets and data. The Maintainer is an independent inter-chain program responsible for updating the status of Light Clients. The mechanism of the Light-client assures the invalidity of malicious attacks from maintainer.
THORChain is a decentralized liquidity protocol that allows users to swap assets in a permissionless setting. By serving as a vault manager, it facilitates the trading of native layer-1 assets like Bitcoin. Tendermint and Cosmos-SDK are used by THORChain to protect its network instead of building a blockchain from scratch. For its leaderless primary vault, it also makes use of threshold signature schemes (TSS).
Swappers who use liquidity pools to swap assets. Liquidity providers who add liquidity to pools and earn rewards. Node operators who provide bonds and are paid to secure the system. Traders who monitor and rebalance pools with the intention of making profits.
To generate yield, which is made up of swap fees and system rewards, liquidity providers deposit their assets in THORChain's liquidity pools. A pool's liquidity can be increased by anyone, making THORChain permissionless. A cross-chain switching network is created by independent node operators, or THORNodes, communicating with one another. They will be rewarded with fees for each swap they make. Swappers will transfer their assets to THORChain and receive another asset via an asset swap. Arbitrage traders control the market pricing on THORChain, which in turn determines the value of asset swaps. By comparing pool balances, THORChain may use this liquidity pool model to calculate the value of every asset in any other asset.
As a vault manager, THORChain keeps track of deposits and withdrawals and values assets using pool ratios. By eliminating centralized intermediaries, this promotes decentralized liquidity.
The native coin of THORChain is called RUNE. It serves as a base pair within the network allowing users to swap RUNE for any other supported asset.
RUNE as a settlement asset: RUNE is the settlement asset for all liquidity pools, facilitating swaps between two pools. RUNE for security: to ensure security, node operators have to bond twice as many RUNE as the amount they added to a pool. RUNE for governance: RUNE token holders can choose which asset or chain they want to give priority to. RUNE for incentives: Block rewards and swap fees are paid to liquidity providers and node operators in RUNE on a set emission schedule.
My concerns about ThorChain for Grindery project
As a DEX, the trust problem of a centralized exchange is alleviated by using an intermediate consensus layer in order to achieve transaction consensus. This additional overhead seems to be unnecessary, adding complexity to the project.
THORChain is a decentralised cross-chain liquidity protocol based on Tendermint & Cosmos-SDK and utilising Threshold Signature Schemes (TSS). It does not peg or wrap assets, it simply determines how to move them in response to user-actions.
THORChain observes incoming user deposits to vaults, executes business logic (swap, add/remove liquidity), and processes outbound transactions. THORChain is primarily a leaderless vault manager, ensuring that every stage of the process is byzantine-fault-tolerant.
THORChain's key objective is to be resistant to centralisation and capture whilst facilitating cross-chain liquidity. THORChain only secures the assets in its vaults, and has economic guarantees that those assets are safe.
Breakdown on how ThorChain work:
THORChain is a leaderless vault manager with the following structure:
1-way State Pegs allow syncing state from external chains A State Machine to coordinate asset exchange logic and delegate outgoing transactions Bifröst Chain Client to processs chain-specific transactions A TSS protocol to enable distributed threshold key-signing
The Bifröst Protocol: 1-way State Pegs
Each node has a "Bifröst" service that deals with the nuances of connecting to each chain. Once nodes are synced, they watch vault addresses. If they ever see an inbound transaction, they read it and convert it into a THORChain witness transaction.
THORChain processes each observed transaction and waits for consensus. Once a super-majority of nodes agree on a particular transaction, it moves from a pending state to a finalised state.
Each chain client is quite light-weight, containing only as much logic as is necessary to connect to that particular chain. Most of the logic is in the observer itself.
THORChain State Machine
The state machine processes the finalised transaction and performs logic, such as ordering transactions, computing state changes, and delegating them to a particular outbound vault. Finally, a txOut item is created and stored in the Key-Value store.
The Transaction Out item details which chain it should be sent on, the destination address, the vault it should be sent from, and the maximum gas that should be spent. It also has fields for the transaction that initiated it (the InHash) and the transaction that will complete the accounting (the OutHash).
Once the finalised transaction is created, the Signer loads it from their local copy and serialises it into a correct transaction for the destination chain using the respective chain client. This is then sent to the TSS module which coordinates key-signing. The final signed transaction is then broadcast to the respective chain.
There are two types of vaults in THORChain's system - "inbound vaults" and "outbound vaults":
Asgard TSS Vaults - inbound vaults with large committees (27-of-40) Yggdrasil Vaults - outbound vaults with 1of1 single-signer
This allows the system to use the security of the large vaults to hold the bulk of assets, but delegate to the small, fast outbound vaults the outgoing assets. Every THORNode runs an outbound vault.
It takes 10-20 seconds to sign 27-of-40 TSS, so the system would be extremely limited if this vault did all the outbounds. But with each node (100) running an outbound vault, the system can do roughly 1 transaction per vault per second, so around 1500 times the output.
Sharded Asgard Vaults
In order to further increase the node count to beyond 40 nodes, the system shards Asgard vaults into two when it approaches the MaxNodesForAsgard constant (and merges them if two ever drop below half of this). As such, with 100 nodes, there would be 3 Asgard vaults, with 100 yggdrasil vaults. The system constantly checks which vault has the highest excess security, and instructs users to send funds there.
Managing Yggdrasil Funding
The state machine constantly monitors and tops up each yggdrasil outbound vault, limited to 25% of the value of its bond in assets. Thus if a node bonded $4m, then up to $1m in assets would arrive on its vault. These top up transactions are identified with yggdrasil+ memos.
When the node churns out, it automatically returns these assets back to Asgard with a yggdrasil- memo.
Not all assets are funded to yggrdrasil vaults since it would split the funding up far too much. Instead, all pools with a depth less than minimumDepthForYggdrasil keep their funds on Asgard vaults.
When the network churns, it creates new public keys and migrates the funds forward. The churning process is split up in 5 different transactions, 1 per asset (identified by migrate memo). It typically takes a few hours to complete. Users are instructed to only send funds to the newest vault, but the retiring vault is monitored. Once the last of the 5 migrations is complete, the previous vault is discarded and no longer monitored.
There are four key roles in the system:
Liquidity providers who add liquidity to pools and earn fees and rewards Swappers who use the liquidity to swap assets ad-hoc, paying fees Traders who monitor pools and rebalance continually, paying fees but with the intent to earn a profit. Node Operators who provide a bond and are paid to secure the system
LayerZero is an omnichain interoperability protocol designed for lightweight message passing across chains. LayerZero provides authentic and guaranteed message delivery with configurable trustlessness. LayerZero is the first trustless omnichain interoperability layer, and supports messaging directly between both Layer 1 and Layer 2 chains.
The key idea underpinning LayerZero is that if two independent entities corroborate the validity of a transaction (in this case, tA) then chain B can be sure that tA is valid:
An Oracle that provides the block header. A Relayer that provides the proof associated with the aforementioned transaction
LayerZero Endpoints: user-facing interface to LayerZero implemented as a series of onchain smart contracts. Oracle (can be Chainlink): third party service that provides a mechanism to, independently of the other LayerZero components, read a block header from one chain and send it to another chain. Relayer: an off-chain service that is similar in function to an Oracle, but instead of fetching block headers it fetches the proof for a specified transaction.
My concerns about LayerZero for Grindery project
An exchange built on LayerZero looks simplified when compared to classical DEX where an intermediate token and an intermediate chain are involved. LayerZero enables a clean and minimal single-transaction swap that does not include any intermediate tokens. The only condition is the independence between the Oracle and Relayer
In practice, the Oracle service is often performed by Chainlink. If this service is also used for the web2 part of the Grindery product, it can be consistent to use it also for the depay cross-chain exchanges in order to unify our stack.
The relayer can be implemented directly by the user of LayerZero that can render the service flexible.
LayerZero seeks to provide a solution to interoperability. It is an interoperability protocol that uses a novel technique to make it easier for different blockchain networks to connect with each other. Now, LayerZero joins that competitive environment aiming to go even further – to create a true ‘omnichain’ solution to serve as a base interoperability layer for the entire blockchain ecosystem. So, here’s how it aims to achieve that lofty ambition.
As known running smart contracts on Layer 1 chains can be cost prohibitive, especially as the amount of stored data increases. To make the LayerZero Endpoint practical, it was necessary for us to design the most lightweight client possible. Previous work on trustless cross-chain validation through crosschain state machine replication (SMR), such as Golden Gate], could cost millions of dollars per day to run on popular Layer 1 chains like Ethereum
To solve this problem, LayerZero design the most lightweight client possible. The key observation is that replicating and storing block headers within the client is not necessary. Rather, LayerZero delegate the task of fetching the necessary cross-chain headers and transaction proofs to off-chain entities: the Oracle and Relayer. This results in LayerZero Endpoints being incredibly lightweight, making them cost-effective even on notoriously expensive chains like Ethereum.
Looking at the details of how LayerZero implemented support for running LayerZero on
Ethereum Virtual Machines (EVMs). For the sake of brevity, LayerZero focuses on the aspects of the system whose implementation is likely to vary by chain and highlight how our implementation handles the specific requirements of the Ethereum chain. As mentioned in, the current version of LayerZero relies on Chainlink to provide the Oracle service, and expects users to use the Relayer service that we provide.
LayerZero packet : The format of the LayerZero packet will vary depending on the source and destination chains. There is a precise layout of the LayerZero packet for EVM endpoints. Each field functions as follows:
A unique identifier for each chain on the LayerZero network.
The address of the recipient smart
contract on the destination chain.
User Arg The payload sent by the
0 – N.
user application—in EVM this
can contain up to N-byte argument.
Sender-side chain transaction stability : Ensures the message transaction is stable on the source chain, LayerZero rely on the inherent properties of decentralized oracle networks, the Oracle will only notify the destination chain of a particular block header after it hears some number of block confirmations, which in the case of Ethereum is 15. Precisely speaking LayerZero protocol will only execute after the Oracle hears 15 block confirmations on chain A.
LayerZero Endpoint: We implement the LayerZero Endpoint as a series of smart contracts, composed of the four main modules.
For most existing blockchains, including the Ethereum blockchain, LayerZero are able to implement the Communicator , Validator , and Network each as separate smart contracts. However, this design does not preclude the implementation of LayerZero Endpoint on (future) chains with different requirements. The Library component of the LayerZero Endpoint is the key to providing support for the Ethereum blockchain in this case study. LayerZero implement a Library to handle the construction of the EVM-specific LayerZero packet and handle the encoding and decoding of EVM smart contract address information.
An additional responsibility of the Library is to handle the actual computation involved in validating the transaction proof. LayerZero EVM Library handles Merkle-Patricia Tree validation for transactions on an EVM block, which we base on an open-source implementation by Golden Gate.
Application built with LayerZero
Cross-chain decentralized exchange:
LayerZero enables a cross-chain DEX (cross-chain bridge) that deals exclusively in native assets. Contrary to existing DEX designs that issue wrapped tokens or go through intermediary sidechains, a DEX built using LayerZero to send messages between chains can be built such that liquidity pools exist on both chains, and users can simply deposit their native assets in one pool and withdraw native assets from another. LayerZero’s messaging primitive is powerful enough to enable direct bridges (1:1 pricing), automated market making (ab = k pricing), and any other derivation (such as one similar to Curve DAO pricing ). The guarantee of valid delivery that LayerZero provides enables a wide range of decentralized exchange applications.
Multi-chain yield aggregator: Current yield aggregators typically operate within the confines of single chain ecosystems, with projects such as Yearn Finance enabling yield aggregation using single chain
strategies. One key weakness of these single chain yield aggregation systems it that they cannot take advantage of any yield opportunities outside of their current ecosystem, potentially missing out on many of the best yields.
A yield aggregator that uses LayerZero for cross-chain transactions would allow for strategies that tap into the best opportunities across all ecosystems, increasing access to high yield opportunities and enabling users to take advantage of market inefficiency. A multi-chain yield aggregator would be strictly better than a singlechain yield aggregator, as in the worst case the strategy would degrade to taking advantages of opportunities on only one chain, and in the best case it would have exponentially more opportunities to choose from.
Multi-chain lending: Today, users have no easy way to take advantage of opportunities on chains where they do not hold assets. For example, suppose that a user with assets consolidated in ETH wants to take advantage of an opportunity on Polygon. Their choices are to either
move their entire asset base to another chain and convert it to the desired currency, lend their assets on Ethereum, borrow the desired asset, and then bridge that asset to the destination chain.
LayerZero enables a lending protocol that would allow the user to keep their entire asset base in-place on Ethereum, lend it out, then borrow directly in MATIC on Polygon. This eliminates intermediary costs such as bridge and swap fees.
These three examples represent but a tiny fraction of the many possibilities that LayerZero enables. By leveraging LayerZero, it enables developers to be able to write their applications without worrying about differing semantics between inter- and intra-chain transactions, and users will be able to freely move liquidity across chains.
We suggest the Axelar network as a way to connect the blockchain ecosystems and make it possible for applications to communicate freely between them. It is based on Cosmos SDK and Tendermint.
Collectively, validators manage the cross-chain request protocols and a byzantine consensus process. They are elected through a delegation process by the users. Validators receive voting power pro-rata according to the stake delegated to them.
Subsequently, the Axelar base layer is aware of the state of external blockchains at any point in time, creating the “incoming bridges” from other blockchains. Altogether, one can view the Axelar network as a decentralized cross chain read/write oracle.
Cross-Chain Gateway Protocol (CGP): this protocol is used to connect multiple autonomous blockchain ecosystems and is responsible for routing across them. Cross-Chain Transfer Protocol (CTP): this protocol is analogous to application-level protocols File Transfer, Hypertext Transfer Protocols on the Internet. Users can use the CTP protocol to interact with applications on any chain using simple API calls analogous to HTTP GET/POST requests.
Plug and play integration: it is needed to plug in any existing or new blockchain frictionlessly and to add new assets with minimal effort. No modifications are required to add a new blockchain. Cross-chain routing: Functions such as the discovery of network addresses, routing paths, and networks are at the core of the Internet and this must be addressed in the scope of cross-chain technologies. Upgradability support: The system needs to recognize updates, and minimal effort should be required to support them. The network must be made to be updated and improved easily. Uniform language for applications: Applications need a simple protocol to lock, unlock, transfer, and communicate with other applications no matter which chain they reside on.
Decentralized trust: The network and protocols must be decentralized, open, and allow everyone to participate fairly. High safety: The system must satisfy high safety guarantees. The system must preserve assets and the network during the cross-chain transfers. High liveness: The system must satisfy high liveness guarantees to support applications leveraging its cross-chain features.
Each of these objectives can be easily achieved on its own, but creating a network that can do all of them is difficult. Axelar appears to have overcome this obstacle, though.
Characteristic of the network
Open membership: any user should be able to become a validator Updates to membership: when a validator leaves the system honestly, their key needs to be revoked appropriately. Incentives and slashing: malicious validators should be identifiable and their actions must be identified and addressed by the protocol. Key-management: just as ordinary validators in any PoS system must carefully guard their keys. Threshold Key Generation. Handling Validator Membership Changes: the validator set needs to be rotated periodically to allow for new stakeholders to join the set. Threshold Key Generation and Signing in the Presence of Rotating Validators.
Maximum safety: Axelar sets the safety threshold to 90%, meaning that almost all validators will need to collude to withdraw any funds that are locked by its network or forge state proofs. Maximum Decentralization: since the network uses threshold signature schemes, the number of validators can be as large as possible. Robust Fall-back Mechanisms: to address any potential stall of the Axelar network itself, each threshold bridge account on a blockchain X that the Axelar validators collectively control has an “emergency unlock key” (this key acts as a fall-back). Maximum Decentralization of Fall-Back Mechanisms: this fall-back mechanism includes a secondary recovery set of users, in which just anyone can participate without any cost.
My concerns about Axelar for Grindery project
Via the CTP protocol, developers can lock, unlock, and transfer assets between any two addresses across any blockchain platforms, execute cross-chain application triggers and perform general cross-chain requests between apps across chains. Grindery projects can probably make use of these trigger possibilities.
The security techniques developed with robust fall-back mechanisms seem to be more adapted to large liquidity pools and large payments.
However, the system is similar to a decentralized Oracle with the protocol CTP which allows communication with applications via a simple API. I suppose that this system can be modulable and adjusted easily for the needs of the project.
Axelar network consists of a decentralized network which bridges blockchain ecosystems that speak different languages and a protocol suite with APIs on top, making it easy for applications to perform cross-chain requests. The network connects existing stand-alone blockchains such as Bitcoin, Stellar, Terra, Algorand, and interoperability hubs such as solutions like Cosmos, Avalanche, Ethereum, and Polkadot. The mission is to enable application developers to build such apps easier using a universal protocol and API without
rolling out their proprietary cross-chain protocols underneath or rewriting applications as new bridges are developed. Towards this, Axelar designed a protocol suite that includes Cross-Chain Gateway Protocol and Cross-Chain Transfer Protocol.
A core component of the network are the underlying decentralized protocols. Validators collectively maintain the Axelar network and run the nodes that secure the Axelar blockchain. They are elected through a delegation process by the users. Validators receive voting power pro-rata according to the stake delegated to them. The validators reach consensus on the state of multiple blockchains that the platform is connected to. The blockchain is responsible for maintaining and running the cross-chain routing and transfer protocols.
Governance rules allow network participants to enact protocol decisions such as which blockchains to bridge and which assets to support.
Axelar blockchain follows a Delegated Proof-of-Stake (DPoS) model similar to Cosmos Hub. Users elect validators who must bond their stake to participate in the consensus and maintain high-quality service. The DPoS model allows maintenance of large decentralized validator set and robust incentives to guarantee that the validators are responsible for maintaining bridges and shares of cryptographic threshold schemes. As part of consensus, validators run light-client software of other blockchains, allowing them to verify the state
of other blockchains. The validators report these states to the Axelar blockchain, and once enough of them report, the state of Bitcoin, Ethereum, and other chains is recorded on Axelar. Subsequently, the Axelar base layer is aware of the state of external blockchains at any point in time, creating the “incoming bridges” from other blockchains. The validators collectively maintain threshold signature accounts on other blockchains (e.g., 80% of validators must approve and co-sign any transaction
out of it), which allows them to lock and unlock assets and state across chains and to post state on other blockchains, the “outgoing bridges.” Altogether, one can view the Axelar network as a decentralized crosschain read/write oracle.
The remainder of the document describes preliminaries and building blocks behind the network, some technical details of the network (Section 5), cross-chain gateway protocol, and cross-chain transfer protocol.
Axelar is the universal overlay network, securely connecting all blockchain ecosystems, applications, assets and users to deliver Web3 interoperability. Axelar is composed of a decentralized network of validators, secure gateway contracts, uniform translation, routing architecture, and a suite of software development kits (SDKs) and application programming interfaces (APIs) to enable composability between blockchains. It allows developers to build on the best platform for their use case, while being able to access users, assets and applications in every other ecosystem. Instead of pairwise cross-chain bridges, they can rely on a network architecture that provides a uniform code base and governance structure.
Architecture Details and How it works:
The Axelar network has three key components across two functional layers.
A decentralized network
The first is the decentralized network itself, supported by a set of validators that are responsible for maintaining the network and executing transactions. The validators run the cross-chain gateway protocol, which is a multi-party cryptography overlay that sits on top of Layer1 blockchains. They are responsible for performing read and write operations to gateway smart contracts deployed on connected external chains, voting and attesting to events on those chains.
Gateway smart contracts
The second are the gateways smart contracts that provide the connectivity between the Axelar network and its interconnected Layer 1 blockchains. Validators monitor gateways for incoming transactions, which the validators READ. They then come to consensus on the validity of that transaction; once agreed, they WRITE to the destination chain’s gateway to execute the cross-chain transaction. The validators and gateways compose the core infrastructure layer.
Sitting on top of the validators and gateways are the APIs and SDKs (the libraries and tools that enable developers to access the Axelar network easily). This is the application-development layer that developers will use to compose across any two chains in a single hop, adding universal interoperability to their blockchains and applications. With Axelar, they can lock, unlock and transfer assets between any two addresses on any two blockchain platforms, execute cross-chain application triggers, and more generally handle any cross-chain requests.
The Axelar Network has four main interaction points:
The first is the SDK described above, which developers will use to integrate their Web3 applications.
The second is to run a node or validator, participating in the core underlying processes that secure the network, and validating cross-chain transactions. Validator setup documentation can be found here .
The third is to lead or support the integration of a new blockchain with the Axelar Network. With each new blockchain that connects to the Axelar network, the potential value that Axelar provides developers and end-users grows exponentially. At the time, adding new blockchains was not openly available as a function for Axelar network users.
The fourth is to use Axelar’s newly launched, decentralized cross-chain asset transfer application, Satellite. At the time of writing, Satellite supports transferring native Terra assets like Luna and UST between a set of both Ethereum Virtual Machine (EVM) and non-EVM blockchains: Avalanche, Ethereum, Fantom, Moonbeam, Polygon and Terra. Support for other networks and assets will roll out over the coming weeks and months. Satellite demonstrates the potential seamlessness to the end-user: users may exchange assets across previously siloed ecosystems, without any change in user interface.
The solutions developed by Multichain allow almost all blockchains to inter-operate. There is no restriction to Ethereum like chains (e.g. Binance Smart Chain), or different Layer 2 chains requiring finality to Ethereum (e.g. Polygon), or a network of Parachains (e.g. Moonbeam in the PolkaDot system), or Bitcoin types of chain (e.g. Litecoin), or COSMOS chains (e.g. Terra).
Every bridge connects two blockchains. The asset to be bridged is delivered to a unique SMPC wallet address on the asset origin chain, where it is safely stored (Decentralized Management Account). SMPC nodes operate independently of any blockchain and work together to sign transactions, however they always only have a portion of the key and must work in a group. On the destination chain, a smart contract mints tokens 1:1 with those held in the Decentralized Management Account and sends them to the user's wallet.
An asset is locked up in a MPC smart contract on the source chain and then a corresponding wrapped asset is minted on the target chain. The opposite also happens when tokens are sent to the smart contract; they are burned before being released on the origin chain by the SMPC nodes.
The Cross-Chain Router e nables any assets to be transferred between multiple chains, no matter if they are native or created with Multichain's Bridge.
Native assets: in this instance, Multichain cannot mint the asset, so instead liquidity pools are used. Bridge assets: there is no need for a liquidity pool for the asset, since Multichain controls the supply of the asset on the chain where the contract resides. Hybrid Native/Bridged Assets: it is the responsibility of the project team to ensure that there is sufficient liquidity in the pool for assets which are native on a chain, but the liquidity on chains for which Bridges exist is 'Unlimited'.
The cross-chain fee is 0.1%; The minimum cross-chain fee is equal to tokens worth $5(to ETH is around $80); The maximum cross-chain fee is equal to tokens worth $1000; The minimum cross-chain amount is equal to tokens worth $10 (to ETH is $90); The maximum cross-chain amount is equal to tokens worth $5M; Cross-chain amount larger than $1M could take up to 12 hours. Mainstream tokens(including stable-coins) bridge fee Cross-chain fee to none-ETH chains: $0.9-$1.9 per transaction; Cross-chain fee to ETH: 0.1% per transaction; minimum fees $40; maximum fees $1000. The minimum cross-chain amount is equal to tokens worth $12 (to ETH is $50); The maximum cross-chain amount is equal to tokens worth $20M; Cross-chain amount larger than $5M could take up to 12 hours.
My concerns about Multichain for Grindery project
Multichain offers an integration with a large number of blockchains (26) as it is an active protocol. This can offer more flexibility with partners and for future integrations on the Grindery side.
The cross-chain amounts that must be transmitted and the related fees are designed for massive payment structures rather than micropayments.
Multichain is a Router for web3. It is an infrastructure developed for arbitrary cross-chain interactions.
The SMPC Network
The Multichain network comprises what are called SMPC nodes. They exist separately from any blockchain and collectively sign transactions, but a group of them must do so together and they each only ever know part of the key to make this happen. The SMPC nodes are run by different organisations, institutions and individuals and they are incentivized to perform their functions properly.
Multichain is its Secure Multi Party Computation (SMPC) Multichain network of nodes, which implements with the TSS Distributed Key Generation algorithm. This code has been completely and freshly written by Multichain's engineers and is optimised for multichain applications. Each node in a set, selected from the network, works independently from the others to generate part of the private key responsible for signing transactions. They collectively sign transactions, but crucially they cannot individually do so and the key is not reconstructed when signing. The complete key is never assembled and so it cannot be intercepted. This is accomplished by several rounds of communication between the t+1 nodes. If one sends a bad message, then it is important that this node can be recognised, otherwise there is the possibility of a Dedicated Denial of Service Attack. GG20 solves this using an elegant property of the ECDSA algorithm, so that R, the part of the signature from a node can be used to query whether it was at fault (the 'bad actor'). Other features present in GG20 that increase efficiency are the ability to have Asynchronous Approval, where a large number of signatures can be pre-computed, calculating the R factor in the ECDSA signatures, before they are needed. This encompasses most of the computation and communication, with only the final round of communication necessary to actually sign the message, with all t nodes online at this stage. This means that for the bulk of the work, there is no longer the need for all nodes to be online simultaneously, with the implication that some network latency can be accommodated.
The SMPC network is responsible for signing transactions on each supported blockchain to perform a multitude of tasks comprising the management of asset accounts and smart contracts. A Threshold, will be needed to sign the transaction. This Threshold Signature (TSS) is denoted as (t, n), such as (9,15), (15,21), (21,31) etc., where t is the number of nodes needed to sign, and n is the total number of nodes in the set.
The nodes are run by different organizations, institutions and individuals, which independently run Multichain's protocol. The end result is a decentralized and trustless service. Multichains's code is completely open source, which is a prerequisite of any system that describes itself as being decentralized. There is an inevitable trade-off between security and performance as the total number nodes and the threshold are changed. For the security of the system to be broken, t TSS nodes would have to collude to assemble the private key, but as t increases, this eventuality becomes vanishingly rare and this has not happened despite the length of time the network has been running and the huge TVL and daily volume that exists today on Multichain's network. Another possible security flaw rests on each blockchain itself. It is necessary to wait for a sufficient number of confirmations before finality can be agreed upon and so that any short lived forks cannot result in a double spend. These are the issues that ultimately limit the potential speed of cross-chain transactions.
The Multichain Services
There are some different services that use the SMPC network
Bridge: An asset is locked up in a MPC smart contract on the source chain and then a corresponding wrapped asset is minted on the target chain. The reverse process (called Redeeming) sees the wrapped asset being burned and then the asset in smart contract being released back to the chain from where it originally came from. A bridge can therefore only ever operate between two blockchains. There are now more than 600 bridged assets and it is easy to deploy new ones, a process that takes about 2 weeks, which we can perform upon request and is free.
For many projects, Multichain custodial bridges are still the best solution, since they do not require liquidity on each chain. They remain alongside Multichain other methods of crosschain transfer. They are most useful when projects are launching straightforward ERC20 like tokens on new chains where they do not already have tokens. Several two way bridges can be deployed for each token.
Router: Multichain launched its Multichain router V3 beta mainnet. The Router has these significant features:
It can allow assets transfers between any two or more chains.
It can work with pre-existing assets on blockchains, by using liquidity pools for those assets.
It can also work with Bridged assets smart contract, where Multichain is responsible for minting assets on chains. This allows a generalization of Bridges, so that assets are not restricted to having to return to their source chain before being sent to another chain. This makes for a cost effective solution for users, especially if the asset originated on Ethereum. The Router can include both native and Bridged assets. This allows inclusion of assets that might have been generated with a third party bridge (though we would need to understand what bridges were originally used).
anyCall Crosschain Contract Calls: With the anyCall smart contract function, projects can now make cross-chain contract calls, all with the security of Multichain's MPC network. Crosschain NFT Bridges and Router: Multichain now offers a bridge for NFT's (both ERC721 and ERC1155 smart contract standards). We also now have a Router for NFT's.
Cross-Chain Interoperability Protocol (CCIP) for Decentralized Inter-Chain Messaging and Token Movements
Cross-Chain Interoperability Protocol (CCIP) is a new open-source standard for cross-chain communication. CCIP aims to establish a universal connection between hundreds of blockchain networks, both private and public, unlocking isolated tokens and empowering cross-chain applications for all on-chain ecosystems.
CCIP provides smart contract developers a generalized, compute-enabled infrastructure for transferring data and smart contract commands across blockchain networks. CCIP will underpin a variety of cross-chain services, such as the Chainlink Programmable Token Bridge, which will empower users to move their tokens across any blockchain network in a highly secure, scalable, and cost-efficient manner.
Architecture Details and How it works:
Building secure and efficient cross-chain technology for both token movements and generalized messaging across all blockchain networks is not a simple task. However, the historical reliability of Chainlink’s existing infrastructure, alongside a growing Chainlink ecosystem and specific cross-chain technological innovations makes Chainlink the most well-suited protocol to be an open-source standard for cross-chain communication.
Decentralized Network of Proven Node Operators
Cross-chain bridges at their most basic level are a committee of nodes that collectively attest to information on one chain and relay it to another by cryptographically signing transactions in a threshold manner. The Chainlink Network is already supported by the largest collection of independent, Sybil-resistant, and provably reliable node operators in the industry, made up of some of the top DevOps and infrastructure providers in the world. Chainlink’s growing network of node operators secures over $30B+ for smart contract ecosystems through numerous oracle services and will further scale in size via a coming upgrade to Chainlink’s Off-Chain Reporting protocol (OCR).
Chainlink OCR 1.0 is a secure and efficient off-chain computation protocol for data aggregation that has operated at scale for an extended period of time without fail, successfully lowering on-chain gas costs of oracle reports by up to 90%. OCR 2.0 will expand upon this success by enabling even more efficient and expressive off-chain computations that give rise to advanced cross-chain capabilities. CCIP will leverage OCR 2.0 within its protocol stack to scale the number of nodes that sign committee-based reports into the hundreds, leading to increased security of locked funds while maintaining a high degree of cost-efficiency for users. Combining the world’s largest pool of secure node operators with upgraded off-chain computation capabilities, CCIP will achieve both a high degree of tamper resistance and performance.
Security and fraud prevention are foundational elements for cross-chain services aiming to directly secure high-value contracts. To that end, CCIP will include a newly invented risk management system never before seen in the blockchain industry called the Anti-Fraud Network. The Anti-Fraud Network will consist of decentralized oracle networks with the sole purpose of monitoring CCIP services for malicious activity that could lead to financial loss. Importantly, the Anti-Fraud Network will contain fully independent committees of nodes compared to the node committees they are responsible for monitoring on CCIP, completely separating anti-fraud detection and cross-chain services.
The Anti-Fraud Network acts as a verification layer and will periodically submit heartbeat checks when the system is operating as normal. If the Anti-Fraud Network’s heartbeat messages stop or its nodes notice any nefarious activity, an emergency shutdown is automatically triggered to stop a particular cross-chain service. The pause allows user funds to be protected against a potential black swan event affecting the service. While the Anti-Fraud Network will initially consist of high-quality Chainlink nodes independent of the CCIP services they protect, dApps securing a large amount of value through a CCIP service can join the Anti-Fraud Network to provide their users with greater guarantees that any fraudulent activity will be caught and mitigated.
The Anti-Fraud Network is a decentralized implementation of risk management and anti-fraud detection commonly used when securing high-value contracts. The Anti-Fraud Network revolutionizes how risk is managed in cross-chain infrastructure by establishing a checks and balances system that separates responsibilities and minimizes the control any single group has over the operation of CCIP services. Importantly, the network can also scale and evolve into the future through additions like AI for enhanced detection techniques.
Large Ecosystem Support Across Blockchains
Cross-chain systems are most useful when they have large network effects. Network effects lead to increased security of user funds, increased token access and a simplified user experience, better documentation and tooling for developers, and greater revenue opportunities for token provisioning no matter which blockchain an asset is natively launched on. With over a hundred blockchains working with Chainlink and many blockchains and layer-2 solutions already integrated with Chainlink on mainnet, Chainlink is the ideal infrastructure to serve as a credibly neutral protocol for cross-chain communication between all blockchains.
On top of being the most widely integrated oracle solution by top blockchains, Chainlink powers a large number of dApps running across these blockchains. Chainlink already works with the top lending, insurance, and other DeFi protocols and is accelerating adoption within supported chains through open-source development and the Chainlink Community Grant Program. Numerous blockchain partners and applications have already expressed a desire to use Chainlink oracles for cross-chain activities, making it a top priority to bring the entire smart contract industry a highly secure, reliable, and performant set of generalized cross-chain solutions.
Defining the Cross-Chain Tech Stack
The Cross-Chain Interoperability Protocol (CCIP) sits within a layered open-source technology stack that will be leveraged to provide users with new cross-chain services, such as the Chainlink Programmable Token Bridge, various other bridge implementations, and the ability to create powerful cross-chain applications that span any blockchain network. Each layer of the tech stack provides a key role in ultimately supporting the expanding multi-chain ecosystem.
At the top of the technology stack are the interfaces that enable users to connect to the Chainlink Programmable Token Bridge or other bridge implementations and begin moving their tokens across blockchain environments. Importantly, new and existing ecosystem projects can deploy their own interface in a permissionless manner. This can include established wallets, aggregators, applications, exchanges, and a wide range of user-facing services wanting to provide a gateway to the multi-chain ecosystem. By taking a community-driven approach to the interface layer, cross-chain infrastructure can become easily accessible, censorship-resistant, and innovative in terms of how users interact with solutions built upon the CCIP.
Programmable Token Bridge
The Programmable Token Bridge is a reference bridge implementation built upon the CCIP that allows developers to build cross-chain applications that seamlessly and securely move their existing tokens across any blockchain. It’s a unified bridge system, where various bridge connections between chains are secured by unique committees of nodes in order to distribute security while maintaining universal interoperability using routing contracts. The Programmable Token Bridge will support existing token standards, meaning already liquid assets can be instantly used within different smart contract ecosystems. On top of employing high-quality node operators and decentralized architecture, additional safety precautions will be implemented, such as time-based flow limits to minimize downside risk during black swan events—the parameters of which can be managed by much larger DONs.
The Programmable Token Bridge is compute-enabled, empowering users and smart contracts to send not only their tokens but also commands to the bridge and have it run customized logic around how it interacts with other blockchains. Users don’t need to know how to use other blockchains—they just need to send instructions to the bridge on how they want to interact with other chains, and the bridge will automatically move the tokens cross-chain and deploy them in smart contracts on the destination chain within an atomic transaction. Thus, a user can stay on their blockchain of choice while still benefiting from smart contract ecosystems on other blockchain networks. The Programmable Token Bridge opens up advanced hybrid smart contract use cases like cross-chain yield aggregators, collateralized loans, and much more. Importantly, the Programmable Token Bridge is just one reference implementation built by Chainlink Labs, but any third-party bridge application can be easily built by independent development teams wanting to take advantage of the security and functionality of CCIP.
Cross-Chain Interoperability Protocol (CCIP)
CCIP is an open-source standard that enables smart contracts on any blockchain to send and receive data packets to and from smart contracts on any other blockchain network. The protocol is generalized in nature, supporting the delivery of any type of data that a smart contract may want to deliver across chains. Generalized cross-chain interoperability will give developers a simple framework to build cross-chain applications without dealing with the complexity of the underlying protocols.
All applications built on top of CCIP like the Programmable Token Bridge, other cross-chain bridges, and cross-chain dApps can tap into the security of the Anti-Fraud Network in order to automate detection and mitigation of nefarious activity. We are also exploring defense-in-depth approaches that can be deployed in the future such as trusted execution environments, hardware security modules for key management, crypto-economic security through staking, and more.
Chainlink’s cross-chain tech stack will be powered by decentralized networks of independent, highly reputable oracle node operators. Chainlink nodes will run the OCR 2.0 client to securely and cost-efficiently reach consensus off-chain on cross-chain transactions. OCR 2.0 removes any single point of failure and supports the ability to scale to hundreds of independent node operators without meaningfully increasing on-chain gas costs. Importantly, the report will contain a signature of every oracle node that responded, creating accountability and providing a trail that can be used to implement trust-minimization techniques.
Resume and conclusions
Router protocol: interesting but seems not mature enough to support many blockchains and involve a third party protocol. Celer protocol: made for large transfers and too complex for our use case. Synapse protocol: stableswap pool to equilibrate the supplied assets induces fees that are not necessary for our use case. Axelar: centralized security protocol with robust fall-back mechanisms that seem to be more suited for big liquidity pools than for micropayment structures. Multichain: made for large transfers. Thorchain: inherent scalability limitations, cumbersome intermediate currency, and heavyweight protocol.
➜ Utilizing technologies like LayerZero or the Map Protocol or Multichain seems quite appealing for simplicity and modularity perspectives. Drawing brief theoretical diagrams, in my opinion, can be quite helpful in understanding how these strategies can be incorporated into the Grindery depay project. We may gain some insights and ideas about our implementation strategy from this. Here is what I suggest doing before starting to code. Do not hesitate to give me your opinion if you agree/ disagree.
I suggest using Miro (or another tool to create some architecture diagrams: I'm not sure what your preferred tool is, and I have no preferences in the matter) to sketch with:
An architecture scheme of the simplest solution without any existing bridging technique (as discussed this week). An architecture scheme with our solution coupled with the Map Protocol. An architecture scheme with our solution coupled with the LayerZero.
I think that we will beneficiate from this work in order to:
Ask ourselves the good question before writing lines of code. Compare the existing solutions with a bootstrapped one. Discuss around clear diagrams to clarify everything and to define altogether the architecture to be coded.
Discussion around protocols applied to the Grindery use case
Utilizing a basic Oracle between networks to allow the exchange of gas tokens between various chains is the simplest way to achieve the depay goal of permitting micropayments between distinct blockchains. Following a gas token payment on any blockchain, it is feasible to feed a central account using this straightforward method that provides access to real-world data such as asset prices. In this instance, the Oracle is utilized to collect the most recent pricing information for an asset and link it to a specific Grindery smart contract on the central chain. Moreover, it is also used to verify that transactions have been correctly executed on each blockchain, involving the block headers and the proof of the transactions.
The use of any application in this context results in a request for funds on the Grindery user account of the central chain, which is there to supply gas tokens for the workflows on the Grindery Nexus network.
Benefits/risks of using a simple Oracle system:
Fully configurable and maintainable by our own. Security risks of using just an Oracle (risks for a malicious user to penetrate our network of blockchains via the Oracle). Due to the large number of micropayments in our network, it may be challenging and take some time to identify this type of fraud.
Benefits/risks of using Map Protocol:
Using Light-client to conduct cross-chain verification is the ultimate security mechanism (Map Protocol, Cosmos, Polkadot) . Cross-chain transactions between heterogeneous chains may utilize a substantial amount of gas fees due to the Light-client verification process. It is advisable to use a relay chain that is compatible with multiple chains' algorithms in order to enable a homogenous cross-chain and build the ultimate cross-chain verification network. This is the approach chosen by Map Protocol with its central Map Relay Chain. A fully decentralized MAP chain backed by consensus and immutability to safeguard the assets in transition. Complete dApp development service toolkits. A cross-chain operation requires multiple verification and building proof procedures due to the light clients deployed on each blockchain and on the central Map relay chain, which can make the process rather inefficient for small transactions that need to be carried out quickly and frequently.
Benefits/risks of using LayerZero:
The increased security provided by the usage of an Oracle-Relayer pair is one of the key benefits of the LayerZero approach over a straightforward Oracle solution. The Relayer does in fact add an additional layer of protection. Both the Oracle and its related Relayer must be hacked for a malicious operation to take place. It means that the worst-case security of this new network still reduces to being as secure as the oracle. If Chainlink is used as an oracle, any malicious action in the system is still predicated on first being able to defeat the Chainlink Decentralized Oracle Network (no easy task). Even if the Oracle’s consensus is corrupted, it also requires that the Relayer is actively colluding. For instance, in the most extreme case where the Oracle A’s consensus is corrupted and the Relayer A is colluding, there is a risk only for User Applications accepting messages from Oracle A and Relayer A. All User Applications using Relayer B-Z, running their own Relayer, or using Oracle B-Z remain completely unaffected. The LayerZero protocol offers a good combination between extremely high security and cost-effectiveness by the use of Ultra Light Nodes (ULN , providing the security of a light node with the cost-effectiveness of middle chains). This is accomplished by carrying out the same validation as an on-chain light node, but block headers are streamed on demand by decentralized oracles rather than being kept sequentially. No custodian, middle-chain bridge, or intermediate transactions without compromising on decentralization, transparency and immutability . LayerZero is a simple protocol which does not involve complex intermediate chains/smart contracts when compared to the Map Protocol that provides a higher level of security but it is also more difficult to program and to maintain . The requirement of independence between the relayer and the oracle instead of trust is one aspect of what allows LayerZero to be efficient and lightweight . This very light protocol is probably well suited to handle micro-payments quickly and efficiently.