Polkadot: Visão para uma estrutura heterogênea de múltiplas cadeias

Zusammenfassung

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 DR. GAVIN WOOD GRÜNDER, ETHEREUM & PARITÄT [email protected] Zusammenfassung. Heutige blockchain-Architekturen leiden alle unter einer Reihe von Problemen, nicht zuletzt hinsichtlich praktischer Möglichkeiten der Erweiterbarkeit und Skalierbarkeit. Wir glauben, dass dies auf die Verknüpfung zweier sehr wichtiger Teile der Konsensarchitektur zurückzuführen ist, nämlich Kanonizität und Gültigkeit liegen zu eng beieinander. In diesem Artikel wird eine Architektur vorgestellt, die eine heterogene Mehrkette darstellt. was die beiden grundlegend unterscheidet. Durch die Unterteilung dieser beiden Teile und durch die Beschränkung der Gesamtfunktionalität auf ein absolutes Minimum Im Hinblick auf Sicherheit und Transport führen wir praktische Mittel zur Kernerweiterbarkeit vor Ort ein. Die Skalierbarkeit wird durch adressiert ein „Teile-und-Herrsche“-Ansatz für diese beiden Funktionen, der aus seinem verbundenen Kern heraus durch Anreize erweitert wird nicht vertrauenswürdige öffentliche Knoten. Die heterogene Natur dieser Architektur ermöglicht die Zusammenarbeit vieler sehr unterschiedlicher Arten von Konsenssystemen in einer vertrauenslosen, vollständig dezentralisierten „Föderation“, die offenen und geschlossenen Netzwerken einen vertrauensfreien Zugriff ermöglicht einander. Wir schlagen ein Mittel zur Bereitstellung von Abwärtskompatibilität mit einem oder mehreren bereits vorhandenen Netzwerken vor, z Ethereum. Wir glauben, dass ein solches System eine nützliche Basiskomponente bei der allgemeinen Suche nach einer praktischen Lösung darstellt ein umsetzbares System, das in der Lage ist, Skalierbarkeits- und Datenschutzniveaus im globalen Handel zu erreichen. 1. Vorwort Dies soll eine technische „Vision“-Zusammenfassung sein einer möglichen Richtung, die bei der Weiterentwicklung des blockchain-Paradigmas eingeschlagen werden könnte, zusammen mit einer Begründung, warum diese Richtung sinnvoll ist. Es liegt in so detailliert wie möglich in dieser Entwicklungsphase ein System, das zu einer konkreten Verbesserung führen kann Anzahl der Aspekte der blockchain-Technologie. Es ist nicht als Spezifikation gedacht, weder formal noch anderweitig. Es erhebt keinen Anspruch auf Vollständigkeit und stellt auch keinen Anspruch darauf dar Endgültiges Design. Es ist nicht beabsichtigt, Aspekte abzudecken, die nicht zum Kerngeschäft gehören des Frameworks wie APIs, Bindungen, Sprachen usw Nutzung. Dies ist besonders experimentell; wo Parameter festgelegt sind, können sie sich wahrscheinlich ändern. Mechanismen werden als Reaktion auf die Community hinzugefügt, verfeinert und entfernt werden Ideen und Kritiken. Große Teile dieses Papiers werden wahrscheinlich überarbeitet werden, sobald experimentelle Beweise und Prototyping vorliegen uns Informationen darüber, was funktionieren wird und was nicht. Dieses Dokument enthält eine Kernbeschreibung des Protokolls sowie Vorschläge für mögliche Vorgehensweisen verschiedene Aspekte zu verbessern. Es ist vorgesehen, dass der Kern Die Beschreibung dient als Ausgangspunkt für eine Initiale Reihe von Proof-of-Concept. Eine endgültige „Version 1.0“ wäre Basierend auf diesem verfeinerten Protokoll zusammen mit den zusätzlichen Ideen, die sich bewährt haben und entschlossen sind erforderlich sein, damit das Projekt seine Ziele erreichen kann. 1.1. Geschichte. • 10.09.2016: 0.1.0-proof1 • 20.10.2016: 0.1.0-proof2 • 11.01.2016: 0.1.0-proof3 • 11.10.2016: 0.1.0 2. Einführung Blockchains haben sich in mehreren Bereichen als vielversprechend erwiesen, darunter auch im „Internet der Dinge“. (IoT), Finanzen, Governance, Identitätsmanagement, Webdezentralisierung und Asset-Tracking. Trotz der Das technologische Versprechen und die großen Worte müssen wir noch sehen bedeutender realer Einsatz der gegenwärtigen Technologie. Wir glauben, dass dies auf fünf wesentliche Versäumnisse der Gegenwart zurückzuführen ist Technologie-Stacks: Skalierbarkeit: Wie viele Ressourcen weltweit ausgegeben werden über Verarbeitung, Bandbreite und Speicher, damit das System eine einzelne Transaktion verarbeiten kann und wie viele Transaktionen können angemessen abgewickelt werden Spitzenbedingungen? Isolierbarkeit: Kann den unterschiedlichen Bedürfnissen mehrerer Personen gerecht werden Parteien und Anträge im gleichen Rahmen nahezu optimal angesprochen werden? Entwickelbarkeit: Wie gut funktionieren die Tools? Tun Sie es die APIs erfüllen die Bedürfnisse der Entwickler? Sind Lehrmaterialien verfügbar? Sind die richtigen Integrationen vorhanden? Governance: Kann das Netzwerk flexibel bleiben? sich im Laufe der Zeit weiterentwickeln und anpassen? Können Entscheidungen sein mit ausreichender Inklusivität, Legitimität und gemacht Transparenz zur Gewährleistung einer effektiven Führung eines dezentrales System? Anwendbarkeit: Befriedigt die Technologie tatsächlich allein ein dringendes Bedürfnis? Ist weitere „Middleware“ erforderlich, um die Lücke zu schließen? tatsächliche Anwendungen? In der vorliegenden Arbeit wollen wir uns mit den ersten beiden befassen Probleme: Skalierbarkeit und Isolierbarkeit. Das heißt, wir glauben Das Polkadot-Framework kann bei jeder dieser Problemklassen sinnvolle Verbesserungen bewirken. Moderne, effiziente blockchain-Implementierungen wie z Der Paritäts-Client Ethereum [17] kann process mehr als 3.000 Transaktionen pro Sekunde bei Ausführung auf leistungsstarker Consumer-Hardware. Allerdings aktuelle reale Welt blockchain Netzwerke sind praktisch auf etwa 30 begrenzt Transaktionen pro Sekunde. Diese Einschränkung ist hauptsächlich auf die Tatsache zurückzuführen, dass die aktuellen synchronen Konsensmechanismen große zeitliche Sicherheitsmargen erfordern die voraussichtliche Bearbeitungszeit, die durch die noch verschärft wird 1

Einführung

Blockchains haben sich in mehreren Bereichen als vielversprechend erwiesen, darunter auch im „Internet der Dinge“. (IoT), Finanzen, Governance, Identitätsmanagement, Webdezentralisierung und Asset-Tracking. Trotz der Das technologische Versprechen und die großen Worte müssen wir noch sehen bedeutender realer Einsatz der gegenwärtigen Technologie. Wir glauben, dass dies auf fünf wesentliche Versäumnisse der Gegenwart zurückzuführen ist Technologie-Stacks: Skalierbarkeit: Wie viele Ressourcen weltweit ausgegeben werden über Verarbeitung, Bandbreite und Speicher, damit das System eine einzelne Transaktion verarbeiten kann und wie viele Transaktionen können angemessen abgewickelt werden Spitzenbedingungen? Isolierbarkeit: Kann den unterschiedlichen Bedürfnissen mehrerer Personen gerecht werden Parteien und Anträge im gleichen Rahmen nahezu optimal angesprochen werden? Entwickelbarkeit: Wie gut funktionieren die Tools? Tun Sie es die APIs erfüllen die Bedürfnisse der Entwickler? Sind Lehrmaterialien verfügbar? Sind die richtigen Integrationen vorhanden? Governance: Kann das Netzwerk flexibel bleiben? sich im Laufe der Zeit weiterentwickeln und anpassen? Können Entscheidungen sein mit ausreichender Inklusivität, Legitimität und gemacht Transparenz zur Gewährleistung einer effektiven Führung eines dezentrales System? Anwendbarkeit: Befriedigt die Technologie tatsächlich allein ein dringendes Bedürfnis? Ist weitere „Middleware“ erforderlich, um die Lücke zu schließen? tatsächliche Anwendungen? In der vorliegenden Arbeit wollen wir uns mit den ersten beiden befassen Probleme: Skalierbarkeit und Isolierbarkeit. Das heißt, wir glauben Das Polkadot-Framework kann bei jeder dieser Problemklassen sinnvolle Verbesserungen bewirken. Moderne, effiziente blockchain-Implementierungen wie Der Paritäts-Client Ethereum [17] kann mehr verarbeiten 3.000 Transaktionen pro Sekunde bei Ausführung auf leistungsstarker Consumer-Hardware. Allerdings aktuelle reale Welt blockchain Netzwerke sind praktisch auf etwa 30 begrenzt Transaktionen pro Sekunde. Diese Einschränkung ist hauptsächlich auf die Tatsache zurückzuführen, dass die aktuellen synchronen Konsensmechanismen große zeitliche Sicherheitsmargen erfordern die voraussichtliche Bearbeitungszeit, die durch die noch verschärft wirdPOLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 2 Wunsch, langsamere Implementierungen zu unterstützen. Das liegt daran die zugrunde liegende Konsensarchitektur: der staatliche Übergangsmechanismus oder die Mittel, mit denen die Parteien zusammenarbeiten und die Ausführung von Transaktionen ist grundsätzlich logisch in den Konsens-„Kanonisierungs“-Mechanismus oder den Mittel, mit denen sich die Parteien auf eine von mehreren einigen einigen mögliche, gültige Geschichten. Dies gilt gleichermaßen für proof-of-work (PoW)-Systeme wie Bitcoin [15] und Ethereum [5,23] und Proof-of-Stake (PoS)-Systeme wie NXT [8] und Bitshares [12]: alle leiden letztlich unter der gleichen Behinderung. Es ist einfach Strategie, die zum Erfolg von blockchains beigetragen hat. Allerdings durch die enge Verbindung dieser beiden Mechanismen zu einer einzigen Einheit des Protokolls bündeln wir auch mehrere verschiedene Akteure und Anwendungen mit unterschiedlichen Risikoprofilen, unterschiedlichen Skalierbarkeitsanforderungen und unterschiedlichen Datenschutzanforderungen. Eine Einheitsgröße passt nicht für alle. Zu oft kommt es vor, dass in einem Im Streben nach breiter Anziehungskraft nimmt ein Netzwerk einen Grad an Konservatismus an, der zu einem kleinsten gemeinsamen Nenner führt nur wenigen optimal zu dienen und letztendlich zum Scheitern zu führen manchmal in der Fähigkeit zur Innovation, Leistung und Anpassung dramatisch. Einige Systeme wie z.B. Tatsache ist, dass [21] den Zustandsübergangsmechanismus vollständig fallen lässt. Allerdings ist ein Großteil davon Der von uns gewünschte Nutzen erfordert die Fähigkeit zum Übergangszustand gemäß einer gemeinsamen Zustandsmaschine. Das Ablegen löst das Problem ein alternatives Problem; es bietet keine Alternative Lösung. Es scheint daher klar, dass es eine vernünftige Richtung gibt als Weg zu einem skalierbaren dezentralen Computer zu erkunden Die Plattform besteht darin, die Konsensarchitektur von zu entkoppeln der Zustandsübergangsmechanismus. Und es überrascht vielleicht nicht, dass dies die Strategie ist, die Polkadot als Lösung für die Skalierbarkeit verfolgt. 2.1. Protokoll, Implementierung und Netzwerk. Wie Bitcoin und Ethereum, Polkadot beziehen sich sowohl auf ein Netzwerkprotokoll als auch auf das (bisher vorausgesetzte) Primäre öffentliches Netzwerk, das dieses Protokoll ausführt. Polkadot soll ein kostenloses und offenes Projekt sein, dessen Protokollspezifikation unter einer Creative Commons-Lizenz steht und die Code, der unter eine FLOSS-Lizenz gestellt wird. Das Projekt ist wird offen entwickelt und nimmt Beiträge entgegen wo immer sie nützlich sind. Ein System von RFCs, nicht unähnlich Die Python Enhancement Proposals ermöglichen eine Möglichkeit öffentliche Zusammenarbeit bei Protokolländerungen und -aktualisierungen. Unsere erste Implementierung des Polkadot-Protokolls wird als Parity Polkadot-Plattform bekannt sein und wird umfassen eine vollständige Protokollimplementierung zusammen mit der API Bindungen. Wie andere Parity blockchain-Implementierungen PPP ist als allgemeiner blockchain Technologie-Stack konzipiert, weder speziell für ein öffentliches Netzwerk noch für Privat-/Konsortialbetrieb. Die Entwicklung davon also Bisher wurde es von mehreren Parteien finanziert, unter anderem durch ein Zuschuss der britischen Regierung. Dieses Papier beschreibt jedoch Polkadot unter dem Kontext eines öffentlichen Netzwerks. Die Funktionalität, die wir uns in einem öffentlichen Netzwerk vorstellen, ist eine Obermenge dessen, was in erforderlich ist alternative (z. B. private und/oder konsortiale) Einstellungen. Darüber hinaus kann in diesem Zusammenhang der volle Umfang von Polkadot genutzt werden klarer beschrieben und besprochen werden. Das bedeutet Der Leser sollte sich darüber im Klaren sein, dass es bestimmte Mechanismen geben kann beschrieben werden (z. B. Zusammenarbeit mit anderen öffentlichen Netzwerken), die für Polkadot nicht direkt relevant sind wenn es in nichtöffentlichen („erlaubten“) Situationen eingesetzt wird. 2.2. Vorherige Arbeit. Es wurde informell vorgeschlagen, den zugrunde liegenden Konsens vom Staatsübergang zu entkoppeln mindestens zwei Jahre lang privat – Max Kaye war in den frühen Tagen von ein Befürworter einer solchen Strategie Ethereum. Eine komplexere skalierbare Lösung, bekannt als Chain Fasern, die auf Juni 2014 zurückgehen und später erstmals veröffentlicht wurden In diesem Jahr plädierte1 für eine einzelne Relay-Chain und mehrere homogene Chains, die einen transparenten Interchain-Ausführungsmechanismus bieten. Dekohärenz wurde bezahlt durch Transaktionslatenz – Transaktionen, die das erfordern Koordination unterschiedlicher Teile des Systems würde die Bearbeitung dauert länger. Polkadot übernimmt einen Großteil seiner Architektur daraus und aus den Folgegesprächen mit Es wird von verschiedenen Menschen genutzt, auch wenn es sich in seiner Gestaltung und Ausstattung stark unterscheidet. Es gibt zwar keine mit Polkadot vergleichbaren Systeme Tatsächlich in Produktion, mehrere Systeme von einiger Relevanz wurden vorgeschlagen, wenn auch nur wenige in nennenswertem Umfang Detail. Diese Vorschläge können seinin Systeme zerlegt die die Vorstellung einer global kohärenten Situation aufgeben oder reduzieren Zustandsautomaten, also solche, die versuchen, einen globalen Zustand bereitzustellen kohärente Singleton-Maschine durch homogene Shards und diejenigen, die nur auf Heterogenität abzielen. 2.2.1. Systeme ohne globalen Staat. Factom [21] ist ein System, das Kanonizität ohne entsprechendes demonstriert Gültigkeit, wodurch die Chronik der Daten effektiv ermöglicht wird. Wegen der Vermeidung des globalen Zustands und der Schwierigkeiten Mit der damit verbundenen Skalierung kann es als skalierbare Lösung betrachtet werden. Allerdings ist, wie bereits erwähnt, das Set Die Anzahl der Probleme, die es löst, ist grundsätzlich und wesentlich kleiner. Tangle [18] ist ein neuartiger Ansatz für Konsenssysteme. Anstatt Transaktionen in Blöcken anzuordnen und einen Konsens über eine streng verknüpfte Liste zu bilden, um eine global kanonische Ordnung von Zustandsänderungen zu erreichen, wird die Idee einer stark strukturierten Ordnung weitgehend aufgegeben und stattdessen drängt auf einen gerichteten azyklischen Graphen abhängiger Transaktionen mit späteren Elementen, die dabei helfen, frühere Elemente zu kanonisieren durch explizite Referenzierung. Für beliebige Zustandsänderungen gilt: dieser Abhängigkeitsgraph würde schnell unlösbar werden, Für das viel einfachere Modell UTXO2 gilt dies jedoch durchaus vernünftig. Weil das System nur lose kohärent ist und die Transaktionen im Allgemeinen voneinander unabhängig sind Andererseits wird ein großer Teil der globalen Parallelität ziemlich groß natürlich. Die Verwendung des Modells UTXO hat tatsächlich den Effekt Tangle auf eine reine Werttransfer-„Währung“ zu beschränken System und nicht etwas Allgemeineres oder Erweiterbares. Darüber hinaus ohne die harte globale Kohärenz, die Interaktion mit anderen Systemen – die tendenziell eines Absoluten bedürfen Grad des Wissens über den Systemzustand wird unpraktisch. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2nicht ausgegebene Transaktionsausgabe, das Modell, das Bitcoin verwendet, wobei der Status effektiv der Satz von Adressen ist, die einem Wert zugeordnet sind; Transaktionen sammeln solche Adressen und formen sie in einen neuen Satz von Adressen um, deren Gesamtsumme äquivalent ist

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 3 2.2.2. Heterogene Kettensysteme. Seitenketten [3] ist ein vorgeschlagene Ergänzung des Bitcoin-Protokolls, die eine vertrauenslose Interaktion zwischen der Hauptkette Bitcoin ermöglichen würde und zusätzliche Seitenketten. Für welche ist keine vorgesehen Grad der „reichen“ Wechselwirkung zwischen Seitenketten: Die Wechselwirkung wäre darauf beschränkt, die Seitenketten zuzulassen Verwalter des gegenseitigen Vermögens, mit Wirkung – vor Ort Jargon – eine zweiseitige Bindung 3. Die Endvision ist ein Rahmen, mit dem die Währung Bitcoin bereitgestellt werden könnte zusätzliche, wenn auch periphere Funktionalität durch Papping auf einige andere Ketten mit exotischeren Zustandsübergängen Systeme, als das Protokoll Bitcoin zulässt. In diesem Sinne, Bei Sidechains geht es eher um Erweiterbarkeit als um Skalierbarkeit. Tatsächlich ist die Gültigkeit von Seitenketten grundsätzlich nicht geregelt; tokens aus einer Kette (z. B. Bitcoin) im Namen einer Seitenkette gehalten werden, werden nur durch die gesichert Die Fähigkeit der Seitenkette, Bergleute zur Kanonisierung zu motivieren gültige Übergänge. Die Sicherheit des Netzwerks Bitcoin kann nicht einfach in die Arbeit für andere überführt werden blockchains. Darüber hinaus ein Protokoll zur Sicherstellung von Bitcoin Bergleute führen Merge-Mine durch (d. h. duplizieren ihre Kanonisierungskraft auf die der Seitenkette) und, was noch wichtiger ist, sie validieren, dass die Übergänge der Seitenkette außerhalb der Seitenkette liegen Umfang dieses Vorschlags. Cosmos [10] ist ein vorgeschlagenes Mehrkettensystem im Gleiche Ader wie die Seitenketten, Austausch des Nakamoto PoW Konsensmethode für den Tendermint-Algorithmus von Jae Kwon. Im Wesentlichen beschreibt es mehrere Ketten (die in arbeiten). Zonen), die jeweils einzelne Instanzen von Tendermint verwenden, zusammen mit einem Mittel zur vertrauensfreien Kommunikation über a Hauptnabenkette. Diese Kommunikation zwischen den Ketten beschränkt sich auf die Übertragung digitaler Vermögenswerte („insbesondere über tokens“) und nicht auf willkürliche Informationen. Eine solche Kommunikation zwischen den Ketten verfügt jedoch über einen Rückweg für Daten. z.B. um dem Absender den Status der Übertragung mitzuteilen. Validator-Sets für die Zonenketten und insbesondere Die Mittel, Anreize zu schaffen, bleiben wie Seitenketten übrig als ungelöstes Problem. Die allgemeine Annahme ist das Jede Zonenkette wird selbst einen Wert von token halten, dessen Inflation zur Bezahlung von validators verwendet wird. Noch im Anfangsstadium Hinsichtlich des Designs mangelt es dem Vorschlag derzeit an umfassenden Details zu den wirtschaftlichen Mitteln zur Erreichung der Skalierbarkeit Gewissheit über globale Gültigkeit. Die erforderliche lockere Kohärenz zwischen den Zonen und dem Hub wird dies jedoch ermöglichen für zusätzliche Flexibilität hinsichtlich der Parameter der Zone Ketten im Vergleich zu einem System, das stärker durchsetzt Kohärenz. 2.2.3. Casper. Bisher gibt es noch keine umfassende Rezension oder einen direkten Vergleich zwischen Casper [6] und Polkadot wurden gemacht, obwohl man ein ziemlich umfassendes Bild machen kann (und dementsprechend ungenaue) Charakterisierung der beiden. Casper ist eine Neuinterpretation eines PoS-Konsensalgorithmus könnte darauf basieren, dass die Teilnehmer auf welche Gabel wetten würde letztendlich kanonisch werden. Es wurde viel Wert darauf gelegt, sicherzustellen, dass es netzwerkfähig ist Forks, auch wenn sie verlängert sind, und verfügen zusätzlich zum Basismodell Ethereum über ein gewisses Maß an Skalierbarkeit. Als So war Casper bisher tendenziell wesentlich mehr komplexeres Protokoll als Polkadot und seine Vorfahren, und a erhebliche Abweichung vom Grundformat blockchain. Es Es bleibt unklar, wie Casper in Zukunft iterieren wird und wie es aussehen wird, wenn es endlich eingesetzt wird. Während Casper und Polkadot beide interessante neue Protokolle und in gewissem Sinne Erweiterungen davon darstellen Ethereum, es gibt erhebliche Unterschiede zwischen ihnen ultimative Ziele und Wege zum Einsatz. Casper ist ein Ethereum Stiftungszentriertes Projekt, ursprünglich entworfen eine PoS-Änderung des Protokolls sein, ohne dass dies gewünscht wird Erstellen Sie ein grundsätzlich skalierbares blockchain. Entscheidend ist, dass es so ist Entwickelt als Hard-Fork und nicht als etwas Expansiveres, und daher wären es alle Ethereum-Clients und -Benutzer erforderlich, um ein Upgrade durchzuführen oder auf einer Abzweigung mit ungewisser Akzeptanz zu bleiben. Dadurch wird die Bereitstellung erheblich erschwert, wie es bei einem dezentralen Projekt mit Engpässen üblich ist Koordination ist notwendig. Polkadot unterscheidet sich in mehrfacher Hinsicht; in erster Linie, Polkadot ist vollständig erweiterbar und skalierbar blockchain Entwicklungs-, Bereitstellungs- und Interaktionstest Bett. Es ist so gebaut, dass es ein weitgehend zukunftssicheres Geschirr ist Neues assimilieren blockchainTechnologie, sobald sie verfügbar ist, ohne übermäßig komplizierte dezentrale Koordination oder harte Gabeln. Wir stellen uns bereits mehrere Anwendungsfälle vor, z als verschlüsselte Konsortialketten und Hochfrequenzketten mit sehr niedrigen Blockzeiten, die unrealistisch sind jede derzeit geplante zukünftige Version von Ethereum. Schließlich ist die Kopplung zwischen ihm und Ethereum extrem locker; Es ist keine Aktion seitens Ethereum erforderlich ermöglichen eine vertrauenswürdige Transaktionsweiterleitung zwischen den beiden Netzwerke. Kurz gesagt, während Casper/Ethereum 2.0 und Polkadot Wir haben einige flüchtige Gemeinsamkeiten, von denen wir glauben, dass sie ihr Endziel sind ist wesentlich unterschiedlich und das anstatt zu konkurrieren, Die beiden Protokolle werden wahrscheinlich letztendlich unter einem koexistieren eine für beide Seiten vorteilhafte Beziehung auf absehbare Zeit.

Zusammenfassung

Polkadot ist eine skalierbare heterogene Multikette. Dies bedeutet, dass im Gegensatz zu früheren blockchain-Implementierungen die sich auf die Bereitstellung einer einzigen Kette unterschiedlicher Produkte konzentriert haben Grad der Allgemeinheit über potenzielle Anwendungen, Polkadot selbst ist so konzipiert, dass es überhaupt keine inhärente Anwendungsfunktionalität bietet. Vielmehr liefert Polkadot das Fundament „Relaiskette“, auf der eine große Anzahl validierbarer, Es können global kohärente dynamische Datenstrukturen gehostet werden Seite an Seite. Wir nennen diese Datenstrukturen „parallelisiert“. Ketten oder Parachains, obwohl kein besonderer Bedarf dafür besteht sie sollen blockchain in der Natur sein. Mit anderen Worten, Polkadot kann als äquivalent zu einer Menge unabhängiger Ketten angesehen werden (z. B. der Menge, die enthält Ethereum, Ethereum Classic, Namecoin und Bitcoin) bis auf zwei sehr wichtige Punkte: • Gebündelte Sicherheit; • Vertrauensfreie Interchain-Transaktionsfähigkeit. Aufgrund dieser Punkte halten wir Polkadot für „skalierbar“. Im Prinzip kann ein Problem, das auf Polkadot bereitgestellt werden soll, im Wesentlichen parallelisiert – skaliert – werden eine große Anzahl von Parachains. Da alle Aspekte von jedem Parachain kann parallel von einem anderen Segment des Polkadot-Netzwerks ausgeführt werden, das System verfügt über einige Fähigkeiten zu skalieren. Polkadot bietet ein eher schlichtes Stück davon 3im Gegensatz zu einer Einwegbindung, bei der im Wesentlichen tokens in einer Kette zerstört werden, um tokens in einer anderen ohne das zu erstellen Mechanismus, um das Gegenteil zu tun und die ursprünglichen tokens wiederherzustellenPOLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 4 Infrastruktur, so dass ein Großteil der Komplexität auf der Middleware-Ebene angegangen werden muss. Dies ist eine bewusste Entscheidung, die darauf abzielt, das Entwicklungsrisiko zu verringern und dies zu ermöglichen erforderliche Software innerhalb kurzer Zeit zu entwickeln und mit einem guten Maß an Vertrauen in seine Sicherheit und Robustheit. 3.1. Die Philosophie von Polkadot. Polkadot sollte bieten eine absolut grundsolide Grundlage Bauen Sie die nächste Welle von Konsenssystemen auf das Risikospektrum produktionsfähiger ausgereifter Konstruktionen zu aufkeimenden Ideen. Durch die Bereitstellung starker Garantien für Sicherheit, Isolation und Kommunikation kann Polkadot dies ermöglichen Parachains können selbst aus einer Reihe von Eigenschaften auswählen. Tatsächlich gehen wir davon aus, dass verschiedene experimentelle blockchains die Eigenschaften dessen, was als sinnvoll angesehen werden könnte, vorantreiben heute. Wir sehen konservativ, hochwertige Ketten ähnlich Bitcoin oder Z-Cash [20], die neben niedrigeren Werten koexistieren „Themenketten“ (so ein Marketing, so lustig) und Testnetze mit null oder nahezu null Gebühren. Wir sehen vollständig verschlüsselt, „dunkle“, Konsortiumsketten, die daneben operieren – und sogar Bereitstellung von Dienstleistungen für hochfunktionale und offene Ketten wie solche wie Ethereum. Wir sehen experimentelles Neues VM-basierte Ketten wie ein subjektiv zeitbelasteter Wasm Die Kette wird als Mittel zur Auslagerung schwieriger Rechenprobleme aus einer ausgereifteren Ethereum-ähnlichen Kette verwendet oder eine eingeschränktere Bitcoin-ähnliche Kette. Um Ketten-Upgrades zu verwalten, wird Polkadot von Natur aus verwendet Unterstützen Sie wahrscheinlich eine Art Governance-Struktur auf bestehenden stabilen politischen Systemen und hat einen Zweikammeraspekt, ähnlich dem Yellow Paper Council [24]. Als Die ultimative Autorität, die zugrunde liegenden steckbaren token-Inhaber, hätte die „Referendums“-Kontrolle. Um die Benutzerfreundlichkeit widerzuspiegeln Angesichts des Entwicklungsbedarfs, aber des Legitimitätsbedarfs der Entwickler gehen wir davon aus, dass sich eine vernünftige Richtung herausbilden würde Die beiden Kammern bestehen aus einem „Benutzer“-Ausschuss (bestehend aus gebunden validators) und ein „technischer“ Ausschuss gebildet großer Kundenentwickler und Ökosystemteilnehmer. Die Die Gruppe der token-Inhaber würde die ultimative Legitimität behalten und eine Supermehrheit bilden, um diese Struktur zu erweitern, neu zu parametrisieren, zu ersetzen oder aufzulösen, was wir tun Zweifeln Sie nicht an der eventuellen Notwendigkeit: in den Worten von Twain „Regierungen und Windeln müssen oft und für immer gewechselt werden aus dem gleichen Grund“. Während eine Neuparametrisierung in der Regel trivial innerhalb eines größeren Konsensmechanismus zu arrangieren ist, wären eher qualitative Änderungen wie Ersatz und Erweiterung erforderlich Wahrscheinlich muss es sich entweder um nicht automatisierte „Soft-Dekrete“ handeln (z. B. durch die Kanonisierung einer Blocknummer und der hash eines Dokuments, das das neue Protokoll offiziell spezifiziert) oder es erforderlich machen, dass der Kernkonsensmechanismus Folgendes enthält: eine ausreichend reichhaltige Sprache, um jeden Aspekt ihrer selbst zu beschreiben was möglicherweise geändert werden muss. Letzteres ist ein mögliches Ziel, Ersteres wird jedoch eher gewählt, um dies zu tun einen angemessenen Entwicklungszeitplan ermöglichen. Die wichtigsten Grundsätze von Polkadot und die darin enthaltenen Regeln Wir bewerten alle Designentscheidungen: Minimal: Polkadot sollte möglichst wenig Funktionalität haben. Einfach: Es sollte keine zusätzliche Komplexität vorhanden sein im Basisprotokoll enthalten, als vernünftigerweise möglich ist in Middleware geladen, durch a gelegt parachain oder in einer späteren Optimierung eingeführt. Allgemein: keine unnötige Anforderung, Einschränkung oder Parachains sollten eingeschränkt werden; Polkadot sollte ein Prüfstand für die Entwicklung eines Konsenssystems sein, das dadurch optimiert werden kann Das Modell, in das Erweiterungen passen, so abstrakt wie möglich gestalten. Robust: Polkadot sollte eine grundsätzliche Bereitstellung bieten Stabile Basisschicht. Neben der wirtschaftlichen Solidität bedeutet dies auch eine Dezentralisierung zur Minimierung die Vektoren für hochlohnende Angriffe.

Teilnahme an Polkadot

Es gibt vier grundlegende Rollen bei der Wartung eines Polkadot Netzwerk: Collator, Fisherman, Nominator und validator. In eine mögliche Implementierung von Polkadot, der letztgenannten Rolle kann tatsächlich in zwei Rollen unterteilt werden: grundlegende validator und Verfügbarkeitsgarantie; Dies wird im Abschnitt besprochen 6.5.3. Collator Fischer Validatoren (diese Gruppe) Validatoren (andere Gruppen) stimmt zu wird Monitore Berichte schlecht Verhalten zu bietet Block Kandidaten für Nominator Abbildung 1. Die Interaktion zwischen vier Rollen von Polkadot. 4.1. Validatoren. Ein validator ist die höchste Gebühr und hilft dabei, neue Blöcke im Polkadot-Netzwerk abzudichten. Voraussetzung für die Rolle des validator ist eine ausreichend hohe Bindung hinterlegt werden, obwohl wir dies auch anderen gebundenen Parteien gestatten Nominieren Sie einen oder mehrere validators, die für sie und als handeln Ein solcher Teil der Anleihe des validator gehört möglicherweise nicht unbedingt dem validator selbst, sondern diesen Nominatoren. Ein validator muss eine Relay-Chain-Client-Implementierung mit hoher Verfügbarkeit und Bandbreite ausführen. An jedem Block Der Knoten muss bereit sein, die Rolle des Ratifizierenden zu übernehmen ein neuer Block auf einer nominierten Parachain. Dieser Prozess beinhaltet den Empfang, die Validierung und die erneute Veröffentlichung des Kandidaten Blöcke. Die Nominierung ist deterministisch, aber praktisch unvorhersehbar. Da der validator nicht möglich ist Es ist vernünftigerweise zu erwarten, dass eine vollständige Synchronisierung gewährleistet ist Datenbank aller Parachains, es wird erwartet, dass der validator die Aufgabe benennen wird, einen Vorschlag für ein neues zu entwickeln Parachain-Block an einen Dritten, einen sogenannten Collator, weiter. Sobald alle neuen Parachain-Blöcke ordnungsgemäß von ihren ernannten validator-Untergruppen, validators, ratifiziert wurden muss dann den Relay-Chain-Block selbst ratifizieren. Dies beinhaltet Aktualisieren des Status der Transaktionswarteschlangen (im Wesentlichen Verschieben von Daten aus der Ausgabewarteschlange einer Parachain in eine andere Eingabewarteschlange von Parachain), Verarbeitung der Transaktionen von der ratifizierte Relay-Chain-Transaktionssatz und die Ratifizierung des Endblock, einschließlich der letzten Parachain-Änderungen.POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 5 Ein validator kommt seiner Pflicht, einen Konsens zu finden, nicht nach nach den Regeln unseres gewählten Konsensalgorithmus wird bestraft. Bei anfänglichen, unbeabsichtigten Ausfällen gilt dies als durch die Belohnung von validator einbehalten. Wiederholte Ausfälle führen zu einer Verringerung ihrer Sicherheitsbindung (durch Brennen). Nachweislich böswillige Aktionen wie Doppelsignierung oder Die Verschwörung zur Bereitstellung eines ungültigen Blocks führt zum Verlust von die gesamte Bindung (die teilweise verbrannt, aber größtenteils gegeben ist). an den Informanten und die ehrlichen Akteure). In gewisser Weise ähneln validators den Mining-Pools der aktuellen PoW blockchains. 4.2. Nominatoren. Ein Nominator ist eine Beteiligungspartei Wer trägt zur Sicherheitsleistung eines validator bei? Sie haben keine zusätzliche Rolle außer der Platzierung von Risikokapital und dergleichen So signalisieren sie, dass sie einem bestimmten validator vertrauen (oder Satz davon), verantwortungsbewusst bei der Aufrechterhaltung der zu handeln Netzwerk. Sie erhalten eine anteilige Erhöhung oder Kürzung in ihrer Einlage entsprechend dem Wachstum der Anleihe sie tragen dazu bei. Zusammen mit den Collatoren sind es in einigen Fällen auch die Nominatoren Sinn ähnlich wie die Miner der heutigen PoW-Netzwerke. 4.3. Collatoren. Transaktions-Collators (kurz Collators) sind Parteien, die validators bei der Erstellung gültiger Dokumente unterstützen Parachain-Blöcke. Sie pflegen einen „vollständigen Knoten“ für eine bestimmte Parachain; Das bedeutet, dass sie alles Notwendige behalten Informationen, um neue Blöcke erstellen und ausführen zu können Transaktionen auf die gleiche Weise wie Miner auf aktuellen PoW blockchains. Unter normalen Umständen sind sie sammelt Transaktionen und führt sie aus, um eine unversiegelte Transaktion zu erstellen blockieren und zusammen mit einem Zero-Wissen bereitstellen Beweis, an einen oder mehrere validators, für die derzeit verantwortlich ist schlägt einen Parachain-Block vor. Die genaue Art der Beziehung zwischen Collators, Nominators und validators wird sich wahrscheinlich ändern Zeit. Zunächst erwarten wir, dass die Zusammensteller sehr eng zusammenarbeiten mit validators, da es nur wenige geben wird (vielleicht nur eine) Parachain(s) mit geringem Transaktionsvolumen. Die Die anfängliche Client-Implementierung umfasst RPCs, um a zu ermöglichen Parachain-Collator-Knoten, um einen (Relaychain-) validator-Knoten bedingungslos mit einer nachweislich gültigen Parachain zu versorgen blockieren. Da die Kosten für die Aufrechterhaltung einer synchronisierten Version von Alle diese Parachains nehmen zu, wir gehen davon aus, dass es noch mehr geben wird Infrastruktur vorhanden, die dabei hilft, die zu trennen Pflichten gegenüber unabhängigen, wirtschaftlich motivierten Parteien. Wir gehen davon aus, dass es irgendwann Zusammentragspools geben wird, die darum wetteifern erheben die meisten Transaktionsgebühren. Solche Kollektoren können beauftragt werden, bestimmte validators über einen bestimmten Zeitraum zu bedienen und einen fortlaufenden Anteil am Prämienerlös zu erhalten. Alternativ können „freiberufliche“ Zusammensteller einfach eine erstellen Markt, der gültige Parachain-Blöcke als Gegenleistung für einen wettbewerbsfähigen Anteil der sofort zahlbaren Belohnung anbietet. Ebenso würden dezentrale Nominator-Pools mehrere ermöglichen gebundene Teilnehmer koordinieren und teilen die Pflicht eines validator. Diese Bündelungsfähigkeit gewährleistet eine offene Beteiligung Dies führt zu einem dezentraleren System. 4.4. Fischer. Im Gegensatz zu den anderen beiden aktiven Parteien Fischer stehen in keinem direkten Zusammenhang mit der Blockerstellung Prozess. Sie sind vielmehr unabhängige „Kopfgeldjäger“. motiviert durch eine große einmalige Belohnung. Genau wegen Aufgrund der Existenz von Fischern gehen wir davon aus, dass Fehlverhalten selten vorkommt und wenn, dann nur aufgrund von die gebundene Partei ist bei der Sicherheit geheimer Schlüssel nachlässig, und nicht aus böswilliger Absicht. Der Name kommt aus der erwarteten Häufigkeit der Belohnung, den Mindestvoraussetzungen für die Teilnahme und der letztendlichen Belohnungsgröße. Fischer erhalten ihre Belohnung durch einen rechtzeitigen Nachweis mindestens eine gebundene Partei hat rechtswidrig gehandelt. Illegale Handlungen Dazu gehört die Unterzeichnung von jeweils zwei Blöcken mit demselben ratifizierten übergeordneten Element oder, im Fall von Fallschirmen, die Unterstützung bei der Ratifizierung eines ungültigen Elements blockieren. Um eine Überbelohnung oder den Kompromiss zu verhindern und unerlaubte Verwendung des geheimen Schlüssels einer Sitzung, der Basisbelohnung dafür Die Bereitstellung einer einzelnen illegal signierten Nachricht von validator ist minimal. Diese Belohnung nimmt asymptotisch zu, je mehr Dies bestätigen illegale Signaturen von anderen validators vorausgesetzt, es handelt sich um einen echten Angriff. Die Asymptote ist eingestellt bei 66 %, was unserer grundlegenden Sicherheitsaussage entspricht Zwei Drittel der validators handeln wohlwollend. Fischer ähneln in gewisser Weise „vollständigen Knoten“ in heutigen blockchain Systemen die benötigten Ressourcen sind relativ klein und erfordern eine stabile Betriebszeit und Bandbreite ist nicht erforderlich. Fischer unterscheiden sich darin so wie sie eine kleine Kaution hinterlegen müssen.Diese Bindung verhindert Sybil-Angriffe verschwenden die Zeit und Rechenleistung von validators Ressourcen. Es ist sofort ausziehbar, wahrscheinlich nein mehr als den Gegenwert von ein paar Dollar und kann führen eine saftige Belohnung dafür zu ernten, dass man ein Fehlverhalten entdeckt validator.

Designübersicht

Dieser Abschnitt soll einen kurzen Überblick darüber geben System als Ganzes. Eine gründlichere Untersuchung der Das System wird im folgenden Abschnitt beschrieben. 5.1. Konsens. Auf der Relay-Kette wird Polkadot erreicht Konsens auf niedriger Ebene über eine Reihe von einvernehmlich vereinbarten Gültigkeiten blockiert durch einen modernen asynchronen byzantinischen fehlertoleranten (BFT)-Algorithmus. Der Algorithmus wird inspiriert sein durch das einfache Tendermint [11] und das wesentlich mehr beteiligt HoneyBadgerBFT [14]. Letzteres bietet eine Effizienter und fehlertoleranter Konsens über eine willkürliche Entscheidung Defekte Netzwerkinfrastruktur angesichts einer Reihe meist harmloser Behörden oder validators. Für ein Netzwerk im Proof-of-Authority-Stil (PoA) reicht dies aus würde ausreichen, wie auch immer man sich Polkadot vorstellt auch als Netzwerk in einer vollständig offenen und öffentlichen Umgebung einsetzbar Situation ohne besondere Organisation oder Vertrauen Behörde, die für die Aufrechterhaltung erforderlich ist. Daher brauchen wir eine Mittel zur Bestimmung einer Reihe von validators und zur Schaffung von Anreizen sie, um ehrlich zu sein. Hierzu nutzen wir die PoS-basierte Auswahl Kriterien. 5.2. Den Einsatz beweisen. Wir gehen davon aus, dass das Netzwerk wird eine Möglichkeit haben, zu messen, wie viel „Einsatz“ ein bestimmtes Konto hat. Zum leichteren Vergleich mit Vorhandene Systeme nennen wir die Maßeinheit „tokens“. Leider ist der Begriff für a nicht ideal Es gibt eine Reihe von Gründen, nicht zuletzt weil es einfach ein Skalar ist Es gibt keine Vorstellung davon, welchen Wert ein Konto hat Individualität. Wir stellen uns vor, dass validators selten (höchstens) gewählt werden einmal pro Tag, aber vielleicht so selten wie einmal pro Quartal), durch ein Nominated Proof-of-Stake (NPoS)-System. Anreize können durch eine anteilige Zuteilung erfolgenPOLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 6 Relais Kette Validator-Schwarm (jeweils gefärbt durch seine bezeichnete Parachain) Transaktion (eingereicht von externer Akteur) Parachain Brücke Virtuelle Parachain (z. B. Ethereum) Parachain Parachain Warteschlangen und I/O Propagierte Transaktionen Kandidateneinreichung blockieren 2. Ordnung Relaiskette Parachain-Community Konto Eingehende Transaktion Ausgehende Transaktion Interchain-Transaktionen (verwaltet von validators) Collator Propagierter Block Fischer Abbildung 2. Ein zusammenfassendes Schema des Polkadot-Systems. Dies zeigt Collators, die Benutzertransaktionen sammeln und weitergeben sowie Blockkandidaten an Fischer und validators weitergeben. Es auch zeigt, wie ein Konto eine Transaktion, die aus seiner Parachain ausgeführt wird, über die Relay-Chain buchen kann und weiter in eine andere Parachain, wo es als Transaktion auf ein dortiges Konto interpretiert werden kann. Mittel aus einer token Basiserweiterung (bis zu 100 %) pro Jahr, wahrscheinlicher jedoch etwa 10 % zusammen mit etwaige erhobene Transaktionsgebühren. Während eine Ausweitung der Geldbasis typischerweise zu Inflation führt, da alle token Eigentümer Hätte er eine faire Chance auf Teilnahme, müsste kein tokenInhaber eine Wertminderung erleiden Bestände im Laufe der Zeit, vorausgesetzt, sie waren bereit, eine zu übernehmen Rolle im Konsensmechanismus. Ein besonderer Anteil von tokens wären für den staking-Prozess vorgesehen; die Die effektive Basiserweiterung token würde angepasst werden einen marktbasierten Mechanismus, um dieses Ziel zu erreichen. Validatoren sind durch ihre Einsätze stark gebunden; verlassend Die Anleihen der validators bleiben noch lange bestehen, nachdem die Pflichten der validators aufgehört haben (vielleicht etwa drei Monate). So lange Die Liquidationsfrist der Anleihe lässt zukünftiges Fehlverhalten zu bis zur regelmäßigen Kontrolle der Kette bestraft. Fehlverhalten führt zu einer Bestrafung, beispielsweise einer Kürzung Belohnung oder, in Fällen, die vorsätzlich gefährden Die Integrität des Netzwerks wird beeinträchtigt, der validator verliert einige oder alle seiner Integrität Anteil an andere validators, Informanten oder die Stakeholder als Ganzes (durch Brennen). Zum Beispiel ein validator Wer versucht, beide Zweige einer Abzweigung zu ratifizieren (manchmal (bekannt als „Angriff aus kurzer Distanz“) kann identifiziert werden und auf letztere Weise bestraft. Langstreckenangriffe, bei denen nichts auf dem Spiel steht4, werden durch eine einfache „Checkpoint“-Verriegelung umgangen, die eine gefährliche Kettenneuorganisation von mehr als einem verhindert besondere Kettentiefe. Um sicherzustellen, dass Clients neu synchronisiert werden lassen sich nicht auf die falsche Kette täuschen, regelmäßig Es wird zu „Hard Forks“ kommen (höchstens im gleichen Zeitraum). validators‘ Anleiheliquidation), die den jüngsten Checkpoint-Block hashes in Clients fest codiert. Dies passt gut zu einem weiteren den Platzbedarf reduzierenden Maß der „endlichen Kettenlänge“ oder periodisches Zurücksetzen des Genesis-Blocks. 5.3. Parachains und Collators. Jeder Parachain bekommt Ähnliche Sicherheitsvorkehrungen wie bei der Relay-Kette: die Die Header der Parachains sind im Relay-Chain-Block versiegelt Sicherstellen, dass nach der Bestätigung keine Neuorganisation oder „doppelte Ausgaben“ möglich sind. Dies ist eine ähnliche Sicherheitsgarantie wie die Seitenketten und das Mergemining von Bitcoin. Polkadot bietet jedoch auch starke Garantien dafür, dass die Zustandsübergänge der Parachains gültig sind. Dies geschieht dadurch, dass die Menge der validators kryptografisch zufällig in Teilmengen segmentiert wird; eine Teilmenge pro Parachain, wobei die Teilmengen pro Block möglicherweise unterschiedlich sind. Dies Das Setup impliziert im Allgemeinen, dass die Blockzeiten von Parachains dies tun mindestens so lang sein wie die der Relaiskette. Das Spezifische Mittel zur Bestimmung der Partitionierung liegen außerhalb des Geltungsbereichs 4Bei einem solchen Angriff schmiedet der Gegner vom Genesis-Block an eine völlig neue Geschichtskette. Durch die Steuerung a Obwohl sie zu Beginn einen relativ unbedeutenden Anteil am Einsatz haben, sind sie in der Lage, ihren Anteil am Einsatz im Vergleich zu allen anderen schrittweise zu erhöhen Stakeholder, da sie die einzigen aktiven Teilnehmer an ihrer alternativen Geschichte sind. Da es für die Schöpfung keine intrinsische physische Einschränkung gibt von Blöcken (im Gegensatz zu PoW, wo ziemlich viel Rechenenergie aufgewendet werden muss), sind sie in der Lage, eine Kette zu erstellen, die länger ist als die echte Kette in einem relativ kurze Zeitspanne und machen Sie es möglicherweise zum längsten und besten, indem Sie den kanonischen Zustand des Netzwerks übernehmen.POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 7 dieses Dokuments, würde aber wahrscheinlich auf einem von beiden basieren ein Commit-Reveal-Framework ähnlich dem RanDAO [19] oder Verwenden Sie Daten, die aus vorherigen Blöcken jeder Parachain kombiniert wurden unter einem kryptografisch sicheren hash. Solche Teilmengen von validators sind erforderlich, um a bereitzustellen Parachain-Blockkandidat, der garantiert gültig ist (am Schmerz der Anleihebeschlagnahme). Die Gültigkeit dreht sich um zwei wichtige Punkte; erstens, dass es an sich gültig ist – das Alle Zustandsübergänge wurden gewissenhaft ausgeführt und das alles Externe Daten, auf die verwiesen wird (z. B. Transaktionen), sind für die Einbeziehung gültig. Zweitens, dass es sich um alle Daten handelt, die nicht dazugehören B. diese externen Transaktionen, über eine ausreichend hohe Verfügbarkeit verfügen, damit die Teilnehmer dazu in der Lage sind Laden Sie es herunter und führen Sie den Block manuell aus.5 Validatoren stellen möglicherweise nur einen „Null“-Block bereit, der keine externen „Transaktionsdaten“ enthält, laufen jedoch möglicherweise Gefahr, eine geringere Belohnung zu erhalten, wenn sie dies tun. Sie arbeiten Seite an Seite ein Parachain-Klatschprotokoll mit Kollatatoren – Einzelpersonen die Transaktionen in Blöcken zusammenfassen und einen nicht interaktiven, wissensfreien Beweis liefern, dass der Block ein gültiges Kind seines Elternblocks darstellt (und jede Transaktion entgegennimmt). Gebühren für ihre Mühe). Es bleibt den Parachain-Protokollen überlassen, ihre eigenen zu spezifizieren Mittel zur Spam-Prävention: Es gibt keine grundsätzliche Vorstellung von „Rechenressourcenmessung“ oder „Transaktionsgebühr“ durch die Relaiskette auferlegt. Es gibt diesbezüglich auch keine direkte Durchsetzung durch das Relay-Chain-Protokoll (obwohl es Es ist unwahrscheinlich, dass sich die Stakeholder für eine Übernahme entscheiden würden eine Parachain, die keinen anständigen Mechanismus bot). Dies ist eine ausdrückliche Anspielung auf die Möglichkeit unterschiedlicher Ketten Ethereum, z.B. eine Bitcoin-ähnliche Kette, die ein viel einfacheres Gebührenmodell oder ein anderes, noch nicht vorgeschlagenes Spam-Präventionsmodell hat. Die Relay-Chain von Polkadot selbst wird wahrscheinlich als existieren Ethereum-ähnliche Konten und Statuskette, möglicherweise ein EVMDerivat. Da die Relay-Chain-Knoten dies benötigen Führen Sie wesentliche andere Verarbeitungsvorgänge durch, den Transaktionsdurchsatz werden teilweise durch hohe Transaktionsgebühren minimiert und, falls unsere Forschungsmodelle dies erfordern, eine Blockgrößenbeschränkung. 5.4. Interchain-Kommunikation. Der entscheidende letzte Bestandteil von Polkadot ist die Kommunikation zwischen den Ketten. Seitdem Parachains können eine Art Informationskanal zwischen sich haben, wir erlauben uns, Polkadot a zu betrachten skalierbare Multikette. Im Fall von Polkadot ist die Kommunikation so einfach wie möglich: Transaktionen werden in a ausgeführt Parachain sind (gemäß der Logik dieser Kette) dazu in der Lage bewirken die Weiterleitung einer Transaktion an eine zweite Parachain oder möglicherweise die Relaiskette. Wie externe Transaktionen Bei Produktions-blockchains sind sie vollständig asynchron und es gibt keine intrinsische Fähigkeit für sie, etwas zurückzugeben Art von Informationen zurück zu ihrem Ursprung. Ziel: bekommt Daten von früher validators des Blocks. Konto erhält Beitrag: Eintrag entfernt aus Eingang Merkle tree Konto sendet Beitrag: Eintrag platziert in Ausgang Merkle tree für das Ziel Parachain Ausgang Quelle: Aktien Daten mit den nächsten Blöcken validators Postnachweis gespeichert in Parachain-Ausstieg Merkle Baum geroutete Referenz platziert in Zielparachains Eingang Merkle tree Eindringen Abbildung 3. Eine grundlegende schematische Darstellung die Hauptteile des Routings für Gepostete Transaktionen („Posts“). Um eine minimale Implementierungskomplexität zu gewährleisten, minimal Risiko und minimal Zwangsjacke von Zukunft Parachain-Architekturen sind diese Interchain-Transaktionen praktisch nicht von extern signierten Standardtransaktionen zu unterscheiden. Die Transaktion verfügt über ein Ursprungssegment, das die Möglichkeit bietet, eine Parachain zu identifizieren, und eine Adresse, die beliebig groß sein kann. Im Gegensatz zu gängigen aktuellen Systemen wie Bitcoin und Ethereum sind Interchain-Transaktionen mit keinerlei „Zahlung“ von Gebühren verbunden; Jede solche Zahlung muss durch Verhandlungslogik auf den Quell- und Zielparachains verwaltet werden. Ein System wie das vorgeschlagene Die Serenity-Veröffentlichung [7] von Ethereum wäre ein einfaches Mittel Es ist jedoch schwierig, eine solche kettenübergreifende Ressourcenzahlung zu verwalten Wir gehen davon aus, dass zu gegebener Zeit andere in den Vordergrund treten werden. Interchain-Transaktionen werden mit einer einfachen Lösung gelöst Warteschlangenmechanismus basierend auf einem Merkle tree, um sicherzustellen Treue. Es ist die Aufgabe der Relay-Chain-Betreuer, dies zu tun Verschieben Sie Transaktionen in der Ausgabewarteschlange einer Parachain in die Eingabewarteschlange der Zielparachain. Die Übergebene Transaktionen werden in der Relay-Chain referenziert, sind jedoch nicht relAy-Chain-Transaktionen selbst. Um zu verhindern, dass ein Parachain einen anderen Parachain mit Spam überschwemmt Transaktionen, damit eine Transaktion gesendet werden kann, ist dies erforderlich dass die Eingabewarteschlange des Ziels nicht zu groß ist der Zeitpunkt des Endes des vorherigen Blocks. Wenn die Eingabe Ist die Warteschlange nach der Blockverarbeitung zu groß, gilt sie als „gesättigt“ und es können keine Transaktionen dorthin weitergeleitet werden es innerhalb nachfolgender Blöcke, bis es wieder unter das reduziert wird Grenze. Diese Warteschlangen werden in der Relay-Chain verwaltet Parachains können so die Sättigung des anderen bestimmen Status; Auf diese Weise ist der Versuch, eine Transaktion zu buchen, fehlgeschlagen zu einem blockierten Ziel können synchron gemeldet werden. (Da es jedoch keinen Rückkehrpfad gibt, konnte eine sekundäre Transaktion, die aus diesem Grund fehlschlug, nicht zurückgemeldet werden an den ursprünglichen Anrufer und andere Möglichkeiten zur Wiederherstellung müsste stattfinden.) 5.5. Polkadot und Ethereum. Aufgrund der Turing-Vollständigkeit von Ethereum gehen wir davon aus, dass ausreichend Möglichkeiten für die Interoperabilität zwischen Polkadot und Ethereum bestehen voneinander, zumindest innerhalb einiger leicht ableitbarer Sicherheitsgrenzen. Kurz gesagt, wir stellen uns vor, dass Transaktionen von Polkadot kann von validators signiert und dann eingespeist werden 5Eine solche Aufgabe könnte zwischen validators geteilt werden oder zur designierten Aufgabe einer Gruppe stark verbundener validators werden, die als bezeichnet werden Verfügbarkeitsgaranten.

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 8 Ethereum, wo sie interpretiert und umgesetzt werden können ein Transaktionsweiterleitungsvertrag. In die andere Richtung, Wir sehen die Verwendung speziell formatierter Protokolle (Ereignisse) vor. aus einem „Breakout-Vertrag“ stammen, um eine schnelle Überprüfung zu ermöglichen, dass eine bestimmte Nachricht weitergeleitet werden sollte. 5.5.1. Polkadot bis Ethereum. Durch die Wahl eines BFT Konsensmechanismus mit validators, gebildet aus a Gruppe von Stakeholdern, die durch eine Zustimmungsabstimmung bestimmt wird Mechanismus können wir einen sicheren Konsens mit einem erreichen selten wechselnde und bescheidene Anzahl von validators. In einem System mit insgesamt 144 validators beträgt eine Blockzeit von 4 Sekunden und eine Endgültigkeit von 900 Blöcken (unter Berücksichtigung böswilliger Angriffe). Verhaltensweisen wie Doppelstimmen werden zur Anzeige gebracht, bestraft und repariert), kann die Gültigkeit einer Sperre vernünftigerweise sein Als bewiesen gelten bereits 97 Unterschriften (zwei Drittel von 144 plus eine) und eine anschließende 60-minütige Überprüfungsperiode, in der keine Anfechtungen hinterlegt werden. Ethereum ist in der Lage, einen „Einbruchsvertrag“ zu hosten, der Die 144 Unterzeichner können gepflegt und kontrolliert werden sie. Da die Wiederherstellung der digitalen Signatur mit elliptischer Kurve (ECDSA) nur 3.000 Gase unter dem EVM erfordert, und seitdem Wir möchten wahrscheinlich, dass die Validierung nur auf einem erfolgt Supermehrheit von validators (statt völliger Einstimmigkeit), Die Grundkosten von Ethereum bestätigen, dass eine Anweisung vorliegt wurde ordnungsgemäß validiert, da aus dem Polkadot-Netz nicht mehr als 300.000 Gas stammen würden – lediglich 6 % davon die Gesamtblockgasgrenze liegt bei 5,5 M. Erhöhen der Anzahl der validators (wie es für die Bearbeitung erforderlich wäre). Dutzende Ketten) erhöhen diese Kosten jedoch zwangsläufig Es wird allgemein erwartet, dass die Transaktionsbandbreite von Ethereum im Laufe der Zeit wächst, wenn die Technologie ausgereift ist Infrastruktur verbessert sich. Zusammen mit der Tatsache, dass nicht alle validators müssen beteiligt sein (z. B. nur die höchste). Für eine solche Aufgabe können abgesteckte validators herangezogen werden Die Grenzen dieses Mechanismus erstrecken sich einigermaßen gut. Unter der Annahme einer täglichen Rotation solcher validators (was (ziemlich konservativ – wöchentlich oder sogar monatlich können akzeptabel sein), dann die Kosten für die Wartung des Netzwerks diese Ethereum-Weiterleitungsbrücke wäre etwa 540.000 Gas pro Tag oder, bei den aktuellen Gaspreisen, 45 $ pro Jahr. Eine einfache Transaktion, die allein über die Brücke weitergeleitet wird, würde Kosten verursachen etwa 0,11 $; zusätzliche Vertragsberechnung würde kosten mehr natürlich. Durch Pufferung und Bündelung von Transaktionen Zusammengenommen können die Einbruchsgenehmigungskosten leicht betragen geteilt, wodurch die Kosten pro Transaktion erheblich gesenkt werden; wenn vor der Weiterleitung 20 Transaktionen erforderlich wären, dann Die Kosten für die Weiterleitung einer Basistransaktion würden auf sinken etwa 0,01 $. Eine interessante und kostengünstigere Alternative zu diesem Multisignatur-Vertragsmodell wäre die Verwendung von Schwellenwertsignaturen, um die multilaterale Eigentumssemantik zu erreichen. Während Schwellensignaturschemata für ECDSA sind rechenintensiv, diejenigen für andere Schemata wie Schnorr-Signaturen sind sehr vernünftig. Ethereum plant die Einführung von Grundelementen, die dies ermöglichen würden Schemata, die im kommenden Metropolis-Hardfork günstig zu verwenden sind. Wenn ein solches Mittel genutzt werden könnte, würden die Gaskosten sinken zur Weiterleitung einer Polkadot-Transaktion in den Ethereum Netzwerk würde dramatisch auf nahezu Null reduziert werden Gemeinkosten, die über die Grundkosten für die Validierung hinausgehen Unterschrift und Ausführung der zugrunde liegenden Transaktion. In diesem Modell hätten die validator-Knoten von Polkadot dies getan nichts anderes zu tun, als Nachrichten zu signieren. Damit die Transaktionen tatsächlich an das Netzwerk Ethereum weitergeleitet werden, haben wir Gehen Sie davon aus, dass sich auch die validators selbst dort befinden würden das Ethereum-Netzwerk oder, was wahrscheinlicher ist, kleine Kopfgelder dem ersten Akteur angeboten werden, der die Nachricht weiterleitet an das Netzwerk (das Kopfgeld könnte trivialerweise an das Netzwerk gezahlt werden). Urheber der Transaktion). 5.5.2. Ethereum bis Polkadot. Transaktionen durchführen Die Weiterleitung von Ethereum an Polkadot verwendet den einfachen Begriff der Protokolle. Wenn ein Ethereum-Vertrag eine Transaktion an eine bestimmte Parachain von Polkadot senden möchte, Es muss lediglich ein spezieller „Break-out-Vertrag“ abgeschlossen werden. Der Breakout-Vertrag würde jede mögliche Zahlung erfordern erforderlich sein und eine Protokollierungsanweisung erteilen, damit seine Existenz durch einen Merkle-Beweis und eine Behauptung, dass der Header des entsprechenden Blocks gültig ist, nachgewiesen werden kann kanonisch. Von den beiden letztgenannten Bedingungen ist die Gültigkeit möglicherweise die am einfachsten zu beweisen. Im Prinzip ist die einzige Voraussetzungfür jeden Polkadot-Knoten, der den Beweis benötigt (d. h. ernannte validator-Knoten), um eine vollständig synchronisierte Instanz eines Standard-Ethereum-Knotens auszuführen. Leider ist dies selbst eine ziemlich starke Abhängigkeit. Ein mehr Eine leichte Methode bestünde darin, einen einfachen Beweis dafür zu verwenden Der Header wurde korrekt ausgewertet, indem nur der angegeben wurde Ein Teil des Statusversuchs von Ethereum musste ordnungsgemäß ausgeführt werden Überprüfen Sie die Transaktionen im Block und prüfen Sie, ob die Protokolle (im Blockbeleg enthalten) gültig sind. Solche „SPV-ähnlichen“6 Beweise erfordern möglicherweise noch eine erhebliche Menge an Informationen; Praktischerweise werden sie normalerweise nicht benötigt alle: Ein Bindungssystem innerhalb von Polkadot würde Bindungen ermöglichen Dritte dürfen keine Header einreichen, auf die Gefahr hin, ihre Header zu verlieren Sollte ein anderer Dritter (z. B. ein „Fischer“, siehe 6.2.3) den Nachweis erbringen, dass der Header ungültig ist, kann die Bindung erfolgen (insbesondere, dass die Staatswurzel oder die Empfangswurzel Betrüger waren). In einem nicht finalisierenden PoW-Netzwerk wie Ethereum ist das Kanonizität lässt sich nicht schlüssig beweisen. Um dies zu beheben, versuchen Anwendungen, sich auf irgendeine Art zu verlassen Bei einer kettenabhängigen Ursache-Wirkungs-Beziehung warten Sie auf eine Reihe von „Bestätigungen“ oder bis die abhängige Transaktion eine bestimmte Anzahl von „Bestätigungen“ erreicht hat besondere Tiefe innerhalb der Kette. Am Ethereum, dies Die Tiefe variiert von 1 Block für die am wenigsten wertvollen Transaktionen ohne bekannte Netzwerkprobleme bis zu 1200 Blöcken wie bisher Dies war bei der ersten Frontier-Veröffentlichung für Börsen der Fall. Im stabilen „Homestead“-Netzwerk liegt diese Zahl bei 120 Blöcke für die meisten Börsen, und wir würden wahrscheinlich nehmen ein ähnlicher Parameter. Also wir kann Stell dir vor unsere Polkadot-Seite Ethereuminterface hat einige einfache Funktionen: um in der Lage zu sein Akzeptieren Sie einen neuen Header aus dem Netzwerk Ethereum und validieren Sie den PoW, um einen Beweis dafür akzeptieren zu können, dass a Ein bestimmtes Protokoll wurde vom Breakout-Vertrag auf der Ethereum-Seite für einen Header mit ausreichender Tiefe (und Weiterleitung) ausgegeben die entsprechende Nachricht innerhalb von Polkadot) und schließlich Beweise akzeptieren zu können, dass ein zuvor akzeptiertes aber Der noch nicht in Kraft gesetzte Header enthält einen ungültigen Empfangsstamm. Um tatsächlich die Header-Daten Ethereum selbst zu erhalten (und etwaige SPV-Beweise oder Gültigkeits-/Kanonizitätswiderlegungen) in das Netzwerk Polkadot, ein Anreiz zur Weiterleitung 6SPV bezieht sich auf „Simplified Payment Verification“ in Bitcoin und beschreibt eine Methode für Kunden, Transaktionen zu überprüfen und dabei nur Transaktionen zu überprüfen eine Kopie aller Blockheader der längsten PoW-Kette.POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 9 Daten benötigt werden. Dies kann so einfach sein wie eine Zahlung (finanziert aus den auf der Seite Ethereum erhobenen Gebühren) bezahlt an jeden, der einen nützlichen Block weiterleiten kann, dessen Header ist gültig. Um dies zu gewährleisten, müssten Validatoren Informationen zu den letzten paar tausend Blöcken aufbewahren in der Lage sein, Forks zu verwalten, entweder über protokollintrinsische Mittel oder über einen auf dem Server gepflegten Vertrag Relaiskette. 5.6. Polkadot und Bitcoin. Bitcoin Interoperation stellt für Polkadot eine interessante Herausforderung dar: ein sogenanntes „Zwei-Wege-Kopplung“ wäre ein nützliches Stück Infrastruktur auf der Seite beider Netzwerke zu haben. Allerdings aufgrund Die Einschränkungen von Bitcoin gelten für die sichere Bereitstellung eines solchen Stifts ein nicht triviales Unterfangen. Zustellung einer Transaktion von Bitcoin bis Polkadot kann im Prinzip mit einem ähnlichen Verfahren wie für Ethereum erfolgen; eine „Breakout-Adresse“ in irgendeiner Weise durch die Polkadot validators kontrolliert werden könnten Empfangen übertragener tokens (und zusammen mit ihnen gesendeter Daten). SPV-Nachweise könnten durch incentivierte oracles erbracht werden und, zusammen mit einer Bestätigungsfrist, einer Prämie für Identifizieren nicht-kanonischer Blöcke, die die Transaktion implizieren wurde „doppelt ausgegeben“. Alle tokens, die sich dann im Besitz befinden „Breakout-Adresse“ würde dann im Prinzip von denselben validators für eine spätere Verbreitung kontrolliert. Das Problem besteht jedoch darin, wie die Einzahlungen von einem rotierenden validator-Set aus sicher gesteuert werden können. Anders als Ethereum, das in der Lage ist, willkürliche Entscheidungen zu treffen Bei Kombinationen von Signaturen ist Bitcoin im Wesentlichen eingeschränkter, da die meisten Kunden nur Multisignatur-Transaktionen mit maximal drei Parteien akzeptieren. Eine Ausweitung auf 36 oder, wie letztlich gewünscht, sogar auf Tausende, ist nach dem aktuellen Protokoll nicht möglich. Eine Möglichkeit besteht darin, das Protokoll Bitcoin zu ändern, um es zu aktivieren Solche Funktionalitäten gibt es jedoch in sogenannten „Hard Forks“. Bitcoin Welt ist nach jüngsten Versuchen schwer zu arrangieren. Eine Möglichkeit ist die Verwendung von Schwellenwertsignaturen, kryptografische Schemata, um eine eindeutig identifizierbare Öffentlichkeit zu ermöglichen Schlüssel zur effektiven Kontrolle durch mehrere geheime „Teile“, Einige oder alle davon müssen verwendet werden, um eine gültige Signatur zu erstellen. Leider sind Schwellenwertsignaturen kompatibel mit Bitcoins ECDSA sind rechenintensiv erstellen und von polynomialer Komplexität. Andere Schemata wie z Eine Schnorr-Signatur bietet jedoch weitaus geringere Kosten Zeitplan, auf dem sie in die Bitcoin eingeführt werden können Protokoll ist unsicher. Denn die letztendliche Sicherheit der Einlagen liegt bei Eine weitere Möglichkeit besteht darin, eine Reihe gebundener validators zu verwenden Reduzieren Sie die Anzahl der Multi-Signatur-Schlüsselhalter nur stark gebundene Teilmenge der gesamten validators, so dass dieser Schwellenwert vorliegt Signaturen werden machbar (oder schlimmstenfalls Bitcoins native). Mehrfachsignatur ist möglich). Dies reduziert natürlich die Gesamtbetrag der Anleihen, die als Wiedergutmachung abgezogen werden könnten, falls sich die validators illegal verhalten, wie auch immer ist eine elegante Verschlechterung, bei der einfach eine Obergrenze von festgelegt wird die Höhe der Mittel, die sicher zwischen den fließen können zwei Netzwerke (oder tatsächlich, auf die prozentualen Verluste bei einem Angriff). aus den validators erfolgreich). Daher halten wir es für nicht unrealistisch, eine einigermaßen sichere Bitcoin Interoperabilität „virtuelle Parachain“ zu platzieren. zwischen den beiden Netzwerken, obwohl dennoch ein erheblicher Aufwand mit ungewissem Zeitplan und durchaus möglich ist Dies erfordert die Zusammenarbeit der Beteiligten Netzwerk.

Protokoll im Detail

Das Protokoll kann grob in drei Teile unterteilt werden Teile: der Konsensmechanismus, die Parachain-Schnittstelle und Interchain-Transaktionsrouting. 6.1. Relaiskette Betrieb. Die Relaiskette wird Wahrscheinlich handelt es sich dabei um eine Kette, die Ethereum weitgehend ähnelt ist bundesstaatsbasiert, wobei der Bundesstaat die Adresse dem Konto zuordnet Informationen, hauptsächlich Salden und (um Wiederholungen zu verhindern) a Transaktionszähler. Das Platzieren von Konten erfüllt hier einen Zweck: die Bereitstellung von Konten für diejenigen, die Identität besitzen Wie hoch ist der Anteil am System?7 Es wird jedoch bemerkenswerte Unterschiede geben: • Verträge können nicht über Transaktionen bereitgestellt werden. Aufgrund des Wunsches, Anwendungsfunktionalität auf der Relay-Kette zu vermeiden, wird dies nicht der Fall sein Unterstützung der öffentlichen Bereitstellung von Verträgen. • Die Nutzung von Rechenressourcen („Gas“) wird nicht berücksichtigt. da die einzigen Funktionen für die öffentliche Nutzung verfügbar sind behoben werden, das Grundprinzip der Gasabrechnung hält nicht mehr. Daher wird eine Pauschalgebühr erhoben in allen Fällen, sodass in jedem Fall mehr Leistung erzielt werden kann dynamische Codeausführung, die möglicherweise durchgeführt werden muss und ein einfacheres Transaktionsformat. • Für aufgelistete Verträge werden spezielle Funktionen unterstützt, die eine automatische Ausführung und Netzwerknachrichtenausgaben ermöglichen. Für den Fall, dass die Relay-Kette eine VM hat und es sein sollte Basierend auf EVM würde es eine Reihe von Modifikationen aufweisen, um maximale Einfachheit zu gewährleisten. Es wäre wahrscheinlich verfügen über eine Reihe integrierter Verträge (ähnlich denen bei Adressen 1-4 in Ethereum), um eine plattformspezifische Anpassung zu ermöglichen zu verwaltende Aufgaben einschließlich eines Konsensvertrags, a validator-Vertrag und ein Parachain-Vertrag. Wenn nicht EVM, dann ist ein WebAssembly-Backend [2] (wasm) die wahrscheinlichste Alternative. in diesem Fall das Gesamtbild Die Struktur wäre ähnlich, aber es wäre nicht nötig für die integrierten Verträge, wobei Wasm ein realisierbares Ziel ist eher für Allzwecksprachen als für unreife Sprachen und begrenzte Sprachen für EVM. Andere wahrscheinliche Abweichungen vom aktuellen Ethereum-Protokoll sind durchaus möglich, beispielsweise eine Vereinfachung des Transaktionsempfangsformat, das die parallele Ausführung nicht widersprüchlicher Transaktionen innerhalb desselben Blocks ermöglicht, wie für die Serenity-Änderungsreihe vorgeschlagen. Es ist möglich, wenn auch unwahrscheinlich, dass es Serenity-ähnlich ist Als Relay-Chain kann eine „reine“ Kette eingesetzt werden, die Folgendes ermöglicht: Besonderer Vertrag zur Verwaltung von Dingen wie staking token gleicht aus, anstatt dies zu einem grundlegenden Bestandteil zu machen das Protokoll der Kette. Dies halten wir derzeit für unwahrscheinlich wird eine ausreichend große Protokollvereinfachung bieten Die damit verbundene zusätzliche Komplexität und Unsicherheit lohnt sich bei der Entwicklung. 7Diese Stake-Konten sind ein Mittel zur Darstellung des Betrags, den ein bestimmter Inhaber für die Gesamtsicherheit des Systems verantwortlich macht unweigerlich einen wirtschaftlichen Wert verschlüsseln. Es sollte jedoch klar sein, dass keine Absicht besteht, solche Werte zu verwenden In irgendeiner Weise zum Zweck des Austauschs gegen reale Waren und Dienstleistungen sollte dementsprechend beachtet werden, dass die tokens nicht mit ihnen verglichen werden können Währung und als solche behält die Relay-Chain ihre nihilistische Philosophie in Bezug auf Anwendungen bei.POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 10 Für die Verwaltung des Konsensmechanismus, des validator-Sets, des Validierungsmechanismus und der Parachains sind eine Reihe kleinerer Funktionalitäten erforderlich. Diese könnten gemeinsam unter einem monolithischen Protokoll implementiert werden. Aus Gründen der Modularität bezeichnen wir diese jedoch als „Verträge“ der Relay-Chain. Das sollte so verstanden werden, dass sie Objekte sind (im Sinne von objektorientierte Programmierung), die vom Konsensmechanismus der Relaychain verwaltet wird, aber nicht unbedingt Sie werden als Programme in EVM-ähnlichen Opcodes definiert, noch sogar, dass sie durch das einzeln ansprechbar sind Kontosystem. 6.2. Absteckvertrag. Dieser Vertrag verwaltet den Satz validator. Es verwaltet: • Welche Konten sind derzeit validators; • die kurzfristig zu validators werden können bemerken; • auf welche Konten die Stake-Nominierung erfolgt ist ein validator; • Eigenschaften jedes einzelnen, einschließlich staking Volumen, akzeptable Auszahlungsraten und Adressen sowie kurzfristige (Sitzungs-)Identitäten. Es ermöglicht einem Konto, den Wunsch zu registrieren, ein zu werden gebundener validator (zusammen mit seinen Anforderungen), um sich für eine Identität zu nominieren und für bereits bestehende gebundene validators, ihren Wunsch zu registrieren, diesen Status zu verlassen. Es auch umfasst die Maschinerie selbst für den Validierungs- und Kanonisierungsmechanismus. 6.2.1. Stake-token Liquidität. Im Allgemeinen ist dies wünschenswert so viel wie möglich von den gesamten staking tokens haben seitdem an den Netzwerkwartungsarbeiten beteiligt Dies verknüpft die Netzwerksicherheit direkt mit der gesamten „Marktkapitalisierung“ des staking token. Dies kann problemlos erfolgen Anreize geschaffen werden, indem die Währung aufgebläht wird und der Erlös an diejenigen ausgeschüttet wird, die als validators teilnehmen. Allerdings stellt dies ein Problem dar: Wenn der token im Einsatzvertrag unter Strafe der Kürzung festgeschrieben ist, wie kann dann ein wesentlicher Anteil ausreichend bleiben? liquide sein, um eine Preisfindung zu ermöglichen? Eine Antwort hierauf besteht darin, einen einfachen Derivatkontrakt zu ermöglichen, der fungible tokens auf einem zugrunde liegenden, abgesteckten token sichert. Dies lässt sich nur schwer vertrauensfrei regeln. Darüber hinaus können diese derivativen tokens nicht gleich behandelt werden, und zwar aus demselben Grund, aus dem die Staatsanleihen verschiedener Eurozonen-Staatsanleihen nicht fungibel sind: dort besteht die Möglichkeit, dass der zugrunde liegende Vermögenswert versagt und wird wertlos. Bei den Regierungen der Eurozone könnte es eine geben Standard. Mit validator-abgesteckten tokens können die validator böswillig handeln und bestraft werden. Im Einklang mit unseren Grundsätzen entscheiden wir uns für die einfachste Lösung: Es werden nicht alle tokens abgesteckt. Das würde das bedeuten Ein gewisser Anteil (vielleicht 20 %) der tokens wird zwangsweise liquide bleiben. Obwohl dies aus sicherheitstechnischer Sicht unvollkommen ist, ist es unwahrscheinlich, dass es einen grundlegenden Unterschied macht die Sicherheit des Netzwerks; 80 % der durch Anleihebeschlagnahmungen möglichen Wiedergutmachung könnten noch geleistet werden im Vergleich zum „perfekten Fall“ von 100 % staking. Das Verhältnis zwischen eingesetzten und liquiden tokens kann relativ einfach durch einen umgekehrten Auktionsmechanismus gesteuert werden. Im Wesentlichen sind token-Inhaber daran interessiert, ein validator zu werden. würde jeweils ein Angebot für den staking-Vertrag veröffentlichen, in dem es heißt: die Mindestauszahlungsrate, die sie in Anspruch nehmen müssten Teil. Zu Beginn jeder Sitzung (Sitzungen würden passieren regelmäßig, vielleicht sogar einmal pro Stunde validator Slots würden je nach Interessenten besetzt Einsatz und Auszahlungsrate von validator. Ein möglicher Algorithmus denn das würde bedeuten, diejenigen mit den niedrigsten Angeboten anzunehmen einen Einsatz darstellen, der nicht höher ist als der angestrebte Gesamteinsatz dividiert durch die Anzahl der Slots und nicht weniger als die Untergrenze der Hälfte dieses Betrags. Wenn die Plätze nicht besetzt werden können, Die Untergrenze könnte wiederholt um einen Faktor verringert werden, um die Anforderungen zu erfüllen. 6.2.2. Nominierung. Es ist möglich, ohne Vertrauen zu nominieren diejenigen staking tokens zu einem aktiven validator und geben ihnen die Verantwortung für die Aufgaben von validators. Nominierung von Werken durch ein Zustimmungs-Abstimmungssystem. Jeder potenzielle Nominierende kann eine Anweisung zum staking-Vertrag veröffentlichen Ausdruck einer oder mehrerer validator Identitäten unter deren Verantwortung, die sie bereit sind, ihrer Bindung anzuvertrauen. In jeder Sitzung werden die Anleihen der Nominierenden verteilt dargestellt durch einen oder mehrere validators. Der Streuungsalgorithmus optimiert für einen Satz von validators gleicher Gesamtzahl Anleihen. Die Anleihen der Nominierenden unterliegen der tatsächlichen Verantwortung des validator aund Interesse gewinnen oder leiden Strafminderung entsprechend. 6.2.3. Beschlagnahmung/Verbrennung von Anleihen. Bestimmtes validator Verhalten führt zu einer Strafminderung ihrer Bindung. Wenn Die Anleihe wird unter das zulässige Minimum reduziert Die Sitzung wird vorzeitig beendet und eine neue gestartet. Eine nicht erschöpfende Liste strafbarer validator Fehlverhaltens umfasst: • Teil einer Parachain-Gruppe sein, die nicht in der Lage ist, etwas bereitzustellen Konsens über die Gültigkeit eines Parachain-Blocks; • aktiv für die Gültigkeit eines Invaliden unterschreiben Parachain-Block; • Unfähigkeit, Ausgangsnutzlasten bereitzustellen als verfügbar abgestimmt; • Inaktivität während des Konsensprozesses; • Validierung von Relay-Chain-Blöcken auf konkurrierenden Forks. Einige Fälle von Fehlverhalten gefährden die Integrität des Netzwerks (z. B. das Signieren ungültiger Parachain-Blöcke und die Validierung mehrerer Seiten eines Forks) und führen daher zu einem effektiven Exil durch die vollständige Reduzierung der Bindung. In andere, weniger schwerwiegende Fälle (z. B. Inaktivität im Konsens). Prozess) oder Fälle, in denen die Schuld nicht genau zugeordnet werden kann (Teil einer ineffektiven Gruppe), ein kleiner Teil Stattdessen kann eine Geldstrafe verhängt werden. Im letzteren Fall dies Funktioniert gut mit der Abwanderung von Untergruppen, um sicherzustellen, dass bösartige Knoten erleiden wesentlich mehr Verlust als die kollateralgeschädigten wohlwollenden Knoten. In einigen Fällen (z. B. Multi-Fork-Validierung und ungültig Unterblocksignierung) validators können das Fehlverhalten der anderen aufgrund der ständigen Überprüfung nicht einfach selbst erkennen eines jeden Parachain-Blocks wäre eine zu mühsame Aufgabe. Hier Es ist notwendig, die Unterstützung externer Parteien zu gewinnen den Validierungsprozess, um ein solches Fehlverhalten zu überprüfen und zu melden. Für die Meldung solcher Aktivitäten erhalten die Parteien eine Belohnung; Ihr Begriff „Fischer“ beruht auf der Unwahrscheinlichkeit einer solchen Belohnung. Da es sich in diesen Fällen typischerweise um sehr schwerwiegende Fälle handelt, gehen wir davon aus, dass etwaige Belohnungen problemlos aus der beschlagnahmten Kaution bezahlt werden können. Generell bevorzugen wir eine ausgeglichene Verbrennung (d. h. Reduktion auf nichts) mit Neuzuweisung, statt Versuch einer umfassenden Umverteilung. Dies hat die Wirkung

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 11 Erhöhen des Gesamtwerts von token, Kompensieren der Netzwerk im Allgemeinen bis zu einem gewissen Grad und nicht im Spezifischen an der Entdeckung beteiligte Partei. Dies dient vor allem der Sicherheit Mechanismus: Die großen Mengen, um die es geht, könnten zu extremen und akuten Verhaltensanreizen führen, wenn sie alle wären einem einzelnen Ziel verliehen. Im Allgemeinen ist es wichtig, dass die Belohnung groß genug ist, damit sich die Verifizierung für das Netzwerk lohnt, aber nicht so groß, dass sie die Kosten für die Bereitstellung eines Netzwerks ausgleicht gut finanzierter, gut orchestrierter Krimineller auf „industrieller Ebene“. Hackerangriff auf einen unglücklichen validator, um Fehlverhalten zu erzwingen. Auf diese Weise sollte der geforderte Betrag in der Regel Nein betragen größer als die direkte Bindung des fehlerhaften validator, damit a Es entsteht ein perverser Anreiz, sich schlecht zu benehmen und sich für das Kopfgeld zu melden. Dem kann entweder explizit entgegengewirkt werden durch eine Mindestanforderung an eine direkte Bindung, um ein zu sein validator oder implizit durch die Aufklärung der Nominatoren darüber, dass validators mit geringen hinterlegten Anleihen keinen großen Anreiz haben sich gut benehmen. 6.3. Parachain-Registrierung. Jede Parachain ist in definiert dieses Register. Es handelt sich um ein relativ einfaches datenbankähnliches Konstrukt, das sowohl statische als auch dynamische Informationen enthält jede Kette. Zu den statischen Informationen gehört der Kettenindex (ein einfacher ganze Zahl), zusammen mit der Validierungsprotokollidentität, a Mittel zur Unterscheidung zwischen den verschiedenen Klassen von Parachain, damit der richtige Validierungsalgorithmus gefunden werden kann wird von validators durchgeführt und hat die Aufgabe, einen gültigen Kandidaten vorzuschlagen. Ein erster Proof-of-Concept würde sich auf die Platzierung konzentrieren Die neuen Validierungsalgorithmen werden in die Clients selbst integriert, sodass jedes Mal ein Hard Fork des Protokolls erforderlich ist Zusätzliche Kettenklassen wurden hinzugefügt. Letztlich aber Möglicherweise kann der Validierungsalgorithmus in angegeben werden eine Art und Weise, die sowohl streng als auch effizient genug ist, dass Kunden es sind in der Lage, effektiv mit neuen Parachains zu arbeiten, ohne eine Hard-Fork. Ein möglicher Weg hierzu wäre die Spezifizierung der Parachain-Validierungsalgorithmus in einem etablierten, nativ kompilierte, plattformneutrale Sprache wie WebAssembly. Um dies festzustellen, sind zusätzliche Untersuchungen erforderlich Ob dies wirklich machbar ist, aber wenn ja, könnte es etwas bringen Damit verbunden ist der enorme Vorteil, Hard-Forks zu verbannen für immer. Dynamische Informationen umfassen Aspekte des Transaktionsroutingsystems, die eine globale Vereinbarung haben müssen, z als Eingangswarteschlange der Parachain (beschrieben in Abschnitt 6.6). Der Registry können nur Parachains hinzugefügt werden durch vollständige Abstimmung über das Referendum; das ließe sich bewerkstelligen intern, würde aber eher in einem externen platziert werden Referendumsvertrag, um die Weiterverwendung zu erleichtern allgemeinere Governance-Komponenten. Die Parameter zu Abstimmungsanforderungen (z. B. erforderliches Quorum, Mehrheit). erforderlich) zur Registrierung zusätzlicher Ketten und anderer, Weniger formelle Systemaktualisierungen werden in einem „Master“ dargelegt Verfassung“, werden aber wahrscheinlich einer ziemlich traditionellen Verfassung folgen Weg, zumindest zunächst. Die genaue Formulierung liegt uns nicht vor Spielraum für die vorliegende Arbeit, aber z.B. eine Zwei-Drittel-Supermehrheit mit mehr als einem Drittel des Gesamtsystems Eine positive Beteiligungsabstimmung kann ein sinnvoller Ausgangspunkt sein. Zu den weiteren Vorgängen gehört das Aufhängen und Entfernen von Fallschirmen. Eine Aussetzung würde es hoffentlich nie geben passieren, aber es soll zumindest als Schutz dienen Es gibt ein hartnäckiges Problem im Validierungssystem einer Parachain. Der offensichtlichste Fall, wo es sein könnte Erforderlich ist ein konsenskritischer Unterschied zwischen Implementierungen, der dazu führt, dass validators nicht in der Lage sind, sich darauf zu einigen Gültigkeit oder Sperren. Der Einsatz von Validatoren wird empfohlen mehrere Client-Implementierungen, damit sie in der Lage sind um ein solches Problem vor der Einziehung der Anleihe zu erkennen. Da es sich bei der Aussetzung um eine Notfallmaßnahme handelt, wäre dies der Fall unter der Schirmherrschaft des dynamischen validator-Votings statt als ein Referendum. Eine Wiedereinsetzung wäre bei beiden möglich aus den validators oder einem Referendum. Die vollständige Entfernung von Parachains wäre nur möglich nach einem Referendum und mit dem erforderlich wäre a erhebliche Schonfrist, um einen ordnungsgemäßen Übergang zu ermöglichen entweder eine eigenständige Kette oder um Teil einer anderen zu werden Konsenssystem. Die Schonfrist würde wahrscheinlich betragen Dies geschieht in der Reihenfolge von Monaten und wird wahrscheinlich pro Kette im Parachain-Register aufgeführt, damit dies anders ist Parachains können unterschiedliche Schonfristen genießen ihr Bedürfnis. 6.4. Relaisblöcke versiegeln. Unter Versiegelung versteht man im Wesentlichen zum Prozess der Kanonisierung; das heißt, Grunddaten welche umwandelnbildet das Original in etwas grundlegend Einzigartiges und Bedeutsames ab. Unter einer PoW-Kette, Versiegelung ist gewissermaßen ein Synonym für Bergbau. In unserem Fall, Dabei handelt es sich um die Sammlung signierter Aussagen von validators über die Gültigkeit, Verfügbarkeit und Kanonizität von a bestimmter Relay-Chain-Block und die Parachain blockiert diesen es repräsentiert. Die Mechanik des zugrunde liegenden Konsensalgorithmus BFT liegt außerhalb des Rahmens dieser Arbeit. Das werden wir Beschreiben Sie es stattdessen mit einem Grundelement, das a annimmt konsensschaffende Staatsmaschine. Letztlich erwarten wir sich von einer Reihe vielversprechender BFT Konsens inspirieren zu lassen Algorithmen im Kern; Tangaora [9] (eine BFT Variante von Raft [16]), Tendermint [11] und HoneyBadgerBFT [14]. Der Algorithmus muss eine Einigung über mehrere Parachains parallel erzielen und unterscheidet sich somit vom Üblichen blockchain Konsensmechanismen. Wir gehen davon einmal aus Sobald ein Konsens erreicht ist, können wir den Konsens aufzeichnen in einem unwiderlegbaren Beweis, der von jedem erbracht werden kann die Teilnehmer dazu. Auch wir gehen von Fehlverhalten aus innerhalb des Protokolls kann generell auf ein kleines Maß reduziert werden Gruppe mit Teilnehmern, die sich schlecht benehmen, sollte minimiert werden der Kollateralschaden bei der Strafzumessung.8 Der Beweis, der die Form unserer signierten Aussagen annimmt, wird zusammen im Header des Relay-Chain-Blocks platziert mit bestimmten anderen Feldern, nicht zuletzt dem Statetrie-Root und dem Transaction-Trie-Root der Relay-Kette. Die Versiegelung Prozess dauert Ort unter a Single konsensgenerierend Mechanismus Adressierung beides die Der Block der Relay-Chain und die Blöcke der Parachains, die machen Teil des Inhalts des Relays: Parachains werden von ihren Untergruppen nicht separat „festgeschrieben“ und dann zusammengestellt später. Dies führt zu einem komplexeren Prozess für die Relaychain, ermöglicht es uns aber, den Konsens des gesamten Systems in einer einzigen Phase zu vervollständigen, wodurch die Latenz minimiert und ermöglicht wird für recht komplexe Datenverfügbarkeitsanforderungen hilfreich für den Routing-Prozess unten. 8Bestehende PoS-basierte BFT-Konsensschemata wie Tendermint BFT und der ursprüngliche Slasher erfüllen diese Behauptungen.

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 12 Der Zustand der Konsensmaschine jedes Teilnehmers kann sein als einfache (zweidimensionale) Tabelle modelliert werden. Jeder Teilnehmer (validator) verfügt über eine Reihe von Informationen im Formular von unterzeichneten Erklärungen („Stimmen“) anderer Teilnehmer zu jedem Parachain-Block-Kandidaten sowie zum Relaychain-Block-Kandidaten. Der Informationssatz besteht aus zwei Teilen der Daten: Verfügbarkeit: tut dies validator habe Ausgang Transaktions-Post-Informationen aus diesem Block also Sind sie in der Lage, Parachain-Kandidaten im folgenden Block ordnungsgemäß zu validieren? Sie dürfen abstimmen entweder 1 (bekannt) oder 0 (noch nicht bekannt). Sobald sie Stimme 1, sie sind entschlossen, in ähnlicher Weise dafür zu stimmen der Rest dieses Prozesses. Spätere Abstimmungen, bei denen dies nicht der Fall ist Respekt, das ist ein Strafgrund. Gültigkeit: Ist der Parachain-Block gültig und ist alles? extern referenzierte Daten (z.B. Transaktionen) verfügbar? Dies ist nur für validators relevant, die der Parachain zugeordnet sind, über die sie abstimmen. Sie können entweder mit 1 (gültig), -1 (ungültig) oder 0 stimmen (noch nicht bekannt). Sobald sie ungleich Null stimmen, sind sie sind entschlossen, für den Rest auf diese Weise abzustimmen der Prozess. Spätere Abstimmungen, die dies nicht respektieren sind Strafgründe. Alle validators müssen Stimmen abgeben; Abstimmungen können unter Einhaltung der oben genannten Regeln erneut eingereicht werden. Der Fortschritt von Der Konsens kann als mehrere Standardkonsensalgorithmen über jede Parachain modelliert werden, die parallel stattfinden. Da diese möglicherweise durch eine relativ vereitelt werden Eine kleine Minderheit böswilliger Akteure konzentriert sich darauf Es besteht allgemeiner Konsens darüber, dass es sich um eine einzelne Parachain-Gruppe handelt Richten Sie eine Rücksicherung ein, um das Worst-Case-Szenario einzudämmen Deadlock zu lediglich einem oder mehreren ungültigen Parachain-Blöcken (und eine Runde der Bestrafung der Verantwortlichen). Die Grundregeln für die Gültigkeit der einzelnen Blöcke (Damit kann die Gesamtmenge der validators als Ganzes erreicht werden Konsens darüber, dass es der einzigartige Parachain-Kandidat wird vom kanonischen Relay referenziert werden): • Es müssen mindestens zwei Drittel der validators positiv und keines davon negativ stimmen; • Es muss mehr als ein Drittel der validators geben, die positiv über die Verfügbarkeit von Informationen zur Ausgangswarteschlange stimmen. Gibt es mindestens ein positives und mindestens ein negatives Votum zur Gültigkeit, entsteht eine Ausnahmebedingung und die gesamte Gruppe von validators muss abstimmen, um zu entscheiden wenn es böswillige Parteien gibt oder wenn ein Unfall vorliegt Gabel. Neben gültigen und ungültigen Stimmen gibt es noch eine dritte Art von Stimmen sind erlaubt, gleichbedeutend damit, für beide zu stimmen, was bedeutet, dass Der Knoten hat widersprüchliche Meinungen. Dies könnte daran liegen Der Eigentümer des Knotens führt mehrere Implementierungen aus, die dies tun nicht einverstanden, was auf eine mögliche Unklarheit im Protokoll hinweist. Nachdem alle Stimmen aus dem gesamten validator-Satz gezählt wurden, wenn die unterlegene Meinung hat zumindest einen kleinen Anteil (zu parametrisiert sein; höchstens die Hälfte, vielleicht deutlich weniger) der Stimmen der siegreichen Meinung, dann wird davon ausgegangen Wenn es sich um eine versehentliche Parachain-Gabel handelt, wird die Parachain automatisch vom Konsensprozess ausgeschlossen. Andernfalls gehen wir davon aus, dass es sich um eine böswillige Handlung handelt und ahnden diese Minderheit, die für die abweichende Meinung stimmte. Den Abschluss bildet eine Reihe demonstrierender Unterschriften Kanonizität. Anschließend kann der Relaiskettenblock versiegelt werden und der Prozess der Versiegelung des nächsten Blocks begann. 6.5. Verbesserungen beim Versiegeln von Relaisblöcken. Während Diese Dichtungsmethode bietet starke Garantien für den Systembetrieb, sie lässt sich jedoch nicht besonders gut skalieren da die Schlüsselinformationen jeder Parachain ihre eigenen haben müssen Verfügbarkeit garantiert von über einem Drittel aller validators. Dies bedeutet, dass der Verantwortungs-Fußabdruck jedes validator wächst, wenn weitere Ketten hinzugefügt werden. Während Datenverfügbarkeit innerhalb offener Konsensnetzwerke Da es sich im Wesentlichen um ein ungelöstes Problem handelt, gibt es Möglichkeiten, den Overhead für validator-Knoten zu verringern. Eine einfache Die Lösung besteht darin, zu erkennen, dass validators zwar schultern müssen Obwohl sie die Verantwortung für die Datenverfügbarkeit tragen, müssen sie die Daten nicht selbst speichern, kommunizieren oder replizieren. Sekundäre Datensilos, möglicherweise im Zusammenhang mit (oder sogar im selben Zusammenhang). (gleiche) Erfasser, die diese Daten zusammenstellen, dürfen die verwalten Die Aufgabe besteht darin, die Verfügbarkeit zu gewährleisten, wobei die validators einen Teil ihrer Zinsen/Einnahmen als Zahlung leisten. Obwohl dies zwar eine gewisse mittlere Skalierbarkeit erkaufen könnte, löst es das zugrunde liegende Problem jedoch nicht. seitdem Das Hinzufügen weiterer Ketten erfordert im Allgemeinen zusätzliche validators, der laufende Netzwerkressourcenverbrauch (insbesondere in Bezug auf die Bandbreite) wächst mit dem Quadrat von dieKetten, eine auf Dauer unhaltbare Eigenschaft. Letztendlich werden wir uns wahrscheinlich weiterhin den Kopf zerbrechen gegen die grundlegende Einschränkung, die das besagt Ein Konsensnetzwerk gilt als verfügbar und sicher Der laufende Bandbreitenbedarf liegt in der Größenordnung von insgesamt validators mal die gesamten Eingabeinformationen. Das liegt daran die Unfähigkeit eines nicht vertrauenswürdigen Netzwerks, die Aufgabe der Datenspeicherung ordnungsgemäß auf viele Knoten zu verteilen, die sitzen abgesehen von der eminent verteilbaren Aufgabe der Verarbeitung. 6.5.1. Einführung in die Latenz. Eine Möglichkeit, dies abzumildern Die Regel besteht darin, den Begriff der Unmittelbarkeit zu lockern. Indem wir verlangen, dass 33 %+1 validators nur irgendwann und nicht sofort für die Verfügbarkeit stimmen, können wir die exponentielle Datenausbreitung besser nutzen und dazu beitragen, Spitzen beim Datenaustausch auszugleichen. Eine vernünftige Gleichheit (wenn auch unbewiesen) kann sein: (1) Latenz = Teilnehmer × Ketten Unter dem aktuellen Modell skaliert die Größe des Systems mit der Anzahl der Ketten, um sicherzustellen, dass die Verarbeitung erfolgt verteilt; da jede Kette mindestens einen validator benötigt und wir den Verfügbarkeitsnachweis auf eine Konstante festlegen Anteil von validators, dann wächst die Zahl der Teilnehmer ebenfalls mit der Anzahl der Ketten. Am Ende haben wir: (2) Latenz = Größe2 Das heißt, wenn das System wächst, sind die erforderliche Bandbreite und die Latenz bis zur Verfügbarkeit überall bekannt Netzwerk, das auch als Nummer bezeichnet werden könnte der Blöcke vor der Endgültigkeit, wächst mit seinem Quadrat. Das ist Es ist ein erheblicher Wachstumsfaktor und könnte sich als erhebliches Hindernis erweisen und uns in „nicht flache“ Paradigmen zwingen wie zum Beispiel das Zusammenstellen mehrerer „Polkadotes“ in einer Hierarchie für die mehrstufige Weiterleitung von Posts durch einen Baum von Relaychains.

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 13 6.5.2. Öffentlichkeitsbeteiligung. Eine weitere mögliche Richtung ist die Einbeziehung der Öffentlichkeit in den Prozess durch a Mikro-Beschwerdesystem. Ähnlich wie die Fischer dort könnten externe Parteien sein, die die validators überwachen, die Ansprüche geltend machen Verfügbarkeit. Ihre Aufgabe besteht darin, jemanden zu finden, der offenbar nicht in der Lage ist, eine solche Verfügbarkeit nachzuweisen. Dabei tun sie kann eine Mikrobeschwerde bei anderen validators einreichen. PoW oder Eine abgesteckte Anleihe kann verwendet werden, um den Sybil-Angriff abzuschwächen was das System weitgehend unbrauchbar machen würde. 6.5.3. Verfügbarkeitsgarantien. Ein letzter Weg wäre Nominieren Sie einen zweiten Satz gebundener validators als „Verfügbarkeit“. Bürgen“. Diese werden wie die normalen validators verklebt und können sogar aus demselben Set stammen (In diesem Fall würden sie jedoch über einen langfristigen Zeitraum ausgewählt, zumindest pro Sitzung). Im Gegensatz zu normalen validators sind sie würde nicht zwischen Parachains wechseln, sondern eher Bilden Sie eine einzige Gruppe, um die Verfügbarkeit aller wichtigen Interchain-Daten zu bestätigen. Dies hat den Vorteil, dass die Äquivalenz zwischen Teilnehmern und Ketten gelockert wird. Im Wesentlichen können Ketten wachsen (zusammen mit der ursprünglichen Kette validator gesetzt), wohingegen Die Teilnehmer, und insbesondere diejenigen, die am Test zur Datenverfügbarkeit teilnehmen, können zumindest sublinear bleiben und möglicherweise konstant. 6.5.4. Collator-Einstellungen. Ein wichtiger Aspekt dabei Das System besteht darin, sicherzustellen, dass es eine gesunde Auswahl gibt Collatoren, die die Blöcke in einer beliebigen Parachain erstellen. Wenn ein Ein einzelner Collator dominierte eine Parachain und dann einige Angriffe machbarer werden, da die Wahrscheinlichkeit des Mangels an Die Verfügbarkeit externer Daten wäre weniger offensichtlich. Eine Möglichkeit besteht darin, Parachain-Blöcke künstlich zu beschweren ein pseudozufälliger Mechanismus, um eine große Vielfalt an Collatoren zu begünstigen. Im ersten Fall würden wir verlangen als Teil des Konsensmechanismus, den validators bevorzugen Parachain-Block-Kandidaten gelten als „schwerer“. Ebenso müssen wir validators dazu anregen, es zu versuchen Schlagen Sie den schwersten Block vor, den sie finden können – das könnte sein Dies geschieht, indem ein Teil ihrer Belohnung proportional zum Gewicht ihres Kandidaten gemacht wird. Um sicherzustellen, dass den Zusammenstellern eine angemessene Fairness geboten wird Chance, dass ihr Kandidat als Sieger ausgewählt wird Kandidaten im Konsens, wir machen das spezifische Gewicht von a Parachain-Blockkandidaten bestimmen anhand einer Zufallsfunktion, die mit jedem Collator verbunden ist. Zum Beispiel nehmen das XOR-Abstandsmaß zwischen der Adresse des Sortierers und eine kryptografisch sichere Pseudozufallszahl nahe dem Punkt des zu erstellenden Blocks bestimmt (ein fiktives „Gewinnticket“). Dies gibt effektiv jedem Zusammensteller (oder genauer gesagt die Adresse jedes Zusammenstellers) a zufällige Chance, dass ihr Kandidatenblock „siegt“. alle anderen. Um den Sybil-Angriff eines einzelnen Collators abzuschwächen, der eine Adresse in der Nähe des Gewinnscheins „schürft“ und sich somit befindet Wenn wir jeden Block zu einem Favoriten machen, fügen wir der Adresse eines Collators etwas Trägheit hinzu. Das kann so einfach sein, wie sie zu verlangen um einen Grundbetrag an Mitteln in der Adresse zu haben. Ein mehr Ein eleganter Ansatz wäre es, die Nähe zum zu gewichten Gewinnschein mit dem auf dem geparkten Geldbetrag Adresse in Frage. Während die Modellierung noch aussteht, Es ist durchaus möglich, dass dieser Mechanismus sogar sehr viel ermöglicht kleine Stakeholder, die als Zusammensteller mitwirken können. 6.5.5. Übergewichtige Blockaden. Wenn ein validator-Set kompromittiert ist, können sie einen Block erstellen und vorschlagen, der jedoch funktioniert gültig, die Ausführung nimmt übermäßig viel Zeit in Anspruch und validieren. Dies ist ein Problem, da eine validator-Gruppe dies könnte vernünftigerweise einen Block bilden, dessen Herstellung sehr lange dauert ausführen, es sei denn, eine bestimmte Information ist bereits bekannt und ermöglicht eine Abkürzung, z. B. Faktorisierung eines großen Primzahl. Wenn ein einzelner Zusammensteller diese Informationen wüsste, dann Sie hätten einen klaren Vorteil, wenn sie ihre eigenen bekämen Kandidaten nahmen an, solange die anderen mit der Bearbeitung des alten Blocks beschäftigt waren. Wir nennen diese Blöcke Übergewicht. Der Schutz vor der Übermittlung und Validierung dieser Blöcke durch validators erfolgt größtenteils unter dem gleichen Deckmantel wie für ungültige Blöcke, jedoch mit einer zusätzlichen Einschränkung: Da die Zeit, die zum Ausführen eines Blocks benötigt wird (und damit sein Status als). Übergewicht) ist subjektiv, das Endergebnis einer Abstimmung Fehlverhalten lässt sich im Wesentlichen in drei Lager einteilen. Eins Es besteht die Möglichkeit, dass der Block definitiv nicht übergewichtig ist. in diesem Fall erklären mehr als zwei Drittel, dass sie es könnten Führen Sie den Block innerhalb einer bestimmten Grenze aus (z. B. 50 % der zwischen den Blöcken zulässigen Gesamtzeit). Ein weiterer Grund ist, dass die Block ist ddefinitiv übergewichtig – das wäre, wenn mehr als Zwei Drittel erklären, dass sie den Block nicht ausführen konnten innerhalb dieser Grenze. Eine letzte Möglichkeit ist eine ziemlich gleiche Meinungsverschiedenheit zwischen validators. In diesem Fall können wir sich dafür entscheiden, eine angemessene Strafe zu verhängen. Um sicherzustellen, dass validators vorhersagen können, wann dies der Fall sein wird Wenn Sie einen übergewichteten Block vorschlagen, kann es sinnvoll sein, von ihnen zu verlangen, dass sie Informationen über ihre eigene Leistung für jeden Block veröffentlichen. Über einen ausreichenden Zeitraum hinweg Dies sollte es ihnen ermöglichen, ihre Verarbeitungsgeschwindigkeit zu profilieren im Vergleich zu den Kollegen, die sie beurteilen würden. 6.5.6. Collator-Versicherung. Ein Problem bleibt für validators bestehen: Anders als bei PoW-Netzwerken, um die eines Collators zu überprüfen Um die Gültigkeit eines Blocks zu gewährleisten, müssen sie die darin enthaltenen Transaktionen tatsächlich ausführen. Böswillige Sortierer können ungültige oder übergewichtige Blöcke an validators weiterleiten, was ihnen Kummer (Verschwendung) bereitet ihre Ressourcen) und möglicherweise erhebliche Opportunitätskosten verursachen. Um dies zu mildern, schlagen wir eine einfache Strategie vor Teil von validators. Zunächst werden Kandidaten für den Parachain-Block gesendet bis validators müssen von einem Relay-Chain-Konto signiert werden mit Mitteln; Ist dies nicht der Fall, sollte validator gelöscht werden es sofort. Zweitens sollten solche Kandidaten durch eine Kombination (z. B. Multiplikation) von priorisiert werden der Betrag des Guthabens auf dem Konto bis zu einer gewissen Obergrenze, die Anzahl der vorherigen Blöcke, die der Collator in der Vergangenheit erfolgreich vorgeschlagen hat (ganz zu schweigen von den vorherigen). Strafen) und der Nähefaktor zum Gewinner Ticket wie zuvor besprochen. Die Kappe sollte gleich sein als Strafschadenersatz, der in diesem Fall an validator gezahlt wurde von ihnen sendet einen ungültigen Block. Um Sortierer davon abzuhalten, ungültige oder übergewichtige Blockkandidaten an validators zu senden, kann jeder validator dies tun Platzieren Sie im nächsten Block eine Transaktion, einschließlich des beleidigenden Blocks, in dem ein Fehlverhalten behauptet wird, mit der Folge, dass einige oder alle Gelder in den sich schlecht benehmenden Zusammensteller übertragen werden Konto an den Geschädigten validator. Diese Art von Transaktion geht allen anderen voraus, um sicherzustellen, dass der Collator dies nicht kann Entfernen Sie die Gelder vor der Bestrafung. Die Menge an Die Höhe der als Schadensersatz überwiesenen Gelder ist noch ein dynamischer Parameter

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 14 muss modelliert werden, wird aber wahrscheinlich ein Teil der Blockbelohnung validator sein, um das Ausmaß der verursachten Trauer widerzuspiegeln. Zu Um zu verhindern, dass böswillige validators die Gelder der Sammler willkürlich beschlagnahmen, kann der Sammler im Gegenzug bei einer Jury aus zufällig ausgewählten validators gegen die Entscheidung des validator Berufung einlegen für die Hinterlegung einer kleinen Anzahlung. Wenn sie zugunsten des validator entscheiden, wird die Kaution von ihnen verbraucht. Wenn nicht, wird die Die Kaution wird zurückerstattet und der validator wird mit einer Geldstrafe belegt (da der validator ist in einer viel gewölbteren Position, der feine Wille wahrscheinlich ziemlich heftig sein). 6.6. Interchain Transaktion Routenführung. Interchain Das Transaktionsrouting ist eine der wesentlichen Wartungsarbeiten Aufgaben der Relay-Chain und ihrer validators. Das ist das Logik, die regelt, wie eine gebuchte Transaktion (oft mit einfach „Buchung“ abgekürzt) zu einer gewünschten Ausgabe wird von einer Quell-Parachain zu einem nicht verhandelbaren Input einer anderen Ziel-Parachain ohne jegliches Vertrauen Anforderungen. Wir wählen die obige Formulierung sorgfältig aus; vor allem wir Es ist nicht erforderlich, dass in der Quelle eine Transaktion stattgefunden hat Parachain hat diesen Beitrag ausdrücklich genehmigt. Der Einzige Die Einschränkungen, die wir unserem Modell auferlegen, sind Parachains bereitgestellt werden müssen, verpackt als Teil ihres Gesamtblocks Verarbeitungsausgabe, die Beiträge, die das Ergebnis der sind Blockausführung. Diese Posts sind als mehrere FIFO-Warteschlangen strukturiert; die Die Anzahl der Listen wird als Routing-Basis bezeichnet und kann sein etwa 16. Bemerkenswert ist, dass diese Zahl die Menge darstellt von Parachains, die wir unterstützen können, ohne darauf zurückgreifen zu müssen Mehrphasen-Routing. Zunächst wird Polkadot dies unterstützen Art der direkten Weiterleitung, wir werden jedoch eine Möglichkeit skizzieren Mehrphasen-Routing-Verfahren („Hyper-Routing“) als Mittel der Skalierung weit über den anfänglichen Satz von Parachains hinaus. Wir annehmen das alle Teilnehmer wissen die Untergruppierungen für die nächsten beiden Blöcke n, n + 1. Zusammenfassend lässt sich sagen, dass die Das Routing-System folgt diesen Schritten: • CollatorS: Kontaktieren Sie Mitglieder von V alidators[n][S] • CollatorS: FÜR JEDE Untergruppe: Stellen Sie sicher, dass at Mindestens 1 Mitglied von Validators[n][s] in Kontakt • Sortierer: FÜR JEDE Untergruppe s: annehmen egress[n −1][s][S] ist verfügbar (alle eingehenden Beiträge). Daten an „S“ vom letzten Block) • Sortierer: Verfassen Sie den Blockkandidaten b für S: (b.header, b.ext, b.proof, b.receipt, b.egress) • Sortierer: Senden Beweis Informationen Beweis[S] = (b.header, b.ext, b.proof, b.receipt) zu Validatoren[n][S] • CollatorS: Sicherstellung externer Transaktionsdaten b.ext wird anderen Sortierern und validators zur Verfügung gestellt • Sortierer: FÜR JEDER Untergruppe s: Senden Ausgang Informationen Ausgang[n][S][s] = (b.header, b.receipt, b.egress[s]) zu die Empfangen Untergruppen Mitglieder von als nächstes blockieren Validatoren[n + 1][s] • ValidatorV: Alle Mitglieder derselben Gruppe vorab verbinden für den nächsten Block: sei N = Chain[n + 1][V ]; verbinden alle validators v so dass Chain[n + 1][v] = N • ValidatorV: Sammeln Sie dazu alle eingehenden Daten Block: FÜR JEDER Untergruppe s: Abrufen egress[n −1][s][Chain[n][V ]], erhalte von anderen validators v, so dass Chain[n][v] = Chain[n][V ]. Möglicherweise werden zufällig ausgewählte andere validators zum Nachweis des Versuchs herangezogen. • ValidatorV: Akzeptieren Sie hierfür Kandidatennachweise Blockbeweis[Kette[n][V ]]. Gültigkeit des Abstimmungsblocks • ValidatorV: Akzeptieren Sie die Ausgangsdaten des Kandidaten für nächster Block: Akzeptieren Sie für jede Untergruppe Ausgang[n][s][N]. Verfügbarkeit von Vote-Block-Ausgangsdaten; unter interessierten validators erneut veröffentlichen v so dass Kette[n + 1][v] = Kette[n + 1][V ]. • V alidatorV: BIS ZUM KONSENS Wobei: egress[n][from][to] die aktuelle Ausgangswarteschlange ist Informationen für Beiträge, die von Parachain „von“ zu „gehen“. Parachain „to“ in Blocknummer „n“. CollatorS ist ein Collator für Parachain S. V alidators[n][s] ist die Menge von validators für Parachain s bei Blocknummer n. Umgekehrt, Chain[n][v] ist die Parachain, der validator v im Block Nummer n zugewiesen ist. block.egress[to] ist der Ausgang Warteschlange mit Beiträgen von einem Parachain-Blockblock, dessen Ziel Parachain ist. Da Collators (Transaktions-)Gebühren auf der Grundlage von erheben Ihre Blöcke werden kanonisch, zu denen sie einen Anreiz haben Stellen Sie sicher, dass für jedes nächste Blockziel die Untergruppe Mitglieder werden ab sofort über die Ausgangswarteschlange informiert blockieren. Validatoren werden nur dazu angeregt, einen Konsens über einen (Parachain-)Block zu erzielen, und kümmern sich daher wenig darum welcher Collator-Block letztendlich kanonisch wird. In Prinzipiell könnte ein validator eine Allianz mit einem Sammler eingehen und sich verschwören, um die Chancen anderer Sammler zu verringern. Blöcke werden kanonisch, aber das ist beides schwierig aufgrund der Zufallsauswahl zu arrangierenFunktion von validators für Parachains und könnten mit einer Reduzierung der Gebühren für Parachain-Blöcke, die sich halten, abgewehrt werden der Konsensprozess. 6.6.1. Externe Datenverfügbarkeit. Sicherstellung eines Fallschirms Die Frage, ob externe Daten tatsächlich verfügbar sind, ist ein Dauerproblem dezentrale Systeme, die darauf abzielen, die Arbeitslast zu verteilen das Netzwerk. Im Kern geht es um die Verfügbarkeit Problem, das besagt, dass dies nicht möglich ist Erstellen Sie einen nicht interaktiven Verfügbarkeitsnachweis noch irgendeiner Art des Nachweises der Nichtverfügbarkeit, damit ein BFT-System ordnungsgemäß funktioniert Validieren Sie jeden Übergang, dessen Richtigkeit davon abhängt Verfügbarkeit einiger externer Daten, die maximale Anzahl von akzeptablen byzantinischen Knoten plus einem des Systems muss bescheinigen, dass die Daten verfügbar sind. Damit ein System wie Polkadot ordnungsgemäß skaliert werden kann, ist Folgendes erforderlich Lädt ein Problem ein: wenn ein konstanter Anteil von validators muss die Verfügbarkeit der Daten bescheinigen und davon ausgehen dass validators die Daten tatsächlich speichern wollen, bevor sie behaupten, dass sie verfügbar sind, wie können wir das dann vermeiden? Problem, dass der Bandbreiten-/Speicherbedarf mit der Systemgröße (und damit der Anzahl der validators) zunimmt? Eine mögliche Antwort wäre ein separates Set von validators (Verfügbarkeitsgaranten), deren Bestellung wächst sublinear mit der Größe von Polkadot als Ganzes. Das ist beschrieben in 6.5.3. Wir haben auch einen sekundären Trick. Als Gruppe haben die Zusammensteller einen intrinsischen Anreiz, dafür zu sorgen, dass alle Daten vorhanden sind verfügbar für ihre gewählte Parachain, da sie ohne diese sind nicht in der Lage, weitere Blöcke zu erstellen, aus denen sie können Transaktionsgebühren erheben. Auch die Zusammensteller bilden eine Gruppe, deren Mitgliederzahl unterschiedlich ist (aufgrund der Zufälligkeit). Parachain validator Gruppen) nicht trivial und einfach einzugeben

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 15 zu beweisen. Aktuelle Collatoren (vielleicht der letzten paar tausend Blöcke) dürfen daher Herausforderungen an stellen die Verfügbarkeit externer Daten für eine bestimmte Parachain Block an validators für eine kleine Kaution. Validatoren müssen diejenigen aus der offensichtlich beleidigenden validator-Untergruppe kontaktieren, die ausgesagt haben, und entweder die Daten beschaffen und an den Ermittler zurücksenden oder die Sache eskalieren Sachverhalt durch Aussage über die mangelnde Verfügbarkeit (die direkte Weigerung, die Daten bereitzustellen, gilt als Straftat zur Beschlagnahmung von Anleihen, daher wird der sich schlecht benehmende validator wahrscheinlich gerechtfertigt sein). Trennen Sie die Verbindung) und kontaktieren Sie weitere validators um den gleichen Test durchzuführen. Im letzteren Fall die Bürgschaft des Gläubigers wird zurückgegeben. Sobald ein Quorum von validators erreicht ist, die solche Nichtverfügbarkeitszeugnisse abgeben können, werden sie freigelassen Eine sich schlecht benehmende Untergruppe wird bestraft und die Sperre aufgehoben. 6.6.2. Weiterleitung von Beiträgen. Jeder Parachain-Header enthält eine Egress-Trie-Root; Dies ist die Wurzel eines Versuchs, der das enthält Routing-basierte Bins, wobei jede Bin eine verkettete Liste ist von Egress-Posts. Merkle-Beweise können quer vorgelegt werden Parachain validators, um zu beweisen, dass es sich um eine bestimmte Parachain handelt Der Block hatte eine bestimmte Ausgangswarteschlange für eine bestimmte Zielparachain. Zu Beginn der Verarbeitung jeweils ein Parachain-Block Die Ausgangswarteschlange einer anderen Parachain ist für diesen Block bestimmt in die Eingangswarteschlange unseres Blocks eingefügt. Wir gehen von starken, wahrscheinlich CSPR9, Unterblockreihenfolge, um eine deterministische Operation zu erreichen, die keine Bevorzugung zwischen irgendwelchen bietet Paarung von Parachain-Blöcken. Collators berechnen die neue Warteschlange und entleeren Sie die Ausgangswarteschlangen entsprechend der Parachain Logik. Der Inhalt der Eingangswarteschlange wird explizit geschrieben in den Parachain-Block. Dies hat zwei Hauptzwecke: Erstens bedeutet dies, dass die Parachain isoliert von den anderen Parachains vertrauenswürdig synchronisiert werden kann. Zweitens, Es vereinfacht die Datenlogistik für den gesamten Eingang Warteschlange kann nicht in einem einzelnen Block verarbeitet werden; validators und Collators können folgende Blöcke verarbeiten ohne die Daten der Warteschlange speziell beschaffen zu müssen. Wenn die Eingangswarteschlange der Parachain über einem Schwellenwert liegt Betrag am Ende der Blockverarbeitung, dann wird er markiert Die Relaiskette ist gesättigt und es dürfen keine weiteren Nachrichten gesendet werden bis zur Freigabe an ihn geliefert werden. Merkle-Beweise sind Wird verwendet, um die Betriebstreue des Zusammentragers zu demonstrieren der Beweis des Parachain-Blocks. 6.6.3. Kritik. Ein kleiner Fehler in Bezug auf dieses Basic Mechanismus ist der Post-Bomben-Anschlag. Hier ist alles Parachains senden die größtmögliche Anzahl an Beiträgen zu einer bestimmten Parachain. Während dies das Ziel fesselt Ingress-Warteschlange auf einmal, es entsteht kein darüber hinausgehender Schaden ein Standard-Transaktions-DoS-Angriff. Normaler Betrieb, mit einer Reihe gut synchronisierter und nicht böswillige Collators und validators, für N Parachains, N × M insgesamt validators und L Collatoren pro Parachain, wir kann die gesamten Datenpfade pro Block aufschlüsseln in: Validator: M −1+L+L: M −1 für die anderen validators im Parachain-Satz L für jeden Collator, der einen Kandidaten-Parachain-Block bereitstellt, und ein zweites L für jeden Collator des nächsten Blocks, der die Ausgangsnutzlasten des vorherigen Blocks erfordert. (Letzteres entspricht eher dem schlimmsten Fall Betrieb, da es wahrscheinlich ist, dass Sortierer diesen gemeinsam nutzen werden Daten.) Collator: M + kN: M für eine Verbindung zu jedem relevanten Parachain-Block validator, kN zum Seeding der Ausgangsnutzlasten an eine Teilmenge jeder Parachain-validator-Gruppe für der nächste Block (und möglicherweise einige bevorzugte Collator(s)). Daher wachsen die Datenpfadwege pro Knoten linear mit der Gesamtkomplexität des Systems. Während dies so ist angemessen, da das System in Hunderte oder Tausende von Parachains skaliert wird, kann es zu einer gewissen Kommunikationslatenz kommen im Austausch für eine geringere Komplexitätswachstumsrate absorbiert werden. In diesem Fall kann ein mehrphasiger Routing-Algorithmus verwendet werden um die Anzahl der momentanen Pfade zu reduzieren auf Kosten der Einführung von Speicherpuffern und Latenz. 6.6.4. Hyper-Cube-Routing. Hyper-Cube-Routing ist ein Mechanismus, der meist als Erweiterung zum erstellt werden kann oben beschriebener grundlegender Routing-Mechanismus. Im Wesentlichen, Anstatt die Knotenkonnektivität mit der Anzahl der Parachains und Untergruppenknoten zu erhöhen, wachsen wir nur mit der Logarithmus von Parachains. Beiträge können zwischen diesen verschoben werden Mehrere Parachain-Warteschlangen auf dem Weg zur endgültigen Lieferung. Das Routing selbst ist deterministisch und einfach. Wir beginnen mit Begrenzung der Anzahl der Bins in den Eingangs-/Ausgangswarteschlangen; anstatt die Gesamtzahl der Parachains zu sein, sie sind dieRouting-Basis (b) . Dies wird als Nummer festgelegt von Parachains ändert sich, wobei stattdessen der Routing-Exponent (e) erhöht wird. Unter diesem Modell ist unser Nachrichtenvolumen wächst mit O(be), wobei die Pfade konstant bleiben und die Latenz (oder Anzahl der für die Zustellung erforderlichen Blöcke) mit O(e). Unser Routing-Modell ist ein Hyperwürfel mit E-Dimensionen. wobei jede Seite des Würfels b mögliche Orte hat. In jedem Block leiten wir Nachrichten entlang einer einzelnen Achse weiter. Wir alternieren die Achsen im Round-Robin-Verfahren und garantieren so die Lieferzeit von e-Blöcken im ungünstigsten Fall. Im Rahmen der Parachain-Verarbeitung fremdgebunden Nachrichten, die in der Eingangswarteschlange gefunden werden, werden sofort an den entsprechenden Bin der Ausgangswarteschlange weitergeleitet aktuelle Blocknummer (und damit Routingdimension). Dies Der Prozess erfordert eine zusätzliche Datenübertragung für jeden Hop Auf dem Lieferweg ist dies jedoch selbst ein Problem Dies kann durch den Einsatz alternativer Mittel gemildert werden der Daten-Nutzdatenlieferung und enthält nur eine Referenz, und nicht die volle Nutzlast des Posts im Post-Trie. Ein Beispiel für ein solches Hyper-Cube-Routing für ein System mit 4 Parachains könnte b = 2 und e = 2 sein: Phase 0, bei jeder Nachricht M: • sub0: wenn Mdest ∈{2, 3} dann sendTo(2) sonst behalten • sub1: wenn Mdest ∈{2, 3} dann sendTo(3) sonst behalten • sub2: wenn Mdest ∈{0, 1} dann sendTo(0) sonst behalten • sub3: wenn Mdest ∈{0, 1} dann sendTo(1) sonst behalten Phase 1, zu jeder Nachricht M: • sub0: wenn Mdest ∈{1, 3} dann sendTo(1) sonst behalten • sub1: wenn Mdest ∈{0, 2} dann sendTo(0) sonst behalten • sub2: wenn Mdest ∈{1, 3} dann sendTo(3) sonst behalten • sub3: wenn Mdest ∈{0, 2} dann sendTo(2) sonst behalten Die beiden Dimensionen sind hier als erste leicht zu erkennen zwei Bits des Zielindex; für den ersten Block die Es wird nur das höherwertige Bit verwendet. Der zweite Block befasst sich mit dem niederwertigen Bit. Sobald beides geschieht (in beliebiger Reihenfolge). Bestellung), dann wird die Post weitergeleitet. 9kryptografisch sicheres Pseudozufälliges

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 16 6.6.5. Maximierung des Zufalls. Eine Änderung des Grundprinzips Der Vorschlag würde eine feste Gesamtzahl von c2 −c validators vorsehen, mit c−1 validators in jeder Untergruppe. Jeder Block, anstatt Es findet eine unstrukturierte Neupartitionierung von validators statt unter Parachains, stattdessen für jede Parachain-Untergruppe, Jeder validator würde einem eindeutigen und anderen Objekt zugeordnet werden Parachain-Untergruppe im folgenden Block. Das würde führen zur Invariante dass zwischen zwei beliebigen Blöcken für jeden Bei zwei Parachain-Paarungen gibt es zwei validators, die haben die Parachain-Verantwortlichkeiten getauscht. Dies kann jedoch nicht dazu genutzt werden, absolute Garantien für die Verfügbarkeit zu erhalten (Ein einzelner validator wird gelegentlich offline gehen, auch wenn wohlwollend), kann es dennoch den Gesamtfall optimieren. Dieser Ansatz ist nicht ohne Komplikationen. Auch die Hinzufügung einer Parachain würde eine Neuorganisation erfordern des validator-Sets. Darüber hinaus ist die Anzahl der validators, die an das Quadrat der Anzahl der Fallschirme gebunden ist, würde zunächst sehr klein anfangen und schließlich weit wachsen zu schnell und wird nach etwa 50 Parachains unhaltbar. Keines davon sind grundsätzliche Probleme. Im ersten Fall Eine Neuorganisation der validator-Sets ist etwas, das sein muss sowieso regelmäßig gemacht. Bezüglich der Größe des validator Wenn dieser Wert zu klein ist, können mehrere validators zugewiesen werden auf dieselbe Parachain anwenden, indem ein ganzzahliger Faktor auf die angewendet wird Gesamtsumme von validators. Ein mehrphasiger Routing-Mechanismus wie das in 6.6.4 besprochene Hypercube-Routing würde dies tun Verringern Sie den Bedarf an einer großen Anzahl von validators wenn es eine große Anzahl von Ketten gibt. 6.7. Parachain-Validierung. Der Hauptzweck eines validator besteht darin, als gut vernetzter Akteur zu bezeugen, dass es sich um einen Parachain handelt Der Block ist gültig, einschließlich, aber nicht beschränkt auf, alle Zustandsübergänge, alle externen Transaktionen einschließlich der Ausführung von alle wartenden Beiträge in der Eingangswarteschlange und den Endzustand der Ausgangswarteschlange. Der Prozess selbst ist ziemlich einfach. Sobald der validator den vorherigen Block versiegelt hat, sind sie frei mit der Arbeit an der Bereitstellung eines möglichen Parachain-Blocks zu beginnen Kandidat für die nächste Konsensrunde. Zunächst findet validator einen Parachain-Blockkandidaten über einen Parachain-Collator (im Folgenden beschrieben) oder einen solchen seiner Co-validators. Die Parachain-Block-Kandidatendaten Enthält den Header des Blocks, den Header des vorherigen Blocks, alle enthaltenen externen Eingabedaten (für Ethereum und Bitcoin werden solche Daten als Transaktionen bezeichnet, sie können jedoch im Prinzip beliebige Datenstrukturen für beliebige Zwecke umfassen), Ausgangswarteschlangendaten und interne Daten zum Nachweis der Zustandsübergangsgültigkeit (für Ethereum Dies wären die verschiedenen Status-/Speicher-Trie-Knoten, die zum Ausführen jeder Transaktion erforderlich sind. Experimentelle Beweise zeigen diesen vollständigen Datensatz für einen aktuellen Ethereum-Block höchstens ein paar Hundert KiB betragen. Gleichzeitig wird, falls noch nicht geschehen, der validator angezeigt Es wird versucht, Informationen zum Übergang des vorherigen Blocks abzurufen, zunächst aus dem Übergang des vorherigen Blocks validators und höher von allen validators, die für die unterzeichnen Verfügbarkeit der Daten. Sobald der validator einen solchen Kandidatenblock erhalten hat, Anschließend validieren sie es vor Ort. Der Validierungsprozess ist im Modul validator der Parachain-Klasse enthalten, a konsenssensitives Softwaremodul, das geschrieben werden muss für jede Implementierung von Polkadot (allerdings im Prinzip Eine Bibliothek mit einem C-ABI könnte dies einer einzelnen Bibliothek ermöglichen zwischen Implementierungen mit den entsprechenden geteilt werden Verringerung der Sicherheit aufgrund der Tatsache, dass es nur eine einzige „Referenz“-Implementierung gibt). Der Prozess nimmt den Header des vorherigen Blocks und überprüft seine Identität über die kürzlich vereinbarte Relay-Kette Block, in dem sein hash aufgezeichnet werden soll. Sobald die Gültigkeit des übergeordneten Headers festgestellt ist, wird die spezifische Parachain Die Validierungsfunktion der Klasse kann aufgerufen werden. Dies ist eine einzelne Funktion, die eine Reihe von Datenfeldern akzeptiert (ungefähr). die zuvor angegebenen) und die Rückgabe eines einfachen Booleschen Werts die Gültigkeit der Sperre verkünden. Die meisten dieser Validierungsfunktionen prüfen zunächst die Header-Felder, aus denen direkt abgeleitet werden kann der übergeordnete Block (z. B. übergeordneter Block hash, Nummer). Nachfolgend Dadurch füllen sie alle internen Datenstrukturen auf notwendig, um Transaktionen und/oder Beiträge zu bearbeiten. Für eine Ethereum-ähnliche Kette läuft dies auf das Auffüllen von a hinaus Versuchen Sie die Datenbank mit den Knoten, die dafür benötigt werden vollständige Ausführung der Transaktionen. Andere Kettentypen können möglicherweise vorhanden sein andere pReparaturmechanismen. Sobald dies erledigt ist, werden die Eingangsbeiträge und externen Transaktionen (oder was auch immer die externen Daten darstellen) angezeigt umgesetzt, ausbalanciert gemäß der Spezifikation der Kette. (A Eine sinnvolle Standardeinstellung könnte sein, dass alle Eingangsbeiträge erforderlich sein müssen verarbeitet werden, bevor externe Transaktionen bedient werden, dies sollte jedoch der Logik der Parachain überlassen bleiben.) Durch diesen Erlass wird es eine Reihe von Egress-Beiträgen geben erstellt und es wird überprüft, ob diese tatsächlich übereinstimmen der Kandidat des Collators. Endlich ist das richtig besiedelt Der Header wird mit dem Header des Kandidaten verglichen. Bei einem vollständig validierten Kandidatenblock ist der validator kann dann für den hash seines Headers stimmen und alle erforderlichen Validierungsinformationen an die Co-validators in seiner Untergruppe senden. 6.7.1. Parachain-Collatoren. Parachain-Collatoren sind ungebundene Betreiber, die einen Großteil der Aufgaben von Minern erfüllen in den heutigen blockchain Netzwerken. Sie sind spezifisch zu einer bestimmten Parachain. Um zu funktionieren, müssen sie Halten Sie sowohl die Relaiskette als auch die vollständige Synchronisierung aufrecht Parachain. Die genaue Bedeutung von „vollständig synchronisiert“ hängt von der Klasse der Parachain ab, umfasst jedoch immer den aktuellen Status der Eingangswarteschlange der Parachain. Im Fall von Ethereum geht es auch darum, zumindest aufrechtzuerhalten eine Merkle-Tree-Datenbank der letzten paar Blöcke, aber vielleicht umfassen auch verschiedene andere Datenstrukturen, einschließlich Bloom Filtert nach Kontoexistenz, Familieninformationen und Protokollierung Ausgänge und Reverse-Lookup-Tabellen für die Blocknummer. Es sorgt nicht nur dafür, dass die beiden Ketten synchronisiert bleiben, sondern sorgt auch dafür, dass die beiden Ketten synchronisiert bleiben Sie müssen auch nach Transaktionen „fischen“, indem Sie eine Transaktionswarteschlange unterhalten und ordnungsgemäß validierte Transaktionen akzeptieren aus dem öffentlichen Netz. Mit der Warteschlange und der Kette ist es so ist in der Lage, neue Kandidatenblöcke für die in jedem Block ausgewählten validators zu erstellen (deren Identität bekannt ist, da die Relaychain synchronisiert ist) und sie zusammen mit dem einzureichen diverse Zusatzinformationen wie z.B. Gültigkeitsnachweis, via das Peer-Netzwerk. Für seine Mühe erhebt es alle Gebühren im Zusammenhang mit den darin enthaltenen Transaktionen. Darum kreisen verschiedene Ökonomien Anordnung. In einem hart umkämpften Markt, wo es gibt Liegt ein Überschuss an Collatoren vor, ist es möglich, dass die Transaktion erfolgt Die Gebühren werden mit den Parachain-validators geteilt, um Anreize zu schaffen die Aufnahme eines bestimmten Collator-Blocks. Ähnlich,

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 17 Einige Kollektoren erheben möglicherweise sogar die erforderlichen Gebühren zu zahlen, um den Block attraktiver zu machen validators. In diesem Fall sollte sich ein natürlicher Markt bilden Bei Transaktionen, bei denen höhere Gebühren anfallen, entfällt die Warteschlange und eine schnellere Einbindung in die Kette. 6.8. Vernetzung. Networking auf traditionellen blockchains wie Ethereum und Bitcoin haben eher einfache Anforderungen. Alle Transaktionen und Blöcke werden in einem einfachen, ungerichteten Klatsch übertragen. Insbesondere die Synchronisierung ist aufwändiger mit Ethereum, aber in Wirklichkeit war diese Logik darin enthalten die Peer-Strategie und nicht das Protokoll selbst, das sich um einige Anforderungs- und Antwortnachrichtentypen drehte. Während Ethereum mit dem devp2p-Protokoll Fortschritte bei den aktuellen Protokollangeboten machte, was viele ermöglichte Unterprotokolle, die über eine einzelne Peer-Verbindung gemultiplext werden sollen und daher das gleiche Peer-Overlay haben, unterstützen viele P2P-Protokolle gleichzeitig, der Ethereum-Teil von Das Protokoll blieb immer noch relativ einfach und das P2P Das Protokoll bleibt eine Weile unvollendet und wichtig Es fehlen Funktionen wie QoS-Unterstützung. Leider besteht weitgehend der Wunsch, ein allgegenwärtigeres „Web 3“-Protokoll zu schaffen ist fehlgeschlagen, da die einzigen Projekte, die es explizit nutzen, diese sind finanziert durch den Crowd-Sale Ethereum. Die Anforderungen für Polkadot sind etwas umfangreicher. Anstelle eines völlig einheitlichen Netzwerks, Polkadot verfügt über mehrere Arten von Teilnehmern mit jeweils unterschiedlichen Anforderungen an die Zusammensetzung ihrer Kollegen und über mehrere Netzwerke „Wege“, über deren Teilnehmer sich gerne unterhalten wird bestimmte Daten. Dies bedeutet ein wesentlich strukturierteres Netzwerk-Overlay – und ein Protokoll, das dies unterstützt – wird wahrscheinlich notwendig sein. Darüber hinaus ist die Erweiterbarkeit möglich, um zukünftige Ergänzungen wie neue Arten von „Ketten“ zu ermöglichen erfordern selbst eine neuartige Overlay-Struktur. Während einer ausführlichen Diskussion darüber, wie die Vernetzung Da das Protokoll möglicherweise nicht in den Rahmen dieses Dokuments fällt, ist eine Analyse der Anforderungen sinnvoll. Wir können Teilen Sie unsere Netzwerkteilnehmer grob in zwei Gruppen auf (Relaiskette, Parachains) jeweils aus drei Teilmengen. Wir können Geben Sie auch an, dass jeder der Parachain-Teilnehmer nur ist daran interessiert, sich untereinander zu unterhalten, anstatt Teilnehmer an anderen Parachains: • Relay-Chain-Teilnehmer: • Validatoren: P, jeweils in Teilmengen P[s] aufgeteilt Parachain • Verfügbarkeitsgaranten: A (dies kann durch Validatoren in der Grundform des Protokolls dargestellt werden) • Relay-Chain-Clients: M (beachten Sie die Mitglieder von jedem Parachain-Set wird tendenziell auch Mitglieder von M sein) • Parachain-Teilnehmer: • Parachain-Collatoren: C[0], C[1], . . . • Parachain-Fischer: F[0], F[1], . . . • Parachain-Kunden: S[0], S[1], . . . • Parachain-Light-Clients: L[0], L[1], . . . Im Allgemeinen benennen wir bestimmte Kommunikationsklassen findet tendenziell zwischen Mitgliedern dieser Gruppen statt: • P | A <-> P | A: Die voll eingestellt von validators/Bürgen muss sein gut vernetzt zu Konsens erreichen. • P[s] <-> C[s] | P[s]: Jeder validator als Mitglied einer bestimmten Parachain-Gruppe neigt zum Tratschen mit anderen solchen Mitgliedern sowie den Zusammenstellern dieser Parachain, um Blockkandidaten zu entdecken und zu teilen. • A <-> P[s] | C | A: Jeder Verfügbarkeitsgarant muss konsenssensitiv kettenübergreifend gesammelt werden Daten aus den ihm zugeordneten validators; Collatoren kann auch die Chance auf einen Konsens darüber optimieren blockieren, indem Sie es an Verfügbarkeitsgarantien weitergeben. Sobald sie vorliegen, werden die Daten an ausgezahlt einen anderen solchen Garanten, um den Konsens zu erleichtern. • P[s] <-> A | P[s']: Parachain validators wird Sie müssen zusätzliche Eingabedaten aus dem vorherigen Satz von validators oder den Verfügbarkeitsgaranten sammeln. • F[s] <-> P: Beim Melden dürfen die Fischer Platz nehmen eine Reklamation gegenüber jedem Teilnehmer. • M <-> M | P | A: Allgemeine Relay-Chain-Clients geben Daten von validators und Bürgen aus. • S[s] <-> S[s] | P[s] | A: Parachain-Kunden zahlen Daten von den validator/Garanten aus. • L[s] <-> L[s] | S[s]: Parachain-Light-Clients Daten von den Vollkunden auszahlen. Um einen effizienten Transportmechanismus zu gewährleisten, ist ein „flacher“ Overlay-Netzwerk – wie devp2p von Ethereum – wobei jedes Knoten unterscheidet nicht (nicht willkürlich) die Eignung seiner Knoten Gleichaltrige sind wahrscheinlich nicht geeignet. Eine einigermaßen erweiterbare Es wird wahrscheinlich ein Peer-Auswahl- und Entdeckungsmechanismus erforderlich sein sowohl in das Protokoll aufgenommen als auch aggressiv sein Planen Sie einen Ausblick, um die richtige Art von Kollegen sicherzustellen sind „zufällig“ connezur richtigen Zeit getroffen. Die genaue Strategie der Peer-Zusammensetzung wird für jede Teilnehmerklasse unterschiedlich sein: für eine ordnungsgemäße Skalierung Multi-Chain-Collatoren müssen entweder kontinuierlich sein Wiederverbindung mit den entsprechend gewählten validators oder Testamenten benötigen laufende Vereinbarungen mit einer Teilmenge der validators um sicherzustellen, dass sie während des größten Teils der Zeit, in der sie dafür unbrauchbar sind, nicht getrennt werden validator. Selbstverständlich werden auch Sortierer versuchen, eines aufrechtzuerhalten oder stabilere Verbindungen in den Verfügbarkeitsgaranten soll eine schnelle Verbreitung ihrer konsensorientierten Maßnahmen gewährleisten Daten. Verfügbarkeitsgaranten werden meist darauf abzielen, eine aufrechtzuerhalten stabile Verbindung untereinander und zu validators (für den Konsens und die konsenskritischen Parachain-Daten, zu denen). sie bezeugen) sowie an einige Collatoren (für die Parachain). Daten) und einige Fischer und Vollkunden (zum Zerstreuen). Informationen). Validatoren neigen dazu, nach anderen validators zu suchen, insbesondere nach solchen in derselben Untergruppe und anderen Collatoren, die ihnen Parachain-Blockkandidaten liefern können. Fischer sowie allgemeine Relay-Chain und Parachain Kunden werden im Allgemeinen versuchen, eine Verbindung zu a offen zu halten validator oder Bürge, aber viele andere ähnliche Knoten für sich selbst sonst. Parachain-Light-Clients streben ebenfalls danach, mit einem vollständigen Client der Parachain verbunden zu werden. wenn nicht nur andere Parachain-Light-Clients. 6.8.1. Das Problem der Peer-Churn. Im Basisprotokollvorschlag ändert sich jede dieser Teilmengen ständig zufällig mit jedem Block, der den zur Überprüfung zugewiesenen validators zugewiesen wird Die Parachain-Übergänge werden zufällig ausgewählt. Das kann ein Problem sein, wenn unterschiedliche (Nicht-Peer-)Knoten dies benötigen Daten untereinander weitergeben. Man muss sich entweder darauf verlassen ein fair verteiltes und gut vernetztes Peer-Netzwerk

POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 18 Stellen Sie sicher, dass die Hop-Distanz (und damit die Latenz im schlimmsten Fall) nur mit dem Logarithmus der Netzwerkgröße wächst (ein Kademlia-ähnliches Protokoll [13] kann hier helfen), oder man muss Führen Sie längere Blockzeiten ein, um die notwendige Verbindungsaushandlung zu ermöglichen, um ein Peer-Set aufrechtzuerhalten spiegelt die aktuellen Kommunikationsbedürfnisse des Knotens wider. Keine dieser Lösungen ist großartig: lange Blockzeiten Wird dem Netzwerk aufgezwungen, kann es unbrauchbar werden bestimmte Anwendungen und Ketten. Sogar eine völlig faire und verbundenes Netzwerk wird zu erheblicher Verschwendung führen der Bandbreite, da sie aufgrund uninteressierter Knoten skaliert für sie nutzlose Daten weiterzugeben. Während beide Richtungen Teil der Lösung sein können, Eine sinnvolle Optimierung zur Minimierung der Latenz wäre möglich sein, die Volatilität dieser Parachain zu begrenzen validator Sätze, wobei entweder die Zugehörigkeit nur zwischen Reihen von Blöcken neu zugewiesen wird (z. B. in Gruppen von 15, die bei einer 4-Sekunden-Einheit). Blockzeit würde bedeuten, dass die Verbindungen nur einmal pro Jahr geändert werden Minute) oder durch schrittweise Rotation der Mitgliedschaft, z.B. Änderung durch jeweils ein Mitglied (z. B. wenn dort Sind jeder Parachain 15 validators zugeordnet, dann wäre es im Durchschnitt eine ganze Minute zwischen völlig eindeutig Sätze). Indem Sie die Abwanderung von Peers begrenzen und sicherstellen, dass vorteilhafte Peer-Verbindungen gut hergestellt werden Fortschritt durch die teilweise Vorhersehbarkeit von Parachain Sets können wir dazu beitragen, dass jeder Knoten dauerhaft einen behält zufällige Auswahl von Kollegen. 6.8.2. Weg zu einem effektiven Netzwerkprotokoll. Wahrscheinlich die Der effektivste und vernünftigste Entwicklungsaufwand wird sich auf die Nutzung eines bereits vorhandenen Protokolls statt auf die fortlaufende Nutzung konzentrieren unser eigenes. Es gibt mehrere Peer-to-Peer-Basisprotokolle Wir können das eigene DevP2P von Ethereum verwenden oder erweitern [22], libp2p von IPFS [1] und GNUnet von GNU [4]. Eine vollständige Überprüfung dieser Protokolle und ihrer Relevanz für den Aufbau eines modulares Peer-Netzwerk, das bestimmte strukturelle Garantien, dynamische Peer-Steuerung und erweiterbare Unterprotokolle unterstützt geht weit über den Rahmen dieses Dokuments hinaus, wird aber eine sein wichtiger Schritt bei der Umsetzung von Polkadot. 7. Praktische Aspekte des Protokolls 7.1. Interchain-Transaktionszahlung. Während ein tolles Durch den Wegfall der Notwendigkeit eines ganzheitlichen Rechnungslegungsrahmens für Rechenressourcen wie dem Gas von Ethereum wird ein Höchstmaß an Freiheit und Einfachheit gewonnen. Dies wirft jedoch eine wichtige Frage auf: Wie funktioniert eine Parachain ohne Gas? verhindern, dass eine andere Fallschirmkette sie zu Berechnungen zwingt? Während wir uns auf die Transaktions-Post-Eingangswarteschlange verlassen können Puffer, um zu verhindern, dass eine Kette eine andere mit Spam überschüttet Transaktionsdaten bietet das Protokoll keinen gleichwertigen Mechanismus, um Spam bei der Transaktionsverarbeitung zu verhindern. Dies ist ein Problem, das der höheren Ebene überlassen bleibt. Da Ketten Es steht Ihnen frei, dem eingehenden Text eine beliebige Semantik hinzuzufügen Transaktionspostdaten können wir diese Berechnung sicherstellen muss vor Beginn bezahlt werden. In ähnlicher Weise wie die Modell, das von Ethereum Serenity vertreten wird, können wir uns vorstellen ein „Break-in“-Vertrag innerhalb einer Parachain, der a validator um eine garantierte Zahlung im Austausch dafür zu erhalten Bereitstellung einer bestimmten Menge an Verarbeitungsressourcen. Diese Ressourcen können in etwas wie Gas gemessen werden, Es könnte sich aber auch um ein völlig neuartiges Modell handeln, beispielsweise um eine subjektive Ausführungszeit oder um ein Bitcoin-ähnliches Pauschalpreismodell. Dies allein ist nicht so nützlich, da wir nicht ohne weiteres davon ausgehen können, dass der Anrufer außerhalb der Kette für ihn verfügbar ist Welcher Wertmechanismus auch immer durch den Einbruch erkannt wird Vertrag. Wir können uns jedoch einen sekundären „Breakout“-Vertrag in der Quellkette vorstellen. Die beiden Verträge würden zusammen eine Brücke bilden, einander anerkennen und Bereitstellung von Wertäquivalenz. (Staking-tokens, verfügbar für jedes einzelne könnte zur Begleichung der Zahlungsbilanz verwendet werden.) Ein Aufruf in eine andere solche Kette würde ein Proxying bedeuten über diese Brücke, die die Mittel dafür bereitstellen würde Aushandeln des Werttransfers zwischen Ketten, um Bezahlen Sie die für die Zielparachain erforderlichen Rechenressourcen. 7.2. Zusätzlich Ketten. Während die Ergänzung von a Parachain ist eine relativ günstige Operation, sie ist nicht kostenlos. Mehr Parachains bedeuten weniger validators pro Parachain und schließlich eine größere Anzahl von validators mit jeweils einem reduzierte durchschnittliche Bindung. Während das Problem geringerer Zwangskosten für den Angriff auf eine Parachain dadurch gemildert wird Fischer, das wachsende validator-Set erzwingt im Wesentlichen a höhere Latenz aufgrund der Mechanik des zugrunde liegenden Konsensesthod. Darüber hinaus jeder Parachain bringt das Potenzial mit sich, validators mit einem zu trauern Überlastender Validierungsalgorithmus. Daher wird es einen „Preis“ geben, der validators ist und/oder die Beteiligungsgemeinschaft wird dafür extrahieren Hinzufügung einer neuen Parachain. Dieser Markt für Ketten wird sehen Sie möglicherweise den Zusatz von entweder: • Ketten, bei denen wahrscheinlich kein Nettobeitrag gezahlt wird (in Bezug auf das Einsperren oder Verbrennen von staking tokens), die in einen Teil einbezogen werden müssen (z. B. Konsortialketten, Doge-Ketten, App-spezifische Ketten); • Ketten, die dem Netzwerk einen intrinsischen Wert liefern durch das Hinzufügen bestimmter Funktionen schwierig woanders hinzukommen (z. B. Vertraulichkeit, interne Skalierbarkeit, Serviceanbindung). Im Wesentlichen muss die Gemeinschaft der Beteiligten dies tun Anreize geschaffen werden, Kinderketten hinzuzufügen – entweder finanziell oder durch den Wunsch, dem Relais funktionsreiche Ketten hinzuzufügen. Es ist vorgesehen, dass neue Ketten hinzugefügt werden Kurze Kündigungsfrist für den Ausbau, sodass neue Ketten eingebaut werden können kompromisslos experimentiert werden kann das mittel- oder langfristige Wertversprechen. 8. Fazit Wir haben eine Richtung skizziert, die man als Autor einschlagen kann skalierbares, heterogenes Multi-Chain-Protokoll mit dem Potenzial, abwärtskompatibel zu bestimmten, bereits vorhandenen Protokollen zu sein blockchain Netzwerke. Unter einem solchen Protokoll, Teilnehmer Arbeiten Sie in aufgeklärtem Eigeninteresse daran, ein Gesamtsystem zu schaffen, das auf außerordentlich kostenlose Weise und ohne die typischen Kosten für bestehende Benutzer erweitert werden kann stammt aus einem Standarddesign blockchain. Wir haben gegeben ein grober Überblick über die Architektur, die erforderlich wäre, einschließlich die Art der Teilnehmer, ihre wirtschaftlichen Anreize und die Prozesse, an denen sie beteiligt sein müssen. Wir haben identifizierte ein grundlegendes Design und diskutierte seine Stärken und Einschränkungen; Dementsprechend haben wir weitere Anweisungen, die kann diese Einschränkungen lockern und den Weg zu einer vollständig skalierbaren blockchain-Lösung ebnen.POLKADOT: VISION FÜR EIN HETEROGENES MULTI-CHAIN-RAHMEN ENTWURF 1 19 8.1. Fehlendes Material und offene Fragen. Bei unterschiedlichen Implementierungen des Protokolls ist eine Netzwerkverzweigung immer möglich. Die Erholung von einem solchen Ausnahmezustand wurde nicht besprochen. Angesichts der Tatsache, dass das Netzwerk zwangsläufig einen Fertigstellungszeitraum ungleich Null haben wird, Die Wiederherstellung nach der Relaychain-Forking sollte kein großes Problem darstellen, erfordert jedoch eine sorgfältige Integration das Konsensprotokoll. Die Beschlagnahmung von Anleihen und umgekehrt die Bereitstellung von Belohnungen hat noch nicht tief erforscht. Derzeit gehen wir von Belohnungen aus werden nach dem Prinzip „Gewinner nimmt alles“ bereitgestellt: Dies ist möglicherweise nicht der Fall Bieten Sie den Fischern das beste Anreizmodell. Ein kurzzeitiger Commit-Reveal-Prozess würde es vielen Fischern ermöglichen den Preis zu beanspruchen und eine gerechtere Verteilung der Belohnungen zu gewährleisten, Allerdings könnte der Prozess zu zusätzlicher Latenz im führen Entdeckung von Fehlverhalten. 8.2. Danksagungen. Vielen Dank an alle Korrektoren, die dabei geholfen haben, dies in den Griff zu bekommen vorzeigbare Form. Insbesondere Peter Czaban, Bjorn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler und Jack Petersson. Vielen Dank an alle die Menschen, die Ideen oder Anfänge beigesteuert haben davon verdienen Marek Kotewicz und Aeron Buchanan besondere Erwähnung. Und vielen Dank an alle anderen für ihre Hilfe unterwegs. Alle Fehler sind meine eigenen. Teile dieser Arbeit, einschließlich erster Recherchen zu Konsensalgorithmen wurden teilweise von den Briten finanziert Regierung im Rahmen des Innovate UK-Programms.