In diesem Artikel haben wir versucht, die Änderungen im Bitcoin-Protokoll, die infolge des Softfork-Updates für getrennte Zeugen aufgetreten sind, im Detail zu untersuchen. Wir haben Probleme im Zusammenhang mit der Formbarkeit von Transaktionen, der Aufrechterhaltung der Abwärtskompatibilität, der Erhöhung des Durchsatzes, neuen Transaktionsserialisierungsformaten, neuen Skriptoptionen, dem Bech32-Adressformat und seinen Vorteilen, Konzepten für Gewicht, Größe und virtuelle Größe angesprochen. Darüber hinaus sind im Folgenden die wichtigsten Statistiken zur Anpassung des Updates aufgeführt und Antworten auf häufig gestellte Fragen zum Thema dieses Updates dargestellt.
Bevor Sie mit einer detaillierten Beschreibung aller Änderungen in diesem Update fortfahren, empfehlen wir Ihnen, sich mit der Hauptidee von Segregated Witness vertraut zu machen. Wörtlich wird Segregated Witness aus dem Englischen als "separater Zeuge" übersetzt. Der Bitcoin-Wettbewerb impliziert, dass der Nachweis des Eigentums an Münzen getrennt von den Transaktionsstammdaten gespeichert wird, wie in der Abbildung angegeben.
Wenn wir das gesamte Protokollupdate berücksichtigen, enthält es viele weitere Verbesserungen. Mit SegWit können Sie die Netzwerkbandbreite erhöhen, den Besitznachweis für Münzen von den übrigen Transaktionsdaten trennen, die Mängel des Transaktionsformats beheben, die mit der Möglichkeit verbunden sind, Daten in signierten Transaktionen zu ändern (Formbarkeit von Transaktionen), und gleichzeitig die Abwärtskompatibilität mit früheren Versionen des Protokolls beibehalten. Der größte Vorteil dieses Updates besteht darin, dass Sie viele sehr wichtige Off-Chain-Lösungen zusätzlich zum Bitcoin-Protokoll implementieren können.
Problem und Lösung der Formbarkeit von Transaktionen
Unter dem Strich besteht bei der Arbeit in Bitcoin die Möglichkeit, die Transaktion so zu ändern, dass sie während der Überprüfung korrekt bleibt. Diese Änderungen sind sehr geringfügig und wirken sich nicht auf die Adressen des Absenders und Empfängers aus. Sie reichen jedoch aus, um das Ergebnis des Hashs zu ändern. Mit anderen Worten, die Transaktion überträgt die Münzen an ihre vorherigen Adressen, aber der geänderte Hashwert stimmt nicht mehr mit der geänderten Transaktion mit der ursprünglichen überein.
Offensichtlich kann die oben beschriebene Situation nur bei Transaktionen auftreten, die noch keine Bestätigung erhalten haben. Ohne seine Lösung ist es unmöglich, einen zuverlässigen Betrieb von Off-Chain-Protokollen zu erreichen, einschließlich des Aufbaus von Ketten unbestätigter Transaktionen. Da beim Kompilieren einer Transaktion nicht alle Daten signiert werden (z. B. können Sie scriptSig nicht signieren), gibt es die Möglichkeit verschiedener Arten von Angriffen:
- Ändern Sie das Signaturformat . Im Bitcoin-Protokoll ist das Signaturformat nicht streng genehmigt und hängt von der Implementierung der OpenSSL-Bibliothek ab, in der das strenge Format auch für die Signatur nicht definiert ist. Ein Dritter kann die abgefangene Transaktion ändern, was zu einer Änderung des Hashwerts führt.
- Auswirkungen direkt auf scriptSig . Wie bereits erwähnt, enthält scriptSig eine Reihe von Vorgängen, mit denen überprüft werden kann, ob ein bestimmter Benutzer Eigentümer der Münzen ist. Zusätzlich zu diesen Vorgängen können Sie weitere hinzufügen. Einige harmlose Vorgänge, die nichts beeinflussen, führen zu einer Änderung des Hashwerts der Transaktion.
Auf diese Weise können Sie den Hashwert einer Transaktion ändern, ohne Zugriff auf private Schlüssel zu haben. Warum ist das Ändern eines Hashwerts so unerwünscht?
Zunächst ist zu beachten, dass es möglich ist, eine Kopie der ursprünglichen Transaktion zu erstellen, Änderungen hinzuzufügen, die die Richtigkeit der Transaktion während der Überprüfung nicht beeinträchtigen, und sie an das Netzwerk zu senden. Eine modifizierte Kopie mit einem anderen Hashwert gibt die gleichen Münzen wie das Original aus, sodass sie mit der ursprünglichen Transaktion um Bestätigung konkurrieren kann.
Off-Chain-Protokolle wurden oben erwähnt. Für ihre Implementierung ist eine Lösung für das Problem der Formbarkeit von Transaktionen erforderlich. Im Mittelpunkt ihrer Arbeit steht der Aufbau von Ketten unbestätigter Transaktionen. Das Ändern des Hashwerts der ersten Transaktion führt zur Ungültigkeit der gesamten Kette unbestätigter Transaktionen.
Mit dem SegWit-Update wurden strenge Regeln für das Ausfüllen der Felder definiert, sodass die Probleme im Zusammenhang mit der Formbarkeit von Transaktionen für Transaktionen des neuen Formats als behoben betrachtet werden können. Dadurch konnten wir Daten spezifizieren und eindeutig serialisieren, wodurch die Dualität beseitigt wurde.
Abwärtskompatibilität beim Verteilen eines Blocks über ein Netzwerk
Nach alten Regeln beträgt die maximale Blockgröße 1 MB und enthält Transaktionen mit integrierten Beweisen. Während die neuen Regeln davon ausgehen, dass die maximale Basisblockgröße 1 MB beträgt, gibt es zusätzlich eine Datenstruktur mit Beweisen. Dementsprechend überschreitet die Gesamtgröße des neuen Blocks 1 MB.
Aus Gründen der Abwärtskompatibilität ermöglichen die Protokollregeln den alten Knoten, mit neuen Blöcken zu arbeiten, sie erhalten den Block jedoch nur in der Grundkonfiguration mit einer maximalen Größe von 1 MB. Die Zeugenstruktur steht ihnen nicht zur Verfügung. Neue Knoten erhalten einen vollständigen Block mit Transaktionen und Beweisen. Die folgende Abbildung hilft Ihnen, sich mit dieser Frage vertraut zu machen.
Auf der linken Seite sehen Sie ein Diagramm der Funktionsweise des Bitcoin-Protokolls vor der Aktivierung von Segregated Witness. Der Block hatte eine maximale Größe von 1 MB und wurde in einer Form auf verschiedene Netzwerkknoten verteilt.
Da die Blockgröße begrenzt ist, ist auch die Anzahl der Transaktionen, die darin platziert werden können, begrenzt, und die Systemkapazität hängt davon ab. Als sich die Frage nach der Erhöhung des Durchsatzes stellte, suchten sie zunächst nach Möglichkeiten, die maximale Blockgröße zu erhöhen.
Möglichkeiten zur Steigerung des Durchsatzes
Betrachten Sie die beiden Hauptmethoden zur Lösung des Problems der Erhöhung des Systemdurchsatzes. Jedes Angebot wird vom Entwicklungsteam des Bitcoin-Protokolls sorgfältig geprüft und getestet. Wenn die Community eine Einigung erzielt und beschlossen hat, den Vorschlag in das Protokoll umzusetzen, wird ein Update veröffentlicht.
Hardfork Update. Die häufigste Aktualisierung besteht darin, den Block zu vergrößern. Es wird davon ausgegangen, dass eine Einheit mehr Transaktionen aufnehmen und den Durchsatz erhöhen kann. Eine solche Einheit wird jedoch von Knoten, die nach dem alten Protokoll arbeiten, nicht akzeptiert. Die Regeln besagen, dass die maximale Blockgröße 1 MV nicht überschreiten darf. Eine solche Änderung erfordert Hardfork, die organisatorisch komplexer ist als Softfork.
SoftFork-Update. Mit Segregated Witness können wir dieses Problem mit Softfork lösen. Wie genau? Es ermöglicht uns, den Block in zwei Teile zu unterteilen, von denen der erste Transaktionen speichert und der zweite Beweise enthält. Gleichzeitig empfangen die neuen Netzwerkknoten beide Teile, während die alten nur einen 1-MB-Transaktionsblock erhalten. Alte Knoten können keine Blöcke mit Beweisen empfangen und können dementsprechend die empfangenen Transaktionen nicht validieren. Dies ermöglicht ihnen jedoch, an der Konsensbildung teilzunehmen und nicht auf Hardfork zurückzugreifen, sondern schrittweise auf neue Software umzusteigen.
Innovationen getrennt Zeugnis
Überlegen Sie, was im Update für getrennte Zeugen enthalten ist. Die erste und wichtigste Neuerung von Segregated Witness ist das neue Transaktionsserialisierungsformat. Zusätzlich zu den bereits bekannten Feldern enthält die neue Transaktion drei neue Felder: marker, flag, die für die Versionierung verwendet werden. In diesem Fall sind sie streng festgelegt. In den folgenden Protokollen können sie jedoch geändert werden, ebenso wie das Zeugenfeld. Zeugen (Zeugenaussagen) sind tatsächlich eine Reihe von Nachweisen für den Besitz von Münzen, die aus dem Hauptteil der Transaktion entnommen werden. Strukturell sieht es aus wie eine Reihe von Eingaben, wobei jedes Zeugen-Datenelement einer Eingabe mit einer bestimmten Nummer entspricht, mit der Sie Beweise mit bestimmten ausgegebenen Münzen vergleichen können.
Zeugen der Transaktions-ID
Um die Transaktionskennung (Transaktions-ID, txid) zu erhalten, müssen Sie die Transaktion selbst in einem speziellen Serialisierungsformat auf eine Datensequenz bringen und dann den Hash-Wert aus dieser Datensequenz abrufen. Mit der Einführung von Segregated Witness wurden eine neue Kennung, eine Zeugen-Transaktions-ID (wtxid) und ein neues Serialisierungsformat angezeigt. Bei älteren Transaktionen, bei denen Geld ausgegeben wird, ohne dass Segregated Witness verwendet wird, ist wtxid mit txid identisch, da Segregated Witness keine neuen Felder hinzugefügt werden.
Wtxid wird benötigt, um einen alternativen Merkle-Baum für Beweise zu erstellen. Es wird auf die gleiche Weise wie bei normalen Transaktionen erstellt, anstelle des Transaktions-Hash wird nur wtxid verwendet. Dementsprechend werden wtxid paarweise gehasht und führen zur Merkle-Wurzel.
Es ist wichtig zu beachten, dass Merkle root in eine Coinbase-Transaktion und nicht in den Block-Header eingefügt wird. Wenn sich root im Blockheader befindet, ändert sich die Struktur des Blocks. Knoten, die das alte Protokoll unterstützen, konnten mit solchen Blöcken nicht funktionieren. Und alle Bemühungen, die Abwärtskompatibilität aufrechtzuerhalten, würden dieser Inkonsistenz entgegenstehen. Daher wird root in einen der Ausgänge der Coinbase-Transaktion eingefügt. Wenn alle Knoten zu Segregated Witness wechseln, kann sich diese Situation ändern und neue Ansätze werden in Betracht gezogen.
Zeugenprogramme zur Festlegung der Bedingungen für das Ausgeben von Münzen
Schauen wir uns an, wie das Segregated Witness-Transaktionsskript erstellt wird und wie ältere Netzwerkknoten verstehen, dass Segregated Witness-Transaktionen korrekt sind, obwohl sie keinen Nachweis über den Besitz von Münzen erhalten.
Das Skript, das die Regeln für das Ausgeben von Münzen aus einer Transaktion im neuen Format beschreibt, besteht aus zwei Teilen. Der erste Teil ist das Zeugenversionsbyte (das Byte, das die Version des Zeugenprogramms angibt). Es kann Werte von 0 bis 16 annehmen (OP0-OP16), jetzt wird OP0 verwendet. In Zukunft werden möglicherweise neue Versionen des Protokolls mit Unterstützung für andere Versionen des Zeugenprogramms angezeigt. Der zweite Teil ist das Zeugenprogramm. Dieser Teil kann eine Größe von 2 bis 40 Bytes haben.
Das Zeugenprogramm ist das Ergebnis eines Hash-Skripts. Das Zeugen-Skript selbst enthält eine vollständige Beschreibung der Bedingungen für das Ausgeben von Münzen. Die Zeugenaussagen enthalten einen Eigentumsnachweis für Münzen, die die Bedingungen im Zeugenschrift erfüllen müssen. Dementsprechend bestehen Zeugenaussagen immer aus zwei Teilen: einem Zeugenskript und einem Eigentumsnachweis für Münzen.
Es ist erwähnenswert, dass das Zeugenprogramm keine Operationen enthält (übereinstimmende Hashwerte, Überprüfung elektronischer Signaturen) und das Skript selbst mit dem OP0-Code beginnt. Daher ist es für alle alten Knoten gültig. Darüber hinaus prüfen Knoten, die nicht auf SegWit aktualisiert wurden, nicht den Besitznachweis für Münzen auf neue Formatausgaben. Sie betrachten eine solche Verschwendung in jedem Fall als korrekt. Streng genommen akzeptieren alte Knoten Transaktionen eines neuen Formats, auch wenn der Absender die entsprechenden Münzen nicht besitzt. Aus diesem Grund verlangt SegWit, dass die Besitzer der meisten Bitcoin-Mining-Energie dieses Update akzeptieren. Eine weitere Funktion ist, dass das scriptSig einer Transaktion, die Münzen aus der Ausgabe des neuen Formats ausgibt, leer ist.
Neue Optionen zum Festlegen der Bedingungen für das Ausgeben von Münzen
Mit der Einführung von SegWit wurden zwei Standardformate für scriptPubKey vorgeschlagen, die eine Alternative zu den beiden gängigsten Formaten zum Festlegen von Regeln für den Münzausgaben darstellten, bevor dieses Update veröffentlicht wurde. Betrachten wir sie der Reihe nach.
Pay-to-Zeuge-Hash für öffentliche Schlüssel (P2WPKH) ist ein Analogon zum Standard-Hash für Pay-to-Public-Key. Was ist der Unterschied? Wie bereits erwähnt, ist scriptSig nicht ausgefüllt und bleibt leer. Alle Eigentumsnachweise für Münzen werden an die Zeugen-Datenstruktur übertragen.
In diesem Fall wird das zuvor berücksichtigte Skript, die Version und der Hash des öffentlichen Schlüssels, bei dem es sich um das Zeugenprogramm handelt, in scriptPubKey eingefügt. Ein Knoten im Netzwerk unterscheidet ein solches Ausgabenskript von anderen, da es eine Version von eins und eine Datengröße von 20 Byte hat. Eine andere Version und eine andere Größe haben andere Ausgabenregeln.
In diesem Fall besteht scriptPubKey aus zwei Teilen: Die Zeugenversionsnummer ist Null und der Hashwert des öffentlichen Schlüssels des Empfängers. ScriptSig ist leer und die Zeugenangaben enthalten eine elektronische Signatur und einen öffentlichen Schlüssel zur Überprüfung.
Pay-to-Zeuge-Skript-Hash (P2WSH) ist ein Analogon zum Standard-Pay-to-Script-Hash. In diesem Fall kann ein benutzerdefiniertes Skript verwendet werden, um die Regeln für das Ausgeben von Münzen festzulegen. Wie unterscheidet ein Host ein solches Skript vom vorherigen? In diesem Fall hat die Version immer noch den Wert Eins, und das Zeugenprogramm benötigt 32 Byte und ist ein Hashwert aus dem Zeugenskript. Wenn eine Transaktion zu einem Host kommt, der ein Skript mit der ersten Version enthält, dessen Größe jedoch von den Werten von 20 oder 32 Byte abweicht, lehnt der Host diese Transaktion ab, da er nicht weiß, wie er damit arbeiten soll.
Die Daten der Zeugen sind hier in zwei Teile unterteilt. Die erste enthält eine Reihe von Nachweisen für den Besitz von Münzen, dh eine Reihe von Unterschriften. Im zweiten Teil wird ein Zeugen-Skript platziert, dessen Inhalt nur die Regeln für das Ausgeben von Münzen festlegt. In diesem Fall wird es jedoch zum Zeitpunkt der Ausgabe und zum Zeitpunkt des Versendens der Münzen angegeben. Der Hash-Wert wurde angegeben.
In diesem Fall besteht scriptPubKey aus zwei Teilen: Die Zeugenzahl der Version ist Null und der Hashwert des Zeugenskripts für den Fall der Mehrfachsignatur 1 von 2. ScriptSig ist leer und die Zeugenangaben enthalten die elektronische Signatur und das ursprüngliche Zeugenskript im Klartext.
P2SH-Wrapper
Das neue Skriptformat unterscheidet sich vom alten. Dementsprechend wissen alte Dienste und Brieftaschen nicht, wie sie mit diesem Skriptformat arbeiten und wie sie es erstellen sollen. Aus Gründen der Abwärtskompatibilität verwenden Segregated Witness-Transaktionen mit P2SH einen speziellen „Wrapper“, mit dem Sie eine Transaktion erstellen können, die die Eigenschaften einer Segregated Witness-Transaktion aufweist, sich jedoch nicht von der für die Außenwelt üblichen P2SH-Transaktion unterscheidet.
P2SH wird verwendet, um die Arbeit des Absenders zu vereinfachen und ihn nicht mit den Details der Implementierung des Einlöseskripts des Empfängers zu belasten. In diesem Fall gibt der Empfänger dem Absender nur den Hash-Wert "Skript einlösen", und das Skript selbst wird zusammen mit den Beweisen an scriptSig übergeben.
In diesem Fall enthält scriptPubKey eine Hash-Operation, einen Einlösungs-Scrip-Hash-Wert und eine Vergleichsoperation (wie bei der alten Version von P2SH). ScriptSig enthält hier den Hash-Wert des öffentlichen Schlüssels, und Zeugen-Daten enthalten die elektronische Signatur und den öffentlichen Schlüssel.
Mit diesem Ansatz können nicht aktualisierte digitale Geldbörsen Transaktionen an Adressen getrennter Zeugen senden, ohne etwas über die neuen Möglichkeiten zum Festlegen der Bedingungen für das Ausgeben von Münzen zu wissen.
Neues Bech32-Adressformat
Es ist erwähnenswert, Bech32-Adressen, die als native SegWit-Adressen gelten, separat zu erwähnen. Während des größten Teils seiner Geschichte hat Bitcoin die Base58-Codierung für Adressen mit einer zusätzlichen Prüfsumme verwendet. Dies ist ein abgeschnittenes Ergebnis von doppeltem Hashing mit der SHA-256-Hash-Funktion. Sie waren Teil der ursprünglichen Software und ihr Anwendungsbereich wurde in BIP13 für P2SH erweitert. Sowohl der Zeichensatz als auch der Prüfsummenalgorithmus weisen jedoch Einschränkungen auf:
- Die Adresse in Base58 belegt mehr Speicher in QR-Codes, da sie den alphanumerischen Darstellungsmodus nicht verwenden kann.
- base58 ist sehr unpraktisch, um zuverlässig auf Papier zu schreiben, über eine mobile Tastatur zu tippen oder vorzulesen.
- doppeltes Prüfsummen-Hashing ist langsam;
- Die Base58-Decodierung ist komplex und relativ langsam.
Das SegWit-Update enthält eine neue Klasse von Exits (Zeugenprogrammen) und zwei seiner Fälle: P2WPKH und P2WSH. Ihre Funktionalität ist für alte Knoten durch die Verwendung von P2SH indirekt verfügbar, es ist jedoch optimaler und sicherer, sie direkt zu verwenden. Dazu muss ein neues Adressformat eingeführt werden.
Bech32-Adressspezifikation
Die Bech32-Adresse hat eine Länge von nicht mehr als 90 Zeichen und enthält:
- Ein Teil, der für Menschen lesbar ist. Dies schließt Daten ein, die möglicherweise übertragen werden müssen oder etwas mit dem Eigentümer der Adresse zu tun haben, die mindestens 1 Zeichen lang ist. Beispielsweise sind die Zeichen für Mainnet-Adressen standardmäßig "bc" und für Testnet "tb".
- Ein Trennzeichen, das immer 1 ist. Wenn "1" innerhalb des für Menschen lesbaren Teils zulässig ist, ist das Trennzeichen das letzte der Zeichen "1".
- Der Datenteil hat eine Länge von mindestens 6 Zeichen und besteht nur aus alphanumerischen Zeichen, ausgenommen "1", "b", "i" und "o". Hier werden die Version des Zeugenprogramms und die Daten des Zeugenprogramms selbst (von 2 bis 40 Bytes) als Hauptdaten verwendet.
Warum ein Trennzeichen in Adressen einfügen? Auf diese Weise können Sie den vom Menschen lesbaren Teil eindeutig vom datenlesbaren Teil trennen und so mögliche Kollisionen mit anderen vom Menschen lesbaren Teilen vermeiden, die das Präfix verwenden. Außerdem werden Zeichensatzbeschränkungen für den vom Menschen lesbaren Teil vermieden. Das Trennzeichen ist 1, da die Verwendung eines nicht alphanumerischen Zeichens das Kopieren von Adressen erschwert (ohne Doppelklick in mehreren Anwendungen). Daher wurde ein alphanumerisches Zeichen außerhalb des Hauptzeichensatzes ausgewählt. Die Verwendung des Basis-32-Nummernsystems geht auch mit einer Erhöhung der Adresslänge um 15% im Vergleich zum Basis-58-Nummernsystem einher, dies spielt jedoch beim Kopieren von Adressen keine Rolle.
Prüfsumme Bech32 Adressen
Die letzten 6 Zeichen der Adresse sind eine Prüfsumme. Die Prüfsumme basiert auf dem BCH-Code, der die Erkennung von Fehlern garantiert, die nicht mehr als 4 Zeichen betreffen, und die Wahrscheinlichkeit, dass die Prüfsumme konvergiert, wenn mehr als 4 Fehler gemacht werden, ist eine von 109.
Einer der Vorteile der Verwendung von BCH-Codes besteht darin, dass sie zur Korrektur von Fehlern verwendet werden können. Wenn bis zu 4 Fehler in der Adresse gemacht wurden, werden diese automatisch korrigiert. Und wenn mehr Fehler gemacht werden, werden sie mit hoher Wahrscheinlichkeit erkannt, jedoch ohne die Möglichkeit ihrer automatischen Korrektur.
Groß- und Kleinschreibung in der Adresse
Kleinbuchstaben werden verwendet, wenn für eine Prüfsumme ein Zeichenwert erforderlich ist.
Bech32 . (, QR-), . , , , . , QR- , - , 45% , .
, Segregated Witness, , . Segregated Witness . 1 MB. . , .
(weight units). 3, witness data 1. , , witness data 3 , . . .
block weight = base size * 3 + total sizeblock weight – ( )
base size – ( )
total size – ( )
, , . .
, , , , 4 . Segregated Witness , .
, . (virtual size) , , , spb (satoshi per byte).
virtual size = weight units / 4Segregated Witness 4 , , . , . , . , , . , witness data (base size) 1 MB, 4 MB.
: « witness data?». . , 1 MB 4 MB. . 1.8 MB. ? 60% . 1 MB, 40% , .
400000 * 4 = 1600000600000 * 1 = 6000001600000 + 600000 = 22000004000000 / 2200000 = 1.81 MB, , 1.8 MB. , .
2018 SegWit 35% . Segregated Witness (, Electrum Bitxfy).
BitMex Research. 1 MB, 2 MB. , , SegWit .
BitMex Research, .
, Segregated Witness off-chain Bitcoin. , lightning network – SegWit, , .
Häufig gestellte Fragen
— , Segregated Witness RBF (replace-by-fee)?, replace by fee Segregated Witness , , , , sequence number . , , , , .
— ?- , . ScriptSig, , , . , , - . , , , - .
— witness data?, Segregated Witness . , , , . , . : , , ( ), , Witness data, . .
— , RFC3548 z-base-32 Bech32 ?, , . , . , .