UZH Blockchain Center erhält Stipendium zur Untersuchung des IOTA-Konsensmodells

TL;DR:
Als jüngste Entwicklung ihrer Partnerschaft mit dem Blockchain Center der Universität Zürich hat die IOTA Foundation dem Center einen Zuschuss zur Erforschung des im IOTA-Protokoll verwendeten Konsensmodells gewährt.

„UZH Blockchain Center erhält Stipendium zur Untersuchung des IOTA-Konsensmodells“ weiterlesen

IOTA-Stiftung vergibt Zuschuss an das Imperial College London

BERLIN. 3. Februar 2022 – Die IOTA Foundation, die gemeinnützige Organisation, die die Entwicklung von Open-Source-Distributed-Ledger-Technologien (DLT) vorantreibt, kündigt einen philanthropischen Zuschuss in Höhe von 1 Million Pfund für das Imperial College an, um zu untersuchen, wie DLT zur Förderung der Kreislaufwirtschaft beitragen kann. Mit diesem Zuschuss wird eine Initiative finanziert, die Forschungsexpertise aus dem gesamten College zusammenführt, um das I3-LAB (Imperial-IOTA-Infrastructures Lab) innerhalb der Dyson School of Design Engineering zu gründen. „IOTA-Stiftung vergibt Zuschuss an das Imperial College London“ weiterlesen

IOTA Forschungsstatus Update Juli 2021

Nach der Aufregung um die DevNet-Veröffentlichung Anfang Juni ist unser Team ein wenig zu seiner normalen Kadenz zurückgekehrt. Wir arbeiten weiter an der Fertigstellung der Spezifikationen, optimieren bestimmte Aspekte des Protokolls, wie z. B. den Algorithmus zur Staukontrolle, und nehmen unsere Arbeit an Data Sharding wieder auf.

Ein Unterschied besteht jedoch darin, dass uns die im DevNet gesammelten Daten für unsere Arbeit zur Verfügung stehen. Wir hoffen, dass die folgenden Updates für Sie informativ sind, da wir genau erklären, wie diese Daten verwendet werden und was die nächsten Schritte für die IOTA-Forschungsabteilung sein werden.

DevNet-Implementierung

Wir sammeln wertvolle Daten von den meisten der Knoten im DevNet. Mit diesen Daten konnten wir einige Fehler in unserem Netzwerk-Stack entdecken, die dazu führen, dass einige Nachrichten mit größeren Verzögerungen als erwartet durch das Netzwerk propagiert werden.

Unabhängig davon, dass wir dieses Problem mit v0.7.3 behoben haben, hat dieses Problem einen Nachteil in Bezug auf FCoB aufgezeigt, dem Protokoll, mit dem die Knoten ihre anfängliche Meinung zu jeder Transaktion festlegen. Genauer gesagt kann es aufgrund der aktuellen Implementierung von FCoB und FPC passieren, dass zwei (oder mehr) Konflikte beide abgelehnt werden können. Ohne einen klaren Gewinner könnten neue Knoten, die dem Netzwerk beitreten, oder bestehende Knoten, die fehlende Nachrichten verfestigen, nur eine solche Nachricht erhalten und daher versuchen, ihre neuen Nachrichten an eine Seite des Tangles anzuhängen, die nicht genug Zustimmungsgewicht erhält, um jemals bestätigt zu werden.

Obwohl wir FCoB verbessern könnten, indem wir Kommunikationsredundanz für die abgelehnten Konflikte hinzufügen, möchten wir diese Gelegenheit nutzen, um eine Variante von FPC zu untersuchen, die wir „FPC on a set“ nennen und die immer einen Gewinner innerhalb einer Konfliktmenge auswählen würde. Dies würde uns auch erlauben, mit einem Mechanismus zu experimentieren, der dem On Tangle Voting (OTV) ähnlicher ist, kombiniert mit FPC on a set als Metastabilitätsbrecher.

Andere Aspekte der Implementierung werden ebenfalls verbessert. Zum Beispiel verschieben wir den Scheduler (den Kern der Staukontrolle) nach dem Booker. Dies führt zu einem natürlicheren Verhalten beim Synchronisieren, da der Knoten den Scheduler nicht explizit umgehen muss, um mit dem Netzwerk gleichzuziehen.

Darüber hinaus überarbeitet das Team den Solidification-Mechanismus so, dass eine Nachricht als solide gilt, wenn sowohl ihre Eltern als auch ihre Nutzlast (d. h. ihre Transaktion) solide sind. Dies wird es uns ermöglichen, die kostspielige Überprüfung der Vergangenheit zu entfernen.

Protokoll-Aktualisierung

Mit der DevNet-Implementierung kam die erste Welle des Feedbacks bezüglich der vielen Komponenten, die unser IOTA 2.0-Netzwerk ausmachen werden. Während die meisten der Komponenten vielversprechende Ergebnisse zeigten, erkannten wir auch, dass einige von ihnen Änderungen benötigen würden, um den Standards zu entsprechen, die wir vom zukünftigen Netzwerk erwarten. Glücklicherweise macht es die modulare Natur von IOTA 2.0 möglich, dass wir Komponenten entwickeln, mit denen wir zufrieden sind, während wir gleichzeitig die erforschen und verbessern, die Aufmerksamkeit erfordern.

Die gesamte Forschungsabteilung hat sich zusammengesetzt, um zu bestimmen, welche Komponenten von weiterer Forschung profitieren könnten, und um zu entscheiden, wie wir dies in einer Weise organisieren, die die anderen laufenden Projekte nicht behindert. Die wichtigsten Verbesserungen, an denen wir arbeiten werden, sind:

  • Erhöhung der Modularität des Konsens-Algorithmus durch Einführung der „Conflict Selection Function„, die alle Konsens-Mechanismen verallgemeinert, die in IOTA 2.0 implementiert werden können. Aktualisierung des FPC zum „On Tangle FPC on a set“ durch die
  • Verwendung der Konfliktauswahlfunktionen.
  • Entfernen der Notwendigkeit, über Zeitstempel abzustimmen und Nachrichten als geeignet für die Tipp-Auswahl zu klassifizieren, indem der Mechanismus „Inclusion Score“ eingeführt wird.
  • Entfernen Sie die Notwendigkeit für schwache Freigaben und untersuchen Sie, wie sich das Protokoll unter Konflikt-Spamming verhält.

Nachdem wir diese Forschungsthemen definiert hatten, teilten wir uns in zwei Gruppen auf, um sie in Angriff zu nehmen. Das Hauptaugenmerk dieser Forschung liegt darauf, zu Ergebnissen zu kommen, die in die Spezifikationen aufgenommen werden können. Wir hoffen, bis zum nächsten Forschungsupdate einige Ergebnisse vorlegen zu können.

Spezifikationen

Nach umfangreicher Arbeit, um den ersten Stapel von Spezifikationen fertig zu stellen und mit der Gemeinschaft zu teilen, hat das Team eine Übersicht über unsere aktuelle Forschung erstellt, um die nächsten Ziele zu bestimmen. Um dies in angemessener Weise zu tun, war der kürzliche Start des DevNet entscheidend. Die neuen Aufgaben, die beschlossen wurden, waren: Aktualisierung der Spezifikationen gemäß den jüngsten Ergebnissen aus dem DevNet; Fortfahren mit dem Standardisierungsprozess für die Dateien, die nicht von den DevNet-Ergebnissen betroffen sind; und Arbeit an der zweiten Charge von Spezifikationen, um alle Dateien geschrieben zu haben.

Da der Schwerpunkt der Forschungsabteilung in den nächsten Monaten auf der Forschung liegen wird, wird die Arbeit an den Spezifikationen natürlich folgen. Sobald die Forschung abgeschlossen ist, werden wir die relevanten Ergebnisse in die Spezifikationen aufnehmen.

Vernetzung

Die Forschung im Netzwerkteam konzentriert sich derzeit auf die Implementierung des Staukontrollalgorithmus im DevNet und dessen Integration mit dem Rest des Protokolls.

Als Ergebnis untersuchen wir eine Reihe von Optimierungen, die es uns ermöglichen, den Code zu vereinfachen und gleichzeitig die Leistung zu verbessern. Die wichtigste Änderung gegenüber der ursprünglichen Idee ist die Tatsache, dass Nachrichten sofort nach ihrer Festigkeit gebucht werden können, sodass der Scheduler nur noch bestimmt, welche Nachrichten geklatscht und zur Tippliste hinzugefügt werden. Dies erlaubt eine viel schnellere Synchronisation für out-of-sync Knoten, die alte Nachrichten mit einer Rate wiederherstellen können, die schneller als die des Schedulers ist. Andererseits eröffnet die Verlagerung des Schedulers an das Ende des Datenflusses die Möglichkeit von Angriffen, die derzeit untersucht werden. Wir können potenzielle Angriffe durch die Einführung des Inklusions-Scores entschärfen, einer Metrik, die die Wahrscheinlichkeit misst, dass eine Nachricht in Zukunft ein permanenter Teil des Tangles wird.

Als zweites Forschungsthema untersuchen wir derzeit ein Modell zur Verbesserung der Erlebnisqualität für die Benutzer. Insbesondere bestimmt der Rate Setter den Durchsatz eines bestimmten Benutzers, abhängig vom Zugriffsmana. Fragen wie „wie viele Nachrichten kann ich – als Knoten – mit X Mana senden“ oder „wann darf ich die nächste Nachricht ausgeben“ werden durch dieses Modell beantwortet.

Schließlich sind wir stolz darauf, bekannt geben zu können, dass unser Paper, das wir in Zusammenarbeit mit Professor Bob Shorten und seinem Team am Imperial College London geschrieben haben, „Access Control for Distributed Ledgers in the Internet of Things: A Networking Approach„, zur Veröffentlichung im IEEE Internet of Things Journal (Impact Factor 9.936), einer hochrangigen Fachzeitschrift für Computerwissenschaften, angenommen worden ist.

Sharding

Während der letzten zwei Monate war die gesamte Forschungsabteilung auf zwei Dinge fokussiert: DevNet-Entwicklung und die Veröffentlichung der Spezifikationen. Daher ging die Sharding-Gruppe, zusammen mit einigen anderen Gruppen, in eine Pause, damit unsere Arbeitskräfte diesen Aufgaben richtig zugewiesen werden konnten. Mit der Freigabe des DevNet und der ersten Spezifikationsfreigabe arbeitet die Forschungsabteilung wieder an ihren Sharding-Lösungen. Der erste Vorschlag, ein Whitepaper über Data Sharding, befindet sich gerade in Produktion, und wir erwarten bald eine Veröffentlichung, um unsere Ideen mit der Community zu teilen.

Wir erwarten, dass die Entwicklung des Data Sharding den Durchsatz des Netzwerks für Datennachrichten deutlich verbessern wird, und seine Implementierung kann mit dem zukünftigen Fluid Sharding parallelisiert werden.

Original by William Sanders: https://blog.iota.org/iota-research-status-update-july-2021/

IOTA 2.0 Forschungsspezifikationen

Dieser Beitrag soll kurz die Forschungsspezifikationen vorstellen, die wir mit der Veröffentlichung des IOTA 2.0 DevNet (Nectar) zur Verfügung gestellt haben. Die Spezifikationen können hier gefunden werden. Ihr Zweck ist es, den aktuellen Stand des IOTA 2.0-Protokolls sorgfältig zu erklären, sowohl für interne als auch für externe Entwickler, die auf Nectar aufbauen oder es testen wollen, für Akademiker, die das Protokoll analysieren, modellieren und optimieren wollen und eine rigorose Beschreibung jedes Moduls benötigen, und für Community-Mitglieder und jeden, der einfach mehr über das Protokoll erfahren möchte.

Wir hoffen, dass dieser Beitrag ein nützlicher Leitfaden zu den IOTA 2.0-Forschungsspezifikationen ist, und wir hoffen, dass Sie in sie eintauchen, um so viel wie möglich darüber zu lernen, wie das IOTA 2.0 DevNet funktioniert! Bevor Sie jedoch die Spezifikationen lesen, möchten wir dem Leser ein paar Punkte erklären.

Was sind Forschungsspezifikationen?

Diese Sammlung enthält Spezifikationen zu jeder wichtigen experimentellen Komponente von Coordicide. Es gibt jedoch zwei wichtige Vorbehalte bezüglich dieser Dokumente.

Erstens: Keiner der Parameter ist endgültig festgelegt. Obwohl unsere früheren Studien bestimmte Bereiche für jeden dieser Parameter angeben, erfordert die Abstimmung jedes Parameters auf seinen optimalen Wert eine Menge Tests und Forschung. Glücklicherweise können wir diese Forschung durchführen, während die Software entwickelt wird, da die Parameter, die wir feineinstellen, im Code sehr leicht zu ändern sind. In diesen Spezifikationen wird jeder Parameter auf eine fundierte Schätzung gesetzt.

Zweitens werden mehrere nicht-experimentelle Komponenten des Protokolls in diesem Dokument ausgelassen. Zum Beispiel werden Snapshotting (das Modul, das das Pruning von alten Nachrichten in Permaknoten verwaltet) und eine Beschreibung des Gossip-Protokolls weggelassen. Beide Komponenten sind gut verstandene Bestandteile des aktuellen Chrysalis-Mainnets, und daher waren wir der Meinung, dass es sich nicht lohnt, die Veröffentlichung der Spezifikationen zu verzögern, wenn man sie einbezieht. Im Inhaltsverzeichnis der Readme-Datei können Sie sehen, dass noch einige Spezifikationen fehlen. Diese werden im Laufe des Sommers hinzugefügt.

Ein letzter Punkt, der zu beachten ist, ist, dass diese Spezifikationen weder stabil sind noch einem strengen Versionierungssystem unterliegen. Nectar ist ein Forschungsprototyp. Als solcher wird er zur Forschung und zur Verfeinerung der Spezifikationen verwendet, wenn dies zur Optimierung des Protokolls erforderlich ist. In den kommenden Monaten werden wir Daten sammeln und Experimente mit dem IOTA 2.0 DevNet durchführen. Wir haben viel über das Protokoll gelernt, indem wir es einfach gebaut haben, und die Informationen, die wir in dieser Phase durch Testen gewonnen haben, werden das Protokoll und zukünftige Implementierungen weiter verbessern.

Konkret werden wir:

  • Optimieren der Parameter
  • Verbesserung der Software-Implementierungen des Protokolls in Verbindung mit der Entwicklung der Bee- und Hornet-Nodes
  • Identifizierung und Beseitigung potenzieller Leistungsengpässe
  • Optimieren der Leistung jedes Moduls
  • Vereinfachung des Protokolls durch Eliminierung aller Elemente, die sich als unnötig erweisen

Während wir diese Verbesserungen am Protokoll vornehmen, werden sich diese Spezifikationen ändern.

Jedes Protokoll, das die Verabschiedung erreicht, entwickelt sich ständig weiter und verbessert sich, und das IOTA-Protokoll wird nicht anders sein. Die IOTA-Forschungsabteilung wird immer danach streben, neue Entdeckungen zu machen, um das Protokoll zu perfektionieren, und wir werden auch immer eine Art von Forschungsspezifikationen pflegen, um die vorgeschlagenen Änderungen zu verfolgen.

Nectar-Dokumentation vs. Forschungsspezifikationen

Der Leser wird feststellen, dass das GoShimmer-Repository auf GitHub eine eigene Dokumentation enthält, die das Protokoll beschreibt. Wie verhält sich diese Dokumentation zu diesen Spezifikationen? Wie ist die Beziehung zwischen Nectar und diesen Spezifikationen?

Die Nectar-Dokumentation beschreibt, wie das Protokoll im IOTA 2.0 DevNet funktioniert, während die IOTA 2.0 Forschungsspezifikationen beschreiben, wie das IOTA 2.0 Protokoll aussehen sollte. Theoretisch sollten diese gleich sein (und eines Tages werden sie es auch sein), aber derzeit gibt es einige Unterschiede.

Die Nectar-Dokumentation wurde für zwei Zwecke entwickelt. Erstens sollte sie unseren Forschungsingenieuren helfen, herauszufinden, wie bestimmte Module zu kodieren sind, da Teile des Prototyps vor der Spezifikation geschrieben wurden. Zweitens hilft die Dokumentation anderen, sowohl intern als auch extern, sich in der Codebasis zurechtzufinden. Daher ist die Nectar-Dokumentation nicht vollständig und deckt nur die Kernbereiche des Protokolls ab.

Da es sich bei Nectar um einen Prototyp handelt, wurden bei der Implementierung auch einige Abkürzungen genommen. Zum Beispiel ist das dRNG-Komitee feststehend, anstatt auf Basis des Konsens-Manas zu rotieren. Dies vereinfacht die Implementierung und erlaubt es uns, die erforderliche Forschung durchzuführen. Die Forschungsspezifikationen sagen, wie das Komitee ausgewählt werden soll.

Protokoll vs. Implementierungsspezifikationen

Ein Protokoll ist eine Vereinbarung zwischen mehreren Knoten, wie Daten ausgetauscht und interpretiert werden sollen. Die Implementierung des Protokolls ist die Software, die die tatsächlichen Operationen ausführt, die durch das Protokoll vorgegeben sind. Das Protokoll ist eindeutig und fest, während die Implementierung variiert. Zum Beispiel schreibt HTTP (HyperText Transfer Protocol) vor, wie Ihr Browser mit Internetservern kommunizieren soll. Es gibt verschiedene Browser (Firefox, Chrome, Safari, usw.), die dieses Protokoll ausführen. Intern arbeiten diese Browser sehr unterschiedlich und haben verschiedene Funktionen und Designs, aber sie kommunizieren alle auf die gleiche Weise mit einem Server.

IOTA 2.0 ist ein standardisiertes Protokoll und wird daher spezielle Protokollspezifikationen haben, die vorschreiben, wie sich IOTA-Knoten zu verhalten haben. Die IOTA Foundation wird zwei Software-Implementierungen dieses Protokolls erstellen: Bee und Hornet, geschrieben in Rust bzw. Go. Jede dieser Implementierungen wird jedoch Implementierungsspezifikationen haben, die genau beschreiben, wie die Software funktioniert. Mit Hilfe der Protokollspezifikationen kann (und wird hoffentlich irgendwann) jeder seine eigenen Softwareimplementierungen mit eigenen Implementierungsspezifikationen schreiben.

Diese Forschungsspezifikationen sind eine Mischung aus den Protokollspezifikationen und den Implementierungsspezifikationen. Warum ist dies der Fall? Da alle unsere Ideen in Code getestet werden müssen, müssen wir gleichzeitig das Protokoll und eine Implementierung des Protokolls entwickeln. Alle Ideen, die nicht effizient implementiert werden können, müssen verworfen werden. Jetzt, wo wir einen funktionierenden Prototyp haben, können wir damit beginnen, das Protokoll von diesen Spezifikationen zu trennen, während die Entwicklungsabteilung an der Implementierung arbeitet.

Wir hoffen, dass dieser Beitrag informativ war, und wir hoffen, dass auch die nicht so technisch interessierten Leser sich die Zeit nehmen, die Forschungsspezifikationen durchzusehen oder sie sogar im Detail zu lesen, wenn Sie dazu geneigt sind. Natürlich sind wir sehr stolz auf unsere Rolle bei der Entwicklung des Protokolls bis zu diesem Punkt, und es ist wunderbar, dass eine gut informierte Gemeinschaft Interesse an unserer Arbeit zeigt.

Original by William Sanders: https://blog.iota.org/iota-2-0-research-specifications/

IOTA Forschungsstatus Update März 2021

In diesem Monat gab es neue Veröffentlichungen unseres Pollen-Testnetzes sowie weitere Fortschritte bei der Verifizierung unseres Kernprotokolls, während wir uns auf die Veröffentlichung von Nectar vorbereiten.

Da die „Nectar“-Phase unserer Coordicide-Implementierung vor uns liegt, wickelt unser Team derzeit die letzten Forschungsarbeiten ab, die zum Erreichen dieses Meilensteins erforderlich sind. Zu diesem Zeitpunkt beziehen sich die verbleibenden Arbeiten hauptsächlich auf Optimierungen, und wir werden weiterhin die von Pollen gesammelten Daten nutzen, um alle erforderlichen Änderungen zu implementieren. Nectar wird unsere erste voll funktionsfähige Coordicide-Implementierung sein, daher wollen wir sie von Anfang an so robust wie möglich machen, mit dem Ziel, sie weiter zu optimieren, während wir das Netzwerk gemeinsam nutzen und daraus lernen. „IOTA Forschungsstatus Update März 2021“ weiterlesen

IOTA Forschungsstatus Update – Mai 2020

Original by Serguei Popov: https://blog.iota.org/iota-research-status-update-may-2020-35a7c3dadd8d (14.05.2020)

Der vergangene Monat war für uns unglaublich produktiv, da wir die letzten paar Details um die Koordizid-Spezifikationen herum festlegen konnten. Die Übergabe der Koordizid-Spezifikationen an die Entwicklung wird ein wichtiger Meilenstein für unser Team sein. Wir danken allen für ihr Interesse an unserer Arbeit und ihre Geduld während dieses Prozesses. Nachstehend finden Sie spezifische Aktualisierungen, die den Fortschritt in jedem Bereich hervorheben.

GoShimmer-Implementierung

Das GoShimmer-Team hat sich auf die Integration von FPC mit dem Wert Tangle konzentriert. Eine große Anstrengung wurde der Reformierung des gesamten Werttransaktionsprozesses gewidmet, um den Code stabiler und sauberer zu machen. Wir haben auch das Konzept der Synchronisation eingeführt. Das bedeutet, dass ein Knoten, der dem Netzwerk beitritt, seinen Synchronisationsstatus kennt, indem er prüft, ob die Nachrichten, die er als „Anker“ verwendet, fest sind oder nicht. Ein brandneuer Tangle-Visualisierer ist jetzt Teil des GoShimmer-Dashboards. Darüber hinaus wurde das Integrationstest-Framework verbessert und durch die Implementierung weiterer Tests für dRNG, Synchronisation und Nachrichtenrelais bereichert. Wie immer können Sie die Entwicklung auf unserem GitHub-Repository verfolgen.

FPC

Wir haben ein Forschungspapier über eine optimierte Version der FPC vorgelegt. Diese Version von FPC ist auf eine Umgebung zugeschnitten, in der die Stimmkraft proportional zum Mana eines Knotens ist. Sobald der Schiedsrichterprozess abgeschlossen ist, werden wir die Ergebnisse veröffentlichen. Gegenwärtig verfassen wir eine kurze Forschungsnotiz, in der wir Effekte untersuchen, die sich aus einer gewichteten Abstimmung ergeben können, wie z.B. Verlust der Anonymität, Zentralisierung, Skalierbarkeit, während wir ihre Relevanz für das Protokolldesign und die Implementierung diskutieren.

Spezifikationen

Viele neue Spezifikationen werden derzeit fertiggestellt, wie z.B. die für Peer Discovery und Resynchronisation, und wir erwarten, dass viele weitere bis Anfang nächsten Monats fertiggestellt werden.

Wie wir in der Aktualisierung vom letzten Monat erwähnt haben, haben wir an einem neuen „Benennungsschema“ für die neuen Koordizidstrukturen gearbeitet. Einige Folgegespräche zu diesem Thema waren sehr produktiv, und ein neues Benennungsschema wurde fertiggestellt. Ein Blog-Beitrag dazu ist in Vorbereitung, und wir freuen uns darauf, nach dem Koordizid eine neue, standardisierte Sprache für alle Aspekt von IOTA zu haben.

Vernetzung

Wir arbeiten derzeit an Leistungsoptimierungen des Staukontrollalgorithmus. Der vorgeschlagene Scheduler basiert auf dem Defizit-Round-Robin, der leichtgewichtig ist und es dem Protokoll erlaubt, minimale Verzögerung, maximale Auslastung und gewichtete Fairness (d.h. Durchsatz proportional zu Mana) zu erreichen. Was die Angriffsanalyse betrifft, so haben wir verifiziert, dass ein bösartiger Knoten, der versucht, seinen zulässigen Durchsatz zu überschreiten, eine Verzögerung für seine eigenen Transaktionen verursacht, während ehrliche Transaktionen davon nicht betroffen sind. Infolgedessen kann böswilliges Verhalten erkannt und bestraft werden.

Das Team hat auf der IEEE ICBC 2020 auch das Papier mit dem Titel „On the Fairness of Distributed Ledger Technologies for the Internet of Things“ vorgestellt, in dem unser adaptiver PoW-Algorithmus diskutiert wird. Im Zusammenhang mit VDFs evaluieren wir derzeit Multi-Potenzierungstechniken auf der Grundlage des Lenstra-Algorithmus. Dieser Algorithmus ist unter anderem relevant, um die VDF-Verifikationszeit zu reduzieren.

dRNG

Wir haben die erste Version der dRNG-Modulspezifikation für das Post-Koordizid-IOTA-Netzwerk fertiggestellt. Unsere Lösungen umfassen die Auswahl von Komitees aus Knoten mit hohem Mana-Anteil (unter Anwendung eines speziellen „Antrags“-Verfahrens). Der Ausschuss verwendet dann ein auf einer Schwellenwertsignatur basierendes Schema, um Zufallszahlen zu erzeugen. Gegenwärtig konzentrieren wir uns auf eine Zusammenarbeit mit Ingenieuren, die uns helfen soll, die Spezifikationen und die Optimierung der angenommenen Lösungen zu verbessern. Wir beabsichtigen, unsere Ergebnisse zu teilen und sie in Form eines wissenschaftlichen Artikels zu veröffentlichen.

Mana und Autoperieren

Im letzten Monat haben wir die Spezifikationen für Mana und Autopeering geschrieben, mit dem internen Ziel, beides bis zur Aktualisierung im nächsten Monat fertigzustellen!

Wir stellten einige Herausforderungen bei der Umsetzung von Mana in Autopeering fest. Im Wesentlichen sollte unser aktueller Vorschlag dazu führen, dass der Netzdurchmesser zu groß ist, während er keinen ausreichenden Schutz für manaarme Knotenpunkte bietet. Siehe die Diskussion hier für die technischen Details. Wir entwarfen einige mögliche einfache Lösungen und testeten diese dann mit unserem Autopeering-Simulator. Die Simulationen haben gezeigt, dass eine bestimmte Lösung sehr gut funktioniert, und deshalb werden wir diese nun in die Spezifikationen aufnehmen.

Protokoll

Die Untersuchung möglicher Engpässe bei der Nachrichtenverarbeitung durch die Knoten gab uns eine Liste, die mit den anderen Teams diskutiert und simuliert werden sollte. Diese Simulationen, die wir voraussichtlich noch in diesem Monat durchführen werden, werden es uns auch ermöglichen, die Leistung in verschiedenen Situationen zu messen. Wir sind bei der Lösung kleiner Probleme wie Verfestigungen vorangekommen. Im Koordizid-Tangle gibt es zwei Fälle von Verfestigungen, die sehr unterschiedlich funktionieren. Wir haben auch begonnen, das Problem der Verwaisung zu erforschen, oder wie man definiert, wann eine Nachricht aus dem Hauptbuchzustand entfernt werden sollte. Wir gehen davon aus, dass wir dies bis nächste Woche abschließen und direkt mit dem Schreiben des Protokolls und der Verarbeitungsspezifikationen beginnen können.

Wir freuen uns darauf, im nächsten Monat weitere Updates mit allen zu teilen! Wie immer können Sie sich über das IOTA-Forschungsteam im Kanal #tanglemath auf unserem Discord auf dem Laufenden halten. Und Sie sind herzlich eingeladen, unsere technischen Diskussionen in unserem öffentlichen Forum zu verfolgen und daran teilzunehmen: IOTA.cafe.