Technology
NeuroBox network leverages advanced cryptography and distributed computing technologies to guarantee fairness and efficiency:
PoSV (Proof of Service Value): rewards based on latency, bandwidth, and service quality.
VRF and Random Arbitration: prevents fraud and detects fake traffic.
TEE and Zero-Knowledge Proofs: ensure correctness and privacy of AI inference tasks.
Cross-chain Settlement: built on high-throughput chains such as Solana with multi-chain interoperability.
Developer Interfaces: SDKs, APIs, and Edge Functions that make it simple for developers to integrate NeuroBox services into their applications.
1. Design objectives and principles
Objective: To achieve measurable, auditable and settleable real services (CDN/AI) with "near-chain computing + chain summary solidification"; and to support large-scale and low-cost distribution with Merkle-Claim.
Main chain and standard: BSC mainnet; BEP-20 token; Solidity contract (EVM ecosystem).
Principles: minimum chain, strong power, weak trust (multiple Keeper cross-check), parameter governance (white list + change speed limit + Timelock), IPv6 citizen, compatible with W3bstream / ioID / DePINscan methodology.
2. Overall architecture (Near-Chain↔On-Chain)
Edge nodes (Worker: CDN / GPU)
└─ Capacity detection / heartbeat / containerized execution / TaskReport (signature)
Near-Chain services (Near-Chain)
├─ Collector (5 minute aggregation)
├─ Auditor / Arbiter (k-of-n recheck, challenge sample, quality score)
├─ ReceiptBuilder (verifiable detail package → Merkle Tree)
└─ API (with signed snapshot, with W3bstream receipt reference)
Keeper (white list multi instances)
└─ Snap → Sign-off → Calculate scores → Generate distribution root → Submit BSC
On the chain (BSC/Solidity)
├─ EpochRegistry (epochId, merkleRoot, submittedAt,etc)
├─ RewardBook (allocation parameters, BEP-20 release)
└─ Claim (Unified Merkle-Claim; bitmap replay protection)
Observability layer (derived DePINscan compatible indicators)
The epoch is fixed for 5 minutes; the same root with the same epochId can be submitted repeatedly (idempotent), while different roots refuse.
l Multiple Keeper rotation and cross-checking, read the chain before writing to avoid "double write/forking".
3. PoSV (Proof of Service Value) -Unified measurement and distribution
3.1 Equipment score (single Epoch)
S_i = α·B_i + β·L_i^{-1} + γ·D_i + δ·A_i + ε·Q_i + ζ·P_i + κ·G_i
B_i: Effective throughput (GB or Mbps equivalent, excluding self-playback)
L_i: Delay fraction (P50/P95 weighted)
D_i: Content coverage/cached hits
A_i: AI measurement = Σ (GPU·min × M_vram × M_arch)
Q_i: Quality (inference consistency/score; fine-tuning/train metrics; CDN return rate)
P_i: IPv6 weight (IPv6-only/Proportion)
G_i: availability/credibility (SLA compliance, challenge pass rate, arbitration record)
α..κ: On-chain parameter whitelist with upper and lower limits and change rate limit (Timelock is in effect).
It is recommended to increase α/β (bandwidth/latency) during the cold start phase and gradually increase δ/ε (AI/quality) as the AI business grows.
3.2 Distribution and collection
The transaction chain process: Collector aggregates → Auditor conducts a k-of-n sampling calculation → ReceiptBuilder generates detail packets and Merkle trees; Keeper verifies the transaction and calculates SiS_iSi, transforming leaf nodes (device ID, amount, flags) into a root structure.
On the chain: only epochId, merkleRoot, submittedAt; Allocation (example):
R_i = REpoch · (S_i^θ / Σ_j S_j^θ) // θ Control the differentiation intensity
Claim: claim (epochId, proof, leaf, to, amount); bitmap replay protection; support for multiple Epoch batch.
4. VRF and Random Arbitration (Anti-Corruption and Cost Control)
VRF weighted draw (optional): Seed seed_e = H(epochId || prev_root);
The probability of winning the lottery is P (i) ∝ VRF (seed_e, ID_i) · S_i^η (η>1 to improve the weight of high-quality nodes and avoid oligopoly).
Random arbitration: Rerun and recalculate 10% of the tasks, check the output hash/index; challenge samples with watermarks/traps, deduct reputation and confiscate them if failed, and trigger a cooldown.
Dynamic coverage: the lower the credibility, the higher the sampling.
5. Correctness and privacy: TEE + ZK (on-demand hardening)
TEE (SGX/SEV/SNP/GPU-TEE): High-value tasks are executed in TEE, and remote proof Quote (off-chain verification, on-chain summary hash) is submitted as a bonus item of QiQ_iQi.
ZK Summary: Generate ZK-commitment for key indicators of reasoning consistency and fine-tuning/training; only commitment exists on the chain, and sampling verification can be performed.
Data minimization: Task data and model weight are encrypted and distributed, and the plaintext is destroyed when the task is completed; only verifiable summaries are stored in logs.
6. Chain contracts (Solidity summary)
6.1 Data structures
struct EpochState {
uint64 epochId;
bytes32 merkleRoot;
uint64 submittedAt;
bool opened; // Whether to open the claim
}6.2 Core interfaces
function submitEpoch(uint64 epochId, bytes32 root, bytes calldata statsSig)
external onlyKeeper; // Equality: the same root can be repeated; different roots are rejected
function openClaim(uint64 epochId) external onlyKeeper;
function claim(
uint64 epochId,
bytes32[] calldata proof,
bytes32 leaf, // encode(deviceId, amount, flags) bytes32 leaf, // encode(deviceId, amount, flags)
address to,
uint256 amount
) External; // BEP-20 transfer; bitmap replay protection ) External; // BEP-20 transfer; bitmap replay protection
event RootsSubmitted(uint64 indexed epochId, bytes32 root);
event RewardClaimed(uint64 indexed epochId, bytes32 indexed deviceId, address to, uint256 amount);6.3 Bitmap anti-replication (gas friendly)
mapping(uint64 => mapping(uint256 => uint256)) claimed;
idx>> 8 positioning slot, idx & 255 positioning bit; after setting, you can not claim again.
6.4 Parameter whitelist and speed limit
The setParams configuration on the chain (α..κ, θ, η,...) is subject to multi-signature and Timelock mechanisms. Each modification is subject to fluctuation limits and frequency thresholds with circuit breakers (which reduce AI weighting, raise compliance thresholds, or temporarily suspend large transactions during anomalies).
7. Near-Chain snapshot API (developer interface)
GET/api/mining_data?epoch={id}
Return (key field):
{
"epoch": 12345,
"timestamp": 1723456789,
"devices": [{
"device_id": "0x..",
"wallet": "0xWallet",
"bandwidth": 103489382,
"latency": 55,
"coverage": 24,
"ai_gpu_minutes": 367,
"ai_vram_gb": 24,
"ai_arch": "Ampere",
"ai_quality_score": 0.93,
"sla_uptime": 0.997,
"ipv6": true,
"task_hash": "0x..",
"signature": "device-ed25519"
}],
"merkle_root_candidate": "0x..",
"backend_signature": "backend-ed25519",
"extreceipthash": "0xW3bstreamReceipt" // Optional: Connect to external receipt
}Security: HTTPS + timestamp + nonce + device signature/backend signature; IP whitelist and access speed limit on the Keeper side.
8. Worker (CDN/GPU) specifications
Initialization: nvidia-smi/rocm-smi capability detection (GPU/VRAM/architecture); bandwidth/latency benchmark; region/ASN/IPv6 portrait.
Execution: OCI containerized image pulling and weight setting → task execution → generating TaskReport{usage, output.digest, metrics, logs_hash, agent_version, ts, signature}; breakpoint resumption and failure retry.
Privacy: minimum permission and one-time token; data encrypted transmission; plaintext expired and destroyed.
9. IPv6 and regional/ASN policy
Registration is distinguished from logs: IPv4/IPv6; IPv6-only and high proportion nodes are weighted in PiP_iPi.
Priority is given to low penetration areas, combined with SLA/ delay/price selection.
10. Cross-chain adaptation (EVM ecosystem)
The BSC serves as the original record chain; epochId + root + summary is synchronized to other EVMs (opBNB, ETH, Polygon...) via Wormhole, LayerZero, or IBC-like protocols.
The target chain is used to map the distribution or indicator display without recalculation; cross-chain messages require multi-sign verification; root conflicts are based on the BSC status.
11. Monitoring and observability (DePINscan compatible)
Equipment: region/ASN/IPv6, GPU/VRAM, online rate, reputation, failure rate, challenge pass rate;
Business: throughput (GB/h, tokens/s, images/s), latency (P50/P95), quality, audit coverage, budget utilization;
On the chain: Epoch submission/failed, Claim success rate, gas cost;
Export: /metrics/depinscan standard field for third-party capture and evaluation.
12. End-to-end pseudocode (excerpts)
Scoring vs Root (Keeper)
score(d,p):
base = p.α*d.bw + p.β*(1000/max(1,d.lat)) + p.γ*d.coverage
if d.ipv6: base += p.ζ
m_vram = {8:1.0,12:1.2,16:1.4,24:1.8,48:2.6,80:3.2}[d.vram]
m_arch = {"Turing":1.0,"Ampere":1.05,"Hopper":1.10}[d.arch]
ai = p.δ*d.gpu_min*m_vram*m_arch
qual = p.ε*d.ai_q
avail = p.κ*d.sla_up
return max(0, base + ai + qual + avail)
build_root(devs,p):
S = [score(d,p) for d in devs]; T = Σ(S)
leaves = [hash_leaf(d.id, S[i]/T, d.flags) for i,d in enumerate(devs)]
return merkle(leaves)
Solidity bit (biting)
_isClaimed(e, i):
word = claimed[e][i >> 8]
mask = 1 << (i & 255)
return (word & mask) != 0
_setClaimed(e, i):
claimed[e][i >> 8] |= 1 << (i & 255)Engineering trade-offs
Adherence to minimum chain + Root/Claim is the key to scalability and low cost;
Write the parameter whitelist + speed limit + Timelock + circuit breaker into the contract to stabilize the supply side and economic expectations;
First, the business closed loop of reasoning + CDN is connected, and then the fine-tuning and training are gradually opened up to improve the coverage of ZK/TEE.
Last updated