Versionsbits

Ein Versionsbit steht für einen anstehenden Soft Fork und wird über ein festes Fenster von Blöcken ausgezählt. BIP-9 bietet die Bits 0 bis 28 an, und ein Deployment wird festgeschrieben, sobald 1.916 Blöcke in einem Zeitraum von 2.016 Blöcken sein Bit setzen, oder es scheitert an einem Timeout, für den ein Jahr vorgeschlagen wird. Diese Signale zu lesen ist der Weg, auf dem Sie Monate im Voraus wissen, ob eine Funktion, die Ihre Wallet möchte, zu einer Netzwerkregel wird.

Wie es funktioniert

Versionsbits laufen als Zustandsmaschine mit fünf Zuständen, die jeder Node für sich selbst berechnet, einmal pro Neuberechnungszeitraum, für jedes Deployment, das er kennt.

Die Zustände sind DEFINED, STARTED, LOCKED_IN, ACTIVE und FAILED. Jeder Block innerhalb eines Neuberechnungszeitraums von 2.016 Blöcken teilt einen Zustand, ein Übergang kann also nur auf einer Höhe landen, die ein Vielfaches von 2.016 ist. Ein Deployment verlässt DEFINED in Richtung STARTED, wenn die Median Time Past des vorherigen Blocks die konfigurierte Startzeit überschreitet, wobei die Median Time Past der Median der Zeitstempel eines Blocks und seiner zehn Vorgänger ist.

Sobald ein Deployment STARTED erreicht hat, geht ein Node genau 2.016 Vorfahren zurück und zählt die Blöcke, deren oberste drei Versionsbits 001 sind und deren Deployment-Bit gesetzt ist. Alles andere zählt als null, sodass ein Miner, der ein anderes Versionsschema verwendet, nicht versehentlich signalisieren kann. Das Mainnet benötigt 1.916 davon, das Testnet 1.512. Wird die Hürde verfehlt, bis die Median Time Past den Timeout überschreitet, geht das Deployment dauerhaft in FAILED über. BIP-9 schlägt vor, diesen Timeout 31.536.000 Sekunden, also ein Jahr, nach der Startzeit zu legen, damit ein ins Stocken geratener Vorschlag sein Bit freigibt, statt die Warteschlange für immer zu blockieren.

An einem Detail stolpern viele. Der Zustand eines Blocks hängt nie von seinem eigenen Versionsfeld ab, nur von dem seiner Vorfahren, sodass ein Miner nicht für eine Regel stimmen und die Stimme den abstimmenden Block binden kann. Die obersten drei Bits auf 001 festzulegen, begrenzt außerdem die Version eines signalisierenden Blocks auf den Bereich 0x20000000 bis 0x3FFFFFFF und lässt die Muster 010 und 011 frei für welchen Mechanismus auch immer, der die Versionsbits schließlich ersetzt.

Bits werden wiederverwendet statt verbraucht. Sobald ein Deployment aktiviert ist oder sein Timeout erreicht hat, kann sein Bit einen späteren Vorschlag tragen, nach einer Brachepause, die BIP-9 empfiehlt, damit fehlerhafte Software zuerst erkannt wird. Die Spezifikation verlangt außerdem, dass Nodes Bits verfolgen, die sie nicht erkennen, und deutlich warnen, wenn ein unbekanntes Deployment festgeschrieben wird; so warnt Sie nicht aktualisierte Software, dass eine Regel kommt, die sie nicht durchsetzen kann.

Wo Sie es sehen

Zwei Deployments sind im Mainnet von Bitcoin mit den eigenen Parametern von BIP-9 gelaufen, und die Deployment-Liste des BIP führt beide in einer Tabelle auf.

Das erste, csv genannt, nahm Bit 0 mit einer Startzeit von 2016-05-01 und einem Ablauf von 2017-05-01 und wurde bei Block 419.328 aktiv. Es bündelte BIP-68, BIP-112 und BIP-113, drei der Änderungen, die BIP-9 als solche auflistet, die zuvor gültige Transaktionen ungültig machen. Das zweite, segwit, nahm Bit 1 mit einem Fenster von 2016-11-15 bis 2017-11-15 und wurde bei Block 481.824 aktiv, innerhalb einer Frist, die es hätte verfehlen können.

Das Schema ist auch in der Mining-Infrastruktur sichtbar. BIP-9 erweiterte den Aufruf getblocktemplate um ein Array rules, das die bereits aktiven Deployments nennt, ein Objekt vbavailable, das den Namen jedes anstehenden Deployments seinem Bit zuordnet, und eine optionale Maske vbrequired mit Bits, die der Server verlangt. Ein Pool liest diese Schlüssel, um zu entscheiden, was signalisiert wird, und das ist es, was aus einer ausgelieferten Version eine Prozentzahl in der Verfolgung macht.

Versionsbits vs. Version-2-Block

Ein Version-2-Block trägt einen Zähler im Versionsfeld; Versionsbits tragen einen Bitvektor in denselben vier Bytes. Unter BIP-34 wurde das Feld als ganze Zahl verglichen, sodass nur eine Aktualisierung gleichzeitig laufen konnte und jeder Erfolg dauerhaft Werte verbrannte, die ein gültiger Block verwenden konnte. BIP-9 rechnet die Rechnung vor: Nach BIP-34, BIP-66 und BIP-65 blieben nur 0x7FFFFFFB Versionswerte übrig, was jedes Bitvektor-Schema auf 30 unabhängige Deployments begrenzt. Stattdessen machte das Festlegen der obersten drei Bits aus dem Rest 29 Spuren, die parallel laufen und wiederverwendet werden können.