Standard: Merkle-Proof-Datenformat

Antragsteller: Steve Shadders (nChain) TSC-Sponsor: Ryan X Charles (Money Button) Autoren: (automatisch vorgeschlagen) Steve Shadders Prüfer: TBA-Ergänzung: Bei Bedarf kann der TSC-Nutzer, Implementoren, Sachverständige und Normungsexperten für zusätzliche Aufgaben innerhalb einer Arbeitsgruppe benennen. Fachgutachter: Recht, IP, Compliance

1. Hintergrund

  1. Problemstellung

    Ein Merkle-Proof stellt einen Zweig eines Hash-Baums mit einer Wurzel dar, die normalerweise im Header eines Bitcoin-Blocks eingebettet ist. Die Durchführung des Nachweises erfordert die Neuzusammenstellung der bereitgestellten Datenelemente mit den berechneten Datenelementen nach einem bestimmten Algorithmus. Ein Merkle-Proof-Format muss nicht nur die erforderlichen Daten festlegen, sondern auch, wie diese Daten im Kontext der algorithmischen Ausführung zu interpretieren sind.

  2. Ziele/Begründung

    Der Merkle-Proof ist grundlegend für das SPV-Modell (Simplified Payment Verification/vereinfachte Zahlungsverifizierung), das im ursprünglichen Bitcoin-Whitepaper beschrieben wurde und die Bitcoin-Skalierung unterstützt. Damit SPV-Wallets sie nutzen können, müssen Miner oder andere Akteure, die vollständige Blöcke herunterladen, Merkle-Proofs den Wallets zur Verfügung stellen. Da es wahrscheinlich eine Vielzahl von Implementierungen geben wird, die Merkle-Proofs aus verschiedenen Gründen übertragen und empfangen, vereinfacht es die Implementierungen im gesamten Ökosystem, wenn ein genormtes Format verwendet wird. Der derzeitige Stand der Technik kommt in FilteredBlock p2p-Nachrichten zum Ausdruck, die einen Bitvektor und eine Liste von Hashes verwenden. Diese Regelung ist unnötig verwirrend und erfordert die Validierung des Proofs in umgekehrter Richtung, da sie keinen einfachen Mechanismus zur Berechnung des Positionsindexes einer Transaktion im Hash-Baum bietet. Außerdem wird diese P2P-Nachricht aufgrund der inhärenten Skalierbarkeitsprobleme bei der Verwendung von Bloom-Filtern für SPV-Kunden wahrscheinlich zugunsten anderer Mechanismen veraltet sein.

  3. Anwendungsbereich

    Der häufigste Anwendungsfall für einen Merkle-Proof ist der Nachweis, dass eine Transaktion in einen Block aufgenommen wurde. Dies wird als SPV (Simplified Payment Verification) bezeichnet. Der Nachweis selbst kann zusätzliche Informationen erfordern, darunter die Transaktion, den Index der Transaktion in einem Block und einen Verweis auf den Kopf des Blocks, in dem sie enthalten ist. Wenn eine Transaktion noch nicht in einem Block enthalten ist oder wenn ein Merkle-Proof für sie noch nicht verfügbar ist, kann der Nachweis anhand einer ununterbrochenen Kette von Vorgängertransaktionen erbracht werden, die in einer Transaktion resultiert, für die ein Merkle-Proof erbracht werden kann. Wir bezeichnen diesen erweiterten Datensatz vorläufig als „SPV-Envelope“, der Merkle-Proof- und weitere Daten enthält. Der SPV-Envelope stellt somit eine Übergruppe des Merkle-Proof-Formats selbst dar. Obwohl wir den SPV-Envelope als integralen Bestandteil zur Erfüllung der Bedürfnisse der Branche betrachten, sollte er separat gehalten werden und fällt nicht in den Anwendungsbereich dieses Normungsvorschlags, da eine solche Norm das Merkle-Proof-Element unabhängig von seiner Formatierung einschließen kann.

  4. Vorteile

    Das TSC-Leitbild beinhaltet das Ziel: „den Nutzen von Bitcoin SV zu verbessern, indem die Interoperabilität durch Normung erhöht wird“. Merkle-Proof-Daten sind das Herzstück der Peer-to-Peer-Interaktionen auf Bitcoin. Definitionsgemäß erfordert eine solche Interaktion das Zusammenwirken von Systemen, die wahrscheinlich sehr unterschiedlich und einzigartig sind. Der primäre Nutzen der Entwicklung eines standardisierten Merkle-Proof-Datenformats steht daher im Einklang mit den erklärten Zielen des TSCs und deckt einen Bedarf, der die Implementierung eines grundlegend primitiven SPV-Betriebs im gesamten Ökosystem vereinfachen wird.

  5. Arbeitsergebnis

    Ein Normendokument, das ein Datenformat und den dazugehörigen Ausführungsalgorithmus für den Empfang und die Ausführung eines Merkle-Proofs beschreibt. Diese Norm sollte das Format auf eine solche Weise beschreiben, dass sie sowohl in einem binären als auch in einem lesbaren Format implementiert werden kann.

2. Kurze Beschreibung des Arbeitsgruppenprozesses

Extern: Aufruf zur Interessenbekundung für die Mitarbeit im Überprüfungsgremium Intern: Entwurf >> Überprüfung >> Iteration (falls erforderlich) Intern: Fachliche Überprüfung (Recht, IP, Compliance) >> Iteration zum Entwurf (falls erforderlich) Extern: Öffentliche Überprüfung >> Antwort auf Kommentare >> Iteration zum Entwurf (falls erforderlich) Extern: Ratifizierung durch TSC

3. Ernennung von Prüfern

Bitte beachten Sie, dass zu einem späteren Zeitpunkt im Standardentwicklungsprozess ein öffentlicher Überprüfungsprozess vorgesehen ist, der jeder Person offensteht, die sich in den Prozess einbringen möchte.

  1. Kriterien

    Kandidaten, die sich für die Mitarbeit im Prüfungsgremium dieser TSC-Arbeitsgruppen bewerben möchten, sollten die folgenden Kriterien erfüllen:

    • Sie sollten über mindestens eine der folgenden Eigenschaften verfügen:
      1. Fachwissen in dem spezifischen Bereich Normungsvorschlags
        • Bachelor-Abschluss oder gleichwertige Erfahrung in einem einschlägigen Studienfach.
          • z. B. Ingenieurwesen, Informatik, Mathematik, andere einschlägige Fachgebiete.
      2. Sie sollten als aktueller oder künftiger Anwender oder Umsetzer der Norm ein wichtiger Interessenvertreter für die Ergebnisse dieses Standards sein
      3. Sie sollten über umfangreiche Erfahrungen in der Entwicklung von Normen in Verbindung mit einer international anerkannten Normungsorganisation verfügen
    • Sie sollten bereit sein, eine GHV für die Dauer des Lebenszyklus der Arbeitsgruppe zu unterzeichnen
    • Sie sollten über ausreichend Zeit verfügen, um den Überprüfungsprozess während der voraussichtlichen Dauer der Arbeitsgruppe durchzuführen (als Richtwert gilt, dass der Lebenszyklus einer Arbeitsgruppe zwischen 3 und 4 Monaten liegt und in der Regel mehrere Tage Überprüfungsarbeit, verteilt auf 2 bis 3 Iterationen eines Normenentwurfs, erfordert)
  2. Bewerbung

    Bewerbungen für die Teilnahme an der internen Entwicklungsphase dieser Norm können unter Angabe der oben genannten Kriterien in einer E-Mail an folgende Adresse gerichtet werden: [email protected]. Alle Bewerbungen müssen bis zum 3. Juli 2020 eingehen.