Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Celestia mainnet config #1038

Merged
merged 39 commits into from
Feb 28, 2025
Merged

Celestia mainnet config #1038

merged 39 commits into from
Feb 28, 2025

Conversation

mzabaluev
Copy link
Collaborator

@mzabaluev mzabaluev commented Feb 6, 2025

Resolves #1030

Summary

  • Categories: protocol-units, scripts, util.

Add "mainnet" configuration and setup infrastructure for Celestia DA.

Redo the celestia DA configuration: transpose the network enum and the parameter struct, so that network is a field. This makes for a lot less code duplication.

@l-monninger
Copy link
Collaborator

Next Steps

Testing e2e

Test against Celestia mainnet. Use an arbitrary namespace. You may request TIA from myself.

Key Info

The keys used should be available into the celestia-appd/keys under validator.info and <matching-address>.address. Per #1030 , I would like this to be populated from some value in our config containing serialized or unserialized key material. This makes it easier than brittle file redirection for the moment.

Keyring Naming

It is fine to leave as test, but you can also rename this as you need. I do not believe using a keyring with a name other than "test" actually changes the encoding used.

Providers

  • consensus.lunaroasis.net
  • public-celestia-rpc.numia.xyz
  • rpc.celestia.pops.one

@mzabaluev
Copy link
Collaborator Author

Key Info

The keys used should be available into the celestia-appd/keys under validator.info and <matching-address>.address. Per #1030 , I would like this to be populated from some value in our config containing serialized or unserialized key material. This makes it easier than brittle file redirection for the moment.

The way it can work with the cel-key utility is, we export the key in PGP ASCII armor, protected by a random passphrase generated by setup. Then the cel-key import command can import the key to be consumable by celestia node(s).

Keyring Naming

It is fine to leave as test, but you can also rename this as you need. I do not believe using a keyring with a name other than "test" actually changes the encoding used.

There are no named keyrings, but you can select backends. I think the only backend available on Linux is test (there is also memory, but it's for in-process use).

@mzabaluev
Copy link
Collaborator Author

Per #1030 , I would like this to be populated from some value in our config containing serialized or unserialized key material. This makes it easier than brittle file redirection for the moment.

I have looked in detail into what's available via the provided cel-key tool and cosmos-sdk keyrings.

  • The import/export format used by cel-key is not readily available in Rust libraries for Tendermint or Cosmos. It's possible to recreate with some extra implementation cost.

  • The format of the file-based key store is defined by a Go codec, so it would be fragile to try to import directly into this from Rust unless the format is well understood and stable.

The most feasible integration option to me is to use the key name from the keyring as the configuration value, and rely on setup crates (for local setups) or the infrastructure to provision the key into the keyring as expected by celestia light node.
I have added the light node configuration with the requisite key name in this PR.

@mzabaluev mzabaluev force-pushed the mikhail/celestia-mainnet-config branch from f367a49 to fbe04d1 Compare February 13, 2025 14:32
@mzabaluev mzabaluev changed the base branch from l-monninger/secure-signing-e2e-integration to main February 13, 2025 14:32
@mzabaluev mzabaluev marked this pull request as ready for review February 13, 2025 15:43
The crate is not currently listed in the workspace,
its inclusion impeded by a dependency problem.
@mzabaluev mzabaluev force-pushed the mikhail/celestia-mainnet-config branch from 4046471 to b955c7c Compare February 14, 2025 10:23
To avoid a costly sync from height 0, make the initial height
a config parameter settable by config.
Make the block height fetching routines
do the real thing.
If the Celestia network is not local, don't generate a random chain ID.
Harmonize the format of the namespace string with the one
expected by the celestia CLI: 0x prefix for hex, otherwise base64.
No more expecting quoted base64-encoded string as if it were JSON.
@mzabaluev
Copy link
Collaborator Author

Relevant configuration via environment variables given to the setup binary that creates config for movement-celestia-da-light-node and movement-celestia-light runner:

  • CELESTIA_NETWORK, with values mainnet, mocha, arabica, or local (the default).
  • CELESTIA_NAMESPACE: hexadecimal namespace suffix for a v0 ID (up to 10 bytes) if the value starts with "0x", otherwise decoded as the base64 encoding of the full 29-byte namespace ID.
    • WARNING: the = padding character of base64 is known to be misinterpreted when used in the environment specification in process-compose; use an .env file.
    • If you are testing with public Celestia networks, be sure to pick a randomly generated namespace.
  • CELESTIA_LIGHT_KEYNAME: name of the key in the test cosmos-sdk keyring, that can be provisioned with cel-key. The default key name is "movement_celestia_light".

The command to run the celestia light node (unless using the Movement runner) can be obtained from the runner source code for the respective network.

For Docker, see this guide, including the section on mounting the keyring.

I may have time to add this to the docker-compose files in the repository.

Copy link
Contributor

@musitdev musitdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a practical question. For local execution is it still the same as before?

@mzabaluev
Copy link
Collaborator Author

I have a practical question. For local execution is it still the same as before?

Yes, it should work the same way. I have tested this while working on the branch, but not on the latest commits.

@mzabaluev mzabaluev merged commit 7b6f1f7 into main Feb 28, 2025
121 of 125 checks passed
mcmillennick pushed a commit that referenced this pull request Mar 9, 2025
Co-authored-by: Liam Monninger <l.mak.monninger@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add direct support for Celestia Mainnet Service Compositions
3 participants