[cosmos-plugin] Complete Cosmos Hub Snapshot-Based devnet

[kangeunchan]

Enhancement Description

• One-line description (release-note style): Finish and harden the Cosmos Hub plugin so devnet-builder can reliably create and run snapshot-based devnets from Cosmos Hub mainnet and testnet.
• Scope type: End-to-end plugin completion and integration hardening

Background

devnet-builder already supports production workflows for stable networks, but the Cosmos plugin started as an example-level implementation.

This issue tracks:

• Remaining work required to declare Cosmos plugin completion

Scope

• Implement ModifyGenesis and ModifyGenesisFile core logic
  • File: examples/cosmos-plugin/internal/plugin/genesis.go
  • Includes validator-set replacement, staking/slashing/distribution cleanup, governance parameter tuning, and bank/supply mutation logic
• Implement baseline GenerateDevnet flow
  • File: examples/cosmos-plugin/internal/plugin/devnet.go
  • Includes validator directory creation, key generation, gentx generation, collect-gentxs, and final genesis output
• Implement real RPC methods (replace dummy responses)
  • File: examples/cosmos-plugin/internal/plugin/rpc.go
  • Includes block height, governance params, proposal lookup, health checks, wait-for-block polling, and upgrade plan retrieval
• Configure snapshot/RPC endpoints and Docker/TOML overrides
  • Files: examples/cosmos-plugin/internal/plugin/module.go, examples/cosmos-plugin/internal/plugin/config_overrides.go
  • Includes network endpoint selection, Docker image/tag/home settings, and Cosmos-specific config/app TOML overrides
• Finalize genesis option propagation across adapter boundaries
  • Ensure ports.GenesisModifyOptions -> network.GenesisOptions preserves required fields in both in-memory and file-based paths
  • Files: internal/application/devnet/provision.go, internal/di/factory.go, internal/infrastructure/network/adapter.go
  • Note: cmd/devnet-builder/plugin_adapter.go path was removed/refactored
• Decide and enforce account-funding contract (AddAccounts) at interface/proto level
  • Files: pkg/network/interface.go, pkg/network/plugin/network.proto, pkg/network/plugin/grpc_server.go, pkg/network/plugin/grpc_client.go
• Complete runtime wiring for plugin-first Cosmos RPC path
  • Ensure DI factory passes plugin module into RPC client creation path so implemented plugin RPC methods are actually used at runtime
  • Files: internal/di/factory.go, internal/infrastructure/rpc/cosmos_client.go
• Harden endpoint strategy for provider outages
  • Verify mainnet/testnet endpoint reliability and add fallback behavior where needed
  • Files: examples/cosmos-plugin/internal/plugin/*, internal/infrastructure/genesis/fetcher.go
• Complete Docker/runtime compatibility hardening
  • Verify --home behavior, container mount consistency, command assumptions, and startup compatibility across runtime layers
  • Files: internal/daemon/runtime/docker.go, internal/application/devnet/run.go, internal/infrastructure/node/docker.go, internal/infrastructure/nodeconfig/initializer.go
• Complete regression and E2E validation with evidence
  • Unit/adapter/runtime wiring tests have been strengthened
  • Mainnet/testnet runtime evidence (block production/tx/status/logs) is still pending

Non-Goals

• Building a generalized multi-chain plugin framework change beyond what Cosmos plugin completion requires (moved to separate issue)
• Large architectural refactor unrelated to Cosmos plugin delivery (moved to separate issue)
• Introducing new CLI surface area not required for Cosmos plugin completion (moved to separate issue)

Risks and Open Questions

• Should test account funding be guaranteed by plugin contract or treated as optional behavior?
• Are current public snapshot providers stable enough for CI and repeated local automation?
• Do we need stronger fallback semantics for snapshot and RPC provider failover before calling this production-ready?

Validation Plan

Unit and Integration Checks

• ASDF_GOLANG_VERSION=1.24.0 go test ./examples/cosmos-plugin/...
• Add targeted tests for large-genesis file-based path behavior
• Add adapter mapping tests for genesis options at each boundary
• Add runtime wiring tests confirming plugin-first RPC path selection

End-to-End Checks

• devnet-builder deploy --blockchain cosmos --network mainnet
• devnet-builder deploy --blockchain cosmos --network testnet
• Verify block production after startup
• Verify transaction submission from funded test account
• Verify devnet-builder status and devnet-builder logs behavior

Evidence Required in Issue Updates

• Command output snippets for both mainnet and testnet deploy flows
• Block height progression proof
• At least one successful tx hash and confirmation output
• Notes on any fallback behavior triggered during snapshot/RPC resolution

Acceptance Criteria

• Mainnet snapshot-based deploy succeeds and network starts producing blocks
• Testnet snapshot-based deploy succeeds and network starts producing blocks
• Genesis modification produces a bootable devnet genesis without startup panic
• Plugin RPC methods are used in runtime path and return real chain data
• Docker and local runtime modes both start Cosmos nodes with correct home/config paths
• status and logs commands operate normally after deployment
• Test account transaction flow is successful end-to-end

Deliverables

• Merged Cosmos plugin code for genesis/devnet/RPC/config functionality
• Merged tests covering failure paths and integration boundaries
• Updated documentation for operational usage and known constraints
• Closure comment with validation evidence and residual risk summary

[qj0r9j0vc2]

Hey @kangeunchan can you create feature step by step with seperated PR please?

I think this features work area is really large.

so I think you need to create multiple PRs and also work with draft PR.

[kangeunchan]

@qj0r9j0vc2
Thanks for the feedback.

I agree the scope is large, and I also want to reduce review burden by splitting the work.

One caveat is that this branch is not a single isolated feature — it includes several tightly-coupled changes:

• Cosmos plugin implementation/refactor (genesis/devnet/rpc/snapshot)
• User customization surface (API/YAML/CLI)
• AddAccounts contract change across the full pipeline (interface/proto/grpc/adapter/provision/plugin)
• Runtime wiring + docker/snapshot stabilization
• Significant test additions

In particular, the AddAccounts contract change needs the cross-layer updates to land together to remain buildable/runnable. If we split it too granularly by layer, we’ll likely end up with intermediate PRs that don’t compile or don’t work end-to-end.

So instead of fully independent PRs, I propose stacked Draft PRs grouped by runnable units, so you can review step-by-step while keeping each step in a coherent state. I’ll restructure the current branch accordingly and open them in order (with clear dependencies and a merge sequence).

[kangeunchan]

Using Cosmos Hub mainnet/testnet snapshots to bootstrap by “generating a huge genesis (several GB up to ~10GB) and injecting it into a new chain via InitChain/InitGenesis” can crash during the CometBFT state DB write/compaction path (default goleveldb + snappy), because it can exceed the effective single block/batch size limits and trigger panic: snappy: decoded block is too large. This is not something we can fundamentally eliminate by hardening the plugin’s internal logic (ModifyGenesis/GenerateDevnet/RPC implementations, TOML/Docker overrides, option propagation, etc.); it ultimately requires changing the bootstrap strategy to avoid “huge genesis import” entirely.