/wallet
TensorCash Core.
Десктопный Qt-кошелёк для цепочки TensorCash — потомок Bitcoin Core с поддержкой нативных активов и встроенной JSON-RPC-консолью. Соберите его сами из публичного дерева исходников (через Docker или нативно) или возьмите готовый бинарник от одного из благодетелей ниже.
Тур
Та же раскладка, что у Bitcoin Core, плюс TensorCash-вкладки под нативные активы и эмиссию. Нажмите на плитку, чтобы открыть изображение в полном разрешении.
Сборка из исходников
Канонический артефакт — дерево исходников в services/core-node/bcore/. Qt-кошелёк собирается из той же CMake-цели, что и фоновый демон: передайте -DBUILD_GUI=ON на этапе конфигурации. Два пути: Dockerfile, который собирает весь стек (проще, в песочнице), или нативные зависимости на вашей машине (быстрее цикл правок, образ компактнее).
Путь 1 · Docker (рекомендуется)
В репозитории есть многостадийный Dockerfile, который за один проход собирает Rust-бинарник cosign-bridge, Python-пакет ChiaVDF и полный демон 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-порт кошелька и (при необходимости) 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.
Клонирование
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)Конфигурация и компиляция
На macOS / Linux конфигурация — это один вызов CMake. На 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Полезные флаги: -DBUILD_GUI=ON (Qt-кошелёк), -DENABLE_WALLET=OFF (только узел без кошелька), -DWITH_ZMQ=ON (темы ZMQ pub/sub). Полный список — cmake -B build -LH.
Сборка cosign bridge
Функции cosign в кошельке (подписание с сопряжённого устройства, федеративный мультисиг) общаются через локальный сокет с Rust-бинарником-sidecar под названием 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; для быстрой проверки направьте кошелёк на 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 Core — это сам кошелёк плюс небольшой набор sidecar-сервисов вокруг него. Docker-сборка включает их все; при нативной сборке возьмите только те, которые нужны под выбранные функции.
| Сервис | Путь к исходникам | Что делает | Нужен для |
|---|---|---|---|
| cosign-bridge | services/core-node/cosign-bridge/ | Локальный Rust-sidecar, отвечающий за сопряжение cosign / федеративную подпись (SPAKE2 + Noise поверх WebSocket). Обрабатывает сценарии с сопряжёнными устройствами на стороне Qt-кошелька. | Функции cosign (подписание с нескольких устройств, федеративный мультисиг) |
| ChiaVDF | shared-utils/chiavdf/ | Verifiable Delay Function для валидации цепочки. Собирается как Python-пакет вместе с демоном. | Валидация любого блока (mainnet, testnet или regtest) |
| core-node REST | services/core-node/src/ | Небольшая REST-поверхность рядом с JSON-RPC-сервером. Отдаёт метаданные моделей и метрики узла. | Интеграции с провайдерами; самому кошельку не нужен |
| verification-api | services/verification-api/ | OSS-сервис верификации. Кошелёк не обращается к нему напрямую — это делает bcore, когда выставлен -validationapi=real. | Реальная (не моковая) валидация блоков в продакшене |
| miner-api | services/miner-api/ | Мост между цепочкой и движком инференса (llama.cpp / vLLM). Производит доказательство инференса, которое попадает в блок. | Майнинг (обслуживание инференса и генерация блоков) |
Бинарники от благодетелей
Канонический путь — сборка из исходников. Для удобства участники сообщества — благодетели — публикуют собственные сборки того же дерева исходников. Проект не производит, не подписывает и не распространяет бинарники: это независимые сторонние публикации, перечисленные здесь только для удобства поиска. Сверьте любую сборку благодетеля со своей собственной сборкой из исходников — или сопоставьте сборки разных благодетелей между собой.
| Благодетель | Платформы | PGP-ключ | Примечания |
|---|---|---|---|
| TensorCash | macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64) | pending | Сборки из публичного дерева исходников. К каждому релизу рядом с бинарниками публикуются SHA-256-манифест и отделённая PGP-подпись. |
Чтобы попасть в список благодетелей: соберите бинарник из тегированного релиза исходников, опубликуйте 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 — встроенная консоль кошелька понимает любой метод из этого справочника.
- Участвовать — все остальные способы участия: институты, провайдеры, разработчики, верификаторы, исследователи.