Dev Log #12
Overview
Following on from our first-ever IBC Kusama<>Polkadot trustless bridge announcement, we can now reveal the development progress that we will leverage for the launch of Picasso and Pablo. A significant amount of the work for the bridge has already been completed as we will detail below.
Whilst the announcement of connecting KSM<>DOT via IBC is new, the underlying pallets and infrastructures that support its proper functioning have already been discussed in our previous publications and dev logs. Therefore, leveraging this for parachain<>parachain IBC bridging is the best use case to test our infrastructure before we add support for Cosmos chains. With this in mind and with the cutting-edge research from our bridging team, we were able to find solutions to blockers that therefore meant we are able to push this to production in time for the launch of Picasso. Specifically, we were initially relying on the Beefy light client which is still being developed by Parity, however, after our Rust relayer and IBC pallet work was completed much sooner than expected, we were able to expedite the development of the entire bridge by optimizing the GRANDPA light client instead. Thus, the first KSM<>DOT IBC bridge was born.
Picasso/Pablo
As highlighted in our previous dev logs, the Substrate team is nearing completion of all our pallets required for launch, with the final integration tests, QA, and audits now in progress. Staking-rewards and fNFTs pallets have seen a significant amount of code being pushed and have been in progress for several weeks. After small refactorings and fixes, these pallets should be pushed into the test and audit pipeline from Monday 12th September — marking an important milestone internally. This should allow the parachain team to shift focus onto end-to-end tests and full pre-prod launch sequence rehearsals. Please see our detailed fNFT spec here: https://github.com/ComposableFi/composable/blob/main/rfcs/0006-financial-nft.md.
https://github.com/ComposableFi/composable/pull/1585
We continue to emphasize that the launch of Picasso and Pablo will entail a feature complete sequence that will allow users to trade and swap, provide liquidity, earn rewards, stake their tokens, create fNFT positions, bond, and more. With this in mind, the team is finalizing specs for launch fail-safes surrounding all our features and pallets, to support a robust emergency plan.
In addition, the Substrate team is also now working on the release process to test the IBC bridge between Picasso and Composable. As mentioned in the main article, we made sure to design the UI/UX for this bridge to feel very similar to bridging KSM from the relay chain to Picasso. Users will be able to use the same “Transfer Page” on Picasso or Pablo to bridge their DOT to Picasso. By using the BYOG pallet on both parachains, users will be able to use $DOT for all transactions.
To leak some more alpha, whilst our devs have been busy preparing Picasso for launch, our design team is finalizing a reskin and updated branding for Pablo. We want Pablo to visually represent what we are trying to achieve — the convergence of Picasso, Polkadot, and Cosmos.
Bridging team
As mentioned above, our bridging team is now focused on preparing the first IBC bridge for public use between Kusama and Polkadot for launch. The bridge consists of several core components:
- Pallet ibc
- ibc-rs
- GRANDPA light client
- Rust relayer
The team has made significant progress with pallet IBC, with it now being pushed into our QA and audit stream — https://github.com/ComposableFi/composable/tree/main/frame/ibc. The Hyperspace (Rust) relayer is also now IBC compliant, with the team now focusing on building the relevant test suite to further secure this. Therefore, the remaining key pieces are the Grandpa light client which is currently being developed — the feasibility has already been proven and the final details are being ironed out, meaning that the next steps are integrating it with ibc-rs. Ibc-rs is being refactored to support parachain<>parachain, with the technical debt being tackled. To summarize, pallet IBC will begin audit next week, the development of grandpa light client and refactoring of ibc-rs is estimated for 1–2 weeks, with an additional 2–3 weeks estimated for their audits. In parallel, the QA and Substrate teams will begin the testing process to ensure the bridge is aligned with our Picasso and Pablo launch sequence.
As regards our efforts to trustlessly bridge to NEAR, our NEP-364 proposal was merged, therefore paving the way for supporting IBC to establish the first trustless Polkadot<>NEAR bridge. All of the state verification PRs have now been merged.
https://gov.near.org/t/near-polkadot-using-ibc-trustless-bridging-requests/22807
https://github.com/near/nearcore/pull/7165
EVM bridging Strategy
With the above updates, we decided to focus our internal efforts fully on trustless bridging — especially now that we have a solution we are able to leverage for Picasso’s launch. This decision has already translated to significant progress within the team, with our focus fully aligned.
Therefore, Mosaic is no longer a separate product stream, but rather, the team is now being consolidated under bridging for our EVM strategy. These devs bring their experience to the fore as they are now focused on the EVM components of our trustless bridging suite. Our initial focus is on IBC and connecting Cosmos, Polkadot, and NEAR; however, with the Mosaic team now adjusting their focus, we are able to already explore and research the support of trustless light-client bridging to ETH 2.0, Polygon, Arbitrum, and other EVM chains.
XCVM
With our vision of orchestrating generalizability and the mass adoption of DeFi, we are abstracting the development process for builders to further simplify the user experience in interoperability. The Composable XCVM we have been building from the ground up highlights our efforts in this regard. As we consolidate our efforts and build towards a decentralized future, we will continue to share with you our progress.
As the Cosmoverse conference inches closer, the XCVM team remains focused on bringing top-level and user-friendly orchestration to the public by September 26th. We will display the latest progress on our tool and what’s next to come, as well as run the contracts live, and then showcase the data output and interaction on the developer interface. The last will include the stepper where the user can visualize the full orchestration process, introducing a dropdown for every transaction detail.
As regards our roadmap concerning the XCVM, we have finished and reviewed our UI, frontend structure, smart contracts, VM pallet, setup, and relayer support. As we simultaneously groom and test our backend for the upcoming demo, we are also focusing on finalizing the API integration and data structure powered by Hasura.
The XCVM satellites contracts (CosmWasm contracts) are now deployed on both Juno and Picasso for the demo, showcasing XCVM in action (and also the fact that you can deploy the same protocols written in CosmWasm on both chains and expect the same behavior).
Specifically for the CosmWasm pallet, we have been working to make it fully spec compliant, with events generation now compliant to the Wasm VM reference implementation.
Through this work, we also proposed improvements to the Wasm VM for deterministic contract address derivation (already implemented in our VM).
If you would like to know more about XCVM use cases and user experience, check out our last posts on Medium, in which we unpack the complete XCVM flow and experience for both users and builders.
