BitPays Vorstoß für Extension Blocks und alternative Clients

BitPay, Bitmain und Purse wollen den alternativen Client bcoin etablieren und Extension Blocks bewerben. An sich ist eine Vielfalt von Entwicklerteams für ein Open Source Ökosystem gesund. Aber bei Bitcoin ist es auch gefährlich. Darum denkt ein BitPay-Entwickler darüber nach, wie verschiedene Clients den Konsens behalten können.
Bcoin von Purse hat vor kurzem mit Extension Blocks einen Vorschlag zur Skalierbarkeit gemacht, der ausdrücklich das Ziel hat, alle Seiten zu befriedigen. Andrew Lee und Purse-Entwickler JJ – die beide früher bei BitPay gearbeitet haben – haben mit BitPay und Lightning-Entwickler Joseph Poon ein Konzept vorgestellt, das als Softfork aktiviert wird, ein flexibleres Kapazitätslimit ermöglicht, Mallebility löst und, als Bonus eine Schwachstelle von Lightning beseitigt. Win-Win-Win?
Angesichts der Verflechtungen von Purse und BitPay ist es kein Wunder, dass der Geschäftsführer des Zahlungsdienstleisters, Stephen Pair, offen dafür ist, die Idee auf seinen Servern zu testen. Auf dem Blog der Firma berichtet Pair, dass JJ die Extension Blocks in bcoin – den von Purse selbst in NodeJS geschriebenen Full Client – implementiert sind und nun auch auf einem öffentlichen Testnet ausprobiert werden. “Wenn es hält, was es verspricht, werden wir es auf dem Mainnet unterstützen.”
Auch die beiden wichtigen chinesischen Miner Jihan Wu (AntPool / Bitmain) und Wang Chun (F2Pool) können sich mit der Idee anfreunden. Jihan Wu twitterte, er liebe Extension Blocks, sie seien kompatibel mit BU, während Wang Chun meckerte, dass Core 0.14.1 noch nicht bereit für den Release sei,  da Extension Blocks fehlen.
Core – und weite Teile der Community – fragen sich hingegen: Warum? Extension Blocks ist fast dasselbe wie SegWit. Softfork, mehr Kapazität, Malleability-Fix? Warum wollen die Miner (und BitPay) eine unausgereifte, kaum getestete, eilig gebaute Lösung, die womöglich die Fungibilität von Bitcoins beeinträchtigt, aktivieren? Obowhl es mit SegWit eine sorgfältig entwickelte, lange getestete Lösung gibt, die fast dasselbe macht, aber eleganter und weniger disruptiv ist? Nur weil Extension Blocks nicht SegWit sind?
Die beiden Lösungen liegen so nahe beieinander, dass es im Prinzip für beide Seiten lächerlich ist, die andere abzulehnen.
BitPay und Bitmain kooperieren für neuen Client
BitPay und Bitmain (der Firma von Jihan Wu und Antpool) scheinen sich in den letzten Wochen oder Monaten näher gekommen zu sein. Gestern stellte BitPay eine Partnerschaft mit BitMain vor: “Im Laufe der kommenden Jahre wird BitPay mit seinem neuen Kunden Bitmain eine fortschrittliche Open Source Software für Miner, Pools und Full Nodes entwickeln, die Blockchain-Transaktionen speichert und sichert.”
Es folgen einige Absätze mit freundlichen Worten, die erklären, weshalb BitPay und Bitmain klasse Firmen und perfekte Partner sind. Weitere Infos bleiben leider aus. Es liegt nicht zu fern, zu vermuten, dass Bitmain und BitPay gemeinsam die Entwicklung von bcoin vorantreiben wollen. Wäre nicht so absurd.
BitMain versucht derzeit im Allgemeinen, den Aufbau alternativer Clients zu fördern. So hat der chinesische Hersteller von Mining-Hardware bereits den  Rust-basierte Bitcoin-Client von Parity  mit finanziert.
Man kann das ganze so oder so sehen. Als Angriff auf die Core-Entwickler, als politischen Zug, um einer Gruppe von Leuten Macht zu entreissen, vielleicht sogar als Versuch der “Wirtschaft”, der Plattformen und Miner, Macht auf Kosten der Open Source Community zu gewinnen, die unabhängig von solchen Einflüssen bleiben möchte.
Man kann es auch als Dezentralisierung der Entwicklung sehen, in der verschiedenen Teams mit verschiedenen Implementierungen konkurrieren und kooperieren sollen, wie es bei bei Linux geschieht. Allerdings hat das, selbst wenn es in friedlicher Absicht geschieht, seine Nachteile. Denn Bitcoin ist nicht Linux, sondern Geld.
Warum alternative Clients eine schlechte Idee sind
“Heute wird das [Bitcoin-]Netzwerk fast ausschließlich von Mining Pools, Börsen und Full Nodes unterhalten, die eine Version der C++ Implementierung benutzen, ” stellt Jason Dreyzehner, Head of Design, fest. Weil diese extreme Monokultur für viele, die neu in der Szene sind, verwirrend und beunruhigend ist, fragt er: “Warum werden nicht mehr alternative Bitcoin-Implementierungen genutzt?”
Dreyzehner erklärt, dass alle Knoten im Netzwerk einen perfekten Konsens erhalten müssen. Dies ist extrem wichtig, und jede Abweichung vom Konsens kann für Unternehmen Downtime oder gar Verluste durch Betrug bedeuten. Er zitiert den berühmten Ausspruch von Satoshi:
“Ich glaube für keine Sekunde, dass kompatible Implementierungen von Bitcoin jemals eine gute Idee sein werden. Das Design hängt so sehr davon ab, dass alle Knoten exakt dieselben Resultate haben, weshalb eine zweite Implementierung eine Gefahr für das Netzwerk wäre.”
Dieser Ausspruch von Satoshi hat sich, so Dreyzehner, in der Vergangenheit wiederholt bestätigt. So hat Coinbase früher etwa eine Ruby-Implementierung benutzt, diese aber aufgegeben, nachdem im Jahr 2013 eine Reihe von Consens-Fehlern zu Problemen bei Transaktionen geführt hatte. Es ist in der Softwareentwicklung absurd schwierig, einen perfekten Konsens aufrechtzuhalten. “Um sicher zu sein, müssen alternative Implementierungen eine Bug-for-Bug-Kompatibilität aufrechthalten, was bedeutet, dass sie exakt dieselben Bugs implementieren müssen, die in Bitcoin Core sind.” Dreyzehner nennt kleine Bugs, etwa nicht-standardisierte Merkle-Trees, und erklärt, dass diese Bugs durch ihre Präsenz in Core zu einem Teil des Protokolls geworden sind, da Core die einzige Spezifikation von Bitcoin ist.
Diese Problematik nimmt mitunter groteske Ausmaße an: “Selbst für alternative Implementierungen, die erfolgreich die bekannten Schrullen von Bitcoin Core übernehmen, besteht das Risiko von noch nicht entdeckten Macken, die für die alternativen Implementierungen zu Zero-Day-Schwächen werden können.” Anders gesagt: Wenn es in Core einen Zero-Day, ein noch nicht bekannter Bug, gibt, dann schadet das nicht direkt Core, sondern den anderen Clienten, weil sie den Konsens verlieren.
Aus solchen und mehr Gründen warnen viele Bitcoin Entwickler davor, alternative Clients für Bitcoin zu unterhalten.
Warum eine Monokultur der Clients aber auch nicht ideal ist
Die Monokultur bei Bitcoin ist nicht unbegründet. Aber sie verursacht auch drastische Probleme. So entmutigt sie etwa neue Entwickler, die nicht nur in der Lage sein müssen, mit der nicht eben als einfach geltende Sprache C++ zu arbeiten, sondern sich auch durch den als Spaghetti-Code bekannten, über die Jahre hingweg chaotisch gewachsenene Code von Core kämpfen. Dreyzehner zitiert aus der Einleitung von Purse zur Veröffentlichung von bcoin:
“Während Bitcoin Core auf dem Schlachtfeld getested wurde und der Standard ist, ist die Codebase schwer zugänglich, selbst für erfahrene Software-Ingenieure. Das Resultat ist, dass nur eine Handvoll von Entwicklern aktiv zu Bitcoin Core beitragen kann – und nur einige Dutzend Individun es mit alle Macken vollständig verstehen.”
Des weiteren ist es für manche Projekte problematisch, eine Infrastruktur aufzubauen, die mit C++ kompatibel ist, etwa weil dafür zunächst eigene Librarys zu schreiben sind. Auch ist es oft schwierig, auch nur kleine Veränderungen in Core voranzubringen, selbst wenn diese harmlos sind, sei es, weil es keinen Entwickler dafür gibt oder sie nicht in das Konzept oder die Struktur der aktuellen Entwicklung passt, unabhängig vom Konsens.
Außerdem – und vielleicht am Schlimmsten – führt die Monokultur zu einer Politisierung der Entwicklung. Kennen wir zur Genüge. Der Grund ist, dass auseinandergehende Visionen nicht, wie bei anderen Open Source Projekten, als eigene Implementierungen um den User konkurrieren können. Stattdessen müssen Änderungen durch “politischere Methoden, durch einen Lobbyismus für einen ‘Wandel von innen’” forciert werden. Das Ergebnis ist in allen sozialen Medien rund um Bitcoin überdeutlich zu spüren: “Politik vergiftet den Diskurs und stößt Individuen ab, die Konfrontationen vermeiden.”
Schließlich besteht die Gefahr, dass es noch unentdeckte (oder noch nicht eingeführte) Bugs in Bitcoin Core gibt. Bei der derzeitigen Monokultur können diese das gesamte Netzwerk lahmlegen. Ethereum hat während der Angriffe im vergangen Herbst demonstriert, dass eine duale Infrastruktur für eine Blockchain lebensrettend sein kann.
Was also tun? Defensiver Konsens?
Dreyzehner schlägt einen “defensiven Konsens” vor. Dieser soll es erlauben, dass alternative Implementierungen nicht jeden Bug von Core reproduzieren müssen – und sogar in der Lage sind, das Netzwerk vor einem Bug in Core zu schützen – aber gleichsam nicht wegen jeder kleinsten Unstimmigkeit in den Implementierungen den Konsens verlieren und forken. Diesen defensiven Konsens skizziert der Entwickler in drei aufeinanderfolgenden Schritten:
Erstens sollen die Miner versuchen, eine Fork zu vermeiden. Dazu benutzen sie einen sogenannten Candidate Block, mit dem sie testen, ob der Block von allen wichtigen Implementierungen im Netzwerk anerkannt wird. Diese Art von Risikokontrolle durch die Miner sollte Teil des Nodes sein, ohne jedoch eine Änderung des Protokolls darzustellen.
Zweiten sollen Knoten es vermeiden, einer Fork zu folgen. Sollte es dazu kommen, müssen Unternehmen darauf achten, durch die Fork keinen Schaden zu nehmen. Dazu sollten sie aufhören, auf einer Fork Transaktionen vorzunehmen, wenn diese kontrovers wurde, und stattdessen auf einen unkontroversen Client – wie derzeit Bitcoin Core – umsteigen.
Die beiden ersten Schritte waren lediglich lokale Methoden, mit einem erhöhten Risiko von Forks durch alternative Clients umzugehen. Sie berühren nicht das Konsens-Protokoll an sich. Anders der dritte Schritt. Mit diesem soll das Ökosystem eine Fork selbst dann vermeiden, wenn es eine Änderung der Regeln bzw. Uneinigkeit über diese gibt. Dies kann passieren, wenn neue Implementierungen die Konsens-Regeln verletzen, sei es versehentlich, sei es, weil sie einen Bug in Core nicht reproduzieren, oder sei es, weil sie bewusst die Regeln ändern wollen. In diesem Fall soll ein Signalisierungsprozess, wie man ihn gegenwärtig von SegWit kennt, es kenntlich machen, welche Konsensregeln von den Minern als gültig erachtet werden. Blöcke, die diesen verletzen, werden abgelehnt und verwaist.
Mit diesem Plan, so Dreyzehner, soll Bitcoin ebenso zuverlässig im Konsens bleiben wie bisher, aber zugleich eine blühende und bunte Vielfalt von Clients in verschiedenen Sprachen erlauben.Filed under: Deutsch Tagged: BitPay, Blocksize, Client, Scalability
Source: Bitcoin Blog