/wallet

TensorCash Core.

Un wallet desktop Qt pour la chaîne TensorCash — issu de Bitcoin Core, avec prise en charge des actifs natifs et une console JSON-RPC intégrée. Compilez-le vous-même depuis le dépôt public (avec Docker ou en natif), ou récupérez ci-dessous un binaire de commodité publié par un bienfaiteur.

Tour

Même interface que Bitcoin Core, avec des onglets TensorCash dédiés aux actifs natifs et à l'émission. Cliquez sur une tuile pour voir l'image en pleine résolution.

Vue d'ensemble · solde, transactions récentes, état du réseau

1 / 12

Compiler depuis les sources

L'artefact canonique est le dépôt source dans services/core-node/bcore/. Le wallet Qt se compile depuis la même cible CMake que le daemon headless — passez -DBUILD_GUI=ON au moment de la configuration. Deux approches : un Dockerfile qui compile toute la pile (le plus simple, isolé en sandbox), ou les dépendances natives sur votre hôte (itération plus rapide, empreinte image plus légère).

Voie 1 · Docker (recommandé)

Le dépôt embarque un Dockerfile multi-étapes qui compile le binaire Rust cosign-bridge, la wheel Python ChiaVDF et le daemon bcore complet + wallet Qt en une seule passe. Il vous suffit d'avoir Docker installé sur l'hôte. Le conteneur inclut aussi Tor pour la mise en réseau via service caché et un serveur VNC, pour exécuter l'interface graphique à l'intérieur du conteneur si vous le souhaitez.

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 \
  .

Une fois la compilation terminée, lancez le conteneur en exposant le port RPC du wallet et (en option) VNC pour l'accès 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

Voie 2 · Compilation native

À utiliser si vous voulez des binaires natifs sur votre hôte sans conteneur. Testé sur macOS 13+ (arm64 / x86_64) et Ubuntu / Debian ; Fedora et Arch sont documentés dans doc/build-unix.md du sous-module bcore.

Cloner

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

Installer les dépendances — macOS

Xcode Command Line Tools d'abord, puis les paquets 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

Installer les dépendances — Linux (Ubuntu / Debian)

Même principe, gestionnaire de paquets différent. Pour Fedora et Arch, voir doc/build-unix.md (upstream) dans le dépôt.

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

Installer les dépendances — Windows (cross-compilation)

Les compilations Windows natives passent par MSVC (voir doc/build-windows-msvc.md). La voie la plus rapide, retenue par la plupart des contributeurs, est la cross-compilation depuis un hôte Linux (ou WSL) avec la chaîne d'outils Mingw-w64 et le système de dépendances intégré. NSIS n'est nécessaire que pour la cible installeur .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)

Configurer + compiler

Sur macOS / Linux, la configuration tient en une seule invocation CMake. Sur Windows, passez le fichier toolchain généré par l'arbre de dépendances.

# 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

Options de configuration courantes : -DBUILD_GUI=ON (wallet Qt), -DENABLE_WALLET=OFF (nœud de chaîne seul, sans wallet), -DWITH_ZMQ=ON (topics ZMQ pub/sub). Lancez cmake -B build -LH pour la liste complète.

Compiler le cosign bridge

Les fonctions Cosign du wallet (signature par appareil appairé, multisig fédéré) communiquent avec un binaire Rust sidecar appelé cosign-bridge via une socket locale. La voie Docker le compile automatiquement ; en compilation native, vous le produisez avec 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.

Lancer

Le binaire du wallet Qt atterrit dans build/bin/. La première synchronisation avec mainnet prend des heures et écrit un chainstate de plusieurs Go ; pour un test rapide, pointez-le plutôt sur un 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

Consultez le guide regtest pour la configuration complète de développement local, avec validation simulée et les RPCs spécifiques à TensorCash.

Services compagnons

TensorCash Core, c'est le wallet plus un petit ensemble de services sidecar avec lesquels il dialogue. La compilation Docker ci-dessus les regroupe tous ; en compilation native, voici ce que vous assemblez aux côtés du binaire Qt selon les fonctionnalités souhaitées.

Service	Chemin source	Rôle	Nécessaire pour
cosign-bridge	services/core-node/cosign-bridge/	Sidecar Rust local qui gère l'appairage cosign / signature fédérée (SPAKE2 + Noise over WebSocket). Sert de façade aux flux d'appareils appairés depuis le wallet Qt.	Fonctions Cosign (signature multi-appareil, multisig fédéré)
ChiaVDF	shared-utils/chiavdf/	Verifiable Delay Function utilisée par la validation de la chaîne. Compilée comme wheel Python lors de la construction du daemon.	Validation de tout bloc (mainnet, testnet ou regtest)
core-node REST	services/core-node/src/	Interface REST légère adossée au serveur JSON-RPC. Expose les métadonnées de modèle et les métriques du nœud.	Intégrations fournisseur ; le wallet lui-même n'en a pas besoin
verification-api	services/verification-api/	Service de vérification OSS. Le wallet ne l'appelle pas directement — bcore le fait, quand -validationapi=real.	Validation de blocs réelle (non simulée) en production
miner-api	services/miner-api/	Fait le pont entre la chaîne et le moteur d'inférence (llama.cpp / vLLM). Producteur de la preuve d'inférence qui s'intègre dans un bloc.	Minage (servir l'inférence + produire des blocs)

Binaires des bienfaiteurs

Compiler depuis les sources reste la voie canonique. Par commodité, des bienfaiteurs de la communauté publient leurs propres compilations du même dépôt source. Le projet ne produit, ne signe ni ne distribue de binaires — il s'agit de publications tierces indépendantes, listées ici à titre informatif uniquement. Vérifiez tout binaire de bienfaiteur en le confrontant à votre propre compilation depuis les sources, ou en croisant les références entre plusieurs bienfaiteurs.

Bienfaiteur	Plateformes	Clé PGP	Notes
TensorCash	macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64)	pending	Compile depuis le dépôt source public. Chaque version est accompagnée d'un manifeste SHA-256 et d'une signature PGP détachée aux côtés des binaires.

Pour être listé comme bienfaiteur : compilez depuis une version source taguée, publiez un manifeste SHA-256 de vos artefacts et une signature PGP détachée, puis ouvrez une pull request qui ajoute une ligne à ce tableau.

Vérifier un binaire de bienfaiteur

Deux vérifications. La première relie la déclaration du bienfaiteur au binaire que vous avez téléchargé ; la seconde relie le binaire au code source.

Hash + signature

Chaque bienfaiteur publie un fichier SHA256SUMS et une signature SHA256SUMS.asc détachée. Confirmez que le fichier téléchargé correspond bien au manifeste, et que le manifeste est signé par la clé PGP publique du bienfaiteur.

# 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

Recoupement

La signature d'un seul bienfaiteur prouve uniquement qu'il se porte garant du binaire — pas que ce binaire correspond au code source. Deux façons de combler cet écart : compilez depuis les sources vous-même et comparez les hashes, ou comparez avec le manifeste d'un second bienfaiteur pour le même tag de version. Lorsque deux compilateurs indépendants ou plus publient des SHA-256 identiques pour le même artefact, vous avez la preuve que la compilation est reproductible depuis les sources publiques.

Et ensuite

guide regtest — bac à sable de développement local avec validation simulée, et parcours d'enregistrement de modèles et d'émission d'actifs.
Référence JSON-RPC — la console intégrée du wallet prend en charge toutes les méthodes de cette référence.
S'impliquer — toutes les autres façons de participer : institutions, fournisseurs, développeurs, vérificateurs, chercheurs.