Vai al contenuto
Financial Context Wiki

Selfish mining

Il mining egoista trattiene strategicamente blocchi di proof-of-work validi e rilascia un ramo privato per far perdere ai miner concorrenti più lavoro accettato. Analizza la strategia esatta, la quota di hash, il comportamento nei pareggi, le ricompense, l'aggiustamento della difficoltà, le prove e le mitigazioni senza trattare una soglia del modello come un fatto di rete.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Il mining egoista è una famiglia di politiche strategiche di mining proof-of-work in cui un miner o una coalizione coordinata trattiene uno o più blocchi validi, estende privatamente un ramo e pubblica selettivamente i blocchi nel tentativo di far spendere ad altri miner una frazione maggiore del loro lavoro su rami che non vengono accettati. L’obiettivo è solitamente modellato come l’aumento della quota di lungo periodo della coalizione di ricompense accettate rispetto alla sua quota compatibile di hash, non la creazione di proof-of-work dal nulla.

La classica strategia Eyal-Sirer, spesso chiamata SM1, traccia il vantaggio privato della coalizione. A vantaggio zero, un blocco della coalizione viene trattenuto. A vantaggio uno, un altro blocco della coalizione estende il ramo segreto, mentre un blocco pubblico concorrente innesca la pubblicazione per creare un pareggio visibile. Se il vantaggio privato è di almeno due, la pubblicazione viene sincronizzata per superare o rimanere avanti rispetto al ramo pubblico. Ogni blocco pubblicato deve comunque soddisfare le regole di validità e di proof-of-work della rete.

Due parametri del modello sono comunemente indicati come alpha e gamma. alpha è la frazione della coalizione del tasso di scoperta dei blocchi compatibile. Nella astrazione originale della rete istantanea, gamma è la frazione della potenza di hashing non della coalizione che mina sul ramo della coalizione durante un pareggio pubblico. Non è semplicemente la latenza, la frazione di nodi che hanno visto per primi un blocco o una proprietà permanente di un pool di mining. Topologia, politica di trasmissione, tempo di validazione del blocco, aggiornamento dei template, contenuto delle fee e le strategie degli altri miner possono tutti influenzare il comportamento effettivo durante un pareggio.

Non esiste una soglia universale per il mining egoista. I valori noti di un terzo o un quarto provengono da un modello particolare a ricompensa costante, a due parti, stazionario, basato sulla catena più lunga e da una strategia specifica. Lavori successivi ampliano lo spazio delle strategie, includono il ritardo di propagazione, commissioni variabili, più coalizioni, condizioni di eclisse e diversi algoritmi di regolazione della difficoltà. Una soglia derivata da un modello è un risultato condizionale, non un limite di sicurezza misurato per ogni rete proof-of-work.

Il mining egoista non è nemmeno sinonimo di ogni tipo di ritenzione di blocchi. Un partecipante a un pool può inviare quote parziali nascondendo soluzioni complete per sabotare un pool; quello è un diverso tipo di attacco a livello di pool. Pubblicazioni ritardate accidentali, fork temporanei, attacchi con blocchi non validi, censura, fee sniping, concorrenza sleale, doppia spesa, riorganizzazione della maggioranza e varianti di mining testardo si sovrappongono in alcuni meccanismi ma richiedono definizioni e prove separate.

Come analizzare il mining egoistico

  1. Definisci rete e obiettivo. Registra blocco genesis, client e attivazioni, algoritmo proof-of-work, scelta del fork e comportamento nei pareggi, target e regolazione della difficoltà, maturazione, sussidio, commissioni, blocchi stale, osservatore e periodo; specifica se l’obiettivo è ricavo accettato relativo, ricavo per tempo reale, profitto netto dei costi, censura o riorganizzazione.
  2. Specifica la strategia come una macchina a stati. Definire rami pubblici e privati, lavoro cumulativo, lead non pubblicato, azioni consentite come attendere, adottare, corrispondere, sovrascrivere o pubblicare, coordinamento di coalizioni, profondità massima trattenuta e comportamento dopo ogni scoperta di coalizione o non coalizione. Non utilizzare “selfish mining” come algoritmo completo.
  3. Definire i parametri di hash e di propagazione. Collega alpha al tasso efficace di individuazione dei blocchi compatibili nello stesso intervallo. Definisci esattamente come gamma o un modello di ritardo più ricco assegna il lavoro non della coalizione durante ogni gara; includi la topologia del relay, la validazione, il cambio di template, il comportamento dei blocchi compatti, le partizioni e la capacità di eclipse dove rilevante.
  4. Modella separatamente ricompense accettate e tempo. Traccia i blocchi accettati della coalizione e degli altri miner, i blocchi validi stale o abbandonati, sussidio, commissioni, ricompense ommer o di inclusione, maturazione, tempo di scoperta, crescita della catena pubblica e periodi di difficoltà. La quota accettata relativa non equivale automaticamente al ricavo orario o al profitto.
  5. Risolvi e valida il modello indicato. Utilizzare un’analisi Markov esatta, un processo decisionale Markov delimitato o una simulazione di eventi riproducibile appropriata alla strategia. Segnalare troncamento, convergenza, fase di riscaldamento, semi, intervalli di confidenza, sensibilità e un baseline di mining onesto; riprodurre indipendentemente a mano piccole transizioni di stato.
  6. Verifica prove e alternative. Conserva header osservati per primi, tempi di arrivo per peer, rami concorrenti, lavoro, attribuzione coinbase o pagamenti, template, commissioni, timestamp e cambi di pool. Confronta la trattenuta con varianza Poisson, ritardo di propagazione, interruzioni, errori software, partizioni, fee sniping ed errori di etichetta. La sola catena pubblica può non mostrare blocchi perdenti mai pubblicati.
  7. Valuta i controlli senza esagerare. Testa relay più rapidi e diversificati, miglioramenti di validazione, regole di pareggio, modifiche a fork-choice o ricompense, algoritmi di difficoltà, concentrazione dei pool, mobilità dei miner, monitoraggio, risposta e politica di conferma. Ogni controllo può cambiare incentivi e osservabilità o creare nuove strategie; rianalizza tutte le regole di rete.

L’output dovrebbe distinguere la definizione della strategia, il risultato del modello, il risultato della simulazione, le prove osservate nella rete e la conclusione operativa. Nessuno può sostituire silenziosamente un altro.

Esempi svolti

1. Una traccia guidata dai privati e una corsa pubblica

Sia una coalizione con alpha = 0.30. Partendo da un suggerimento pubblico, supponiamo che le scoperte successive siano coalizione, coalizione, poi non coalizione. La probabilità di quel preciso prefisso indipendente nel modello semplificato è:

0.30 * 0.30 * 0.70 = 0.063 = 6.3%

La coalizione può pubblicare il suo ramo a due blocchi contro il ramo pubblico a un blocco; se entrambi i rami sono validi e ogni blocco rappresenta lavoro uguale, il suo ramo vince e il blocco concorrente diventa obsoleto. Questa traccia dà alla coalizione due blocchi accettati, ma non stabilisce la redditività a lungo termine poiché tutte le altre tracce, i rami privati falliti, il tempo trascorso, le commissioni e le regole di adattamento contano anch’essi.

Se invece la sequenza raggiunge un pareggio pubblico di un solo blocco, impostare gamma = 0.50. Condizionato alla prossima scoperta che risolve quella gara, la coalizione la trova con probabilità 0.30 e guadagna due blocchi accettati; i miner non appartenenti alla coalizione estendono il ramo della coalizione con probabilità 0.70 * 0.50 e la coalizione guadagna uno; l’altro esito le fa guadagnare zero. I blocchi attesi condizionatamente della coalizione sono:

0.30 * 2 + 0.70 * 0.50 * 1 = 0.95

Ci sono due blocchi accettati dopo la risoluzione in ogni ramo di questa gara giocattolo, quindi la quota condizionale è 0.95 / 2 = 47.5%. Confrontare quell’evento selezionato direttamente con 30% è un bias di selezione; un modello di stato a lungo termine deve includere la probabilità e il costo di raggiungere la gara.

2. Perché la soglia classica è condizionale

Per SM1 nell’astrazione a ricompensa costante originale con alpha < 0.50, la soglia di break-even della quota di hash riportata è:

alpha* = (1 - gamma) / (3 - 2 * gamma)

A gamma = 0, la soglia è 1 / 3 = 33.3333%. A gamma = 0.50, è 0.50 / 2 = 25%. A gamma = 0.90, è 0.10 / 1.20 = 8.3333%. Questi valori mostrano la sensibilità all’assunzione di parità; non indicano che una rete misurata con otto, 25, o 34 percento di quota hash sia necessariamente redditizia, sicura, dannosa o controllata da un unico attore. L’ottimizzazione della strategia, il ritardo reale, la varianza delle ricompense, le commissioni, la difficoltà e i costi modificano la questione.

3. La quota relativa accettata non è un ricavo immediato nel tempo

Supponiamo che un intervallo simulato contenga scoperte di blocchi 1,000. Una coalizione con una quota di hash modellata 28% ottiene 270 blocchi accettati, altri miner ottengono 650, e 80 scoperte valide vengono abbandonate. La quota della coalizione sui blocchi accettati è:

270 / (270 + 650) = 270 / 920 = 29.3478%

Questo è 1.3478 punti percentuali sopra la sua quota di hash. Eppure un benchmark proporzionale onesto sulle stesse 1,000 scoperte è 280 blocchi della coalizione, quindi il suo conteggio accettato prima di qualsiasi normalizzazione del tempo è 10 inferiore, o 10 / 280 = 3.5714% sotto quel benchmark. Un successivo aggiustamento della difficoltà può ripristinare la frequenza dei blocchi della catena pubblica e modificare la ricompensa per il tempo reale, ma solo sotto le sue esatte ipotesi di finestra, timestamp, limitazione, hash-rate, commissioni e strategia continuativa. La quota relativa da sola non dimostra un profitto immediato.

4. Un’anomalia nella condivisione dei blocchi non è prova di attribuzione

Supponiamo una quota di coalizione stimata in modo indipendente di p = 0.30 e, solo come modello nullo approssimativo, n = 10,000 blocchi accettati indipendentemente. Il conteggio previsto è n * p = 3,000, e la deviazione standard binomiale è:

sqrt(10,000 * 0.30 * 0.70) = 45.8258 blocks

Un conteggio attribuito di 3,080 dà z = (3,080 - 3,000) / 45.8258 = 1.7457. Quello non è un rilevatore di mining egoista. I blocchi accettati non sono necessariamente indipendenti con p fisso; le stime di hash e le etichette del pool contengono errori; la selezione delle commissioni, i guasti, la fortuna, la propagazione e il cambio possono modificare i conteggi; e i blocchi privati non riusciti potrebbero non raggiungere mai l’osservatore. L’indagine richiede prove di header concorrenti e di arrivo dei peer, oltre a un modello causale dichiarato, non solo uno z-score della condivisione dei blocchi.

Rischi e fallimenti della revisione

Errori di modello e di protocollo

  • Strategia indefinita: SM1, varianti testarde, politiche ottimali, ritenuta consapevole delle commissioni e sabotaggio del pool richiedono azioni diverse. Pubblica una tabella completa di stati e azioni.
  • Altezza sostituita al lavoro cumulativo: La scelta del ramo segue le regole della rete sul lavoro valido, non un confronto universale del conteggio dei blocchi. Ricostruisci entrambi i rami e il lavoro esatto.
  • Dichiarazione di soglia universale: Un terzo, un quarto o qualsiasi altro valore dipende da un modello e da un obiettivo. Indica l’equazione, il dominio, la strategia e le ipotesi.
  • Lettura errata gamma: È un’allocazione modellata dell’attività mineraria non di coalizione durante una gara, non un punteggio di latenza globale osservato direttamente. Definire come viene stimata o simulata.
  • Assunzione di ricompensa costante e uguale: Sussidi , tariffe eterogenee, ricompense degli zii, maturità e selezione delle transazioni possono modificare gli incentivi. Modella il vettore di ricompensa effettivo.
  • Ignorando la regolazione della difficoltà: La crescita della catena pubblica persa può influenzare la difficoltà successiva e i ricavi in tempo reale. Simula l’epoca esatta, i timestamp, i limiti e la risposta del tasso di hash.
  • Chiamare una politica ottimale: Un MDP limitato ottimale dipende dal suo stato, azione, ricompensa, ritardo e scelte di troncamento. Riporta limiti e sensibilità piuttosto che l’ottimalità universale.

Prove ed errori di sicurezza

  • Confondere il blocco di ritenuta della pool: Nascondere una soluzione completa da un pool durante l’invio delle condivisioni differisce dall’estendere privatamente un ramo di consenso. Mantieni separati i partecipanti e i meccanismi di ricompensa.
  • Confondere la doppia spesa o il controllo di maggioranza: La manipolazione delle ricompense può verificarsi senza un pagamento in conflitto, mentre gli obiettivi di riorganizzazione e censura richiedono ulteriori dati e prove.
  • Trattare una ritenuta valida come accettazione di blocco non valida: Le blockchain della coalizione pubblicate devono ancora affrontare la normale proof-of-work e la convalida delle transazioni. La quota di hash non può autorizzare transizioni di stato invalide.
  • Inferenza del vincitore consecutivo: Poisson l’estrazione produce naturalmente dei run. Usa finestre lunghe, incertezza, rami concorrenti, tempi di arrivo, modelli e ipotesi alternative.
  • Certezza del tasso obsoleto: La copertura degli osservatori , la politica di relay, la topologia, le gare accidentali, le interruzioni e i blocchi persi nascosti influenzano le misurazioni obsolete. Conservare le limitazioni del punto di osservazione.
  • Certezza dell’etichetta del pool: I tag Coinbase, gli indirizzi di pagamento, le impronte digitali dei modelli, i contributori hash e il controllo effettivo non corrispondono perfettamente. Versionare l’attribuzione e indicarne l’incertezza.
  • Ignorando partizioni ed effetti di eclisse: Le visualizzazioni di rete ristrette possono alterare le razze, misurategamma, e fattibilità della strategia. Testare la diversità dei pari e la connettività avversaria.

Economia ed errori di mitigazione

  • Quota relativa chiamata profitto: Converti le ricompense accettate in flussi di cassa reali, sottrai i costi di energia, hosting, pool, capitale, finanziamento, tasse, variazioni e blocchi non riusciti.
  • Assumendo l’economia immediatamente dopo l’aggiustamento: La persistenza della strategia , l’uscita o l’ingresso dei concorrenti, le variazioni del prezzo dell’hash, le commissioni, il prezzo delle monete e il ritardo negli aggiustamenti possono invalidare le proiezioni a regime stazionario.
  • Trattare la quota di partecipazione al pool come controllo permanente: I contributori di Hash possono cambiare, ma contratti, firmware, custodia dei pagamenti, ritardi di coordinamento, geografia e concentrazione possono limitarli.
  • Rilevamento a metrica singola: La condivisione del blocco , il tasso obsoleto, la latenza o il modello di commissioni da soli non sono identificativi. Combina la telemetria indipendente con una regola di decisione statistica esplicita.
  • Mitigazione senza analisi di equilibrio: Relè più veloce, risoluzione dei pareggi casuale, regole di freschezza, modifiche alle ricompense o penalità possono spostare gli incentivi e aggiungere superfici di manipolazione. Rimodellare l’adozione e gli avversari.
  • Il conteggio delle conferme come correzione completa: Maggiore profondità può ridurre una parte dell’esposizione alla riorganizzazione delle transazioni, ma non elimina la distorsione delle ricompense, il lavoro sprecato, la pressione verso la centralizzazione o gli effetti sulla vivacità.

Comuni idee sbagliate

Il mining egoista richiede la maggioranza della potenza di hash

No. Lo studio del risultato originale riguarda quando una coalizione di minoranza può migliorare la sua quota relativa di ricompensa accettata modellata. Il punto di pareggio dipende dal comportamento in caso di parità e da altre ipotesi; il potere della maggioranza non è né la definizione né un prerequisito universale.

Trattenere un blocco dimostra il mining egoista

No. Gli operatori possono ritardare la pubblicazione accidentalmente o per altri motivi strategici e tecnici, e un osservatore esterno potrebbe non sapere quando è stato trovato un blocco. Il mining egoista è una politica contingente tra gli stati, non un singolo ritardo isolato.

Più blocchi accettati che condivisioni di hash dimostrano la strategia

No. Il ritrovamento del blocco è casuale, la condivisione dell’hash è stimata, le etichette sono imperfette e i miner cambiano. Anche una deviazione statisticamente insolita necessita di propagazione, ramificazione, modello, ricompensa e prove di causa alternativa.

Il mining egoista crea blocchi non validi o lavoro gratuito

No. I suoi blocchi pubblicati devono essere validi e contenere una reale prova di lavoro. Il vantaggio modellato deriva dal cambiare quali scoperte valide vengono accettate e dalla risposta di altri miner e dalle regole di difficoltà.

Un miglioramento del relay o più conferme eliminano il problema

Nessun singolo controllo dimostra la compatibilità degli incentivi. Il relay può modificare le probabilità di corsa, mentre le conferme affrontano parte del rischio di inversione delle transazioni; nessuno dei due da solo risolve la progettazione delle ricompense, le varianti strategiche, la concentrazione, le regole di aggiustamento o gli incentivi sulle commissioni.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...