Mit full Nodes gegen Bitcoin-Zentralisierung

Dr. Philipp Giese

von Dr. Philipp Giese

Am · Lesezeit: 12 Minuten

Dr. Philipp Giese

Dr. Philipp Giese arbeitet als Chief Analyst für BTC-ECHO und ist auf die Bereiche Chartanalyse und Technologie spezialisiert. Der promovierte Physiker kann dabei auf jahrelange Berufserfahrung als technologischer Berater zurückgreifen. Zudem ist er zentraler Ansprechpartner im Discord-Channel von BTC-ECHO und pflegt als Speaker und Interviewer den Austausch mit Startups, Entwicklern und Visionären.

Teilen
Bitcoin Intermediary

Quelle: © BillionPhotos.com, Fotolia

BTC10,490.35 $ 0.18%

Dezentralisierung ist wahrscheinlich die wichtigste Eigenschaft des Bitcoin Netzwerks. Ohne Dezentralisierung würden viele der Bitcoin charakterisierenden Eigenschaften, wie beispielsweise die Vereinfachung von Transaktionen ohne Mittelsmann, kaum möglich sein. In diesem Artikel werden die Gründe für die rapide Abnahme an full Nodes untersucht und Ideen zur Umkehr dieses Trends vorgeschlagen.

Der Artikel wurde zuletzt aktualisiert am 26. Mai 2019 05:05 Uhr von Mark Preuss

ses Netzwerk garantiert Bitcoins Infrastruktur, indem viele Kopien der Blockchain an verschiedenen Orten gespeichert und mit neuen Blocks und Transaktionsdaten geupdatet werden.

Trotz dieser zentralen Rolle sinkt die Anzahl der Nodes seit Jahren, was zu einer Zentralisierung des Netzwerkes führt. Jameson Lopp hat seit einiger Zeit  über das Absterben der Nodes geschrieben und mit seiner Statoshi Software seine eigenen Nodes beobachten können. Dieses Wissen ermöglicht ihn, ein paar bisher wenig beachtete Punkte zu den aktuellen Skalierungs-Debatten beizusteuern.


In den Anfangstagen von Bitcoin konnte man im Blockchain-Netzwerk nur mittels full Nodes partizipieren. Mit den Jahren wurde ein fruchtbares Bitcoin-Ökosystem geschaffen und nun gibt es viele Optionen für Wallets. Die meisten Wallets heutzutage sind entweder leichtgewichtige Clients, die Daten von full Nodes anfragen oder sind extern auf Servern gehostet. Es besteht, oberflächlich betrachtet, kein Bedarf daran, daß Bitcoin-Nutzer full Nodes betreiben.

Resultat: Die meisten neuen User entscheiden sich gegen eine Node und einige alte Hasen haben ihre geschlossen. Die Frage, die sich stellt, ist:

Wie viele full Nodes braucht Bitcoin?

Je nach eigener Perspektive kann man auf folgende Antworten können:

  • Eine: Bitcoin ist ein Netzwerk ohne Vertrauen, weshalb die einzige Node, die was zählt, die eigene ist.
  • Hunderte bzw genügend, um es einer einzelnen Partei unmöglich zu machen, einen signifikanten Anteil des Netzwerks auszuschalten.
  • Tausende bzw genügend, um die Menge an Anfragen von SPV-clients berbeiten zu können.

Die gegenteilige Frage – wie viele Bitcoins sind zu viele – ist einfach zu beantworten: Wir können nicht zu viele Nodes haben. Wie reagieren wir aber auf das Faktum, daß weniger als 1% der Bitcoin-Nutzer eine full Node betreiben?

Full Nodes vs Skalierung

Auf die Frage, weshalb full Nodes wichtig sind, hat Pieter Wuille (Bitcoin core developer & Autor des Segregated Witness) folgendes gesagt:

“Full nodes garantieren ein ehrliches Netzwerk. Und es ist weniger eine Frage, ob genügend Nodes da sind als vielmehr, wie schwer es ist, eine full node zu hosten.”

Durch die Popularität von Bitcoin laufen wir zur Zeit in die Obergrenze der Blocksize (1MB), was zu vielen Streiteren um die gerechte Balance zwischen Skalierung des Netzwerkes und Dezentralisierung desselben führt.

Ein Argument, was oft in dieser Debatte aufkommt, ist um die Kosten des Instandhaltens einer full Node. Einer theoretischen Betrachtung nach werden diese höheren Kosten – durch zusätzliche Hardware, um größere Blocks zu validieren und weiterzugeben – in weniger full Nodes enden.

In dem Post Measuring Decentralization führt der Entwickler Paul Sztorc das Konzept CONOP (cost of node-option) ein: Er postuliert, daß bei geringeren Kosten mehr Leute Dinge tun würden, die für sie auf lange Sicht profitabel wären. Das Argument macht Sinn, wenn man annimmt, daß als Variable nur die Kosten des Instandhaltens einer Node berücksichtigt werden. Im nächsten Artikel werden andere Faktoren diskutiert, die Einfluss auf CONOP haben.

Nach Betrachtung der Skalierungsdebatte kommt man immer wieder zu einem Problem zurück: Es gibt keine eindeutig definierten Minimalbedingungen zum Betreiben von full Nodes. Dadurch gibt es für die Bitcoin Entwickler kein Benchmark, was die Bedingungen für Protokollneuerungen an eine full Node betrifft. Wenn eine solche Minimalbedingung existieren würde würde man diese wahrscheinlich mit der aktuell genutzten Hardware definieren.

Ein ARM-basiertes Gerät wie ein Raspberry Pi oder ein ODROID+ scheinen zur Zeit die minimalen Spezifikationen zu sein. Man kann damit bis zu 1MB blocks bearbeiten, auch wenn man ca zwei Wochen für die erste Blockchain Synchronisation (dh bis Block 390000) braucht. Für $170 kann man einen Bitseed kaufen und für $140 einen Bitcoin Mini. Technisch versierte können eine eigene Raspberry Pi Node für $100 bauen. Für einen Hunderter mehr kann man eine sehr leistungsfähige Node aufbauen, die die nächsten Jahre gut laufen sollte.

Ein weiteres Problem bezüglich der Kosten einer eigenen Node ist, daß die User Base nie eindeutig definiert wurde. Demographische Studien lassen vermuten, daß der durchschnittliche Bitcoin-user ein weißer männlicher Techie unter 30 ist (das kann man aber generell über Early Adopter sagen). Viele in der Bitcoin Community vertreten die Position, daß Bitcoin für einen langfristigen Erfolg eine breite User-Basis benötigt. Im Kontrast dazu finden sich die meisten Nodes in Nordamerika und Westeuropa.

Da der Internetzugang nicht weltweit derselbe ist, wäre es zu simpel gedacht, von einer Bitcoin Welt zu träumen, in der jeder Nutzer seine eigene Node besitzt. Extrem hat dies Gavin Andersen ausgedrückt:

“Die meisten Otto-Normal-Verbraucher sollten KEINE Node hosten. Wir benötigen full nodes, die immer online sind, mehr als Acht Verbindungen aufweisen und mit einer High-Bandwidth-Verbindung am Internet hängen.”

Statistiken von Statoshi zeigen, daß gut verbundene full Nodes ca 200Kb/s Downstream und 1.5Mb/s Upstream benötigen; es kommt aber zu Spikes mit 2Mb/s Downstream und 40 Mb/s Upstream.

Nach Akamais State of the Internet-Bericht ist die durchschnittliche Bandbreite 5Mb/s, jedoch findet man in dieser Liste nur ca ein Viertel der Länder auf Erden. Nach Schätzungen sind überhaupt nur 40% der Weltbevölkerung Internetnutzer.

Eine Spezifizierung einer Minimalnode

Ziel einer Spezifizierung der Minimalanforderung an eine Node sollte auch die gewünschte Performance definieren, die Ressourcen, die es dazu benötigt und die Kosten, die die dafür benötigte Hardware mit sich bringt.

Man kann hier ähnliche Logik wie Jonas Nick, Greg Sanders und Mark Friedenbach bei der Abschätzung der Block Size-Kosten nutzen. Ihr Ansatz ist durchdacht, auch wenn eine Abschätzung der “Minimalspezifizierung” komplexer wäre. Beispielsweise könnte eine solche Minimalspezifizierung wie folgt aussehen:

  • Zielkosten Hardware: $200
  • Minimale Zeit, um einen Block zu validieren: 10 Sekunden
  • Minimale Netzwerk-Bandbreite: 2Mb/s
  • Minimale CPU: 5000 MIPS
  • Minimaler RAM: 1GB

Jean-Paul Kogelman zeigte, daß eine solche Spezifizierung bei den Skalierungs-Debatten helfen würde, da man anhand dessen die Kosten für Verifizierung von Transaktionen abschätzen kann.

In Bitcoin Core vor 0.12 wurde Open SSL zur Verifizierung genutzt. Mit 0.12 wird secp256k1 genutzt, was die Verifizierung von Transaktionen um 500% beschleunigen würde. Da das die oben genannte Validierungszeit um 80% verkürzen würde kann man dank der Minimalspezifizierung nun zwischen zwei Optionen wählen:

  • Man könnte das oben genannte Minimum nach unten korrigieren
  • Man könnte andere Parameter wie die Anzahl der Signatur-Operationen pro Transaktion oder die Anzahl der Transaktionen pro Block nach oben korrigieren.

Mit dieser Minimalspezifizierung kann man, wenn Protokolländerungen vorgeschlagen werden, genau sagen, was das für eben diese bedeuten würde. Mit dem Fortschritt der Technologie und den sinkenden Hardwarekosten könnte man gut bestimmen, wie die Hardwareanforderungen ohne Anhebung der Kosten erhöht werden könnten. Das sollte zu weniger Kontroversen als bei der Blocksize-Debatte führen. Wenn beispielsweise klar wäre, daß aktuelle Node-Betreiber, deren Hardware den Minimalspezifizierungen entspricht, durch Erhöhung der erlaubten Anzahl an Signaturen pro Block keine Nachteile hinnehmen müssen, sollte eine entsprechende Erhöhung nicht so viele Kontroversen mit sich bringen.

Kosten vs Nutzen

Es ist ein schönes Ziel, die Kosten für Hosten von full Nodes gering und erschwinglich für den durchschnittlichen User zu halten. Wenn wir jedoch diese Anforderungen an die Ressourcen immer an den neuesten Raspberry Pi und die global durchschnittliche Internetverbindung anpassen, ist unklar, was das für die Transaktionsgebühren heißen würde. Anders ausgedrückt: Wenn die Kosten der Nutzung des Netzwerkes so hoch werden, daß der durchschnittliche Nutzer von Bitcoin-Transaktionen abzieht wird derselbe Nutzer an erschwinglichen full Nodes auch keine Freude haben.

Verschiedene Kosten (neben einfachen monetären) kommen beim Hosten einer Node zusammen:

  • die erste Lernkurve (Zeit)
  • Installation, Konfiguration und erste Synchronisation mit der Blockchain (Zeit, Bandbreite, CPU)
  • Laufende Kosten (Bandbreite, CPU, RAM, Festplatten-Speicher)
  • Instandhaltungskosten (Zeit, um Troubleshooting oder Updates auszuführen)

Bitcoin zu verstehen kann Wochen bis Monate kosten. Im Gegensatz dazu benötigt es nur wenige Stunden, um herauszufinden, wie man eine Node zum Laufen bekommt.

Installation, Konfiguration und speziell die Synchronisation kann zwischen mehreren Stunden und mehreren Wochen kosten. Grob abgeschätzt wird man für die Instandhaltung maximal eine Stunde pro Monat benötigen.

Man kann sich vorstellen, daß die Kosten, die aufgelistet wurden (Geld, Bereitstellung der Bandbreite, Zeit…) sich antiproportional zu der Anzahl der full Nodes verhalten – aber was ist, wenn Kosten nicht der einzige Faktor sind? Stephen Pair, der CEO von Bitpay sagte hierzu:

“Es existieren nur so viele nodes wie es Nachfrage nach unabhängigen Transaktionsvalidierungen ohne Mittelsmann gibt.”

Wenn man die Äußerungen von Pair und Stzorc im Hinterkopf hat kann man sagen, daß die Anzahl der Nodes letztlich abhängig von der oben genannten Nachfrage und den Kosten eine Node ist. Des weiteren wird die Anzahl der Nodes abhängig von dem Wert sein, der von Bitcoin Nutzern angespart und genutzt wird.

Oft wird gesagt, daß das Betreiben von full Nodes ein komplett altruistisches Unterfangen ist. Jedoch kann man schon einige Anreize ausmachen:

  • Investment: Wenn man viel Geld in Bitcoin angelegt hat möchte man ggf seinen Beitrag zum Schutz des Netzwerks (und damit zum Schutz der eigenen Anlage) leisten.
  • Performance: Eine lokale Kopie der Blockchain zu analysieren ist mehrere Größenordnungen schneller als dies über das Internet zu tun.
  • Widerstand gegen Zensur: Durch Senden und Empfangen von Transaktionen von der eigenen Node hat niemand die Macht, dagegen vorzugehen.
  • Privatsphäre: Durch Abfragen von fremden full Nodes können können Kriminelle versuchen, die Anonymität von jemandem aufzuheben.
  • Trustlessness: Eine Kopie des public Ledger zu haben, die man selbst validiert hat bedeutet, daß man keinen Mittelsmann benötigt.

Zusammenfassend kann man folgendes sagen: Das Ziel sollte sein, daß Leute mit einem nicht trivialen Wert in Bitcoin full Nodes betreiben sollten. Je höher dieser Wert ist, desto größer ist letztlich der Reiz, daß man sein Guthaben selbst schützen kann. 

Analyse des Nutzerverhaltens

Um den Hintergrund hinter der Entscheidung, eine full Node zu betreiben, zu verstehen, wurde unter 500 Bitcoin Usern eine Umfrage veranstaltet (Auswertung, Rohdaten). Zusammenfassend kann man folgende Punkte aus der Umfrage herauslesen:

  • 24% der Gefragten hatten mal full Nodes am Laufen, tun dies jedoch nicht mehr
  • 42% der Leute ohne Node sehen einfach keinen Anreiz dafür
  • 44% der Node-Operators nutzen die Node weniger aus idealistischen Gründen, sondern zum eigenen Vorteil (siehe oben genannte Anreize)
  • 57% würden bereit sein, über 100kb/s Bandbreite einer Node zur Verfügung zu stellen
  • 58% möchten nicht mehr als $10 pro Monat für eine Node zahlen
  • 81% der Node-Operators haben eine full Node bei sich zuhause

Interessanterweise gibt es anscheinend keine Korrelation zwischen dem Investment des Users und dem Interesse, full Nodes zu betreiben – im Kontrast zu obigen Überlegungen. Man muß jedoch sagen, da ggf die Frage etwas zu vage zu formuliert war, man hat nicht nach spezifischen Geldwerten in Bitcoin gefragt.
Generell läßt sich jedoch trotzdem – auch anhand der Begründung über den eigenen Vorteil beim Betreiben von full Nodes – sagen, daß jeder Nutzer, die viel in Bitcoin invetiert hat, von einer eigenen Node dramatisch profitiert.

Abschließende Betrachtungen

Die auch hier oft angesprochene Theorie, daß höhere Kosten in weniger full Nodes enden sollte man kritisch betrachten, da man auch sagen kann, daß ein höheres Transaktionsvolumen in einer größeren Adoption von Bitcoin und damit in mehr Nutzern, die full Nodes betreiben, niederschlagen kann.

Ja, die Kosten werden dann größer und gut über die $10 pro Monat gehen, aber wenn das Bitcoin Netzwerk größer wird, wird damit auch der Anreiz steigen, die trustlessness von Bitcoin durch eigene full Nodes am Leben zu erhalten.

Auf der anderen Seite muß man auch sehen, daß es wenig Grund gibt, ein System zu nutzen, dessen Validierungskosten gering und dessen Transaktionskosten extrem hoch sind.

So oder so wird, wenn man sich der Block Size Debate über diesen Gesichtspunkt nähert, entweder die eine oder die andere Seite unter einer Entscheidung zu leiden haben: Die Blocksize nicht zu erhöhen wird einige Nutzer vom Senden von Transaktionen ausschließen, während das Erhöhen dieser Block Size Nutzer vom Hosten einer Node ausschließen wird. Viele Variablen gilt es, in Balance zu halten, so das das Bitcoin Ökosystem wachsen kann und trotzdem dezentral bleibt.

Jameson Lopp schlägt den Bitcoin Developern abschließend folgende Punkte (in absteigender Priorität) vor:

  • Es braucht eine Minimale Ressourcenspezifikation, die festlegt, was full Nodes mit einer bestimmten Zielperformance benötigen.
  • Der Fokus sollte auf der Maximierung des Transaktionsvolumens liegen, was auch zu einer Maximierung der Nutzer führt.
  • Ein weiterer Fokus sollte darin bestehen, es Nutzern einfacher zu machen, eine Node zu betreiben. Das wird mit der wachsenden Reputation und Akzeptanz von Bitcoin einher gehen.
  • Vom Standpunkt der Hardware-Ressourcen her gesehen sollte man es Nutzern einfacher machen, full Nodes zu betreiben. Ein erster Schritt könnte sein, eine Node so zu konfigurieren, daß sie schnell im SPV-mode laufen kann, während im Hintergrund die Blockchain synchronisiert wird. 
  • Man sollte der Frage nachgehen, wie man einen direkten Anreiz zum Bereitstellen einer Node schaffen könnte – vielleicht durch eine Gebühr für bestimmte Datenservices.

Solange die Kosten für das Betreiben einer Node langsamer als der Wert derselben wachsen sollte das Netzwerk dezentralisiert bleiben, selbst wenn der Druck auf die Node-Operators steigt.

Die demographische Verteilung der Node-Operators wird sich ändern, aber solange der dezentrale Charakter von Bitcoin intakt bleibt, kann man Änderungsvorschläge am Bitcoin-Protokoll begeistert diskutieren.

Jameson Lopp ist Software-Entwickler bei BitGo, ist Gründer von Bitcoinsig.com und der Mensch hinter Statoshi.info.  

BTC-Echo
Quelle: How to Save Bitcoin’s Node Network from Centralization via Coindesk
Image Source: Fotolia


Teilen

Die aktuellsten News kostenlos per E-Mail

Ich stimme zu, dass meine E-Mail-Adresse für den Versand des Newsletters gespeichert und verarbeitet wird. Weitere Hinweise
BTC-ACADEMY

Kryptowährungen einfach kaufen und verkaufen

Ein Bankkonto, Krypto-Wallets und Trading vereint

  • Einfach, sicher und zuverlässig
  • Kontoeröffnung in nur 5 Minuten
  • Nur 1% Handelsgebühr
  • Made in Germany