/wallet
TensorCash Core.
Uma carteira desktop baseada em Qt para a rede TensorCash — descendente do Bitcoin Core, com suporte a ativos nativos e um console JSON-RPC embutido. Compile você mesmo a partir do código-fonte público (com Docker ou nativamente), ou baixe um binário de conveniência publicado por um benefactor.
Tour
Mesmo formato do Bitcoin Core, com abas específicas da TensorCash para ativos nativos e emissão. Clique em um tile para ver a imagem em alta resolução.
Compilar do código-fonte
O artefato canônico é a árvore de código-fonte em services/core-node/bcore/. A carteira Qt compila do mesmo alvo CMake que o daemon headless — passe -DBUILD_GUI=ON no momento da configuração. Dois caminhos: um Dockerfile que compila toda a stack (mais fácil, isolado), ou dependências nativas no seu host (iteração mais rápida, imagem menor).
Caminho 1 · Docker (recomendado)
O repositório inclui um Dockerfile multi-estágio que compila o binário Rust do cosign-bridge, o wheel Python do ChiaVDF e o daemon bcore completo + carteira Qt em uma única etapa. Você só precisa do Docker instalado no host. O container também inclui Tor para redes de serviço oculto e um servidor VNC para rodar a GUI dentro do container, se quiser.
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 \
. Após a compilação, rode o container expondo a porta RPC da carteira e (opcionalmente) VNC para acesso à 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 Caminho 2 · Compilação nativa
Use este caminho se quiser binários nativos no seu host sem container. Testado no macOS 13+ (arm64 / x86_64) e Ubuntu / Debian; Fedora e Arch estão documentados no doc/build-unix.md dentro do submódulo bcore.
Clone
git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash/services/core-node/bcore Instalar dependências — macOS
Primeiro o Xcode Command Line Tools, depois os pacotes 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 Instalar dependências — Linux (Ubuntu / Debian)
Mesma lógica, gerenciador de pacotes diferente. Fedora e Arch estão no doc/build-unix.md upstream dentro do repositório.
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 Instalar dependências — Windows (compilação cruzada)
Compilações nativas para Windows usam MSVC (veja doc/build-windows-msvc.md). O caminho mais rápido que a maioria dos contribuidores usa é a compilação cruzada a partir de um host Linux (ou WSL) com a toolchain Mingw-w64 mais o sistema de dependências embutido. NSIS só é necessário para o alvo do instalador .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) Configurar + compilar
No macOS / Linux, a etapa de configuração é uma única invocação CMake. No Windows, passe o arquivo de toolchain gerado pela árvore de dependências.
# 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 Flags de configuração comuns: -DBUILD_GUI=ON (carteira Qt), -DENABLE_WALLET=OFF (nó somente com cadeia), -DWITH_ZMQ=ON (tópicos ZMQ pub/sub). Execute cmake -B build -LH para a lista completa.
Compilar o cosign bridge
Os recursos de Cosign na carteira (assinatura entre dispositivos pareados, multisig federado) se comunicam com um binário Rust sidecar chamado cosign-bridge via socket local. O caminho Docker o compila automaticamente; para compilações nativas, você o produz com 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. Rodar
O binário da carteira Qt fica em build/bin/. A sincronização inicial com a mainnet leva horas e grava um chainstate de vários GB; para um teste rápido, aponte para um datadir de 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 Serviços auxiliares
TensorCash Core é a carteira mais um conjunto de serviços sidecar com os quais ela se comunica. A compilação Docker acima inclui todos eles; se você compilar nativamente, é isso que você montaria junto ao binário Qt dependendo dos recursos que quiser.
| Serviço | Caminho do código-fonte | O que faz | Necessário para |
|---|---|---|---|
| cosign-bridge | services/core-node/cosign-bridge/ | Sidecar Rust local que gerencia o pareamento cosign / assinatura federada (SPAKE2 + Noise sobre WebSocket). Processa os fluxos de dispositivo pareado da carteira Qt. | Recursos Cosign (assinatura multi-dispositivo, multisig federado) |
| ChiaVDF | shared-utils/chiavdf/ | Verifiable Delay Function usada pela validação da cadeia. Compilada como wheel Python durante a build do daemon. | Validar qualquer bloco (mainnet, testnet ou regtest) |
| core-node REST | services/core-node/src/ | Pequena interface REST ao lado do servidor JSON-RPC. Expõe metadados de modelo + métricas do nó. | Integrações de provedor; a carteira em si não precisa |
| verification-api | services/verification-api/ | Serviço de verificação OSS. A carteira não o chama diretamente — o bcore sim, quando -validationapi=real. | Validação de blocos real (não simulada) em produção |
| miner-api | services/miner-api/ | Faz a ponte entre a cadeia e o mecanismo de inferência (llama.cpp / vLLM). Produtor da prova de inferência que integra um bloco. | Mineração (atender inferência + produzir blocos) |
Binários de benefactors
Compilar do código-fonte é o caminho canônico. Como conveniência, benefactors da comunidade publicam suas próprias compilações da mesma árvore de código. O projeto não produz, assina nem distribui binários — estas são publicações independentes de terceiros, listadas aqui apenas como referência. Verifique qualquer binário de benefactor contra a sua própria compilação a partir do código-fonte, ou compare entre diferentes benefactors.
| Benefactor | Plataformas | Chave PGP | Notas |
|---|---|---|---|
| TensorCash | macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64) | pending | Compila a partir da árvore de código-fonte pública. Cada versão inclui um manifesto SHA-256 e uma assinatura PGP desanexada junto aos binários. |
Para ser listado como benefactor: compile a partir de uma versão com tag de lançamento, publique um manifesto SHA-256 dos seus artefatos e uma assinatura PGP desanexada, e abra um pull request adicionando uma linha a esta tabela.
Verificando um binário de benefactor
Duas verificações. A primeira vincula a alegação do benefactor ao binário que você baixou; a segunda vincula o binário ao código-fonte.
Hash + assinatura
Todo benefactor publica um arquivo SHA256SUMS e uma assinatura desanexada SHA256SUMS.asc. Confirme que o arquivo baixado corresponde ao manifesto e que o manifesto está assinado pela chave PGP publicada pelo benefactor.
# 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 Referência cruzada
A assinatura de um único benefactor só prova que ele garante o binário — não que o binário corresponde ao código-fonte. Duas formas de fechar essa lacuna: compile do código-fonte e compare os hashes, ou compare com o manifesto de um segundo benefactor para a mesma tag de lançamento. Quando dois ou mais compiladores independentes publicam SHA-256 idênticos para o mesmo artefato, você tem evidência de que a compilação é reproduzível a partir do código-fonte público.
O que ver a seguir
- guia de regtest — sandbox de desenvolvimento local com validação simulada, walkthroughs de registro de modelo e emissão de ativos.
- Referência JSON-RPC — o console embutido na carteira cobre todos os métodos desta referência.
- Participe — todas as outras formas de participar: instituições, provedores, desenvolvedores, verificadores, pesquisadores.