数字资产 API

4 数字资源 API

Oracle Blockchain Platform Enterprise Edition for Besu 提供数字资产 API，您可以使用这些 API 来处理智能合同。

数字资产 API 是基于 Solidity 的可重用组件，用于在 Besu 上开发、测试和部署数字资产智能合同。您可以使用 API 实施特定于域的令牌应用，同时保留一致的令牌配置、身份和访问控制、可升级性和监管方法。

任何 Oracle Blockchain Platform Besu 应用的核心都是一个或多个智能合约，这些合约定义了数字资产的状态以及管理数字资产的创建、转移、持有、兑换和管理方式的业务规则。由于这些规则直接影响资产生命周期，因此必须在部署之前设计、审核和测试合同。这两个 API 中的每个都支持不同的令牌标准。

标记标准	主要用途	用例示例
ERC-20	可变资产，其中每个令牌可与其他令牌互换。	支付、稳定币、存款代币、结算代币和批发 CBDC 资产。
ERC-1155	有形资产和非无形资产 (NFT)。同一智能合同中支持多个令牌类型。支持小数标记（共享资源）。	标记化的资产、集合和独特的数字资产。

API 提供可配置的基本合同和支持库，您可以从 Solidity 合同继承或组成这些库。根据所选的令牌模型，应用程序可以包含铸造和刻录、控制传输、保留、审批、身份感知权限和策略实施等功能。如果应用需要可升级的合同模式和治理控制的生命周期操作，API 还支持这些操作。

下图说明了扩展的 ERC-20 令牌标准实现的功能。

下图说明了扩展的 ERC-1155 令牌标准实现的功能。

可插拔访问控制模块

您可以选择账户和策略模块，以将令牌操作与应用程序的访问控制模型对齐。具体而言，API 包括 ERC-5982 和 EIP-6617 权限模型的合同和账户版本。这些模块将令牌合同连接到身份和策略网关，允许应用程序应用角色感知和组织感知授权，而无需在每个令牌合同中嵌入单个访问控制实施。

您可以选择适合您应用的账户变量和策略功能，然后使用令牌合同中的公用账户接口。这种分离可使令牌业务逻辑专注于资产生命周期，同时允许随着应用需求的发展而配置、扩展或交换访问策略。

合同构成模型

Solidity 标记层使用合约组成模型。您可以选择可升级的令牌基础，添加资产生命周期所需的行为模块，然后将该令牌与相应的帐户和访问控制模块配对。此模型支持铸造、刻录、暂挂和审批等功能，而不需要每个令牌来公开每个操作。您可以使用严格组合或混合/兼容组合。

在设计时已知支持的令牌操作时，严格组合是合适的。开发人员从仅支持特定功能的狭窄基础合同中继承。合同 ABI 中仅包括选定的工序。在初始化期间，将根据所选功能配置文件验证令牌配置，以便拒绝不兼容的行为或铸造和刻录模式。

当运行时灵活性和更广泛、可重复使用的令牌操作集更为重要时，Mixin/兼容性组合是合适的。开发人员从更全面的基本合同继承，运行时行为标志可确定哪些可选策略处于活动状态。完整的 ABI 仍然可用，而行为特定的操作在调用时会强制执行启用的配置。

选择符合您的产品要求的最窄组合，然后将其与所需的访问控制帐户模块和特定于产品的业务逻辑相结合。严格的成分会产生更小、更故意的 ABI，并防止不受支持的操作暴露。Mixin/兼容性组合为必须在运行时配置其行为的应用程序提供了更广泛的基础。

使用 API 作为起点，而不是用作固定应用程序。通常，团队会选择与所需资产模型匹配的 ERC-20 或 ERC-1155 基础，配置行为和访问控制，然后实施特定的业务逻辑来支持资产生命周期。这有助于建立通用的合同基础，同时允许每个应用程序反映自己的参与者、授权规则和运营流程。

API 适用于 Solidity 开发人员，他们直接使用 ERC-20 和 ERC-1155 合同来源。您可以使用 Hardhat 开发和测试应用，然后使用适合应用的部署方法部署到 Oracle Blockchain Platform 环境。

用于部署和升级合同的监管流

监管控制部署的合同何时可用以及哪些 UUPS 实施升级已获授权。组合项目部署并连接账户和令牌代理，然后同时附加到监管合同和监管 UUID。在配置的监管流激活代理之前，代理是故意不活动的，如以下生命周期中所示：

部署帐户和令牌 UUPS 代理。
设置账户/令牌上下文和监管上下文。代理保持不活动状态。
使用代理、实施和代码散列组件提交部署意图。
- No-Op：立即接受，激活组件。
- Governed：收集策略审批，然后在审批后激活组件。

监管模型

支持的两种治理模式为“无运营”和“监管”。

No-Op 不会从应用程序中删除监管生命周期。它实施相同的监管界面，记录意图，并自动批准部署和升级检查。请勿将“无工序”模型用作生产审批机制。

被监管模型不允许部署者、区块链应用构建器或 CLI 脚本绕过审批者。所需的审批人、阈值、截止日期和审批流程由部署的监管和策略配置定义。

下表汇总了两种治理模型的行为。

监管模型	用途	部署行为	升级行为
无操作	故意绕过治理审批的本地开发、演示和其他情况。	`proposeDeployIntent` 函数接受 Intent 并立即激活其组件。	未经策略批准即可接受升级意图；操作员仍运行准备好的 `upgradeToAndCall` 执行步骤。
受监管	需要基于策略的审查和审批的环境。	在配置的策略在截止日期之前收到所需的审批之前，意图将保持暂挂状态；仅在此之后才激活组件。	提议的实现及其代码散列必须获得所需的授权，然后执行步骤才能使用实现并升级代理。

使用区块链应用程序构建器构建项目时，已提供以下治理构建块：

IDAContractGovernance 接口以及 NoOpGovernance 和 GovernedGovernance 实现。
对生成的令牌和账户合同库（包括 setGovernanceContext、getGovernanceContext 和 activateFromGovernance 方法）提供监管上下文和激活支持。
UUPS 通过 API 的 UpgradeAuthorizationLib 方法进行升级授权，该方法在 _authorizeUpgrade 过程中调用配置的监管合同。
生成的部署和升级脚本，用于设置监管上下文、准备意图数据、记录清单和提交意图请求。

由于已经提供了这些构建块，因此标准组合项目不需要为其生成的令牌和账户合同编写额外的 Solidity 管理挂钩。您仍必须选择和部署或获取适当的监管合同，配置 UUID 和策略，并将其地址提供给部署/升级工作流，并接受监管环境的审批流程。对于 Oracle Blockchain Platform Besu 网络，在实例预配过程中会部署治理合同。