Was ist Mana bei IOTA?

Eines der Themen in IOTA 2.0, zu denen wir häufig Fragen erhalten, ist Mana. Dies ist ein wichtiges Thema, deshalb sind wir gerne bereit, mehr über die theoretische Seite von Mana zu erklären und einen Einblick in seine Umsetzung zu geben.

Unser Ziel ist es hier nicht, die Spezifikationen aus technischer und mathematischer Sicht darzustellen, sondern den IOTA-Anwendern zu helfen, diese wichtige Coordicide-Komponente auf theoretischer und praktischer Ebene zu verstehen. Selbstverständlich werden alle Details zur Verfügung gestellt, wenn wir die vollständigen IOTA 2.0-Spezifikationen veröffentlichen.

Dieser Beitrag umfasst:

• Die grundlegende Anforderung an jedes DLT, sowohl Sybil-Schutz als auch Staukontrolle zu haben. Wir erklären, wie Mana diese theoretischen Anforderungen erfüllt. Eine einfache Art und Weise, über Mana nachzudenken, ist, dass es verwendet wird, um den Einfluss verschiedener Module, einschließlich FPC-Abstimmung, dRNG, Autopeering und Staukontrolle, zu gewichten
• Eine Präsentation einer hochrangigen Sichtweise unserer Implementierung von Mana in IOTA 2.0
• Kommentare und Gedanken darüber, wie Benutzer im Live-Netzwerk mit Mana „interagieren“ werden
• Einige häufig gestellte Fragen aus der Gemeinde

Was ist Mana?

Jedes DLT benötigt ein paar verschiedene Komponenten, aber im Rahmen dieser Diskussion werden wir uns auf die Forderung nach zwei spezifischen Merkmalen konzentrieren: eine Form des Sybil-Schutzes und eine Möglichkeit zur Kontrolle von Netzwerküberlastungen.

Der Sybil-Schutz verhindert, dass ein Angreifer durch die Schaffung mehrerer Identitäten ungebührlichen Einfluss auf das Netzwerk gewinnt. Die Überlastungskontrolle bestimmt, wer in Zeiten der Überlastung in der Lage ist, in den Ledger zu schreiben. Jede DLT muss Komponenten enthalten, die diese grundlegenden Anforderungen erfüllen.

Mana ist vielleicht am besten als ein Werkzeug zu betrachten, das in verschiedenen Rollen im Netzwerk eingesetzt wird. Es ist mit dem IOTA-Token verwandt, bleibt aber auch davon getrennt. Wenn eine Werttransaktion verarbeitet wird, wird eine Menge namens Mana an eine bestimmte Node-ID „verpfändet“. Diese Menge bezieht sich auf die in die Transaktion bewegte IOTA-Menge. Das an jede Node-ID verpfändete Mana wird als eine Erweiterung des Ledgers gespeichert.

Die einzige Möglichkeit, Mana zu gewinnen, besteht darin, einen Token-Inhaber zu überzeugen, es an dich zu verpfänden. In diesem Sinne ist Mana ein delegierter Nachweis des Token-Eigentums. Mana bietet daher einen angemessenen Sybil-Schutz, da es schwierig ist, es in willkürlichen Mengen zu erwerben.

Zusätzlich fungiert Mana als Sybil-Kontrollmechanismus im Staukontrollalgorithmus. Obwohl also verschiedene Faktoren wie die Netzwerknutzung die Nachrichtenquote einer Node beeinflussen, bestimmt das von einer Node gehaltene Mana, wie viele Nachrichten er im Verhältnis zum gesamten Netzwerkdurchsatz ausgeben kann.
Der Verpfändungsprozess wird zweimal durchgeführt, einmal für die Module, die sich mit dem Konsens befassen, und ein weiteres Mal für die Staukontrolle. Dies geschieht, um maximale Freiheit und Sicherheit im Netzwerk zu gewährleisten.

Da die Anreize für Sicherheit und Zugang potenziell gegensätzlich sein können, stellt diese Trennung sicher, dass die Nutzer immer in der Lage sein werden, so zu handeln, dass das Netz am besten gesichert ist, während ihre Freiheit gewahrt bleibt, den Zugang entsprechend ihren wirtschaftlichen Interessen zuzuweisen. Der Token-Inhaber ist somit in der Lage, ihren Zugang zu delegieren, ohne dem Delegierten ein zusätzliches „Gewicht“ im Konsensverfahren zu verleihen.

Wie wir später erörtern, können Token-Inhaber ihr Zugangsmana leasen, aber es gibt keinen Grund, dies für das Konsensmana zu tun. Konkret bedeutet dies, dass wir zwei getrennte Werte für Mana zuweisen, die wir als Konsensmana und Zugangsmana bezeichnen.

Mana-Implementierung

In diesem Abschnitt listen wir einige wichtige Aspekte unserer Mana-Implementierung auf. Wir behandeln die Manaberechnung, die Zuordnung von Mana zu einer Node-ID und die Rolle von Mana in jeder der IOTA 2.0-Komponenten.

Zusätzlich zu den beiden Verwendungszwecken von IOTA (Sybil-Schutz und Staukontrolle) führt unsere IOTA 2.0-Implementierung zwei Wege zur Manaberechnung ein.
Eine Möglichkeit der Manaberechnung (allgemein als „Mana 1“ bezeichnet) besteht darin, dass das verpfändete Mana einfach der Anzahl der in der Transaktion bewegten Marken entspricht. Die zweite Art der Manaberechnung („Mana 2„) ist eine Erweiterung von Mana 1, die nicht nur einen delegierten Eigentumsnachweis, sondern auch einen Nachweis der Aktivität der Node beinhaltet. Mana 2 hat eine vorhersehbare Entwicklung im Laufe der Zeit in dem Sinne, dass es nicht durch zusätzliche Token-Transfers beeinträchtigt wird. Diese Vorhersagbarkeit kann für Benutzer wichtig sein, die in einem „Zugangsmanamarkt“ (mehr dazu weiter unten) interagieren und die Kontrolle über ihren gekauften oder gemieteten Zugang sicherstellen wollen.

Unser Team untersucht noch immer, welche der beiden Möglichkeiten besser ist, indem beide Optionen in GoShimmer implementiert werden. Beide Optionen werden funktionieren, aber die endgültige Wahl wird durch robustes gleichzeitiges Testen beider Lösungen in GoShimmer getroffen.

Wir schätzen auch das Feedback, das wir von Partnern und unabhängigen Forschern erhalten. Es besteht keine Eile, sich zu diesem Zeitpunkt auf eine Option festzulegen, ohne sie vorher „in Aktion“ gesehen zu haben. Wir sehen diese Wahl einfach als die Wahl der besseren von zwei guten Optionen. Sobald das Mana berechnet ist, läuft das Protokoll wie folgt ab.

Das Gewicht sowohl des Konsens- als auch des Zugriffsmanas eines bestimmten Knotens ist relativ zum gesamten „aktiven Mana“ oder dem Mana, das von den im Netzwerk aktiven Knoten gehalten wird. Wenn ein Knoten beispielsweise 5 % des gesamten Zugriffsmanas besitzt und nur 50 % des Zugriffsmanas aktiv sind, kann ein Knoten 10 % der vom Protokoll erlaubten Gesamtdaten zum Tangle hinzufügen.

In ähnlicher Weise ist das Stimmrecht proportional zum aktiven Konsensmana. Je mehr Konsensus-Mana eine Node besitzt, desto mehr FPC-Anfragen erhält er, d.h. desto mehr Stimmrecht hat er. Auch im dRNG werden die Zufallszahlen von den obersten aktiven Manahaltern vergeben. Obwohl das Zugangsmana einen Mindestzugang zum Netzwerk garantiert, bestimmt das gesamte aktive Mana den tatsächlich gewährten Zugang.

Mana wird von jedem Modul im Protokoll verwendet, das den Schutz von Sybil benötigt:

• Überlastungskontrolle: Die Menge der Daten, die man dem Tangle hinzufügen kann, ist proportional zu ihrem Mana. Wenn Daten mit einer maximalen Rate von 1000 KB/s zum Tangle hinzugefügt werden (Anmerkung: hier verwenden wir nur eine runde Zahl für Diskussionszwecke), dann kann eine Node mit 5% des Manas 50 KB/s an Daten hinzufügen. Genauer gesagt kann ein Node mit 0 Mana keine Transaktionen ausgeben.
• FPC: Die Wahrscheinlichkeit, dass ein Knoten abgefragt wird, ist proportional zur Menge des Manas, das er enthält
• dRNG: Die obersten Manahalter legen die DRNG fest
• Autopeering: Knoten mit ähnlichem Mana-Peer, wodurch Knoten mit hohem Mana-Anteil besser vor Eclipse-Angriffen geschützt sind

Mit Mana interagieren

Um all dies miteinander zu verbinden, kommen wir nun zu dem recht wichtigen Thema, wie IOTA-Nutzer mit Mana „interagieren“ werden.

Für die meisten Benutzer wird Mana ein nahtloser Bestandteil der Nutzung von IOTA sein. Während der Vorbereitung der signierten Transaktion wählt die Wallet des Benutzers eine Node-ID aus, an die das Mana verpfändet wird. Normalerweise wählt die Wallet die Knoten-ID des Sendeknotens. Die Auswahl der Node-ID erfolgt in der Tat automatisch in der von der IOTA Foundation erstellten Wallet-Software. Bitte beachten Sie, dass in bestimmten Anwendungsfällen selten Mana anderen Node-IDs als dem Sendeknoten zugewiesen wird, z.B. bei der Verpfändung von Mana an einen neuen Node.

Wie oben erwähnt, wird Mana an eine Node-ID verpfändet. Technisch gesehen können Knotenbetreiber Mana auf drei Arten erwerben:

• Token halten: Knotenbetreiber können Token kaufen und das durch diese Token erzeugte Mana an ihre eigenen Knoten verpfänden
• Mana von Token-Inhabern leihen. Mietzahlungen können in IOTA oder in bar erfolgen
• Verarbeitung von Wertverkehr: Ein Node kann Zahlungen im Austausch gegen das in diesen Zahlungen verpfändete Mana verarbeiten

Die Rolle von Mana im Staukontrollmodul wird in Zeiten von Netzwerküberlastung immer wichtiger. In solchen Zeiten steigt die Menge an aktivem Zugangsmana, und daher benötigen Knoten mehr Zugangsmana als in nicht überlasteten Zeiten, um einen bestimmten Durchsatz zu gewährleisten. Bei einer ausreichenden Nachfrage nach Zugangsmana ist es naheliegend, dass ein Mana-Verleihmarkt entstehen wird, auf dem Token-Inhaber potenziell von der Verpachtung ihres Manas profitieren können. Mit intelligenten Verträgen kann dieser Prozess zu einem nahtlosen Teil der Benutzererfahrung werden. Angesichts des relativ hohen Netzwerkdurchsatzes von IOTA 2.0 erwarten wir für eine gewisse Zeit keine Staus, die nicht auf Spam zurückzuführen sind – was bedeutet, dass wir genügend Vorlaufzeit haben, um unsere Sharing-Lösung mit zunehmender Akzeptanz zu implementieren.

Häufig gestellte Fragen

Wann wird Mana über das Pollen-Testnetz freigegeben?

Es wird zum Zeitpunkt der Veröffentlichung dieses Blogbeitrags implementiert.

Wie viel Mana reicht aus, um Transaktionen zu versenden?

Die Antwort auf diese Frage hängt stark von den Netzwerkbedingungen ab. Da die Bandbreite begrenzt ist, wenn die Knoten mit dem Transaktionsfluss zu kämpfen haben, muss es einen Mechanismus zur Priorisierung der Nachrichten geben. Das für den Zugriff auf das Tangle erforderliche Mana hängt davon ab, wie viele Transaktionen du senden möchtest und wie überlastet das Netzwerk ist.

Wie wirkt sich Sharding auf das Mana aus

Wir befinden uns noch im Anfangsstadium der Definition, wie unsere Splitterlösung funktionieren wird, aber sie wird definitiv eine Art „Scherbenmana“ enthalten. Es gibt mehrere Möglichkeiten, dies zu erreichen. Zum Beispiel wird jede Adresse zu einem Scherben gehören, und wenn Gelder von dieser Adresse ausgegeben werden, kann das versprochene Mana auch mit demselben Scherben markiert werden.

Ist Mana eine Art Pfahlnachweis? Ist es eine Art delegierter Pfahlnachweis?

Es gibt einige Ähnlichkeiten zwischen Mana und delegiertem Pfahlnachweis. Die Begriffe PoS und DPoS bezeichnen jedoch ein System, bei dem Validatoren gewählt werden, um Blöcke zu erstellen, Belohnungen und Gebühren zu erhalten und bei Fehlverhalten ihren Einsatz verlieren können. In unserem neuartigen DAG-basierten Ansatz gibt es keine Blöcke, Belohnungen oder Gebühren, so dass die Vergleiche zwischen Mana und PoS und DPoS begrenzt sind.

Gibt es eine Rolle für den Arbeitsnachweis in IOTA 2.0? Wird für Mana überhaupt ein Arbeitsnachweis verwendet?

Für alle Absichten und Zwecke für ehrliche Benutzer wird es im Wesentlichen keinen Arbeitsnachweis geben. Das Protokoll wird einen sogenannten adaptiven Arbeitsnachweis als Spam-Prävention implementieren. Ehrliche Node, die Transaktionen erstellen, müssen eine sehr kleine Menge an Arbeitsnachweisen erbringen (viel kleiner als jetzt), um eine Nachricht zu erstellen. Ein böswilliger Node, der versucht, das Netzwerk zu spammen, wird jedoch schnell mit enormen Anforderungen an den Arbeitsnachweis bestraft, was seine Fähigkeit, Nachrichten zu erstellen, physisch einschränkt. Dieser Mechanismus wird ehrliche Knoten nicht bestrafen. Mana wird keine Art von Arbeitsnachweis verwenden.

Unterschiedliche Wahrnehmungen von Mana, kann das Probleme verursacht? Kann ein Angreifer diese Unterschiede überbewerten?

Dies ist eine sehr wichtige Frage bezüglich der Implementierung von Mana, hat aber eine sehr technische Antwort. Nehmen wir an, eine Transaktion, die eine große Menge an Geldern bewegt, entfernt Mana von Knoten A und verpfändet es an Knoten B. Während sich die Transaktion durch das Netzwerk verbreitet, werden einige Knoten, die die Transaktion zuerst erhalten, vorübergehend sehen, dass Knoten B viel Mana hat, und andere werden sehen, dass A viel Mana hat. Darüber hinaus kann ein Angreifer mit einer beträchtlichen Menge an Mana eine Sequenz von Transaktionen senden, die viel Mana zwischen verschiedenen Knoten-IDs bewegt.

Um diesen Angriff zu verbessern, berechnet das Protokoll Mana mit einem exponentiellen gleitenden Durchschnitt. Das bedeutet, dass das Protokoll zwei verschiedene Mengen verwendet: Basismana und effektives Mana. Das Basismana ist eine Erweiterung des Ledger-Zustands. Es wird direkt aus den Transaktionen berechnet, die dem Hauptbuchstatus hinzugefügt wurden. In der Zwischenzeit ist das effektive Mana das von jedem Modul verwendete Mana und wird periodisch mit der folgenden rekursiven Formel aktualisiert:

Neues effektives Mana=α(Basis-Mana) +(1-α)(Altes effektives Mana)

Wobei α zwischen 0 und 1 liegt. Mit dem exponentiell gleitenden Durchschnitt verlangsamt das effektive Mana die Wirkung von Änderungen des Grundmanas. Daher werden die großen Veränderungen im Basismana des obigen Angriffs nur langsam registriert, und zwar erst dann, wenn die Transaktionen eine Chance haben, sich im gesamten Netzwerk auszubreiten. Der Parameter α steuert, wie langsam diese Änderungen sind.

Jedes Modul des Protokolls kann einige Diskrepanzen in der Mana-Wahrnehmung tolerieren. Wir werden im GoShimmer-Netzwerk genau untersuchen, wie groß diese Diskrepanzen sein können, was den entsprechenden Parameter α bestimmen wird.

Wie kann ich als neuer Node Mana dazu bringen, auf das System zuzugreifen? Muss ich es kaufen? Wie lange dauert es, um mit dem Senden von Nachrichten zu beginnen?

Wie wir oben erwähnt haben, wird Mana ein nahtloser Bestandteil der Benutzererfahrung sein. Die einfachste Möglichkeit für einen Knotenbetreiber, mit dem Senden von Nachrichten zu beginnen, besteht darin, eigene Token zu kaufen, eine Transaktion zu erstellen, die diese Token an sich selbst verpfändet, und dann einen anderen Knoten zu finden, der diese Transaktion ausgibt. Der IF kann auch einen „Mana-Hahn“ einrichten, zu dem Benutzer kommen und eine Mana-Verpfändung für ihren Node beantragen können.
Sobald die Knoten-ID die Mana-Zusage erhalten hat, muss der Knoten einige Minuten auf den exponentiell gleitenden Durchschnitt warten, um die Mana-Änderungen zu registrieren, und der Knoten hat dann freien Zugang zum Netzwerk.

Gibt es Strategien, um Mana anzuhäufen, das ein Angreifer zum Angriff auf das Netzwerk verwenden könnte?

Mana ist immer mit einer Node-ID verbunden, die einfach ein öffentlicher Schlüssel ist, und bestimmte signierte Nachrichten lösen die Berechnung von Mana aus. Daher kann ein einzelner physischer Knoten leicht mit Tausenden von Knoten-IDs betrieben werden. Es besteht jedoch weder ein Anreiz zum Splitting noch zum Pooling, da der Nutzen von Mana in der Regel proportional zum versprochenen Betrag ist. Insbesondere kann ein Knoten ohne Mana nicht auf das Netzwerk zugreifen. Mana kann an jede beliebige Node-ID verpfändet werden, auch an IDs, die offline oder nicht existierenden Rechnern entsprechen. Wir sagen also, dass aktives Mana Mana ist, das von einem aktiven Knoten gehalten wird.
Ein Angreifer könnte versuchen, Mana für ruchlose Zwecke anzuhäufen, aber die Knappheit an Mana dürfte dies erschweren. Da sich kein Markt für Konsensmana entwickeln sollte, kann ein byzantinischer Akteur die Konsensschicht nur durch den Kauf von Tokens angreifen, und er bräuchte mehr Tokens als ehrliche Akteure wie der IF.

Ist dieses Mana-System sicher? Was hindert einen Angreifer daran, eine hohe Menge an Konsensmana aufzubauen, alle Tokens zu verkaufen und dann das System anzugreifen?

Ja, das Manasystem ist sicher. Streng genommen könnte Konsensmana nach Belieben vergeben werden. Es ist jedoch ganz offensichtlich, dass für jeden, der über Jota-Token verfügt, einfach kein Anreiz besteht, mit Konsens-Mana zu „handeln“. Nur ein Angreifer hätte ein Interesse daran, eine ungebührliche Menge an Konsensmana anzusammeln, und deshalb ist der Entwurf der IOTA zur Trennung von Konsens- und Zugangsmana so wichtig. Es ermöglicht den Handel mit Zugangsmana, während gleichzeitig der Konsens geschützt werden kann. Ungeachtet des fehlenden Anreizes zum Handel mit Konsensmana könnte ein Angreifer immer noch versuchen, Tokens mit dem Ziel zu erwerben, Konsensmana zu akkumulieren, das dann zum Angriff auf das Netzwerk verwendet werden könnte. Ein solcher Angriff wäre jedoch unerschwinglich teuer, da der Kauf den Preis in die Höhe treibt und eine große Anzahl von Tokens erforderlich wäre, um einen Angriff durchzuführen. Darüber hinaus würde der Verkauf von Tokens vor einem Angriff ohne Preisabsturz viel länger dauern, als das Konsensmana seinen Einfluss auf das Netzwerk behalten würde.

Warum hat IF keine Wahl zwischen Mana 1 und Mana 2 getroffen?

Wir sind zuversichtlich, dass beide Manaberechnungen dem beabsichtigten Zweck dienen. Es handelt sich nicht um eine Wahl zwischen gut und schlecht, sondern zwischen gut und besser. Wir möchten, dass beide in Pollen umgesetzt werden, damit wir eine fundierte Entscheidung darüber treffen können, welche der beiden Berechnungen am besten funktioniert oder ob es tatsächlich einen praktischen Unterschied zwischen den beiden gibt.

Ist Mana ein Reputationssystem?

Mana kann als ein sehr grundlegendes Reputationssystem an sich betrachtet werden, obwohl wir es als eine Komponente in einem Reputationswert sehen. Ein gutes Reputationssystem würde das Verhalten eines Knotens berücksichtigen, und die Reputation würde auf Null sinken, wenn der Knoten sich falsch verhält. Wir finanzieren derzeit einen Zuschuss, der dieses Thema abdeckt.

Original Übersetzt von William Sanders: https://blog.iota.org/explaining-mana-in-iota-6f636690b916