Monat: März 2021

Letzte Woche haben wir eine neue Version unseres Pollen-Testnetzes veröffentlicht, die mana enthält. Mit diesem Release haben wir die Reife und die Effizienz unserer mana-Lösung demonstriert. Bald wird Mana in viele Module implementiert sein, ein wichtiger Schritt auf dem Weg zu Nectar, unserem kommenden und ersten voll funktionsfähigen Coordicide-Testnetz.

Angesichts dieses wichtigen Meilensteins dachten wir, wir würden einige häufig gestellte Fragen klären. Seit unserer ersten Veröffentlichung über Mana, die auch eine FAQ enthielt, sind von verschiedenen Seiten Fragen aufgeworfen worden, die wir mit diesem Beitrag beantworten wollen. Wir haben diese Fragen von Leuten aus der Community erhalten, sowohl über unseren Discord als auch über Reddit. Die Fragen sind nach Themen gruppiert, und unter einigen Fragen finden Sie die Langform der ursprünglichen Frage in Kursivschrift.

Das Feedback der Partner und der Community ist sehr wertvoll für uns, da es uns zeigt, welche Aspekte von besonderem Interesse sind und uns hilft, die Bereiche in unserer vollständigen Mana-Spezifikation zu identifizieren, die wir optimieren könnten. Die vollständige Spezifikation wird veröffentlicht werden, bevor wir in die „Nectar“-Phase unseres bestehenden „Coordicide“-Testnetzes eintreten.

Seit unserem letzten Beitrag gab es nur eine vorgeschlagene Änderung, die mit Mana zu tun hat: Benutzern mit Null Mana könnte es möglicherweise erlaubt werden, Nachrichten zu senden, wenn das Netzwerk nicht überlastet ist, wie von Partnern und Mitgliedern der breiteren Gemeinschaft gewünscht. Wir untersuchen die Möglichkeit, Nachrichten für Nodes mit niedrigem oder null Mana in Zeiten geringer Überlastung auszustellen, unter der Bedingung, dass sie eine zusätzliche Aufgabe erfüllt haben, z. B. einen Arbeitsnachweis. Dies ist keineswegs einfach oder gar möglich. Wir werden Ihnen mitteilen, was unsere Forschung herausfindet, sobald wir Ergebnisse haben.

Bitte beachten Sie, dass die Fragen darüber, wie viel Zugriff eine bestimmte Menge an Mana garantiert, eigentlich keine Fragen über Mana an sich sind, sondern eigentlich Fragen über unseren Staukontrollalgorithmus sind. Obwohl also Mana selbst vollständig ist, sind die Fragen bezüglich der Null-Mana-Knoten noch offen. In Kürze werden wir einen weiteren Blog-Beitrag veröffentlichen, der den IOTA-Staukontrollalgorithmus erklärt.

Eine kurze Auffrischung: Mana

Für diejenigen, die unsere erste Veröffentlichung über Mana nicht gelesen haben, hier ein kurzer Überblick darüber, was Mana ist und warum es wichtig ist. Jedes Mal, wenn eine Transaktion Geld bewegt, „verpfändet“ diese Transaktion eine Menge Mana an eine Node-ID. Mana kann also als Beweis für delegierten Token-Besitz betrachtet werden. Die einzige Möglichkeit, Mana zu erhalten, besteht darin, entweder Token zu kontrollieren oder eine Art Beziehung zu jemandem zu haben, der Token kontrolliert. Die Menge an Mana, die während eines Transfers verpfändet wird, wird so berechnet, dass ein Angreifer das Mana, das ein Knoten besitzt, nicht künstlich aufblähen kann.

Warum ist Mana wichtig? Ohne eine Art von Schutzmechanismus könnten Angreifer ein Netzwerk wie IOTA angreifen, indem sie Millionen von gefälschten Identitäten fälschen, was als Sybil-Angriff bezeichnet wird. Daher müssen alle DLTs Sybil-Angriffe verhindern, indem sie die Identität mit einer kryptographisch überprüfbaren, knappen Ressource verbinden. Proof of Work und Proof of Stake verwenden Energie bzw. gestackte Token als Sybil-Schutzmechanismen.

IOTA verwendet Mana, um Sybil-Angriffe zu verhindern. Aus diesem Grund muss Mana von allen Kernkomponenten von Coordicide berücksichtigt werden, wie z.B. dem IOTA Congestion Control Algorithmus, unserem Konsens-Algorithmus (FPC), Autopeering und unserem verteilten Zufallszahlengenerator. Das ist auch der Grund, warum die Implementierung von Mana in das Pollen-Testnetz ein wichtiger Schritt für die Nectar-Phase des Testnetzes war: Es bedeutet, dass wir damit beginnen können, Schlüsselkomponenten des IOTA-Kernprotokolls vor grundlegenden Angriffsvektoren zu schützen.

Der Unterschied zwischen Mana und Staukontrolle

Mana ist unser aktueller anfänglicher Vorschlag, um das Verhalten der Nodes zu messen. In der Zukunft wird sich Mana zu einem komplexeren mehrdimensionalen Reputationssystem entwickeln, um den Beitrag einer Node zur Netzwerkaktivität und dessen Sicherheit zu bewerten. Im aktuellen Stadium wird Mana als Eingabedaten verwendet, um fälschungssichere Identitäten für verschiedene Coordicide-Module bereitzustellen, einschließlich des IOTA Staukontrollalgorithmus.

Mana Eigenschaften

Wie lang ist ungefähr die Zerfallsfunktion?

Liegt die Halbwertszeit von Manas eher bei einer Minute oder eher bei einem Jahr?

Erinnern Sie sich daran, dass bei der Mana zwei Berechnungsmethode das Mana nach einer Exponentialfunktion zerfällt und daher mit einem neuen Pfand aufgefrischt werden muss. Die Halbwertszeit des Zerfalls liegt bei einigen Stunden, z.B. 6 Stunden. Wir wollen jedoch sehen, wie sich dies im Testnetz tatsächlich bewährt und werden diesen Parameter entsprechend anpassen.

Wie wird „aktives Mana“ gemessen?

„Aktives Mana“ kann auf unendlich viele Arten berechnet werden, je nach Zweck. Aktiv zu sein könnte bedeuten „der Prozentsatz der Node, die in den letzten X Sekunden mindestens eine Transaktion gesendet haben“ oder es könnte bedeuten „der Prozentsatz der Node, die im Hinblick auf ihre Reputation ‚genug‘ Transaktionen gesendet haben.“

Für die Staukontrolle muss die Node das aktive Mana nicht kennen: Die Node schaut einfach auf seinen Posteingang und reagiert entsprechend dem Mana der ausstellenden Node. Die Information über die Menge an Mana, die jede Node besitzt, ist für jede Node verfügbar, basierend auf der ID der ausstellenden Node, die Teil jeder Nachricht ist, die sich durch das Netzwerk verbreitet.

Für FPC und Autopeering verwaltet das Peer Discovery-Modul eine Liste bekannter Nodes, die derzeit online sind. Die Node verwendet diese Liste für FPC-Abfragen und für die Auswahl von Nachbarn.

Bösartiges Verhalten

Wird Mana durch die fehlende Dezentralisierung auf die gleichen Probleme stoßen, wie PoS-Token?

Etwa 0,06% der Adressen halten ~65% aller Token. Das bedeutet, dass selbst wenn 99,94% der Adressen zu aktivem, ehrlichem Mana beitragen, sind das nur ~35% des gesamten Manas. Wie können 0,06% der Adressen, die 65% der Token kontrollieren, kein Problem für den Konsens, die Abstimmung oder den Datendurchsatz darstellen?

Erstens entspricht die Anzahl der Adressen nicht der Anzahl der Leute, die IOTA nutzen. Zum Beispiel halten 35% aller Adressen, d.h. 14000 Adressen, weniger als 10 MI. Es wäre absurd, anzunehmen, dass diese Beträge von 14000 Personen kontrolliert werden. Wallets und verschiedene Anwendungen verteilen das Geld aus verschiedenen Gründen oft auf mehrere Adressen. Auf der anderen Seite werden Token im Cold Storage oft auf eine einzige Adresse gebündelt. Daher ist die obige Statistik nicht überraschend.

Zweitens ist diese Statistik kein Problem, da die zugrunde liegende Sicherheitshypothese immer noch erfüllt ist. Unseren Simulationen zufolge müsste ein Angreifer mindestens 30 % (manchmal mehr) des aktiven Konsens-Manas kontrollieren, um eine vernünftige Chance zu haben, FPC anzugreifen und eine Doppelausgabe zu verursachen. Ein signifikanter Anteil der Top-Token-Inhaber müsste sich also absprechen, um einen Double Spend zu verursachen. Da die obersten 0,06 % der Adressen immer noch mehrere hundert Adressen sind, erscheint dies unwahrscheinlich. Darüber hinaus würden andere Angriffe wie Zensur-Angriffe oder Liveness-Angriffe deutlich mehr Mana erfordern.

Drittens muss in jeder DLT der Zugang zum Netzwerk mit einer kryptographisch verifizierbaren, knappen Ressource verbunden sein. Typischerweise folgt der gesamte Ressourcenbesitz einer Zipf-Verteilung: Einige wenige haben viel, andere immer weniger. Daher ist dieses Zentralisierungsproblem nicht einzigartig für IOTA, sondern endemisch für alle DLTs.

Schließlich sind Proof-of-Work/Proof-of-Stake-Lösungen starre Systeme. Im Vergleich dazu ist unser Ansatz viel flexibler. Die Idee ist, ein mehrdimensionales Reputationssystem aufzubauen, bei dem Mana nur eine der Komponenten ist. Durch die Verwendung zusätzlicher Metriken – wie Belohnungen für gutes Verhalten, Begriffe wie Alter und Teilnahme am Netzwerk sowie Reputationsverluste für egoistische oder sich falsch verhaltende Knoten – wollen wir die Diskrepanzen in der Reputation über alle Knoten hinweg reduzieren.

Wird eine zentralisierte Verteilung Probleme verursachen?

IOTA 2.0 („Coordicide“) ist so konzipiert, dass es keine großen Machtkonzentrationen gibt. Im Gegensatz zu den meisten PoS-Systemen ist IOTA keine Blockchain und wird daher nicht durch einen Leader-Wahlprozess begrenzt. In einer Blockchain sind Blöcke sequentiell und so wird nur eine relativ kleine Anzahl von Blöcken jede Stunde produziert, und so kann es nur so viele Blockproduzenten geben.

In einer DAG können jedoch mehrere Personen gleichzeitig Informationen hinzufügen, und so können Nodes mit kleinen Mengen an Mana gleichzeitig mit großen Mana-Inhabern Nachrichten erstellen. Selbst wenn Sie einen ziemlich kleinen Anteil an Mana haben, garantiert Ihnen dieses Mana zumindest eine minimale Menge an Zugang, und dieser Zugang kann nicht entzogen werden, unabhängig davon, wie viele große Mana-Inhaber das Netzwerk sättigen. So kann der IOTA Congestion Control Algorithm (ICCA) tausende von kleinen Mana-Inhabern unterstützen. Durch die proportionale Zuteilung von Mana stellen wir sicher, dass die „kleinen Jungs“ ihren fairen Anteil an Stimmrecht oder Zugang bekommen.

Das Verständnis der absoluten Mindestmenge an Mana, die benötigt wird, um eine Nachricht auszugeben, ist Teil der Forschung mit Null-Mana-Knoten.

Kann man mit genügend Mana eine doppelte Ausgabe tätigen?

Ist es möglich, Doppelausgaben zu genehmigen, indem man zwei widersprüchliche Transaktionen genehmigt und sie in den Tangle einbettet, wenn es genug böswillige Nodebesitzer gibt, die sie „genehmigen“? Wie hoch ist der Prozentsatz an (aktivem/passivem) Mana, der erforderlich wäre, um dies erfolgreich zu tun? Wie würden ehrliche Nodes auf weitergeleitete, aber widersprüchliche Transaktionen reagieren, die eine Mehrheit von böswilligen Knotenbesitzern/Mana-Inhabern für legitim befunden hat?

Mit etwa 30 % des Konsens-Manas kann ein Angreifer potenziell den Abstimmungsalgorithmus manipulieren, um ein Paar von Doppelausgaben gültig zu machen. Bei diesem Angriff würde eine Gabelung entstehen, bis sie aufgelöst ist, wären keine Nachrichten endgültig.

Wie auch immer:

1. Kein Angreifer wird 30% des Konsens-Manas aus IOTA-Beständen haben.
2. Es wird keinen legitimen Markt für Konsens-Mana geben, da es keinen Sinn macht, diesen zu etablieren. Der Handel mit Access Mana hat einen legitimen Anwendungsfall, so dass ein gesunder Markt dafür wahrscheinlich wachsen wird. Konsens-Mana ist rein für die Verwaltung. Nur Angreifer würden es kaufen. Es würde eine lange Zeit und eine Menge Ressourcen benötigen, um eine Marktposition aufzubauen, um auch nur in die Nähe einer Situation zu kommen, in der man eine Mehrheit der Stimmen erreichen kann. Es ergibt keinen Sinn, dass ein solcher Markt reift.

Wie verhindern Sie Prioritätsumkehrungen?

Das könnte passieren, wenn eine Transaktion mit hohem Mana-Wert von einer Transaktion mit niedrigem Mana-Wert abhängt.

Wenn Transaktion A von Transaktion B abhängt, muss B im Vergangenheits-Kegel von A sein. Wenn eine High-Mana-Node eine Nachricht mit Transaktion A ausgibt, und eine Low-Mana-Node gibt Transaktion B aus, wird A nicht getratscht, wenn B nicht getratscht hat.

Darüber hinaus – im Tratschprotokoll – tratschen Nodes nur „bei Verfestigung“, was bedeutet, dass eine Node eine Nachricht nur dann getratscht wird, wenn seine Eltern ebenfalls getratscht hatten. Tatsächlich wird der Staukontrollalgorithmus eine Nachricht erst dann in Betracht ziehen, wenn er den gesamten vergangenen Kegel erhalten hat.

Wie verhindert man „Mana Dusting“?

„Mana Dusting“, also das Zuweisen von Mana an nicht vorhandene Nodes und damit das Füllen der Nodetabellen aller Nodes?

Wir haben noch keine offizielle Lösung für dieses potenzielle Problem spezifiziert.

Jedes Modul erfordert nur einen „ungefähren Konsens“ über Mana, was bedeutet, dass das Protokoll kleine Unterschiede in der Mana-Wahrnehmung toleriert. Somit kann Manastaub ohne Auswirkungen gelöscht werden. Um jedoch kleine Mana-Halter zu ermöglichen, kann es sinnvoll sein, Mana-Staub für einen kurzen Zeitraum, etwa einen Tag oder so, leben zu lassen, danach kann er gelöscht werden.

„Freie“ Transaktionen

Kann eine Null-Mana-Node Transaktionen ausgeben, wenn es keinen Stau gibt?

Im aktuellen Entwurf für den Überlastungssteuerungsalgorithmus benötigen Sie Mana, um eine Nachricht zu senden. Dies soll verhindern, dass plötzliche aggressive Spam-Attacken das Netzwerk stören. Wie in der Einleitung erwähnt, prüfen wir die Möglichkeit, dass eine Node einen Arbeitsnachweis erbringen kann, um Nachrichten ohne Mana ausgeben zu können. Allerdings kann die Möglichkeit, die ungenutzte Bandbreite zu geringen Kosten auszunutzen, auch böswillige Knoten begünstigen, die versuchen, das Netzwerk zu verstopfen oder, noch schlimmer, Ledger-Inkonsistenzen zu erzeugen. Da IOTA 100% erlaubnisfrei ist, ist die Lösung dieses Problems nicht trivial.

Eine Alternative ist, Mana-Faucets zu haben, was etwas ist, das die IOTA Foundation oder andere große Halter im Netzwerk unterhalten könnten. Die Idee ist, dass Knoten automatisch eine Liste von Faucets halten könnten. Vom Node-Dashboard aus kann der Node-Operator eine minimale Menge an Mana vom Faucet anfordern.

Braucht man eigentlich Mana für nicht-wertige Nachrichten?

Der IOTA Congestion Control Algorithmus behandelt alle Nachrichtentypen im Tangle gleich. Nicht-wertige Transaktionen (Datennachrichten) werden auf die gleiche Art und Weise verarbeitet wie Werttransaktionen (Wertnachrichten). In Zeiten der Überlastung benötigt eine Node ausreichend Mana, um eine von beiden auszustellen.

Benötigen Sie überhaupt Mana, wenn Sie gerade einen Knoten eingerichtet haben und eine Werttransaktion durchführen möchten?

Sie benötigen kein Mana, wenn Sie einfach nur eine Node „aufstellen“ und den Tangle überwachen. 0-Mana-Nodes können die gleichen Peering-Mechanismen in Chrysalis verwenden, um einfach in das Netzwerk „hineinzuhören“, obwohl sie nicht den Eclipse-Schutz haben, den Mana ihnen bieten würde.

In unserer anfänglichen Version des IOTA Congestion Control Algorithmus benötigen Sie jedoch Mana, um Transaktionen zu senden – oder irgendeine Art von Nachricht auszugeben. Wie bereits erwähnt, untersuchen wir, wie wir es einer Node ohne Mana erlauben können, Nachrichten zu senden, wenn es keinen Stau gibt. Wir haben eine vielversprechende Lösung, aber wir müssen sicherstellen, dass sie keine Angriffsvektoren öffnet. Wir werden unsere Ergebnisse zu einem späteren Zeitpunkt bekannt geben, wenn diese Forschung weiter entwickelt ist.

Mana-Markt

Was wird der Marktwert von Mana sein?

Wir wissen es nicht. Mana ist eine technische Lösung für verschiedene Probleme in einem dezentralen IOTA-Netzwerk. Der Mana-Markt ist ein Nebenprodukt unserer Absicht, ein erlaubnisfreies Protokoll zu schaffen, das so frei von Einschränkungen wie möglich ist. Wir haben die Angriffsvektoren, die diese Lösung mit sich bringt, überprüft, werden aber die Bewertung ihres monetären Wertes dem Markt überlassen.

Es gibt jedoch ein paar vernünftige Annahmen, die darauf hindeuten, dass Mana eine Art von Marktwert haben wird. Erstens: Wenn das Netzwerk überlastet wird, wird der Zugang zum Netzwerk – und damit Mana – wertvoll. Dies ist eine einfache Angebots- und Nachfrageökonomie, die für alle DLTs gilt. Allerdings wird sich diese Berechnung mit Sharding ändern, da Sharding das Angebot an Zugang stark erhöhen wird.

Zweitens, derzeit könnten einige Unternehmen zögern, jede Krypto aufgrund von Vorschriften, Steuern oder allgemeine Skepsis zu halten. Daher ist das Mieten von Mana durch vertrauenswürdige IOTA-Infrastrukturpartner ein Weg, dass Unternehmen garantierten Zugang haben können, ohne Token zu halten.

Warum kann Mana an einen anderen Node verpfändet werden?

Was war der Grund für die Entscheidung, Mana nicht an Nodes zu verpfänden, die Transaktionen verarbeiten? Warum sollte jemand in der Lage sein, Mana an eine andere Entität zu verpfänden?

Wir wollen IOTA so flexibel und frei – im Sinne von Freiheit, nicht „umsonst“ – wie möglich halten. Es gibt mit ziemlicher Sicherheit komplizierte Anwendungsfälle in der Zukunft, die wir nicht aus willkürlichen Gründen einschränken wollen.

Jeder sollte in der Lage sein, Mana auf die Art und Weise zu nutzen, die er für richtig hält. Das gilt sowohl für Benutzer als auch für Nodes. Wenn Sie der Node, der Ihre Transaktion verarbeitet, kein Mana zuweisen, muss er Ihre Transaktion nicht verarbeiten. Sie können darauf bestehen, dass alle Werttransaktionen, die sie verarbeiten, Mana an ihre Node-ID verpfänden.

Es kann jedoch sein, dass Ihr Knoten sein Zugriffsmana nur periodisch benötigt, z. B. zu Spitzenverkehrszeiten, nur an Wochentagen oder Wochenenden oder in anderen Abständen. Wenn der Eigentümer der Nodes eine Menge IOTA besitzt und keine Verwendung für (einen Teil) des von ihm generierten Manas hat, erhält er durch die Möglichkeit, es an andere Nodes zu verpfänden, einen erhöhten Nutzen aus seinem IOTA.

Zum Beispiel könnten einige Unternehmen nicht wollen, Token in der nahen Zukunft zu halten. Krypto in den Büchern zu haben, kann in einigen Ländern rechtliche Probleme verursachen, aber sie möchten vielleicht trotzdem Zugang zum Tangle haben. Durch die Trennung des Pfands von der Node, der die Transaktion verarbeitet, ermöglicht es einen Markt für sie, den Zugang im Austausch für Fiat zu kaufen und rechtliche Probleme zu umgehen.

Unternehmen könnten z.B. öffentliche Nodes für Benutzer anbieten, um von dem dadurch generierten Mana zu profitieren.

Was passiert mit ungenutztem Zugangsmana?

Ungenutzte Bandbreite wird proportional zu der Menge an Access Mana aufgeteilt, die aktive Benutzer haben.

Das heißt, wenn Sie z.B. 1 % Zugangsmana haben und die Bandbreite zu 60 % gesättigt ist, können Sie mindestens 1 % der ungenutzten 40 % zugewiesen bekommen. Von der ungenutzten Bandbreite danach bekommen Sie wieder 1%, auf ewig, bis die Bandbreite gesättigt ist.

Dies könnte das Netzwerk bis zu seinem hart kodierten Limit verstopfen, aber es behindert niemals den Zugang eines Mana-Inhabers zum Netzwerk aufgrund seines Manas.

Kann jeder einfach Katzenbilder spammen und das Netzwerk verstopfen?

Das Protokoll kann nicht bestimmen, was Spam ist und was nicht. Dies ist ein Merkmal der erlaubnisfreien Innovation. Während Katzenbilder für einige trivial erscheinen mögen, können sie für andere sehr wichtig sein. Es ist nicht unsere Aufgabe, dies zu bestimmen.

Jeder sollte in der Lage sein, das Netzwerk so zu nutzen, wie er es für richtig hält, auch wenn andere damit nicht einverstanden sind. Dies ist eine Kernaussage von DLT, und Mana ermöglicht dies auf faire Weise. Die Zusammensetzung des überlasteten Netzwerks wird durch die Menge an Mana, die ein Spammer besitzt, begrenzt. Das Netzwerk könnte nur aus 100% Katzenbildern bestehen, wenn der Spammer 100% des aktiven Manas besitzt. Somit ist auch bei diesem Katzen-Spamming ein fairer Durchsatz gewährleistet.

Staukontrolle

Bleiben Sie dran für unseren nächsten Blog-Beitrag über den Mechanismus der Überlastungssteuerung.

Wie messen Sie, wann das Netzwerk überlastet ist?

Ein Raspberry Pi kann nur einen Bruchteil einer AWS-Node verarbeiten, so dass die beiden sehr unterschiedliche Ansichten darüber haben, wann die „mana-basierte Ratenkontrolle“ einsetzen muss – und wenn diese voneinander abweichen, haben Sie wieder Prioritätsumkehreffekte.

Zunächst einmal muss der Algorithmus zur Staukontrolle nicht feststellen, ob das Netzwerk überlastet ist oder nicht. Wenn es keinen Stau gibt, dann ist der Posteingang des Knotens meistens leer. Jede Node im Netzwerk verarbeitet Nachrichten mit einer maximalen festen Rate, die vom Protokoll festgelegt wird. Diese Rate bestimmt die Mindestanforderungen an die Hardware der Node, einschließlich Bandbreite und Rechenleistung. Jeder Rechner ohne diese Fähigkeiten wird nicht in der Lage sein, eine Node zu betreiben. Wir legen diesen Ratenparameter so fest, dass die Art von Maschinen möglich ist, die wir für den Betrieb einer Node für notwendig erachten.

Damit ein kleines Gerät das Netzwerk nutzen kann, muss es nicht unbedingt eine Node oder gar eine Wallet betreiben. Typischerweise werden die heutigen IoT-Geräte über ein leistungsfähigeres Gateway gesteuert, das über eine zuverlässige Internetverbindung verfügt. Das Gateway kann eine Wallet oder eine Node betreiben. Um diese Geräte mit geringem Stromverbrauch zu ermöglichen, müssen wir also nur sicherstellen, dass alle Anwendungen, die von Geräten mit geringem Stromverbrauch verwendet werden, über ein Gateway funktionieren können.

In Zukunft wird das Sharding ein vielfältigeres Netzwerk ermöglichen, da nicht alle Geräte alle Nachrichten verarbeiten müssen. Dann können Geräte mit geringerer Leistung kleinere Teile des Netzwerks als Node ausführen.

Kann man das System manipulieren, um das Netzwerk zu überlasten?

Welcher Prozentsatz an Mana, der von ehrlichen Nodebesitzern gehalten wird, ist erforderlich, um eine künstliche Sättigung des Netzwerks zu verhindern, um das Entstehen eines Marktes mit gebührenpflichtigen Transaktionen zu verhindern, wenn man davon ausgeht, dass böswillige Nodebesitzer das Netzwerk künstlich sättigen könnten („Spam“), um ihre Netzwerkkapazität (oder Mana) an den Meistbietenden verkaufen zu können.

Zunächst einmal hängt ein potenzieller Mana-Markt nicht allein von der Überlastung ab. Unternehmen, die keine Kryptowährung in ihren Büchern haben wollen, werden bereits ohne Stau auf dem Markt für Mana sein.

Als nächstes ist es wichtig zu erkennen, dass Ihr Mana den Zugang zum Netzwerk garantiert, proportional zu der Menge an Mana, die Sie haben. Keine noch so große Zentralisierung durch andere Besitzer kann Ihren Zugang verhindern; sie können das Netzwerk nicht auf unfaire Weise verstopfen. Sie haben immer den Teil der Bandbreite zur Verfügung, der Ihnen zusteht.

Verhalten der Node

Kann eine Node feststellen, ob der Aussteller einer Transaktion ihm Mana gutschreiben hat, bevor er eine Transaktion annimmt und weiterleitet?

Ja.

Ist diese Eigenschaft signiert?

Ja, die Eigenschaft ist signiert.

Können Nodes Transaktionen, die ihnen kein Mana zusagen, einfach ablehnen?

Wie kostspielig ist es für die Node (wrt DoS), es synchron aufzulösen, so dass er möglicherweise die Transaktion ablehnen kann und der Benutzer davon erfährt?

Es ist trivial, solche Transaktionen zu verifizieren und abzulehnen.

Die Standardeinstellung ist, dass in der Kommunikation zwischen Wallet und Node, die Wallet der Node nach einer Node-ID fragt, an die das Mana verpfändet werden soll. Die Node teilt der Wallet dann die ID mit, an die das Mana verpfändet werden soll. Die Brieftasche kann beantragen, das Mana an einen anderen Ort zu verpfänden, und es liegt an der Node, dieser Bitte nachzukommen oder nicht.

Dieses Verhalten ist im Kernprotokoll nicht vorgesehen. Es ist nicht essentiell für die Sicherheit, und wir wollen zukünftige Anwendungsfälle nicht durch eine solche Regel behindern. Jeder kann die Nodesoftware so konstruieren, dass sie sich in Bezug auf die Verpfändung von Mana anders verhält, so wie er es für seinen Anwendungsfall für richtig hält.

Was passiert, wenn eine Node ihr Mana aufgrund von böswilligem Verhalten verliert?

Was spricht dagegen, es woanders zu verpfänden und den Angriff erneut zu versuchen? Ist es nicht billig, neu zu verpfänden?

In IOTA 2.0 wird Mana nicht durch das Protokoll von einem sich falsch verhaltenden Node entzogen. Wie durch die Frage angedeutet, gibt es einige offensichtliche Fragen, die geklärt werden müssten, bevor dies dem Protokoll hinzugefügt wird. Einzelne Benutzer können jedoch ihr Mana-Versprechen im Falle von Fehlverhalten widerrufen. Es liegt jedoch in ihrer Verantwortung, ihr Konsens-Mana an ehrliche Quellen zu verpfänden.

Wir haben einen Zuschuss an die Gruppe von Mauro Conti gegeben, um ein allgemeineres Reputationssystem zu untersuchen, das das Verhalten der Node berücksichtigt. Dies ist eine laufende Forschung und wir werden alle über ihre Ergebnisse auf dem Laufenden halten.

Original by William Sanders: https://blog.iota.org/explaining-mana-in-iota-part-2/