Zephyrnet-Logo

Technische Sicherheit durch Koordinationsprobleme

Datum:

Kürzlich kam es zu einem kleinen Streit zwischen der Core- und der Unlimited-Fraktion der Bitcoin-Gemeinschaft, ein Streit, der vielleicht das fünfzigste Mal darstellt, dass dasselbe Thema diskutiert wurde, der aber dennoch interessant ist, weil er einen sehr subtilen philosophischen Punkt über die Funktionsweise von Blockchains hervorhebt arbeiten.

ViaBTC, ein Mining-Pool, der Unlimited bevorzugt, twitterte „Hashpower ist Gesetz“, ein üblicher Diskussionspunkt für die Unlimited-Seite, die glaubt, dass Miner eine sehr große Rolle bei der Governance von Bitcoin spielen und spielen sollten. Das übliche Argument dafür ist, dass Miner die einzige Benutzerkategorie sind, die dies tut hat einen großen und illiquiden finanziellen Anreiz für den Erfolg von Bitcoin. Greg Maxwell (von der Core-Seite) antwortete dass „die Sicherheit von Bitcoin genau deshalb funktioniert, weil Hash-Power KEIN Gesetz ist“.

Das Kernargument besteht darin, dass Miner nur eine begrenzte Rolle im Bitcoin-System spielen, um die Reihenfolge von Transaktionen sicherzustellen, und dass sie NICHT die Macht haben sollten, irgendetwas anderes zu bestimmen, einschließlich Blockgrößenbeschränkungen und anderer Blockgültigkeitsregeln. Diese Einschränkungen werden durch von Benutzern betriebene vollständige Knoten durchgesetzt. Wenn Miner beginnen, Blöcke nach einem Satz von Regeln zu produzieren, die sich von den Regeln unterscheiden, die die Knoten der Benutzer durchsetzen, lehnen die Knoten der Benutzer die Blöcke einfach ab, unabhängig davon, ob 10 % oder 60 % oder 99 % der Hashpower stecken dahinter. Darauf antwortet Unlimited oft mit etwas wie „Wenn 90 % der Hashpower hinter einer neuen Kette stecken, die das Blocklimit erhöht, und die alte Kette mit 10 % Hashpower jetzt fünf Monate lang zehnmal langsamer ist, bis sich der Schwierigkeitsgrad wieder anpasst, würden Sie das tun?“ wirklich Aktualisieren Sie Ihren Client nicht, um die neue Kette zu akzeptieren?“


Viele Leute oft argumentieren gegen die Verwendung öffentlicher Blockchains für Anwendungen, die reale Vermögenswerte oder alles mit Kontrahentenrisiko beinhalten. Die Kritik ist entweder vollständig und besagt, dass es keinen Sinn macht, solche Anwendungsfälle auf öffentlichen Blockchains zu implementieren, oder teilweise und besagt, dass die Speicherung zwar Vorteile haben könnte technische Daten auf einer öffentlichen Kette, die Geschäftslogik sollte außerhalb der Kette ausgeführt werden.

Das üblicherweise verwendete Argument ist, dass in solchen Anwendungen bereits Vertrauenspunkte bestehen – es gibt jemanden, der die physischen Vermögenswerte besitzt, die die genehmigten Vermögenswerte in der Kette stützen, und dass sich immer jemand dafür entscheiden kann, mit den Vermögenswerten davonzulaufen oder gezwungen zu werden, sie einzufrieren Sie werden von einer Regierung oder einer Bank verwaltet, und so ist die Verwaltung der digitalen Darstellungen dieser Vermögenswerte auf einer Blockchain so, als würde man für sein Haus bei geöffnetem Fenster eine verstärkte Stahltür bezahlen. Stattdessen sollten solche Systeme private Ketten oder sogar traditionelle serverbasierte Lösungen verwenden und möglicherweise Teile der Kryptografie hinzufügen, um die Überprüfbarkeit zu verbessern, und so die Ineffizienzen und Kosten einsparen, die entstehen, wenn alles auf einer Blockchain gespeichert wird.


Die oben genannten Argumente sind beide in ihrer reinen Form fehlerhaft, und sie sind in ähnlicher Weise fehlerhaft. Während es so ist theoretisch möglich für Miner, die 99 % ihrer Hashpower auf eine Kette mit neuen Regeln verlagern (um ein Beispiel zu geben, wo das unumstritten schlecht ist, nehmen wir an, dass sie die Blockbelohnung erhöhen), und sogar Spawn-Camp Die alte Kette dauerhaft unbrauchbar zu machen, und es ist theoretisch auch möglich, dass ein zentraler Manager einer Asset-Backed-Währung einen digitalen Token nicht mehr anerkennt und einen neuen digitalen Token mit den gleichen Guthaben wie der alte Token erstellt, mit Ausnahme eines bestimmten Kontos Der Kontostand wird auf Null reduziert, und in der Praxis wird mit der Einlösung des neuen Tokens begonnen Beides ist ziemlich schwierig.

Im ersten Fall müssen Benutzer erkennen, dass mit der bestehenden Kette etwas nicht stimmt, sich damit einverstanden erklären, dass sie zu der neuen Kette wechseln sollen, auf der die Miner jetzt schürfen, und die Software herunterladen, die die neuen Regeln akzeptiert. Im zweiten Fall werden alle Clients und Anwendungen, die vom ursprünglichen digitalen Token abhängig sind, unterbrochen, Benutzer müssen ihre Clients aktualisieren, um auf den neuen digitalen Token umzusteigen, und Smart Contracts können nicht nach außen schauen und erkennen, dass sie dies tun Wenn ein Update erforderlich ist, wird es vollständig kaputt gehen. Inmitten all dessen können Gegner des Wechsels eine Angst-Ungewissheit-und-Zweifel-Kampagne ins Leben rufen, um die Leute davon zu überzeugen, dass sie ihre Kunden vielleicht doch nicht oder gar nicht aktualisieren sollten dritte Regelwerk (z. B. Änderung des Arbeitsnachweises), was die Umsetzung der Umstellung noch schwieriger macht.

Daher können wir sagen, dass in beiden Fällen, obwohl es theoretisch zentralisierte oder quasi-zentralisierte Parteien gibt, die einen Übergang von Zustand A zu Zustand B erzwingen könnten, wobei Zustand B für Benutzer unangenehm, den zentralisierten Parteien jedoch vorzuziehen ist, dies erforderlich ist Durchbrechen eines schwierigen Koordinationsproblems. Koordinationsprobleme gibt es überall in der Gesellschaft und sind oft eine schlechte Sache – während es für die meisten Menschen besser wäre, wenn die englische Sprache ihr hochkomplexes und unregelmäßiges Rechtschreibsystem abschaffen und ein phonetisches einführen würde, oder wenn die Vereinigten Staaten auf metrische Systeme umsteigen würden, oder wenn wir es sofort könnten im Falle einer Rezession alle Preise und Löhne um zehn Prozent senkenIn der Praxis erfordert dies jedoch, dass sich alle gleichzeitig auf den Wechsel einigen, und das ist oft sehr, sehr schwierig.

Bei Blockchain-Anwendungen machen wir jedoch etwas anderes: Wir nutzen Koordinationsprobleme zu unserem VorteilDabei wird die Reibung, die durch Koordinationsprobleme entsteht, als Bollwerk gegen Fehlverhalten zentralisierter Akteure genutzt. Wir können Systeme erstellen, die über die Eigenschaft X verfügen, und wir können garantieren, dass sie die Eigenschaft . Selbst wenn es einen Akteur gäbe, der die Änderung erzwingen könnte, wäre dies schwierig. Dies ist die Art von Sicherheit, die Sie durch die clientseitige Validierung der Blockchain-Konsensregeln erhalten.

Beachten Sie, dass diese Art der Sicherheit insbesondere auf der Dezentralisierung der Benutzer beruht. Selbst wenn es nur einen Miner auf der Welt gibt, gibt es dennoch einen Unterschied zwischen einer von diesem Miner geschürften Kryptowährung und einem PayPal-ähnlichen zentralisierten System. Im letzteren Fall kann der Betreiber die Regeln willkürlich ändern, das Geld der Leute einfrieren, einen schlechten Service anbieten, seine Gebühren erhöhen oder eine ganze Reihe anderer Dinge tun, und die Koordinierungsprobleme kommen dem Betreiber zugute, wie es bei solchen Systemen der Fall ist Es kommt zu erheblichen Netzwerkeffekten und so müssten sehr viele Nutzer gleichzeitig zustimmen, auf ein besseres System umzusteigen. Im ersteren Fall bedeutet die clientseitige Validierung, dass viele Unfugversuche, die der Miner möglicherweise unternehmen möchte, standardmäßig abgelehnt werden und das Koordinationsproblem nun zu Gunsten der Benutzer wirkt.

Beachten Sie, dass die obigen Argumente NICHT funktionieren. selbst, implizieren, dass es eine schlechte Idee ist, dass Bergleute die Hauptakteure sind, die die Blockgröße (oder im Fall von Ethereum das Gaslimit) koordinieren und entscheiden. Es kann durchaus sein, dass im konkreten Fall der Blockgröße/Gasbegrenzung„Regierung durch koordinierte Bergleute mit abgestimmten Anreizen“ ist der optimale Ansatz für die Festlegung dieses einen bestimmten politischen Parameters, vielleicht weil das Risiko, dass Bergleute ihre Macht missbrauchen, geringer ist als das Risiko, dass sich eine bestimmte gewählte harte Grenze als völlig ungeeignet für die Marktbedingungen erweist Jahrzehnt nach Festlegung des Grenzwerts. Es ist jedoch nichts Unvernünftiges daran, zu sagen, dass die Regierung durch Bergleute der beste Weg sei, über einen politischen Parameter zu entscheiden, und das gleichzeitig zu sagen für andere Parameter (z. B. Blockbelohnung) Wir möchten uns auf die clientseitige Validierung verlassen, um sicherzustellen, dass die Miner eingeschränkt werden. Das ist die Essenz des Engineerings dezentraler Institutionen: Es geht darum, Koordinationsprobleme strategisch zu nutzen, um sicherzustellen, dass Systeme weiterhin bestimmte gewünschte Eigenschaften erfüllen.

Die obigen Argumente implizieren auch nicht, dass es immer optimal ist, zu versuchen, alles auf einer Blockchain zu platzieren, selbst für Dienste, die Vertrauen erfordern. Im Allgemeinen lassen sich durch die Ausführung von mehr Geschäftslogik auf einer Blockchain zumindest einige Gewinne erzielen, diese sind jedoch oft viel geringer als die Verluste bei Effizienz oder Datenschutz. Und das ist ok; Die Blockchain ist nicht für jede Aufgabe das beste Werkzeug. Was sind die Argumente oben? do Dies bedeutet jedoch, dass Sie, wenn Sie eine Blockchain-basierte Anwendung erstellen, die viele zentralisierte Komponenten aus der Notwendigkeit heraus enthält, erhebliche weitere Fortschritte bei der Vertrauensminimierung erzielen können, indem Sie Benutzern die Möglichkeit geben, über einen regulären Blockchain-Client auf Ihre Anwendung zuzugreifen ( (z. B. im Fall von Ethereum kann dies Mist, Parity, Metamask oder Status sein), anstatt sie dazu zu bringen, eine Weboberfläche zu verwenden, die Sie persönlich steuern.

Theoretisch werden die Vorteile der benutzerseitigen Validierung optimiert, wenn buchstäblich jeder Benutzer einen unabhängigen „idealen vollständigen Knoten“ betreibt – einen Knoten, der alle Blöcke akzeptiert, die den Protokollregeln folgen, denen alle bei der Erstellung des Systems zugestimmt haben, und alle Blöcke ablehnt, die dies tun nicht. In der Praxis bedeutet dies jedoch, dass jeder Benutzer jede von jedem im Netzwerk durchgeführte Transaktion verarbeiten muss, was eindeutig unhaltbar ist, insbesondere angesichts der schnellen Zunahme von Smartphone-Benutzern in Entwicklungsländern.

Hier gibt es zwei Auswege. Das erste ist, dass wir das erkennen können, während es ist optimal Unter dem Gesichtspunkt der oben genannten Argumente, dass jeder einen vollständigen Knoten betreibt, ist dies sicherlich nicht der Fall falls angefordert. Vermutlich wird jede große Blockchain, die mit voller Kapazität läuft, bereits den Punkt erreicht haben, an dem es für „die einfachen Leute“ keinen Sinn mehr macht, ein Fünftel ihres Festplattenspeichers für den Betrieb eines vollständigen Knotens aufzuwenden, und so sind die verbleibenden Benutzer Hobbyisten und Unternehmen. Solange es eine relativ große Anzahl von ihnen gibt und sie unterschiedliche Hintergründe haben, wird das Koordinationsproblem, diese Benutzer zur Zusammenarbeit zu bewegen, immer noch sehr schwierig sein.

Zweitens können wir uns darauf verlassen Strong-Light-Client-Technologie.

Grundsätzlich sind in Blockchain-Systemen zwei Ebenen von „Light Clients“ möglich. Die erste, schwächere Art von Light-Client überzeugt den Benutzer einfach mit einem gewissen Maß an wirtschaftlicher Sicherheit davon, dass er sich in der Kette befindet, die vom Großteil des Netzwerks unterstützt wird. Dies kann viel kostengünstiger durchgeführt werden als die Verifizierung der gesamten Kette, da die Kunden lediglich in Proof-of-Work-Programmen Nonces oder in Proof-Stake-Programmen signierte Zertifikate verifizieren müssen, in denen steht: „Entweder ist der Root-Hash des Staates das, was ich sage.“ ist, oder Sie können dieses Zertifikat in der Hauptkette veröffentlichen, um einen großen Betrag meines Geldes zu löschen.“ Sobald der Light-Client einen Root-Hash verifiziert hat, kann er Merkle-Bäume verwenden, um alle spezifischen Daten zu verifizieren, die er verifizieren möchte.

Schauen Sie, es ist ein Merkle-Baum!

Die zweite Ebene ist ein „nahezu vollständig verifizierender“ Light Client. Diese Art von Kunde versucht nicht einfach, der Kette zu folgen, der die Mehrheit folgt; Vielmehr wird auch versucht, nur Ketten zu befolgen, die alle Regeln befolgen. Dies geschieht durch eine Kombination von Strategien; Am einfachsten lässt es sich erklären, dass ein Light-Client mit spezialisierten Knoten zusammenarbeiten kann (Gavin Wood hat sich den Namen „Fischer“ ausgedacht), deren Zweck es ist, nach ungültigen Blöcken zu suchen und „Betrugsbeweise“, also Kurznachrichten, zu generieren Sagen Sie im Wesentlichen: „Schau! Dieser Block hat hier einen Fehler!“ Light-Clients können dann diesen bestimmten Teil eines Blocks überprüfen und prüfen, ob er tatsächlich ungültig ist.

Wenn festgestellt wird, dass ein Block ungültig ist, wird er verworfen; Wenn ein Light-Client einige Minuten lang keine Betrugsbeweise für einen bestimmten Block hört, geht er davon aus, dass der Block wahrscheinlich legitim ist. Da ist ein etwas komplexer an der Bearbeitung des Falles beteiligt, bei dem das Problem nicht in den Daten liegt Badewanne , sondern vielmehr Daten Kommt demnächst..., aber im Allgemeinen ist es möglich, alle möglichen Wege zu erkennen, auf denen Miner oder Validatoren gegen die Regeln des Protokolls verstoßen können.

Beachten Sie, dass diese Regeln im Konsens ausgeführt werden müssen, damit ein Light-Client einen Satz Anwendungsregeln effizient validieren kann – das heißt, sie müssen entweder Teil des Protokolls oder Teil eines Mechanismus sein, der innerhalb des Protokolls ausgeführt wird ( wie ein Smart Contract). Dies ist ein Hauptargument dafür, die Blockchain nicht nur zur Datenspeicherung, sondern sowohl zur Datenspeicherung als auch zur Ausführung der Geschäftslogik zu verwenden.

Diese Light-Client-Techniken sind insofern unvollkommen, als sie auf Annahmen über die Netzwerkkonnektivität und die Anzahl anderer Light-Clients und Fischer im Netzwerk beruhen. Aber es ist eigentlich nicht entscheidend, dass sie 100 % der Zeit für 100 % der Validatoren funktionieren. Vielmehr wollen wir lediglich eine Situation schaffen, in der jeder Versuch eines feindlichen Kartells von Minern/Validatoren, ungültige Blöcke ohne Zustimmung des Benutzers zu pushen, vielen Menschen große Kopfschmerzen bereiten wird und letztendlich dazu führt, dass jeder seine Software aktualisieren muss, wenn dies der Fall ist Ich möchte weiterhin mit der ungültigen Kette synchronisieren. Solange dies erfüllt ist, haben wir das Ziel der Sicherheit durch Koordinationsfriktionen erreicht.

Quelle: https://vitalik.eth.limo/general/2017/05/08/coordination_problems.html

spot_img

Neueste Intelligenz

spot_img