hackathon/whitepaper
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add translate

Browse Source
This commit is contained in:
godvmxi
2026-02-08 21:39:16 -08:00
parent 8db5a96230
commit ed84f6ad90
12 changed files with 483 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

0
en/technical/README.md
View File

56
en/technical/arch.md Normal file
View File

@@ -0,0 +1,56 @@
```mermaid
graph TD
%% Define styles
classDef layer stroke-width:2px,stroke-dasharray: 5 5;
classDef hardware fill:#f96,stroke:#333,stroke-width:2px;
classDef storage fill:#bbf,stroke:#333,stroke-width:2px;
classDef contract fill:#dfd,stroke:#333,stroke-width:2px;
subgraph User_Side [AI Accessibility Layer & Hardware Sovereignty Layer]
A[User Interaction / AI Assistant] --> B[Privacy Proxy]
B -- Local Filtering / De-identification --> C[AI Vendor Server]
B -- Identify Valuable Assets --> D{Biometric Authorization}
D -- Authorization Passed --> E[[TEE Hardware Environment]]
subgraph TEE [TEE Internal Execution]
E --> F[Master Key K]
F --> G[Inner Hardware Encryption]
end
end
subgraph API_Layer [Third-Party API Integration Layer]
H[Mode A: Standalone Sovereignty]
I[Mode B: Collaborative SDK]
I -.-> D
end
subgraph Sentinel_Storage [Sentinel Vault Layer]
G --> J[Server Cluster Outer Encryption]
J --> K[S1 Recursive Fragmentation]
subgraph Distributed_Nodes [Distributed Storage Nodes]
K --> L1[Node A: Sub-shard S1a]
K --> L2[Node B: Sub-shard S1b]
K --> Ln[Node N: Sub-shard S1n]
end
L1 & L2 & Ln --> M[(Arweave Permanent Storage Network)]
end
subgraph Survival_Mechanism [Survival Guarantee Layer]
N[Legal Trust Fund] -- Fee Payment Guarantee --> M
O[Smart Contract Dead Man Switch] -- Heartbeat Monitoring --> J
O -- Trigger Open-Source Takeover --> P[Release Node Private Keys & Ciphertext Index]
P --> Q[Open-Source Self-Recovery Tool]
subgraph Recovery [Reconstruction Path]
Q --> R{Reconstruct Master Key K}
S0[Redundancy Shard S0] --> R
S2[Heir Shard S2] --> R
L1 & L2 & Ln -- Contract-Triggered Release --> R
end
R --> T[Decrypt Original Data Assets]
end
%% Apply layer hierarchy styles
class E,F,G hardware;
class M,L1,L2,Ln storage;
class O contract;
```

85
en/technical/architecture.md
View File

@@ -0,0 +1,85 @@
# Sentinel Protocol (哨兵协议) Technical Whitepaper
## **1. Abstract**
Sentinel Protocol proposes a digital asset protection framework based on "sovereignty origin + recursive fragmentation." By reducing adoption barriers through **AI privacy proxy**, locking sovereignty execution root through **TEE hardware**, and combining **multi-level SSS algorithms** to enable perpetual asset succession. The core innovation lies in the dual-track guarantee of **smart contract dead man switch** and **statutory trust storage mechanism**, ensuring that after a commercial entity ceases service, the open-source community can take over access rights, and encrypted data remains physically preserved and decryptable over long historical periods.
---
## **2. Core Architecture: Four-Layer Defense System**
### **2.1 AI Accessibility Layer**
* **Functional Assistant**: Encapsulates advanced prompts into preset plugins, providing natural language interaction entry points.
* **Privacy Proxy**:
* **Local Interception**: Executes sensitive keyword filtering on the client side, ensuring private key fragments or personally identifiable information **never** leave the local environment.
* **De-identified Forwarding**: Relay proxy removes metadata such as IP addresses and device IDs, allowing third-party AI vendors to receive only anonymized pure instructions.
* **Local Semantic Summary**: Client-side AI locally summarizes assets, only prompting users to enter hardening process when valuable targets are discovered.
### **2.2 Hardware Sovereignty Layer**
* **Master Key (K)**: Derived from mnemonic phrases, locked within the phone's **TEE (Trusted Execution Environment)**. We don't trust software systems, only mathematics locked in chip architectures.
* **Inner Hardening**: Data completes the first-layer hardware-level inner encryption using $K$ before leaving the device.
### **2.3 Sentinel Vault Layer**
* **Outer Hardening**: Server clusters perform secondary public key encryption on ciphertext to defend against transmission risks.
* **Perpetual Storage**: Double-encrypted ciphertext is custodied on decentralized permanent networks such as Arweave.
### **2.4 Third-Party API Integration Layer**
* **Mode A: Standalone Sovereignty**: Third-party applications work with **independent mnemonics**. Sentinel Protocol serves solely as storage medium and algorithm suite, with completely isolated logic.
* **Mode B: Collaborative SDK**: Third-party applications integrate **Sentinel encryption SDK**. After user biometric authorization, collaborative sharing of master authorization data breaks down data silos.
---
## **3. Role Definitions and Key Derivation System**
The system follows strict derivation logic from "mathematical meta-seed" to "physical shards":
* **Mnemonic**: System's **root seed**, the sole mathematical origin of all keys.
* **Master Key (K)**: Locked within TEE chip, serving as the daily sovereignty execution root.
* **S0 (Redundancy)**: Redundancy backup shard. Saved offline by users (physical printout/USB drive) as final recourse.
* **S1 (Cloud)**: Distributed recursive shard, custodied by cloud nodes.
* **S2 (Heir)**: Heir shard. Distributed by user to designated estate handlers.
---
## **4. S1 Distributed Recursive Fragmentation (Multi-Server Fragmentation)**
To completely eliminate centralized node data breach and collusion risks, $S_1$ adopts a "divide and conquer" strategy:
### **4.1 Secondary Fragmentation Logic**
After the mobile device generates $S_1$, instead of uploading it directly, it is fragmented again through the SSS algorithm into $n$ sub-shards ($n \ge 2$): $\{S_{1a}, S_{1b} \dots S_{1n}\}$.
### **4.2 Node Encryption and Storage**
* **Independent Encryption**: Each sub-shard is encrypted using the independent public key of its corresponding storage node.
* **Distributed Storage**: Sub-shards are distributed to multiple geographically isolated and logically independent sentinel server nodes.
* **Security Characteristics**: No single server possesses complete $S_1$. Hackers breaching a single database only obtain "fragments of fragments."
---
## **5. Business Logic Workflow**
### **5.1 Data Ingestion Flow**
1. **Identification and Confirmation**: Local AI discovers information, obtaining user biometric authorization.
2. **Double Encryption**: TEE invokes $K$ to complete inner hardening $\rightarrow$ Server executes outer hardening.
3. **Recursive Distribution**: $S_1$ is fragmented into multiple sub-shards, then encrypted and sent to different geographic nodes.
### **5.2 Succession and Recovery Flow**
1. **Status Determination**: Smart contract detects incapacity signal.
2. **Shard Aggregation**: Multiple nodes verify contract instructions, decrypt and release their respective sub-shards.
3. **Multi-level Reconstruction**:
* **First-level Reconstruction**: Sub-shards reconstruct the original cloud shard $S_1$.
* **Second-level Reconstruction**: $S_1$ combined with heir-held $S_2$ (or redundancy shard $S_0$) synthesizes Master Key (K).
4. **Asset Decryption**: Using $K$ to peel off inner encryption and retrieve original assets.
---
## **6. Survival Guarantee and Security Summary**
### **6.1 Survival Guarantee (The Great Survival Protocol)**
* **Statutory Trust and Renewal**: Dedicated trust fund independent from commercial entities, ensuring physical validity of storage fees over long historical periods.
* **Dead Man Switch**: Once the commercial entity becomes incapacitated, smart contracts automatically release ciphertext indexes and node private keys, with open-source community taking over access.
* **Open-Source Self-Rescue**: Users can leverage open-source tools, combined with mnemonic phrases or $S_2/S_0$, to locally restore $K$; even if official services disappear, data can be recovered.
### **6.2 Security Highlights**
* **Anti-Database Breach (Anti-DB Leak)**: Cloud-side $S_1$ exists in fragmented state; single-point compromise is meaningless.
* **Privacy Sovereignty**: Privacy Proxy physically isolates AI-side profiling risks.
* **Uniqueness and Robustness**: $K$ locked in TEE, and system can reconstruct data even when some nodes go offline.
---

12
en/technical/glossary.md
View File

@@ -0,0 +1,12 @@
## **Appendix: Glossary**
| Term | Common Definition | Role in This Protocol |
| :--- | :--- | :--- |
| **TEE (Trusted Execution Environment)** | An "independent safe deposit box" in the phone's chip. | Stores the master key $K$, preventing key theft even if the phone is compromised. |
| **SSS (Secret Sharing Scheme)** | Like the ancient "tiger's order," torn into fragments separately, assembled into authority. | Fragments the master key into $S_0, S_1, S_2$, enabling disaster recovery and backup. |
| **Mnemonic** | The system's "meta-seed," the most important words in life. | The highest permission root for recovering all assets. |
| **Privacy Proxy** | Your "digital double," speaking to AI on your behalf. | Intercepts local sensitive information, removes IP/device ID, preventing identity leakage. |
| **Arweave** | A "permanent and unchangeable" digital monument. | Permanently custodies encrypted ciphertext, solving the problem of data loss after traditional cloud storage bankruptcy. |
| **Recursive Sharding** | Like feeding shredded paper through the shredder one more time. | Ensures that even if storage nodes are compromised, attackers cannot obtain the complete cloud shard $S_1$. |
| **Dead Man Switch** | If I stop checking in, the protocol executes automatically. | Monitors commercial entity status; if bankrupt, transfers decryption rights to the community. |
| **Legal Trust** | A data "maintenance fund" protected by law. | Ensures storage fees remain continuously paid, preventing fee discontinuation due to company bankruptcy. |