Archive Adaptive PoW

Ein Rate-Control-Algorithmus für mehr Schutz und Fairness im Tangle

Die IF erforscht neue Algorithmen um Überlastung bzw. Engpässe bei den Transaktionen im Tangle zu vermeiden. Bösartige Nodes, die Schäden per Spam, DOS Angriffe oder ähnliches verursachen, müssen daran gehindert werden das Netzwerk negativ zu beeinflussen. Daher ist ein Steuermechanismus für die Transaktionsrate der einzelnen Nodes von grundlegender Bedeutung, damit der Tangle in Zukunft geschmeidig funktioniert. Über diese Standardanforderung der Anti-Spam-Technik gegen bösartige Nodes hinaus will die IF einen Algorithmus entwickeln, der ein gewisses Maß an Fairness erreicht und garantiert, dass Nodes mit geringer Rechenleistung immer noch eine hohe Wahrscheinlichkeit haben, dass ihre Transaktionen genehmigt werden. Die IF glaubt, dass dies grundlegende Voraussetzung sind, um die Technologieeinführung zu beschleunigen.

Ein erster möglicher Weg, um das Problem der Transaktionsraten Kontrolle im Tangle anzugehen, ist der Aufbau eines Reputationssystems für Nodes, welches diese bewertet und als „vertrauenswürdig“ oder ggf. als „nicht vertrauenswürdig“ einstuft, dazu soll ein „guter Ruf“ schwer zu bekommen, aber leicht zu verlieren sein. Wenn ein Node eine ungültige Transaktion genehmigt, versucht, das Netzwerk zu spammen, oder ein ähnlich schlechtes Verhalten zeigt, wird dieser von anderen Nodes identifiziert und digital gebrandmarkt. Infolgedessen ist dieser Node als „nicht vertrauenswürdig“ eingestuft und seine Transaktionen werden mit sehr hoher Wahrscheinlichkeit nicht genehmigt.

Ein Reputationssystem ist jedoch nur ein universeller Ansatz, der daher nicht speziell auf die Transaktionsraten Kontrolle ausgerichtet ist. Aus diesen Gründen erforscht die IF einen neuartigen anpassungsfähigen Transaktionsraten Regelungsalgorithmus, der auf den folgenden Ideen basiert:

  • ein gewisser Rechenaufwand ist erforderlich, um eine Transaktion durchzuführen
  • der Rechenaufwand, der erforderlich ist, um mehrere Transaktionen in einem kurzen Zeitintervall durchzuführen, steigt schrittweise an
  • während schnelle Nodes häufiger Transaktionen ausgeben können, ist bei Nodes mit geringer Rechenleistung dennoch gewährleistet, dass ihre Transaktionen mit hoher Wahrscheinlichkeit genehmigt werden


Die beiden Hauptbausteine des Algorithmus, die zur Erreichung der oben genannten Ziele notwendig sind, ist es jedem Node eine globale Identität zuzuweisen und der tatsächliche anpassungsfähige Transaktionsraten Kontrollmechanismus, der auf unterschiedlichen Proof-of-Work Schwierigkeiten basiert. Globale Node Identitäten sind zwingend notwendig, um einen Transaktionsraten Kontrollmechanismus in einem verteilten System zu implementieren. Wenn jeder Node eine Identität hat, kann die Public-Key-Kryptographie verwendet werden, um eine Transaktion zu signieren und diese manipulationssicher mit seinem ausgebenden Node zu verbinden. Durch die Einführung von Identitäten, wird ein verteiltes System anfällig für *Sybil-Attacken, bei denen eine bösartige Entität viele gefälschte Identitäten maskiert und diese nutzt, um die Transaktionsraten Kontrolle zu überwinden und einen koordinierten Angriff zu starten oder das Netzwerk zu spammen.

*Sybil-Attacke ist ein Angriff auf Peer-to-Peer-Netzwerke durch die Erstellung falscher Identitäten. Die Attacke kann etwa darauf abzielen, Mehrheitsabstimmungen und die Netzwerk-Organisation zu beeinflussen, das Netzwerk gezielt zu verlangsamen, die Vernetzung im Netzwerk zu stören, oder etwa Kommunikation zwischen anderen Peers abzuhören.

Die IF möchte einen solchen Sybil-Angriff durch das sogenannte Ressourcen-Testen erschweren, bei dem jede Node Identität den Besitz bestimmter schwer zu erwerbenden Ressourcen nachweisen muss. Die IF hat sich entschieden in ihrem Algorithmus, eine bestimmte Anzahl von Iota-Token als Ressource/Sicherheit (Stake) vorzuschreiben und eine vereinfachte Version des Proof-of-Stake zu implementieren. Das sind notwendige Voraussetzung für jede Node mit Identität und nur Nodes mit einem Mindestbetrag an Iota-Token als Sicherheit dürfen Transaktionen durchführen, die Anzahl der Iota-Token (Stake) wird dabei nicht verringert. Der neuartige anpassungsfähige Proof-of-Work ermöglicht es jedem Node, Transaktionen auszugeben und gleichzeitig Spamming-Aktionen zu bestrafen.

Als zusätzliche Sicherheitsmaßnahme möchte die IF, dass die Gesamtzahl, der von einem Node ausgegebenen Transaktionen begrenzt ist. Je größer die Sicherheit (Stake) eines Nodes ist, desto höher ist die Anzahl der Transaktionen, die derselbe Node ausgeben kann. Diese Schwelle bringt zwei Vorteile, zum einen stellt sie sicher, dass selbst ein Benutzer mit unendlicher Rechenleistung das Netzwerk nicht willkürlich spammen kann und zum anderen kann eine richtige Wahl der Schwelle die Sybil-Angriffe minimieren.


Fazit

Die Diskrepanz zwischen kleineren Universalgeräten und optimierter Hardware in Bezug auf die Proof-of-Work Leistung liegt in der Geschwindigkeit der Berechnungen. Daher würde jede auf dem Proof-of-Work basierende Transaktionsraten Kontrolle letztendlich kleinere Ressourcen arme Geräte nicht berücksichtigen. Umgekehrt würde ein rein Stake-basiertes System zu einer Zentralisierung führen, an der nur die “reichen” Nutzer (Nodes) teilnehmen können.

Quellen

https://blog.iota.org/whos-in-who-s-out-a-rate-control-algorithm-for-the-tangle-c7b5ecf85677

Sharding: Durchsatz, Skalierbarkeit und warum wir sie brauchen

05.11.2021

Übersetzung des IOTA Blogartikel.

TL;DR

Bei Distributed-Ledger-Technologien bezeichnet Skalierbarkeit die Fähigkeit eines Systems, seinen Durchsatz zu erhöhen, wenn mehr Nachfrage generiert wird. Die Skalierbarkeit stellt für Blockchain 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 näher auf die Unterschiede zwischen Skalierbarkeit und Durchsatz ein und untersuchen dann die Sharding-Lösung, bei der Messages nur an eine Teilmenge der Netzwerkknoten übermittelt werden, wodurch die Redundanz reduziert und ein Hochleistungsnetzwerk aufgebaut wird.

Vor langer Zeit waren Tangle City und Las Iota durch eine zweispurige Autobahn verbunden. Dies 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 dem Highway 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 pro Zeiteinheit im Netz verarbeitet, validiert und übermittelt werden können, und wird in Bytes pro Sekunde gemessen (im Falle von Messages variabler Größe ist die allgemein verwendete Metrik Transaktionen pro Sekunde nur ein Näherungswert für die 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 Nodes. Während die beiden Bürgermeister den Durchsatz durch den Ausbau der bestehenden Straßeninfrastruktur verbesserten, erreichte die wachsende 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 erweitern (und zu schrumpfen), 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 Message, die auf eine Bestätigung warten, und der Anzahl der Nodes im Netzwerk bleiben der Gesamtdurchsatz und die Finalitätszeit unverändert. Einige neuere Lösungen haben versucht, dieses Problem zu überwinden, indem sie z. B. das Lightning Network auf dem 2-Layer hinzugefügt haben, um Zahlungskanäle außerhalb der Chain zu schaffen und so die Belastung der Main-Chain zu verringern.

Durch die Auslagerung von Transaktionen auf einen anderen Layer lässt sich zwar der Gesamtdurchsatz leicht erhöhen, aber das Problem der Skalierbarkeit der Main-Chain ist damit noch nicht gelöst: Das Öffnen und Schließen von Lightning-Kanälen erfordert immer noch jeweils eine Transaktion auf dem Base-Layer. Selbst wenn also der Base-Layer nur zum Öffnen und Schließen von Lightning Kanälen verwendet wird und alle anderen Transaktionen in den Lightning Kanälen stattfinden, wäre die Skalierbarkeit immer noch auf die Anzahl der Lightning Kanäle 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 Ebene von Hochgeschwindigkeits-Autobahnspuren über der eigentlichen Autobahn hinzugefügt, aber die Leute müssen immer noch die gleichen Onramps nehmen, um überhaupt auf die Autobahn zu gelangen, bevor sie die Hochgeschwindigkeitsspuren nutzen können.

Andere Lösungen gehen nicht dazu über, den Durchsatz auf zusätzliche Layer auszulagern, sondern rühmen sich mit der Fähigkeit der Main Chain, mehrere hunderttausend Transaktionen pro Sekunde zu unterstützen. 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 Nodes ü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 realisieren ist und deren Abzweigungen 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 erhalten?


Die populärsten Lösungen für die Skalierbarkeit von DLTs werden durch ein Konzept namens Sharding repräsentiert – die Aufteilung der Gesamtmenge an 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 zur Erleichterung der Datenreplikation einzusetzen. 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 Nodes, nur eine Teilmenge der im Netzwerk ausgetauschten Messages zu validieren und zu speichern. Da die Redundanz reduziert wird, steigt die Zahl der Messages, 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 Gesamt-Stack (bei Proof-of-Stake und ähnlichen Systemen) ist. Durch die Aufteilung des Transaktionsvolumens in kleine Einheiten besteht die Gefahr, dass auch die Sicherheitsmerkmale aufgeteilt werden und somit die Sicherheit jedes einzelnen Shards 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 Messages 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 Leaderless-Protokoll (dt. Führerlos-), was bedeutet, dass jede Node eine andere Wahrnehmung des Status Quo des Ledger-State 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 Messages eine schnellere Finalität!

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 immer vorhandenen Netzwerk-Overhead und die Tatsache, dass die Nodes in einem Peer-to-Peer-Netzwerk normalerweise mit mehreren Nodes verbunden sind. In der Praxis müssten solche konkurrierenden Netzwerke darauf angewiesen sein, dass sich die Knoten mindestens 10 Gbit/s-Verbindungen 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.



Quellen

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


IOTA-Area-Codes (IACs)

Das IOTA Protokoll ist sehr flexibel und kann auf verschiedene Arten verwendet werden. Zwei verschiedene Arten der Übertragung sind möglich, die Wert Transaktion mittels des Iota-Token und die Message (Null-Wert, Daten/Informationen). Das IOTA Protokoll kann leicht erweitert werden, indem eine zweite Ebene (second layer) über dem Basisprotokoll erstellt wird, sowohl IOTA Streams als auch Flash-Channels sind perfekte Beispiel für solche Lösungen.

Die IF in Person von Lewis Freiberg (Director of Ecosystem) schlägt eine weitere second layer Lösung vor, die IOTA-Area-Codes (IACs) ermöglichen den Aufbau von IOTA-basierten Anwendungen mit geografischen Bezug. IOTA Transaktionen könnten aufgrund geographischer Merkmale getaggt und/oder abgerufen werden.


Was sind IOTA-Area-Codes (IACs)?

IACs sind kurze, tryte-codierte Standortcodes, mit denen IOTA-Transaktionen, die sich auf bestimmte Standorte beziehen, gekennzeichnet und abgerufen werden können.

Die IACs sind typischerweise 10 Trytes lang und repräsentieren einen Bereich von 13,5 m x 13,5 m, mit einer weiteren Stelle (11 Trytes) lässt sich ein Raster von 2,8m x 3,5m darstellen. IACs sind eine direkte Kopie der Open Location Codes, auch Plus Codes genannt, die 2014 von Google Zürich vorgeschlagen wurden. Es gibt einige geringfügige Änderungen, um sie mit der Codierung von IOTA kompatibel zu machen.

Bei der Veröffentlichung von Informationen über IOTA gibt es derzeit keine Möglichkeit, Transaktionen, die sich auf ein geografisches Gebiet beziehen, leicht zu identifizieren. Um Transaktionen zu finden, die sich auf einen geografischen Bereich beziehen, müssen Sie Ihre Transaktionen bei einem zentralen Dienst registrieren, beispielsweise einem Datenmarktplatz, der Standortdaten sammelt, speichert und an die Verbraucher weitergibt.

Die IACs ermöglichen es jemandem, eine Transaktion zu finden, die sich auf kleine Gebiet beziehen aber der wahre Wert dieses Systems ergibt sich aus der Fähigkeit, große Flächen für verwandte Transaktionen abzufragen.

IACs sind derzeit dazu gedacht, ein Katalysator für die Community zu sein. Der Standard, in seinem aktuellen Format, ist nützlich, könnte aber viel besser sein. Wir empfehlen Ihnen, beim Github vorbeizuschauen und einige Pull-Requests zu erstellen, um den Code zu verbessern oder Beispiele vorzuschlagen.

Demo Application, Github Library, NPM Repo

Verifiable Delay Function – Spamschutz

24. Dez’19

Bei der Umsetzung des Coordicide plant die IF den Einsatz von Adaptive PoW (weitere Informationen finden Sie sowohl im WP, als auch in einem Dokument, das in IEEE ICBC 2019 veröffentlicht wurde). Grundsätzlich ist die Idee, dass jede Node eine maximale erlaubte TPS besitzt, welche von seinem Mana abhängt. Die Schwierigkeit des PoWs zu lösen hängt vom Mana des ausgebenden Nodes ab und auf die Anzahl der vom Node im letzten Zeitfenster ausgegebenen Transaktionen.

Sobald ein Node/Benutzer mehr Transaktionen ausgeben möchte, muss er den Schwierigkeitsgrad des PoWs erhöhen. Dieser Mechanismus ist mit einem AIMD-basierten Mechanismus zur Überlastungsvermeidung gekoppelt, der Folgendes garantiert: dass (i) die Ressourcen nicht unzureichend genutzt werden, ii) das Netz nie überlastet ist und (iii) dass alle Nodes die gleiche Sicht auf den Tangle haben (Nodes sehen die gleichen eingehenden Transaktionen).

Als zukünftige Optimierung, ist geplant, PoW entweder durch VDF‘s (Verifiable Delay Function) zu ersetzen oder sogar komplett zu entfernen, falls der vorgeschlagene Mechanismus zur Überlastungskontrolle es allein schafft, mit Spam-Angriffen fertig zu werden. Die IF erforscht derzeit die mögliche Alternative zum PoW, die Verifiable Delay Function VDF (dt. verifizierbare Verzögerungsfunktion) genannt wird. Im Gegensatz zu PoW sind solche Funktionen nicht parallelisierbar, was den Einsatz von FPGAs ineffizient macht, um eine große Beschleunigung ihrer Berechnung zu erreichen.

Um VDF als Anti-Spam-Mechanismus für das Tangle verwendet zu können müssen größten Herausforderungen gemeistert werden, beispielsweise die Erzeugung eines RSA-Moduls auf verteilte Weise, das für die sichere Funktion des VDF erforderlich ist. Dieses Dokument schlägt einen Weg zur Lösung dieser Aufgabe vor: Download


Quelle

Offizieller IOTA Discord Kanal

Flash Channels

Flash-Channel ist die IOTA-Version von Bitcoin’s Lightning oder Ethereums Raiden. Es ist ein offline Zahlungskanal für Ein- und Auszahlungen, der sofortigen Transaktionen mit hohem Durchsatz ermöglicht. Dies ist möglich, da im IOTA-Tangle nur zwei Transaktionen stattfinden, nämlich das Öffnen und Schließen eines Flash-Kanals. Im Wesentlichen bieten sie den beiden Geschäftspartnern eine Möglichkeit, mit hoher Frequenz zu handeln, ohne darauf zu warten, dass jede Transaktion im öffentlichen IOTA-Netzwerk bestätigt wird.

Flash-Channel oder eine sehr ähnliche Funktion wird  irgendwann Teil von IOTA-Streams sein, zwei Personen können mithilfe von Mikrotransaktionen außerhalb des Tangle interagieren, indem sie im voraus Sicherheiten auf eine gegenseitig kontrollierte Adresse zur Verfügung stellen. Dies funktioniert jedoch nur für 1: 1 Zahlungen.


Quellen

www.iota.org

Adaptive PoW

Ein Rate-Control-Algorithmus für mehr Schutz und Fairness im Tangle

Die IF erforscht neue Algorithmen um Überlastung bzw. Engpässe bei den Transaktionen im Tangle zu vermeiden. Bösartige Nodes, die Schäden per Spam, DOS Angriffe oder ähnliches verursachen, müssen daran gehindert werden das Netzwerk negativ zu beeinflussen. Daher ist ein Steuermechanismus für die Transaktionsrate der einzelnen Nodes von grundlegender Bedeutung, damit der Tangle in Zukunft geschmeidig funktioniert. Über diese Standardanforderung der Anti-Spam-Technik gegen bösartige Nodes hinaus will die IF einen Algorithmus entwickeln, der ein gewisses Maß an Fairness erreicht und garantiert, dass Nodes mit geringer Rechenleistung immer noch eine hohe Wahrscheinlichkeit haben, dass ihre Transaktionen genehmigt werden. Die IF glaubt, dass dies grundlegende Voraussetzung sind, um die Technologieeinführung zu beschleunigen.

Ein erster möglicher Weg, um das Problem der Transaktionsraten Kontrolle im Tangle anzugehen, ist der Aufbau eines Reputationssystems für Nodes, welches diese bewertet und als „vertrauenswürdig“ oder ggf. als „nicht vertrauenswürdig“ einstuft, dazu soll ein „guter Ruf“ schwer zu bekommen, aber leicht zu verlieren sein. Wenn ein Node eine ungültige Transaktion genehmigt, versucht, das Netzwerk zu spammen, oder ein ähnlich schlechtes Verhalten zeigt, wird dieser von anderen Nodes identifiziert und digital gebrandmarkt. Infolgedessen ist dieser Node als „nicht vertrauenswürdig“ eingestuft und seine Transaktionen werden mit sehr hoher Wahrscheinlichkeit nicht genehmigt.

Ein Reputationssystem ist jedoch nur ein universeller Ansatz, der daher nicht speziell auf die Transaktionsraten Kontrolle ausgerichtet ist. Aus diesen Gründen erforscht die IF einen neuartigen anpassungsfähigen Transaktionsraten Regelungsalgorithmus, der auf den folgenden Ideen basiert:

  • ein gewisser Rechenaufwand ist erforderlich, um eine Transaktion durchzuführen
  • der Rechenaufwand, der erforderlich ist, um mehrere Transaktionen in einem kurzen Zeitintervall durchzuführen, steigt schrittweise an
  • während schnelle Nodes häufiger Transaktionen ausgeben können, ist bei Nodes mit geringer Rechenleistung dennoch gewährleistet, dass ihre Transaktionen mit hoher Wahrscheinlichkeit genehmigt werden


Die beiden Hauptbausteine des Algorithmus, die zur Erreichung der oben genannten Ziele notwendig sind, ist es jedem Node eine globale Identität zuzuweisen und der tatsächliche anpassungsfähige Transaktionsraten Kontrollmechanismus, der auf unterschiedlichen Proof-of-Work Schwierigkeiten basiert. Globale Node Identitäten sind zwingend notwendig, um einen Transaktionsraten Kontrollmechanismus in einem verteilten System zu implementieren. Wenn jeder Node eine Identität hat, kann die Public-Key-Kryptographie verwendet werden, um eine Transaktion zu signieren und diese manipulationssicher mit seinem ausgebenden Node zu verbinden. Durch die Einführung von Identitäten, wird ein verteiltes System anfällig für *Sybil-Attacken, bei denen eine bösartige Entität viele gefälschte Identitäten maskiert und diese nutzt, um die Transaktionsraten Kontrolle zu überwinden und einen koordinierten Angriff zu starten oder das Netzwerk zu spammen.

*Sybil-Attacke ist ein Angriff auf Peer-to-Peer-Netzwerke durch die Erstellung falscher Identitäten. Die Attacke kann etwa darauf abzielen, Mehrheitsabstimmungen und die Netzwerk-Organisation zu beeinflussen, das Netzwerk gezielt zu verlangsamen, die Vernetzung im Netzwerk zu stören, oder etwa Kommunikation zwischen anderen Peers abzuhören.

Die IF möchte einen solchen Sybil-Angriff durch das sogenannte Ressourcen-Testen erschweren, bei dem jede Node Identität den Besitz bestimmter schwer zu erwerbenden Ressourcen nachweisen muss. Die IF hat sich entschieden in ihrem Algorithmus, eine bestimmte Anzahl von Iota-Token als Ressource/Sicherheit (Stake) vorzuschreiben und eine vereinfachte Version des Proof-of-Stake zu implementieren. Das sind notwendige Voraussetzung für jede Node mit Identität und nur Nodes mit einem Mindestbetrag an Iota-Token als Sicherheit dürfen Transaktionen durchführen, die Anzahl der Iota-Token (Stake) wird dabei nicht verringert. Der neuartige anpassungsfähige Proof-of-Work ermöglicht es jedem Node, Transaktionen auszugeben und gleichzeitig Spamming-Aktionen zu bestrafen.

Als zusätzliche Sicherheitsmaßnahme möchte die IF, dass die Gesamtzahl, der von einem Node ausgegebenen Transaktionen begrenzt ist. Je größer die Sicherheit (Stake) eines Nodes ist, desto höher ist die Anzahl der Transaktionen, die derselbe Node ausgeben kann. Diese Schwelle bringt zwei Vorteile, zum einen stellt sie sicher, dass selbst ein Benutzer mit unendlicher Rechenleistung das Netzwerk nicht willkürlich spammen kann und zum anderen kann eine richtige Wahl der Schwelle die Sybil-Angriffe minimieren.


Fazit

Die Diskrepanz zwischen kleineren Universalgeräten und optimierter Hardware in Bezug auf die Proof-of-Work Leistung liegt in der Geschwindigkeit der Berechnungen. Daher würde jede auf dem Proof-of-Work basierende Transaktionsraten Kontrolle letztendlich kleinere Ressourcen arme Geräte nicht berücksichtigen. Umgekehrt würde ein rein Stake-basiertes System zu einer Zentralisierung führen, an der nur die “reichen” Nutzer (Nodes) teilnehmen können.

Quellen

https://blog.iota.org/whos-in-who-s-out-a-rate-control-algorithm-for-the-tangle-c7b5ecf85677