spike: interoperability between Cosmos SDK and libp2p

[mudler]

Is your feature request related to a problem? Please describe. We have looked into the Comsos SDK in https://github.com/masa-finance/masa-oracle/issues/595 and we found out that Cosmos mets all the requirements for us in order to implement our own chain and our token, however, the Cosmos SDK implementation relies on gRPC services, which directly communicate with the hosts.

This basically means that nodes participating to the network would have to expose ports to the public, and it would mean a regression in term of usability that lead us before to remove the actor framework ( https://github.com/masa-finance/roadmap/issues/69 ).

Describe the solution you'd like This is a spike ticket, to understand if instead we could relay on libp2p, to bridge the gRPC server of the comsos SDK throught the libp2p transport layer. In such case, we can see masa-oracle libp2p nodes to provide connections for the Cosmos SDK to operate with its own libp2p protocol.

Describe alternatives you've considered Re-implement everything from scratch with libp2p ( https://github.com/masa-finance/masa-oracle/issues/380 )

Additional context

[mcamou]

Initial findings

Bridging gRPC over Libp2p

There are multiple projects that act as bridges between gRPC and Libp2p. For example:

https://github.com/birros/go-libp2p-grpc. This one is fairly easy to integrate. On the Listener side you just need to change the grpc.NewServer() and server.Serve() calls. On the Dial side, you just have to update the parameters to the grpc.Dial() call. The main issue is that it doesn't have a version tag so Go can't install it. However, since it hasn't been updated in a while and is fairly simple (5 source files) it would be easy to maintain our own fork

https://github.com/drgomesp/go-libp2p-grpc. This one does have proper version tags, but integration is a bit more involved. It has its own Server and Client objects, so code changes are more involved.

Modifying the Cosmos SDK

An initial review of the https://github.com/cosmos/cosmos-sdk code shows that the networking code is intertwined fairly deep inside the SDK. To do the appropriate surgery (as mentioned above) we would need to maintain our own fork of the cosmos-sdk project. This being such a large project means that either our fork would be quickly out of date, or we would have an ongoing chore of keeping it up to date with upstream. Neither of these options is practical.

Action plan

@restevens402 and I came up with the following action plan for this spike:

• Study the feasibility of making the cosmos-sdk network transport pluggable.
• If feasible, submit a PR to upstream (hopefully they will accept it?).
• Create a pluggable module that uses libp2p.

For this, we have cloned the cosmos-sdk project into https://github.com/masa-finance/cosmos-sdk.

[mcamou]

After digging through the Cosmos SDK code, I found the following:

• There is a single net.Listen() call outside of tests, in server/grpc/server.go. Following the call stack up, it is called from server/start.go, specifically in the start(...) function. start() calls getAndValidateConfig() to get the serverconfig.Config object. We could inject our object into that and get it propagated to the proper place.
• The bigger problem is with grpc.Dial(). That is called from a bunch of places, but all of them come from protobuf definitions. Replacing them will be a challenge.

However, here's another idea. Since the Cosmos node will always be paired with an Oracle node, we could add a proxy to the Oracle process and point the gRPC node to it. That way, the Cosmos node sends an HTTP/2 request to the proxy, the proxy forwards it to the destination's Oracle node via libp2p, and the destination Oracle node contacts the Cosmos node via HTTP/2. I've started researching the feasibility of this but haven't made much progress yet.