✍️ Traduzione by Dash Italia — Fonte originale
[Questo articolo è stato scritto il 9 Agosto 2023 quindi alcune informazioni potrebbero essere cambiate nel frattempo]
Tutti nel Web3 conoscono già gli Smart Contract, l’innovazione rivoluzionaria di Ethereum che ha reso popolare il concetto di dapp. Tuttavia, pochi sono a conoscenza del nuovo supplemento della Dash Platform agli Smart Contract che renderà lo sviluppo di dapp più accessibile alle masse: i Data Contract.
I Data Contract sono uno strumento potente già ampiamente utilizzato nel panorama dei servizi dati Web2 per i loro numerosi vantaggi per l’esperienza utente e di sviluppo. Sono schemi JSON relativamente semplici che definiscono le strutture dei dati che una dapp può archiviare. Utilizzarli nella Dash Platform ci consente di sfruttare i loro vantaggi tradizionali e al contempo di consentire agli sviluppatori Web2 di archiviare i dati delle loro app su una piattaforma Web3 decentralizzata senza dover imparare un linguaggio di Smart Contract come Solidity. Piuttosto, possono farlo facilmente semplicemente utilizzando costrutti con cui hanno già familiarità.
Oltre a una maggiore accessibilità e un’esperienza utente più fluida, i Data Contract abilitano anche una varietà di altre utili funzionalità, come l’indicizzazione semplice, il controllo delle versioni e la documentazione integrata. In definitiva, aiuteranno a coltivare un ecosistema diversificato di dapp basate su Dash e a diffondere maggiormente l’adozione delle criptovalute nel loro complesso.
Questo articolo accompagna il rilascio di dashpay.io , un’app Web in cui gli utenti possono generare automaticamente un contratto dati in base alle descrizioni della loro dapp desiderata utilizzando l’intelligenza artificiale. Inizieremo esaminando l’architettura di alto livello e le applicazioni dei Data Contract prima di tornare indietro e approfondire i dettagli dell’architettura.
Applicazione
A un livello elevato, un contratto dati di Dash Platform è uno schema JSON che definisce le strutture dei dati che una dapp memorizzerà. Definisce le proprietà consentite, come “città” o “cucina” per una dapp ristorante, la logica di convalida, come “maxLength” di una proprietà stringa e gli indici creati sulle proprietà. Gli sviluppatori devono inviare i loro Data Contract a Platform per la convalida a livello di sistema prima che gli utenti delle loro dapp possano inviare documenti ai loro Data Contract per la convalida a livello di dapp. Ciò garantisce che i dati dapp funzionino bene con il resto del sistema, dando al contempo agli sviluppatori il controllo sulla struttura e sui tipi di dati che possono essere inviati alle loro dapp. I Data Contract sono quindi utili per una serie di motivi oltre a consentire una facile transizione da Web2 a Web3:
Mentre gli Smart Contract che sono una priorità assoluta dopo il lancio della v1, saranno in sinergia con i Data Contract per abilitare una gamma molto più ampia di funzionalità per le dapp su Dash Platform, ci sono ancora molte possibilità con i soli Data Contract. Lo sviluppatore di Dash Incubator Pshenmic ci ha fornito alcuni esempi di cui è personalmente entusiasta:
Se sei interessato a saperne di più sulle possibili applicazioni che i Data Contract abilitano su Dash Platform, dai un’occhiata a questo fantastico articolo del 2021 di Hackernoon: Building dapps On Dash: An Interview With readme .
Ora, passiamo all’architettura.
Architettura
Come già affermato in precedenza, un contratto dati Dash Platform è uno schema JSON che definisce le strutture dei dati che una dapp può archiviare. Definisce le proprietà consentite, la logica di convalida e gli indici creati sulle proprietà.
Uno schema JSON del contratto dati Dash Platform deve definire almeno un tipo di documento . Un tipo di documento definisce un tipo di documento che può essere inviato a un contratto dati. Richiedono tre campi: type, properties e additionalProperties e supportano due campi facoltativi: indices e required. Un contratto dati con un tipo di documento, nft, che impiega tutti e cinque i campi, potrebbe apparire così, ad esempio:
{
"nft": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Name of the NFT token",
"maxLength": 63
},
"description": {
"type": "string",
"description": "Description of the NFT token",
"maxLength": 256
},
"imageUrl": {
"type": "string",
"description": "URL of the image associated with the NFT token",
"maxLength": 2048,
"format": "uri"
},
"imageHash": {
"type": "array",
"description": "SHA256 hash of the bytes of the image specified by tokenImageUrl",
"byteArray": true,
"minItems": 32,
"maxItems": 32
},
"imageFingerprint": {
"type": "array",
"description": "dHash the image specified by tokenImageUrl",
"byteArray": true,
"minItems": 8,
"maxItems": 8
},
"price": {
"type": "number",
"description": "Price of the NFT token in Dash",
"minimum": 0
},
"quantity": {
"type": "integer",
"description": "Number of tokens in circulation",
"minimum": 0
},
"metadata": {
"type": "array",
"description": "Any additional metadata associated with the NFT token",
"byteArray": true,
"minItems": 0,
"maxItems": 2048
}
},
"indices": [
{
"name": "price",
"properties": [
{
"price": "asc"
}
]
},
{
"name": "quantity",
"properties": [
{
"quantity": "asc"
}
]
},
{
"name": "priceAndQuantity",
"properties": [
{
"price": "asc"
},
{
"quantity": "asc"
}
]
}
],
"required": [
"name",
"price",
"quantity"
],
"additionalProperties": false
}
}
Figura 1: Un contratto dati Dash Platform con un tipo di documento, “nft”.
I tipi di documento nella Dash Platform sono oggetti JSON e pertanto devono specificare “type”:”object”. Devono inoltre specificare un set di properties contenente almeno una propietà e “additionalProperties”:false. Facoltativamente, possono anche includere un elenco di indices e un elenco di proprietà required. Ecco un esempio di un documento nft valido (con alcuni campi troncati) che potrebbe essere inviato al contratto dati di cui sopra:
{
"name": "Dash Cat 001",
"description": "The original Dash Cat. Meow.",
"imageUrl": "…",
"imageHash": [0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, …],
"price": 50,
"quantity": 1
}
Figura 2: Un documento valido (con alcuni campi troncati) che potrebbe essere inviato al contratto dati nella Figura 1.
In questo documento, sono presenti tutte le proprietà elencate nel campo required del contratto dati. Non ci sono additionalProperties (proprietà che non sono definite nel set di properties del contratto) e ogni valore di proprietà è conforme alle regole di convalida di quella proprietà individuale (ad esempio, la lunghezza di imageUrl è inferiore al set maxLength di 2048 ed è in formato URI). I riferimenti a questo documento vengono automaticamente archiviati negli indici corrispondenti definiti in indices, mentre il documento stesso viene serializzato e archiviato nell’indice primario del contratto.
Proprietà di sistema
Oltre alle proprietà definite dall’utente, come name e price, ci sono alcune “proprietà di sistema” aggiuntive che i Data Contract possono includere negli indices. Queste sono $ownerId, $createdAt e $updatedAt. $createdAt e $updatedAt possono anche essere inclusi nell’elenco delle proprietà required, in quanto sono facoltativi quando si invia un documento a livello di sistema, ma $ownerId è sempre obbligatorio, quindi non è consentito nell’elenco obbligatorio definito dall’utente.
Consulta i Data Contract DPNS e Dashpay per due esempi concreti che utilizzano più di un tipo di documento.
Prima di concludere con i dettagli aggiuntivi sull’architettura, che potrebbero essere troppo complessi per alcuni lettori, concluderò dicendo che potresti anche essere interessato a controllare la Documentazione del contratto dati per ulteriori informazioni e, come sempre, la community, inclusi Dash Core Group e me stesso, è disponibile per rispondere a domande e suggerimenti su Dash Discord .
Infine, non dimenticare di controllare dashpay.io (repository Github qui), dove puoi usare l’intelligenza artificiale per generare automaticamente un contratto dati basato su una descrizione della tua dapp prevista, usare un modulo dinamico per modificarlo alla perfezione e risparmiare tempo e denaro convalidando il tuo contratto dati prima di inviarlo a Dash Platform.
Dettagli aggiuntivi sull’architettura
Indici
Il contratto dati nella Figura 1 definisce tre indici: price, quantity e priceAndQuantity. Quando un documento viene inviato al contratto dati, il documento serializzato completo andrà nel primary index, che è un sottoalbero con chiave 0 nell’albero “nft”, e i riferimenti al documento saranno automaticamente inseriti nei tre sottoalberi del secondary index. Ciò è illustrato nel diagramma seguente, dove le linee continue sono relazioni padre-figlio effettive all’interno di un albero e le linee tratteggiate indicano il nodo in cui è archiviato l’hash radice di quell’albero.
Figura 3: La struttura di un albero di tipo documento nellaDash Platform.
Albero dei documenti contrattuali
Nella struttura GroveDB di Dash Platform, tutti i Data Contract e i documenti corrispondenti sono archiviati nell’albero dei documenti contrattuali, che è un sottoalbero dell’albero radice. Il diagramma seguente mostra il percorso dall’albero radice all’albero di tipo documento “nft” mostrato nel diagramma sopra.
Figura 4: Il percorso dall’albero radice della piattaforma Dash all’albero del tipo di documento “nft” della Figura 3.
Autore: Paul DeLucia
🌐 V️isita il nostro Sito Web 🌐
