Ja, weil ein allgemeines Proof-of-Stake-System mit Ihrer einzigen angegebenen Anforderung darin besteht, Unterschriften von mindestens 2/3 der Validatoren zu sammeln, gewichtet nach Einzahlung (meine Bearbeitung, sonst könnten Sie 4.000 von 6.000 Validatoren mit einer Mindestsicherheitskaution haben, das heißt schlecht konzipiert, zu klein sein, mehr als 2/3 der gewichteten Einzahlung haben und fehlerhaft handeln, mit einer höheren erwarteten Rendite als dem erwarteten Verlust bei Verlust der Mindesteinzahlung, und somit der Blockchain schaden) garantiert keine Datenverfügbarkeit, weil mehr als ein Drittel der Validatoren sind nicht garantiert fehlerfrei, und ein generisches Proof-of-Stake-Konsensprotokoll garantiert keine byzantinische Fehlertoleranz. Um es anders auszudrücken, es ist nicht sicher in einem Modell der Bestechung von Angreifern oder der koordinierten Mehrheit, bei dem mehr als 67 % der Prüfer geheime Absprachen treffen.

Neben der Verwendung von Löschcodes können Notare versuchen, Sammlungen oder Blöcke herunterzuladen (um die Verfügbarkeit zu prüfen) und möglicherweise auch zu überprüfen (um die Gültigkeit zu prüfen, wenn sie auch als Testamentsvollstrecker fungieren). Wenn ein Notar eine Kollation nicht herunterladen kann, kann er mit 0 dafür stimmen (0 bedeutet Ablehnung, 1 Zustimmung). Diese Notare können über eine öffentlich überprüfbare Zufallsquelle wie RANDAO- oder BLS-Aggregatsignaturen zufällig gemischt werden. Ein Komitee aus einer beliebigen Untergruppe von Notaren kann dann auch eine BLS-Gesamtsignatur auf diesen Stimmen vornehmen. Bei sehr großen Transaktionen, die das Gaslimit überschreiten, kann die Transaktion außerhalb der Kette gespeichert und verifiziert werden, z. B. mit IPFS, Truebit usw.

Siehe auch Ausschnitte von STRG+F „availab“ von https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs und https://github.com/ethereum/wiki/wiki/Sharding-FAQs .

• CAP-Theorem - "In den Fällen, in denen eine Netzwerkpartitionierung stattfindet, müssen Sie entweder Konsistenz oder Verfügbarkeit wählen, Sie können nicht beides haben". Das intuitive Argument ist einfach: Wenn sich das Netzwerk in zwei Hälften aufteilt und ich in der einen Hälfte eine Transaktion „Sende meine 10 Münzen an A“ und in der anderen eine Transaktion „Sende meine 10 Münzen an B“ sende, dann entweder das System nicht verfügbar ist, da eine oder beide Transaktionen nicht verarbeitet werden, oder es wird inkonsistent, da eine Hälfte des Netzwerks die erste Transaktion abgeschlossen sieht und die andere Hälfte die zweite Transaktion abgeschlossen sieht. Beachten Sie, dass das CAP-Theorem nichts mit Skalierbarkeit zu tun hat; es gilt gleichermaßen für Sharding- und Nicht-Sharding-Systeme. Siehe auchhttps://github.com/ethereum/wiki/wiki/Sharding-FAQs#but-doesnt-the-cap-theorem-mean-that-fully-secure-distributed-systems-are-unposible-and-so-sharding- ist vergeblich . — https://github.com/ethereum/wiki/wiki/Sharding-FAQs#but-doesnt-the-cap-theorem-mean-that-fully-secure-distributed-systems-are-unposible-and-so-sharding -ist-sinnlos

Kann man die Zensur als Nachweis des Einsatzes wirtschaftlich bestrafen?

Im Gegensatz zu Reverts ist Zensur viel schwieriger zu beweisen. Die Blockchain selbst kann nicht direkt den Unterschied zwischen „Benutzer A hat versucht, Transaktion X zu senden, aber es wurde zu Unrecht zensiert“, „Benutzer A hat versucht, Transaktion X zu senden, aber es kam nie an, weil die Transaktionsgebühr nicht ausreichte“ und „Benutzer A hat es nie versucht Transaktion X überhaupt zu senden". Siehe auch Hinweis zu Datenverfügbarkeit und Löschcodes . Es gibt jedoch eine Reihe von Techniken, die verwendet werden können, um Zensurprobleme zu mildern.

Der erste ist der Zensurwiderstand durch das Anhalten des Problems. In der schwächeren Version dieses Schemas ist das Protokoll so konzipiert, dass es Turing-vollständig ist, so dass ein Validator nicht einmal sagen kann, ob eine bestimmte Transaktion zu einer unerwünschten Aktion führt oder nicht, ohne eine große Menge an Rechenleistung für die Ausführung der Transaktion aufzuwenden , und öffnet sich damit für Denial-of-Service-Angriffe. Das hat die DAO Soft Fork verhindert .

In der stärkeren Version des Schemas können Transaktionen zu einem bestimmten Zeitpunkt in der nahen bis mittelfristigen Zukunft garantierte Wirkungen auslösen. Daher könnte ein Benutzer mehrere Transaktionen senden, die miteinander und mit vorhergesagten Informationen von Drittanbietern interagieren, um zu einem zukünftigen Ereignis zu führen, aber die Validatoren können unmöglich sagen, dass dies passieren wird, bis die Transaktionen bereits enthalten (und wirtschaftlich abgeschlossen) sind. und es ist viel zu spät, sie aufzuhalten; selbst wenn alle zukünftigen Transaktionen ausgeschlossen sind, würde das Ereignis, das die Prüfer anhalten möchten, immer noch stattfinden. Beachten Sie, dass Prüfer in diesem Schema immer noch versuchen könnten, alles zu verhindernTransaktionen, oder vielleicht alle Transaktionen, die nicht mit einem formellen Beweis verpackt sind, dass sie zu nichts Unerwünschtem führen, aber dies würde bedeuten, eine sehr breite Klasse von Transaktionen zu verbieten, bis zu dem Punkt, an dem im Wesentlichen das gesamte System gebrochen wird, was die Prüfer dazu veranlassen würde an Wert verlieren, da der Preis der Kryptowährung, auf die ihre Einlagen lauten, fallen würde.

Die zweite, von Adam Back hier beschriebene , besteht darin, dass Transaktionen Timelock-verschlüsselt werden müssen . Daher werden Validatoren die Transaktionen einbeziehen, ohne den Inhalt zu kennen, und erst später könnten die Inhalte automatisch aufgedeckt werden, und zu diesem Zeitpunkt wäre es wiederum viel zu spät, die Transaktionen aufzuheben. Wenn die Validatoren jedoch ausreichend bösartig wären, könnten sie einfach nur zustimmen, Transaktionen einzubeziehen, die mit einem kryptografischen Beweis (z. B. ZK-SNARK) der entschlüsselten Version versehen sind; Dies würde Benutzer zwingen, neue Client-Software herunterzuladen, aber ein Gegner könnte solche Client-Software bequem zum einfachen Herunterladen bereitstellen, und in einem spieltheoretischen Modell hätten Benutzer den Anreiz, mitzuspielen.

Das Beste, was man in einem Proof-of-Stake-Kontext vielleicht sagen kann, ist, dass Benutzer auch ein Software-Update installieren könnten, das einen Hard Fork enthält, der die böswilligen Validatoren löscht, und das ist nicht viel schwieriger als die Installation eines Software-Updates, um ihre Transaktionen durchzuführen "zensurfreundlich". Alles in allem ist dieses Schema also auch mäßig effektiv, obwohl es auf Kosten der Verlangsamung der Interaktion mit der Blockchain geht (beachten Sie, dass das Schema obligatorisch sein muss, um effektiv zu sein; andernfalls könnten böswillige Prüfer verschlüsselte Transaktionen viel einfacher filtern ohne Filtern der schnelleren unverschlüsselten Transaktionen).

Eine dritte Alternative besteht darin, die Zensurerkennung in die Fork-Choice-Regel aufzunehmen. Die Idee ist einfach. Nodes beobachten das Netzwerk auf Transaktionen, und wenn sie eine Transaktion mit einer ausreichend hohen Gebühr für einen ausreichenden Zeitraum sehen, weisen sie Blockchains, die diese Transaktion nicht beinhalten, eine niedrigere „Punktzahl“ zu. Wenn alle Knoten dieser Strategie folgen, würde sich schließlich automatisch eine Minderheitskette zusammenschließen, die die Transaktionen umfasst, und alle ehrlichen Online-Knoten würden ihr folgen. Die Hauptschwäche eines solchen Schemas besteht darin, dass Offline-Knoten immer noch dem Mehrheitszweig folgen würden, und wenn die Zensur vorübergehend ist und sie sich nach Ende der Zensur wieder anmelden, dann würden sie auf einem anderen Zweig landen als Online-Knoten. Somit, Dieses Schema sollte eher als Werkzeug zur Erleichterung der automatisierten Notfallkoordination bei einem Hard Fork angesehen werden, als als etwas, das eine aktive Rolle bei der täglichen Fork-Auswahl spielen würde. Proof-of-Work-Algorithmen und Chain-basierte Proof-of-Stake-Algorithmen entscheiden sich für Verfügbarkeit statt Konsistenz, aber Konsensalgorithmen im BFT-Stil tendieren eher zur Konsistenz;Tendermint entscheidet sich ausdrücklich für Konsistenz, und Casper verwendet ein Hybridmodell, das Verfügbarkeit bevorzugt, aber so viel Konsistenz wie möglich bietet und sowohl On-Chain-Anwendungen als auch Clients bewusst macht, wie stark die Konsistenzgarantie zu einem bestimmten Zeitpunkt ist.

Siehe auch https://github.com/ethereum/wiki/wiki/Sharding-FAQs#what-might-a-basic-design-of-a-sharded-blockchain-look-like .

Wie könnte ein grundlegendes Design einer Sharded Blockchain aussehen?

Ein einfacher Ansatz ist wie folgt. Der Einfachheit halber verfolgt dieses Design nur Datenblobs; es versucht nicht, eine Zustandsübergangsfunktion zu verarbeiten.

Es gibt Nodes namens Proposer , die Blobs auf Shard akzeptieren k(je nach Protokoll wählen Proposer entweder welche aus koder ihnen werden zufällig welche zugewiesen k) und Kollationen erstellen , daher fungieren sie auch als Collator, und Agenten, die sowohl als Proposer als auch als Collator fungieren, können dies tun als Prolatoren bezeichnet werden. Eine Sortierung hat einen Sortierungs-Header , eine kurze Nachricht der Form „Dies ist eine Sortierung von Blobs auf Shard k, die übergeordnete Sortierung ist 0x7f1e74 und der Merkle-Stamm der Blobs ist 0x3f98ea“. Zusammenstellungen jedes Shards bilden eine Kette, genau wie Blöcke in einer traditionellen Blockchain.

Es gibt auch Notare, die Zusammenstellungen in einem Shard herunterladen und verifizieren, dass sie zufällig zugewiesen werden und wo sie in jedem Zeitraum über eine zufällige Beacon-Kette (unter Verwendung einer verifizierbaren Zufallsfunktion wie einem Blockhash, der von einer BLS-Aggregatsignatur erzeugt wird, in einen neuen Shard gemischt werden RANDAO, obwohl letzteres auf Manipulationsanfälligkeit getestet wurde) und über die Verfügbarkeit der Daten in einer Kollation abstimmen (unter der Annahme, dass keine EVM vorhanden ist, können sie bei einer EVM auch als Vollstrecker fungieren und über die Gültigkeit von Daten abstimmen).

Ein Komitee kann dann auch diese Voten von Notaren prüfen und entscheiden, ob ein Collation-Header in die Hauptkette aufgenommen wird und somit eine Querverbindung zur Collation im Shard hergestellt wird. Andere Parteien können das Komitee, Notare, Proposer, Validatoren (mit Casper Proof of Stake) usw. herausfordern, zB mit einem interaktiven Verifizierungsspiel oder durch die Verifizierung eines Gültigkeitsnachweises.

Eine „Hauptkette“, die von allen verarbeitet wird, existiert immer noch, aber die Rolle dieser Hauptkette beschränkt sich auf das Speichern von Sortierungskopfzeilen für alle Shards. Die „kanonische Kette“ von Shard kist die längste Kette gültiger Sortierungen auf Shard, kderen Header sich alle innerhalb der kanonischen Hauptkette befinden.

Beachten Sie, dass es jetzt mehrere "Ebenen" von Knoten gibt, die in einem solchen System existieren können:

• Super-Full-Knoten – lädt jede Sortierung jedes Shards sowie die Hauptkette vollständig herunter und verifiziert alles vollständig.
• Top-Level-Knoten – verarbeitet alle Hauptkettenblöcke und gibt ihnen „Light Client“-Zugriff auf alle Shards.
• Einzel-Shard-Knoten – fungiert als Knoten der obersten Ebene, lädt aber auch jede Sortierung auf einem bestimmten Shard, der ihm wichtiger ist, vollständig herunter und überprüft sie.
• Light node - lädt nur die Blockheader der Hauptkettenblöcke herunter und verifiziert sie; verarbeitet keine Kollations-Header oder Transaktionen, es sei denn, es muss ein bestimmter Eintrag im Zustand eines bestimmten Shards gelesen werden. In diesem Fall lädt es den Merkle-Zweig zum neuesten Kollations-Header für dieses Shard herunter und lädt von dort den Merkle-Beweis herunter Wunschwert im Zustand.

Die kurze Antwort lautet: Ja , diese Probleme bestehen fort, aber in einem kleinen, aber erträglichen Ausmaß.

Die Lösung hierfür wäre ein perfekt byzantinisches fehlertolerantes System ( BFT ).