TensorCash Core.

Compila dai sorgenti

L'artefatto canonico è l'albero dei sorgenti in services/core-node/bcore/. Il wallet Qt si compila dallo stesso target CMake del daemon headless — basta passare -DBUILD_GUI=ON in fase di configurazione. Due percorsi: un Dockerfile che compila l'intero stack (più semplice, isolato), oppure le dipendenze native sull'host (iterazione più rapida, immagine più leggera).

Percorso 1 · Docker (consigliato)

Il repository include un Dockerfile multi-stage che compila il binario Rust cosign-bridge, la wheel Python ChiaVDF e il daemon bcore completo con il wallet Qt in un unico passaggio. Serve solo Docker sull'host. Il container include anche Tor per la rete hidden-service e un server VNC per eseguire la GUI dentro al container.

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

Dopo la build, avvia il container esponendo la porta RPC del wallet e (opzionalmente) VNC per l'accesso alla 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

Percorso 2 · Build nativa

Scegli questa strada se vuoi binari nativi sull'host senza container. Testato su macOS 13+ (arm64 / x86_64) e Ubuntu / Debian; Fedora e Arch sono documentati nel doc/build-unix.md all'interno del sottomodulo bcore.

Clone

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

Installa le dipendenze — macOS

Prima Xcode Command Line Tools, poi i pacchetti 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

Installa le dipendenze — Linux (Ubuntu / Debian)

Stessa logica, gestore di pacchetti diverso. Fedora e Arch sono nel doc/build-unix.md upstream all'interno del repository.

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

Installa le dipendenze — Windows (cross-compilazione)

Le build native per Windows passano per MSVC (vedi doc/build-windows-msvc.md). Il percorso più veloce, usato dalla maggior parte dei contributor, è la cross-compilazione da un host Linux (o WSL) con il toolchain Mingw-w64 e il sistema depends incluso. NSIS serve solo per il target installer .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)

Configura + compila

Su macOS / Linux la configurazione è una singola invocazione CMake. Su Windows passa il file toolchain generato dall'albero 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

Flag di configurazione comuni: -DBUILD_GUI=ON (wallet Qt), -DENABLE_WALLET=OFF (nodo solo chain), -DWITH_ZMQ=ON (topic ZMQ pub/sub). Esegui cmake -B build -LH per la lista completa.

Compila il cosign bridge

Le funzionalità Cosign nel wallet (firma tra dispositivi accoppiati, multisig federato) comunicano con un sidecar Rust chiamato cosign-bridge tramite un socket locale. Il percorso Docker lo compila automaticamente; per le build native lo produci con 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.

Esegui

Il binario del wallet Qt si trova in build/bin/. La sincronizzazione iniziale con la mainnet richiede ore e scrive gigabyte di chainstate; per un test rapido, puntalo su 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

Consulta la guida regtest per l'ambiente di sviluppo locale completo, tra cui la validazione mock e gli RPC specifici di TensorCash.

Servizi di supporto

TensorCash Core è il wallet, più un piccolo gruppo di servizi sidecar con cui dialoga. La build Docker li include tutti; se compili in modo nativo, questi sono i componenti da affiancare al binario Qt in base alle funzionalità che ti servono.

Binari dei benefattori

Compilare dai sorgenti è il percorso canonico. Per comodità, i benefattori della comunità pubblicano le proprie build dallo stesso albero sorgente. Il progetto non produce, firma né distribuisce binari — si tratta di pubblicazioni indipendenti di terze parti, elencate qui a solo titolo informativo. Verifica qualsiasi build di un benefattore confrontandola con la tua build dai sorgenti, oppure incrociala con quella di un altro benefattore.

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.

Per essere elencato come benefattore: compila da una release sorgente con tag, pubblica un manifesto SHA-256 dei tuoi artefatti e una firma PGP separata, poi apri una pull request aggiungendo una riga a questa tabella.

Verificare una build di un benefattore

Due controlli. Il primo collega la dichiarazione del benefattore al binario scaricato; il secondo collega il binario ai sorgenti.

Hash + firma

Ogni benefattore pubblica un file SHA256SUMS e una firma SHA256SUMS.asc separata. Verifica che il file scaricato corrisponda al manifesto, e che il manifesto sia firmato con la chiave PGP pubblicata dal benefattore.

# 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

Incrocio

La firma di un singolo benefattore dimostra solo che lui si fa garante del binario — non che il binario corrisponda ai sorgenti. Due modi per colmare questa lacuna: compilare dai sorgenti e confrontare gli hash, oppure confrontare con il manifesto di un secondo benefattore per lo stesso tag di release. Quando due o più builder indipendenti pubblicano SHA-256 identici per lo stesso artefatto, hai la prova che la build è riproducibile dai sorgenti pubblici.

Da qui in poi

• guida regtest — sandbox di sviluppo locale con validazione mock, walkthrough per registrazione del modello ed emissione di asset.
• Reference JSON-RPC — la console integrata nel wallet supporta ogni metodo di questa reference.
• Partecipa — tutti gli altri modi di partecipare: istituzioni, provider, sviluppatori, verificatori, ricercatori.