Polkadot Node rejects IPFS Nodes

[peetzweg]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

The Polkadot SDK's updated libp2p protocol handling uses genesis-hash-based identifiers, breaking compatibility with standard IPFS nodes. This prevents the our storage chain from leveraging the public IPFS Amino DHT network for data distribution.

Our setup

• we have a solo storage chain node running
• it's using the transaction-storage pallet (https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/transaction-storage)
• this pallet makes uploaded data available via ipfs.
• on the same machine as the storage chain node we run a IPFS Kubo instance (https://docs.ipfs.tech/install/command-line/), we use it for it's ipfs gateway. So we can access the uploaded blocks of data over http.
• the Kubo instance should connect to the storage node
• we did this by adding the storage chain node multiaddress as a peer into the kubo config or just by doing
• ipfs swarm connect <multiaddrs of storage chain node>

This setup worked flawlessly until we upgraded to a more recent version of polkadot-sdk, from 0e09ad4 (Nov. 7, 2024) to cdf107d (Jan. 9, 2025)

Now I get the following errors in the logs in kubo when I try to ipfs swarm connect <multiaddrs of storage-node>

stream reset

2025-01-28T18:55:57.948+0100    WARN    net/identify    identify/id.go:431      failed to identify 12D3KooWQCkBm1BYtkHpocxCwMgR8yjitEeHGx8spzcDLGt2gkBm: stream reset

And in the logs of the storage chain node I used -lsub-libp2p=trace and found these

Ignoring self-reported address of peer 12D3KooWGsN2yqVZ9kYCncCjkFSNCGEAPN5SSeEqQ1SpGMapi2X6 as remote node is not part of the Kademlia DHT supported by the local node.

025-01-28 18:55:57.949 TRACE tokio-runtime-worker sub-libp2p::discovery: Ignoring self-reported address of peer 12D3KooWGsN2yqVZ9kYCncCjkFSNCGEAPN5SSeEqQ1SpGMapi2X6 as remote node is not 
part of the Kademlia DHT supported by the local node.    
2025-01-28 18:55:57.949 TRACE tokio-runtime-worker sub-libp2p: ping time with PeerId("12D3KooWGsN2yqVZ9kYCncCjkFSNCGEAPN5SSeEqQ1SpGMapi2X6"): 106.625µs    

Steps to reproduce

You can reproduce it by running a

./polkadot --ipfs-server -lsub-libp2p=trace

And trying to to connect it to your swarm
ipfs swarm connect <multiaddress of polkadot node>

It will say connect and shows briefly in the peers list but will disconnect shortly after.
ipfs swarm peers

[lexnv]

The IPFS daemon responds on the following protocols:

protocols: ["/ipfs/bitswap", "/ipfs/bitswap/1.0.0", "/ipfs/bitswap/1.1.0", "/ipfs/bitswap/1.2.0", "/ipfs/id/1.0.0", "/ipfs/id/push/1.0.0", "/ipfs/kad/1.0.0", "/ipfs/lan/kad/1.0.0", "/ipfs/ping/1.0.0", "/libp2p/autonat/1.0.0", "/libp2p/autonat/2/dial-back", "/libp2p/autonat/2/dial-request", "/libp2p/circuit/relay/0.2.0/hop", "/libp2p/circuit/relay/0.2.0/stop", "/libp2p/dcutr", "/x/"]

The polkadot network backend initiates the following protocol negotiations:

2025-02-12 13:35:44.586 TRACE tokio-runtime-worker litep2p::tcp::connection: substream opened substream_id=SubstreamId(3)
2025-02-12 13:35:44.586 TRACE tokio-runtime-worker litep2p::tcp::connection: negotiating protocols protocols=["/8213c1503114b49f52f3af4c17e526d974b11e5b4e278fc3e2a116dfe1847eaa/kad", "/dot/kad"]

2025-02-12 13:35:44.586 DEBUG tokio-runtime-worker litep2p::multistream-select: Dialer: Proposed protocol: /8213c1503114b49f52f3af4c17e526d974b11e5b4e278fc3e2a116dfe1847eaa/kad
2025-02-12 13:35:44.586 TRACE tokio-runtime-worker litep2p::multistream-select: Received message: NotAvailable
2025-02-12 13:35:44.586 DEBUG tokio-runtime-worker litep2p::multistream-select: Dialer: Received rejection of protocol: /8213c1503114b49f52f3af4c17e526d974b11e5b4e278fc3e2a116dfe1847eaa/kad


2025-02-12 13:35:44.586 DEBUG tokio-runtime-worker litep2p::multistream-select: Dialer: Proposed protocol: /dot/kad
2025-02-12 13:35:44.587 TRACE tokio-runtime-worker litep2p::multistream-select: Received message: NotAvailable
2025-02-12 13:35:44.587 DEBUG tokio-runtime-worker litep2p::multistream-select: Dialer: Received rejection of protocol: /dot/kad
2025-02-12 13:35:44.587 DEBUG tokio-runtime-worker litep2p::tcp::connection: failed to accept/open substream error=FailedToNegotiate { protocol: Some(Allocated("/8213c1503114b49f52f3af4c17e526d974b11e5b4e278fc3e2a116dfe1847eaa/kad")), substream_id: Some(SubstreamId(3)), error: NegotiationError(MultistreamSelectError(Failed)) }
2025-02-12 13:35:44.587 DEBUG tokio-runtime-worker litep2p::protocol-set: failed to open substream protocol=/8213c1503114b49f52f3af4c17e526d974b11e5b4e278fc3e2a116dfe1847eaa/kad substream=SubstreamId(3) error=NegotiationError(MultistreamSelectError(Failed))

2025-02-12 13:35:44.587 TRACE tokio-runtime-worker litep2p::ipfs::kademlia: failed to open substream substream_id=SubstreamId(3) error=NegotiationError(MultistreamSelectError(Failed))
2025-02-12 13:35:44.587 TRACE tokio-runtime-worker litep2p::ipfs::kademlia: disconnect peer peer=PeerId("12D3KooWCRdUApUzabsmxxTTwRueZmNE2xjRfEkXJAQNAGM2vUj1") query=Some(QueryId(4))

I've created this branch to double check the IPFS connectivity: #7551.
From my side this connect the polkadot binary to the IPFS network, however Im not entirely sure if that completely solves your issue

@peetzweg Could you please build the polkadot binary from the above branch and tell me if that solves the issue for you? 🙏
Please start the node with --network-backend litep2p

If that's the case we'd need to expose the ipfs/kad/1.0.0 enablement under a CLI flag.