Erklärung von Mana

28. Sep'20

Übersetzung des Blogartikel von Autor William Sanders, IOTA Foundation.




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 den theoretischen Aspekt 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, sobald wir die vollständigen IOTA 2.0-Spezifikationen veröffentlichen.


Dieser Beitrag umfasst:

  • Grundvoraussetzung für jedes DLT ist es, sowohl Sybil-Schutz als auch eine Überlastungskontrolle zu gewährleisten. Wir erklären, wie Mana diese theoretischen Anforderungen erfüllt. Eine einfache Art und Weise, über Mana nachzudenken, ist, dass es zur Gewichtung des Einflusses zwischen verschiedenen Modulen, einschließlich FPC-Abstimmung, dRNG, Autopeering und Überlastungskontrolle, verwendet wird.
  • Eine Präsentation einer übergeordneten 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 Community




Was ist Mana?

Jedes DLT benötigt ein paar unterschiedliche Komponenten, aber im Rahmen dieser Diskussion werden wir uns auf die Notwendigkeit von 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 das Ledger zu schreiben. Jedes 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 gekoppelt, 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 Sie 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 Überlastungskontrollalgorithmus. Obwohl also verschiedene Faktoren wie die Netzwerknutzung die Nachrichtenrate eines Nodes beeinflussen, bestimmt das von einem 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 Überlastungssteuerung. Dies geschieht, um maximale Freiheit und Sicherheit im Netzwerk zu gewährleisten.

Da die Anreize für Sicherheit und Zugang möglicherweise uneins sind, stellt diese Trennung sicher, dass Benutzer immer in der Lage sind, das Netzwerk am besten zu sichern und gleichzeitig die Freiheit zu wahren, den Zugang entsprechend ihren wirtschaftlichen Interessen zuzuweisen. Der Tokeninhaber kann somit seinen Zugang delegieren, ohne dem Delegierten ein zusätzliches "Gewicht" im Konsensverfahren zu verleihen.

Wie wir später besprechen, können die Inhaber von Token ihr Zugangsmana leasen, aber es gibt keinen Grund, dies für das Konsensmana zu tun. Konkret bedeutet dies, dass wir zwei separate 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 Überlastungskontrolle) führt unsere IOTA 2.0-Implementierung zwei Arten der 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 Token entspricht. Die zweite Art, Mana zu berechnen ("Mana 2"), ist eine Erweiterung von Mana 1, die nicht nur einen delegierten Eigentumsnachweis, sondern auch einen Nachweis der Node-Aktivität 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 Wahl unter diesen beiden Optionen 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 Nodes ist relativ zum gesamten "aktiven Mana" oder dem Mana, das von den im Netzwerk aktiven Nodes gehalten wird. Wenn ein Node beispielsweise 5 % des gesamten Zugriffsmanas besitzt und nur 50 % des Zugriffsmanas aktiv sind, kann ein Node 10 % der vom Protokoll erlaubten Gesamt-Daten zum Tangle hinzufügen.

In ähnlicher Weise ist das Stimmrecht proportional zum aktiven Konsensmana. Je mehr Konsensmana ein 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 Sybil-Schutz benötigt:

  • Überlastungskontrolle: Die Menge der Daten, die man dem Tangle hinzufügen kann, ist proportional zu ihrem Mana. Wenn dem Tangle Daten mit einer maximalen Rate von 1000 KB/s hinzugefügt werden (Anmerkung: hier verwenden wir nur eine runde Zahl für Diskussionszwecke), dann kann ein Node mit 5% des Manas 50 KB/s an Daten hinzufügen. Konkret kann ein Node mit 0 Mana keine Transaktionen ausgeben. >>>  Eigene Anmerkung: Befindet sich noch in der Erforschung kann ggf. noch geändert werden. <<<
  • FPC: Die Wahrscheinlichkeit, dass ein Node abgefragt wird, ist proportional zu der Menge an Mana, die er enthält.
  • dRNG: Die Top Manahalter legen die DRNG fest. Hinweis: Das dRNG wird das DRAND-Protokoll zur Erzeugung von Zufallszahlen verwenden, DRAND benötigt ein Komitee, das aus den höchsten Manahaltern besteht.
  • Autopeering: Nodes mit ähnlichem Mana-Peer, wodurch Nodes 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. In der Regel wählt die Wallet die Node-ID des Sendenodes. 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 seltenen Anwendungsfällen Mana anderen Node-IDs als dem Sendenode zugewiesen werden kann, 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 Node Betreiber Mana auf drei Arten erwerben:

  • Token halten: Node-Betreiber können Token kaufen und das durch diese Token erzeugte Mana an ihre eigenen Node verpfänden.
  • Mieten von Mana von Token-Inhabern. 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 Überlastungsmodul gewinnt in Zeiten von Netzengpässen an Bedeutung. In solchen Zeiten wird die Menge an aktivem Zugangsmana zunehmen, und daher benötigen die Nodes mehr Zugangsmana als in nicht überlasteten Zeiten, um einen bestimmten Durchsatz zu garantieren. Bei einer ausreichenden Nachfrage nach Zugangsmana ist es naheliegend, dass ein Mana-Verleihmarkt entstehen wird, auf dem Token-Inhaber potenziell von der Verleihung ihres Manas profitieren können. Mit Smart Contracts kann dieser Prozess zu einem nahtlosen Teil der Benutzerfreundlichkeit gemacht 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 Sharding-Lösung zu implementieren, wenn die Akzeptanz wächst.




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 Nodes 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 Sie senden möchten und wie überlastet das Netzwerk ist.



Wie wirkt sich Sharding auf das Mana aus?

Wir befinden uns noch im Anfangsstadium der Definition, wie unsere Sharding-Lösung funktionieren wird, aber sie wird definitiv eine Art von "gesplittertem" Mana haben. Es gibt mehrere Möglichkeiten, dies zu erreichen. Zum Beispiel wird jede Adresse zu einem Shard gehören, und wenn Gelder von dieser Adresse ausgegeben werden, kann das versprochene Mana auch mit demselben Shard markiert werden.



Ist Mana eine Art Proof of Stake? Ist es eine Art delegierter Proof of Stake?

Es gibt einige Ähnlichkeiten zwischen Mana und delegiertem Proof of Stake. 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 bzw. DPoS schwierig sind.



Gibt es eine Rolle für Proof of Work in IOTA 2.0? Wird bei Mana überhaupt ein Proof of Work verwendet?

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



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

Dies ist eine sehr wichtige Frage in Bezug auf die Umsetzung von Mana, hat aber eine sehr technische Antwort. Angenommen, eine Transaktion, die eine große Menge an Geldmitteln bewegt, entfernt Mana von Node A und verpfändet es an Node B. Während sich die Transaktion durch das Netzwerk verbreitet, werden einige Nodes, die die Transaktion zuerst erhalten, vorübergehend sehen, dass Node 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 eine Menge Mana zwischen verschiedenen Node-IDs bewegt.

Um diesen Angriff zu entschärfen, 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 Ledger-Status 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.



Als neuer Node, wie kann ich Mana bekommen auf das System zugreifen? Muss ich es kaufen? Wie lange dauert es, Messages zu senden?

Wie wir oben erwähnt haben, wird Mana ein nahtloser Teil der Benutzerfreundlichkeit sein. Die einfachste Möglichkeit für einen Node-Betreiber, mit dem Senden zu beginnen, besteht darin, eigene Token zu kaufen, eine Transaktion zu erstellen, die diese Token an sich selbst verpfändet, und dann einen anderen Node zu finden, der diese Transaktion ausgibt. Der IF kann auch einen "Mana-Faucet" einrichten, zu dem die Benutzer kommen und eine Mana-Verpfändung für ihren Node beantragen können.

Sobald die Node-ID die Mana-Zusage erhalten hat, muss der Node einige Minuten warten, bis der exponentiell gleitende Durchschnitt die Mana-Änderungen registriert hat, woraufhin der Node frei auf das Netzwerk zugreifen kann.



Gibt es Strategien zur Anreicherung von Mana, mit dem ein Angreifer das Netzwerk angreifen könnte?

Mana ist immer mit einer Node-ID verbunden, die schlicht ein öffentlicher Schlüssel ist, und bestimmte signierte Nachrichten lösen die Berechnung von Mana aus. Daher kann ein einzelner physischer Node problemlos mit Tausenden von Node-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 Node 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 Node 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 Iota-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 die 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 Nodes berücksichtigen, und die Reputation würde auf Null gehen, wenn sich der Node falsch verhalten würde. Wir finanzieren derzeit einen Zuschuss, der dieses Thema behandelt.