✍️ Traduzione by Dash Italia — Fonte originale
[Questo articolo è stato scritto il 22 Agosto 2018 quindi alcune informazioni potrebbero essere cambiate]
In questo post, vorrei descrivere cosa sono i quorum in Dash e cosa risolvono. Vorrei anche spiegare i problemi con questi e perché non possiamo facilmente scalarli o usarli per nuovi casi d’uso. Inizialmente, questo faceva parte di un altro post che sto scrivendo nello stesso momento e che pubblicherò qualche tempo dopo questo. Fondamentalmente, in questo post cercherò di descrivere cosa sono i quorum, a cosa servono attualmente e quali sono i loro limiti attuali. Il prossimo post darà quindi una risposta su come intendiamo risolvere questi problemi una volta per tutte.
Cosa sono i quorum?
Un quorum è una raccolta di entità che possono votare su qualcosa. A ogni membro è generalmente consentito votare solo una volta. Se >= 51% vota per la stessa cosa, si raggiunge la maggioranza. Qualcosa ha ottenuto la maggioranza dei voti o no, non dovrebbe esserci nulla in mezzo.
Questo è utile se la probabilità di disaccordo è troppo alta, come ad esempio accade quando si tratta di propagazione delle transazioni e gestione dei conflitti se si presentano. Bitcoin ha introdotto una politica per gestire questo, che è la politica first-seen. Dash ha ereditato questa politica. Fondamentalmente significa che se si verifica un conflitto (ad esempio una transazione di doppia spesa) la prima transazione vista è l’unica che un nodo dovrebbe accettare e propagare ignorando tutte le altre.
Questo rimuove ogni ambiguità su un singolo nodo, inclusi i miner. Riduce anche l’ambiguità sull’intera rete, poiché significa anche che una transazione ben propagata non può essere sostituita da una in conflitto. Tuttavia, se una transazione non è ancora ben propagata, due transazioni concorrenti inizieranno a competere nella rete, con il risultato che una parte della rete vedrà prima una delle transazioni e l’altra parte della rete vedrà prima l’altra transazione. Alla fine, sarà impossibile dire quale delle due transazioni verrà estratta e confermata sulla catena. Questo perché un singolo nodo non può sapere cosa hanno visto per primo gli altri nodi.
InstantSend
Dash ha già risolto questo problema grazie a InstantSend. InstantSend è la prima volta che abbiamo utilizzato i quorum per risolvere tale ambiguità nella rete. Funziona scegliendo un nuovo quorum di 10 masternode per input di transazione e lasciando che ogni membro firmi e propaghi un voto per esso. Se 6 di questi 10 lo fanno, possiamo essere abbastanza sicuri che la maggior parte della rete ha visto anche questa transazione per prima. Se questo è il caso, un nodo può tranquillamente rifiutare tutte le altre transazioni in conflitto con quella, anche se sono state viste localmente per prime. Se si fosse verificata una gara tra due transazioni in conflitto, solo una di entrambe sarebbe stata in grado di raggiungere più dell’altra.
Delegare il voto al quorum è quindi come una misurazione statistica, perché ciò che si applica statisticamente all’intera rete si applica anche a un sottogruppo casuale di quella rete.
Se 3 transazioni gareggiassero nello stesso modo, è ancora possibile che solo una ottenga la maggioranza, ma potrebbe accadere che non si ottenga alcuna maggioranza, il che significa che non si può prendere alcuna decisione. Per InstantSend, questo va bene perché la cosa peggiore che può accadere è che il destinatario di una transazione non riceva la garanzia immediata di una conferma successiva e quindi debba attendere la normale conferma on-chain.
Attacchi Sybil e Masternode
Potresti chiederti perché questa soluzione non sia stata utilizzata in altre monete, ad esempio Bitcoin. Il motivo è che un tale sistema è sicuro solo se la possibilità dei cosiddetti attacchi Sybil è praticamente pari a zero. Un attacco Sybil significa che una singola entità (possibilmente un avversario) è in grado di creare facilmente tutte le entità necessarie per aumentare le possibilità di poter controllare l’esito di un voto.
Nelle criptovalute, ad esempio, questo significa che non puoi semplicemente scegliere un set di nodi da tutti i nodi noti, poiché qualsiasi avversario è in grado di creare migliaia o addirittura decine di migliaia di nodi per aumentare la probabilità che i suoi nodi vengano scelti.
Ciò significa che per rendere sicuro il sistema, il numero di possibili membri del quorum deve essere limitato. Deve anche essere relativamente costoso diventare un membro, poiché altrimenti si potrebbe diventare membro a basso costo più volte. Deve anche esserci un incentivo a comportarsi bene, il che significa che deve esserci il rischio di perdere qualcosa nel caso in cui qualcuno venga colto nel tentativo di imbrogliare il sistema.
I masternode in Dash risolvono tutto questo richiedendo una garanzia di 1000 Dash e pagando ai proprietari di masternode una parte della ricompensa del blocco. Ciò limita il numero di possibili membri del quorum e incentiva i masternode a comportarsi in modo onesto. Qualcuno che possiede molti masternode rischia di perdere le sue ricompense quando cerca di giocare con il sistema.
Scalabilità dei quorum e InstantSend
Attualmente, InstantSend è una funzionalità opzionale che richiede il pagamento di una commissione più elevata. Fondamentalmente paghi alcune commissioni extra in modo che il destinatario di una transazione InstantSend riceva i fondi più velocemente. C’è richiesta nella comunità affinché ciò cambi in modo che ogni transazione diventi sostanzialmente una transazione InstantSend.
Tuttavia, questo non è così facile come ci si potrebbe aspettare. I quorum dietro InstantSend hanno un sovraccarico sulla rete poiché devono propagare molti più messaggi di una transazione normale. In genere, InstantSend richiede circa 10 volte più messaggi per essere completamente propagato nella rete. InstantSend è anche più esigente quando si tratta di requisiti di CPU e RAM.
Il motivo è che ogni membro del quorum crea un voto per input di transazione e poi lo propaga all’intera rete. Alla fine, vengono propagati 10 messaggi per input di transazione. Una transazione con 10 input richiederebbe già 100 messaggi per essere propagata. Allo stesso tempo, ogni nodo nella rete deve verificare questi messaggi e poi conservarli in memoria finché la transazione non viene estratta sulla catena e confermata da più blocchi. Immagina cosa significherebbe se tutte le persone nel mondo iniziassero a usare Dash…
Il carico sulla rete non solo aumenterebbe le richieste di hardware e di rete. Ridurrebbe anche la stabilità, l’affidabilità e la sicurezza dell’intera rete. Questo perché ogni voto viene trattato come un singolo messaggio e solo se 6 su 10 sono presenti localmente, la maggioranza può essere dimostrata. A causa del carico, aumenta la probabilità che diversi nodi vedano un diverso sottoinsieme di voti, rendendo più facile per gli avversari sfruttare la propagazione lenta e non deterministica.
Utilizzo dei quorum per nuovi casi d’uso
Ci sono molti altri casi d’uso che trarrebbero vantaggio dai quorum. Alcuni sono persino impossibili da implementare senza qualcosa come i quorum.
Questi tuttavia soffrirebbero degli stessi problemi di scalabilità descritti per InstantSend, rendendo il sistema attuale inadatto. Allo stesso tempo, molti casi d’uso richiedono un livello di sicurezza molto più elevato, che può essere ottenuto solo aumentando le dimensioni dei quorum.
L’aumento delle dimensioni del quorum aumenterebbe tuttavia anche il carico sulla rete. Se ad esempio utilizzassimo 100 membri per quorum, dovrebbero essere propagati 100 voti per tutto ciò su cui è necessario votare.
Evolution e quorum
Evolution contiene alcune funzionalità fondamentali che si basano molto sulle decisioni di maggioranza prese dai quorum. Inizialmente, il piano era di riutilizzare il sistema di quorum esistente per questo, ma si è scoperto che avremmo incontrato troppi limiti.
Fondamentalmente si applicano gli stessi limiti del ridimensionamento di InstantSend, ma sono emerse anche alcune nuove limitazioni. Ad esempio, dobbiamo archiviare i risultati delle decisioni di quorum on-chain in modo che possano essere verificati da tutti e per sempre. Tuttavia, archiviare 100 o più firme ECDSA on-chain ogni volta non sembra che si adatterebbe bene 😉
Conclusione
I quorum attualmente utilizzati in Dash sono per lo più abbastanza buoni per quello che vengono utilizzati al momento. Tuttavia, siamo a un punto in cui abbiamo bisogno di una soluzione migliore se vogliamo continuare a migliorare. Uno dei miei prossimi post descriverà una soluzione su cui stiamo lavorando da un po’ di tempo.
Autore: Alexander Block
🌐 V️isita il nostro Sito Web 🌐
