> For the complete documentation index, see [llms.txt](https://aurora-21.gitbook.io/aurora-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://aurora-21.gitbook.io/aurora-docs/ji-shu-jia-gou/fei-bo-na-qi-suan-li-mo-zu.md).

# 斐波那契算力模組

Aurora 的算力模組不是單純「挖礦收益分配」，而是一套把**生產性算力**（BTC 礦業算力、AI/通用算力、合作機房算力等）轉化為可確權、可驗證、可拆分、可組合的鏈上資產單元，並與黃金 RWA / 黃金 NFT / RDA 數據層共同構成「價值捕獲—價值證明—價值分配」閉環。

在 Aurora 架構裡，算力是兩件事：

1. **產出源（Yield Source）**：提供可持續現金流或鏈上收益的底層生產要素
2. **價值約束（Value Constraint）**：透過斐波那契節奏控制增長與激勵，避免短期過熱與長期失衡

要把算力轉化成鏈上資產，需要三個關鍵：**度量標準**、**證明物件**、**資產映射協議**。

A. 度量標準（Compute Metric Standard）\
Aurora 建議以「可審計、可比較、可結算」為原則，定義算力資產的最小度量集合（不同算力類型可擴展）：

* 身份：asset\_id、provider\_id、site\_id
* 能力：rated\_hashrate / rated\_flops（或核心數/顯存等）、額定功耗
* 行為：uptime、有效工作量（shares / job logs）、錯誤率、延遲
* 結算：收益來源（礦池 / 客戶合同）、結算週期、結算幣種
* 合規：地區、電力來源/碳排標記、KYC/AML 狀態（機構級）

B. 證明物件（Proof-of-Compute, PoC / Compute Proof Object）\
Aurora 的算力上鏈不應靠「單點上報」，而是透過多源證明組合成可驗證的資料包（可視為 RDA 的一種）：

* 原始資料源（Raw Sources）
  * 礦池結算 API / 報表
  * 機房監控（溫度、功耗、在線狀態）
  * 礦機韌體/代理程式（agent）回報
  * 第三方審計/抽查紀錄（可選）
* 驗證方式（Verification）
  * 多節點簽名（N-of-M）
  * 時間戳與不可逆序列（防回填）
  * 哈希承諾（Merkle Root）與抽樣驗證
  * 異常檢測（例如 hashrate 突降、收益與算力不匹配）

產出的「ComputeProof」可被智能合約引用作為唯一結算依據：沒有有效 Proof，就不能鑄造算力資產或分配收益。

C. 資產映射（Tokenization Primitive）\
Aurora 可採「一底層、多表達」設計，滿足不同流動性與合規場景：

* 算力 NFT（cNFT，Compute NFT）
  * 用於表達唯一性：特定礦機集群、特定期間算力切片、特定合同收益權
  * 重要欄位：hashrate 上限、期限、收益規則、可轉讓條件、關聯的 ComputeProof Root
* 算力份額 FT（cToken，Fungible Share Token）
  * 用於碎片化與 AMM 流動性：把多個 cNFT 的收益權聚合成可交易份額
  * 適合做：流動性池、抵押品、結構化產品
* 收益憑證（rToken / Yield Receipt）

  * 用於結算與再投資：用戶質押 cNFT/cToken 後，生成可複利的收益憑證

  ### 斐波那契算力經濟模型（Non-linear Emission & Growth Control）

  Aurora 的核心不是「算力越多發越多」，而是用斐波那契序列與黃金分割的非線性節奏，做三層控制：

  1. 釋放節奏調節（Emission Scheduling）

  * 啟動期：釋放相對積極，鼓勵供給端接入（算力上鏈）、流動性形成、使用者增長

  * 成長/成熟期：釋放速率逐步放緩，強化稀缺性與供需平衡

  * 目的：避免“挖礦即拋壓”造成系統短期過熱，並讓長期激勵可持續

  2. 自然增長曲線（Smooth Growth）

  * 斐波那契帶來的「非線性平滑」可抑制擴張過程中的驟熱驟冷

  * 在算力大幅新增時，不讓獎勵同幅度線性增加；在算力下降時，也避免獎勵驟降導致供給端崩盤

  3. 供需與風險掛鉤（Risk-weighted Allocation）

  * 算力收益不是只看 hashrate，還看：
    * uptime、穩定性、歷史履約
    * 能耗/碳排指標（ESG 權重）
    * 合規狀態（可服務市場範圍）
  * 高風險/低透明算力，即使額定算力高，也可能被折算成較低「有效算力」

  ### AI 動態調節與參數控制（AI Governance Layer）

  斐波那契提供「長期規則邊界」，AI 提供「局部自適應」：在不破壞供給曲線的前提下，對參數做小幅動態調整（例如年度變化控制在約 10% 級別），讓系統能面對現實波動。

  A. AI 輸入信號（Signals）

  * 供給端：接入算力增速、故障率、收益偏差、地區分佈
  * 需求端：cNFT/cToken 交易深度、借貸利用率、清算觸發頻率
  * 市場端：BTC 難度/價格波動、手續費、主要利率
  * 風險端：異常事件（礦池變更、政策風險、攻擊行為）

  B. 可調參數（Knobs）

  * 有效算力折扣係數（stability/ESG/合規加權）
  * 激勵分配比例（供給端 vs 流動性端 vs 生態基金）
  * 風險緩衝池注入比例（黑天鵝準備金）
  * 抵押品折價率（用於借貸清算的風控參數）

  C. 控制方式（Control）

  * AI 只輸出「建議區間」，最終由 DAO 以鏈上治理確認或以預設策略自動執行
  * 核心原則：可解釋（explainable）、可回溯（auditable）、可回滾（rollback）


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://aurora-21.gitbook.io/aurora-docs/ji-shu-jia-gou/fei-bo-na-qi-suan-li-mo-zu.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.