Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Isolate cosmos-sdk dependency in a separate Go submodule

オープン
#24 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
go
領域
build-system

調査の方向性

まずルートの go.mod と提案されている submit/go.mod の境界を調査し、次に cmd/apex/main.go と指定された submit ファイルを確認します。core インターフェースが cosmos-sdk 型を避けられる方法と、2 つのモジュールを独立してテストする方法を検証します。cosmos-sdk が submit/ に分離され、read-only core がそれなしでビルドでき、submission インターフェースが引き続き利用可能であれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Summary

The core apex codebase must not import cosmos-sdk. All cosmos-sdk-dependent code (transaction construction, signing, gas estimation) must live in an isolated Go submodule with its own go.mod to prevent dependency contamination.

Problem

cosmos-sdk pulls in a massive transitive dependency tree:

  • cometbft (celestia's fork: celestiaorg/celestia-core)
  • iavl, cosmos-db, cosmos-proto
  • gRPC, protobuf, gogoproto
  • celestia-app's own forks of cosmos-sdk

Importing it into the core module would:

  • Bloat build times and binary size for read-only deployments that don't need tx submission
  • Create version pinning headaches against celestia's forked dependencies
  • Make upgrades painful — a celestia-app bump could break unrelated apex code
  • Bleed transitive deps into packages that have no business depending on them

Design

apex/
├── go.mod                      # core module — zero cosmos-sdk
├── cmd/apex/main.go
├── pkg/
│   ├── store/                  # SQLite — clean
│   ├── sync/                   # backfill, streaming — clean
│   ├── fetch/                  # DataFetcher, CelestiaNodeFetcher — clean
│   └── api/                    # JSON-RPC, gRPC server — clean
└── submit/
    ├── go.mod                  # separate Go module, imports cosmos-sdk here
    ├── go.sum
    ├── signer.go               # key loading, tx signing (SIGN_MODE_DIRECT)
    ├── msg.go                  # MsgPayForBlobs construction
    ├── gas.go                  # deterministic gas estimation
    ├── broadcast.go            # BroadcastTxSync + confirmation polling
    └── submit.go               # public API: Submit(blobs) -> TxResult
Boundary interface

The core module defines a submission interface with no cosmos-sdk types:

// In pkg/submit/iface.go (core module, no cosmos-sdk imports)
type BlobSubmitter interface {
    Submit(ctx context.Context, blobs []RawBlob, opts SubmitOpts) (*TxResult, error)
}

type RawBlob struct {
    Namespace []byte
    Data      []byte
}

type TxResult struct {
    TxHash   string
    Height   int64
    GasUsed  int64
    Code     uint32
    Error    string
}

The submit/ submodule implements this interface, converting RawBlob to cosmos-sdk types internally.

Build integration
  • cmd/apex/main.go imports submit/ only when submission is configured
  • Read-only deployments compile without the submodule (build tags or conditional import)
  • CI tests the core module and submit module independently

Related issues

  • #4 — Custom tx submission client (parent)
  • #8 — Nonce management (lives in submit/)
  • #9 — Keyring and signing (lives in submit/)
  • #17 — Gas estimation (lives in submit/)
  • #18 — Rate limiting / circuit breaker (can live in core, no cosmos-sdk needed)
  • #19 — Tx confirmation lifecycle (lives in submit/)
  • #5 — Multi-account support (lives in submit/)
主要言語
Go
スター
4
フォーク
0
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

evstack/apex のほかの issue

evstack/apex の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。