Bitcoin Soft Fork: Braucht die Währung diese neuen OP_Codes wirklich?

Einige Entwickler drängen erneut auf einen Soft Fork, der deutlich weniger Konsens findet als frühere. Es ist nicht einfach, den Bitcoin-Code zu ändern.

Einige Entwickler drängen erneut auf einen Soft Fork, der deutlich weniger Konsens findet als die vorherigen.

Bitcoin Soft ForkEs ist nicht einfach, den Bitcoin-Code zu ändern. Wir haben den Anreiz, niemals den Teil des Codes zu ändern, der der 21-Millionen-Grenze entspricht.

Einige Entwicklungen sind dennoch notwendig, andere weitaus weniger. Leider wird es immer Entwickler geben, die ihr schlechtes Salzkorn mitbringen wollen.

Codeentwicklungen werden über „Pull Requests“ vorgeschlagen. Die meisten sind geringfügig, aber einige sind auch schwerwiegend. Sie werden dann zu BIPs (Bitcoin Improvement Proposals), die manchmal „Soft Forks“ sind.

Zur Erinnerung: Ein Hard Fork ist eine Weiterentwicklung des Codes, der mit dem alten nicht kompatibel ist. Das typische Beispiel ist BCH (Bitcoin Cash). BTC-Netzwerkknoten validieren BCH-Blöcke nicht, da sie die 1-MB-Grenze pro Block überschreiten können. Eine solche Änderung löst einen Hard Fork aus.

Im Fall eines Soft Forks existieren die beiden Codes nebeneinander auf derselben Blockchain. Dies wird als Abwärtskompatibilität bezeichnet. Beispielsweise könnten wir die Blockgröße auf 0,3 MB ändern. Dies ist weniger als die 1-MB-Grenze und somit abwärtskompatibel mit dem Originalprotokoll.

Die neuesten Soft Forks waren SegWit (2016) und Taproot (2021). Einige Entwickler drängen derzeit auf einen neuen Fork, um die Erstellung von „Covenants“ durch das Hinzufügen neuer OP_codes zu ermöglichen.

Blockstream Research hat kürzlich eine ziemlich detaillierte Zusammenfassung zu diesem Thema veröffentlicht:

Um die Mechanismen von Bitcoin-Transaktionen zu verstehen, ist es wichtig, sie zu verstehen was Bündnisse sind. Die Magie geschieht dank einer Computerausführungssprache namens „Skript“. Es ist eine sehr einfache Sprache mit einer begrenzten Anzahl von Anweisungen.

Diese Anweisungen werden OP_codes genannt. Betrachten Sie sie als kleine digitale Zahnräder, die in Gang kommen, wenn eine Transaktion validiert wird.

Konkret bedeutet die Durchführung einer Bitcoin-Transaktion, aus einem (oder mehreren) anderen „utxo“ ein „utxo“ zu erstellen, das dabei zerstört wird. Ein utxo ist ein Stück Code (ein Skript), das eine Menge Bitcoins mathematisch mit einer Bitcoin-Adresse (einem öffentlichen Schlüssel) verknüpft.

Im Wesentlichen bedeutet die Durchführung einer Transaktion, den öffentlichen Schlüssel (die Bitcoin-Adresse) zu ändern, an den sich der Betrag bezieht von Bitcoins ist verknüpft.

Während einer Transaktion ist der Star-OP_code OP_CHECKSIG. Dadurch wird überprüft, ob die Signatur mit dem öffentlichen Schlüssel des ausgegebenen Utxo übereinstimmt. Wenn alles in Ordnung ist, wird ein neues Utxo erstellt, das den öffentlichen Schlüssel des Empfängers enthält.

Insgesamt handelt es sich bei Bitcoin Script um eine eher einfache „stacked based“ Programmiersprache, die das Feld der Möglichkeiten einschränkt.

Blockstream schreibt dazu:

“ Nach derzeitigem Stand ist es nicht möglich, vorab zu konfigurieren, wie Bitcoins aus einem utxo ausgegeben werden können oder mit welcher Geschwindigkeit sie ausgegeben werden können. Die einzige Lösung besteht darin, PSBTs (teilweise signierte Bitcoin-Transaktionen) zu verwenden, die neben anderen Einschränkungen keine Transaktionsgebühren richtig einschließen können.“ Einschränkungen in seiner Fähigkeit, die grundlegendsten Smart Contracts zu unterstützen.“

Mehr Arithmetik im Stapel „Stackbasiert“ bedeutet, dass die für die Transaktionsmechanik benötigten Daten in einem „Stapel“ abgelegt werden, in dem logische Operationen ausgeführt werden.

Beispiel für einen Transaktionsüberprüfungsmechanismus:

Der OP_code OP_DUP dupliziert die Öffentlichkeit Schlüssel eines utxo und legen Sie ihn in den Stapel.

Der OP_code OP_HASH hasht diesen Schlüssel (wodurch er in eine Adresse umgewandelt wird, mit der die Bitcoins im utxo mathematisch verknüpft wurden)

OP_EQUALVERIFY überprüft, ob der resultierende Hash tatsächlich zu dem gehört utxo in Frage.

OP_CHECKSIG überprüft, ob die bereitgestellte Signatur mit dem öffentlichen Schlüssel des utxo übereinstimmt.

Bitcoin Script hat knapp 100 nicht triviale OP_codes. Es ist jedoch nicht möglich, Daten im Stapel zu multiplizieren, zu dividieren oder zu verketten (kombinieren).

Satoshi hat 2010 mehrere OP_codes deaktiviert (OP_OR, OP_MUL [multiplizieren], OP_DIV [dividieren] und OP_CAT [verketten]). Diese OP_codes wurden entfernt, weil ihre ursprünglichen Implementierungen ausnutzbare Schwachstellen aufwiesen, die die Netzwerksicherheit gefährden könnten.

Ihr Fehlen macht es jedoch schwierig, bestimmte exotische Ausgabebedingungen (intelligente Verträge) zu schaffen. Insbesondere die Unfähigkeit, Ausgabenbedingungen im utxo basierend auf Transaktionsdaten zu definieren.

Blockstream erklärt:

„Wenn das Skript die Möglichkeit hätte, mehr Details in Transaktionsdaten zu interpretieren, könnten wir viel robustere Verträge erstellen, die bestimmte Ausgaben ermöglichen.“ Bedingungen."

VereinbarungenDerzeit ist der einzige „intelligente Vertrag“, der mit Bitcoin möglich ist, einfach der klassische Vorgang des Sperrens und Entsperrens von Bitcoins, die mit einem öffentlichen Schlüssel verknüpft sind. Im Wesentlichen eine Transaktion durchführen.

Vereinbarungen zielen darauf ab, eine neue Art von Utxo zu schaffen, die es dem Absender einer Transaktion ermöglicht, bestimmte Bedingungen festzulegen, wie der Empfänger die Bitcoins anschließend ausgeben kann.

Hier sind zwei OP_Codes, die unter dem Begriff „Verpflichtungen“ zusammengefasst sind ” mit begrenzten Fähigkeiten, die

Das obige ist der detaillierte Inhalt vonBitcoin Soft Fork: Braucht die Währung diese neuen OP_Codes wirklich?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!