TensorCash Core.

ソースからビルド

正規の成果物は services/core-node/bcore/ のソースツリーです。Qt ウォレットはヘッドレスデーモンと同じ CMake ターゲットからビルドします — configure 時に -DBUILD_GUI=ON を渡してください。方法は 2 つ: スタック全体をビルドする Dockerfile（最も簡単、サンドボックス化済み）か、ホストにネイティブ依存関係を入れる方法（イテレーションが速く、イメージフットプリントも小さい）です。

方法 1 · Docker（推奨）

リポジトリにはマルチステージの Dockerfile が同梱されており、cosign-bridge の Rust バイナリ、ChiaVDF の Python ホイール、フル bcore デーモン + Qt ウォレットを一括でビルドします。ホストに Docker があるだけで十分です。コンテナには Tor（隠しサービスネットワーク用）と VNC サーバーも含まれているので、コンテナ内で GUI を動かすこともできます。

Dockerfile: services/core-node/tor.Dockerfile

git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash

docker build \
  -f services/core-node/tor.Dockerfile \
  -t tensorcash-core:dev \
  .

ビルド後、ウォレットの RPC ポートを公開し（オプションで GUI アクセス用に VNC も）コンテナを起動します:

# Headless daemon, RPC reachable on host:18332.
docker run --rm -p 18332:18332 \
  -v $HOME/.tensorcash-data:/data \
  tensorcash-core:dev

# With the Qt GUI exposed via VNC on host:5900 (default password in the
# container's vnc.sh — change before any non-localhost binding).
docker run --rm -p 5900:5900 -p 18332:18332 \
  -v $HOME/.tensorcash-data:/data \
  tensorcash-core:dev

方法 2 · ネイティブビルド

コンテナなしでホストにネイティブバイナリが欲しい場合はこちら。macOS 13+（arm64 / x86_64）と Ubuntu / Debian でテスト済み。Fedora と Arch は bcore サブモジュール内の doc/build-unix.md に記載されています。

クローン

git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash/services/core-node/bcore

依存関係のインストール — macOS

まず Xcode Command Line Tools を入れてから、Homebrew パッケージをインストールします。

xcode-select --install   # if not already installed

brew install \
  cmake boost pkgconf libevent \
  qt@6 qrencode \
  zeromq \
  capnp                  # optional, only if you want -DENABLE_IPC=ON

依存関係のインストール — Linux (Ubuntu / Debian)

考え方は同じで、パッケージマネージャが違うだけです。Fedora と Arch はリポジトリ内の upstream doc/build-unix.md を参照してください。

sudo apt-get install -y \
  build-essential cmake pkgconf python3 \
  libevent-dev libboost-dev libsqlite3-dev libzmq3-dev \
  qt6-base-dev qt6-tools-dev qt6-l10n-tools qt6-tools-dev-tools libgl-dev \
  libqrencode-dev

依存関係のインストール — Windows（クロスコンパイル）

Windows ネイティブビルドは MSVC を使います（doc/build-windows-msvc.md 参照）。多くのコントリビューターが選ぶ早い方法は、Linux ホスト（または WSL）から Mingw-w64 ツールチェーンとバンドル済みの depends システムでクロスコンパイルする方法です。NSIS は .exe インストーラターゲットにのみ必要です。

# On a Linux host (or WSL inside Windows):
sudo apt-get install -y g++-mingw-w64-x86-64-posix nsis

# Build the depends tree once.
gmake -C depends HOST=x86_64-w64-mingw32 -j$(nproc)

Configure + コンパイル

macOS / Linux では configure ステップは CMake を 1 回呼び出すだけです。Windows では depends ツリーが生成したツールチェーンファイルを渡します。

# macOS / Linux
cmake -B build -DBUILD_GUI=ON
cmake --build build -j$(getconf _NPROCESSORS_ONLN 2>/dev/null || nproc)

# Windows (cross-compile from Linux/WSL)
cmake -B build --toolchain depends/x86_64-w64-mingw32/toolchain.cmake -DBUILD_GUI=ON
cmake --build build -j$(nproc)
cmake --build build --target deploy   # produces the .exe installer via NSIS

主な configure フラグ: -DBUILD_GUI=ON（Qt ウォレット）、-DENABLE_WALLET=OFF（チェーンのみのノード）、-DWITH_ZMQ=ON（ZMQ pub/sub トピック）。cmake -B build -LH で全リストを確認できます。

cosign ブリッジをビルド

ウォレットの Cosign 機能（ペアデバイス署名、フェデレーテッドマルチシグ）は、ローカルソケット経由で cosign-bridge という Rust バイナリと通信します。Docker パスでは自動的にビルドされます。ネイティブビルドでは cargo で生成します:

# Rust 1.85+ required.
cd services/core-node/cosign-bridge
cargo build --release --bin cosign-bridge --bin cosign-local-relay
# Binaries land in target/release/. Run cosign-bridge alongside the wallet.

起動

Qt ウォレットのバイナリは build/bin/ に生成されます。mainnet に対する初回同期は数時間かかり、マルチ GB のチェーンステートが書き込まれます。手早く動作確認したい場合は regtest datadir を指定してください。

# Smoke test on a private chain — no real coins, no peers, no IBD.
build/bin/bitcoin-qt -regtest -datadir=$HOME/.tensorcash-regtest

# Production: starts initial block download against the live network.
build/bin/bitcoin-qt

モック検証や TensorCash 固有の RPC を含むローカル開発環境の完全なセットアップは、regtest ガイドをご覧ください。

コンパニオンサービス

TensorCash Core はウォレット本体と、それが通信する少数のサイドカーサービスで構成されます。上記の Docker ビルドにはすべて同梱されています。ネイティブビルドの場合は、必要な機能に応じて Qt バイナリと組み合わせて用意してください。

ベネファクターバイナリ

ソースから自分でビルドするのが正規の方法です。利便性のために、コミュニティのベネファクターが同じソースツリーから独自にビルドを公開しています。プロジェクト自身は、バイナリの生成・署名・配布をいっさい行いません。これらはあくまで独立したサードパーティの公開物で、ここでは見つけやすさのためにまとめているだけです。ベネファクターのビルドを使う際は、自分でソースからビルドしたもの、あるいは別のベネファクターのビルドと、必ず突き合わせて確認してください。

ベネファクターとして掲載されるには: タグ付きソースリリースからビルドし、成果物の SHA-256 マニフェストと独立した PGP 署名を公開してから、このテーブルに行を追加するプルリクエストを開いてください。

ベネファクタービルドの検証

確認は 2 段階です。1 つ目は、ベネファクターの主張とダウンロードしたバイナリを結びつけること。2 つ目は、バイナリとソースを結びつけること。

ハッシュ + 署名

各ベネファクターは、SHA256SUMS ファイルと、それに対応する独立した SHA256SUMS.asc 署名を公開しています。ダウンロードしたファイルがマニフェストと一致しているか、そしてマニフェストがベネファクターの公開 PGP キーで署名されているかを確認してください。

# 1. Manifest matches the binary you have on disk.
shasum -a 256 -c SHA256SUMS --ignore-missing

# 2. Manifest is signed by the benefactor's key.
gpg --verify SHA256SUMS.asc SHA256SUMS

クロスリファレンス

ベネファクター 1 人の署名が証明できるのは、そのベネファクター自身がバイナリを保証している、という事実だけ。バイナリがソースと一致しているかは、別の話です。このギャップを埋める方法は 2 つあります。自分でソースからビルドしてハッシュを比べるか、同じリリースタグに対する別のベネファクターのマニフェストと突き合わせるか。2 人以上の独立したビルダーが同じ成果物に対して同一の SHA-256 を公開していれば、公開ソースから再現可能なビルドである証拠になります。

次のステップ

• regtest ガイド — モック検証、モデル登録、資産発行のウォークスルーを含むローカル開発サンドボックス。
• JSON-RPC リファレンス — ウォレット内蔵のコンソールは、このリファレンスに載るすべてのメソッドに対応しています。
• 参加する — そのほかの参加の仕方 — 機関、プロバイダ、開発者、検証者、研究者。