4 Digitale Assets APIs

Oracle Blockchain Platform Enterprise Edition für Besu bietet APIs für digitale Assets, mit denen Sie mit Smart Contracts arbeiten können.

Die APIs für digitale Assets sind Solidity-basierte, wiederverwendbare Komponenten für die Entwicklung, das Testen und die Bereitstellung von Smart Contracts für digitale Assets auf Besu. Mit den APIs können Sie domänenspezifische Tokenanwendungen implementieren und dabei konsistente Ansätze für Tokenkonfiguration, Identitäts- und Zugriffskontrollen, Upgradefähigkeit und Governance beibehalten.

Der Kern jeder Oracle Blockchain Platform Besu-Anwendung ist ein oder mehrere Smart Contracts, die den Status eines digitalen Assets und die Geschäftsregeln definieren, die bestimmen, wie es erstellt, übertragen, gehalten, eingelöst und verwaltet wird. Da sich diese Regeln direkt auf den Lebenszyklus von Anlagen auswirken, müssen Verträge vor dem Deployment entworfen, geprüft und getestet werden. Jede der beiden APIs unterstützt einen anderen Tokenstandard.

Tokenstandard	Primäre Verwendung	Beispielanwendungsfälle
ERC-20	Fungible Assets, bei denen jedes Token mit jedem anderen Token austauschbar ist.	Zahlungen, Stablecoins, Einzahlungstoken, Abrechnungstoken und CBDC-Großhandelsvermögen.
ERC-1155	Fungible Assets und Non-Fungible (NFT) Assets. Im selben Smart-Vertrag werden mehrere Tokentypen unterstützt. Bruchteilige Token (Shares) werden unterstützt.	Tokenisierte Assets, Collections und eindeutige digitale Assets.

Die APIs bieten konfigurierbare Basisverträge und unterstützende Bibliotheken, die Sie von Ihren eigenen Solidity-Verträgen übernehmen oder daraus zusammenstellen können. Je nach ausgewähltem Tokenmodell können Anwendungen Funktionen wie Prägen und Brennen, kontrollierte Übertragungen, Sperren, Genehmigungen, identitätsbezogene Berechtigungen und Policy Enforcement integrieren. Die APIs unterstützen auch upgradefähige Vertragsmuster und Governance-gesteuerte Lebenszyklusvorgänge, wenn diese für eine Anwendung erforderlich sind.

Das folgende Diagramm veranschaulicht die Möglichkeiten der erweiterten ERC-20-Token-Standardimplementierungen.

Das folgende Diagramm veranschaulicht die Möglichkeiten der erweiterten ERC-1155token-Standardimplementierungen.

Integrierbare Zugriffskontrollmodule

Sie können Account- und Policy-Module auswählen, um Tokenvorgänge an dem Access-Control-Modell einer Anwendung auszurichten. Insbesondere enthält die API Vertrags- und Accountversionen für die Berechtigungsmodelle ERC-5982 und EIP-6617. Diese Module verbinden Tokenverträge mit Identitäts- und Policy-Gateways, sodass Anwendungen eine rollen- und organisationsspezifische Autorisierung anwenden können, ohne dass eine einzige Zugriffskontrollimplementierung in jeden Tokenvertrag eingebettet wird.

Sie können die Accountvarianten- und Policy-Funktionen auswählen, die zu Ihrer Anwendung passen, und dann die allgemeinen Accountschnittstellen aus den Tokenverträgen verwenden. Durch diese Trennung wird die Tokengeschäftslogik auf den Assetlebenszyklus ausgerichtet, während Zugriffs-Policys konfiguriert, erweitert oder ausgetauscht werden können, wenn sich die Anwendungsanforderungen ändern.

Vertragszusammensetzungsmodell

Die Solidity-Tokenisierungsebene verwendet ein Vertragszusammensetzungsmodell. Sie wählen eine upgradefähige Tokenbasis aus, fügen die für den Assetlebenszyklus erforderlichen Verhaltensmodule hinzu und koppeln das Token dann mit einem geeigneten Account- und Zugriffssteuerungsmodul. Dieses Modell unterstützt Funktionen wie Prägen, Brennen, Sperren und Genehmigungen, ohne dass jedes Token jeden Vorgang anzeigen muss. Sie können strikte Zusammensetzung oder Mixin-/Kompatibilitätszusammensetzung verwenden.

Eine strenge Zusammensetzung ist angemessen, wenn die unterstützten Tokenvorgänge zur Entwurfszeit bekannt sind. Entwickler erben von einem engen Basisvertrag, der nur bestimmte Funktionen unterstützt. Nur ausgewählte Vorgänge sind in der Vertrags-ABI enthalten. Während der Initialisierung wird die Tokenkonfiguration anhand des ausgewählten Funktionsprofils validiert, sodass inkompatible Verhaltensweisen oder Minting- und Burn-Modi abgelehnt werden.

Mixin / Kompatibilitätszusammensetzung ist geeignet, wenn Laufzeitflexibilität und ein breiterer, wiederverwendbarer Satz von Tokenoperationen wichtiger sind. Entwickler erben von einem Fuller-Basisvertrag, wobei Laufzeitverhaltens-Flags bestimmen, welche optionalen Policys aktiv sind. Die vollständige ABI bleibt verfügbar, während verhaltensspezifische Vorgänge die aktivierte Konfiguration erzwingen, wenn sie aufgerufen werden.

Wählen Sie die engste Zusammensetzung, die Ihren Produktanforderungen entspricht, und kombinieren Sie sie dann mit dem erforderlichen Kontomodul für die Zugriffssteuerung und der produktspezifischen Geschäftslogik. Strenge Zusammensetzung erzeugt eine kleinere, absichtlichere ABI und verhindert, dass nicht unterstützte Operationen ausgesetzt werden. Mixin/Kompatibilitätszusammensetzung bietet eine breitere Grundlage für Anwendungen, deren Verhalten zur Laufzeit konfiguriert werden muss.

Verwenden Sie die APIs als Ausgangspunkt und nicht als feste Anwendungen. In der Regel wählt ein Team die ERC-20- oder ERC-1155-Grundlage aus, die dem erforderlichen Assetmodell entspricht, konfiguriert das Verhalten und die Zugriffskontrollen und implementiert dann eine bestimmte Geschäftslogik zur Unterstützung des Assetlebenszyklus. Dies ermöglicht eine gemeinsame Vertragsgrundlage, während jede Anwendung ihre eigenen Teilnehmer, Autorisierungsregeln und betrieblichen Prozesse widerspiegeln kann.

Die APIs sind für Solidity-Entwickler gedacht, die direkt mit den Vertragsquellen ERC-20 und ERC-1155 arbeiten. Sie können Anwendungen mit Hardhat entwickeln und testen und dann mit dem für die Anwendung geeigneten Deployment-Ansatz in einer Oracle Blockchain Platform-Umgebung bereitstellen.

Governance-Ablauf für das Deployment und Upgrade von Verträgen

Governance steuert, wann ein bereitgestellter Vertrag nutzbar wird und welche UUPS-Implementierungsupgrades autorisiert sind. Zusammengesetzte Projekte stellen den Account und die Token-Proxys bereit und verbinden sie. Anschließend werden sie einem Governance-Vertrag und einer Governance-UUID zugeordnet. Die Proxys sind absichtlich inaktiv, bis der konfigurierte Governance-Ablauf sie aktiviert, wie im folgenden Lebenszyklus dargestellt:

1. Stellen Sie UUPS-Proxys für Accounts und Token bereit.
2. Account-/Tokenkontext und Governance-Kontext festlegen. Stellvertreter bleiben inaktiv.
3. Deployment-Intent mit Proxy-, Implementierungs- und Code-Hash-Komponenten weiterleiten.
4. • No-Op: Sofort angenommen, Komponenten aktiviert.
   • Gesteuert: Erfassen Sie Policy-Genehmigungen, und die Komponenten werden nach der Genehmigung aktiviert.

Governance-Modelle

Die beiden unterstützten Governance-Modelle sind No-Op und Governed.

No-Op entfernt den Governance-Lebenszyklus nicht aus der Anwendung. Es implementiert dieselbe Governance-Schnittstelle, zeichnet das Intent auf und genehmigt automatisch Bereitstellungs- und Upgradeprüfungen. Verwenden Sie das No-Op-Modell nicht als Produktionsgenehmigungsmechanismus.

Das gesteuerte Modell lässt nicht zu, dass der Deployer, Blockchain App Builder oder ein CLI-Skript Genehmiger umgehen. Die erforderlichen Genehmiger, der Schwellenwert, die Frist und der Genehmigungsprozess werden durch die bereitgestellte Governance- und Policy-Konfiguration definiert.

In der folgenden Tabelle wird das Verhalten der beiden Governance-Modelle zusammengefasst.

Governance-Modell	Zweck	Deployment-Verhalten	Upgradeverhalten
Vorgang findet nicht statt	Lokale Entwicklung, Demos und andere Situationen, in denen die Genehmigung der Governance absichtlich umgangen wird.	Die Funktion proposeDeployIntent akzeptiert das Intent und aktiviert seine Komponenten sofort.	Das Upgrade-Intent wird ohne Policy-Genehmigung akzeptiert. Der Operator führt weiterhin den vorbereiteten upgradeToAndCall-Ausführungsschritt aus.
Governance	Umgebungen, die eine richtlinienbasierte Überprüfung und Genehmigung erfordern.	Das Intent bleibt ausstehend, bis die konfigurierte Policy die erforderlichen Genehmigungen vor Ablauf der Frist erhält. Nur dann werden Komponenten aktiviert.	Die vorgeschlagene Implementierung und ihr Code-Hash müssen die erforderliche Autorisierung erhalten, bevor der Ausführungsschritt die Implementierung konsumieren und das Proxy-Upgrade durchführen kann.

Wenn Sie ein Projekt mit Blockchain App Builder erstellen, werden bereits die folgenden Governance-Bausteine bereitgestellt:

• Die Schnittstelle IDAContractGovernance und die Implementierungen NoOpGovernance und GovernedGovernance.
• Governance-Kontext und Aktivierungsunterstützung für generierte Token- und Accountvertragsbasen, einschließlich der Methoden setGovernanceContext, getGovernanceContext und activateFromGovernance.
• UUPS-Upgradeautorisierung über die API-Methode UpgradeAuthorizationLib, die den konfigurierten Governance-Vertrag während des _authorizeUpgrade-Prozesses aufruft.
• Generierte Deployment- und Upgradeskripte, die Governance-Kontext festlegen, Intent-Daten vorbereiten, Manifeste aufzeichnen und Intent-Anforderungen weiterleiten.

Da diese Bausteine bereits bereitgestellt sind, erfordert ein standardbasiertes Projekt nicht, dass Sie zusätzliche Solidity-Governance-Hooks für die generierten Token- und Kontoverträge schreiben. Sie müssen weiterhin den entsprechenden Governance-Vertrag auswählen und bereitstellen oder abrufen, die UUID und die Policy konfigurieren und ihre Adressen für den Deployment-/Upgradeworkflow angeben sowie den Genehmigungsprozess für gesteuerte Umgebungen durchlaufen. Bei einem Oracle Blockchain Platform Besu-Netzwerk wird ein Governance-Vertrag als Teil der Instanzbereitstellung bereitgestellt.