IOTA 2.0 DevNet (Nectar) – Die Ära der Dezentralisierung von IOTA beginnt hier

TL;DR

Heute starten wir das IOTA 2.0 DevNet, das erste vollständig dezentralisierte IOTA-Netzwerk ohne die Notwendigkeit eines Koordinators, zusammen mit unserem neuen Digital Assets Framework. Wir laden jeden (und jede Maschine) ein, diesem Netzwerk beizutreten, zu lernen und die Zukunft von IOTA schon heute zu erleben. Schauen Sie sich die schicke neue Website, den Tangle-Explorer und die Entwicklerdokumentation an.

Tangle Explorer

Im Jahr 2015 entwarf das IOTA-Projekt eine Vision für ein skalierbares, gebührenfreies, dezentrales Distributed-Ledger-Protokoll, das als The Tangle bekannt wurde.

Es wäre ein Leichtes gewesen, eine PoW- oder PoS-basierte Blockchain zu kopieren und sie zu verbessern. Einige Blockchain-Iterationen haben signifikante Verbesserungen des ersten Protokolls, das von Bitcoin im Jahr 2008 vorgeschlagen wurde, geliefert. Dennoch leiden alle diese Netzwerke nach mehr als einem Jahrzehnt der Innovation an denselben grundlegenden Nachteilen, die eine Blockchain-Architektur mit sich bringt: Entweder sind sie nicht wirklich dezentralisiert, nicht skalierbar, haben ineffiziente Gebührenstrukturen, verschwenden Strom oder sind einfach nicht sicher genug (oder sogar mehrere dieser Probleme zusammen).

Ab 2015 glaubten viele, dass es unmöglich sei, diese fundamentalen Nachteile zu überwinden und eine komplett neue Distributed-Ledger-Architektur einzuführen. „Ich werde es glauben, wenn ich es sehe“ war ein beliebtes und oft wiederholtes Mantra von frühen Kritikern der ehrgeizigen Pläne von IOTA. Es ist klar, warum das so war: Es gab keinen greifbaren Beweis für die Machbarkeit, eine DLT zu entwickeln, die auf etwas anderem als der üblichen Blockchain-Architektur basiert, oder ein Netzwerk, das ohne Transaktionsgebühren und wirtschaftliche Subventionen (in Form von Inflation) als sicher gelten könnte, um Anreize für Validierer zu schaffen. IOTA wollte beweisen, dass beides realisierbar ist.

Im Jahr 2019 skizzierten das IOTA-Forschungsteam und akademische Partner die theoretische Grundlage für ein gebührenloses, vollständig dezentrales und sicheres IOTA-Protokoll – was als IOTA 2.0 bekannt wurde. Die Lösung wurde daraufhin in mehr als einem Dutzend akademischer Arbeiten definiert und begutachtet, in renommierten Fachzeitschriften veröffentlicht und auf angesehenen Konferenzen vorgestellt.

Wir haben das IOTA 2.0-Protokoll als offenes, gerechtes und faires Distributed-Ledger-Netzwerk konzipiert, in dem jeder Netzwerkteilnehmer den gleichen Regeln und Algorithmen unterliegt und die exakt gleichen Rechte hat. Aufgebaut auf einem Leaderless-Konsens-Protokoll, trägt jeder Knoten direkt zur Sicherheit und zum Konsens des Netzwerks bei, indem er Transaktionen validiert. Mit geringen Ressourcenanforderungen, die für das Internet der Dinge geeignet sind, war unsere Vision, dass IOTA 2.0, sobald es in der Produktion eingesetzt wird, eines der größten und dezentralsten Distributed-Ledger-Netzwerke überhaupt werden würde.

Nach Jahren harter Arbeit, um die theoretischen Grundlagen in Code durch unser Team und akademische Partner zu implementieren, und fast einem Jahr umfangreicher Tests, Validierung und iterativer Entwicklung zusammen mit unserer Community, sind wir endlich bereit, dass jeder es „sehen und glauben“ kann. Wir sind stolz darauf, heute den Start des IOTA 2.0 Development Network (DevNet) bekannt zu geben: das erste vollständig dezentralisierte, skalierbare und gebührenfreies IOTA-Netzwerk, wie es bei der Gründung des Projekts im Jahr 2015 vorgesehen war.

  • Keine Gebühren
  • Keine Blöcke
  • Keine Kette
  • Keine Schürfer
  • Keine verschwendete Energie
  • Keine Zensur
  • Keine Zentralisierung
  • Keine Berechtigungen

Die totale Freiheit.

Neue Website für das Devnet

Das IOTA 2.0 DevNet ist offen für jeden und jede Maschine, um daran teilzunehmen, ohne Gebühren zu Transaktionen durchzuführen, darauf aufzubauen – und die Zukunft von IOTA schon heute zu erleben. Wir haben eine Reihe von Möglichkeiten entwickelt, wie Sie sich in das Netzwerk einbringen können:

Das IOTA 2.0 DevNet ist die nächste Evolution auf unserem Weg zu einem globalen Standard und baut auf der Arbeit des erfolgreichen Chrysalis-Upgrades im April 2021 auf. Mit dem IOTA 2.0 DevNet sind unsere Partner und die Community eingeladen, mit einer völlig neuen Spielwiese und einer Vielzahl von Werkzeugen, Funktionen, Anwendungsfällen und Möglichkeiten zu innovieren. Das IOTA 2.0 DevNet führt nicht nur die vollständige Dezentralisierung ein, sondern es ist auch das erste Mal, dass unser Digital Assets Framework für die Community bereit ist, damit zu experimentieren. Heute ist der erste Tag, an dem unser Ökosystem mit dem Aufbau von dApps und neuen Geschäftsmodellen beginnen kann, bevor die unvermeidliche Zukunft von IOTA 2.0 auf unserem Mainnet (bekannt als „Coordicide“) startet.

Es ist wichtig, im Hinterkopf zu behalten, dass IOTA 2.0 von der IOTA Foundation, den Mitwirkenden der Community und den akademischen Partnern schnell weiterentwickelt werden wird. Das Netzwerk wird kontinuierlich verbessert, aufgerüstet und getestet werden, und Sie können mit gelegentlichen Unterbrechungen und Fehlern rechnen. Dies ist der Ansatz, den wir wählen müssen, um den Fortschritt und die technologische Entwicklung zu beschleunigen. Lassen Sie uns schnell vorankommen und gemeinsam etwas bewegen!

Das IOTA 2.0 DevNet führt eine Vielzahl neuer Features und Funktionalitäten ein, darunter:

  • Erlaubnisfreie und dezentrale Abstimmung mit FPC
  • Schnelle Finalität mit Mana-basierter Zustimmungsgewichtung
  • Energiesparendes Sybil-Schutzsystem mit Mana
  • Fairer Zugang verwaltet durch den neuartigen und führerlosen IOTA Congestion Control Algorithmus
  • Effiziente Algorithmen unter Verwendung eines parallelen Reality-Ledger-Status
  • Sicheres Autopeering-System, das sichere Netzwerkverbindungen garantiert
  • Unser neues Digital Assets Framework zur Erstellung von tokenisierten Assets und NFTs
  • Verankerung von IOTA-Smart-Contract-Ketten

Was kommt also als nächstes? GoShimmer wurde zunächst als Forschungsprototyp entwickelt. Da nun alle Komponenten in Code implementiert sind, können wir die Leistung jedes Moduls detaillierter bewerten, was uns erlaubt, ihr Design zu verbessern und wichtige Parameter festzulegen. Dies wird unserem Forschungsteam dabei helfen, das standardisierte IOTA 2.0-Protokoll fertigzustellen und in Zusammenarbeit mit unserem Ingenieursteam dieses Protokoll in Rust und Go in den Bee- bzw. Hornet-Knoten zu implementieren.

Gemeinsam mit unseren Forschungspartnern werden wir das IOTA 2.0 DevNet nutzen, um:

  • Testen und Prüfen des Protokolls durch Experimentieren und Sammeln von Daten und weitere Optimierung der gesamten IOTA 2.0-Lösung
  • Untersuchung, wie alle Parameter definiert werden sollten
  • Verbessern Sie die Software-Implementierungen als Vorbereitung für die Unterstützung in Bee- und Hornet-Knoten
  • Identifizierung und Beseitigung möglicher Leistungsengpässe
  • Vereinfachung des Protokolls durch Eliminierung aller Elemente, die als unnötig erachtet werden

Durch die iterative Entwicklung im IOTA 2.0 DevNet werden wir schließlich Anreize in das Netzwerk einführen. Nach der Bewertung verschiedener Optionen für das incentivierte Testnet ist unser Team zuversichtlich, dass wir einen geeigneten Ansatz entwickelt haben, um die IOTA 2.0-Lösung offen zu testen und den Coordicide im Mainnet und das Upgrade auf IOTA 2.0 zu beschleunigen. Am wichtigsten ist, dass wir glauben, dass dies eine langfristige Lösung ist, die zum nachhaltigen Wachstum und zur Beschleunigung von IOTA und seinem Ökosystem beitragen wird – aber das ist eine Geschichte für einen anderen Tag. Heute feiern wir den Start des IOTA 2.0 DevNet und markieren offiziell den Beginn des Marsches in Richtung der vollständigen Dezentralisierung von IOTA.

Original by IOTA Foundation: https://blog.iota.org/iotav2devnet/

Eine (fast) nicht-technische Einführung in IOTAs Mana

The National Physical Laboratory of India

Für die dritte nationale Wahl in Indien im Jahr 1962 entwickelte das National Physical Laboratory of India eine eigene violette Tinte, die aus Silbernitrat, einer lichtempfindlichen Verbindung, die in Fotochemikalien vorkommt, hergestellt wurde. Sobald der Finger eines Wählers mit dieser Tinte bestrichen wurde, hinterlässt jede Einwirkung von UV-Strahlen einen unauslöschlichen Abdruck, der so lange bestehen bleibt, bis der Körper eine völlig neue Hautschicht bildet. Da diese Form der Wahlauthentifizierung von der Sonne selbst erzeugt wird, beweist der einfache Akt des Zeigens der Hand, ob man gewählt hat oder nicht. Die Formel der Wahltinte bleibt ein streng gehütetes Staatsgeheimnis.

Blauer Finger für die Wahl

Dieser ausgeklügelte Sybil-Schutzmechanismus, den Indien immer noch in Länder auf der ganzen Welt exportiert, beruht auf der Tatsache, dass Hände schwer zu bekommen sind. Wenn Sie eine unmarkierte linke Hand finden, können Sie beweisen, dass Sie die Erlaubnis haben, zu wählen. Durch ein einfaches Zertifizierungsverfahren erhält jeder Bürger eine Stimme, und niemand kann zweimal wählen, ohne sich zu entblößen. Ohne irgendeinen Prozess der Identifikation – Ausweise, Wählerregistrierung, Wahltinte, z.B. – wäre kein Wahlsystem sicher gegen doppelte Stimmen.

Jeder Distributed Ledger braucht eine Lösung, um Konflikte zu lösen und muss daher eine endliche Anzahl von Stimmen an die Netzwerkteilnehmer vergeben, um zu verhindern, dass jeder so oft wählen kann, wie er will. Im Bitcoin-Netzwerk hat jeder, der ein Gewinnlos hat – die Lösung eines kryptographischen Puzzles, das durch das Protokoll definiert ist – das Recht, über Konflikte abzustimmen. Die Wahrscheinlichkeit, dass Miner gewinnen, ist proportional zu der Menge an Strom, die in die rechnerische „Arbeit“ zur Lösung des kryptographischen Rätsels gesteckt wurde, weshalb das gewinnende „Lotterielos“ „Proof of Work“ (PoW) genannt wird. Der Proof of Work, wie die unmarkierten Hände eines indischen Wählers, demonstriert jedem Knoten im Netzwerk, dass ein Miner ein unausgeübtes Stimmrecht hat, mit dem er die sogenannte längste Kette wählen kann. Als Belohnung für diesen aufwendigen Proof-of-Work erhält der Miner, oder Konsens-„Anführer“, Gebühren und Block-Belohnungen.

Im Gegensatz zu Proof-of-Work-basierten Systemen ist das IOTA-Protokoll ein gefühlloses und führerloses Protokoll: alle Netzwerkteilnehmer können parallel Ledger-Updates vorschlagen, Transaktionen validieren und an der Lösung von Konflikten teilnehmen. Dieses Design hebt die Unterscheidung zwischen Nutzern und Minern auf. Es ist eine fundamentale Abkehr von Bitcoin und anderen PoW- und PoS-basierten Kryptowährungen, die einen einzelnen Anführer wählen, der Updates in die Kette schreibt und über Konflikte abstimmt, einen Block nach dem anderen. Obwohl IOTA ein führerloses Protokoll ist, muss IOTA, wie alle DLTs, den Netzwerkteilnehmern endliche Stimmrechte auf eine überprüfbare Weise zuweisen, um zu verhindern, dass jemand mehr als seinen fairen Anteil wählt.

Das Recht zu wählen

Konsensuales Mana

Eine Stammaktie, manchmal auch Stimmrechtsaktie genannt, ist ein Wertaufbewahrungsmittel und möglicherweise sogar ein Tauschmittel. Sie dient auch als Nachweis für das Recht, bei Wahlen zum Aufsichtsrat eine Stimme abzugeben, die durch eine Stimmrechtsvollmacht an andere delegiert werden kann. Eine Aktie, eine Stimme. In ähnlicher Weise verwendet IOTA die Token, die dem IOTA-Protokoll eigen sind, um das Recht zu beweisen, bei Konflikten abzustimmen. Dieses Stimmrecht, der delegierte Nachweis des Token-Besitzes, wird im IOTA-Protokoll Konsens-Mana (cMana) genannt.

Die Idee, Token-Besitz als Mittel zur Vergabe von Stimmrechten zu nutzen, ist nicht neu. Bereits 2011 schlug ein Benutzer auf dem BitcoinTalk Nachrichtenbrett, der sich selbst QuantumMechanic nannte, eine der ersten Beschreibungen der Idee vor:

Blogbeitrag für die Einführung von PoS

Es ist erwähnenswert, dass sich in QuantumMechanics Definition der Proof of Stake auf die Idee bezieht, Stimmen an andere Knoten zu delegieren, aber nichts mit dem Konzept des Slashings zu tun hat – also dem Entzug von Token von einem Benutzer, der in einer offensichtlich böswilligen Weise abstimmt, als eine Form der Bestrafung – bekannt aus populären PoS-basierten Kryptowährungen.
„Stake“ bezieht sich hier darauf, einen Anteil am Netzwerk als Ganzes zu haben. Wie Benutzer QuantumMechanic weist darauf hin, später in dem Beitrag, Benutzer, die einen großen Anteil an dem Netzwerk halten würde einen Anreiz haben, um den Wert des Netzwerks zu erhalten, indem Sie nicht in böswilliger Weise abstimmen. Proof Of Stake (PoS), in der hier beschriebenen einfachen Form, ist eher ein delegierter Nachweis des Tokenbesitzes, der Anteile am Wert des gesamten Netzwerks repräsentiert. Diese einfache Form ist der Lösung von IOTA recht ähnlich.

In IOTAs gefühllosem und führerlosem Design ist die Rolle von cMana im System anders als die von PoS oder PoW in einer Blockchain. Beim Nakamoto-Konsens wird PoS oder PoW verwendet, um einen einzelnen Blockproduzenten zu wählen, der das Recht erhält, in das Ledger zu schreiben. Wenn zufällig mehr als ein Blockproduzent gewählt wird, dann wird der nächste Blockproduzent entscheiden, welchem der beiden zuvor generierten Blöcke er folgt. In der Folge wird das Netzwerk schließlich der längsten Kette folgen. Im Zusammenhang mit dem Nakamoto-Konsens ist der Sybil-Schutz auch Teil eines Mechanismus, der lineare Aktualisierungen des Ledgers erzwingt. Da IOTA den Nutzern erlaubt, den Ledger parallel zu aktualisieren, wird cMana verwendet, um die Stimmrechte über das gesamte Netzwerk zu verteilen, so dass alle cMana-Inhaber direkt am Konsensfindungsprozess teilnehmen können.

Der Fast Probabilistic Consensus (FPC) ist ein Abstimmungsprotokoll, bei dem alle Netzwerkteilnehmer das Recht haben, eine Stimme über einen Konflikt abzugeben, gewichtet im Verhältnis zu den von ihnen gehaltenen cMana.

Wenn zwei konfliktbehaftete Ledger-Updates ungefähr zur gleichen Zeit im Tangle eintreffen, könnten verschiedene Knoten unterschiedliche Wahrnehmungen darüber haben, welches zuerst kam. Sie verwenden FPC, um sich darauf zu einigen, welche zu akzeptieren und in das Hauptbuch aufzunehmen ist. Vereinfacht ausgedrückt, fragen die Knoten die Meinung einiger zufällig ausgewählter Nachbarknoten ab und aktualisieren ihre Meinung, indem sie dem Mehrheitsvotum (gewichtet mit cMana) ihrer Nachbarn folgen. Durch dieses einfache Verhalten kommt das gesamte Netzwerk nach einigen Abstimmungsrunden relativ schnell zu einer Einigung, die im Falle eines solchen Konflikts nur wenige Sekunden dauert.

In ähnlicher Weise wird angenommen, dass Starenschwärme ihr kollektives Verhalten organisieren, indem sie individuell das Verhalten von sechs oder sieben benachbarten Vögeln im Schwarm verfolgen. Jeder Vogel trägt zum organisierten Verhalten der Gruppe bei und erreicht so eine Art führerlosen Konsens darüber, in welche Richtung er als kollektiver Schwarm fliegen soll. Das IOTA-Protokoll verhält sich in ähnlicher Weise wie diese Art von organischen Systemen.

Vogelschaar von Staren

Zugangsmana

In den Anfängen des öffentlichen Telefons mussten die Benutzer einer Telefonistin eine spezielle, von der Telefongesellschaft geprägte Wertmarke vorlegen, die ihnen erlaubte, das Telefon für ein paar Minuten zu benutzen. Diese Interaktion wurde schließlich mechanisiert, aber die proprietären Telefonmarken blieben in den USA bestehen, bis ihr Metall während des Zweiten Weltkriegs zur Herstellung von Patronenhülsen verwendet wurde.

Prepaid-Telefonkarten haben das Münztelefon im 21. Jahrhundert verdrängt, aber das Prinzip ist immer noch dasselbe: Sie beweisen das Recht auf Zugang zu einem Dienstprogramm, in diesem Fall die Bandbreite der Telefongesellschaft.

Münzeinwurf für ein Telefongespräch

Dies weist auf eine weitere wichtige Rolle hin, die mana im IOTA-Protokoll spielt: Zugangsrechte zu einer knappen Ressource. Neben dem Nachweis von Stimmrechten vergibt mana auch Zugriffsrechte, genannt access mana (aMana). Access mana bestimmt die Erlaubnis, Updates in den Ledger zu schreiben – oder in einfachen Worten „Transaktionen zu senden“. Je mehr aMana ein Benutzer hat, desto häufiger kann er die Bandbreite des Netzwerks nutzen, um Transaktionen zu senden.

Beim Nakamoto-Konsens sind das Schreiben eines neuen Blocks und die Abstimmung über die längste Kette ein und dasselbe: Ein neuer Block ist automatisch eine einzige Abstimmung darüber, welche Kette die längste ist. Es ist jedoch möglich, zumindest logisch zwischen „Zugriffsrechten“ und „Stimmrechten“ zu unterscheiden. PoW und PoS weisen einem einzelnen Blockproduzenten nicht nur das Recht zur Abstimmung zu, sondern auch das Recht, den Ledger zu verändern, indem neue Informationen im Netzwerk veröffentlicht werden. Auf die gleiche Weise unterscheidet IOTA zwischen Konsens-Mana und Zugriffs-Mana.

Da das IOTA-Protokoll führerlos ist, steht es den Netzwerkteilnehmern frei, Transaktionen parallel zu veröffentlichen, wann immer sie wollen. Das bedeutet, dass, wenn der Netzwerkverkehr die physikalischen Grenzen der Hardware und der Infrastruktur, auf der er betrieben wird, erreicht, die Rolle des Access Mana darin besteht, den Nutzern Netzwerkbandbreite im Verhältnis zu den von ihnen gehaltenen Token zuzuteilen. Im Allgemeinen erhalten diejenigen, die den größten Anteil am IOTA-Netzwerk haben, gemessen an den Token, die sie halten, den meisten Zugang zum Netzwerk in Zeiten der Überlastung.

In gewisser Hinsicht ist das IOTA-Netzwerk mit den Versorgungsgenossenschaften vergleichbar, die in den USA während der großen Depression entstanden sind, um ländliche Gemeinden mit Strom (und heute mit Breitband) zu versorgen. In IOTA werden den Nutzern Zugangsrechte im Verhältnis zu der Anzahl der Token (oder Anteile), die sie besitzen, gewährt. Da es keine Miner gibt, die Gebühren verlangen, werden die Zugangsrechte nach dem Nachweis des Besitzes des Netzwerks selbst aufgeteilt. Wenn Sie den IOTA-Token kaufen, kaufen Sie effektiv einen Teil der Netzwerkkapazität, die Sie nach eigenem Ermessen zuweisen können, solange Sie den Token besitzen.

Elektrizität für alle

Das Mana von IOTA ist der Beweis, dass ein Benutzer, der Token besitzt, seine Rechte an einen Knoten verpfändet hat. Dieser Nachweis gibt einem Knoten das Recht auf eine Stimme im Konsensprozess und auf das Senden von Transaktionen durch das Netzwerk. Das Zugriffsrecht (aMana) kann sogar an eine beliebige Person delegiert oder ihr entzogen werden, wenn ein Benutzer dies wünscht.
Mana ist so konzipiert, dass jeder, der durch den Besitz von Token einen gewissen Anteil am Netzwerk hat, Rechte im Verhältnis zu seinem Anteil erhält. Da PoW- und PoS-Systeme nur einem einzigen Leader erlauben, das Ledger zu aktualisieren und am Konsens teilzunehmen, werden die Ressourcen aller anderen Netzwerkteilnehmer verschwendet, ganz zu schweigen von der extremen Energieverschwendung, die mit PoW einhergeht. IOTAs Konzept eines vollständig dezentralisierten Ledgers ist eines, bei dem alle Knoten gemeinsam das Netzwerk sichern und Transaktionen parallel ausgeben, wobei die Ressourcen aller Netzwerkteilnehmer auf die effizienteste und dezentralste Weise genutzt werden.

Alle Systeme, PoW, PoS, ihre zahlreichen Geschwister und auch IOTAs FPC führen zurück zu einer etwas philosophischeren Frage: Woher kommen diese Rechte? Die Antwort darauf lautet „Vertrauen“. Der Staat oder ein Unternehmen garantiert, dass die Stimme eines Bürgers oder Aktionärs gezählt wird. Ein Kommunikationsanbieter verspricht, dass ein Telefonanschluss verfügbar sein wird.
Hinter jedem Recht steht eine Art Versprechen oder eine Garantie, die von einer Behörde gegeben wird. Dieses Versprechen wird normalerweise in einer offiziellen Erklärung ausgedrückt: einer Verfassung, einer Satzung oder einem Vertrag – Erklärungen, die einen Beweis für die Rechte bieten, die sie erweitern.

Man könnte sagen, dass diese Rechte nichts anderes sind als das Versprechen selbst. Es ist die Tatsache, dass wir darauf vertrauen, dass eine Autorität die Macht und den Willen hat, ihr Versprechen zu erfüllen, die den Rechten ihre Bedeutung verleiht. In einer Demokratie, in der niemand darauf vertraut, dass seine Stimme gezählt wird, wäre das Recht zu wählen bedeutungslos. Nur Vertrauen gibt der Stimme Bedeutung.

Kaianere’kó:wa = Das große Recht des Friedens

Im Fall eines verteilten Ledgers ist die vertrauenswürdige Autorität die Codebasis des Ledgers selbst. Im Vertrauen auf viele akademische Validierungen und die Beständigkeit des Protokolls im realen Leben, vertrauen die Benutzer freiwillig darauf, dass das Design und die Technik des Ledgers die Rechte verteilen und durchsetzen wird, die durch den Code versprochen werden, die alle überprüft werden können und sollten.
Aber selbst wenn ein verteilter Ledger perfekt konstruiert wäre, wäre das ganze System selbst nutzlos, wenn sich niemand bereit erklären würde, dem ehrlichen Verhalten zu folgen, das durch das Protokoll definiert ist. Diese Tatsache zeigt, dass das Vertrauen in ein digitales Hauptbuch bis zu einem gewissen Grad von dem Vertrauen abhängt, das die Menschen „außerhalb“ des Systems ihm entgegenbringen – eine Tatsache, die immer dann deutlich wird, wenn eine Gemeinschaft beschließt, ein Netzwerk durch soziale Koordination, die „off chain“ stattfindet, zu faken.

Schließlich ist ein Distributed Ledger ein Teil der menschlichen Lebenswelt, so etwas wie Straßen, elektrische Leitungen oder Kanäle, die die Möglichkeiten des sozialen Lebens erweitern. Es gibt a priori keinen Grund, warum das Vertrauen, das bereits außerhalb eines Ledgers besteht – das Vertrauen in bestimmte Institutionen und Menschen, sich ehrlich zu verhalten – nicht auch gleichermaßen genutzt werden kann, um die zwischen Maschinen getroffenen Vereinbarungen zu stärken.

Kleroterion

Im antiken Athen wurden Beamte, Stadtratsmitglieder und Geschworene durch eine Lotterie ausgewählt. Mit Hilfe eines Systems aus Spielsteinen und farbigen Würfeln wählte ein mechanisches Gerät namens Kleroterion nach dem Zufallsprinzip Bürger aus jedem der athenischen Stämme. Da jeder Bürger als gleichwertig angesehen wurde, glaubte man, dass die verschiedenen bürgerlichen Befugnisse des Wählens und der Verwaltung öffentlicher Ämter durch einen zufälligen, mechanischen Prozess zugewiesen werden sollten – etwas, das Aristoteles als das Kennzeichen der Demokratie betrachtete.

Es gibt eine interessante Verschmelzung des mechanischen und des menschlichen Aspekts in diesem Konzept der Demokratie. Ein Zufallsgenerator garantiert eine gewisse Art von Fairness, aber letztlich beruht das System auf dem Vertrauen, das den gewählten Bürgern entgegengebracht wird – Menschen, die sich in der Stadt Athen jeden Tag gekannt und miteinander zu tun gehabt hätten.

Mit Werkzeugen wie dezentralisierten digitalen Identitäten ist es durchaus möglich, dass mana in Zukunft die Grundlage eines umfassenderen Reputationssystems bilden könnte, das das wertvolle Vertrauen, das bereits auf reale Menschen und reale Institutionen ausgedehnt wird, mit dem Vertrauen interagieren lässt, das wir in das Verhalten des Codes setzen, auf den sich Maschinen heute und in Zukunft verlassen.

Der Inhalt dieses Artikels gibt die Meinung der IOTA Foundation wieder, wurde aber in großen Teilen von IOTA-Community-Mitglied @b0rg (Discord) verfasst. Teile des ursprünglichen Artikels wurden umformuliert, um die Meinung der IOTA Foundation wiederzugeben, in Übereinstimmung und mit Zustimmung des ursprünglichen Autors, b0rg. Wenn Sie daran interessiert sind, ein bestimmtes IOTA-bezogenes Thema zu behandeln, indem Sie selbst einen Artikel für die IOTA Foundation schreiben, können Sie sich gerne an Antonio Nardella in unserem Discord wenden oder mit einem X-Team-Simplify-Community-Mitglied im Discord-Kanal (mit demselben Namen) sprechen.

Original by IOTA Foundation: https://blog.iota.org/mana-parallels-to-human-voting-systems-and-ingenious-concepts/

 

Pollen Testnet v0.5.5 Versionshinweise

Wir freuen uns, eine neue Version unseres Pollen-Testnetzes v0.5.5 zu veröffentlichen. Nachdem wir Mana vor ein paar Wochen in unserem Testnetz eingeführt haben, freuen wir uns, es nun mit zwei der Coordicide-Module zu verwenden: Konsens (FPC) und Autopeering. Wie Sie sich wahrscheinlich vorstellen können, ist dies ein sehr wichtiger Schritt für uns und für die kommende „Nectar“-Stufe der Coordinator-freien, vollständig dezentralisierten Version von IOTA. Mit Ihrer Hilfe können wir einige der Parameter abstimmen, um einen wünschenswerten Kompromiss zwischen Leistung und Sicherheit des Netzwerks zu finden.

Die vollständige Liste der Änderungen beinhaltet:

  • Integration von Mana mit FPC
  • Integrieren von Mana mit dem Autopeering
  • Hinzufügen mehrerer FPC-Optimierungen
  • Hinzufügen der dRNG-Diagnose-API
  • Vereinfachen der Speichernutzung des Dashboards und Anpassen an Grafana
  • Diagramm für Stored, Solidifier, Scheduler und Booker MPS hinzufügen
  • Update auf die neueste hive.go

Wie bei der vorherigen Version setzt diese Version das Netzwerk sowie den Tangle und alle Guthaben und tokenisierten Assets zurück.

Mana im FPC

Das Fast Probabilistic Consensus (FPC)-Protokoll wird als Teil des Konsens-Mechanismus in der Coordicide-Lösung verwendet, und Sie können eine genauere Beschreibung im FPC-Blogpost finden. Bisher hat dieses Konsensmodul die Meinungen jedes Knotens gleich behandelt, allerdings bietet dies keinen Schutz gegen Sybil-Angriffe, bei denen Angreifer hunderte oder sogar tausende von Knoten betreiben, um den Konsens zu stören. Mit der Integration von Mana bilden die Knoten stattdessen ihr Quorum, indem sie die abzufragenden Knoten proportional zu ihrem Mana auswählen.

Diese Integration ist ein erster wichtiger Schritt, um unser Mana-System als Sybil-Schutz- und Reputationssystem in einer Testnetzumgebung zu testen. Wir erwarten einige interessante Ergebnisse aus dieser Implementierung, da wir auch mehrere experimentelle Verbesserungen des Protokolls eingeführt haben, die sowohl durch interne als auch durch Peer-Review-Forschung vorgebracht wurden.

Mana im Autopeering

Damit das Netzwerk effizient arbeiten kann und die Knoten über den Zustand des Ledgers auf dem Laufenden gehalten werden, tauschen die Knoten untereinander Informationen wie Nachrichten und Transaktionen aus. Jeder Knoten baut einen Kommunikationskanal mit einer kleinen Teilmenge von Knoten (d.h. Nachbarn) über einen Prozess namens Peering auf. Ein solcher Prozess muss widerstandsfähig gegen Eclipse-Angriffe sein: Wenn alle Nachbarn eines Knotens von einem Angreifer kontrolliert werden, dann hat der Angreifer die vollständige Kontrolle über die Sicht des Knotens auf das Tangle. Weitere Informationen über das Autopeering-Modul finden Sie in unseren Blog-Beiträgen: Autopeering Teil 1 und Teil 2.

Um Sybil-basierte Angriffe zu verhindern/einzuschränken, macht das Autopeering Gebrauch von Mana: Beliebige Knoten ohne Mana können erstellt werden, aber es gibt eine Grenze, wie viele Knoten mit einer bestimmten Menge an Mana erstellt werden können. Genauer gesagt wird es für einen Angreifer prohibitiv schwierig, viele Knoten mit hohem Mana zu erzeugen.

Im Kern verwendet das Autopeering-Modul einen Screening-Prozess namens Mana-Rank, der eine Teilmenge aller bekannten Knoten auf der Grundlage ihrer Mana-Ähnlichkeit auswählt. Das bedeutet, dass Knoten mit ähnlichem Mana mit größerer Wahrscheinlichkeit zu Nachbarn werden.

Durch die Einführung von Mana in das Autopeering-Modul können wir auf das Pollen-Testnetz zurückgreifen, um zu untersuchen, welche Parameter für den Netzwerkgraphen sicher und stabil sind und welche Auswirkungen dies auf das Netzwerk hat. Wenn wir die Konsens-Mana-Verteilung im aktuellen Pollen-Netzwerk betrachten, können wir einige interessante Topologien erwarten, die davon abhängen, wie die Parameter für den Mana-Rang ausgewählt werden, und dies kann unsere Forschungsbemühungen aufklären und rückkoppeln. Die Abbildung unten zeigt zum Beispiel die Veränderung der Netzwerktopologie, wenn der R-Parameter verringert wird, der bestimmt, wie weit im Netzwerkraum High-Mana-Knoten von Low-Mana-Knoten entfernt sind.

IOTA Mana

Was kommt als Nächstes?

In den kommenden Wochen wird sich das Team auf die Integration von Mana mit den übrigen Modulen konzentrieren: Congestion Control, Finality (Zulassungsgewicht), Reorg und dRNG. Als letzte Meilensteine vor Nectar werden wir Snapshots und Timestamp-Voting einführen. Sobald diese fertiggestellt sind, wird Nectar bereit sein, für die Öffentlichkeit zu starten.

Wir möchten uns bei unserer gesamten Community für ihre Hilfe und Unterstützung bedanken. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im #tanglemath-Kanal auf unserem Discord. Sie können auch in der #goshimmer-discussion auf Discord mitdiskutieren.

Original by Angelo Capossele: https://blog.iota.org/pollen-testnet-v0-5-5-release-notes/

Erklärung des IOTA Congestion Control Algorithmus

Dieser Artikel erklärt in einigen technischen Details den IOTA Congestion Control Algorithm (ICCA), der im IOTA 2.0 Protokoll (Coordicide) verwendet wird. Wir wollten diesen Überblick anbieten, um die Beziehung zwischen Access und Mana zu klären, die in unserem vorherigen Beitrag über Mana angesprochen wurde.  Außerdem sind wir uns bewusst, dass viele begierig sind, mehr über Coordicide zu erfahren, und dass Interessenvertreter aus dem gesamten IOTA-Umfeld von diesem Wissen profitieren. Das heißt, die in diesem Artikel enthaltenen Informationen sind kein „erforderliches Wissen“, um IOTA zu nutzen. Außerdem werden alle Aspekte, die in diesem Artikel besprochen werden, Teil unserer vollständigen Spezifikation sein. Wenn Sie Fragen haben, besuchen Sie bitte unseren Discord, um sie mit unseren Entwicklern und Forschern zu diskutieren. Die Congestion Control (dt. Überlastungskontolle) ist ein wichtiger und faszinierender Aspekt von Coordicide, daher hoffen wir, dass Sie diese Erklärung genießen.

Unser besonderer Dank gilt Bob Shorten und seinem Team am Imperial College London für ihre Arbeit bei der Mitentwicklung dieses wichtigen Algorithmus. Ihre Arbeit hat maßgeblich zur Entwicklung dieser wichtigen Komponente und zur Validierung ihres Betriebsverhaltens beigetragen.

Eine ausführliche Erklärung finden Sie in unserem ersten Artikel zu diesem Thema, der zur Präsentation auf dem 7th IEEE/IFIP Workshop on Security for Emerging Distributed Network Technologies angenommen wurde.

Was ist Congestion Control und warum benötigen wir sie?

In den meisten DLTs werden Informationen über das Netzwerk durch einen Prozess namens „Gossiping“ weitergegeben, bei dem die teilnehmenden Nodes Nachrichten von einem Nachbarn erhalten und diese dann an andere Nachbarn weiterleiten. Natürlich erhalten die Nodes viele Nachrichten, so dass sie entscheiden müssen, welche dieser Nachrichten sie an ihre Nachbarn weiterleiten und in welcher Reihenfolge sie dies tun. Ein Algorithmus zur Überlastungskontrolle trifft diese Entscheidungen.

Eine Überlastung tritt auf, wenn ein Netzwerk mehr Datenverkehr hat, als es bewältigen kann. Ohne eine angemessene Überlastungskontrolle kann das Netzwerk übersättigt werden und nicht mehr funktionieren, da die Nodes ihre Nachbarn mit mehr Nachrichten überfluten können, als von einem einzelnen Node verarbeitet werden können. Durch die Entscheidung, welche Nachrichten weitergeleitet werden sollen, wird ein Congestion Control-Algorithmus eingesetzt, um diese Überlastung zu verhindern. In einem unsharded DLT ist das Problem besonders akut, da jeder Netzwerkteilnehmer („die Node“) alle gültigen Transaktionen verarbeiten muss. Daher ist der Gesamtdurchsatz des Netzwerks (informell als Transaktionen pro Sekunde bezeichnet) letztlich durch die verfügbaren Ressourcen wie Internetanbindung, Geräteverarbeitung und Speicherkapazitäten begrenzt.

Da jedoch ein Congestion-Control-Algorithmus entscheidet, welche Nachrichten weiter gesendet (geklatscht) werden, bestimmt er im Wesentlichen, wer Zugang zum Netzwerk hat; der Congestion-Control-Algorithmus hat einen tiefgreifenden Einfluss auf das Benutzererlebnis. Um „Coordicide“ zu verdeutlichen, möchten die Autoren ICCA erklären, das im IOTA 2.0-Protokoll (Coordicide) verwendet wird.

Congestion Control ist ein sehr altes Thema, das intensiv untersucht wurde, als die Infrastruktur des Internets entwickelt wurde. Im Gegensatz zu den meisten Netzwerken haben DLTs jedoch sehr strenge Anforderungen, die die Congestion Control zu einem besonders schwierig zu lösenden Problem machen. Insbesondere müssen die folgenden Anforderungen erfüllt werden (es gibt noch weitere Anforderungen, auf die wir weiter unten näher eingehen, aber diese sind die wichtigsten):

  • Fairer Zugang: der Netzwerkzugang muss proportional zu einer „knappen Ressource“ gewährt werden
  • Angriffsresistenz: böswillige Nodes können das Netzwerk nicht stören
  • Konsistenz: alle Nodes müssen die gleichen Nachrichten in ihr lokales Ledger schreiben

Blockchains lösen die Überlastungskontrolle, indem sie einige Mechanismen verwenden, um Anführer zu wählen, die Blöcke minen. Der Zugang ist fair, da die Rate, mit der ein Anführer gewählt wird, proportional zu seinem Einsatz oder seiner Hashing-Power ist. Da der Zugriff nur auf die Anführer beschränkt ist, ist eine Überlastung nie möglich, auch nicht während eines Angriffs. Letztendlich wird ein Konsens erreicht, da Blockchains ein Konsensmodul haben, um einen Anführer zu wählen. Die Beschränkung des Zugriffs auf „Anführer“ macht es für PoS- und PoW-Architekturen einfacher, zentralisiert aber den Zugriff.

Da IOTA eine DAG und keine Blockchain verwendet, können (und wollen) wir keine Art von Leader-Wahlprozess verwenden. Stattdessen verwendet die ICCA einen sogenannten Scheduler, der Nachrichten auswählt, die „planmäßig“ sind. Geplante Nachrichten werden in den lokalen Tangle geschrieben und an die Nachbarn des Node weitergeleitet. Der Scheduler plant Nachrichten mit einer konstanten Rate ein, wodurch sichergestellt wird, dass keiner der Nachbarn überlastet wird.

Nun können wir erörtern, wie das ICCA unsere drei oben genannten Hauptanforderungen – fairer Zugriff, Angriffsresistenz und Konsistenz – erreicht. Zunächst können wir sehen, dass jeder Node lokal den Verkehr fair nach Mana plant. Es stellt sich heraus, dass dies auch global gilt und dass der Zugriff fair nach Mana vergeben wird.

Zweitens, was passiert, wenn ein Angreifer versucht, das Netzwerk voll zu spammen? Lokal werden die Nodes die Nachrichten des Angreifers nicht schneller als ihre erlaubte Rate verarbeiten. Die Nachrichten des Angreifers werden sich also anhäufen und seine Warteschlange wird wachsen. Alle Nodes werden dies erkennen und den Angreifer aus dem Netzwerk verbannen. Natürlich gibt es zahlreiche andere Angriffsmethoden, die wir untersucht haben, aber der Scheduler ist schwer auszutricksen, so dass der Algorithmus recht widerstandsfähig gegen Angreifer ist.

Da der Scheduler niemals ehrliche Nachrichten löscht, stellt der Algorithmus schließlich sicher, dass sie alle Nodes erreichen. Wenn ein Angreifer aus dem Netzwerk verbannt wird, was passiert dann mit den von ihm ausgegebenen Nachrichten? Da das Verhalten des Angreifers nachweisbar ist, werden die meisten Nodes den Angreifer im gleichen Moment verbannen, wodurch sichergestellt wird, dass die Ledger nahezu identisch sind. Dann verfügt das Gossip-Protokoll über einen Mechanismus namens „Solidification“, der winzige Unterschiede in den Tangles korrigieren kann.

Im Folgenden finden Sie einen technischeren Überblick über die ICCA, da eine tiefere Analyse der Anforderungen präsentiert wird.

Anforderungen für jede DLT

Es gibt einige allgemeine Anforderungen und einige davon sind entscheidend für den Erfolg eines jeden DLT-Congestion-Control-Algorithmus: Konsistenz, fairer Zugriff, Auslastung, faire Latenzzeit und Angriffsresistenz.

Konsistenz

Konsistenz bedeutet, dass jede Node die exakt gleichen Nachrichten in den Ledger schreibt. Wenn das Netzwerk überlastet ist, sind die Nodes möglicherweise gezwungen, einige Nachrichten zu verwerfen, was zu Inkonsistenzen führt. Das Ziel des ICCA ist es, das Verwerfen von Nachrichten auf ein Minimum zu reduzieren und die verbleibenden Inkonsistenzen durch Solidification Requests zu beheben. Ohne dies gibt es keinen Konsens.

Fairer Zugriff

Da die verfügbaren Netzwerkressourcen endlich sind, muss der Zugriff (äquivalent dazu der Durchsatz) in irgendeiner Weise eingeschränkt werden. In DLTs wird dies üblicherweise durch die Beschränkung des Zugriffs durch eine „knappe Ressource“ gewährleistet. Viele DLTs nutzen Energie als knappe Ressource, indem sie von Minern verlangen, PoW zu betreiben. Proof-of-Stake-DLTs verwenden oft den Token selbst als knappe Ressource; IOTA verwendet Mana (siehe unseren Mana-Blogbeitrag und dessen Folgeartikel).

Fairer Zugang bedeutet, dass alle Nodes einen fairen Anteil des Durchsatzes erhalten sollten. Es ist wichtig zu beachten, dass dieser Zugang linear proportional zur Menge des Manas sein muss: Wenn der Zugang sublinear vergeben wird – also immer weniger Zugang mit mehr Mana – dann werden große Akteure ihr Mana auf kleinere Nodes aufteilen, um unfairen Zugang zu erhalten. Wenn es superlinear ist – also mehr Zugang mit mehr Mana gewährt wird – dann haben große Inhaber einen Vorteil. Dies schafft Anreize für Nodes, ihre Ressourcen zu bündeln, wie bei Mining-Pools. Sowohl sublineare als auch superlineare Zugriffsvergaben sind im Allgemeinen unfair und fördern ein Verhalten, das dem Netzwerk langfristig schaden könnte.

Auslastung

Wenn es eine Nachfrage gibt, wird das volle Potenzial des Netzwerks genutzt.

Denken Sie zum Beispiel an eine triviale Zugangskontrolle, bei der der Durchsatz jeder Node durch seinen prozentualen Mana-Anteil gedeckelt ist, sagen wir 10% Mana erlauben einem Benutzer maximal 10% der Bandbreite. Das wäre zwar fair, aber ineffizient: Wenn z.B. 95% des Manas offline sind, dann würde das Netzwerk mit 5% Kapazität arbeiten. Ein effizienter Mechanismus zur Überlastungskontrolle muss diese ungenutzte Kapazität umfunktionieren.

Die Kombination von Auslastung und Fairness ist kompliziert. Die Frage „Wie viel Mana brauche ich für X TPS“ ist schwer zu beantworten. Aber denken Sie daran: Auslastung ist eine gute Sache! Ohne sie wäre das Netzwerk unbrauchbar.

Auslastung und Fairness bilden zusammen ein Konzept namens „Max-min-Fairness“. Dies ist ein wichtiges Konzept aus der klassischen Netzwerktechnik. Router, die Internet-Verkehr weiterleiten, brauchen genau diese Eigenschaften (stellen Sie sich vor, wenn Ihre lokalen Router diese Eigenschaften nicht hätten, wäre Ihr Heim-Internet unbrauchbar).

Faire Latenzzeit

Alle ehrlichen Benutzer sollten eine ähnliche Latenzzeit erfahren. Die Latenz ist die Zeit, die eine ausgegebene Nachricht benötigt, um sich an alle Nodes zu verbreiten. Diese Latenzzeit muss sowohl für ein gutes Benutzererlebnis als auch für die Stabilität des Protokolls gering sein.

Die Benutzererfahrung sollte für sich selbst sprechen; niemand mag Verzögerungen. Für die Stabilität des Protokolls wäre es jedoch ein perverser Anreiz, vom Algorithmus abzuweichen, wenn die Latenzzeit für verschiedene Benutzer dramatisch unterschiedlich wäre. Die Bestrafung der Latenz von böswilligen Nodes ist aus spieltheoretischer Sicht gut. Wenn also die Latenz von Nodes ansteigt, wenn sie sich falsch verhalten, dann werden sie bestraft und somit zu ihrem Verhalten ermutigt.

Angriffsresistent

Diese oben genannten Eigenschaften müssen für ehrliche Nodes auch dann gelten, wenn ein Angreifer versucht, das System zu knacken. Die Nodes haben einen Anreiz, ihren Zugriff zu erhöhen und ihre Latenzzeit zu verringern. Abweichungen sollten unmöglich sein oder bestraft werden.

IOTA Congestion Control Algorithmus (ICCA)

Der IOTA Congestion Control Algorithm (ICCA) rationalisiert den Transaktionsprozess, um die Auswirkungen einer möglichen Überlastung zu minimieren und den Schreibzugriff auf den Ledger zu regulieren. Der ICCA erreicht dies durch seine drei Teile: den Scheduler, den Rate Setter und den Blacklister.

Der Scheduler bestimmt, welche Transaktionen in den Ledger geschrieben und geklatscht werden. Der Rate Setter verwendet einen klassischen AIMD-Algorithmus (Additive Increase Multiplicative Decrease), um die Rate jedes Einzelnen anzupassen. Blacklisting zensiert Nodes, die das Netzwerk angreifen.

Dies ist – soweit wir wissen – der erste nicht Proof of Work, DAG-basierte Congestion Control Algorithmus, der im Bereich der Kryptowährungen veröffentlicht wurde. Er ist die neuartigste Komponente von Coordicide und ein Grundpfeiler des IOTA 2.0 Protokolls.

Node-Modell

iota congestion control algorithm erklärung

Von dem Netzwerk-Layer (siehe diesen Link zur Terminologie) kommen Nachrichten über Gossip von den Nachbarn an, werden auf Duplikate und ungültige Nachrichten gefiltert und kommen im Posteingang an, wo sie sich in die Warteschlange gemäß der ausstellenden Node-ID einreihen. Der Posteingang empfängt auch Nachrichten, die lokal vom Rateneinsteller der Node erstellt wurden. Der Blacklister überwacht die Warteschlangen des Posteingangs auf böswilliges Verhalten, und der Scheduler entscheidet, welche Nachrichten den Posteingang verlassen dürfen.  Nachdem eine Nachricht eingeplant wurde, finden die folgenden Aufgaben gleichzeitig statt:

  • Die Nachricht wird an alle Nachbarn außer dem, von dem wir sie erhalten haben, geklatscht (an die Netzwerkschicht zurückgegeben)
  • Die entsprechende Anwendung (aus dem Applikations-Layer) wird aufgerufen, um die Nutzlast zu parsen
  • Die Nachricht wird in den lokalen Tangle „geschrieben“, wo sie als Tip betrachtet werden kann, von FPC abgestimmt wird, im Ledger verbucht wird, usw.

Planer

In der ICCA schlagen wir die Verwendung einer modifizierten Version eines Deficit Round Robin-Schedulers vor. Abgesehen von der Tatsache, dass ein solcher Scheduler alle oben genannten Anforderungen erfüllt (d. h. Konsistenz, Auslastung, Fairness und Angriffsresistenz), haben wir uns für ihn entschieden, weil er leichtgewichtig ist. Er ist zum Beispiel die Standardoption, um eine sehr große Anzahl von Threads für den Linux-Kernel effizient zu handhaben.

Der Scheduler funktioniert folgendermaßen: Nachdem Nachrichten empfangen wurden, werden sie im Posteingang abgelegt. Jeder Nachricht wird eine „Arbeitsbewertung“ zugewiesen, die darauf basiert, wie viele Ressourcen sie verbraucht. Größere Nachrichten haben größere Punktzahlen, da sie mehr Bandbreite verbrauchen. Eine Nachricht mit einer Transaktion, die 100 Signaturen enthält, hat eine höhere Punktzahl als eine Transaktion mit einer Signatur, da die Validierung der Signaturen mehr Ressourcen erfordert. Im Wesentlichen sorgt der Scheduler dafür, dass eine maximale Anzahl von Ressourcen pro Sekunde verbraucht wird. Die Forscher und Ingenieure, die dies entwickeln, haben völlige Freiheit, diese Arbeitsfunktion zu definieren, um den Algorithmus genau an die Bedürfnisse des IOTA-Netzwerks anzupassen.

Wenn Nachrichten empfangen werden, werden sie von ihrem abgebenden Node in verschiedene Warteschlangen sortiert. Der Scheduler besucht jede Warteschlange, plant eine Anzahl von Nachrichten basierend auf dem Mana (die „knappe Ressource“, die in IOTA verwendet wird), das die ausstellende Node besitzt, und geht dann zur nächsten Warteschlange über. Wenn eine Warteschlange leer ist, wird sie übersprungen; der Scheduler plant dann aus anderen Warteschlangen. Auf diese Weise werden die Nachrichten aller Nodes proportional zu ihrem Mana verarbeitet, solange ihre Warteschlange nicht leer wird.

Der Posteingang der Nodes wird in Warteschlangen aufgeteilt, wobei für jede Node im Netzwerk eine Warteschlange zur Verfügung steht; ein Deficit-Round-Robin-Scheduler kann Zehntausende von Warteschlangen effizient verarbeiten. Nachrichten werden dann in die Warteschlange der Node gestellt, der die Nachricht ausgegeben hat. Der Scheduler besucht jede nicht leere Warteschlange in einer deterministischen Reihenfolge. Jeder Warteschlange wird eine Menge zugewiesen, die „Guthaben“ für diesen Node genannt wird. Wenn der Scheduler eine Warteschlange besucht, fügt er einen bestimmten Prioritätswert proportional zum Mana der entsprechenden Knoten-ID hinzu. Er plant dann Nachrichten aus der Warteschlange dieser Node ein. Jedes Mal, wenn eine Nachricht eingeplant und weiterverarbeitet wird, wird der „Arbeitswert“ der Nachricht vom Guthaben abgezogen. Wenn keine weiteren Nachrichten aus der Warteschlange von N eingeplant werden können oder das Guthaben negativ wird, wechselt der Scheduler zur nächsten Warteschlange.

Derzeit planen wir Nachrichten mit einer festen/maximalen voreingestellten Rate. Zurzeit analysieren und untersuchen wir verschiedene Möglichkeiten, diesen Schwellenwert dynamisch zu gestalten, so dass das Netzwerk durch Sharding natürlich skaliert werden kann.

Aber was passiert, wenn ein Angreifer oder ein egoistischer Node sich nicht an die Regeln des Schedulers hält? Nehmen wir an, dass eine egoistischer Node beschließt, nur seine eigenen Transaktionen weiterzuleiten. Das würde dazu führen, dass die entsprechende Warteschlange in den Posteingangspuffern der ehrlichen Nodes aufgebläht wird, was zu großen Verzögerungen nur für seine eigenen Transaktionen führt. Das Gleiche gilt für böswillige Nodes: Solange ehrliche Nodes dem defizitären Round-Robin-Scheduler folgen, würden Transaktionen von Angreifern nicht weitergeleitet werden.

Rate Setter

Woher weiß eine Node, wie viele Nachrichten er ausgeben kann? Er verwendet den Rate Setter. Basierend auf der Warteschlangenlänge verwendet der Rate Setter den AIMD-Algorithmus, um seine eigene Transaktionserzeugungsrate zu regulieren. Ein ähnlicher Algorithmus wird von Routern im Internet verwendet, um den Datenverkehr anzupassen.

Eine Node kann die Länge seiner eigenen Warteschlange überwachen. Wenn diese Warteschlange zu lang wird, weiß er, dass er zu viele Nachrichten ausgibt. Eine Node erhöht seine Ausgaberate langsam (Additive Erhöhung), bis seine Warteschlange zu lang wird. An diesem Punkt verringert die Node schnell seine Ausgaberate (Multiplikative Verringerung), um eine bevorstehende Überlastung zu verhindern. Auf diese Weise konvergiert der Rate Setter schließlich zu einer fairen Ausgaberate, abhängig von den aktuellen Datenverkehrsbedingungen.

Als zusätzlicher Vorteil sorgt der Rate Setter dafür, dass die Latenzzeit für Transaktionen, die von Knoten ausgegeben werden, die dem Protokoll folgen, gering ist. Nodes, die diesem Algorithmus nicht folgen, überfluten ihre Warteschlangen und erhöhen ihre Latenz. Auf diese Weise erhalten die Nodes einen Anreiz, den Rate Setter zu verwenden.

Was passiert, wenn böswillige Nodes den Rate Setter nicht verwenden? Was ist, wenn sie sich nicht um die Erhöhung der Latenz kümmern, z. B. bei einem Spam-Angriff? Die folgenden Abschnitte enthalten Sicherheitsmaßnahmen, die wir eingerichtet haben und die ausgelöst werden, bevor ein Angreifer der Konsistenz schaden kann.

Blacklisting

Was passiert, wenn die Node den Rate Setter nicht verwendet? Dann wird er seine Rate nicht reduzieren, wenn seine Warteschlange wächst, und so wird seine Warteschlange weiter wachsen. Da die anderen ehrlichen Nodes nur so viel Speicher haben, kann keine Warteschlange unendlich wachsen. Daher hat das ICCA den Blacklister, um die Länge der Warteschlangen zu begrenzen. Je nach Mana darf ein Node eine bestimmte Anzahl von Nachrichten in der Warteschlange haben. Wenn diese Anzahl einen bestimmten Schwellenwert überschreitet, wird die Node vorübergehend auf eine schwarze Liste gesetzt, was bedeutet, dass für eine gewisse Zeit keine weiteren Transaktionen von diesem Node in den Posteingang aufgenommen werden. Wenn die Warteschlange einer Node zu explodieren beginnt, werden die neu eingehenden Nachrichten für diese Node verworfen.

Kontrollsatz

Ein Angreifer kann versuchen, das Netzwerk mit großen Mengen an Spam zu überfluten, indem er direkt versucht, Hunderte von Nodes auf einmal zu überlasten. Zum Schutz vor solchen Angriffen verwenden wir einen Mechanismus namens Rate-Control (dt. Ratenkontrolle) als grobe Unterbrechung, der die Menge der Nachrichten, die eine Node senden kann, physikalisch begrenzt. Dazu verwenden wir ein adaptives PoW als Ratenkontrollmechanismus. Für ehrliche Nodes ist die PoW-Schwierigkeit relativ gering. Wenn eine Node jedoch anfängt zu spammen, steigt die Schwierigkeit exponentiell an, was ihn physisch daran hindert, mehr Nachrichten zu versenden. Dieser Mechanismus würde also verhindern, dass das System komplett überlastet wird.

So nützlich der Mechanismus zur Ratenkontrolle auch ist, er ist möglicherweise nicht notwendig. Das ICCA hat das Potenzial, so stark zu sein, dass dieses Modul überflüssig ist. In der ersten Version des Coordicide-Protokolls wollen wir jedoch den maximalen Schutz gewährleisten, und eine eventuelle spätere Verringerung oder Entfernung jeglicher PoW bleibt als zukünftige Optimierung übrig. Im GoShimmer-Testnetz werden wir das Zusammenspiel zwischen der adaptiven PoW-Ratensteuerung und dem ICCA untersuchen.

Null Mana Nachrichten

Leider erfordert das ICCA, dass Nodes ein gewisses Mana haben müssen, um Nachrichten ausgeben zu können, denn Nodes mit 0 Mana erhalten niemals Guthaben und ohne Guthaben werden ihre Nachrichten nicht eingeplant. Dies ist wichtig, um billige Angriffe zu vermeiden: Ohne dies könnten Nodes mit niedrigem Mana einen Ansturm von Transaktionen erzeugen, wodurch das Netzwerk überlastet und die Konsistenz des Ledgers beeinträchtigt wird.

Wir können verschiedene Optionen anbieten, damit Null-Mana-Nodes in der Lage sind, ihre Transaktionen auszugeben. Eine Möglichkeit ist über einen Faucet, bei dem jede Node freiwillig sein ungenutztes Mana neuen Benutzern anbieten kann, die das Netzwerk ausprobieren wollen, für welchen Anwendungsfall auch immer sie im Sinn haben. Eine andere Möglichkeit ist die Nutzung des Mana-Marktes, auf dem man selbst bestimmen kann, wie und wann man Mana nach Bedarf mieten möchte. Eine weitere Methode besteht darin, Token zu kaufen und sie durch Verpfändung an die Nodes zu transferieren.

Schließlich untersuchen wir eine Möglichkeit, die minimale Mana-Schwelle dynamisch anzupassen, abhängig vom Prozentsatz des aktiven Manas und von den aktuellen Datenverkehrsbedingungen.

In Zeiten mit geringer Überlastung dürfen „validierte Low-Mana-Nodes“ ihre Transaktionen ausgeben und werden von ehrlichen Nodes eingeplant. Ein „validierter Low-Mana-Node“ ist eine Node, der die folgenden zwei Bedingungen erfüllt: Erstens, sein Mana ist kleiner als der minimale Mana-Schwellenwert; und zweitens, die Node hat kürzlich einen großen PoW durchgeführt. Wenn die Überlastung gering ist, lassen ehrliche Nodes vorübergehend Planungen von diesen validierten Low-Mana-Nodes zu. Sobald die Überlastung groß wird, können validierte Low-Mana-Nodes ihre Transaktionen nicht mehr ausgeben; sie müssen auf Zeiten mit geringer Überlastung warten.

Original by William Sanders: https://blog.iota.org/explaining-the-iota-congestion-control-algorithm/

Was ist MANA bei IOTA – Teil 2

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/

Pollen Testnet v.0.5.0 – Die Reise mit Mana

Pollen Testnet v0.5.0 – Wir beginnen unsere Reise mit Mana

Wir veröffentlichen eine neue Version unseres Pollen-Testnetzes v0.5.0. Mit dieser Veröffentlichung beginnen wir offiziell unsere Reise mit Mana. Das erste Ziel ist es, die erste Wiederkehr der Mana-Implementierung zu testen, um die Verteilung im Pollen-Testnetz zu untersuchen, nach eventuellen Fehlern zu suchen und allgemein die Stabilität zu beurteilen. Nach dieser Phase werden wir unsere Kernmodule, wie die IOTA-Staukontrolle, den Fast Probabilistic Consensus, das Autopeering und den verteilten Zufallszahlengenerator Mana als Sybil-Schutzmechanismus nutzen lassen.

Die vollständige Liste der Änderungen beinhaltet:

  • Hinzufügen von Mana (wird derzeit von keinem der Module verwendet)
  • Hinzufügen von Mana-APIs
  • Hinzufügen des Mana-Abschnitts zum lokalen Dashboard
  • Hinzufügen des Mana-Abschnitts zum Pollen Analyzer Dashboard
  • Hinzufügen des Mana-Abschnitts zum Grafana-Dashboard
  • Refactor des Consensus Managers, um unabhängig von dem konkret implementierten Konsensmechanismus zu sein
  • Verbessern des Tangle-Visualisierers
  • Verbessern der Dokumentation

Wie bei der vorherigen Version werden auch in dieser Version das Netzwerk und das Tangle sowie alle Guthaben und tokenisierten Assets zurückgesetzt.

Außerdem wurde eine neue GUI-Pollen-Wallet-Version veröffentlicht.

Diese Version bringt eine Reihe neuer APIs, einen neuen Mana-Bereich auf dem lokalen Dashboard, dem Pollen Analyzer Dashboard sowie auf dem Grafana Dashboard. Sowohl die GUI- als auch die CLI-Wallets wurden aktualisiert, um dem Benutzer die Möglichkeit zu geben, die Identität des Knotens als Empfänger des Zugriffs und des Konsens-Mana-Pledge einer Transaktion zu definieren.

Hier ein Screenshot des Mana-Abschnitts des lokalen Dashboards des Knotens:

Pollen Testnet 0.5

Die Dokumentation der Mana bezogenen APIs und Client-Libs finden Sie in unserem Wiki sowie hier.

In der aktuellen Implementierung basieren Konsens- und Zugriffs-Mana auf den Berechnungsmethoden Mana1 bzw. Mana2. Das bedeutet, dass beide einem gleitenden Durchschnitt folgen, aber bei Mana2 gibt es zusätzlich einen Verfallsfaktor. In der Praxis bedeutet dies, dass das Konsens-Mana, sobald das Mana zugesagt wurde, schneller ansteigt als das Zugriffs-Mana, da es abnimmt. Durch regelmäßiges Auffrischen des Zugriffs-Mana wird sichergestellt, dass sein Wert aktiv bleibt. Wir haben auch noch eine dritte Art von Mana, die wir untersuchen wollen. Das ist eine Kombination aus Mana1 und Mana2, deren Gewicht durch einen Koeffizienten definiert ist.

Obwohl die Einführung von Mana eindeutig die wichtigste Funktion dieser Version ist, wurde eine ebenso wichtige Änderung an GoShimmer vorgenommen. Wir haben die Consensus-Manager-Komponente so umgestaltet, dass sie agnostisch in Bezug auf die tatsächlich implementierten Konsensmechanismen ist. Auf diese Weise kann GoShimmer nicht nur als der IOTA 2.0-Prototyp, sondern auch als flexibles Framework für jede DAG-basierte DLT gesehen werden. Tatsächlich kann jeder Konsens-Mechanismus, wie z.B. On Tangle Voting, BFT, Leader-basiert und mehr, so einfach wie das Ändern von nur ein paar Zeilen in der Tangle-Initialisierung eingesteckt werden. Wir hoffen, dass unsere Bemühungen, dieses Tool bereitzustellen und kontinuierlich zu verbessern, anderen Forschern helfen werden, Fortschritte im Bereich der DLT zu machen.

Nachdem das Mana-Modul erfolgreich implementiert wurde, steht die nächste Stufe unseres Coordicide-Testnetzes namens „Nectar„, unser erstes funktionsfähiges koordinatorfreies Testnetz, vor der Tür. Das Team arbeitet bereits an den verbleibenden Features wie Nachrichtenfinalität über Genehmigungsgewicht, Reorganisation, Snapshots, Zeitstempel-Abstimmung und der Integration von Mana mit unseren Kernmodulen.

Wir möchten uns bei unserer gesamten Community für ihre Hilfe und Unterstützung bedanken. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im #tanglemath-Kanal auf unserem Discord. Sie können auch in der #goshimmer-discussion auf Discord mitdiskutieren.

Original by Angelo Capossele: https://blog.iota.org/pollen-testnet-v0-5-0-starting-our-journey-with-mana/

IOTA als digitale Infrastruktur: Phasenübergänge auf den IOTA-Token

Mit dem erweiterten Narrativ von Bitcoin als „Finanzinstrument“, das im Jahr 2021 an Popularität gewinnt, macht es Sinn, zu überprüfen, wie der Nutzen des IOTA Tokens aufgrund technischer Updates und makroökonomischer Kräfte wächst. In diesem Blog-Beitrag wende ich PlanBs Idee der „Phasenübergänge“ an und skizziere eine mögliche Entwicklung des IOTA-Tokens als grundlegende Ressource für digitale Infrastruktur in der globalen Maschinenwirtschaft.

„IOTA als digitale Infrastruktur: Phasenübergänge auf den IOTA-Token“ weiterlesen

IOTA Forschungsstatus Update Dezember 2020

In diesem Monat hat unser Team weiterhin große Fortschritte bei unserem derzeitigen Hauptaugenmerk, der Pollen-Testnet-Implementierung von IOTA 2.0, erzielt. Wir arbeiten hart daran, die letzten verbleibenden Elemente der Spezifikation zu implementieren, was letztendlich unser nächster großer Meilenstein bei der Bereitstellung von IOTA 2.0 sein wird: Nectar.

Diese erste vollständige Implementierung von Nectar, die irgendwann im ersten Quartal erwartet wird, ist aus unserer Sicht eine wichtige Veröffentlichung, da sie im Wesentlichen unsere erste erfolgreiche Umsetzung der theoretischen Konzepte unserer Coordicide-Lösung darstellt.

Diejenigen, die diese vielen Monate der Coordicide-Entwicklung mit verfolgt haben, werden sicher die Bedeutung und unsere Aufregung über diese erste vollständige Coordicide-Implementierung verstehen. Mehr dazu folgt in Kürze!

Nachfolgend bieten wir unsere normalen Gruppen-Updates an, die einige Details über unseren Fortschritt in verschiedenen Bereichen enthalten. Zusätzlich zu den unten beschriebenen Fortschritten haben wir zwei Papiere, „On Fairness in Voting Consensus Protocols“ und „Committee selection in DAG distributed ledgers and applications“, zur Aufnahme in die Computing Conference 2021 angenommen. Wir freuen uns darauf, diese Papiere zu gegebener Zeit mit der Community zu teilen.

Pollen Testnet-Implementierung

Letzten Monat haben wir Pollen testnet v0.3.1 veröffentlicht. Die Hauptmerkmale dieses Updates sind das Refactoring der Nachrichtenstruktur gemäß dem neuen Tangle RFC und das Hinzufügen eines Community-basierten Einstiegsknotens. Sie können mehr darüber in unserem Blogpost zu den Release Notes lesen.

Das Team hat auch Fortschritte auf dem Mana-Zweig gemacht. Wir haben ein Tool hinzugefügt, mit dem man bestimmen kann, wie viel Zugangsmana generiert werden würde, wenn man Geld ausgibt. Wir haben einen neuen WeightedMana-Typ für Forschungszwecke hinzugefügt und die Schnittstellen BaseMana und BaseManaVector überarbeitet. Sowohl für Consensus als auch für Access Mana gibt es jetzt verbesserte Integrationstests. Wir haben uns auch darauf konzentriert, unsere forschungsorientierten Werkzeuge zu verbessern, wie z. B. eine neue Mana-Seite für den Pollen Analyzer sowie die Möglichkeit, Knoten basierend auf ihrem Mana einzufärben. Sie können mehr darüber in diesem Github-PR lesen.

Das Team hat sich darauf konzentriert, die Konsens-Implementierung durch die Einführung von FPC-Anweisungen zu optimieren. Das FPC-Protokoll erfordert, dass Knoten direkt zufällig ausgewählte Knoten zur Konfliktlösung abfragen. Die Informationen, die bei einem solchen Abstimmungsmechanismus entstehen, werden jedoch nicht im Tangle gespeichert, sondern befinden sich nur in den lokalen Metadaten des Knotens. Außerdem müssten die Knoten mit dem höchsten Mana auf zu viele Abfragen antworten, wenn das Quorum zur Abfrage zufällig proportional zum Mana gebildet wird, da ihre Wahrscheinlichkeit, im Quorum jedes Knotens enthalten zu sein, hoch ist. Die Idee des FPC-Statements ist es, jedem Knoten die freie Wahl zu lassen, ob er seine Meinung zu einem bestimmten Konflikt und einer bestimmten FPC-Runde in den Tangle schreibt, so dass andere Knoten seine Meinung erfahren können, ohne sie direkt anzufragen. Sie können mehr darüber in diesem Spezifikationsdokument lesen.

Ein weiterer wichtiger Meilenstein, den das Team erreicht hat, ist die Implementierung von Markern. Der Marker ist ein Werkzeug, um Wissen über die Struktur des Tangles in Bezug auf vergangene/zukünftige „Kegelmitgliedschaften“ abzuleiten. Um zu wissen, ob eine Nachricht im Tangle verwaist ist oder nicht, führen wir Finalitätsgrade ein, um den Status einer Nachricht zu interpretieren. Der Grad der Endgültigkeit wird durch das Zustimmungsgewicht bestimmt, welches der Anteil der aktiven Konsensmänner ist, die eine bestimmte Nachricht genehmigen. Um das Zustimmungsgewicht einer bestimmten Nachricht zu berechnen, muss man das Tangle von der Nachricht bis zu den Spitzen durchlaufen und das aktive Konsensmana aller Nachrichten in seinem zukünftigen Kegel aufsummieren. Der Marker kann die Zustimmungsgewichtung einer Nachricht effizient abschätzen und so den Teil des Tangles reduzieren, den wir durchlaufen müssen.

Schließlich haben sich viele Mitglieder unserer Community zusammengetan, um das erste IOTA Community-basierte dRNG-Komitee zu gründen. Das ist eine großartige Leistung und zeigt wirklich, wie sehr unsere Community ein fundamentaler und integraler Bestandteil dieses Prototyping-Prozesses ist.

Pollen Testnet Studiengruppe

Diesen Monat haben wir weiter den Einfluss von Mana auf das Autopeering untersucht. Wir sind mit den bisherigen Ergebnissen recht zufrieden, vor allem in Bezug auf Sybil-Schutz und Netzwerkdurchmesser. Eine unwissenschaftliche, aber dennoch anschauliche Animation eines erfolglosen Sybil-Angriffs auf das Autopeering finden Sie hier.

Wir haben zwei Hauptkandidatenansätze dafür betrachtet, wie Mana den Autopeering-Auswahlprozess beeinflussen sollte. Unsere Ergebnisse zeigen, dass beide Ansätze in gewisser Weise „äquivalent“ sind und wir daher den Kandidaten verwenden können, der einfacher zu implementieren und robuster gegenüber möglichen Unterschieden in der Mana-Wahrnehmung ist. In der Zukunft sind weitere quantitative Ergebnisse zu erwarten – eine gründliche Studie ist im Gange, aber eine solche Analyse benötigt einen angemessenen Zeitrahmen.

Vernetzung

Im Netzwerkteam führen wir Simulationen durch, um den Staukontrollmechanismus zu validieren. Wir belasten den Algorithmus unter extremen Bedingungen (Ring, kompletter Graph) oder sehr starken Angriffen (böswillige Knoten, die das Netzwerk spammen und kontinuierliches, wiederholtes Spamming mit mehreren Knoten). In unseren umfangreichen Simulationen hat sich der Algorithmus als robust gegenüber all diesen Umständen erwiesen und ist bereit, im Pollen-Testnetzwerk implementiert zu werden. Darüber hinaus forschen wir an einer Möglichkeit, die Adoptionsbarriere in Coordicide zu senken und den Zugang zu Knoten mit niedrigem Mana in unbelasteten Perioden zu garantieren.

An der VDF-Front untersuchen wir eine Möglichkeit, die Multi-Exponentierungs-Operation (entscheidende Operation bei der VDF-Berechnung) durch Montgomery-Reduktion zu beschleunigen. Wir haben sie in Open SSL implementiert, und unsere ersten Ergebnisse zeigen bis zu 6-fache Verbesserungen im Vergleich zu einem Szenario ohne die Reduktion.

Sharding

Im letzten Monat haben wir uns einige Second-Layer-Lösungen näher angesehen, insbesondere für Daten. Wir haben eine Idee diskutiert, die wir vorübergehend „Data Sharding“ nennen und die die Menge der auf dem Tangle gespeicherten Daten stark erhöhen würde. In diesem Vorschlag würden die Leute den Großteil ihrer Daten auf separaten Tangles der zweiten Schicht speichern. Hashes von Nachrichten aus diesen Tangles der zweiten Schicht würden auf dem Haupt-Tangle gepostet werden, um die Daten zu sichern.

Wir haben sorgfältig einen Vorschlag geschrieben, der Data Sharding zusammenfasst, so dass wir diese Idee analysieren und weitere Forschungsfragen identifizieren können. Wir diskutieren auch die Rolle, die Data Sharding in IOTAs Sharding-Vision spielen wird.

Wenn Sie Fragen haben oder einfach nur hallo sagen möchten, finden Sie die Mitglieder unseres Forschungsteams im #tanglemath-Kanal auf unserem Discord. Sie sind auch herzlich eingeladen, unseren technischen Diskussionen in unserem öffentlichen Forum zu folgen und sich daran zu beteiligen: IOTA.cafe.

Original: https://blog.iota.org/iota-research-status-update-december-2020-c69bb28a0456/

Pollen Testnet v0.3.1 Versionshinweise

Wir veröffentlichen eine neue Version unseres Pollen-Testnetzes: v0.3.1. Die vollständige Liste der Änderungen enthält:

  • Refactor Nachrichtenstruktur gemäß dem neuen Tangle RFC, einschließlich Unterstützung für mehrere Elternteile, aktualisiertes lokales Dashboard, neue Einheitentests, maximale Nutzlastgröße geändert auf 65157 Bytes und mehr
  • Hinzufügen eines Community-basierten Einstiegsnode
  • Hinzufügen eines Commit-Tags zur Version
  • Hinzufügung eines Pakets für häufige Sentinel-Fehler
  • Verbesserung der Dashboard-Websocket-Verwaltung
  • Integrieren einer NTP-basierten Uhr in die Netzwerkverzögerungsanwendung
  • Umschalten von Packer auf pkger to Pack-Dashboard
  • Wechsel von Viper zu koanf als Kernbibliothek für die Konfiguration
  • Verwaltung der Tip-Auswahl von Value Tangle fixieren
  • Korrektur der mps-Abfragebeschriftung in grafana
  • Behebung einer potenziellen Race Condition innerhalb des Uhrenpakets
  • Upgrade auf das neueste hive.go
  • Upgrade der NodeJS-Abhängigkeiten des Dashboards

Wie bei der vorherigen Version setzt diese Versions Bump sowohl das Netzwerk als auch das Tangle und alle Salden und tokenisierten Assets zurück.

Wir möchten Sie auch darüber informieren, woran das Team derzeit arbeitet: Levente Pap und Bill Acha konzentrieren sich hauptsächlich auf die Entwicklung des Mana-Moduls. Für diese Aufgabe implementieren sie sowohl das Konsensmana als auch das Zugangsmana sowie einige Werkzeuge, wie neue APIs und angereicherte Dashboards, so dass wir die Manadynamik auf dem Pollen-Testnetz überwachen und analysieren können. Hans Moog arbeitet an der Verschmelzung des Message Tangle mit dem Value Tangle sowie an verschiedenen Mechanismen, um die Notwendigkeit, in den Tangle zu gehen, zu minimieren und so seine Leistung zu optimieren. Jonas Theis, Vivian Lin und Angelo Capossele arbeiten an der Spezifizierung verschiedener Aspekte unseres Protokolls und an der Implementierung von Funktionen über den gesamten Protokollstapel hinweg. Wolfgang Welz, Olivia Saa und Billy Sanders schlagen die Brücke zwischen Forschung und Entwicklung, indem sie wertvolle Richtlinien und Unterstützung für die modernsten Module bereitstellen.

Als Randnotiz hat unser Kollege Sam Chen eine Client-Bibliothek veröffentlicht, die Sie bei der Entwicklung von IoT-Anwendungen mit einem GoShimmer Node in der Sprache C unterstützt. Sie zielt darauf ab, auf IoT-Geräten wie Raspberry(Banane/Orange) Pi, ESP32 und Mikrocontrollern mit Netzwerk-Stack zu laufen.

Wir möchten noch einmal unserer gesamten Gemeinschaft für ihre Hilfe und Unterstützung danken. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im Kanal #tanglemath auf unserer Discord. Sie können sich auch an der #goshimmer-Diskussion auf Discord beteiligen.

Original von Angelo Capussele: https://blog.iota.org/pollen-testnet-v0-3-1-release-notes-4171ec9bef09

IOTA Dev Status Update – November 2020 – Deutsch

Dieses Update wird jeden Monat vom IOTA-Entwicklerteam veröffentlicht und versorgt dich mit Neuigkeiten und Updates über unsere Schlüsselprojekte! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen möchten.
Die Forschungsabteilung gibt auch ein monatliches Update heraus, das Sie vielleicht lesen möchten.

IOTA 1.5

„IOTA Dev Status Update – November 2020 – Deutsch“ weiterlesen