數位資產 API

4 數位資產 API

Oracle Blockchain Platform Enterprise Edition for Besu 提供數位資產 API，可用來處理智能合約。

數位資產 API 是 Solidity 型、可重複使用的元件，可用於開發、測試及部署 Besu 上的數位資產智能合約。您可以使用 API 實作網域特定的記號應用程式，同時保持對記號組態、識別和存取控制、可升級性及治理的一致方法。

任何 Oracle Blockchain Platform Besu 應用程式的核心是一或多個智能合約，定義了數位資產的狀態，以及管理如何建立、轉移、保留、贖回和管理的業務規則。由於這些規則會直接影響資產生命週期，因此必須在部署之前設計、複查及測試合約。這兩個 API 都支援不同的記號標準。

權杖標準	主要用途	使用案例範例
二氧化碳 -20	每個權杖都可互換的有趣資產。	付款、穩定幣、存款權杖、結算權杖及批發 CBDC 資產。
ERC-1155	有趣資產及不可變 (NFT) 資產。相同的智慧型合約支援多種權杖類型。支援小數記號 (共用)。	權杖化資產、集合和獨特的數位資產。

API 提供可設定的基本合約和支援程式庫，您可以繼承自或組成您自己的 Solidity 合約。視選取的權杖模型而定，應用程式可以納入一些功能，例如探勘和燒錄、受控制的傳輸、保留、核准、識別感知權限以及原則強制實行。API 也支援可升級的合約模式和受治理控制的生命週期作業 (如果應用程式需要這些作業)。

下圖說明延伸 ERC-20 權杖標準實作的功能。

下圖說明延伸 ERC-1155token 標準實作的功能。

可插式存取控制模組

您可以選取帳戶和原則模組，讓記號作業與應用程式的存取控制模型保持一致。具體而言，API 包括 ERC-5982 和 EIP-6617 權限模型的合約和帳戶版本。這些模組可將權杖合約連線至身分識別和原則閘道，讓應用程式無須在每個權杖合約中內嵌單一存取控制實作，即可套用角色感知和組織感知授權。

您可以選擇適合應用程式的科目變異和原則功能，然後使用權杖合約中的通用科目介面。此區隔可將權杖業務邏輯集中在資產生命週期，同時允許在應用程式需求發展時設定、擴充或交換存取原則。

合約組成模型

Solidity 代碼化層使用合約組成模型。您可以選取可升級的權杖基準、新增資產生命週期所需的行為模組，然後將權杖與適當的帳戶和存取控制模組配對。此模型支援如採礦、燒錄、保留和核准等功能，無需每個權杖即可顯示每項作業。您可以使用嚴格組合或混合 / 相容性組合。

嚴格組合適用於在設計階段已知支援的記號作業。開發人員繼承自僅支援特定功能的狹窄基準合約。只有選取的作業會包含在合約 ABI 中。在初始化期間，記號組態會根據選取的功能設定檔進行驗證，因此會拒絕不相容的行為或探勘和燒錄模式。

混合 / 相容性組成適用於執行時期彈性，且更廣泛且可重複使用的記號作業集更重要時。開發人員繼承自更完整的基本合約，而程式實際執行行為旗標則決定作用中的選擇性原則。完整的 ABI 會保持可用狀態，而行為特定的作業會在呼叫時強制執行已啟用的組態。

選擇最窄的組合，以符合您的產品需求，然後將其與所需的存取控制帳戶模組及產品特定的業務邏輯結合。嚴格組合會產生較小、更故意的 ABI，並防止不受支援的作業暴露。混合 / 相容性組合為必須在程式實際執行時設定行為的應用程式提供更廣泛的基礎。

使用 API 作為起點，而非固定的應用程式。一般而言，團隊會選取符合所需資產模型的 ERC-20 或 ERC-1155 基礎、設定行為與存取控制，然後實作特定的業務邏輯來支援資產生命週期。這可啟用通用合約基礎，同時允許每個應用程式反映其本身的參與者、授權規則及作業流程。

此 API 適用於 Solidity 開發人員，可直接使用 ERC-20 和 ERC-1155 合約來源。您可以使用 Hardhat 開發和測試應用程式，然後使用適合應用程式的部署方法部署到 Oracle Blockchain Platform 環境。

部署與升級合約的治理流程

治理可控制已部署合約何時可用，以及獲得哪些 UUPS 導入升級授權。組合的專案會部署並連結帳戶和權杖代理，然後將兩者附加至治理合約和治理 UUID。在設定的治理流程啟動代理主機之前，代理主機會刻意停用，如下列生命週期所示：

部署帳戶和權杖 UUPS 代理主機。
設定帳戶 / 權杖相關資訊環境和治理相關資訊環境。代理主機維持非作用中。
透過代理、導入和程式碼雜湊元件提交部署意圖。
- No-Op：立即接受，元件已啟用。
- 受控：收集原則核准，然後在核准後啟用元件。

治理模型

這兩種支援的治理模型皆為「免費」和「治理」。

「否」並不會從應用程式移除治理週期。它實作相同的治理介面、記錄意圖，以及自動核准部署和升級檢查。請勿使用 No-Op 模型作為生產核准機制。

受控模型不允許部署者、區塊鏈 App 產生器或 CLI 命令檔略過核准者。必要的核准者、臨界值、期限及核准程序是由建置的治理和原則組態所定義。

下表摘要兩個治理模型的行為。

治理模型	目的	部署行為	升級行為
無作業	本地開發、示範和其他故意略過治理核准的情況。	`proposeDeployIntent` 函數接受意圖並立即啟動其元件。	不需核准原則即可接受升級意圖；運算子仍然會執行準備好的 `upgradeToAndCall` 執行步驟。
已管控	需要原則式複查與核准的環境。	目的會維持擱置中狀態，直到設定的原則在其期限之前收到必要的核准；只有元件才會啟動。	建議的實行及其程式碼雜湊必須先接收必要的授權，執行步驟才能使用實行並升級代理主機。

當您使用 Blockchain App Builder 建置專案時，已經提供下列治理建置區塊：

IDAContractGovernance 介面和 NoOpGovernance 和 GovernedGovernance 實作。
對產生的權杖和帳戶合約基礎 (包括 setGovernanceContext、getGovernanceContext 和 activateFromGovernance 方法) 提供治理相關資訊環境和啟用支援。
透過 API 的 UpgradeAuthorizationLib 方法 (在 _authorizeUpgrade 處理過程中呼叫已設定的治理合約) 進行 UUPS 升級授權。
產生的部署與升級指令碼，可設定治理內容、準備意向資料、記錄資訊清單及提交意向要求。

因為已提供這些建置區塊，所以標準組成的專案不需要您為其產生的權杖與帳戶合約撰寫額外的「實體治理」鉤點。您仍然必須選擇並部署或取得適當的治理合約、設定 UUID 和原則，並將其位址提供給部署 / 升級工作流程，以及進行治理環境的核准程序。對於 Oracle Blockchain Platform Besu 網路，會在執行處理佈建過程中部署治理合約。