Fails to bootstrap with mocha default nodes

[austinabell]

Noticing that running the node on Mocha, it seems like the default multiaddrs used are failing:

 2024-03-12T17:58:02.993501Z DEBUG Transport::dial{address=/dns4/da-bridge-mocha-4-2.celestia-mocha.com/udp/2121/quic/p2p/12D3KooWK6wJkScGQniymdWtBwBuU36n6BRXp9rCDDUD6P5gJr3G}: libp2p_dns: Dial error: MultiaddrNotSupported("/ip4/151.115.15.166/udp/2121/quic/p2p/12D3KooWK6wJkScGQniymdWtBwBuU36n6BRXp9rCDDUD6P5gJr3G").

I haven't dug into if that's referring to the node or client that doesn't support this protocol. I also couldn't find any info on updated bootnodes to use with this node.

Also couldn't use a go node for this integration because the docker compose seems to be only setup for devnet and also #222 blocks the blob submission for a local node (unclear which version devnet is using right now).

[zvolin]

regarding #222, it is already fixed on the main branch, however there are still git dependencies there that we need to make release for the first time until we release new version to crates io. The devnet setup is using 0.13.1 currently

[zvolin]

The bootstrap lists seem identical

https://github.com/celestiaorg/celestia-node/blob/main/nodebuilder/p2p/bootstrap.go#L39
https://github.com/eigerco/lumina/blob/main/node/src/network.rs#L68

[zvolin]

I can reproduce this using last released version of lumina-node and the git version works correctly. The first difference I can see here is that the older bootstrap peers (from released version) use quic but the newer one use tcp

[austinabell]

Ah, I see, yeah running with:

lumina node --network mocha --bootnode /dns4/da-bridge-mocha-4.celestia-mocha.com/tcp/2121/p2p/12D3KooWCBAbQbJSpCpCGKzqz3rAN4ixYbc63K68zJg9aisuAajg

Works for now. Installed from latest released version, so that seems like it will be fixed with the next release. Thanks for pointing to the bootstrap node multiaddr list!

[zvolin]

yeah, you can run with all bootnodes set explicitely:

lumina node -n mocha \
  -b /dns4/da-bridge-mocha-4.celestia-mocha.com/tcp/2121/p2p/12D3KooWCBAbQbJSpCpCGKzqz3rAN4ixYbc63K68zJg9aisuAajg \
  -b /dns4/da-bridge-mocha-4-2.celestia-mocha.com/tcp/2121/p2p/12D3KooWK6wJkScGQniymdWtBwBuU36n6BRXp9rCDDUD6P5gJr3G \
  -b /dns4/da-full-1-mocha-4.celestia-mocha.com/tcp/2121/p2p/12D3KooWCUHPLqQXZzpTx1x3TAsdn3vYmTNDhzg66yG8hqoxGGN8 \
  -b /dns4/da-full-2-mocha-4.celestia-mocha.com/tcp/2121/p2p/12D3KooWR6SHsXPkkvhCRn6vp1RqSefgaT1X1nMNvrVjU2o3GoYy

it's still interesting, because lookup reports that those nodes listen for quic protocol, just not quic but quic-v1:

❯ libp2p-lookup direct --address /dns4/da-full-1-mocha-4.celestia-mocha.com/tcp/2121/p2p/12D3KooWCUHPLqQXZzpTx1x3TAsdn3vYmTNDhzg66yG8hqoxGGN8
Local peer id: 12D3KooWLuVbKfW6U4uPZngTGuyJXcs68rT1Asobeo4MDRkBjPEt
Lookup for peer with id PeerId("12D3KooWCUHPLqQXZzpTx1x3TAsdn3vYmTNDhzg66yG8hqoxGGN8") succeeded.

Protocol version: ""
Agent version: "celestia-mocha-4"
Observed address: "/ip4/100.64.61.32/tcp/59370"
Listen addresses:
        - "/ip4/100.64.29.57/tcp/2121"
        - "/ip4/100.64.29.57/udp/2121/quic-v1"
        - "/ip4/151.115.15.168/tcp/2121"
        - "/ip4/151.115.74.172/tcp/2121"
        - "/ip4/151.115.74.172/udp/2121/quic-v1"
        - "/ip4/151.115.74.172/udp/32527/quic-v1"

however if I switch to quic-v1 in bootstrappers on the release tag, it still doesn't work, but on the other hand addresses which report the quic-v1 readiness report also different IP, so that may be the case (missed that there are pairs)

[austinabell]

Thanks for the context on the bootnodes.

Sorry if this exists somewhere in docs that I just can't find. Is there support for setting up an auth key to use the Rust client with? I'm only seeing options for the go client.

Simply just trying to submit a blob on mocha, and this particular setup I'm unfamiliar with.

[zvolin]

we don't yet support submitting blobs unfortunately, for this case you will still need to run go node. We plan to support this, but it's likely gonna happen after next milestone. For now the only way I see is to run the go node and you could use celestia-rpc crate to submit blobs via rpc

[zvolin]

If by client you mean rpc client tho, then there is an example in docs

[austinabell]

we don't yet support submitting blobs unfortunately, for this case you will still need to run go node. We plan to support this, but it's likely gonna happen after next milestone. For now the only way I see is to run the go node and you could use celestia-rpc crate to submit blobs via rpc

And is there a setup for initializing the auth header documented anywhere? Seems the go docs have the more common pattern of signing client side, and I'm wondering if the path to getting the Rust client to work on mocha is to just modify the local docker configuration in this repo to handle more networks (specifically Mocha)?

[zvolin]

it should be as simple as running the go node like:

celestia light init --p2p.network mocha
celestia light start --core.ip <mocha-core-ip> --p2p.network mocha
export TOKEN=$(celestia light auth admin --p2p.network mocha)

and then following the docs linked above with token in teh corresponding env var. Just as I said before, if mocha nodes are already running 0.13.1, you'll need the git version of rpc to have correct api alignments

[zvolin]

btw I haven't checked that but I think that if you want to use the currently released version of celestia-rpc you can just run go node on tag v0.12.4. The changes between those versions affect mostly the RPC interface but those should be compatible on the P2P level (and cosmos-sdk, as submitting blobs doesn't happen through p2p yet)

[austinabell]

btw I haven't checked that but I think that if you want to use the currently released version of celestia-rpc you can just run go node on tag v0.12.4. The changes between those versions affect mostly the RPC interface but those should be compatible on the P2P level (and cosmos-sdk, as submitting blobs doesn't happen through p2p yet)

This errors on the client:

Caused by:
    ErrorObject { code: ServerError(0), message: "fatal error calling 'blob.Submit': panic in rpc method 'blob.Submit': runtime error: invalid memory address or nil pointer dereference", data: None }

and on the node:

2024-03-12T15:42:55.558-0400    ERROR   rpc     [email protected]/handler.go:276        panic in rpc method 'blob.Submit': runtime error: invalid memory address or nil pointer dereference
github.com/filecoin-project/go-jsonrpc.doCall.func1
        /Users/austinabell/golang/pkg/mod/github.com/filecoin-project/[email protected]/handler.go:276
runtime.gopanic
        /opt/homebrew/opt/go/libexec/src/runtime/panic.go:914
runtime.panicmem
        /opt/homebrew/opt/go/libexec/src/runtime/panic.go:261
runtime.sigpanic
        /opt/homebrew/opt/go/libexec/src/runtime/signal_unix.go:861
github.com/celestiaorg/celestia-node/state.(*CoreAccessor).getMinGasPrice
        /Users/austinabell/development/github.com/celestiaorg/celestia-node/state/core_access.go:555
github.com/celestiaorg/celestia-node/state.(*CoreAccessor).SubmitPayForBlob
        /Users/austinabell/development/github.com/celestiaorg/celestia-node/state/core_access.go:219
...

Seems like it's simple enough to debug, I just don't need this urgently, so I'll just come back once there are compatible versions, unless there is a known workaround here.

[zvolin]

Seems like it's simple enough to debug, I just don't need this urgently, so I'll just come back once there are compatible versions

As I said it was my guess 😅 since this works with #222 I think it's okay to just wait for release then as we should handle it soon

[zvolin]

we've managed to release new version, sorry it took so long