In this article, we’re excited to provide an update on our ongoing development efforts, where we’re building a custom bridge solution for the Kadena blockchain. Our primary focus is on developing a bridge based on the Hyperlane architecture.
Although Kadena’s architecture differs from the Ethereum Virtual Machine (EVM), Hyperlane is EVM-compatible. Therefore, our primary goal is to seamlessly adapt Hyperlane architecture to work with Kadena’s non-EVM architecture while still maintaining the level of security that Kadena offers.
This initiative marks a significant milestone in our commitment to advancing the Kadena community. We’re wholeheartedly dedicated to enhancing the capabilities of the Kadena ecosystem, and now, we’re eager to share the technical details of this project. Let’s dive right in.
Why Hyperlane?
Hyperlane serves as an innovative universal interoperability layer within the modular blockchain ecosystem. It simplifies communication across various blockchain environments, whether they are layer-1, rollup solutions, or app-chains. This simplification extends to the integration of backend systems, smart contract configuration, and quickly deploying bridging solutions.
As a result, the need for complex liquidity provisioning in third-party protocols or navigating extensive KYC procedures becomes unnecessary. Hyperlane’s technology can seamlessly integrate into existing infrastructure, which is precisely what we’re doing with the Kadena blockchain in our current context.
Our implementation for Kadena will be built upon Hyperlane Version 3, which offers a comprehensive range of features and capabilities. Implementation will be specifically tailored to non-EVM networks, ensuring compatibility and optimal performance within the Kadena ecosystem.
How Will the Kadena Bridge Work?
Here’s a brief overview of how the Hyperlane bridge implementation will function and facilitate the transfer of tokens between the Kadena blockchain and other chains.
The process looks as follows:
- First, the user initiates the bridge process by depositing funds into the Mailbox smart contract of the Kadena [Network A];
- The contract verifies the transaction’s receipt using an explorer to confirm its arrival in the network;
- Using messaging API, the protocol repackages transaction data into specialized-format messages;
- Hyperlane processes and validates these messages through its Interchain Security Modules (ISM);
- Once validated, Hyperlane authorizes the issuance of tokens within Network B.
- Issued tokens are sent to Network B for further processing;
- In Network B, received tokens undergo validation and confirmation to secure the cross-network transaction’s integrity.
Overcoming Technological Differences
Our journey into Kadena’s development has been more than just a collaboration; it’s an invitation to explore a new frontier in technology. It’s a challenge our development team eagerly embraced, fully aware that it would not only push our skills to the limit but also play a significant role in advancing this emerging technology.
In the following section, we will highlight the challenges we faced during this journey and demonstrate how our expertise enabled us to overcome them.
Non-EVM Compatibility
Transforming a solution initially intended for EVM networks into one compatible with non-EVM posed a substantial challenge. Kadena’s distinct architecture differs from the EVM, and since Hyperlane is inherently tailored for EVM compatibility, our primary goal was to intricately modify Hyperlane sequences to integrate with Kadena’s non-EVM architecture seamlessly.
This adaptation demanded a meticulous and precise approach to guarantee the technology’s seamless and uninterrupted operation.
Security Key Storage
Managing security keys presents a distinctive challenge due to the varying cryptographic techniques used in EVM and non-EVM networks. Our top priority in this domain is to meticulously identify and adjust a secure key storage solution that perfectly matches the project’s needs.
After thorough research and continuous collaboration with the Kadena team, we have painstakingly assessed and selected HashiCorp Vault Transit as the ideal solution. We opted for this technology because it is open source, thus offering self-deployment capabilities.
As the project’s code will eventually be open source, individuals running the bridge, or its components like relayer or validators can establish a secure storage instance. Additionally, this technology stands out as one of the few in the market supporting Ed25519 key types, which are integral to the Kadena blockchain. Furthermore, a readily available library for integration into the Rust language ecosystem simplifies the process of adopting this solution.
This choice plays a crucial role in addressing the intricate aspects of blockchain security keys, safeguarding the integrity, and security of our development process, particularly when bridging EVM and non-EVM environments.
Back-End Technology
Our product development initially began with the Node.js programming language. However, when we consulted with the Hyperlane bridge technology team, they expressed reservations about providing support for Node.js. Instead, they advised us to align our solution with Hyperlane’s native language, which is Rust.
This unexpected change presented a considerable challenge, as it required us to shift our backend codebase from Node.js to Rust. This transition, in turn, demanded substantial adaptations and modifications to our technical stack to meet the new language requirement.
Final Thoughts
Working closely with the Kadena team has been an exceptional experience. The team consists of a passionate group of individuals united by a common goal: to bring a safer and more scalable solution to the blockchain realm.
We are deeply honored to participate in this effort and play a role in bringing to life a crucial component of the Kadena ecosystem—a technology that will connect the community with EVM networks. Together, we are charting a course toward a promising future in the blockchain industry.
