Built on Chainlink CCIP
Since the advent of smart contract blockchains in 2014 - blockchain researchers and developers have been working towards solving a few fundamental issues with the design of blockchain networks. One of those key problems is scalability - the blockchain design (as it exists today) must verify and store all transactions ever processed on it. This makes sense for large transactions between big accounts, but - if we're going to make blockchain the default financial backbone - there is no sense to employ the same security and finality for a person buying a cup of coffee and an insurance company paying out a multi-million insurance claim.
Currently, the most popular approach for solving this is to create multiple, independent blockchain networks (called many names - L2s, rollups, appchains, parachains, ...) which process transactions with differing speed, security and finality guarantees. This approach is employed by most major blockchain projects - from Ethereum with rollups, Polkadot with parachains, Avalanche with subnets, Cosmos with their "Internet of Blockchains", etc...
While there are still technical challenges in implementing these systems on a mainstream, commercial basis - the future of blockchain development is clear - many, independed AppChains & L2s, processing their own transactions and settling periodically on a few robust, battle-tested L1s.
Developing production blockchain solutions as a series of smaller networks, however, comes with its own set of challenges. A notable change is that - having multiple independent networks breaks composability and atomicity - two key aspects of blockchain networks today and the backbone of the interesting solutions in DeFi & NFT spaces. Let's define our terms:
- Composability - The ability of one end user account or smart contract to interact with any other smart contract deployed on the network(s). Additionalliy, the ability to chain the interactions between multiple smart contracts and use the result of one operation as the input for the next operation.
- Atomicity - The guarantee that, in a chain of operations, either all of them succeed or none of them do. Meaning - a protection from partial execution.
A protocol which solves cross-chain composability and atomicity would truly enable the "Internet of Blockchains" or "Internet of Smart Contracts" to scale and reach mainstream adoption.
Lately, there has been a lot of progress in cross-chain communication protocols and standards - with notable examples such as Chainlink CCIP, Connext or Layer Zero. These communication protocols enable blockchains to share messages and execute remotely execute actions across different blockchain networks.
In this paper, we are going to present Klaster - a middleware protocol positioned between smart contracts and cross-chain communication solutions, enabling a seamless, developer-friendly & standardized way for all Web3 apps to adapt to the cross-chain future.
Borrowing from networking terminology, we'll define the term Blokchain Clustering - Making multiple, independent blockchain networks & multiple cross-chain communication solutions act as a single virtual blockchain network with preserved atomicity and composability.
Klaster is not a cross-chain communication protocol. Klaster is a standardized interface which abstracts away cross-chain communication protocols from smart contract developers. It enables easy conversion of exsiting DeFi, NFT & payment apps into cross-chain native apps and drastically reduces the time needed to develop new cross-chain applications. The V1 of Klaster will have all of its cross-chain communication handled by ChainLink CCIP. Klaster is a set of smart contracts, deployed on all compatible blockchain networks, which drastically reduce integration time of new and existing DeFi apps into cross-chain protocols, such as CCIP.
It achieves this through the creation of several standards:
-
Two Way Handshake RTC - Remote Transaction Calls - a standardized, composable way to call a function on an EVM smart contract from one blockchain network to another. The point of the two-way handshake is to preserve atomicity and enable multi-chain transaction hops (e.g. Swap tokens on Uniswap on Optimism and then supply the LP tokens to Curve on Polygon and then put those crv tokens into mainnet Yearn). With Klaster two-way handshake, the developers can be assured that either all actions in the chain succeeed or none of them do - enabling easy creation of cross-chain DeFi strategies.
-
Native Multichain Assets - Extensions of ERC20 and ERC721 standards, which make them cross-chain compatible.
-
Native Multichain ERC20 - An ERC20 token which has the same address on all deployed blockchain networks and has its supply shared between multiple blockchain networks through secure cross-chain communication solution.
-
Native Multichain ERC721 - An NFT which has the same address on all deployed blockchain networks and has its items shared between multiple blockchain networks through secure cross-chain communication solution.
-
-
dApp Adapters - Smart contracts which handle the additional logic required by
Klaster RTCto perform cross-chain blockchain transactions. They are generally lightweight wrappers around existing dApps or built-into solutions which are cross-chain since inception.
The Klaster protocol is implemented as a singleton contract on every supported chain. This singleton contract is tasked with creating, sending and receiving Remote Transaction Call (RTC) messages. Each RTC message contains the data needed to execute the transaction on the destination chain. The RTC messages are forwarded to the singleton contract on the destination chain, which then executes the action.
Klaster system works best when paired with MultiChain Asset standard contracts. So far, we have developed the standards for multichain ERC20 and ERC721 assets, but a MultiChainAssetAdapter can be built for any other type of asset.
ERC20MultiChainAssetAdapter and ERC721MultiChainAssetAdapter both support wrapping of regular ERC20 and ERC721 assets, making the Klaster system immediately adaptable for DeFi, without changing the implementation of blockchain apps (e.g. regular Uniswap or regular AAVE would work just fine).
RTC Message Structure
---
- Destination Chain ID: Number
- Remote Execution Call Data: RTCCallDataObject[]
RTCCallDataObject:
Destination Contract Address: string
EVM Call Data
MultiChainAssetAdapter Type: string (e.g. 'ERC20')
MultiChainAsset Address: string
Adapter Params: Object (e.g. for ERC20 - tokens used, approval amount, apporval recipients)
Let's explore the flow of a Remote Transaction Call as outlined in the diagram above. We will be swapping on Uniswap. Our assets are on Avalanche, but we want to swap on Optimism.
A user interacts with a frontend and calls the rtc function on the source chain singleton contract with the RTC message as the paramters. Our RTC message would look like this:
{
"destChainID":10,
"rtcCallData":{
"contract":"0xUniPoolAddressOnOptimsim",
"callData":"Encoded call data. Call function swap",
"mcAssetAdapterType":"ERC20",
"mcAssetAdapterParams":{
"tokensUsed":2000000000000000000,
"approvals":[
{
"amount":2000000000000000000,
"beneficiary":"0xUniPoolAddressOnOptimism"
}
]
}
}
}We encode this and pass it on into the rtc function on the Klaster singleton contract.
Klaster singleton contract will receive the message, fetch the logic for the MultiChainAssetAdapterType (if specified) and choose the cross-chain communication solution to be used for the sending of the message.
The selection of the cross-chain communication solution is a work-in-progress. The V1 of the Klaster protocol will have Chainlink CCIP as it's only provider, so for V1 - this step means selecting CCIP and encoding the message.
For each way of communication, there is an expiry period which is attached to the message. After the expiry period has passed, the destination chain singleton will reject the message (if it comes through the communication channel).
After commiting the message, the source chain singleton will wait for the ACK or NACK signals from the destination chain. ACK signal means the action was sucessfully completed on the destination chain, while the NACK signal means that the message was reverted on the destination chain.
If a period of 3 * expiry has passed and no ACK or NACK message has been received, the source chain will consider the action a failure. Since the destination chain contract must check the expiry variable before performing the action, the source chain can safely revert any changes made (e.g. tokens reserved) when 3 * expiry (one expiry for message from source to destination, one expiry for message from destination back to source and one expiry of buffer) has passed.
The expiry times for each chain should be considered at average finality time, with the extra expiry holding period serving as a buffer for deviations in finality time. If abberant finality tiems are observed on source or destination chains, the system will automatically revert all actions, since the ACK singnal will take too long to propagate.
The singleton will assingn each sent message a UUID and a status! The status of the message can be PENDING | ACK | NACK | EXPIRED - depending on the situations explained above.
Request RTC execution. The cross-chain communication provider will call the rtc function on the destination chain singleton contract. The contract will then execute the desired function on the desination chain and (if the function was successfull) it will call the rtcAck function back to the source chain.
The singleton contract will usually interact with MultichainAdapter contracts which wrap around existing DeFi and NFT apps and perform some additional logic. An example would be a UniswapMultichainAdapter contract, which would be able to wrap the LP tokens into MultiChainERC20 tokens and send them back to the source chain.
If the function was a sucess, the MultichainAdapter contract will perform all the necessary actions and send the ACK signal back to the source chain through the cross-chain communication provider (e.g. CCIP). The ACK signal can have additional actions appended to it! E.g. - the ACK for the Uniswap swap function will come with wrapped LP tokens. If the function reverts - the singleton will send the NACK back to the source chain.
The source chain singleton will receive the ACK or NACK and set the status of the RTC message accordingly. In the case of NACK, it will revert any changes made in the first step.
The singleton will emit an event that the frontend can pick up, to notify the user that the process was a success.