Dash: una criptovaluta focalizzata sui pagamenti — 🇮🇹 WHITEPAPER

✍️ Traduzione by Dash Italia — Fonte originale
[Alla Fonte originale potete trovare le revisioni avvenute dalla sua pubblicazione fino ad oggi]

Abstract. Una criptovaluta basata su Bitcoin, opera di Satoshi Nakamoto, con vari miglioramenti come una rete incentivata a due livelli, nota come rete masternode. Sono inclusi altri miglioramenti come PrivateSend, per aumentare la fungibilità, e InstantSend, che consente la conferma immediata delle transazioni senza un’autorità centralizzata.

1 Introduzione
Bitcoin [1] è una criptovaluta che è emersa come un popolare mezzo di scambio ed è la prima valuta digitale che ha attratto un numero considerevole di utenti [2]. Sin dal suo inizio nel 2009, Bitcoin è cresciuto rapidamente nell’adozione mainstream e nell’uso da parte dei commercianti [3]. Un problema principale con l’accettazione di Bitcoin in situazioni di punto vendita (POS) è il tempo necessario per attendere che la rete confermi la validità della transazione effettuata. Alcuni processori di pagamento hanno creato metodi per consentire ai venditori di accettare transazioni a conferma zero, ma queste soluzioni utilizzano una controparte attendibile per mediare la transazione al di fuori del protocollo.

Bitcoin fornisce transazioni pseudonime in un registro pubblico, con una relazione uno a uno tra mittente e destinatario. Ciò fornisce una registrazione permanente di tutte le transazioni che hanno mai avuto luogo sulla rete [5]. Bitcoin è ampiamente noto negli ambienti accademici per fornire un basso livello di privacy, sebbene con questa limitazione molte persone affidino ancora la loro cronologia finanziaria alla sua blockchain.

Dash è la prima criptovaluta basata sul lavoro di Satoshi Nakamoto con funzioni di privacy integrate. In questo documento proponiamo una serie di miglioramenti a Bitcoin che si traducono in una criptovaluta decentralizzata e fortemente anonima, con transazioni istantanee a prova di manomissione e una rete peer-to-peer (P2P) secondaria incentivata a fornire servizi alla rete Dash.

2 Masternode Network
I nodi completi sono server in esecuzione su una rete P2P che consentono ai peer di utilizzarli per ricevere aggiornamenti sugli eventi sulla rete. Questi nodi utilizzano quantità significative di traffico e altre risorse che comportano un costo sostanziale. Di conseguenza, da qualche tempo si è osservata una diminuzione costante della quantità di questi nodi sulla rete Bitcoin [7] e, di conseguenza, i tempi di propagazione dei blocchi sono stati superiori a 40 secondi [14]. Sono state proposte molte soluzioni, come un nuovo schema di ricompensa da parte di Microsoft Research [4] e il programma di incentivi Bitnodes [6].

Figura 1: Nodi completi Bitcoin nella primavera del 2014

Questi nodi sono molto importanti per la salute della rete. Forniscono ai client la possibilità di sincronizzare e facilitare la rapida propagazione dei messaggi in tutta la rete. Proponiamo di aggiungere una rete secondaria, nota come rete masternode Dash. Questi nodi avranno un’elevata disponibilità e forniranno un livello di servizio richiesto alla rete per partecipare al Masternode Reward Program.

2.1 Masternode Reward Program — Costi e pagamenti
Gran parte del motivo della diminuzione dei nodi completi sulla rete Bitcoin è la mancanza di incentivi a gestirne uno. Nel tempo, il costo di gestione di un nodo completo aumenta man mano che la rete viene utilizzata di più, creando più larghezza di banda e costando di più all’operatore. Man mano che il costo aumenta, gli operatori consolidano i loro servizi per renderli più economici da gestire o gestiscono un client leggero che non aiuta affatto la rete.

I masternode sono nodi completi, proprio come nella rete Bitcoin, tranne per il fatto che devono fornire un livello di servizio alla rete e avere una garanzia collaterale per partecipare. La garanzia non viene mai persa ed è al sicuro mentre il masternode è in funzione. Ciò consente agli operatori di masternode di fornire un servizio alla rete, guadagnare un pagamento per i loro servizi e ridurre la volatilità della valuta.

Per gestire un masternode, l’operatore deve dimostrare di avere il controllo su 1.000 DASH. Quando sono attivi, i masternode forniscono servizi ai client sulla rete e in cambio ricevono un pagamento regolare dalla ricompensa del blocco. Come i miner, i masternode vengono tutti pagati dalla ricompensa del blocco, il 45% della quale è dedicato a questo programma.

Poiché il programma di ricompense dei masternode è una percentuale fissa e i nodi della rete dei masternode sono fluttuanti, le ricompense dei masternode previste varieranno in base al conteggio totale attuale dei masternode attivi. I pagamenti per un giorno standard per l’esecuzione di un masternode possono essere calcolati utilizzando la seguente formula:

Dove:
n è il numero di masternode controllati da un operatore
t è il numero totale di masternode
r è la ricompensa corrente in blocchi (attualmente in media circa 3,3 DASH)
b sono i blocchi in un giorno medio. Per la rete Dash questo di solito è 576.
a è il pagamento medio del masternode (45% della ricompensa media in blocchi)

Il costo associato all’esecuzione di un masternode crea un limite rigido e flessibile di nodi attivi sulla rete. Attualmente con 8,2 milioni di DASH in circolazione, solo 8.200 nodi potrebbero essere in esecuzione sulla rete. Il limite flessibile è imposto dal prezzo che costa acquisire un nodo e dalla liquidità limitata sugli exchange dovuta all’utilizzo di Dash come valuta e non semplicemente come investimento.

2.2 Ordinamento deterministico
Uno speciale algoritmo deterministico viene utilizzato per creare un ordinamento pseudo-casuale dei masternode. Utilizzando l’hash della proof-of-work per ogni blocco, la sicurezza di questa funzionalità sarà fornita dalla rete di mining.

Pseudocodice, per la selezione di un masternode:

For(mastenode in masternodes){
current_score = masternode.CalculateScore();

if(current_score > best_score){
best_score = current_score;
winning_node = masternode;
}
}

CMasterNode::CalculateScore(){
pow_hash = GetProofOfWorkHash(nBlockHeight); // get the hash of this block
pow_hash_hash = Hash(pow_hash); //hash the POW hash to increase the entropy
difference = abs(pow_hash_hash — masternode_vin);
return difference;
}

Il codice di esempio può essere ulteriormente esteso per fornire anche classifiche di masternode, un “secondo”, “terzo”, “quarto” masternode nell’elenco da selezionare.

2.3 Quorum Trustless
Attualmente la rete Dash ha circa 4.800 masternode attivi [8]. Richiedendo 1.000 DASH di garanzia per diventare un masternode attivo, creiamo un sistema in cui nessuno può controllare l’intera rete di masternode. Ad esempio, se qualcuno volesse controllare il 50% della rete di masternode, dovrebbe acquistare 4.800.000 DASH dal mercato aperto. Ciò aumenterebbe notevolmente il prezzo e diventerebbe impossibile acquisire i DASH necessari.

Con l’aggiunta della rete di masternode e dei requisiti di garanzia, possiamo utilizzare questa rete secondaria per svolgere attività altamente sensibili in modo senza fiducia, in cui nessuna singola entità può controllare il risultato. Selezionando N pseudo-masternode casuali dal pool totale per eseguire lo stesso compito, questi nodi possono agire come un oracolo, senza che l’intera rete svolga il compito.

Ad esempio, l’implementazione di un quorum senza fiducia (vedere InstantSend [9]), che utilizza i quorum per approvare le transazioni e bloccare gli input o l’implementazione della proof-of-service [10].

Un altro esempio di utilizzo dei quorum senza fiducia può includere l’utilizzo della rete masternode come oracolo decentralizzato per i mercati finanziari, rendendo possibili contratti decentralizzati sicuri. Ad esempio, se il 31 dicembre 2018 le azioni Apple (AAPL) superano i 300 $, paga la chiave pubblica A, altrimenti paga la chiave pubblica B.

2.4 Ruoli e proof-of-service
I masternode possono fornire un numero qualsiasi di servizi extra alla rete. Come proof-of-concept, la nostra prima implementazione includeva PrivateSend e InstantSend. Utilizzando ciò che chiamiamo proof-of-service, possiamo richiedere che questi nodi siano online, rispondano e persino alla corretta altezza del blocco.

I malintenzionati potrebbero anche eseguire masternode, ma non fornire nessuno dei servizi di qualità richiesti al resto della rete. Per ridurre la possibilità che le persone utilizzino il sistema a proprio vantaggio, i nodi devono inviare un ping al resto della rete per assicurarsi di rimanere attivi. Questo lavoro viene svolto dalla rete masternode selezionando 2 quorum per blocco. Il quorum A controlla il servizio del quorum B per ogni blocco. Il quorum A è il nodo più vicino all’attuale hash del blocco, mentre il quorum B è il nodo più lontano da detto hash.

Masternode A (1) controlla Masternode B (livello 2300)
Masternode A (2) controlla Masternode B (livello 2299)
Masternode A (3) controlla Masternode B (livello 2298)

Tutto il lavoro svolto per controllare la rete per dimostrare che i nodi sono attivi viene svolto dalla stessa rete masternode. Circa l’1% della rete verrà controllato per ogni blocco. Ciò comporta che l’intera rete venga controllata circa sei volte al giorno. Per mantenere questo sistema affidabile, selezioniamo i nodi in modo casuale tramite il sistema Quorum, quindi richiediamo anche un minimo di sei violazioni per disattivare un nodo.

Per ingannare questo sistema, un aggressore dovrà essere selezionato sei volte di seguito. Altrimenti, le violazioni verranno annullate dal sistema poiché altri nodi vengono selezionati dal sistema quorum.

Tabella 1. Probabilità di ingannare il sistema che rappresenta un singolo masternode come proof-of-service non riuscito

Dove:
n è il numero totale di nodi controllati dall’attaccante
t è il numero totale di masternode nella rete
r è la profondità della catena

La selezione dei masternode è pseudo casuale in base al sistema Quorum

2.5 Protocollo masternode
I masternode vengono propagati nella rete utilizzando una serie di estensioni di protocollo tra cui un messaggio di annuncio del masternode e un messaggio di ping del masternode. Questi due messaggi sono tutto ciò che serve per rendere un nodo attivo sulla rete, oltre a questi ci sono altri messaggi per eseguire una richiesta di proof-of-service, PrivateSend e InstantSend.

I masternode vengono originariamente formati inviando 1.000 DASH a un indirizzo specifico in un portafoglio che “attiverà” il nodo rendendolo in grado di essere propagato attraverso la rete. Viene creata una chiave privata secondaria che viene utilizzata per firmare tutti gli altri messaggi. Quest’ultima chiave consente di bloccare completamente il portafoglio quando è in esecuzione in modalità autonoma.

Una modalità fredda è resa possibile dall’utilizzo della chiave privata secondaria su due macchine separate. Il client primario “caldo” firma l’input DASH 1.000 includendo la chiave privata di firma secondaria nel messaggio. Subito dopo, il client “freddo” vede un messaggio che include la sua chiave secondaria e si attiva come masternode. Ciò consente di disattivare il client “caldo” (client spento) e non lascia alcuna possibilità a un aggressore di ottenere l’accesso a 1.000 DASH ottenendo l’accesso al masternode dopo l’attivazione.

All’avvio, un masternode invia un messaggio “Masternode Announce” alla rete, contenente:

Messaggio: (input DASH 1K, indirizzo IP raggiungibile, firma, ora della firma, chiave pubblica Dash 1K, chiave pubblica secondaria, chiave pubblica di donazione, percentuale di donazione)

Ogni 15 minuti successivi, viene inviato un messaggio ping che dimostra che il nodo è ancora attivo.

Messaggio: (1K DASH Input, Firma (utilizzando chiave secondaria), Ora firma, Stop)

Dopo che un time-to-live è scaduto, la rete rimuoverà un nodo inattivo dalla rete, impedendo ai client di utilizzarlo o di pagarlo. I nodi possono anche inviare ping alla rete costantemente, ma se non hanno le porte aperte, alla fine verranno contrassegnati come inattivi e non verranno pagati.

2.6 Propagazione dell’elenco dei masternode
I nuovi client che entrano nella rete Dash devono essere informati dei masternode attualmente attivi sulla rete per poter utilizzare i loro servizi. Non appena si uniscono alla rete mesh, viene inviato un comando ai loro peer chiedendo l’elenco noto dei masternode. Un oggetto cache viene utilizzato dai client per registrare i masternode e il loro stato corrente, quindi quando i client si riavviano caricheranno semplicemente questo file anziché chiedere l’elenco completo dei masternode.

2.7 Pagamenti tramite mining e applicazione
Per garantire che a ogni masternode venga pagata la sua giusta quota di ricompensa del blocco, la rete deve far sì che i blocchi paghino il masternode corretto. Se un miner non è conforme, i suoi blocchi devono essere rifiutati dalla rete, altrimenti verrà incentivato l’imbroglio.

Proponiamo una strategia in cui i masternode formano i quorum, selezionano un masternode vincente e trasmettono il loro messaggio. Dopo che N messaggi sono stati trasmessi per selezionare lo stesso beneficiario di destinazione, verrà formato un consenso e quel blocco in questione sarà tenuto a pagare quel masternode.

Quando si esegue il mining sulla rete, il software pool (siti Web che uniscono gli sforzi dei singoli miner) utilizza l’interfaccia API RPC per ottenere informazioni su come creare un blocco. Per pagare i masternode, questa interfaccia deve essere estesa aggiungendo un beneficiario secondario a GetBlockTemplate. I pool quindi propagano i loro blocchi estratti con successo, con un pagamento diviso tra loro e un masternode.

3 PrivateSend
Riteniamo sia importante avere un’implementazione standard senza fiducia per migliorare la privacy dei suoi utenti nel client di riferimento che fornisca un elevato grado di privacy. Anche altri client come Electrum, Android e iOS avranno lo stesso livello di anonimato implementato direttamente e utilizzeranno le estensioni del protocollo. Ciò consente agli utenti un’esperienza comune di anonimizzazione dei fondi utilizzando un sistema ben compreso.

PrivateSend è una versione migliorata ed estesa di CoinJoin. Oltre al concetto di base di CoinJoin, impieghiamo una serie di miglioramenti come la decentralizzazione, un forte anonimato utilizzando un approccio di concatenamento, denominazioni e miscelazione passiva anticipata.

La sfida più grande quando si migliora la privacy e la fungibilità di una criptovaluta è farlo in un modo che non oscuri l’intera blockchain. Nelle criptovalute basate su Bitcoin, si può dire quali output non sono spesi e quali no, comunemente chiamati UTXO (output di transazione non speso). Ciò si traduce in un registro pubblico che consente a qualsiasi utente di agire come garante dell’integrità delle transazioni. Il protocollo Bitcoin è progettato per funzionare senza la partecipazione di controparti fidate e, in loro assenza, è fondamentale che le capacità di auditing rimangano facilmente accessibili agli utenti tramite la blockchain pubblica. Il nostro obiettivo è migliorare la privacy e la fungibilità senza perdere questi elementi chiave che, secondo noi, rendono una valuta di successo.

Avendo un servizio di mixing decentralizzato all’interno della valuta, otteniamo la capacità di mantenere la valuta stessa perfettamente fungibile. La fungibilità è un attributo del denaro, che impone che tutte le unità di una valuta rimangano uguali. Quando ricevi denaro all’interno di una valuta, non dovrebbe avere alcuna cronologia dei precedenti utenti della valuta o gli utenti dovrebbero avere un modo semplice per dissociarsi da tale cronologia, mantenendo così tutte le monete uguali. Allo stesso tempo, qualsiasi utente dovrebbe essere in grado di agire come revisore per garantire l’integrità finanziaria del registro pubblico senza compromettere la privacy degli altri.

Per migliorare la fungibilità e mantenere l’integrità della blockchain pubblica, proponiamo di utilizzare una strategia di mixing decentralizzata senza fiducia anticipata. Per essere efficace nel mantenere la valuta fungibile, questo servizio è direttamente integrato nella valuta, facile da usare e sicuro per l’utente medio.

3.1 Tracciamento di CoinJoin per importi
Una strategia comune nelle implementazioni Bitcoin esistenti di CoinJoin è semplicemente unire le transazioni insieme. Ciò espone gli utenti a vari metodi per seguire le monete degli utenti attraverso queste transazioni unite.

Figura 2: Un esempio di transazione CoinJoin con 2 utenti [11][12]

In questa transazione, 0,05 BTC sono stati inviati tramite il mixer. Per identificare la fonte del denaro, basta semplicemente sommare i valori sulla destra finché non corrispondono a uno dei valori sulla sinistra.

Scomposizione della transazione:

0,05 + 0,0499 + 0,0001(commissione) = 0,10 BTC.
0,0499 + 0,05940182 + 0,0001(commissione) = 0,10940182 BTC.
Ciò diventa esponenzialmente più difficile man mano che vengono aggiunti più utenti al mixer. Tuttavia, queste sessioni possono essere de-anonimizzate retroattivamente in qualsiasi momento in futuro.

3.2 Tramite Linking e Forward Linking
In altre implementazioni proposte di CoinJoin, è possibile che un utente renda anonimo il denaro e poi invii il resto da quella transazione a un exchange o a un’altra entità che conosce l’identità dell’utente. Ciò interrompe l’anonimato e consente all’entità di ripercorrere a ritroso le transazioni di quell’utente. Chiamiamo questo tipo di attacco “Forward Linking”:

Figura 3: Collegamento di modifica in avanti

In questo esempio, Alice rende anonimi 1,2 BTC, che vanno a due output, 1 BTC e 0,2 BTC. Quindi spende 0,7 BTC dall’output di 1 BTC, ricevendo un resto di 0,3 BTC. Quei 0,3 BTC vanno quindi a una fonte identificabile, confermando che Alice ha speso anche i 0,7 BTC nella transazione precedente.

Per identificare il mittente della transazione anonima, inizia dalla transazione “exchange” e torna indietro nella blockchain fino ad arrivare a “Alice invia 0,7 BTC in modo anonimo”. Come exchange, sai che è stato il tuo utente ad aver appena acquistato qualcosa in modo anonimo, rompendo così completamente l’anonimato. Chiamiamo questo tipo di attacco “Through Change Linking”.

Figura 4: tramite Change Linking

Nel secondo esempio, Alice acquista 1,2 BTC da Coinbase, quindi rende anonimo questo importo in un output di 1 BTC. Quindi spende 1 BTC, riceve un resto di 0,3 BTC e quindi lo combina con il suo precedente resto di 0,2 BTC.

Combinando il resto dalla transazione anonima (0,3 BTC) e il resto ricevuto dalla transazione CoinJoin, puoi collegare l’intera cronologia prima e dopo, interrompendo completamente l’anonimato.

3.3 Privacy migliorata e resistenza al Denial-of-Service (DOS)
PrivateSend sfrutta il fatto che una transazione può essere formata da più parti e intestata a più parti per unire i fondi insieme in un modo in cui non possono essere disaccoppiati in seguito. Dato che tutte le transazioni PrivateSend sono configurate per gli utenti che si pagano da soli, il sistema è altamente sicuro contro i furti e le monete degli utenti rimangono sempre al sicuro. Attualmente, il mixaggio PrivateSend richiede almeno tre partecipanti.

Figura 5: Tre utenti inviano fondi denominati in una transazione comune. Gli utenti si rimborsano sotto forma di nuovi output, ordinati in modo casuale.

Per migliorare la privacy del sistema nel suo complesso, proponiamo di utilizzare denominazioni comuni di 0,1 DASH, 1 DASH, 10 DASH e 100 DASH. In ogni sessione di mixaggio, tutti gli utenti devono inviare le stesse denominazioni come input e output. Oltre alle denominazioni, le commissioni devono essere rimosse dalle transazioni e addebitate in blocco in transazioni separate, sporadiche e non collegabili.

Per affrontare i possibili attacchi DOS, proponiamo che tutti gli utenti inviino una transazione come garanzia al pool quando si uniscono. Questa transazione sarà intestata a loro stessi e pagherà una commissione elevata ai minatori. Nel caso in cui un utente invii una richiesta al pool di mixaggio, deve fornire una garanzia all’inizio di questo scambio. Se in qualsiasi momento un utente non collabora, rifiutandosi di firmare ad esempio, la transazione di garanzia verrà trasmessa automaticamente. Ciò renderà costoso effettuare un attacco sostenuto sulla rete di privacy.

3.4 Anonimizzazione passiva dei fondi e concatenamento
PrivateSend è limitato a 1.000 DASH per sessione e richiede più sessioni per rendere completamente anonime somme di denaro significative. Per semplificare l’esperienza utente e rendere molto difficili gli attacchi temporali, PrivateSend funziona in modalità passiva. A intervalli stabiliti, il client di un utente richiederà di unirsi ad altri client tramite un masternode. All’ingresso nel masternode, un oggetto coda viene propagato in tutta la rete specificando le denominazioni che l’utente desidera rendere anonime, ma nessuna informazione che possa essere utilizzata per identificare l’utente.

Ogni sessione di PrivateSend può essere considerata un evento indipendente che aumenta l’anonimato dei fondi dell’utente. Tuttavia, ogni sessione è limitata a tre client, quindi un osservatore ha una probabilità su tre di poter seguire una transazione. Per aumentare la qualità dell’anonimato fornito, viene impiegato un approccio di concatenamento, in cui i fondi vengono inviati tramite più masternode, uno dopo l’altro.

Tabella 2. Quanti utenti potrebbero essere coinvolti in N sessioni di mixaggio.

3.5 Considerazioni sulla sicurezza
Quando le transazioni vengono unite, i masternode possono potenzialmente “spiare” i fondi degli utenti durante il loro passaggio. Ciò non è considerato una limitazione seria a causa del requisito per i masternode di contenere 1.000 DASH e del fatto che gli utenti utilizzano masternode casuali che selezionano per ospitare i loro join. La probabilità di seguire una transazione durante un evento di concatenamento può essere calcolata come segue:

Tabella 3. Probabilità di seguire una transazione PrivateSend sulla rete dato che l’attaccante controlla N nodi.

Dove:
n è il numero totale di nodi controllati dall’attaccante
t è il numero totale di masternode nella rete
r è la profondità della catena

La selezione dei masternode è casuale.

Considerando la fornitura limitata di DASH (8,2 milioni al momento della stesura, agosto 2018) e la bassa liquidità disponibile sul mercato, diventa impossibile ottenere un numero di masternode sufficientemente grande per avere successo in un attacco del genere.

Estendere il sistema oscurando i masternode alle transazioni che si verificano sul loro nodo migliorerà notevolmente anche la sicurezza del sistema.

3.6 Masternode Blinding tramite Relay System
Nella Sezione 3.4 descriviamo le probabilità di seguire una singola transazione attraverso più sessioni di miscelazione PrivateSend. Questo può essere ulteriormente affrontato oscurando i masternode, in modo che non possano vedere quali input/output appartengono a quali utenti. Per fare questo proponiamo un semplice sistema di relay che gli utenti possono usare per proteggere la propria identità.

Invece di inviare input e output direttamente nel pool, un utente sceglierà un masternode casuale dalla rete e richiederà che trasmetta input/output/firme al masternode di destinazione. Ciò significa che il masternode riceverà N set di input/output e N set di firme. Ogni set appartiene a uno degli utenti, ma il masternode non può sapere quale appartiene a quale.

4 Transazioni istantanee tramite InstantSend
Utilizzando i quorum dei masternode, gli utenti sono in grado di inviare e ricevere transazioni irreversibili istantanee. Una volta formato un quorum, gli input della transazione vengono bloccati in modo da poter essere spesi solo in una transazione specifica, un blocco di transazione impiega circa quattro secondi per essere impostato attualmente sulla rete. Se viene raggiunto un consenso su un blocco dalla rete del masternode, tutte le transazioni o i blocchi in conflitto verranno rifiutati in seguito, a meno che non corrispondano all’ID transazione esatto del blocco in atto.

Ciò consentirà ai venditori di utilizzare dispositivi mobili al posto dei tradizionali sistemi POS per il commercio nel mondo reale e agli utenti di risolvere rapidamente transazioni non commerciali faccia a faccia come con il denaro tradizionale. Ciò avviene senza un’autorità centrale. Una panoramica completa di questa funzionalità può essere trovata nel white paper InstantSend [9].

5 Ulteriori miglioramenti
5.1 Algoritmo di hashing X11
X11 è un algoritmo di hashing ampiamente utilizzato, che adotta un approccio diverso, noto come concatenamento di algoritmi. X11 è costituito da tutti gli 11 concorrenti SHA3 [13], ogni hash viene calcolato e quindi inviato all’algoritmo successivo nella catena. Utilizzando più algoritmi, la probabilità che venga creato un ASIC per la valuta è minima fino a una parte successiva del suo ciclo di vita.

Nel ciclo di vita di Bitcoin, il mining è iniziato con gli hobbisti che utilizzavano le unità di elaborazione centrale (CPU) per estrarre la valuta, quindi poco dopo è stato creato il software delle unità di elaborazione grafica (GPU), che ha rapidamente sostituito le CPU. Anni dopo il ciclo delle GPU, sono stati creati gli ASIC o Application Specific Integrated Circuits, che hanno rapidamente sostituito le GPU.

A causa della complessità e delle dimensioni del die necessarie per creare un ASIC per estrarre X11, prevediamo che ci vorrà molto più tempo rispetto a Bitcoin, consentendo agli hobbisti di partecipare all’estrazione per un periodo di tempo più lungo. Riteniamo che questo sia molto importante per una buona distribuzione e crescita di una criptovaluta.

Un altro vantaggio dell’approccio di hashing a catena è che le CPU di fascia alta offrono un rendimento medio simile a quello delle GPU. Inoltre, è stato segnalato che le GPU funzionano con temperature inferiori del 30–50%, con meno wattaggio rispetto all’algoritmo Scrypt utilizzato dalla maggior parte delle criptovalute attuali.

5.2 Fornitura di mining
Un approccio diverso per limitare l’inflazione del mining è adottato in Dash, utilizzando una riduzione del 7% della fornitura all’anno. Ciò avviene in contrapposizione al dimezzamento implementato da altre valute. Inoltre, la fornitura di ogni blocco è direttamente legata alla quantità di minatori sulla rete; più minatori comportano ricompense minerarie più basse.

La produzione di Dash è programmata per continuare per tutto questo secolo e per il prossimo, riducendosi lentamente fino a quando, verso l’anno 2150, la produzione cesserà.

Figura 6: Programma di ricompensa del mining

6 Conclusione
Questo documento introduce vari concetti per migliorare la progettazione di bitcoin, con conseguente miglioramento della privacy e fungibilità per l’utente medio, minore volatilità dei prezzi e propagazione più rapida dei messaggi in tutta la rete. Tutto ciò è ottenuto utilizzando un modello a due livelli incentivato, anziché il modello a livello singolo esistente in altre criptovalute come Bitcoin. Utilizzando questa progettazione di rete alternativa diventa possibile aggiungere molti tipi di servizi come la miscelazione decentralizzata di monete, transazioni istantanee e oracoli decentralizzati utilizzando quorum masternode.

Riferimenti

Autori: Evan Duffield & Daniel Diaz

🌐 V️isita il nostro Sito Web 🌐

Posted Using InLeo Alpha

Sort:

Trending

[-]

hivebuzz (74) 3 days ago

Congratulations @italiadash! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)

	You received more than 100 HP as payout for your posts, comments and curation. Your next payout target is 250 HP. _{The unit is Hive Power equivalent because post and comment rewards can be split into HP and HBD}
	You made more than 400 comments. Your next target is to reach 500 comments.

_{You can view your badges on your board and compare yourself to others in the Ranking}
_{If you no longer want to receive notifications, reply to this comment with the word STOP}

Check out our last posts:

Christmas Season is Back - Gift your Loved Friends

$0.00