/wallet
TensorCash Core.
En Qt-baseret desktopwallet til TensorCash-kæden — afledt af Bitcoin Core, med understøttelse af native aktiver og en integreret JSON-RPC-konsol. Byg den selv fra det offentlige kildetræ (via Docker eller nativt), eller hent en færdigbygget binær fra en af benefaktorerne herunder.
Tour
Samme grundform som Bitcoin Core, med TensorCash-specifikke faner til native aktiver og udstedelse. Klik på et billede for at se det i fuld opløsning.
Byg fra kildekode
Det kanoniske artefakt er kildetræet i services/core-node/bcore/. Qt-wallet'en bygges fra samme CMake-mål som den hovedløse daemon — angiv -DBUILD_GUI=ON, når du konfigurerer. To veje: en Dockerfile, der bygger hele stakken (nemmest, sandboxet), eller native afhængigheder på din egen vært (hurtigere iteration, mindre image).
Vej 1 · Docker (anbefalet)
Repositoriet indeholder en multi-stage Dockerfile, der i ét hug bygger cosign-bridge Rust-binæren, ChiaVDF Python-wheel'et og den fulde bcore-daemon + Qt-wallet. Du behøver kun at have Docker installeret på værten. Containeren rummer også Tor til hidden-service-netværk samt en VNC-server, så du kan køre GUI'en inde i containeren, hvis du vil.
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 \
. Når byggeprocessen er færdig, kører du containeren og åbner wallet'ens RPC-port — og eventuelt VNC til GUI-adgang:
# 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 Vej 2 · Native build
Brug denne vej, hvis du vil bygge native binære filer på din vært uden en container. Testet på macOS 13+ (arm64 / x86_64) og Ubuntu / Debian; Fedora og Arch er dokumenteret i bcore-submodulens doc/build-unix.md.
Klon
git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash/services/core-node/bcore Installer afhængigheder — macOS
Først Xcode Command Line Tools, derefter Homebrew-pakkerne.
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 afhængigheder — Linux (Ubuntu / Debian)
Samme fremgangsmåde, blot med en anden pakkehåndtering. Fedora og Arch finder du i upstream doc/build-unix.md i repositoriet.
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 afhængigheder — Windows (krydskompilering)
Native Windows-builds går gennem MSVC (se doc/build-windows-msvc.md). Den hurtigere vej — som de fleste bidragydere bruger — er at krydskompilere fra en Linux-vært (eller WSL) med Mingw-w64-toolchainet og det medfølgende depends-system. NSIS skal kun bruges til .exe-installer-målet.
# 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) Konfigurer + kompiler
På macOS / Linux klares configure-trinnet med ét enkelt CMake-kald. På Windows skal du pege på den toolchain-fil, depends-træet genererer.
# 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 Almindelige configure-flag: -DBUILD_GUI=ON (Qt-wallet), -DENABLE_WALLET=OFF (kun kæde-node), -DWITH_ZMQ=ON (ZMQ pub/sub-emner). Kør cmake -B build -LH for den fulde liste.
Byg cosign-broen
Cosign-funktionerne i wallet'en (parret-enhed-signering, federeret multisig) snakker med en Rust-sidecar ved navn cosign-bridge over en lokal socket. Docker-vejen bygger den automatisk; til native builds bygger du den selv med 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. Kør
Qt-wallet-binæren lander i build/bin/. Første synkronisering mod mainnet tager mange timer og skriver en chainstate på flere GB; vil du bare tage en hurtig smoke-test, så peg den på et regtest-datadir i stedet.
# 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 Tilhørende tjenester
TensorCash Core er wallet'en plus et lille sæt sidecar-tjenester, den snakker med. Docker-vejen ovenfor bundler dem alle; bygger du nativt, er det dem, du skal samle ved siden af Qt-binæren — afhængigt af, hvilke funktioner du vil bruge.
| Tjeneste | Kildesti | Hvad den gør | Nødvendig til |
|---|---|---|---|
| cosign-bridge | services/core-node/cosign-bridge/ | Lokal Rust-sidecar, der står for cosign- og federeret-signerings-parring (SPAKE2 + Noise over WebSocket). Håndterer parret-enhed-flows for Qt-wallet'en. | Cosign-funktioner (multi-enhed-signering, federeret multisig) |
| ChiaVDF | shared-utils/chiavdf/ | Verificerbar forsinkelsesfunktion (VDF), som kædevalidering bruger. Bygges som en Python-wheel sammen med daemon'en. | Validering af enhver blok (mainnet, testnet eller regtest) |
| core-node REST | services/core-node/src/ | Lille REST-grænseflade ved siden af JSON-RPC-serveren. Stiller modelmetadata og node-metrics til rådighed. | Udbyder-integrationer; selve wallet'en har ikke brug for den |
| verification-api | services/verification-api/ | OSS-verifikationstjeneste. Wallet'en kalder den ikke direkte — det gør bcore, når -validationapi=real er sat. | Ægte (ikke-mock) blokvalidering i produktion |
| miner-api | services/miner-api/ | Bro mellem kæden og inferensmotoren (llama.cpp / vLLM). Producerer det inferensbevis, der indgår i en blok. | Mining (servering af inferens + produktion af blokke) |
Benefaktor-binærer
Den kanoniske vej er at bygge fra kildekode. For nemheds skyld udgiver fællesskabets benefaktorer dog egne builds af det samme kildetræ. Projektet producerer, signerer eller distribuerer ikke binærer — det her er uafhængige tredjepartsudgivelser, vi kun nævner her, så du kan finde dem. Verificer altid en benefaktor-binær mod dit eget byg fra kildekode, eller krydstjek den mod en anden benefaktor.
| Benefaktor | Platforme | PGP-nøgle | Noter |
|---|---|---|---|
| TensorCash | macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64) | pending | Bygger fra det offentlige kildetræ. Hvert release leveres med et SHA-256-manifest og en fritstående PGP-signatur ved siden af binærerne. |
Vil du på listen som benefaktor? Byg fra et tagget kilderelease, udgiv et SHA-256-manifest over dine artefakter og en fritstående PGP-signatur, og åbn et pull request med en ny række i denne tabel.
Verificering af et benefaktor-build
To tjek. Det første knytter benefaktorens påstand til den binær, du har downloadet; det andet knytter binæren til kilden.
Hash + signatur
Alle benefaktorer udgiver en SHA256SUMS-fil og en fritstående SHA256SUMS.asc-signatur. Bekræft, at den fil, du har downloadet, matcher manifestet, og at manifestet er signeret med benefaktorens offentliggjorte PGP-nøgle.
# 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 Krydstjek
En enkelt benefaktors signatur beviser kun, at de går god for binæren — ikke at binæren svarer til kilden. Du kan lukke hullet på to måder: byg selv fra kildekode og sammenlign hashes, eller sammenlign med en anden benefaktors manifest for samme release-tag. Når to eller flere uafhængige byggere udgiver identiske SHA-256'er for samme artefakt, har du belæg for, at bygget er reproducerbart fra den offentlige kilde.
Hvad så herfra?
- regtest-guide — lokalt udviklingsmiljø med mock-validering og gennemgange af modelregistrering og aktivudstedelse.
- JSON-RPC-reference — den indbyggede konsol i wallet'en kan kalde alle metoder i denne reference.
- Vær med — alle de andre måder at være med på: institutioner, udbydere, udviklere, verifiere, forskere.