Wie würden SPV-Proofs verifiziert, wenn Assets in 2-Wege-gekoppelte Sidechains zurückverlagert werden?

Ihre Frage ist genau richtig und stellt das Hauptproblem der Sidechain-Schnittstelle dar: Wie kann man einer Kette (nennen Sie es die "Mainchain") beweisen, dass ein Ereignis (z. B. eine Einzahlung) auf einer entfernten Kette (nennen Sie es die "Sidechain" ).

Soweit mir bekannt ist, gibt es noch keine genauen Einzelheiten darüber, wie dies funktioniert, aber es gibt mehrere Ansätze, die verfolgt werden können. Der hier übliche Ansatz besteht darin, einer Gruppe von „Funktionären“ oder „Fischern“ zu erlauben, die Transaktion auf der Sidechain zu beobachten, darauf zu warten, dass sie dort bestätigt wird, und dann durch die Unterzeichnung einer Erklärung für die Tatsache zu bürgen, dass sie stattgefunden hat (ein „Zertifikat“), das bescheinigt, dass die Transaktion in der Sidechain wirklich stattgefunden hat. Dies kann gut funktionieren, wenn es einige Ehrlichkeitsannahmen über die Funktionäre gibt, zB dass die Mehrheit von ihnen ehrlich ist. In diesem Fall kann die Auszahlung in der Praxis wirklich eine Multisig-Prüfung sein. Dieser Ansatz würde mit der bestehenden Bitcoin-Implementierung funktionieren.Plasma , Polkadot, Elemente.

Wenn Sie nicht im Bitcoin-Gebiet bleiben wollen, gibt es elegantere Lösungen mit unterschiedlichen Vertrauensannahmen, die sich realisieren lassen. Wenn Ihnen das Bedrohungsmodell einer zentralisierten Gruppe von Funktionären (oder einer "Föderation" davon) nicht gefällt und Sie völlig vertrauenswürdig vorgehen möchten, müssen Sie auf dezentrale Weise einen Beweis für ein entferntes Ereignis erbringen. Dieser Beweis muss die Form einer einfachen Zeichenfolge haben, die bestätigt, dass etwas auf der entfernten Kette passiert ist, selbst wenn die lokalen Bergleute sich nicht mit dieser entfernten Kette verbinden und nicht wissen, wie ihr Konsens funktioniert.

Wenn die Sidechain einen Proof-of-Work-Konsens hat, stellen diese Proofs eine Behauptung auf, die die Tatsache bestätigt, dass ein ausreichender Proof-of-Work stattgefunden hat, um eine Transaktion in der Remote-Chain zu begraben. Da sie belegen, dass ein Proof-of-Work stattgefunden hat, handelt es sich um „Proofs of Proof-of-Work“ (PoPoWs). Die Überprüfung solcher Beweise ist nicht trivial und Bitcoin hat derzeit keinen Opcode, um dies zu tun, noch ist eine Unterstützung geplant. Daher wären solche Schemata möglich, wenn die Hauptkette eine Turing-vollständige Blockchain ist oder einen PoPoW-Opcode unterstützt (unwahrscheinlich).

Andererseits muss die Sidechain auch die Generierung dieser Beweise unterstützen. Dies kann in die Kette integriert werden, wie ERGO , WebDollar oder Nimiq . Eine Blockchain ohne PoPoW-Unterstützung kann ohne Soft Forking und ohne Miner-Zulassung hinzugefügt werden, indem ein entsprechender Velvet Fork durchgeführt wird .

Schließlich müssen diese PoPoWs von Seitenkettenbetreuern in einem "einmaligen" Versuch erzeugt werden, der eine einfache Zeichenfolge generiert, und sie sollten keine Interaktion erfordern, dh sie sollten nicht-interaktive Proofs of Proof-of-Work (NIPoPoWs) sein. Angesichts dieser Zutaten können Sie es auf völlig vertrauenslose Weise tun.

Alle oben genannten Konstruktionen setzen voraus, dass Sidechain und Mainchain unabhängig voneinander sicher überleben. Zum Beispiel muss die Sidechain ehrliche Mehrheitsrechenleistung haben, wenn sie PoW-basiert ist.

Zusammenfassend lässt sich sagen, dass Bitcoin derzeit keine Möglichkeit hat, das, was Sie verlangen, auf vertrauenslose Weise zu tun, aber es gibt föderierte / cothority-Möglichkeiten, dies zu tun. Wenn Sie bereit sind, an neuen Systemen zu arbeiten, können Sie dies dezentral tun.

Haftungsausschluss: Ich bin einer der Co-Autoren des Non-Interactive Proofs of Proof-of-Work-Papiers.

Als Erstes ist es wichtig zu verstehen, dass diese Methode eine von zwei verschiedenen Möglichkeiten ist, Münzen zwischen zwei Ketten hin und her zu bewegen. Das andere heißt Federated Peg , von dem ich glaube, dass es erfolgreicher sein wird, obwohl es weniger technisch ausgefeilt und zentralisierter ist.

Allgemeines Konzept

Der erste Schritt besteht darin, dass Sie eine Transaktion auf der Sidechain senden, die Ihr Geld an Ort und Stelle hält. Sobald diese Transaktion einige Bestätigungen hat, erstellen Sie den SPV-Nachweis, um ihn an die Mainchain zu senden.

Gehen wir näher auf diesen letzten Schritt ein:

Wenn Sie einen SPV-Client ausführen, lädt Ihr Client keine vollständigen Blöcke herunter. Es lädt Header herunter. Dann lädt es die Transaktionen in oder aus Ihrer Brieftasche herunter. Dann lädt es die Merkle-Zweige herunter, um Ihre Transaktion mit einem der Block-Header zu verbinden.

Wenn Sie einen SPV-Proof erstellen, nehmen Sie diese Block-Header, die Sie heruntergeladen haben, und diese Merkle-Zweige, die Sie mit Ihrer Transaktion und Ihrer speziellen Coin-Locking-Transaktion verbinden müssen, und Sie serialisieren sie in einer einzigen Datenstruktur.

Warum müssen wir den SPV-Proof überhaupt serialisieren?

…können die Nodes, die den SPV-Proof prüfen, Nodes in der Sidechain nicht bitten, die SPV-Daten bereitzustellen?

Nein, da die Sidechain-Knoten möglicherweise unterschiedlich auf verschiedene Mainchain-Knoten antworten. Das würde zu einem Fork der Mainchain führen. Ein serialisierter SPV-Proof wird von allen Mainchain-Knoten auf die gleiche Weise ausgewertet.

Einige Komplikationen

Der SPV-Beweis stimmt möglicherweise nicht mit dem Sidechain-Netzwerk überein

Wenn ich viel Mining-Power habe, muss ich kein Geld auf der Sidechain haben, um Geld von Sidechain-Ausgängen auf der Mainchain abzuheben. (dh ich kann eine Sidechain-Entnahme vortäuschen.)

So funktioniert es: Ich erstelle eine Transaktion aus einer gefälschten Ausgabe auf der Sidechain. Wenn ich dies an die Sidechain senden würde, würden alle Knoten es ablehnen. Ich schürfe jedoch einen Block, der diese Transaktion enthält, und mache weiter, bis ich genug Blöcke bekomme, damit die Mainchain meinem SPV-Beweis vertraut.

Abmilderungen

1. Fordern Sie weitere Bestätigungen an, bevor Sie Geld von der Sidechain in die Mainchain verschieben
2. Erstellen Sie eine Nachfrist, in der jemand Ihre Auszahlung blockieren kann, indem er einen „Counter-SPV-Nachweis“ erstellt, der eine längere Kette von Arbeitsnachweisen zeigt, die Ihren Block-Header nicht enthalten.
3. Wenn die Sidechain feststellt, dass jemand erfolgreich Geld gestohlen hat, markiert sie alle zukünftigen Abhebungen, um einen Bank Run zu vermeiden.

Was Sie einzahlen, stimmt nicht mit dem überein, was Sie abheben

Wenn Sie die Sidechain für Transaktionen verwenden, werden Sie am Ende mit mehr oder weniger Geld auskommen als zu Beginn. Dies ist jedoch eine Softfork, sodass wir nicht einfach alle eingehenden Gelder in einen einzigen Topf einzahlen können. Alle Gelder verteilen sich auf viele verschiedene Ausgaben, und in Bitcoin müssen Sie jede Ausgabe, die Sie beanspruchen, vollständig ausgeben. (Sie können eine Ausgabe nicht teilweise beanspruchen.) Dafür gibt es zwei Lösungen:

1. Sperren Sie den genauen Geldbetrag einer Ausgabe auf der Mainchain ein und fordern Sie ihn dann ein. Tun Sie dies möglicherweise viele Male. Das ist einfach, hat aber zwei Probleme: Erstens verbraucht es mehr Blockchain-Speicherplatz als nötig; zweitens, wenn es keine Menge an Outputs gibt, die sich genau zu dem summieren, was Sie abheben, wird ein Teil Ihres Geldes in der Sidechain stecken bleiben.

2. Personen erlauben, eine oder mehrere Ausgaben zu beanspruchen und optional Änderungen an eine andere OP_SPVPROOFVERIFY-Ausgabe zu senden. Diese Lösung ist viel flexibler, hat aber einige versteckte Zähne. (Können Sie versehentlich eine Miner-Gebühr von 80 BTC senden, weil Sie Ihr Javascript vermasselt haben ? Werden die Leute einen Anreiz haben, die Staubausgaben zu vermeiden, was zu einer Reihe von Ausgaben führt, für deren Einlösung niemand bezahlen möchte?)

Dinge, die keine Komplikationen sind

Knoten auf der Mainchain, die OP_SPVPROOFVERIFY nicht verstehen

Da es sich um eine Softfork handelt, müssen nicht alle Knoten aktualisiert werden.

Was kann in einer Sidechain geändert werden?

Da wir davon ausgehen, dass wir einen neuen Opcode von Grund auf neu entwerfen, können wir dafür sorgen, dass er viele verschiedene Dinge unterstützt. Es könnte Scrypt, X11 und jeden gewünschten Hash-Algorithmus unterstützen. Es kann den reinen Proof of Stake nicht sinnvoll unterstützen. Es könnte mehrere verschiedene Zielzeiten, Adresstypen usw. unterstützen.

Es kann jedoch keine unvorhergesehenen Änderungen unterstützen. Wenn sich also jemand eine brillante Änderung einfallen lässt, die für SPV-Kunden sichtbar ist, funktioniert es mit den oben genannten nicht.

Nun, das stimmt nicht ganz. Sie könnten zwei Anweisungen erstellen, OP_SPVPROOFCHECKERREGISTER und OP_SPVPROOFVERIFY. Das erste würde ein Ethereum-ähnliches Skript registrieren, das den Status behalten könnte, und alle eingehenden Rücknahmeanträge prüfen würde. Der zweite würde einen Geldbetrag bereitstellen, bis das erstere Skript sagte, dass es freigeschaltet werden könnte. Das würde beliebige SPV-sichere Systeme (obwohl es immer noch keine reinen PoS-Systeme erlauben würde) auf Kosten einer erhöhten Komplexität ermöglichen.