Alcune osservazioni:
il
pruning serve solo a risparmiare spazio, il tempo necessario per il download + syncing è lo stesso
il vero collo di bottiglia è dato di solito dal
processore e dall'hard disk; per usare il più possibile la ram invece dell'hard disk per il database degli UTXO impostare il parametro
--dbcache=numero di mega (per default --dbcache=300, ma se avete molta memoria potete impostare --dbcache=4000 o --dbcache=6000); per usare più core per la verifica degli script impostare il parametro
--par=2 (o 4 o quanti thread in parallelo volete utilizzare)
Avrete notato che quando si sincronizza Bitcoin Core per la prima volta, il tempo per scaricare e validare i primi 200000 blocchi è meno di 1 ora, per validare gli ultimi 10000 blocchi invece ormai il mio vecchio portatile impiega 7 ore
Ovviamente i motivi sono molti (all'inizio i blocchi erano quasi vuoti, sui primi 295000 blocchi non si verificano le firme grazie ai checkpoint, ecc.), ma perché c'è ancora tanta differenza tra validare 1 blocco di 10 mesi fa e 1 blocco di 1 mese fa?
Innanzitutto considerate che man mano che si acquisiscono blocchi il database degli UTXO che deve essere costantemente aggiornato cresce e si complica, inoltre c'è la questione del numero di firme da verificare e del tempo di verifica che cresce in
maniera quadratica all'aumentare del numero di firme presenti in ciascuna transazione, e questa situazione sta peggiorando vistosamente negli ultimi mesi:
se andate qui infatti -->
https://statoshi.info/dashboard/db/transactions , impostate il tempo a 1 anno e guardate l'ultimo grafico, quello intitolato: "sigops", osserverete come si sta complicando e appesantendo il lavoro di validazione dei full node soprattutto dall'estate in poi. Se le cose continueranno così, tra 1 anno sarà letteralmente impossibile per pc vecchi come il mio tentare una sincronizzazione da zero della blockchain.
Il controllo delle firme non è l'unico controllo da fare, tutti i vari controlli si possono dividere in 3 categorie:
The checks performed can be divided in three groups: A) block validity, B) linking and C) script validity. A includes rules like proof-of-work, amount generated, ... B is about whether transactions are not double spends. C is whether spends are done using the correct key. When downloading blocks, A and B are performed, and C after the last checkpoint. At startup, only A is performed ...
Pieter Wuille
Ai primi di dicembre ho dovuto reinstallare Bitcoin Unlimited (ho provato anche con Core, e da questo punto di vista sono la stessa cosa) :
6 giorni per riscaricare e validare i 100 giga di blocchi (portatile Intel Core 2 Duo CPU 8700 @2.53Hz, 4 GB di RAM, disco meccanico usb esterno), cpu sempre al massimo. Per questo ho affermato che tra 1 anno, visto che la pesantezza dei calcoli non cresce linearmente nel tempo, probabilmente mi ci vorranno 2 settimane o più.
Per il momento l'unica cosa che mi è venuta in mente è agire direttamente sui checkpoint, quindi ho modificato a mano la lista in questo modo:
file
chainparams.cpp originale
checkpointData = (CCheckpointData) {
boost::assign::map_list_of
( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
(105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
(134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
(168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
(193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
(210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
(216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
(225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
(250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
(279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
(295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983")),
1397080064, // * UNIX timestamp of last checkpoint block
36544669, // * total number of transactions between genesis and last checkpoint
// (the tx=... number in the SetBestChain debug.log lines)
60000.0 // * estimated number of transactions per day after checkpoint
};
file
chainparams.cpp modificato
checkpointData = (CCheckpointData) {
boost::assign::map_list_of
( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
(105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
(134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
(168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
(193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
(210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
(216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
(225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
(250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
(279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
(295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))
(445000, uint256S("0x000000000000000003287f1b7576b82af3c8927ae8af9a7398bdcbf9af378762")),
1482653647, // * UNIX timestamp of last checkpoint block
181954097, // * total number of transactions between genesis and last checkpoint
// (the tx=... number in the SetBestChain debug.log lines)
200000.0 // * estimated number of transactions per day after checkpoint
};
Ho ricompilato il tutto, e riprovato da zero a scaricare e sincronizzare:
33 ore il tempo totale, quindi il 75% circa del tempo risparmiato (che corrisponde al tempo necessario a verificare le firme dal blocco 295000 al blocco 445000!).
Ovviamente bisogna essere consapevoli che così facendo non si stanno effettuando una serie di controlli (quelli della categoria C citata da Wuille).
Per concludere esiste un progetto in rete (Iguana Core) nel quale è stato riscritto completamente il codice che implementa il protocollo bitcoin (non come Unlimited, che si basa su Core), anche se è a uno stadio iniziale:
https://bitco.in/forum/threads/iguana-parallel-sync-full-btc-blockchain-in-30-minutes-uses-half-the-space-but-starts-up-instant.911/https://bitcointalksearch.org/topic/using-compact-indexes-instead-of-hashes-as-identifiers-1377459http://wiki.supernet.org/wiki/How_To_Use_Bitcoin_RPC_In_IguanaVengono promesse prestazioni incredibili proprio nella fase di sincronizzazione iniziale della blockchain, ci sono anche delle critiche, io non l'ho testato, vi segnalo solo che esiste.
)
