Quale motore per smart contract si adatta alla Dash Platform?
Published on HivePostify by @italiadash · Sun Aug 16 2026
https://img.leopedia.io/DQmWDqVSB2fX5R2ijt2oDJg3umHZbzvVFPpNTAxbHxXMe1a/Dash%20hilawe%20smart%20contract.jpeg
✍️ Traduzione by Dash Italia - [Fonte originale](https://medium.com/r/?url=https%3A%2F%2Fx.com%2Fhilawe%2Fstatus%2F2088810836252905916%3Fs%3D20) -Ringraziamo Hilawe per questa analisi indipendente molto interessante-
La @dashpay Platform dispone già di quattro funzionalità utili.
1. memorizzare dati strutturati (profili, messaggi e record dell'app) 2. indicizzarli tramite più chiavi (proprietario, data o stato) 3. dimostrare i dati memorizzati a client leggeri (verificare un record senza scaricarlo interamente) 4. autorizzare le modifiche tramite firma (confermare che il proprietario ha approvato un aggiornamento)
Ciò che non può fare è eseguire un programma e far verificare a ogni validatore (Evonode) lo stesso risultato.
[Yap.pr](http://Yap.pr/) mostra questo limite in un'applicazione funzionante. Gestisce un social network e un marketplace sulla testnet di Dash Platform. Attraverso il Dash Platform Name Service (DPNS) e i data contract propri di Yappr, l'app organizza i seguenti record.
- username e profili Dash (bio, sito web e link social) - post e attività social (follow, like, repost e feed privati) - negozi e prodotti (prezzi, categorie, zone di spedizione e quantità in magazzino) - ordini crittografati, aggiornamenti di stato e recensioni collegate agli ID ordine
Le query indicizzate permettono al client di trovare utenti e hashtag, sfogliare i prodotti per categoria o stato, e recuperare gli ordini di un acquirente o di un venditore. Questi record risiedono su Platform anziché in un database centrale dell'applicazione.
Il [Codice Sorgente](https://github.com/PastaPastaPasta/yappr) mostra anche cosa potrebbe aggiungere un motore per smart contract. Oggi il browser calcola il totale dell'ordine, le quantità in magazzino sono puramente informative, il rilevamento dei pagamenti osserva la comparsa di un nuovo output Dash verso l'indirizzo del venditore, e i venditori pubblicano manualmente lo stato degli ordini.
Una logica eseguita dai validatori potrebbe confermare il prezzo corrente, ridurre l'inventario alla creazione dell'ordine, custodire i Dash in escrow, rilasciarli o rimborsarli secondo regole concordate, limitare i cambi di stato consentiti e permettere una recensione solo dopo che l'acquirente ha completato un ordine. I data contract forniscono il catalogo condiviso, il registro ordini e la ricevuta. Uno smart contract aggiungerebbe un cassiere condiviso e un addetto all'escrow. Si baserebbe sui dati ricercabili e dimostrabili di Yappr, senza sostituirli.
L'integrazione richiederebbe una nuova interfaccia per gli ordini, perché oggi Yappr cripta il contenuto degli ordini per acquirente e venditore. Il contratto avrebbe bisogno di accedere ai termini minimi da verificare, oppure a impegni crittografici (commitment) e prove relative a tali termini, mantenendo privati indirizzi e dati di contatto.
Gli ultimi mesi sono stati dedicati a studiare che cosa richiederebbe un calcolo on-chain sicuro e generale. Sono stati costruiti anche prototipi mirati sul motore di storage reale di Platform.
Dash dovrebbe probabilmente partire da CosmWasm, adattarlo a Platform e farlo girare su GroveDB. La compatibilità con Ethereum dovrebbe restare un livello separato.
Come si è arrivati a questa conclusione
Questo lavoro è nato come un problema di progettazione del consenso, non come un progetto di programmazione. Un bug software può far crashare un server. Un bug di consenso può dividere il registro condiviso o mettere a rischio i fondi. Il lavoro è partito dai requisiti, non da un motore preferito. Diverse architetture sono state confrontate rispetto agli stessi vincoli:
1. Ogni design doveva supportare esecuzione deterministica, costi vincolati, stato dimostrabile, funzioni native di Platform, possibilità di aggiornamento e pulizia sicura. 2. Prototipi mirati hanno testato storage, prove, scansioni ordinate, misurazione dei costi, esecuzione dei contratti, binding nativi ed esecuzione guest della Ethereum Virtual Machine (EVM). 3. L'analisi tecnica si è concentrata sui punti limite in cui un design plausibile potrebbe comunque fallire, in particolare la pulizia dello storage, la compatibilità delle prove e il carico di lavoro nel caso peggiore per blocco.
Diverse idee progettuali, test e analisi sono conversi su un'unica architettura. Questo non la rende infallibile. Significa che la raccomandazione si basa su vincoli espliciti, comportamenti misurati e prototipi funzionanti, piuttosto che su preferenze personali.
Dove converge il lavoro
Il risultato è un motore WebAssembly (WASM) deterministico all'interno del processo di state-transition di Platform, la parte che verifica una modifica richiesta e aggiorna il registro condiviso.
WASM funziona come un laboratorio chiuso a chiave. I programmi possono usare solo gli strumenti che Platform espone deliberatamente tramite host function (leggere un saldo, spostare un token o aggiornare un documento). Non possono accedere a funzioni arbitrarie del nodo né inventare permessi.
Il design risultante presenta alcune proprietà importanti.
- lo stato dei programmi resta in GroveDB, l'archivio autenticato che mantiene i dati dimostrabili - le prove per client leggeri (light-client proof) continuano a funzionare per i dati dei programmi - token, identità, gruppi e documenti restano funzionalità native - l'esecuzione avviene solo su numeri interi, è addebitata in base al lavoro svolto in Platform credit, ed è limitata (cap) affinché un singolo programma non possa monopolizzare un blocco - il rilascio può iniziare sotto governance e diventare permissionless in un secondo momento - il design non introduce alcuna nuova parte fidata obbligatoria
Il determinismo è il requisito su cui si regge tutto il resto. I programmi non possono dipendere dall'orologio di sistema, da numeri casuali o dalla temporizzazione dei thread. Due validatori onesti, dato lo stesso input, devono sempre produrre lo stesso risultato.
Il problema difficile era la pulizia
Eliminare qualcosa su una blockchain non è gratuito. I record devono essere rimossi, gli indici aggiornati e i saldi regolati. Questo lavoro consuma lo stesso budget di blocco usato dall'attività normale.
Il design deve quindi soddisfare tre condizioni contemporaneamente.
- la pulizia non può essere gratuita o senza vincoli, perché un attaccante potrebbe inondarla di richieste - i dati non possono scomparire in modo casuale, perché i client potrebbero detenere prove che li riguardano - molti oggetti non possono diventare tutti costosi da chiudere nello stesso blocco
La soluzione che ha superato il confronto e i test è un misuratore di lavoro terminale (terminal-work meter), che funziona come un budget di pulizia prepagato. Ogni oggetto porta con sé una stima finanziata, nel caso peggiore, del lavoro necessario per chiuderlo. Se l'oggetto cresce, cresce contemporaneamente anche il suo deposito di pulizia.
L'analogia più vicina è un deposito cauzionale per il trasloco che cambia in base al contenuto di un appartamento. Addebitare un importo fisso al momento dell'ingresso fallisce se l'inquilino riempie poi ogni stanza. Addebitare in base alla crescita del contenuto mantiene finanziata la futura pulizia.
Lo scheduler separa quindi due tipi di lavoro.
- Scadenze rigide: il lavoro che deve concludersi in un blocco specifico (come un pagamento sensibile al tempo) riserva in anticipo capacità in quel blocco. - Nessuna scadenza: il recupero dello storage fisico (liberare spazio nel database) scorre attraverso una coda costante. Nuova pulizia non entra mai più velocemente di quanto esca la pulizia completata.
Questo limita l'arretrato senza porre un tetto allo stato live di Platform. Un ambiente può essere contrassegnato come vacante immediatamente, per poi recuperare lo storage fisico nel tempo.
Cosa ha mostrato il prototipo di misurazione
È stato costruito un banco di prova mirato sul motore di storage reale di Platform. Non era l'intero motore per smart contract, ma la parte necessaria per sostituire le stime di costo con misurazioni reali.
I risultati sono stati incoraggianti:
- i costi di storage misurati corrispondevano allo stimatore del caso peggiore di GroveDB - le stime non si sono discostate (drift) al crescere del database - i costi di pulizia sono stati misurati per classe di oggetto - il recupero ha restituito esattamente i byte depositati da un record - un tetto di ammissione (il limite alle nuove obbligazioni di pulizia) ha mantenuto l'arretrato di pulizia a zero sotto carico sintetico - lo stesso carico è cresciuto senza vincoli quando quel tetto è stato rimosso - il calcolo può essere misurato contando le operazioni eseguite come "carburante" (fuel), piuttosto che usando i secondi trascorsi, che variano da macchina a macchina
Due parametri richiedono ancora dati esterni: un modello di carico di lavoro realistico e un'indagine sull'hardware dei validatori.
Perché CosmWasm ha cambiato il percorso
Il piano originale prevedeva che Dash costruisse un proprio motore per smart contract. Sam Westrich (QuantumExplorer) ha suggerito invece di usare CosmWasm come punto di partenza. Ulteriori ricerche hanno confermato che la sua architettura si adatta a Platform, rendendo un motore basato su CosmWasm la direzione consigliata.
L'implementazione finale sarebbe comunque adattata a Dash, includendo lo storage GroveDB, i Platform credit, le prove e funzionalità native come token e identità. Questo somiglierebbe alla relazione tra Tenderdash e Tendermint, dove un motore consolidato è stato adattato ai requisiti di Dash.
CosmWasm è un motore maturo e sottoposto ad audit, già utilizzato su molte chain. Condivide la stessa forma di base emersa dal confronto progettuale e dal lavoro sui prototipi: è deterministico, opera solo su numeri interi, misura i costi in gas, è isolato (sandboxed), basato su WASM, orientato principalmente a Rust, e si collega alla chain tramite un'interfaccia host.
La domanda chiave riguardava lo storage: un programma CosmWasm potrebbe usare GroveDB mantenendo le prove di Platform?
La corrispondenza è strutturale. CosmWasm si aspetta un archivio chiave-valore autenticato e ordinato (uno schedario dimostrabile le cui cartelle restano in ordine di chiave). GroveDB è proprio questo tipo di archivio. È più simile ad adattare un motore collaudato a una trasmissione compatibile che a sostituire l'intero veicolo.
Piccoli prototipi funzionanti hanno poi verificato questa corrispondenza.
- lo storage di CosmWasm ha funzionato su GroveDB, incluse scansioni ordinate per intervallo (leggere le chiavi da A a F) all'interno di una transazione - lo stato del contratto è rimasto crittograficamente dimostrabile - un adattatore costo-gas ha convertito il lavoro di storage misurato nell'importo pagato da un contratto - un contratto reale, compilato, è stato istanziato ed eseguito attraverso la macchina virtuale (VM) reale - i binding nativi hanno funzionato in entrambe le direzioni: un contratto ha letto il saldo di un token Dash e applicato un trasferimento reale - un piccolo interprete Ethereum Virtual Machine (EVM) ha funzionato come contratto guest, eseguendo bytecode reale e scrivendo uno slot di storage dimostrabile
Si tratta di prototipi di integrazione, non di un'implementazione in produzione. Dimostrano però che i percorsi di storage, prova, esecuzione e binding nativi funzionano insieme.
Dove si adatta Ethereum, e dove no
L'EVM non dovrebbe essere il livello di esecuzione di base di Platform. Memorizza i dati di ciascun contratto in un albero separato, usando slot a 256 bit e l'hashing Keccak-256 per individuare i valori. Questo è in conflitto con il modello ad albero e di prova di GroveDB. Renderlo fondamentale romperebbe le prove uniformi di Platform, oppure costringerebbe a incapsulare ogni funzionalità nativa di Platform.
Eseguire una EVM come "ospite" (guest) è una proposta diversa. Un interprete EVM misurato potrebbe funzionare come un normale programma WASM, con lo stato Ethereum emulato memorizzato in GroveDB.
Cosa si adatta già
Tags: #hive-146620#dash#bitcoin#digitalcash#privacy#web3#blockchain#devs#crypto