Aktuelle News

BSV Merkle-Proof-Standardformat veröffentlicht

Eine der wichtigsten Ankündigungen bei der CoinGeek-Konferenz in Zürich war die Veröffentlichung des Merkle-Proof-Standardformats durch das Bitcoin SV Technical Standards Committee (TSC).

Während der Veranstaltung verkündeten Steve Shadders, Technischer Direktor von nChain und TSC-Vorstand, und Alex Fauvel, Gründer von Two Hop Ventures und TSC-Gründungsmitglied, in ihrer Präsentation den Abschluss der öffentlichen Prüfung des Merkle-Proof-Standardformats und die Veröffentlichung des Standards unter der OpenBSV-Lizenz.

Dies bedeutet gute Neuigkeiten für Entwickler und Nutzer von Bitcoin SV gleichermaßen, da das Format eine weitaus bessere Interoperabilität für BSV-Zahlungen ermöglicht und eine stabile und zuverlässige Plattform für den Aufbau vereinfachter Zahlungsüberprüfungen (Simple Payment Verification, SPV) auf der Blockchain bietet. SPV ist ein integraler Bestandteil der Kernfunktion von Bitcoin SV, jener Blockchain, die am ehesten mit Satoshi Nakamotos ursprünglichen, 2008 veröffentlichten Bitcoin Whitepaper übereinstimmt. Das Whitepaper beschreibt die Anwendung von SPV, die den Nutzern den Empfang und die Validierung von Zahlungen ermöglicht, ohne einen vollständigen Bitcoin-Node zu betreiben.

Das Ziel des Technical Standards Committees ist eine Verbesserung der Interoperabilität innerhalb des wachsenden Bitcoin SV-Ökosystems, indem in Zusammenarbeit mit Entwicklern und Stakeholdern gemeingültige Standards entwickelt werden, die über verschiedene Anwendungen hinweg kompatibel sind. Es ist wichtig zu betonen, dass das TSC keine Standards festlegt – es stellt lediglich den Rahmen und den Prozess für die Entwicklung technischer Standards, um die Interoperabilität zu verbessern und die wachsende Akzeptanz von Bitcoin SV zu beschleunigen.

„Das TSC entscheidet nicht, was die Standards sind. Es hilft der Branche lediglich, selbst zu entscheiden, was diese Standards sind“, erklärt Shadders.

Das Merkle-Proof -Standardformat hat den umfassenden, offenen Standardisierungsprozess der Kommission durchlaufen, dazu gehört die Erwägung und Ausarbeitung sowie interne und öffentliche Prüfung, und wurde nun für die allgemeine Nutzung veröffentlicht.

Merkle-Proofs und ihre Funktion für SPV

Um die Vorteile eines Standardformats für Merkle-Proofs nachvollziehen zu können, muss man zunächst die Bedeutung dieser Datenstruktur für vereinfachte Zahlungsüberprüfungen (SPV) verstehen. Mit der SPV kann ein Händler oder Nutzer eine Bitcoin SV-Transaktion validieren, ohne dabei die ganze Blockchain herunterladen zu müssen. Stattdessen erhalten sie einen Block-Header des Bitcoin-Blocks, der diese Transaktion von einem zuverlässigen Node enthält. In diesem Block-Header ist die Merkle-Wurzel enthalten, ein Hash aller Transaktionen in diesem Block.

Bitcoin-Transaktionen werden in Merkle-Baum-Datenstrukturen gelagert. Diese Strukturen verhalten sich ähnlich wie ein Binärbaum, die Blätter der Struktur bestehen jedoch aus den Hashwerten der einzelnen Transaktionen, die dann mit den benachbarten Hashwerten je eine Schicht hinauf bis zur Wurzel des Baumes – der Merkle-Wurzel – gehasht werden. Die Merkle-Wurzel enthält also den Proof für jede Transaktion im Bitcoin-Block, wodurch man die Existenz einer Transaktion auf der Bockchain mittels dieses Proofs und der Transaktions-ID oder dem Hash nachweisen kann.

Die technischen Eigenschaften dieser Art der Validierung ermöglichen es den Nutzern von Bitcoin SV, eine „Light Node“-SPV ohne komplexe und teure Hardware sicher durchzuführen, um Transaktionen von anderen zu erhalten. Dabei haben sie die Gewissheit, dass sie ohne viel Aufwand überprüfen können, ob diese Transaktionen gültig sind – es ist keine komplette Blockchain erforderlich.

„Neben dem Bitcoin-Block-Header ist der Merkle-Proof wahrscheinlich eine der grundlegendsten Datenstrukturen in Bitcoin. Sie können damit überprüfen, ob eine Transaktion mit einem Block verbunden ist, sprich, ob die Miner diese Transaktion bestätigt haben. Es gibt also viele Gründe, warum es einen standardisierten Merkle-Proof für mehrere Parteien geben sollte“, so Shadders zur Bitcoin Association.

„Ein Standard ist ein wesentlicher Bestandteil der Peer-to-Peer-Interaktion, da als Teil der Interaktion Informationen mit angehängten Merkle-Proofs versendet werden. Er muss also mit vielen verschiedenen Wallets kompatibel sein. Wenn ihn also jeder anders einsetzt, dann müssen Sie bei jeder Nutzung eines neuen Dienstes einen neuen Weg finden, den Proof zu verwenden.“

Mit der Veröffentlichung des Merkle-Proof-Standardformats können diese wichtigen Proofs zwischen verschiedenen Diensten und Nutzern ausgetauscht werden. Dabei haben die Nutzer die Gewissheit, dass die Proofs mit ihren Wallets oder SPV-Nodes kompatibel sind, wodurch der gesamte Prozess der Transaktionsvalidierung autonomer und zugänglicher wird.

Die Bedeutung von technischen Standards

Das Merkle-Proof-Standardformat ist der erste Standard des TSCs, der es bis zur Veröffentlichung geschafft hat. Zum Zeitpunkt der öffentlichen Prüfung war der Standard zwar schon ziemlich ausgereift, jedoch haben die Stakeholder durch ihre Rückmeldung vor der Veröffentlichung noch viele Aspekte verbessert.

Shadders erklärt, dass Standards einen wichtigen Teil zur Förderung eines innovativen und interoperablen Ökosystems beitragen, wie ihre weite Verbreitung in traditionellen Branchen zeigt. Sie verringern auch nicht den Wettbewerb, sondern machen das Ökosystem zugänglicher für Wettbewerber und Nutzer. Er zeigt am Beispiel der DVD-Branche, wie Standards den Wettbewerb fördern und das Nutzererlebnis verbessern können.

„Nehmen wir an, ich habe einen DVD-Player von Sony und ich kaufe mir einen DVD-Player von Samsung. Stellen Sie sich vor, diese Geräte würden unterschiedliche Formate benutzen – ich müsste mir eine komplett neue DVD-Sammlung kaufen, um alle meine DVDs zu ersetzen. Der Standard löst dieses Problem”, sagt er.

„Jede Wallet kann den vorhandenen Standard für Merkle-Proofs durchführen. Das bedeutet, dass die Wallets sofort mit allen anderen Wallets, die den Standard implementiert haben, kommunizieren können – sogar mit Wallets, an die sie vielleicht gar nicht gedacht haben.

Dazu gehören Wallets, die noch nicht existieren und die vielleicht in Zukunft gebaut werden.” Ohne solche Standards laufen Branchen Gefahr, den Nutzern siloartige, getrennte Ökosysteme zu bieten und die generelle Zugänglichkeit von zugrundeliegenden Technologien und der darauf aufbauenden Anwendungen zu mindern. Die  Bitcoin-SV -Community hat durch die Standardisierung des Merkle-Proof-Formats sichergestellt, dass die Interoperabilität zur grundlegenden Komponente der Innovation und des Wettbewerbs zwischen SPV-Wallets und Datenanbietern wird.

„Das wesentliche Element der SPV ist der Inclusion Proof, also der Merkle-Proof. Wenn wir diesen Standard nicht hätten, müsste sich jeder, der eine richtige SPV in einer Wallet implementieren möchte, eine Datenstruktur ausdenken. Der Nächste müsste sich entscheiden, ob er diese Datenstruktur übernimmt oder nicht. In dem Fall ergeben sich zwei inkompatible SPV-Wallets mit siloartigen Ökosystemen“, erklärt Shadders.

Er betont, dass die vom TSC veröffentlichten Standards nicht die Ansichten der Kommissionsmitglieder widerspiegeln, sondern den Input der Community. Er fügt hinzu, dass diese Standards nach der Veröffentlichung weiterhin der öffentlichen Kontrolle unterliegen und aktualisiert, verändert oder sogar eingestellt werden können, wenn es bessere Lösungen gibt oder sich die eingesetzte Technologie ändert.

„Das TSC arbeitet nur in Zusammenarbeit mit der Branche. Wir übernehmen dabei die Rolle der Vermittler und Dienstleister, aber der tatsächliche Input wird von anderen geliefert“, sagt Shadders.

„Meiner Meinung nach gibt es bei den Mitgliedern des TSC wichtige Unterschiede. Wenn TSC-Mitglieder als Teil der Kommission agieren, sind sie unabhängig und spielen die Rolle der Vermittler. Darüber hinaus sind sie natürlich alle ein Teil der Branche und haben unterschiedliche Interessen. Sie können also auch Arbeitsgruppen beitreten.“

Der TSC-Standardisierungsprozess ist darauf ausgelegt, dass ein Standard bei Bedarf zu einem späteren Zeitpunkt aktualisiert werden kann. Es kann sein, dass viele dieser Standards Aktualisierungen und Änderungen erfordern, wenn neue Anforderungen entstehen oder sich das Ökosystem ändert.

„Wir versuchen, die Teilnehmer dazu zu bewegen, an die Aufwärtskompatibilität zu denken, damit sie etwaigen zukünftigen Änderungen nicht ablehnend gegenüberstehen. Es ist jedoch durchaus möglich, dass ein Standard irgendwann einfach impraktikabel oder veraltet ist, weil sich die eingesetzte Technologie verändert hat. In diesem Fall wird der Standard höchstwahrscheinlich zurückgezogen und durch einen neuen ersetzt“, sagt Shadders.

„Wenn also jemand den Bedarf der Branche für eine Aktualisierung oder einen neuen Standard ausspricht, wird dieser Antrag eingereicht und von den Stakeholdern geprüft – nicht nur vom TSC.“

Das Merkle-Proof-Standardformat

Nachdem nun das Merkle-Proof-Standardformat bereits veröffentlicht wurde, finden Sie Informationen zum Standard auf einer eigenen Seite der TSC-Website.

Das Format legt die Datenstruktur fest, in der die Merkle-Proof-Informationen gespeichert werden, wenn sie zwischen Nutzern (z.B. SPV-Wallets) übertragen werden. Laut dem Vorwort zu den technischen Spezifikationen ist das von entscheidender Bedeutung für den effizienten und interoperablen Austausch dieser Informationen.

Das Merkle-Proof-Standardformat besteht aus zwei Komponenten:

  • Eine Darstellung des vorgeschlagenen Datenstrukturformats als Binärformat und JavaScript Object Notation (JSON).
  • Eine Erklärung des Algorithmus, der zur Validierung der Transaktionen gegen den Merkle-Proof verwendet wird, sobald sie in diesem Format empfangen wurden.

Der Anwendungsbereich für dieses Standardformat für Merkle-Proofs bezieht sich nur auf einfache Proofs, wie sie von SPV-Wallets benötigt werden, um einzelne Transaktionen beim Empfang zu validieren. Zusammengesetzte Proofs werden Thema zukünftiger erweiterter Standards sein. Die Definition von standardisierten API-Anrufen ist ebenfalls ausgeklammert, da dies nichts mit der Kerndatenstruktur zu tun hat und dazu weitere Überlegungen erforderlich sind.

Unter dem Standardformat werden Merkle-Proofs in einer Struktur gespeichert, die ein einzelnes Flagbyte, den Positionsindex der Transaktion im Merkle-Baum, eine Liste von 32-Byte-Hashes und eine Transaktions-ID oder einen Hash enthält. Diese Information kann entweder im Binär- oder JSON-Format gespeichert und wiedergegeben werden, wobei das Flagbyte zusätzliche Funktionen beschreibt. Wenn man diesen Standard verwendet, um eine Transaktion mit dem Merkle-Proof eines Blocks zu vergleichen, kann man wählen, ob man die ursprüngliche Transaktion oder nur die Transaktions-ID, den Zieltyp oder das Endelement sowie die Art des Proofs (Zweig oder Baum) einbezieht und ob dieser Proof Teil eines zusammengesetzten Proof-Sets sein soll.

Ebenfalls beschrieben ist der Ablauf der Merkle-Proof-Validierung, der mehrere Prüfungen zur Berücksichtigung der oben genannten Flags sowie die Validierung von Nodes ohne Nachbarn in der Merkle-Baum-Datenstruktur enthält.

Während der internen und öffentlichen Prüfung erhielt das TSC Feedback bezüglich der Komplexität und der Standardoptionen des Standard-Datenstrukturformats. Insbesondere legten viele Stakeholder nahe, dass der häufigste Anwendungsfall (die Validierung einzelner Transaktionen unter Verwendung geläufiger Datenfelder) keine Auseinandersetzung mit den komplexeren Aspekten des Formats erfordern sollte.

„Um dieses Problem zu beheben, wurden vor allem am JSON-Anwendungsfall Änderungen vorgenommen, sodass die Verwendung der Standardoptionen ein viel einfacheres JSON-Objekt ergibt. Dadurch bleibt die Möglichkeit erhalten, die alternativen Optionen zu verwenden, ohne den Standard zu brechen. Die optionalen Felder werden in der Standardeinstellung ausgeblendet“, heißt es in der Spezifikation.

Eine vollständige technische Beschreibung des Merkle-Proof-Standardformats finden Sie auf der TSC-Website.

So entsteht ein Bitcoin-SV-Standard

Dieser erste Standard verdeutlicht die Fähigkeiten des TSC als Mittel zur Gemeinschaftsentwicklung, um das Umfeld zu verbessern, in dem Bitcoin SV-Entwickler, Start-ups und Unternehmen tätig sind. Die interne und öffentliche Prüfung des Merkle-Proof-Standardformats hat zu einem Datenstrukturformat und Validierungsalgorithmus geführt, die einfacher zu bedienen sind. Gleichzeitig wurden Flexibilität und zukunftsweisende Unterstützung für Aufgaben wie die Validierung zusammengesetzter Proofs beibehalten.

Das TSC hält sich an einen umfassenden, mehrstufigen Standardisierungsprozess, was den Austausch mit der Community und den Stakeholdern sicherstellt. Jeder kann Vorschläge für Bitcoin SV-Standards präsentieren. Diese Vorschläge werden anschließend von der Kommission in Erwägung gezogen, bevor sie die nächste Phase – die Ausarbeitung der technischen Standards – erreichen.

Sobald der Standard ausgearbeitet wurde, wird er einer Reihe von internen Prüfungen unterzogen, die eine Überprüfung des geistigen Eigentums und eine rechtliche Prüfung beinhalten, um mögliche Probleme bei der Veröffentlichung des Entwurfs zu ermitteln. Während dieser Prüfungen gilt eine Geheimhaltungsvereinbarung, die sicherstellt, dass der vorgeschlagene Standard von der Kommission und den beteiligten Stakeholdern geheim gehalten wird.

Nach Abschluss dieser Prüfungen wird der Standard bei Bedarf einer erneuten Ausarbeitungsphase unterzogen oder einer öffentlichen Prüfung ausgesetzt. Während der öffentlichen Prüfung können interessierte Parteien Feedback zum vorgeschlagenen Standard geben. Jedes Feedback wird berücksichtigt.

Sollte es sich als relevant erweisen, wird der Standard entsprechend angepasst. Der Standard wird erst veröffentlicht, wenn die öffentliche Prüfung abgeschlossen ist. Die Arbeit ist hier jedoch noch nicht zu Ende. Nach der Veröffentlichung eines Standards prüfen das TSC und die Stakeholder die Reaktionen und die Akzeptanz innerhalb der Branche.

Nach einem angemessenen Zeitraum können sie den Standard entweder empfehlen oder die Veröffentlichung zurückziehen. Das TSC hat einen Entwicklungsprozess für Standards erstellt, der aus drei Phasen besteht. Die erste Phase ist die Einreichungsphase, in der externe Personen Anträge für die Standardisierung einreichen können, wobei es nicht relevant ist, ob man diese Dinge in ihrer eigenen Branche findet. Wir würden es aber bevorzugen, wenn sie Stakeholder in dieser Branche wären, damit sie diese Dinge tatsächlich nutzen und den Bedarf in dieser Branche erhöhen“, erklärt TSC-Gründungsmitglied Alex Fauvel.

„In der zweiten Phase geht es um die Ausarbeitung. Tatsächlich erstellen wir hier den ersten Entwurf, dann folgt die interne Prüfung und im Anschluss lassen wir den Entwurf von IP-Spezialisten prüfen. Und bei Bedarf wird er dann von technischen Spezialisten geprüft.“

„Wenn wir mit dem ersten Entwurf zufrieden sind und er mehrere Zyklen durchlaufen hat, veröffentlichen wir ihn, damit die Öffentlichkeit die Möglichkeit hat, Feedback zu geben. Dafür ist ein Zeitraum von zwei Monaten vorgesehen, und sobald wir dieses Feedback (falls erforderlich) eingearbeitet haben, veröffentlichen wir den Standard. Das ist die dritte Phase. Anschließend beobachten wir die Annahme des Standards in der Branche, um ihn entweder abzusegnen und zu empfehlen oder um ihn zurückzuziehen, was wir hoffentlich nicht tun werden!“

Das TSC nutzt diesen Prozess, um auch weiterhin die Erstellung von nützlichen und einflussreichen Standards für die Entwicklung von Bitcoin SV zu erleichtern. Dazu gehört unter anderem die sogenannte ‚Envelope Specification‘, die sich derzeit in der öffentlichen Prüfungsphase befindet und offen für Feedback ist. Diese Spezifikation befasst sich mit der Art, wie Daten innerhalb von Bitcoin-Transaktionen gespeichert werden, indem ein allgemeiner Datenumschlag erstellt wird, der eine effiziente Verarbeitung von Informationen und Interoperabilität mit bestehenden und zukünftigen Datenprotokollen ermöglicht.

Um sich an der Entwicklung von technischen Standards für Bitcoin SV zu beteiligen,  besuchen Sie die TSC-Website  und schlagen Sie einen neuen Standard vor, geben Sie Feedback für Entwürfe von Standards unter öffentlicher Prüfung oder reichen Sie Vorschläge zum Entwurf der Roadmap ein.

Scroll to Top