Accelerant la sincronització inicial de Bitcoin amb el conjunt UTXO
Tots ens hem trobat algun cop que el nostre node de Bitcoin deixa de funcionar, la raspberry falla, el disc mor, o simplement necessitem el disc per altres propòsits i acabem quedant-nos sense node de Bitcoin. En el futur quan volem tornar a muntar un node ens trobem que hem de tornar a passar pel procés de IBD (initial block download) per sincronitzar la cadena de blocs. Un procés pesat, que pot durar en molts casos dies i que ens impedeix utilitzar el node i connectar-hi les bitlleteres fins que el node estigui sincronitzat del tot.
En aquest post veurem com podem avançar-nos a aquesta situació i com podem prendre mesures per poder, en un futur, sincronitzar els nostres nodes ràpidament.
⚠️ CLICKBAIT WARNING El node no se sincronitza més ràpidament, però sí que et permet utilitzar-lo quasi a l’instant usant sincronització en segon pla!
Primeres Idees
Hi ha algunes maneres d’accelerar el procés d’IBD sacrificant seguretat no verificant la cadena de blocs. Tot i que algunes no són recomanables, s’expliquen en aquest primer apartat.
Assume valid
El paràmetre assumevalid a Bitcoin Core permet especificar-li al node que fins a certa altura de bloc no vols que es verifiquin les transaccions i assumeix que són vàlides. Per tant, el procés es simplifica a només validar que els blocs estan construïts correctament. Utilitzar aquest paràmetre durant la sincronització inicial accelera moltíssim el procés perquè el principal factor que alenteix la sincronització és la verificació són els scripts.
Tot i això, amb assumevalid igualment necessitarem descarregar tota la cadena per poder utilitzar el node. Sí, anirà més ràpid, però la descàrrega l’hem de fer igualment fins a arribar a l’estat actual.
💡 Informació: Bitcoin Core té habilitat assumevalid per defecte a una altura de bloc prèvia a la release.
Copiar la cadena de blocs
Una altra manera d’accelerar el procés d’IBD és copiar els fitxers d’un node a l’altre. Específicament s’hauria de copiar els fitxers del directori blocks i chainstate.
Aquest procediment pot tenir alguns problemes. Per començar, descarregar els fitxers d’una font desconeguda no és recomanable. Si has de dur a terme aquest procediment, fes-ho des d’un node que tu controlis. També podrien haver-hi incompatibilitats entre versions del software del node en cas que la manera que creen i emmagatzemen aquests fitxers fos diferent.
Descartem aquesta opció perquè mantenir còpies redundants de la cadena de blocs sencera no és la manera òptima de fer-ho.
Com ho fem doncs? 🤔
Imaginem que poguéssim guardar un checkpoint que representés l’estat de la cadena a certa altura de bloc. Quina informació hauria de tenir aquest checkpoint? Per verificar transaccions i gastar bitcoins el que necessitem és conèixer les transaccions no gastades en el present. Qui manté un registre d’aquestes transaccions no gastades? –> L’UTXO set!
L’UTXO set és una base de dades que representa l’estat actual de les sortides de transacció no gastades (UTXO). Amb l’UTXO set podem verificar que una transacció és vàlida sense mirar la cadena, ja que les entrades d’aquestes han de gastar unspent transaction outputs (UTXOs) i crear-ne de nous. Amb paraules més simples, és un registre que diu a on són els bitcoins en aquest precís instant.
Com utilitzem l’UTXO set per sincronitzar el node
Si tenim l’estat actual de la cadena, és a dir, les monedes (UTXOs) que es poden gastar, podem fer i verificar transaccions sense problemes. Això funciona ja que TOTS els bitcoins que tenim disponibles per gastar estàn representats a l’UTXO set.
Si només necesitem l’UTXO set per fer i verificar transaccions, podem simplement carregar-lo en un punt molt recent, començar a utilitzar Bitcoin i, mentrestant, decarregar els blocs previs?
Sí! Els blocs previs es podran anar descarregant en segon pla sense influir en la capacitat de les wallets per mostrar el balanç i gastar fons.
💡 Informació! Aquest és el motiu pel qual els nodes “pruned” també poden verificar tota la informació, només necesiten l’UTXO set!
Carregar còpia de l’UTXO Set
Suposem que tenim un backup de l’UTXO set en un fitxer: utxo.dat. Aquest backup de l’UTXO set està fet en el bloc 840.000, per tant, quan l’importem, el nostre node s’haurà d’actualitzar a l’altura 840.000 casi a l’instant.
Per fer-ho podem utilitzar la comanda que introdueix Bitcoin Core v26.0 “loadtxoutset”.
Comencem des del principi. Iniciem el node de Bitcoin executant, com és habitual, el binari bitcoind. Veurem que al principi realitza una presincronització dels headers i després els sincronitza. Hem d’esperar que la sincronització dels headers finalitzi.
Un cop tenim el node ja corrent i sincronitzant podem importar l’UTXO set amb la instrucció bitcoin-cli -rpcclienttimout=0 loadtxoutset utxo.dat. On utxo.dat és el nostre backup de l’UTXO set. (💡Recomano col·locar el fitxer utxo.dat a dins el directori on estiguis guardant les dades del node, per defecte és ~\.bitcoin).
Abans de fer-ho és recomanable utilitzar bitcoin-cli setnetworkactive false. Aquesta instrucció millora el rendiment, ja que para les comunicacions de la xarxa p2p. S’ha de tornar a habilitar en acabar la càrrega. (Això és opcional, si no es fa, funcionarà igualment però amb pitjor rendiment)
⚠️ Alerta És important especificar -rpcclienttimout=0 per evitar que ens tanqui la comunicació per timeout, ja que el procés pot trigar uns minuts
És normal que la terminal quedi penjada sense actuar tal que:
Mentre la comanda sembla que queda penjada es pot veure en els logs del bitcoind com el node continua sincronitzant-se de manera normal i, eventualment, es poden observar logs on mostra que està carregant les coins de l’UTXO set.
Un cop acabat veurem que la comanda RPC confirma que hem importat les dades:
Si observem els logs de bitcoind, podrem veure com ha actualitzat el chainstate (l’estat de la cadena) al bloc 840.000:
2025-02-18T14:55:18Z UpdateTip: new best=000000000000085b8326215f4334716986036cd7f22b474b4bb1d30e44abc7c6 height=190942 version=0x00000001 log2_work=68.448132 tx=5332360 date='2012-07-27T01:22:01Z' progress=0.004564 cache=264.9MiB(2106915txo)
2025-02-18T14:55:18Z [snapshot] validated snapshot (0 MB)
2025-02-18T14:55:18Z [snapshot] successfully activated snapshot 0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5
2025-02-18T14:55:18Z [snapshot] (0 MB)
2025-02-18T14:55:18Z Opening LevelDB in /home/sliv3r/Escritorio/blockchain/chainstate
2025-02-18T14:55:18Z Opened LevelDB successfully
2025-02-18T14:55:18Z Using obfuscation key for /home/sliv3r/Escritorio/blockchain/chainstate: d06729b36c1332a2
2025-02-18T14:55:18Z [Chainstate [ibd] @ height 190942 (000000000000085b8326215f4334716986036cd7f22b474b4bb1d30e44abc7c6)] resized coinsdb cache to 0.4 MiB
2025-02-18T14:55:18Z [Chainstate [ibd] @ height 190942 (000000000000085b8326215f4334716986036cd7f22b474b4bb1d30e44abc7c6)] resized coinstip cache to 22.0 MiB
2025-02-18T14:55:18Z Cache size (277731616) exceeds total space (23068672)
2025-02-18T14:55:22Z Opening LevelDB in /home/sliv3r/Escritorio/blockchain/chainstate_snapshot
2025-02-18T14:55:22Z Opened LevelDB successfully
2025-02-18T14:55:22Z Using obfuscation key for /home/sliv3r/Escritorio/blockchain/chainstate_snapshot: ffaa87a9790b88bb
2025-02-18T14:55:22Z [Chainstate [snapshot] @ height 840000 (0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5)] resized coinsdb cache to 7.6 MiB
2025-02-18T14:55:22Z [Chainstate [snapshot] @ height 840000 (0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5)] resized coinstip cache to 418.0 MiB
I si executem la comanda bitcoin-cli getblockchaininfo podrem veure com efectivament tenim el node sincronitzat al bloc 840.000:
bitcoin-cli getblockchaininfo
{
"chain": "main",
"blocks": 840077,
"headers": 884327,
"bestblockhash": "000000000000000000018bd4948d21337c98ea27cd5586393a31c644ce9ab1ce",
"bits": "17034219",
"target": "0000000000000000000342190000000000000000000000000000000000000000",
"difficulty": 86388558925171.02,
"time": 1713621243,
"mediantime": 1713616671,
"verificationprogress": 0.8484856035034852,
"initialblockdownload": true,
"chainwork": "000000000000000000000000000000000000000075537cab1a1b8a216234e13a",
"size_on_disk": 3395515205,
"pruned": false,
"warnings": [
"This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
]
}
En cas d’haver desactivat la xarxa p2p torna a habilitar-la amb bitcoin-cli setnetworkactive true. Tornem a mirar els logs de bitcoind i veiem que ara està sincronitzant els blocs que hi ha entre el 840.000 i el tip de la cadena:
💡 S’anomena tip al bloc actual de la cadena, és a dir a l’últim bloc de la cadena amb més proof of work.
Un cop el node acaba de sincronitzar des del bloc 840.000 fins al tip actual, en aquest cas el bloc 884.365, podem veure com comença a sincronitzar el node des de 0. Es pot identificar fàcilment, ja que en els logs es marca com a background validation.
Fixant-nos en els logs anteriors podem veure que, tot i que està verificant blocs molt antics com el 210.000, quan apareix un bloc nou, el 884.366 en aquest cas, de seguida actualitza el tip de la seva cadena i posteriorment continua amb la verificació de blocs antics.
Com crear o aconseguir un backup de l’UTXO set?
La manera més fàcil d’aconseguir un backup de l’UTXO set és amb el magnet link:magnet:?xt=urn:btih:559bd78170502971e15e97d7572e4c824f033492&dn=utxo-880000.dat&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969.
⚠️ Alerta. Aquest magnet link és pel bloc 800.000
Com he dit prèviament s’ha d’evitar descarregar l’UTXO set de fons desconegudes (no et pots fiar de mi!), però bé, hi ha diferents mecanismes de verificar que la còpia que proporciona aquest magnet link és correcte:
Per començar és el link proporcionat en el PR Bitcoin Core que introdueix els paràmetres al codi.
Pots validar el hash de la còpia amb: shasum -a 256 utxo-880000.dat el resultat hauria de donar 43b3b1ad6e1005ffc0ff49514d0ffcc3e3ce671cc8d02da7fa7bac5405f89de4.
Com generem el nostre propi backup?
Per fer-ho necessitem un node ja sincronitzat a una altura de bloc superior a la del backup. En aquest cas superior al 880.000.
⚠️ Alerta El node no pot estar prunat a una altura inferior a la del bloc sobre el qual es fa el backup!
Utilitzant la instrucció bitcoin-cli -rpcclienttimeout=0 dumptxoutset utxo.dat rollback. Per defecte aquesta comanda farà un backup de l’UTXO set al directori ~\.bitcoin. Aquest procés pot tardar una miqueta, ja que el node es “desincronitza” fins a arribar al block de l’últim checkpoint vàlid.
Aquí es pot veure un vídeo de com es dessincronitza un node en fer aquest procés.
Altre cop es pot validar que el backup és el correcte amb el hash del fitxer:
shasum -a 256 utxo-880000.dat
43b3b1ad6e1005ffc0ff49514d0ffcc3e3ce671cc8d02da7fa7bac5405f89de4
Conclusions i precaucions
Amb aquest procés el node arriba a un estat on és usable per consultar el balanç i crear transaccions de manera molt més ràpida que no pas sincronitzant tota la cadena. En un portàtil normal, tot aquest procés no m’ha pres més de 2 hores que ja és un avanç mot gran respecte als dies que pot arribar a trigar una sincronització normal.
⚠️ Alerta És molt important no descarregar l’UTXO set d’una font desconeguda i amb la que no confiem. El perill és molt elevat, ja que una representació falsa de l’UTXO set pot fer-te creure que t’han pagat quan no és cert. Et poden enganyar i robar.
Bitcoin Core intenta prevenir això limitant la importació de l’UTXO set al un bloc definit en l’última release (el bloc 880.000 a data d’aquest post) i comprovant que l’UTXO set és el correcte i no ha estat manipulat. Saltar-se aquesta comprovació no és difícil i permet a usuaris més experimentats accelerar encara més aquest procés. En aquest post no s’explicarà com fer-ho per tal de no exposar als lectors a un possible atac.
⚠️ Alerta Quan es va escriure la 1a part del post el block de l’última release era el 840.000 i no el 880.000, per això la guia es fa sobre el 840.000
Apa! Gaudeix sincronitzant nodes a la velocitat de la llum!!
I RECORDA —> DON’T TRUST, VERIFY. IF YOU DON’T RUN YOUR OWN NODE YOU ARE NOT USING BITCOIN WITHOUT A “TRUSTED” MIDLEMAN
Fakta yang sering luput: UTXO set bukan sekadar istilah teknis, tapi penentu seberapa mulus node Bitcoin bisa disinkronkan. Di UNDITOTOSLOT, topik ini dibedah lewat sudut pandang yang sederhana namun tetap presisi.
Alih-alih membahasnya secara umum, artikel ini menyorot hubungan UTXO set, proses sinkronisasi node, dan dampaknya pada kecepatan pembacaan data. Pendekatan ini membantu Anda melihat kenapa satu detail kecil bisa mengubah hasil akhirnya.
Kalau ingin memahami alurnya tanpa kehilangan konteks, teruskan membaca sampai tuntas. Bersama UNDITOTOSLOT, Anda bisa menangkap inti pembahasan dan melihat bagaimana sinkronisasi node Bitcoin bekerja dari sisi yang lebih rapi.
