The problem Swift DEX solves

Motivation: Slow Interoperation, but Why

Traditional cross-chain protocols (Avalanche, Chainlink, Cosmos, etc.) face the High-Latency bottleneck.

It is a fact that, only when the cross-chain message is finalized (or with a extreme-high probability) on the source chain, the target chain could accept it as a valid message by verification mechnisms (like Avalanche's BLS-Aggregation, IBC's Light Client, and Zero-Knowledge, etc.).

The finalization process spends at least one consensus epoch (more epochs for Bitcoin, Ethereum2.0, etc.).

Essentially, message finality means that the message could be verified by outside entities (also called Verifier). Missing finalization means missing security guaranteed by underlying decentralized blockchains.

The traditional cross-chain protocol abstract paradigm: in one word, the message is first finalized, then transmitted and finally verified.

SwiftDEX: Not Wait Finality

Core Idea: Any message is always generated before finalization (It is the First Principle). Since the message has generated, then DO NOT wait finality. Just asynchronize finalization, transmission, and verification.

We propose SwiftDEX protocol, achieving swift, atomic cross-chain exchange without any security loss. It introduces the following cutting-edge technologies:

• Post-Finality: It is the fundamental sub-protocol of SwiftDEX. Post-Finality achieves the core idea of asynchronizing finalization, transmission and verification. With it, we could build the following Unstable Cross-chain message and Dual Lock.
• UNSTABLE Cross-chain Message: It is the Pivotal, Critical, Core, Key component to reduce atomic interoperation latency. However, it is also extremly easy while ignored by most researchers and developers. The message's unstability could reduce latency about 40%.
• Dual Lock: For some Non-Fungible Token/Asset/State, the Dual Lock could avoid dirty/repeatable/phantom read or write operations.

Practical Considerations

• All in smart contracts without introducing any other trusted third-parties.
• Suitable for all kinds of blockchains (First Principle), without any hard-fork invasion.
• Compatible with existing verification mechanisms, like BLS-Aggregation, Light Client, Zero-Knowledge, etc.

Efficiency

Until now, we have conducted some evaluations in a local cross-chain network (including Ethereum, and Avalanche). The result shows that the latency has reduced 40%.

Next, we will conduct more evaluations in a geo-distributed cross-chain network with more complex DApps (like defi, nft, supply chain, etc.) and scenarios. And, we will also adapt SwiftDEX to other homogeneous/heterogeneous blockchains to emphasize its practicality.

FastCCIP

Now, this system is just developed as a prototype because of limited time and fund. In the future, we will integrate the cross-chain protocol into Chainlink CCIP.

Challenges I ran into

We implement SwiftDEX in smart contracts by solidity for on-chain logic.

And the off-chain relayer (also called eICN) connecting different Avalanche C-Chains is also customized by golang.

Because this project is still a Proof-of-Concept which focuses on the core functionalities and technology, some interactive components (like UI, beautiful interactive operations, etc.) are listed as future work.

During research and development, we also produce some necessary avalanche tools, like multi-chain creation, deployment, and SDK (by golang), contract compiling&deployment (by golang) etc.

The most difficult challenge is how to keep atomic in the practical system. We can prove, formally and theoretically, that the SwiftDEX is atomic. However, keeping atomic in this practical system is very hard. To solve it, we constructed the state transition one by one and convert these transitions into a encoding state-machine. Within this state-machine, all cross-chain operations could be executed strictly and guaranteed correctness.

The second challenge is how to reduce the solidity contract size code. It is a classical issue for solidity developers. However, the detailed solution is different for each project. In SwiftDEX, we abstract the atomicity state-machine into a public library. And the main contract executes state transition by 'delategate call' the library. In the delegate call, the storage is still in the main contract, and the actual logic is in the library. After updating, the contract code size is changed from 40,000+ bytes to 21,000+ bytes.