Bitcoin-IBD: Ein Community-Projekt sammelt Informationen über den Download der Blockchain
Die Raspberry-Pi-Mikrocomputer sind vielen in der Bitcoin-Szene heilig.
Um einen echten Full Node zu haben, muss man die gesamte Blockchain herunterladen. Weil das immer länger dauert, macht sich ein Teil der Bitcoin-Szene Sorgen, dass die Dezentralisierung des Netzwerks durch Full Nodes verloren geht. Eine Sammlung von Daten rund um den „Initialen Blockhain Download“ (IBD) soll nun Klarheit in die Diskussion bringen.
Für viele in der Bitcoin-Szene ist ein Full Node heilig. Nur er macht jemanden zu einem wirklichen Bitcoin-Nutzer, zu einem echten Knoten im Netzwerk, zu jemandem, der an der dezentralen Natur des Bitcoin-Netzwerks teilhat und diese stützt. Nur wer einen Full Node betreibt, ist in der Lage, ohne fremde Hilfe die Blockchain zu verifizieren. Um in diesen Genuss zu kommen, muss man jedoch etwas leisten: Man muss rund 180 Gigabyte an Daten herunterladen und verifizieren. Je nach Computer und Internetverbindung dauert das sechs Stunden bis drei Wochen.
Da die Blockchain immer weiter wächst, wird die Dauer, um einen Full Node zu synchronisieren, ebenfalls immer weiter wachsen. Eine Gruppe innerhalb der Bitcoin-Szene betrachtet dies schon lange mit einer großen Sorge. Auf der Webseite Bitcoin-IDB.com rufen sie nun User auf, ihre Erfahrungen bei der Synchronisierung eines Full Nodes mitzuteilen, um die Diskussion darüber auf eine vernünftige Datengrundlage zu stellen.
Auf der Webseite erklären sie, warum und weswegen, und liefern dabei auch eine eigene politische Theorie von Bitcoin: „Bitcoin ist nicht das, was ein Individuum, eine Firma oder ein Staat sagt. Es ist, was wir alle sagen; es ist ein Meme, ein Shelling-Point, ein Konsens der Mehrheit über Geld. Du trittst mit deiner Wahl dem Chor bei, wenn du die Blockchain herunterlädst und einen Full Node betreibst – mit dem Set an Regeln, das du selbst auswählst.“
Aus dieser Perspektive ist Bitcoin keine Demokratie, aber etwas ähnliches: Ein Konsens-Netzwerk. Die Full Nodes, die Transaktionen und Blöcke akzeptieren und weiterleiten – wenn sie den Regeln entsprechen – finden einen Konsens darüber, was Bitcoin ist. Diese Art der Entscheidungsfindung ist konservativer und träger als eine Demokratie; die Knoten einigen sich nicht auf dem Zustand, den jemand im speziellen will, sondern auf den sogenannten „Shelling-Points“, zu deutsch: Fokale Punkte. Dies sind Punkte, an denen sich Akteure treffen, wenn sie keine Möglichkeit haben, zu kommunizieren. Wenn man beispielsweise zusammen einen Ausflug macht, sich dabei aber verliert und kein Handy dabei hat, trifft man sich logischerweise am Auto wieder. Der Status Quo ist in einem solchen System oft der naheliegendste Fokale Punkt, weshalb es äußerst resistent gegen Änderungen ist.
Die Miner spielen bei dieser Entscheidungsfindung eine eher untergeordnete Rolle: Sie „erhalten nicht den Shelling-Point – sie folgen ihm lediglich, wohin er sich auch bewegt. Wenn ein Bitcoin Miner einen Block einreicht, der nicht gültig ist und von der wirtschaftlichen Mehrheit der Nodes abgelehnt wird, wird er nicht propagiert und sie haben Zeit und Ressourcen vergeudet. Um es einfach zu sagen: Miner sichern Transaktionen die an die Blockchain angehängt wurden, während Nodes entscheiden, welche Transaktionen an die Blockchain angehängt werden sollen.“ Wenn Bitcoin skalieren und dabei dezentral bleiben soll, braucht es viele Nodes. „Wenn in einigen Jahrzehnten vier Milliarden Menschen Bitcoin benutzen wollen, ist es absurd zu denken, dass die wichtigste Verteidigungslinie von Bitcoin nur aus 10.000 oder 100.000 Node-Betreibern bestehen wird. Millionen von Menschen sollten in der Lage sein, einen Node zu betreiben.“
Um dies zu erreichen, muss man an der schmerzhaftesten Bürde für Node-Betreiber ansetzen – dem initialen Blockchain-Download. Der Prozess, die gesamte Blockchain von den anderen Knoten im Netzwerk herunterzuladen, braucht derzeit mit einem Raspberry Pi bereits Wochen, da er nicht nur von der Internetverbindung abhängt, sondern auch von Rechner-Ressourcen wie Arbeitsspeicher oder der CPU. Es ist zu befürchten, dass Node-Betreiber schon vor-validierte Blockchains von anderen Quellen benutzt. Als Beispiel nennt die Webseite den Casa Node, eine Full-Node-Box für zuhause, die mit einer vorvalidierten Blockchain ausgeliefert wird. „Wenn Casa dies kommerzialisiert, wird die nächste Million von Node-Betreibern mit einer Blockchain und einem Regelwerk gefüttert, die von einem profitorientierten Team entschieden werden. Das ist ein ernsthaftes Problem.“
Die Bitcoin-Community, fordert die Webseite, muss dahin streben, dass Bitcoin mit dem „geringsten gemeinsamen Nenner“ benutzbar ist. Dies ist ein Gerät wie die oben genannten Raspberry Pies. „Mit der derzeitigen Rate des Blockchain-Wachstums, wird es für uns rasch unmöglich, dieses Ziel zu erreichen.“ Um die Diskussion über eine gesunde Größe der Blöcke – der atomaren Einheit von Blockchains – zu beginnen, fordert das Bitcoin-IBD-Projekt User auf, einen Node zu starten und Daten einzureichen, etwa über das System, auf dem der Node läuft, sowie die Dauer, bis verschiedene Schwellen erreicht sind. Etwas ironisch ist angesichts der politischen Forderung, mit dem Node über die Regeln mitzuentscheiden, die Instruktion, bei Bitcoin Core die Version 0.1.7 herunterzuladen. Wenn alle sowieso nur die Software eines Teams benutzen – dann wird der Full Node nicht zum Mittel der Mitentscheidung über Bitcoin, sondern zum Soldaten einer Gruppe von Entwicklern.
Das Bitcoin-IBD-Projekt könnte in Zusammenhang mit der Initiative von Luke Dashjr stehen, der die maximale Größe von Blöcken von bisher etwa 1,2 Megabyte auf 0,3 Megabyte senken möchte. Mit seinem Vorstoß, die Kapazität von Bitcoin durch eine Softfork zu reduzieren, hat Luke Dashjr für einige Aufregung gesorgt. Auf der einen Seite wird der Vorschlag weithin als lachhaft und unrealistisch abgetan, während er auf der anderen Seite seine Anhänger hat. Lightning, heißt es, macht es möglich, dass man die Anzahl der Blockchain-Transaktionen reduziert, ohne den Usern die Möglichkeit zu nehmen, Bitcoin immer mehr zu benutzen. Seine Weihe bekam Luke’s Vorschlag, als das renommierte Bitcoin Magazine die Idee in einem langen Artikel ernsthaft und relativ wohlwollend aufgriff. Je nachdem, wie viel Wert man auf die Teilnahme von Raspberry Pies als Full Nodes legt, könnte das Projekt Bitcoin-IBD der Diskussion um eine Senkung der maximalen Blockgröße Nahrung verschaffen – und wir hätten erneut eine Debatte um die Blocksize, diesmal jedoch nicht um ihre Erhöhung, sondern um ihre Senkung.
Zitat:
„… Miner sichern Transaktionen die an die Blockchain angehängt wurden, während Nodes entscheiden, welche Transaktionen an die Blockchain angehängt werden sollen.“
Da ist sie wieder, die künstliche Aufspaltung des Systems. Warum diese Trennung?
Bitcoin Whitepaper:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Ekelhaft, wie diese Raspi-Hippies versuchen das System neuzuinterpretieren und so viele aus Ahnungslosigkeit mitziehen.
„One-CPU-one-vote“.
Jaja…
Ich habe eine Raspi als pruned node aufen. Auf dem pc habe ich mir den Full Node eingerichtet und eine Kopie als pruned Version erstellt und auf den Raspi überspielt. Dieser Aufwand ist überschaubar. Tatsächlich hatte ich den Raspi zuvor wochenlang laufen und er wurde nicht fertig…
„Ekelhaft, wie diese Raspi-Hippies versuchen das System neuzuinterpretieren und so viele aus Ahnungslosigkeit mitziehen.“ Es gibt leider viel zu wenig Nodes, die das Netzwerk unterstützen. Nodes sind gut. Auch die auf Raspis! Ich habe Vertrauen, dass sich auch die richtigen Dinge so entwickeln werden, wie es für das Bitcoin Netzwerk auch gesund sein wird. So war es bisher immer und so wird es auch weiterhin sein.
Wozu brauchen wir eigentlich mehr Nodes und Nutzer ? Für die 7
Transaktionen/Sekunde reicht die derzeitige Konfiguration doch aus.
„If CASA rapidly commericialises this, the next million node operators
will be spoon-fed a blockchain and node ruleset decided by a
profit-motivated team. This is a serious problem.“
Das wäre natürlich ein Problem wenn jeder seinen eigenen node
nach seinen eigenen Regeln aufsetzt.
„…und wir hätten erneut eine Debatte um die Blocksize“
Dann kommt sicher bald die nächste Fork. Was passiert eigentlich mit
Lightning-Kanälen? Werden die dann auch verdoppelt? Sicher eine
gute Gelegenheit für Atomic Swaps. Ich glaube wir können da wieder
viel Spaß haben.
Vollständig validierende Netzwerkknoten sind elementar wichtig für das Bitcoin Netzwerk.
Punkt.
Ausserdem haben sie den Vorteil, das du dich damit wirklich auf niemanden, keinen einzigen Mittelsmann verlassen musst bei einer Transaktion.
–
Ein „simpler“ Fork und alle händy-wallets folgen ersteinmal der falschen Blockchain..und das sind leider 70-90% der heutigen Bitcoin-Nutzer.
–
Die bereits existierenden 180GB sind schon ein großes Problem, wenn man will, dass möglichst viele Menschen Full Nodes betreiben. Man hätte eigentlich schon vor langer Zeit die Blocksize noch deutlich weiter reduzieren müssen. Selbst, wenn man jetzt verkleinert wird es noch lange dauern, bis durch den Fortschritt der Hardware diese 180GB trivial werden.
Diese 180GB schließen z.B. jedes Telefon aus und auch jede Person in Gegenden, die schlechtes Internet haben. Man braucht außerdem zwingend eine (große) SSD, weil sonst auch ein schneller Desktop-PC einfach nur ewig braucht bei voller Last (Wochen).
Wenn man nicht daran glaubt, dass hohe Gebühren ein Problem sind, dann macht dieser Vorschlag zur Verkleinerung der Blocksize durchaus Sinn.
Core könnte auch mal über UTXO-Commitments nachdenken. Das könnte man per Softfork einbringen. Das würde den anfänglichen Download beschleunigen. Oder ist das nicht genug Validierung in den Augen von Core?
naja, jetzt mal nicht übertreiben, eine ssd ist NICHT zwingend notwendig, der flaschen-hals ist eher cpu …ein mittlerer heutiger computer braucht für den vollständigen blockchain dowload zwischen 12-96 Stunden, vorausgesetzt die internet anbindung ist nicht der limitierende Faktor –
trotzdem, das ist ziemlich lang und wird immer länger..
-Core macht zum beispiel solche sachen:
Complete hybrid full block SPV mode
– https://github.com/bitcoin/bitcoin/pull/9483
..eine fullNode die im hintergrund die gesamte blockchain runterläd aber sofort einsatzbereit ist als spv(simplified payment verification- Händy-ich-glaub-fast-alles-modus)
und die neue version 0.18 von core wird ein funktionierendes interface für hardwareWallets bringen, aber leider erstmal nur command line interface, also keine graphische oberfläche.
–
Das Thema ist wichtig, danke Christoph für den Artikel.
Der Widerspruch liegt doch hier:
Weshalb sollen VIELE Nutzer die Bereitschaft oder den Wunsch haben einen full-node
auf kleinen Geräten wie Telefon oder RasPi oder in Gegenden mit schlechter
Internetanbietung zu betreiben wenn es die geringe Blockgröße ohnehin nur erlaubt
WENIGE Transaktionen zu verarbeiten ?
Wenn die Blockchain zu groß wird sollte man dazu Forschung betreiben sie zu verkleinern.
Man könnte Meilensteine einführen. Alles bis Block sowieso als akzeptiert voraussetzen und nur neueres herunterladen.
Grins Cutthroughs weiterentwickeln und vielleicht übernehmen. Sachen herauszurechnen macht sie Größe Handhabbar.
Lightning fördern um es für alle zum benutzbaren Standard zu machen.
Es ist schön zu sehen dass da Problem erkannt wurde.
Ob kleinere Blöcke die Lösung sind, glaube ich nicht.
Ach Christoph, da ich gerade gut drauf bin, noch ein Post zu Monero (auch wenn der „werbetechnisch“ wie du es genannt hast kaum Sinn ergibt, da der Beitrag alt ist), aber er ist in meinen Augen relevant.
„Nodes“ sind keinerlei relevantes Kriterium einer Blockchain, es sei denn man bezieht sich auf die stakenden in meinen Augen keinerlei sicheren PoS Algorithmen, wo jeder Node seinen Stake irgendwie setzen muss oder auch nicht. Für Bitcoin und ähnliche Blockchains kann der Node-Count keinerlei relevante Größe darstellen, da er im Gegensatz zum PoW sehr einfach zu fälschen ist. Der Vorschlag, „Nodes“ irgendwie in eine Konsensentscheidung einzubeziehen ist tatsächlich absurd, es sei denn man koppelt es an zusätzliche Faktoren wie „getätigte Transaktionen“, „bezahlte Fees“, „Stake“ usw. aber dann sind wir wieder bei einem zentralen System.
Aber zum Blockchain Sync…
Man kennt Pruning von Ethereum und ohne das würde es wohl keine 100 Nodes mehr geben, da sie 2TB an Speicher bräuchten. Das Problem an Pruning ist immer, man verliert Daten über den Zustand der Chain zu einem bestimmten Zeitpunkt und unter Umständen deren Validierungskriterien. Wenn man einen Ethereum Node starten will, muss man durchaus diese 2TB herunterladen, validieren, was auf einem VPS mittlerweile eher unmöglich ist und man speichert dann immer nur den Chainstate ab, der zu einem gewissen Zeitpunkt gültig war / ist.
Bei Bitcoin kann man nach der Validierung fast alles ausser den UTXO löschen und seinen Semi-Full Node trotzdem betreiben, aber dieser ist tatsächlich nur ein Schmarotzer im Netzwerk, da er nur neue Blöcke zu sich synct, aber nichts mehr weiterreichen kann.
Bei Monero hat man Pruning jetzt so gelöst, dass es standardmäßig deaktiviert ist, man kann es aber aktivieren. Dabei werden Daten, die der Node für die Verifizierung neuer TX nicht benötigt gelöscht und Key-Images (bei Bitcoin UTXO) behalten. Die Standardeinstellung dafür ist, dass ca. 30 Tage der letzten Transaktionen trotzdem vollständig vorgehalten werden (da diese über 99% der Syncs ausmachen) und zusätzlich 1/8 randomisiert der gesamten Blockchain, um neuen Nodes auch beim initialen Sync zu helfen. Wenn diese ihre 32-64 standardmäßigen Connections im Monero Netzwerk haben, sollte die Möglichkeit groß genug sein, dass auch pruned Nodes zum Sync beitragen. Diese Einstellungen kann man je nach eigener Speicherkapazität/Bandbreite oder Egoismus verändern, aber per default hilft selbst ein Pruning Node dem Netzwerk. Leider ist das Pruning Feature etwas verzögert worden durch den vorgezogenen PoW Hard-Fork… Aber in voraussichtlich 2 Monaten (ohne erneuten Hard Fork) kann man wieder einen Monero „Full“ Node (mit Standard Pruning) auf einem 25 GB VPS laufen lassen, mit Full Pruning wahrscheinlich unter 20GB aber man muss sich dann eben bewusst sein, dass man damit dem Netzwerk eher schadet als nützt, wenn man die relevanten Daten direkt nach dem Eigensync löscht.
Den Sync beschleunigt diese Lösung leider auch nicht, aber vielleicht findet sich irgendwann ein Konsens zu regelmäßigen „States“, die das Netzwerk dann über etliche Transaktionen „verifiziert“ und diese dann wie bei IOTA durch den einen Godlike Coo unveränderbar werden 😉
Es gibt dazu viele Überlegungen, aber noch ist keine so sicher wie einige Blöcke PoW bei Bitcoin und wir werden wohl noch einige Jahre auf mögliche sichere Alternativen warten müssen. Der Sync würde dadurch jedenfalls massiv beschleunigt werden, denn man hätte einen sicheren „State“, einzelne Transaktionsdaten zur tatsächlichen Verifizierung neuer könnte man von seinen Peers weiterhin anfordern (oder eben im Hintergrund die ganze History syncen).
> Man kennt Pruning von Ethereum und ohne das würde es wohl keine 100 Nodes mehr geben, da sie 2TB an Speicher bräuchten. Das Problem an Pruning ist immer, man verliert Daten über den Zustand der Chain zu einem bestimmten Zeitpunkt und unter Umständen deren Validierungskriterien. Wenn man einen Ethereum Node starten will, muss man durchaus diese 2TB herunterladen, validieren, was auf einem VPS mittlerweile eher unmöglich ist und man speichert dann immer nur den Chainstate ab, der zu einem gewissen Zeitpunkt gültig war / ist.
Besser du informierst dich darüber. Diese Aussage ist durch und durch falsch. Gerade Afri hat sich ständig mit dieser Missinformation beschäftigt. Die Ethereum-Blockchain ist 140 Gigabyte groß. Was gepruned wird sind die Zwischenstates, die auch bei allen anderen Kryptowährungen nicht aufgehoben werden und die man nicht braucht, um alles, was auf der Blockchain geschieht, zu validieren. Da Ethereum so komplex ist (Smart Contracts etc.) gibt es einen Node, der die vollen 2 TB aller Zwischenstates sammelt, weil es sehr aufwändig ist, ohne diese jede historische Statusänderung aller Smart Contracts zu rekonstruieren.
Ach ja: Monero hat ein ähnliches Problem, weil die Transaktionen mit RingCT sehr viel aufwändiger zu verifizieren sind. wie bei Ethereum ist die Blockchain nicht so groß, aber der Aufwand, sie zu validieren, ist schon jetzt enorm. Und das, wo Monero noch kaum benutzt wird.
Ethereum synchronisiert standardmäßig die Zwischenstates eben nicht, aber das wäre eigentlich notwendig, um die Integrität der Chain zu verifizieren. Man kann natürlich argumentieren, dass wenn alle Nodes den gleichen State haben, wird er schon richtig sein… Trotzdem hat man es selbst nicht verifiziert. Übrigens ist das ganze Pruning ganz gut gegen Chain Analysen, bekanntlich hat Ripple ja um die 30 Tausend Blöcke „verloren“ und eigentlich kann kein Mensch sagen, wie viele XRP im Umlauf sind. Aber eh egal, das ist auch keine Kryptowährung und selbst wenn das Protokoll für manche Anwendungen sinnvoll sein könnte, braucht die Token selber niemand.
„Natürlich“ braucht man für die Verifizierung von Ring Transaktionen mit 11 potenziellen Zeichnern länger als für einen konkreten Zeichner. Aber keine Sorge, auch das wird nicht unter den Teppich gekehrt und ständig optimiert, wenn möglich und man hat es hinbekommen, nach den 85% mit der Bulletproof Einführung wieder 60% der restlichen 15% einzusparen, also werden nur noch ca. 8% der ursprünglichen Zeit für die Verifikation benötigt: https://www.getmonero.org/2019/02/01/pruning.html
Ich hab auch die Community gefragt, noch steht die Antwort aus: https://www.reddit.com/r/Monero/comments/avbz69/what_is_the_verification_time_of_monero/
Ich bin mir ziemlich sicher, das bekommt man bei Monero noch so optimiert, dass es schneller ist als bei Bitcoin, denn da hat sich seit Jahren auf Protokollebene nichts bewegt und es ist auch kein Fokus, denn Scaling On-Chain ist ja vom Tisch, neue Features im Protokoll wohl ebenso.
Der initiale Sync ist die Crux und vielleicht sind irgendwann Ethereum-ähnliche „States“ tatsächlich eine Lösung für den ersten Sync eines „Pseudo-Full“ Nodes (der dann mit der Zeit zum echten Full Node werden kann falls gewollt), aber damit habe ich mich noch nicht eingehend befasst. Im initialen Sync von Monero muss man bisher leider eben auch die unsäglich großen RingCT Transaktionen, die bis zur Bulletproof Einführung genutzt wurden, verifizieren deren Signaturschema man nicht mehr ändern kann und das dauert neben dem Download/Sync eben auch mehr als 10x so lange wie für aktuelle Transaktionen. Wie gesagt, vielleicht irgendwann über ein sinnvolles Stating (welches trustless ist) überbrückbar…
Solche technischen Auseinandersetzungen in der Kommentarspalte würde ich mir als Stammleser mehr wünschen, gefühlt war das vor 2-3 Jahren als wir hauptsächlich um die Bitcoin Blocksize debattiert haben viel mehr und kontroverser 😉
Ein normaler Ethereum Node hat die gesamte Blockchain, und synchronisiert alle Zwischenstates mit, speichert sie aber nicht. Im Endeffekt macht ein Bitcoin Node das nicht anders. Bei Ethereum dauert aber auch dieser Sync recht lange, eben weil die Smart Contracts sehr viel aufwändiger sind. Leider wird die Blockchain nur in Größe angegeben (140 Gigabyte), weshalb sie kleiner als Bitcoin wirkt, aber theoretisch könnte man sowohl ETH als auch BTC in Gas angeben. Ich denke, dann wäre ETH viel größer.
Und ja, die Komplexität von Ethereum ist gut für die Privacy. Sobald die Full Archival Chain so groß ist, dass keiner sie speichern kann, wird es nicht mehr möglich sein, Massenüberwachung von Smart Contract Operationen zu betreiben.
> Solche technischen Auseinandersetzungen in der Kommentarspalte würde ich mir als Stammleser mehr wünschen, gefühlt war das vor 2-3 Jahren als wir hauptsächlich um die Bitcoin Blocksize debattiert haben viel mehr und kontroverser
Heute wurde die technische Diskussion leider „geklärt“, und alles, was Core sagt, ist per definition richtig. Da gibt es nicht mehr viel Diskussionsbedarf.
Hmm… Christoph, hast Du Deiner ersten Antwort nicht komplett widersprochen? Ich bin mir tatsächlich nicht im Klaren, ob ein Ethereum „Full“ Node die gesamten 2TB laden und verifizieren muss oder ob der aktuelle Chain State ausreicht. Tut mir Leid, dafür bin ich bei Ethereum zu wenig involviert, da mir das Projekt seit seinen Anfängen zu suspekt war, auch wenn ich es mittlerweile zumindest als eines der „nicht-Scams“ sehe und Vitalik, Vlad und die Entwickler darum durchaus schätze.
„Chain states“ für den initialen Sync halte ich persönlich für machbar
Du unterschätzt die Möglichkeiten der „5-Eyes“ Geheimdienste, die archivieren wahrscheinlich ALLES, filtern (bzw. deduplizieren) würde ich an deren stelle tatsächlich nur Content, den sie schon haben… Bei unseren Geheimdiensten habe ich da nicht soooo große Sorgen, obwohl beim BSI tatsächlich sehr fähige Leute sitzen und wahrscheinlich auch von den Geheimdiensten „befördert“ werden. Das ist die Massenüberwachung und selbst eine Blockchain, die z.B. 2 PetaByte umfasst zu speichern und verarbeiten dürfte kein großes Thema sein. Das schaffen nicht nur regierungsnahe Behörden, sondern wahrscheinlich die Konzerne wie Google, Amazon, Alibaba besser.
Diese „Obfuscation“ hilft meiner Meinung nach nur gegen Amateure der Chain-Analyse wie Dich und mich. Selbst Vitalik sieht ein, dass Privatsphäre doch mehr Stellenwert hätte bekommen sollen als sie es heute hat: https://twitter.com/VitalikButerin/status/1000869998385074176
Btw. entweder ist Deine Kommentarfunktion irgendwie broken oder verträgt sich nicht (mehr) mit meinen Browsersettings. Dass Du meine Kommentare immer manuell freischalten musstest, bin ich gewohnt, aber mittlerweile muss ich selbst meinen Namen etc. bei jedem Kommentar neu eingeben…
Hm, seltsam. Auf die Kommentareinstellungen habe ich leider keinen Einfluss.
Ich versuche mal, zu erklären, wie ein Ethereum-Sync im Vergleich zu einem Bitcoin-Sync aus meiner Wahrnehmung abläuft: Sowohl bei Bitcoin als auch bei Ethereum wird die Chain geladen, die Transaktionen validiert, und aus diesen ein State aufgebaut. Der State wird fortlaufend aufgebaut, die alten States werden weggeworfen. Das ist der normale Sync. Bei Ethereum gibt es aber einen Full Archival Sync, der jeden Zwischenstate aufbewahrt. Sinnvoll ist das, weil man so die Historie von Smart Contracts rekonstruieren kann, ohne dass man diese Stück für Stück selbst erneut ausrechnet, was sowieso schon kompliziert ist, aber beinah unmöglich wird, wenn etwa ein Smart Contract mit einem anderen Smart Contract interagiert.
Wenn du in einem Bitcoin-Node eine neue Adresse einspielst, macht er einen kleinen Resync, was einige Minuten dauert, um die vergangenen States dieser Adresse festzustellen. Um das einfacher zu machen, kann man bei Bitcoin einen txindex mitsynchronisieren. Etwas ähnliches macht ein Electrum Full Node (wobei ich da nicht weiß, ob er nicht gleich alle Zustände aufhebt). Bei Ethereum kann man auch einen txindex mitsynchronisieren, ist aber technisch noch längst nicht so ausgereift.
Ein „Full Archival Node“ ist bei Bitcoin an sich nicht notwendig (auch wenn man eventuell sagen könnte, dass Electrum-Server oder Blockexplorer das haben), und er wäre auch wesentlich kleiner als bei Ethereum, weil hier nur Transaktionsdaten ausgewertet werden, während es bei Ethereum um die Operationen und Ergebnisse von Smart Contracts geht.