Please describe your proposed solution
State of the Problem
Blockchains are closed systems by design. Security reasons back that decision. But users don’t care, they want to have a seamless experience abstracting Blockchain compatibility issues and technical restrictions. This lack of interoperability results in slower innovation and is holding back the progress and mass adoption of Web3.
Blockchain interoperability protocols are important for the Web3 ecosystem and traditional systems that need to interact with different blockchains. These protocols are the foundation for building blockchain abstraction layers, allowing traditional backends and dApps to interact with any blockchain network through a single middleware solution. Without a blockchain interoperability protocol, Web2 systems and dApps would need to build separate in-house implementations for each cross-chain interaction that they want to use, which is a time-consuming, resource-intensive, and complex process.
Blockchain interoperability protocols provide the following capabilities:
You can transfer assets and information across multiple blockchains.
Application developers can leverage the strengths and benefits of different chains.
Collaboration between developers from diverse blockchain ecosystems enables the building of cross-chain applications to serve more users and provide additional features or products for them.
What is CCIP?
CCIP provides a single interface through which dApps and web3 entrepreneurs can securely meet all their cross-chain needs. You can use CCIP to transfer data, tokens, or both data and tokens across chains.
CCIP supports three main capabilities:
- Arbitrary Messaging is the ability to send arbitrary data (encoded as bytes) to a receiving smart contract on a different blockchain. The developer is free to encode any data they wish to send. Typically, developers use arbitrary messaging to trigger an informed action on the receiving smart contract, such as rebalancing an index, minting a specific NFT, or calling an arbitrary function with the sent data as custom parameters. Developers can encode multiple instructions in a single message, enabling them to orchestrate complex, multi-step, multi-chain tasks.
- Token Transfer: You can transfer tokens to a smart contract or directly to an EOA (Externally Owned Account) on a different blockchain.
- Programmable Token Transfer is the ability to simultaneously transfer tokens and arbitrary data (encoded as bytes) within a single transaction. This mechanism allows users to transfer tokens and send instructions on what to do with those tokens. For example, a user could transfer tokens to a lending protocol with instructions to leverage those tokens as collateral for a loan, borrowing another asset to be sent back to the user.
Some of these use cases are DeFi composability (e.i: Cross-Chain Liquidation Protection), Cross-Chain name services, Cross-Chain NFTs minting, Gaming, and any other circumstances where users from one chain want to act on another chain.
Solution
We propose a hybrid on-chain/off-chain solution to enable cross-chain messaging on the Cardano network. This solution aims to facilitate seamless communication between Cardano and other blockchain networks, allowing for efficient token transfers and other cross-chain operations.
Solution Architecture Overview
On-Chain Components
a. Master Incoming Contract: Receives messages destined for the Cardano network.
b. Master Outgoing Contract: Sends messages to other networks.
c. Project Configuration Contract: Stores project-specific configurations as UTXOs, each identified by a unique NFT token.
These contracts serve as storage centers for messages and project configurations, allowing the off-chain module to detect changes and perform corresponding actions.
Off-Chain Components
a. Message Processing Module: Handles message processing and creates corresponding transactions for both incoming and outgoing messages based on the project configurations stored in the Project Configuration Contract.
b. Project Configuration Info: Each project or use case will have a unique UTXO with configuration info that defines the logic for creating specific transactions based on the received messages.
Messaging Flow
Outgoing Messages from Cardano:
- Users create a transaction that generates a new UTXO in the Master Outgoing Contract, specifying the source address using the unique NFT token of the target project.
- The Message Processing Module detects the change, retrieves the corresponding project configuration from the Project Configuration Contract, and processes the message accordingly.
- If required, the module creates a transaction on the Cardano network before sending the message to the destination network (e.g., burning tokens for a Burn and Mint scenario).
Incoming Messages to Cardano:
- Messages from other networks are sent using the channels provided by existing cross-chain protocols, creating an entry in the Master Incoming Contract, specifying the destination address using the unique NFT token of the source project.
- The Message Processing Module detects the change, retrieves the corresponding project configuration from the Project Configuration Contract, and processes the message accordingly.
- The module creates a transaction on the Cardano network based on the message (e.g., minting tokens for a Burn and Mint scenario).
Off-Chain Infrastructure
The Message Processing Module will be part of the off-chain infrastructure maintained by the existing cross-chain protocols. This infrastructure is typically supported by a network of nodes and validators, ensuring a decentralized solution if the module's logic is integrated into these nodes.
Transaction Creation Complexities:
- UTXO System: Cardano's deterministic and specific UTXO system requires careful handling when creating transactions. The off-chain module will construct specific transactions based on the project configuration values and the message being processed.
- If the transaction needs to consume UTXOs from a Cardano wallet, the private key must be encrypted using an internal system public key and attached to the message. The off-chain module will decrypt the private key using the corresponding internal private key and use it to sign the created transaction.
- If the transaction needs to consume UTXOs from a contract with restricted access to a specific wallet, an extra signature will be attached to the message. Users will sign the message before creating it and attach the signature to the message, then sign the transaction itself that stores the message in either the Master Outgoing or Master Incoming Contract.
- Message signing can be performed using Cardano wallets or any EVM wallet (e.g., Metamask). The smart contract from which funds are to be consumed must have the public key (EVM or Cardano address) of the wallet stored in the UTXO to be consumed, allowing for verification and consumption.
Message Structure
Messages will contain the following fields:
- Date
- Source Network
- Source Address
- Destination Network
- Destination Address
- Message: Any encoded information
- Signatures: Attached signatures for the entire message block
- Processed Flag: Indicates whether the message has been processed by the off-chain module
Project Configuration
Each project or use case will have an entry UTXO in the Project Configuration Contract, identified by a unique NFT token. The datum of this UTXO will contain all the necessary fields for configuring the project. The smart contract will ensure that only authorized wallets can update the datum.
When constructing messages with source or destination addresses, the unique policy and token name minted for each project will be used to identify them. The off-chain module will retrieve the project configuration (datum) from the Project Configuration Contract when needed to process messages, using the NFT as an identifier matching against the source or destination address.
The Project Configuration datum will include:
- Scripts: List of UTXOs with scripts to be referenced when building transactions.
- Redeemers: List of redeemers with their fields and default values or values to be generated using variables. Each redeemer will have a unique name or type for identification.
- Datums: List of datums with their fields and default values or values to be generated using variables. Each datum will have a unique name or type for identification.
- Transactions: List of possible transactions with their configuration and logic
Transaction Configuration
For each transaction, the following should be specified:
- Flag indicating if it should be used for outgoing, incoming, or both
- Query to Activate: Query applied by the off-chain module to determine if the logic should be applied to the message
- Scripts: Script hashes to be used in the transaction. They will be attached to the transactions or read from the UTXO where they are stored. It will search for the script hash in the JSON configuration file.
- Inputs: List of inputs to be added to the transaction, either specific UTXOs or using the intelligent selector to find UTXOs in a particular address. For each input to be consumed from a smart contract, a redeemer must be specified, including its type, which will be searched for in the list of redeemers in the configuration file. The complete redeemer will be constructed based on the declaration, using default values, variable-filled values, or specific values set for fields at this point.
- Reference Inputs: List of reference inputs to be added to the transaction, either specific UTXOs or using the intelligent selector to find UTXOs in a particular address.
- Minting/Burning: Specification of tokens to be minted or burned, including the token, amount, and a redeemer.
- Outputs: List of outputs to be added to the transaction, including destination address, tokens, and possible datum (new or updated). To create the datum, the type must be specified and searched for in the list of datum declarations. If it is an UPDATE operation, the datum to be updated must be specified by selecting the index of the input from which the datum should be read. Specific fields can be updated using a formula, such as {amount: input.amount + message.amount}.
Intelligent UTXO Selector
The intelligent UTXO selector can be configured to:
- Select one or more UTXOs that possesses a specific NFT
- Select one or more UTXOs that possesses more than a certain amount of FT tokens
- Select one or more UTXOs that possesses a specific datum or a type of datum
- Select one or more UTXOs that possesses a specific value or condition in a field of its datum
- Select one or more UTXOs that possesses a reference script with a specific hash
- Select one or more UTXOs to satisfy a specific aggregated condition (e.g., total amount of tokens between them)
Redeemers and Datums
Redeemers and datums have declarations in the UTXO in the Project Configuration Contract. In the redeemer and datum declarations, fields, default values, variable-filling values, and a type for identification are specified.
In each transaction, for every minting or consuming operation, a redeemer is required. The type of the redeemer is set, and it will be created based on the template. Specific values for different fields can also be set at these points.
Similarly, for datums in outputs, the type is set, and specific fields with values are defined. If the datum is an update, the index of the input from which the datum will be read must be specified, and the updated datum will be populated accordingly. It is also possible to set a datum field with a transformation formula, such as {amount: input.amount + message.amount}.
Cost Efficiency
The transaction fees incurred by the off-chain module can be handled in two ways:
- For outgoing transactions, users can pay additional ADA when creating the message transaction in the master contract to cover the fees. If not all the ADA is used, a mechanism should be in place for users to collect the remaining balance.
- For incoming or outgoing transactions, the master contract or a separate smart contract can lock ADA to pay for the transactions. Different possibilities include each project having an entry in the contract, each user having an entry, or the cross-chain protocol itself providing ADA. The specific approach can be determined based on the requirements and preferences of the projects and users involved.
Reliability and Fault Tolerance
To ensure reliability and fault tolerance, the following mechanisms can be implemented:
- Retry Mechanism: If a transaction fails due to network issues or other transient errors, the off-chain module can retry the transaction after a certain interval to ensure that temporary failures don't result in lost messages.
- Transaction Log: Maintain a log of all transactions processed by the off-chain module, including their status (success, failure, pending), for auditing, debugging, and recovery purposes.
- Rollback Mechanism: In case of critical failures or inconsistencies, implement a mechanism to roll back the state of the master contracts and the off-chain module to a previously known stable state, preventing data corruption and ensuring the integrity of the cross-chain messaging system.
- Monitoring and Alerts: Implement monitoring and alerting systems to detect and notify administrators of any errors, failures, or anomalies in the message processing flow, enabling prompt action to investigate and resolve issues.
Governance and Updates
The integration and update of off-chain modules and components are the responsibility of the cross-chain protocol adopting this solution. They should incorporate the off-chain module into their existing decentralized infrastructure of nodes and validators. The cross-chain protocol should provide a secure mechanism for projects to add, edit, or delete their Project Configuration Contract.
User Experience
To enhance the user experience, the solution includes a flag in the outgoing or incoming messages to indicate whether they have been processed by the off-chain module. Leveraging the existing tracking systems of the cross-chain protocols allows users to monitor the progress of messages across different networks.
Conclusion
This hybrid on-chain/off-chain solution enables seamless cross-chain messaging on the Cardano network. With the help of the master contracts for message storage and an off-chain message processing module, the solution facilitates efficient token transfers and other cross-chain operations.
The Project configuration contract allows for customizable transaction creation based on specific project requirements, including the declaration and usage of redeemers and datums. The intelligent UTXO selector and transaction signing mechanisms ensure secure and flexible handling of transactions.
Incorporating cost efficiency measures, reliability, fault tolerance mechanisms, governance and update procedures, and user experience enhancements provides a robust and efficient means for integrating Cardano into cross-chain protocols.
It opens up new possibilities for cross-chain applications and use cases, enhancing Cardano's interoperability with other blockchain networks.