Comprendere i Masternode#

Panoramica#

I Masternodes, un tempo esclusivi della rete Dash, stanno ora diventando popolari man mano che la tecnologia viene forcata in altre blockchain. Questa sezione della documentazione descrive i principi e i meccanismi dei masternode e i servizi che forniscono specificamente alla rete Dash.

In poche parole, un masternode è un server con una copia completa della blockchain di Dash, che garantisce un certo livello minimo di prestazioni e funzionalità per eseguire determinate attività relative alla convalida dei blocchi, così come InstantSend e CoinJoin, come la transazione istantanea e la privacy. vengono chiamate le funzionalità in Dash. I masternode vengono pagati per questo servizio, utilizzando un concetto noto come Proof of Service. Ciò si aggiunge alla Proof of Work svolta dai miner per proteggere la blockchain. I masternode possono anche votare su proposal di governance e finanziamento, e ciascun masternode riceve un voto (sì/no/astenuto) su ogni proposal presentata al sistema.

Chiunque può eseguire un masternode. L’obiettivo è avere una decentralizzazione sufficiente per garantire che nessuna singola persona controlli una frazione significativa dei masternode. Tuttavia, per evitare di gonfiare la rete con masternode non necessari o di incoraggiare operatori sconsiderati, c’è una condizione che deve essere soddisfatta: la prova della proprietà delle garanzie DASH. Non è necessario che le monete siano nel masternode, ma devono essere conservate in un certo modo che sia trasparente per l’intera rete. Se il proprietario sposta o spende quelle monete, il masternode smette di funzionare e il pagamento cessa.

I Masternode vengono pagati dalla rete per i servizi InstantSend, CoinJoin e di governance che forniscono. Il 20% del sussidio per il blocco va al budget con il restante 80% suddiviso tra miner e masternode secondo questa tabella di riallocazione delle ricompense dei blocchi. Quindi, ogni 16.616 blocchi (circa 30,29 giorni), viene creato un superblocco che contiene l’intero pagamento del 20% ai vincitori della proposta di budget. I masternode vengono selezionati per il pagamento in ciascun blocco (circa ogni 2,6 minuti) da un elenco deterministico di masternode e spostati in fondo all’elenco dopo il pagamento. Man mano che vengono creati più masternode, la durata tra i pagamenti aumenta. Se la garanzia dietro un masternode viene esaurita, o se un masternode smette di fornire servizi alla rete per più di un’ora, viene rimosso dall’elenco fino al ripristino del normale servizio. In questo modo, i masternode vengono incentivati a fornire servizi efficienti e affidabili alla rete.

Avere così tanti server che contengono una copia completa della blockchain e lavorano per la moneta può essere estremamente utile. Grazie al sistema di ricompensa, non c’è il rischio di non avere abbastanza masternode e gli sviluppatori possono fare affidamento su di loro per implementare rapidamente qualsiasi nuova funzionalità decentralizzata che desiderano implementare. È qui che risiede la vera forza di Dash: un sistema incentivato di migliaia di server distribuiti che funzionano 24 ore su 24, 7 giorni su 7 significa che Dash può scalare in modo più efficiente e distribuire servizi più rapidamente di una blockchain gestita interamente da volontari non retribuiti. Più masternode, migliore e più sicura sarà la rete Dash.

As of July 2024, the Dash network has over 3000 masternodes located in over 20 countries and hosted on over 140 ISPs. The block reward is approximately 1.9 Dash, so the selected masternode receives 1.4 Dash per payment or approximately 6.5 Dash per month. The block reward decreases by 7.14% approximately once per year, so the annual earnings for a masternode owner is approximately 7% of the collateral, and will decrease over time as calculated here. See this tool to calculate real-time payment rates, and this site for various real-time statistics on the masternode network.

Evolution Masternode (evonodes)#

Evolution Masternodes (evonodes) are a subset of masternodes that have been created to host Dash Platform. Evonodes are similar to regular masternodes, but have these differences:

	Masternode	Evolution Masternode
Collaterale	1000 DASH	4000 DASH
Service(s)	Solo Dash Core	Sia Dash Core che Platform
Peso del voto	1 (collateral amount / 1000)	4 (collateral amount / 1000)

Evonodes also have higher hardware requirements than regular masternodes due to the additional Dash Platform services they host. See DIP28 for more information about evonodes.

Concetti di Masternode#

Di seguito è riportato l’elenco della documentazione disponibile:

Concetti importanti:

I Masternode sono «registrati» e iniziano a offrire servizi quando una ProRegTx `transazione speciale < https://github.com/dashpay/dips/blob/master/dip-0002.md>`_ contenente una chiave particolare viene scritta sulla blockchain.
ProRegTx fa riferimento all’ID della transazione (txid) e all’indice che detiene la garanzia. In questa transazione vengono definiti anche l’indirizzo IP e la porta del masternode.
ProRegTx contiene 2 indirizzi Dash (chiamati anche chiavi pubbliche) e una chiave pubblica BLS, che rappresentano 3 diversi ruoli nel masternode e definiscono i diritti di aggiornamento e voto. Le chiavi sono:
1. ownerKeyAddr: questo è un indirizzo Dash (chiave pubblica) controllato dal proprietario del masternode. È diverso dall’indirizzo utilizzato per la garanzia. Poiché il proprietario utilizza la chiave privata associata a questo indirizzo per emettere transazioni ProUpRegTx, deve essere univoca per ciascun masternode.
2. operatorPubKey: Questa è la chiave pubblica BLS dell’operatore masternode. Solo l’operatore può emettere transazioni ProUpServTx. Poiché la chiave dell’operatore viene utilizzata durante l’operazione live del masternode per firmare i messaggi P2P relativi al masternode, i messaggi relativi al quorum e i voti di attivazione della governance, la chiave BLS deve essere univoca per ciascun masternode.
3. votingKeyAddr: questo è un indirizzo Dash (chiave pubblica) utilizzato per la votazione delle proposal. I voti firmati con la chiave privata corrispondente sono validi mentre il masternode è nel set registrato.
I proprietari di Masternode dovrebbero specificare un indirizzo diverso da quello della garanzia per ricevere i pagamenti nel ProRegTx. Il proprietario può facoltativamente specificare una percentuale diversa da zero come pagamento a un operatore masternode separato, se applicabile.
La configurazione del masternode può essere successivamente aggiornata utilizzando le transazioni ProUpServTx, ProUpRegTx e ProUpRevTx. Vedi Aggiornamento delle informazioni su Masternode in DIP003 e Aggiornamento delle informazioni sul Masternode in questa documentazione per maggiori dettagli.

Il processo di configurazione o aggiornamento di un masternode è il seguente:

Configura il tuo server e il tuo sistema operativo
Installa il software Dash e sincronizza la blockchain
Genera una coppia di chiavi BLS e inserisci la chiave privata sul masternode
Preparare una transazione ProRegTx
Firma la transazione ProRegTx
Invia la transazione ProRegTx firmata

Il passaggio 1 può essere omesso se disponi di un server esistente. I passaggi 2 e 3 richiedono l’accesso diretto al masternode. I passaggi 3 e 4 richiedono l’accesso a un Dash Wallet (o DMT). Il passaggio 5 richiede l’accesso al wallet che detiene effettivamente la garanzia. Il passaggio 6 richiede un saldo Dash per pagare la commissione di transazione.

Masternode vs. mining#

Dash, come Bitcoin e la maggior parte delle altre criptovalute, si basa su un registro decentralizzato di tutte le transazioni, noto come blockchain. Questa blockchain è protetta attraverso un meccanismo di consenso; nel caso sia di Dash che di Bitcoin, il meccanismo di consenso è Proof of Work (PoW). I minatori tentano di risolvere problemi difficili con computer specializzati e, quando risolvono il problema, ricevono il diritto di aggiungere un nuovo blocco alla blockchain. Se tutte le altre persone che gestiscono il software concordano sul fatto che il problema è stato risolto correttamente, il blocco viene aggiunto alla blockchain e il minatore viene ricompensato.

Dash funziona in modo leggermente diverso da Bitcoin, tuttavia, perché ha una rete a due livelli. Il secondo livello è alimentato da masternode (Full Nodes), che consentono la privacy finanziaria (CoinJoin), transazioni istantanee (InstantSend) e il sistema di governance e budget decentralizzato. Poiché questo secondo livello è così importante, i masternode vengono ricompensati anche quando i miner scoprono nuovi blocchi. La ripartizione è la seguente: l’80% del sussidio del blocco è suddiviso tra il miner e un masternode secondo la distribuzione trovata qui, mentre il 20% è riservato al sistema di budget (creato dai superblocchi ogni mese).

Il sistema masternode viene definito Proof of Service (PoSe), poiché i masternode forniscono servizi cruciali alla rete. L’intera rete, infatti, è supervisionata dai masternode, che hanno il potere di respingere i blocchi formati in modo improprio dai miner. Se un minatore provasse a prendere per sé l’intero premio del blocco o tentasse di eseguire una vecchia versione del software Dash, la rete masternode renderebbe orfano quel blocco e non verrebbe aggiunto alla blockchain.

In breve, i miner alimentano il primo livello, ovvero l’invio e la ricezione di fondi e la prevenzione della doppia spesa. I Masternodes alimentano il secondo livello, che fornisce le funzionalità aggiuntive che rendono Dash diverso dalle altre criptovalute. I masternode non eseguono operazioni di mining e i computer di mining non possono fungere da masternode. Inoltre, ogni masternode è “protetto” dal collaterale DASH. Questi DASH rimangono sempre sotto il controllo esclusivo del proprietario e possono ancora essere spesi liberamente. I fondi non sono bloccati in alcun modo. Tuttavia, se i fondi vengono spostati o spesi, il masternode associato andrà offline e smetterà di ricevere premi.

Logica di pagamento#

Masternodes payments all originate on the Core chain. The Core chain pays out 62.5% of the masternode portion of Core block rewards. The remaining 37.5% is put into the credit pool and used for evonode rewards on Platform. Masternodes and evonodes also receive a portion of transaction fees on the Core chain, while evonodes receive all fees from Platform.

Poiché le percentuali di distribuzione della ricompensa sono fisse, si prevede che il numero di evonode si stabilizzi attorno a un numero fisso basato sul numero totale di masternode (considerando il numero attuale di ~3850 Masternode, si prevedono ~450 evonode). Questo perché se il numero di evonodi è superiore a quello prefissato, l’esecuzione di un normale MN sarà più redditizia rispetto all’esecuzione di un evonode e gli host convertiranno i propri evonodi in MN.

Reward reallocation#

Since the masternode reward reallocation hard fork activated in August 2024 at block 2128896, part of the coinbase masternode subsidy is moved into the credit pool each time a block is mined. Now, evonodes receive a single reward per payment cycle on the Core chain instead of rewards from four sequential blocks, as in Dash Core v19/v20.

Masternode payment frequency and payment amount have both been affected by this fork, as described in the following sections. Although masternodes initially saw a significant drop in rewards, a market-driven point of equilibrium between regular masternodes and evonodes is expected where rewards are similar to what they were before the fork.

Suggerimento

Until the network reaches a point of equilibrium, the number of masternodes and evonodes is expected to fluctuate. As more masternodes are converted to evonodes, payment frequency (and therefore rewards) on the Core chain will continue to increase. See the Evonode FAQ, DIP28, and the proposal approving evonodes for more information.

Payment frequency#

The frequency of Core chain masternode payments has increased as fewer payments are made per cycle. Around the time of the hard fork, the network had approximately 2600 enabled masternodes and approximately 175 enabled evonodes. This resulted in a reduction from 3330 payments per cycle (2600 + (175 * 4)) before the fork to only 2775 (2600 + 175) after the fork. See the following table for the outcomes of this change.

	Pre-fork	Post-fork	Difference	Outcome
Payment (blocks)	3300	2775	-525	More frequent payment
Payment (days)	5.73	4.82	-0.91	More frequent payment
Payments / year	64	76	12	More payments

Payment amount#

The increased payment frequency is balanced against the reduction per-block payment amount on the Core chain. This reduction resulted from the moving of some funds to the credit pool for Dash Platform. The table below compares the miner, credit pool, and Core chain masternode payments from a block immediately before the hard fork with the block immediately after it.

Category	Pre-Fork	Post-Fork	Difference
Miner	0.48	0.48	No change
Credit pool	0	0.54	+0.54
Masternode	1.43	0.89	-0.54
Total	1.91	1.91	No change

Suggerimento

As more masternodes are converted to evonodes, payment frequency will increase, and the difference between overall pre-fork and post-fork rewards per year on the Core chain will decrease.

Core block rewards#

A partire dalla versione 0.13.0 di Dash, i pagamenti masternode sono interamente deterministici e basati su un semplice algoritmo di ordinamento delle liste. La versione 0.13.0 di Dash ha implementato DIP003 che definisce due set di masternode.

Il set completo, che contiene tutti i masternode registrati che non hanno speso le loro transazioni di finanziamento collaterale.
Il set valido, un sottoinsieme del set completo che contiene tutti i masternode che non sono contrassegnati come Proof of Service (PoSe) vietati.

Ogni masternode dell’insieme dei masternode validi, identificato dal suo ID di transazione di registrazione, è associato al blocco in cui è stato pagato l’ultimo. Se non ha mai ricevuto il pagamento o è stato bannato per non aver soddisfatto i requisiti PoSe, verrà utilizzato il blocco in cui è stato registrato per la prima volta o in cui è stato ripristinato il servizio. L’elenco è ordinato in ordine crescente in base all’altezza del blocco e all’hash ProRegTx (come elemento decisivo nel caso in cui due masternode siano stati registrati nello stesso blocco) e la prima voce viene selezionata per il pagamento.

The Core block reward rules apply uniformly to regular masternodes and evonodes. Each are paid once per payment cycle and receive the same block subsidy amount.

Platform rewards#

Evonode rewards are based on participation in Platform consensus. Specifically, evonodes are paid for the blocks they propose while in the active validator set. At the end of each Platform epoch (9.125 days), block rewards are paid to the masternode identities associated with the participating evonodes.

Proof of Service#

Proof of Service (PoSe) è un sistema di punteggio utilizzato per determinare se un masternode fornisce servizi di rete in buona fede. Nel calcolo sono coinvolte numerose metriche, quindi non è possibile ingannare il sistema facendo sì che i masternode vengano bannati da PoSe per non aver risposto alle richieste ping, ad es. un attacco DDoS subito prima del pagamento. Ogni mancata erogazione del servizio comporta un incremento del punteggio PoSe rispetto al punteggio massimo, pari al numero di masternode registrati. Se il punteggio raggiunge il numero di masternode registrati, viene emanato un divieto PoSe e il masternode deve essere riparato per garantire che fornisca un servizio affidabile e registrato nuovamente nell’elenco utilizzando un :ref:`ProUpServTx `. Le attuali regole di punteggio a partire da Dash 0.14 sono:

Mancata partecipazione a DKG= 66% di punizione
Ogni blocco successivo riduce il punteggio PoSe di 1

La cui selezione#

Nelle versioni precedenti di Dash, si formavano spontaneamente quorum di 10 masternode per bloccare le transazioni InstantSend. A partire dalla versione 0.14, i quorum sono formati in modo deterministico, contengono più masternode e rimangono attivi per un periodo di tempo più lungo. Pur rimanendo responsabili delle transazioni InstantSend, il meccanismo di blocco è stato modificato per tentare automaticamente di bloccare la maggior parte delle transazioni di rete in base ai requisiti descritti qui. I Masternode ora sono anche responsabili di più funzioni di consenso della rete, come ChainLocks. I quorum Masternode vengono formati attraverso un processo di generazione di chiavi distribuite. La mancata partecipazione al DKG comporterà eventualmente il divieto di PoSe come descritto sopra.

Requisiti del masternode#

DASH collateral: Hosting a masternode requires a large amount of DASH collateral. Arguably the hardest part. Dash can be obtained from exchanges such as Poloniex, Bittrex, Kraken and LiveCoin. Shapeshift’s service is also an excellent way.
A server or VPS running Linux: Most recent guides use Ubuntu 22.04 LTS. We recommend VPS services such as Vultr and DigitalOcean, although any decent provider will do.
Un indirizzo IP dedicato: solitamente viene fornito con il VPS/server.

Oltre ai DASH conservati in garanzia, i masternode hanno anche requisiti hardware minimi. Per le versioni Dash 20.0 e successive, questi requisiti sono i seguenti:

Regular masternodes#

	Minimo	Raccomandato
CPU	2x 2 GHz	3x 2 GHz
RAM	4 GB + 2 GB swap	8 GB + 4 GB swap
Disco	60 GB	80 GB
Rete	750 GB/mth	1 TB/mth

Evonodes#

Evonodes have higher hardware requirements since they host Dash Platform services along with Dash Core. To support the network effectively, the following requirements are recommended:

Nota

Intel CPUs should be Haswell architecture or newer

	Raccomandato
CPU	4x 2.4 GHz
RAM	8 GB + 2 GB swap
Disco	200 GB
Rete	1 TB/mth

Masternode bandwidth use varies and will grow as the network does.