TensorCash Core.

Зібрати з вихідного коду

Канонічний артефакт — вихідне дерево у services/core-node/bcore/. Qt-гаманець будується з того самого CMake-таргету, що й headless-демон — передайте -DBUILD_GUI=ON на етапі конфігурації. Два шляхи: Dockerfile, який збирає весь стек (найпростіше, в ізоляції), або нативні залежності на хості (швидша ітерація, менший розмір образу).

Шлях 1 · Docker (рекомендовано)

У репозиторії є багатоетапний Dockerfile, який збирає Rust-бінарник cosign-bridge, Python-wheel ChiaVDF і повний демон bcore + Qt-гаманець за один прохід. На хості потрібен лише Docker. У контейнер також включено Tor для мережі прихованих сервісів і VNC-сервер — щоб можна було запустити GUI всередині контейнера.

Dockerfile: services/core-node/tor.Dockerfile

git clone --recurse-submodules https://git.tensorcash.org/tensorcash/tensorcash.git
cd tensorcash

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

Після збірки запустіть контейнер, відкривши RPC-порт гаманця та (за потреби) VNC для доступу до GUI:

# 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 задокументовані у doc/build-unix.md підмодуля bcore.

Clone

git clone --recurse-submodules https://git.tensorcash.org/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)

Конфігурація + компіляція

На macOS / Linux етап конфігурації — це один виклик CMake. На Windows передайте файл тулчейна, згенерований деревом залежностей.

# 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

Типові прапори конфігурації: -DBUILD_GUI=ON (Qt-гаманець), -DENABLE_WALLET=OFF (вузол без гаманця), -DWITH_ZMQ=ON (теми ZMQ pub/sub). Запустіть cmake -B build -LH для повного списку.

Збірка cosign bridge

Функції Cosign у гаманці (підписання між пристроями, федеративний multisig) взаємодіють із supутнім Rust-бінарником cosign-bridge через локальний сокет. Шлях через 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 займає кілька годин і записує кілька ГБ chainstate; для швидкого перевірочного тесту вкажіть натомість datadir для regtest.

# 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-бінарником залежно від бажаних функцій.

Бінарники від прихильників

Збірка з вихідного коду — канонічний шлях. Для зручності прихильники спільноти публікують власні збірки того самого вихідного дерева. Проєкт не виробляє, не підписує і не поширює бінарники — це незалежні публікації третіх сторін, наведені тут лише для зручності пошуку. Перевіряйте будь-яку збірку від прихильника щодо власної збірки з вихідного коду або порівнюйте між собою збірки різних прихильників.

Convenience binaries are published by community benefactors and listed in the network directory. Those listings are unverified and not endorsed by the project — always verify a build's PGP signature against the public source (below) before you run it.

Щоб бути включеним до списку прихильників: зберіть із позначеного тегом релізу вихідного коду, опублікуйте SHA-256-маніфест артефактів і окремий PGP-підпис, а потім відкрийте pull request із рядком до цієї таблиці.

Перевірка збірки від прихильника

Два кроки. Перший прив'язує заяву прихильника до завантаженого вами бінарника; другий — бінарник до вихідного коду.

Хеш + підпис

Кожен прихильник публікує файл 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

Взаємна перевірка

Підпис одного прихильника лише підтверджує, що він ручається за бінарник — але не те, що бінарник відповідає вихідному коду. Два способи закрити цей розрив: зберіть самостійно і порівняйте хеші, або звіртеся з маніфестом другого прихильника для того самого тегу релізу. Коли два або більше незалежних збирачів публікують однакові SHA-256 для того самого артефакту — це свідчить про відтворюваність збірки з публічного вихідного коду.

Що далі

• посібник regtest — пісочниця для локальної розробки з імітованою валідацією, покроковими інструкціями з реєстрації моделі та емісії активу.
• Довідник JSON-RPC — вбудована консоль гаманця підтримує кожен метод із цього довідника.
• Долучитися — всі інші способи участі: установи, провайдери, розробники, верифікатори, дослідники.