Glossar / Protokoll und Upgrades
Nutzeraktivierter Soft Fork
Auch bekannt als UASF.
- Was ist ein nutzeraktivierter Soft Fork?
- Ein nutzeraktivierter Soft Fork erzwingt eine neue Regel an einem Stichtag, den die Node-Betreiber wählen, sodass Miner, die ihn ignorieren, ihre Blöcke abgelehnt sehen, statt nur überstimmt zu werden.
Spezifiziert im BIP-148.
Die Idee kehrt die übliche Reihenfolge der Vorgänge um. Statt darauf zu warten, dass Hashrate Bereitschaft signalisiert, kündigen die Nodes, die Zahlungen empfangen, ein Datum an, nach dem sie jeden Block ablehnen, der die Regel nicht einhält. BIP-148 setzte dieses Datum auf den 1. August 2017, und der glaubhaften Drohung dahinter wird weithin zugeschrieben, dass sie einen Signalstillstand beendete, der seit November 2016 andauerte.
Wie es funktioniert
Die Validierung, nicht das Mining, ist der Ort, an dem eine Regel letztlich durchgesetzt wird, und ein nutzeraktivierter Soft Fork baut auf dieser Tatsache auf.
Ein Node entscheidet selbst, welche Blöcke gültig sind. Wenn genug von der Wirtschaft, also die Börsen, Zahlungsabwickler und Verwahrer, mit denen die Menschen tatsächlich abrechnen, Software ausführt, die nicht konforme Blöcke ablehnt, dann wird ein Miner, der solche Blöcke produziert, in Coins bezahlt, die niemand akzeptieren wird. Die Blockbelohnung ist nur dann etwas wert, wenn die Kette, auf der sie liegt, die Kette ist, die Käufer anerkennen, also weist der Anreiz in Richtung Regelkonformität, ohne dass eine Abstimmung stattfindet.
Der Mechanismus ist ein Datum und kein Schwellenwert. BIP-148 verlangte, dass ab dem 1. August 2017 jeder Block Bereitschaft für SegWit signalisiert, und wies Nodes an, Blöcke, die das nicht taten, zu verwerfen. Das ist eine Verschärfung, also bleibt eine regelkonforme Kette für Nodes gültig, die nie aktualisiert wurden. Was er nicht beseitigt, ist das Spaltungsrisiko: Wenn der größte Teil der Hashrate weiterhin nicht konforme Blöcke mint, hat die durchsetzende Seite weniger aufgelaufene Arbeit, und die beiden Ketten bestehen nebeneinander, bis eine Seite nachgibt.
BIP-8 machte den Ansatz später zu einem allgemeinen Parametersatz. Es zählt Signale so wie BIP-9, fügt aber lockinontimeout hinzu, meist LOT geschrieben. Ist LOT auf false gesetzt, läuft das Deployment einfach aus, wenn die Miner den Schwellenwert nie erreichen. Ist LOT auf true gesetzt, wird es unabhängig davon zur Timeout-Höhe festgeschrieben, was ein nutzeraktivierter Soft Fork als Konfigurationsschalter ist.
Wo er auftritt
Die 2017-Sequenz ist das einzige abgeschlossene Beispiel auf Bitcoin, und es lohnt sich, sie der Reihe nach zu kennen. BIP-148 wurde im März 2017 von einem Entwickler unter dem Namen Shaolin Fry veröffentlicht und im Laufe des Frühjahrs von Node-Betreibern aufgegriffen. Angesichts einer Frist im August nahmen die Miner im Juli BIP-91 an, um die SegWit-Signalisierung untereinander verpflichtend zu machen. SegWit wurde dann bei Block 479.808 am 8. August 2017 festgeschrieben und bei Block 481.824 am 24. August 2017 durchsetzbar. Der Stichtag kam ohne dauerhafte Spaltung, weil das von ihm verlangte Ergebnis bereits gesichert war.
Vor Taproot tauchte der Ansatz erneut auf. Ende 2020 und Anfang 2021 drehte sich die Diskussion ganz darum, ob BIP-8 mit LOT true oder false ausgeliefert werden sollte, ein alternativer Client mit LOT true wurde veröffentlicht, und der Kompromiss war Speedy Trial, der ein kurzes Zeitfenster ohne erzwungene Aktivierung festlegte. Die Miner erreichten den Schwellenwert im Juni 2021, sodass die Frage nie auf die Probe gestellt wurde.
Wenn Sie Bitcoin halten, ist die relevante Erkenntnis, dass der Betrieb eines eigenen Nodes all dem Gewicht verleiht. Ein nutzeraktivierter Soft Fork zählt die Nutzer, die validieren, und jemand, dessen Guthaben vollständig auf einer Börse liegt, wird durch die Software dieser Börse vertreten, nicht durch die eigene.
Nutzeraktivierter Soft Fork vs. Hard Fork
Ein nutzeraktivierter Soft Fork verschärft die Regeln; ein Hard Fork lockert sie, und die Verwirrung im Jahr 2017 entstand daraus, dass beide ein Spaltungsrisiko trugen. Unter BIP-148 funktionierte eine alte Wallet weiter, und die entstandene Kette blieb für jede frühere Version der Software gültig, was genau das ist, was ein Hard Fork nicht versprechen kann. Das Spaltungsrisiko war vorübergehend und hing vom Verhalten der Miner ab, während die Spaltung bei einem Hard Fork vom ersten inkompatiblen Block an eingeplant ist.