✍️ Traduzione by Dash Italia — Fonte originale

-Ringraziamo Hilawe per questa analisi indipendente molto interessante-

La Dash 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 mostra questo limite in un’applicazione funzionante. Gestisce un social network e un marketplace sulla testnet della 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 sulla Platform anziché in un database centrale dell’applicazione.

Il Codice Sorgente 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 della Platform.

Dash dovrebbe probabilmente partire da CosmWasm, adattarlo alla 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 della 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 della 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 la 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 nei 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 della 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 della 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 alla 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 della 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 della 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 della Platform, oppure costringerebbe a incapsulare ogni funzionalità nativa della 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à

• Ogni validatore ottiene la stessa risposta. Questo è il determinismo. L’EVM segue regole fisse e usa aritmetica a numeri interi anziché in virgola mobile. Unità fisse, come i centesimi al posto dei dollari, mantengono esatte le regole di precisione ed evitano differenze di arrotondamento in virgola mobile.
• Dash comprende già il sistema di firme. Dash ed Ethereum usano lo stesso sistema di firma, chiamato secp256k1. La Platform potrebbe esporre il controllo del firmatario ecrecover dell’EVM come funzione nativa.
• Le regole di consenso di base restano le stesse. L’interprete guest funziona come un programma WASM attraverso la stessa interfaccia limitata degli altri programmi della Platform.

Cosa richiede ancora lavoro

• I formati delle prove devono combaciare. GroveDB e i wallet Ethereum parlano linguaggi di prova diversi. Un livello di compatibilità deve collegare le prove di GroveDB al formato Merkle Patricia Trie atteso da eth_getProof.
• I due misuratori di costo devono allinearsi. Il gas dell’EVM registra quanto lavoro svolge un contratto. I Platform credit pagano quel lavoro su Dash. Operazioni come l’hashing Keccak-256 hanno bisogno di un prezzo prevedibile, senza lavoro lasciato senza addebito.
• I wallet hanno bisogno di un traduttore. I wallet da browser inviano transazioni Ethereum e richieste JSON-RPC (JavaScript Object Notation Remote Procedure Call), ad esempio per controllare un saldo o chiamare un contratto. Un gateway deve tradurre queste richieste in state transition della Platform.
• Lo storage ha bisogno di un budget di pulizia. I dati dei contratti EVM possono crescere senza alcun “affitto”. La Platform deve riservare crediti sufficienti per rimuovere o ritirare tali dati in seguito.

Un’alternativa più leggera è permettere agli sviluppatori di scrivere Solidity e compilarlo in WASM. Questo offre loro una sintassi familiare, ma i contratti esistenti e gli strumenti Ethereum non funzionerebbero senza modifiche.

• Solidity compilato in WASM. Gli sviluppatori mantengono un linguaggio familiare, ma il bytecode EVM esistente e gli strumenti Ethereum non funzionano senza modifiche.
• Una EVM guest. I contratti esistenti sono più facili da portare, ma la Platform deve fare da ponte per prove, wallet, misurazione dei costi e pulizia.

Il piccolo prototipo di EVM guest dimostra che questa impostazione è possibile. La piena compatibilità resta comunque un progetto separato.

Direzione consigliata

Partire da CosmWasm, adattarlo a Dash e farlo girare su GroveDB, anziché inventare una nuova macchina virtuale. Mantenere separata la compatibilità con l’EVM.

Di seguito sono elencati i principali compiti di integrazione.

• un router di produzione per i messaggi emessi dai contratti
• binding per indirizzi e firme
• cataloghi di operazioni native di Dash per token, identità e gruppi

Cinque domande richiedono risposte verificate prima che l’implementazione abbia inizio.

1. Determinismo: fissare il compilatore, i confini della misurazione dei costi, le esclusioni sui numeri in virgola mobile e la versione del motore su tutti i validatori.

2. Tempo di blocco nel caso peggiore: includere la generazione delle prove e testare rispetto alla cadenza di blocco di circa mezzo secondo sotto carico avverso.

3. Verifica zero-knowledge: confermare che le prove di privacy possano essere verificate senza esporre le informazioni segrete sottostanti.

4. Operazioni asincrone: supportare lavori come le firme a soglia dei masternode, che iniziano in un blocco e si concludono in uno successivo.

5. Governance delle versioni: mantenere ogni validatore su una release del motore compatibile, in modo che le differenze di versione non dividano il consenso.

Per delimitare chiaramente i confini: si tratta di un design consolidato e di un insieme di piccoli prototipi. Non è una funzionalità rilasciata, non c’è nulla nel nodo, e non è una proposta formale.

Nota: questa è una ricerca indipendente, non una roadmap ufficiale di Dash.

🌐 V️isita il nostro Sito Web 🌐