TensorCash Core.

Aus dem Quellcode bauen

Das maßgebliche Artefakt ist der Quellbaum unter services/core-node/bcore/. Die Qt-Wallet wird aus demselben CMake-Target gebaut wie der headless Daemon — beim Konfigurieren -DBUILD_GUI=ON übergeben. Zwei Wege: ein Dockerfile, das den gesamten Stack baut (am einfachsten, isoliert), oder native Abhängigkeiten auf dem Host (schnellere Iteration, kleinerer Image-Footprint).

Weg 1 · Docker (empfohlen)

Das Repository enthält ein mehrstufiges Dockerfile, das das cosign-bridge-Rust-Binary, das ChiaVDF-Python-Wheel und den vollständigen bcore-Daemon plus Qt-Wallet in einem Schritt baut. Auf dem Host muss nur Docker installiert sein. Der Container enthält außerdem Tor für Hidden-Service-Networking und einen VNC-Server, um die GUI bei Bedarf im Container zu betreiben.

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

Nach dem Build den Container starten und den RPC-Port der Wallet (und optional VNC für GUI-Zugriff) freigeben:

# 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

Weg 2 · Native Build

Nimm diesen Weg, wenn du native Binaries direkt auf dem Host willst — ohne Container. Getestet auf macOS 13+ (arm64 / x86_64) und Ubuntu / Debian; Fedora und Arch sind im bcore-Submodul unter doc/build-unix.md dokumentiert.

Clone

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

Abhängigkeiten installieren — macOS

Zuerst Xcode Command Line Tools, dann Homebrew-Pakete.

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

Abhängigkeiten installieren — Linux (Ubuntu / Debian)

Gleicher Ansatz, anderer Paketmanager. Fedora und Arch sind in der vorgelagerten doc/build-unix.md im Repo dokumentiert.

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

Abhängigkeiten installieren — Windows (Cross-Compile)

Native Windows-Builds laufen über MSVC (siehe doc/build-windows-msvc.md). Der schnellere Weg, den die meisten Mitwirkenden nutzen, ist Cross-Compiling von einem Linux-Host (oder WSL) mit dem Mingw-w64-Toolchain plus dem mitgelieferten Depends-System. NSIS wird nur für das .exe-Installer-Target benötigt.

# 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)

Konfigurieren + kompilieren

Auf macOS / Linux ist der Konfigurationsschritt ein einzelner CMake-Aufruf. Unter Windows die vom Depends-Tree erzeugte Toolchain-Datei übergeben.

# 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

Häufige Konfigurations-Flags: -DBUILD_GUI=ON (Qt-Wallet), -DENABLE_WALLET=OFF (Chain-only-Node), -DWITH_ZMQ=ON (ZMQ-Pub/Sub-Topics). Die vollständige Liste mit cmake -B build -LH abrufen.

Cosign-Bridge bauen

Cosign-Funktionen in der Wallet (Geräte-Pair-Signing, federated Multisig) kommunizieren mit einem lokalen Rust-Sidecar namens cosign-bridge über einen lokalen Socket. Der Docker-Weg baut es automatisch; bei nativen Builds wird es mit cargo erzeugt:

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

Starten

Das Qt-Wallet-Binary landet in build/bin/. Die erstmalige Synchronisierung mit mainnet dauert Stunden und schreibt einen mehrere Gigabyte großen Chainstate; für einen schnellen Smoke-Test stattdessen auf ein regtest-Datadir zeigen.

# 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

Den vollständigen lokalen Entwicklungsaufbau inklusive Mock-Validierung und TensorCash-spezifischer RPCs zeigt der regtest-Guide.

Begleitdienste

TensorCash Core ist die Wallet plus ein paar Sidecar-Dienste, mit denen sie kommuniziert. Der Docker-Build oben bündelt sie alle; beim nativen Build stellst du dir die nötigen Dienste je nach gewünschten Features selbst neben dem Qt-Binary zusammen.

Benefaktor-Binaries

Der Quellcode-Build ist der kanonische Weg. Als praktische Alternative veröffentlichen Community-Benefaktoren eigene Builds desselben Quellbaums. Das Projekt produziert, signiert und verteilt keine Binaries — diese sind unabhängige Drittveröffentlichungen, hier nur zur Information aufgeführt. Jeden Benefaktor-Build gegen den eigenen Quellcode-Build verifizieren oder zwischen Benefaktoren querprüfen.

Als Benefaktor gelistet werden: aus einem getaggten Quell-Release bauen, ein SHA-256-Manifest der Artefakte sowie eine abgetrennte PGP-Signatur veröffentlichen und einen Pull Request einreichen, der eine Zeile zu dieser Tabelle hinzufügt.

Benefaktor-Build verifizieren

Zwei Prüfungen. Die erste knüpft den Anspruch des Benefaktors an das heruntergeladene Binary; die zweite verbindet das Binary mit dem Quellcode.

Hash + Signatur

Jeder Benefaktor veröffentlicht eine SHA256SUMS-Datei und eine abgetrennte SHA256SUMS.asc-Signatur. Bestätigen, dass die heruntergeladene Datei mit dem Manifest übereinstimmt und dass das Manifest mit dem veröffentlichten PGP-Schlüssel des Benefaktors signiert ist.

# 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

Querprüfung

Die Signatur eines einzigen Benefaktors beweist nur, dass er für das Binary bürgt — nicht, dass es dem Quellcode entspricht. Zwei Wege, diese Lücke zu schließen: selbst aus dem Quellcode bauen und Hashes vergleichen, oder das Manifest eines zweiten Benefaktors für dasselbe Release-Tag gegenüberstellen. Wenn zwei oder mehr unabhängige Builder identische SHA-256-Werte für dasselbe Artefakt veröffentlichen, liegt ein Nachweis vor, dass der Build aus öffentlichem Quellcode reproduzierbar ist.

So geht's weiter

• regtest-Guide — lokale Entwicklungsumgebung mit Mock-Validierung — plus Walkthroughs für Modellregistrierung und Asset-Emission.
• JSON-RPC-Referenz — die eingebettete Konsole in der Wallet unterstützt jede Methode dieser Referenz.
• Mitmachen — alle weiteren Möglichkeiten zur Teilnahme: Institutionen, Anbieter, Entwickler, Verifizierer, Forscher.