/wallet

TensorCash Core.

Portfel desktopowy oparty na Qt dla sieci TensorCash — wywodzący się z Bitcoin Core, z obsługą aktywów natywnych i wbudowaną konsolą JSON-RPC. Zbuduj go samodzielnie z publicznego drzewa źródeł (przez Docker lub natywnie) albo pobierz gotową binarkę opublikowaną przez benefaktora.

Tour

Taki sam układ jak Bitcoin Core, z zakładkami TensorCash dla aktywów natywnych i emisji. Kliknij kafelek, by zobaczyć obraz w pełnej rozdzielczości.

Przegląd · saldo, ostatnie transakcje, stan sieci

1 / 12

Buduj ze źródeł

Kanonicznym artefaktem jest drzewo źródeł w services/core-node/bcore/. Portfel Qt buduje się z tego samego celu CMake co bezgłowy daemon — przekaż -DBUILD_GUI=ON przy konfiguracji. Dwie drogi: Dockerfile, który buduje cały stos (najprościej, w sandboxie), albo zależności natywne na hoście (szybsza iteracja, mniejszy ślad obrazu).

Ścieżka 1 · Docker (zalecana)

Repozytorium zawiera wieloetapowy Dockerfile, który buduje w jednym kroku binarny plik Rust cosign-bridge, wheel Python ChiaVDF oraz pełny daemon bcore i portfel Qt. Na hoście potrzeba tylko zainstalowanego Dockera. Kontener zawiera też Tor dla sieci ukrytych usług oraz serwer VNC, jeśli chcesz uruchamiać GUI wewnątrz kontenera.

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

Po zbudowaniu uruchom kontener, wystawiając port RPC portfela i opcjonalnie VNC dla dostępu do 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

Ścieżka 2 · Budowa natywna

Wybierz tę opcję, jeśli chcesz natywnych binarek na hoście bez kontenera. Testowane na macOS 13+ (arm64 / x86_64) i Ubuntu / Debian; Fedora i Arch są udokumentowane w doc/build-unix.md wewnątrz submodułu bcore.

Klonuj

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

Zainstaluj zależności — macOS

Najpierw Xcode Command Line Tools, potem pakiety 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

Zainstaluj zależności — Linux (Ubuntu / Debian)

Ten sam pomysł, inny menedżer pakietów. Fedora i Arch żyją w upstream doc/build-unix.md w repozytorium.

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

Zainstaluj zależności — Windows (kompilacja krzyżowa)

Natywne buildy Windows idą przez MSVC (patrz doc/build-windows-msvc.md). Szybszą ścieżką, z której korzysta większość kontrybutorów, jest kompilacja krzyżowa z hosta Linux (lub WSL) z użyciem toolchainu Mingw-w64 oraz bundled depends. NSIS jest potrzebny tylko dla celu instalatora .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)

Konfiguruj + kompiluj

Na macOS / Linux konfiguracja to jedno wywołanie CMake. Na Windows przekaż plik toolchainu wygenerowany przez drzewo 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

Popularne flagi konfiguracji: -DBUILD_GUI=ON (portfel Qt), -DENABLE_WALLET=OFF (node bez portfela), -DWITH_ZMQ=ON (tematy pub/sub ZMQ). Uruchom cmake -B build -LH, by zobaczyć pełną listę.

Zbuduj mostek cosign

Funkcje cosign w portfelu (podpisywanie parowane, federated multisig) komunikują się z pomocniczym binarnym plikiem Rust zwanym cosign-bridge przez lokalny socket. Ścieżka Docker buduje go automatycznie; przy budowie natywnej produkujesz go przez 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.

Uruchom

Binarka portfela Qt trafia do build/bin/. Pierwsza synchronizacja z mainnetu trwa godziny i zapisuje chainstate o rozmiarze wielu GB; do szybkiego testu wskaż mu zamiast tego katalog danych 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

Zajrzyj do przewodnika regtest, by poznać pełną konfigurację local-development z mockowaną walidacją i RPC-ami specyficznymi dla TensorCash.

Usługi towarzyszące

TensorCash Core to portfel plus niewielki zestaw usług pomocniczych, z którymi się komunikuje. Docker build powyżej bundluje je wszystkie; jeśli budujesz natywnie, oto co składasz obok binarki Qt w zależności od potrzebnych funkcji.

Usługa	Ścieżka źródłowa	Co robi	Potrzebne do
cosign-bridge	services/core-node/cosign-bridge/	Lokalny sidecar Rust obsługujący parowanie cosign / federated-signing (SPAKE2 + Noise przez WebSocket). Obsługuje przepływy parowania urządzeń z portfela Qt.	Funkcje cosign (podpisywanie wielo-urządzeniowe, federated multisig)
ChiaVDF	shared-utils/chiavdf/	Verifiable Delay Function używana przez walidację łańcucha. Budowana jako wheel Python podczas budowy daemona.	Walidacja dowolnego bloku (mainnet, testnet lub regtest)
core-node REST	services/core-node/src/	Mały interfejs REST obok serwera JSON-RPC. Udostępnia metadane modelu i metryki węzła.	Integracje z dostawcami; sam portfel tego nie potrzebuje
verification-api	services/verification-api/	Otwartoźródłowa usługa weryfikacji. Portfel nie wywołuje jej bezpośrednio — robi to bcore, gdy -validationapi=real.	Prawdziwa (nie-mockowana) walidacja bloków w produkcji
miner-api	services/miner-api/	Łączy łańcuch z silnikiem inferencji (llama.cpp / vLLM). Produkuje dowód inferencji, który staje się częścią bloku.	Wydobycie (obsługa inferencji + produkcja bloków)

Binarki od benefaktorów

Budowa ze źródeł to kanoniczna ścieżka. Dla wygody, benefaktorzy ze społeczności publikują własne buildy tego samego drzewa źródeł. Projekt nie produkuje, nie podpisuje ani nie dystrybuuje binarek — to niezależne publikacje stron trzecich, wymienione tutaj wyłącznie informacyjnie. Zweryfikuj każdą binarkę benefaktora względem własnego builda ze źródeł lub porównaj między benefaktorami.

Benefaktor	Platformy	Klucz PGP	Uwagi
TensorCash	macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64)	pending	Buduje z publicznego drzewa źródeł. Każde wydanie zawiera manifest SHA-256 i oddzielny podpis PGP obok binarek.

By trafić na listę benefaktorów: zbuduj z oznaczonego wydania źródeł, opublikuj manifest SHA-256 swoich artefaktów i oddzielny podpis PGP, a następnie otwórz pull request dodając wiersz do tej tabeli.

Weryfikacja builda benefaktora

Dwa kroki. Pierwszy wiąże deklarację benefaktora z pobraną binarką; drugi wiąże binarkę ze źródłami.

Hash + podpis

Każdy benefaktor publikuje plik SHA256SUMS i oddzielny podpis SHA256SUMS.asc. Sprawdź, że pobrany plik zgadza się z manifestem i że manifest jest podpisany opublikowanym kluczem PGP benefaktora.

# 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

Wzajemna weryfikacja

Podpis jednego benefaktora dowodzi tylko, że ręczy za binarkę — nie że binarka odpowiada źródłom. Dwa sposoby na domknięcie tej luki: zbuduj ze źródeł samodzielnie i porównaj hashe, albo porównaj z manifestem drugiego benefaktora dla tego samego tagu wydania. Gdy dwóch lub więcej niezależnych budowniczych publikuje identyczne SHA-256 dla tego samego artefaktu, masz dowód, że build jest reprodukowalny z publicznych źródeł.

Co dalej

przewodnik regtest — lokalny sandbox z mockowaną walidacją, rejestracja modelu i emisja aktywów krok po kroku.
Dokumentacja JSON-RPC — wbudowana konsola w portfelu obsługuje każdą metodę z tej dokumentacji.
Dołącz do projektu — wszystkie inne sposoby uczestnictwa: instytucje, dostawcy, deweloperzy, weryfikatorzy, badacze.