✍️ 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:
- Interoperabilità. Innanzitutto, i Data Contract consentono le convalide che assicurano un’interoperabilità fluida tra dati utente, dapp e la piattaforma sottostante, con conseguente migliore esperienza utente e sviluppatore. Inoltre, standardizzando il modo in cui i dati vengono archiviati nella Dash Platform, altre piattaforme possono facilmente ottenere l’interoperabilità in futuro adottando lo stesso formato.
- Semplicità. Tutti i Data Contract nella Dash Platform seguono le stesse linee guida e lo stesso formato generali e sono molto facili da capire rispetto agli Smart Contract. Una volta acquisita una comprensione iniziale di essi, capire come interagire con la dapp di un altro sviluppatore o creare un nuovo contratto dati è piuttosto intuitivo.
- Documentazione. Sulla base di ciò, i Data Contract servono come una forma di documentazione per una dapp. Gli utenti dovrebbero essere in grado di visualizzare lo schema di un contratto e ottenere una comprensione di base di cosa fa la dapp e come, soprattutto se vengono utilizzate le sezioni di commento e descrizione.
- Indicizzazione. I Data Contract consentono agli sviluppatori di indicizzare facilmente le proprietà semplicemente specificandole nello schema, mentre con gli attuali linguaggi per Smart Contract, il processo è molto più complesso e di solito richiede più strutture dati. Questa funzionalità è resa possibile grazie a GroveDB di Dash Platform, il primo database a consentire query verificabili su indici secondari.
- Versioning. I Data Contract includono informazioni di versioning in modo che possano essere aggiornati man mano che le esigenze della dapp si evolvono nel tempo, mantenendo al contempo la retrocompatibilità.
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:
- Persistenza dei dati Web3. Se un’applicazione non necessita di pesanti operazioni di lettura/scrittura, può utilizzare i Data Contract di Dash Platform come storage persistente con prove e indicizzazione. Gli utenti possono archiviare account utente, impostazioni o qualsiasi altra cosa con i vantaggi di una piattaforma Web3 decentralizzata. Dash Platform offre anche l’opzione di storage immutabile per coloro che desiderano la permanenza dei dati.
- Chat room. Gli utenti possono pubblicare, modificare o eliminare messaggi come documenti su un contratto dati di chat room. In realtà esiste già un’applicazione che lo fa: https://dashshoutout.com .
- Applicazioni di ordine. Gli utenti possono inviare un documento al contratto dati di un ristorante con l’ordine del pasto desiderato. Il backend del ristorante sarà quindi in grado di prenderlo ed elaborare il loro ordine.
- Deposito firme. Gli utenti possono caricare le proprie chiavi pubbliche su un contratto dati e una controparte sarà in grado di estrarle senza fare affidamento su alcun archivio centralizzato. Ad esempio, considera le chiavi pubbliche SSH. I server remoti saranno in grado di fornire facilmente a chiunque l’accesso utilizzando il nome utente Identity o DPNS caricato sul proprio (o su un altro) contratto dati.
- Oracle. C’è una crescente domanda nel processo di pagamento crittografico per negozi e altri commercianti. Come proprietario di un sito, spesso non vuoi occuparti dello sviluppo dell’elaborazione dei pagamenti e invece lo deleghi semplicemente alle API centralizzate come Coingate. Con Dash Platform, gli utenti potrebbero caricare gli indirizzi che vorrebbero ascoltare nel contratto dati (in questo caso gli indirizzi dei clienti) e il backend Oracle li raccoglierà e inizierà ad ascoltarli. Quando il pagamento arriva al registro, il backend Oracle sarà in grado di pubblicare i dettagli della transazione sulla piattaforma. Poiché tutti i dati vengono pubblicati on-chain, i backend Oracle sono verificabili al 100%.
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 🌐