Invio non richiesto di un blocco

Spingere senza invito è scortese nella maggior parte dei protocolli ed è corretto in questo. Ogni viaggio di andata e ritorno che un blocco trascorre in transito è tempo che un miner dedica a lavorare su una punta della catena che non esiste più, perciò il BIP152 ha formalizzato la scorciatoia: fino a tre peer scelti possono lanciarti un blocco nel momento in cui lo hanno. Il tuo nodo lo valida comunque da zero e non deve nulla al mittente.

Come funziona

Sotto il nome di invio non richiesto di un blocco viaggiano due cose diverse, una vecchia e informale, una specificata.

La forma vecchia è semplicemente un messaggio block che arriva senza un getdata corrispondente. Il protocollo non lo ha mai vietato e i destinatari hanno sempre elaborato questi blocchi, anche se con condizioni. Bitcoin Core verifica la proof of work nell'intestazione prima di fare qualsiasi cosa costosa, non inoltra il blocco finché non è stato validato del tutto e non si collega alla catena migliore, e tratta un blocco che non si collega a nulla che conosca come qualcosa da scartare e non come un rompicapo da risolvere. Queste regole esistono perché i dati non richiesti sono gratuiti per il mittente e costosi per il destinatario, ed è la forma di ogni attacco di negazione del servizio nel protocollo.

La forma specificata è la modalità ad alta larghezza di banda del BIP152. Un nodo invia al suo peer un messaggio sendcmpct il cui primo byte è 1, che significa: non annunciare, invia e basta. Quel peer può quindi trasmettere un cmpctblock nell'istante in cui sente parlare di un nuovo blocco, possibilmente prima di aver finito di validarlo. Il BIP152 fissa un tetto rigido di tre peer di questo tipo e Bitcoin Core applica esattamente questo, tenendo un elenco di al massimo tre nodi scelti per aver consegnato per primi i blocchi recenti. Tre è un compromesso: ridondanza sufficiente perché un solo peer lento non possa farti aspettare, e abbastanza pochi perché tu non riceva lo stesso blocco su ogni connessione che hai.

Poiché un annuncio ad alta larghezza di banda può precedere la validazione, il nodo che lo riceve lo tratta come un'affermazione e non come un fatto. La proof of work viene verificata per prima, essendo l'unica parte di un blocco che non si può falsificare a basso costo, e tutto il resto segue il percorso normale. La versione del protocollo 70015 esiste proprio perché un nodo possa segnalare che non penalizzerà un peer per aver annunciato un blocco che poi risulti non essere stato verificato del tutto.

Dove lo vedi

Gli invii non richiesti si concentrano dove i secondi valgono denaro.

I pool di mining mantengono connessioni dirette tra loro e con reti di relay come FIBRE, costruite per spostare blocchi tra continenti con il minor scambio di annuncio e richiesta che la fisica consenta. Su una macchina comune, la chiamata getpeerinfo riporta due flag per peer, bip152_hb_to e bip152_hb_from, che mostrano a quali peer hai chiesto di inviarti blocchi e quali hanno chiesto lo stesso a te. Vederne tre del primo tipo è normale, e tre è il limite.

Invio non richiesto di un blocco vs relay standard dei blocchi

Il relay standard dei blocchi e un invio non richiesto differiscono su chi decide che i byte si muovano. Con il relay standard è il destinatario a chiedere, quindi governa la propria larghezza di banda e può rifiutare qualsiasi cosa abbia già. Con un invio decide il mittente, il che risparmia un viaggio di andata e ritorno ma mette in mano a un estraneo una leva sulle tue risorse. La risposta di Bitcoin è non scegliere tra i due: consentire l'invio, limitarlo a tre peer che hai selezionato tu, verificare la proof of work prima di spendere qualsiasi cosa e validare il blocco per intero, indipendentemente da quanto cortesemente sia arrivato.