Cross-Chain Trading Atomicity via Coordinator Locking
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current blockchain systems face challenges in ensuring atomicity and data integrity during cross-chain transactions, particularly in securities trading, where the completion of transactions on one blockchain is unclear, leading to potential 'delivery or payment failure' issues due to lack of interoperability and conflicting rules across different blockchains.
Innovation Solution
The Cross Framework is developed to support cross-chain smart contracts and transactions, implementing a distributed consensus protocol with a locking mechanism and atomic commit protocols to ensure atomicity, consistency, isolation, and durability across multiple blockchains, using a cross-module for cross-chain transactions and a contract module for smart contract management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If two-way-peg method is used for cross-chain token transfer, then token transfer between blockchains is enabled, but security token side cannot check rules on fund side (e.g., transferee limits, KYC status) leading to potential trading conflicts
Solution Approach 1:
The system performs preliminary rule verification on the security token side before executing the transfer. The security token side checks whether the transferee meets KYC requirements and whether the transferee limit has been reached, and only then allows the transfer to proceed. This preliminary action prevents trading conflicts before they occur.
Solution Approach 2:
The system establishes a feedback mechanism where the security token side verifies rules and returns confirmation to the fund side. This feedback loop ensures that both sides are aware of the rule compliance status and can coordinate accordingly, preventing conflicts arising from unilateral assumptions about rule compliance.
2Loss of time
If HTLC method is used for cross-chain transaction, then timeout mechanism is provided for token retrieval, but delivery or payment failure risk remains when securities transfer rules prevent transaction at timeout timing
Solution Approach 1:
The system performs preliminary verification of security transfer rules (such as transferee limits and KYC status) before the timeout period begins. This ensures that the transaction is valid and can be executed immediately when the timeout occurs, eliminating the risk of delivery or payment failure.
Solution Approach 2:
The system introduces an intermediary verification layer that checks security transfer rules independently of the HTLC timeout mechanism. This intermediary layer ensures that when the timeout occurs and token retrieval is attempted, the security transfer can be successfully executed because the rules have been pre-verified.
3Adaptability or versatility
If blockchain handles funds and another blockchain handles securities separately, then specialized processing is enabled, but atomicity of trading cannot be guaranteed across chains
Solution Approach 1:
The system merges the fund blockchain and security token blockchain into a unified trading execution environment. The coordinator executes both fund transfer and security token transfer operations atomically, ensuring that either both transactions complete successfully or both are aborted, thus guaranteeing trading atomicity across chains.
Solution Approach 2:
The coordinator acts as an intermediary that manages the atomic execution of transactions across both blockchains. It receives transfer instructions, verifies rules on both chains, and coordinates the execution of both transactions together, ensuring atomicity while allowing each chain to maintain its specialized processing capabilities.
Data Source
AI summary
A trading system for atomically executing a smart contract for trading between a first blockchain and a second blockchain includes a coordinator section and a first user section on the first blockchain and a second user section on the second blockchain. The coordinator section sends a first packet created based on a predetermined transaction in which a contract function is specified to the first and second user sections. When the contract function in the first packet received from the coordinator section is successful, the first user section saves a change operation in a state store associated therewith, acquires lock for a change target, and sends a second packet with a status set executable to the coordinator section. When the execution is failed, the first user section discards the change operation in the state store associated therewith and sends a third packet with the status set inexecutable to the coordinator section.