Blockchain explorer (Hilfe)

marian7 · 2. November 2021 um 10:36

Aktuell beschäftige ich mich viel mit Blockchain explorer.
Ich selber habe aktuell einen Electrum server in Rust (https://github.com/romanz/electrs) am laufen zusammen mit einem BTC RPC Explorer (https://github.com/janoside/btc-rpc-explorer). Beides an sich funktioniert auch super zusammen, doch leider bietet der BTC RPC Explorer nicht die funktion an, welche ich haben will. Um es genauer zu verdeutlichen, ich will anhand vom pubkey oder privkeys die wallets sehen. Und ich will sehen, wieviel Guthaben eine spezifische wallet hat.
Das mit dem Guthaben einer Wallet geht zwar mit dem BTC RPC Explorer, jedoch geht es nicht automatisiert per API.
Aus dem Grund hab ich an Esplora gedacht (https://github.com/Blockstream/esplora), jedoch bereitet es mir derzeit noch Probleme mit dem Setup, da der electrumserver sehr speicherintensiv ist.

Vielleicht hat jemand von euch eine Ahnung oder kann eine alternative anbieten. Blockchain.info/.com ist leider keine option, da ich es von anfang an ohne 3rd Party API machen will, da ich später mit viel Datenmengen rechne.

VIP · 2. November 2021 um 16:31

Ich denke, da kommt es ausschließlich auf die Konfiguration der Server-Hardware an! Benutzt du einen Bare-Metal Server @home oder einen gemieteten Server (VPS oder Dedi) aus dem Internet?
Alleine schon, um den Electrum-Server vernünftig betreiben zu können, sollte eine Minimum-Konfiguration von:

CPU: Intel Xeon E3-1230v6 - 4 c / 8 t - 3.5 GHz / 3.9 GHz (oder vergleichbar)
RAM: Ab 16 GB
Storage: NVMe, SATA

vorliegen! Online rät man von VPS-Systemen eher ab und tendiert zu dedizierten Servern. Wie du ja schon selber bemerkt hattest, arbeitet der Electrum-Server schon alleine sehr ressourcen-intensiv. Die Alternativen zu Esplora bzw. Esplora selber, brauchen aber auch selber genügend Performance. Ich denke, ohne ein Performance-Upgrade (oder Server-Wechsel) wirst du somit immer deine Probleme behalten…

marian7 · 2. November 2021 um 16:54

Das Performance upgrade ist nicht direkt passiert, aber im Grunde ja. Der limitierende Faktor bei dem alten Server ist der Speicher gewesen. Aus dem Grund hab ich jetzt nochmal einen Server geholt mit der gleiche konfiguration, allerdings mehr Speicher.

Edit: Beide Server sind dedicated Server!

Was gibt es den für welche? Ich finde die Dokumentation von esplora Katastrophal…
Den Rust server hab ich noch zum laufen gebracht, den esplora braucht (der Speicherintensiv ist und ich rede nicht von dem Standart electrs Server, der immernoch läuft), aber esplora mit dem blockstream electrs (https://github.com/Blockstream/electrs), dafür hab ich noch keine richtige option gefunden. Vielleicht war mein Fehler auch, dass ich esplora auf einem externen Server laufen lassen wollte.

VIP · 2. November 2021 um 17:06

Wäre hier zum Beispiel nicht „mempool“ eine alternative Lösung?? Siehe einmal:

https://github.com/mempool/mempool

marian7 · 2. November 2021 um 17:14

Ja, das sieht nach einer guten alternative aus!
Es sieht sogar so aus, als hätte das Teil das gleiche api System (also die Endpoints) wie esplora.

Ich berichte dann mal, sobald das Teil steht und vielleicht mach ich dann noch esplora fertig.
Danke erstmal

marian7 · 3. November 2021 um 13:20

Ich hab das Teil jetzt zum laufen gebracht. Die Nacht über musste der NODE sich syncen. Das einzig komische derzeit ist, dass ich nur sehen kann, wieviel Guthaben die Adresse hat, aber nicht die ein und ausgänge. Jetzt setze ich noch esplora auf und schaue mir an, wie das funktioniert. Sobald alles läuft, berichte ich dann wieder

marian7 · 3. November 2021 um 17:07

Ich kann schonmal sagen, dass das elects von blockstream weitaus mehr „rumzickt“, als man erwarten könnte. Wenn es einmal gestoppt ist, braucht es eine halbe Ewigkeit, bis es wieder weitergeht. Man kann den Prozess nicht einfach so abbrechen…
Ich schaue dann mal, dass sich das Teil völlig synchronisiert hat mit der Blockchain. Bedenkt, beim starten von electrs (blockstream) braucht ihr mehr als 500gb platz. Leider hat sich bei mir der sync bei 469G abgebrochen, weshalb ich gerade auf Fehlersuche bin. Ich berichte euch weiter, wenn es was neues gibt. Ich hoffe aber der nächste Bereicht wird sein, dass es läuft…

VIP · 3. November 2021 um 18:46

Was für ne Pladde hast du da drin? Wenn es eine 500er ist, wäre das definitiv zu knapp bei einem Partitionsschema mit RAMDisk, System und vor allem SWAP.
Wenn beim Sync ein Schatten-Image erzeugt wird, welches nicht in die SWAP auslagert, sollte es auch knallen - wie gesagt, bei einer 500er Platte bzw. Partition

Naja…die brauchen halt alle ohne Ende Ressourcen! Anscheinend sind selbst für „elects“ zuwenige vorhanden, was man mit dem verzögerten Prozess-Abbruch belegen könnte! Du kannst den Prozess erst riguros killen, wenn alles rückgespeichert ist, um Datenverluste so gering, als möglich zu halten. Wenn er aber nach dem Kill-Befehl noch rechnen muß, um Abzuschließen, kommt er ja schon allgemein nicht hinterher!!

marian7 · 3. November 2021 um 20:02

Zuerst kamm der fehler, dass eine blk0xxxx.dat nicht eingelesen werden konnte, weil zu viele Zugriffe darauf stattfinden. Dann hab ich eine Minute gewartet und danach flogen mir irgendwelche Peer Fehler um die Ohren. Ich hab dann den Fehler gemacht, dass ich den bitcoind Server gestoppt habe… Der muss jetzt erstmal wieder alles einlesen, daher wird es damit wohl erst morgen weitergehen.

Die Platten sind 2x2tb zu einer 4tb Platte gemacht.
/dev/md2 3.6T 910G 2.5T 27% /

Ich weiß nicht, was mit dem Teil los ist, aber ich werde morgen weiterberichten. Zum aktuellen Zeitpunkt kann ich nur sagen, das mempool lief, mit der ausnahme, dass mir nur die Balance angezgit wurde, welche die Wallet gesamt hat. Es wurde mir nicht angezeigt, wieviel gesendet oder empfangen wurde, was mich allerdings (erstmal) nicht weiter stört .

marian7 · 4. November 2021 um 10:38

Nachdem die Bitcoinnode wieder vollständig über Nacht sich synchronisert hat, habe ich dann wieder electrs von blockstream syncen lassen. Am lief das Teil auch super, bis es zu diesem Fehler kam:

WARN - failed to export stats: failed to read stats
thread 'blkfiles_reader' panicked at 'failed to read "/FOLDERPATH/.bitcoin/blocks/blk02552.dat": Os { code: 24, kind: Other, message: "Too many open files" }', src/new_index/fetch.rs:160:41
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted

und damit ist es dann abgestürtzt nach knapp 2stunden und einer angelegten Datenbank von 459G…

Nach einem neustart, ohne die Datenbank zu löschen, kommt jetzt der Fehler:

DEBUG - Server listening on 127.0.0.1:4225
DEBUG - Running accept thread
INFO - NetworkInfo { version: 210100, subversion: "/Satoshi:0.21.1/", relayfee: 0.00001 }
INFO - BlockchainInfo { chain: "main", blocks: 708160, headers: 708160, bestblockhash: "00000000000000000009c8fcdded7291d50c72bbd3795fdc59f050ab864f1eb4", pruned: false, verificationprogress: 0.9999967, initialblockdownload: Some(false) }
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/txstore"
WARN - failed to export stats: failed to read stats
WARN - failed to export stats: failed to read stats
DEBUG - 0 blocks were added
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/history"
DEBUG - 0 blocks were indexed
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/cache"
ERROR - server failed: Error: failed to clone TcpStream { addr: 127.0.0.1:60828, peer: 127.0.0.1:8332, fd: 811 }

Ich warte jetzt mal bisschen ab und starte dann den Prozess nochmal. Ich versuche das Teil zum laufen zu bringen, ohne das ich die Datenbank lösche.

Nach etwas warten tat sich dann folgendes:

DEBUG - Server listening on 127.0.0.1:4225
DEBUG - Running accept thread
INFO - NetworkInfo { version: 210100, subversion: "/Satoshi:0.21.1/", relayfee: 0.00001 }
INFO - BlockchainInfo { chain: "main", blocks: 708160, headers: 708160, bestblockhash: "00000000000000000009c8fcdded7291d50c72bbd3795fdc59f050ab864f1eb4", pruned: false, verificationprogress: 0.99999523, initialblockdownload: Some(false) }
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/txstore"
DEBUG - 0 blocks were added
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/history"
DEBUG - 0 blocks were indexed
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/cache"
ERROR - server failed: Error: failed to clone TcpStream { addr: 127.0.0.1:60844, peer: 127.0.0.1:8332, fd: 820 }
Caused by: Too many open files (os error 24)

Den TcpStream kann der aber weiterhin nicht einlesen…
Drückt mir die Daumen, ich versuche es mal weiterhin

marian7 · 4. November 2021 um 10:58

Nach etwas rumprobieren bin ich auf die Lösung gestoßen:

Öffnet die
/etc/security/limits.conf

Ganz nach unten Scrollen und folgendes einfügen:

# End of file
USERNAME          soft    memlock         unlimited
USERNAME          hard    memlock         unlimited
USERNAME          soft    nofile          64000
USERNAME          hard    nofile          64000

Ihr müsst euch mit dem User ausloggen und dann wieder einloggen, damit die Limitswerte übernommen werden!

Anschließend könnt ihr den Server neustarten:

DEBUG - Server listening on 127.0.0.1:4225
DEBUG - Running accept thread
INFO - NetworkInfo { version: 210100, subversion: "/Satoshi:0.21.1/", relayfee: 0.00001 }
INFO - BlockchainInfo { chain: "main", blocks: 708163, headers: 708163, bestblockhash: "000000000000000000066dac5a6a1ab7e8e06de2030668322d5710a16c99fdcf", pruned: false, verificationprogress: 0.9999987, initialblockdownload: Some(false) }
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/txstore"
DEBUG - 679730 blocks were added
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/history"
DEBUG - 0 blocks were indexed
DEBUG - opening DB at "/FOLDERPATH/mainnet/newindex/cache"
DEBUG - downloading all block headers up to 000000000000000000066dac5a6a1ab7e8e06de2030668322d5710a16c99fdcf
DEBUG - writing 0 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable

Das mit „writing 0 rows“ kommt dann eine ganze weile. Ich warte dann mal ab und berichte, wenn das alles läuft, oder es weiterhin zu Fehlern kommt…

marian7 · 4. November 2021 um 14:14

Weiter geht die wilde Fahrt… Nachdem nun der Fehler behoben war, ging es nach 15min mit „writing 0 rows…“ weiter:

DEBUG - writing 1068246 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1105287 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1028132 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 966059 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1034708 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1106248 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable

und nach einer weiteren Stunde kam ich dann zu diesem Punkt hier:

DEBUG - writing 1001301 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1084189 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1071794 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 953835 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 1088813 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - writing 346439 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - starting full compaction on RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }

Zu dem Zeitpunkt hat die Datenbank eine etwaige Größe von ca ~530GB erreicht.

Dann fing die „full compaction“ an… Das ganze hat dann auch ncohmal gute 2-3h eingenommen.

Thu Nov  4 13:43:35 CET 2021
784G    esplora_db/

Thu Nov  4 13:44:35 CET 2021
788G    esplora_db/

Thu Nov  4 13:45:35 CET 2021
793G    esplora_db/

Thu Nov  4 13:46:35 CET 2021
797G    esplora_db/

[.....]

Thu Nov  4 14:34:22 CET 2021
988G    esplora_db/

Thu Nov  4 14:35:23 CET 2021
992G    esplora_db/

Thu Nov  4 14:36:23 CET 2021
996G    esplora_db/

Thu Nov  4 14:37:23 CET 2021
1000G   esplora_db/

Thu Nov  4 14:38:24 CET 2021
1004G   esplora_db/

Thu Nov  4 14:39:24 CET 2021
1008G   esplora_db/

Thu Nov  4 14:40:25 CET 2021
1013G   esplora_db/

Thu Nov  4 14:41:25 CET 2021
502G    esplora_db/

Thu Nov  4 14:42:25 CET 2021
502G    esplora_db/

Thu Nov  4 14:43:25 CET 2021
502G    esplora_db/

Gegen Ende sah man dann den Sprung, als compaction dann fertig war.

Anschließend sag man nurnoch

DEBUG - writing 346439 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }, flush=Disable
DEBUG - starting full compaction on RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }
DEBUG - finished full compaction on RocksDB { path: "/FOLDERPATH/mainnet/newindex/txstore" }
DEBUG - indexing history from 708164 blocks using BlkFiles
DEBUG - listing block files at "/root/.bitcoin/blocks/blk*.dat"
DEBUG - writing 1780261 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable

und jetzt warte ich darauf, dass etwas passiert… Weil die Ports für die Kommunikation sind nicht freigegeben, sodass ich esplora mit electrs verbinden kann.

netstat -tulpen
tcp        0      0 127.0.0.1:4225          0.0.0.0:*               LISTEN      0          972274     27028/target/releas

marian7 · 4. November 2021 um 14:52

Weil nach 20min nichts passiert ist, hab ich das Teil nochmal neugestartet (,ohne die Datenbank zu löschen).

Aktuell sehe ich nur:

TRACE - skipping block 0000000000000e46cf867d566bcfc9483442f8fba314e512f0836fd4cfd8357a
TRACE - skipping block 00000000000004868c41aeda6933e5421ab05bd7361f306d400f16c8abaa1ca6
TRACE - skipping block 0000000000000681b858b51080af14739f21685070f72a183c66be3d9ca7dee8
TRACE - skipping block 000000000000072631fac7128b3757c0e5f2034ae2f1bc8afe745e65435a5cb6
TRACE - skipping block 0000000000000d9cdc606b11f297e446a436fb92f14b2128f452b5846d592b91
TRACE - fetched 5607 blocks
TRACE - fetched 5679 blocks
TRACE - fetched 6392 blocks
TRACE - reading "/root/.bitcoin/blocks/blk00006.dat"
TRACE - parsing 134201847 bytes
TRACE - reading "/root/.bitcoin/blocks/blk00007.dat"
TRACE - parsing 134214381 bytes
TRACE - reading "/root/.bitcoin/blocks/blk00008.dat"

marian7 · 4. November 2021 um 17:06

Kleines Update nach 2h

DEBUG - writing 1964371 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable
TRACE - parsing 134169275 bytes
TRACE - reading "/root/.bitcoin/blocks/blk00021.dat"
TRACE - fetched 1567 blocks
DEBUG - writing 1961327 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable
TRACE - parsing 134195048 bytes
TRACE - reading "/root/.bitcoin/blocks/blk00022.dat"
TRACE - fetched 1536 blocks
DEBUG - writing 1956973 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable
TRACE - parsing 134196378 bytes
TRACE - reading "/root/.bitcoin/blocks/blk00023.dat"
TRACE - fetched 1191 blocks

edit:
Ich behaupte mal frech, die HDD gibt den Geist auf…

VIP · 4. November 2021 um 21:08

Kann es denn sein, bezüglich dem TCP-Stream, dass der Port 60844 / 8332 vielleicht geblockt bzw. nicht weitergeleitet wird? Hinsichtlich Port-Forwarding?
Der Port 4225 scheint ja korrekt offen und weitergeleitet zu sein.

Caused by: Too many open files (os error 24)

Da staut sich ja was an, was dann irgendwann zum overflow führt…?
Vielleicht hilfts ja, wenn du über Github beim Entwickler mal nen Issue aufmachst?!

marian7 · 5. November 2021 um 11:22

Nach dem ich die limits erhöht habe, ging das einlesen weiter…

marian7 · 5. November 2021 um 11:23

Kurzes statusupdate, ich befürchte die HDDs haben sich verabschiedet…
Das ist der aktuelle stand der Dinge.

> DEBUG - writing 2023960 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable
> TRACE - parsing 133947501 bytes
> TRACE - reading "/root/.bitcoin/blocks/blk00151.dat"
> TRACE - fetched 555 blocks
> DEBUG - writing 2027378 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable
> TRACE - parsing 134152599 bytes
> TRACE - reading "/root/.bitcoin/blocks/blk00152.dat"
> TRACE - fetched 647 blocks
> DEBUG - writing 2041359 rows to RocksDB { path: "/FOLDERPATH/mainnet/newindex/history" }, flush=Disable
> TRACE - parsing 134123989 bytes
> TRACE - reading "/root/.bitcoin/blocks/blk00153.dat"
> TRACE - fetched 622 blocks

VIP · 5. November 2021 um 15:01

Du sagtest ja oben, dass du 2x 2TB zu einer 4TB Platte zusammengefügt hast. OK, das wäre ja immer noch ein RAID 0 - Verbund. Grundsätzlich ne gute Idee, weil es die Lese / Schreibzugriffe beschleunigt und den gesamten Speicherplatz zur Verfügung hält. Die Datenblöcke werden quasi abwechselnd auf die beiden HDDs verteilt. Wenn du jetzt sagst, dass du das Gefühl hast, dass die Platten sich verabschieden, mag dir das so vorkommen, muß aber nicht den Tatsachen entsprechen!
Du weißt ja selber, es gibt drei verschiedene Arten, wie man ein RAID einrichten kann und die Möglichkeiten sind nunmal von der vorhandenen Hardware abhängig…

Software RAID
Host RAID
Hardware RAID (Controller)

Ich stelle mir nur die Frage, welche RAID-Konfiguration du genutzt hattest? Wenn du dort echte Server-Hardware stehen hast, sollte es ja eigentlich ein Hardware-RAID sein?

Ein reines Software RAID ist für solch ein Projekt die denkbar ungeeignetste Konfiguration, da

kein Caching möglich
Überlastung des Gesamtsystem möglich, da nur die CPU die benötigten Berechnungen macht für die RAID-Verwaltung plus die eigentliche Token-Berechnungen etc.
Komplette Überlastung von CPU, RAM sowie des kompletten BUS-Systems inkl. SATA-Controller

Das angesprochene Host-RAID ist genauso ungeeignet für so rechenintensive Aufgaben, da

eigentlich kein echtes RAID, auch Fake-RAID genannt! Im Grunde ist dies nur ein Software-RAID, was an bestimmte Hardware gebunden ist
die CPU genau wie beim Software-RAID die komplette Arbeit übernimmt
im Endeffekt die gleichen Überlastungen auftreten, wie oben schon genannt!

Das erwähnte Hardware-RAID (über seperaten Marken RAID-Controller) wäre hier Standard, da

das Speicher-Subsystem des Controllers die vollst. Verwaltung inkl. Caching usw. übernimmt
das restliche System sich nur dann rein der Token-Berechnungen etc. widmen kann
es gute Gründe gibt, warum häufig Hardware-Host-Adapter (nicht Host-RAID) eingesetzt werden - Nur ein Hardware-RAID schützt ausreichend vor Hardware-Defekten.

Das wäre nämlich auch noch echt wichtig bei jeglichem RAID-Verbund, dass die verbauten Festplatten überhaupt für diese Belastungen ausgelegt sind. Mal als Beispiel bei WD wären das nur die „Red Edition“ bzw. die „Black Edition“! Bitte niemals normale Consumer-Platten, das geht unweigerlich in die Hose…!
Also nur HDDs, die vom jeweiligen Hersteller explizit für Hochverfügbarkeit in Storage-Systemen (SAN, NAS usw) zugelassen sind.
Das angezeigte Debugging ist ja nur ein Indiz, dass zuvor einiges schiefgelaufen ist, was nun versucht wird zu berichtigen! Warum…bleibt ja erstmal unklar?
Entweder geben die Platten wirklich langsam, aber sicher auf? Oder die ganzen Fehler entstehen durch die hardware-seitige Überlastung (Software / Host - RAID)?
Da du ja irgendwo anfangen musst, die Fehler zu analysieren, würde ich pers. bei der Hardware anfangen z.B. mit ner UBCD o. ä. um dann die HDDs im Low-Level, Sektor für Sektor zu überprüfen!
Danach unbedingt den RAM komplett testen mit einem Low-Level Tool wie z.B. ViVard. Da ein Low-Level RAM-Test nunmal zufallsabhängig arbeitet, kann dieser mal gerne 24-48 Std. dauern, bis überhaupt Fehler angezeigt werden - oder der Test wird gestartet und schon innerhalb der ersten Minute färbt sich der Bildschirm knallrot

marian7 · 5. November 2021 um 16:23

Ich hab mich entschieden, dass ich das esplora Projekt nicht mehr weiter verfolge… Mempool tut was ich brauche und das reicht mir! Das Teil läuft performant und bringt, bis auf paar kleinere Anfangsschwierigkeiten, alles mir, was ich brauche. Sollte ich mich dazu entscheiden, dass doch noch zu machen, werde ich den Thread hier updaten.

marian7 · 10. November 2021 um 08:49

Weiter ging/geht die Reise. Diesmal ohne Raid oder sonstiges. Über Nacht hat die Blockchain gesynct und jetzt läuft der sync für Blockstream-electrs. Warten wir mal was weiter passiert

Edit: 2x2tb Festplatten
Die zweite ist gemountet und dort wird auch das blockstream-electrs geladen