> 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/an-quan-xing-yu-ke-kuo-zhan-xing.md).

# 安全性與可擴展性

### 鏈上風控與合約安全

在區塊鏈鏈上環節，本計畫內建完善的風險控制措施與智能合約安全架構：

* 資產上鏈審核機制：任何實物黃金資產對應的代幣在上鏈發行前，必須通過 DAO 治理的白名單提案批准以及風控團隊的風險審查。只有經社群投票同意且風險評估合格的資產，才能映射為鏈上代幣，從源頭把關資產品質與合規性。
* 清算與風險控制邏輯：智能合約中預先內建嚴格的抵押率監控、清算條件和風險控制邏輯。一旦代幣化黃金用於抵押融資或其他DeFi場景，鏈上風控模組將持續實時監測抵押品價值變動，涵蓋抵押率、清算邊界和異常操作偵測等。一旦觸發清算條件，合約將自動執行清算程序或風險處置，保障整體系統的資產安全。
* 多重簽名與角色分離：採用多重簽名錢包對關鍵合約操作進行管理，將合約治理權限分散給多個經授權的管理者，以提高容錯能力。同時實行嚴格的角色分離制度，將合約管理職能按職責劃分為不同角色（如合約管理員、升級管理員、應急管理員等），各角色權限獨立。多簽與角色分離的結合確保即使個別管理人員出現疏失或惡意行為，也無法單方面危及系統安全，提升合約治理的靈活性與安全等級。

基於角色的存取控制：正如前文基礎結構所述，應限制敏感操作（鑄造、狀態更新、銷毀）的存取權限。除 Ownable 模式外，建議使用 OpenZeppelin 的 AccessControl 以實現更靈活的權限管理。可定義例如 MINTER\_ROLE（鑄造權限）、UPDATER\_ROLE（預言機更新權限）、PAUSER\_ROLE（緊急暫停權限）等角色。部署合約的管理員（可為多簽地址）作為 DEFAULT\_ADMIN，負責向不同營運帳戶授予或撤銷這些角色。透過角色隔離，可降低單一私鑰洩漏所帶來的風險。例如，即使擁有鑄造權限的帳戶被盜，攻擊者也無法直接修改託管狀態，因為該操作屬於 UPDATER\_ROLE 帳戶的權限範圍。

多簽管理員：在實際部署中，建議將合約的所有者或預設管理員設定為多簽錢包（如 Gnosis Safe）。如此一來，所有僅限 Owner 才能執行的操作（如角色授予、關鍵參數變更）都需經多方簽名確認後方可生效。這一點對 Aurora 黃金平台尤為重要，因平台需符合合規與風控要求，避免單人控制實體憑證的情況。多簽管理員亦可搭配時間鎖等機制，提高治理流程的透明度，便於審計追蹤每一項敏感操作由哪些成員核准。

暫停機制：引入 Pausable 模組可在緊急情況下暫時凍結合約功能。Aurora 黃金 NFT 涉及實體資產，安全性不容有失。若發現預言機資料異常（例如疑似遭攻擊而回傳錯誤狀態）或合約出現漏洞，管理員應即時觸發暫停。在暫停狀態下，可禁止 NFT 的轉移、鑄造及狀態更新等操作，以確保問題排查期間資產不會被錯誤轉移。僅有持有 PAUSER\_ROLE 或合約 Owner 的多簽帳戶才能呼叫 pause() 與 unpause()。暫停功能相當於系統的緊急停止開關，提供一層即時的保護機制。

輸入驗證與安全程式設計：在開發合約函式時，需嚴格檢查輸入參數與呼叫來源。例如在 updateStatus 函式中，需驗證傳入的新狀態是否屬於允許的列舉值，以及呼叫者是否持有授權簽名或預言機角色。此外，應避免使用 tx.origin 等不安全的驗證方式，改以 msg.sender 搭配 AccessControl／Ownable 進行權限驗證。所有外部呼叫盡量使用 call 而非低階 send，以檢查執行結果並防範重入攻擊（如 NFT 涉及支付功能時，可考慮引入 ReentrancyGuard）。使用 Solidity 0.8.x 編譯器預設啟用的溢位檢查，可有效避免整數溢位漏洞，並應善用 OpenZeppelin 函式庫中已通過審計的元件，避免重複實作而引入潛在風險。

相容性與標準擴充：確保合約符合 ERC721 標準的介面要求，包括 IERC721、IERC721Metadata（提供 name、symbol、tokenURI），以及（可選）IERC721Enumerable 介面。若實作了 Enumerable 或 AccessControl 等功能，亦需在 supportsInterface 中宣告支援對應的 interfaceId，以便錢包與區塊瀏覽器正確識別合約功能。對於中繼資料格式，也應遵循通用標準，例如 OpenSea 所要求的 JSON 欄位結構。採用常見標準有助於 Aurora 黃金 NFT 獲得更廣泛的相容與支援。未來若考慮升級至 ERC721 的新擴充（如 ERC721A、ERC6454 等），亦應盡量保持向後相容。

可升級性：實體資產數位化專案通常生命週期較長，且需求可能隨時間演進，合約設計時可考慮可升級方案，例如採用代理合約模式（Transparent／UUPS Proxy）以利後續替換實作邏輯。然而，引入可升級性亦需權衡安全性，因升級權限可能帶來中心化風險。若選擇可升級模式，應將代理管理員設定為多簽帳戶，並在治理流程中加入充分的社群審閱與延遲機制，以防止升級被濫用。反之，若選擇不可升級的永久合約，則必須在部署前進行充分測試與審計，因一旦發現漏洞僅能透過部署新合約並遷移資產處理，於實體資產場景中成本較高。因此是否採用可升級設計，需結合 Aurora 平台的治理能力與風險偏好審慎決定。

效能與成本：在確保安全與功能需求的前提下，亦需關注 Gas 成本與效能擴充性。鑄造與更新操作會消耗鏈上資源，若部署於 Aurora 等交易費用相對低廉的網路，壓力較小，但仍應避免不必要的儲存讀寫。例如在批量鑄造情境下，可考慮 Gas 最佳化的批量 mint 方案，或使用效率較高的 ERC721 實作（如 ERC721A，惟其對動態更新的支援有限）。當 NFT 數量極大時，Enumerable 擴充的效能瓶頸亦需留意，必要時可使用 The Graph 等鏈下索引服務取代部分鏈上列舉功能，以減輕合約負擔。

審計與測試：最後且同樣重要的是，在主網部署前必須對合約進行全面測試與第三方審計。測試內容應涵蓋正常業務流程（鑄造、轉移、提貨等）與異常流程（惡意輸入、權限繞過、預言機延遲或錯誤等），以確保合約在各種情況下皆能如預期運作。審計則有助於發現潛在的安全漏洞與邏輯缺陷。特別是涉及實體資產的合約，通常需接受更嚴格的安全審查，包括對預言機機制與多簽管理合理性的評估。唯有經過充分的測試與審計，方能最大程度確保 Aurora 黃金 NFT 合約在複雜環境中的安全穩定運行。

### 預言機與資料驗證安全

為確保鏈上所依賴的外部數據真實可靠，本計畫建立了安全的預言機機制與數據驗證流程：

* 多源預言機架構：關鍵數據（例如黃金庫存、金價行情、收益數據等）由多個獨立來源提供，包括金庫托管方、第三方審計報告、礦場生產數據、主流交易所報價等。預言機節點從多來源收集數據並進行交叉比對，由多個節點共同簽名確認後再提供給鏈上合約使用，同時附加時間戳防止數據回溯篡改，避免單一數據源失準的風險。
* 證明與容錯機制：引入鏈上/鏈下的 Proof-of-Attestation (PoA) 機制，確保實物資產和關鍵事件都有見證記錄上鏈。此外，實施 N-of-M 的錯誤容忍閾值驗證機制：例如在 M 個節點中至少 N 個達成一致方認可數據有效，容忍少數節點故障或異常。這種多節點共識機制進一步提高了數據餵送的可靠性與抗操縱性。
* 數據加密上鏈：所有關鍵業務數據在上鏈時均經過加密處理，僅供授權的智能合約模組解讀引用，防止敏感資訊洩露。同時，將重要參數和狀態變量上鏈存證，讓監管者與參與者可查驗系統狀態，但合約執行不依賴任何單一中心化資料庫或伺服器，確保數據來源安全且無單點失效風險。


---

# 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/an-quan-xing-yu-ke-kuo-zhan-xing.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.