/wallet
TensorCash Core.
Qt-დაფუძნებული desktop-საფულე TensorCash-ის ჯაჭვისთვის — Bitcoin Core-ის შთამომავალი, მშობლიური აქტივების მხარდაჭერითა და ჩაშენებული JSON-RPC კონსოლით. ააშენე თვითონ საჯარო წყაროს ხიდან (Docker-ით ან ნატიურად), ან გადმოიტვირთე benefactor-ის გამოქვეყნებული ბინარული ფაილი ქვემოდან.
ტური
Bitcoin Core-ის იმავე ფორმა — TensorCash-ის სპეციფიკური ჩანართებით მშობლიური აქტივებისა და ემისიისთვის. დაწკაპე ფილაზე სრულრეზოლუციური სურათის სანახავად.
ააშენე წყაროდან
მთავარი წყაროა წყაროს ხე services/core-node/bcore/-ში. Qt-საფულე იმავე CMake-სამიზნიდან იშენება, რაც headless-daemon — კონფიგურაციისას უბრალოდ გაიარე -DBUILD_GUI=ON. ორი გზაა: Dockerfile, რომელიც მთელ სტეკს ერთიანად აშენებს (ყველაზე მარტივი, სანდბოქსირებული), ან ნატიური დამოკიდებულებები ჰოსტზე (უფრო სწრაფი იტერაცია, უფრო მცირე image-ის წონა).
გზა 1 · Docker (რეკომენდებული)
რეპოზიტორი შეიცავს მრავალსაფეხურიან Dockerfile-ს, რომელიც cosign-bridge-ის Rust-ბინარს, ChiaVDF-ის Python-wheel-ს და სრულ bcore-daemon-ს + Qt-საფულეს ერთ სროლაში აშენებს. ჰოსტზე მხოლოდ Docker გჭირდება. კონტეინერი ასევე შეიცავს Tor-ს ფარული სერვისის ქსელისთვის და VNC-სერვერს, რათა GUI კონტეინერშივე გაუშვა, სურვილისამებრ.
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 \
. build-ის შემდეგ გაუშვი კონტეინერი საფულის RPC-პორტის გამოყოფით და (სურვილისამებრ) VNC 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 გზა 2 · ნატიური build
გამოიყენე, თუ გსურს ნატიური ბინარები ჰოსტზე კონტეინერის გარეშე. გამოცდილია macOS 13+-ზე (arm64 / x86_64) და Ubuntu / Debian-ზე; Fedora და Arch დოკუმენტირებულია bcore-ქვემოდულის doc/build-unix.md-ში.
Clone
git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash/services/core-node/bcore დამოკიდებულებების ინსტალაცია — macOS
ჯერ Xcode Command Line Tools, შემდეგ 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 დამოკიდებულებების ინსტალაცია — Linux (Ubuntu / Debian)
იგივე მიდგომა, სხვა პაკეტ-მენეჯერი. Fedora და Arch — upstream doc/build-unix.md-ში.
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 დამოკიდებულებების ინსტალაცია — Windows (cross-compile)
ნატიური Windows-build გადის MSVC-ის გავლით (იხ. doc/build-windows-msvc.md). უმეტეს კონტრიბუტორთა მიერ გამოყენებული უფრო სწრაფი გზაა cross-compile Linux-ჰოსტიდან (ან WSL-იდან) Mingw-w64 toolchain-ით, ბუნდელ depends-სისტემასთან ერთად. NSIS საჭიროა მხოლოდ .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) კონფიგურაცია + კომპილაცია
macOS / Linux-ზე კონფიგურაციის ეტაპი ერთი CMake-გამოძახებაა. Windows-ზე გაიარე depends-ხიდან გენერირებული toolchain-ფაილი.
# 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 ძირითადი კონფიგურაციის ფლაგები: -DBUILD_GUI=ON (Qt-საფულე), -DENABLE_WALLET=OFF (მხოლოდ-ჯაჭვის კვანძი), -DWITH_ZMQ=ON (ZMQ pub/sub-თემები). სრული სიისთვის გაუშვი cmake -B build -LH.
cosign bridge-ის build
საფულის Cosign-ფუნქციები (დაწყვილებული მოწყობილობის ხელმოწერა, ფედერირებული multisig) ლოკალური სოკეტის გავლით ლაპარაკობს cosign-bridge სახელის Rust-ბინართან. Docker-გზა მას ავტომატურად აშენებს; ნატიური build-ისთვის გამოიმუშავე 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. გაშვება
Qt-საფულის ბინარი build/bin/-ში მოხვდება. პირველადი სინქრონიზაცია mainnet-ზე საათებს სჭირდება და რამდენიმეგიგაბაიტიან chainstate-ს წერს; სწრაფი შემოწმებისთვის მიუთითე regtest-datadir.
# 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 თანმხლები სერვისები
TensorCash Core არის საფულე და მცირე თანმხლები სერვისების ნაკრები, რომლებსაც ის ეკონტაქტება. ზემოთ ნაჩვენები Docker-build ყველას ათავსებს ერთად; ნატიური build-ის შემთხვევაში — სწორედ ამას ააგებდი Qt-ბინართან ერთად, სასურველი ფუნქციების მიხედვით.
| სერვისი | წყაროს გზა | დანიშნულება | საჭიროა |
|---|---|---|---|
| cosign-bridge | services/core-node/cosign-bridge/ | ლოკალური Rust sidecar, რომელიც ამუშავებს cosign / federated-signing დაწყვილებას (SPAKE2 + Noise WebSocket-ის გავლით). Qt-საფულიდან paired-device ნაკადების წინამძღვარი. | Cosign-ფუნქციები (multi-device ხელმოწერა, ფედერირებული multisig) |
| ChiaVDF | shared-utils/chiavdf/ | Verifiable Delay Function ჯაჭვის ვალიდაციისთვის. daemon-ის build-ის დროს Python-wheel-ად იშენება. | ნებისმიერი ბლოკის ვალიდაცია (mainnet, testnet ან regtest) |
| core-node REST | services/core-node/src/ | მცირე REST API JSON-RPC-სერვერის გვერდით. ხსნის მოდელის მეტამონაცემებსა და კვანძის მეტრიკებს. | პროვაიდერის ინტეგრაციები; თვით საფულეს არ სჭირდება |
| verification-api | services/verification-api/ | ღია კოდის ვერიფიკაციის სერვისი. საფულე მას პირდაპირ არ ეძახის — bcore ეძახის, -validationapi=real-ის შემთხვევაში. | რეალური (არა-mock) ბლოკის ვალიდაცია პროდაქშენში |
| miner-api | services/miner-api/ | ხიდი ჯაჭვსა და ინფერენციის ძრავს (llama.cpp / vLLM) შორის. ინფერენციის proof-ის მწარმოებელი, რომელიც ბლოკის ნაწილი ხდება. | მაინინგი (ინფერენციის მიწოდება + ბლოკების წარმოება) |
Benefactor-ის ბინარები
წყაროდან აშენება — კანონიკური გზაა. მოხერხებულობისთვის, საზოგადოების benefactor-ებს იმავე საჯარო წყაროდან საკუთარი build-ები გამოაქვთ. პროექტი თავად ბინარებს არ აწარმოებს, არ აწერს ხელს და არ ავრცელებს — ეს დამოუკიდებელი, მესამე მხარის გამოქვეყნებებია, აქ მხოლოდ საინფორმაციო მიზნით ჩამოთვლილი. ნებისმიერი benefactor-ის build გადაამოწმე საკუთარი წყაროდან აგებული build-ის მიხედვით, ან შეადარე ერთმანეთს ორი benefactor-ის გამოქვეყნება.
| Benefactor | პლატფორმები | PGP-გასაღები | შენიშვნები |
|---|---|---|---|
| TensorCash | macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64) | pending | საჯარო წყაროს ხიდან build. ყოველი release-ი SHA-256-მანიფესტსა და დაცილებულ PGP-ხელმოწერას ბინარებთან ერთად აგზავნის. |
benefactor-ად დარეგისტრირებისთვის: ააშენე tagged-წყაროს release-იდან, გამოაქვეყნე შენი არტეფაქტების SHA-256-მანიფესტი და დაცილებული PGP-ხელმოწერა, და გახსენი pull request ამ ცხრილში სტრიქონის დამატებით.
benefactor-ის build-ის გადამოწმება
ორი შემოწმება. პირველი benefactor-ის მტკიცებას ჩამოტვირთულ ბინართან აკავშირებს; მეორე — ბინარს წყაროსთან.
ჰეში + ხელმოწერა
ყოველი benefactor-ი SHA256SUMS-ფაილსა და დაცილებულ SHA256SUMS.asc-ხელმოწერას აქვეყნებს. დაადასტურე, რომ ჩამოტვირთული ფაილი მანიფესტს ემთხვევა, და რომ მანიფესტი benefactor-ის გამოქვეყნებული PGP-გასაღებითაა ხელმოწერილი.
# 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 ჯვარედინი გადამოწმება
ერთი benefactor-ის ხელმოწერა მხოლოდ ადასტურებს, რომ ის ბინარს უჭერს მხარს — არა იმას, რომ ბინარი წყაროს შეესაბამება. ამ ხარვეზის დახშობის ორი გზა: ააშენე წყაროდან თვითონ და შეადარე ჰეშები, ან შეადარე მეორე benefactor-ის მანიფესტს იმავე release-ტეგისთვის. როდესაც ორი ან მეტი დამოუკიდებელი builder-ი ერთი და იმავე არტეფაქტისთვის იდენტურ SHA-256-ებს აქვეყნებს, გაქვს მტკიცებულება, რომ build-ი საჯარო წყაროდან რეპროდუცირებადია.
შემდეგი ნაბიჯები
- regtest-გზამკვლევი — ლოკალური-განვითარების სატესტო გარემო mock-ვალიდაციით, მოდელის რეგისტრაციითა და აქტივის ემისიის გზამკვლევებით.
- JSON-RPC ცნობარი — საფულის ჩაშენებულ კონსოლს ამ ცნობარის ყველა მეთოდი ესმის.
- ჩაერთე — მონაწილეობის ყველა სხვა გზა: ინსტიტუციები, პროვაიდერები, დეველოპერები, ვერიფიკატორები, მკვლევრები.