Energieverbrauch von IOTA 2.0

Fortgesetzte Energieeffizienz mit neuen Protokollkomponenten

TL;DR:
Tests des koordinatorlosen IOTA 2.0-Prototyps zeigen schlüssig eine erhebliche Verringerung des Energieverbrauchs für die Ausgabe von Nachrichten und eine Fortsetzung des insgesamt niedrigen Energieverbrauchs des Netzwerks, was IOTA zu einer der umweltfreundlichsten und nachhaltigsten Distributed Ledger Technologien (DLT) macht. Ein GoShimmer-Netzwerk mit 450 Raspberry Pi-Knoten bei einer konstanten Netzwerklast von 50mps würde nur etwa 43,30 % des jährlichen Energieverbrauchs einer Person verbrauchen und 0,000009 % des derzeit geschätzten jährlichen Energieverbrauchs des Bitcoin-Netzwerks verbrauchen.

„Energieverbrauch von IOTA 2.0“ weiterlesen

Dev Status Update – September 2021

Das IOTA-Entwicklungsteam veröffentlicht jeden Monat dieses Update, das Sie über Neuigkeiten und Aktualisierungen unserer wichtigsten Projekte informiert! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen möchten. Für monatliche Forschungs-Updates, klicken Sie hier.

Chrysalis

Es ist schon ein paar Monate her, dass Chrysalis erfolgreich im Mainnet veröffentlicht wurde. Sie können alles über die Veröffentlichung hier nachlesen. Bislang wurden über 67 % aller Token in das neue Netzwerk migriert.

Im August haben wir die Unterstützung von Ledger Nano zu Firefly hinzugefügt. Sie können alles über das Update hier nachlesen. Sie können sich auch das von uns produzierte Video ansehen, das zeigt, wie einfach es ist, Ihre IOTA-Token auf einen Ledger Nano zu migrieren.

Ein großer Schwerpunkt des Entwicklungsteams liegt derzeit auf Smart Contracts und zukünftigen Protokoll-Upgrades zur Unterstützung unserer Smart Contract-Fähigkeiten.

IOTA 2.0 Devnet

Nach der erfolgreichen Veröffentlichung des IOTA 2.0 DevNet Anfang Juni hat sich das Team auf Änderungen am Konsens und Optimierungen konzentriert. Für den neuesten Stand von IOTA 2.0 lesen Sie bitte den Beitrag, den wir Anfang dieser Woche veröffentlicht haben. Das GoShimmer-Team hat gerade eine neue Version veröffentlicht, die hauptsächlich Refactor- und Abhängigkeits-Updates enthält. Die Veröffentlichung konzentriert sich nicht auf die OTV-Konsensänderungen. Wir stellen nun auch tägliche Datenbankexporte zur Verfügung, so dass Community-Mitglieder leichter neue Nodes aufsetzen können.

Um mehr über das IOTA 2.0 DevNet zu erfahren, besuchen Sie die neue Website, den Tangle-Explorer und die Entwicklerdokumentation.

Bee

Das Bee-Team hat vor kurzem zwei Versionen des Knotens veröffentlicht, 0.2.0 und 0.2.1, die das Pruning einführen, Fehler beheben und die Leistung verbessern. Wir empfehlen, auf die neueste Version zu aktualisieren. Das Team hat auch an der Instrumentierung gearbeitet, um eine bessere Fehlersuche zu ermöglichen und die Leistung zu verbessern.

Die Arbeit an Coordicide geht weiter mit einem komplett neuen Plugin-System, einer überarbeiteten Speicherimplementierung, neuen Nachrichten- und Nutzlast-Layouts und deren Validierungsregeln, der Verwendung eines gemeinsamen Akteurs-Frameworks zwischen dem Bee-Knoten und dem Chronicle-Knoten, einem Entwurf des Nachrichtenflusses sowie einer mit GoShimmer kompatiblen Netzwerkschicht.

Hornet

Anfang des Monats hat das Team die Version 1.0.5 von Hornet veröffentlicht. Seitdem hat das Team hauptsächlich an den Spezifikationen für die nächsten Protokoll-Upgrades gearbeitet, die auf IOTA zukommen.

Smart Contracts

In diesem Monat hat das IOTA Smart Contract Team die Arbeit an der Beta-Version von ISCP fortgesetzt, die im IOTA 2.0 Devnet veröffentlicht wird, sobald die letzte Dokumentation hinzugefügt und die Optimierungen eingearbeitet wurden. Ein neues Schema-Tool wurde in die Codebasis integriert, das Ihnen bei der Entwicklung von Smart Contracts alle schweren Arbeiten abnimmt, so dass Sie sich auf das Wesentliche konzentrieren können: die Implementierung selbst. Die experimentelle EVM-Unterstützung wird ebenfalls verbessert und getestet, während in der Zwischenzeit bereits Vorbereitungen für die Lieferungen nach dem Beta-Release getroffen werden. Dazu gehört die Unterstützung des neuen Native-Assets-Standards, der derzeit spezifiziert wird, sowie die erweiterte EVM-Unterstützung, die die Kommunikation zwischen Layer 1 IOTA- und ISCP-Ketten ermöglicht. Wir legen auch letzte Hand an ein öffentliches Testnetz für ISCP, um die Einstiegshürde für das Experimentieren mit der ISCP-Beta zu senken. Die Dokumentation für ISCP wurde ebenfalls neu geschrieben und sobald wir die letzten Themen abgeschlossen haben, werden wir diese in das Wiki einbinden, um sie leichter zugänglich zu machen. Wir können es kaum erwarten, dass Sie es ausprobieren, sobald die Beta-Version veröffentlicht wurde.

Ihr könnt die Updates verfolgen und Erfahrungen in den Kanälen #smartcontracts-discussion und #smartcontracts-dev auf Discord austauschen.

Stronghold

Wir befinden uns auf dem Weg zur Version 1.0 von Stronghold. Zu den aktuellen Funktionen gehören die vollständige und teilweise Synchronisation für lokale Strongholds, später auch für entfernte Strongholds. In diesem Zusammenhang streben wir auch eine Remote-Ausführung von Prozeduren an. Die komponierbare kryptographische prozedurale API erreicht ihre Endphase und wir arbeiten derzeit an der Integration grundlegender kryptographischer Bausteine.

Wallet

Das Firefly-Team hat kürzlich seine Entwicklungsdiskussionen öffentlich gemacht und Sie können den Fortschritt im #firefly-dev Kanal auf Discord verfolgen. Wir planen auch, die Entwicklung von Firefly Mobile zu einem bestimmten Zeitpunkt öffentlich zu machen.

Das Team konzentriert sich im Moment auf eine Mischung aus verschiedenen Dingen. Firefly Mobile macht gute Fortschritte und die Benutzeroberfläche nimmt Gestalt an. Die Bindungen für Android sind in der Entwicklung, während iOS in der Forschung ist und wahrscheinlich noch einige Wochen dauern wird. Sobald die Anbindungen für jede Plattform fertig sind, können wir damit beginnen, die Benutzeroberfläche mit der zugrunde liegenden Logik und der wallet.rs Bibliothek auf der jeweiligen Plattform zu verbinden. In der Zwischenzeit hat das Team einige Hausarbeiten erledigt, Probleme bereinigt und Wiki-Artikel hinzugefügt, um die Entwicklung der Community zu fördern. Parallel dazu werden UX-Ideen für einige der zukünftigen Funktionen von Firefly entwickelt.

IOTA-Identität

Das IOTA Identity Team wächst weiter mit zwei zusätzlichen Rust-Entwicklern: Henrique Nogara und Oliver Anderson, die das Team vorerst vervollständigen. Mit den vielen Neuzugängen im Team und unserem nächsten Ziel, dem IOTA Identity 1.0 Release Candidate, haben wir viel geforscht und Spezifikationen zu verschiedenen Themen geschrieben, um die beste API bereitzustellen, die wir entwerfen konnten. Wir erwarten, dass die Nutzung von IOTA Identity in den nächsten Updates noch einfacher wird und arbeiten weiter an der Spezifikation von DID Communications für den Identity Actor.

Diesen Monat haben wir auch die erste Version des Identity Resolver veröffentlicht. Dieses Tool ist nun Teil des IOTA Explorers und bietet Entwicklern und interessierten Community-Mitgliedern die Möglichkeit, den Status und die Historie digitaler Identitäten zu erkunden. Dies ist besonders hilfreich, wenn Sie eine Anwendung mit IOTA Identity entwickeln, da Sie die Historie Ihrer erstellten Identitäten mit einem einzigen Mausklick einsehen können.

Identity Resolver

Chronicle

Das Team war damit beschäftigt, Korrekturen an der Chrysalis-Version von Chronicle vorzunehmen und den Backstage-Teil des Permanodes neu zu schreiben. Diese Arbeit wurde zusammen mit dem Bee-Team durchgeführt und die Projekte teilen sich nun die Implementierung des Akteursmodells. Wir arbeiten jetzt hauptsächlich an einer Spezifikation für die selektive Permanode-Funktionalität. Sobald wir einen Entwurf haben, mit dem wir zufrieden sind, werden wir ihn für weiteren Input nach außen geben.

IOTA-Experiance Team

Diesen Monat begrüßen wir die neuesten Mitglieder des IOTA X-Teams: Sabo/LendexeFinance und Gman214

X-Teammitglied Stefan Braun von IOTA.php gab bekannt, dass die zu 100 % von der Community betriebene IOTA-PHP-Bibliothek, die hier verfügbar ist, die IOTA-Identität in die neu veröffentlichte Alphaversion 0.4.0 integriert hat. Unterstützen Sie das Projekt, indem Sie IOTA.php auf Twitter folgen und dem Repository auf GitHub einen Stern hinzufügen!

Permanode X-Team Mitglied NO8ODY hat die Version 0.8.6 seiner SWARM Node Management Software veröffentlicht. Mit dieser neuen Version erlaubt das Update nun die gleichzeitige Installation von Hornet, Bee und GoShimmer Nodes auf einem System.

Wie einfach es ist, IOTA Nodes einzurichten und zu verwalten, erfahren Sie auf seiner Website.

Unterstützen Sie das Projekt, indem Sie Tanglebay auf Twitter folgen und einen Stern für das Repository auf GitHub vergeben!

Wir freuen uns, dass ein weiteres IOTA-Gemeinschaftsprojekt in Betrieb geht. Die X-Team Mitglieder Merul, adamski und rbrtbrnschn haben den Vorhang für ihr IOTA UP Projekt gelüftet

UP ist eine Plattform zum Teilen von Projekten, die es den Entwicklern ermöglicht, sich mit der Community zu verbinden. Sie bietet eine zentrale Anlaufstelle, um Updates zu teilen und sich mit einem globalen Publikum zu verbinden, um Unterstützung und Aufmerksamkeit für bahnbrechende Innovationen und Design zu erhalten.

Besuchen Sie IOTA UP und erfahren Sie mehr über diese großartige Gemeinschaftsinitiative. Melden Sie sich an und fügen Sie Ihr Projekt zu IOTA UP hinzu!

Simplify X-Team Mitglied Linus hat 2 Beiträge auf Reddit und Medium über IOTA veröffentlicht, die absolut lesenswert sind:
Reddit:

Medium:

Das X-Team und das von der Community betriebene IOTA-Wiki wachsen!

Die X-Team-Mitglieder Dr. Muon, adamski, Critical und Jeroen van den Hout haben weiter an dem Wiki gearbeitet und das Design, den Inhalt und die Benutzerfreundlichkeit stark verfeinert.
Das Wiki wird ein zentraler Anlaufpunkt für IOTA-Informationen sein. Lasst es uns gemeinsam BUIDLen!

IOTA Wiki

Entwickler sind eingeladen, die Community-Wiki-Initiative zu verbessern, indem sie sich den Code im Repository ansehen. Jeroen van den Hout hat einen Markdown-Editor für Docusaurus-Inhalte entwickelt, der GitHub nutzt, um jeden Fortschritt zu übertragen und es den Mitwirkenden zu ermöglichen, eine Pull-Anfrage an das Upstream-Repository zu stellen, ohne dass sie Markdown oder GitHub kennen müssen. Das Repository ist hier zu finden, Ihr Beitrag wird sehr geschätzt. Der implementierte In-Page-Editor, der es einfach macht, zum Wiki-Inhalt beizutragen, ohne ein GitHub-Experte zu sein, hat bereits vielen Community-Mitgliedern geholfen, Beiträge zu leisten. Folgen Sie ihrem Beispiel! Das Einzige, was Sie brauchen, um es zu nutzen, ist ein GitHub-Konto.

Jedes IOTA-Community-Mitglied ist aufgefordert, den Inhalt mit seinen Beiträgen zu erweitern.

Beteiligen Sie sich an der Diskussion im #community-wiki Kanal auf dem IOTA Discord

Die Mitglieder des X-Team Smart contracts bereiten sich darauf vor, das IOTA Smart contracts Team auf dem Weg zur erwarteten Beta-Version von ISCP zu unterstützen. Das IOTA Foundation Smart contracts Team hat die Mitglieder des X-Teams bereits zu Beiträgen und Unterstützung eingeladen und die Mitglieder werden zu diesem Thema aktiv.

Da sich die Community auf die nächsten Schritte in der Entwicklung von IOTAs Smart Contracts vorbereiten möchte, hat die X-Team Smart Contracts Initiative einen neuen Champion gefunden, der sicherstellt, dass die X-Team Mitglieder ein wöchentliches Treffen abhalten können, um Ideen auszutauschen und ihre Fähigkeiten im Umgang mit Smart Contracts auf IOTA zu stärken. Wir begrüßen Gman214 als neuen X-Team Champion und danken ihm für die Übernahme dieser wichtigen Rolle.

Wenn Sie sich die Hände mit ISCP schmutzig machen und zum Beta-Start beitragen wollen, treten Sie den X-Teams bei.

Die zu 100% vom X-Team getragene Identity-Initiative trifft sich weiterhin jeden Montag um 20 Uhr MESZ. Vergewissern Sie sich, dass Sie bei der nächsten Sitzung auf dem IOTA Discord dabei sind.

Jeder ist zu den IOTA Experience Teams eingeladen, um den Weg für IOTA zu ebnen, um die beste Erfahrung im DLT- und IoT-Bereich zu haben. Lesen Sie mehr über das IOTA Experience Team in diesem Blogbeitrag, entdecken Sie die IOTA Experience Teams, erkunden Sie die IOTA Experience Initiativen, treten Sie dem IOTA Discord bei und bewerben Sie sich dann über dieses Formular.

Folgen Sie den IOTA Experience Teams und erhalten Sie Updates auf Twitter hier: https://twitter.com/IOTAXTeams.

Sehen Sie sich die früheren X-Team-Treffen hier auf dem YouTube-Kanal der IOTA Foundation an.

IOTA Gemeinschaft Github

Das Github-Repository der IOTA-Gemeinschaft besteht jetzt aus 72 Repositories, 32 Personen, organisiert in 8 Teams.

Original by Jakub Cech: https://blog.iota.org/dev-status-update-september-2021/

IOTA 2.0 – Details zum aktuellen Stand und die nächsten Schritte

TL;DR
Wir geben einen detaillierten Überblick über den aktuellen Stand und die nächsten Schritte für IOTA 2.0. Die aktuellen Bemühungen konzentrieren sich hauptsächlich auf die Optimierung der Konsens- und Kommunikationsschicht, um das Protokoll effizienter und weniger komplex zu machen. Die nächsten Schritte umfassen die Implementierung von aktiven Verteidigungsmaßnahmen und Benutzerfreundlichkeitsmerkmalen wie lokalen Snapshots.

Einführung

Die Veröffentlichung des DevNet für IOTA 2.0 stellt einen der wichtigsten Meilensteine in der Geschichte der IOTA Foundation dar. Zum ersten Mal waren wir nicht nur in der Lage, die Ideen hinter IOTA 2.0 in einem echten, vollständig dezentralisierten und koordinatorenfreien Netzwerk zu demonstrieren, sondern wir konnten auch das Zusammenspiel der verschiedenen Komponenten untersuchen.

Die Möglichkeit, die Leistung jeder dieser Komponenten zu messen und zu bewerten, hat es uns ermöglicht, eine Reihe von Optimierungen zu diskutieren und zu beschließen, um das Protokoll robuster, effizienter und weniger komplex zu machen.

Bei den meisten Änderungen handelt es sich um kleine Optimierungen des Datenflusses und Codevereinfachungen. Aber wir haben auch Anpassungen an der Kommunikationsschicht und einige entscheidende Änderungen an der Konsensschicht vorgenommen.

Die Verbesserungen an der Konsensschicht vereinfachen das Protokoll erheblich, indem sie alle Informationen aus dem Tangle ableiten und eingehende Transaktionen auf optimistische Weise behandeln. Die erste Implementierung ist abgeschlossen, und wir arbeiten gleichzeitig an detaillierten Simulationen und Forschungspapieren. Es müssen nur noch einige wenige Änderungen vorgenommen werden, während wir einen klaren Weg einschlagen.

Was die Kommunikationsschicht betrifft, so wird derzeit ein effizienter Scheduling-Algorithmus im IOTA 2.0 DevNet implementiert. Dieser arbeitet mit einem Rate Setter Modul, um Fairness und kurze Verzögerungen zu gewährleisten. In einem nächsten Schritt werden wir einen Mechanismus zur Bestrafung von Angreifern implementieren, der bereits spezifiziert ist. Außerdem arbeiten wir derzeit an einer verbesserten Benutzerfreundlichkeit, um die Nutzung des Netzwerks zu erleichtern.

Dieser eher technische Blog-Beitrag geht auf die Details der IOTA 2.0-Verbesserungen ein, beschreibt den aktuellen Status und zeichnet ein allgemeines Bild des weiteren Weges.

Aktueller Stand der IOTA Entwicklung

Konsens-Ebene

Die Vision

Wie in einem früheren Blogbeitrag beschrieben, müssen die Knoten nicht mehr andere Knoten um ihre Meinung bitten, um Konflikte zu lösen, sondern erhalten alle Informationen, die sie benötigen, einfach durch Beobachtung des Tangles. Das daraus resultierende Protokoll ist der ursprünglichen Vision von IOTA sehr ähnlich, die einen reinen Konsens im Nakamoto-Stil ohne zusätzlichen Abstimmungs-Overhead verwendete, bei dem die Knoten ihre Meinung durch das Erstellen von Nachrichten im Tangle kundtun.

Bei FCOB+FPC wurde jede Transaktion mit einer Quarantänezeit bestraft, um eine anfängliche Meinung festzulegen und die Metastabilität im seltenen Fall von Konflikten, die nicht rechtzeitig gelöst werden können, von vornherein zu brechen. Im Gegensatz dazu erlauben die Änderungen am Konsens den Knoten, ihre Meinung zu äußern, ohne eine Quarantänezeit anzuwenden. Erst wenn ein Konflikt für einige Zeit ungelöst ist, wird ein Metastabilitätsmechanismus wie FPCS aktiviert, um den Konflikt zu entscheiden. Dieses optimistische Verfahren beschleunigt nicht nur die Bestätigungszeiten, sondern macht das Protokoll auch viel einfacher und schlanker.

Wo wir gerade stehen

Die Umsetzung der Verbesserungen des Konsensverfahrens schreitet zügig voran: Eine erste Implementierung des reinen On Tangle Voting (OTV) als modulare Konfliktauswahlfunktion und ähnlicher Schalter ist abgeschlossen und wir befinden uns derzeit in der Test-, Fehlerbehebungs- und Dokumentationsphase. Unmittelbare nächste Schritte sind die Vereinfachung der Marker für das Approval Weight (AW) und die Aktualisierung des Toolings, d.h. der GUI-Wallet, der Bibliothek und ihrer Dokumentation.

Die erste Version unseres auf FPC basierenden Metastabilitätsunterbrechers wurde von der Wissenschaft gründlich validiert (FPC-BI, Fast Probabilistic Consensus with Weighted Votes). Die gleichen Ergebnisse und Konzepte können auf unseren aktuellen optimierten Vorschlag ausgeweitet werden, der eine einfache Modifikation des ursprünglichen FPC ist und in Kürze in einer strengen wissenschaftlichen Abhandlung veröffentlicht werden wird. Wir werden unsere Validierung fortsetzen, indem wir ein wissenschaftliches Forschungspapier erstellen, das die Stärke unseres verbesserten Konsensmechanismus demonstriert.

Neben der Beschreibung des OTV-Mechanismus werden wir seine Leistung durch umfangreiche Simulationsstudien auf der Grundlage des Multiversum-Simulators analysieren, der derzeit erweitert wird, um als allgemeiner Simulationsrahmen für unseren Konsens zu dienen. Dazu gehören die Untersuchung der Bestätigungszeiten und der Widerstandsfähigkeit in verschiedenen Double-Spend-Szenarien sowie die Berücksichtigung eines ungünstigen Umfelds. Schließlich werden wir OTV zusammen mit FPC on a set (FPCS) einbeziehen und die Auswirkungen dieser Symbiosen im Detail untersuchen.

Der Weg nach vorn

Bei reinem OTV legen die Knoten ihre anfängliche Meinung zu Konflikten auf der Grundlage ihrer Wahrnehmung des schwereren Zweigs fest, wodurch sich das Protokoll ähnlich wie die Bitcoin-Regel der längsten Kette verhält. Das bedeutet, dass der Konsens inhärent probabilistisch ist und der Kunde (z. B. ein Knoten, eine Geldbörse oder eine Börse) anhand seiner Sicherheitsschwelle entscheidet, wann er eine Transaktion als bestätigt ansieht (in Bitcoin ist dies als 6-Block-Regel bekannt). Dementsprechend werden wir mehrere Finalitätsgrade (Grades of Finality, GoF) einführen, die hauptsächlich auf dem Genehmigungsgewicht basieren und ansteigende Sicherheitsschwellenwerte definieren. Je höher der Grad, desto höher die Sicherheit. In seltenen Fällen (z. B. wenn ein Knoten verfinstert oder teilweise offline ist) könnte ein Knoten jedoch zu einem späteren Zeitpunkt fehlende Informationen erhalten, was dazu führen könnte, dass er seine lokale Wahrnehmung reorganisieren muss, genau wie bei Bitcoin. Glücklicherweise macht eine hohe GoF-Einstellung solche Vorkommnisse praktisch unmöglich. Nichtsdestotrotz muss dieses Reorganisationsverfahren in die Knotensoftware implementiert werden, um Komponenten, die von der Bestätigung abhängen, zurückzusetzen.

Sobald wir eine stabile Version von reinem OTV mit laufender Reorg haben, können wir uns auf die Implementierung eines Mechanismus zur Unterbrechung der Metastabilität konzentrieren, der mit reinem OTV Hand in Hand geht und einsetzt, wenn ein Konflikt zu lange ungelöst bleibt. Konkret werden wir zunächst Fast Probabilistic Consensus on a set (FPCS) als Metastabilitätsunterbrechung implementieren und dabei positive frühere Forschungsergebnisse nutzen. Die modulare Konfliktauswahlfunktion ermöglicht es uns, die Art und Weise, wie wir die anfängliche Meinung festlegen, einfach auszutauschen; daher erfordert auch das Experimentieren mit anderen Ansätzen zur Konsensfindung nur geringfügige Anpassungen des Codes.

Als Sybil-Schutz werden die Stimmen nach cMana gewichtet. Die absoluten cMana-Werte liefern jedoch möglicherweise nicht genügend Informationen. Stattdessen verwenden wir aktives cMana, um das Gewicht eines Knotens im Verhältnis zu allen kürzlich aktiven Knoten auszudrücken. Daher ist aktives cMana eine entscheidende Komponente, die gründlich untersucht werden muss, um ihre Grenzen und Einschränkungen zu verstehen.

Kommunikationsebene

Die Vision

Bei herkömmlichen, auf Proof of Work basierenden Distributed-Ledger-Technologien (DLTs) wird das Recht, eine neue Nachricht in das Hauptbuch aufzunehmen, durch den Mining-Prozess garantiert, bei dem einer der Knoten nach Abschluss einer rechenintensiven Aufgabe gewählt wird. Als Anreiz für die Durchführung einer solchen Aufgabe erhält der siegreiche Knoten Transaktionsgebühren und Blockbelohnungen. Bei solchen DLTs dienen die Gebühren als Filter, um auszuwählen, welche Nachrichten dem Hauptbuch hinzugefügt werden sollen: In Zeiten der Überlastung wird der Betrag der Gebühren folglich größer.

IOTA hingegen soll das Rückgrat der aufstrebenden digitalen Wirtschaft sein, insbesondere der Maschinenwirtschaft. Daher ist ein Protokoll, das Gebühren und High-End-Geräte erfordert, weder machbar noch nachhaltig. Die Abschaffung der Gebühren erfordert jedoch die Einführung eines expliziten Mechanismus zur Bewältigung großer Verkehrsausbrüche.

In der IOTA Foundation verfolgen wir einen Ansatz, der vom „Standard-Internet“ inspiriert ist, um den IOTA Congestion Control Algorithm (ICCA) zu definieren. Im Gegensatz zu DLTs, die auf Proof of Work basieren, ermöglicht unser Ansatz die optimale Nutzung der Netzwerkressourcen, die nur durch die physischen Beschränkungen des Netzwerks in Bezug auf Bandbreite und Transaktionsverarbeitungsmöglichkeiten begrenzt sind. Darüber hinaus kann ICCA von Low-End-Knoten effizient genutzt werden, da es keine teuren Aufgaben oder Gebühren erfordert. Unsere Lösung bietet mehrere weitere grundlegende Funktionen:

  • Konsistenz: Alle Knoten schreiben letztendlich die gleichen Nachrichten in ihr lokales Hauptbuch.
  • Fairness: Der Netzzugang wird proportional zu einer „knappen Ressource“ gewährt, nämlich dem Zugangsmana (siehe unten).
  • Effizienz: Wenn die Nachfrage besteht, wird das volle Potenzial des Netzes genutzt.

Wo wir im Moment sind

Dieser Unterabschnitt beschreibt die Aktionen, die ein Knoten ausführen muss, wenn eine neue Nachricht erstellt wird und wenn eine Nachricht von einem Nachbarn empfangen wird, und die derzeit im IOTA 2.0 DevNet implementiert sind.

Erzeugung von Nachrichten

Eine Menge namens access Mana gibt den Knoten Schreibrechte. Aus Sicht des Benutzers bedeutet Access Mana einen bestimmten Durchsatz für den Knoten. Interessanterweise passt sich dieser Durchsatz an die aktuellen Verkehrsbedingungen an: Die Knoten erhöhen schrittweise ihre Nachrichtengenerierungsrate (Durchsatz) bis zu dem Punkt, an dem eine Überlastung festgestellt wird; sobald dies der Fall ist, wird der Durchsatz reduziert. Die Knoten erkennen eine Überlastung, indem sie die Anzahl ihrer eigenen Nachrichten in der Warteschleife in ihrem Ausgangspuffer betrachten.

Nachrichtenempfang

Nachdem eine neu empfangene solide Nachricht (siehe nächster Abschnitt) bestimmte Validierungsfilter (z. B. Signaturprüfung und syntaktische Validierung) durchlaufen hat, wird sie dem lokalen Hauptbuch hinzugefügt. Danach wird die Nachricht an den Postausgangspuffer angehängt, der von einem Scheduler verwaltet wird, um zu entscheiden, welche Nachricht zu den Tipps hinzugefügt und an die Nachbarn weitergegeben werden soll. Der Scheduler verwendet einen leichtgewichtigen Round-Robin-Algorithmus, um eine große Anzahl von Nachrichten gleichzeitig effizient zu verarbeiten. Kürzlich haben wir den Scheduler nach der Nachrichtenbuchung verschoben, um das Resynchronisationsverfahren zu optimieren.

Verfestigung

Vertiefung/Solidification ist der Prozess der Anforderung von Nachrichten, deren vergangener Konus einem Knoten noch nicht bekannt ist. Ähnlich verhält es sich bei Transaktionen: Die verbrauchten Outputs (Inputs) einer Transaktion müssen einem Knoten bekannt sein, damit die Transaktion ordnungsgemäß validiert werden kann. In der Vergangenheit verlangte das Protokoll, dass alle Eingaben einer Transaktion im Vergangenheitskegel der enthaltenen Nachricht liegen. Um zu überprüfen, ob sich etwas im Vergangenheitskegel befindet, muss man möglicherweise durch das Tangle laufen, was eine teure Operation ist und sich im DevNet als nicht praktikabel erwiesen hat. Aus diesem Grund wurde die erste Version eines anderen Ansatzes zur Verfestigung implementiert, der nicht nur das Erfordernis des „past cone“ beseitigt, sondern auch den Datenfluss vereinfacht und eine bessere Parallelisierung ermöglicht.

Der Weg nach vorn

Widerstand gegen Angriffe

Bei DLTs haben böswillige Knoten ein großes Interesse daran, das Funktionieren des Netzes zu beeinträchtigen. Aus diesem Grund muss jede Lösung gegen alle potenziellen Bedrohungen validiert werden. Wie wir experimentell bewiesen haben, ist ICCA resistent gegen Angriffe: Wenn Angreifer versuchen, einen schnelleren als den erlaubten Durchsatz zu erreichen, werden ihre Nachrichten von ehrlichen Knoten verzögert, da sie nicht gemäß dem aktuellen Zugriffs-Mana-Vektor eingeplant werden. Daher bleiben die vom Angreifer verschickten Nachrichten lange Zeit im Postausgang der ehrlichen Knoten. Obwohl dies die Leistung ehrlicher Nachrichten nicht beeinträchtigt, ist es aus zwei Gründen wichtig, solche bösartigen Verhaltensweisen zu erkennen: (i) der Angreifer kann die Anzahl der Nachrichten in den Postausgängen seiner Nachbarn aufblähen, so dass ihnen die Ressourcen ausgehen; (ii) ehrliche Knoten können zusätzlich zu den böswilligen Nachrichten noch weitere angehängt haben, was zu inkonsistenten Ledgern auf allen Knoten führt. Um diese Probleme zu überwinden, werden wir böswillige Knoten auf eine schwarze Liste setzen, indem wir ihre Nachrichten verwerfen. Bösartige Ströme werden erkannt, wenn die Anzahl ihrer Nachrichten im Postausgang einen bestimmten Schwellenwert überschreitet. Die Art und Weise, wie dieser Schwellenwert festgelegt wird (der für die schnelle Erkennung von bösartigem Verhalten entscheidend ist, ohne dass ehrliche Knoten auf die schwarze Liste gesetzt werden), wurde in einem kürzlich erschienenen Artikel beschrieben und wird bald in unserem DevNet implementiert.

Es ist auch wichtig, eine genaue Einschätzung der Gültigkeit der Zeitstempel in den Nachrichten zu haben. So sollten beispielsweise alte Nachrichten nicht in den Scheduler aufgenommen werden, da sie mit hoher Wahrscheinlichkeit bereits von den Nachbarn empfangen worden sind. Auch das Anhängen an alte Nachrichten ist unerwünscht, da dies die Bestätigungszeit für neue Nachrichten erhöhen würde (wir gehen davon aus, dass alte Nachrichten bereits validiert wurden). Darüber hinaus werden genaue Zeitstempel benötigt, um eine schnelle Resynchronisierung zu gewährleisten und Angreifer davon abzuhalten, die Leistung des Protokolls zu beeinträchtigen. Wir untersuchen derzeit eine Metrik, die so genannte Inklusionsbewertung, die die Wahrscheinlichkeit bewertet, dass eine Nachricht als „neu“ und bereit zur Einplanung angesehen wird: Diese Metrik berücksichtigt den Zeitstempel der Nachricht und die Belegung der Nachrichten durch den Scheduler des ausstellenden Knotens.

Benutzererfahrung

Der Durchsatz eines Knotens wird durch den Rate Setter Algorithmus reguliert. Das bedeutet, dass die Knoten im Falle einer Überlastung nicht kontinuierlich Nachrichten generieren können, da sie von ICCA bestraft werden würden. Wir arbeiten derzeit an der Bereitstellung von Schätzungen des Knotendurchsatzes, der als Funktion des Zugriffs-Mana-Vektors berechnet wird. Mit einer vernünftigen Schätzung wäre es möglich, die folgende Frage zu beantworten: Angenommen, ein Benutzer (eine Wallet oder ein Knoten) hat eine neue Nachricht zu veröffentlichen: Welcher Knoten sollte gewählt werden, damit diese Nachricht schnell zum IOTA-Ledger hinzugefügt wird? Diese Forschungsrichtung versucht, neue Nachrichten den Knoten zuzuweisen, die zu einem bestimmten Zeitpunkt weniger ausgelastet sind. Wir haben diese Herausforderung als Optimierungsproblem formuliert und testen einige vorgeschlagene Strategien, die auf der Belegung der Nachrichtenersteller oder der Verzögerung pro Knoten basieren.

Andererseits ist zu bedenken, dass die Zeit, die für die Zustellung einer Nachricht an alle Knoten benötigt wird, (fast) unabhängig von der Zugriffs-Mana des ausstellenden Knotens ist. Dies bedeutet, dass der Zugriffs-Mana-Vektor nur die Rate regelt, mit der neue Nachrichten erstellt werden, aber keinen Einfluss auf die Nutzbarkeit des Netzes hat. Im Durchschnitt dürften die Verzögerungen relativ gering sein: Wir schätzen, dass die Nachrichten unter normalen Bedingungen nur Bruchteile von Sekunden im Scheduler verbleiben; bei hohem Verkehrsaufkommen erhöht sich diese Verzögerung leicht. Im aktuellen Vorschlag gehen wir mit starkem Datenverkehr um, indem wir einen minimalen Mana-Schwellenwert festlegen, der von den Knoten benötigt wird, um Nachrichten ausgeben zu können: Wenn dieser Schwellenwert niedriger ist, können trivialerweise mehr Knoten Nachrichten ausgeben und potenziell Staus verursachen. Wir arbeiten derzeit daran, diesen Schwellenwert opportunistisch an das aktuelle Verkehrsaufkommen anzupassen.

Schnappschüsse

Das Tangle kann sehr groß werden, und nicht jeder Nutzer wird in der Lage sein, seine gesamte Geschichte bis zurück zur Entstehung zu verfolgen. Daher sollten lokale Schnappschüsse es den Knoten ermöglichen, ihre Datenbank sicher zu bereinigen, d. h. ausreichend alte Daten können gelöscht werden, ohne die Sicherheit des Netzes zu beeinträchtigen. Schnappschüsse hängen von vielen Teilen des Protokolls ab und haben direkte Auswirkungen auf die Partitionstoleranz, da Partitionen nicht über lokale Schnappschüsse hinaus zusammengeführt werden können. Sie stehen auch in engem Zusammenhang mit der vertrauenslosen Synchronisierung, da Knoten ohne die gesamte Historie, die bis zur Entstehung zurückreicht, den Zustand des Ledgers nicht ohne einen zusätzlichen Mechanismus, wie z. B. Merkle-Baum oder polynomielle Zusagen, überprüfen können. Diese Themen werden derzeit erforscht.

Schlussfolgerung

Das IOTA 2.0 DevNet hat unserem Team wertvolle Einblicke in unser Bestreben gegeben, das IOTA Netzwerk mit einem führerlosen, gebührenfreien und erlaubnisfreien Distributed Ledger Protokoll vollständig zu dezentralisieren.

Wir haben große Fortschritte in der GoShimmer-Implementierung gemacht, indem wir einige der jüngsten Verbesserungen (insbesondere beim Konsens) hinzugefügt und begonnen haben, die Codebasis zu überarbeiten. Wir freuen uns über diesen iterativen Fortschritt auf dem Weg zu einer stabilen Netzwerkimplementierung, aber es gibt noch einige wichtige Forschungsfragen, die unser Team evaluieren, validieren und dann in GoShimmer implementieren muss. Wir sind zuversichtlich, dass diese Änderungen das Protokoll insgesamt sicherer, einfacher zu implementieren und schneller zu nutzen machen werden.

Sobald wir alle erforderlichen Änderungen implementiert haben, werden wir das IOTA 2.0 DevNet aktualisieren und die IOTA-Gemeinschaft zusammen mit unserem Team und unseren Forschungspartnern einladen, sich zu beteiligen und mit dem verbesserten Protokoll zu experimentieren. Auf der Grundlage der Ergebnisse und des Feedbacks aus diesem Netzwerk wird unser Team dann an der Fertigstellung der IOTA 2.0 Spezifikationen arbeiten und mit der Entwicklung einer stabilen Implementierung in Go und Rust beginnen. Dies wird dann zum Start eines incentivierten Testnetzes und schließlich zum „Coordicide“ des IOTA Mainnet führen.

Original by IOTA Foundation: https://blog.iota.org/iota-2-0-details-on-current-status-and-outlook/

IOTA Native Digitale Assets – DevNet Version

TL;DR

Mit dem heutigen Start des IOTA 2.0 DevNet haben wir offiziell auch unser Digital Assets Framework im DevNet veröffentlicht. Es ist Zeit zu tokenisieren, zu NFT, und Spaß zu haben, um magische dezentrale Internet-Token zu senden. Wir haben eine neue Wallet für das IOTA 2.0 DevNet gebaut, um unserer Community die Möglichkeit zu geben, mit digitalen Assets zu experimentieren. Für Entwickler können Sie die Dokumentation hier finden.

Wie bereits angekündigt, haben wir eine frühe Wallet zum Testen und zur Teilnahme am IOTA 2.0 DevNet vorbereitet. Sie basiert auf einer Wallet, die unsere Forschungsabteilung und die Entwickler des Ökosystems verwendet haben, um IOTA 2.0 zu testen. Ihr Zweck ist es, einen ersten Einblick zu geben, wie einfach es ist, Token-Typen zu prägen und verschiedene Arten von digitalen Assets im IOTA 2.0 DevNet zu erstellen. Bitte beachten Sie, dass diese Version nur für Test- und Entwicklungszwecke gedacht ist und ausschließlich auf dem IOTA 2.0 DevNet funktioniert.

Warum sind wir so begeistert von Digital Assets auf IOTA? Sind bestehende DLT-Lösungen nicht gut genug? Nein, das sind sie nicht! Sie haben Gebühren und verschwenden Strom, sind typischerweise nicht skalierbar und sind oft weniger sicher als native Token. Wir haben digitale Assets mit Blick auf die Anforderungen unseres Ökosystems und unserer Industriepartner neu durchdacht. IOTA wird die erste DLT-Infrastruktur für die Erstellung von digitalen Assets bereitstellen, die nativ gesichert sind (d.h. so sicher und skalierbar wie der native IOTA-Token), ohne dass Gebühren anfallen oder Strom verschwendet wird.

DevNet Wallet download

Klingt gut? Lassen Sie uns tokenisieren!

Im Gegensatz zu anderen DLT-Netzwerken wird die Erstellung von digitalen Vermögenswerten im IOTA-Netzwerk immer gefühlslos sein. Für 1 MIOTA erhalten Nutzer 1.000.000 Token für das digitale Asset, das sie erstellen möchten. Mit unserer Test-Wallet für das IOTA 2.0 DevNet kann jeder ausprobieren, wie einfach es sein wird, digitale Assets auf IOTA 2.0 zu erstellen. Wir haben eine Registry eingerichtet, die alle im DevNet erstellten digitalen Assets auflistet: https://v2.iota.org/coin-registry

7 Schritte zur Erstellung eines nativen digitalen Assets im IOTA 2.0 DevNet

  1. Laden Sie die Wallet von der IOTA 2.0 DevNet-Website herunter: https://v2.iota.org.
  2. Öffnen Sie die App, klicken Sie auf die Schaltfläche „New Wallet“ und erstellen Sie Ihre eigene Test-Wallet (Je nach Ihren Sicherheitseinstellungen müssen Sie die Ausführung der App eventuell zulassen).
  3. Kopieren Sie Ihren Seed und bewahren Sie ihn sicher auf. Klicken Sie auf die Schaltfläche „OK“.
  4. Fordern Sie Geld vom Faucet an, indem Sie auf die Schaltfläche „Geld anfordern“ klicken (dies kann je nach Netzwerkauslastung zwischen einigen Sekunden und mehreren Minuten dauern).
  5. Erstellen Sie Ihr eigenes, natives digitales Asset, indem Sie testnet-Token „taggen“: Geben Sie Ihren eigenen Asset-Namen und Ihr Symbol ein und klicken Sie auf die Schaltfläche „OK“.
  6. Airdrop-Zeit! Senden Sie Ihre neu erstellten Token an jeden, den Sie mögen.
  7. Zusätzlich: Senden Sie Ihre Adresse an andere und erhalten Sie deren digitale Assets.

Wir sind gespannt, wie viele kreative digitale Assets auf der IOTA 2.0 DevNet-Registry entstehen werden.

Die Wallet ist nur eine einfache grafische Benutzeroberfläche, die unsere Forscher und Ökosystem-Entwickler nutzen, um die IOTA 2.0-Architektur im DevNet zu testen. Darüber hinaus ist die IOTA 2.0 DevNet Registry, in der die Namen der digitalen Assets gespeichert werden, derzeit eine Testimplementierung der zukünftigen Token Foundry. Angelo Capossele hat es für die Community eingerichtet, um digitale Assets unter Verwendung von menschenlesbaren Namen anstelle von hexadezimalen IDs zu erstellen. Der vollständig dezentralisierte IOTA 2.0 Ledger verwaltet bereits die digitalen Assets selbst. Vorerst werden ihre Namen in einem zentralen Register gespeichert. Wir ermutigen die Community, weitere Verbesserungen an der Wallet zu entwickeln und an neuen Innovationen mit unserem Digital Assets Framework zu arbeiten. Sie können die gesamte Dokumentation und die Open-Source-Projekte hier finden.

In der Zukunft wird die Firefly-Wallet das IOTA 2.0-Protokoll und das digitale Asset-Register unterstützen. Die Pflege von Asset-Namen wird vollständig dezentralisiert sein. Sie können bereits einige witzige digitale Assets sehen, die von Mitgliedern der IOTA Foundation und Community-Mitgliedern erstellt wurden, die sofort die Updates unserer Github-Repos gesehen haben – jeder scheint heutzutage eine Münze besitzen zu wollen. Glücklicherweise kostet ihre Erstellung mit IOTA nichts.

Digitale Vermögenswerte: Was sie sind und warum sie spannend sind

Durch die Digitalisierung von digitalen oder physischen Vermögenswerten wie Edelmetallen, Immobilien, Wertpapieren oder Kunstwerken können Vermögenswerte als digitale Token gespeichert (tokenisiert) werden. Die tokenisierten Vermögenswerte können dann gehandelt werden – wobei der Token als digitale, übertragbare Repräsentation dieses Vermögenswerts fungiert. Tokenisierte Assets werden in der Regel auf einem DLT aufbewahrt und übertragen, da sie ein Maß an Sicherheit bieten, das keine andere Architektur bietet.

Das IOTA-Protokoll ist die digitale Infrastrukturebene für unsere physische Welt, die Menschen und Maschinen mit einem „Vertrauens“-Protokoll ausstattet – unveränderliche und überprüfbare Daten, gebührenfreie Wertübertragungen und die Schaffung digitaler Vermögenswerte. Diese Eigenschaften zusammen ermöglichen digitale Zwillinge, die mit physischen Vermögenswerten verknüpft sind, wobei alle Daten- und Werteflüsse innerhalb dieser Systeme digital abgebildet werden und völlig autonom ablaufen. Das ist es, was letztendlich zur Schaffung der Machine Economy führen wird.

Das IOTA-Protokoll und unser Framework für digitale Vermögenswerte ist nicht nur für physische Vermögenswerte nützlich, sondern auch für jede Art von Tokenisierung, einschließlich anderer Kryptowährungen, Community-Token, digitaler Rechte, Lizenzen und Kunstwerke.

Insbesondere Kunstwerke waren in letzter Zeit in den Nachrichten. Kunst kann über nicht-fungible Token (NFTs) digitalisiert werden: Ein Gemälde bleibt in physischer Form an der Wand und kann von Betrachtern bewundert werden, aber ein tokenisiertes, digitales Kunstwerk oder die Darstellung eines physischen Kunstwerks kann entweder in Teilen oder als Ganzes gehandelt werden. Ohne das Gemälde von der Wand nehmen zu müssen oder das Eigentum in Form eines papierbasierten Vertrages zu überschreiben, kann der Vermögenswert übertragen werden oder sogar geteiltes Eigentum haben.

Ein wesentlicher Vorteil der Tokenisierung besteht darin, dass einzelne Assets, wie z.B. Immobilien, auf Bruchteilsbasis gehandelt werden können. Somit ist es für Investoren möglich, Anteile dieser Assets in kleineren Mengen zu erwerben und somit ganze Assetklassen für Investoren zugänglicher zu machen. Ermöglicht wird dies durch DLT, die die Zwischenhändler ausschaltet und so die Kosten senkt und die Teilhabe an der Wirtschaft weiter demokratisiert.

Original by IOTA Foundation: https://blog.iota.org/iota-native-digital-assets-devnet/

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

TL;DR

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

Tangle Explorer

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

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

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

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

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

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

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

Die totale Freiheit.

Neue Website für das Devnet

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

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

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

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

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

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

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

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

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

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

Einführung von Pollen: Das erste dezentralisierte Testnetz für IOTA 2.0

Original by IOTA Foundation: https://blog.iota.org/introducing-pollen-the-first-decentralized-testnet-for-iota-2-0-349f63f509a1 (20.06.2020)

Nach Jahren intensiver Forschung, rigoroser Tests und unermüdlicher Bemühungen unserer Ingenieure sind wir stolz darauf, endlich alle zur Teilnahme an diesem bedeutenden Meilenstein für das IOTA-Projekt einladen zu können. Pollen markiert den Beginn des weltweit ersten wirklich dezentralisierten, skalierbaren und gebührenfreien Distributed Ledger, das von Anfang an das Versprechen der IOTA war. Pollen ist die erste Phase der dreiteiligen Freigabestrategie von IOTA, die in unserem koordinatorenlosen, produktionsbereiten Netzwerk gipfeln wird: IOTA 2.0. Pollen ist ein sich rasch entwickelndes Forschungs-Testbed, in dem die Gemeinschaft, Forscher und Ingenieure die Konzepte von IOTA 2.0 testen und validieren können.

Sie können die neue Version herunterladen und das vollständige Changelog hier einsehen.

Pollen stellt ein wichtiges Upgrade im Vergleich zur vorherigen Version Alphanet v0.1.3 dar. Wir zählen ungefähr 60000 Hinzufügungen und 25000 Löschungen in der Codebasis. Wir haben die Grundlage für ein funktionales Netzwerk ohne Koordinator geschaffen. Von hier aus werden iterative Verbesserungen des Codes Pollen in den endgültigen, funktionsreichen Release-Kandidaten für IOTA 2.0 verwandeln.IOTA Update 2.0

Die heutige Veröffentlichung enthält die folgenden Aktualisierungen der Hauptfunktionen:

  • Fast Probabilistic Consensus – der neue Konsens-Algorithmus für IOTA für ein dezentralisiertes Netzwerk. Sie können das Forschungspapier hier lesen
  • Werttransaktionen – Netzwerkteilnehmer können jetzt einen automatisierten Hahn benutzen, um Tokens zu empfangen, Werttransaktionen zu senden (über eine Brieftasche) und die Konfliktlösung im Netzwerk zu testen
  • Tokenisierte Vermögenswerte – Einzelpersonen können jetzt IOTA-Token mit verschiedenen Attributen „einfärben“, die reale Vermögenswerte wie Gebäude, IoT-Geräte oder sogar Firmenkapital repräsentieren
  • Prometheus- und Grafana-Integration – Knotenbetreiber können jetzt mehrere Metriken überwachen, indem sie ein Grafana-Dashboard aktivieren
  • Feeless dApps – diese Version beinhaltet eine zukünftige Fähigkeit für das IOTA-Ökosystem: die Entwicklung von gefühllosen dezentralisierten Anwendungen

Wir haben auch bereits früher veröffentlichte Funktionen der letzten Version von Alphanet verbessert. Dazu gehören eine verbesserte Stabilität und Instrumentierung sowohl des Autopeering- als auch des Klatschmoduls. Wir haben ein erweitertes Dashboard mit einem brandneuen Tangle-Explorer und Visualizer gebaut. Der Analyseserver wurde von Grund auf neu gestaltet, um nicht nur die Visualisierung und Analyse des Autopeering-Netzwerks zu unterstützen, sondern auch die Echtzeit-Aktualisierung des Fast Probabilistic Consensus-Protokolls in Aktion.

Dashboard GoShimmer

Unser Interesse an diesem Testnetz wird sich auf das Gesamtverhalten des Netzwerks konzentrieren und nicht auf seine rohe Leistung und Benutzererfahrung. Wir werden in künftigen Iterationen schrittweise an Optimierungen und Verbesserungen arbeiten. Was die Implementierung betrifft, so stecken die neu eingeführten Komponenten noch in den Kinderschuhen (z.B. Brieftaschenbibliothek, FPC) und einige Komponenten sind noch nicht optimiert (z.B. Klatsch und Tratsch). Bitte beachten Sie, dass wir das Netzwerk von Zeit zu Zeit zurücksetzen werden, bis lokale Snapshots implementiert sind, um zu verhindern, dass die Datenbank zu stark wächst und um potentiell brechende Änderungen einzuführen.

Mit dieser neuen Version haben wir eine neue Architektur eingeführt, die aus drei separaten Schichten besteht: Der Netzwerk-, Kommunikations- und Anwendungsschicht. Diese neue Architektur wird Unterstützung für zukünftige Funktionen wie Tokenisierung, skalierbare intelligente Verträge, Feeless dApps und Sharding bieten.

IOTA Update 2.0

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 die Paketübertragung 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. Um mehr darüber zu erfahren, können Sie unseren Blogpost „A Guide to Upcoming IOTA 2.0 Terminology“ lesen.

IOTA Pollen Update

Der Kern von Pollen besteht aus diesen Merkmalen:

  • Neues Nachrichten-Layout – Jede Nachricht enthält die Hashes der Eltern, Ausgabeinformationen (Ausgabeknoten-ID, Zeitstempel usw.), eine Nutzlast, den PoW, eine Nonce und die Signatur des Ausgabeknotens
  • Binär – Da jetzt alles binär ist, haben wir eine neue konfigurierbare Proof of Work (PoW)-Bibliothek entwickelt, die in zukünftigen und iterativen Versionen auf unseren adaptiven PoW-Mechanismus umgestellt wird. 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
  • Ledger-Zustand & UTXO – Diese GoShimmer-Version wird mit einem völlig neuen Ledger-Zustand ausgeliefert, der auf einer erweiterten Version von UTXO basiert – dem auf Parallel-Realität basierenden Ledger-Zustand. Durch die Entkopplung von Konsens und Saldenverfolgung ermöglichen wir ein unübertroffenes Maß an Flexibilität und reduzieren die Komplexität der Nachrichten massiv, indem nur über Konflikte abgestimmt wird
  • FPC – Das Fast Probabilistic Consensus-Protokoll treibt den Konsens unseres Testnetzes voran. Für diese erste „Vanille“-Version des Protokolls lassen wir Knoten FPC auslösen, falls bei der Erstarrung Konflikte festgestellt werden. Die ersten Meinungen basieren auf den Ankunftszeiten der Nachrichten. Neue Knoten, die online gehen, erhalten die Nachrichten jedoch nicht in der richtigen Reihenfolge und können daher zu einer falschen Meinung kommen. In zukünftigen Versionen werden wir einen Synchronisationsmechanismus hinzufügen, der diese Diskrepanzen verhindern wird
  • Zufälligkeit – Die von FPC verwendete Zufälligkeit wird lokal von jedem Knoten auf der Grundlage des Unix-Zeitstempels generiert. Genauer gesagt wird jede Minute in Epochen von 5 Sekunden eingeteilt. Es liegt auf der Hand, dass die durch diese Methode erzeugte Zufallszahlenfolge vorhersehbar und somit unsicher ist. Aufgrund ihrer Einfachheit und Unabhängigkeit vom Netzwerk oder einer anderen Komponente eignet sie sich jedoch sehr gut für einen ersten Test des FPC-Verhaltens. Die nächste Iteration wird sich auf ein gemeindebasiertes Komitee dRNG stützen
  • Lokales Dashboard – Wir haben das Dashboard um einen brandneuen Tangle-Explorer, Tangle Visualizer und Faucet bereichert
  • Grafana-Dashboard über Prometheus – Jeder Knotenbetreiber kann das Prometheus-Plugin aktivieren und Grafana zur Anzeige von Metriken zum Netzwerkverkehr, Autopeering-Status, FPC-Statistiken und mehr verwenden
  • Netzwerk-Verzögerungsanwendung – Wir werden periodisch eine spezifische Netzwerk-Verzögerungsmeldung an das gesamte Netzwerk senden. Dadurch werden die Knoten, die sie empfangen, veranlasst, den Zeitstempel des Empfangs an einen zentralen Logger zu senden, so dass wir periodisch die durchschnittliche netzwerkweite Verzögerung beurteilen und diese Information zur Optimierung der Abstimmung der FPC-Parameter verwenden können.
  • Brieftaschenbibliothek – Wir stellen eine sehr einfache Brieftaschenbibliothek zur Verfügung, damit Entwickler und Tester Token verschieben können. Sie können gerne mit einer Wallet-UI beitragen, die auf dieser Bibliothek basiert
  • (Faucet)Zapfhahn-App – Das GoShimmer-Dashboard wird mit einer Zapfhahn-Sektion geliefert, so dass Sie Token an eine bestimmte Adresse anfordern können
  • Client-Bibliothek & API – Tester, Entwickler und Knotenbetreiber können über die Client-Bibliothek und/oder API mit einem GoShimmer-Knoten interagieren. Um mehr darüber zu erfahren, können Sie sich auf unserer Wiki-Seite informieren.
  • Analyse-Server – Wir haben auch den Analyse-Server verbessert. Dieser zeigt den Gesamtnetzwerkstatus an und hat einen brandneuen Abschnitt, der den Gesamtnetzwerkkonsens anzeigt – ein Echtzeit-Update des FPC-Ergebnisses zu jedem Konflikt. Diese Ergebnisse werden in einer Datenbank gespeichert, so dass wir zusammen mit unserer Gemeinschaft genügend experimentelle Daten sammeln können, um sie mit unseren früheren, durch Simulationen erzielten Ergebnissen zu vergleichen.

Wir haben ein Wiki geschrieben, um der Gemeinschaft die Möglichkeit zu geben, diese Version des Pollen-Testnetzes auszuprobieren und mehr über sie zu erfahren:

Mit unserem nächsten großen Release, genannt Nectar, werden die übrigen Komponenten (wie Mana, Ratenkontrolle, adaptives PoW, um nur einige zu nennen) für ein voll funktionsfähiges, mit Anreizen versehenes Testnetz auf unser Testnetz freigegeben.

Pollen ist ein wichtiger Meilenstein für IOTA 2.0. Es ist ein wesentlicher Schritt zur Erprobung der Kernideen des vollständig dezentralisierten IOTA-Netzes.

Wir freuen uns darauf, Sie auf dieser aufregenden Reise mit Pollen mit uns zu begleiten, und wir hoffen, dass Sie die Entwicklung dieses Projekts ebenso genießen werden wie wir. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im Kanal #tanglemath auf unserer Discord. Sie können auch an der #goshimmer-Diskussion auf Discord teilnehmen.

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!