Ordinals wurde am 20. Januar 2023 vom Entwickler Casey Rodarmor im Bitcoin-Mainnet als Bestellprotokoll für „Satoshis“ gestartet. „Satoshis“ sind die kleinste Einheit von Bitcoin, und jeder Bitcoin besteht aus 100 Millionen Satoshis (1 BTC = 10^8 Sat). Das Ordinals-Protokoll verleiht jedem Satoshi eine eindeutige Identität.
Ordinals-Inschriften sind nicht fungible Token (NFT), die auf dem Ordinals-Protokoll basieren und Daten wie Bilder, Text und Videos enthalten.
Im Vergleich zu Ethereum NFT können wir einfach denken, dass das Ordinals-Protokoll die Token-ID und die Inschrift Metadaten implementiert.
TokenID bietet eine eindeutige Kennung für jeden NFT, sodass Benutzer Token voneinander unterscheiden können. TokenID macht NFTs wirklich einzigartig.
Ethereum verfügt über eine gute Programmierbarkeit, was die Implementierung von TokenID erleichtert. Bei Bitcoin erfordern ähnliche Implementierungen jedoch normalerweise die Verwendung von Netzwerken der zweiten Schicht. Plattformen wie Counterparty und Stacks haben bereits Bitcoin-basierte NFTs implementiert, aber die Ordinals-Inschrift weist grundlegende Unterschiede zu anderen Bitcoin-NFT-Architekturen auf.
Das Ordinals-Protokoll nutzt das UTXO-Transaktionsmodell von Bitcoin. UTXO ähnelt einem Bargeldsystem im Gegensatz zum traditionellen, auf dem Kontostand basierenden Modell.
In der Bitcoin-Blockchain werden alle Salden in einer Liste namens Unspent Transaction Outputs (UTXOs) gespeichert. Jedes UTXO enthält eine bestimmte Menge Bitcoin sowie Informationen über seinen Besitzer und ob es ausgegeben werden kann. Man kann es sich wie einen Barscheck vorstellen, auf dem der Name des Eigentümers steht und der mit der Unterschrift des Eigentümers auf eine andere Person übertragen werden kann. Für eine bestimmte Adresse stellt die Summe aller UTXO-Beträge den Saldo des Wallets dieser Adresse dar. Indem wir alle UTXOs durchlaufen, können wir den aktuellen Saldo für jede Adresse ermitteln. Die Addition aller UTXO-Beträge ergibt den Gesamtumlauf von Bitcoin.
Um das Zahlungsmodell im Bitcoin-Netzwerk besser zu verstehen, gehen wir ein Beispiel durch, bei dem A n Bitcoin an B sendet. Das Diagramm unten zeigt den Prozess, bei dem A 3 Bitcoin an B sendet.
Für Benutzer A muss zunächst die Menge aller UTXOs bestimmt werden, die er besitzt, d. h. alle Bitcoins, die Benutzer A kontrollieren kann;
A wählt einen oder mehrere UTXOs aus diesem Satz als Eingabe der Transaktion aus. Die Summe der Beträge dieser Eingaben beträgt m (2+0,8+0,5=3,3 BTC), der größer ist als der zu zahlende Betrag n (3 BTC);
Benutzer A legt zwei Ausgaben für die Transaktion fest, eine Ausgabe wird an die Adresse von B gezahlt, der Betrag beträgt n (3 BTC), und die andere Ausgabe wird an die eigene Wechseladresse von A gezahlt, der Betrag beträgt mn-fee (3,3-3-0,001). =0,299 BTC). Das Wallet eines Benutzers besteht normalerweise aus mehreren Adressen. Im Allgemeinen wird jede Adresse nur einmal verwendet und Änderungen werden standardmäßig an eine neue Adresse zurückgegeben.
Nachdem der Miner die Transaktion verpackt und zur Bestätigung in die Kette hochgeladen hat, kann B die Transaktionsinformationen empfangen. Da die Blockgröße eine Obergrenze hat (ca. 1 MB), priorisieren Miner Transaktionen mit hohen Transaktionsraten (fee_rate=fee/size), um im Gegenzug die höchste Gebühr zu erhalten.
Gemäß dem Ordinals-Protokoll basiert die Anzahl der „Satoshi“ auf der Reihenfolge, in der sie abgebaut werden, und da jeder „Satoshi“-BTC durch Mining-Belohnungen generiert wird, kann seine Seriennummer durch Rückverfolgbarkeit ermittelt werden.
Angenommen, Benutzer A erhält den 100. bis 110. Satoshi durch Mining (10 Satoshis werden als Ganzes im selben UTXO mit der ID adc123 gespeichert). Wenn Benutzer A 5 Satoshis an Benutzer B zahlen möchte, wählt er die ID abc123 als Eingabe der Transaktion, von der 5 Satoshis an Benutzer B gegeben werden und 5 Satoshis als Wechselgeld an Benutzer A zurückgegeben werden. Diese beiden Kopien von 5 „Satoshi“ bilden ein Ganzes und werden in zwei UTXOs mit den IDs abc456 bzw. abc789 gespeichert. Die obige UTXO-ID und die Anzahl der „Satoshi“ dienen nur als Beispiele. In tatsächlichen Situationen ist die Mindestanzahl der gesendeten „Satoshi“ auf 546 begrenzt und die UTXO-ID wird nicht in dieser Form ausgedrückt.
In der obigen Transaktion ist der Umlaufpfad der 10 Satoshis von Benutzer A:
Der Bergbau produziert 10 „Satoshi“ mit den Nummern [100, 110]. Zeigt an, dass der 100. bis 109. „Satoshi“ im UTXO mit der ID abc123 gespeichert ist und sein Besitzer Benutzer A ist.
Wenn A Geld überweist, werden 10 „Satoshis“ in zwei Teile mit jeweils 5 „Satoshis“ aufgeteilt. Das hier verwendete „Wer zuerst kommt, mahlt zuerst“-Prinzip besteht darin, dass die Nummernreihenfolge von „Satoshi“ anhand ihres Index in der Transaktionsausgabe bestimmt wird. Angenommen, die Ausgabereihenfolge ist zuerst Benutzer A, dann Benutzer B, dann sind die Seriennummern der verbleibenden 5 „Satoshis“ von Benutzer A [100, 105), die im UTXO mit der ID abc456 gespeichert sind, und die Seriennummern der verbleibenden 5 „Satoshis“ von Benutzer B. satoshis“ Die Sequenznummer ist [105, 110) und wird im UTXO mit der ID abc789 gespeichert.
Metadaten für Ordinalinschriften werden nicht an einem bestimmten Ort gespeichert. Stattdessen werden diese Metadaten in die Zeugendaten der Transaktion (Zeugendaten, Zeugenfeld) eingebettet, weshalb sie als „Inschrift“ bezeichnet werden, da diese Daten wie eine Inschrift in bestimmte Teile der Bitcoin-Transaktion „eingraviert“ werden. , und diese Daten sind bestimmten „Satoshi“ zugeordnet. Dieser Eintragungsprozess wird durch Segregated Witness (SegWit) und Taproot implementiert, der zwei Phasen umfasst: Festschreiben und Offenlegen, und kann jede Form von Inhalt (wie Text, Bild oder Video) auf dem bezeichneten „Satoshi“ einschreiben.
SegWit ist ein Update aus dem Jahr 2017, das zu einem Soft Fork der Bitcoin-Blockchain führte. Das Update trennt Bitcoin-Transaktionen effektiv in zwei Teile, indem es einen Abschnitt „Zeugendaten“ hinzufügt, der beliebige Daten unterstützen kann.
Segregated Witness trennt Transaktions- und Zeugendaten (Signaturdaten) in separate Teile und ermöglicht die Speicherung beliebiger Daten im Zeugenteil.
Technisch gesehen bedeutet die Implementierung von Segregated Witness, dass Transaktionen keine Zeugendaten mehr enthalten müssen (und nicht den 1 MB Speicherplatz beanspruchen, den Bitcoin ursprünglich für Blöcke zugewiesen hatte). Stattdessen wird am Ende eines Blocks ein zusätzlicher separater Bereich für Zeugendaten erstellt. Es unterstützt beliebige Datenübertragungen und verfügt über ein reduziertes „Blockgewicht“, das große Datenmengen geschickt innerhalb der Blockgrößenbeschränkungen von Bitcoin hält, um die Notwendigkeit einer Hard Fork zu vermeiden.
Taproot wurde im November 2021 implementiert und ist ein vielschichtiges Upgrade, das den Datenschutz, die Skalierbarkeit und die Sicherheit von Bitcoin verbessern soll. Taproot erstellt ein System, das die Speicherung beliebiger Zeugendaten erleichtert und die Grenzen dafür lockert, wie viele beliebige Daten in eine Bitcoin-Transaktion eingefügt werden können. Das ursprüngliche Ziel dieses Upgrades besteht darin, Bitcoin-basierte Smart Contracts weiter zu verbessern, beispielsweise zeitgebundene Verträge, die typischerweise in Zeugendaten ausgedrückt werden.
Ordinalzahlen speichern Metadaten in einem Spend-Skript im Taproot-Skriptpfad.
Erstens können wir aufgrund der Art und Weise, wie Taproot-Skripte gespeichert werden, Inskriptionsinhalte in Taproot-Skriptpfadausgabeskripten speichern, die nahezu keine Einschränkungen hinsichtlich des Inhalts haben, und erhalten gleichzeitig Rabatte auf Zeugendaten, was das Speichern von Inskriptionsinhalten relativ wirtschaftlich macht. Da die Verwendung von Taproot-Skripten nur aus bereits vorhandener Taproot-Ausgabe erfolgen kann, werden Inschriften mithilfe eines zweistufigen Commit-/Reveal-Prozesses erstellt. Zunächst wird in der Commit-Transaktion eine Taproot-Ausgabe erstellt, die ein Skript verspricht, das den Inhalt der Inschrift enthält. Dann wird bei der Offenlegungstransaktion eine Transaktion initiiert, indem das UTXO, das dieser Inschrift entspricht, als Eingabe verwendet wird. Zu diesem Zeitpunkt wurde der entsprechende Inschrifteninhalt im gesamten Internet veröffentlicht.
Dieser Ansatz reduziert den Ressourcenverbrauch erheblich. Wenn Sie das Taproot-Skript nicht verwenden, werden die Zeugeninformationen in der Ausgabe der Transaktion gespeichert. Auf diese Weise werden die Zeugeninformationen immer im UTXO-Satz gespeichert, solange diese Ausgabe nicht verbraucht wird. Wenn dagegen P2TR verwendet wird, erscheinen die Zeugeninformationen nicht in der während der Festschreibungsphase generierten Transaktion und werden daher nicht in den UTXO-Satz geschrieben. Erst wenn dieses UTXO verbraucht ist, erscheinen die Zeugeninformationen in der Transaktionseingabe während der Offenlegungsphase. P2TR ermöglicht das Schreiben von Metadaten in die Bitcoin-Blockchain, erscheint jedoch nie im UTXO-Set. Da die Wartung/Änderung des UTXO-Sets mehr Ressourcen erfordert, kann dieser Ansatz viele Ressourcen einsparen.
Obwohl der Name BRC-20 dem ERC-20 von Ethereum sehr ähnlich ist, sind die technischen Unterschiede zwischen den beiden tatsächlich erheblich. Der Haltestatus von ERC-20-Tokens wird in der Kette gespeichert, und in der Kette kann ein Netzwerkkonsens erzielt werden, während BRC-20 nur ein spezielles Ordinalprotokoll ist, das am 8. März 2023 vom Twitter-Benutzer @domodata erstellt wurde und Ordinalzahlen verwendet Beschriftungen von JSON-Daten zum Bereitstellen von Token-Verträgen sowie zum Prägen und Übertragen von Token. Der bereitgestellte JSON lautet wie folgt:
{
"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events
"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)
"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)
"max": "21000000",//Max supply: The maximum supply of brc-20 tokens
"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time
}
Die entsprechenden Operationen sind Mint und Transfer, und die beiden Formate sind fast gleich. Wenn op „Transfer“ ist, ist der Transferempfänger der Inschrift der Empfänger des „Satoshi“, der der Inschrift entspricht. Daher muss die Übertragung von BRC-20 mit der Übertragung des Bitcoin-Eigentums einhergehen und darf nicht nur als Bearbeitungsgebühr verbraucht werden.
BRC-20 implementiert einen „Wer zuerst kommt, mahlt zuerst“-Mechanismus. Wiederholte Einsätze und übermäßige Minze sind ungültig. Die zentralisierte Organisation leitet den aktuellen Kontostand ab, den der Benutzer auf der Grundlage jedes in der Kette registrierten OP haben sollte, und beurteilt die Gültigkeit der Transaktion.
In diesem Prozess werden die Inschriften an die Transaktion „Satoshi“ „angehängt“. Bitcoin-Miner werden diese Inschriften nicht verarbeiten. Aus Sicht der Kette unterscheiden sie sich dennoch nicht von anderen „Satoshis“. Sie alle gelten als gewöhnliche „Satoshis“. „Cong“ wird übertragen.
Für das BRC-20-Protokoll wird die Inschrift als Hauptbuch behandelt, das den Einsatz, die Prägung und die Übertragung von BRC-20-Tokens aufzeichnet. Da Smart Contracts nicht auf Bitcoin ausgeführt werden können, können BRC-20-Tokens durch die Ausführung von Smart Contracts keine relevanten Informationen über den aktuellen Token abfragen. Daher verwendet BRC-20 Off-Chain-Abfragen, d. h. einen zentralen Server zum Abrufen von Bitcoin-Blöcken, zum Aufzeichnen der Bereitstellungs-, Münz- und Übertragungsvorgänge aller BRC-20-Tokens, um den endgültigen Kontostand der BRC-20-Tokens jedes Benutzers abzufragen.
Einfach ausgedrückt ist das BRC-20-Hauptbuch dezentralisiert und wird in der Bitcoin-Kette aufgezeichnet, der Abwicklungsprozess ist jedoch zentralisiert. Derzeit gibt es zwei Websites, brc-20.io und unisat.io, die Abfragen im Zusammenhang mit BRC-20-Token unterstützen.
Die Zentralisierung des Abwicklungsprozesses kann dazu führen, dass verschiedene Plattformen bei der Abfrage eines bestimmten Kontostands zu unterschiedlichen Ergebnissen kommen. Obwohl alle Vorgänge in der Kette aufgezeichnet werden, liegt es in der Verantwortung eines Kunden, diese Vorgänge zu überprüfen. Wenn diese zentralisierten Dienstleister ihre Verifizierungsregeln nicht offenlegen, gibt es eigentlich keine Garantie für das gesamte BRC-20-Ökosystem.
Tatsächlich startete UniSat am Abend des 23. April die BRC-20-Handelsplattform, erlitt jedoch aufgrund von Schwachstellen in der Codebibliothek eine große Anzahl von Double-Spending-Angriffen. Die Adresse bc1pwturekq4w455l64ttze8j7mnhgsuaupsn99ggd0ds23js924e6ms9fxyht prägte zunächst die übertragenen Ordinals NFT und versuchte, 5.000 ORDI und 35.000 ORDI aus dem Nichts an seine eigene Adresse zu übertragen, und versuchte, die aus dem Nichts geprägten Ordi an andere Benutzer zu verkaufen. Anschließend sperrte Unisat den Zugriff auf die Website und führte eine Untersuchung durch, bei der schließlich festgestellt wurde, dass 70 Transaktionen betroffen waren.
Hätte Unisat den Fehler in dieser Nacht nicht behoben, wurde der Schaden durch den Double-Spend-Angriff auf über 1 Million US-Dollar geschätzt. Wie sichergestellt werden kann, dass der zentralisierte Serverabruf und die Überprüfung fehlerfrei sind, ist das wichtigste Problem, das bei der Entwicklung von BRC-20 gelöst werden muss.
Die Essenz der Ordinal-Inschrift lautet: Im Bitcoin-Netzwerk mit Hilfe von aTaproot Das Skript baut eine einfache Buchhaltungsschicht auf, um Vermögenswerte und Daten zu zählen und aufzuzeichnen.
Da es sich nur um die Buchhaltung handelt, bedeutet dies, dass es keine Skriptausführungs- und Verifizierungsprozesse ähnlich wie bei Smart Contracts gibt und es in hohem Maße von zentralisierten Verwaltungs- und Berichtsergebnissen außerhalb der Kette abhängig sein muss.
Daher müssen, mit Ausnahme von BRC-20, alle Ordinaleinträge auf Offline-Diensten außerhalb des Bitcoin-Netzwerks zur Zustandserhaltung basieren, solange sie eine Zustandsübertragung (z. B. Transaktionen) beinhalten. Wenn der zugrunde liegende staatliche Dienst nicht verfügbar oder fehlerhaft ist, kann es zu Vermögensverlusten kommen, da das Bitcoin-Netzwerk nicht verhindern kann, dass ungültige Inschriften in die Kette hochgeladen werden. Die zentrale Plattform muss entscheiden, wessen Eintrag gültig ist, und dieser wird auf der Plattform gültig sein.
Diese zentralisierte Handels- und Preismethode bietet der zentralisierten Plattform eine erhebliche Möglichkeit für böswilliges Verhalten. Darüber hinaus ermöglicht die Kombination aus dem logischen Paradoxon der Inschrift „Wer zuerst kommt, mahlt zuerst“ und dem Mechanismus, dass Bergleute Verpackungen auf der Grundlage der Bergbaugebühren priorisieren, es Bergleuten und vordersten Robotern, eine große Anzahl beliebter Inschriften vor anderen zu prägen, was zu einem führt unfairer Prägeprozess.
Allerdings ist es eine Herausforderung, die Entwicklung neuer Dinge vorherzusagen und einzuschätzen. Die Einführung der Ordinalinschrift hat zweifellos eine Debatte innerhalb der Bitcoin-Community über die grundlegende Rolle und das Wesen von Bitcoin ausgelöst. Diese Diskussion könnte möglicherweise zu einer Abspaltung von Bitcoin führen, wobei der Schwerpunkt auf Sicherheit und Programmierbarkeit liegt. Es scheint, dass die Büchse der Pandora geöffnet wird.
Ordinals wurde am 20. Januar 2023 vom Entwickler Casey Rodarmor im Bitcoin-Mainnet als Bestellprotokoll für „Satoshis“ gestartet. „Satoshis“ sind die kleinste Einheit von Bitcoin, und jeder Bitcoin besteht aus 100 Millionen Satoshis (1 BTC = 10^8 Sat). Das Ordinals-Protokoll verleiht jedem Satoshi eine eindeutige Identität.
Ordinals-Inschriften sind nicht fungible Token (NFT), die auf dem Ordinals-Protokoll basieren und Daten wie Bilder, Text und Videos enthalten.
Im Vergleich zu Ethereum NFT können wir einfach denken, dass das Ordinals-Protokoll die Token-ID und die Inschrift Metadaten implementiert.
TokenID bietet eine eindeutige Kennung für jeden NFT, sodass Benutzer Token voneinander unterscheiden können. TokenID macht NFTs wirklich einzigartig.
Ethereum verfügt über eine gute Programmierbarkeit, was die Implementierung von TokenID erleichtert. Bei Bitcoin erfordern ähnliche Implementierungen jedoch normalerweise die Verwendung von Netzwerken der zweiten Schicht. Plattformen wie Counterparty und Stacks haben bereits Bitcoin-basierte NFTs implementiert, aber die Ordinals-Inschrift weist grundlegende Unterschiede zu anderen Bitcoin-NFT-Architekturen auf.
Das Ordinals-Protokoll nutzt das UTXO-Transaktionsmodell von Bitcoin. UTXO ähnelt einem Bargeldsystem im Gegensatz zum traditionellen, auf dem Kontostand basierenden Modell.
In der Bitcoin-Blockchain werden alle Salden in einer Liste namens Unspent Transaction Outputs (UTXOs) gespeichert. Jedes UTXO enthält eine bestimmte Menge Bitcoin sowie Informationen über seinen Besitzer und ob es ausgegeben werden kann. Man kann es sich wie einen Barscheck vorstellen, auf dem der Name des Eigentümers steht und der mit der Unterschrift des Eigentümers auf eine andere Person übertragen werden kann. Für eine bestimmte Adresse stellt die Summe aller UTXO-Beträge den Saldo des Wallets dieser Adresse dar. Indem wir alle UTXOs durchlaufen, können wir den aktuellen Saldo für jede Adresse ermitteln. Die Addition aller UTXO-Beträge ergibt den Gesamtumlauf von Bitcoin.
Um das Zahlungsmodell im Bitcoin-Netzwerk besser zu verstehen, gehen wir ein Beispiel durch, bei dem A n Bitcoin an B sendet. Das Diagramm unten zeigt den Prozess, bei dem A 3 Bitcoin an B sendet.
Für Benutzer A muss zunächst die Menge aller UTXOs bestimmt werden, die er besitzt, d. h. alle Bitcoins, die Benutzer A kontrollieren kann;
A wählt einen oder mehrere UTXOs aus diesem Satz als Eingabe der Transaktion aus. Die Summe der Beträge dieser Eingaben beträgt m (2+0,8+0,5=3,3 BTC), der größer ist als der zu zahlende Betrag n (3 BTC);
Benutzer A legt zwei Ausgaben für die Transaktion fest, eine Ausgabe wird an die Adresse von B gezahlt, der Betrag beträgt n (3 BTC), und die andere Ausgabe wird an die eigene Wechseladresse von A gezahlt, der Betrag beträgt mn-fee (3,3-3-0,001). =0,299 BTC). Das Wallet eines Benutzers besteht normalerweise aus mehreren Adressen. Im Allgemeinen wird jede Adresse nur einmal verwendet und Änderungen werden standardmäßig an eine neue Adresse zurückgegeben.
Nachdem der Miner die Transaktion verpackt und zur Bestätigung in die Kette hochgeladen hat, kann B die Transaktionsinformationen empfangen. Da die Blockgröße eine Obergrenze hat (ca. 1 MB), priorisieren Miner Transaktionen mit hohen Transaktionsraten (fee_rate=fee/size), um im Gegenzug die höchste Gebühr zu erhalten.
Gemäß dem Ordinals-Protokoll basiert die Anzahl der „Satoshi“ auf der Reihenfolge, in der sie abgebaut werden, und da jeder „Satoshi“-BTC durch Mining-Belohnungen generiert wird, kann seine Seriennummer durch Rückverfolgbarkeit ermittelt werden.
Angenommen, Benutzer A erhält den 100. bis 110. Satoshi durch Mining (10 Satoshis werden als Ganzes im selben UTXO mit der ID adc123 gespeichert). Wenn Benutzer A 5 Satoshis an Benutzer B zahlen möchte, wählt er die ID abc123 als Eingabe der Transaktion, von der 5 Satoshis an Benutzer B gegeben werden und 5 Satoshis als Wechselgeld an Benutzer A zurückgegeben werden. Diese beiden Kopien von 5 „Satoshi“ bilden ein Ganzes und werden in zwei UTXOs mit den IDs abc456 bzw. abc789 gespeichert. Die obige UTXO-ID und die Anzahl der „Satoshi“ dienen nur als Beispiele. In tatsächlichen Situationen ist die Mindestanzahl der gesendeten „Satoshi“ auf 546 begrenzt und die UTXO-ID wird nicht in dieser Form ausgedrückt.
In der obigen Transaktion ist der Umlaufpfad der 10 Satoshis von Benutzer A:
Der Bergbau produziert 10 „Satoshi“ mit den Nummern [100, 110]. Zeigt an, dass der 100. bis 109. „Satoshi“ im UTXO mit der ID abc123 gespeichert ist und sein Besitzer Benutzer A ist.
Wenn A Geld überweist, werden 10 „Satoshis“ in zwei Teile mit jeweils 5 „Satoshis“ aufgeteilt. Das hier verwendete „Wer zuerst kommt, mahlt zuerst“-Prinzip besteht darin, dass die Nummernreihenfolge von „Satoshi“ anhand ihres Index in der Transaktionsausgabe bestimmt wird. Angenommen, die Ausgabereihenfolge ist zuerst Benutzer A, dann Benutzer B, dann sind die Seriennummern der verbleibenden 5 „Satoshis“ von Benutzer A [100, 105), die im UTXO mit der ID abc456 gespeichert sind, und die Seriennummern der verbleibenden 5 „Satoshis“ von Benutzer B. satoshis“ Die Sequenznummer ist [105, 110) und wird im UTXO mit der ID abc789 gespeichert.
Metadaten für Ordinalinschriften werden nicht an einem bestimmten Ort gespeichert. Stattdessen werden diese Metadaten in die Zeugendaten der Transaktion (Zeugendaten, Zeugenfeld) eingebettet, weshalb sie als „Inschrift“ bezeichnet werden, da diese Daten wie eine Inschrift in bestimmte Teile der Bitcoin-Transaktion „eingraviert“ werden. , und diese Daten sind bestimmten „Satoshi“ zugeordnet. Dieser Eintragungsprozess wird durch Segregated Witness (SegWit) und Taproot implementiert, der zwei Phasen umfasst: Festschreiben und Offenlegen, und kann jede Form von Inhalt (wie Text, Bild oder Video) auf dem bezeichneten „Satoshi“ einschreiben.
SegWit ist ein Update aus dem Jahr 2017, das zu einem Soft Fork der Bitcoin-Blockchain führte. Das Update trennt Bitcoin-Transaktionen effektiv in zwei Teile, indem es einen Abschnitt „Zeugendaten“ hinzufügt, der beliebige Daten unterstützen kann.
Segregated Witness trennt Transaktions- und Zeugendaten (Signaturdaten) in separate Teile und ermöglicht die Speicherung beliebiger Daten im Zeugenteil.
Technisch gesehen bedeutet die Implementierung von Segregated Witness, dass Transaktionen keine Zeugendaten mehr enthalten müssen (und nicht den 1 MB Speicherplatz beanspruchen, den Bitcoin ursprünglich für Blöcke zugewiesen hatte). Stattdessen wird am Ende eines Blocks ein zusätzlicher separater Bereich für Zeugendaten erstellt. Es unterstützt beliebige Datenübertragungen und verfügt über ein reduziertes „Blockgewicht“, das große Datenmengen geschickt innerhalb der Blockgrößenbeschränkungen von Bitcoin hält, um die Notwendigkeit einer Hard Fork zu vermeiden.
Taproot wurde im November 2021 implementiert und ist ein vielschichtiges Upgrade, das den Datenschutz, die Skalierbarkeit und die Sicherheit von Bitcoin verbessern soll. Taproot erstellt ein System, das die Speicherung beliebiger Zeugendaten erleichtert und die Grenzen dafür lockert, wie viele beliebige Daten in eine Bitcoin-Transaktion eingefügt werden können. Das ursprüngliche Ziel dieses Upgrades besteht darin, Bitcoin-basierte Smart Contracts weiter zu verbessern, beispielsweise zeitgebundene Verträge, die typischerweise in Zeugendaten ausgedrückt werden.
Ordinalzahlen speichern Metadaten in einem Spend-Skript im Taproot-Skriptpfad.
Erstens können wir aufgrund der Art und Weise, wie Taproot-Skripte gespeichert werden, Inskriptionsinhalte in Taproot-Skriptpfadausgabeskripten speichern, die nahezu keine Einschränkungen hinsichtlich des Inhalts haben, und erhalten gleichzeitig Rabatte auf Zeugendaten, was das Speichern von Inskriptionsinhalten relativ wirtschaftlich macht. Da die Verwendung von Taproot-Skripten nur aus bereits vorhandener Taproot-Ausgabe erfolgen kann, werden Inschriften mithilfe eines zweistufigen Commit-/Reveal-Prozesses erstellt. Zunächst wird in der Commit-Transaktion eine Taproot-Ausgabe erstellt, die ein Skript verspricht, das den Inhalt der Inschrift enthält. Dann wird bei der Offenlegungstransaktion eine Transaktion initiiert, indem das UTXO, das dieser Inschrift entspricht, als Eingabe verwendet wird. Zu diesem Zeitpunkt wurde der entsprechende Inschrifteninhalt im gesamten Internet veröffentlicht.
Dieser Ansatz reduziert den Ressourcenverbrauch erheblich. Wenn Sie das Taproot-Skript nicht verwenden, werden die Zeugeninformationen in der Ausgabe der Transaktion gespeichert. Auf diese Weise werden die Zeugeninformationen immer im UTXO-Satz gespeichert, solange diese Ausgabe nicht verbraucht wird. Wenn dagegen P2TR verwendet wird, erscheinen die Zeugeninformationen nicht in der während der Festschreibungsphase generierten Transaktion und werden daher nicht in den UTXO-Satz geschrieben. Erst wenn dieses UTXO verbraucht ist, erscheinen die Zeugeninformationen in der Transaktionseingabe während der Offenlegungsphase. P2TR ermöglicht das Schreiben von Metadaten in die Bitcoin-Blockchain, erscheint jedoch nie im UTXO-Set. Da die Wartung/Änderung des UTXO-Sets mehr Ressourcen erfordert, kann dieser Ansatz viele Ressourcen einsparen.
Obwohl der Name BRC-20 dem ERC-20 von Ethereum sehr ähnlich ist, sind die technischen Unterschiede zwischen den beiden tatsächlich erheblich. Der Haltestatus von ERC-20-Tokens wird in der Kette gespeichert, und in der Kette kann ein Netzwerkkonsens erzielt werden, während BRC-20 nur ein spezielles Ordinalprotokoll ist, das am 8. März 2023 vom Twitter-Benutzer @domodata erstellt wurde und Ordinalzahlen verwendet Beschriftungen von JSON-Daten zum Bereitstellen von Token-Verträgen sowie zum Prägen und Übertragen von Token. Der bereitgestellte JSON lautet wie folgt:
{
"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events
"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)
"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)
"max": "21000000",//Max supply: The maximum supply of brc-20 tokens
"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time
}
Die entsprechenden Operationen sind Mint und Transfer, und die beiden Formate sind fast gleich. Wenn op „Transfer“ ist, ist der Transferempfänger der Inschrift der Empfänger des „Satoshi“, der der Inschrift entspricht. Daher muss die Übertragung von BRC-20 mit der Übertragung des Bitcoin-Eigentums einhergehen und darf nicht nur als Bearbeitungsgebühr verbraucht werden.
BRC-20 implementiert einen „Wer zuerst kommt, mahlt zuerst“-Mechanismus. Wiederholte Einsätze und übermäßige Minze sind ungültig. Die zentralisierte Organisation leitet den aktuellen Kontostand ab, den der Benutzer auf der Grundlage jedes in der Kette registrierten OP haben sollte, und beurteilt die Gültigkeit der Transaktion.
In diesem Prozess werden die Inschriften an die Transaktion „Satoshi“ „angehängt“. Bitcoin-Miner werden diese Inschriften nicht verarbeiten. Aus Sicht der Kette unterscheiden sie sich dennoch nicht von anderen „Satoshis“. Sie alle gelten als gewöhnliche „Satoshis“. „Cong“ wird übertragen.
Für das BRC-20-Protokoll wird die Inschrift als Hauptbuch behandelt, das den Einsatz, die Prägung und die Übertragung von BRC-20-Tokens aufzeichnet. Da Smart Contracts nicht auf Bitcoin ausgeführt werden können, können BRC-20-Tokens durch die Ausführung von Smart Contracts keine relevanten Informationen über den aktuellen Token abfragen. Daher verwendet BRC-20 Off-Chain-Abfragen, d. h. einen zentralen Server zum Abrufen von Bitcoin-Blöcken, zum Aufzeichnen der Bereitstellungs-, Münz- und Übertragungsvorgänge aller BRC-20-Tokens, um den endgültigen Kontostand der BRC-20-Tokens jedes Benutzers abzufragen.
Einfach ausgedrückt ist das BRC-20-Hauptbuch dezentralisiert und wird in der Bitcoin-Kette aufgezeichnet, der Abwicklungsprozess ist jedoch zentralisiert. Derzeit gibt es zwei Websites, brc-20.io und unisat.io, die Abfragen im Zusammenhang mit BRC-20-Token unterstützen.
Die Zentralisierung des Abwicklungsprozesses kann dazu führen, dass verschiedene Plattformen bei der Abfrage eines bestimmten Kontostands zu unterschiedlichen Ergebnissen kommen. Obwohl alle Vorgänge in der Kette aufgezeichnet werden, liegt es in der Verantwortung eines Kunden, diese Vorgänge zu überprüfen. Wenn diese zentralisierten Dienstleister ihre Verifizierungsregeln nicht offenlegen, gibt es eigentlich keine Garantie für das gesamte BRC-20-Ökosystem.
Tatsächlich startete UniSat am Abend des 23. April die BRC-20-Handelsplattform, erlitt jedoch aufgrund von Schwachstellen in der Codebibliothek eine große Anzahl von Double-Spending-Angriffen. Die Adresse bc1pwturekq4w455l64ttze8j7mnhgsuaupsn99ggd0ds23js924e6ms9fxyht prägte zunächst die übertragenen Ordinals NFT und versuchte, 5.000 ORDI und 35.000 ORDI aus dem Nichts an seine eigene Adresse zu übertragen, und versuchte, die aus dem Nichts geprägten Ordi an andere Benutzer zu verkaufen. Anschließend sperrte Unisat den Zugriff auf die Website und führte eine Untersuchung durch, bei der schließlich festgestellt wurde, dass 70 Transaktionen betroffen waren.
Hätte Unisat den Fehler in dieser Nacht nicht behoben, wurde der Schaden durch den Double-Spend-Angriff auf über 1 Million US-Dollar geschätzt. Wie sichergestellt werden kann, dass der zentralisierte Serverabruf und die Überprüfung fehlerfrei sind, ist das wichtigste Problem, das bei der Entwicklung von BRC-20 gelöst werden muss.
Die Essenz der Ordinal-Inschrift lautet: Im Bitcoin-Netzwerk mit Hilfe von aTaproot Das Skript baut eine einfache Buchhaltungsschicht auf, um Vermögenswerte und Daten zu zählen und aufzuzeichnen.
Da es sich nur um die Buchhaltung handelt, bedeutet dies, dass es keine Skriptausführungs- und Verifizierungsprozesse ähnlich wie bei Smart Contracts gibt und es in hohem Maße von zentralisierten Verwaltungs- und Berichtsergebnissen außerhalb der Kette abhängig sein muss.
Daher müssen, mit Ausnahme von BRC-20, alle Ordinaleinträge auf Offline-Diensten außerhalb des Bitcoin-Netzwerks zur Zustandserhaltung basieren, solange sie eine Zustandsübertragung (z. B. Transaktionen) beinhalten. Wenn der zugrunde liegende staatliche Dienst nicht verfügbar oder fehlerhaft ist, kann es zu Vermögensverlusten kommen, da das Bitcoin-Netzwerk nicht verhindern kann, dass ungültige Inschriften in die Kette hochgeladen werden. Die zentrale Plattform muss entscheiden, wessen Eintrag gültig ist, und dieser wird auf der Plattform gültig sein.
Diese zentralisierte Handels- und Preismethode bietet der zentralisierten Plattform eine erhebliche Möglichkeit für böswilliges Verhalten. Darüber hinaus ermöglicht die Kombination aus dem logischen Paradoxon der Inschrift „Wer zuerst kommt, mahlt zuerst“ und dem Mechanismus, dass Bergleute Verpackungen auf der Grundlage der Bergbaugebühren priorisieren, es Bergleuten und vordersten Robotern, eine große Anzahl beliebter Inschriften vor anderen zu prägen, was zu einem führt unfairer Prägeprozess.
Allerdings ist es eine Herausforderung, die Entwicklung neuer Dinge vorherzusagen und einzuschätzen. Die Einführung der Ordinalinschrift hat zweifellos eine Debatte innerhalb der Bitcoin-Community über die grundlegende Rolle und das Wesen von Bitcoin ausgelöst. Diese Diskussion könnte möglicherweise zu einer Abspaltung von Bitcoin führen, wobei der Schwerpunkt auf Sicherheit und Programmierbarkeit liegt. Es scheint, dass die Büchse der Pandora geöffnet wird.