Wie können Personen, die Thin Clients verwenden, den korrekten Merkle-Pfad der von ihnen gesendeten Transaktionen kennen, ohne den vollständigen Block zu kennen?

Benutzer A sendet eine Transaktion an Benutzer B. Diese Transaktionen werden in einem Merkle-Baum gebündelt. Benutzer A und B können beide die Transaktion plus den Merkle-Stamm plus den Merkle-Pfad verwenden, um zu beweisen, dass der Merkle-Stamm im Block-Header korrekt ist.

Lassen Sie mich Ihre Frage umformulieren, um sicherzustellen, dass wir auf derselben Seite sind:
Alice bezahlt Bob. Wenn Alice ihre Transaktion an das Netzwerk übermittelt, ist sie noch unbestätigt. Die Transaktion wird bestätigt, indem sie in einen Block aufgenommen wird. Der Block-Header enthält die Merkle-Root, die eine kryptografische Verpflichtung zum enthaltenen Transaktionssatz (in der Reihenfolge) darstellt.

Weder Alice noch Bob kennen zu diesem Zeitpunkt den Merkle-Pfad. Abhängig vom Thin Client, den sie ausführen, fordert ihre Wallet entweder einen Full-Node-Peer auf, Transaktionen zu kennzeichnen, die mit einem Bloom-Filter übereinstimmen, der ihre Interessen codiert (BIP 37 (veraltet)), sie vertrauen darauf, dass ein Dienstanbieter ihre Adressen kennt (Electrum, verschiedene zentralisierte Wallet-Dienste), oder sie laden kompakte clientseitige Blockfilter herunter, die sie lokal verwenden können, um zu sehen, ob ein Block etwas Interessantes enthalten könnte (BIP 157/158).

Sobald der Thin Client von einer Transaktion erfährt, an der er interessiert ist, fordert der Thin Client entweder speziell den Merkle-Block für die Transaktion oder den vollständigen Block von einem Full-Node-Peer oder seinem Dienstanbieter an. Die Merkle-Blockdatenstruktur verfügt über alle notwendigen Hashing-Partner, um den vollständigen Zweig vom Transaktionsblatt bis zur Wurzel sowie den Block-Header (wie natürlich auch den vollständigen Block) nachzuvollziehen. So wissen sie es!

Wie chytrik in einer anderen Antwort schrieb , folgen die meisten Thin Clients dem Netzwerk, indem sie die Block-Header-Kette synchronisieren. Da sie nicht die vollständigen Blöcke parsen, verfolgen sie nicht das vollständige Hauptbuch der Bitcoin-Salden (der nicht ausgegebene Transaktionsausgabesatz) und können daher Transaktionen nicht validieren. Sie können jedoch grundlegende Gültigkeitsprüfungen an Blöcken durchführen, z. B. ob sie die aktuelle Schwierigkeitsanforderung erfüllen und ob der Inhalt des Block-Headers tatsächlich mit dem angegebenen Hash übereinstimmt.

Wie kennen A und B den richtigen Merkle-Pfad, ohne den gesamten Block zu benötigen?

Viele Light-Clients synchronisieren sich mit der längsten Kette von Headern, unter der Annahme, dass andere Knoten im Netzwerk den vollständigen Inhalt dieser Blöcke auf Gültigkeit prüfen. (Bedenken Sie: Wenn jeder Knoten ein Light-Client wäre, könnten Miner ungültige Transaktionen in Blöcke aufnehmen, und keiner der Light-Clients würde es wissen!)

Durch Anfordern der Zwischenzustände des Merkle-Baums von einem Knoten, der den vollständigen Block hat, kann ein Light-Client auf effizientere Weise überprüfen, ob eine Transaktion, an der der Benutzer interessiert ist, tatsächlich in einem Block enthalten ist, der Teil der längsten Kette ist als den gesamten Block selbst zu validieren (der Vorbehalt ist die oben erwähnte Annahme der Gültigkeit).

Benötigen sie einen zentralen Anbieter, der die Blöcke verarbeitet, um diese für sie zu berechnen? Ist das dezentral möglich?

Dies hängt ganz von der Implementierung ab. Einige Light-Wallets rufen möglicherweise einfach einen bestimmten Server zurück, der beispielsweise von den Entwicklern der Brieftasche betrieben wird. Andere Light-Clients versuchen möglicherweise, diese Informationen von zufälligen Knoten im Netzwerk abzurufen. Einige sind sogar so gebaut, dass sie sich mit Ihrem eigenen Knoten verbinden.

Letztendlich wird die höchste Gewissheit erreicht, wenn Sie selbst einen vollständig validierenden Knoten (dh einen vollständigen Knoten) betreiben. Wie Bitcoiner gerne sagen: Vertraue nicht, verifiziere.