Closed austinabell closed 2 days ago
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
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
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!
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 (missed that there are pairs)quic-v1
readiness report also different IP, so that may be the case
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.
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
If by client you mean rpc client tho, then there is an example in docs
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)?
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
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)
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 tagv0.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 go-jsonrpc@v0.3.1/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/go-jsonrpc@v0.3.1/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.
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 :sweat_smile: since this works with #222 I think it's okay to just wait for release then as we should handle it soon
we've managed to release new version, sorry it took so long
Noticing that running the node on Mocha, it seems like the default multiaddrs used are failing:
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 https://github.com/eigerco/lumina/issues/222 blocks the blob submission for a local node (unclear which version devnet is using right now).