Sharding: Durchsatz, Skalierbarkeit und warum wir sie brauchen

TL;DR
Bei Distributed-Ledger-Technologien bezeichnet Skalierbarkeit die Fähigkeit eines Systems, seinen Durchsatz zu erhöhen, wenn mehr Nachfrage generiert wird. Für die Blockchain stellt die Skalierbarkeit eine große Herausforderung dar, da der Aufbau des Ledgers vorschreibt, dass die Transaktionen vollständig geordnet sind. In diesem Blogbeitrag gehen wir zunächst auf die Unterschiede zwischen Skalierbarkeit und Durchsatz ein. Anschließend untersuchen wir die Sharding-Lösung, bei der Nachrichten nur an eine Teilmenge der Netzwerkknoten übermittelt werden, wodurch die Redundanz reduziert und ein Hochleistungsnetzwerk aufgebaut wird.

Einst waren Tangle City und Las Iota durch eine zweispurige Schnellstraße verbunden. Es war die einzige Strecke, auf der Autos zwischen den beiden Städten verkehren konnten. Mit der Zeit wuchsen die Städte, was zu langen Staus auf der Autobahn führte. Eines sonnigen Tages beschlossen die Bürgermeister der beiden Städte, dass es an der Zeit sei, das Problem anzugehen. Ihre erste Idee war: „Lasst uns eine größere Autobahn mit vier statt zwei Fahrspuren bauen!„. Die Idee klang gut, aber die Umsetzung war schwierig: Ein Fluss, eine alte Kirche und ein störrischer Bauer in der Nähe der Hauptstraße stellten einige Hindernisse auf dem Weg zur Fertigstellung dar. Doch schließlich wurde die Autobahn fertiggestellt. Leider löste sie das Verkehrsproblem nicht: Die Autos mussten immer noch durch das gleiche Nadelöhr fahren, und die beiden Städte wuchsen weiter, was die beiden Bürgermeister bald vor das gleiche alte Problem stellte. Sollten die Bürgermeister noch einmal größere Autobahnen bauen, um eine gute Verbindung zwischen Tangle City und Las Iota zu gewährleisten? Oder gibt es andere Lösungen?

Wir haben soeben das Konzept des Durchsatzes und der damit verbundenen Überlastung aufgrund der wachsenden Nachfrage in einer nicht skalierbaren Lösung beschrieben. Allzu oft werden diese beiden Konzepte, Durchsatz und Skalierbarkeit, im Zusammenhang mit der Distributed-Ledger-Technologie (DLT) verwechselt.

Der Durchsatz gibt an, wie viele Informationen im Netz pro Zeiteinheit verarbeitet, validiert und übermittelt werden können und wird in Bytes pro Sekunde gemessen (bei Nachrichten mit variabler Größe ist die üblicherweise verwendete Metrik Transaktionen pro Sekunde nur ein Näherungswert zur Messung des Durchsatzes). Der Durchsatz entspricht der Anzahl der Autobahnspuren in dem obigen Beispiel.

Skalierbarkeit hingegen ist die Fähigkeit des Netzes, ein wachsendes Arbeitsaufkommen zu bewältigen, indem dem System Ressourcen hinzugefügt werden, z. B. durch Erhöhung der Anzahl der Knoten. Während die beiden Bürgermeister den Durchsatz durch den Ausbau der bestehenden Straßeninfrastruktur verbesserten, erreichte die steigende Nachfrage bald wieder die volle Kapazität. Daher hätten verschiedene Alternativen in Betracht gezogen werden müssen, um das Leben der Bürger zu verbessern: z. B. der Bau zusätzlicher Autobahnen, der Ersatz von Autos durch effizientere öffentliche Verkehrsmittel (z. B. Busse oder Züge), der Bau neuer Städte, um die Bürger zu verteilen, ohne Engpässe in den großen Metropolen zu schaffen, und so weiter. In diesem Blogbeitrag werden wir die Definition von Skalierbarkeit klären und erklären, wie sie sich auf DLTs auswirkt.

Der Begriff Skalierbarkeit lässt sich auf eine Vielzahl von Kontexten und Bereichen anwenden, z. B. auf Routing-Protokolle, verteilte Systeme, Netzwerke, Datenbanken und Geschäftsmodelle. Im Zusammenhang mit DLT sind wir an der Skalierbarkeit der Last interessiert, d. h. an der Fähigkeit eines verteilten Systems, sich zu vergrößern (und zu verkleinern), um größere (oder kleinere) Lasten aufzunehmen. Bitcoin zum Beispiel kann nicht als skalierbares DLT definiert werden; das ist so gewollt, weil die Sicherheit der Leistung vorgezogen wurde. Unabhängig von der Anzahl der Nachrichten, die auf eine Bestätigung warten, und der Anzahl der Knoten im Netzwerk bleiben der Gesamtdurchsatz und die Abschlusszeit unverändert. Einige neuere Lösungen haben versucht, dieses Problem zu überwinden, indem sie z. B. das Lightning Network auf Schicht 2 hinzugefügt haben, um Zahlungskanäle außerhalb der Kette zu schaffen und so die Belastung der Hauptkette zu verringern.

Durch die Auslagerung von Transaktionen auf eine andere Schicht lässt sich zwar der Gesamtdurchsatz leicht erhöhen, das Problem der Skalierbarkeit der Hauptkette wird jedoch nach wie vor nicht angegangen: Das Öffnen und Schließen von Lightning-Kanälen erfordert immer noch jeweils eine Transaktion auf der Basisschicht. Selbst wenn also die Basisschicht nur zum Öffnen und Schließen von Lightning Channels verwendet wird und alle anderen Transaktionen in den Lightning Channels stattfinden, wäre die Skalierbarkeit immer noch auf die Anzahl der Lightning Channels beschränkt, die geöffnet und geschlossen werden können, was im Bitcoin-Netzwerk derzeit fünf bis sieben pro Sekunde beträgt. Bitcoin hat im Grunde eine zweite Schicht von Hochgeschwindigkeits-Autobahnspuren über der eigentlichen Autobahn hinzugefügt, aber die Leute müssen immer noch die gleichen Auffahrten nehmen, um überhaupt auf die Autobahn zu kommen, bevor sie die Hochgeschwindigkeitsspuren nutzen können.

Andere Lösungen gehen nicht dazu über, den Durchsatz auf zusätzliche Schichten auszulagern, sondern rühmen sich damit, dass die Hauptkette mehrere hunderttausend Transaktionen pro Sekunde unterstützen kann. Das bringt jedoch eine andere Herausforderung mit sich: Wenn eine einzelne Transaktion nur 1024 Bytes groß ist, würden 250.000 dieser Transaktionen pro Sekunde bedeuten, dass zwei Knoten über eine Hochgeschwindigkeitsdatenverbindung mit mehr als 2 Gbit/s¹ verbunden sein müssten. Dies würde dazu führen, dass die Teilnahme an einem dezentralen Netzwerk auf diejenigen beschränkt wird, die sich eine teure Infrastruktur leisten können. Man könnte sich diese Lösung also wie eine Autobahn mit Hunderten von Fahrspuren vorstellen, die jedoch schwierig und extrem teuer zu bebauen ist und deren Ausfahrten von einigen wenigen wohlhabenden Personen kontrolliert werden.

Um Skalierbarkeit zu erreichen, muss das Blockchain-Trilemma überwunden werden, das besagt, dass man nur zwei Möglichkeiten hat: Dezentralisierung, Sicherheit und Skalierbarkeit. Bitcoin entscheidet sich für Sicherheit und Dezentralisierung, aber nicht für Skalierbarkeit, während einige andere Wettbewerber sich für Sicherheit und Skalierbarkeit entscheiden, aber nicht für Dezentralisierung. Wie kann man also alle drei Eigenschaften beibehalteniota Sharding Lösung trillema

Die populärsten Lösungen für die Skalierbarkeit von DLTs werden durch ein Konzept namens Sharding repräsentiert – die Aufteilung der Gesamtmenge der Transaktionen in kleinere Partitionen. Der Begriff „Shard“ wurde 1988 durch den technischen Bericht „Overview of SHARD: a System for Highly Available Replicated Data„² eingeführt, der darauf abzielte, redundante Hardware zu verwenden, um die Datenreplikation zu erleichtern. Mit Sharding in der DLT ist in der Regel eine horizontale Partitionierung gemeint, bei der die Zeilen einer Datenbank, die eine einzige Partition bilden, getrennt auf verschiedenen Servern gehalten werden. Derzeit werden Sharding-Lösungen von mehreren Blockchain-Projekten entwickelt, darunter Ethereum, Zilliqa und Polkadot.

Das Sharding in DLTs ermöglicht es den Knoten, nur eine Teilmenge der im Netzwerk ausgetauschten Nachrichten zu validieren und zu speichern. Da die Redundanz reduziert wird, steigt die Zahl der Nachrichten, die das Netzwerk verarbeiten kann, im Vergleich zu einer Lösung ohne Sharding. Beim Sharding kann ein Angreifer jedoch leichter einen größeren Einfluss innerhalb eines einzelnen Shards erlangen, da die Sicherheit des Shards direkt proportional zur kumulativen Hash-Rate (bei Proof-of-Work-Systemen) oder zum Gesamtstapel (bei Proof-of-Stake- und ähnlichen Systemen) ist. Im Wesentlichen besteht durch die Aufteilung der Transaktionsmenge in Stücke die Gefahr, dass auch die Sicherheitsmerkmale aufgeteilt werden und somit die Sicherheit für jeden einzelnen Shard verringert wird, es sei denn, es wird ein Abhilfemechanismus eingeführt.

Die Struktur des gerichteten azyklischen Graphen (DAG) des IOTA-Ledgers bietet einen hervorragenden Ausgangspunkt für den Aufbau einer skalierbaren DLT. Ein DAG-basierter Ledger führt nicht den konzeptionellen Engpass ein, der in der Blockchain vorhanden ist, wo alle Nachrichten einer totalen Ordnung unterliegen, was zu unvermeidlichen Reibungen im Protokoll führt: In IOTA gibt es keinen zentralen Anführer, der die Erstellung des nächsten Transaktionsblocks bestimmt. Darüber hinaus ist IOTA ein führerloses Protokoll, was bedeutet, dass jeder Knoten eine andere Wahrnehmung des Status Quo des Ledger-Status haben kann, während er sich immer noch darüber einig ist, welche Transaktionen gültig sind und welche nicht. Infolgedessen bedeuten in IOTA mehr Nachrichten eine schnellere Endgültigkeit!

Wie bereits erwähnt, sind jedoch auch die Ressourcen in IOTA begrenzt, so dass eine Lösung für die Herausforderung der Skalierbarkeit der Last erforderlich ist. Das IOTA-Protokoll ist leichtgewichtig und erfordert keine Gebühren, was einen grundlegenden Vorteil gegenüber ähnlichen Technologien darstellt. Die Forschungsabteilung der IOTA Foundation untersucht Lösungen, die im Sinne der IOTA-Vision das volle Potenzial von IOTA ausschöpfen. Wir freuen uns darauf, unsere Ergebnisse bald mit Ihnen zu teilen.

¹ Diese Berechnung ignoriert den stets vorhandenen Netzwerk-Overhead und die Tatsache, dass die Knoten in einem Peer-to-Peer-Netz in der Regel mit mehreren Knoten verbunden sind. In der Praxis müssten solche konkurrierenden Netze darauf angewiesen sein, dass die Knoten sich Verbindungen mit mindestens 10 Gbit/s leisten können.

² Derzeit sind keine Kopien des Berichts leicht zugänglich. Eine andere Interpretation ist, dass der Name „Shard“ aus dem Videospiel Ultima Online stammt.

Original by Luigi Vigneri: https://blog.iota.org/sharding-throughput-scalability-and-why-we-need-them/

IOTA Forschungsstatus Update September 2021

Wir freuen uns, Ihnen die folgenden Neuigkeiten aus unseren Forschungsgruppen mitteilen zu können. Die Abteilung konzentriert sich weiterhin auf die Verbesserung der Implementierung des IOTA 2.0-Protokolls im DevNet.

In diesem Monat stellen wir zwei neue Gruppen vor: die Konsensgruppe und die Kommunikationsschichtgruppe. Die Konsensgruppe wurde gebildet, um das Problem der Verzögerung bei der Nachrichtenausbreitung anzugehen, das in unserem monatlichen Update vom Juli beschrieben wurde. Die Arbeit an der Simulation und dem Testen unseres verbesserten Konsensmechanismus hat bisher gute Ergebnisse erbracht. Die Kommunikationsschicht-Gruppe arbeitet, wie der Name schon sagt, an verschiedenen Aspekten der Kommunikation im IOTA 2.0-Protokoll. Dazu gehören Themen wie die Überprüfung der Netzwerkleistung, Optimierungen und Zeitstempel. Wie immer, lesen Sie bitte unten alle Details.

DevNet-Implementierung

Seit der letzten Aktualisierung hat das Team die Versionen 0.7.4 und 0.7.5 veröffentlicht, die die allgemeine Stabilität der Software verbessern, mehrere Fehler beheben und die Scheduler-Komponente an das Ende des Datenflusses verlagern. Dies ermöglicht einen besseren Synchronisationsprozess sowie eine Vereinfachung des gesamten Datenflusses. Es gibt immer noch einige Probleme im Zusammenhang mit der Marker-Zuweisung, die es für einige neue Teilnehmer schwierig machen, ihre Knoten erfolgreich zu synchronisieren. Aus diesem Grund arbeitet das Team an einer neuen Funktion, die es den Community-Knoten ermöglichen wird, eine aktuelle Datenbank herunterzuladen, um eine schnellere und zuverlässigere Synchronisierung zu ermöglichen.

Die Umsetzung der neuen Verbesserungen für den Konsens schreitet sehr schnell voran, da sich das Team bereits in der Testphase befindet. Konkret wurden eine modulare Konsens-Schnittstelle, der On Tangle Voting (OTV)-Mechanismus, ein neuer übergeordneter Typ (d.h. der Like-Schalter) und eine überarbeitete syntaktische Validierung von Nachrichten bereits zur Codebasis hinzugefügt, aber noch nicht zusammengeführt. Das Gewicht der Zustimmung, das jeder Nachricht zugewiesen wird, kann nun in Finalitätsgrade (GoF) übersetzt werden: niedrig, mittel und hoch. Die Sammlung neuer Metriken, die speziell für die Analyse von OTV entwickelt wurden, wurde ebenfalls hinzugefügt und eine neue Konfliktübersichtsseite wurde für das lokale Dashboard des Knotens entwickelt, so dass jeder Knotenbetreiber das Verhalten seines Knotens bei der Abstimmung über Konflikte in Echtzeit überprüfen kann.

IOTA Konses

Andere Komponenten des Protokolls, einschließlich des Rate Setters, der Kernkomponente der Staukontrolle, wurden in den Fluss integriert. Schließlich wurden erhebliche Anstrengungen zur Verbesserung der Codequalität unternommen. Die Verwendung von Dependency Injection bei der Initialisierung von Plugins, die Vereinheitlichung der Parameter, eine generischere Serialisierungs- und Deserialisierungsbibliothek sind nur einige Beispiele.

Die offizielle Dokumentation wurde zu docusaurus migriert und Sie können sie hier einsehen.

Vernetzung

Der derzeitige Schwerpunkt des Teams liegt auf der Analyse der Leistung des IOTA-Staukontrollalgorithmus (ICCA) und auf der Verbesserung der Benutzererfahrung. Genauer gesagt wurde ICCA mit dem Ziel entwickelt, die maximale Verzögerung zu minimieren, d.h. die Zeit, die benötigt wird, um eine Nachricht an alle Knotenpunkte zu übermitteln. Das bedeutet, dass die von ICCA verwendeten Schwellenwerte (Blacklisting, Self-Back-Off und Minimum Mana) als Regler für diese maximale Verzögerung fungieren. Um dies zu verstehen, stellen Sie sich einen Puffer mit unendlicher Größe vor, bei dem die Verzögerungen potenziell unendlich sein könnten. Wenn derselbe Puffer eine geringe Größe hat, muss eine neue Nachricht nur warten, bis alle vorhandenen (wenigen) Nachrichten eingeplant sind. Aus diesem Grund arbeiten wir an der Analyse der verschiedenen Parameter, um herauszufinden, wie sie die tatsächliche Leistung von ICCA beeinflussen und wie diese Parameter optimiert werden können. Als vorläufiges Ergebnis haben wir festgestellt, dass die Art und Weise, wie das Defizit zugewiesen und gekappt wird, einen starken Einfluss auf die Leistung hat.

Parallel dazu arbeiten wir an der Lastverteilung zwischen den Knoten und versuchen, die folgende Frage zu beantworten: Angenommen, ein Nutzer (Brieftasche oder Knoten) hat eine neue Nachricht zu versenden, welcher Knoten sollte gewählt werden, damit diese Nachricht in kurzer Zeit erstellt wird? Es sei daran erinnert, dass jeder Knoten über ein Modul zur Nachrichtenerstellung verfügt und die Rate der Hinzufügung neuer Nachrichten in den Scheduler durch den Rate Setter-Algorithmus reguliert wird; daher versucht dieses Projekt, neue Nachrichten den Knoten zuzuweisen, die zu einem bestimmten Zeitpunkt weniger ausgelastet sind. Wir haben dieses Problem als Optimierungsproblem formuliert und testen einige vorgeschlagene Strategien, die auf der Belegung des Nachrichtenerstellers oder der Verzögerung pro Knoten basieren.

Im Zusammenhang mit überprüfbaren Verzögerungsfunktionen (VDFs) optimieren wir die Berechnungs- und Auswertungszeit unseres vorgeschlagenen Algorithmus zur Spamvermeidung durch den Einsatz von Mehrfachpotenzierungstechniken, die wir zuvor untersucht haben. Wir haben festgestellt, dass einer der (zeitlich) teuersten Aspekte der Verifizierung der VDF darin besteht, die minimale Zahl zu finden, so dass der Hash dieser Zahl plus einer Eingabenachricht prim ist. Wir konzentrieren uns derzeit darauf, diese Funktion zu beschleunigen.

Sharding

In den vergangenen Wochen gab es verschiedene Schwerpunkte für die Data Sharding Gruppe: Hauptsächlich Diskussionen über ISCP Chains und Motivation zu Data Sharding, Simulationen zum Modell und Formalisierung unserer Ergebnisse, Definitionen und Diskussionen.

Zwei verschiedene Simulationen wurden von Mitgliedern der Data Sharding Group durchgeführt. Bei der ersten handelte es sich um ein benutzerbasiertes Modell, bei dem wir davon ausgingen, dass verschiedene Benutzer mit unterschiedlichen MPS-Anforderungen (Nachrichten pro Sekunde) dem Netzwerk beitreten und sich selbst optimal zuordnen. Anhand dieses Modells überprüften wir interessante Daten wie die Zuteilung von Mana pro Shard, erwartete MPS pro Mana-Anteil und MPS pro Schicht. Das zweite Modell ist ein Shard-basiertes Modell, bei dem wir uns hauptsächlich auf den durch die Kommunikation zwischen den Shards verursachten Overhead konzentrierten. Beide Simulationen lieferten uns Ergebnisse, die entweder erwartet oder positiv waren. Die Ergebnisse werden formalisiert und tragen zu unserer laufenden Arbeit bei.

Konsens

Die Consensus Group ist eine neu gegründete Gruppe, die sich mit allen Fragen im Zusammenhang mit Consensus Changes befasst. Als solche ist sie eine interdisziplinäre Gruppe, die sich derzeit hauptsächlich mit der Implementierung und dem Testen der modularen Konsensänderungen und des Like-Switch, der Simulation von OTV, dem Verfassen eines Artikels über OTV und der Diskussion weiterer Ideen zur Vereinfachung und Verbesserung des Protokolls beschäftigt.

Auf der Grundlage des Multiversum-Simulators baut das Team einen allgemeinen Simulationsrahmen auf, der uns dabei helfen wird, den Konsensmechanismus, seine Vorteile und seine Grenzen genau zu verstehen. Es wird auch als Schlachtfeld für verschiedene Angriffe auf reines OTV und OTV mit FPCS als Mechanismus zum Aufbrechen der Metastabilität und potenziell andere dienen. Derzeit befindet sich der Simulationsrahmen noch in einem sehr frühen Stadium und es können noch keine aussagekräftigen Ergebnisse erzielt werden. In naher Zukunft wird uns das Framework dabei helfen, fundierte Entscheidungen über Parametereinstellungen zu treffen (z. B. wann sollte FPCS eingeschaltet werden?), ein Gefühl für Bestätigungszeiten bei verschiedenen Manaverteilungen und Anweisungsraten zu bekommen und Inhalte für unsere Veröffentlichungen über OTV zu liefern.

Das Team diskutiert auch über weitere Vereinfachungen des Protokolls. Zum Beispiel haben wir mit dem „Like“-Schalter jetzt eine klare Trennung zwischen Genehmigungsgewicht (AW) für Zweige und Marker. Durch die Verwendung einer einzigen Marker-Sequenz zur Annäherung an AW können wir diese Komponenten trennen, die AW-Berechnung beschleunigen und die Dinge leichter verständlich machen. Darüber hinaus diskutieren wir den Begriff des aktiven cMana (cMana, das bei aktuellen Konflikten/Nachrichten berücksichtigt wird) und die Beendigung des Konsenses, da die Verfolgung des schwersten Zweigs ein nie endendes Abstimmungsschema ist, genau wie die Regel der längsten Kette in Blockchains.

Kommunikationsschicht

Die Communication Layer Group ist ein weiteres neu gegründetes Team. Ihr Schwerpunkt liegt auf Kommunikations- und Synchronisationsthemen, die während der Forschung in der Networking- und der GoShimmer-Gruppe aufkamen.

In diesem Monat führte das Team Tests und Benchmarks für die kürzlich zum DevNet hinzugefügten Komponenten Scheduler und Rate Setter durch. Dabei wurden verschiedene virtuelle Netzwerkkonfigurationen eingerichtet, um zu überprüfen, ob die bestehende Implementierung den erwarteten Ergebnissen aus der Netzwerkforschung entspricht. Ein weiterer Aspekt dieser Tests war die Ermittlung potenzieller Leistungsengpässe in bestimmten Grenzszenarien.

Auf einer eher theoretischen Ebene haben wir verschiedene Zeitstempel-Methoden evaluiert. Zeitstempel ermöglichen den direkten Vergleich und die Ordnung von Nachrichten, was für eine Vielzahl von Komponenten hilfreich ist. Diese verschiedenen Methoden müssen im Hinblick auf ihre Präzision, Zuverlässigkeit und Rechenkomplexität bewertet werden.

Original by William Sanders: https://blog.iota.org/iota-research-status-update-september-2021/

2020 Zusammenfassung von Polkadot

Obwohl es für so ziemlich jeden ein hartes Jahr war (mit der möglichen Ausnahme von Amazon und Imbissbuden), kommen das Polkadot-Netzwerk und die Community mit viel Wind in den Segeln aus dem Jahr 2020. Jetzt, wo wir das Ende des Jahres 2020 erreicht haben, wollen wir eine Zusammenfassung dessen geben, was wir erreicht haben und was wir im Laufe des Jahres 2021 planen…

Ich neige dazu, diese Zusammenfassungen mit ein paar Statistiken zu beginnen, und dieses Jahr scheint keine Ausnahme zu sein. Die Entwicklung ist weiter vorangeschritten, und die Rust-Codebasis umfasst mittlerweile weit über eine halbe Million Codezeilen. Etwa die Hälfte der insgesamt 577 kLOC befinden sich im Substrate Repository, das mittlerweile von mehr als 1.000 Github-Benutzern geforkt wurde und 3.515 Sterne von Entwicklern aus aller Welt erhalten hat. Dieser Code wurde in fast 5.000 separaten Verbesserungen in den 3 Jahren, in denen es existiert, hinzugefügt. Über 2.600 Entwickler sitzen im technischen Kanal von Substrate, was fast eine Verdreifachung von weniger als 1.000 zu Beginn des Jahres bedeutet. „2020 Zusammenfassung von Polkadot“ weiterlesen

IOTA Forschungsstatus Update Februar 2021

Im vergangenen Monat haben wir weitere Fortschritte in unserem Pollen Testnetz gemacht, während wir uns dem Testnetz mit Anreizsystem nähren.

Es ist vielleicht ein guter Zeitpunkt, um einige Erwartungen zu formulieren, was wir von Nectar erwarten und lernen werden. Erstens: Nectar wird eine Beta Software sein, und als solche erwarten wir, dass wir einige Fehler sehen werden! Sie zu finden, ist der einzige Grund, warum wir überhaupt ein Testnetz eingerichtet haben. „IOTA Forschungsstatus Update Februar 2021“ weiterlesen

IOTA Forschungsstatus Update Dezember 2020

In diesem Monat hat unser Team weiterhin große Fortschritte bei unserem derzeitigen Hauptaugenmerk, der Pollen-Testnet-Implementierung von IOTA 2.0, erzielt. Wir arbeiten hart daran, die letzten verbleibenden Elemente der Spezifikation zu implementieren, was letztendlich unser nächster großer Meilenstein bei der Bereitstellung von IOTA 2.0 sein wird: Nectar.

Diese erste vollständige Implementierung von Nectar, die irgendwann im ersten Quartal erwartet wird, ist aus unserer Sicht eine wichtige Veröffentlichung, da sie im Wesentlichen unsere erste erfolgreiche Umsetzung der theoretischen Konzepte unserer Coordicide-Lösung darstellt.

Diejenigen, die diese vielen Monate der Coordicide-Entwicklung mit verfolgt haben, werden sicher die Bedeutung und unsere Aufregung über diese erste vollständige Coordicide-Implementierung verstehen. Mehr dazu folgt in Kürze!

Nachfolgend bieten wir unsere normalen Gruppen-Updates an, die einige Details über unseren Fortschritt in verschiedenen Bereichen enthalten. Zusätzlich zu den unten beschriebenen Fortschritten haben wir zwei Papiere, „On Fairness in Voting Consensus Protocols“ und „Committee selection in DAG distributed ledgers and applications“, zur Aufnahme in die Computing Conference 2021 angenommen. Wir freuen uns darauf, diese Papiere zu gegebener Zeit mit der Community zu teilen.

Pollen Testnet-Implementierung

Letzten Monat haben wir Pollen testnet v0.3.1 veröffentlicht. Die Hauptmerkmale dieses Updates sind das Refactoring der Nachrichtenstruktur gemäß dem neuen Tangle RFC und das Hinzufügen eines Community-basierten Einstiegsknotens. Sie können mehr darüber in unserem Blogpost zu den Release Notes lesen.

Das Team hat auch Fortschritte auf dem Mana-Zweig gemacht. Wir haben ein Tool hinzugefügt, mit dem man bestimmen kann, wie viel Zugangsmana generiert werden würde, wenn man Geld ausgibt. Wir haben einen neuen WeightedMana-Typ für Forschungszwecke hinzugefügt und die Schnittstellen BaseMana und BaseManaVector überarbeitet. Sowohl für Consensus als auch für Access Mana gibt es jetzt verbesserte Integrationstests. Wir haben uns auch darauf konzentriert, unsere forschungsorientierten Werkzeuge zu verbessern, wie z. B. eine neue Mana-Seite für den Pollen Analyzer sowie die Möglichkeit, Knoten basierend auf ihrem Mana einzufärben. Sie können mehr darüber in diesem Github-PR lesen.

Das Team hat sich darauf konzentriert, die Konsens-Implementierung durch die Einführung von FPC-Anweisungen zu optimieren. Das FPC-Protokoll erfordert, dass Knoten direkt zufällig ausgewählte Knoten zur Konfliktlösung abfragen. Die Informationen, die bei einem solchen Abstimmungsmechanismus entstehen, werden jedoch nicht im Tangle gespeichert, sondern befinden sich nur in den lokalen Metadaten des Knotens. Außerdem müssten die Knoten mit dem höchsten Mana auf zu viele Abfragen antworten, wenn das Quorum zur Abfrage zufällig proportional zum Mana gebildet wird, da ihre Wahrscheinlichkeit, im Quorum jedes Knotens enthalten zu sein, hoch ist. Die Idee des FPC-Statements ist es, jedem Knoten die freie Wahl zu lassen, ob er seine Meinung zu einem bestimmten Konflikt und einer bestimmten FPC-Runde in den Tangle schreibt, so dass andere Knoten seine Meinung erfahren können, ohne sie direkt anzufragen. Sie können mehr darüber in diesem Spezifikationsdokument lesen.

Ein weiterer wichtiger Meilenstein, den das Team erreicht hat, ist die Implementierung von Markern. Der Marker ist ein Werkzeug, um Wissen über die Struktur des Tangles in Bezug auf vergangene/zukünftige „Kegelmitgliedschaften“ abzuleiten. Um zu wissen, ob eine Nachricht im Tangle verwaist ist oder nicht, führen wir Finalitätsgrade ein, um den Status einer Nachricht zu interpretieren. Der Grad der Endgültigkeit wird durch das Zustimmungsgewicht bestimmt, welches der Anteil der aktiven Konsensmänner ist, die eine bestimmte Nachricht genehmigen. Um das Zustimmungsgewicht einer bestimmten Nachricht zu berechnen, muss man das Tangle von der Nachricht bis zu den Spitzen durchlaufen und das aktive Konsensmana aller Nachrichten in seinem zukünftigen Kegel aufsummieren. Der Marker kann die Zustimmungsgewichtung einer Nachricht effizient abschätzen und so den Teil des Tangles reduzieren, den wir durchlaufen müssen.

Schließlich haben sich viele Mitglieder unserer Community zusammengetan, um das erste IOTA Community-basierte dRNG-Komitee zu gründen. Das ist eine großartige Leistung und zeigt wirklich, wie sehr unsere Community ein fundamentaler und integraler Bestandteil dieses Prototyping-Prozesses ist.

Pollen Testnet Studiengruppe

Diesen Monat haben wir weiter den Einfluss von Mana auf das Autopeering untersucht. Wir sind mit den bisherigen Ergebnissen recht zufrieden, vor allem in Bezug auf Sybil-Schutz und Netzwerkdurchmesser. Eine unwissenschaftliche, aber dennoch anschauliche Animation eines erfolglosen Sybil-Angriffs auf das Autopeering finden Sie hier.

Wir haben zwei Hauptkandidatenansätze dafür betrachtet, wie Mana den Autopeering-Auswahlprozess beeinflussen sollte. Unsere Ergebnisse zeigen, dass beide Ansätze in gewisser Weise „äquivalent“ sind und wir daher den Kandidaten verwenden können, der einfacher zu implementieren und robuster gegenüber möglichen Unterschieden in der Mana-Wahrnehmung ist. In der Zukunft sind weitere quantitative Ergebnisse zu erwarten – eine gründliche Studie ist im Gange, aber eine solche Analyse benötigt einen angemessenen Zeitrahmen.

Vernetzung

Im Netzwerkteam führen wir Simulationen durch, um den Staukontrollmechanismus zu validieren. Wir belasten den Algorithmus unter extremen Bedingungen (Ring, kompletter Graph) oder sehr starken Angriffen (böswillige Knoten, die das Netzwerk spammen und kontinuierliches, wiederholtes Spamming mit mehreren Knoten). In unseren umfangreichen Simulationen hat sich der Algorithmus als robust gegenüber all diesen Umständen erwiesen und ist bereit, im Pollen-Testnetzwerk implementiert zu werden. Darüber hinaus forschen wir an einer Möglichkeit, die Adoptionsbarriere in Coordicide zu senken und den Zugang zu Knoten mit niedrigem Mana in unbelasteten Perioden zu garantieren.

An der VDF-Front untersuchen wir eine Möglichkeit, die Multi-Exponentierungs-Operation (entscheidende Operation bei der VDF-Berechnung) durch Montgomery-Reduktion zu beschleunigen. Wir haben sie in Open SSL implementiert, und unsere ersten Ergebnisse zeigen bis zu 6-fache Verbesserungen im Vergleich zu einem Szenario ohne die Reduktion.

Sharding

Im letzten Monat haben wir uns einige Second-Layer-Lösungen näher angesehen, insbesondere für Daten. Wir haben eine Idee diskutiert, die wir vorübergehend „Data Sharding“ nennen und die die Menge der auf dem Tangle gespeicherten Daten stark erhöhen würde. In diesem Vorschlag würden die Leute den Großteil ihrer Daten auf separaten Tangles der zweiten Schicht speichern. Hashes von Nachrichten aus diesen Tangles der zweiten Schicht würden auf dem Haupt-Tangle gepostet werden, um die Daten zu sichern.

Wir haben sorgfältig einen Vorschlag geschrieben, der Data Sharding zusammenfasst, so dass wir diese Idee analysieren und weitere Forschungsfragen identifizieren können. Wir diskutieren auch die Rolle, die Data Sharding in IOTAs Sharding-Vision spielen wird.

Wenn Sie Fragen haben oder einfach nur hallo sagen möchten, finden Sie die Mitglieder unseres Forschungsteams im #tanglemath-Kanal auf unserem Discord. Sie sind auch herzlich eingeladen, unseren technischen Diskussionen in unserem öffentlichen Forum zu folgen und sich daran zu beteiligen: IOTA.cafe.

Original: https://blog.iota.org/iota-research-status-update-december-2020-c69bb28a0456/

Was ist Ethereum 2.0 und warum ist es wichtig?

TL;DR

Ethereum 2.0 ist ein lang ersehntes Upgrade des Ethereum (ETH)-Netzwerks, das erhebliche Verbesserungen der Funktionalität und Erfahrung des Netzwerks als Ganzes verspricht. Einige der bemerkenswerteren Upgrades umfassen eine Verlagerung auf Proof of Stake (PoS), shard chains und eine neue Blockchain im Kern, die so genannte Beacon Chain. Es wird erwartet, dass all dies und mehr im Rahmen eines sorgfältig geplanten Fahrplans schrittweise eingeführt wird.

Aber das ist nur die Spitze des Eisbergs. Da Ethereum eine der populärsten Krypto-Währungen auf dem Planeten ist, gibt es wichtige Details darüber, was Ethereum 2.0 wirklich ist und wie es sich auf das Krypto-Versum als Ganzes auswirken wird.

Einführung

Seit der Veröffentlichung von Ethereum hat die Entwicklung neuer Technologien in Form von dezentralisierten Anwendungen (Dapps) und anderen Blockchains stark zugenommen. Noch wichtiger ist, dass viele dieser Technologien auf das Ethereum-Netzwerk aufgesetzt wurden. Denken Sie an einige der größten Innovationen der dezentralisierten Finanzen (DeFi) – ein bedeutender Teil davon läuft auf dem Ethereum-Netzwerk.

Leider traten allmählich Skalierbarkeitsprobleme auf. Mit der Zunahme der Anzahl der Transaktionen im Ethereum-Netzwerk stiegen auch die Kosten für die Durchführung dieser Transaktionen (die mit Gas bezahlt werden). Wenn Ethereum die Plattform sein soll, die die nächste Generation des Internets einläuten soll, dann muss die Ökonomie Sinn ergeben. Andernfalls wird die Nutzung unpraktisch.

An dieser Stelle kommt Ethereum 2.0 ins Spiel. Die vorgeschlagenen ETH-2.0-Upgrades für das Ethereum-Netzwerk sollen in erster Linie die Frage der Skalierbarkeit lösen. Diese Verbesserungen bilden einen Kontrast zur bestehenden Version von Ethereum, die alle im Rahmen einer sorgfältig geplanten Roadmap eingeführt werden sollen.

 

Was ist Ethereum 2.0?

Ethereum 2.0 (aka Eth2 oder „Serenity“) ist das lang erwartete Upgrade des Ethereum-Netzwerks, das unter anderem eine Verbesserung der Skalierbarkeit des Netzwerks verspricht. Durch die Implementierung verschiedener Erweiterungen sollen Geschwindigkeit, Effizienz und Skalierbarkeit verbessert werden, ohne dabei die Sicherheit und Dezentralisierung zu opfern.

Diese Version von Ethereum war schon immer in Sicht, aber es hat einige Jahre gedauert, bis sie eingeführt wurde. Der Hauptgrund dafür ist, dass die Skalierung einer Blockchain auf sichere und dezentralisierte Weise eine anspruchsvolle Aufgabe ist.

Dankenswerterweise zielt Ethereum 2.0 darauf ab, dieses Problem durch die Implementierung einiger sehr wichtiger Funktionen zu lösen. Diese neuen Funktionen schaffen einige wesentliche Unterschiede zwischen dem Ethereum, das wir kennen, und dem Ethereum, das wir erwarten sollten.

Unterschiede zwischen Ethereum und Ethereum 2.0

Die größten Unterschiede zwischen Ethereum und Ethereum 2.0 liegen in der Verwendung des Proof of Stake (PoS)-Konsensmechanismus, der shard chains und der Bakenchain. Schauen wir uns diese Unterschiede genauer an.

Proof of stake

Proof of Work (PoW) ist Ethereums (und vieler anderer Blockchains) Weg, das Netzwerk sicher und aktuell zu halten, indem es die Miner belohnt, die Blöcke auf der Blockchain erstellen und validieren. Leider ist PoW nicht skalierbar, da es mit zunehmender Größe der Blockchain immer mehr Rechenleistung erfordert.

Der Einsatznachweis (Proof of Stake, PoS) löst dies, indem die Rechenleistung durch „selbst investiert sein“ ersetzt wird. Das heisst, solange Sie mindestens 32 ETH haben, können Sie sie verpflichten (d.h. einsetzen), Validator werden und durch die Bestätigung von Transaktionen bezahlt werden. Wenn Sie einen tieferen Einblick in die Funktionsweise von PoS und Staking erhalten möchten, sehen Sie sich Proof of Stake Explained an.

Sharding

Jeder, der auf das Ethereum-Netzwerk zugreifen möchte, muss dies über einen Knotenpunkt tun. Ein Knoten speichert eine Kopie des gesamten Netzwerks, was bedeutet, dass der Knoten jede einzelne Transaktion seit Beginn der Existenz von Ethereum herunterladen, berechnen, speichern und verarbeiten muss. Während Sie als Benutzer nicht unbedingt einen Knoten ausführen müssen, nur um Transaktionen durchzuführen, verlangsamt dies alles.

Sharding chains sind genau wie jede andere Blockchain, außer dass sie nur bestimmte Teilmengen einer ganzen Blockkette enthalten. Dies hilft den Knoten, da sie nur einen Teil, oder Shard, des Ethereum-Netzwerks verwalten müssen. Dies sollte den Transaktionsdurchsatz und die Gesamtkapazität von Ethereum erhöhen.

Die beacon chain

Da Sharding chains parallel arbeiten, muss etwas dafür sorgen, dass sie alle miteinander synchron bleiben. Nun, die Signalkette sorgt dafür, indem sie einen Konsens für alle parallel laufenden Sharding chain herstellt.

Die Beacon chain ist eine brandneue Blockchain, die eine zentrale Rolle in Ethereum 2.0 spielt. Ohne sie wäre der Informationsaustausch zwischen den shards nicht möglich und die Skalierbarkeit wäre nicht gegeben. Aus diesem Grund wurde erklärt, dass es das erste Feature sein wird, das auf dem Weg zu Ethereum 2.0 ausgeliefert wird.

Der Weg zum Ethereum 2.0

Die Einführung von Ethereum 2.0 wird nicht auf einmal erfolgen. Stattdessen wird es in drei Phasen herausgebracht, von denen jede einzelne mit bestimmten Merkmalen einhergeht, um den Erfolg des neuen Ethereum sicherzustellen.

Phase 0

Die erste Phase, oder Phase 0, wird der Freigabe der Beacon chain gewidmet sein, da sie für die Funktionalität von sharding von zentraler Bedeutung ist. Es wird noch keine Sharding chain geben, aber die Signalkette wird beginnen, Validatoren (d.h. Staker) durch einen Einwegpfandvertrag zu akzeptieren.

Es ist wichtig zu beachten, dass alle registrierten Validierer, die ihre ETH mit einem stack versehen, erst dann „entstapelt“ werden können, wenn die shard chain vollständig implementiert sind. Das bedeutet, dass die ETH von Validierern bis zur nächsten Phase eingesperrt sein wird.

Es wird erwartet, dass Phase 0 im Laufe des Jahres 2020 eingeführt wird.

Phase 1/1,5

Die nächste Phase ist eigentlich ein Mix aus zwei Phasen: Phase 1 und Phase 1.5. In Phase 1 werden Shard chains eingeführt, die es den Validatoren erlauben, Blöcke auf der Blockchain durch PoS zu bilden. In Phase 1.5 wird das Hauptnetz von Ethereum die shard chains offiziell einführen und den Übergang vom PoW zum PoS beginnen.

Es wird erwartet, dass Phase 1/1.5 im Laufe des Jahres 2021 eingeführt wird.

Phase 2

Die letzte Phase wird Phase 2 sein, in der Ethereum 2.0 voll ausgebildete shards unterstützt und zum offiziellen Ethereum-Netzwerk wird. Shard chains werden auch mit intelligenten Verträgen arbeiten können, so dass Entwickler von Dapps und anderen Technologien sich nahtlos in Ethereum 2.0 integrieren können.

Es wird erwartet, dass Phase 2 2021 oder später eingeführt wird.

Abschließende Gedanken

Ethereum 2.0 ist aus einer Reihe von Gründen ein wichtiges Upgrade des Ethereum-Netzwerks, insbesondere im Hinblick auf die Skalierbarkeit. Ohne die neuen Funktionen des PoS, des shardings und der beacons könnte Ethereum irgendwann nicht mehr zukunftsfähig sein und nicht mehr die führende intelligente Vertragsplattform im Krypto-Ökosystem sein.

Die Einführung von Eth2 wird einige Zeit in Anspruch nehmen, und es könnte sogar länger dauern als erwartet. Die gute Nachricht ist, dass sie bereits in vollem Gange ist, und die Entwickler von Ethereum sind entschlossen, sie zu Ende zu führen.

Haben Sie noch Fragen zu Ethereum 2.0 und digitalen Assets? Schauen Sie sich unsere Q&A-Plattform Ask Academy an, wo die Binance-Community Ihre Fragen beantworten wird.

Original Binance: https://academy.binance.com/en/articles/what-is-ethereum-2-0-and-why-does-it-matter

Aktueller Stand der IOTA-Forschung – Oktober 2020

Wir freuen uns, die folgenden Aktualisierungen von mehreren unserer Gruppen weiterzugeben. Es war ein arbeitsreicher Monat für alle im Team. Zusätzlich zu der unten beschriebenen Arbeit waren wir auch mit der Planung unseres nächsten ReSum-Treffens beschäftigt, das Ende des Monats stattfinden wird.

Wir laden die gesamte Community ein, sich der AMA mit dem IF-Team anzuschließen, das am kommenden Mittwoch (14. Oktober) um 13.00 Uhr MESZ | 7.00 Uhr EST auf Reddit stattfindet. Wir werden Ihre Fragen zu Coordicide beantworten.

Hier die Updates!

Pollen-Testnet-Implementierung

Diesen Monat hat sich das Team darauf konzentriert, die gesamte GoShimmer-Codebasis zu bereinigen. Wir verfolgen einen ähnlichen Ansatz wie das Hornet-Team, indem wir die Paketstruktur verflachen. Dies wird sich positiv auf den Entwicklungsfortschritt auswirken und die Konsistenz zwischen den beiden Projekten erhöhen. Wir haben einen neuen Abschnitt in unserem Wiki hinzugefügt, um unseren Ansatz zur Fehlerbehandlung zu beschreiben.

Nachdem die Mana-Spezifikations-Implementierung fertig geschrieben war, begann das Team mit der Implementierung. Wir haben uns auf die grundlegenden Mana-Funktionen wie Manaberechnungen, Metrik-Sammlung und eine erste Integration mit dem neuen Transaktionslayout und der neuen Wallet konzentriert. Wir haben neue APIs hinzugefügt, um sowohl das Abrufen Mana-bezogener Informationen – wie Rohwerte für Zugriffs- und Konsensmana pro Node, Perzentil- und Höchstwerte – als auch die Angabe der ID des Knotens beim Verpfänden von Mana während der Ausgabe einer Werttransaktion zu ermöglichen.

Angesichts der Bedeutung von Mana in unserer Coordicide-Lösung haben wir damit begonnen, einige Visualisierungstools zu entwickeln, die in das lokale Dashboard der Nodes eingebettet sind, um seine Funktionsweise besser darzustellen, sowie eine Reihe von Überwachungsinstrumenten zur Untersuchung seiner Dynamik. Sie können einen Einblick in diese Arbeit in den Bildern unten sehen.

Coordicide IOTA Dashboard

Darüber hinaus haben wir diesen Monat an zwei neuen RFCs gearbeitet, die sich noch im Entwurf befinden und die sich damit befassen, wie ein Konsens über Zeitstempel erreicht werden kann und wie die Konfliktlösung durch das Schreiben von FPC-Stellungnahmen in dem Tangle optimiert werden kann. Sie können diese hier und hier einsehen.

Unter dem Gesichtspunkt der kontinuierlichen Integration/des kontinuierlichen Einsatzes (Continuous Integration/Continuous Deployment, CI/CD) haben wir den Einsatz von Snyk in unsere Pipeline integriert. Seine Integration hat bereits dazu beigetragen, einige Sicherheitsprobleme innerhalb der JWT-Bibliothek aufzudecken, die wir derzeit zum Schutz des Zugangs zu den APIs verwenden. Dieses Tool wird uns dabei helfen, unseren Code während seiner gesamten Entwicklung sicherer zu machen.

Das dRNG-Experiment, das im vergangenen Monat mit dem von der Community gesteuerten GoShimmer X-Team begonnen hat, war voll und ganz erfolgreich! Die Community schaffte es, ein verteiltes Komitee von 7 Mitgliedern zu schaffen und gemeinsam alle 10 Sekunden ohne Unterbrechung neue Zufälligkeiten zu erzeugen, und das schon seit mehr als 2 Wochen. Unten sehen Sie einen Screenshot von einigen der Zufälligkeiten, die im lokalen Dashboard des GoShimmer angezeigt werden:

dRNG Beacon

Wir überwachen ständig die Leistung unserer dRNG-Lösung auf der Grundlage des drand-Projekts. Innerhalb der letzten 2 Wochen konnte das verteilte Komitee ein schwellenwertbasiertes Unterschriftenschema (4 von 7) ausführen und die jeweiligen Beiträge austauschen, um eine neue Zufälligkeit unter 300 ms im Durchschnitt zu erzeugen, wie Sie aus dieser Darstellung ersehen können.

Beacon delay

Was die nächsten Schritte betrifft, so werden wir sehr bald eine neue Pollen-Testnet-Version v0.3.0 mit dem Community-getriebenen dRNG als Standard veröffentlichen.

Pollen-Testnet-Studiengruppe

Da die Implementierung des Pollen-Testnetzes voranschreitet und immer mehr der Coordicide-Module integriert werden, ist es an der Zeit, das Testnetz richtig zu analysieren. Für uns Forscher sind dies aufregende Zeiten!

Coordicide umfasst viele Module, die wir auf Papier entwickelt und studiert und durch Simulationsstudien als eigenständige Module validiert haben. Es ist an der Zeit, all diese verschiedenen Module ineinandergreifen zu sehen und als Ganzes zum Leben zu erwecken.

Das Armaturenbrett in Pollen bietet bereits einen ausgezeichneten Überblick über die verschiedenen Komponenten und ihre Leistung in Pollen. Während diese Informationen viele gute Indikatoren für das ordnungsgemäße Funktionieren des Testnetzes liefern, besteht das Endziel dieser Gruppe darin, wissenschaftlich fundierte Beweise für die Behauptungen von Coordicide zu erhalten. Wir freuen uns darauf, demnächst weitere Ergebnisse zu diesem Unterfangen zu veröffentlichen!

Protokoll

In diesem Monat setzte die Protokollgruppe ihre Arbeit zur Klärung der wenigen letzten verbleibenden theoretischen Fragen zu IOTA 2.0 fort. Eines der Hauptthemen, das wir besprachen, war die Synchronisierung zwischen Knoten und Werkzeugen, mit denen der Knoten erkennen kann, ob er nicht synchron ist. Abgesehen davon entwickelten wir die Spezifikationen zum Bootstrapping weiter und vertieften unsere Diskussionen über das spieltheoretische Verhalten der Tip-Auswahl. Obwohl der URTSA (Uniform Random Tip Selection Algorithm) sehr gut funktioniert, ist er aufgrund der Freiheitsphilosophie der IOTA nicht durchsetzbar, so dass es letztlich dem Knotenoperator überlassen bleibt, welchen er verwendet. Die Forschung über TSAs muss sicherstellen, dass der TSA die beste Option ist, die ein Knoten unter Standardannahmen verwenden kann.

Nächsten Monat wollen wir die mathematische Untersuchung der TSA abschliessen und unsere Schlussfolgerungen in die entsprechenden Spezifikationen einfliessen lassen.

Vernetzung

Wir konzentrieren unsere Bemühungen auf eine umfassende Angriffsanalyse des Staukontrollalgorithmus. Insbesondere haben wir durch Simulationen nachgewiesen, dass Angreifer weder die Fairness (die Anforderung, dass ein Knoten Nachrichten proportional zu seinem Mana sendet) noch die effiziente Nutzung der verfügbaren Kommunikations- und Verarbeitungsressourcen der Knoten beeinträchtigen können. Wir untersuchen derzeit ausgefeiltere Angriffe, bei denen böswillige Knoten verschiedene Nachrichtenströme an verschiedene Nachbarn aussenden, um die Konsistenz zu beeinträchtigen. Vorläufige Ergebnisse zeigen, dass geeignete Richtlinien zur Nachrichtenabgabe und Schwarze Listen wirksame Gegenmaßnahmen sind.

Wir freuen uns, mitteilen zu können, dass unser Forschungspapier „Healthor: Protecting the Weak in Heterogeneous DLTs with Health-aware Flow Control“ (Schutz der Schwachen in heterogenen DLTs durch gesundheitsbewusste Flusskontrolle) zur Veröffentlichung auf dem 4. Workshop über skalierbare und belastbare Infrastrukturen für verteilte Ledger (SERIAL 2020) angenommen wurde. Die Arbeit zeigt, wie es möglich ist, unseren Staukontrollalgorithmus im Falle einer intermittierenden Konnektivität durch Rückkopplung von benachbarten Knotenpunkten anzupassen.

Zusätzlich entwerfen wir einen verteilten Zufallszahlengenerator (dRNG) auf der Basis verifizierbarer Verzögerungsfunktionen, der als zweite Zufallsquelle verwendet werden kann (die erste Zufallsquelle in Coordicide stammt von einem dRNG, der auf Schwellenwertkryptographie basiert).

Sharding

Wie vielen unserer Gemeindemitgliedern inzwischen bekannt ist, haben wir unseren Sharding-Ansatz, den wir Fluid Sharding nennen, genau unter die Lupe genommen. Unser Ziel beim Fluid Sharding ist es, das skalierbarste Basisschicht-DLT zu bauen, das man überhaupt bauen kann. Es genügt zu sagen, dass dies keine kleine Aufgabe ist, obwohl wir sehr zuversichtlich sind, dass unser Team dazu in der Lage ist! Es ist wahrscheinlich, dass wir beide Skalierbarkeitsschienen parallel verfolgen werden. Einen Überblick über diesen Ansatz auf hoher Ebene finden Sie hier.

Als wir begannen, uns formeller mit diesem Thema zu befassen, haben wir eine umfassende Literaturrecherche zu bestehenden Ansätzen und Lösungen durchgeführt, um sicherzustellen, dass unser Team auf dem neuesten Stand der Forschung über Sharding ist. Unser Ziel war es, die aktuelle Forschung zu untersuchen, um auch die Sicherheit unserer eigenen Lösung zu verbessern.

Unsere Leser sind wahrscheinlich mit dem Begriff der Skalierungslösungen der ersten und zweiten Schicht vertraut, und wir sind dabei, diese beiden Ansätze zur Skalierbarkeit in IOTA zu integrieren. Fluid Sharding bezieht sich auf unsere Skalierungslösung der ersten Schicht. Wir sehen uns auch das, was wir als „Datensharding“ bezeichnen, als eine Art Lösung der zweiten Schicht genau an.

Unsere Gespräche mit verschiedenen Interessenvertretern von IOTA waren fruchtbar, da wir verstanden haben, dass das Datensharding in der Tat vielen Bedürfnissen normaler Benutzer und Anwender in Unternehmen gleichermaßen dient. Wir glauben, dass letztendlich beide Lösungen entwickelt werden und zusammen werden sie das umfassen, was man als eine „vollständig gesharte“ IOTA 3.0 bezeichnen könnte.

Vielen Dank für die Lektüre, und wenn Sie Fragen haben oder einfach nur Hallo sagen möchten, finden Sie unsere Forschungsteammitglieder im Kanal #tanglemath auf unserer Seite Discord.

Sie sind auch willkommen, unsere technischen Diskussionen in unserem öffentlichen Forum zu verfolgen und daran teilzunehmen: IOTA.cafe.

Original Übersetzt von Serguei Popov: https://blog.iota.org/iota-research-status-update-october-2020-e8b279176f51

Einführung von Pollen: Das erste dezentralisierte Testnetz für IOTA 2.0

Original by IOTA Foundation: https://blog.iota.org/introducing-pollen-the-first-decentralized-testnet-for-iota-2-0-349f63f509a1 (20.06.2020)

Nach Jahren intensiver Forschung, rigoroser Tests und unermüdlicher Bemühungen unserer Ingenieure sind wir stolz darauf, endlich alle zur Teilnahme an diesem bedeutenden Meilenstein für das IOTA-Projekt einladen zu können. Pollen markiert den Beginn des weltweit ersten wirklich dezentralisierten, skalierbaren und gebührenfreien Distributed Ledger, das von Anfang an das Versprechen der IOTA war. Pollen ist die erste Phase der dreiteiligen Freigabestrategie von IOTA, die in unserem koordinatorenlosen, produktionsbereiten Netzwerk gipfeln wird: IOTA 2.0. Pollen ist ein sich rasch entwickelndes Forschungs-Testbed, in dem die Gemeinschaft, Forscher und Ingenieure die Konzepte von IOTA 2.0 testen und validieren können.

Sie können die neue Version herunterladen und das vollständige Changelog hier einsehen.

Pollen stellt ein wichtiges Upgrade im Vergleich zur vorherigen Version Alphanet v0.1.3 dar. Wir zählen ungefähr 60000 Hinzufügungen und 25000 Löschungen in der Codebasis. Wir haben die Grundlage für ein funktionales Netzwerk ohne Koordinator geschaffen. Von hier aus werden iterative Verbesserungen des Codes Pollen in den endgültigen, funktionsreichen Release-Kandidaten für IOTA 2.0 verwandeln.IOTA Update 2.0

Die heutige Veröffentlichung enthält die folgenden Aktualisierungen der Hauptfunktionen:

  • Fast Probabilistic Consensus – der neue Konsens-Algorithmus für IOTA für ein dezentralisiertes Netzwerk. Sie können das Forschungspapier hier lesen
  • Werttransaktionen – Netzwerkteilnehmer können jetzt einen automatisierten Hahn benutzen, um Tokens zu empfangen, Werttransaktionen zu senden (über eine Brieftasche) und die Konfliktlösung im Netzwerk zu testen
  • Tokenisierte Vermögenswerte – Einzelpersonen können jetzt IOTA-Token mit verschiedenen Attributen „einfärben“, die reale Vermögenswerte wie Gebäude, IoT-Geräte oder sogar Firmenkapital repräsentieren
  • Prometheus- und Grafana-Integration – Knotenbetreiber können jetzt mehrere Metriken überwachen, indem sie ein Grafana-Dashboard aktivieren
  • Feeless dApps – diese Version beinhaltet eine zukünftige Fähigkeit für das IOTA-Ökosystem: die Entwicklung von gefühllosen dezentralisierten Anwendungen

Wir haben auch bereits früher veröffentlichte Funktionen der letzten Version von Alphanet verbessert. Dazu gehören eine verbesserte Stabilität und Instrumentierung sowohl des Autopeering- als auch des Klatschmoduls. Wir haben ein erweitertes Dashboard mit einem brandneuen Tangle-Explorer und Visualizer gebaut. Der Analyseserver wurde von Grund auf neu gestaltet, um nicht nur die Visualisierung und Analyse des Autopeering-Netzwerks zu unterstützen, sondern auch die Echtzeit-Aktualisierung des Fast Probabilistic Consensus-Protokolls in Aktion.

Dashboard GoShimmer

Unser Interesse an diesem Testnetz wird sich auf das Gesamtverhalten des Netzwerks konzentrieren und nicht auf seine rohe Leistung und Benutzererfahrung. Wir werden in künftigen Iterationen schrittweise an Optimierungen und Verbesserungen arbeiten. Was die Implementierung betrifft, so stecken die neu eingeführten Komponenten noch in den Kinderschuhen (z.B. Brieftaschenbibliothek, FPC) und einige Komponenten sind noch nicht optimiert (z.B. Klatsch und Tratsch). Bitte beachten Sie, dass wir das Netzwerk von Zeit zu Zeit zurücksetzen werden, bis lokale Snapshots implementiert sind, um zu verhindern, dass die Datenbank zu stark wächst und um potentiell brechende Änderungen einzuführen.

Mit dieser neuen Version haben wir eine neue Architektur eingeführt, die aus drei separaten Schichten besteht: Der Netzwerk-, Kommunikations- und Anwendungsschicht. Diese neue Architektur wird Unterstützung für zukünftige Funktionen wie Tokenisierung, skalierbare intelligente Verträge, Feeless dApps und Sharding bieten.

IOTA Update 2.0

Es gibt Parallelen zwischen unseren Schichten und den oberen Schichten des OSI-Modells, obwohl wir den Leser vor tiefgreifenden Vergleichen warnen. Die Netzwerkschicht verwaltet die Verbindungen und die Paketübertragung zwischen den Knoten. Die Kommunikationsschicht schafft eine standardisierte Plattform für die Speicherung und Kommunikation von Informationen. Den Entwicklern steht es dann frei, dezentralisierte Anwendungen auf der Anwendungsschicht zu entwerfen und gleichzeitig die unteren Schichten zu abstrahieren. Um mehr darüber zu erfahren, können Sie unseren Blogpost „A Guide to Upcoming IOTA 2.0 Terminology“ lesen.

IOTA Pollen Update

Der Kern von Pollen besteht aus diesen Merkmalen:

  • Neues Nachrichten-Layout – Jede Nachricht enthält die Hashes der Eltern, Ausgabeinformationen (Ausgabeknoten-ID, Zeitstempel usw.), eine Nutzlast, den PoW, eine Nonce und die Signatur des Ausgabeknotens
  • Binär – Da jetzt alles binär ist, haben wir eine neue konfigurierbare Proof of Work (PoW)-Bibliothek entwickelt, die in zukünftigen und iterativen Versionen auf unseren adaptiven PoW-Mechanismus umgestellt wird. Wir haben die Unterstützung für traditionelle Public-Key-Kryptographie auf der Basis elliptischer Kurven (z.B. Ed25519 und BLS) sowie binäre Hash-Funktionen wie SHA-256, SHA-512 und Blake2b integriert
  • Ledger-Zustand & UTXO – Diese GoShimmer-Version wird mit einem völlig neuen Ledger-Zustand ausgeliefert, der auf einer erweiterten Version von UTXO basiert – dem auf Parallel-Realität basierenden Ledger-Zustand. Durch die Entkopplung von Konsens und Saldenverfolgung ermöglichen wir ein unübertroffenes Maß an Flexibilität und reduzieren die Komplexität der Nachrichten massiv, indem nur über Konflikte abgestimmt wird
  • FPC – Das Fast Probabilistic Consensus-Protokoll treibt den Konsens unseres Testnetzes voran. Für diese erste „Vanille“-Version des Protokolls lassen wir Knoten FPC auslösen, falls bei der Erstarrung Konflikte festgestellt werden. Die ersten Meinungen basieren auf den Ankunftszeiten der Nachrichten. Neue Knoten, die online gehen, erhalten die Nachrichten jedoch nicht in der richtigen Reihenfolge und können daher zu einer falschen Meinung kommen. In zukünftigen Versionen werden wir einen Synchronisationsmechanismus hinzufügen, der diese Diskrepanzen verhindern wird
  • Zufälligkeit – Die von FPC verwendete Zufälligkeit wird lokal von jedem Knoten auf der Grundlage des Unix-Zeitstempels generiert. Genauer gesagt wird jede Minute in Epochen von 5 Sekunden eingeteilt. Es liegt auf der Hand, dass die durch diese Methode erzeugte Zufallszahlenfolge vorhersehbar und somit unsicher ist. Aufgrund ihrer Einfachheit und Unabhängigkeit vom Netzwerk oder einer anderen Komponente eignet sie sich jedoch sehr gut für einen ersten Test des FPC-Verhaltens. Die nächste Iteration wird sich auf ein gemeindebasiertes Komitee dRNG stützen
  • Lokales Dashboard – Wir haben das Dashboard um einen brandneuen Tangle-Explorer, Tangle Visualizer und Faucet bereichert
  • Grafana-Dashboard über Prometheus – Jeder Knotenbetreiber kann das Prometheus-Plugin aktivieren und Grafana zur Anzeige von Metriken zum Netzwerkverkehr, Autopeering-Status, FPC-Statistiken und mehr verwenden
  • Netzwerk-Verzögerungsanwendung – Wir werden periodisch eine spezifische Netzwerk-Verzögerungsmeldung an das gesamte Netzwerk senden. Dadurch werden die Knoten, die sie empfangen, veranlasst, den Zeitstempel des Empfangs an einen zentralen Logger zu senden, so dass wir periodisch die durchschnittliche netzwerkweite Verzögerung beurteilen und diese Information zur Optimierung der Abstimmung der FPC-Parameter verwenden können.
  • Brieftaschenbibliothek – Wir stellen eine sehr einfache Brieftaschenbibliothek zur Verfügung, damit Entwickler und Tester Token verschieben können. Sie können gerne mit einer Wallet-UI beitragen, die auf dieser Bibliothek basiert
  • (Faucet)Zapfhahn-App – Das GoShimmer-Dashboard wird mit einer Zapfhahn-Sektion geliefert, so dass Sie Token an eine bestimmte Adresse anfordern können
  • Client-Bibliothek & API – Tester, Entwickler und Knotenbetreiber können über die Client-Bibliothek und/oder API mit einem GoShimmer-Knoten interagieren. Um mehr darüber zu erfahren, können Sie sich auf unserer Wiki-Seite informieren.
  • Analyse-Server – Wir haben auch den Analyse-Server verbessert. Dieser zeigt den Gesamtnetzwerkstatus an und hat einen brandneuen Abschnitt, der den Gesamtnetzwerkkonsens anzeigt – ein Echtzeit-Update des FPC-Ergebnisses zu jedem Konflikt. Diese Ergebnisse werden in einer Datenbank gespeichert, so dass wir zusammen mit unserer Gemeinschaft genügend experimentelle Daten sammeln können, um sie mit unseren früheren, durch Simulationen erzielten Ergebnissen zu vergleichen.

Wir haben ein Wiki geschrieben, um der Gemeinschaft die Möglichkeit zu geben, diese Version des Pollen-Testnetzes auszuprobieren und mehr über sie zu erfahren:

Mit unserem nächsten großen Release, genannt Nectar, werden die übrigen Komponenten (wie Mana, Ratenkontrolle, adaptives PoW, um nur einige zu nennen) für ein voll funktionsfähiges, mit Anreizen versehenes Testnetz auf unser Testnetz freigegeben.

Pollen ist ein wichtiger Meilenstein für IOTA 2.0. Es ist ein wesentlicher Schritt zur Erprobung der Kernideen des vollständig dezentralisierten IOTA-Netzes.

Wir freuen uns darauf, Sie auf dieser aufregenden Reise mit Pollen mit uns zu begleiten, und wir hoffen, dass Sie die Entwicklung dieses Projekts ebenso genießen werden wie wir. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im Kanal #tanglemath auf unserer Discord. Sie können auch an der #goshimmer-Diskussion auf Discord teilnehmen.

Skalierung IOTA Teil 2 – Das Gewirr entwirren (Untangling the Tangle)

Original by Hans Moog: https://medium.com/@hans_94488/scaling-iota-part-2-untangling-the-tangle-3a6ed2303b3c (21.04.2020)

Um die im ersten Teil dieses Blogbeitrags erwähnten Probleme zu lösen, brauchen wir eine völlig andere Form des shardings.

In den folgenden Abschnitten werden wir eine schrittweise Einführung in die Konzepte geben, die es IOTA ermöglichen, die Anzahl der Knoten unendlich zu skalieren, ohne die Sicherheit in den frühen Phasen der Einführung zu gefährden oder in den Durchsatzanforderungen in „Versorgungsschocks“ zu zerfallen.

Der Tangle shards (Scherbt) automatisch

Der Tangle ist nicht durch eine Blockgröße begrenzt, und jeder kann jederzeit neue Transaktionen anhängen, ohne sich auf etwas anderes als die beiden vorangegangenen Ereignisse, auf die es sich bezieht, verlassen zu müssen. Das bedeutet, dass das Tangle im Wesentlichen nie voll ist und eine beliebige Anzahl von Transaktionen enthalten kann.

Wenn der Netzwerkdurchsatz die Verarbeitungskapazitäten der Knoten übersteigt, sehen und verarbeiten die Knoten unterschiedliche Transaktionen, je nachdem, wo im Netzwerk sie sich befinden, und sehen daher auch einen unterschiedlichen Tangle. Knoten mit ähnlichen Verarbeitungsfähigkeiten, die nahe beieinander liegen, werden eine ähnliche Wahrnehmung haben.

Jeder Knoten wird seinen jeweiligen Teil der DAG validieren, der aus einer Teilmenge aller vorhandenen Transaktionen besteht. Dies ist die eigentliche Definition von Sharding: „Teilen Sie die Aufgaben auf und sorgen Sie dafür, dass jeder Knoten nur eine Teilmenge der Gesamtarbeitsmenge durchführt.

Das folgende Bild zeigt, wie ein solches natürlich zersplittertes Gewirr aussehen würde (die Hälfte der Transaktionen wird von der Hälfte der Knoten verarbeitet):

Hard Netzwerk im Tangle

Dieser Aufspaltungsprozess kann rekursiv erfolgen, so dass z.B. Scherben 1 in weitere Scherben zerfällt, wenn die Knoten nicht in der Lage sind, alle verbleibenden Transaktionen zu verarbeiten. Die verschiedenen Netzsegmente werden zu unterschiedlichen Zeiten, je nach dem tatsächlichen Durchsatz, mehr oder weniger augenblicklich aufgeteilt, ohne dass komplizierte Verhandlungen darüber geführt werden müssen, wann und wo aufgeteilt werden soll. Es hängt einfach davon ab, welche Transaktionen die Knoten verarbeiten können (agentenzentrierter Ansatz).

Sobald die Last sinkt, sind die verschiedenen Tangle theoretisch (siehe Probleme unten) in der Lage, wieder miteinander zu verschmelzen, was zu einem System führt, das in der Lage ist, dynamisch auf unterschiedliche Netzwerkbedingungen und wachsende Akzeptanz zu reagieren.

Probleme mit diesem Ansatz

Diese Lösung ist zwar extrem einfach und erlaubt es dem Netzwerk theoretisch, auf eine beliebige Anzahl von Transaktionen pro Sekunde zu skalieren, sie hat aber auch einige sehr ernste Probleme:

  1. Die Knotenpunkte haben keine Vorstellung davon, für welchen Teil des Gewirrs sie verantwortlich sind. Folglich wäre es für die Benutzer schwierig zu wissen, welchen Knoten sie wählen müssen, wenn sie versuchen, auf ihre Gelder zuzugreifen.
  2. Es wird für die verschiedenen Scherben schwierig, miteinander zu interagieren, da es keine objektive Wahrnehmung darüber gibt, welche Scherben überhaupt existieren.
  3. Da die verschiedenen Tangle zwar die gleiche Geschichte, aber nicht die gleichen Prüfer haben, könnte man Gelder, die man vor der Teilung erhalten hat, doppelt ausgeben, und zwar für jeden Scherben getrennt – siehe Abbildung:

sharding Netzwerk iota Problem

Dieses Problem der doppelten Mittelverwendung ist ziemlich schwerwiegend, da es sogar verhindert, dass die Verwicklungen wieder zusammenfließen (sobald die Belastung sinkt), was das volle Potenzial der Lösung untergräbt.

Der Grund für diese Probleme liegt jedoch nicht in der Struktur der DAG selbst (wie in diesem Video von RADIX behauptet), sondern in der Tatsache, dass das Knäuel im Wesentlichen völlig unkontrolliert und zufällig zersplittert.

Lösung der genannten Probleme

Um diese Probleme zu lösen, müssen wir einen Weg finden, wie die Knoten auf nicht-zufällige und deterministische Weise zersplittert werden können. Das bedeutet, dass wir im Wesentlichen einen Mechanismus finden müssen, der es uns ermöglicht, Knoten und ihre Transaktionen einem bestimmten Ort im zersplitterten Netzwerk zuzuordnen.

Um dies zu erreichen, bringen wir jeden Knoten und jede Transaktion dazu, eine Markierung zu tragen, die definiert, zu welchem Scherben sie gehören (noch bevor sich irgendwelche Scherben entwickeln). Wenn die Notwendigkeit einer Aufspaltung entsteht, spaltet sich die DAG auf und der Ledger-Zustand teilt sich mit ihr.

Schauen wir uns das gleiche Beispiel an, aber diesmal mit jeder Transaktion, die eine Markierung (blau oder rot) trägt:

sharding iota Netzwerk Lösung

Anfänglich sind die Transaktionen der verschiedenen Scherben „verschränkt“, aber nach der Aufspaltung des Gewebes werden die roten Knoten nur rote Salden und Transaktionen verfolgen und die blauen Knoten nur ihren jeweiligen Anteil. Dieser einfache Mechanismus beseitigt die Möglichkeit, alte Gelder doppelt auszugeben, ohne eine komplizierte Form der Kommunikation zwischen den Scherben einzuführen. Jede Scherbe hat eine bestimmte Zuständigkeit, für die er verantwortlich ist, und ein Benutzer, der versucht, blaue Gelder in den roten Scherben auszugeben, wird einfach ignoriert. Dieser Mechanismus wird als staatliches Sharding bezeichnet.

In dem Beispiel haben wir Farben verwendet, aber die Markierungen sind eigentlich nur Zahlen, die durch eine Bitmaske dargestellt werden können, die es dem Gewirr erlaubt, beliebig oft zu sharpen (eine 64-Bit-Markierung würde es uns zum Beispiel erlauben, mehr als 9 Fünflinge zu erzeugen).

Die Scherben-Markierung wird so etwas wie die Scherben-DNA einer Transaktion, die alle Informationen enthält, die sie benötigt, um ihre zukünftige Position in einer erwachsenen DAG zu bestimmen. In seinem kindlichen Zustand wird diese Information latent vorhanden sein, aber sie wird es dem Tangle ermöglichen, zuverlässig zu sharpen, sobald der Bedarf entsteht.

Da die Ledger-Zustände der beiden Zweige niemals in Konflikt geraten können, können diese Scherben jetzt sogar zu einem späteren Zeitpunkt, wenn die Belastung sinkt, wieder zusammenfließen.

Eine logische Überlagerungskartierung der „realen Welt

Die Scherbenmarkierungen lösen alle oben genannten Probleme, aber darüber hinaus geben sie uns auch ein sehr leistungsfähiges Werkzeug an die Hand, mit dem wir ein Scherbenlayout entwerfen können, das die reale Welt als eine Art logisches Overlay-Mapping widerspiegelt, was letztendlich bedeutet, dass wir den Zahlen, die die Scherbenmarkierungen darstellen, eine gewisse Bedeutung geben können.

Da wir ein Protokoll für das Internet der Dinge entwerfen, macht es sehr viel Sinn, eine geographische Kartierung zu verwenden, bei der die Scherbenmarkierungen in bestimmte Koordinaten auf diesem Planeten übersetzt werden. Auf diese Weise werden Knoten, die physisch nahe beieinander liegen, Teil desselben Scherbens sein.

Auf diese Weise werden nicht nur die Netzwerklatenzen innerhalb eines Shards reduziert, sondern auch die Kommunikation zwischen den Shards auf ein absolutes Minimum reduziert, da die meisten wirtschaftlichen Aktivitäten lokal stattfinden:

  • Ein Auto kauft Strom von einer Ladestation in der Nähe
  • Die Leute kaufen Pizza in der Pizzeria um die Ecke
  • und so weiter …

Diese geographische Überlagerungskartierung ist daher eine sehr gute Annäherung an die wirtschaftlichen Beziehungen in einer bestimmten Region.

Darüber hinaus ist diese Verwendung einer geographischen Kartierung eine gute Möglichkeit, mit großräumigen Netzwerkspaltungen umzugehen. Wenn ein Netzwerksegment z.B. aufgrund von Dingen wie dem Dritten Weltkrieg offline geht, dann kann niemand chinesische Gelder in den USA ausgeben und umgekehrt. Die beiden getrennten Netzwerke haben daher eine höhere Chance, wieder zusammenzuschließen, sobald die Spaltung aufgelöst ist.

Wenn die Scherbenmarkierungen alle genannten Probleme lösen … sind wir dann fertig? Noch nicht, noch nicht! Es gibt noch einige Probleme, die gelöst werden müssen:
Bevor wir Scherbenmarkierungen einführten, scherten die Knoten automatisch auf der Grundlage ihrer eigenen Verarbeitungsmöglichkeiten. Dieser Mechanismus macht jedoch keinen Sinn mehr, da wir versuchen, die Knoten entsprechend ihrer Zugehörigkeit zu einer bestimmten Jurisdiktion zu sharpen.

Die Knoten müssen daher eine Form von Konsens darüber haben, wann und wo sie gesplittet werden sollen. Dies ist ein kniffliges Problem, zumal die Knoten völlig unterschiedliche Verarbeitungsfähigkeiten haben und daher auch unterschiedliche Auffassungen darüber haben, wann der Zeitpunkt zum Teilen gekommen ist.

Das Gewirr entwirren

Da wir die Mechanismen einfach halten wollen und nicht noch einen weiteren Konsensmechanismus über das Gewirr hinaus einführen wollen, müssen wir einen anderen Ansatz finden, um mit diesem Problem umzugehen.

Wenn wir uns die Scherbenmarkierungen anschauen und was es eigentlich „bedeutet“, für jeden Scherben getrennte Untermarkierungen zu haben, dann erkennen wir ziemlich schnell, dass es uns genau einen Vorteil bringt: Die Knoten, die verarbeiten, d.h. der rote Scherben, haben eine Möglichkeit, nur die roten Transaktionen zu identifizieren, herunterzuladen und zu verarbeiten, ohne dass sie mit Transaktionen von anderen Scherben verstrickt werden.

Wenn der einzige Zweck der getrennten Unter-Dreiecke darin besteht, zusammenhängende Transaktionen zu trennen, dann können wir dasselbe erreichen, indem wir die Spitzenauswahl wie folgt modifizieren:

Wenn wir eine neue Transaktion mit einer Scherbenmarkierung X anhängen, dann wählen wir eine Spitze als Zweig, der eine Scherbenmarkierung Y hat, wobei Y ≤ X und einen Stamm, der eine Scherbenmarkierung Z hat, wobei Z ≥ X.

Was wir am Ende erhalten, ist eine DAG, die entsprechend den Markierungen im Gewirr vorverteilt ist. Wenn wir dem referenzierten Zweig folgen, können wir Transaktionen mit einer gleichen oder kleineren Markierung entdecken, und wenn wir dem Stamm folgen, können wir Transaktionen mit einer gleichen oder höheren Markierung entdecken – siehe Bild (mit Farben anstelle von Zahlen für die Markierungen):

Lösung von Tangle sharding iota

Auch wenn die Grafik nicht mehr in verschiedene Zweige aufgeteilt ist, können wir immer noch Transaktionen, die gleiche Marker tragen, auf die gleiche Weise identifizieren, überprüfen und verfestigen, als ob sie tatsächlich aufgeteilt wären.

Beim Verfestigen des Gewirrs hören die Knoten auf, die fehlenden Transaktionen abzufragen, sobald sie eine Markierung erreichen, an der sie nicht interessiert sind, und betrachten diese Transaktionen einfach als verfestigt. Da der „blaue Ledger-Zustand“ nur von „blauen Transaktionen“ betroffen sein wird, hat das Ignorieren der roten Transaktionen keine nachteiligen Auswirkungen auf einen blauen Knoten.

Flüssigkeitsscherben

Die beschriebene Art und Weise, das Gewirr zu entwirren, befreit nicht nur von der Notwendigkeit, einen Konsens darüber zu erzielen, wann und wo gespalten werden soll, sondern gibt den Knotenpunkten auch die völlige Freiheit zu wählen, an welchem Teil der resultierenden DAG sie interessiert sind und wie viel der DAG sie sehen und verarbeiten wollen, ohne dass sie ein vorgegebenes Scherbenlayout benötigen.

IoT-Bausteine mit beschränkten Ressourcen können einen kleineren Teil des DAG überwachen als leistungsfähigere Knoten. Die Scherben sind daher nicht mehr isolierte Datenblöcke, sondern kontinuierliche Regionen, wobei die Knoten in der Lage sind, verschiedene Teile je nach ihrem Interesse (Standort in der realen Welt) zu validieren – siehe Bild:

knoten sharding iota
Die grünen Kästchen stellen Knoten dar, die unterschiedliche „Standorte“ und unterschiedliche Beobachtungsradien haben.

Beispiel: Eine Person, die zwischen Ost- und West-Berlin lebt, könnte sich dafür entscheiden, der Hälfte von Ost- und der Hälfte von West-Berlin zu „folgen“, während eine Person, die im Zentrum von West-Berlin lebt, sich dafür entscheiden könnte, stattdessen nur West-Berlin zu folgen.

Wir sind auch in der Lage, durch Veränderung des Beobachtungsradius die Größe der überwachten Scheibe entsprechend den Durchsatzanforderungen im Netzwerk anzupassen.

Beispiel: Knoten in einer Region mit sehr geringer wirtschaftlicher Aktivität könnten es sich leisten, eine viel größere „Scheibe“ der DAG zu überwachen als Knoten, die in einem dicht besiedelten Gebiet mit relativ mehr Transaktionen operieren.

Durch die Verwendung einer Prioritätswarteschlange für die empfangenen Transaktionen – die die empfangenen Transaktionen nach ihrer Entfernung vom Standort eines Knotens im Netzwerk sortiert – verringern die Knoten automatisch ihren Beobachtungsradius, wenn sie überlastet werden, und filtern Transaktionen von zu weit entfernten Knoten heraus. Sie werden daher sofort auf unterschiedliche Durchsatzanforderungen reagieren, ohne dass sie ein neues Sharing-Layout neu verhandeln oder Gebühren verwenden müssen, um zu entscheiden, welche Transaktionen ausgeführt werden sollen. Die Lösung wird agentenzentriert und ermöglicht es uns, sofort auf unterschiedliche Belastungen im Netzwerk zu reagieren.

Schlussfolgerung

Wir haben ein paar sehr einfache Änderungen an der Funktionsweise des Gewirrspiels vorgenommen. Diese Änderungen ermöglichen es uns, die Transaktionen in der DAG zu entwirren und sie nach ihrer Beteiligung an den entsprechenden Scherben zu gruppieren.

Anstatt einfach viele Verwicklungen parallel laufen zu lassen (wie bei Blockchains), erlaubt uns diese neue Art des flüssigen Scherbens, weiterhin ein großes kontinuierliches Gewirr zu verwenden, das sich über die ganze Welt erstreckt und immer noch in der Lage ist, eine beliebig große Anzahl von Transaktionen pro Sekunde zu verarbeiten.

Am Anfang, wenn die Akzeptanz noch gering ist, werden die meisten Knoten höchstwahrscheinlich alle Transaktionen sehen und verarbeiten, aber sobald die Akzeptanz wächst und die Durchsatzanforderungen die Verarbeitungskapazitäten der Knoten übersteigen, werden wir sehen, wie die Knoten ihren Wahrnehmungsradius langsam verringern, um die höhere Last zu bewältigen.

Im 3. Teil dieses Blogbeitrags, der demnächst veröffentlicht wird, werde ich erklären, wie Transaktionen zwischen entfernten Scherben funktionieren werden und wie ein kontinuierliches Gewirr es uns ermöglicht, einen ähnlichen Mechanismus wie eine Bakenkette zu implementieren, jedoch ohne Bakenkette, wodurch eine echte „unendliche“ Skalierbarkeit (mit der Anzahl der Knoten) erschlossen wird.

 

Skalierung IOTA Teil 1 – Ein Leitfaden zum Thema Sharding

Original by Hans Moog: https://medium.com/@hans_94488/scaling-iota-part-1-a-primer-on-sharding-fa1e2cd27ea1 (21.04.2020)

In den folgenden Blogbeiträgen werden einige der grundlegenden Ideen und Konzepte vorgestellt, die hinter einer neuen Sharing-Lösung(schieben/etwas verlegen) für den IOTA-Tangle stehen. Wir werden erörtern, wie der vorgeschlagene Mechanismus funktioniert und warum bestimmte Entscheidungen beim Entwurf dieser Lösung getroffen wurden.

Obwohl dieses Thema noch erforscht wird und sich einige der Details im Laufe der Forschung ändern könnten, ist es dennoch reif genug, um offen diskutiert zu werden, und wir freuen uns auf Rückmeldungen.

Motivation

Eines der größten Probleme von DLT ist heute der begrenzte Durchsatz von Transaktionen pro Sekunde, den die Netzwerke verarbeiten können. Wenn die Nachfrage höher ist als die Verarbeitungskapazitäten, dann führt die Dynamik von „Angebot und Nachfrage“ zu höheren Gebühren und längeren Bestätigungszeiten. Dies wiederum senkt die Nachfrage, indem es das Netzwerk für seine Benutzer etwas weniger „attraktiv“ macht.

Diese Art der „Verwaltung“ der Ressourcen eines Netzwerks funktioniert ziemlich gut, um das Netzwerk funktionsfähig zu halten, aber die dynamischen Gebühren sind ein sehr reales Problem für die Benutzererfahrung und machen es extrem schwierig, darauf zuverlässige Anwendungen für die reale Welt aufzubauen (siehe den jüngsten Zusammenbruch des MakerDAO-Systems, das auf Ethereum aufbaut).

Aufgrund seiner Nullgebühren leidet IOTA offensichtlich nicht unter diesen schwankenden Kosten für die Ausstellung einer Transaktion. Dennoch haben IOTA-Nodes eine Obergrenze für Transaktionen pro Sekunde (TPS), die sie verarbeiten können. Wie wird IOTA also auf diese Unterschiede in Angebot und Nachfrage reagieren, ohne dass das Netzwerk zusammenbricht?

Lassen Sie uns zunächst einen Blick auf die Gründe für diese Beschränkungen werfen und wie andere Projekte dies angehen.

Gründe und Umgehungsmöglichkeiten für diese Einschränkung

Der Hauptgrund für diese Durchsatzbeschränkung ist die Tatsache, dass jeder Knoten im Netzwerk jede einzelne Transaktion verarbeiten muss und dass die Hardwarekapazitäten der Knoten begrenzt sind. Um den Durchsatz zu optimieren, gibt es nur zwei Möglichkeiten:

  1. Delegieren Sie die gesamte Berechnung an einen kleineren Satz sehr leistungsfähiger Nodes (d.h. Hashgraph, EOS usw. …)
  2. Teilen Sie die Aufgaben auf und lassen Sie jeden Knoten nur eine Teilmenge der Gesamtarbeit ausführen

Der erste Ansatz könnte zwar das Problem für eine Weile lösen, indem er den Durchsatz auf ein Niveau erhöht, das in naher Zukunft wahrscheinlich nicht überschritten wird, aber er löst das Problem selbst nicht wirklich. Mit zunehmender Akzeptanz werden die Netzwerke unweigerlich wieder mit den gleichen Einschränkungen konfrontiert werden. Ich neige daher dazu, diese Lösungen als Mikro-Optimierungen zu bezeichnen.

Der zweite Ansatz wird als Sharding bezeichnet und zeigt, wie beispielsweise Ethereum versucht, das Problem der Skalierbarkeit anzugehen. Anstatt eine einzelne Blockkette laufen zu lassen, plant man, 64 Blockketten parallel laufen zu lassen, wobei jeder Shard seine eigenen Validatoren hat. Diese Ketten sind völlig unabhängig, können aber über eine weitere Kette, die alle Scherben verbindet (die Bakenkette), interagieren.

Dies erhöht zwar in der Tat die Skalierbarkeit, hat aber immer noch die gleichen Probleme mit einer Obergrenze dafür, wie viele Transaktionen jeder Shard verarbeiten kann. Dies erfordert daher den gleichen Mechanismus dynamischer Gebühren, um Angebot und Nachfrage für den Durchsatz zu regulieren. Auch wenn dieser Ansatz einer tatsächlichen Lösung näher kommt (weil wir einfach die Anzahl der Scherben nach einigen Jahren mit steigender Annahme erhöhen können), so löst er dennoch nicht wirklich die Probleme der unvorhersehbaren Gebühren und Transaktionszeiten – er führt sogar einige neue Probleme ein.

Zusätzliche Probleme mit Sharding

Da die Entwerter auf alle bestehenden Ketten (einschließlich der Bakenkette) aufgeteilt werden müssen, wird jeder Scherben von weniger Entwertern als bisher gesichert werden. Die Sicherheit des Systems wird folglich geringer sein als in einer nicht abgeschirmten Umgebung. Dieses Problem besteht bei jeder Sharing-Lösung, da die eigentliche Idee des Shardens darin besteht, die Arbeit unter den Validierern aufzuteilen.

Blockketten haben jedoch zusätzliche technologiespezifische Probleme:

  • Der parallele Betrieb mehrerer Ketten erfordert einen Konsens über die Anzahl der Scherben, und eine Änderung dieser Anzahl ist nicht „on-the-fly“ möglich. Um zukunftssicher zu sein, ist es notwendig, das Netzwerk in mehr Scherben aufzuteilen, als der aktuelle Durchsatz erfordert, was vom ersten Tag an zu einer verminderten Sicherheit führt. Es ist unmöglich, dass das Netzwerk organisch auf die wachsende Akzeptanz oder auf unterschiedliche Netzwerkbedingungen reagiert.
  • Da der Durchsatz in jedem Shard durch Systemparameter wie Blockgröße und Blockzeiten definiert ist, muss jeder Knoten bestimmte Hardware-Anforderungen erfüllen, was die Teilnahme von IoT-Geräten mit geringer Leistung am Netzwerk verhindert.
  • Da wir die Anzahl der Shards nicht willkürlich erhöhen können (irgendwann wird die Bakenkette überlastet), bietet diese Lösung auch keine wirklich unbegrenzte Skalierbarkeit mit der Anzahl der Knoten.

Diese traditionelle Art des Shardens (durch einfaches Ausführen mehrerer Instanzen der gleichen Technologie) bietet daher keine Antwort auf die Vision der IOTA.

IOTAs Vision

Die Vision von IOTA ist es, eine DLT-Plattform bereitzustellen, die automatisch mit der wachsenden Verbreitung Schritt halten kann, indem sie einen immer höheren Durchsatz bietet, der mit der Anzahl der Knoten im Netzwerk skaliert. Gleichzeitig muss der verwendete Mechanismus flexibel und schnell genug sein, um auf Dinge wie Angebots- und Nachfrageschocks beim Netzwerkdurchsatz zu reagieren, so dass das Netzwerk funktionsfähig bleiben kann, ohne dass die Knoten über Gebühren entscheiden müssen, welche Transaktionen verarbeitet werden sollen.

Wenn man bedenkt, wie Sharing-Lösungen heute funktionieren, scheint dies ein schwieriges Problem zu sein, das nicht leicht zu lösen ist, und IOTA hat folglich viel Kritik dafür erhalten, dass sie sich öffentlich zu diesen Zielen bekennt, ohne jemals zu verraten, wie dies erreicht werden soll.

Viele Menschen halten dies immer noch für ein unlösbares Problem und geben IOTA die Schuld am Verkauf von Schlangenöl, und es gibt sogar ein Video, das scheinbar „beweist“, dass dieses Problem nicht gelöst werden kann (wir werden später noch einmal auf das beschriebene Problem zurückkommen).

Dieser Blog-Beitrag versucht nun endlich etwas Licht darauf zu werfen, wie die IOTA diese Skalierbarkeit zu erreichen gedenkt.

Anforderungen an die Vision der IOTA

Bevor ich damit beginne, die neuen Konzepte in den späteren Teilen dieses Blogbeitrags vorzustellen, möchte ich einen kurzen Umweg machen und einige der Anforderungen diskutieren, da sie sich direkt auf bestimmte Designentscheidungen der vorgeschlagenen Skalierungslösung auswirken:

  • Die Lösung muss eine Form von Scherbenbildung beinhalten, da Mikro-Optimierungen die Probleme nur verzögern, anstatt sie zu lösen
  • Die Lösung sollte Doppelausgaben verhindern, ohne sich auf eine komplizierte Form der Kommunikation zwischen den Shards zu verlassen (siehe das oben erwähnte Video)
  • Das Netzwerk sollte nur dann sharren, wenn es wirklich notwendig ist, wobei in Zeiten geringer Aktivität so viel Sicherheit des Systems wie möglich aufrechterhalten wird, aber gleichzeitig mit steigender Akzeptanz wachsen kann.
  • Das Sharding-Layout muss dynamisch genug sein, um sofort auf Veränderungen im Netzwerk reagieren zu können, ohne dass die Knoten miteinander „reden“ müssen, um ein neues Sharding-Layout auszuhandeln, oder Gebühren verwenden müssen, um festzulegen, welche Transaktionen bevorzugt werden sollen (agentenzentrierter Ansatz).
  • Das Sharding sollte ein „bedeutungsvolles Mapping“ der realen Welt verwenden (d.h. geographisches Mapping), so dass Knoten, die nahe beieinander liegen, immer in der Lage sind, direkt miteinander zu kommunizieren, ohne eine komplizierte Form der Kommunikation zwischen den Shards verwenden zu müssen.
  • Die Knoten sollten in der Lage sein, individuell zu entscheiden, wie viele und welche Daten sie verarbeiten wollen, so dass wir ein heterogenes Netzwerk mit IoT-Geräten mit geringer Leistung neben leistungsfähigeren Knoten haben können.
  • Die Knoten sollten in der Lage sein, sich frei zwischen Shards (mobilen Knoten wie Autos) zu bewegen, ohne plötzlich riesige Datenmengen herunterladen und validieren zu müssen.

Schlussfolgerung

Aufgrund des gefühllosen Charakters von IOTA haben wir sehr konkrete, aber komplexe Anforderungen an unsere Skalierungslösung, die uns daran hindert, bestehende Konzepte zu verwenden, und wir müssen einen völlig anderen Ansatz finden, der wesentlich flexibler sein muss als die traditionellen Methoden des Shardens.

Der 2. Teil dieses Blogbeitrags wird eine schrittweise Einführung in dieses neue Sharding-Konzept geben (von den ersten abstrakten Ideen bis zu einer konkreten Lösung).