4 API per gli asset digitali

Oracle Blockchain Platform Enterprise Edition per Besu offre API per gli asset digitali che puoi utilizzare per lavorare con gli smart contract.

Le API degli asset digitali sono componenti riutilizzabili e basati su Solidity per lo sviluppo, il test e l'implementazione di smart contract degli asset digitali su Besu. Puoi utilizzare le API per implementare applicazioni di token specifiche del dominio, mantenendo al contempo approcci coerenti alla configurazione dei token, ai controlli di identità e accesso, alla aggiornabilità e alla governance.

La base di qualsiasi applicazione Oracle Blockchain Platform Besu è uno o più smart contract che definiscono gli stati di un asset digitale e le regole aziendali che governano il modo in cui viene creato, trasferito, detenuto, riscattato e gestito. Poiché queste regole influiscono direttamente sul ciclo di vita del cespite, i contratti devono essere progettati, rivisti e testati prima della distribuzione. Ognuna delle due API supporta uno standard di token diverso.

Standard token	Utilizzo principale	Esempi di casi d'uso
ERC-20	Asset fungibili in cui ogni token è intercambiabile con ogni altro token.	Pagamenti, stablecoin, token di deposito, token di liquidazione e asset CBDC all'ingrosso.
ERC-1155	Attività fungibili e attività non fungibili (NFT). Nello stesso smart contract sono supportati più tipi di token. Sono supportati i token frazionari (condivisioni).	Asset, raccolte e asset digitali unici.

Le API forniscono contratti di base configurabili e librerie di supporto che è possibile ereditare o comporre nei propri contratti Solidity. A seconda del modello di token selezionato, le applicazioni possono incorporare funzionalità quali la stampa e la masterizzazione, i trasferimenti controllati, i blocchi, le approvazioni, le autorizzazioni di riconoscimento delle identità e l'applicazione dei criteri. Le API supportano anche modelli di contratto aggiornabili e operazioni del ciclo di vita controllate dalla governance se queste sono richieste da un'applicazione.

Il seguente diagramma illustra le capacità delle implementazioni standard di token ERC-20 estese.

Il seguente diagramma illustra le capacità delle implementazioni standard ERC-1155token estese.

Moduli di controllo dell'accesso collegabili

È possibile selezionare moduli account e criteri per allineare le operazioni token al modello di controllo dell'accesso di un'applicazione. In particolare, l'API include versioni di contratti e conti per i modelli di autorizzazione ERC-5982 e EIP-6617. Questi moduli connettono i contratti token ai gateway di identità e criteri, consentendo alle applicazioni di applicare autorizzazioni basate su ruoli e basate sull'organizzazione senza incorporare un'unica implementazione del controllo dell'accesso in ogni contratto token.

È possibile scegliere la variante di account e le funzionalità dei criteri che si adattano all'applicazione, quindi utilizzare le interfacce di account comuni dai contratti token. Questa separazione mantiene la logica aziendale dei token focalizzata sul ciclo di vita degli asset, consentendo al contempo di configurare, estendere o scambiare i criteri di accesso man mano che i requisiti dell'applicazione si evolvono.

Modello composizione contratto

Il livello di tokenizzazione Solidity utilizza un modello di composizione del contratto. È possibile selezionare una base di token aggiornabile, aggiungere i moduli di comportamento richiesti dal ciclo di vita dell'asset, quindi associare il token a un account e a un modulo di controllo dell'accesso appropriati. Questo modello supporta funzionalità come il minting, la masterizzazione, i blocchi e le approvazioni senza richiedere a ogni token di esporre ogni operazione. È possibile utilizzare composizione rigorosa o composizione mix / compatibilità.

La composizione rigorosa è appropriata quando le operazioni token supportate sono note al momento della progettazione. Gli sviluppatori ereditano da un contratto di base stretto che supporta solo funzionalità specifiche. Solo le operazioni selezionate sono incluse nell'ABI del contratto. Durante l'inizializzazione, la configurazione del token viene convalidata rispetto al profilo di capacità selezionato, in modo che vengano rifiutati comportamenti o modalità di stampa e masterizzazione incompatibili.

La composizione mixin / compatibilità è appropriata quando la flessibilità di runtime e un set più ampio e riutilizzabile di operazioni token sono più importanti. Gli sviluppatori ereditano da un contratto di base più completo, con flag di comportamento runtime che determinano quali criteri facoltativi sono attivi. L'ABI completa rimane disponibile, mentre le operazioni specifiche del comportamento applicano la configurazione abilitata quando vengono richiamate.

Scegliere la composizione più stretta che soddisfi i requisiti del prodotto, quindi combinarla con il modulo account di controllo dell'accesso richiesto e la business logic specifica del prodotto. La composizione rigorosa produce un ABI più piccolo e più intenzionale e impedisce che le operazioni non supportate vengano esposte. La composizione mixin/compatibilità fornisce una base più ampia per le applicazioni il cui comportamento deve essere configurato in fase di esecuzione.

Utilizza le API come punti di partenza anziché come applicazioni fisse. In genere, un team seleziona la base ERC-20 o ERC-1155 che corrisponde al modello di asset richiesto, configura il comportamento e i controlli di accesso, quindi implementa una logica aziendale specifica per supportare il ciclo di vita degli asset. Ciò consente una base contrattuale comune consentendo al contempo a ciascuna applicazione di riflettere i propri partecipanti, le regole di autorizzazione e i processi operativi.

Le API sono rivolte agli sviluppatori Solidity che lavorano direttamente con le fonti contrattuali ERC-20 e ERC-1155. Puoi sviluppare e testare le applicazioni utilizzando Hardhat, quindi distribuirle in un ambiente Oracle Blockchain Platform utilizzando l'approccio di distribuzione appropriato per l'applicazione.

Flusso di governance per la distribuzione e l'aggiornamento dei contratti

La governance controlla quando un contratto distribuito diventa utilizzabile e quali aggiornamenti dell'implementazione UUPS sono autorizzati. I progetti composti distribuiscono e connettono l'account e i proxy token, quindi associano entrambi a un contratto di governance e a un UUID di governance. I proxy sono deliberatamente inattivi fino a quando il flusso di governance configurato non li attiva, come mostrato nel ciclo di vita seguente:

1. Distribuire i proxy UUPS di account e token.
2. Impostare il contesto di account/token e il contesto di governance. I proxy rimangono inattivi.
3. Invia l'intento di distribuzione con componenti proxy, implementazione e code-hash.
4. • No-Op: Accettato immediatamente, componenti attivati.
   • Governato: raccoglie le approvazioni dei criteri, quindi i componenti vengono attivati dopo l'approvazione.

Modelli di governance

I due modelli di governance supportati sono No-Op e Governed.

Nessuna opzione non rimuove il ciclo di vita governance dall'applicazione. Implementa la stessa interfaccia di governance, registra l'intento e approva automaticamente i controlli di distribuzione e aggiornamento. Non utilizzare il modello No-Op come meccanismo di approvazione della produzione.

Il modello controllato non consente al programma di distribuzione, al programma di generazione delle applicazioni Blockchain o a uno script CLI di ignorare gli approvatori. Gli approvatori, la soglia, la scadenza e il processo di approvazione richiesti sono definiti dalla governance distribuita e dalla configurazione dei criteri.

La tabella seguente riassume il comportamento dei due modelli di governance.

Modello di governance	Scopo	Comportamento distribuzione	Comportamento aggiornamento
Nessuna operazione	Sviluppo locale, demo e altre situazioni in cui l'approvazione della governance viene ignorata intenzionalmente.	La funzione proposeDeployIntent accetta l'intento e attiva immediatamente i suoi componenti.	L'intento di aggiornamento è accettato senza l'approvazione dei criteri; l'operatore esegue comunque il passo di esecuzione upgradeToAndCall preparato.
Con governance	Ambienti che richiedono revisione e approvazione basate su criteri.	L'intento rimane in sospeso fino a quando il criterio configurato non riceve le approvazioni richieste prima della scadenza; solo allora vengono attivati i componenti.	L'implementazione proposta e il relativo hash del codice devono ricevere l'autorizzazione richiesta prima che il passo di esecuzione possa consumare l'implementazione e aggiornare il proxy.

Quando si crea un progetto con Blockchain App Builder, vengono già forniti i seguenti modelli di governance:

• L'interfaccia IDAContractGovernance e le implementazioni NoOpGovernance e GovernedGovernance.
• Il contesto di governance e il supporto di attivazione sulle basi contrattuali di token e account generati, inclusi i metodi setGovernanceContext, getGovernanceContext e activateFromGovernance.
• L'autorizzazione di aggiornamento UUPS tramite il metodo UpgradeAuthorizationLib dell'API, che chiama il contratto di governance configurato durante il processo _authorizeUpgrade.
• Script di distribuzione e aggiornamento generati che impostano il contesto di governance, preparano i dati degli intenti, registrano i file manifesto e sottomettono richieste di intenti.

Poiché questi elementi costitutivi sono già forniti, un progetto composto standard non richiede la scrittura di hook di governance Solidity aggiuntivi per i relativi contratti token e account generati. È comunque necessario scegliere e distribuire o ottenere il contratto di governance appropriato, configurare l'UUID e il criterio e fornire i relativi indirizzi al workflow di distribuzione/upgrade e sottoporsi al processo di approvazione per gli ambienti gestiti. Per una rete Besu di Oracle Blockchain Platform, viene distribuito un contratto di governance nell'ambito del provisioning delle istanze.