Archiv Mana, ein Schlüsselfeature in der post Koordinator Ära.

Zusammenfassung der mir bekannten Informationen, siehe Quellen.

Das IOTA-Konsensmodell ist ein Modell, bei dem Konflikte zwischen Transaktionen (d.h.: zwei Transaktionen, die die gleichen Mittel ausgeben) durch die Stimmen der Nodes gelöst werden. Ab IOTA 2.0 gibt es im Netzwerk mit Mana eine knappe Ressource (eine interne Recheneinheit), sie steht im Mittelpunkt des Konsensmodells und bildet einen Schutz.- bzw. ein Reputationsmechanismus für Nodes, der sich auf mehrere Aspekte der Protokolllogik auswirkt. Mana ist am besten als ein Werkzeug zu betrachten, welches für verschiedene Aufgaben im Netzwerk eingesetzt wird.

Ohne eine Art von Schutzmechanismus könnten Angreifer ein Netzwerk wie IOTA angreifen, indem sie Millionen von Schein-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 jeweils Energie und Token-Staking als Sybil-Schutzmechanismen.

IOTA verwendet Mana, um u.a. 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, dem Konsens-Algorithmus (FPC), Autopeering und  verteilten Zufallszahlengenerator (dRNG). In der Zukunft wird sich Mana also zu einem komplexeren mehrdimensionalen Reputationssystem entwickeln, um den Beitrag eines Nodes zur Netzwerkaktivität und dessen Sicherheit zu bewerten.

• Congestion Control Algorithm: zur Verhinderung von Spam > je mehr Mana Sie haben, desto mehr Ihrer Nachrichten/Transaktionen werden gesendet/gelesen/verarbeitet.
  
  

Rate Control: Ein hoher Manahalter (rechts) darf im Falle einer Überlastung des Netzwerks eine größere Anzahl von Transaktionen durchführen. 

• FPC-Abstimmung: Angriffe/Konflikte per Abstimmung verhindern > je mehr Mana Sie haben, desto mehr wird Ihren Meinungen berücksichtigt werden. Die Mana-Menge, die von jedem Node gehalten wird, wird im öffentlichen Ledger (Tangle) als dessen Mana-Status verfügbar sein. Dies wird es ermöglichen, Mana bei der zufälligen Auswahl von Nodes für Abfragen über konfligierende Transaktionen zu berücksichtigen. Daher werden die Nodes in den Abstimmungsrunden (Voting) für den Fast Probabilistic Consensus andere Nodes nach dem Zufallsprinzip auswählen, um deren Meinung einzuholen, wobei sie durch die Manamenge, über die sie verfügen, beeinflusst werden.

• 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.
• Auto-Peering: Eclipse-Angriffe verhindern > Ihre Nachbarn/Partner haben eine ähnliche Menge Mana wie Sie.

Der Einfachheit halber kann man sich Mana auch als einen parallelen Reputations-Token (kein echter handelbarer Token) zum IOTA-Token vorstellen, das von Adressen in einem proportionalen Verhältnis zu den IOTA-Token gehalten wird, dabei sind drei Konzepte besonders wichtig: 

• Pending Mana (dt. ausstehend/schwebend): Adressen erzeugen Pending Mana in einer Größenordnung, die proportional zu dem von ihnen gehaltenen Guthaben ist.

• Mana: Wenn Gelder (d.h. IOTA-Token) von einer Adresse ausgegeben werden, wird das Pending Mana, das von dieser Adresse erzeugt wurde, in Mana umgewandelt und an ein Node verpfändet. Die Menge an Mana, die dieser Node erhält, ist proportional zu der Menge an Iota-Token, die bei der Transaktion gesendet werden. Das Pending Mana wird fortan durch die Guthaben auf der Adresse des Empfängers erzeugt.

• Decay (dt. Verfall): Mana zerfällt proportional zu seinem Wert, wodurch verhindert wird, dass das Mana mit der Zeit unbegrenzt wächst.

Der Mana-Lebenszyklus beginnt mit der Existenz von pending Mana auf jeder Adresse mit Guthaben, proportional zu ihrem Guthaben. Wenn nun Adresse A 50 Miotas an Adresse B sendet, erhält der Full-Node, den der Emittent bei dieser Transaktion auswählt einen proportionalen Betrag an Mana zugeteilt. Auf diese Weise werden die Nodes im Laufe der Zeit, während sie für das Netzwerk arbeiten, Mana anhäufen, aber sie werden aufgrund des Zerfallsmechanismus (Decay) kontinuierlich etwas Mana verlieren. Hinweis: Pending Mana zerfällt nicht im Laufe der Zeit (wie Mana), stattdessen wird bei dem sich ansammelnden Pending Mana die Erzeugungsrate verringert, um das Erreichen einer bestimmten, im Protokoll festgelegten Grenze zu vermeiden.

Bild: Jedes Mal, wenn eine Transaktion Geld bewegt, “verpfändet” diese Transaktion eine Menge Mana an eine Node-ID. 

Mana hat u.a. den Zweck den am Netzwerk teilnehmenden Nodes eine Rangfolge/Reputation zu verleihen, die es ermöglicht, ehrlich arbeitende Nodes mit einer gesicherten Historie von neuen Nodes (Identitäten) die dem Netzwerk gerade erst beigetreten sind zu unterscheiden und den Nodes ggf. den Vorzug bei der Verarbeitung von Transaktionen zu gewähren, falls das Netzwerk nahe seiner Verarbeitungskapazität ist. Die meisten Aspekte des neuen Protokolls (Voting, Peering, Ratensteuerung, usw.) werden daher Nodes mit hohem Mana gegenüber Nodes bevorzugen, die ihre ehrliche Arbeit im Netzwerk nicht nachweisen können. Selbst wenn es also einem Angreifer gelingt, 100 falsche Identitäten zu erschaffen, wird seine “Meinung” nicht berücksichtigt, da seine Reputation (Mana) ihn eine Zeit lang hinter allen ehrlich arbeitenden Nodes im Netzwerk, zurückstellen wird, so werden u.a. Identitätsfälschungen und Sybil-Angriffen verhindert.

Für die Full-Nodes bedeutet das, sofern der Posteingang nicht leer ist, verarbeitet jede Node Messages mit einer im Protokoll festgelegten Rate, diese Rate bestimmt den maximalen Durchsatz. Sollte das Netzwerk nahe an seinen Verarbeitungsmöglichkeiten sein, benötigt jemand der viele Daten-Transaktionen in kurzer Zeit vornehmen möchte Mana für die ausführende Node, um gegenüber anderen Transaktionen (ggf. Spam) bevorzugt zu werden. Dies lässt sich am besten mit dem Erkaufen einer höheren Bandbreite bei einem Internetanbieter vergleichen. Wenn Sie kein Mana haben und das Netzwerk überlastet ist, können Sie keine Transaktionen ausgeben und müssen warten. Hier liegt das wirtschaftliche Modell, welches im Vergleich zu anderen Kryptowährungen einzigartig ist. 

Wie funktioniert das? Genauso wie alles im Leben. Wenn eine Firma Büroräume benötigt, hat sie 2 Möglichkeiten, sie können die Räumlichkeiten entweder kaufen oder mieten. Das Gleiche gilt bei IOTA mit Mana. Wenn jemand das Tangle nutzen möchte, aber die Token nicht besitzen will, wird er Mana von anderen Leuten mieten müssen, auf die gleiche Weise, wie jemand eine Immobilie von einem Vermieter mietet. Einige Leute verwechseln dies oft mit einer Gebühr. Es ist KEINE Gebühr. Es ist ein Zuteilungsmechanismus, bei dem Leute, die zum Netzwerk beitragen, indem sie Token besitzen und/oder Nodes betreiben, Vorrang bei den Netzwerkressourcen bekommen.

In traditionellen Blockchains müssen Sie eine Gebühr bezahlen, unabhängig davon, ob Sie Token halten oder nicht. Es ist eine permanente Gebühr und man bekommt sie nicht zurück. Bei IOTA haben Sie die Möglichkeit, Token zu besitzen und damit für immer einen Anspruch auf einen Teil der Netzwerk TPS. Selbst wenn Sie den Ansatz wählen, keine Token zu besitzen und den Zugang mieten wollen, haben Sie feste kalkulierbare Kosten und einen zuverlässigen Durchsatz.

In der traditionellen Blockchain können Sie Token besitzen und Ihre Betriebskosten nicht kennen, da die Gebühren dynamisch sind. Transaktionen konkurrieren dort um den begrenzten Blockraum und überbieten sich gegenseitig bei den Gebühren um zeitnah berücksichtigt zu werden, daher sind dort die Betriebskosten nicht im Voraus bekannt. Bei IOTA haben Sie entweder 0 operative Kosten oder Sie kennen genau Ihre Mietzahlungen und können verlässlich kalkulieren.

Das Mana-Konzept ähnelt dem Staking (Proof of Stake), aber der Unterschied ist, dass man Token nicht sperrt/staked, um daran zu verdienen und die Renditen reale Renditen (Mieteinnahmen) sind. Bei PoS werden die Belohnungen durch die Inflation ausgezahlt (ein Teil kann aus Gebühren kommen oder auch nicht, aber der größte Teil ist aus Block-Belohnungen – Inflation). Das ist die Illusion von Rendite, die Bezahlung erfolgt, indem neue Token geprägt werden und dadurch das Gesamtangebot erhöht wird.

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 Sende-Nodes. Die Auswahl der Node-ID erfolgt 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. Mana kann also als Beweis für delegierten Token-Besitz betrachtet werden. 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 eigene Node verpfänden.
• Mieten (Mana-as-a-Service): Mana kann gegen Mietzahlungen von anderen Token-Inhabern erworben werden, dies kann mit IOTA-Token oder mit Bargeld (wie bei Amazon Cloud Credits) geschehen.
• Verarbeitung von Wert-Transaktionen: Ein Node kann Wert-Transaktionen im Austausch gegen das in diesen Transaktionen 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.

Zusammenfassung der wichtigsten Punkte:

• 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.
• Wer IOTA Token hält, der hat unabhängig von ihrem Wert einen Anspruch auf einen Teil der Netzwerkressourcen. Das ist für Sicherheitskritische industrielle und Echtzeitapplikationen deren Informationen zeitgerecht durch das Tangle müssen sehr wichtig.
• Mieten (Mana-as-a-Service): Mana kann gegen Mietzahlungen von anderen Token-Inhabern erworben werden, dies kann mit IOTA-Token oder mit Bargeld (wie bei Amazon Cloud Credits) geschehen.
• Es gibt derzeit zwei separate Werte für Mana, diese werden als Access-Mana und Consens-Mana bezeichnet, während Access-Mana verliehen/geleast werden kann, gibt es dagegen keinen Grund, dies für das Konsens-Mana zu tun.
• Werte-Transaktionen bringen immer ihr eigenes Mana für die Verarbeitung durch die Nodes mit, daher gibt es hier generell keine Einschränkungen.
• Es wird immer noch möglich sein, Daten-Transaktionen auch ohne Mana zu versenden – Mana wird nur in Zeiten der Überlastung verwendet, um den Nodes, die mehr Mana besitzen, mehr Priorität einzuräumen, um eine minimale garantierte Bandbreite in der Infrastruktur zu garantieren. Mana wird für längere Zeit keine Voraussetzung sein, um Transaktionen zu senden, denn derzeit können selbst Systeme mit FPGAs nicht so viele TPS spammen, um das Netzwerk an den Rand der Verarbeitungsmöglichkeiten zu bringen. In Zukunft wird zudem Sharding die Netzwerkkapazität deutlich erhöhen und das Problem einer theoretisch möglichen Überlastung lösen.
• Für die Sicherheit bei geschäftlichen Anwendungsfällen wurden Anregungen geschaffen (Transaktionen trotz Überlastung), um eigene Nodes zu betreiben, den Token zu halten und auch zu verwenden.
• Wer keine eigene Node und IOTA-Token besitzt, muss ggf. für die Nutzung fremder Nodes bezahlen, falls das Netzwerk ausgelastet ist und viele Transaktionen in kurzer Zeit getätigt werden sollen.
• Wer IOTA-Token besitzt, kann Mana vermieten und eine Art passives Einkommen generieren, falls zukünftig ein Markt dafür entsteht.
• Möchte ein Unternehmen nichts mit Kryptowährungen zu tun haben, kann Mana auch mit Bargeld bei einem Dienstleister gekauft werden.

Technische Details

Es gibt derzeit zwei separate Werte für Mana, diese werden als Access-Mana und Consensus-Mana bezeichnet, während Access-Mana von Token-Inhabern verliehen/geleast werden kann, gibt es dagegen keinen Grund, dies für das Consensus-Mana zu tun.

• Access-Mana – ist an den Token gebunden und dient der Überlastungskontrolle
• Consensus-Mana – wird durch Nodes aufgebaut und spiegelt dementsprechend die Reputation einer Node wieder. Je mehr Consensus-Mana von einer Node gehalten wird, desto besser die Reputation, die Node bekommt dann auch mehr FPC-Abfragen (Fast Probabilistic Consensus) und erhält mehr Gewicht bei den FPC-Votings. 

Jede Transaktion hat ein accessMana- und ein consensusMana-Feld, die bestimmen, welcher Node diese beiden Arten von Mana zugesprochen werden. Diese beiden Felder bezeichnen eine NodeID, den Empfänger des Manas. Hinweis: accessMana und consensusMana müssen nicht an dieselbe Node verpfändet werden.  Zusätzlich zu den Mana-Feldern wird den Transaktionen auch ein Zeitstempel-Feld hinzugefügt, das für die Berechnung von decay und effective mana verwendet wird.  Aus dem zugesagten Mana einer Transaktion kann eine Node lokal den Base-Mana-Vektor sowohl für Accesss-Mana als auch für Konsens-Mana berechnen.

Ein Base Mana-Vektor besteht aus Base Mana 1 und Base Mana 2 und dem jeweiligen Effective Base Mana. Bei einer Werttransaktion werden Base Mana 1 und Base Mana 2 wie folgt bestimmt:

1) Base Mana 1 wird dem Node entzogen, der die Ausgabe(n) erstellt hat, die als Eingabe(n) in der Transaktion verwendet wurden, und wird an den Node verpfändet, der die neue(n) Ausgabe(n) erstellt. Die Menge des entzogenen und verpfändeten Base Mana 1 entspricht dem Saldo der Eingabe.

2) Base Mana 2 wird zum Zeitpunkt der Ausgabe der Transaktion neu erstellt und dem Node zugesprochen, verfällt aber mit der Zeit. Die Menge des verpfändeten Base Mana 2 wird mit dem Konzept des “Pending Mana” bestimmt: Gelder, auf einer Adresse, erzeugen “Pending Mana”, das mit der Zeit wächst, aber begrenzt ist.

• Mana_pending = (alpha*S)/gamma*(1-e^(-gamma*t)), wobei alpha und gamma gewählte Parameter sind, S die Menge an Geldern ist, die ein Ausgang an die Adresse überträgt, und t die Zeit ist, seit die Gelder auf dieser Adresse liegen.

Ein Beispiel für einen Baase Mana-Vektor für Access-Mana könnte wie folgt aussehen:

Base-Mana wird zu bestimmten Zeitpunkten zugesprochen oder entzogen, was dazu führt, dass Base-Mana eine zeitlich diskontinuierliche Funktion ist. Um das Mana “geschmeidiger” und beständiger zu machen, wird ein exponentieller gleitender Durchschnitt auf die Base-Mana-Werte angewendet, was zu Effektivem Base-Mana 1 und Effektivem Base-Mana 2 führt.

Es ist wichtig zu beachten, dass das Konsumieren einer neuen Transaktion und das Verpfänden ihres Manas geschieht, wenn die Transaktion auf dem Node bestätigt wird. Gleichzeitig werden die Einträge der Nodes, deren Mana während des Verpfändens im Base-Mana-Vektor bzw. in den Base-Mana-Vektoren geändert wird, in Bezug auf die Zeit aktualisiert. Im Allgemeinen erfolgen Aktualisierungen aufgrund der Zeit immer dann, wenn auf das Mana einer Node zugegriffen wird. Außer im oben genannten Fall könnte dies beispielsweise eine Mana-bezogene Abfrage von einem externen Modul (FPC, Autopeering, DRNG, Rate Control, Tools usw.) sein.

Die folgende Abbildung fasst zusammen, wie Access-Mana und Consensus-Mana aus einer Transaktion abgeleitet wird:

Der Grund dafür, dass es zwei separate Base-Mana-Vektoren gibt, ist die Tatsache, dass AccessMana und ConsensusMana an unterschiedliche Nodes verpfändet werden können. 

Die genauen mathematischen Formeln und ihre jeweiligen Parameter werden später während des Testnet festgelegt, sobald das Mana berechnet ist, läuft das Protokoll wie folgt ab:

Das Gewicht sowohl des Consens- als auch des AccessMana 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 AccessMana besitzt und nur 50 % des AccessMana 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 ConsensMana. Je mehr ConsensMana 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 AccessMana einen Mindestzugang zum Netzwerk garantiert, bestimmt das gesamte aktive Mana den tatsächlich gewährten Zugang.

Autopeering-Simulator

Um einen Aspekt des Manakonzepts zu veranschaulichen, wurde im folgenden ein wenig mit dem Autopeering-Simulator gespielt. Mana dient als Sybil-Schutz beim Autopeering. Im folgenden gehen wir von 200 ehrlichen Nodes mit Mana aus, die nach einem Zipf-Gesetz mit Parameter s=1 verteilt sind. Je heller das Blau, desto mehr Mana besitzt der Node. Nodes mit ähnlichem Mana sollten zusammen peeren. Der orangefarbene Node ist ein bösartiger Node, der 10% des gesamten Manas besitzt.

Nun versucht der orangefarbene Angreifer einen Sybil-Angriff und teilt sein Mana auf 100 Nodes auf.  Die hohen Mana-Nodes sind gut vor den bösartigen Nodes geschützt, und selbst die kleinen Mana-Nodes werden nicht eclipsed. Hinweis: Eine Eclipse-Attack ist ein Cyber-Angriff, der darauf abzielt, einen bestimmten Benutzer zu isolieren und nicht das gesamte Netzwerk und anzugreifen.

Wenn sich der Angreifer auf 200 Nodes aufteilt, ergibt sich folgendes Ergebnis.

Die “statischen” Bilder zeigten nicht so gut, was passiert, wenn ein Angreifer in ein bestehendes Netzwerk eindringt, daher gibt es noch kleine Videos. Nach einem Sybil-Angriff treten neue ehrliche Nodes in grün dem Netzwerk bei. Auch hier gilt: Je blauer (türkis), desto mehr Mana.

Die Mana-Menge der neuen Nodes ist höher als die Mana der orangefarbenen Angreifer-Nodes. Neue Nodes mit null Mana oder Mana gleich dem Mana der Angreifer-Nodes werden meist mit den Angreifer-Nodes gleichziehen. Diese Nodes werden wahrscheinlich am Anfang verdrängt. Die Auswirkung des Sybil-Angriffs war also, dass neue Nodes mit sehr geringem Mana Probleme haben, dem Netzwerk beizutreten.

Ohne den ManaSybilSchutz würden jedoch auch Nodes, die schon lange existieren, Gefahr laufen, eclipsed zu werden. Die Kunst besteht darin, ein gutes Gleichgewicht zwischen dem Schutz des bestehenden Netzwerks und dem Senken der Eintrittsbarriere zu finden.

Häufig gestellte Fragen an die IOTA Foundation.

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.

Benutzer mit Null Mana könnten möglicherweise Nachrichten senden dürfen, wenn das Netzwerk nicht überlastet ist, wie von Partnern und Mitgliedern der breiteren Community gewünscht. Wir untersuchen die Möglichkeit, Nachrichten für Knoten 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 (PoW). Dies ist keineswegs einfach oder gar möglich. Wir werden Ihnen mitteilen, was unsere Forschung herausfindet, sobald wir Ergebnisse haben.

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: Basemana und effektives Mana. Das Basemana 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=α(Base-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 Basemana 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 die Art 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 ConsensMana 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 ConsensMana nach Belieben vergeben werden. Es ist jedoch ganz offensichtlich, dass für jeden, der über Iota-Token verfügt, einfach kein Anreiz besteht, mit ConsensMana zu “handeln”. Nur ein Angreifer hätte ein Interesse daran, eine ungebührliche Menge an ConsensMana anzusammeln, und deshalb ist der Entwurf der IOTA zur Trennung von Consens- und AccessMana so wichtig. Es ermöglicht den Handel mit AccessMana, während gleichzeitig der Konsens geschützt werden kann. Ungeachtet des fehlenden Anreizes zum Handel mit ConsensMana könnte ein Angreifer immer noch versuchen, Token mit dem Ziel zu erwerben, ConsensMana 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 Token erforderlich wäre, um einen Angriff durchzuführen. Darüber hinaus würde der Verkauf von Token vor einem Angriff ohne Preisabsturz viel länger dauern, als das ConsensMana seinen Einfluss auf das Netzwerk behalten würde.

Was ist ungefähr die Länge der Zerfallsfunktion (Decay)?

Liegt die Halbwertszeit des Manas eher bei einer Minute oder eher bei einem Jahr? Erinnern Sie sich daran, dass bei der Mana-2-Berechnungsmethode das Mana gemäß einer Exponentialfunktion abfä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 “Aktive-Mana” gemessen?

“Aktive Mana” kann auf unendlich viele Arten berechnet werden, abhängig von seinem Zweck. Aktiv zu sein könnte bedeuten “der Prozentsatz der Nodes, die in den letzten X Sekunden mindestens eine Transaktion gesendet haben” oder es könnte bedeuten “der Prozentsatz der Nodes, die im Hinblick auf ihre Reputation ‘genug’ Transaktionen gesendet haben.” Für die Congestion Control muss die Node das Aktive Mana nicht kennen: die Node schaut einfach auf ihren Posteingang und reagiert entsprechend dem Mana der abgebenden Nodes. Die Information über die Menge an Mana, die jede Node hält, ist für jede Node verfügbar, basierend auf der ausgebenden Node-ID, die Teil jeder Nachricht ist, die sich durch das Netzwerk ausbreitet. Für FPC und Autopeering verwaltet das Peer Discovery-Modul eine Liste bekannter Nodes, die derzeit online sind. Der Nodes verwendet diese Liste für FPC-Abfragen und für die Auswahl von Nachbarn.

Wird Mana in die gleichen Probleme von einem Mangel an Dezentralisierung laufen, wie PoS-Tokens?

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 benutzen.  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. 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 doppelte Ausgabe (Double Spend ) 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, scheint 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 und Reputationsverluste für egoistische oder sich falsch verhaltende Nodes – versucht IOTA, die Diskrepanzen in der Reputation über alle Nodes hinweg zu 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 erhalten.

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

Kann man mit genügend Mana eine Double Spend durchführen?

Ist es möglich, Doppelausgaben zu genehmigen, indem man zwei widersprüchliche Transaktionen genehmigt und in den Tangle einbettet, wenn es genug böswillige Node-Besitzer 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 Node-Besitzern/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 ein Fork entstehen, bis sie aufgelöst ist, wären keine Nachrichten endgültig.

Wie auch immer: Kein Angreifer wird 30% des Konsens-Manas aus IOTA-Beständen haben. 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 entstehen 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 macht keinen Sinn, dass ein solcher Markt heranreift.

Wie verhindern Sie Prioritätsumkehrungen?

Dies könnte passieren, wenn eine Transaktion mit hohem Mana von einer Transaktion mit niedrigem Mana abhängt. Wenn Transaktion A von Transaktion B abhängt, muss B im Vergangenheits-Kegel (Cone) von A sein. Wenn eine High-Mana-Node eine Nachricht mit Transaktion A ausgibt, und ein Low-Mana-Node gibt Transaktion B aus, wird A nicht weiter geklatscht (gossiped), wenn B nicht geklatscht wird.

Darüber hinaus – im Gossip-Protokoll – klatschen Nodes nur “bei Verfestigung”, was bedeutet, dass eine Node eine Nachricht nicht klatschen wird, wenn seine Parents nicht auch geklatscht wurden. Tatsächlich wird der Congestion-Control-Algorithmus eine Nachricht erst dann in Betracht ziehen, wenn er den gesamten Vergangenheits-Kegel erhalten hat.

Kann eine Null-Mana-Node Transaktionen ausgeben, wenn es keine Überlastung gibt?

Im aktuellen Design für die Congestion Control Algorithmus braucht man Mana, um eine Nachricht zu senden. Dies soll verhindern, dass plötzliche aggressive Spam-Attacken das Netzwerk stören. Wir prüfen die Möglichkeit, dass Nodes, wie in der Einleitung erwähnt, einen Arbeitsnachweis erbringen können, um Nachrichten ohne Mana auszugeben. Allerdings kann die Möglichkeit, die ungenutzte Bandbreite zu geringen Kosten auszunutzen, auch böswillige Nodes begünstigen, die versuchen, das Netzwerk zu verstopfen oder, schlimmer noch, Ledger-Inkonsistenzen zu erzeugen. Da IOTA 100% permissionless 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 Token-Halter im Netzwerk unterhalten könnten. Die Idee ist, dass Nodes 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  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 Weise verarbeitet wie Werttransaktionen (Wertnachrichten). In Zeiten der Überlastung benötigt eine Node ausreichend Mana, um eine von beiden ausgeben zu können.

Benötigen Sie überhaupt Mana, wenn Sie gerade eine Node eingerichtet haben und eine Werttransaktion durchführen wollen?

Sie benötigen kein Mana, wenn Sie einfach nur eine Node einrichten” und das Tangle überwachen. Null-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 der 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, untersucht IOTA, wie es Nodes ohne Mana erlaubt werden kann, Nachrichten zu senden, wenn es keine Überlastung gibt. IOTA hat eine vielversprechende Lösung, aber es muss erst sichergestellt werden, dass sie keine Angriffsvektoren öffnet.

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, Krypto zu halten, aufgrund von Vorschriften, Steuern, oder allgemeine Skepsis. 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 eine andere Node verpfändet werden?

Was war der Grund für die Entscheidung, Mana nicht an Nodes zu vergeben, 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 dem 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 Node sein Access-Mana nur periodisch benötigt, z. B. zu Spitzenverkehrszeiten, nur an Wochentagen oder Wochenenden oder in anderen Abständen. Wenn der Eigentümer der Node 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-Token.

Zum Beispiel könnten einige Unternehmen  in der nahen Zukunft nicht wollen, Kryptowährungen in den Büchern zu haben und Token zu halten, dass 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, die die Transaktion verarbeitet, wird die Entstehung eines Marktes fördern, der den Zugang im Austausch gegen Fiat-Geld ermöglicht, um ggf. 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 Access Mana?

Ungenutzte Bandbreite wird proportional zu der Menge an Access Mana aufgeteilt, die aktive Benutzer haben. Das heißt, wenn Sie z.B. 1 % Access Mana 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 der DLT, und Mana ermöglicht dies auf faire Weise. Die Zusammensetzung des überlasteten Netzwerks ist 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.

Wie messen Sie, wann das Netzwerk überlastet ist?

Ein Raspberry Pi kann nur einen Bruchteil eines AWS-Knotens verarbeiten, so dass sie sehr unterschiedliche Ansichten darüber haben würden, wann die “mana-basierte Ratenkontrolle” einsetzen muss – und wenn sie voneinander abweichen, haben Sie wieder Prioritätsumkehreffekte.

Zunächst einmal muss der Congestion-Control-Algorithmus nicht feststellen, ob das Netzwerk überlastet ist oder nicht. Wenn es keine Überlastung gibt, dann wird der Posteingang der Nodes meistens leer sein. Jede Node im Netzwerk wird Nachrichten mit einer maximalen, vom Protokoll festgelegten Rate verarbeiten. Diese Rate bestimmt die Mindestanforderungen an die Hardware der Nodes, einschließlich Bandbreite und Rechenleistung. Jeder Rechner ohne diese Fähigkeiten wird nicht in der Lage sein, einen 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 Mana-System manipulieren, um das Netzwerk zu überlasten?

Welcher Prozentsatz an Mana, der von ehrlichen Node-Besitzern gehalten wird, ist erforderlich, um eine künstliche Sättigung des Netzwerks zu verhindern, um das Entstehen eines Marktes für gebührenpflichtige Transaktionen zu verhindern, unter der Annahme, dass böswillige Node-Besitzer das Netzwerk künstlich sättigen könnten (“Spam”), um ihre Netzwerkkapazität (oder Mana) (an den Höchstbietenden) 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 Überlastung 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.

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

Ja.

Quellen

https://blog.iota.org/explaining-mana-in-iota-6f636690b916

https://blog.iota.org/identities-and-sybil-protection-in-iota-9c62916ff374/

https://github.com/iotaledger/goshimmer/blob/develop/docs/001-mana_proposal.md

https://luka99.medium.com/the-economic-model-of-iota-c28732143d51

https://luka99.medium.com/the-tech-behind-iota-part-1-introduction-b8f82775325a