Dash ha una lunga storia di innovazione e sviluppo, con numerosi prodotti e funzionalità significativi pubblicati nel corso degli anni. Lanciato il 18 gennaio 2014, Dash ha sviluppato rapidamente nuove funzionalità incentrate su velocità, privacy e usabilità, rendendolo ideale per l’uso come valuta digitale. Costruito per garantire la libertà finanziaria e modellare il futuro dei pagamenti per le persone di tutto il mondo, Dash ha una tabella di marcia ambiziosa e una storia comprovata e puntuale.
EVONET
EVONET
EVONET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
Attivazione Dash Core
TESTNET
MAINNET
MAINNET
Dash è stato lanciato da Evan Duffield con l’unicoX11 hashing algorithm come sua caratteristica di definizione, e lo sviluppo iniziale incentrato sulla regolazione dinamica della difficoltà di estrazione mineraria, noto comeDark Gravity Wave. A questo sono presto seguiti imasternodes, che forniscono un insieme potente e incentivato di nodi completi che costituiscono la spina dorsale della rete e offrono servizi agli utenti. Sono stati rilasciati gliSpork per facilitare il processo di rilascio di nuove funzionalità, senza che la rete subisse hard-forking, e infine è stato rilasciatoPrivateSend per rendere Dash una valuta realmente fungibile.
Inizialmente basato sul progetto Litecoin, Dash ha rivaleggiato con Bitcoin all’inizio del 2015.InstantSend,un metodo di blocco delle transazioni protetto usando l’architettura masternode di secondo livello, è stato rilasciato poco dopo. Il lavoro è continuato durante tutto l’anno per costruire unsistema di governance decentralizzato che rilasci fino al 10% del premio del blocco alleproposte presentate alla rete. Il primo superblocco è stato estratto il 7 settembre 2015, facendo di Dash la prima organizzazione autonoma decentrata (DAO) al mondo.
Entro 24 ore, la rete ha completato un voto storico, raggiungendo il consenso per autorizzare gli sviluppatori a iniziare a lavorare su blocchi da 2 MB, garantendo la capacità futura. Nel frattempo, il tasso di hash si è moltiplicato rapidamente quando è stato rilasciato un potente hardware di mining, aumentando di 16 volte nel corso dell’anno. La gestione del core team ha visto un’ulteriore professionalizzazione e l’introduzione di misure di garanzia della qualità. Bitcore e Insight sono stati rilasciati con estensioni di Dash, basate su uno sforzo finanziato dalla rete per trasferire l’algoritmo di hash X11 su JavaScript.
l 2017 ha visto Dash supportato sui principali portafogli hardware e due versioni per ottimizzare la preparazione dei fondi PrivateSend e gestire meglio la crescente lista di oggetti di governance utilizzando uno strumento chiamatoSentinel. Nel frattempo, le commissioni su tutte le transazioni sono state ridotte di un fattore 10 su tutta la linea, e la proprietà di Dash Core Group è stata trasferita a un trust irrevocabile, con la rete decentralizzata stessa nominata come beneficiaria.
Devnets nominati consentire la creazione di più devnet indipendenti. Ognuno è identificato da un nome in un blocco “devnet genesis”, posizionato automaticamente all’altezza 1.
I watchdog non sono stati usati da 0.12.2.x; invece, tutte le informazioni richieste su Sentinel sono incluse nei ping masternode. Per questo aggiornamento, sono state aggiunte informazioni aggiuntive per garantire che i ping masternode non venissero modificati da un nodo intermedio. Tutti i messaggi e le logiche relative ai watchdog sono state rimosse. Sono stati apportati miglioramenti al formato dei messaggi della proposta e alla convalida e all’elaborazione delle proposte, riducendo il traffico di rete e l’utilizzo della CPU. Anche la gestione dei trigger è stata migliorata.
Invece di richiedere che la garanzia PrivateSend sia N volte la commissione di PrivateSend, qualsiasi contributo che sia maggiore o uguale a 1 tassa di PrivateSend (ma inferiore o uguale a 4) può ora essere utilizzato come garanzia. Ingressi maggiori o uguali a 1 tariffa di PrivateSend, ma strettamente inferiori a 2 verranno utilizzati come garanzia con gli output OP_RETURN. Ciò ha ridotto il numero di input che un portafoglio deve gestire e ha migliorato la privacy eliminando il caso in cui un utente unisce casualmente piccoli input non privati. Inoltre ha diminuito la dimensione del set UTXO globale.
Le versioni Android e iOS di DashWallet sono state aggiornate con le nuove linee guida per il branding, modernizzando l’aspetto di entrambe le app.
È stata inoltre integrata la possibilità di acquistare e vendere Dash su Uphold tramite una visualizzazione Web all’interno dell’app Android, consentendo un più facile inserimento degli utenti.
È stata aggiunta la possibilità di richiedere un pagamento tramite NFC, consentendo agli utenti di toccare i terminali di pagamento e i portafogli di pagamento per ricevere le informazioni di pagamento.
È stata aggiunta la possibilità di utilizzare DashWallet su iPad in modo che gli utenti possano pagare e ricevere pagamenti sui loro tablet.
Sono state aggiunte molte nuove lingue e valute in modo che gli utenti di tutto il mondo possano utilizzare DashWallet nella loro lingua nativa e visualizzare i tassi di cambio nelle loro valute locali.
Dash Core v0.13 ha introdotto Automatic InstantSend, in cui le transazioni con quattro o meno input sono predefinite su InstantSend, senza costi aggiuntivi per gli utenti.
IlDeterministic Masternode List fornisce un’unica fonte di verità per tutte le transazioni che richiedono la convalida da parte di masternodes, come le transazioni InstantSend. L’elenco è interamente derivato dai dati sulla catena. Ciò garantisce che tutti i nodi raggiungano lo stesso consenso per quanto riguarda lo stato corrente dell’elenco masternode valido.
Transazioni Speciali forniscono nuove strutture per consentire transazioni non finanziarie sulla blockchain. Questa funzione getterà le basi per gli usi futuri della rete sul livello 2, come Blockchain Users.
Precedentemente, masternode aveva due chiavi per il loro masternode: owner (per dimostrare la proprietà) e operator (per operare il masternode e usarlo per votare). La seconda chiave è stata suddivisa in due: operatore e votazione, in modo tale che il masternode possa delegare il voto se lo desiderano.
Gli utenti possono ora sbloccare il loro portafoglio usando la loro impronta digitale per consentire un uso semplice e sicuro.
DashWallet è ora integrato con una libreria iOS che lo collega alla blockchain di Dash, e potrebbe in futuro essere utilizzato da altri client iOS per fare lo stesso.
DashWallet può ora confermare se una transazione ricevuta è stata inviata tramite InstantSend.
Le fonti di prezzo sono ora allineate tra le versioni iOS e Android di DashWallet.
Long Living Masternode Quorums fornire una maggiore scalabilità della rete migliorando il consenso e ampliando l’universo di potenziali casi d’uso per la rete. Questi quorum riducono drasticamente la quantità di messaggi richiesti per convalidare le transazioni ed evitano che ogni singolo nodo sulla rete debba memorizzare i dati di consenso in memoria fino a quando una transazione viene estratta. Questi quorum possono essere molto grandi a seconda del livello di sicurezza richiesto per il caso d’uso.
ChainLocks ridurre drasticamente il rischio di un attacco di data mining del 51% sulla rete. Questa funzione consente a un quorum del Masternode di lunga durata di firmare un blocco e propagare un messaggio alla rete indicando che i nodi devono rifiutare blocchi alla stessa altezza che non corrispondono al blocco specificato dal quorum. Ciò non solo rende il raggiungimento del consenso rapido e non ambiguo, ma rende anche le riorganizzazioni di catena al di sotto di quel blocco impossibile.
Gli utenti possono trasferire Dash dal proprio account Uphold al proprio portafoglio all’interno dell’app e acquistare e vendere Dash tramite una visualizzazione Web incorporata.
Sono stati apportati miglioramenti per garantire l’allineamento dei tassi di cambio con le altre applicazioni Dash utilizzate di frequente.
Il supporto per LLMQ e ChainLocks è stato aggiunto al portafoglio, garantendo agli utenti la possibilità di beneficiare di maggiore sicurezza e pagamenti immediati.
EVONET
La piattaforma Dash verrà rilasciata su un testnet pubblico a cui gli sviluppatori possono connettersi per sperimentare la funzionalità.
Gli utenti saranno in grado di connettersi a Evonet utilizzando l’API decentralizzata (DAPI); creare identità e nomi di test; e creare, aggiornare ed eliminare documenti.
Gli utenti potranno esplorare il Dash Platform Naming Service (DPNS) e il contratto DashPay.
Diverse librerie saranno disponibili per gli sviluppatori, tra cui le librerie Dash SDK, DAPI-client, DPNS-client e DPP.
Un hub per sviluppatori offrirà documentazione utile e guide alle nuove funzionalità.
L’interfaccia utente di DashWallet sarà unificata su Android e iOS per un aspetto più coerente.
DashWallet iOS introdurrà una modalità oscura coerente con le linee guida di Apple.
Agli utenti verrà offerta una maggiore flessibilità nel modo in cui gestiscono le proprie impostazioni di sicurezza.
Gli utenti saranno in grado di accedere rapidamente alle funzionalità principali dalla schermata principale.
Questa versione aggiornerà Dash con Bitcoin v0.15.2, beneficiando di una serie di correzioni e ottimizzazioni apportate a Bitcoin.
Gli utenti potranno beneficiare di un’interfaccia utente aggiornata sul portafoglio desktop in abbinamenti al marchio Dash aggiornato. Ciò include colori e stili aggiornati uniformati alla guida di stile, rimozione di elementi non necessari, nuove icone per un’interfaccia utente migliore.
Questa versione includerà diverse ottimizzazioni apportate sulla base dei risultati dei recenti stress test.
I miglioramenti alla funzionalità BIP70 consentono un’esperienza di pagamento più efficiente nel punto vendita. Gli utenti/commercianti che implementano questo protocollo beneficiano di opzioni di rimborso, della possibilità di suddividere i pagamenti su più indirizzi e avranno un’esperienza più sicura.
L’assegnazione di ricompense in blocco — escluso il finanziamento delle proposte — tra masternodes e miners sta cambiando da una divisione 50-50 a una divisione 60-40 su un periodo di transizione pluriennale.
L’esperienza Dash Core è ora più coerente in tutti i sistemi operativi supportati per quanto riguarda i caratteri, la grafica e i layout dello schermo.
Il nuovo sistema di ripristino della firma, invece di propagare le condivisioni della firma a ogni nodo, invia inizialmente le condivisioni della firma a un singolo nodo selezionato in modo deterministico. Questa ottimizzazione dovrebbe ridurre il carico di diversi ordini di grandezza.
Proof of Service (PoSe) per i Masternodes è migliorato assicurando che una versione minima del protocollo sia in esecuzione durante DKG.
Il threading di rete è stato ottimizzato eliminando le ripetizioni inutili di loop attraverso tutti i nodi implementando il polling degli eventi (epoll) su Linux.
Questa versione introduce anche oltre 650 aggiornamenti da Bitcoin v0.16 e alcuni aggiornamenti da Bitcoin v0.17.
EVONET
Consente l’implementazione fluida delle modifiche più importanti senza cancellare le reti di sviluppo.
La suite di test della piattaforma è un filerepo contenente test consolidati su tutta la piattaforma, semplifica notevolmente la verifica e l’aggiornamento su tutti i componenti.
Consente agli sviluppatori di utilizzare files binari nativi (ad esempio, Buffer, ByteArray) per memorizzare i propri dati.
Possibilità di registrare l’ora di creazione o aggiornamento di qualsiasi documento archiviato su Dash Platform.
Supporto per modelli di configurazione e nodi multipli inmn-bootstrap.
Consente a un utente di specificare una username principale per la propria identità Dash.
DIP11 Identities eDIP12 Dash Platform Name Service sono stati rilasciati.
Le schede di invio e ricezione sono state eliminate per creare più spazio e per rimuovere la ridondanza con la barra dei collegamenti.
Le etichette sono state accorciate e/o riformattate per evitare la sovrapposizione con altri componenti dell’interfaccia utente su schermi piccoli.
È stato aggiunto un pulsante Indietro, è stato implementato il supporto per frasi non inglesi, e aggiornati i messaggi di avviso
Numerose correzioni e modifiche al design dei dati di base e ai download di Masternode e quorum list.
EVONET
Il programma DashPay Alpha coinvolge la comunità con il test del portafoglio DashPay su Evonet.
Gli utenti potranno registrarsi sulla rete e iniziare a condividere i loro nomi utente personalizzati con altri utenti Dash.
Gli utenti potranno rendere il proprio profilo nome utente più identificabile con un nome, un’immagine e una biografia.
Gli utenti saranno in grado di richiedere contatti per nome utente e creare un elenco di utenti con cui desiderano effettuare transazioni.
Gli utenti possono scambiare Dash con amici, familiari e commercianti con nome utente o indirizzo crittografico.
TESTNET
Miglioramenti per rappresentare i dati binari come array di byte anziché come stringhe, in modo che i dati vengano archiviati in modo più efficiente. Lo schema JSON è stato esteso anche con la parola chiave “byteArray”, consentendo così agli sviluppatori di definire più facilmente le proprietà binarie nei loro contratti dati.
Sono state apportate diverse modifiche alla struttura sottostante che comprende un’identità all’interno di Dash Platform
Questo era un bug noto che impediva a molti sviluppatori di avviare correttamente i nodi su Evonet.
Stabilire il consenso tra le catene L1 e L2 in base all’altezza di L1.
Ciò consente di finanziare le identità sfruttando la velocità di InstantSend.
Memorizzazione dello stato dei dati in alberi Merkle per l’utilizzo con client leggeri.
Il pacchetto di distribuzione (dashman f.k.a. mn-bootstrap) è stato notevolmente aggiornato per migliorare l’esperienza dell’utente e accogliere i nuovi componenti della piattaforma.
Capacità di finanziare identità senza possibilità di raddoppiare la spesa.
Sono stati apportati ulteriori miglioramenti al processo di sincronizzazione a catena per evitare ritardi nell’invio dei pagamenti.
Sono stati apportati miglioramenti per aiutare gli utenti che hanno dimenticato una o due parole della loro frase di ripristino a tentare ancora di recuperare il proprio portafoglio.
È stata implementata la UX associata alla dimenticanza del PIN, sono stati effettuati aggiornamenti per supportare un SDK Android più recente (29), sono stati effettuati arresti anomali associati al backup su un file e all’importazione di una chiave privata.
TESTNET
Un tipo speciale di nodo che fornisce informazioni peer ad altri nodi per migliorare la scalabilità.
Miglioramenti per affrontare diversi possibili vettori di attacco e per la scalabilità su Mainnet.
Aggiungi più log per una maggiore chiarezza e risoluzione dei problemi del comportamento di Drive.
Messaggi leggibili e informativi per una corretta gestione degli errori.
TESTNET
Nuova dimensione del quorum per supportare transazioni speciali di blocco asset.
Miglioramenti della sicurezza quando il core interagisce con la piattaforma.
500+ backport stimati da Bitcoin Core.
TESTNET
Implementa la seconda parte della progettazione del finanziamento dell’identità che include le prove di ChainLock per supportare meglio le prove del cliente.
Abilita la logica deterministicamente specifica sulla rete per consentire la correzione di bug e per abilitare nuove funzionalità senza cancellare i dati.
Il nodo locale mn-bootstrap non supporta i blocchi a catena e i blocchi istantanei, quindi abbiamo dovuto introdurre il fallback durante lo sviluppo e in CI.
Miglioramenti agli Asset Lock Proofs (finanziamento dell’identità) per evitare la duplicazione di logica e dati è meglio utilizzare Core che ha già implementato questa logica e ha tutti i dati richiesti.
Rimuovi le informazioni dettagliate come dipendenza e passa la funzionalità a DAPI per migliorare la stabilità e rimuovere la ridondanza.
Miglioriamo continuamente il pacchetto di distribuzione della piattaforma Dash (precedentemente noto come mn-bootstrap) per renderlo più conveniente e affidabile. Da questa versione, la consideriamo abbastanza matura da ottenere un bel nome e ti incoraggiamo fortemente a iniziare a usarla per eseguire fullnode e masternode di testnet.
Le build lente e la mancanza di funzionalità disponibili in Travis CI hanno rallentato in modo significativo il processo di sviluppo. Siamo migrati su Github Actions e implementato alcuni trucchi di memorizzazione nella cache. Le nuove build CI sono molto più flessibili e funzionano fino a 10 volte più velocemente.
TESTNET
Per ottenere il consenso sulla piattaforma blockchain, un insieme specifico di masternode, chiamati validatori, verifica e firma i blocchi. Fino alla versione 0.19, il set di validatori era statico e ospitato su nodi controllati da DCG. Con la versione 0.20, i quorum Masternode di lunga durata (LLMQ) vengono utilizzati per distribuire e ruotare dinamicamente il set di validatori tra tutti i masternode. Questo approccio distribuisce uniformemente il carico e rende la rete molto più sicura e affidabile.
In precedenza, i clienti dovevano utilizzare nodi completi attendibili per garantire la validità e l’integrità dei dati recuperati dalla rete della piattaforma. In questa versione, DAPI fornisce prove crittografiche efficienti insieme ai dati della piattaforma, che consentono ai client leggeri (ad esempio portafogli mobili) di interagire in modo sicuro con Dash Platform.
I validatori in precedenza utilizzavano firme EdDSA non aggregate del digest crittografico dello stato della piattaforma per fornire prove crittografiche e garantire il consenso della rete. Il numero e la dimensione complessiva di queste firme rendevano le prove ad alta intensità di risorse da utilizzare per i client leggeri. Nella versione 0.20, il meccanismo di firma della soglia BLS viene utilizzato per produrre una sola firma, che i portafogli mobili e altri client leggeri possono facilmente verificare.
In precedenza, i nodi completi e i validatori si affidavano e verificavano tutti i tipi di messaggi P2P. Ciò significa che anche i nodi completi hanno ricevuto traffico di rete contenente messaggi rilevanti solo per i validatori per ottenere il consenso. Nella nuova versione i full node non ricevono più messaggi di consenso intermedi prodotti dai validatori. Invece, i validatori producono solo un messaggio con una firma di soglia BLS per propagare la decisione consensuale risultante al resto della rete. Ciò riduce notevolmente il carico di rete poiché molti messaggi non devono più essere propagati ai nodi completi, con un conseguente utilizzo della larghezza di banda inferiore del 99,5%.
Dash Platform ora allega metadati aggiuntivi alle risposte DAPI, come l’altezza attuale della blockchain della piattaforma, nonché l’altezza sincronizzata della blockchain centrale osservata e concordata da tutti i nodi che partecipano al consenso della rete. Poiché la piattaforma e le blockchain principali sono asincrone, la piattaforma utilizza questa altezza principale per garantire che tutti i nodi della piattaforma abbiano una visione deterministica dello stato della rete principale.
La nuova versione del protocollo Dash Platform aggiorna la specifica dello schema JSON utilizzata per definire i contratti dati alla versione 2020-12 più recente e impiega rigide regole di convalida per prevenire potenziali errori dell’utente nei contratti dati inviati alla rete. Viene inoltre utilizzato uno speciale motore di espressioni regolari per mitigare gli attacchi ReDoS.
Le versioni precedenti della libreria JS Wallet non sempre ricevevano tutte le transazioni richieste e i messaggi di blocco istantaneo da DAPI durante la sincronizzazione. Questo è stato risolto nella versione 0.20.
L’ultima versione di Dashmate contiene 20 correzioni e miglioramenti. I più significativi di questi sono stati progettati per rendere la configurazione di reti di sviluppo locale più comoda e affidabile, nonché per miglioramenti delle prestazioni e supporto di Windows.
Integrazione del Liquid Quick Exchange nel portafoglio per consentire l’acquisto di Dash con carte di credito Visa dall’interno del Dash Wallet.
Miglioramenti all’esperienza utente di deep link in modo che vi sia un’esperienza utente senza interruzioni tra l’app DashDirect appena rilasciata e altre app che utilizzano questo protocollo.
Ciò è in linea con uno standard più comune di organizzazione di input/output che prevede un migliore anonimato.
Miglioramenti dell’interfaccia utente per istruire meglio gli utenti sull’importanza della loro passphrase e impedire agli utenti di acquisire schermate della loro frase.
Miglioramenti dell’interfaccia utente allo stato e modifiche al back-end per migliorare le prestazioni della sincronizzazione.
Bug multipli e miglioramenti dell’interfaccia utente associati a Uphold, autenticazione tramite impronta digitale, navigazione dell’interfaccia utente e funzione di disconnessione automatica e alcuni refactoring del codice in preparazione per l’aggiornamento di DashPay.
TESTNET
Per semplificare l’accesso ai tuoi amici e familiari sulla rete Dash, puoi inviare loro inviti in modo che abbiano tutto ciò di cui hanno bisogno per creare il proprio nome utente.
Come nuovo utente che non ha alcun Dash, un invito gli consentirà di creare subito il proprio nome utente senza dover attendere prima di acquisire Dash.
TESTNET
Implementazione di codici di errore e messaggi più descrittivi in modo che le applicazioni client possano gestirli meglio e così sia più facile indagare sui bug.
Al momento, memorizziamo lo stato in diversi alberi Merk, il che aggiunge un po’ di sovraccarico per memoria e disco. Richiede inoltre una logica molto complessa per garantire l’atomicità e gestire le transazioni tra database che non sono implementate. Verrà definito un nuovo design dell’albero degli stati più robusto e sicuro.
Come parte del nuovo design dell’albero degli stati, MongoDB sarà sostituito.
Testnet verrà aggiornato per includere nodi in più data center per simulare problemi del mondo reale con latenza e prestazioni che potrebbero influire sul ridimensionamento.
Un processo di aggiornamento migliorato eviterà la necessità di cancellare i dati L2 consentendo una transizione sicura tra le versioni del protocollo.
TESTNET
Il primo nel suo genere, un database basato su struttura dati autenticata gerarchica (HADS) che si basa su un sistema di archiviazione dati dimostrabile innovativo. Ciò consentirà funzionalità non possibili con qualsiasi altro database attualmente esistente. La prima versione offrirà indici secondari e conterrà prove crittografiche per l’integrità del contenuto archiviato.
Ciò consente di modificare gli schemi contrattuali senza perdita di dati o senza la necessità di creare un nuovo contratto. Questo è un chiaro ed evidente elemento di differenziazione tra Dash e le reti di contratti intelligenti che non hanno la capacità di farlo.
Quando un Masternode ha una Dash Identity con un saldo allegato, il proprietario del Masternode può ricevere premi per la sua partecipazione al consenso della Piattaforma. Ciò fornisce un flusso di entrate aggiuntivo per i proprietari di Masternode.
Le future funzionalità della piattaforma Dash richiederanno vari livelli di sicurezza. L’esecuzione di una vendita di una risorsa digitale di grande valore dovrebbe richiedere un livello di sicurezza molto elevato, mentre la pubblicazione di immagini di gatti probabilmente non lo richiederebbe. Con questa funzionalità, gli utenti possono mantenere le chiavi del livello di sicurezza più elevato sul proprio portafoglio hardware, ma eseguire azioni meno critiche direttamente dal proprio telefono.
Per accelerare il processo di sviluppo e creazione, il codice dei componenti della piattaforma è stato migrato da repository autonomi a un repository multipacchetto. Questo approccio mono-repository riduce significativamente le operazioni di routine che devono essere eseguite durante lo sviluppo.
Migliora la distribuzione del carico del quorum tra i masternode espandendo allo stesso tempo la sicurezza di InstantSend.questo è statorealizzatos modificando solo un sottoinsieme di masternode in un quorum durante la selezione dei membri del quorum e limitando al tempo stesso il numero di quorum per cui ciascun nodo viene selezionato contemporaneamente.
Riduzione della quota Proposal da5 DASH a 1 DASH al fine di rendere più accessibile il sistema di governance Questa modifica è stata guidata da unaproposal approvata dal masternode.
Aggiunta unaScheda Governance per consentire agli utenti di Dash Core Qt di accedere più facilmente ai dettagli della proposta di governance.
Implementata unanuova transazione speciale e gli aspetti diDIP23 necessari per supportare il meccanismo di hard fork completamente potenziato da rilasciare nella versione successiva di Dash Core.
Introdotti i blocchi InstantSend (DIP22) verificabili deterministicamente per supportare al meglio il sistema di identità della piattaforma. Ciò consente alle transazioni di InstantSend di essere verificate in futuro anziché solo in modo effimero.
Il completamento del backport per Bitcoin Core v0.18 è aumentato dall’83% all’86% e il completamento della v0.19 è aumentato dal 41% al 53%. Inoltre, il 18% e il 10% dei backport sono stati completati rispettivamente per la v0.21 e la v0.22.
Dash Core Group si è ufficialmente impegnata con una società di revisione professionale per eseguire un audit di sicurezza sulla base di codice Core.
TESTNET
Eliminare il gap funzionale relativo alle specifiche del DIP0011. Ciò include l’implementazione di una transizione dello stato di aggiornamento dell’identità, l’introduzione di miglioramenti alla sicurezza della chiave pubblica dell’identità, funzionalità aggiuntive richieste per i prelievi di credito e l’implementazione di una prova di proprietà della chiave di identità.
Un modello tariffario incentivante che compenserà i Masternodes per i costi di elaborazione e archiviazione e preverrà lo spam. L’implementazione del nuovo sistema di calcolo delle tariffe si basa sulle operazioni necessarie per elaborare le transizioni di stato e sulla quantità di dati archiviati sulla rete Masternode. Sebbene il calcolo delle tariffe di stoccaggio con il nuovo modello sia preciso, le tariffe di elaborazione sono ancora soggette a miglioramenti. Nella prossima versione verranno implementati anche i rimborsi delle tariffe per l’eliminazione dei dati.
Un sistema in cui le commissioni della piattaforma vengono raccolte in pool da distribuire ai Masternodes nel tempo. Questo design incentiva i Masternode a continuare a ospitare e ad evitare che il proprio nodo vada offline. Le tariffe di stoccaggio per la transizione di stato vengono distribuite a ogni epoca (~18 giorni) fino a 50 anni nel futuro. Quando inizia una nuova epoca, i Masternode ricevono ricompense per aver fornito il servizio nell’epoca precedente.
I crediti della piattaforma possono essere scambiati con Dash. I Masternodes avranno un modo semplice per ritirare i premi della loro piattaforma.
Sicurezza e affidabilità migliorate per la sincronizzazione della catena nel portafoglio Dash JS. JS Wallet diventerà un vero e proprio client SPV che esegue la sincronizzazione e la verifica dell’intera catena chiedendo ai Masternode selezionati casualmente di restituire i dati della catena richiesti.
Per misurare le prestazioni dei componenti della piattaforma, questa versione introduce uno strumento di benchmark. Questo strumento è profondamente integrato con il runtime blockchain della piattaforma e fornisce strumenti utili agli sviluppatori per sperimentare e monitorare le prestazioni nel tempo.
TESTNET
Il porting di DPP su Rust lo rende più sicuro e performante. Inoltre, renderà più veloce l’elaborazione dei blocchi. Per integrare Rust DPP nei componenti JS forniamo WASM DPP. Questo è il primo passo verso il porting della piattaforma su Rust. JS è stato utile per la sperimentazione e la prototipazione, ma ora abbiamo bisogno di qualcosa di più sostenibile.
Una limitazione ereditata dal progetto Tendermint da cui è stato originariamente derivato il nostro motore di consenso, solo le firme dei blocchi firmerebbero lo stato del blocco precedente così come tutte le transizioni di stato del blocco corrente. Quindi per ottenere dati comprovati da DAPI bisognerebbe attendere l’impegno del blocco successivo. Ciò era incompatibile con il nostro sistema di prova e il sistema di archiviazione desiderati. Questo miglioramento riduce inoltre in modo significativo il carico sulla rete e diminuisce il tempo necessario per inserire i dati nella piattaforma, con conseguente migliore UX.
Attualmente, puoi convertire Dash in crediti della piattaforma creando o ricaricando un’identità. I crediti vengono utilizzati principalmente per pagare le tasse di transizione statali. I Masternode ricevono i loro premi per l’hosting della piattaforma in crediti (premi in blocco e commissioni ST). I prelievi consentono ai Masternode e ad altre identità di riconvertire i propri crediti in Dash.
Dash Platform Protocol (DPP) utilizzava in precedenza il meccanismo di codifica CBOR che implementa la serializzazione dei dati senza schema. Poiché tutti i dati sulla piattaforma sono archiviati in strutture predefinite, non è necessario archiviare anche le informazioni sulla struttura. Memorizzando solo i valori riduciamo drasticamente la dimensione degli oggetti serializzati.
Quando un utente aggiunge dati alla piattaforma, paga per l’archiviazione permanente. Tuttavia, non tutti i dati archiviati nella Piattaforma devono essere permanenti. Gli utenti possono definire nei contratti dati la possibilità di aggiornare o rimuovere i documenti. L’introduzione del rimborso delle commissioni consente agli utenti di recuperare crediti quando cancellano i dati.
Un’identità è composta da vari dati come il suo saldo e una raccolta di chiavi pubbliche utilizzate per vari scopi e livelli di sicurezza. La nuova implementazione dell’archiviazione delle identità consente l’aggiornamento o il recupero solo di parti specifiche o multiple dell’identità. Ciò riduce le spese di transizione statali e il carico sulla rete.
Una nuova funzionalità degli alberi di somma di GroveDB ci ha permesso di implementare un meccanismo di protezione contro i bug inflazionistici sulla blockchain. Questa funzionalità aggiunge somme ai nodi di un tipo specifico di albero Merkle AVL. In this tree, root nodes hold the sum of all integer values in the tree. Ogni volta che un valore viene aggiunto, rimosso o aggiornato in un albero somma, ogni nodo genitore e quindi il “valore somma” della radice viene aggiornato. Il meccanismo di verifica del credito confronta ogni blocco di tutti i saldi di credito in deposito con l’importo previsto di crediti nel sistema. Ciò impedisce attacchi inflazionistici che conierebbero nuovi crediti o token al di fuori dell’offerta predefinita.
Questo è un componente per abilitare le future funzionalità di governance sulla piattaforma.
Da questa versione in poi, le richieste DAPI vengono servite tramite HTTPS per consentire la creazione di applicazioni per i browser.
Un Masternode ad alte prestazioni è un nuovo tipo di Masternode che verrà utilizzato per servire la rete partecipando al consenso sia sulla catena Dash Platform che sulla catena Dash Payment (Core). In questo sistema, il Masternode standard continuerebbe a servire solo la catena Dash Payment. Gli HPMN avranno requisiti maggiori rispetto a un Masternode standard come materiale collaterale 4k Dash e specifiche prestazionali più elevate poiché gestirebbero due catene invece di una sola.
Aggiornamento della libreria di firme BLS per il nuovo schema di firma per l’allineamento degli standard e una maggiore sicurezza.
Backports da Bitcoin Core da BTC v0.19/v0.20/v0.21/v0.22.
Uno degli obiettivi dell’Hard Fork v19 era attivare lo schema BLS di base e iniziare a utilizzarlo in vari messaggi on-chain e p2p. La motivazione dietro questo cambiamento è la necessità di allinearsi agli standard IETF. Sfortunatamente, alcuni casi limite non sono stati rilevati nei nostri test funzionali e non sono stati rilevati nemmeno sul testnet. Il tentativo di attivazione della v19 sulla mainnet ha colpito uno di questi casi limite e la mainnet ha smesso di produrre blocchi. Come soluzione intermedia è stata rilasciata la v19.1.0 che ha ritardato l’inizio della segnalazione per l’Hard Fork v19 fino al 14 giugno.
Per risolvere questi problemi abbiamo dovuto rielaborare il modo in cui vengono gestite le chiavi pubbliche BLS, incluso il modo in cui vengono serializzate nel database interno. Ciò lo rendeva incompatibile con le versioni precedenti di Dash Core, quindi è stato implementato un percorso di migrazione db per tutte le versioni recenti.
Come effetto collaterale, la soluzione implementata per risolvere i problemi dell’Hard Fork v19 ha aperto un percorso per semplificare la migrazione alla v19 per i portafogli mobili.
Con l’implementazione precedente i portafogli mobili avrebbero dovuto convertire 4k+ pubkey al punto di fork v19 e ciò può facilmente richiedere 10-15 secondi se non di più. Inoltre, dopo l’Hard Fork v19, se un elenco masternode viene richiesto da un blocco prima dell’Hard Fork v19, le chiavi dell’operatore arrivavano nello schema BLS di base, ma l’hash merkleroot masternode memorizzato nella transazione coinbase in quel momento veniva calcolato con BLS legacy schema. Quindi era impossibile verificare l’hash Merkleroot.
Per risolvere questi problemi è stato introdotto un nuovo campo nVersion per ogni voce nel messaggio mnlistdiff p2p. Questo campo indica quale schema BLS deve essere utilizzato durante la deserializzazione del messaggio: legacy o di base. nVersion del messaggio mnlistdiff stesso non indicherà più lo schema e dovrà essere sempre impostato su 1.
Le recenti modifiche ai messaggi dsq e dstx hanno consentito ai client mobili che ottengono elenchi masternode dal messaggio mnlistdiff di determinare il masternode correlato a questi messaggi perché è stato utilizzato proTxHash anziché masternodeOutpoint. Una volta attivato l’Hard Fork v19, la firma dei messaggi dsq e dstx sarà basata su proTxHash che dovrebbe consentire ai client mobili di verificarlo.
Prima di questa versione i ChainLocks erano abilitati o disabilitati. A partire da questa versione è possibile impostare SPORK_19_CHAINLOCKS_ENABLED ad un valore diverso da zero per disabilitare la firma di nuovi ChainLocks pur mantenendo quello più conosciuto.
TESTNET
I premi del blocco Masternode saranno suddivisi tra Masternode normali e Masternode ad alte prestazioni (HPMN). La parte HPMN verrà accumulata in crediti e distribuita nel tempo tra i nodi come incentivazione a servire la Piattaforma. I nodi riceveranno ricompense ogni epoca (~18 giorni) se forniscono i servizi (propongono nuovi blocchi della piattaforma).
Si tratta dell’aggiunta di tariffe di elaborazione più limitate e dell’adeguamento/rivisitazione dei numeri esistenti per garantire che tutti i costi siano adeguatamente coperti e che le tariffe siano calcolate correttamente.
Testare e migliorare i processi di aggiornamento del protocollo per ottimizzare l’implementazione di modifiche importanti per diversi livelli del sistema.
Preparare la piattaforma Dash per l’archiviazione e la manutenzione di token non fungibili. Durante l’utilizzo del meccanismo di archiviazione della piattaforma, fornire un modo per mantenere i dati NFT anche sulla catena.
Implementare le metriche per i componenti della piattaforma necessari per il monitoraggio della rete, inclusi ulteriori stress test.
Esperimenti e test di sicurezza da parte di DCG.
Gli stress test vengono eseguiti con una suite di stress test su una rete dedicata.
Prima di DashCore v20.0, il 10% dei premi in blocco veniva accantonato per la tesoreria Dash DAO che finanzia lo sviluppo e altri sforzi di rete. Una volta che l’hard fork DashCore v20.0 entrerà in vigore sulla mainnet, la quota del sistema di tesoreria aumenterà al 20% dei premi del blocco per allinearsi con ilproposta approvata a settembre. Miner and masternode rewards will change to 20% and 60% respectively upon activation of the change.
La funzionalità Sentinel è stata integrata direttamente nella versione v20.0, quindi non sarà più necessario che i masternode eseguano l’applicazione Sentinel autonoma. Diversi comandi RPC sono stati aggiornati per prevenire conflitti tra DashCore v20.0 e le installazioni Sentinel esistenti. Si consiglia di rimuovere o disabilitare Sentinel dopo aver aggiornato i masternodes alla v20.0.
Introdotto un nuovo tipo di transazione speciale, “Blocco asset”, per supportare il finanziamento dell’identità della piattaforma
L’hard fork di riallocazione della ricompensa masternode (MN_RR), incluso per la prima volta in Dash Core v20, verrà attivato dopo che la v21 sarà adottata da masternodes. Questo hard fork abilita la funzionalità principale inclusa in questa versione: la riallocazione della posizione del premio Masternode. L’attivazione avvierà anche il lancio della Dash Evolution Platform Chain.
Una volta attivato l’hard fork MN_RR, parte del sussidio masternode nella coinbase verrà spostato nel Credit Pool (ovvero sulla piattaforma) ogni volta che viene estratto un blocco. Gli Evonode riceveranno quindi una singola ricompensa per ciclo di pagamento sulla catena Core, non ricompense da quattro blocchi sequenziali come nella v19/v20. Il resto dei pagamenti evonode sarà distribuito dalla Piattaforma dal pool di crediti. Questo per incentivare gli evonodi ad aggiornare alla Piattaforma perché solo i nodi che eseguono la Piattaforma possono ricevere questi pagamenti di ricompensa.
Dash ha introdotto gli spork nel 2014 come un modo per fornire transizioni di aggiornamento più fluide rispetto agli hard fork. Sebbene questa innovazione sia stata utile, la rete è maturata a un punto in cui non sono più necessari sulla rete principale grazie a funzionalità come gli hard fork avanzati. Di conseguenza, questa versione rafforza tutti gli spork sulla mainnet. Gli spork rimangono in vigore su tutti i devnet e testnet; tuttavia, sulla mainnet, il valore di tutti gli spork è codificato su 0 o 1 per lo spork SPORK_21_QUORUM_ALL_CONNECTED. Questi valori rafforzati corrispondono ai valori attivi storicamente utilizzati sulla rete principale, quindi non vi è alcun cambiamento nella funzionalità della rete.
MAINNET
Vari esperimenti di rete, rivisitazione della base di codice, preparativi e potenziali correzioni di bug per il rilascio sulla mainnet con una stretta collaborazione con Dash Community (utilizzando i progetti della community che utilizzano Dash Platform).
La prima implementazione della mainnet della piattaforma verrà fornita in bundle con l’implementazione del Core v0.21. La rete Dash sarà incoraggiata a completare gli aggiornamenti il prima possibile.
MAINNET
Queste versioni dovevano garantire un’attivazione riuscita in condizioni specifiche osservate. Si trattava di un aggiornamento obbligatorio per tutti gli operatori Evonode. Contrariamente ad altre attivazioni, questa versione attiverà la catena della piattaforma non appena 67 Evonode nel quorum Genesis saranno aggiornati e configurati correttamente.
Nessuna persona o organizzazione ha il controllo su quando verrà attivato il protocollo della Piattaforma; ciò avverrà dopo che un numero specifico di proprietari di Evonode avranno effettuato l’aggiornamento.
Il numero massimo di intestazioni di blocco compresse che possono essere richieste contemporaneamente è stato aumentato da 2000 a 8000. Si prevede che questa modifica ridurrà i tempi di sincronizzazione della blockchain per i client che utilizzano intestazioni di blocco compresse poiché saranno in grado di ottenere le intestazioni più velocemente.
Per ridurre l’utilizzo della larghezza di banda, il messaggio DSQ viene trasmesso utilizzando il sistema di inventario invece di essere inoltrato a tutti i peer connessi. Sebbene ciò dovrebbe ridurre le esigenze di larghezza di banda per tutti i nodi, l’effetto sarà più evidente sui masternode altamente connessi.
L’elaborazione dei prelievi dalla piattaforma è stata aggiornata per accettare transazioni di prelievo da più quorum della piattaforma. In precedenza, le transazioni venivano accettate solo se firmate da uno dei primi due quorum attivi. Con questa modifica, i prelievi possono essere firmati da qualsiasi quorum valido.
Per migliorare la resistenza alla censura e mitigare i rischi di partizionamento della rete, i nodi Dash Core connessi alla rete Onion mirano ora a mantenere almeno due connessioni Onion in uscita e a proteggere queste connessioni dallo sfratto. A causa della bassa percentuale di indirizzi di cui si parla come nodi Onion, spesso accadeva che, a meno che non si specificasse “onlynet=onion”, un nodo raramente, se non mai, stabiliva connessioni Onion in uscita. Questa modifica garantisce che i nodi che accedono alla rete Onion mantengano alcune connessioni Onion. Di conseguenza, i messaggi di rete continueranno a propagarsi attraverso la rete anche se il traffico IPv4 non Onion viene bloccato, riducendo il rischio di partizionamento. Nota: solo i nodi collegati alla rete Onion sono interessati da questo aggiornamento.
Il rilascio dei portafogli mobili DashPay consentirà agli utenti di eseguire l’aggiornamento da Dash Wallet e creare facilmente nomi utente contestati e non contestati, effettuare pagamenti tramite nome utente e consentire ai proprietari di Maternode di votare sulle richieste di nome utente.
Tris supporta il sistema Platform PoSe per garantire che gli Evonode che non forniscono un servizio sufficiente alla rete vengano banditi per incentivare il proprietario ad affrontare il problema di fondo in modo che possano contribuire efficacemente e continuare a guadagnare premi.
Consente di crittografare le connessioni p2p con un sovraccarico praticamente nullo.
Per aiutare i nuovi nodi a sincronizzarsi più rapidamente con lo stato corrente, la sincronizzazione dello stato replicherà lo stato da altri nodi invece di elaborare l’intera blockchain.
Questo per garantire che gli Evonode che non forniscono un servizio sufficiente alla rete vengano banditi per incentivare il proprietario ad affrontare il problema di fondo in modo che possano contribuire efficacemente e continuare a guadagnare premi.
Il protocollo IBC fornisce un modo senza autorizzazione per inoltrare pacchetti di dati tra blockchain, a differenza della maggior parte delle tecnologie di bridging affidabili, la sicurezza di IBC si riduce alla sicurezza delle catene partecipanti. Il livello di applicazione IBC può essere utilizzato per creare un’ampia gamma di applicazioni cross-chain, inclusi ma non limitati a trasferimenti di token, account interchain (chiamate delegate tra due catene), trasferimenti di token non fungibili e feed di dati Oracle.
Inglese
Tedesco
Greco
Spagnolo
Filipino
Francese
Olandese
Polacco
Portoghese, Brasile
Russo
Vietnamita
Turco
Ucraino
Cinese semplificato
Coreano
Giapponese
Thai
Arabo
Persiano