Geschichte
Ich hatte den ersten Samen dieser Idee, als ich im Frühjahr 2014 mit Janislav Malahov in Berlin unterhielt. Leider ging der ursprüngliche Artikel, den ich schrieb, zusammen mit meinem Laptop verloren, als er in Wien gestohlen wurde. Nachdem wir uns in jüngerer Zeit über die Prinzipien mit Vitalik unterhalten hatten, haben wir eine Reihe von Änderungen und Formalisierungen vorgenommen, hauptsächlich auf die Validierung und die Sub-State-Schneidmechanismen. Was folgt, ist eine ziemlich vollständige Darstellung eines bestimmten möglichen Plans für die Skalierbarkeit von Blockketten in einer späteren Version von Ethereum.
Da dies keineswegs ein endgültiger Vorschlag ist, gibt es a Github Wiki Seite Das wird die Fortschritte bei dieser speziellen Idee verfolgen.
Überblick
Die Grundidee von Kettenfasern ist gegenüber vor einem Jahr unverändert. Teilen Sie den Zustandsraum in Schichten auf und haben Sie separate Transaktionskollatoren, die sich auf eine oder eine Reihe von Zustandsunterräumen spezialisiert haben. Transaktionen, die Interaktionen aus vielen Untervorstellungen erfordern, wären dementsprechend teurer (da die Collatoren auf mehreren Ketten die Präsenz aufrechterhalten müssten) und länger für die Ausführung dauern (da eine geringere Chance besteht, dass ein bestimmter Block einen Superset der Unterschiede der Transaktion enthält). Die Gültigkeit einer Transaktion ist durch die Bereitstellung umfassender Merkle -Proofs für ihre Eingaben in dem Block, in dem sie enthalten ist, isoliert überprüfbar.
The subtleties lie in precisely what governs the division of subspaces (my original proposal included the automated splitting, merging and rotation of subspace-divisions in order to best deliver internal coherency), how security is maintained within comparatively worthless subspaces and how this can play well with Proof-of-Stake (the original was based upon a master PoW chain, feeding off an idea put forward by Max Kaye in early 2014 to disassociate block chain archival from transition Semantik).
Die Grundidee besteht darin, eine Reihe von Ketten (z. B. n) zu haben, wobei jeweils die staatlichen Übergangs für nur eine Schicht des gesamten Systemstaates (dh ein staatlicher Unterraum) beschrieben werden. Nach der Programmierterminologie können diese als “Fasern” bezeichnet werden. Konten gehören somit zu einem Unterraum und als solcher einzelner Faser; Die Faser, zu der sie gehören, kann einfach aus den ersten Log2 (n) -Abbits der Adresse bestimmt werden. N kann erhöhen oder sinken und ist ein Wert, der in den Haushaltsinformationen über die “Master -Kette” aufrechterhalten wird.
Die Master -Kette, die von einer Reihe von gebundenen Validatoren V gepflegt wurde, wobei die Anzahl der Validatoren proportional zu N ist. Eine zufällige Auswahl der Validatoren bestätigt jeden erzeugten Block, und Validatoren stimmen letztendlich zum Konsens über die Master -Kette ab. Jeder Block der Master -Kette hält einen Hinweis auf den Kopfzeile jeder Faser.
Transaktionskollatoren produzieren Blöcke (Akzeptanzgebühren von Transaktoren) und zahlen Validatoren einige der gesammelten Gebühren, um den Hash ihres Blocks in die Hauptkette aufzunehmen. Blöcke werden in einem bestimmten “Heimatsatz” von Fasern hergestellt. Dies ist im Grunde nur die Fasergruppe, deren staatliche Trie sie beibehalten. Ihre Blöcke können Transaktionen über einen oder viele dieser Fasern beinhalten, obwohl keine außerhalb ihres “Heimatsatzes”.
“Fischer” ist ein Begriff, der freiberuflichen Checkern gegeben wird. Da beide Blockvalidierung und -verfügbarkeit wichtig sind und dass es möglich ist, dass Validatoren-Sätze vertraglich bestochen werden, ist es wichtig, einen Mechanismus zu haben, um zusätzliche rationale Personen zu beteiligen, um als “Pfeifblower” zu fungieren, um zu vermeiden, dass die anderen Validatoren unnötig über die Überprüfung von All-Blöcken stehen. Die Fischer zahlen im Grunde genommen, um zu versuchen, ein Quorum von Validatoren zu überzeugen, dass ein zuvor validierter Block ungültig (oder nicht verfügbar ist, von dem wir annehmen, dass es gleichwertig ist). Wenn ein Fischer einen Validator (oder wahrscheinlicher, eher validierer) zeigt, das auf unehrliche Weise gehandelt hat, können sie alle ihre Anleihen beanspruchen. Um die Dosierung der Validatoren mit falschen Herausforderungen zu vermeiden, ist eine Gebühr zu zahlen.
Schematisch
Entschuldigung für die nicht ganz ganz vorhandene Ascii-Art. Ich bin nicht ganz so 1337 in Inkscape wie Vitalik.
Transactors ==TX+FEE==> Collators ==BLOCK+FEE==> Validators
make transaction validate transaction, random selection chosen to audit
produce Comprehensive Merkle TX/PSR/CMP contents & availability,
Proof and Post State Root, all placed in PoS-consensus master block
collate into X-fiber Block
Fishermen ==CHALLENGE+FEE==> Validators
search for invalid or a selection adjudicate challenge
unavailable X-fiber blocks
Transaktoren
Transaktoren sind so gut wie in Ethereum 1.0 – sie sind die Benutzer des Systems.
Transaktoren: Transaktion durchführen
Transaktoren machen eine Transaktion wie im bestehenden Ethereum -System. Ein oder zwei geringfügige Unterschiede – Adressen können als Entfernungsmetrik verwendet werden; Diejenigen, die die gleiche Anzahl von anfänglichen Bits teilen, werden als “näher” angesehen, was eine größere Gewissheit in die Zukunft bedeutet, dass sie weiterhin im selben staatlichen Unterraum enthalten sein werden. Verträge werden natürlich im selben staatlichen Unterraum wie der Schöpfer erstellt.
Transaktionen wie Kollatoren arbeiten über eine Reihe von Fasern; Vielleicht einer vielleicht alles, wahrscheinlich irgendwo dazwischen. Die Einreichung bei Kollatoren kann durch Faser-Unterhandwerk-Overlays gerichtet werden.
Die Einreichung und Zahlung an die Kollatoren erfolgt genauso wie die vorhandene Transaktionsübermittlung an Bergleute in Ethereum 1.0.
Kollatoren
Collatoren behalten die Präsenz bei mindestens zwei Peer-Sub-Network-Overlays bei. Die Validatoren überlagern und eine oder mehrere Faserüberlagerungen. Die Faserüberlagerungen können eine gerichtete Transaktionsbranche liefern. Collatoren “sammeln” auf einer Reihe von Fasern. Sie behalten eine volle Faserkette für jede Faser, über die sie zusammenstellen, und können alle Transaktionen akzeptieren, die eine beliebige Kombination ihres Fasersatzes beinhalten. Je größer diese Kombination ist, desto größer ist ihr “Transaktionsnetz”, aber desto größer ist ihre Gesamtscheibe/Speicher -Fußabdruck.
Kollatoren: Transaktion validieren
Nach Erhalt einer Transaktion durchlaufen sie die üblichen Ethereum 1.0 -Riten der Überprüfung der Zahlung sind ausreichend, anfängliche Guthaben & c. Sobald die grundlegende Validierung abgeschlossen ist, versuchen sie, sie auszuführen, und werfen sie heraus, wenn sie Faser berührt, die nicht Teil des Fasersatzes von Collator sind.
Collatoren: Erstellen Sie umfassende Merkle -Proof- und Post -State -Wurzel
Die Collatoren stellen jede Post-State-Wurzel (wie im Transaktionseingang von Ethereum 1.0) an und hängen den Block Merkle Proofs und zugehörigen Tipps (z. B. Vertragscode) für alle Eingaben (Gleichgewicht, Nonce, Status, Code) aus allen Subräfräumen an, die für die Bewertung jeder Transaktion aus einem zuvor bekannten Post-State-Wurzeln erforderlich sind.
Dies ermöglicht es einem Auditor, für jede Faser, ohne dass etwas anderes als die vorherige Post-State-Wurzel für jede Faser ist, die Gültigkeit des Blocks zu bestimmen.
Collatoren: In X-Faserblock zusammenarbeiten
Ein Kreuzfaserblock wird aus den gesammelten Gesamtinformationen erstellt. Dies beinhaltet Transaktionen, Transaktionsbelege (Post-State-Wurzel), umfassende Merkle-Proofs und zugehörige Hash-Hinweise. Dieser Block enthält keine konsenspezifischen Informationen wie Zeitstempel, Onkel usw.
Validatoren
Validatoren (die möglicherweise besser benannte Prüfer sind) sind gebundene Teilnehmer, die regelmäßig aus den höchsten Bietern ausgewählt wurden und eine geringe Gebühr für die endgültige Wartung des Netzwerks erheben. Ihre Aufgabe als Ganzes ist es, eine Justiz und die ultimative Autorität über die Gültigkeit und den Transaktionsinhalt der Kette zu bilden. Wir gehen im Allgemeinen davon aus, dass sie größtenteils wohlwollend sind und nicht alle bestochen werden können. Wenn Validatoren gebunden sind, können auch Validatoren zur Prüfung und Einstellung ihrer Anleihe in Bezug auf Gültigkeit oder Informationsverfügbarkeit aufgefordert werden.
Validatoren: Alle im POS-Consensus-Master-Block platziert
Sie behalten die Unterschriftenkontrolle über die Master -Kette bei. Die Master Chain (MC) codiert alle POS/Konsens-Dinge wie Timestamping und enthält eine eigene kleine staatliche Wurzel für die Aufzeichnung von Bondbonden des Validators, laufenden Herausforderungen, Faser-Block-Headerhähne und anderen Haushaltsinformationen.
Jeder Master-Block (MB), ein Satz gesammelter X-Faserblöcke (XBS), werden entnommen; Diese müssen nicht überlappend sein, so dass jede Faser nur zu einem einzelnen XB gehört.
Validatoren: Zufällige Auswahl für die Prüfung von TX/PSR/CMP -Inhalt und Verfügbarkeit ausgewählt
Für jeden MB haben wir eine Reihe von XSBs, auf die sich aus dem MB -Trie befindet. Jedes Faser wird ein zufällig ausgewählter Satz von Validatoren zugewiesen, und die Validatoren müssen überprüft werden, ob XB ihre zugewiesene Faser enthält. Die Validierung umfasst das Erreichen des XB, das Finden der vorherigen PSRs für jede der Fasern (in die MB platzierte) und prüft, dass die Beweise in seinem CMP alle erforderlichen Eingaben zu den darin gesammelten Transaktionen abdecken und dass der PSR tatsächlich die endgültige Zustandswurzel ist, wenn alle ausgeführt werden.
Der Block wird als gültig angesehen, wenn alle zugewiesenen Validatoren ihn unterschreiben. Unterzeichnung Es wird als Behauptung angesehen, dass der Blockinhalt sowohl gültig als auch für eine probabilistisch lange “Herausforderungszeit” zur Verfügung steht, in der ein Fischer herausfordern kann. Jede Herausforderung für die Gültigkeit des Blocks, die letztendlich durch einen vollständigen Konsens eines zufällig ausgewählten Satzes von Validatoren (letztendlich mit einer Mehrheitsabstimmung endet, sollte er hartnäckig umkämpft sein), bedeutet den sofortigen Verlust der Anleihe.
Fischer
Fischer (die als Kopfgeldjäger genannt werden können) sind die freiberuflichen Fehlerprüfer des Systems. Die Beobachtung der Validatoren in der Hoffnung, dass sie Fehlverhalten finden können. Um die Präsenz zu gewährleisten, sind die Auszahlungen so ausgelegt, dass sie riesig sind. Die Kosten der Herausforderung sind klein, aber nicht unbedeutend.
Fischer: Suchen Sie nach ungültigen oder nicht verfügbaren X-Faserblöcken
Sie überprüfen die X-Faserblöcke, die nach Gültigkeitsfehlern und/oder der Unvereinbarkeit von Daten suchen. Wenn sie einen ungültigen Block oder nicht verfügbare Daten finden, starten sie eine Herausforderung (gegen eine geringe Gebühr an Validatoren) in der Hoffnung, dass ein ausreichend großer Teil der Validatoren zustimmt. Wenn sie erfolgreich sind und die Validatoren letztendlich die Herausforderung einhalten, erhalten sie die Anleihen aller Validatoren, die zuvor die Gültigkeit/Verfügbarkeit der Informationen geltend gemacht hatten.
Herausforderung der Fischer
- Fisherman findet einen ungültigen/nicht verfügbaren Block noch nicht außerhalb seiner “Herausforderungsphase” (10-30 Blöcke); zahlt eine Gebühr, legt eine Herausforderungstransaktion in die Master -Kette ein;
- Ein zufällig ausgewählter Satz von Validatoren (z. B. Order, z. Jede stimmt y oder n zur Gültigkeit des Blocks ab;
- Wenn N, erhält der Validator eine kleine Zahlung PN.
- Wenn y, erhält der Validator ihre Anleihe, erhält zwar eine größere Zahlungspy (möglicherweise PY = 2PN).
- Das Ergebnis der Herausforderung (wahrscheinlich im folgenden Block angesammelt) ist:
- Wenn mehr als 66% der Validatoren y (gültig) wählen, endet die Herausforderung. Der Fischer verliert seine Gebühr, kann jedoch eine Herausforderung neu initiieren.
- Wenn mindestens ein Validator Y (gültig) stimmt, setzt sich die Herausforderung mit einem zweiten, größeren Satz zufällig ausgewählter Validatoren fort. Alle Bindungen sind festgelegt.
- Wenn alle Validatoren n (ungültig) stimmen, wird der Block als ungültig aufgezeichnet und die Fischer erhält die Anleihe aller Validatoren, die die Gültigkeit der Blöcke geltend gemacht haben. Dies ist eine sehr große Auszahlung.
- HINWEIS: Wenn das Set alle Validatoren enthält, handelt es sich um eine einfache Regel für Mehrheitskreuzer.
Andere Unterschiede
Alle Adressen sind in einer Nachschlagtabelle enthalten, die für jeden staatlichen Unterraum eindeutig ist. Dies bedeutet, dass sie über eine kleine Anzahl von Bits verwiesen werden können und große Mengen an verschwendeter Entropie in der RLP für Beweise & c vermeiden können.
Notizen
Sobald ein Block nicht in der Herausforderungszeit liegt, wird er als unangreifbar angesehen. Wenn sich herausstellt, dass es schlecht ist, muss es auf die gleiche Weise wie ein Protokoll -Upgrade behoben werden. Daher ist es wahrscheinlich, dass Validatoren und andere große Stakeholder als Fischer fungieren würden, um ihre Investition zu schützen.
