This socket is for the research into a potential IBC integration with Pocket Network. It will cover all the protocol-specific research, production of implementation roadmaps as well as general documentation relating to just exactly how one integrates IBC with a non-cosmos chain.
Type of Socket:
Experiment: $3K, paid and reviewed monthly, for the life of the experiment
I will work in the open and self-report monthly.
Work done will be continuously updated in the open to the links provided below as and when it is being done.
In addition to this continuous form of updates, I will be self-reporting on a monthly basis on the progress made each month
This month has focused on getting the foundational pieces of research around an IBC integration with Pocket Network V1 in place. This included the following:
Producing a outline document of what IBC is, how it works and what a general implementation of the protocol requires
Researching other implementations: ibc-go, ibc-rs and ibc-solidity as we use Golang (but no longer are a cosmos-sdk chain) we must implement the IBC specification ourself - so comparing these and seeing where they differ and where they are similar is very useful
Using the previous research, produce a roadmap. This splits the IBC integration into 5 “phases” each with a number of sub-tasks going from the initial first steps and ending with cross-chain fungible token transfers
As this is relatively uncharted territory, not many implementations of the IBC specification exist outside of cosmos (none for Golang), so notible people who has implemented IBC for their chains were consulted to ask for feedback on the roadmap and its contents, those being lead developers from Composable Finance and OmniFlix
Finally the roadmap has been moved over to the Github repo, this is where the design documents will live. The notion document is still accessible but will no longer be added to, it will contain the preliminary research alone
This leads to the plans for next month. I will begin to create more detailed design documents for each task of each phase, starting with the implementation of ICS-23. As this process goes forth it may involve the creation of some GitHub issues/tickets for the current V1 codebase that allow for an easier implementation when the time comes to write the code.
Nice one. Just in future it might help to include the links in this post too if you can… and partly posting this to just remind people all the links are up in the original post if they want to dive into the detail of any of the items listed in the update
@h5law Can you give me write access to your GitHub repo? I read & reviewed it and have some minor edits to submit.
Overall, the plan looks . Easy to read, makes sense and exactly what we need. I took some of the ICS specific details at face value, but we’ll fill in the gaps along the way if we find any.
I wanted to mention some dependencies we might have on external stakeholders:
Phases 1, 2 (core) - This is entirely dependent on the protocol team at PNI so no-problemo.
Phase 3 (relayer) - We will need someone to run a relayer that pulls/pushes IBC packet to/from the Pocket network. We can reach out to Polymer Labs since we already have a relationship with them to integrate with Pocket.
Phase 4 (tendermint light client) - We’re going to need Pocket Validators (in TestNet) to run the tendermint light client during development. Whether it’s PNI or node runners from the community, we’ll have to reach out
Phase 5 (application) - Since fungible token transfer is the first and most widely wanted use case, we’ll need another chain/app to run a Pocket light client. Dydx is a cosmos chain, running tendermint, so I believe we could use PNF’s help in getting that team on board when the time is right.
Can you give me write access to your GitHub repo? I read & reviewed it and have some minor edits to submit.
Done
Phase 3 (relayer) - We will need someone to run a relayer that pulls/pushes IBC packet to/from the Pocket network. We can reach out to Polymer Labs since we already have a relationship with them to integrate with Pocket.
This is what I was thinking, we might as well leverage their network and reduce the amount of work we have to do regarding the integration as much as we can.
Phase 5 (application) - Since fungible token transfer is the first and most widely wanted use case, we’ll need another chain/app to run a Pocket light client. Dydx is a cosmos chain, running tendermint, so I believe we could use PNF’s help in getting that team on board when the time is right.
I recently had a call with the lead developer of OmniFlix who mention a few things regarding the fungile token transfers:
It would be very useful to run a 2 local cosmos-sdk testnets and send tokens to and from them with IBC. This will help us during the development phase knowing how the Channels, Ports and Connections interact and what everything should look like in the wild
When we send a $POKT token from Pocket Network to another IBC chain the token will be created with a specific denom: pokt-ibc-<CHANNELID:PORT:CONNECTION> where the suffix is a unique string depending on the channel that was used to send the token. This means that any channel will have to stay open if it is used to send tokens. If the channel is to shut down without informing users to get their tokens back those tokens will be lost.
This leads us to the following points regarding token transfers (bear in mind I have not fully looked into this part and am going off what I have been told from this developer).
What will $POKT look like when we return it back to the pokt network? Will it be with the denom pokt-ibc-<CHANNEL:PORT:ID>? If so we need to support multiple denoms. However, this will need to be investigated a lot more
When we receive the $POKT back will we simply return the tokens that were originally put into the IBC packet?
These points are further down the line so are most likely going to get cleared up once we reach that point.
I am starting to work on the design document for implementing ICS-23 now the PR supporting SMT non-inclusion proofs has been merged I can create a sort of “demo” implementation of some of the relevant functions and this will expose any additions to the current protocol that need to be implemented.
This month was focused on getting the details of the foundational elements of an IBC integration with Pocket Network V1 thought out, designed and ready for implementation. This consisted of making 2 documents one for ICS-23 and one for ICS-24 the details are discussed below:
ICS-23 (Vector Commitments) - The tl;dr is that this ICS component defines how we are to create CommitmentProof objects that can be verified by counterparty chains. This is of course very relevent for our ultimate goal of token transfers. We want to be able to prove that a transaction was sent on our chain intended to be for the counterparty chain. But on a lower level this component is fundamental to the entirety of IBC. Not only do we need to prove these higher level things like token transfers, but we must also prove that we have a channel opened, or a client available, or even a connection in the first place. Ultimately this document talks about how we can go about setting up this proof/verification system for our usecase.
ICS-24 (Host Requirements) - The tl;dr for this is that it is again another fundamental piece of the IBC puzzle. ICS-24 defines the means by which the IBC module will store information on all things IBC. This, in conjunction with ICS-23, means that all other ICS components can be implemented. The means by which we store IBC related data is important that we get right, it must interact with ICS-23 in such a manner that we can efficiently generate proofs, for anything in the stores, and we also need it to not take up too much space, these must be able to work in a light client setting.
With these two documents currently under review from @Olshansky the work on deciding the correct way to implement them has begun. I expect this review stage to go on for a little while as these 2 ICS modules could be thought of as the foundations for our IBC house. And we don’t want to build on sand. That being said once these documents have gone through a thorough back and forth, we can begin the work of implementing them and getting a MVP for the start of our IBC module!
After these documents are in a state where we believe the implementation will be effective and efficient, the work on implementing them can begin. From this point the final document for Phase 1 of the roadmap will be put together for ICS-02 (Client Semantics). This is essentially the Pocket Network V1 light client.
Overall this month has been a lot of reading, code and documentation and creating the two documents linked below. The work next month will most likely see the close and merger of the 2 PRs and the beginning of the implementation work for an MVP of the IBC module’s core functionality. The work on ICS-02’s design document will most likely begin around the same time.
As always any questions shoot them my way,
High out!
This month has been a bit hectic for me personally but we have officially broke ground! The initial IBC module covering ICS-23 (Vector Commitments) and ICS-24 (Host Requirements), in part, has been implemented. As of writing this the PR [1] is still a work in progress but we have now officially got an IBC module - in its infancy.
Anyone who had read through the pokt-ibc-integration repo [2] may have noticed I planned to utilise the cosmos/ics23 to implement ICS-23. However, this turned out to be more complicated than it seemed due to their lack of support for non-membership proofs for SMTs. Instead I have modified the implementation slightly to use existence proofs for both membership and non-membership. This means that we prove there is an unrelated key-value pair in the place we are checking and it is not the one we are after.
Regarding the integration repo [2], I plan to move the design docs back to a notion page for quicker iterations, instead of the git workflow. This turned out to be the wrong idea and as such the new plan is to utilise a new notion document for designing the IBC module and its components; as each component is implemented official documentation in the form of README.md files and other documentation will be added to the module directory itself in the Pocket V1 repo.
Ultimately the goal for our IBC module is to design it in such a way that once it works and is fully functional and polished it can be pulled out into its own repository and become the first framework agnostic go IBC library that can be used by other projects in place of cosmos/ibc-go.
Alongside starting the IBC module, I have taken over the SMT library [3] as its maintainer and have taken over its development leading forward. The SMT is core to the ICS-23 module for us, as it is the means by which we are able to generate CommitmentProofs to verify our IBC stores contain certain information.
Some minor developments relating to IBC:
Began building relationships with the folks at Polymer Labs so as to better understand how we can leverage their network for our IBC needs
Improved SMT and IBC documentation and understanding so as to prepare presentations and explainers for the community
Moving forward into the month of June I plan to spec out the ICS-02 (Client Sematics) specification. I hope to merge in the IBC module once its initial phase is complete and begin work on the light client. Once this is done phase 1 on the roadmap [2] will be complete!
This month had its ups and downs. The major down was that I misunderstood how cosmos-sdk modules (like ibc-go) work. Each module has its own “state tree” which is included in the entire network’s root hash computation. This meant the way in which I had implemented ICS-24 was incorrect.
Now the ups!
Rewrote the initial module [1]
Reimpemented ICS-23 and ICS-24 from the ground up [2][3]
Changed how we compute our root hash [4]
Fixed a deletion bug in the KVStores to allow the SMT to have reliable deletions [5]
Spec’d out ICS-02 and partially ICS-08 [6]
Submitted a PR to cosmos/ics23 to support SMT Exclusion Proofs natively - no more magic! [7]
The new IBC module is looking very good if I do say so myself. The IBC stores now propagate changes throughout the network following the same transaction logic, and are included in the blocks so that the entire network can agree on the shared IBC store state. SMT Exclusion Proofs are now natively supported by the cosmos/ics23 library and the idea to implement ICS-08 (WASM Clients) was made which is super exciting.
Currently in development is the work to propagate local changes to the IBC store, which can already be handled once received. This will mean that any additions/deletions/etc. made to the IBC store locally will be reflected in the entire networks shared IBC state tree. We can then verify the inclusion/exclusion of a specific element in the state tree itself and also verify the state tree was included in the overall networks state hash. This lays the groundwork for the IBC light client implementation to verify our state effectively!
In the month to come I plan on finishing up the base of ICS-24 by implementing the Event Logging system and then also implement ICS-02 (Client Interface) and then begin the work on creating an IBC light client in WASM that can validate the state of our network, but is also portable and easily used on other chains without the need for governance votes to include support for Pocket V1. This decision to use ICS-08 (although still being developed) means that we can easily update IBC light clients if the chain they verify has had consensus breaking updates without the need to update our codebase. This will future proof our IBC implementation for the clients at least.
Once this is done we will have the first phase of our IBC implementation completed. From then I will focus on getting the connections, channels and ports, and IBC packet implementations complete. This would mean the core IBC components are all complete and all that remains is ICS-20 (Fungible Token Transfers) and with that our IBC implementation will bring us into the IBC ecosystem as a full member!
This month went very well, a string of merges on the now finished ICS-23 and ICS-24 PRs as well as the ICS-02 PR going up for review means we are almost at the point of having a functional IBC light client and can begin testing with relayers and integrating with other chains consensus mechanisms!
To give a brief rundown of the PRs merged this month:
As a reminder once we have a Pocket light client available for the cosmos ecosystem and a Tendermint light client available for the Pocket ecosystem we will be able to begin integrating with IBC relayers ideally hermes. This means we can begin testing E2E features such as creating a light client and once the rest of the transport layer is done (connections, channels and ports) we can test E2E everything!
I have scheduled calls with the hermes team to talk about this integration and also ask some questions I have, as well as discuss some interesting ideas around Pocket V1 servicing IBC relays. I have also begun talks with a member of Strangelove Labs who implemented ICS-08 (WASM Clients) for ibc-go in order to ask questions there and discuss the WASM implementations. I hope these calls will not only be very productive but also will help to garner Pocket some attention from the cosmos ecosystem, more than it already has with my current involvement with IBC and ICF. But I also hope this will become the beginning of a longer relationship with these teams.
Overall, this month has gone very well. There is still a lot of work to be done, but each day the milestone of ICS-20 Fungible Token Transfers becomes more and more in view.
This month was spent mostly doing research around Pocket V1’s architecture. One of my roles during this research sprint was looking at IBC in far more depth and the specifics around its implementation. Although @Olshansky is doing an official write up of the protocol teams learnings and outcomes of this research sprint, I can discuss some of the IBC specific learnings, and other events that ocured this month.
Pocket has support!
The ibc-go team at ICF, numerous community members and teams in the IBC ecosystem as well as the Cosmos ecosystem in general seem to really want to help pocket integrate with IBC
This month I reached out to and had calls with:
The Informal System, Hermes relayer team
The Strangelove Labs team (who implemented ICS-08)
Talks with Jacob Gadakian and the Notional DAO team also began and communication channels with these teams have been opened for long term support, and partnerships
Everyone in the IBC ecosystem loves the idea of a framework agnostic ibc-go implementation. However, the task that I have begun, although admired, is a huge undertaking for a single person - let alone the entire ibc-go team themselves!
It has been made clear that in order to get the most support from the existing IBC community a fork of ibc-go, which removes it’s dependency on cosmos-sdk is the ideal implementation
This would enable:
existing projects to be tested against
full feature compatibility out of the box
more reviewers on PRs (as they have better context)
This could be done by introducing interfaces in places where the SDK is used that could be implemented by cosmos-sdk and projects like Pocket in a more generalised way.
Overall, the implementation of IBC with Pocket still has a long way to go, but with the points above it is clear that moving forward we will have support. And as the IBC community is aligned on a non-sdk based Go implementation, a fork of ibc-go would give us the best chance at external (to Pocket) code reviews.
The next steps for Pocket and IBC look goooood baby
As many of you are aware the recent changes to the protocol’s Shannon upgrade mean that the IBC implementation is no longer required as we will be able to use ibc-go out of the box (due to using comos-sdk as part of Rollkit).
This means this Socket is no longer required.
It has been fun working on this but Shannon needs me in a different way now. I do think the agnostic IBC implementation is needed but as it is no longer a requirement of ours, I don’t see Pocket being the ones to do it anymore.
out.
out!
out!