Der Anforderungstext muss den folgenden Parameter enthalten: 'state'
xBORDER WHITEPAPER 2019

Die Geschichte
xBORDER als Zustandsübergangssystem
Bergbau im Allgemeinen
Merkle-Bäume
Alternative Blockchain-Anwendungen
Skripterstellung für xBORDER
BLOCKCNX
Philosophie
xBORDER-Konten
Nachrichten und Transaktionen
Mitteilungen
xBORDER Zustandsübergangsfunktion
Codeausführung
xBORDER und Bergbau
Anwendungen
Token-Systeme
Finanzderivate und wertbeständige Währungen
Identitäts- und Reputationssysteme
Dezentraler Dateispeicher
Dezentrale autonome Organisationen
Weitere Anwendungen
Verschiedenes und Bedenken
Modifizierte GHOST-Implementierung
Honorare
Berechnung und Turing-Vollständigkeit
Währung und Ausgabe
Bergbau-Zentralisierung
Skalierbarkeit
Fazit
Anmerkungen und weiterführende Literatur
Anmerkungen
Weiterführende Lektüre
Einführung in Bitcoin und bestehende Konzepte

Das Konzept der dezentralen digitalen Währung sowie alternativer Anwendungen wie Grundbuchämter gibt es seit Jahrzehnten. Die anonymen E-Cash-Protokolle der 1980er und 1990er Jahre, die sich hauptsächlich auf ein kryptografisches Primitiv stützten, das als Chaumian-Blinding bekannt ist, boten eine Währung mit einem hohen Maß an Privatsphäre, aber die Protokolle konnten sich aufgrund ihrer Abhängigkeit von einem zentralisierten Vermittler weitgehend nicht durchsetzen . 1998 war Wei Dais B-Geld der erste Vorschlag, der die Idee einführte, Geld durch das Lösen von Rechenrätseln sowie dezentralen Konsens zu schaffen, aber der Vorschlag enthielt kaum Details darüber, wie der dezentrale Konsens tatsächlich umgesetzt werden könnte. Im Jahr 2005 führte Hal Finney ein Konzept wiederverwendbarer Arbeitsnachweise ein, ein System, das Ideen von B-Money zusammen mit Adam Backs rechenintensiven Hashcash-Rätseln verwendet, um ein Konzept für eine Kryptowährung zu erstellen, aber erneut hinter dem Ideal zurückblieb, indem es sich darauf stützte Trusted Computing als Backend. Im Jahr 2009 wurde erstmals eine dezentrale Währung von Satoshi Nakamoto in die Praxis umgesetzt, die etablierte Primitive zur Verwaltung des Eigentums durch Public-Key-Kryptografie mit einem Konsensalgorithmus zur Verfolgung des Besitzes von Münzen kombiniert, der als „Arbeitsnachweis“ bekannt ist.

Der xBORDER-Mechanismus hinter Proof of Work war ein Durchbruch in diesem Bereich, da er gleichzeitig zwei Probleme löste. Erstens stellte es einen einfachen und mäßig effektiven Konsensalgorithmus bereit, der es den Knoten im Netzwerk ermöglichte, sich gemeinsam auf eine Reihe kanonischer Aktualisierungen des Zustands des Crypto-Ledgers zu einigen. Zweitens stellte es einen Mechanismus bereit, der den freien Eintritt in den Konsensprozess ermöglichte und das politische Problem löste, zu entscheiden, wer den Konsens beeinflussen darf, während gleichzeitig Sybil-Angriffe verhindert wurden. Dies geschieht, indem eine formale Barriere für die Teilnahme, wie die Anforderung, als einzigartige Einheit auf einer bestimmten Liste registriert zu sein, durch eine wirtschaftliche Barriere ersetzt wird – das Gewicht eines einzelnen Knotens im Konsensabstimmungsprozess ist direkt proportional zur Rechenleistung die der Knoten bringt. Seitdem wurde ein alternativer Ansatz namens Proof of Stake vorgeschlagen, bei dem das Gewicht eines Knotens proportional zu seinen Währungsbeständen und nicht zu seinen Rechenressourcen berechnet wird. Die Diskussion der relativen Vorzüge der beiden Ansätze würde den Rahmen dieses Papiers sprengen, aber es sollte beachtet werden, dass beide Ansätze als Rückgrat einer Kryptowährung dienen können.

Peter Oldenburger, der Gründer von xBORDER, schrieb diesen Blogbeitrag:

die Krypto als Zustandsübergangssystem 
Das Ledger einer Kryptowährung wie der Crypto kann als Zustandsübergangssystem betrachtet werden, bei dem es einen "Zustand" gibt, der aus dem Eigentumsstatus aller existierenden Cryptos und einer "Zustandsübergangsfunktion" besteht, die einen Zustand und eine Transaktion annimmt und gibt einen neuen Zustand aus, der das Ergebnis ist. In einem Standard-Bankensystem ist der Zustand beispielsweise eine Bilanz, eine Transaktion ist eine Anforderung, $X von A nach B zu verschieben, und die Zustandsübergangsfunktion verringert den Wert auf dem Konto von A um $X und erhöht den Wert auf dem Konto von B Konto von $X. Wenn das Konto von A von vornherein weniger als $X hat, gibt die Zustandsübergangsfunktion einen Fehler zurück. Somit kann man formal definieren:

APPLY(S,TX) -> S' oder ERROR
APPLY({ Alice: $50, Bob: $50 },"sende $20 von Alice an Bob") = { Alice: $30, Bob: $70 }
APPLY({ Alice: $50, Bob: $50 },"sende $70 von Alice an Bob") = ERROR
Der „Zustand“ in der Krypto ist die Sammlung aller Coins (technisch „nicht ausgegebene Transaktionsausgaben“ oder UTXO), die abgebaut und noch nicht ausgegeben wurden, wobei jeder UTXO einen Nennwert und einen Eigentümer (definiert durch eine 20-Byte-Adresse) hat das ist im Wesentlichen ein kryptographischer öffentlicher Schlüsselfn. 1). Eine Transaktion enthält eine oder mehrere Eingaben, wobei jede Eingabe einen Verweis auf ein vorhandenes UTXO und eine kryptografische Signatur enthält, die von dem privaten Schlüssel erzeugt wird, der der Adresse des Eigentümers zugeordnet ist, und eine oder mehrere Ausgaben, wobei jede Ausgabe ein neues UTXO enthält, das hinzugefügt werden soll der Staat.

Die Zustandsübergangsfunktion APPLY(S,TX) -> S' kann grob wie folgt definiert werden:

Für jeden Eingang in TX:

Wenn sich das referenzierte UTXO nicht in S befindet, wird ein Fehler zurückgegeben.
Wenn die bereitgestellte Signatur nicht mit dem Eigentümer des UTXO übereinstimmt, wird ein Fehler zurückgegeben.
Wenn die Summe der Nennwerte aller Eingabe-UTXO kleiner als die Summe der Nennwerte aller Ausgangs-UTXO ist, wird ein Fehler zurückgegeben.

Geben Sie S' zurück, wobei alle Eingabe-UTXO entfernt und alle Ausgabe-UTXO hinzugefügt wurden.

Die erste Hälfte des ersten Schritts verhindert, dass Transaktionssender Coins ausgeben, die nicht existieren, die zweite Hälfte des ersten Schritts verhindert, dass Transaktionssender Coins anderer Leute ausgeben, und der zweite Schritt erzwingt die Werterhaltung. Um dies für die Zahlung zu verwenden, ist das Protokoll wie folgt. Angenommen, Alice möchte 11,7 BTC an Bob senden. Zuerst sucht Alice nach einem Satz verfügbarer UTXO, die sie besitzt und die sich auf mindestens 11,7 BTC belaufen. Realistischerweise wird Alice nicht in der Lage sein, genau 11,7 BTC zu bekommen; sagen, dass das kleinste, was sie bekommen kann, 6 + 4 + 2 = 12 ist. Dann erstellt sie eine Transaktion mit diesen drei Eingaben und zwei Ausgaben. Die erste Ausgabe wird 11,7 BTC mit Bobs Adresse als Eigentümer sein, und die zweite Ausgabe wird die verbleibenden 0,3 BTC „Wechsel“ sein, wobei die Eigentümerin Alice selbst ist.

Bergbau
block_bild.jpg

Wenn wir Zugang zu einem vertrauenswürdigen zentralen Dienst hätten, wäre dieses System einfach zu implementieren; Es könnte einfach genau wie beschrieben codiert werden, wobei die Festplatte eines zentralisierten Servers verwendet wird, um den Status zu verfolgen. Mit der Krypto versuchen wir jedoch, ein dezentralisiertes Währungssystem aufzubauen, daher müssen wir das Zustandsübergangssystem mit einem Konsenssystem kombinieren, um sicherzustellen, dass sich alle über die Reihenfolge der Transaktionen einigen. Der dezentrale Konsensprozess von Crypto erfordert, dass Knoten im Netzwerk kontinuierlich versuchen, Transaktionspakete, sogenannte „Blöcke“, zu erstellen. Das Netzwerk soll ungefähr alle zehn Minuten einen Block produzieren, wobei jeder Block einen Zeitstempel, eine Nonce, einen Verweis auf (d. h. einen Hash des) vorherigen Blocks und eine Liste aller Transaktionen enthält, die seit dem vorherigen stattgefunden haben Block. Im Laufe der Zeit entsteht so eine dauerhafte, ständig wachsende „Blockchain“, die ständig aktualisiert wird, um den neuesten Stand des Crypto-Ledgers darzustellen.

Der Algorithmus zum Prüfen, ob ein Block gültig ist, ausgedrückt in diesem Paradigma, ist wie folgt:

Überprüfen Sie, ob der vorherige Block, auf den der Block verweist, existiert und gültig ist.
Überprüfen Sie, ob der Zeitstempel des Blocks größer ist als der des vorherigen Blockfn. 2 und weniger als 2 Stunden in die Zukunft
Überprüfen Sie, ob der Arbeitsnachweis für den Block gültig ist.
Sei S[0] der Zustand am Ende des vorherigen Blocks.
Angenommen, TX ist die Transaktionsliste des Blocks mit n Transaktionen. Setze für alle i in 0...n-1 S[i+1] = APPLY(S[i],TX[i]) Wenn eine Anwendung einen Fehler zurückgibt, beende sie und gebe false zurück.
Gib wahr zurück und registriere S[n] als Zustand am Ende dieses Blocks.
Im Wesentlichen muss jede Transaktion im Block einen gültigen Zustandsübergang vom kanonischen Zustand vor der Ausführung der Transaktion zu einem neuen Zustand bereitstellen. Beachten Sie, dass der Zustand in keiner Weise im Block codiert ist; Es ist eine reine Abstraktion, die sich der Validierungsknoten merken muss, und kann nur (sicher) für jeden Block berechnet werden, indem vom Genesis-Zustand ausgegangen wird und jede Transaktion in jedem Block sequentiell angewendet wird. Beachten Sie außerdem, dass die Reihenfolge, in der der Miner Transaktionen in den Block aufnimmt, wichtig ist; Wenn es zwei Transaktionen A und B in einem Block gibt, so dass B einen von A erstellten UTXO ausgibt, dann ist der Block gültig, wenn A vor B kommt, aber nicht anders.

Die einzige Gültigkeitsbedingung in der obigen Liste, die in anderen Systemen nicht zu finden ist, ist die Anforderung für einen „Arbeitsnachweis“. Die genaue Bedingung ist, dass der doppelte SHA256-Hash jedes Blocks, der als 256-Bit-Zahl behandelt wird, kleiner als ein dynamisch angepasstes Ziel sein muss, das zum Zeitpunkt des Schreibens dieses Artikels ungefähr 2187 beträgt Blockerstellung rechentechnisch "hart", wodurch Sybil-Angreifer daran gehindert werden, die gesamte Blockchain zu ihren Gunsten neu zu erstellen. Da SHA256 als völlig unvorhersehbare Pseudozufallsfunktion konzipiert ist, ist die einzige Möglichkeit, einen gültigen Block zu erstellen, einfach Trial-and-Error, das wiederholte Erhöhen der Nonce und das Prüfen, ob der neue Hash übereinstimmt.

Beim aktuellen Ziel von ~2187 muss das Netzwerk durchschnittlich ~269 Versuche machen, bevor ein gültiger Block gefunden wird; Im Allgemeinen wird das Ziel vom Netzwerk alle 2016 Blöcke neu kalibriert, sodass im Durchschnitt alle zehn Minuten ein neuer Block von einem Knoten im Netzwerk erzeugt wird. Um die Miner für diese Rechenarbeit zu entschädigen, ist der Miner jedes Blocks berechtigt, eine Transaktion einzubeziehen, die ihm aus dem Nichts 12,5 BTC einbringt. Wenn eine Transaktion einen höheren Gesamtnennwert in ihren Inputs als in ihren Outputs hat, geht die Differenz auch als „Transaktionsgebühr“ an den Miner. Dies ist übrigens auch der einzige Mechanismus, über den BTC ausgegeben werden; Der Genesis-Zustand enthielt überhaupt keine Münzen.

Um den Zweck des Minings besser zu verstehen, lassen Sie uns untersuchen, was im Falle eines böswilligen Angreifers passiert. Da bekannt ist, dass die zugrunde liegende Kryptographie der Crypto sicher ist, wird der Angreifer den einen Teil des Bitcoin-Systems angreifen, der nicht direkt durch Kryptographie geschützt ist: die Reihenfolge der Transaktionen. Die Strategie des Angreifers ist einfach:

Senden Sie 100 BTC an einen Händler im Austausch für ein Produkt (vorzugsweise ein digitales Gut mit schneller Lieferung)
Warten Sie auf die Lieferung des Produkts
Erstellen Sie eine weitere Transaktion, indem Sie die gleichen 100 BTC an sich selbst senden
Versuchen Sie, das Netzwerk davon zu überzeugen, dass seine Transaktion an sich selbst die erste war.
Sobald Schritt (1) stattgefunden hat, wird nach ein paar Minuten ein Miner die Transaktion in einen Block aufnehmen, sagen wir Block Nummer 270. Nach etwa einer Stunde werden der Kette nach diesem Block fünf weitere Blöcke hinzugefügt, mit jedem von diese Blöcke zeigen indirekt auf die Transaktion und "bestätigen" sie somit. An diesem Punkt akzeptiert der Händler die Zahlung als abgeschlossen und liefert das Produkt; Da wir davon ausgehen, dass es sich um ein digitales Gut handelt, erfolgt die Lieferung sofort. Jetzt erstellt der Angreifer eine weitere Transaktion, die die 100 BTC an sich selbst sendet. Wenn der Angreifer es einfach freigibt, wird die Transaktion nicht verarbeitet; Bergleute werden versuchen, APPLY(S,TX) auszuführen und feststellen, dass TX ein UTXO verbraucht, das sich nicht mehr im Zustand befindet. Stattdessen erstellt der Angreifer eine „Verzweigung“ der Blockchain, beginnend mit dem Schürfen einer anderen Version von Block 270, die auf denselben Block 269 als Elternteil zeigt, aber mit der neuen Transaktion anstelle der alten. Da die Blockdaten unterschiedlich sind, muss der Arbeitsnachweis erneut erstellt werden. Darüber hinaus hat die neue Version des Angreifers von Block 270 einen anderen Hash, sodass die ursprünglichen Blöcke 271 bis 275 nicht darauf „zeigen“; Daher sind die ursprüngliche Kette und die neue Kette des Angreifers vollständig getrennt. Die Regel ist, dass in einem Fork die längste Blockchain als Wahrheit angenommen wird, und so arbeiten legitime Miner an der 275-Kette, während der Angreifer allein an der 270-Kette arbeitet. Damit der Angreifer seine Blockchain am längsten machen kann, müsste er mehr Rechenleistung haben als der Rest des Netzwerks zusammen, um aufzuholen (daher „51 % Angriff“).

Merkle-Bäume
SPV in der Krypto

Links: Es reicht aus, nur eine kleine Anzahl von Knoten in einem Merkle-Baum darzustellen, um einen Beweis für die Gültigkeit eines Zweigs zu geben.

Richtig: Jeder Versuch, irgendeinen Teil des Merkle-Baums zu ändern, wird schließlich zu einer Inkonsistenz irgendwo in der Kette führen.

Ein wichtiges Skalierbarkeitsmerkmal von Crypto ist, dass der Block in einer mehrstufigen Datenstruktur gespeichert ist. Der „Hash“ eines Blocks ist eigentlich nur der Hash des Block-Headers, ein etwa 200-Byte-Datenstück, das den Zeitstempel, die Nonce, den vorherigen Block-Hash und den Root-Hash einer Datenstruktur namens Merkle-Baum enthält, in der alle Transaktionen gespeichert sind im Block. Ein Merkle-Baum ist eine Art binärer Baum, der aus einer Reihe von Knoten mit einer großen Anzahl von Blattknoten am unteren Ende des Baums besteht, die die zugrunde liegenden Daten enthalten, einer Reihe von Zwischenknoten, bei denen jeder Knoten der Hash seiner beiden Kinder ist. und schließlich ein einzelner Wurzelknoten, der ebenfalls aus dem Hash seiner beiden Kinder gebildet wird und die "Spitze" des Baums darstellt. Der Zweck des Merkle-Baums besteht darin, dass die Daten in einem Block stückweise geliefert werden können: Ein Knoten kann nur den Header eines Blocks von einer Quelle herunterladen, den kleinen Teil des Baums, der für ihn relevant ist, von einer anderen Quelle und ist dennoch sicher dass alle Daten korrekt sind. Der Grund, warum dies funktioniert, ist, dass sich Hashes nach oben ausbreiten: Wenn ein böswilliger Benutzer versucht, eine gefälschte Transaktion in das untere Ende eines Merkle-Baums einzufügen, führt diese Änderung zu einer Änderung des darüber liegenden Knotens und dann zu einer Änderung des darüber liegenden Knotens , wodurch schließlich die Wurzel des Baums und damit der Hash des Blocks geändert wird, was dazu führt, dass das Protokoll ihn als einen völlig anderen Block registriert (mit ziemlicher Sicherheit mit einem ungültigen Arbeitsnachweis).

Das Merkle-Tree-Protokoll ist wohl wesentlich für die langfristige Nachhaltigkeit. Ein "vollständiger Knoten" im Crypto-Netzwerk, der die Gesamtheit jedes Blocks speichert und verarbeitet, nimmt im April 2014 etwa 15 GB Speicherplatz im Bitcoin-Netzwerk ein und wächst monatlich um über ein Gigabyte. Derzeit ist dies für einige Desktop-Computer und nicht für Telefone möglich, und später in der Zukunft werden nur Unternehmen und Hobbyisten teilnehmen können. Ein Protokoll, das als „vereinfachte Zahlungsüberprüfung“ (SPV) bekannt ist, ermöglicht das Vorhandensein einer anderen Klasse von Knoten, die als „leichte Knoten“ bezeichnet werden und die Blockheader herunterladen, den Arbeitsnachweis für die Blockheader verifizieren und dann nur die „Zweige“ herunterladen " mit für sie relevanten Transaktionen verknüpft sind. Auf diese Weise können Light Nodes mit einer starken Sicherheitsgarantie den Status jeder Bitcoin-Transaktion und ihren aktuellen Kontostand bestimmen, während sie nur einen sehr kleinen Teil der gesamten Blockchain herunterladen.

Alternative Blockchain-Anwendungen
Auch die Idee, die zugrunde liegende Blockchain-Idee auf andere Konzepte zu übertragen, hat eine lange Geschichte. 1998 brachte Nick Szabo das Konzept sicherer Eigentumstitel mit Eigentümerautorität heraus, ein Dokument, das beschreibt, wie „neue Fortschritte in der replizierten Datenbanktechnologie“ ein Blockchain-basiertes System zum Speichern eines Registers ermöglichen werden, das festlegt, wem welches Land gehört, und ein ausgeklügelter Rahmen, einschließlich Konzepte wie Homesteading, nachteiliger Besitz und georgische Grundsteuer. Leider war damals kein effektives repliziertes Datenbanksystem verfügbar, und so wurde das Protokoll nie in die Praxis umgesetzt. Nach 2009 jedoch, sobald der dezentrale Konsens von Bitcoin entwickelt war, tauchten schnell eine Reihe alternativer Anwendungen auf.

Namecoin – Namecoin wurde 2010 gegründet und lässt sich am besten als dezentrale Namensregistrierungsdatenbank beschreiben. In dezentralisierten Protokollen wie Tor, Bitcoin und BitMessage muss es eine Möglichkeit geben, Konten zu identifizieren, damit andere Personen mit ihnen interagieren können, aber in allen bestehenden Lösungen ist die einzige verfügbare Art von Kennung ein pseudozufälliger Hash wie 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Idealerweise möchte man ein Konto mit einem Namen wie "george" haben können. Das Problem ist jedoch, dass, wenn eine Person ein Konto mit dem Namen „george“ erstellen kann, eine andere Person den gleichen Prozess verwenden kann, um „george“ auch für sich selbst zu registrieren und sich als sie auszugeben. Die einzige Lösung ist ein First-to-File-Paradigma, bei dem der erste Registrierer erfolgreich ist und der zweite fehlschlägt – ein Problem, das perfekt für das Bitcoin-Konsensprotokoll geeignet ist. Namecoin ist die älteste und erfolgreichste Implementierung eines Namensregistrierungssystems, das eine solche Idee verwendet.
Farbige Münzen – der Zweck von farbigen Münzen ist es, als Protokoll zu dienen, um es Menschen zu ermöglichen, ihre eigenen digitalen Währungen zu erstellen – oder, im wichtigen trivialen Fall einer Währung mit einer Einheit, digitalen Tokens auf der Bitcoin-Blockchain. Im Protokoll für farbige Münzen „gibt“ man eine neue Währung aus, indem man einem bestimmten Bitcoin UTXO öffentlich eine Farbe zuweist, und das Protokoll definiert rekursiv die Farbe anderer UTXO als die gleiche wie die Farbe der Eingaben, die die Transaktion, die sie erstellt, ausgegeben hat (bei gemischtfarbigen Eingängen gelten einige Sonderregeln). Auf diese Weise können Benutzer Brieftaschen verwalten, die nur UTXO einer bestimmten Farbe enthalten, und sie ähnlich wie normale Bitcoins herumschicken, indem sie die Blockchain zurückverfolgen, um die Farbe jedes UTXO zu bestimmen, das sie erhalten.
Metacoins – Die Idee hinter einem Metacoin ist ein Protokoll, das auf Bitcoin basiert und Bitcoin-Transaktionen verwendet, um Metacoin-Transaktionen zu speichern, aber eine andere Zustandsübergangsfunktion hat, APPLY'. Da das Metacoin-Protokoll nicht verhindern kann, dass ungültige Metacoin-Transaktionen in der Bitcoin-Blockchain erscheinen, wird eine Regel hinzugefügt, dass, wenn APPLY'(S,TX) einen Fehler zurückgibt, das Protokoll standardmäßig auf APPLY'(S,TX) = S gesetzt wird. Dies bietet eine einfacher Mechanismus zum Erstellen eines beliebigen Kryptowährungsprotokolls, möglicherweise mit erweiterten Funktionen, die nicht in Bitcoin selbst implementiert werden können, aber mit sehr geringen Entwicklungskosten, da die Komplexität von Mining und Netzwerk bereits vom Bitcoin-Protokoll gehandhabt wird. Metacoins wurden verwendet, um einige Klassen von Finanzkontrakten, Namensregistrierung und dezentralisiertem Austausch zu implementieren.
Daher gibt es im Allgemeinen zwei Ansätze zum Aufbau eines Konsensprotokolls: Aufbau eines unabhängigen Netzwerks und Aufbau eines Protokolls auf Bitcoin. Der erstgenannte Ansatz ist zwar im Fall von Anwendungen wie Namecoin recht erfolgreich, aber schwierig zu implementieren; Jede einzelne Implementierung muss eine unabhängige Blockchain booten und den gesamten erforderlichen Zustandsübergangs- und Netzwerkcode erstellen und testen. Darüber hinaus sagen wir voraus, dass die Menge der Anwendungen für die dezentralisierte Konsenstechnologie einer Machtgesetzverteilung folgen wird, bei der die überwiegende Mehrheit der Anwendungen zu klein wäre, um eine eigene Blockchain zu rechtfertigen, und wir stellen fest, dass es große Klassen dezentralisierter Anwendungen gibt, insbesondere dezentralisierte autonome Organisationen, die miteinander interagieren müssen.

Der Bitcoin-basierte Ansatz hingegen hat den Fehler, dass er nicht die vereinfachten Zahlungsverifizierungsfunktionen von Bitcoin erbt. SPV funktioniert für Bitcoin, weil es die Blockchain-Tiefe als Proxy für die Gültigkeit verwenden kann; Irgendwann, wenn die Vorfahren einer Transaktion weit genug zurückreichen, kann man mit Sicherheit sagen, dass sie rechtmäßig Teil des Staates waren. Blockchain-basierte Metaprotokolle hingegen können die Blockchain nicht dazu zwingen, Transaktionen nicht einzubeziehen, die im Kontext ihrer eigenen Protokolle nicht gültig sind. Daher müsste eine vollständig sichere SPV-Metaprotokollimplementierung bis zum Anfang der Bitcoin-Blockchain rückwärts scannen, um festzustellen, ob bestimmte Transaktionen gültig sind oder nicht. Derzeit verlassen sich alle „leichten“ Implementierungen von Bitcoin-basierten Metaprotokollen auf einen vertrauenswürdigen Server, um die Daten bereitzustellen, was wohl ein höchst suboptimales Ergebnis ist, insbesondere wenn einer der Hauptzwecke einer Kryptowährung darin besteht, die Notwendigkeit von Vertrauen zu beseitigen.