docs: add clarity to statesync #1958
Conversation
WalkthroughThe documentation for configuring state sync in the consensus node was revised to improve clarity and readability. Additional explanations and formatting were introduced, including warning and tip blocks to emphasize the requirement for multiple RPC endpoints. The example configuration for Changes
Possibly related PRs
Suggested reviewers
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
|
| 2. Retrieve light blocks for verification | ||
| ::: | ||
|
|
||
| In `$HOME/.celestia-app/config/config.toml`, set the RPC endpoints: |
There was a problem hiding this comment.
I think we'd also need to leave a note here to set trusted height and hash, because it isn't clear to me. if you set height/hash higher than 1, for example at 5000, do you not sync anything before that height 5000?
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
how-to-guides/consensus-node.md (1)
228-234: Clarify placeholder values for state sync config
It may be unclear thattrust_heightandtrust_hashmust be replaced with actual values from a trusted RPC. Consider updating these lines with explicit placeholder comments to guide users.rpc_servers = "rpc.example1.com:port,rpc.example2.com:port" # Replace with actual RPC endpoints -trust_height = 0 -trust_hash = "" +trust_height = <trusted_header_height> # Replace with the trusted header height (e.g., 123456) +trust_hash = "<trusted_block_hash>" # Replace with the trusted block hash returned by /block
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
how-to-guides/consensus-node.md(2 hunks)
🔇 Additional comments (2)
how-to-guides/consensus-node.md (2)
222-226: Add warning for multi-endpoint requirement
The new warning block clearly emphasizes the need for at least two RPC endpoints, preventing misconfiguration during state sync.
246-248: Good use of tip to reinforce best practices
This tip block nicely reminds users that more RPC endpoints improve fraud detection.
adlerjohn
requested review from
rootulp,
cmwaters and
evan-forbes
and removed request for
adlerjohn
| To their respective fields. At least two different rpc endpoints should be provided. | ||
| The more, the greater the chance of detecting any fraudulent behavior. | ||
| ::: tip | ||
| The more RPC endpoints you provide, the greater the chance of detecting any fraudulent behavior. |
There was a problem hiding this comment.
is this true? if there are more than 2 endpoints provided, do we check them all? What happens if we do and say 1/10 endpoints is down?
also, if we are making the assumption that we are not eclipsed attacked, presumably we would either construct or someone would gossip some double signing, no?
Overview
Statesync section needs more clarity around what the user needs to set. From what was written (and from not reading closely enough), I thought I didn't need to set up RPCs.
Summary by CodeRabbit