Wie können Merkle-Bäume sicherstellen, dass ein vollständiger Knoten nicht auf einem dünnen Knoten liegt, auf dem ein txn t in einem Block B nicht vorhanden ist, wenn B tatsächlich t enthält? Wie kann ein Thin Node feststellen, ob der Full Node lügt, wenn der Full Node das Vorhandensein eines txn t in Block B leugnet und keine Hash-Werte sendet (zur Überprüfung durch den Thin Node) und stattdessen behauptet, dies nicht zu können? generiert Hashes, die nicht vorhanden sind.
PS: Beachten Sie den informellen Stil meiner Befragung nicht. Ich versuche zunächst nur, Merkle Trees intuitiv zu verstehen.
Ihr Instinkt ist richtig: Ein Full Node kann einen Light Client durch Auslassung belügen und ihm den Beweis verweigern, dass eine Transaktion in einem Block enthalten war. Dies ist eine gut dokumentierte Schwachstelle von SPV-Wallets, und die einzige Abhilfe besteht wirklich darin, sich mit mehr Peers zu verbinden (Sie brauchen nur einen „ehrlichen“ Peer).
Dieses Problem wird auch etwas von BIP157 alias "Neutrino" angegangen. Bei diesem Protokoll scannt der Light-Client ganze Blöcke nach eigenen Transaktionen. Es weiß, welche Blöcke basierend auf Filtern überprüft werden müssen, die von vollständigen Knoten bereitgestellt werden. Das bringt uns natürlich zurück zum ersten Problem: Was ist, wenn ein vollständiger Knoten einen ungültigen Filter liefert? Irgendwann sehen wir vielleicht einen Soft Fork, der erfordert, dass gültige Filter in einen Teil des Blocks eingefügt werden, gesichert durch Proof-of-Work.
Derzeit bietet BIP157 Folgendes an:
Sofern er nicht sicher mit einem vertrauenswürdigen Peer verbunden ist, der Filter-Header bereitstellt, SOLLTE der Client eine Verbindung zu mehreren ausgehenden Peers herstellen, die jeden Filtertyp unterstützen, um das Risiko des Herunterladens falscher Header zu verringern. Wenn der Client widersprüchliche Filter-Header von verschiedenen Peers für einen beliebigen Block- und Filtertyp erhält, SOLLTE er sie abfragen, um festzustellen, welcher fehlerhaft ist. Der Client SOLLTE getcfheaders und/oder getcfcheckpt verwenden, um zuerst die ersten Filterheader zu identifizieren, bei denen die Peers anderer Meinung sind. Der Client SOLLTE dann den vollständigen Block von einem beliebigen Peer herunterladen und den richtigen Filter und Filterheader ableiten. Der Client SOLLTE alle Peers sperren, die einen Filter-Header gesendet haben, der nicht mit dem berechneten übereinstimmt.