feat(deps): bump to latest celestia #176
Conversation
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
WalkthroughThis pull request focuses on updating dependencies and simplifying the project's configuration across multiple files. The changes include upgrading Celestia-related libraries and binaries to newer versions, modifying configuration scripts for bridge, light, and validator nodes, and removing Protobuf-related installation steps. The modifications aim to streamline the project's dependency management and CI/CD workflow, with a particular emphasis on updating to the latest Celestia ecosystem components. Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
ci/Dockerfile.lightnode (1)
13-14: LGTM! Version consistency maintained with bridge nodeGood practice maintaining version consistency between light and bridge nodes (both using celestia-node:v0.20.4).
Consider adding version constraints in a central configuration file to ensure all nodes stay in sync during future updates.
ci/run-bridge.sh (1)
Line range hint
99-100: Consider documenting migration steps for existing deploymentsThe coordinated changes across Cargo.toml and CI scripts represent a significant upgrade of Celestia components:
- Major version bumps in dependencies (0.4.0 → 0.8.0/0.9.0)
- Simplified configuration paths in both light and bridge nodes
Consider:
- Adding migration documentation for existing deployments
- Creating a rollback plan in case of issues
- Adding integration tests to verify the new setup
Also applies to: 14-14, 14-14
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (10)
.github/workflows/ci.yml(0 hunks)Cargo.toml(1 hunks)ci/Dockerfile.bridge(1 hunks)ci/Dockerfile.lightnode(1 hunks)ci/Dockerfile.validator(1 hunks)ci/run-bridge.sh(1 hunks)ci/run-lightnode.sh(1 hunks)ci/run-validator.sh(2 hunks)crates/da/src/celestia.rs(3 hunks)justfile(0 hunks)
💤 Files with no reviewable changes (2)
- .github/workflows/ci.yml
- justfile
🔇 Additional comments (9)
ci/Dockerfile.bridge (1)
13-14: Verify compatibility between bridge node v0.20.4 and validator v3.0.2
The bridge node is being updated to v0.20.4 while the validator is using v3.0.2. Let's verify version compatibility.
Consider documenting the tested version combinations in a compatibility matrix.
✅ Verification successful
Based on the results, I can generate the final response as we have clear evidence of compatibility. The release notes show that celestia-node v0.20.4 specifically upgraded to celestia-app v3.0.2, which is the exact version being used by the validator.
✅ Bridge node v0.20.4 is compatible with validator v3.0.2
The update to celestia-node v0.20.4 is appropriate because:
- It's the latest stable release
- It explicitly upgraded to celestia-app v3.0.2 in its changelog
- It includes important security patches
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check latest versions and compatibility requirements
# Check latest celestia-node versions
gh api \
-H "Accept: application/vnd.github+json" \
repos/celestiaorg/celestia-node/releases | jq -r '.[].tag_name' | head -n 5
# Check compatibility requirements in release notes
gh api \
-H "Accept: application/vnd.github+json" \
repos/celestiaorg/celestia-node/releases | \
jq -r '.[] | select(.tag_name=="v0.20.4") | .body'
Length of output: 963
Cargo.toml (1)
99-100: Verify compatibility between celestia-rpc and celestia-types versions
The major version jumps (0.4.0 → 0.8.0/0.9.0) could introduce breaking changes. Let's verify the compatibility and latest versions.
✅ Verification successful
Versions are up-to-date and commonly used together
The specified versions (celestia-rpc 0.8.0 and celestia-types 0.9.0) are the latest available versions on crates.io, indicating that the update aligns with the most recent stable releases. The presence of these versions together in the codebase suggests they are designed to work together.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check latest versions and compatibility
echo "Checking latest versions on crates.io..."
curl -s https://crates.io/api/v1/crates/celestia-rpc | jq -r '.crate.max_version'
curl -s https://crates.io/api/v1/crates/celestia-types | jq -r '.crate.max_version'
# Check if these versions are commonly used together
echo "Checking for projects using these versions together..."
rg -A 3 'celestia-rpc.*0\.8\.0' | rg 'celestia-types.*0\.9\.0'
Length of output: 489
ci/run-lightnode.sh (1)
14-14: Verify configuration path changes with Celestia's migration guide
The change from network-specific config path ($CELESTIA_HOME/.celestia-light-$P2P_NETWORK) to $CELESTIA_HOME is a breaking change that could impact existing deployments.
ci/run-bridge.sh (1)
14-14: Verify bridge node compatibility with new configuration path
The configuration path change matches the light node changes, maintaining consistency. However, we should verify bridge-specific configurations.
✅ Verification successful
Configuration path change is compatible with bridge node requirements
The verification shows that the bridge node configuration follows the same pattern as other node types (light, validator) and uses the standard $CELESTIA_HOME environment variable consistently. The bridge script handles configuration appropriately with:
- Standard initialization via
celestia bridge init - Proper config file modifications for genesis hash and trusted peers
- No bridge-specific configuration path requirements
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if bridge node has any special config requirements
echo "Checking for bridge-specific config patterns..."
rg -i "bridge.*config|config.*bridge" README.md docs/
# Verify if the new celestia version supports this config structure
echo "Checking celestia bridge help output for config options..."
celestia bridge --help | rg -i "config|home"
# Check for any remaining references to old path structure
echo "Checking for missed path updates..."
rg -i "\.celestia-bridge-.*network"
Length of output: 598
Script:
#!/bin/bash
# Let's check for any bridge-specific configuration patterns in the repository
echo "Checking for bridge configuration patterns..."
rg -i "bridge.*config|config.*bridge"
# Check for any references to bridge configuration directories
echo "Checking for bridge configuration directory references..."
rg -i "celestia-bridge|bridge.*dir"
# Look for any bridge-specific environment variables or settings
echo "Checking for bridge-specific environment variables..."
rg -i "CELESTIA_BRIDGE|BRIDGE_.*CONFIG"
# Check the script itself and related files for configuration handling
echo "Examining bridge script and related files..."
fd -e sh -x cat {}
Length of output: 16476
ci/run-validator.sh (2)
194-195: LGTM: Transaction indexing enabled
Enabling the KV transaction indexer is a good practice for validator nodes as it allows querying historical transactions.
209-209: Verify the necessity of --force-no-bbr flag
The addition of --force-no-bbr flag appears to be related to the Celestia version update. Please confirm if this flag is required for the new version and document its implications.
crates/da/src/celestia.rs (3)
5-5: LGTM: Added AppVersion import for Celestia upgrade
The addition of AppVersion import from celestia_types aligns with the dependency upgrade.
163-163: LGTM: Consistent application of AppVersion::V3
The AppVersion::V3 is correctly and consistently applied in both blob creation calls:
submit_finalized_epochmethod (line 163)submit_transactionsmethod (line 224)
The error handling remains robust with appropriate context and error mapping.
Also applies to: 224-224
163-163: Verify AppVersion::V3 is the recommended version
Let's confirm that AppVersion::V3 is the recommended version for the updated Celestia dependency.
Also applies to: 224-224
✅ Verification successful
Based on the search results, I can now generate the final response. The evidence shows that:
- The codebase consistently uses
AppVersion::V3in both occurrences of Blob creation - The celestia-types dependency is pinned to version "=0.9.0" in the workspace
- There are no comments or documentation suggesting any other version should be used
- The AppVersion is imported from celestia-types, indicating it's part of the official Celestia SDK
AppVersion::V3 is correctly used
The code is using the appropriate version as it's consistently applied across the codebase and matches the pinned Celestia dependency version (0.9.0). The exact version match in dependencies suggests intentional version control.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for AppVersion usage patterns in the codebase
ast-grep --pattern 'AppVersion::$_'
# Look for any documentation about AppVersion
rg -i "appversion" -A 3 -B 3
# Check Celestia's documentation
fd -e md -e txt | xargs rg -i "app.*version.*v3"
Length of output: 1716
Script:
#!/bin/bash
# Let's check the Blob struct and its implementation to understand the available versions
ast-grep --pattern 'enum AppVersion {
$$$
}'
# Search for any version-related constants or documentation
rg -i "version" -A 5 -B 5 crates/da/src/celestia.rs
# Check if there are any version-related tests
rg -i "test.*version|version.*test" crates/da/src/
Length of output: 1432
Script:
#!/bin/bash
# Let's check the dependencies in Cargo.toml for celestia-types version
rg -A 10 "celestia.*types" Cargo.toml crates/*/Cargo.toml
# Let's check for any changelog or release notes
fd -e md | xargs rg -i "celestia.*changelog|celestia.*release"
# Let's look for any comments or documentation about blob versions
rg -i "blob.*version|version.*blob" -A 3 -B 3
Length of output: 68249
Closes #172
Summary by CodeRabbit
New Features
celestia-rpcandcelestia-typesto newer versions.crates/zk/sp1.--force-no-bbrfor the validator startup process.Bug Fixes
Chores
justfile.