# Proof of Compute Security Documentation

## Overview

The **Merkle-Proof-of-Compute (M-PoC)** system is a verifiable GPU-based computation framework designed for proof-of-work style mining.\
Each computation round produces deterministic, tamper-evident proofs that can be efficiently validated by a verifier or server.

This approach guarantees that all GPU workloads are:

* **Deterministic** — reproducible using the same seed.
* **Verifiable** — validated through Merkle root sampling.
* **Bound to origin** — tied to an authenticated compiled miner client.

{% stepper %}
{% step %}

### Core Compute Flow — Challenge Issuance

The server generates a challenge containing:

* A unique random `seed`
* Work parameters (`size`, `batch`, `loops`, `duration`)

The random seed ensures miners cannot precompute or reuse results.
{% endstep %}

{% step %}

### Core Compute Flow — Deterministic GPU Compute

For each loop `i`:

```python
loop_seed = f"{seed}:{i}"
robust_digest = sha256(C_np.astype(np.float32).tobytes())
```

The miner performs deterministic matrix multiplications on GPU and produces a robust digest per loop.
{% endstep %}

{% step %}

### Core Compute Flow — Merkle Commitment

Each digest is committed as a Merkle leaf:

```
leaf = H("LEAFv1" || seed || loop_index || robust_digest)
```

All leaves form a Merkle tree, yielding the final `merkle_root`.
{% endstep %}

{% step %}

### Core Compute Flow — Proof Submission

The miner submits:

```json
{
  "seed": "...",
  "merkle_root": "...",
  "loops": N,
  "compute_time": T,
  "merkle_levels": [...]
}
```

{% endstep %}

{% step %}

### Core Compute Flow — Server Verification

The server randomly samples `k` loop indices, recomputes those digests using the original seed, reconstructs their Merkle proofs, and checks for consistency with the reported `merkle_root`.\
Any mismatch invalidates the proof.
{% endstep %}
{% endstepper %}

***

## Security Architecture

| Layer                              | Purpose                                     | Status |
| ---------------------------------- | ------------------------------------------- | ------ |
| **Server-issued seed**             | Prevents precomputation and replay          | ✅      |
| **Per-loop seed binding**          | Enforces unique digest per loop (`seed:i`)  | ✅      |
| **Merkle tree commitment**         | Detects any tampering or partial work       | ✅      |
| **Random audit sampling**          | Enables low-cost probabilistic verification | ✅      |
| **Nuitka-compiled miner (`.pyd`)** | Obfuscates logic and embedded secrets       | ✅      |
| **App signing key**                | Authenticates official miner builds         | ✅      |
| **GPU hardware binding**           | Associates proofs with a specific GPU UUID  | ✅      |

***

## Security Achievements

| Threat                     | Mitigation                                  |
| -------------------------- | ------------------------------------------- |
| **Fake GPU work**          | Merkle commitment + seed audit verification |
| **Replay / reuse attacks** | Unique server-issued seed per challenge     |
| **Digest manipulation**    | Merkle root verification                    |
| **Binary modification**    | `.pyd` self-hash and signing key check      |
| **Binary cloning**         | GPU UUID + app key pairing                  |
| **Offline forgery**        | Unpredictable seed generation by server     |

***

## Miner Identity & Authenticity

* **Binary Hash**\
  Each miner self-hashes its `.pyd` binary using SHA-256 and sends the result to the server.\
  The server maintains a whitelist of valid build hashes.
* **Application Private Key**\
  A private signing key is embedded within the compiled binary (protected and obfuscated).\
  The miner signs `(seed + merkle_root + gpu_uuid)` before submission.
* **Server Verification**\
  The server verifies the signature using the corresponding public key, confirming that the proof originated from an official build and a registered GPU.

***

## Final Notes

* The miner’s deterministic path (`seed → matmul → digest → Merkle`) ensures all verifications are reproducible.
* TF32 enforcement is removed as it’s not security-critical.
* The compiled `.pyd` binaries act as authenticated, tamper-resistant clients.
* Cloning the binary is ineffective since each proof is tied to both the GPU identity and the server-issued challenge.

{% hint style="success" %}
Final Verdict:\
The current system — *Merkle-Proof-of-Compute + Server-Seeded Challenges + Compiled & Signed Nuitka Miner* — forms a robust, multi-layer proof-of-work verification model that is both tamper-evident and cryptographically secure.

This achieves lightweight, auditable, and cheat-resistant GPU compute verification. 🚀
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hashcloud.sh/proof-of-compute-security-documentation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.