-
Notifications
You must be signed in to change notification settings - Fork 86
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
Celestia mainnet config #1038
Conversation
Next StepsTesting e2eTest against Celestia mainnet. Use an arbitrary namespace. You may request TIA from myself. Key InfoThe keys used should be available into the Keyring NamingIt 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 Providers
|
The way it can work with the
There are no named keyrings, but you can select backends. I think the only backend available on Linux is |
I have looked in detail into what's available via the provided cel-key tool and cosmos-sdk keyrings.
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. |
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.
The crate name has been changed recently.
When "celestia light init ..." is run in setup, the options need to include --keyring.backend.
f367a49
to
fbe04d1
Compare
The crate is not currently listed in the workspace, its inclusion impeded by a dependency problem.
4046471
to
b955c7c
Compare
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.
Relevant configuration via environment variables given to the setup binary that creates config for movement-celestia-da-light-node and movement-celestia-light runner:
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. |
…movementlabsxyz/movement into mikhail/celestia-mainnet-config
Also rename the .celestia-mainnet-trusted docker-compose overlay to .celestia-mainnet because we're running the local node.
A string starting with 0x needs quotes, otherwise it's treated as a number in YAML.
…movementlabsxyz/movement into mikhail/celestia-mainnet-config
There was a problem hiding this 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?
Yes, it should work the same way. I have tested this while working on the branch, but not on the latest commits. |
Co-authored-by: Liam Monninger <l.mak.monninger@gmail.com>
Resolves #1030
Summary
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.