IBC Expansion #5095
Replies: 9 comments 6 replies
-
|
Some additional context Polygon CDK chains should be able to validate wasm blobs as a result of the Near/Polygon zkwasm collaboration |
Beta Was this translation helpful? Give feedback.
-
|
Great write-up! I have two elements of critical feedback on the process, see below.
A firm decision on 1, and executing on that 1 integration, fast and smooth, is likely better than focusing on 2-3.
I think the list of potential targets is a really good starting point. To help get an accurate evaluation of the "Ease" of integration, I would also rank (or filter) the potential targets by how likely is it that the said ecosystems are interested in IBC. I am mentioning this because it's possible a couple of the "potential targets" would not be very receptive of having IBC integrated, since they have their ideas about solutions in the interoperability space; even if those ideas could coexist with IBC, it's usually an uphill battle. Briefly, which of the "potential targets" have appetite for IBC and are open to collaborating/feedback with Interchain GmbH (and other integrators)? |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the feedback! i really appreciate it. re the two elements that you mentioned:
completely agree. the reason we'd like to investigate 2-3 targets is so that we have a better understanding of what design decisions are needed to make ibc-go generic for these targets. in practice, given the resources at hand, it's likely that we might pivot to prioritizing 1 target.
this is a good point. as of now, the OP Stack team has been receptive to the idea of integrating IBC. and we've been working closely with the team at Rollkit to have IBC on their stack. |
Beta Was this translation helpful? Give feedback.
-
|
One piece of feedback from my perspective is that I believe that ibc-go should also maintain the contracts that go into the wasm client. As we trend to connecting multiple ecosystems over IBC, the wasm client will continue to be an important piece of infrastructure, and Composable is interested in collaborating to ensure the client contracts going into the wasm client are fully up to date etc. |
Beta Was this translation helpful? Give feedback.
-
|
Rollkit and then the OP stack seems like the most feasible path for IBC go integration targets. Rollkit should be pretty straightforward and give the development team hands-on experience with a fraud proof architecture, and then the OP stack is also written in go, has people building app chains, high profile users, and Tess is about as good a counterparty as we can ask for to help integrate on the OP side. |
Beta Was this translation helpful? Give feedback.
-
|
note, it may be best to work with polymer on the OP integration since they recently decided to become an OP chain. so maybe there's a separation of concerns where the ICF team could convert IBC go to use ADR-05 and have have polymer implement machinery specific to OP |
Beta Was this translation helpful? Give feedback.
-
|
We're planning on supporting cosmos SDK <> OP stack rollups. IBC-go would come in working form as a cosmos sdk module. The lift would be on the client side. For example, connectivity between a cosmos sdk eth rollup to a cosmos sdk app chain would require the app chain to run an eth LC. |
Beta Was this translation helpful? Give feedback.
-
|
Arbitrum and OP stack would definitely be strong moves, I think Solana may also be a strong potential choice If it's possible. Ton may be an interesting one to follow in the future too, as it opens up a very different market, but may be totally different. |
Beta Was this translation helpful? Give feedback.
-
|
If we focus on the enterprise adoption (as mentioned in current efforts), we are hearing some enterprises employ Polygon for their platform, probably more often comparing to other choices. (Please regard this opinion as observation, not suggestion.) |
Beta Was this translation helpful? Give feedback.
-
|
Rollkit will be the easiest to integrate as it shares common cometBFT types that IBC uses and the cosmos-sdk. The Progression could be the following :
The learnings and concepts learned about Rollup bridging can then be used to tackle further frameworks. |
Beta Was this translation helpful? Give feedback.
-
|
Octopus Network is worth a mention: Composable has NEAR IBC on their roadmap but the Octopus Network team has already completed an audit of the same materials (further drafts still going forward for improvements) without the requirement of a broker/orchestrator chain. Sorry to be late |
Beta Was this translation helpful? Give feedback.
-
|
Just circling back on this. Any status on adding support for algorand??? If not what can i do to make this happen? |
Beta Was this translation helpful? Give feedback.
-
|
we currently have no roadmap item to support algorand. are you someone from the algorand team? |
Beta Was this translation helpful? Give feedback.
-
|
I’m the CTO, you should prioritise if possible, we have a bustling ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
I've sent you a message on linkedin John to make this happen so let's take it from there! |
Beta Was this translation helpful? Give feedback.
-
Introduction
As of today, ibc-go is used by ~100 Cosmos SDK chains. IBC has clearly achieved PMF within Cosmos but needs to expand its extensibility to different ecosystems.
To realize IBC’s vision of becoming the TCP/IP for blockchains, we need a deliberate and strategic approach to extend integrations with other chains.
Objective
This discussion aims to:
Current Efforts
Apart from Cosmos, IBC is currently live on Polkadot. Ongoing efforts to integrate IBC into other ecosystems include:
While these contributions play a crucial role in driving IBC’s extensibility, the focus of this discussion is on the pathway for ibc-go expansion into other chains/frameworks.
Potential targets
In addition to the above-mentioned efforts to expand IBC, Interchain GmbH is actively exploring additional Go-based chains and frameworks. Our initial research has identified the following list of potential targets:
*An OP stack integration would also onboard OP Mainnet, Base, and BNB OP chain, as well as existing L1s that are migrating to an op-rollup such as Celo.
The criteria for prioritizing the aforementioned chains/frameworks include:
These criteria guide our decision-making process to strategically prioritize and select the most useful chains/frameworks for integration.
Within our team, we employ the ICE framework for prioritization decisions. In the context of external integrations, the framework could be applied as follows to arrive at a prioritization score:
Community feedback
In the spirit of open-source development, we’d like to open up this discussion to the public to ensure that the IBC community as a whole is aligned on integrations with the highest potential impact. We’re looking for feedback on:
Your input is highly valuable in shaping the future of IBC integration. We are committed to solving user problems, and your feedback is instrumental in ensuring that our efforts align with the real needs of our users.
Action plan
Given our limited engineering resources, our goal is to strategically focus on 2-3 ecosystems. A high-level action plan on how to execute new integrations could look as follows:
Use the insights and feedback collected from this discussion, along with our internal research findings around feasibility, architectural constraints, and market trends to narrow down a concise list of 2-3 target ecosystems for ibc-go integration.
Create simple POCs for each selected ecosystem. This could include minimal tasks such as performing light client updates or negotiating a channel handshake. The purpose of these POCs is to gain practical experience with each ecosystem and to identify which changes are generic and which changes may necessitate more comprehensive design considerations.
Building on the insights and findings from the POC phase, we’ll draft RFCs, outlining the specs, design decisions, and requirements for integrations with each ecosystem.
With the RFCs as a guide, we’ll move on to implementing more advanced POCs. These may encompass relatively more complex tasks such as token transfers.
Begin implementation work based on the specifications and design considerations outlined in the RFC.
Initiate release cycle
Release
Your feedback is important in helping us determine which chains/frameworks to prioritize, ensuring that our approach aligns with the needs of the IBC community. We invite you to share your thoughts and suggestions on potential integrations. Thank you for your participation!
Beta Was this translation helpful? Give feedback.
All reactions