PepeTeam’s solution to the issue of cross-chain interaction is based on a network of smart contracts and program modules.
For years, one of the acutest issues facing the blockchain space has been cross-chain interaction. On different blockchains, different assets are used, like WAVES on Waves, ETH and USDT (ERC-20) on Ethereum or BNB and USDT (BEP-20) BNB Chain.
However, users need to be able to transfer their assets between these networks in a secure and transparent way, avoiding situations when transfers can’t go through due to insufficient liquidity. Similarly, users would like to collect incomes from their tokens, regardless of the network they were originally issued on.
Building a transparent and decentralized cross-chain interaction protocol
This issue can be solved by building a transparent and decentralized protocol for cross-chain interaction that will facilitate cost-efficient and secure liquidity movements between blockchains, ruling out liquidity fragmentation.
A protocol of that kind would have to satisfy a set of requirements:
- open-source code contracts;
- a high degree of security and reliability of used cryptographic means;
- low fees;
- transparency and a possibility to audit;
- decentralized protocol governance via a DAO;
- the use of smart contracts to govern business logic and guarantees of its immutability;
- system scalability;
- integration of the protocol with other products (AMM, lending protocols, DEXes etc.);
- minimization and decentralization of backend services.
Cross-chain interaction protocol: operation
The proposed protocol for cross-chain interaction is a set of smart contracts (the transport layer is built in the Ride language, periphery contracts are implemented on smart contracts or scripts of the target platform) and program modules that are required for organizing cross-platform interaction (Witness, Signer etc.).
The operation of a protocol of that kind is best explained using a simple example.
Let’s assume a user needs to transfer USDT (ERC-20) tokens from Ethereum to BNB Chain. For that purpose, the tokens the user needs to transfer will be locked on Ethereum and issued in a “wrapped” form on BNB Chain. The wrapped tokens will represent an obligation for the user to receive the equivalent BEP-20 assets on BNB Chain. In a transfer back to Ethereum, the wrapped tokens on BNB Chain will be burned, and the original tokens on Ethereum will be unlocked.
The main advantage of this system is its verifiability. Any user can make sure that the amount of wrapped tokens in the target network is the same as the amount of “real” tokens locked in the original network.
Besides, a noticeable advantage is the fact that smart contracts have an open-source code and will be governed through a DAO, while operation of program modules (Witness-proxy, Relayer) could be run by anyone.
When it comes to implementing the protocol, the main task is building a mechanism for cross-chain interaction based on a network of smart contracts. Since invoking a smart contract in one blockchain from another blockchain is impossible, oracles will have to be used.
One group of oracles will be tracking invocations of a smart contract in one blockchain, processing information attached to a call and transferring it to the other blockchain. Another group of oracles will be responsible for verifying and validating that information.
Caller invokes a transaction completion event that Witness-proxy receives.
Executor executes an invocation that either creates new wrapped tokens or unlocks original tokens.
Witness-proxy (off-chain component) acknowledges an event invoked by Caller and transfers its data to the target blockchain.
Witness (off-chain component) checks the correctness of information transferred by Witness-proxy and receives a reward in a utility token after successful confirmation of the event.
Signer (off-chain component) is an element of the program module group used to validate information about an executed transaction with its part of the signature after it has been confirmed by several Witnesses.
Once a quorum of signatures has been achieved, all of them will be written to the blockchain (the transport blockchain is Waves). The event will be published in the Witness smart contract where confirmation information is also stored. In the Signer smart contract, signatures for confirming early events will be published.
The Relayer component (off-chain) can invoke Executor for a user and collect a fee for that. Alternatively, users can do that by themselves.
Component interaction scheme
Contract А, invoked by someone, invokes another contract with specific parameters in the initial blockchain. Witness-proxy transfers function call data to the target blockchain. Subsequently, several Witnesses confirm or deny the existence of contract A invocation. If it is confirmed, Signer participants validate the existence of contract A invocation with a single signature in the Signer smart contract.
Subsequently, a user or Relayer invokes Executor, which issues a specified amount of the wrapped token and sends it to the receiver. Then, the bridge smart contract comes into play, issuing a specified amount of the wrapped token. Alternatively, the wrapped token is burned and the “real” token is unlocked in the original network.
This idea is based on striving to achieve the invocation of a smart contract by a protocol in another blockchain.
Meanwhile, for a user, the interface will have a very simple look. Just like for token swaps, there will be the fields ‘You Send’ and ‘You Receive,’ as well as several fees: a transaction fee, a Relayer fee and a protocol fee.
Overall, the proposed solution represents quite an innovative approach that aims to achieve transparency and full decentralization. A long-term goal is the creation of a system that will be honestly governed by users and liquidity providers who will have opportunities to collect income from their interaction with the proposed system.