TensorCash Core.

บิลด์จาก source

อาร์ติแฟกต์หลักคือ source tree ที่ services/core-node/bcore/ วอลเล็ต Qt บิลด์จาก CMake target เดียวกับ headless daemon — ส่ง -DBUILD_GUI=ON ตอน configure สองเส้นทาง: Dockerfile ที่บิลด์ทั้ง stack ในครั้งเดียว (ง่ายที่สุด, แยก sandbox) หรือติดตั้ง dependency บนเครื่องโดยตรง (ทำซ้ำได้เร็วกว่า, footprint เล็กกว่า)

เส้นทาง 1 · Docker (แนะนำ)

ที่เก็บโค้ดมาพร้อม Dockerfile แบบ multi-stage ที่บิลด์ไบนารี Rust ของ cosign-bridge, Python wheel ของ ChiaVDF และ daemon bcore เต็มรูปแบบพร้อมวอลเล็ต Qt ในครั้งเดียว ต้องการแค่ Docker บนเครื่องเท่านั้น คอนเทนเนอร์ยังมี Tor สำหรับเครือข่าย hidden-service และ VNC server สำหรับรัน GUI ภายในคอนเทนเนอร์หากต้องการ

Dockerfile: services/core-node/tor.Dockerfile

git clone --recurse-submodules https://git.tensorcash.org/tensorcash/tensorcash.git
cd tensorcash

docker build \
  -f services/core-node/tor.Dockerfile \
  -t tensorcash-core:dev \
  .

หลังบิลด์เสร็จ รันคอนเทนเนอร์โดยเปิด RPC port ของวอลเล็ต และ 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 · Native build

ใช้วิธีนี้หากต้องการไบนารีที่รันบนเครื่องโดยตรงโดยไม่ผ่านคอนเทนเนอร์ ทดสอบบน macOS 13+ (arm64 / x86_64) และ Ubuntu / Debian แล้ว ส่วน Fedora และ Arch มีเอกสารอยู่ใน doc/build-unix.md ภายใน submodule ของ bcore

Clone

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

ติดตั้ง dependency — 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

ติดตั้ง dependency — Linux (Ubuntu / Debian)

แนวทางเดียวกัน ต่างกันที่ package manager ส่วน Fedora และ Arch ดูที่ doc/build-unix.md ใน upstream ของที่เก็บโค้ด

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

ติดตั้ง dependency — Windows (cross-compile)

Windows build แบบ native ผ่าน MSVC (ดู doc/build-windows-msvc.md) เส้นทางที่ contributor ส่วนใหญ่ใช้คือ cross-compile จาก Linux host (หรือ WSL) ด้วย toolchain Mingw-w64 บวกกับระบบ depends ที่มาพร้อมด้วย ต้องการ NSIS เฉพาะตอนสร้าง installer .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)

Configure + compile

บน macOS / Linux ขั้นตอน configure เป็นการเรียก CMake ครั้งเดียว บน Windows ส่ง toolchain file ที่ generate จาก depends tree

# 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

Flag configure ที่ใช้บ่อย: -DBUILD_GUI=ON (วอลเล็ต Qt), -DENABLE_WALLET=OFF (โหนด chain เท่านั้น), -DWITH_ZMQ=ON (ZMQ pub/sub topics) รัน cmake -B build -LH เพื่อดูรายการทั้งหมด

บิลด์ cosign bridge

ฟีเจอร์ Cosign ในวอลเล็ต (การลงนามด้วยอุปกรณ์คู่, federated multisig) คุยกับไบนารี Rust ที่ชื่อ cosign-bridge ผ่าน local socket เส้นทาง Docker บิลด์ให้อัตโนมัติ ส่วนการบิลด์แบบ native ต้องสร้างเองด้วย 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/ การ sync กับ mainnet ครั้งแรกใช้เวลาหลายชั่วโมงและเขียน chainstate ขนาดหลาย GB หากต้องการทดสอบเบื้องต้น ให้ชี้ไปที่ 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

ดูคู่มือ regtest สำหรับการตั้งค่า local-development แบบเต็มรูปแบบ รวมถึง mock validation และ RPC เฉพาะของ TensorCash

บริการเสริม

TensorCash Core คือวอลเล็ตบวกกับบริการ sidecar ขนาดเล็กที่คุยด้วย Docker build ด้านบนรวมทุกอย่างมาให้แล้ว หากบิลด์แบบ native นี่คือสิ่งที่ต้องประกอบควบคู่กับไบนารี Qt ขึ้นอยู่กับฟีเจอร์ที่ต้องการ

ไบนารีจาก benefactor

การบิลด์จาก source คือเส้นทางหลัก แต่เพื่อความสะดวก benefactor จากชุมชนก็เผยแพร่ build ของตนเองจาก source tree เดียวกัน โครงการไม่ผลิต ลงนาม หรือแจกจ่ายไบนารีเอง — สิ่งเหล่านี้เป็นผลงานอิสระของบุคคลที่สาม รายชื่อไว้ที่นี่เพื่อการอ้างอิงเท่านั้น ตรวจสอบ build ของ benefactor กับ build จาก source ของตัวเองเสมอ หรือเทียบข้ามระหว่าง benefactor

Convenience binaries are published by community benefactors and listed in the network directory. Those listings are unverified and not endorsed by the project — always verify a build's PGP signature against the public source (below) before you run it.

หากต้องการเป็น benefactor: บิลด์จาก source release ที่ tag ไว้, เผยแพร่ SHA-256 manifest ของอาร์ติแฟกต์และลายเซ็น PGP แยกต่างหาก แล้ว open pull request เพื่อเพิ่มแถวในตารางนี้

การตรวจสอบ build จาก benefactor

สองขั้นตอน — ขั้นแรกผูกการอ้างสิทธิ์ของ benefactor กับไบนารีที่ดาวน์โหลด ขั้นที่สองผูกไบนารีกับ source

แฮช + ลายเซ็น

ทุก benefactor เผยแพร่ไฟล์ SHA256SUMS และลายเซ็น SHA256SUMS.asc แยกต่างหาก ตรวจสอบว่าไฟล์ที่ดาวน์โหลดตรงกับ manifest และ manifest ลงนามด้วย PGP key ที่เผยแพร่ของ 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

เทียบข้าม

ลายเซ็นจาก benefactor คนเดียวพิสูจน์ได้แค่ว่าพวกเขารับรองไบนารีนั้น — ไม่ได้พิสูจน์ว่าไบนารีตรงกับ source สองวิธีปิดช่องว่างนี้ได้: บิลด์จาก source เองแล้วเทียบแฮช หรือเทียบกับ manifest ของ benefactor รายที่สองสำหรับ release tag เดียวกัน เมื่อ builder อิสระสองคนขึ้นไปเผยแพร่ SHA-256 เดียวกันสำหรับอาร์ติแฟกต์เดียวกัน นั่นคือหลักฐานว่า build นี้ reproduce จาก source สาธารณะได้จริง

ขั้นถัดไป

• คู่มือ regtest — sandbox สำหรับพัฒนาบนเครื่อง พร้อม mock validation, walkthrough การลงทะเบียนโมเดลและการออกสินทรัพย์
• JSON-RPC reference — คอนโซลในตัววอลเล็ตรองรับทุก method บน reference นี้
• มีส่วนร่วมกับเรา — ทุกช่องทางอื่นในการเข้าร่วม: สถาบัน, ผู้ให้บริการ, นักพัฒนา, ผู้ตรวจสอบ, นักวิจัย