Haupterkundungen und Konflikte der ursprünglichen Technologie von Bitcoin

Die ursprüngliche Technologie von Bitcoin stand immer vor Konflikten zwischen ihrer Fähigkeit zur Massenadoption und der Funktionalität, die sie besitzen sollte. Bedeutet Skalierung und Transaktionsvolumen mehr komplexe Transaktionsbefehle und einen größeren Transaktionsraum? Bedeutet es, dass alle Funktionen auf einem einzigen Bitcoin-System implementiert werden müssen? In den Anfangstagen schienen diese Probleme inherent für Bitcoin selbst zu sein, als die Entwicklung der Bitcoin-Ökosystemtechnologie jedoch unvollständig war. Mittlerweile sind viele dieser Probleme jedoch klarer geworden.

Dieser Artikel listet einige der damit verbundenen Probleme sowie die Prozesse auf, durch die sie entstanden und angegangen wurden. Durch diesen Artikel kann man die Verbindung zwischen diesen Problemen und der Technologie sowie den Änderungen in der Hauptkette von Bitcoin und den zugehörigen "Testketten" erkennen. Die Technologie von Bitcoin wurde kontinuierlich von verschiedenen Projekten und Teams (einschließlich Ethereum, das eine Erforschung der Unvollkommenheiten von Bitcoin darstellt) erkundet. Allerdings waren die Veränderungen im Hauptnetz von Bitcoin bis zum Aufkommen von Technologien wie Taproot nicht sehr offensichtlich, was die Entwicklung von Protokollen wie Ordinals anregte und zu einer neuen Überspannung in der Entwicklung führte.

Aus einer breiteren Perspektive betrachtet, können wir anhand dieser Entwicklungen und der von ihnen hervorgebrachten Technologien ihre Verbindungen erkennen und weitere Entwicklungsmöglichkeiten sowie die Gesamtarchitektur ableiten.

1.1 Bitcoins Skripting-Sprache und mehrere Anweisungsreduktionen

Die Programmiersprache von Bitcoin ist eine stapelbasierte Skriptsprache, die die Umgekehrte Polnische Notation verwendet und über keine Schleifen- und bedingten Kontrollanweisungen verfügt (spätere Erweiterungen wie Taproot & Taproot Script haben diese Fähigkeit verbessert). Daher wird oft gesagt, dass die Skriptsprache von Bitcoin nicht turingvollständig ist und ihre Fähigkeiten begrenzt sind.

Aufgrund dieser Einschränkungen können Hacker diese Skriptsprache nicht verwenden, um unendliche Schleifen zu schreiben (die das Netzwerk lahmlegen würden) oder Code, der zu DOS-Angriffen führen könnte, wodurch das Bitcoin-Netzwerk vor DOS-Angriffen geschützt wird. Bitcoin-Entwickler sind auch der Ansicht, dass die Kern-Blockchain keine turingvollständigkeit haben sollte, um bestimmte Angriffe und Netzwerküberlastung zu vermeiden.

Diese Einschränkungen bedeuten jedoch, dass das Bitcoin-Netzwerk keine anderen komplexen Programme ausführen oder einige „nützliche“ Funktionen ausführen kann. Nachfolgende Blockchain-Systeme, die entwickelt wurden, um spezifische Probleme zu lösen und Benutzeranforderungen zu erfüllen, haben diesen Aspekt geändert. Zum Beispiel ist die von Ethereum verwendete Sprache Turing-vollständig.

Gängige Arten von Bitcoin-Skriptanweisungen sind zum Beispiel:

Stichwörter:

1. Konstanten. z.B. OP_0, OP_FALSE

2. Flusssteuerung. z.B., OP_IF, OP_NOTIF, OP_ELSE, usw.

3. Stack-Operationen. z.B. OP_TOALTSTACK (schiebt die Eingabe auf den Hilfsstack und entfernt sie vom Hauptstack), usw.

4. Stringoperationen. z. B. OP_CAT (verkettet zwei Zeichenfolgen, deaktiviert), OP_SIZE (schiebt die Länge des obersten Stapellements Zeichenfolge auf den Stapel, ohne das Element zu entfernen)

5. Bitweise Logik. z.B., OP_AND, OP_OR, OP_XOR

6. Arithmetische Logik. z.B. OP_1ADD (fügt 1 zur Eingabe hinzu), OP_1SUB (subtrahiert 1 von der Eingabe)

7. Kryptographie. z.B., OP_SHA1 (hashes Eingabe mit SHA-1 Algorithmus), OP_CHECKSIG

8. Pseudo-Schlüsselwörter

9. Reservierte Schlüsselwörter

Häufige Arten von Bitcoin-Skript:

1. Standardtransaktion, die an eine Bitcoin-Adresse (Pay-to-Pubkey-Hash) gezahlt wird

2. Standard Bitcoin-Prägetransaktion (Zahlung an den öffentlichen Schlüssel)

3. Nachweislich nicht ausgebare / löschbare Ausgaben

4. Jeder-kann-ausgeben Ausgänge

5. Puzzle-Transaktion

Die fünf Standardtypen von Transaktionsskripten umfassen: Zahlungen an den öffentlichen Schlüssel-Hash (P2PKH), Zahlungen an den öffentlichen Schlüssel, Multisig (begrenzt auf maximal 15 Schlüssel), Zahlungen an den Skript-Hash (P2SH) und Datenausgaben (OP_RETURN).

Für weitere detaillierte Informationen zur Bitcoin-Skripting können Sie besuchen: Bitcoin Wiki - Skript.

Reduzierung der unterstützten Anweisungen in Bitcoin

Historisch gesehen hat Bitcoin mehrere Reduzierungen bei unterstützten Anweisungen durchlaufen. In der folgenden Tabelle sind die roten Teile Anweisungen, die entfernt wurden.

• Zeichenoperationen

（2）

(3) Rechenoperationen

Warum Anweisungen reduzieren? Sicherheit ist nur ein Aspekt, der berücksichtigt werden muss. Wenn wir die Reduzierung von Anweisungen durch die Brille des schichtweisen Designs betrachten, können wir ihre Rationalität verstehen und es ermöglichen, dass das Basissystem grundlegender und stabiler wird. Vielleicht war sich Satoshi Nakamoto von Anfang an dieses Problems bewusst, weshalb er aktiv Anweisungen reduzierte. Gewöhnliches Denken besteht darin, ein kleines System aufzubauen, das die Benutzerbedürfnisse direkt mit vollständigen Befehlen und Systemfunktionen erfüllt, anstatt ein großes Protokoll zu erstellen, das Zusammenarbeit erfordert.

Dies führt auch zu einer Tatsache: Nur Bitcoin eignet sich als Netzwerk der ersten Ebene. Ich habe dieses Phänomen im Artikel "Hohe Bitcoin-Preise könnten das Aufkommen einer neuen alternativen Kette fördern" analysiert, unter Berücksichtigung sowohl wirtschaftlicher als auch technischer Aspekte sowie der Möglichkeit des Aufkommens einer alternativen Bitcoin-Kette. Jedoch können nach den grundlegenden Eigenschaften von Bitcoin und der Perspektive des schichtweisen Designs fast nur Bitcoin als Infrastruktur für ein Netzwerk der ersten Ebene dienen; selbst wenn es alternative Ketten gibt, wären sie ein Produkt der 1,5. Ebene. Auf der Ebene der ersten Ebene ist das Original nur Bitcoin, und höchstens können andere Ketten als alternative Waren von geringerer Qualität dienen.

1.2. Bitcoin-Fork-Geschichte, Gründe und Bedeutung

In der Geschichte der Bitcoin-Entwicklung ist neben dem Problem der Reduzierung von Anweisungen ein weiterer Aspekt die Debatte über die Blockgröße, die oft zu Hard Forks von Bitcoin führt.

Als BTC gegründet wurde, gab es keine Blockgrößenbeschränkung, um eine bestimmte Anzahl von Transaktionen innerhalb des gleichen Zeitraums zu verarbeiten. Allerdings, als die frühen BTC-Preise sehr niedrig waren, war auch der Preis für böswillige Transaktionen sehr niedrig. Um dieses Problem zu lösen, führte Satoshi Nakamoto am 12. September 2010 eine Softfork durch, bei der eine Begrenzung eingeführt wurde, dass Blöcke nicht größer als 1 MB sein dürfen. Satoshi bemerkte, dass diese Beschränkung vorübergehend sei und dass in Zukunft die Blockgrenze kontrolliert und allmählich erhöht werden könne, um den Bedarf an Erweiterung zu decken.

Mit der Popularität von Bitcoin ist das Problem der Netzwerktransaktionsüberlastung und der erhöhten Bestätigungszeiten zunehmend ernst geworden. Im Jahr 2015 kündigten Gavin Andresen und Mike Hearn an, dass sie den BIP-101-Vorschlag in der neuen Version von BitcoinXT umsetzen würden, in der Hoffnung, die Blockgrößenbeschränkung auf 8 MB zu erhöhen. Allerdings widersetzten sich Kernentwickler wie Greg Maxell, Luke Jr. und Pieter Wuille diesem Vorhaben und argumentierten, dass dies die Hürde für den Betrieb eines Full Nodes erhöhen und unkontrollierbare Auswirkungen haben könnte. Diese Debatte weitete sich schließlich sowohl in ihrem Umfang als auch in der Beteiligung aus.

Aus dem obigen Inhalt sehen wir, dass auch Satoshi Nakamoto ausdrückte, dass „die Blockgrößenbeschränkung eine vorübergehende Einschränkung ist, die in Zukunft kontrolliert und allmählich erhöht werden kann, um den Bedarf an Expansion zu decken.“ Aber wann wird eine Abspaltung größere Blöcke unterstützen, und kann das Abspalten einer separaten Kette zur Unterstützung großer Blöcke das Problem lösen? Inmitten anhaltender Kontroversen sind zahlreiche Fälle aufgetreten. Beispielsweise beträgt die BCH-Blockgröße 8 MB, später auf 32 MB erhöht. BSV hat eine Blockgröße von 128 MB. Abgesehen von BCH (und später BSV) sah dieser Zeitraum auch viele andere BTC-Forks; laut BitMEXResearch erschienen im Jahr nach der BCH-Abspaltung allein mindestens 50 neue geforkte Münzen.

Späterer Inhalt wird zeigen, dass auf dem Bitcoin-Hauptnetzwerk Segwit und Taproot den Blockraum auch in gewissem Maße von 1 MB auf 4 MB erhöht haben.

Bitcoins Gabeln sind eine Form der Entwicklungserkundung, die versucht, eine breitere Palette von Bedürfnissen durch Veränderungen innerhalb ihres eigenen Bereichs zu erfüllen, einschließlich der Bedürfnisse von Benutzern, Minern, Investoren, Entwicklern und mehr.

1.3. Mehrere typische Erkundungen in der Entwicklung von Bitcoin

Nachdem Satoshi Nakamoto gegangen war, übernahm sein Nachfolger Gavin Andresen die Führung bei der Gründung von Bitcoin Core und der Bitcoin Foundation. In dieser Zeit wurden Untersuchungen zur Skalierbarkeit von BTC, insbesondere im Bereich der Vermögensausgabe, fortgesetzt.

(1) Colored Coins (染色币)

Yoni Assia, CEO von eToro, schlug erstmals das Konzept der farbigen Münzen in einem am 27. März 2012 veröffentlichten Artikel vor. Diese Idee entwickelte sich weiter und begann, Form anzunehmen und Aufmerksamkeit in Foren wie Bitcointalk zu erregen. Schließlich veröffentlichte Meni Rosenfeld am 4. Dezember 2012 ein ausführliches Whitepaper zu farbigen Münzen.

Die Idee hinter farbigen Münzen besteht darin, eine breitere Palette von Vermögenswerten und Werten darzustellen, indem spezielle Markierungen (d. h. Färbungen) zu bestimmten Teilen von Bitcoin hinzugefügt werden. In der Umsetzung sind farbige Münzen in mehreren Entitäten aufgetaucht, die grob in zwei Kategorien unterteilt sind:

1) Basierend auf OP_RETURN: Wie von Flavien Charlon im Jahr 2013 vorgeschlagen, wird Open Assets verwendet, das OP_RETURN nutzt (eingeführt in Bitcoin v0.9.0, um eine kleine Menge Daten auf Bitcoin zu speichern, ursprünglich auf 40 Bytes begrenzt, später auf 80 Bytes erhöht). Der Opcode wird im Skript gespeichert und das 'Einfärben' und Transaktionen werden durch externes Lesen abgeschlossen (Dieses Modell ähnelt Ordinals, die sich auf einen externen Index verlassen, um die Rechtmäßigkeit von Vermögenswerten zu bestimmen).

2) Basierend auf OP_RETURN: Ein typisches Beispiel ist das EPOBC-Protokoll, das 2014 von ChromaWay vorgeschlagen wurde, bei dem zusätzliche Informationen zu EPOBC-Vermögenswerten im nSequence-Feld von Bitcoin-Transaktionen gespeichert werden und die Kategorie und Legitimität jedes EPOBC-Vermögenswerts bis zur Ursprungstransaktion zurückverfolgt werden müssen, um festgelegt zu werden.

(2) MasterCoin (OMNI)

Am 6. Januar 2012 veröffentlichte JR Willett das Konzept von MasterCoin und nannte es „Das zweite Bitcoin-Whitepaper“. Das Projekt wurde im Juli 2013 offiziell durch einen ICO gestartet und sammelte schließlich 5120 BTC (damals im Wert von 500.000 $). Der Unterschied zwischen MasterCoin und Colored Coins liegt darin, dass es eine vollständige Knotenschicht etablierte, die eine Statusmodell-Datenbank durch Scannen von Bitcoin-Blöcken aufrechterhält, die sich in Knoten außerhalb der Blockchain befinden. Dieses Design bietet komplexere Funktionen als Colored Coins, wie z. B. die Erstellung neuer Vermögenswerte, dezentrale Börsen und automatisierte Preismechanismen. Im Jahr 2014 startete auch Tether den Stablecoin namens Tether USD (OMNI) auf Bitcoin über das Mastercoin-Protokoll.

(3) Gegenpartei

Counterparty wurde offiziell im Jahr 2014 gestartet. Wie Colored Coins verwendet Counterparty auch OP_RETURN, um Daten im BTC-Netzwerk zu speichern. Im Gegensatz zu Colored Coins existieren Vermögenswerte in Counterparty jedoch nicht in Form von UTXOs, sondern die Informationen werden über OP_RETURN geladen, um Asset-Transfers anzuzeigen. Wenn ein Asset-Inhaber eine Transaktion unterzeichnen, die spezielle Daten mit der Halteadresse enthält, wird das Asset übertragen. Durch diese Methode kann Counterparty Asset-Emittierung, Handel und eine Plattform, die mit Ethereum Smart Contracts kompatibel ist, implementieren.

Zusätzlich betrachten einige Ansichten auch Ethereum, Ripple und BitShares als Teil eines breiteren „Bitcoin 2.0“.

1.4 Unvollkommenheiten von Bitcoin und geschichteten Protokollen

Die Unvollkommenheiten (oder Einschränkungen) von Bitcoin zeigen sich hauptsächlich in mehreren Aspekten (die in diesem Artikel erwähnten Unvollkommenheiten basieren auf der Zusammenfassung im Ethereum-Whitepaper und sind nicht unbedingt wahre Mängel).

1. Bitcoins UTXO-Kontosystem

In aktuellen Blockchain-Projekten gibt es hauptsächlich zwei Arten von Aufzeichnungsmethoden: das Konto/Guthaben-Modell und das UTXO-Modell. Bitcoin verwendet das UTXO-Modell, während Ethereum, EOS und andere das Konto/Guthaben-Modell verwenden.

In einer Bitcoin-Brieftasche können wir normalerweise den Kontostand sehen; jedoch gab es in Satoshi Nakamotos ursprünglichem Design des Bitcoin-Systems kein Konzept von einem "Kontostand." Der "Bitcoin-Kontostand" ist eine Ableitung von Bitcoin-Brieftaschenanwendungen. UTXO (Unspent Transaction Outputs) repräsentiert ungenutzte Transaktionsausgänge und ist ein Kernkonzept bei der Generierung und Überprüfung von Bitcoin-Transaktionen. Transaktionen bilden eine kettenartige Struktur, in der alle legitimen Bitcoin-Transaktionen auf Ausgänge von einer oder mehreren vorherigen Transaktionen zurückverfolgt werden können. Diese Ketten beginnen mit Mining-Belohnungen und enden mit aktuellen ungenutzten Transaktionsausgängen.

Daher gibt es in der realen Welt keine Bitcoins, nur UTXOs. Bitcoin-Transaktionen bestehen aus Transaktionseingängen und -ausgängen; jede Transaktion gibt einen Eingang aus, um einen Ausgang zu erzeugen, der dann zum „unspent transaction output“ oder UTXO wird.

Die Implementierung von Smart Contracts stellt bedeutende Herausforderungen mit dem UTXO-Modell dar. Gavin Wood, der Designer des Ethereum Yellow Paper, hat ein tiefes Verständnis für UTXO. Das bedeutendste neue Feature von Ethereum sind Smart Contracts. Aufgrund von Smart Contracts ist es für Gavin Wood schwierig, Turing-vollständige Smart Contracts basierend auf UTXO zu implementieren. Das Account-Modell, das von Natur aus objektorientiert ist, zeichnet jede Transaktion auf dem entsprechenden Konto auf (Nonce++). Zur Vereinfachung des Kontomanagements wird ein globaler Zustand eingeführt, in dem jede Transaktion diesen globalen Zustand verändert, ähnlich wie jede kleine Veränderung die reale Welt beeinflusst. Daher basieren Ethereum und nachfolgende öffentliche Blockchains im Allgemeinen auf verschiedenen Arten von Kontosystemen.

Ein weiterer schwerwiegender Mangel von UTXO ist seine Unfähigkeit, eine feine Kontrolle über die Abhebungslimits des Kontos zu bieten, was im Ethereum-Whitepaper diskutiert wird.

1. Bitcoins Skriptsprache, nicht Turing-vollständig

Obwohl die Skriptsprache von Bitcoin verschiedene Berechnungen unterstützen kann, kann sie nicht alle Berechnungen unterstützen. Die Hauptauslassung besteht darin, dass die Skriptsprache von Bitcoin keine Schleifenanweisungen und bedingten Steuerungsanweisungen unterstützt. Daher ist die Skriptsprache von Bitcoin nicht turingvollständig und beschränkt ihre Fähigkeiten. Diese Einschränkungen verhindern jedoch, dass Hacker diese Skriptsprache verwenden, um endlose Schleifen (die das Netzwerk lahmlegen könnten) oder bösartigen Code zu erstellen, der zu DOS-Angriffen führen könnte, und schützen somit das Bitcoin-Netzwerk vor DOS-Angriffen. Die Bitcoin-Entwickler sind auch der Meinung, dass die Kern-Blockchain nicht turingvollständig sein sollte, um Angriffe und Netzwerküberlastungen zu verhindern. Die Begründung, dass eine nicht turingvollständige Sprache sicherer ist, ist jedoch unzureichend, und eine solche Sprache kann nur begrenzte Funktionen ausführen.

1. Andere Unvollkommenheiten von Bitcoin: Sicherheit, Skalierbarkeit

Die Zentralisierung des Minings ist ein Problem, bei dem der Mining-Algorithmus von Bitcoin es im Wesentlichen ermöglicht, dass Miner geringfügige Änderungen am Block-Header Millionen von Malen vornehmen, bis der Hash der modifizierten Version eines Knotens kleiner als der Zielwert ist. Dieser Mining-Algorithmus ist anfällig für zwei Formen von Zentralisierungsangriffen. Erstens wird das Mining-Ökosystem von ASICs (Anwendungsspezifischen Integrierten Schaltungen) und Computerchips kontrolliert, die speziell für das Bitcoin-Mining entwickelt wurden und Tausende Male effizienter bei dieser Aufgabe sind. Das bedeutet, dass das Bitcoin-Mining nicht mehr hochgradig dezentralisiert und egalitär ist, sondern eine erhebliche Kapitalbeteiligung erfordert. Zweitens validieren die meisten Bitcoin-Miner die Blöcke nicht mehr lokal, sondern verlassen sich auf zentralisierte Mining-Pools, um die Block-Header bereitzustellen. Dieses Problem ist erheblich: Derzeit kontrollieren die drei größten Mining-Pools indirekt etwa 50% der Rechenleistung im Bitcoin-Netzwerk.

Skalierbarkeit ist ein wichtiges Thema für Bitcoin. Bei Verwendung von Bitcoin wächst die Datenmenge um etwa 1 MB pro Stunde. Wenn das Bitcoin-Netzwerk wie Visa 2000 Transaktionen pro Sekunde verarbeiten würde, würde es alle drei Sekunden um 1 MB wachsen (1 GB pro Stunde, 8 TB pro Jahr). Auch niedrigere Transaktionszahlen haben innerhalb der Bitcoin-Community Kontroversen ausgelöst, da größere Blockchains die Leistung verbessern können, jedoch auf Kosten der Zentralisierung.

Von einem Produktlebenszyklus-Perspektive können einige der geringfügigen Unvollkommenheiten von Bitcoin innerhalb seines eigenen Systems verbessert werden, die durch das aktuelle System eingeschränkt sind. Diese Probleme können jedoch ohne Berücksichtigung der Einschränkungen des alten Systems gelöst werden, wenn sie in einem neuen System angesprochen werden. Wenn ein neues Blockchain-System entwickelt wird, sollten auch diese geringfügigen funktionalen Verbesserungen entworfen und aktualisiert werden.

Schichtdesign

Schichtdesign ist eine Methodik und ein Ansatz, den Menschen verwenden, um komplexe Systeme zu behandeln, indem sie ein System in mehrere hierarchische Strukturen unterteilen und die Beziehungen und Funktionen zwischen diesen Schichten definieren, um Systemmodularität, Wartbarkeit und Skalierbarkeit zu erreichen und damit die Designeffizienz und Zuverlässigkeit des Systems zu verbessern.

Für ein breites und umfassendes Protokollsystem bieten die Verwendung von Schichten klare Vorteile. Dieser Ansatz erleichtert es den Menschen, es zu verstehen

, implementieren und verbessern Module. Zum Beispiel ist im Bereich der Computernetzwerke das ISO/OSI-Modell ein siebenschichtiges Design, aber in der Praxis können einige Schichten kombiniert werden, wie z.B. das vierlagige TCP/IP-Protokoll. Spezifische Vorteile der Protokollschichtung sind die Unabhängigkeit und Flexibilität jeder Schicht, strukturelle Teilbarkeit, einfache Implementierung und Wartung sowie die Unterstützung von Standardisierungsbemühungen.

Aus der Perspektive der geschichteten Protokolle bedeutet die Position von Bitcoin als grundlegende Schicht, dass ihre Merkmale wie UTXO, Nicht-Turing-Vollständigkeit, lange Blockzeiten, geringe Blockkapazität und das Verschwinden ihres Gründers keine Mängel, sondern eher Merkmale sind, die eine Basisnetzwerkschicht haben sollte.

Hinweis: Der Autor gibt eine ausführlichere Erklärung zur Protokollschichtung in „Ein Überblick über den Aufbau des Bitcoin Layer 2 (Layer 2) Grundlagenwissensystems V1.5.“

2. Wichtige neue Technologien in der Bitcoin-Entwicklung (Blockausweitung und Leistungserweiterung)

Im vorherigen Abschnitt haben wir die Hauptkonflikte der ursprünglichen Bitcoin-Technologie und einige explorative Fälle untersucht, von denen viele zu Hard Forks oder der Schaffung völlig neuer heterogener Ketten geführt haben. Innerhalb der eigenen Blockchain von Bitcoin haben diese Untersuchungen jedoch auch viele Ergebnisse gebracht, hauptsächlich in Form von Blockexpansion und Kapazitätsverbesserung. Diese zeigen sich hauptsächlich in den folgenden Aspekten:

2.1. OP_RETURN

Bitcoin-Entwickler haben immer versucht, die Fähigkeiten von Bitcoin zu erweitern, was sich auf verschiedene Weisen manifestiert hat:

(1) Verwendung von OP_RETURN

OP_RETURN ist ein Skript-Opcode, der verwendet wird, um ein Skript zu beenden und den obersten Wert des Stapels zurückzugeben. Dieser Opcode ähnelt der Rückgabefunktion in Programmiersprachen. Im Laufe der Geschichte von Bitcoin wurde die Funktionalität des OP_RETURN-Opcode mehrmals geändert, und er wird jetzt hauptsächlich als Methode zum Speichern von Daten im Hauptbuch verwendet. Die Funktionalität des OP_RETURN-Opcode hat in der Vergangenheit erhebliche Änderungen erfahren und ist jetzt ein wichtiges Mechanismus zum Speichern beliebiger Daten on-chain.

Ursprünglich wurde OP_RETURN verwendet, um die Ausführung des Skripts vorzeitig zu beenden, wobei das Ausführungsergebnis als oberstes Stapelobjekt dargestellt wurde. Dieser Opcode hatte anfangs eine Schwachstelle, die leicht ausgenutzt werden konnte, aber Satoshi Nakamoto hat sie schnell gepatcht.

Weitere Änderungen an der OP_RETURN-Funktionalität

Bei der Aktualisierung auf Bitcoin Core v 0.9.0 wurden „OP_RETURN output“-Skripte in einen Standardausgabetyp umgewandelt, der es Benutzern ermöglicht, Daten an „nicht auszahlbare Transaktionsausgänge“ anzuhängen. Das Datenvolumen, das in solchen Skripten verfügbar ist, war ursprünglich auf 40 Bytes begrenzt und wurde dann auf 80 Bytes erhöht.

Speichern von Daten auf der Blockchain:

Die Änderung von OP_RETURN, um immer false zurückzugeben, hatte interessante Ergebnisse. Da nach OP_RETURN keine anderen Opcodes oder Daten ausgewertet werden, begannen Netzwerkbenutzer, diesen Opcode zu verwenden, um Daten in beliebigen Formaten zu speichern.

Während der Bitcoin Cash (BCH)-Ära, vom 1. August 2017 bis zum 15. November 2018, wurde die Datenlänge, die an OP_RETURN-Ausgaben angehängt werden konnte, auf 220 Bytes erweitert, um umfangreichere Daten zu ermöglichen, die innovative Anwendungen auf der Blockchain fördern, wie z.B. das Veröffentlichen von Inhalten in sozialen Medien auf der Blockchain.

Auf BSV wurde die 220-Byte-Grenze für einen kurzen Zeitraum beibehalten. Später, im Januar 2019, weil der OP_RETURN-Opcode das Skript auf eine Weise beendet, dass Knoten keine nachfolgenden Opcodes überprüfen, überprüften Knoten auch nicht, ob das Skript innerhalb der maximalen Skriptgröße von 520 Bytes lag. Folglich beschlossen Netzwerkknotenbetreiber, das maximale Transaktionsvolumen auf 100 KB zu erhöhen, wodurch Entwicklern mehr Freiheit für Anwendungsinnovationen gewährt wurde, um neuen Anwendungen zu ermöglichen, größere und komplexere Daten in die Bitcoin-Ledger zu platzieren. Zu dieser Zeit gab es ein Anwendungsbeispiel, bei dem jemand eine gesamte Website in das BSV-Ledger gesteckt hat.

Obwohl OP_RETURN einige funktionale Erweiterungen hat, sind seine Gesamtfähigkeiten immer noch begrenzt. Dies führte zur Technologie des segregierten Zeugen.

(2) SegWit (Segregated Witness)

Segregated Witness, oder SegWit, wurde erstmals im Dezember 2015 von Pieter Wuille vorgeschlagen (Bitcoin-Kernentwickler und Mitbegründer von Blockstream) und wurde später zu Bitcoin BIP 141. SegWit modifiziert leicht die Datenstruktur von Transaktionen in Bitcoin-Blöcken, um die folgenden Probleme zu lösen:

1) Transaktionsmanipulationsproblem.

2) In SPV-Nachweisen wird die Übertragung von Transaktionssignaturen optional, was das Datenvolumen von Merkle-Nachweisen reduziert.

3) Indirekte Erhöhung der Blockkapazität.

Die ersten beiden Elemente erhöhen hauptsächlich Sicherheit und Leistung, wobei das größte Auswirkung auf neue Technologien das dritte Element darstellt, das indirekt die Blockkapazität erhöht (siehe das Konzept des Blockgewichts unten), und somit die Grundlage für die Leistungsoptimierung von Bitcoin schafft und zu weiteren Verbesserungen bei Taproot (der zweiten Version von Segregated Witness) führt.

Obwohl die Realisierung die Blockkapazität erhöhte, unterliegt SegWit immer noch Blockgrößenbeschränkungen. Die Blockgrößenbegrenzung von Bitcoin beträgt 1 M Byte, und da Zeugendaten nicht in dieser Begrenzung enthalten sind, gibt es immer noch eine Beschränkung der Gesamtblockgröße, um Missbrauch von Zeugendaten zu verhindern. Ein neues Konzept namens Blockgewicht wurde eingeführt:

Blockgewicht = Basissize * 3 + Gesamtgröße

Die Basisgröße ist die Blockgröße ohne Zeugendaten.

Die Gesamtgröße ist die Gesamtblockgröße, die gemäß BIP 144 serialisiert ist, einschließlich sowohl der Basisdaten als auch der Zeugendaten.

SegWit beschränkt Blockgewicht <= 4 M.

SegWit ermöglicht technisch gesehen auch die Erweiterung von Bitcoin zur Nutzung des Lightning-Netzwerks, was hier nicht näher erläutert wird.

(3) Taproot (Segregated Witness V2)

Wenn Sie das Wort Taproot direkt verwenden, denken viele Menschen möglicherweise, dass es sich um ein neues Konzept handelt, aber wenn Sie verstehen, dass es sich um die zweite Version des Segregated Witness handelt, werden die meisten die Verbindung erfassen. Taproot ist mit den BIPs 340, 341 und 342 verbunden, benannt: BIP 340 (Schnorr-Signaturen für secp256k1), BIP 341 (Taproot: SegWit-Version 1-Ausgaberegeln)

BIP 342 (Validierung von Taproot-Skripten).

Im November 2021 wurde Taproot offiziell als Soft Fork aktiviert. Dieses Upgrade kombiniert BIP 340, BIP 341 und BIP 342. Unter ihnen führt BIP 340 Schnorr-Signaturen ein, die gleichzeitig mehrere Transaktionen validieren können, und ersetzt den Elliptic Curve Digital Signature Algorithm (ECDSA), wodurch die Netzwerkkapazität erneut erweitert und die Verarbeitung von Stapeltransaktionen beschleunigt wird. Dies bietet Möglichkeiten für die Bereitstellung komplexer Smart Contracts. BIP 341 implementiert Merklized Abstract Syntax Trees (MAST), um die Speicherung von Transaktionsdaten auf der Blockchain zu optimieren. BIP 342 (Tapscript) verwendet Bitcoins Skriptkodierungssprache, um die nativen Skriptfähigkeiten von Bitcoin zu verbessern.

Die Raumausdehnung, die durch Segwit und Taproot verursacht wurde, führte zur Entstehung von Schnorr-Signaturen, MAST-Bäumen und Taproot-Skripten, deren Mission es ist, die Funktionalitäten des Bitcoin-Mainnets zu erweitern.

2.2 Schnorr-Signaturen, MAST und Taproot-Skripte

Aus Abschnitt 2.1 haben wir beobachtet, wie Bitcoin kontinuierlich in der Skalierung und Kapazitätserweiterung forscht, was zur Entwicklung der Taproot-Technologie führt, zusammen mit mehreren entscheidenden Technologien wie Schnorr, MAST und Taproot-Skripts, die die Fähigkeiten von Bitcoin tatsächlich erweitert haben.

(1) Schnorr Signaturen

Die Entwicklung von Taproot erforderte bei der Erweiterung der Möglichkeiten spezifische Anforderungen an den Signaturalgorithmus, wodurch Schnorr-Signaturen eingeführt wurden, um den elliptischen Kurvendigitalsignaturalgorithmus (ECDSA) zu ersetzen. Schnorr-Signaturen sind ein digitales Signierschema, das Transaktionen und Nachrichten effizient und sicher signieren kann. Sie wurden erstmals von Claus Schnorr in einem Papier von 1991 beschrieben. Schnorr wird für seine Einfachheit, nachweisbare Sicherheit und Linearität gefeiert.

Vorteile von Schnorr-Signaturen:

1) Schnorr-Signaturen bieten mehrere Vorteile, einschließlich Effizienz und verbesserte Privatsphäre, während sie alle Funktionalitäten und Sicherheitsannahmen von ECDSA beibehalten. Sie ermöglichen kleinere Signaturgrößen, schnellere Verifizierungszeiten und verbesserten Widerstand gegen bestimmte Arten von Angriffen.

2) Ein bemerkenswerter Vorteil von Schnorr-Signaturen ist die Schlüsselaggregation, die mehrere Signaturen zu einer einzigen aggregiert, die für die Summe ihrer Schlüssel gültig ist. Mit anderen Worten: Schnorr ermöglicht es mehreren kooperierenden Parteien, eine einzige Signatur zu generieren, die für die Gesamtsumme ihrer öffentlichen Schlüssel gültig ist. Die Signaturaggregation ermöglicht es, die Signaturen mehrerer Unterzeichner zu einer einzigen Signatur zu kombinieren.

Schlüsselaggregation kann Transaktionsgebühren reduzieren und die zugrunde liegende Skalierbarkeit verbessern, da elektronische Signaturen von Multisig-Setups den gleichen Platz in einem Block einnehmen wie die von Einzelparteien-Transaktionen. Diese Funktion von Schnorr kann verwendet werden, um die Größe von Multisig-Zahlungen und anderen Transaktionen im Zusammenhang mit Multisig, wie z.B. Lightning Network-Kanaltransaktionen, zu reduzieren.

3) Ein weiteres wichtiges Merkmal von Schnorr-Signaturen ist ihre Nicht-Malleabilität.

4) Schnorr bietet auch zahlreiche Datenschutzvorteile. Es macht Multisig-Schemata für externe Beobachter nicht von traditionellen Einzelschlüssel-Schemata zu unterscheiden, was es schwieriger macht, Multisig-Ausgaben von Einzel-Signatur-Ausgaben in der Blockchain zu unterscheiden. Darüber hinaus macht es Schnorr in n-von-m Multisig-Setups für externe Beobachter schwieriger zu bestimmen, welche Teilnehmer in einer Transaktion unterschrieben haben und welche nicht.

Schnorr-Signaturen werden im Rahmen des Taproot-Soft-Fork-Upgrades in BIP-340 implementiert und wurden am 14. November 2021 bei Blockhöhe 709.632 aktiviert. Schnorr macht die digitalen Signaturen von BTC schneller, sicherer und einfacher zu handhaben. Bemerkenswert ist, dass Schnorr-Signaturen abwärtskompatibel mit den kryptografischen Algorithmen von BTC sind, was es ermöglicht, sie durch ein Soft-Fork-Upgrade einzuführen.

(2) MAST Abstrakte Syntaxbäume

Es gibt eine leichte Mehrdeutigkeit bei der Abkürzung von MAST in Chinesisch und Englisch. Offiziell verwenden BIP (BIP 114) und einige Artikel die Abkürzung MAST für: Merklized Abstract Syntax Tree. Andere Quellen übersetzen Merklized Alternative Script Trees (MAST) ins Chinesische als Merklized Replacement Script Trees (MAST). In dem Buch „Mastering Bitcoin“ und einem Artikel wird diese Abkürzung verwendet: https://cointelegraph.com/learn/a-beginners-guide-to-the-Bitcoin-Taproot-upgrade.

Merklized Abstract Syntax Trees und Merklized Alternative Script Trees (MAST) scheinen die gleiche Funktion zu haben. Aus Übersetzungssicht halte ich es persönlich für am besten, die Verwendung im offiziellen Bitcoin BIP-Protokoll beizubehalten.

Das Konzept hinter MAST basiert auf zwei Ideen: Abstrakte Syntaxbäume und Merkle-Bäume.

Abstrakte Syntaxbäume (AST) gehören zum Bereich der Compiler-Prinzipien und der formalen Linguistik in der Informatik. Ein abstrakter Syntaxbaum ist eine Zwischenrepräsentation während des Kompilierungsprozesses, die verwendet wird, um die semantische Struktur des Quellcodes darzustellen. Er wandelt den Quellcode in eine Baumstruktur um, bei der jeder Knoten eine semantische Einheit darstellt und die Kanten die Beziehungen zwischen ihnen darstellen. Abstrakte Syntaxbäume spielen eine entscheidende Rolle in den Phasen der lexikalischen und syntaktischen Analyse des Compilers, um das Verständnis des Quellcodes zu erleichtern und anschließende Optimierungs- und Zielcodegenerierungsprozesse durchzuführen. Einfach ausgedrückt ist ein abstrakter Syntaxbaum (AST) eine Methode zur Beschreibung eines Programms, indem es in unabhängige Blöcke unterteilt wird, was die Analyse und Optimierung des Programms erleichtert. Um einen AST zu generieren, müssen alle Gleichungen und ihre Voraussetzungen mit Pfeilen verbunden werden, bis alle Voraussetzungen identifiziert sind. Das folgende Bild zeigt einen AST eines Skripts.

Auf der anderen Seite kann ein Merkle-Baum verwendet werden, um zu überprüfen, ob ein Element zu einem Satz gehört, ohne den gesamten Satz zu kennen. Zum Beispiel verwenden die vereinfachten Zahlungsverifizierungsbrieftaschen (SPV-Brieftaschen) von Bitcoin Merkle-Bäume, um zu überprüfen, ob eine Transaktion innerhalb eines Blocks existiert, indem sie Bandbreite sparen, indem sie nicht den gesamten Block herunterladen.

Um einen Merkle-Baum zu generieren, wird jedes Element einzeln gehasht, um einen eindeutigen Bezeichner zu erstellen; diese Bezeichner werden dann gepaart und erneut gehasht, um einen Bezeichner für dieses Paar zu erstellen; dieser Prozess wird wiederholt, bis nur noch ein Bezeichner übrig bleibt, der als „Merkle-Wurzel“ bekannt ist, ein prägnanter Bezeichner, der die gesamte Menge repräsentiert.

Beim Überprüfen, ob ein Element zu einer Menge gehört, kann der Besitzer der Menge Ihnen alle Identifikatoren von diesem Element bis zum Merkle-Wurzel bereitstellen. Dies beweist, dass das Element tatsächlich Teil der Menge ist.

Kurz gesagt ermöglicht die Technologie hinter AST, ein Programm in mehrere kleine Blöcke zu unterteilen, während ein Merkle-Baum es uns ermöglicht zu überprüfen, dass diese Blöcke tatsächlich Teile eines Gesamtprogramms sind, ohne das gesamte Programm offenzulegen. Dies ist das Grundprinzip von MAST, das es Spendern ermöglicht, ungenutzte Bedingungen in einer einzelnen Transaktion durch einen Merkle-Beweis zu ersetzen, mit den Vorteilen einer Reduzierung der Transaktionsgröße, einer Verbesserung der Privatsphäre und der Unterstützung größerer Verträge.

Es gibt viele Beispiele für MAST-Bäume online, und diejenigen, die mit der Programmierung vertraut sind, können die Logik im Zusammenhang mit einem MAST-Prozess klar verstehen.

Mit dem Aufkommen von MAST-Abstraktsyntaxbäumen wird es notwendig, die nativen Syntaxfähigkeiten von Bitcoin zu erweitern, was zur Schaffung von Taproot-Skripten führt.

(3) Taproot-Skripte

Eingeführt unter dem BIP 342-Protokoll ist Taprootscript eine aktualisierte Version des ursprünglichen Bitcoin-Skripts, im Wesentlichen eine Sammlung von Betriebscodes mit Befehlen, die die Implementierung anderer BIPs unterstützen. Taprootscript beseitigt auch das 10.000-Byte-Skriptgrößenlimit und bietet eine bessere Umgebung für die Erstellung von Smart Contracts im Bitcoin-Netzwerk. Dieses Upgrade legte auch den Grundstein für die spätere Entwicklung von Ordinals, die Taproots Skriptpfad-Ausgabeskripte verwenden, um zusätzliche Daten anzuhängen. Weitere Details finden Sie auf der offiziellen Website:

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

Die Fähigkeiten von TaprootScript wurden noch nicht vollständig genutzt, und zukünftige Entwicklungen werden ihr Potenzial zeigen, insbesondere bei der Verbindung des ersten Bitcoin-Netzwerks mit Technologien der zweiten Ebene, wo voraussichtlich vermehrt Taproot, MAST und TaprootScripts eingesetzt werden.

2.3 Ordnungen, Inschriften, BRC 20 und andere Protokolle

Mit grundlegenden Tools wie Segwit, Taproot, Schnorr, MAST und Taproot-Skripten im Bitcoin-Ökosystem sind neue Anwendungen entstanden. Anfangs waren diese Anwendungen leichtgewichtig und einfach.

(1) Ordinals-Protokoll, Inschriften und BRC 20

Die Schaffung des Ordinals-Protokolls ist eng mit dem Konzept der Satoshis verbunden. Das Protokoll führt die Konzepte der Ordnungszahlen und Inschriften ein. Ordnungszahlen sind ein Nummerierungsschema, das jeder Satoshi im Bitcoin-Netzwerk gemäß der Reihenfolge, in der sie abgebaut wurden, eine eindeutige Nummer zuweist. In dem Protokoll bleibt der Ordnungszahlen-Identifier unverändert, unabhängig davon, wie der Satoshi zwischen verschiedenen Geldbörsen übertragen wird. Bitcoin-Vollknoten, die Rodarmors Open-Source-Software ORD ausführen, können diese nummerierten Satoshis verfolgen und damit einen präzisen Mechanismus für die Verfolgung jedes Satoshis und deren unabhängige Überprüfung bereitstellen.

Inscriptionen beinhalten das Gravieren von Informationen auf Satoshis. Durch die Nutzung von SegWit und Taproot ermöglicht das Ordinals-Protokoll das Gravieren von Dateien kleiner als 4 MB auf jeden Satoshi in einem Bitcoin-Block - dies sind die Inschriften, die verschiedene Arten von Informationen wie Texte, Bilder oder Videos enthalten können.

In einfachen Worten bietet das Ordinalnummerierungsschema jedem Satoshi eine eindeutige, rückverfolgbare Kennung, die ihm nicht fungible Eigenschaften verleiht. Inschriften ermöglichen die Hinzufügung von unteilbaren Daten zu diesen Ordnungen, ähnlich wie das Erstellen von Kunst auf einer leeren Leinwand. Zusammen ermöglichen sie es Bitcoin, einen neuen Standard für NFTs zu hosten. Im Wesentlichen ist Ordinals wie ein NFT-Protokoll, aber im Gegensatz zu ETH oder anderen öffentlichen Blockchains, wo NFT-Metadaten normalerweise auf IPFS oder zentralisierten Servern gespeichert sind, bettet Ordinals Metadaten in die Zeugen-Daten der Transaktion ein, als ob sie auf einen bestimmten Satoshi „graviert“ wären.

BRC-20: Inspiriert vom Ordinals-Protokoll, Twitter-Benutzer @domodataerstellte am 8. März 2023 den experimentellen fungiblen Token-Standard BRC-20 auf Bitcoin. Durch die Zuweisung unterschiedlicher „Attribute“ an jeden Satoshi erstellt das Ordinals-Protokoll BTC-Netzwerk-NFTs, während BRC-20 dies durch Bereitstellung eines einheitlichen „Formats“ und „Attribute“ für auf BTC basierende fungible Token (FTs) tut. BRC-20 verwendet das Ordinals-Protokoll, um einen JSON-Text in eine BTC-Inschrift zu schreiben, um Token-Verträge zu erstellen, Token zu prägen und zu übertragen. Zu den wichtigen Bereitstellungsaspekten gehören der Token-Name, das Gesamtangebot und die maximale Prägung pro Anlass. Bei Transaktionen, die Überweisungen oder Kauf/Verkauf beinhalten, verfolgt ein zusätzliches NFT Off-Chain-Salden. Ein „First-Come-First-Served“-Prägungsmechanismus bietet faire Ausgabe- und Beteiligungsmöglichkeiten. Die relativ unterentwickelte Infrastruktur des BTC-Ökosystems und seine steile Lernkurve, zusammen mit geringer Liquidität, machen es einfach für BRC-20-Token wie Ordi, Sats und Rats, zu einer Überspannung zu führen und einen Reichtumsschöpfungsmythos zu schaffen.

(2) Andere Protokolle - Atomicals, ARC 20

Die Entwicklung des Atomicals-Protokolls war ziemlich dramatisch. Der Gründer, Arthur, wollte ursprünglich ein DID-Projekt auf Basis des neu veröffentlichten Ordinals-Protokolls entwickeln, erkannte jedoch, dass Ordinals viele Einschränkungen hatte, die nicht förderlich für die Unterstützung einiger der Funktionen waren, die er implementieren wollte. Folglich twitterte Arthur am 29. Mai 2023 über sein Konzept für das Atomicals-Protokoll, das später am 17. September 2023 nach Monaten der Entwicklung gestartet wurde. Daraufhin entstanden aus dem Atomicals-Protokoll Konzepte wie Dmint, Bitwork, ARC-20 und RNS, mit zukünftigen Plänen zur Einführung von AVM- und Splitting-Lösungen. Wie bei Ordinals und BRC-20 führt die Bereitstellung von fungiblen Tokens auf Atomicals zur Schaffung von ARC-20. Leser, die sich für ARC-20 interessieren, können hier weiterlesen: ARC-20 Tokens.

(3) Andere Protokolle - Rune

Da sich das Ökosystem weiterentwickelt hat, wies Casey Rodarmor, der Schöpfer der Ordinals, darauf hin, dass BRC-20-Token die "unglückliche Folge von UTXO-Sprawl" haben und schlug Runen als alternative UTXO-basierte Lösung vor. Bestehende Protokolle leiden im Allgemeinen unter komplexen Implementierungen, schlechten Benutzererfahrungen, nutzlosen ungenutzten Transaktionsausgaben (UTXOs) und Operationen, die native Token erfordern.

Die Übertragung von Runen erfolgt über OP_RETURN, und die erste Daten-Ausgabe in der Protokollnachricht wird in eine Folge von Ganzzahlen decodiert, die als Folge von (ID, AUSGABE, MENGE) Tupeln interpretiert werden. Wenn die decodierte Anzahl von Ganzzahlen keine Vielfache von drei ist, ist die Protokollnachricht ungültig. ID bezieht sich auf die Token-ID, die übertragen werden soll, AUSGABE ist der Ausgabeindex (d. h., welcher Ausgabe sie zugewiesen ist), und MENGE ist die zugeteilte Menge. Nach der Verarbeitung aller Tupelzuweisungen werden alle nicht zugewiesenen Runen-Token der ersten nicht-OP_RETURN-Ausgabe zugewiesen, wobei der Rest möglicherweise mit Runen-Token in der OP_RETURN-Ausgabe, die die Protokollnachricht enthält, eingraviert wird.

Die Ausgabe von Runen basiert auf der UTXO-Verfolgung von homogenen Token. Wenn die Protokollnachricht einen zweiten Datenpush enthält, stellt er eine Ausgabetransaktion dar. Der zweite Datenpush wird in zwei Ganzzahlen, SYMBOL und DECIMALS, decodiert. Wenn zusätzliche Ganzzahlen verbleiben, ist die Protokollnachricht ungültig. SYMBOL ist ein grundlegendes, 26 Zeichen langes lesbaren Symbol, ähnlich denen, die in Ordnungsnamen verwendet werden, wobei die einzigen gültigen Zeichen A bis Z sind. DECIMALs geben die Dezimalstellen an, die bei der Ausgabe von Runen verwendet werden sollen. Wenn SYMBOL noch nicht zugewiesen wurde, wird dem Runen-Token ein ID-Wert (beginnend bei 1) zugewiesen. Wenn SYMBOL bereits zugewiesen wurde oder eines der BITCOIN, BTC oder XBT ist, werden keine neuen Runen erstellt. Dies ist eine Besonderheit des Runen-Protokolls – es verknüpft keine Bilanzdatensätze mit Wallet-Adressen, sondern speichert sie in der UTXO selbst. Neue Runen-Token beginnen mit der Ausgabetransaktion, die die Menge, das Symbol und die Dezimalstellen angibt, und diese Menge wird bestimmten UTXOs zugewiesen. UTXOs können eine beliebige Anzahl von Runen-Token enthalten, unabhängig von ihrer Größe, und werden nur zum Verfolgen von Bilanzen verwendet. Dann verwendet die Übertragungsfunktion dieses UTXO, teilt es in mehrere beliebig große neue UTXOs auf, die verschiedene Mengen von Runen enthalten, und sendet die Datensätze an andere. Im Vergleich zu BRC-20 vereinfacht Runen die Konsensschicht, wird einfacher, ohne sich auf Off-Chain-Daten und fehlende native Token zu verlassen, was es sehr geeignet für das native UTXO-Modell von Bitcoin macht.

(4) Andere Protokolle - BTC Stamps, SRC 20, SRC 721

Das Bitcoin-Stamps-System wurde im März 2023 von Mike In Space gestartet, zunächst als Proof-of-Concept-Projekt auf Counterparty, einer Bitcoin-Layer-2, die seit 2014 existiert. Aufgrund von Aktualisierungen in seinen zugrunde liegenden Protokollen hat sich Stamps vollständig auf Bitcoin übertragen und ist seit dem letzten Sommer als SRC-20 bekannt. Anfangs sah Mike Stamps als Methode zur Prägung dauerhafter Bitcoin-NFTs vor. Das Protokoll hat sich jedoch seitdem erweitert, um BRC-20 zu replizieren, eine Art von batch-ersetzbarer Token, die auf Bitcoin aufgrund des Inschriften-Booms, ausgelöst durch Casey Rodarmors Einführung von Ordinals im Januar 2023, gediehen ist.

Der Hauptunterschied zwischen Stamps und Ordinals liegt in ihrer Architektur. Stamps speichert ihre Metadaten in mehrfach signierten ungenutzten Transaktionsausgaben (UTXOs), während Ordinals ihre Metadaten im "witness"-Teil von Bitcoin-Transaktionen speichert. Dieser architektonische Unterschied verdeutlicht die Kompromisse, die von den Entwicklern eingegangen werden. Zum Beispiel macht die UTXO-Methode von Stamps sie unprunable, sodass sie dauerhaft erscheinen, obwohl ihre Herstellungskosten höher sind als die von Ordinals. Im Gegensatz dazu macht die Verwendung von Zeugnisdaten durch Ordinals sie letztendlich prunable, und ihre Herstellungskosten sind geringer als die von Stamps.

So bieten Ordinale möglicherweise das beste Haltbarkeits-Kosten-Verhältnis für die heutigen Krypto-NFTs (die auch auf Ethereum erworben werden können, aber zu höheren Baukosten), während Stamps derzeit die beste Garantie für direkte Beständigkeit zu bieten scheint.

Nach dem Auftreten von BTC-Stempeln wurden SRC 20 und SRC 721 entwickelt, die ähnlich wie BRC-20 funktionieren. BRC-20 basiert auf dem Ordinals-Protokoll, während SRC-20 auf BTC-STAMPS basiert. Interessierte Leser können hier die SRC 20- und SRC 721-Dokumentation weiterlesen:

SRC 20-Protokoll

SRC 721 Protokoll

Damit endet die Einführung in bedeutende neue Technologien im Bitcoin-Layer-1-Netzwerk. Für weitere Skalierung und Verbesserung wird der Fokus auf die obere Schichtinfrastruktur von Bitcoin verlagert, wie z.B. Bitcoin Layer 2 oder Lösungen, die das Lightning Network nutzen. Leser werden empfohlen, zu diesem Thema „Ein umfassender Leitfaden zur Bitcoin-Layer-2-Infrastruktur, Version 1.5“ und „Aus der Perspektive von Zustandsmaschinen: Beobachtung der Architektur und des Konstruktionspfads zukünftiger Web3.0-Anwendungen“ oder andere Artikel zu lesen, die sich mit dem Aufbau oder der architektonischen Gestaltung von Bitcoin Layer 2 befassen.

3. Neue Technologienutzung und zukünftige Entwicklungsbedürfnisse

Basierend auf dem Inhalt von Abschnitt 2 stellen wir fest, dass die technologische Entwicklung innerhalb des Bitcoin-Ökosystems eine Grundlage für breitere Anwendungen gelegt hat. Da die Entwicklung jedoch ein Prozess ist und einige verwandte Technologien noch unreif sind, besteht ein signifikanter Unterschied zwischen aktuellen populären Anwendungen und zukünftigen gängigen Verwendungen.

3.1 Methoden zur Verwendung neuer Technologien

Aus den vorherigen Abschnitten sehen wir, dass die Essenz der technologischen Entwicklung von Bitcoin darin besteht, die Blockkapazität und -fähigkeiten zu erweitern.

Block Expansion:Das segregierte Zeugnis (SegWit) hat die Blockkapazität effektiv erweitert, obwohl es verschiedene Vorschläge gibt, die Zeugendaten zu kürzen, solche Ereignisse sind jedoch unwahrscheinlich, insbesondere nachdem die Zeugendaten an Bedeutung gewonnen haben.

Kapazitätserweiterung:Technologien wie Taproot, Schnorr, MAST und Taproot-Skripte haben die Fähigkeiten von Bitcoin verbessert. Insbesondere erweitert die Kombination von MAST und Taproot-Skripten die Fähigkeiten der nativen Skriptsprache von Bitcoin und ermöglicht die Handhabung komplexerer Szenarien. Die Erweiterung dieser Fähigkeiten erhöht jedoch auch die Komplexität der Bitcoin-Entwicklung und des Verständnisses, da die Skriptentwicklung nicht in einer Hochsprache durchgeführt wird. Darüber hinaus hinkt die Erweiterung dieser Fähigkeiten dem Verständnis und Lernfortschritt der Benutzer hinsichtlich der Kapazitätserweiterung von Blöcken hinterher.

Die Einfachheit der Verwendung von Blockerweiterung im Vergleich zur Komplexität der Fähigkeitserweiterung erklärt, warum Benutzer zunächst kleine Bild-NFTs im Bitcoin-Hauptnetz speichern, was zur Entstehung von Anwendungen wie BRC 20 führt. Die meisten Anwendungen, die derzeit im Bitcoin-Hauptnetz vorhanden sind, erkunden nach Blockerweiterung mögliche Anwendungen. Ein kleiner Teil der Anwendungen beginnt, Fähigkeitserweiterungen zu erkunden, wie die Verbindung zwischen den ersten und zweiten Schichten in BEVM, die die oben genannten grundlegenden Elemente prominent nutzt. Die Kombination von Schnorr-Signaturen, MAST-Verträgen und dem Bitcoin-Leichtknoten-Netzwerk (BTC L2) ist ein repräsentativer Fall, der zeigt, wie die ersten und zweiten Schichten verbunden werden können. Es werden in Zukunft umfangreichere Fähigkeitserweiterungsfälle erwartet.

Wo sollten die Grenzen der Leistungserweiterung liegen? Wir können dies aus der Perspektive des schichtweisen Designs beurteilen. Wenn diese Fähigkeiten in erster Linie als Verbindungen zwischen der ersten und zweiten Schicht von Bitcoin gedacht sind, sollten sie nicht übermäßig kompliziert werden. Getrieben von menschlicher Kreativität und dem starken Reiz der Vermögensausgabe und -verwaltung werden jedoch einige Teams oder Einzelpersonen weitere Szenarien für die Leistungserweiterung erkunden.

3.2 Zukünftiger Entwicklungsbedarf

Der direkteste Grund für das Aufkommen der Blockchain-Technologie ist die digitale Währung, daher sind die Ausgabe und Verwaltung von Vermögenswerten direkte Bedürfnisse im Bitcoin- oder Blockchain-Bereich. Von der Erforschung von farbigen Münzen bis hin zu Anwendungen wie BRC 20 und ARC 20 sowie ICOs und IDOs auf Ethereum handelt es sich um Erkundungen der Vermögensausgabe. Anwendungen wie Uniswap, Lending und AMMs handeln von der Vermögensverwaltung. Diese Arten von Anwendungen haben sich auf Netzwerken wie Ethereum entwickelt, und mit der Weiterentwicklung der Technologie im Bitcoin-Ökosystem werden diese Vermögensverwaltungsanwendungen wahrscheinlich in das Bitcoin-Ökosystem übergehen, insbesondere in die zweite Schicht von Bitcoin.

Erst nach Erfüllung der Anforderungen an die Vermögensausgabe und -verwaltung wird es die Kapazität und Zeit geben, um groß angelegte Anwendungen für das Web3.0-Zeitalter (auch bekannt als das Wertzeitalter) zu entwickeln. Die Systemarchitektur für zukünftige groß angelegte Web3.0-Anwendungen wird in „Aus der Sicht von Zustandsmaschinen, die die zweite Schicht von Bitcoin betrachten, die zukünftige Web3.0-Anwendungsarchitektur und den Konstruktionspfad beobachten“ diskutiert.

Der Weg zum Bau ist ein Prozess des kontinuierlichen Erfüllens von Bedürfnissen, der in kurze, mittlere und lange Phasen unterteilt werden kann. Kurzfristig geht es um neue Technologieanwendungen im Bitcoin-Hauptnetz und einfache Phasen des auf der Blockchain basierenden Aufbaus der zweiten Ebene, um wichtige Leistungserweiterungen für verschiedene Finanzanwendungen zu erfüllen. Mittelfristig geht es um fortgeschrittenere Phasen des auf der Blockchain basierenden Aufbaus der zweiten Ebene und des auf verteilten Systemen basierenden Aufbaus der zweiten Ebene, die auf verschiedene Finanz- und Vertrauensanwendungen zugeschnitten sind. Langfristig geht es um den vollständigen Aufbau des groß angelegten Bitcoin-Ökosystems, um das Web3.0-Zeitalter wirklich zu gestalten.

Haftungsausschluss：

1. Dieser Artikel wurde aus [ neu gedrucktForesightnews], Alle Urheberrechte liegen beim ursprünglichen Autor [Fu Shaoqing, SatoshiLab, Wanwu Island BTC Studio]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LernenTeam, und sie werden es schnell erledigen.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.