Conversation
WalkthroughGenesis configuration updated: chain_id and initial_height changed; state_hash replaced; validator set switched to a single ed25519 validator with a new pubkey and explicit type/power; leader key aligned to the new validator; migration block unchanged; other top-level parameters unchanged. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests
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. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Time Submission Status
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
configs/network/v2/genesis.json (2)
21-24: disabled_gas_costs: true — confirm this is intentional.
- Leaving gas disabled is fine for test/dev, but in prod it can enable DoS vectors and unbounded resource usage even with a 6MB block size.
- If prod, consider enabling gas or adding compensating controls (rate limits, stricter mempool/tx caps).
Confirm intended environment (dev/test/prod) for tn-v2.1. I can propose safe defaults accordingly.
6-11: Confirm single-validator set for tn-v2.1The genesis file currently defines exactly one validator with power 1 and a valid 64-hex ed25519 pubkey:
- File:
configs/network/v2/genesis.json(validators array length: 1)- Pubkey format: 64 hex characters (validated)
Please confirm this single-validator configuration is intentional for this network tier. If this setup is intended for a production environment, consider expanding to at least a 3+ validator set to avoid a single point of consensus failure.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
configs/network/v2/genesis.json(1 hunks)
🧰 Additional context used
🪛 Gitleaks (8.27.2)
configs/network/v2/genesis.json
19-19: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (4)
configs/network/v2/genesis.json (4)
17-20: Leader key aligns with validator pubkey — good.The leader.key matches validators[0].pubkey and type is consistent (ed25519). No issues here.
19-19: Gitleaks “Generic API Key” is a false positive on a public ed25519 key.This is a public key (64 hex chars), not a credential/secret. To reduce CI noise, consider an allowlist for this file/path in your Gitleaks config.
Example .gitleaks.toml snippet:
[allowlist] paths = [ "configs/network/v2/genesis.json" ]Alternative: narrow the rule only for JSON keys named "leader.key" and "validators[].pubkey" if your ruleset supports targeted exclusions.
2-3: Chain ID bump verification successful
- Genesis JSON is valid (
jqsyntax check passed).- No leftover references to the old
tn-v2ID outside ofconfigs/network/v2/genesis.json.- Other
chain_idvalues in staging dirs are unrelated and expected.You’re all set to merge.
12-16: Verify state_hash and migration semantic correctness
- File: configs/network/v2/genesis.json
- state_hash is a valid 64-character hexadecimal.
- migration window is start_height=0 → end_height=0.
Please confirm that this
state_hashexactly matches the app-hash produced by the application at your chosen initial height (e.g., height 195391) to ensure semantic correctness.
Description
Related Problem
related to #67 (comment)
How Has This Been Tested?
Summary by CodeRabbit