Miglior Share Solo, Nessun Blocco: eCash RTT

Il Real-Time Targeting di eCash, noto come Heartbeat, è una regola di consenso che alza il target di mining richiesto per circa due minuti dopo ogni blocco, poi lo lascia decadere fino alla difficoltà pubblicata. Una share che supera la difficoltà mostrata su un explorer è un blocco valido solo se arriva dopo quel decadimento. È di gran lunga il motivo più comune per cui un miner in solitaria su XEC vede una share record e non vince nulla.

Conclusioni chiave

• eCash richiede una difficoltà superiore a quella pubblicata per circa 115 secondi dopo ogni blocco, a cadenza stabile.
• Il requisito parte astronomicamente alto e cala come la quinta potenza del tempo trascorso. Non può mai essere più facile della difficoltà standard.
• Gli explorer mostrano la difficoltà di ogni blocco così com’è stato minato: il valore minimo. Non esiste alcun feed pubblico del requisito in tempo reale.
• Abbiamo riprodotto la formula ufficiale sui log di un nodo in produzione su 15 misurazioni: deviazione massima 0,002%.
• La ripida rampa iniziale in cui incappano oggi i miner in solitaria esiste interamente a causa dell’aggiornamento del 15 novembre 2025, che ha aggiunto una finestra di filtro da un blocco.

Perché la mia share ha superato la difficoltà di rete senza trovare un blocco?

Un miner ci ha scritto con una lamentela precisa e del tutto ragionevole. Aveva risolto un blocco eCash con una share di circa 8,0 miliardi di difficoltà contro una difficoltà di rete pubblicata di circa 7,36 miliardi. Ore dopo il suo miner ha registrato una share molto migliore — circa 11,87 miliardi — e non è successo nulla. Ha controllato ogni blocco della catena da allora. La difficoltà pubblicata era rimasta tra 7,1 e 7,4 miliardi per tutta la notte. Secondo le regole di Bitcoin, quella share era un blocco.

Aveva ragione sui numeri e torto sulla regola. Su eCash la difficoltà che un explorer pubblica non è la difficoltà che devi battere nel momento in cui invii. È il pavimento.

La sua share da 11,87 miliardi è arrivata circa 100 secondi dopo il blocco precedente, ancora dentro la rampa. In quel momento la rete richiedeva 14,85 miliardi, quindi la share valeva circa l’80% di quanto serviva. Quindici secondi più tardi la rampa si era esaurita, il requisito è sceso a 7,33 miliardi, e quella stessa identica share avrebbe vinto. Non gli è mancato hashrate. Gli è mancato un quarto di minuto.

Cos’è il Real-Time Targeting di eCash?

Il Real-Time Targeting si è attivato con l’aggiornamento Heartbeat il 15 novembre 2024. Il problema che risolve è specifico delle catene SHA-256 minoritarie.

eCash condivide l’algoritmo con Bitcoin e Bitcoin Cash, quindi l’hashrate si sposta tra loro inseguendo la redditività. Quando la difficoltà di eCash cala, hashrate esterno si riversa dentro e mina diversi blocchi in rapida successione: i blocchi turbo. L’algoritmo di difficoltà standard reagisce alzando la difficoltà; l’hashrate di passaggio se ne va; la catena resta arenata con una difficoltà alta e una frazione dell’hashrate, producendo vuoti tra blocchi che possono durare ore. I depositi si bloccano. Le conferme diventano imprevedibili.

Heartbeat attacca la prima metà di quel ciclo. Rendendo invalidi i blocchi minati troppo presto dopo il predecessore, elimina il premio per il mining a raffica, così l’algoritmo di base non arriva mai a sovracorreggere. Il design è ispirato alla ricerca di Tom Harding sul Real-Time Block Rate Targeting.

Il meccanismo funziona solo grazie ad Avalanche. Il targeting in tempo reale dipende dalla misurazione che ogni nodo fa di quando un blocco è arrivato, cosa intrinsecamente soggettiva. Il post-consenso di Avalanche riconcilia quelle visioni soggettive in un’unica decisione di rete, senza toccare l’header del blocco né il consenso Nakamoto.

Come si calcola il target in tempo reale di eCash?

La regola è implementata in Bitcoin ABC come policy di parcheggio anziché come regola di validità. Il codice rilevante si trova in src/policy/block/rtt.cpp, e la formula centrale è enunciata nel commento del file stesso:

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K vale 6, quindi il target scala con la quinta potenza del tempo trascorso. T è la spaziatura obiettivo per quella finestra di filtro. Il tempo trascorso si misura da quando il nodo ha ricevuto ciascun header di blocco precedente, non dal timestamp scritto nell’header.

La formula viene valutata su cinque finestre simultaneamente, e vince il risultato più severo:

Le lunghezze delle finestre sono numeri primi, saltandone uno tra voci successive. Il codice sorgente spiega perché: è un tentativo ragionato di evitare frequenze di risonanza concatenando una serie di filtri. La serie si ferma a 17 blocchi perché finestre ulteriori non cambiano più la selettività del filtro in modo significativo.

Due proprietà contano per i miner. Si applica il target più basso tra tutte le finestre, quindi governa il vincolo più duro. E il risultato è limitato: il target in tempo reale non è mai più alto — mai più facile — del target standard. La difficoltà può solo essere spinta in su, mai in giù.

Ricostruire le costanti da gamma(1 + 1/6) = 0.9277193336 riproduce tutti e cinque i coefficienti pubblicati a dieci cifre significative.

Quanto è più difficile un blocco eCash subito dopo il precedente?

Questa è la tabella che non esiste da nessun’altra parte, calcolata dalla formula ufficiale a una cadenza stabile di dieci minuti. Il moltiplicatore si applica alla difficoltà che un explorer pubblicherebbe.

Un blocco trovato un secondo dopo il suo predecessore avrebbe bisogno di circa venti miliardi di volte la difficoltà pubblicata. A dieci secondi, duecentomila volte. La curva è brutalmente ripida e poi semplicemente si ferma: dopo circa 115 secondi il requisito eguaglia esattamente la difficoltà pubblicata, e lì resta.

Quando i blocchi recenti sono arrivati più velocemente di dieci minuti, ogni finestra parte da un tempo trascorso più breve e la rampa parte più alta e dura di più. Non è un effetto collaterale. È il meccanismo anti-blocchi-turbo che fa il suo lavoro.

La formula corrisponde a ciò che fa davvero un nodo?

L’abbiamo testato. Qui sotto ci sono i valori registrati da uno dei nostri nodi eCash nei due minuti e mezzo dopo un blocco, accanto ai valori che la formula pubblicata prevede usando soltanto i tempi di arrivo dei blocchi visibili nello stesso log.

Su tutte e quindici le misurazioni registrate la deviazione massima è stata dello 0,002%. La formula pubblicata non è un’approssimazione di ciò che fanno i nodi: è esattamente ciò che fanno.

Vale la pena estrarre un dettaglio. Per i primi 99 secondi il vincolo determinante è stata la finestra da un blocco. Solo a 109 secondi ha preso il sopravvento la finestra da due blocchi, e 40 secondi dopo la difficoltà standard ha fissato il pavimento.

Cosa è cambiato il 15 novembre 2025?

Prima di quell’aggiornamento c’erano quattro finestre, a partire da due blocchi. L’aggiornamento del 15 novembre 2025 ha aggiunto la finestra da un blocco con la sua spaziatura di 150 secondi.

Passare entrambe le configurazioni nella formula a una cadenza stabile di dieci minuti produce un risultato sorprendente:

A cadenza normale la configurazione a quattro finestre non produceva alcuna rampa. Entrava in gioco solo quando i blocchi stavano già arrivando troppo in fretta, che era il suo scopo circoscritto. La ripida rampa iniziale in cui incappa oggi un miner in solitaria, su una catena per il resto sana, esiste interamente a causa della finestra da un blocco aggiunta a novembre 2025.

Se hai minato eCash in solitaria prima di quella data e non hai mai visto succedere questo, ecco perché.

Perché la difficoltà che mostra il mio pool non coincide con l’explorer?

Perché su eCash sono numeri diversi, e il software di mining lo dice.

Il software di mining in solitaria per eCash di Bitcoin ABC legge rtt.nexttarget a ogni chiamata getblocktemplate, lo converte in difficoltà e — solo per eCash — usa quel valore come difficoltà di rete che riporta e registra. Ogni altra catena SHA-256 usa invece i bit di difficoltà dall’header del blocco.

Quella singola diramazione spiega il comportamento che ogni operatore di pool eCash vede: dopo l’arrivo di un blocco la difficoltà di rete riportata è astronomicamente alta, cala di un ordine di grandezza ogni dieci secondi per circa due minuti, e poi si appiattisce sul valore che un explorer alla fine pubblicherà.

Gli operatori di nodo hanno una seconda opzione: calcolare il target localmente da rtt.prevheadertime, rtt.prevbits e rtt.nodetime, tutti presenti nel template di blocco. Entrambe le strade sono documentate sulla pagina mining di eCash.

Cosa succede a un blocco che viola il target in tempo reale?

Viene parcheggiato, non rifiutato. Il nodo lo marca con una violazione di policy etichettata policy-bad-rtt e lo mette da parte, poi il polling di Avalanche decide se il resto della rete è d’accordo. Se il nodo è in minoranza ribalta la sua posizione. L’header del blocco resta intatto per tutto il tempo, e il consenso Nakamoto non viene modificato.

Eseguire getchaintips su un nodo eCash li mostra accanto alla catena attiva, marcati status: parked. Su uno dei nostri nodi la chiamata ha restituito 262 punte di ramo parcheggiate tra le altezze di blocco 940.265 e 960.666 — circa 20.400 blocchi, quindi circa l’1,3% dei blocchi in quell’intervallo è stato parcheggiato almeno una volta.

Quella cifra è un limite superiore alle violazioni del target in tempo reale, non un loro conteggio. eCash parcheggia blocchi per diverse ragioni, e Avalanche parcheggia anche il lato perdente di una normale corsa a fork. Ma su una catena dove due blocchi concorrenti alla stessa altezza sono rari, un tasso di punte parcheggiate sopra l’uno per cento ti dice che il meccanismo è attivo e sta lavorando, non fermo.

Vale anche per Bitcoin, Bitcoin Cash o le altre catene SHA-256?

No. Tra le catene SHA-256 questo comportamento è esclusivo di eCash, perché dipende dal livello Avalanche per riconciliare una temporizzazione soggettiva.

Su Bitcoin e Bitcoin Cash una share sopra la difficoltà di rete è un blocco, punto. Se mini più catene e stai confrontando i tuoi valori di miglior share tra loro, la colonna eCash è l’unica dove la temporizzazione entra nel calcolo. La nostra analisi delle probabilità del mining in solitaria e il Radar di Rete usano entrambi la difficoltà pubblicata, che è la base corretta per la probabilità di lungo periodo: la rampa si media nel tempo.

Quanto è grande la zona morta per un miner in solitaria?

Ogni share che atterra prima che la rampa si esaurisca è sprecata, per quanto buona sia. A cadenza stabile:

Circa un quinto di ogni intervallo di blocco è inutilizzabile per una share che supera di poco la difficoltà. Le share più forti superano la rampa prima, ed è il motivo per cui una share davvero enorme non viene quasi mai sprecata.

Questo non cambia il tuo rendimento atteso in alcun modo su cui tu possa agire. È già riflesso nella produzione reale di blocchi della catena, e quindi nella difficoltà stessa. Nulla nella configurazione del tuo miner lo influenza.

Cosa dovrebbe davvero fare un miner in solitaria al riguardo?

Per la maggior parte delle persone la risposta onesta è nulla, ma leggi bene i tuoi numeri.

• Il display della miglior difficoltà del tuo miner è calcolato localmente, nell’istante in cui l’hash viene trovato, prima che il pool abbia risposto. Registra il valore che la share fosse destinata a essere valida oppure no. È anche una cifra storica che non si azzera quando trovi un blocco.
• Una miglior share di sempre sopra la difficoltà pubblicata su eCash non è prova di un blocco perso o rubato. Se vuoi confermare che un blocco esiste, guarda la transazione coinbase on-chain. Su un pool non custodiale il tuo indirizzo è scritto nel coinbase prima che inizi l’hashing, quindi un blocco reale è visibile a tuo nome e nessuno può spostarlo.
• Se sei curioso di sapere quanto sei andato vicino, il nostro articolo miglior share spiegata copre come leggere quelle cifre, e il calcolatore delle probabilità converte l’hashrate in aspettative realistiche. La pagina del pool eCash elenca la difficoltà attuale e tutti gli endpoint regionali, il generatore di configurazione costruisce le impostazioni stratum, e i dati live su blocchi e worker stanno sulla dashboard del pool.

Se fai girare un tuo nodo eCash per minare in solitaria, c’è una voce di configurazione che conta. Un nodo ha bisogno di 17 blocchi di tempi di arrivo degli header registrati prima di poter calcolare il target in tempo reale. Finché non li ha, può costruire template a una difficoltà troppo bassa e vedersi parcheggiare i blocchi. Impostare persistrecentheaderstime=1 salva quei tempi di riferimento su disco e li ricarica al riavvio, chiudendo la lacuna.

Fonti

• Documentazione mining di eCash — i campi RTT del template di blocco, l’implementazione di riferimento del calcolo del target e i coefficienti di filtro pubblicati
• Heartbeat Upgrade: A Steady Pulse for eCash — la motivazione, il problema del mining opportunistico e il ruolo del post-consenso di Avalanche
• Codice sorgente di Bitcoin ABC — src/policy/block/rtt.cpp, che contiene la formula, le costanti delle finestre e la policy di parcheggio
• Software di mining in solitaria per eCash — come il target in tempo reale diventa la difficoltà di rete riportata su eCash

Le cifre di verifica in questo articolo sono state prodotte valutando la formula pubblicata sui log di un nodo eCash attivo il 2 agosto 2026 e confrontando i risultati valore per valore.