Verbesserungen des IOTA 2.0 Konsens-Mechanismus

TL;DR

Wir beschreiben, was wir aus dem IOTA 2.0 DevNet gelernt haben und konzentrieren uns dabei auf den Konsensmechanismus. Wir erklären, wie wir das Protokoll verbessern können, indem wir den FPC-Abstimmungsprozess durch einen Mechanismus rationalisieren, den wir On Tangle FPC on a set (OTFPC) nennen.

Bei der IOTA Foundation arbeiten Ingenieure und Forscher sehr eng zusammen, oft im selben Team und nach einer agilen Methodik. Der Ansatz ist pragmatisch und einfach:

  1. Definieren Sie das Problem
  2. Brainstorming von Ideen zur Lösung des Problems
  3. Vielversprechende Ideen in Lösungen umwandeln
  4. Untersuchung der Lösungen mit einer Vielzahl von Methoden und aus verschiedenen Blickwinkeln: analytisch, durch Simulationen, durch Experimente
  5. Die gesammelten Daten synthetisieren und die Lehren aus Punkt 4 ziehen und zur Verbesserung der Lösung nutzen

Eines der besten Beispiele für diesen Ansatz ist GoShimmer, der Forschungsprototyp, der das IOTA 2.0 DevNet betreibt. Sein Hauptzweck ist es, Ideen aus der Forschung in eine funktionierende Implementierung zu verwandeln, damit wir wichtige Aspekte wie Machbarkeit, Schutz gegen verschiedene Angriffe, Leistung und die Behebung von Fehlern auf dem Weg bewerten können.

Die Veröffentlichung der ersten Iteration des IOTA 2.0 DevNet war ein sehr wichtiger Meilenstein für das Coordicide-Projekt, da wir nun die Möglichkeit haben, den Prototyp unserer vollständig dezentralisierten Lösung zu sehen, zu erleben und zu analysieren. Was wir dabei gelernt haben, hilft uns bereits dabei, das zu verbessern, was wir bisher gebaut haben. In diesem Blogbeitrag geht es um den Konsensmechanismus und wie wir das Protokoll durch die Einführung von On Tangle FPC (OTFPC) verbessern können.

Der Konsensmechanismus von IOTA 2.0 ist so konzipiert, dass er ohne Erlaubnis und ohne Anführer funktioniert. In seinem Kern kombiniert er

  1. ein binäres Abstimmungsprotokoll (FPC) als Vorkonsens und Metastabilitätsbrecher (d.h. er zwingt das System zu einer Entscheidung),
  2. und ein virtuelles Abstimmungsprotokoll oder Zustimmungsgewicht (AW), das eine Endgültigkeit ähnlich der Regel der längsten Kette beim Nakamoto-Konsens (d. h. schwerster Zweig) bietet.

Diese Kombination ist aus zwei Gründen notwendig. Erstens brauchen wir FPC, um eine gemeinsame Wahrnehmung dessen, was gut und schlecht ist, durchzusetzen. Zweitens legt FPC die anfängliche Meinung über Transaktionen auf der Grundlage ihrer Ankunftszeit fest (die FCoB-Regel): Ankunftszeiten sind jedoch unbeständig (denken Sie nur an Ihre Internetverbindung zu Hause), und jede Regel, die auf Ankunftszeiten basiert, wird dazu führen, dass einige Knoten aus der Synchronisation fallen. Daher ist die Genehmigungsgewichtung notwendig, damit Knoten, die aus dem Takt geraten sind, aufholen können.

Diese Kombination führt jedoch zu einem recht komplizierten Code. Wir haben festgestellt, dass wir das FPC-Verfahren tatsächlich nachahmen können, indem wir die Genehmigungsgewichtung jedes Konflikts verwenden. Bei FPC fragt ein Knoten einfach andere Knoten nach ihrer Meinung zu einer Transaktion. Jedes Mal, wenn sich jemand auf eine Transaktion bezieht, „stimmt“ er für sie, so dass die Zustimmungsgewichtung zeigt, wer für was gestimmt hat. Indem wir die direkten Abfragen gegen die AW austauschen, erhalten wir ein Verfahren, das wir On Tangle FPC (OTFPC) nennen. In diesem Beitrag werden wir erklären, wie unsere Verbesserungen drei Dinge erreichen:

  1. Starke Vereinfachung unserer Codebasis
  2. Verringerung des Kommunikations-Overheads
  3. Beschleunigung der Bestätigungszeiten

FPC

Das Fast Probabilistic Consensus (FPC)-Protokoll ist ein binäres Abstimmungsprotokoll, bei dem jeder Knoten mit einer anfänglichen Meinung zu einer von FCoB festgelegten Transaktion beginnt. Die Knoten tauschen dann in mehreren Runden Anfragen und Antworten zu ihren Meinungen aus, bis jeder Knoten mit einem endgültigen Wert abschließt: Gefallen oder Nichtgefallen. Das Ergebnis der Abstimmung wird jedoch stark durch den Anteil der ursprünglichen Meinung beeinflusst. Nehmen wir zum Beispiel zwei Transaktionen, die miteinander in Konflikt stehen und von der Mehrheit des Netzes innerhalb der ersten Quarantänezeit (Q1) gesehen werden. Dann werden beide mit hoher Wahrscheinlichkeit von FPC abgelehnt und somit nicht in den Tipp-Pool aufgenommen und schließlich verwaist.

Ohne einen eindeutigen Gewinner könnten neue Knoten, die dem Netzwerk beitreten, oder bestehende Knoten, die fehlende Nachrichten verfestigen, nur eine der beiden Transaktionen erhalten (z. B. aufgrund einer indirekten Verfestigung über schwache Referenzen oder eines Netzwerkausfalls), die anfängliche Meinung über FCoB auf „gefällt mir“ setzen und somit versuchen, ihre neuen Nachrichten an eine Seite des Tangles anzuhängen, die nicht genug Zustimmungsgewicht erhält, um jemals bestätigt zu werden. Dieses Verhalten könnte dadurch gemildert werden, dass nur die abgelehnten Konflikte mitgeteilt werden, was allerdings mit zusätzlichen Informationen in den FPC-Anweisungen verbunden ist.

Zustimmungsgewicht (AW)

Das Genehmigungsgewicht einer Nachricht misst den prozentualen Anteil des aktiven Konsensmanas der Knoten, die eine Nachricht in ihrem zukünftigen Kegel (d. h. durch direkte oder indirekte Referenzierung) ausgegeben haben. Darüber hinaus wird das Genehmigungsgewicht so berechnet, dass das Konsensmana eines Knotens nicht auf das Genehmigungsgewicht von zwei konkurrierenden Transaktionen angerechnet werden kann. Nehmen wir zum Beispiel an, dass A und B kollidierende Transaktionen sind. Ich bin ein Knoten mit hohem Mana und gebe eine Nachricht heraus, die sich auf A bezieht, dann trägt mein Konsensmana zum Genehmigungsgewicht von A bei. Wenn ich jedoch später eine Nachricht herausgebe, die B genehmigt, dann wird mein Konsensmana vom Genehmigungsgewicht von A abgezogen und zu B hinzugefügt.

Wenn also das Zustimmungsgewicht von A größer als 50 % ist, dann wissen wir, dass das Zustimmungsgewicht von B kleiner als 50 % ist. Wir können also sagen, dass eine Nachricht (oder eine Transaktion) abgeschlossen ist, wenn ihr Zustimmungsgewicht größer als 50 % plus die Stärke eines potenziellen Angreifers ist.

AW war ursprünglich ein Kernpunkt von Hans‘ On Tangle Voting Vorschlag. In seinem Vorschlag würden die Knoten immer Tipps auswählen, die sich auf die Transaktionen mit dem höchsten Zustimmungsgewicht beziehen. Es ist jedoch nicht klar, ob dieser Vorschlag gut funktionieren würde, wenn das Zustimmungsgewicht zweier konkurrierender Transaktionen gleich ist, weshalb ein Element wie FPC erforderlich ist, das die Gleichheit aufhebt. Die Zustimmungsgewichtung ähnelt dem Konzept der kumulativen Gewichtung im ursprünglichen White Paper, wurde aber an eine Umgebung angepasst, in der wir Mana als Sybil-Schutzmechanismus verwenden.

Verbesserungen

Es ist wichtig zu bemerken, dass das aktuelle Protokoll nicht grundlegend mangelhaft ist. Tatsächlich hat der aktuelle IOTA 2.0 DevNet Konsensmechanismus, der auf FCoB und FPC basiert, hunderte von Konflikten in unserem Prototyp erfolgreich gelöst. Da wir uns jedoch das Ziel gesetzt haben, das beste DLT zu entwickeln, möchten wir die Leistung des Protokolls optimieren, indem wir die Komplexität des Codes, die Bestätigungszeit und den Kommunikations-Overhead minimieren.

Warum ist die Komplexität des Codes wichtig? Erstens: Je komplexer der Code ist, desto schwieriger ist es, ihn auf Fehler zu überprüfen, was zu Sicherheitsproblemen führen kann. Zweitens wollen die Entwickler auf etwas aufbauen, das sie verstehen können. Wenn die Node-Software einfacher gehalten wird, fördert dies die Akzeptanz.

Aus diesem Grund nehmen wir zwei Änderungen am Protokoll vor. Erstens wechseln wir von FPC zu dem, was wir On Tangle FPC (OTFPC) nennen. Wie bereits erwähnt, fragen wir bei FPC in jeder Runde Knoten im Netzwerk nach ihrer Meinung zu einer Transaktion ab und entscheiden anhand des Prozentsatzes der positiven Antworten und eines zufälligen Schwellenwerts, ob unsere Meinung in der nächsten Runde „gefällt mir“ oder „gefällt mir nicht“ lauten soll.

In OTFPC verwenden wir anstelle von direkten Abfragen die Zustimmungsgewichtung. Da die Knoten ihr Konsensmana nicht auf das Zustimmungsgewicht von zwei verschiedenen Konflikten setzen können, ist das Zustimmungsgewicht einer Abfrage sehr ähnlich, wobei die abgefragten Knoten im Wesentlichen diejenigen sind, die diese Nachricht referenziert haben. OTFPC arbeitet nach wie vor in Runden, wobei ein Knoten in jeder Runde anhand der Zustimmungsgewichtung und eines zufälligen Schwellenwerts entscheidet, welche Transaktionen er mag. Die gemochten Transaktionen bestimmen, welche Nachrichten für die Tipp-Auswahl in Frage kommen, und so erhalten nur gemochte Transaktionen ein Genehmigungsgewicht.

Mit OTFPC benötigen wir keinen Mechanismus für direkte Abfragen, sondern nutzen das Netzwerk selbst als einziges Kommunikationsmedium. Dadurch wird der Kommunikations-Overhead reduziert und die für den Betrieb eines Knotens erforderliche Bandbreite verringert.

Zweitens: Anstatt bei jeder Nachricht eine binäre Entscheidung zwischen „Ja“ und „Nein“ zu treffen, wählen die Knoten mittels FPC aus einer Liste konkurrierender Transaktionen einen Gewinner aus. Wir verwenden also ein Verfahren, das wir FPC on a set (FPCOS) nennen. Da OTFPCOS jedoch als Akronym nicht genießbar ist, lassen wir das OS weg.

Indem wir einen Gewinner wählen, befreien wir uns von der FCoB-Regel, der Regel, die anhand der Ankunftszeiten bestimmt, wen wir mögen. Im Gegensatz zu FCoB verwendet OTFPC keine Quarantänezeiten, die zu längeren Bestätigungszeiten führen könnten. Eingehende Nachrichten werden sofort zum Tipp-Set hinzugefügt, so dass jeder Knoten seine Präferenz ausdrücken und über die Tipp-Auswahl eine Stimme für eine bestimmte Transaktion innerhalb eines Konflikt-Sets abgeben kann. Wie beim Mechanismus der Genehmigungsgewichtung wird die lokale Präferenz eines Knotens durch die Konsens-Mana-Gewichtung bestimmt, die mit einer bestimmten konfliktbehafteten Transaktion über direkte und indirekte Verweise auf sie verbunden ist. Somit wird OTFPC die lokale Meinung eines Knotens zu einer bestimmten Transaktion besser an deren Genehmigungsgewicht anpassen, da es der gleichen Regel des schwersten Zweigs folgt. OTFPC sollte auch schneller handeln als FCoB. Außerdem sollte die Zufälligkeit von OTFPC das Auftreten von metastabilen Zuständen verhindern.

Wenn Sie mehr über OTFPC erfahren möchten, können Sie unseren iota.cafe-Beitrag lesen.

Es ist sehr wichtig zu betonen, dass sich dieser Ansatz nicht radikal von dem unterscheidet, was wir bisher gemacht haben. Obwohl FPC viel Aufmerksamkeit erhalten hat, war das Genehmigungsgewicht immer der Eckpfeiler des Protokolls. Außerdem wurde FPC (und sein Cousin FPC on a set) immer als mathematisches Modell ohne explizite Implementierung untersucht. Unsere Entwicklung ist einfach eine neue Implementierung dieses mathematischen Modells.

Alle Forschungen und Experimente, die mit FPC durchgeführt wurden, sind immer noch relevant, da FPC auf einer Menge nur eine Variante davon ist, mit dem Hauptunterschied, dass es bei einer Konfliktmenge immer einen Gewinner auswählt. Beide konvergieren in nur einer „glücklichen“ Runde zum Vorkonsens. Das Auftreten dieser Runde ist jedoch zufällig und erfolgt jedes Mal mit einer gleichmäßig positiven Wahrscheinlichkeit. Deshalb sind wir zuversichtlich, dass das FPCS mathematisch ebenso solide ist wie das FPC. Wir räumen jedoch ein, dass diese neuen Konzepte zwar recht einfach zu verstehen sind und in vielerlei Hinsicht dem, was wir bereits untersucht haben, grundlegend ähneln, dass sie aber noch nicht umfassend analysiert worden sind. Da der Teufel immer im Detail steckt, arbeiten wir weiter an der Verbesserung unserer Studien über ihr Verhalten bei verschiedenen Randfällen und Angriffen. Wie immer werden wir unsere Ergebnisse über unsere Medien, einschließlich akademischer Veröffentlichungen, verbreiten.

Wir freuen uns auf diese bevorstehenden Verbesserungen sowie auf weitere Upgrades für andere Komponenten, wie z. B. die Staukontrolle, an der wir derzeit arbeiten, und wir werden sie mit den nächsten Versionen schrittweise in das IOTA 2.0 DevNet integrieren.

Der weitere Weg

Leider werden die oben genannten Änderungen es unmöglich machen, den Coordicide im Jahr 2021 im IOTA-Mainnet bereitzustellen. Jede neue Idee, jeder neue Aspekt, jede neue Einsicht oder jede neue Gelegenheit durchläuft die zu Beginn dieses Artikels erwähnte Methodik. Das braucht Zeit: Exzellenz ist nicht schnell.

Diese Richtung einzuschlagen war eine schwere Entscheidung für uns und ist wahrscheinlich für einige eine Enttäuschung, und wir sind uns auch bewusst, dass unsere früheren Schätzungen zu ehrgeizig waren. Aber das ändert nichts an unserer Methodik, unserem Kurs und unserem Ziel: Die beste DLT aller Zeiten zu entwickeln. Letztendlich wären wir nachlässig, wenn wir das Protokoll nicht verbessern würden.

Die Lösungen, die wir entwickeln, sind zwar noch nicht fertig, werden aber bereits von einzelnen Entwicklern, Projekten und Industriepartnern eingesetzt. Wir haben das wunderbare Privileg, ein DLT geschaffen zu haben, das das Interesse eines riesigen Ökosystems von globalen, führenden Industrieakteuren, Regierungen, einzelnen Entwicklern und einer Gemeinschaft geweckt hat, denen gegenüber wir die Verantwortung haben, ein zuverlässiges und sicheres Netzwerk zu liefern, auf dem wir mit minimalen Änderungen auf dem Weg aufbauen können.

Das bedeutet auch, dass wir keine Abkürzungen nehmen werden, um den Zeitplan einzuhalten, indem wir eine technische Lösung durchsetzen, die wir ohnehin irgendwann ändern wollen. Unsere Loyalität gilt denjenigen, die uns dabei helfen, die Vision von IOTA Wirklichkeit werden zu lassen: unserer Gemeinschaft von Erbauern und Machern, öffentlichen und Unternehmenspartnern, die sich auf unsere Software verlassen und uns helfen, damit Branchenlösungen zu entwickeln. Sie sind eher an der bestmöglichen Lösung interessiert, als an der schnellsten, aber mittelmäßigen Lösung, die möglicherweise später Änderungen nach sich zieht. Deshalb konzentrieren wir uns auf diejenigen, die mitmachen, beitragen und bauen und die uns helfen, das Potenzial von IOTA auszuschöpfen. Sie sind es, die den Erfolg von IOTA bestimmen werden, von dem letztendlich alle profitieren werden.

Wenn Sie ein Entwickler sind, dann schauen Sie nur auf unsere Repos und den Entwicklungsfortschritt, und Sie werden im Voraus wissen, wann der Coordicide stattfinden wird. Bis dahin haben wir gemeinsam mit dem IOTA 2.0 DevNet noch eine Menge zu erreichen.

Original by William Sanders: https://blog.iota.org/improvements-to-the-iota-2-0-consensus-mechanism/

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

Coordicide Förderungsreport – Zelluläre Automaten in IOTA

Im Mai dieses Jahres kündigten wir einen Coordicide-Zuschuss zur Untersuchung von Zellularautomaten als mögliche Erweiterung des Konsensmechanismus der IOTA in zukünftigen Versionen des Protokolls an. Heute freuen wir uns, die Ergebnisse dieser Forschung mit Ihnen zu teilen. Dr. André Vilela und Dr. Kenric Nelson untersuchten die dynamischen Eigenschaften der Konsens-Algorithmen von Zellularautomaten (CA). „Coordicide Förderungsreport – Zelluläre Automaten in IOTA“ weiterlesen

IOTA 2.0: Einführung von Pollen, Nektar und Honig

Original by IOTA Foundation: https://blog.iota.org/iota-2-0-introducing-pollen-nectar-and-honey-de7b9c4c8199(29.06.2020)

Bis jetzt haben wir eine Menge Namen und Begriffe für die eventuelle Entfernung des Koordinatorknotens im Umlauf gehabt:

  • Alphanet, der Name des ersten Prototyps unseres dezentralisierten Testnetzes.
  • Goshimmer, die Gruppe von Technologien, die entwickelt werden, um den Koordinator zu entfernen.
  • Coordicide, der Name der Veranstaltung, bei der wir den Koordinator entfernen

In den letzten Monaten haben wir unsere Namenskonventionen von IOTA 1.5 (Chrysalis, die Zwischenstufe des Hauptnetzes vor Coordicide) und IOTA 2.0 (Coordicide, die dauerhafte Entfernung des Koordinatorknotens und die Einführung eines vollständig dezentralisierten IOTA-Netzwerks) vereinfacht, um den nahtlosen Übergang zwischen diesen beiden wichtigen Protokoll-Upgrades und die Art und Weise zu zeigen, wie sie schließlich zu einem koordinatorenlosen, skalierbaren und gefühllosen Netzwerk führen werden. Das erste seiner Art.

IOTA 2.0

Diese aktualisierten Nomenklaturen helfen unserer Gemeinschaft und unseren Partnern auch dabei, den bevorstehenden technologischen Fortschritt für die IOTA besser zu verstehen und zu quantifizieren. Unser Ziel ist es, eine klare Unterscheidung und Verbindung zwischen den Arbeiten herzustellen, die in den kommenden Monaten diese beiden bedeutenden Protokoll-Upgrades miteinander verbinden werden.

In diesem Sinne freuen wir uns, Ihnen heute die drei Phasen von IOTA 2.0 vorzustellen, die wichtige Meilensteine und Testnetzveröffentlichungen im Vorfeld von Coordicide widerspiegeln werden. In Anlehnung an die aktuellen Apoidea-Namenskonventionen, die für Hornet, Bee und HoneycombOS verwendet werden, sind die drei Phasen nach den drei wichtigsten Meilensteinen für die Erzeugung von Honig benannt: Pollen, Nektar und Honig.

IOTA 2.0 Pollen

Pollen

Als erstes offizielles Testnet des IOTA 2.0-Netzwerks stellt Pollen eine wesentliche Änderung gegenüber der vorherigen Version GoShimmer v0.1.3 dar und bildet die Grundlage für das erste und funktionsfähige Netzwerk ohne Koordinator. Iterative Verbesserungen werden Pollen in den endgültigen, funktionsreichen Release-Kandidaten für IOTA 2.0 verwandeln. Das Pollen-Netzwerk wird in erster Linie ein Forschungs-Testbett für die Stiftung, die Gemeinschaft und externe Forscher sein, um Konzepte aus den Coordicide-Weißbüchern zu validieren und bestimmte Angriffsvektoren zu simulieren. Während dieser aktiven Forschungsphase werden viele der Coordicide-Spezifikationen vollständig fertiggestellt werden, so dass wir den endgültigen Entwurf von IOTA 2.0 erhalten.

IOTA 2.0 Nectar

Nectar

Voraussichtlich in der zweiten Hälfte des Jahres 2020 wird Nectar eine vollständige Umsetzung unserer Koordizid-Module auf einem Testnetz mit Anreizen sein. Ziel dieses Netzwerks ist es, auf Fehler oder Probleme zu testen, die vor der endgültigen Veröffentlichung des Hauptnetzes behoben werden müssen. Wie der Name bereits erwähnt, werden die Teilnehmer an diesem Netzwerk mit progressiv steigenden Belohnungen dafür belohnt, Fehler oder Angriffsvektoren zu finden.

IOTA 2.0 Honey

Honig

Der endgültige Release Kandidat für IOTA 2.0, Honey, wird alle Module gemäß der vollständigen und endgültigen Spezifikation von Coordicide enthalten. Zu diesem Zeitpunkt wird das Netzwerk kampferprobt und durch viele Hunderte von Teststunden mit vollständigen Audits unserer Knotenpunkt-Software gesichert sein. Honey kann als die erste Version von IOTA 2.0, unserem vollständig dezentralisierten IOTA-Mainnet, betrachtet werden.

Uns gefällt diese Analogie zu Honig und Honigbienen, weil Bienen als ein komplexes Team arbeiten und ein integraler Bestandteil eines hochentwickelten, natürlichen Ökosystems sind, das die Grundlage für das Leben, wie wir es kennen, bildet. In ähnlicher Weise besteht das IOTA-Netzwerk aus einer großen Gemeinschaft von Mitwirkenden, die mit dem Ziel zusammengebracht wurden, eine neue Art von fairer, quelloffener und verteilter Gesellschaft zu schaffen.

Wir hoffen, dass diese neuen Namenskonventionen es leichter machen, den Fortschritt von Pollen zu Honig in den kommenden Monaten zu verfolgen!

Ein Leitfaden zur bevorstehenden IOTA 2.0 (Koordizid)-Terminologie

Original by William Sanders: https://blog.iota.org/a-guide-to-upcoming-iota-2-0-coordicide-terminology-856872d7bbfc (29.05.2020)

Da die Koordizid-Spezifikationen kurz vor der Fertigstellung stehen, hat die Forschungsabteilung die Einzelheiten des neuen Protokolls an die technische Abteilung, externe Forscher und die Gemeinschaft kommuniziert. Diese Kommunikation erfordert eine einfache und einheitliche Terminologie für die neuen Komponenten. Bis vor kurzem haben Forscher, darunter auch ich, jedoch hauptsächlich potenziell verwirrende „in house“- und Ad-hoc-Namen verwendet.
Daher begannen mehrere Forscher und Ingenieure damit, eine angemessene Terminologie zu entwickeln. Kürzlich haben wir diese Aufgabe abgeschlossen und möchten diese Namen in diesem Blogbeitrag mit Ihnen teilen.
Das neue IOTA-Protokoll ist in drei Schichten unterteilt: die Netzwerk-, die Kommunikations- und die Anwendungsschicht. Es gibt Parallelen zwischen unseren Schichten und den oberen Schichten des OSI-Modells, obwohl wir den Leser vor tiefgreifenden Vergleichen warnen. Die Netzwerkschicht verwaltet die Verbindungen und Paketübertragungen zwischen den Knoten. Die Kommunikationsschicht schafft eine standardisierte Plattform für die Speicherung und Kommunikation von Informationen. Den Entwicklern steht es dann frei, dezentralisierte Anwendungen auf der Anwendungsschicht zu entwerfen und gleichzeitig die unteren Schichten zu abstrahieren.

Die Netzwerkschicht (Network Layer)

Diese Schicht verwaltet die unteren Schichten der Internet-Kommunikation wie TCP. Sie ist die technischste und in gewisser Weise die uninteressanteste. In dieser Schicht werden die Verbindungen zwischen den Knoten durch die Autopeering- und Peer-Discovery-Module und das Klatschprotokoll verwaltet.

Die Kommunikationsschicht (Communication Layer)

Diese Schicht speichert und kommuniziert Informationen. Diese Schicht enthält das „verteilte Ledger“ oder das Gewirr. Die Kurssteuerung und Zeitstempel befinden sich ebenfalls in dieser Schicht.
In der Kommunikationsschicht sehen wir viele neue Funktionen des Protokolls. Zunächst wird unser Signatur-„Gewirr“ in „Nachrichtengewirr“ umbenannt, und Objekte, die Nachrichten genannt werden, ersetzen Transaktionen und Bündel. Nachrichten haben ein flexibles Format von variabler Größe, die effizienter sind als Bündel von Transaktionen fester Größe. Außerdem werden wir die Bezeichnungen „Stamm und Zweig“ abschaffen: Jede Nachricht verweist auf zwei andere Nachrichten, die wir jetzt die Eltern nennen.
Die Nachrichten werden von einem Knoten ausgegeben und dann auf der Netzwerkschicht geklatscht. Neben den Hashes der Eltern enthält eine Nachricht bestimmte Ausgabeinformationen (Ausgabeknoten-ID, Zeitstempel usw.), eine Nutzlast, die die Daten enthält (mehr dazu später), und die Signatur des Ausgabeknotens.
Coordicide communication layer
Der Begriff „Nachricht“ wurde gewählt, um den Begriff „Transaktion“ zu ersetzen, da das IOTA-Protokoll nicht nur eine Anwendung zur Übertragung von Werten ist, sondern eine Plattform zur sicheren Speicherung und Übertragung von Daten.

Die Anwendungsschicht (Application Layer)

Das IOTA-Protokoll ermöglicht die Ausführung einer Vielzahl von Anwendungen auf dem Nachrichtengewirr. Jeder kann eine Anwendung entwerfen, und die Benutzer können entscheiden, welche Anwendungen auf ihren Knoten ausgeführt werden sollen. Diese Anwendungen werden alle die Kommunikationsschicht zum Senden und Speichern von Daten verwenden.
Jeder Knoten wird jedoch bestimmte Kernanwendungen ausführen müssen, die für den Betrieb des Protokolls erforderlich sind. Dazu gehören zum Beispiel:
  • Die Wertübertragungsanwendung
  • Der verteilte Zufallszahlengenerator (kurz DRNG)
  • Das Fast Probabilistic Consensus (FPC)-Protokoll

Diese Anwendungen pflegen den Ledgerstatus, und andere Anwendungen können ebenfalls auf diesen Anwendungen arbeiten.

Anwendungen lesen und erstellen Nachrichten-Payloads, die auf der Kommunikationsschicht gespeichert sind. Wir entwickeln einen flexiblen Rahmen, um diese Interaktion zu vermitteln.

Objekte (Objects)

Die Grundeinheit der Daten im IOTA-Protokoll wird als Objekt bezeichnet. Jedes Objekt hat einen Typ und eine Größe. Der Typ ist in einem Schema genau definiert und gibt an, welche Felder das Objekt enthält und wie sie angeordnet sind. Der Typ bestimmt auch, wie ein Knoten das Objekt parst.
Nachricht ist ein Objekttyp. Ein weiteres Beispiel ist das generische Datenobjekt, bei dem es sich, wie der Name schon sagt, nur um Daten handelt. Jeder Knoten führt eine Liste der Objekttypen, die er erkennt und zu parsen weiß.
Wie bei Nachrichten können Objekte ein Nutzlastfeld enthalten. Eine Payload muss immer mit einem anderen Objekt gefüllt werden. Beim Parsen eines Objekts parst ein Knoten seine Nutzlast entsprechend seinem Typ. Wenn der Knoten den Typ nicht kennt, behandelt er die Payload wie ein generisches Datenobjekt. Ein Objekttyp kann verlangen, dass eine Payload einen bestimmten Typ hat. Über Payloads können Objekte ineinander verschachtelt werden, wodurch eine sehr flexible Plattform entsteht.
Um im Message-Gewirr zu klatschen und gespeichert werden zu können, muss jedes Objekt innerhalb einer Message gekapselt werden, entweder direkt als Payload oder indirekt als Payload eines anderen Objekts. Informell kann eine Nachricht mit dem Nutzlasttyp X als X-Nachricht bezeichnet werden.
Beispielsweise kann eine Lieferkettenanwendung einen Objekttyp namens „Zustellung“ definieren. Die Nutzlast eines Zustellobjekts könnte zwei verschiedene Objekttypen unterstützen: Paket und Empfang. Beim Senden eines Pakets kann ein Benutzer eine Zustellnachricht (eine Nachricht mit einem Zustellobjekt) ausgeben, die ein Paketobjekt enthält, das das Paket beschreibt. Jedes Mal, wenn jemand das Paket empfängt, kann er eine Zustellnachricht mit einem Empfangsobjekt ausgeben, das den Hash des Paketobjekts auflistet.
deutsch iota update
Jeder, der die Auslieferungsanwendung nicht verwendet, könnte einfach alle Auslieferungsobjekte als generische Daten behandeln.
Allerdings muß jeder bestimmte Kernobjekttypen erkennen, die von den Kernanwendungen verwendet werden. Zu den Kernobjekttypen gehören:
  • Wert-Objekte
  • Einwände gegen FPC-Stellungnahme
  • DRNG-Objekte
  • Salzdeklaration-Objekte
  • Generische Datenobjekte

Wie bereits erwähnt, können Nachrichten, die diese Objekte enthalten, jeweils als Wertnachrichten, FPC-Nachrichten usw. bezeichnet werden.
Alle Objekttypen enthalten eine Versionsnummer, so dass jede Anwendung aktualisiert werden kann. Die Versionsnummer einer Meldung gibt an, welche Version des IOTA-Protokolls die Meldung verwendet. Wir gehen davon aus, dass es das IOTA-Protokoll noch eine Weile geben wird und sich wahrscheinlich von Zeit zu Zeit ändern wird. Anhand der Versionsnummern können die Knoten die Interoperabilität zwischen diesen verschiedenen Versionen verwalten.

Die Wertübertragungsanwendung (Value Transfer Application)

Die wichtigste Kernanwendung ist die Werttransferanwendung, die Mittel bewegt und den Ledgerstand aktualisiert. Diese Anwendung verwendet Wertobjekte. Jedes Wertobjekt referenziert zwei andere Wertobjekte, und so bilden Wertobjekte ein zusätzliches Dreieck über dem Nachrichten-Dreieck, das so genannte Werte-Dreieck.

In diesem Werte-Wirrwarr stellen die Referenzen eine „Genehmigung“ dar und zeichnen die Ergebnisse der FPC-Abstimmungen auf. Grob gesagt werden alle von FPC abgelehnten Wertobjekte im Werte-Wirrwarr verwaist. Wir trennen das Wert- und das Nachrichten-Wirrwarr, um die unschuldigen Daten zu reduzieren, die in diesem Prozess verloren gehen.

Jedes Wertobjekt hat eine Nutzlast, die nur einen Objekttyp namens Transaktion unterstützt. Eine Transaktion enthält die Input-Transaktionen, die Output-Adressen und Salden, den Mana-Empfänger, eine Nutzlast und eine Signatur. Da wir ein UTXO-Schema verwenden, macht der Begriff Transaktion Sinn: UTXO steht für Nicht ausgegebene (TX) Transaktions-Ausgabe.

iota value transaction deutsch

Die Nutzlast einer Transaktion kann eine Vielzahl von Objekttypen wie z.B. intelligente Verträge unterstützen. Da die Nutzlast unterzeichnet wird, ist sie grundsätzlich Teil der Transaktion. Nach dem UTXO-Schema kommt es zu Konflikten zwischen verschiedenen Transaktionen, die die gleichen Inputs verbrauchen. Daher kommt es zu Konflikten zwischen zwei ansonsten identischen Transaktionen, wenn sie unterschiedliche Nutzlasten haben. Die Nutzlast ist also inhärent an die Ausgaben gebunden. Diese Funktionalität ermöglicht eine Vielzahl von Anwendungen, die auf der Wertübertragungsanwendung aufbauen.

Betrachten Sie das Beispiel der Lieferanwendung. Wenn der Empfänger für das gelieferte Paket zahlen muss, könnte das Empfangsobjekt in der Payload der Zahlungstransaktion enthalten sein. Dann würde der Zahlungsbeleg den Zustellnachweis enthalten, und entweder sind beide oder keiner von beiden in dem Gewirr enthalten.

Glossar der Begriffe

Wir nehmen nun ein Glossar der neuen Definitionen in dieses Dokument auf.

  • Anwendungsschicht: Die oberste Schicht, die alle Anwendungen beherbergt
  • Kern-Anwendung: Eine Anwendung, die von allen Benutzern ausgeführt werden muss
  • Kommunikationsschicht: Die Schicht, die sich mit Nachrichten und dem Nachrichtengewirr befasst
  • Kern-Objekttyp: Ein Objekttyp, der von allen Benutzern geparst werden muß
  • Generisches Datenobjekt: Der grundlegendste Objekttyp. Alle nicht erkannten Datenobjekte werden so behandelt
  • Netzwerkschicht: Die grundlegendste Schicht, die die Verbindungen und den Klatsch zwischen Nachbarn verwaltet
  • Nachricht: Der Objekttyp, über den zwischen Nachbarn getratscht wird. Alle geklatschten Informationen sind in einer Nachricht enthalten
  • Nachrichten-Verwirrung: Die Sammlung aller Nachrichten
  • Objekt: Die grundlegendste Informationseinheit des IOTA-Protokolls. Jedes Objekt hat einen Typ und eine Größe und enthält Daten
  • Nutzlast: Ein Feld in einem Objekt, das nur von einem anderen Objekt gefüllt werden kann
  • Verwicklung: Eine Append only-Datenstruktur, bei der jedes Objekt auf zwei andere Objekte verweist
  • Transaktion: Die Payload eines Wertobjekts. Sie enthält die Angaben zu einem Geldtransfer
  • Wertobjekt: Das Grundobjekt der Wertübertragungsanwendung
  • Werteverwirrung: Die Sammlung aller Wertobjekte
  • Wertübertragungsanwendung: Die Anwendung, die den Zustand des Ledgers aufrechterhält
  • Versionsnummer: Gibt das korrekte Format jedes Typs an

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.

 

Eine Einführung in IOTA Smart Contracts

Original by Evaldas Drasutis: https://blog.iota.org/an-introduction-to-iota-smart-contracts-16ea6f247936 (06.05.2020)

Ich möchte mich bei meinen Kollegen in der IOTA-Stiftung bedanken, die Beiträge und Feedback zu diesem Artikel geliefert haben. Insbesondere Eric Hop, der das Qubic-Projekt leitete und jetzt zu IOTA Smart Contracts gehört, und Jake Cahill, der für den größten Teil des Wortlauts verantwortlich ist.

IOTA Smart Contracts ist eine fortlaufende Bemühung der IOTA Foundation. Das Ziel dieses Artikels ist es, die Gemeinschaft darüber zu informieren, was wir tun und wohin wir mit IOTA Smart Contracts gehen. Er bietet auch eine Gelegenheit für die Gemeinschaft, mit Fragen und Feedback zum Projekt beizutragen.

Hintergrund

Kürzlich stellte Eric Hop das Qubic-Projekt in seinem Artikel The State of Qubic vor und erläuterte unsere Entscheidung, uns vorerst ausschließlich auf intelligente Verträge zu konzentrieren. Natürlich warfen diese Entwicklungen viele Fragen aus der Gemeinschaft auf, wie sich die intelligenten Verträge der IOTA zu Qubics Vision verhalten.

Der vorliegende Artikel wird diese Fragen beantworten, indem er einen Kontext und eine technische Einführung zu den IOTA Smart Contracts bietet. Obwohl viele Aspekte der IOTA Smart Contracts vom Qubic-Projekt abgeleitet wurden, handelt es sich in vielerlei Hinsicht um ein eigenständiges, eigenständiges Projekt. Wir glauben, dass die Richtung, die wir einschlagen, viel Potenzial hat, und wir unternehmen jetzt die notwendigen Schritte, um dieses Potenzial in der Praxis unter Beweis zu stellen.

Was ist ein Vertrag?

Bevor wir einen intelligenten Vertrag definieren, ist es wichtig, zunächst zu verstehen, was ein legaler Vertrag ist.

Juristische Verträge sind nicht-deterministische Vereinbarungen, die komplexen Rechtssystemen unterliegen. Die Gesetze, die Verträge umgeben, variieren in Abhängigkeit von einer Reihe von Faktoren, wie zum Beispiel dem Land, in dem alle Parteien den Vertrag abgeschlossen haben. Das wichtigste Wort ist hier „nicht-deterministisch“. Das bedeutet, dass Verträge oft mehrdeutig sind, und ihre subjektive Auslegung kann zu Streitigkeiten führen.

Was ist ein Intelligenter Vertrag?

Im Gegensatz dazu ist ein intelligenter Vertrag eine programmierte Vereinbarung, die völlig deterministisch ist und automatisch durchgesetzt wird. Dies macht es unmöglich, zu streiten.

Das Konzept eines intelligenten Vertrags wurde von Nick Szabo in den 90er Jahren in seiner Abhandlung mit dem Titel „Forming and Securing Relationships on Public Networks“ (Beziehungen in öffentlichen Netzwerken bilden und sichern) erfunden. In diesem Papier stellte er sich Vertragsregeln vor, die als Computercode kodiert sind.

Ein intelligenter Vertrag könnte zum Beispiel für die folgende Vereinbarung programmiert werden:

Wenn Flug F mehr als 3 Stunden Verspätung hat, dann zahlen Sie den Versicherungsbetrag A auf das Konto von Alice.

„Der Flug hat Verspätung“ ist eine Bedingung der Vereinbarung, und „Versicherungsbetrag A an Alice zahlen“ ist eine Folge dieser Bedingung.

Die Folgen der Ausführung eines intelligenten Vertrags hängen von einer Reihe von Bedingungen ab, die wir seinen Zustand nennen.

Der Zustand eines intelligenten Vertrags kann zum Beispiel umfassen

  • Flug F: Pünktlichkeit
  • Das Konto von Alice: 0
  • Intelligentes Vertragskonto: 1000
  • Deckungssumme: 100
  • Ausbezahlt: Falsch

Der Status eines intelligenten Vertrags wird in einem verteilten Ledger veröffentlicht. Wenn eine Aktualisierung erfolgt und das Netzwerk einen Konsens über die Änderung erzielt, wird eine neue Transaktion an das Ledger angehängt, um den Status des Vertrags zu aktualisieren:

Flug F: Verspätet (ein Verweis auf eine andere Transaktion mit Nachweis der Verspätung)

  • Das Konto von Alice: 100
  • Intelligentes Vertragskonto: 900
  • Deckungssumme: 100
  • Ausbezahlt: Wahr

Intelligente Verträge hinterlassen einen unveränderlichen Prüfpfad auf dem verteilten Ledger, und ihre Automatisierung spart Zeit und Geld für die beteiligten Parteien. Das Konzept ist einfach und lässt sich in nahezu jeder Branche in einer Vielzahl interessanter Anwendungsfälle anwenden, von der Verfolgung von Waren in der gesamten Lieferkette bis hin zum Austausch von Eigentum an Aktien und Anleihen. Intelligente Verträge sind jedoch eine aufstrebende Technologie. Es bleibt eine offene Frage, wie sie sich in den bestehenden Rechtsrahmen einfügen werden, und es ist noch einiges zu tun, bevor sie ihr volles Potenzial erreichen.

Arten von intelligenten Verträgen

Schicht 1 („On-Chain“)
Intelligente „On-Chain“-Verträge, wie die auf Ethereum, sind Teil des Kernprotokolls. Das bedeutet, dass sie von allen Knoten im Netzwerk ausgeführt und validiert werden.

Vorteile

  • Die Sicherheit von intelligenten Verträgen ist proportional zur Größe des Netzwerks
  • Intelligente Verträge können Tokens von ihrem Konto übertragen, ohne eine Unterschrift zu leisten

Nachteile

  • Intelligente Verträge skalieren schlecht, weil ihre Programme von allen Knoten ausgeführt werden müssen
  • Intelligente Verträge unterliegen Netztransaktionsgebühren, die ebenso volatil sind wie der zugrunde liegende symbolische Preis.
  • Die durchschnittlichen Kosten eines intelligenten Vertragsabschlusses sind ungefähr proportional zum zugrunde liegenden symbolischen Preis

Schicht 2 („Off-Chain“)
„Off-chain“ intelligente Verträge werden außerhalb des Kernprotokolls ausgeführt. Nur eine Untergruppe von Knoten, ein so genannter Ausschuss, muss sie ausführen, und ein Konsens kann außerhalb des Kernprotokolls erreicht werden.

Vorteile

  • Intelligente Verträge belasten den Rest des Netzwerks nicht
  • Die durchschnittlichen Kosten für eine intelligente Vertragsabwicklung sind niedrig und vorhersehbar
  • Der notwendige Grad der Dezentralisierung (und damit die Sicherheit) eines intelligenten Vertrags kann an jeden Anwendungsfall angepasst werden.

Nachteile

  • Um Token zu übertragen, müssen intelligente Vertragsprogramme Transaktionen unterzeichnen, um nachzuweisen, dass sie Zugriff auf die Kontoadresse haben.
  • Die Dezentralisierung (und damit die Sicherheit) intelligenter Verträge hängt von der Größe des Ausschusses, den Ausschussmitgliedern und der Stelle ab, die den Ausschuss einsetzt.

Warum braucht die IOTA intelligente Verträge?

Intelligente Verträge sind in vielen Bereichen von IOTA unverzichtbar, darunter Supply Chain, Smart Cities, Industrial IoT und andere. Intelligente IOTA-Verträge können Vertragsverpflichtungen innerhalb dieser Branchen automatisieren.
Im Vergleich zu ihren Blockchain-Pendants haben IOTA Smart-Contracts dank der Tangle-Eigenschaften wie Skalierbarkeit, hoher Durchsatz und Gebührenfreie Transaktionen viele Vorteile.

Wie funktionieren intelligente Verträge in IOTA?

IOTA Smart Contracts werden als unveränderliche Zustandsmaschinen definiert:

  • Zustandsmaschine: Jeder intelligente Vertrag hat einen Zustand, der mit dem Tangle verbunden ist. Der Zustand enthält Daten wie Kontostände, Eingabebedingungen und Konsequenzen im Laufe der Zeit. Jede Zustandsaktualisierung stellt einen Zustandsübergang auf dem Tangle dar.
  • Unveränderlich: Der Zustand und der Programmcode des intelligenten Vertrags sind beide unveränderlich, da sie auf dem Tangle gespeichert sind. Der Zustand kann inkrementell aktualisiert werden, indem neue Transaktionen an das Tangle angehängt werden.

Der Tangle bietet einen verifizierbaren Prüfpfad der Zustandsübergänge. Dadurch können wir darauf vertrauen, dass die Zustandsübergänge gültig sind und nicht durch böswillige oder fehlerhafte Knoten verfälscht werden können.

Der Fall für intelligente Layer-2-Verträge

Um die Anwendungsfälle der IOTA, einschließlich des Internet der Dinge, zu erleichtern, bauen wir intelligente IOTA-Verträge auf Schicht 2, „off-Tangle“.

Obwohl die „on-chain“ intelligenten Verträge von Ethereum aufgrund ihrer Eigenschaften beliebt sind, haben sie einige bedeutende Nachteile. Der hervorstechendste ist, dass jeder Knotenpunkt für jeden intelligenten Vertrag, der existiert, eine Kopie des Programmcodes und -status des Vertrags behalten muss. Jeder Knoten im Netzwerk muss genau den gleichen Code ausführen, wenn der Smart-Vertrag ausgelöst wird.

Es gibt keine Begrenzung der Anzahl der Knoten, die diesen identischen Code ausführen müssen, nur um ein einziges Ergebnis zu erzeugen. Und je größer das Netzwerk wird, desto mehr Verarbeitung ist erforderlich, um dasselbe Ergebnis zu erzielen. Dies stellt ein enormes Hindernis für die Skalierbarkeit dar.

Zusätzlich zu den Transaktionsgebühren, die Sie zahlen müssen, um für die Aufnahme in das Hauptbuch in Betracht gezogen zu werden, müssen Sie auch Gasgebühren zahlen, um das Programm lange genug laufen zu lassen, damit es abgeschlossen werden kann. Das bedeutet, dass die Kosten für den Betrieb dieser intelligenten Verträge unerschwinglich hoch werden, wenn man von bestimmten Anwendungsfällen absieht, in denen der Kostenaufwand relativ unbedeutend ist.
Aus diesem Grund werden IOTA Smart-Contracts nicht als Teil des Kernprotokolls implementiert, sondern als ein Layer-2-Protokoll.

Infolgedessen bieten IOTA Smart-Contracts eine natürlichere Art und Weise, verteilte Berechnungen auszuführen. Jeder Smart-Contract kann in einem lokalisierten Kontext ausgeführt werden, ohne dass das gesamte Netzwerk zur Ausführung gezwungen wird. Dies bedeutet auch, dass IOTA Smart-Contracts in Zukunft nicht zu einem Hindernis für die Skalierung des IOTA-Netzwerks mit Sharing-Lösungen werden.

Der Eigentümer eines intelligenten Vertrags

Jeder Smart-Vertrag hat einen Eigentümer, der für ihn verantwortlich ist:

  • Das smart contract-Programm zu erstellen und beim Netzwerk einzureichen
  • Festlegung der Größe des Komitees (die Zahl N) und die Auswahl der Netzwerkknoten, die Teil des Komitees sein sollen
  • Entscheidung, wie viele Ausschussknoten einen Konsens über Aktualisierungen des Smart Contract-Status erreichen müssen. Diese Zahl wird als Quorum bezeichnet
  • Festlegung anderer allgemeiner Konfigurationsparameter des Smart-Vertrags

Ein Eigentümer kann eine einzelne Einheit sein, z. B. eine Organisation oder eine Person, oder es kann sich um eine dezentralisierte Sammlung von Peers handeln, z. B. ein Konsortium von Organisationen. In jedem Fall verwaltet der Eigner nur die Einrichtung und Konfiguration des Smart-Vertrags und nimmt nicht an dessen Betrieb teil.

Der Eigentümer kann je nach Kontext und Zweck wählen, wie intelligente Verträge eingerichtet werden sollen. Beispielsweise kann ein intelligenter Vertrag, der hochwertige Transaktionen abwickelt, einen großen Ausschuss von Knoten erfordern. Während ein intelligenter Vertrag, der Mikrotransaktionen abwickelt, unter Umständen nur 20-30 Knoten im Ausschuss benötigt.

Motivationen: Belohnungen und Reputation

Es gibt viele mögliche Gründe, einen intelligenten Vertrag zu erstellen oder zu betreiben. Ein Grund ist die Belohnung.

Obwohl IOTA-Transaktionen Gebührenfrei sind, bieten intelligente IOTA-Verträge den Unternehmen die Möglichkeit, eine Gebühr in IOTA-Tokens zu verlangen, z.B. zur Deckung der Betriebskosten. Wir nennen diese Gebühr eine Belohnung.

Sowohl Eigentümer als auch Ausschussknotenpunkte können intelligente Vertragsbelohnungen erhalten. Es ist Sache des Eigentümers, mit den Betreibern von Komitee-Knotenpunkten zu verhandeln, um die minimal akzeptable Belohnung festzulegen.

  • Ausschussknoten können Belohnungen erhalten, indem sie einen bestimmten intelligenten Vertrag bearbeiten, der eine Belohnung bietet
  • Eigentümer haben auch die Möglichkeit, intelligente Verträge zu erstellen, die dem Eigentümer einen Prozentsatz der Belohnung zukommen lassen.

Eine weitere potenzielle Motivation für die Mitgliedschaft in einem Ausschuss ist der Aufbau eines guten Rufs. Kluge Vertragsinhaber können sich dafür entscheiden, Ausschüsse nur aus Knotenpunkten mit einem guten Ruf zu bilden.
Diese Art von Reputationssystem könnte einen offenen Markt für Ausschussknoten schaffen, der gutes Verhalten im Netzwerk fördert.

Das Smart Contract Programm

Ein intelligentes Vertragsprogramm ist ein Algorithmus, der Anweisungen für eine virtuelle Maschine (VM) enthält. Wir werden WebAssembly (WASM) als Haupt-VM für IOTA Smart Contracts verwenden. Aber im Allgemeinen kann die VM in jeder Sprache oder sogar fest in der Software des Knotens programmiert sein.

Das Programm nimmt zwei Transaktionen als Input: die Anfragetransaktion und die Transaktion des aktuellen Status. Die Transaktion des nächsten Zustands verweist immer auf die Anfragetransaktion und die Transaktion des vorherigen Zustands. Auf diese Weise verfügt das intelligente Vertragsprogramm über eine deterministische Methode zum Aufbau einer Kette von Zustandsaktualisierungen, die durch eingehende Anfragen ausgelöst werden.

Der Hash des Programms wird im Tangle gespeichert und ist daher unveränderlich.
(Hinweis: Intelligente IOTA-Verträge werden durch eine Transaktion und nicht durch ein Bündel definiert, da wir sie im IOTA-Protokoll nach dem IOTA-Koordizid implementieren, das ein UTXO-Modell für Werttransaktionen verwendet)

Ein Beispiel für ein intelligentes Vertragsprogramm

Es folgt eine kurze Beschreibung des intelligenten FairRoulette-Vertrags: unser interner PoC, den wir für Tests verwenden.

Betrachten Sie einen Smart-Vertrag, der Wetten auf ein Rouletterad annimmt. Der Smart-Vertrag würde in seinem Konto gestapelte IOTA-Münzen sowie Daten über jede platzierte Wette (Summe, Farbe, Spieler) enthalten. Letzteres wird für Auszahlungen an die Gewinner von Roulette-Spielen benötigt.

Um eine Wette zu platzieren, senden Sie eine Antragstransaktion an den Smart-Vertrag. Die Transaktion würde enthalten:

  • Eine Gebührenzahlung von IOTA-Marken für die Bearbeitungskosten
  • Eine Einzahlung von IOTA-Münzen, die Sie setzen möchten
  • Die Farbe, auf die Sie wetten

Wenn die Komitee-Knotenpunkte dann diese Transaktion sehen, werden sie das Programm des intelligenten Vertrags ausführen, um den Status mit Ihrer Wette zu aktualisieren.

Die Auszahlung an die Gewinner wird nach Spielende automatisch gemäß dem Programm des Smart-Vertrags ausgeführt.

Der Ausschuss und das Quorum

Die Kontoadresse des Smart-Vertrags ist Eigentum des Ausschusses. Diese Adresse enthält die hinterlegten IOTA-Marken. Nur ein Quorum von Ausschussknoten ist in der Lage, Tokens von der Adresse weg zu übertragen. Mit anderen Worten, ein Quorum von Ausschussknoten muss zusammenarbeiten, um IOTA-Marken vom Konto zu entfernen.

Wir verwenden BLS-Adressen mit mehreren Unterschriften, um den Ausschussknoten das gleiche Eigentumsrecht an der Adresse zu geben. Diese Adressen ermöglichen Schwellenunterschriften, was bedeutet, dass eine bestimmte Anzahl von Knoten im Ausschuss, das Quorum, dieselbe Transaktion mit ihrem geheimen Schlüssel unterschreiben muss, um eine gültige Unterschrift zu erzeugen und somit den Zustand des Smart-Vertrags zu aktualisieren und die vom Smart-Vertrag kontrollierten Mittel zu bewegen.

Wie intelligente Verträge erstellt werden

Der Eigentümer eines Smart-Vertrags erstellt das Programm, und sein Binärcode wird in Ausschussknoten gespeichert. Der Hash des Programms ist durch die staatliche Transaktion immer zugänglich, so dass der Smart-Vertrag unveränderlich ist.

Der Eigentümer setzt einen Ausschuss von Knotenpunkten ein, die für die Ausführung des Programms, das Abhören des Tangle für Anfragetransaktionen und die kollektive Aktualisierung des Zustands des Smart-Vertrags verantwortlich sind.
Während der Einsetzung des Ausschusses entscheidet der Eigentümer über die Größe des Ausschusses und das Quorum und initialisiert einen Prozess der verteilten Schlüsselerzeugung (Distributed Key Generation, DKG) zwischen den Knoten des Ausschusses. Dieser Prozess erzeugt:

  • Eine durch den Smart-Vertrag kontrollierte Kontoadresse
  • Einen privaten Schlüssel für jeden Ausschussknoten (weder dem Eigentümer noch anderen Ausschussknoten bekannt)

Dieser Prozess kann entweder zentralisiert oder dezentralisiert sein. In der zentralisierten Version kann der Eigentümer bei Bedarf einen Generalschlüssel verwenden, um Ausschussbeschlüsse außer Kraft zu setzen. In der dezentralisierten Version kann der Verantwortliche Entscheidungen nicht außer Kraft setzen.

Wie der Status eines intelligenten Vertrags aktualisiert wird

Die Ausschussknotenpunkte hören immer auf den Tangle, wenn es um Anfragetransaktionen geht, die an den intelligenten Vertrag gesendet werden sollen.

Wenn ein Ausschussknoten eine Transaktion erkennt, berechnet er den nächsten Zustand, indem er das Smart-Contract-Programm ausführt. Auf diese Weise werden ehrliche und synchronisierte Knoten immer genau die gleiche Zustandsaktualisierungstransaktion erzeugen. Ausschussknoten tauschen nie echte Ergebnisse aus, sondern nur Hashes. Es besteht also kein Risiko, dass Knoten die Ergebnisse der anderen kopieren, um zu versuchen, die Belohnung auszuspielen.

Wenn sich die Knoten nicht über den aktualisierten Zustand einig sind, wird jeder Knoten eine andere Transaktion unterzeichnen, was zu einer ungültigen Signatur führt. Die Knoten müssen daher einen mehrheitlichen Konsens über den aktualisierten Zustand erreichen.

In der asynchronen Einstellung des Tangles kann jeder Ausschussknoten einen anderen Zustand sehen, je nach seiner lokalen Uhr oder seinen Nachbarn. Ausschussknoten müssen daher einen verteilten Konsensalgorithmus ausführen, um einen Konsens über das Ergebnis zu erzielen. Das Ergebnis des Konsenses ist ein Hash des Ergebniskerns, eine Sammlung von Teilunterschriften des BLS und ein Zeitstempel. Alle intelligenten Vertragstransaktionen werden mit einem Zeitstempel versehen, und der Zeitstempel stimmt mit den lokalen Uhren der meisten Knoten überein.

Wenn alle Knoten einen Konsens erreicht haben, sammelt ein Ausschussmitglied, der Leiter, alle Teil-BLS-Signaturen der Knoten, bevor die endgültige Transaktion an das Tangle übermittelt wird. Diese Transaktion muss sich auf den vorherigen Zustand beziehen, um eine Kette von Zustandsaktualisierungen zu erstellen, die als Prüfpfad dient. Wenn die Transaktion bestätigt wird, wird sie zum neuen Zustand des intelligenten Vertrags.

Herausforderungen

IOTA Smart Contracts sind äußerst flexibel, aber diese Flexibilität bringt auch Herausforderungen mit sich, für die wir zum Teil bereits Lösungen entwickelt haben.

Staatliche „Forks“

Ein State Fork ist eine widersprüchliche Kopie des Zustands des intelligenten Vertrags. Dies kann passieren, wenn zwei oder mehr Transaktionen an den Tangle angehängt werden, die beide den Zustand auf unterschiedliche Weise aktualisieren.

Obwohl wir erwarten, dass Zustandsabzweigungen selten sind, könnten sie theoretisch in einer asynchronen Umgebung auftreten. Zum Beispiel verliert der führende Knoten unmittelbar vor der Verbuchung der letzten Transaktion die Verbindung mit dem Tangle und nach einer Zeitüberschreitung übernimmt ein anderer Knoten die Führung. In diesem Fall könnten zwei führende Knoten Aktualisierungen des Tangle nach der Verbuchung der letzten Transaktion vornehmen.

Um Zustandsabzweigungen zu verhindern, wird bei der Einrichtung des Smart-Vertrags ein einzigartiges farbiges Token, das als Smart-Vertrags-Token (mit einem Gesamtvorrat von 1) bezeichnet wird, erstellt und an die Smart-Vertragsadresse übertragen. Bei jeder Statusaktualisierung wird das einzige Smart-Contract-Token an dieselbe Adresse gesendet, wodurch die entsprechende nicht ausgegebene Ausgabe in die neue Transaktion verschoben wird. Auf diese Weise bilden die Transaktionen eine nicht verarbeitbare Kette, da es unmöglich ist, den Output des intelligenten Vertragstokens aufzuteilen und zweimal auszugeben.

Schnappschüsse

Ein Schnappschuss ist eine Möglichkeit für einen Knoten, Speicherplatz zu sparen. Transaktionen vor einem bestimmten Datum werden möglicherweise „weggeschnappt“. Dabei können ältere intelligente Transaktionen und Aktualisierungen des Vertragsstatus verloren gehen.

Um dieses Problem zu entschärfen, können intelligente Verträge ihre eigenen Momentaufnahmen durchführen, indem sie alle Zustandsinformationen sammeln und sie zu einer einzigen Transaktion hinzufügen. Diese Transaktion wird zum Anfang der neuen Kette.

Große Summen von Tokens

Eine große Geldsumme über einen langen Zeitraum in einem Vertrag zu sperren, ist viel sicherer, wenn man sich darauf verlassen kann, dass das gesamte Netzwerk für die Abwicklung zur Verfügung steht, wie bei den intelligenten Verträgen von Ethereum Level 1. Es ist jedoch nicht garantiert, dass nach einem langen Zeitraum ein Ausschuss von begrenzter Größe existiert. Für diese Anwendungsfälle könnte ein intelligenter Vertragsinhaber von Fall zu Fall andere Notfallpläne aufstellen.

Schlüsselverwaltung

Die Knotenpunkte müssen für jeden Ausschuss, dem sie angehören, einen Schlüssel verwalten. Wenn ein Knotenpunkt Teil vieler Ausschüsse ist, ist daher die Speicherung und Verwaltung dieser Schlüssel eine wesentliche Aufgabe. Die Knotenpunkte benötigen eine Lösung für eine sichere und skalierbare Schlüsselverwaltung.

Schlussfolgerung

IOTA Smart Contracts sind intelligente Vertragsprogramme, die von einem genehmigten Ausschuss auf Schicht 2 (Off-Tangle) ausgeführt werden. Der Ausschuss der Knotenpunkte aktualisiert das Ledger kollektiv, indem er unterzeichnete Transaktionen (unter Verwendung von Schwellenwertunterschriften) an das Tangle einreicht.

IOTA Smart-Contracts sind sehr flexibel und benötigen viel weniger Ressourcen als die Blockketten-Alternativen. Sie ermöglichen Anwendungsfälle, die mit Gebühren als einzigem Anreiz nicht möglich gewesen wären. Dies gilt insbesondere im Bereich des IoT, wo Mikroverträge und Mikrotransaktionen die Norm sein dürften.

Wir planen, WebAssembly in der ersten Version zu verwenden, aber wir sind nicht auf eine einzige virtuelle Maschine (VM) beschränkt, mit der Möglichkeit, in Zukunft auch andere Programmiersprachen und VMs zu verwenden.

Wir laden die Gemeinschaft ein, ihre Gedanken, Ideen und ihr Feedback im Kanal #smartcontracts auf dem offiziellen IOTA-Discord zu teilen.

IOTA: Verbesserung des sicheren Konsenses durch intelligente Maschinenmodell-Erfassung von Aspekten der verteilten Ledger-Technologie

Original by Adan Saada: https://thecurrencyanalytics.com/14109/iota-improving-secure-consensus-using-intelligent-machine-model-capturing-aspects-of-distributed-ledger-technology/ (01.05.2020)

Die IOTA teilte mit, dass sie mit Begeisterung verkünden kann, dass die Arbeit an der Erweiterung des Konsensmechanismus der IOTA als Teil unseres Koordizidzuschussprogramms begonnen hat.

Das Projekt soll von Dr. André Vilela und Dr. Kenric Nelson entwickelt werden. Das Projekt konzentriert sich auf die Erweiterung des Konsensmechanismus zu IOTA.

Die mathematischen Mechanismen, die das Verhalten von Agenten in Gruppen innerhalb von sozialen Netzwerken und finanziellen Netzwerken bestimmen, sollen untersucht werden. Es wird entschieden, welche Entscheidungen zu aktiven kollektiven Phänomenen beitragen. Die Informationstheorie wird bei der Analyse komplexer Systeme angewandt, die schließlich zum Entwurf und zur Entwicklung intelligenter Maschinen beitragen.

Das IOTA-Projekt wird sich auf die Erstellung eines Modells konzentrieren, das die verschiedenen Aspekte der verteilten Ledger-Technologie genau erfasst. Diese Arbeit wird für die künftige Erweiterung von IOTA von grundlegender Bedeutung sein und CA als zusätzlichen Konsensmechanismus umfassen.

Sydney Ifergan, der Krypto-Experte tweetete: „IOTA untersucht alle Möglichkeiten, um einen sicheren Konsens über die Distributed Ledger Technology zu ermöglichen. Sie pflügen dem Marktführer auf ihre eigene Art und Weise im Bereich der Krypto-Währung entgegen“.

IOTA DLT für Rückverfolgbarkeit

IOTA-Twitter: „Wir arbeiten mit w/@ZebraTechnology zusammen, um RFID- und Barcode-Scanner mit dem #Tangle für einen einfachen und vertrauenswürdigen Datenaustausch zu verbinden. Nehmen Sie an unserem Webinar teil und erfahren Sie, wie wir #DLT für die Rückverfolgbarkeit in #Supplychains einsetzen. 5. Mai um 3PM MEZ“.

Im Future Proof Webinar diskutierte die IOTA mit Holger Kother, dem Direktor für Partnerschaften, über die dezentralen Marktplätze. Diejenigen, die an den Webinaren teilnehmen, werden nach jeder Sitzung ein IOTA-Ausbildungszertifikat erhalten.

IOTA arbeitet mit Tangle_EE zusammen, um die Entwicklung von Unternehmens- und Open-Source-Tools auf der Grundlage von Tangle zu beschleunigen. Dies tun sie in Zusammenarbeit mit EclipseFDN. Es hilft, mehr über Eclipse Unified Identity & Eclipse Tangle-Marktplatzprojekte zu erfahren.

Jens Munch, Leiter des Bereichs Globaler Handel und Lieferketten bei der IOTA, arbeitet mit dem Weltwirtschaftsforum und anderen globalen Experten zusammen, um ein Toolkit für den Einsatz von Blockchainlösungen unter Verwendung von Lieferketten zu erstellen. IOTA erklärte, sie freue sich, Teil der Initiative zu sein.

Die IOTA hat in letzter Zeit über die Verbesserung des Abfallmanagements mit intelligenten Behältern und Tangle diskutiert, um den Prozess des intelligenten Abfallmanagements zu beschleunigen und so die Energieoptimierung zu verbessern.

Die IOTA sind in eine Menge Forschung involviert und arbeiten somit auf eine vertrauenswürdige und widerstandsfähige Zukunft hin.

Stand der IOTA-Forschung – April 2020

Original by Serguei Popov: https://blog.iota.org/iota-research-status-update-april-2020-f1c3576b57db (16.04.2020)

Wir freuen uns, Ihnen die neuesten Nachrichten aus der IOTA-Forschungsabteilung mitzuteilen. Wir hoffen, dass Ihnen die Präsentationen zur Einführung in die Coordicide-spezifikationen, die wir kürzlich veröffentlicht haben, gefallen haben. Nachstehend finden Sie die neuesten Updates zu unseren Fortschritten.

Sitzung „Benennung“

Mehrere Forscher trafen sich mit weiteren Mitgliedern der Stiftung, um viele der neuen Coordicide-Strukturen zu benennen. Dies mag trivial erscheinen, ist aber aufgrund ihrer Bedeutung und Dauerhaftigkeit tatsächlich schwierig. Sowohl interne als auch externe Entwickler müssen verstehen, wie IOTA funktioniert, damit sie Anwendungen erstellen können. Abgesehen von der Verlangsamung der Produktion kann ein unintuitives Benennungsschema sogar die Annahme behindern, indem es Menschen davon abhält, auf der IOTA-Plattform aufzubauen.

Wir haben gute Fortschritte gemacht. Da wir davon ausgehen, dass der größte Teil des Datenverkehrs im IOTA-Netz aus „0-Wert-Transaktionen“ bestehen wird, haben wir vorläufig beschlossen, die Objekte im Tangle in „Nachrichten“ statt in „Transaktionen“ umzubenennen. Jede Nachricht enthält eine Nutzlast, und wir haben Namen für mehrere der Kernnutzlasttypen entwickelt. Zusätzlich zu den Kernnutzlasten können Benutzer ihre eigenen Nutzlasttypen definieren, die nicht von allen Knoten verarbeitet werden müssen. Mit diesem flexiblen Nachrichten-/Payload-Format kann IOTA eine Vielzahl von Anwendungen bedienen.

In Verbindung mit dem Benennungsprozess stehen wir kurz davor, das Layout der Nachrichten und einiger Kernnutzlasten auf hohem Niveau abzuschließen. Um die Dinge beim Namen nennen zu können, müssen wir verstehen, was wir benennen. Dies ist ein wichtiger Schritt zur Entwicklung eines standardisierten Protokolls.
Wir gehen davon aus, dass die Terminologie bis zur nächsten Aktualisierung fertig gestellt und veröffentlicht sein wird.

Spezifikationen

Wir haben große Fortschritte bei den Spezifikationen von Coordicide gemacht und arbeiten derzeit an den Blaupausen und einem gelben Papier. Mike Bennett von der OMG und unser Leiter der Normung unterstützt diesen Prozess. Die Arbeit an GoShimmer (erste Implementierung von Coordicide) ist in vollem Gange, und wir beabsichtigen, in einigen Wochen das erste Testnetz zu starten. Dies ist eine gemeinsame Arbeit des Forschungs- und Ingenieurteams. Um beide Teams auf der theoretischen Ebene aufeinander abzustimmen, haben wir eine Reihe von Präsentationen entwickelt, in denen wir kurz erläutern, welche Themen in der Hauptspezifikationsdatei erscheinen sollen. Die Präsentationen wurden recht gut aufgenommen und ermöglichten es den Ingenieuren, gemeinsam mit den Forschern an jedem Thema zu arbeiten. Mit dem Schreiben der Spezifikationen wurde begonnen, und wir hoffen, im kommenden Monat eine große Weiterentwicklung zu erreichen.

Vernetzung

Wir haben eine erste Komplettlösung zur Bewältigung von Netzwerküberlastungen fertiggestellt. Insbesondere besteht unser Protokollvorschlag aus zwei Modulen, die die Tarifkontrolle ergänzen: (i) Terminierung, bei der Transaktionen, die von bestimmten Knoten ausgegeben werden, Vorrang eingeräumt wird, um den Durchsatz proportional zum Mana zu teilen; (ii) Tarifgestaltung, die sich mit der lokalen Überlastung befasst und von der AIMD inspiriert ist. Gegenwärtig führen wir umfangreiche Simulationen durch und vergleichen sie auch mit bestehenden Terminierungsrichtlinien und Staukontrollalgorithmen. Unsere Ergebnisse zeigen, dass Fairness garantiert ist und die Latenzzeit begrenzt ist. Wir planen nun, eine „Packet-Drop-Politik“ zur Behandlung von Transaktionsbursts hinzuzufügen und anschließend zu evaluieren, wie sich diese Politik auf die Konsistenzanforderung auswirkt.

Was den adaptiven PoW-Algorithmus betrifft, so haben wir das so genannte Kollisionsproblem gelöst, indem wir Sequenznummern entfernt haben (mehr dazu können Sie hier lesen). Das Protokoll ist bereit für Spezifikationen. Zusätzlich untersuchen wir im Zusammenhang mit VDFs niedrigere Grenzen für die Anzahl der Gate-Operationen, die zur Lösung modularer Quadrierungen erforderlich sind, was Schätzungen der physikalischen Grenzen zur Lösung einer VDF liefern wird. Unser Vortrag über IOTA und VDFs auf der Stanford Blockchain Conference ist auf YouTube verfügbar.

dRNG

Wir schlossen den Großteil der Konzeptarbeit an einem dezentralen Zufallszahlengenerator (dRNG) für das IOTA-Netzwerk ab. Unsere Arbeit beinhaltete die Anpassung und Justierung des „drand-Protokolls“, damit es in der DLT-Umgebung ohne Erlaubnis funktioniert. Wir entwarfen ein spezielles Tangle-Nachrichten-Layout, das die Auswahl durch den Ausschuss, die verteilte Schlüsselgenerierung und die nahtlose Erfassung der Zufälligkeit ermöglicht.

Im Moment ist das Hauptaugenmerk unserer Gruppe darauf gerichtet, die Spezifikation für die Entwickler zu schreiben. Wir entwickeln jedoch auch zusätzliche Sicherheitsmerkmale von IOTA dRNG. Die endgültige Spezifikation soll Backup-Zufallsgeneratoren sowie Mechanismen zur Erkennung von Ausschussfehlern und Methoden zur Benennung des neuen Ausschusses enthalten.

GoShimmer-Implementierung

Unsere Gemeinschaft hat uns beim Testen unseres Prototyps enorm geholfen, und als Ergebnis haben wir v0.1.3 veröffentlicht, die mehrere Fehlerbehebungen, verbessertes Autopeering und Dashboard und mehr Stabilität enthält.

In der Zwischenzeit hat das GoShimmer-Team an der bevorstehenden nächsten Version v0.2.0 gearbeitet. Wir haben die Unterstützung für traditionelle Public-Key-Kryptographie auf der Basis elliptischer Kurven (z.B. Ed25519 und BLS) sowie binäre Hash-Funktionen wie SHA-256, SHA-512 und Blake2b integriert.

Die Goshimmer-Modularität hat durch die Implementierung eines schichtenbasierten Ansatzes weitere Fortschritte gemacht. Obwohl die Benennung der Schichten noch nicht abgeschlossen ist, können wir Ihnen einen kleinen Einblick geben: Die erste Schicht befasst sich mit Nachrichten; jede Nachricht enthält einige Metadaten wie Stamm, Zweig, Zeitstempel und andere Informationen zur Identität des Emittentenknotens sowie eine Nutzlast. Jede Nutzlast hat einen Typ und einige Daten. Aufgrund ihres Typs (z.B. dRNG-Typ, Werttransaktion) können die enthaltenen Daten entsprechend interpretiert werden. Diese „Interpretations“-Schicht ist unsere zweite Schicht. Darüber haben wir die „Anwendungs“-Schicht, wo ein Protokoll die von der darunter liegenden Schicht bereitgestellten Informationen nutzen kann. So könnte zum Beispiel ein intelligentes Vertragsprotokoll über dem Werte-Tangle implementiert werden (d.h. das Protokoll, das die Werttransaktion implementiert), oder ein dezentralisiertes Lotterieprotokoll über dem dRNG-Protokoll.

Werttransaktionen und das UTXO-Modell sind nun im Entwicklungszweig abgeschlossen. Wir verbinden auch das FPC-Protokoll mit dem Werte-Tangle, so dass widersprüchliche Transaktionen durch Abstimmung gelöst werden können. Eine Wasserhahnanwendung wird es den Benutzern ermöglichen, Mittel zu Testzwecken anzufordern.
Das dRNG wurde ebenfalls in seine erste Iteration integriert: Ausschussmitglieder werden eine IOTA-Version der drand-Anwendung betreiben und „kollektive Baken“ über einen GoShimmer-Knoten an das Netzwerk senden. Jeder Knoten wird in der Lage sein, die Korrektheit der „collective beacons“ zu verifizieren, indem ihre Signatur mit dem verteilten öffentlichen Schlüssel verglichen wird (d.h. dem öffentlichen Schlüssel, der aus den öffentlichen Schlüsseln aller Ausschussmitglieder abgeleitet wird).

Schließlich haben wir an einigen kleineren Verbesserungen gearbeitet: ein besserer Netzwerk-Visualisierer, sowohl auf der Client- als auch auf der Server-Seite; ein Plugin-Manager, der es Entwicklern erlaubt, GoShimmer-Plugins einfach hinzuzufügen und zu verwalten; automatisierte Integrationstests; ein flexibleres Autopeering, das frühere NAT- und Reverse-Proxy-bezogene Einschränkungen aufhebt.

FPC

In der FPC-Gruppe arbeiteten wir weiter an Optimierungen der FPC. Simulationsstudien zeigen, dass diese Anpassungen die Ausfallrate um mindestens eine Größenordnung senken. Gegenwärtig fassen wir diese Ergebnisse in einem Forschungspapier zusammen; das Video gibt Ihnen vielleicht einen ersten Eindruck von unserem Ansatz und von der Art der Ergebnisse, die wir zeigen können. Die Spezifikationen von FPC sind weit fortgeschritten und die restlichen Details werden in Zusammenarbeit mit dem Ingenieurteam festgelegt.

Mana und Autopeering

Die Mana- und Autopeering-Projekte beginnen sich zu beruhigen. Wir diskutierten die letzten Fragen bezüglich der Spezifikationen und trafen einige endgültige Designentscheidungen.

Wir haben auch die Arbeit an unseren Forschungsarbeiten fortgesetzt. Wir haben beschlossen, zwei Arbeiten zu schreiben: eine Analyse unserer Simulationen, die wir mit unserem GoShimmer-Simulator durchgeführt haben. Die zweite wird unsere mathematischen Berechnungen enthalten. Wir hoffen auch, einen Konferenzband zu verfassen, der die Ergebnisse in diesen beiden Papieren zusammenfasst.

Wir haben jetzt noch drei Aufgaben:

  1. Schreiben der Spezifikationen
  2. Beendigung unsere Forschungsarbeiten
  3. Die Parameter einstellen

Obwohl die erste Aufgabe eindeutig die wichtigste ist, erwarten wir weitere Fortschritte bei unseren Papieren. Wir haben beschlossen, mit der Erforschung der endgültigen Parameter zu warten, bis wir mit der Spezifikation fertig sind.

Protokoll

Die Protokollgruppe befasste sich in diesem Monat mit dem Problem der Endgültigkeit des Tangle, wo wir eine Reihe von Instrumenten entwickelt haben, mit denen der Benutzer die Sicherheit seiner Transaktionen überprüfen kann. Wir erörterten auch Optimierungen und die Frage, wie die Finalität mit vertretbarem Rechenaufwand kalkulierbar gemacht werden kann. Wir sind dabei, Wahrscheinlichkeitswerte für die Finalitätstools zu bestimmen, so dass wir genau wissen, wie sicher wir sind. Der nächste Schritt der Gruppe wird darin bestehen, die Engpässe zu bestimmen, die im gegenwärtigen Ansatz optimiert werden müssen, indem das Verarbeitungsverfahren eines Knotens analysiert wird, sowie mit dem Schreiben der Spezifikationen zu beginnen.

Wir freuen uns darauf, Ihnen bald weitere Neuigkeiten mitzuteilen! 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.