feat(katana): add support for sovereign mode for init command - #3101
Conversation
|
Ohayo, sensei! Below is the updated summary of the changes with the requested sections. WalkthroughThe changes update the initialization process for chain configuration. The Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Configurator
participant OutcomeHandler
User ->> CLI: Provide chain configuration and options
CLI ->> Configurator: Parse InitArgs (validate id, check sovereign flag)
Configurator -->> CLI: Process settlement and sovereign options
CLI ->> OutcomeHandler: Generate outcome (PersistentOutcome or SovereignOutcome)
OutcomeHandler -->> CLI: Return AnyOutcome result
CLI -->> User: Display initialization result
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 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
Documentation and Community
|
![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 (3)
crates/katana/messaging/src/lib.rs (1)
139-141: Ohayo sensei, consider returning an error instead of panicking.
Panics can crash the entire node unexpectedly. Handling it gracefully could improve stability.bin/katana/src/cli/init/prompt.rs (2)
186-186: Ohayo sensei, consider returning aVecinstead ofOption<Vec>.
The function always returnsSome(...); clarifying the type might simplify usage.
229-229: Ohayo sensei, always returningSome(...)indicatesOptionisn’t strictly necessary.
Refactoring the function to returnVeccould improve readability.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
bin/katana/src/cli/init/mod.rs(5 hunks)bin/katana/src/cli/init/prompt.rs(6 hunks)crates/katana/chain-spec/src/lib.rs(1 hunks)crates/katana/messaging/src/lib.rs(1 hunks)crates/katana/node/src/lib.rs(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: fmt
🔇 Additional comments (26)
crates/katana/chain-spec/src/lib.rs (1)
104-108: Ohayo sensei, the newSovereignvariant is nicely introduced.
No issues here; it provides a future extension point for DA syncing.crates/katana/node/src/lib.rs (1)
232-234: Ohayo sensei, consider using a fixed gas approach for sovereign settlement.
Relying on external sampling might be misleading when there’s no actual external settlement chain.bin/katana/src/cli/init/prompt.rs (7)
17-17: Ohayo sensei, new imports look good.
They correctly reference the updated outcome types.
22-22: Ohayo sensei, the broaderAnyOutcomereturn type looks good.
This flexible approach helps accommodate both persistent and sovereign outcomes.
40-40: Ohayo sensei, addingSovereignto the enum is consistent.
Smooth integration for the new settlement chain type.
52-52: Ohayo sensei, enumeratingSovereignin options is aligned with new functionality.
No problems spotted here.
65-73: Ohayo sensei, the sovereign flow looks well-structured.
ReturningSovereignOutcomeis clear and distinct.
173-173: Ohayo sensei, collecting slot paymasters is a helpful addition.
This ensures consistent paymaster logic across setups.
175-184: Ohayo sensei, formingPersistentOutcomehere is neat.
It centralizes all necessary state for a persistent chain.bin/katana/src/cli/init/mod.rs (17)
30-38: Ohayo sensei! Potential contradiction in theidfield configuration.
The doc comment states that an emptyidis not allowed, but#[arg(default_value = "")]implies it can start empty. This might be intentional for prompting the user, but please confirm if there's a need to enforce a non-empty string before reaching the prompt logic.
40-40: Ohayo sensei! Nice doc clarification.
The description for the settlement chain setup is concise and helps users understand the configuration details.
45-45: Ohayo sensei! Great documentation.
This doc comment clearly states the purpose of the settlement account address.
50-50: Ohayo sensei! Good detail on the private key usage.
The comment clarifies how the private key is used for core contract configuration.
55-57: Ohayo sensei! Clear doc for settlement contract handling.
Explains how the contract might be deployed or reused, which is helpful for new contributors.
62-64: Ohayo sensei! Good explanation ofsettlement_contract_deployed_block.
Ensures that Katana knows how to gather messages from the correct block onward.
69-78: Ohayo sensei! Well-structured introduction of the sovereign mode.
The#[arg(conflicts_with_all = [...])]approach is concise and prevents invalid usage alongside settlement fields.
98-106: Ohayo sensei! Settlement matching logic is well-handled.
Switching toSettlementLayer::Sovereignwhen the outcome is sovereign is clear and predictable. Great addition!
109-109: Ohayo sensei! Neat chain ID parsing.
Parsing output's chain ID helps ensure we store the correct chain spec. Looks good.
114-117: Ohayo sensei! Slot paymasters integration is nicely modular.
This block effectively extends the genesis for paymasters without disturbing other logic.
135-137: Ohayo sensei! Cleaner return type forconfigure_from_args.
ReturningOption<anyhow::Result<AnyOutcome>>is a good step to accommodate both persistent and sovereign flows.
138-143: Ohayo sensei! Sovereign outcome initialization is straightforward.
Creating aSovereignOutcomewhensovereignis set keeps the logic concise.
193-201: Ohayo sensei! Solid handling ofPersistentOutcome.
Unwrapping settlement arguments confidently works well, given Clap’s strict requirement checks.
208-213: Ohayo sensei! Splitting outcomes intoAnyOutcomeis a neat architectural move.
Having an enum to unify possible outcomes simplifies downstream logic.
215-230: Ohayo sensei! Useful methods onAnyOutcome.
Exposingid()andslot_paymasters()ensures flexible, ergonomic usage for both outcome variants.
232-240: Ohayo sensei!SovereignOutcomestruct creation is well-defined.
The separation is clean and clarifies the data needed for a sovereign chain.
242-260: Ohayo sensei!PersistentOutcomestruct is well-structured.
All necessary fields for the settlement configuration are logically grouped, promoting clarity.
glihm
changed the title
init command
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3101 +/- ##
==========================================
- Coverage 57.21% 57.19% -0.03%
==========================================
Files 446 446
Lines 60618 60685 +67
==========================================
+ Hits 34685 34709 +24
- Misses 25933 25976 +43 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@kariy thank you sensei for the review and fixes. 🙏 |
2 participants
Currently, Katana only supports the
initcommand for persistent rollup, which can be cumbersome for users that only wants to send proofs on a DA layer using sovereign mode.This PR aims at proposing a simplified
katana initflow for sovereign rollup, to ensure that Katana can be started in provable mode without providing settlement information.Summary by CodeRabbit
New Features
Documentation