Es wurde ja schon viel Gutes über Cores Release 0.13.1 und die Vorteile von SegWit geschrieben. Diesmal stelle ich ein weniger bekanntes und weniger positives Feature von SegWit vor: Ein 0.13.1 Node bevorzug die Verbindung zu anderen 0.13.1 Nodes. Aus diesem Grund meint Peter Todd auch, dass die SegWit Softfork ähnliche Eigenschaften hat wie eine Hardfork.
Einen Node zu starten, bedeutet, sich mit einem Netzwerk von Nodes zu verbinden. Das ist ein wenig so, wie wenn man in eine fremde Stadt zieht und sich dort Freunde sucht. ;ithilfe eines öffenlichen DNS-Seed findet der Knoten seine ersten Kontakte. Die erzählen ihm dann die Adressen ihrer peers, und er verbindet sich mit diesen. So baut sich der Node nach und nach ein Netzwerk von Freunden auf, um die Blockchain herunterzuladen und Transaktionen zu propagieren.
In der Regel freundet sich ein Knoten mit einer Vielzahl verschiedener Knoten an. Knoten aus alle Ländern dieser Erde, neue Knoten, alte Knoten, Knoten verschiedener Implementierungen von Bitcoin, Core-Knoten, BitcoinJ-Knoten, Classic-Knoten, Unlimited-Knoten … In einer idealen Welt repräsentiert die Liste von Verbindungen eines Knoten die mehr als 100 verschiedenen Implementierungen des Protokolls, die das Bitcoin-Netzwerk derzeit bevölkern.
Multikulti rules: Eine Liste mit den Peers, mit denen mein Knoten normalerweise Kontakt aufnimmt.
Der Knoten, der gelernt hat, einen Unterschied zu machen
All das ändert sich, wenn man einen Knoten mit der neuesten Version von Core, 0.13.1, startet. Dieser Release kann das lang erwartete Upgrade SegWit aktivieren. User, die ihn benutzen, werden jedoch erleben, dass der Knoten fortan Schluss mit der Vielfalt macht. Er ändert sein Vernetzungs-Verhalten und sucht nur noch Freunde, die so sind wie er. Zwar akzeptiert der Knoten weiterhin eingehende Verbindungen von anderen Knoten, doch bei der Suche nach anderen Knoten – den ausgehenden Verbindungen – toleriert er nur noch 0.13.1 Knoten.
Manche Knoten sind halt gleicher als die anderen: Sämtliche acht ausgehenden Verbindungen gehen an 0.13.1 Knoten.
SegWit hat viele großartige Eigenschaften, von denen die Erhöhung der Kapazität nur eine ist. Mir persönlich gefällt die Beseitigung der Anreize, die Blockchain mit vielen outputs zu verstopfen, vielleicht am besten. Oder dass SegWit per Softfork eine Erhöhung der Kapazität ermöglich.
Die Präferenz beim Verbinden gehört jedoch nicht zu erfreulichen Eigenschaften. Wenn ein SegWit-Knoten nur zu anderen SegWit-Knoten verbindet, dann wird dies bei steigender Verbreitung von 0.13.1-Knoten dazu führen, dass mehr und mehr nicht nur die ausgehenden, sondern auch die eingehenden Verbindungen von 0.13.1 Nodes belegt werden. Schließlich ist jede ausgehende Verbindung des einen Nodes die eingehende Verbindung eines anderen. Es bildet sich ein Netzwerk im Netzwerk, das immer weniger Kontakt zu den anderen Teilen des Netzwerks hat.
Das ist nicht nur problematisch, wenn man aus ideologischen Gründen meint, ein Knoten solle wie der andere sein. Es ist auch problematisch, weil es das Risiko birgt, das Netzwerk zu partitionieren und womöglich Sybill-Angriffe zu vereinfachen. Da all dies nichts ist, was im allgemeinen erwünscht ist, sollte man erwarten, dass es ernsthafte Gründe dafür gibt, warum sich die Knoten so verhalten.
Und ja, die gibt es.
Paritionieren, um die Partitionierung zu verhindern?
Ein Grund kann man in den Release Notes auf bitcoincore.org finden. Hier erklären die Core Entwickler, dass SegWit als Softfork einige spezifische Risiken mit sich bringt. Eine Softfork bedeutet, dass nicht jeder Node upgraden muss, wie bei einer Hardfork, sondern nur jeder Miner, während das Upgrade der Nodes freiwillig bleibt. Wer will, trägt das Extra-Päckchen, wer nicht will, lässt es. Dies ist eines der stärksten Argumente, um die Kapazitätserhöhung per SegWit durchzuführen. Aber es birgt auch das Risiko, dass, wie Core erklärt, „ein schlecht gemachtes Upgrade ein Scheitern des Systems in verschiedene Arten verursachen kann.“
Ohne näher ins Detail zu gehen, erklärt Core, dass dies unter anderem dadurch vermieden wird, dass man ein Netzwerk im Netzwerk aufbaut: „Eine signifikante Arbeit wurde darin investiert, sicherzustellen, dass Peers, die SegWit aktiviert haben, einen stark verbundenen Subgraphen des Bitcoin P2P Netzwerkes bilden. Dies beinhaltet die Bereitstellung eines speziellen Service Bits für diese Knoten und die Präferenz, sich mit solchen Knoten zu verbinden.“
Warum nun was genau, wird nicht richtig klar. Wenn wir jedoch weiter zurückgehen, an den Anfang des Jahres, finden wir eine etwas weitergehende Erklärung von Peter Todd in der Mailing-List: „SegWit Nodes können nicht durch Nicht-SegWit-Knoten synchronisieren und danach vollständig validieren,“ so der Entwickler. Nur SegWit Knoten speichern und verifizieren die Signaturen von SegWit-Transaktionen; um vollständig zu synchronisieren, muss sich ein SegWit-Knoten daher mit anderen SegWit-Knoten verbinden. Und Todd weiter: „Wenn einmal die SegWit Softfork aktiviert ist, brauchen Full Nodes die Witness Daten, um zu arbeiten. Dies führt zum Problem, dass, wenn die Miner Adoption hinter der Full-Node-Adoption zurückbleibt, das SegWit-P2P-Netzwerk sich partitionieren kann und den Konsens verliert.“
SegWit als Softfork kommt also mit dem Risiko daher, dass SegWit-Knoten womöglich Probleme haben, die Daten zu finden, die sie brauchen, um sich mit dem Netzwerk zu synchronisieren. Um dieses Risiko zu vermeiden, schlug Todd vor, dass „Peers sich nur mit Peers verbinden, die SegWit unterstützen.“ Aus diesem Grund „hat die SegWit Softfork Eigenschaften, die einer Hardfork nicht unaähnlich sind, hinsichtlich des Drucks auf Nodes, ein Upgrade durchzuführen.“
Um vernünftig zu funktionieren, müssen es SegWit-Knoten also bevorzugen, sich mit anderen SegWit-Knoten zu verbinden. Während Peter Todd dies als Lösung vorschlug, um eine Partitionierung des Netzwerkes zu verhindern, droht dies selbst in einer Art Partitionierung zu enden. Zumindest wird es es erschweren, dass sich SegWit-Knoten mit anderen Knoten verbinden, wenn die Verbreitung von SegWit-Knoten zunimmt.
Erste Probleme …
Bisher verursacht dieses Feature nur Probleme für diejenigen, die einen 0.13.1 Node betreiben. Obwoh SegWit noch nicht aktiviert ist, verbinden sich diese Knoten fast ausschließlich mit 0.13.1 Nodes. Ein Nachteil ist, dass diese begrenzte Vielfalt an ausgehenden Verbindungen es schwieriger machen kann, sich mit einem Mining-Pool zu verbinden, wodurch die Bestätigung von Transaktionen verzögert werden kann.
Ein anderer Nachteil ist eine erhöhte Aktivivtät der Festplatte. Einige User beschwerten sich, dass sie seit dem Update auf 0.13.1 „eine nachhaltige höhere IO Rate für das Lesen der Festplatte“ sowie „plötzliche Spitzen der IO Rate“ bemerkten. Core Entwickler Matt Corallo erklärt, „dass dies von anderen Knoten zu kommen scheint, die die Chain von dir herunterladen, weil sie deinen Knoten aufgrund der Vernetzungs-Präferenz gewählt haben.“ Aufgrund dieser (kleinen) Probleme hat ein Entwickler vorgeschlagen, „die Peer Selektion zu fixen, so dass man weiterhin zu nicht-Witness-Nodes Kontakt aufnimmt.“ Sein Vorschlag, diese Präferenz der Vernetzung erst nach der Aktivierung von SegWit zu aktivieren, wurde von Gregory Maxwell jedoch abgelehnt: „NACK. Dies untergräbt eine absichtliche Design-Entscheidung. Es ist nicht akzeptabel, dass sich die Netzwerk-Topologie plötzlich verändern, wenn SegWit aktiviert wird.“
Dieses Thema sieht zwar eher wie ein technisches Detail aus. Die damit verbundenen Probleme sind überschaubar, und es scheint eine Notwendigkeit zu sein, um SegWit funktionsfähig zu machen. Allerdings zeigt es auch, dass SegWit nicht eine reine Softfork ist, sondern auch Eigenschaften einer Hardfork hat. Vielleicht könnte man es eine Mischung aus beiden Forks nennen.