Einleitung

Das dritte einfachIOTA Magazin ist da! Dieses Mal sind wir online und das Thema ist das neue IOTA Chrysalis Netzwerk!

Viel Spaß beim Lesen!

Schwerpunkt - Chrysalis

Am 28. April 2021 war es endlich so weit - das Chrysalis Netzwerk (IOTA 1.5) ging online.

Was nun alles neu ist und wie du deine Token von dem alten Netzwerk in das neue Chrysalis Netzwerk transferieren kannst, erfährst du auf den nächsten Seiten!

Was ist Chrysalis?

Die IOTA Foundation ist auf dem besten Weg, ihr Kernziel eines koordinatorfreien und damit dezentralen IOTA-Mainnets zu verwirklichen. In der Grundlagenforschung zum Coordicide und der Umsetzung in GoShimmer wurden erhebliche Fortschritte erzielt. Einige Coordicide-Module wurden bereits dem IOTA-Mainnet hinzugefügt, einschließlich Autopeering und Object-Storage. Bevor der Coordicide abgeschlossen werden kann, soll das IOTA-Mainnet zuvor weiter optimiert und eine unternehmenstaugliche Lösung für das Ökosystem bereitgestellt werden.

Diese Zwischenaktualisierung läuft unter dem Projektnamen „Chrysalis“. Eine Chrysalis (dt. Puppe) ist die Form, die eine Raupe annimmt, bevor sie als voll ausgebildete Motte oder als Schmetterling aus ihrem Kokon hervortritt. Im Kontext von IOTA steht Chrysalis für die Transformation des Mainnets in eine ausgereifte Form, um IOTA zur Produktionsreife zu bringen.

Chrysalis war das umfangreichste Update in der Geschichte von IOTA; es betraf alle Aspekte des Protokolls, Bibliotheken, Wallets und Software-Implementierungen, die von der IOTA Foundation entwickelt wurden. Mit dem Update des Tangles wurden technische Probleme und Ineffizienzen behoben und wesentliche Verbesserungen in Bezug auf Leistung, Stabilität, Zuverlässigkeit und Sicherheit implementiert. Exotische Aspekte des Protokolls wurden durch etablierte Standards ersetzt und es wurde eine Fülle von neuen Werkzeugen für Entwickler, Unternehmen und Börsen bereitgestellt.

Das Chrysalis-Update enthält bereits viele Aspekte, die für die Entfernung des Koordinators erforderlich sind. Viele grundlegende Änderungen wurden bewusst frühzeitig vorgenommen, sodass nur noch wenige Anpassungen für das eigentliche Coordicide-Ereignis nötig sein werden. Mit diesen wichtigen Protokollverbesserungen wurde der Prozess der Adoption deutlich beschleunigt, weil es Unternehmen, Entwicklern, Börsen, Custodians und anderen Partnern bereits heute ermöglicht, mit der Implementierung ihrer Lösungen zu beginnen, da es keine grundlegenden Protokolländerungen (Signaturschema, Ledger-State, etc.) mehr geben wird.

Was ist neu?

EdDSA Support: Das Signaturschema Ed25519 wurde eingeführt und die alte Winternitz One-Time Signature (W-OTS) vollständig ersetzt.

Atomic Transactions: Das Bundle-Konstrukt wurde entfernt und durch einfachere Atomic Transaktionen ersetzt.

UTXO Model: Das aktuelle Guthaben-Modell zur Verfolgung von Adressen wurde auf das UTXO-Modell umgestellt.

Autopeering: Ein Mechanismus, der es den Nodes ermöglicht, automatisch Nachbarn auszuwählen, ohne dass der Node Operator manuell eingreifen muss.

White-Flag: Ein einfacherer Ansatz zur Berechnung der Guthaben, bei dem Konflikte besser vermieden werden.

Improved-Tip-Selection (URTS): Ein deutlich schnellerer und effizienterer Ansatz in der Node-Software, um unbestätigte Transaktionen auszuwählen.

New Milestone Selection: Dieser Mechanismus ermöglicht dem Netzwerk, höhere CTPS (Confirmed Transactions Per Second, Bestätigte Transaktionen pro Sekunde) durchzuführen und steigert dabei die Recheneffizienz.

Binary Transaction Layout: Die ehemals ternären Transaktionen wurde auf binär umgestellt.

Die Ergebnisse des vollständigen Chrysalis Updates sind:

• Transaktionsbestätigungszeiten von etwa 10 Sekunden
• Transaktionen müssen nur noch sehr selten neu angehängt (reattached) werden
• Eine beträchtliche Erhöhung der Message Per Second (MPS) im Mainnet
• Leistungs- und Zuverlässigkeitsverbesserungen für Nodes
• Reduzierte Node-Setupzeiten durch Autopeering
• Wiederverwendbare Adressen (reusable addresses) und Unterstützung von Standard-Kryptographie (EdDSA), wodurch Hardware-Lösungen für alle wichtigen Architekturen möglich werden
• Vereinfachtes Transaktionslayout und eine Verringerung der Transaktionsgröße, wodurch die Leistung weiter gesteigert wurde
• Einführung neuer Features, wie bspw. tokenisierter Vermögenswerte (Digital Assets)
• Signifikante Verbesserungen der Nutzbarkeit und Zuverlässigkeit von IOTA

Der Weg zu Chrysalis

Eine der Hauptaufgaben der IOTA Foundation besteht darin, eine Entwicklungs-Roadmap, die mit der Strategie der Foundation übereinstimmt, zu definieren sowie umzusetzen und dadurch die Produktionsbereitschaft und Akzeptanz des IOTA Protokolls zu erreichen.

Das IOTA-Mainnet ist seit 2016 in Betrieb und die gesamte Engineering-Strategie hat sich (basierend auf der Nachfrage und dem Feedback aus der Branche) erheblich weiterentwickelt.

Die Fortschritte in der Coordicide-Forschung haben dazu geführt, dass viele Konzepte identifiziert wurden, die schon jetzt in das aktuelle IOTA-Mainnet implementiert wurden, um den Benutzern des Protokolls schon vor dem Coordicide einen erheblichen Mehrwert zu bieten. Unsere Entwicklungsstrategie bezüglich Chrysalis wurde angepasst. In diesem Zusammenhang konnten eine Reihe von Upgrades des Protokolls durchgeführt werden, um die Produktionsfähigkeit (Production Readiness) des Protokolls schon vor dem Coordicide zu gewährleisten.

Der Vorteil dieses Ansatzes besteht darin, dass viele Protokolleigenschaften, die gleich oder fast gleich zum Coordicide-Netzwerk sein werden, bereits heute implementiert sind. Dies führt dazu, dass der Coordicide viel einfacher umgesetzt werden kann und bereits frühzeitig ein besseres Set an Entwicklertools zur Verfügung steht.

Die beabsichtigten Ergebnisse für Chrysalis:

• Einfacherer Übergang zum Coordicide – Da der Coordicide erhebliche Fortschritte gemacht hat, können wir sicherstellen, dass alle Entwickler und Unternehmen, die ihre Produkte auf Chrysalis aufbauen, einen möglichst reibungslosen Übergang zum Coordicide Netzwerk haben werden.
• Erhebliche Leistungsverbesserungen - Mit den von Chrysalis eingeführten Änderungen haben wir eine wesentliche Verbesserung der Skalierbarkeit und Zuverlässigkeit des IOTA Mainnets erreicht.
• Verbesserte Entwickler- und Benutzererfahrung - Die neuen Protokollfunktionen und die neuen Bibliotheken, auf denen man aufbauen kann sowie die neue Brieftasche (Wallet) machen IOTA zu einer der besten Plattformen. Diese Neuerungen beseitigen konkrete Schwierigkeiten, die Entwickler heute erleben, während die Lösungen, die auf dem IOTA Protokoll aufbauen, zugleich eine bessere Benutzererfahrung bieten.
• Beschleunigte Adaption - Chrysalis hat IOTA 'Enterprise-Ready' gemacht. Es handelt sich dabei um ein zukunftssicheres, stabiles Protokoll mit einem zuverlässigen Satz von Entwicklertools und Frameworks, die es Startups, Unternehmen und Regierungen schon jetzt ermöglichen, Produkte zu entwickeln und auf den Markt zu bringen, welche auch zukünftig von IOTA unterstützt werden.

Die Phasen von Chrysalis

Das Chrysalis-Upgrade war ein komplexes Unterfangen. Wir mussten eine Reihe verschiedener Produkte koordinieren, um einen reibungslosen Übergang für die aktuellen Benutzer und Partner von IOTA zu gewährleisten. Neben der Core-Node-Software mussten wir auch unsere Wallet-Software, unsere Bibliotheken und die gesamte Infrastruktur aktualisieren.

Eine weitere wichtige Anforderung war es, den einfachen Übergang zum zukünftigen Coordicide-Netzwerk zu gewährleisten. Durch die sorgfältige Planung der dabei eingeführten "Breaking Changes" und die Unterstützung unserer Entwicklertools stellten wir sicher, dass unser wachsendes Ökosystem aus Entwicklern, Startups und Unternehmen zuverlässig neue innovative Produkte auf IOTA entwickeln und auf den Markt bringen kann.

Der Plan zur Umsetzung von Chrysalis gliederte sich in zwei Phasen.

Die erste Phase bestand aus einer verbesserten Tip-Selection-Auswahl (URTS), einer verbesserten Meilensteinauswahl und aus einem White-Flag Ansatz. Diese Verbesserungen wurden nach und nach in die Nodesoftware implementiert. Diese erste Phase erforderte ein Upgrade aller Nodes, einschließlich die des Koordinators. Sie erforderte allerdings keinen Snapshot.

Die erste Phase von Chrysalis führte zu:

• Transaktionsbestätigungszeiten von etwa 10 Sekunden
• Transaktionen, die stabil verarbeitet werden und nur noch selten erneut an den Tangle angehängt (reattached) werden müssen
• Einem erheblichen Anstieg an TPS (Transaktionen pro Sekunde)
• Leistungs- und Zuverlässigkeitsverbesserungen für die Nodes

Die zweite Phase von Chrysalis bestand aus der Übernahme und/oder Implementierung von UTXO, atomaren Transaktionen, wiederverwendbaren Adressen (Ed25519), einem Übergang zum binären Transaktionslayout und einem neuen Satz an Client-Bibliotheken und Entwicklertools. Diese stellten wesentliche Änderungen des Kernprotokolls und der Art und Weise dar, wie Transaktionen strukturiert und verarbeitet werden. Sobald alles getestet, validiert und geprüft war, hatte die IOTA Foundation ein neues Chrysalis-Netzwerk eingerichtet. Das aktuelle Legacy-Netzwerk bleibt parallel über einen längeren Zeitraum betriebsbereit. Dies ermöglicht es Benutzern, Börsen und Partnern nach Belieben zum Chrysalis-Netzwerk zu migrieren. Die Migration ist zeitlich nicht begrenzt.

Die zweite Phase von Chrysalis bestand aus:

• Wiederverwendbaren Adressen und die Unterstützung von Standardkryptografie (EdDSA), wodurch eine effizientere Hardwareunterstützung für alle wichtigen Architekturen möglich ist
• Einem vereinfachten Transaktionslayout und einer Reduzierung der Transaktionsgröße, wodurch Leistung und Effizienz weiter gesteigert werden konnten
• Deutlichen Verbesserungen in der Benutzerfreundlichkeit und Zuverlässigkeit von IOTA
• Einem Wechsel vom Kontenmodell zu einem UTXO-basierten Modell

Die Einführung von wiederverwendbaren Adressen war eine wichtige Änderung für IOTA Token-Inhaber. Dies hat die Benutzerfreundlichkeit von IOTA erheblich verbessert und macht die Integration in neue Börsen, Wallets und Zahlungssysteme viel einfacher. Mit Chrysalis wurde eine neue Wallet namens Firefly veröffentlicht. Diese Wallet ermöglicht den Token-Inhabern einen einfachen Übergang vom aktuellen WOTS-Adressschema zum neuen EdDSA-Schema.

Unser Ziel war es, diesen Übergang für alle Personen im IOTA-Ökosystem so nahtlos wie möglich zu gestalten. Dazu gehörten zum einen eine Vielzahl von Verbesserungen und Aktualisierungen unserer Bibliotheken und Software-Lösungen, zum anderen aber auch Schulungen der Entwickler sowie die Schulungen für unsere Partner.

Von der Theorie in die Praxis

Bei Chrysalis mussten viele harte Entscheidungen getroffen werden, damit eine saubere und zeitnahe Umsetzung gewährleistet werden konnte. Die folgenden Komponenten wurden mit diesem Update erfolgreich spezifiziert und implementiert.

Spezifikation und Standardisierung

Spezifikationen sind ein wesentlicher Bestandteil des neuen Entwicklungsprozesses. Alle neuen Softwareprojekte (Node-Software, Wallet, Identity, Access, Streams usw.) basieren auf geprüften Spezifikationen. Spezifikationen sind dazu da, die beabsichtigte Funktionalität eines Projekts genauer zu beschreiben. Auf diese Weise wird es beispielsweise für externe Partner einfacher, Auditmaßnahmen durchzuführen oder die Entwicklung eigener Implementierungen in verschiedenen Sprachen voranzutreiben.

Die Chrysalis-Änderungen werden in Form von RFCs spezifiziert. Man kann alle RFCs im Repository protocol-rfcs finden.

Die Liste der Chrysalis RFCs umfasst:

• Verbesserte Tipp-Selection-Auswahl (URTS)
• Verbesserte Meilensteinauswahl
• White Flag Ansatz zur Berechnung von Guthaben
• Auf IOTA angepasstes UTXO-Protokoll (Unspent Transaction Output)
• Ed25519 Signaturschema
• Wiederverwendbare Adressen (Ed25519)
• Nachrichtenobjekt
• Binäres Transaktionslayout
• Nachricht Arbeitsnachweis (Proof of Work)
• Staubschutz (Dust Protection)
• Neues Dateiformat für lokale Snapshot-Dateien
• Bech32-Adressformat
• RESTful-Node-API
• Eventful-Node-API

Wallet-Unterstützung

Die Trinity Wallet war eine beliebte IOTA-Wallet. Mit Chrysalis wurde eine neue Wallet-Implementierung, Firefly, veröffentlicht. Das Team hatte an einer vollständigen Neuausrichtung der Wallet-Architektur und einer komplett neu gestalteten Benutzerführung gearbeitet. Kernstück war eine neue Wallet-Bibliothek, die in Rust geschrieben wurde. Die Wallet-Bibliothek wurde auf eine Weise entwickelt, die anderen Entwicklern die einfache Implementierung von IOTA-Wallets in ihren Anwendungen ermöglicht. Firefly verwendet eine neue Rust-Bibliothek namens Stronghold. Stronghold ermöglicht eine ultrasichere Handhabung und Aufbewahrung von Geheimnissen.

Infrastruktur

Derzeit unterstützt die IOTA Foundation zwei öffentliche Netzwerke: das Mainnet und das Devnet (das Devnet ist für die Validierung von Prototypen und Anwendungstests bestimmt). Beide Netzwerke bieten öffentliche Endpunkte für Benutzer und Partner an.

Das frühere Mainnet wurde zwar durch das neue Chrysalis-Netzwerk ersetzt, es bleibt jedoch über einen längeren Zeitraum weiterhin in Betrieb. Zum Zwecke des zeitunabhängigen Übergangs von Projekten, die auf dem alten Devnet bereitgestellt wurden, wurde das Devnet erst nach der Veröffentlichung von Chrysalis aktualisiert.

Chrysalis Testnetz

Im Testnetz bereitgestellte Nodes können mit einem Load Balancer unter folgender Adresse abgefragt werden:

api.lb-0.testnet.chrysalis2.com

Wir empfehlen, für die meisten Szenarien den Load Balancer zu verwenden.

Einzelnodes-Endpunkte, die natives MQTT (Message Queuing Telemetry Transport) verfügbar machen, sind:

api.hornet-0.testnet.chrysalis2.com
api.hornet-1.testnet.chrysalis2.com
api.hornet-2.testnet.chrysalis2.com
api.hornet-3.testnet.chrysalis2.com

Fazit

Chrysalis ist die bisher vielversprechendste Upgrade-Serie für IOTA. Es war ein wichtiger Schritt für die Produktionsbereitschaft mit erhöhtem Transaktionsdurchsatz, Netzwerkstabilität sowie verbesserter Benutzerfreundlichkeit und ermöglicht es, neue Funktionen und Anwendungsfälle zu entwickeln. Die letzten Wochen und Monate gehörten zu den aufregendsten in der Geschichte von IOTA. Wir sind auf einem klaren Weg zur Einführung von IOTA als Basistechnologie für das Internet der Dinge (Internet of Things - IoT).

Firefly

Eine neue Wallet für IOTA 1.5

Die bevorstehenden grundlegenden Änderungen im IOTA-Protokoll (neues Signaturschema etc.) verlangen eine völlig neue Wallet-Architektur. IOTA hat diesen Umstand zum Anlass genommen, um die Wallet von Grund auf neu zu überdenken: von der Transaktionslogik über das Benutzererlebnis bis hin zum Design. Die neue Wallet namens "Firefly" soll als Plattform für das aktuelle und zukünftige IOTA-Ökosystem dienen.

Die technische Architektur und die Benutzerschnittstelle der Wallet wurden mit Blick auf spätere Ergänzungen wie Digital-Assets, Chat und Kontaktmanagement recht modular entworfen. Während im Laufe des nächsten Jahres eine Reihe zusätzlicher Funktionen zum Stack der Wallet hinzukommen werden, wurde in der ersten Version von Firefly zunächst ein besonderer Wert auf Sicherheit, Benutzerfreundlichkeit und eine erweiterbare Architektur gelegt.

Es gibt bereits einige offensichtliche Unterschiede zu der alten Trinity-Wallet:

• Profile: Die App kann von mehreren Personen auf demselben Gerät genutzt werden, ohne Zugriff auf die Wallets der anderen Personen zu gewähren.
• Konten: Ein Benutzer kann seine Geldmittel z. B. auf ein Hauptkonto, ein Ausgabenkonto und ein Ledger Nano-Konto aufteilen.
• Pin-Code: Eine PIN Eingabe öffnet die Wallet, ohne dass jemals der Seed entschlüsselt wird, wodurch der Kontostand sicher überprüft werden kann.
• Wiederverwendbare Adressen: Die neuen Chrysalis Adressen (Bech32 Standard) fangen immer mit "iota" an und sehen wie im folgenden Beispiel aus: "iota11qykf7rrdjzhgynfkw6z7360avhaaywf5a4vtyvvk6a06gcv5y7sksu7n5cs".
• Wiederherstellungssätze: Das Backup erfolgt über die 24-Wort-Wiederherstellungssätze (Bip39 Standard).
• Bedienung: Verbesserte Benutzerfreundlichkeit und Netzwerkleistung.
• Netzwerkindikator: Zeigt Informationen über den aktuellen Zustand des IOTA-Netzwerks an.
  

Unter der Haube

Ein erweiterbarer und exportierbarer Anwendungskern

Mit diesem Konzept können alle Entwicklungen von anderen Entwicklern in neuen Anwendungen wiederverwendet werden. Folglich existieren bereits einige nützliche Tools für andere Entwickler, mit denen sie ihre eigenen Anwendungen entwickeln können.

stronghold.rs - Eine sichere Mehrzweckbibliothek zur Handhabung und Speicherung von Seeds

Stronghold ist die bedeutendste Neuerung, welche die Sicherheit der Wallet erheblich verbessert. Sensible Operationen wie Adressgenerierung und Transaktionssignierung finden in einem isolierten Anwendungsspeicher statt, wodurch der Seed von potenziellen Angreifern ferngehalten wird. Stronghold stellt eine Schlüssel-Werte-Datenbank bereit in der Anwendungen Daten speichern können. Das bedeutet, dass die Wallet vollständig portabel wird: Um die Transaktionshistorie auf ein anderes Gerät oder eine andere Wallet-App zu übertragen, wird nur ein aktuelles Stronghold-Backup benötigt.

wallet.rs - Eine vielseitige Wallet-Bibliothek

Die gesamte Transaktionslogik in Firefly wird von wallet.rs bereitgestellt - einer umfassenden, in Rust geschriebenen IOTA Wallet-Bibliothek. Die Bibliothek bietet alle Funktionen, die für die Erstellung von Wallets und die Integration von Börsen (exchanges) benötigt werden, von der Kontoerstellung über die Initiierung von Transfers bis hin zur Zustandsverwaltung und Sicherung. Die erste Version wird mit Neon-Bindungen für Node JS kommen, Python und WASM werden folgen, weitere sind zu einem späteren Zeitpunkt geplant.

Mit wallet.rs und stronghold.rs können Entwickler auf einfache Weise sichere Wallet- und Zahlungsfunktionalitäten in eine Vielzahl von Anwendungsfällen und Umgebungen integrieren. Zudem wird die Mentalität der Wiederverwendbarkeit auch auf das Design der Benutzerschnittstelle angewandt und IOTA plant, eine Komponentenbibliothek für Entwickler zur Verfügung zu stellen, die neu gestaltet und in eigenen Projekten verwendet werden kann. Parallel wird an einem Plugin-System mit einer Zugangskontroll-API gearbeitet, um den Benutzern die Kontrolle darüber zu geben, welche Funktionen in der Wallet aktiviert werden sollen. IOTA rechnet mit einer Reihe von Community-Projekten, bei denen Wallets und andere Anwendungen mit diesen Tools entwickelt werden.

Die Zukunft von Firefly

Firefly dient als Einstiegspunkt in das IOTA-Ökosystem und IOTA wird das Benutzererlebnis als Zahlungsprotokoll der Zukunft mit neuen Funktionen verbessern. Die Priorität liegt aber zunächst auf der Desktop-Version, bevor die Aufmerksamkeit auf mobile Geräte gelenkt wird.

Die neue Wallet ist eine modulare Plattform für unterschiedliche Anwendungen, ggf. auch von Drittanbietern. Im Folgendem werden ein paar dieser kommenden Funktionen aufgelistet:

• Mana-Delegation: Diese Funktion wird im Mainnet erst ab dem Coordicide zwingend benötigt, man wird dann (potenziell gegen Bezahlung) das von den gehaltenen Token erzeugte Mana an Nodes verpfänden können.

• Kontaktsystem: Konto-Adressen können mit Namen verknüpft werden. Damit löst Firefly das Problem der komplizierten Adressierung von Kryptowährungen für Benutzer und macht sich wiederholende Transaktionen (Bsp.: Geschäftskontakte oder Freunde) sicherer und schneller.

• Chat mit Bezahlfunktion: Der Nutzer soll mit Kryptowährungen so einfach umgehen können, wie beim Versenden von Textnachrichten oder beim Scannen eines QR-Codes. Die Messaging-App ähnelt in ihrer Funktionsweise der von Tencent betriebenen App WeChat. Diese deckt bereits über 30 Prozent der mobilen Zahlungen in China ab und erfreut sich steigender Beliebtheit.

• Digitale Identität: Durch die Bereitstellung einer digitalen Identität für Benutzer wird das Vertrauen in Transaktionen erhöht. Benutzer können ihr Profil mit überprüfbaren Anmeldeinformationen wie von Drittanbietern validierten KYC-Informationen verbessern. Auch könnte sich ein Benutzer an verschiedenen Terminals auf einfache Weise mit dem Handy über NFC ausweisen. Eine Implementierung der digitalen Identität eröffnet eine große Menge an weiteren Anwendungsfällen.

• Browsererweiterung: Diese kommt, allerdings darf man auf die Umsetzung gespannt sein. Wird es etwas Ähnliches wie Metamask? Eventuell mit einer Brücke zu ETH? Die Gerüchteküche brodelt.

• DApp-Interaktion: Verschiedene Drittanbieter-Apps werden mit der Wallet und ggf. untereinander kommunizieren können. Beispielsweise könnten Exchanges, Börsen oder Banken die IOTA-Wallet-Plattform als Grundlage für eigene Anwendungen nutzen, um mit dem Tangle zu interagieren. Dies erschafft völlig neue Servicedienstleistungen und Anwendungsgebiete. Neben dem einfacheren und schnelleren Kauf/Verkauf von MIOTA könnte dies auch Umtausch-Transaktionen von EUR/MIOTA in Echtzeit ermöglichen, wenn die Wallet eine Drittanbieter-App mit Banklizenz und so mit direkter Bankverbindung bekommen würde.

• Zugriffskontrolle: Mit IOTA-Access kann der Zugriff/Zugang auf unterschiedlichste Geräte/Orte gewährt werden.

• Digital Assets: Die Verwaltung von Colored Coins und NFTs wird zukünftig ebenfalls mit der Wallet möglich sein.
  

Migration: Was ist zu beachten?

Chrysalis - Sicherheit bei der Token-Migration

Die nächste Phase der Entwicklung von IOTA beinhaltet eine Token-Migration vom alten Legacy-Netzwerk zum neuen Chrysalis-Netzwerk mit Hilfe der Firefly-Wallet. Dieser Artikel bietet eine kurze Anleitung, wie man sich sicher durch das Cryptoland bewegt und Social-Engineering-Angriffe und Phishing-Versuche vermeidet.

Der offizielle Starttermin der Chrysalis-Netzwerkmigration war Mittwoch, der 21. April 2021. Das Netzwerk-Update selbst wurde am darauffolgenden Mittwoch, dem 28. April 2021, gestartet. Die eine Woche zwischen Migrationsbeginn und Netzwerk-Update ermöglichte es Nutzern, Börsen und Verwahrern, ihre Token-Migration vor dem Netzwerk-Update vorzubereiten. Benutzer waren nicht verpflichtet, ihre Token vor dem Netzwerk-Update zu migrieren. Sie werden mindestens bis zu IOTAs "Coordicide" in der Lage sein, ihre Token-Migration durchzuführen. IOTA-Token, die an Börsen aufbewahrt werden, werden von den Börsen im Namen ihrer Nutzer migriert.

Gefahr durch Betrüger

Dem Kaninchenbau ins Kryptoland zu folgen, eröffnet unendliche Möglichkeiten in technischer, finanzieller und professioneller Hinsicht. Doch leider gehört es zu dieser "interessantesten Branche der Welt", dass Neulinge und unerfahrene Nutzer nicht selten in die Fänge krimineller Akteure geraten, die mit Hilfe von 'Impersonification' und 'Social Engineering', getarnt als der Versuch, hilfreich zu sein, an Gelder, Token und persönliche Informationen ihrer Opfer gelangen.

Der Paradigmenwechsel, den die Dezentralisierung darstellt, birgt auf der einen Seite ein enormes Potenzial für finanzielle Selbstbestimmung und einen unerschöpflichen Raum für Innovationen. Auf der anderen Seite bringt er ein Maß an Eigenverantwortung mit sich, das im Idealfall dazu führen kann, dieses Ökosystem von seiner besten Seite zu erleben, im schlimmsten Fall jedoch dazu führt, gleich zu Beginn der Reise ausgeraubt zu werden.

Sei deine eigene Bank (Be your own bank) ist das Mantra, seit DLT die Welt innoviert, und besonders in Zeiten steigender Bewertungen nehmen die finanziellen Anreize für Betrüger proportional zu.

Die Dezentralisierung diktiert, dass eine einmal abgeschlossene Transaktion nie wieder rückgängig gemacht werden kann. Dies bedeutet, dass gestohlene Gelder nicht wiederhergestellt werden können.

Besonders in Zeiten der Token-Migration für das Chrysalis-Update ist es wahrscheinlich, dass Nutzer, die Hilfe beim Migrationsprozess benötigen, zur Zielscheibe von Betrügern werden.

Um unserer Community und den Nutzern eine Hilfestellung zu geben, hat die IOTA Foundation eine Liste mit einfach zu befolgenden "Best Practices" erstellt, die zum Schutz vor böswilligen Akteuren unter allen Umständen befolgt werden sollten.

Best-Practices

a) Teile niemals persönliche Informationen über die Menge der Token, die du besitzt oder wo und wie du deine Token aufbewahrst, einschließlich Passwörter, Passphrasen zur Wiederherstellung sowie Benutzernamen von Wallet-Konten oder Börsen.

Teile diese Informationen mit niemandem - auch nicht mit Mitgliedern der IOTA Foundation.

b) Teile niemals den Seed, den Privat-Key, die Ledger-Passphrase mit 24 Wörtern oder die Adresse zu deinen Token mit irgendjemandem - auch nicht mit Mitgliedern der IOTA Foundation.

c) Mitglieder und Moderatoren der IOTA Foundation werden niemals nach deinem Seed, deinem Privat-Key oder deinem Ledger-Passphrase mit 24 Wörtern fragen. "Nie" bedeutet wirklich nie. Es gibt keine Ausnahmen, niemals. Falls dies doch passiert, dann melde dich umgehend bei einer vertrauenswürdigen Person der IOTA Foundation, um diesen Vorfall aufzuklären.

d) Wenn du von angeblichen IOTA Foundation-Mitgliedern oder Moderatoren auf dem IOTA Discord über deine Token angesprochen wirst, sind das mit Sicherheit keine Mitglieder der IOTA Foundation, sondern bösartige Akteure, die sich als IF-Mitglieder ausgeben. Leider ist es auf Discord durch bezahlte Abonnements unglaublich einfach, sich überzeugend als andere Benutzer, Moderatoren oder sogar Mitarbeiter auszugeben.

Was zu tun ist, falls du Hilfe benötigst:

a) Wenn du bei der Migration deiner Token auf Hindernisse stoßen solltest, kannst du im offiziellen IOTA-Discord nach Unterstützung durch die Community suchen. Sobald du dich angemeldet hast, besuche den #help-Kanal, lese die Anweisungen und befolge sie. Der beste Weg um Hilfe zu erbitten, ist, es öffentlich in diesem Kanal zu tun: Solange deine Konversation öffentlich ist und nicht in privaten Nachrichten, gibt es weniger Risiko, weil jeder sehen kann, ob ein Betrüger versucht, dich zu betrügen und dich darüber informieren wird.

b) Wenn du jemanden über eine private Nachricht auf Discord um Hilfe bitten möchtest, dann stelle sicher, dass DU derjenige bist, der die Unterhaltung beginnt: Die Auswahl eines offiziellen Gesprächspartners aus der Seitenleiste und das Starten der Konversation durch dich selbst ist ohne Risiko, da Imitatoren nicht als grün gefärbte offizielle Mitglieder der IOTA Foundation in der Seitenleiste angezeigt werden können. Eine Konversation zu beginnen, indem man jemanden Offiziellen aus der Seitenleiste auswählt, ist daher sicher. Eine Direktnachricht von jemandem anzunehmen, der nur den gleichen Namen wie jemand in der Seitenleiste hat, ist nicht sicher. Es könnte sich um einen Betrüger handeln, der nur den gleichen Namen hat wie die offiziellen Mitarbeiter, die in der Seitenleiste angezeigt werden.

c) Lade deine Software nur von vertrauenswürdigen Quellen herunter (normalerweise Webseiten, die mit .IOTA.org enden). Um sicherzustellen, dass du nur besagte vertrauenswürdige Anwendungen verwendest, ist es ein guter Anfang, nach Links in den offiziellen Blog-Beiträgen (https://blog.IOTA.org) zu suchen.

d) Klicke niemals auf zufällige Links, die von angeblichen Mitgliedern oder angeblichen Moderatoren eines IOTA-bezogenen Social-Media-Kanals zur Verfügung gestellt werden, da sie ein hohes Risiko bergen, schädliche Software zu enthalten, die dein System kapern könnte.

Migration mit Firefly

Wenn es um die Chrysalis-Migration geht, wird Firefly dich Step-by-Step durch den gesamten Migrationsprozess führen. Dafür musst du nur deinen alten Seed in Firefly eingeben und dem Schritt-für-Schritt-Prozess folgen. Die Pre-Chrysalis Migrationsperiode begann am 21. April und das neue Netzwerk startete am 28. April. Als Nutzer konntest du wählen, ob du bereits während dieses Zeitraums migrieren wolltest oder damit bis nach Chrysalis Update warten möchtest. Es besteht keine Eile, deine Token zu migrieren - allerdings wird von der IOTA Foundation empfohlen, dies vor dem Coordicide-Update durchzuführen!

Nachdem du deinen Seed eingegeben hast, wird Firefly eine neue Mnemonik erstellen und eine EdDSA-Adresse im Chrysalis-Netzwerk für deine Token generieren. Dieser schwierige Vorgang wird vollständig automatisiert von der Firefly-Wallet durchgeführt und die Token-Inhaber werden über eine einfache Benutzeroberfläche durch den gesamten Prozess geführt. Dieser Artikel dient als weiterführende Anleitung für die automatisierte Token-Migration. Betrachte ihn als ergänzende Referenz, um sicherzustellen, dass alles reibungslos abläuft!

Wir raten dir außerdem, den IOTA Foundation Blogbeitrag über "Sicherheit während der Token-Migration" zu lesen oder den vorherigen Artikel hier im Heft "Migration, was ist zu beachten?".

Migrieren von Geldern

Möchtest du deine Token auf das neue Netzwerk migrieren? Das ist ganz einfach, doch einige Dinge solltest du beachten: Die meisten Nutzer werden den gleichen Migrationsprozess durchlaufen, allerdings kommt es vor, dass einige Nutzer einen etwas anderen Ablauf haben. Doch auch bei Abweichungen hat die IOTA Foundation den Übergang so einfach wie möglich gestaltet. Der Prozess bietet dir Optionen, die dich bei der Migration unterstützen.

Die Schritte werden dir nun im Folgenden erläutert.

Beachte, dass du keinen Migrationsprozess einleiten musst, wenn sich deine Token auf einer Börse befinden, da die Börsen die Token-Migration für dich durchführen.

Wenn du viele kleine Beträge (< 1Mi) hast, die über viele Adressen verteilt sind, ist es eventuell nicht möglich, diese kleinen Beträge zu migrieren.

Unabhängig davon, ob man Trinity auf einem Desktop-Computer oder auf einem mobilen Gerät verwendet, und unabhängig davon, ob die Migration vor dem Netzwerk-Update oder danach eingeleitet wurde, folgen alle Token-Migrationen einem grundlegenden Prozess:

1. Importiere deine IOTAs nach Firefly.
2. Prüfe, ob der Kontostand korrekt ist.
3. Erstelle ein neues Passwort und eine neue PIN für deine Wallet.
4. Erstelle eine Wiederherstellungsphrase und ein Stronghold-Backup für deine Wallet.
5. Starte den automatischen Migrationsprozess.
6. Erkunde Firefly.

Standardablauf einer Token-Migration

Lade zunächst Firefly auf deinen Rechner (Windows, Mac oder Linux) herunter. Bitte nutze hier nur die Download-Links von der Firefly Website https://firefly.iota.org. Nachdem du Firefly installiert und geöffnet hast, bieten sich dir zwei Möglichkeiten, den bestehenden Seed in Firefly zu laden: entweder durch eine Textsicherung oder eine Dateisicherung.

Textbackup - IOTA-Seed eingeben (81 Zeichen).

Dateibackup - Importieren einer Trinity-SeedVault-Datei (mit der Endung .kdbx).

Hinweis: Wenn du dein Trinity-Backup verloren hast, kannst du in den Einstellungen von Trinity Desktop oder Trinity Mobile den Seed aus Trinity erneut exportieren.

Um über Chrysalis auf dem Laufenden zu bleiben und die verfügbaren Ressourcen für das größte Upgrade in der Geschichte von IOTA zu sehen, besuche die Projektseite von Chrysalis: https://chrysalis.iota.org. Wenn du weitere Fragen hast, schau in dem #firefly-discussion Kanal auf dem offiziellen IOTA Discord vorbei.

Ledger

Chrysalis Migration für Ledger-Nutzer - Don't Panic!

Dieser Artikel gibt euch ein paar Hintergrundinformationen für die Migration des Hardwarewallets Ledger Nano zum neuen Chrysalis Netzwerk mit der Firefly Wallet.

Mehr Informationen zur Firefly Wallet findest du auf der offiziellen Website

https://firefly.iota.org/

Vorsicht! Bitte lade eine Wallet Sofware nur von der vertrauenswürdigen Seite iota.org herunter.

Das Chrysalis-Update von IOTA erfordert die Migration der Token vom alten legacy (dt. Erbe, Altbestand) Mainnet (IOTA 1.0) zum neuen Chrysalis Netzwerk (IOTA 1.5). Die Firefly-Wallet führt dich nahtlos durch den Migrationsprozess. Dafür musst du nur das Ledger Nano-Gerät an deinem PC anschließen, Firefly öffnen und der Schritt-für-Schritt Anleitung folgen.

Was geschieht da?

Die Migration vom Legacy-Netzwerk zum neuen Chrysalis-Netzwerk beinhaltet die Umstellung von Adressen mit Winternitz One-Time Signature auf wiederverwendbare EdDSA-Adressen. Diese Protokolländerungen erfordern eine Aktualisierung der alten Ledger Nano App und einen Wechsel von der alten Wallet Software Trinity zur neuen Wallet Software namens Firefly.

Nachdem du den Ledger Nano angeschlossen hast, wird Firefly den Migrationsprozess starten und dich durch eine Reihe von Schritten führen. Dieser Artikel erklärt, was bei dem automatisierten Prozess in Firefly passiert und soll dir Bedenken nehmen, etwas Falsches zu machen.

Migration

Möchtest du deine Token auf das neue Netzwerk migrieren? Das ist ganz einfach: Die meisten Nutzer werden den gleichen Migrationsprozess durchlaufen. Doch auch bei Abweichungen hat die IOTA Foundation den Übergang so einfach wie möglich gestaltet. Firefly unterstütz euch in diesem Fall mit entsprechenden Optionen.

Alle Ledger-Token-Migrationen folgen dem gleichen Grundprozess:

1. Erstelle ein neues Firefly-Profil mit einem PIN-Code.
2. Schließe den Ledger mit dem orginalen Kabel an.
3. Installiere über Ledger Live sowohl die alte, als auch die neue IOTA Ledger-App.
4. Schließe Ledger Live, öffne die neue Ledger-App und generiere eine neue Chrysalis-Adresse.
5. Wechsele nun zur alten Ledger-App und überprüfe, ob das Guthaben korrekt ist.
6. Starte den automatischen Migrationsprozess.
7. Das war's schon - nun kannst du Firefly erkunden und das neue IOTA Chryslis Netzwerk testen!

In den ersten Wochen wurden über 1 Milliarde US-Dollar (1,3 Peta IOTA) zu Chrysalis migriert. Mit der Implementierung der Ledger-Unterstützung wird erwartet, dass diese Zahl dramatisch ansteigen wird. Mehrere Börsen warten auch auf diese Funktion für ihre eigenen Integrationen und die IOTA Foundation arbeitet mit ihnen zusammen, um die Chrysalis-Unterstützung abzuschließen.

Warum die Veröffentlichung so lange gedauert hat und was wir daraus gelernt haben

Das Chrysalis-Netzwerk ging erstmals am 28. April live, doch Ledger-Benutzer mussten einige Monate warten, bevor sie über Firefly zu Chrysalis migrieren konnten. Die IOTA Foundation ist sich bewusst, dass dies eine inakzeptabel lange und für viele Leute frustrierende Zeit war. Es entspricht weder den hohen Standards der IOTA Foundation, noch den Standards, die unsere Community von uns erwartet. Vor diesem Hintergrund möchten wir einige Informationen darüber teilen, warum es so lange gedauert hat, welche Fehler gemacht wurden und wie die IOTA Foundation in Zukunft sicherstellen möchte, dass Protokoll-Upgrades und neue Funktionen reibungsloser veröffentlicht werden.

Einige Wochen vor Veröffentlichung von Chrysalis wurde klar, dass der Ledger-Support bis dahin nicht bereitstehen wird. Ledger Nutzern, die ihr Guthaben früher migrieren wollten, wurde geraten, ihr Guthaben zunächst an eine Nicht-Ledger-Adresse zu senden. Nach dem damaligen Wissen hatte man damit gerechnet, die Integration zeitnah abschließen zu können. Leider führte eine Reihe von unerwarteten Ereignissen und Rückschlägen während der Entwicklung zu einem viel längeren Zeitrahmen, als ursprünglich erwartet.

Chrysalis war ein kolossales Unterfangen. Es war das erste Mal in der Geschichte von IOTA, dass alle Teile des IOTA-Stacks berührt wurden, einschließlich einer kompletten Überarbeitung des Protokolls, einer vollständigen Neufassung aller Bibliotheken und Wallets und natürlich der notwendigen Migration von (jetzt veralteten) WOTS-Adressen zu EdDSA-Adressen in Chrysalis. Die gesamte Engineering-Abteilung hat intensiv zusammengearbeitet, um die umfangreichen Änderungen koordiniert umzusetzen. In dieser arbeitsintensiven Zeit wurden jedoch auch einige Fehler gemacht - aber daraus hat das Team gelernt und analysiert, wo es sich verbessern muss.

Da für Chrysalis an vielen Fronten gleichzeitig gearbeitet wurde, hatten einige Teams, einschließlich des Firefly-Teams, zu wenig Entwickler um termingerecht liefern zu können. Die Unterbesetzung durch Überarbeitung auszugleichen ist natürlich kein skalierbarer Ansatz. Daher hat die IOTA Foundation mehr als 20 Entwickler und technische Redakteure zusätzlich eingestellt, die in mehreren Teams in der gesamten Entwicklungsabteilung tätig sind und sicherstellen, dass die ehrgeizigen Pläne erreicht werden können. Chrysalis war auch eine Gelegenheit, viele der internen teamübergreifenden Engineering-Praktiken zu verfeinern.

Die IOTA Foundation hat ebenfalls erkannt, dass die Kommunikation rund um die Ledger-Veröffentlichung, insbesondere im Hinblick auf die geschätzten Zeitpläne und die Regelmäßigkeit der Statusaktualisierungen, nicht ausreichend war. Informationen und Updates werden nun über alle Kanäle hinweg und in erhöhter Frenquenz bereitgestellt.

Nächste Haltestelle: Coordicide!

Genau wie bei der Bitcoin-Blockchain besteht das IOTA-Tangle aus tausenden von Full-Nodes, die Messages über das Gossip-Protokoll übermitteln. Jede Node verwendet dieses Protokoll, um zu validieren, ob seine Kopie des Ledgers (hinsichtlich des Datenbestands im Tangle) mit dem Rest des Netzwerks übereinstimmt bzw. konsistent ist.

Die Art und Weise, wie die Konsens-Finalität im Tangle erreicht wird, ist aktuell noch zentralisiert. Eine Reihe von Transaktionen, die dem DAG des Tangles hinzugefügt werden, werden von einem speziellen, zentralen Node namens "Coordinator" (dt. "Koordinator") als valide bezeichnet, sobald er den Tip, also die letzte Transaktion dieser Reihe, ausgewählt und mit dem anheften einer eigenen Transaktion bestätigt hat. Auf diese Weise werden alle Transaktionen die dieser Tip referenziert, ebenfalls bestätigt. Andere - bspw. widersprüchliche - Transaktionen bleiben hingegen zurück, ohne jemals von dem Koordinator bestätigt zu werden. Ähnlich wie bei Bitcoin, wo sog. "Checkpoints" bis zum 16.06.2014 (also über 5 Jahre nach Aktivierung des Netzwerks) normal waren, ist der Einsatz dieser zentralisierten „Finalitätsvorrichtung“ derzeit noch notwendig, um die Sicherheit des noch jungen und nicht vollständig fertig gestellten Netzwerks zu gewährleisten.

Hinweis: Der "Coordinator", dessen Code Open Source zur Verfügung steht, kann lediglich Transaktionen validieren. Konsensregeln kann er dagegen nicht umgehen, womit es ihm auch nicht möglich ist, IOTA-Token zu erschaffen, einzufrieren oder einen anderen "Betrug" im Netzwerk zu begehen! Es wird schließlich immer von allen Nodes überprüft, was der "Coordinator" macht.

Bei IOTA gibt es im Grunde keine protokollbedingten Engpässe - die Skalierbarkeit ist einzig und allein durch die Hardware und die Gesetze der Physik beschränkt. Derzeit ist der "Coordinator" ein solcher Engpass, welcher das Protokoll daran hinter wirklich zu skalieren. Zudem stellt der "Coordinator" einen "Single Point of Failure" dar und verhindert, dass IOTA ein vollständig dezentrales Netzwerk ist. Die Entfernung des "Coordinators" - auch bezeichnet als "Coordicide" (Komposition aus den Wörtern "Coordinator" und "Homicide" (dt. Mord)) - ist aus den genannten Gründen das nächste große Ziel der IOTA Foundation (IF). Die Forschungs- und Entwicklerteams der IF haben mit dem Chrysalis Update die Grundlagen geschaffen, um das Ziel einer vollständigen Dezentralisierung im Hinblick auf den Konsens zu erreichen. Ein weiterer wichtiger Meilenstein ist das erst vor kurzem gestartete "IOTA 2.0 DevNet" (urspr. als "Nectar" bezeichnet). Es ist das erste vollständig dezentrale, also ohne "Coordinator" funktionierende, IOTA-Entwicklungsnetzwerk, welches auf dem Chrysalis Update basiert. Es stellt den Prototypen für das zukünftige, vollständig dezentrale IOTA-Hauptnetzwerk dar. Bevor jedoch irgendwann der Wechsel vom Entwicklungs- zum Hauptnetzwerk, und damit der eigentliche "Coordicide", durchgeführt werden kann, muss das "IOTA 2.0 DevNet" noch intensiv "auf Herz und Nieren" getestet werden. Diese Tests sollen idealerweise nicht nur durch die Teams der IF, sondern insb. auch durch die IOTA-Community bzw. Externe Personen durchgeführt werden. Geplant sind hierfür u.a. finanzielle Anreize, um eventuell vorhandene Sicherheitslücken zu finden und zu beheben. Deshalb lädt die IOTA Foundation jeden Sicherheitsforscher, Hacker und Interessierten ein, sich mit dem "IOTA 2.0 DevNet" und seiner Funktionalität genauer auseinanderzusetzen!

• Der offizielle Blogpost zum "IOTA 2.0 DevNet": https://blog.iota.org/iotav2devnet/

IOTA-Konsens nach dem Coordicide: Wie funktioniert das konkret?

Nach der Analyse verschiedener Ansätze kam das Forschungsteam der IF zu der bereits angesprochenen Lösung namens "Coordicide", welche auf der Lösung von Konflikten mithilfe eines Abstimmungssystems beruht. Dies bedeutet, dass die Nodes bei zwei beliebigen, in Konflikt stehenden Transaktionen abstimmen und ihre Meinung darüber austauschen muss, welche Transaktion als gültig erachtet werden sollte. Damit jedoch ein solches Modell sicher funktioniert, müssen diverse Sicherheitsmaßnahmen implementiert werden, damit das IOTA Protokoll keine Angriffsvektoren bietet, welche die Sicherheit des Netzwerks beeinträchtigen würde. Sybil-, Eclipse- und Spam-Angriffe sind nur einige der Angriffsvektoren, für die entsprechende Sicherheitsfeatures im Code von IOTA implementiert werden müssen. Der "Coordicide" sollte daher sorgsam und mit Bedacht geplant und durchgeführt werden. Das "IOTA 2.0 DevNet" stellt den Prototypen vom "Coordicide"-Netzwerk dar und implementiert all diese Funktionen mit einer Reihe von Modulen, die zusammenwirken, um einen dezentralen Konsensus zu erreichen. Dieser Ansatz macht den "Coordicide"-Vorschlag und das zukünftige Protokoll modular, sodass jedes Modul unabhängig voneinander getestet, ersetzt oder verbessert werden kann.

Stronghold

Was ist Stronghold?

Stronghold ist eine Sammlung von Mehrzweckbibliotheken zur sicheren Verwaltung und Schutz von digitalen Geheimnissen z.B. Passwörter, sehr persönliche Daten oder private Schlüssel.

Stronghold: Kurz und knackig erklärt

Bei Stronghold handelt es sich um eine Software-Implementierung die mittels der Programmiersprache Rust extrem sicher entwickelt wurde. Ihr alleiniger Zweck ist es, digitale Geheimnisse, wie Seeds, Schlüssel oder Passwörter vor der Gefahr durch Hacker und versehentliche Leaks zu schützen.

Wie genau funktioniert das?

Stronghold verwendet versionierte und dateibasierte Snapshots mit doppelter Verschlüsselung, die leicht gesichert und sicher zwischen Geräten ausgetauscht werden können. Entwickelt in Rust, bietet Stronghold starke Garantien für Speichersicherheit und Prozessintegrität.

Die entwicklerfreundlichen Bibliotheken von Stronghold integrieren das IOTA-Protokoll und dienen als Referenzimplementierung für jeden, der nach Inspiration oder den besten Tools seiner Klasse sucht. Die Low-Level-Bibliotheken haben keinerlei Bezug zur Kryptowährung oder dem Tangle. Diese Funktionen befinden sich erst auf höherer Ebene, so dass Stronghold auch für Software-Projekte eingesetzt werden kann, welche nicht direkt etwas mit einem Distributed Ledger zu tun haben, sondern bspw. lediglich bestimmte wertvollen Daten lokal schützen soll.

Intern setzt die IOTA Foundation Stronghold zur Sicherung ihrer neuen Wallet Software "Firefly" ein. Außerdem ist Stronghold die Grundlage für die neue Wallet Library "wallet.rs". Diese wurde ebenfalls in Rust geschrieben, kann jedoch durch "bindings" auch mit anderen Programmiersprachen wie NodeJS, Java oder Python genutzt werden.

Wo kann man Stronghold einsetzen?

Aufgrund der hohen Flexibilität gibt es neben der Sicherung von Kryptowährungs-Wallets noch viele weitere spannende Anwendungen, die mit Stronghold erstellt werden können. Die Low-Level-Engine von Stronghold ist völlig Anwendungsfall unabhängig und so flexibel, dass die Verschlüsselungsalgorithmen nach Belieben ausgetauscht, auf neue Weise zusammengestellt und mit anderen Teilen praktisch jedes "Stacks" erweitert werden können. Die High-Level-Bibliotheken werden so solide sein, dass sie von Haus aus eine enorme Sicherheit mitbringen.

Hier sind einige mögliche Anwendungsbeispiele für Stronghold:

Wallet

Alice's IOTA-Wallet wird durch Stronghold geschützt, welche sie so konfigurieren kann (siehe obige Grafik), dass sie die Aktivitäten in ihrer Wallet überwacht und gefährliche Ereignisse verhindert.

Exchanges

Die Daytraderin Alice und ihre Börsen können gemeinsam die verteilte Schlüsselerzeugung von Stronghold und BLS-Schwellwertsignaturen nutzen, um die Überprüfbarkeit von IOTA-Token-Transfers mit hohem Volumen zu verbessern.

Tools zur Passwortverwaltung

Das sichere Säubern des Speichers nach der Verwendung eines Passwortes ist eine häufige Schwachstelle in Passwort-Managern. Stronghold ist so implementiert, dass auch eine solche Schwachstelle nicht von einem Angreifer ausgenutzt werden kann.

Multimedia-Center

Alice leiht sich einen Film aus, den sie mit ihrem Handy auf dem Smart TV abspielt. Der Film wird als verschlüsselter Stream an das Smart TV gesendet und ein Schlüssel zum entschlüsseln wird mit dem Stronghold ihres Gerätes synchronisiert. Nach 48 Stunden wird der Schlüssel durch den Dienst aus ihrem Stronghold gelöscht und der Film kann nicht mehr abgespielt werden.

GDPR-Datenprozessoren und -Controller

Anstatt persönlich identifizierbare Informationen in einer zentralen Datenbank zu speichern, die auf einen Schlag gestohlen werden können, kann Alice sich dafür entscheiden, den Zugriff auf ihre Daten direkt aus ihrer Stronghold-basierten Anwendung heraus freizugeben oder zu widerrufen.

Software-Entwickler

Die Verwendung der Stronghold-Befehlszeilenschnittstelle oder des Systemdienstes als lokales Geheim- und Abrufsystems erhöht die Betriebssicherheit der Programmiererin Alice und trägt dazu bei, eine versehentliche Offenlegung zu verhindern.

Nützliche Links:

• Das offizielle Repository: https://github.com/iotaledger/stronghold.rs
• Dokumentation: https://stronghold.docs.iota.org/
• Stronghold X-Team: https://github.com/iota-community/X-Team_IOTA_Stronghold

einfachIOTA

Hier berichtet das einfachIOTA Team über eigene Projekte oder Dinge, die auf dem Discord Server passieren.

Der IOTA Einsteiger Guide

Schon seit vielen Jahren schreibt Schmucklos bereits an seinem allseits beliebten IOTA Einsteiger Guide. Darin sind nicht nur viele aktuelle Blogposts der IOTA Foundation auf deutsch übersetzt und sinnvoll geordnet, sondern es werden auch eine Vielzahl von Projekten aus dem IOTA Ökosystem beschrieben und die Technik dahinter erklärt. Der IOTA Einsteiger Guide wird immer wieder aktualisiert, wobei es nicht selten vorkommt, dass auch alte Texte wieder gelöscht werden müssen, da die beschriebene Technik veraltet, oder die Projekte dahinter nicht mehr relevant sind. Dieses Jahr hat sich Schmucklos entschieden sein Projekt unter die Schirmherrschaft von einfachIOTA zu stellen, um noch mehr Aufmerksamkeit zu generieren. Aller Respekt gilt aber natürlich weiterhin ausschließlich ihm, denn er ist derjenige der für alles verantwortlich ist. Nur bei der englischen Variante, die es seit diesem Jahr gibt, dem "IOTA Beginners Guide", wird er von ... unterstützt. Er hat die meisten Artikel aus dem IOTA Einsteiger Guide ins englische übersetzt. Dadurch hat auch der englishsprachige Teil der IOTA Community Zugriff auf diese einzigartige Sammlung von IOTA Informationen.

Der IOTA Stammtisch

Letztes Jahr hat vrom die Initiative "IOTA Stammtische" ins Leben gerufen und zusammen mit einfachIOTA versucht, neben dem regulären Stammtischen aus München und Mannheim weitere Stammtische in der DACH Region zu etablieren. Grundsätzlich war die Idee, dass jeder einen Stammtisch in seiner Stadt organisieren kann, wenn er es schafft mehr als 3 Leute zu motivieren sich regelmäßig zu treffen. Anschließend bekommt man im einfachIOTA Discord einen eigenen Channel für seine Stadt zugewiesen, um sich dort noch besser verabreden zu können. Auf diese Weise haben sich mittlerweile Stammtische in München, Mannheim, Berlin, Hamburg, Aaachen, Saarbrücken, Südtirol und in der Schweiz etabliert. Corona bedingt war es allerdings abzusehen, dass diese Erfolgsgeschichte ein jähes Ende finden würde, wenn wir es nicht schaffen die Zwangspause zu überbrücken. Also haben wir beschlossen einen wöchentlichen deutschsprachigen virtueller Stammtisch bei uns im einfachIOTA Discord zu organisieren. Was mit mur 10-15 Leuten im Oktober 2020 began, konnte sich von Woche zu Woche über zunehmender Beliebtheit erfreuen, so dass mittlerweile jeden Montag zwischen 200-300 Leute daran teilnehmen und bis spät in die Nacht diskutieren. Deshalb werden wir auch in Zukunft den virtuellen Stammtisch wöchentlich betreiben. Nichtsdestotrotz freuen wir uns aber natürlich auch über jeden realen Stammtisch der in einer echten Kneipe oder einem Lokal stattfindet. Bei einem gemütlichen Bier und einer leckeren Mahlzeit lässt sich das gemeinsame Thema "IOTA" einfach noch mehr genießen!

IOTA Einsteiger Guide

Der IOTA Einsteiger Guide ist eine Webseite, auf der die Grundlagen von IOTA auf deutsch erklärt werden und die versucht, alle Partnerschaften und Entwicklungen im IOTA Ökosystem aufzugreifen und auf deutsch zur Verfügung zu stellen. Dieser Artikel ist nur ein kleiner Ausschnitt von dem, was euch auf der Webseite erwartet, also schaut auf jeden Fall mal vorbei!

https://iota-einsteiger-guide.de

Was ist IOTA? - Eine Zusammenfassung

IOTA ist keine Blockchain, IOTA ist ein skalierbares Open-Source-Kommunikationsprotokoll mit Token (Kryptowährung) für einen Wertetransfer. Es wird entwickelt und bereitgestellt von der gemeinnützigen, also nicht gewinnorientierten IOTA Foundation (Stiftung nach deutschem Recht) mit Hauptsitz in Berlin.

Der Name IOTA stammt von dem altgriechischen Buchstaben Iota (altgriechisches Neutrum Ἰῶτα; „der kleinste Buchstabe") und bezeichnet "etwas Geringes". Das Iota ist der 9. Buchstabe des altgriechischen Alphabets und wurde in der Antike wie heute identisch, nämlich i ausgesprochen. Von ihm stammt bspw. auch der lateinische Buchstabe i ab. Im IOTA Kommunikationsprotokoll steht das i für 1 Iota und ist im Netzwerk die kleinste handelbare Werteeinheit - hier schließt sich der Kreis zu "etwas Geringes".

Das Ziel der IOTA Foundation ist es, einen Trust Layer (Vertrauensschicht) für das Internet of Everything (IoE) zu erschaffen, die es Geräten im IoE ermöglicht, Daten und Werte untereinander unveränderlich sowie gebührenfrei auszutauschen. IOTA strebt in Zusammenarbeit mit der Industrie und der Object-Management-Group (einem Konsortium, das sich mit der Entwicklung von Standards für die herstellerunabhängige, systemübergreifende, objektorientierte Programmierung beschäftigt) eine Standardisierung ihres Kommunikationsprotokolls an. Mit einer hohen Interoperabilität wird IOTA das "Ledger Of Everything" sein, dessen Infrastruktur ohne Restriktionen (permissionless) auch von externen Anwendungen genutzt werden kann.

IOTA ermöglicht eine schnelle, manipulationssichere und dezentrale Übertragung von Werten und Daten über viele Netzwerk Knotenpunkte (Nodes). Dabei werden Werte- und Daten-Transaktionen grundsätzlich unterschiedlich gehandhabt. Während Werte-Transaktionen von Full-Nodes validiert werden müssen, werden Daten-Transaktionen direkt bestätigt und sind somit in gewisser Weise "notarisiert". An dieser Stelle werden sich die ein oder anderen Lesenden fragen: Warum benötigt man für eine reine Daten-Transaktion die IOTA Distributed Ledger Technologie? Man kann die Daten doch auch einfach so verschlüsseln, signieren und via TCP/IP versenden.

Nun, abgesehen davon, dass auf diese Weise immernoch „Man in the Middle“-Angriffe möglich wären, beweisen signierte Daten nur, dass die Daten von Person A kommen. Es ermöglicht Person B weder zu prüfen, wann Person A die Daten gesendet hat, noch ob identische Daten auch an alle anderen Personen übermittelt wurden. Person A könnte also z.B. eine bestimmte Information an Person B und eine andere Information an Person C senden. Signaturen allein können niemanden vor solchen Angriffen schützen.

Mithilfe der „Notarisierung“ kann bewiesen werden, dass ein elektronisches Dokument in einer bestimmten Form zu einem bestimmten Zeitpunkt existiert hat und seit der Erstellung nicht verändert wurde. Bei der Erstellung einer Notarisierung wird ein eindeutiger Hash (Fingerabdruck) eines Dokumentes berechnet und gemeinsam mit einem Zeitstempel im IOTA-Ledger (dem "Tangle") unveränderbar gespeichert. Falls zu einem späteren Zeitpunkt verifiziert werden soll, dass das betreffende Dokument zum behaupteten Zeitpunkt existiert hat und/oder nicht verändert wurde, werden die Daten aus dem Tangle abgerufen und mit den vorliegenden Informationen verglichen.

Wenn das IOTA Tangle als Transportmedium verwendet wird, dann sind diese Art von Angriffen nicht möglich. Schon heute gibt es viele Anwendungsfälle, bei denen es von entscheidener Bedeutung ist, dass alle beteiligten Parteien sich darauf verlassen können, dass alle an oder mit den gleichen Informationen arbeiten (z.B. Lieferketten, Oracles, synchronisierte Fernsteuerungssysteme usw.). Es geht daher primär um Anwendungsfälle, bei denen Daten eben nicht einfach nur via TCP/IP übertragen werden können. Ansonsten könnte man auch direkt BitTorrent dafür nutzen. Sender und Empfänger benötigen eine verlässliche und transparente Form der Übertragung zwischen mehreren Parteien oder Organisationseinheiten.

Unter dem Strich bedeutet dies Folgendes: Daten dürfen weder während der Übertragung noch nach dem Empfang manipulierbar sein. Zur Verdeutlichung soll folgendes Beispiel dienen: Ein Sensor (mit IDoT Chip) hat einige Werte gemessen und versendet diese Daten über den IOTA-Tangle, welcher den Hash dieser Daten speichert. Wenn diese Daten später verkauft werden sollen, kann über den Hash nachgewiesen werden, dass die Daten vom Sensor im Nachhinein nicht verändert wurden. Die IOTA Technologie, also das Tangle, fungiert hierbei wie eine Art Fingerabdruck - mit ihr können alle gesendeten Daten verifiziert werden. An dieser Stelle noch ein kurzer Hinweis: Um Missbrauchsszenarien zu verhindern und auf eine effiziente Art und Weise die Maschinenökonomie zu ermöglichen, werden zukünftig Nodes und Geräte eine eindeutige Kennung (ID) erhalten, siehe auch Identität der Dinge (IDoT).

Bei IOTA sind die Guthaben auf den Adressen allen teilnehmenden Full-Nodes jederzeit bekannt. Jedoch versteht sich IOTA nicht als Datenspeicher, sodass die Transaktionshistorie auf den Full-Nodes nicht über einen längeren Zeitraum gespeichert werden muss (analog zum TCP/IP-Traffic des Internets, der ebenfalls nicht gespeichert wird). Möchte ein Nutzer oder ein Unternehmen zusätzlich auch die Transaktionshistorie über mehrere Jahre hinweg abrufen bzw. speichern, müssen dafür zusätzliche Lösungen eingesetzt werden. Dies könnte eine Permanode, eine selektiver Permanode, eine eigene Second-Layer Lösung oder zukünftig auch ein Smart-Contract sein, welcher mehrere Nodes für diese Dienstleistung bezahlt.

Das Kommunikationsprotokoll ist modular aufgebaut, was zukünftig schnellere und einfachere Updates ermöglicht. Für die Redundanz im Netzwerk sind sehr viele Nodes nötig - in ein paar Jahren kann jedoch jedes Auto, jede Maschine, jeder Router usw. ein IOTA Node sein. Je mehr Nodes am Netzwerk teilnehmen, umso schneller und sicherer wird es.

Technologie

Um die oben genannten Ziele zu ermöglichen, sind folgende Protokollmerkmale von grundlegender Bedeutung:

• Skalierbar - Verarbeiten einer beträchtlichen Anzahl von Transaktionen/Messages pro Sekunde über ein großes Netzwerk von Nodes mit schnellen Bestätigungszeiten.
• Schlankes System - Leistungsschwache Geräte sind in der Lage, direkt am Netzwerk teilzunehmen.
• Gebührenfrei - Das Senden aller Transaktionen kann ohne Zahlung von Netzwerkgebühren erfolgen: Wenn 50 MIOTA versendet werden, kommen auch 50 MIOTA beim Empfänger an.

Datenstruktur

Neben den Gebühren weisen herkömmliche DLTs, wie die Blockchain, weitere begrenzende Faktoren auf und sind daher für die Erreichung des Ziels von IOTA ungeeignet. Ein Beispiel ist die inhärente Beschränkung der Geschwindigkeit von Blockchain-Netzwerken, welche allgemein als "Blockchain-Bottleneck" bezeichnet wird. In der Blockchain gibt es nur eine Seite, an der neue Transaktionen angefügt werden können - das Ende der Kette. Die daraus resultierenden negativen Auswirkungen auf den Netzwerkdurchsatz werden in dieser einfachen Grafik dargestellt:

Im Gegensatz dazu wird bei IOTA nicht Block an Block aneinandergereiht und es werden auch keine Miner zur Validierung von Transaktionen benötigt. Die Kerndatenstruktur bei IOTA ist von Natur aus hoch skalierbar. Dies wird mit einer einfachen Regel ermöglicht: Jede Transaktion referenziert und genehmigt zwischen 2 und acht weitere Transaktionen. Diese Regel definiert die zugrundeliegende Datenstruktur von IOTA - das Tangle - welches mathematisch als gerichteter azyklischer Graph (DAG) bezeichnet wird.

Bildlich lässt sich das wie folgt beschreiben:

• Eine Menge von Transaktionen sind durch Pfade verbunden - dies ist ein Graph.
• Jeder dieser Pfade besitzt eine eindeutig festgelegte Laufrichtung, womit es ein gerichteter Graph ist.
• Lässt sich niemals ein Pfad finden, der zu seinem Ausgangspunkt zurückkehrt, ist der Graph azyklisch (im Kreis laufende Pfade wären dagegen zyklisch).
• Wir sprechen beim IOTA Tangle also von einem gerichteten azyklischen Graph

Transaktionsstatus

Grün = Bestätigt (Konsens) / Weiß = Unbestätigt (Conflict) / Grau = Neu angehängt (Tips)

Im Gegensatz zur Blockchain, die das Anhängen neuer Transaktionen nur an einer einizgen Stelle erlaubt, bieten DAGs mehrere Punkte an, um Transaktionen anzuhängen. Die Nutzer können also neue Transaktionen an verschiedene Stellen des Tangles anhängen, ohne auf die Bestätigung durch andere Transaktionen warten zu müssen:

In dieser chaotischen Anordnung werden sämtliche Transaktionen parallel abgearbeitet und ermöglichen eine sehr hohe Skalierbarkeit, da mit steigender Anzahl der Transaktionen auch die Bestätigungsraten ansteigen. Dies ist, wie oben zu sehen war, genau konträr zu der Funktionsweise der derzeitigen üblichen "klassischen" Blockchains.

Konsensmechanismus

In der Blockchain teilt der Nakamoto-Konsens das Netzwerk in Miner und Nutzer auf. Miner verbrauchen große Mengen an Rechenleistung und erfüllen damit den Proof-of-Work (PoW), der für die Verkettung der Blöcke erforderlich ist. Miner werden durch die Gebühren, welche Nutzer bereit sind zu zahlen, damit ihre Transaktionen in einen Block aufgenommen werden, incentiviert. Diese gebührenbasierte Anreizstruktur wäre eine erhebliche Barriere in einer Maschine-zu-Maschine-Ökonomie, in der Mikrozahlungen zwischen den Maschinen niedriger sein können als die anfallenden Gebühren.

Bei IOTA gibt es keinen Unterschied zwischen Minern und Nutzern. Alle Nodes können am Konsens gleichermaßen teilnehmen. Eine IOTA-Node spielt eine wesentlich andere Rolle als eine Bitcoin-Miner-Node. IOTA-Nodes führen nur einfache Operationen durch, welche nicht viel Rechenleistung erfordern, z.B. das Speichern des Ledgerzustands oder das Validieren von Transaktionen. Nutzer können mit minimalen Kosten einen IOTA Node einrichten und aktiv am Netzwerkkonsens teilnehmen und so die Sicherheit des Netzwerks erhöhen.

Der Konsensmechanismus legt fest, wie sich die Nodes darauf einigen, welche Transaktionen vertrauenswürdig sind und gewährleistet somit eine Übereinstimmung im gesamten Netzwerk. In der aktuellen IOTA-Implementierung vertrauen Nodes den (Wert-)Transaktionen nur, wenn diese von den sogenannten Meilensteinen (Milestones) referenziert und genehmigt wurden. Diese Meilensteine sind ganz normale Transaktionen, die von dem Coordinator (deutsch: Koordinator) ausgestellt wurden. Das ist übrigesn ähnlich wie beim Bitcoin in der Anfangszeit - hier gab es bis zum 16.06.2014 auch sogenannte "Checkpoints". Derzeit ist der Einsatz dieser zentralen "Finalitätsentscheidung" noch notwendig, um die Sicherheit des noch jungen Netzwerks zu gewährleisten. Das Ziel ist aber diesen Coordinator schon bald abzuschalten, so dass das IOTA Netzwerk als komplett dezentral angesehen werden kann.

Hinweis: Der Coordinator, dessen Open Source Code einsehbar ist, kann lediglich Transaktionen validieren. Konsensregeln kann er dagegen nicht ändern oder umgehen, womit es ihm auch nicht möglich ist, IOTA-Token zu erschaffen, IOTA-Token einzufrieren oder einen anderen "Betrug" im Netzwerk zu begehen!

IOTA ohne Coordinator

Der Coordinator soll in naher Zukunft abgeschaltet werden. Bekannt geworden ist dieser Schritt under der Bezeichnung "Coordicide" (Wortschöpfung aus den englischen Begriffen "coordinator" und "homicide", d.h "Tötung"). Diesbezüglich wurden bereits alle Forschungsarbeiten weitestgehend abgeschlossen und u.a. von mehreren Universitäten überprüft. Der Entwicklungsfahrplan - offiziell als Roadmap bezeichnet - der die IOTA-Technologie zur Produktionsreife führen soll, wurde bereits veröffentlicht und befindet sich derzeit in der Umsetzung.

Noch vor dem Coordicide wurde Ende April 2021 eine vollumfängliche Aktualisierung des IOTA Netzwerkes durchgeführt. Bei dem als "Chrysalis" (IOTA 1.5) bezeichneten Updates handelt es sich um eine Weiterentwicklung, welches das Netzwerk unternehmenstauglich (enterpriseready) für das IOTA Ökosystem gemacht hat.

Ein weiterer wichtiger Meilenstein war das erst vor kurzem gestartete "IOTA 2.0 DevNet" (urspr. als "Nectar" bezeichnet). Es ist das erste vollständig dezentrale IOTA-Entwicklungsnetzwerk, das ohne den Coordinator funktioniert. Es basiert auf dem "Chrysalis"-Update und stellt bereits den Prototypen für das zukünftige, dezentrale IOTA-Hauptnetzwerk dar. Aktuell wird das Entwicklungsnetzwerk auf Herz und Nieren geprüft und soweit optimiert, so dass es aller Vorraussicht nach Ende 2021/Anfang 2022 das jetzige Hauptnetzwerk ersetzt und somit den Coordinator final abschaltet.

Der Coordicide stellt sicher, dass das Netzwerk ohne den Coordinator einen Konsens erzielt und gleichzeitig die folgenden Eigenschaften aufweist:

• Skalierbar: Die Transaktionsrate im Netzwerk ist nicht durch das Protokoll begrenzt - eine beispiellose Skalierbarkeit wird ermöglicht.
• Sicher: Ein Angreifer kann den Konsens nicht beeinflussen.
• Dezentral: Alle ehrlichen Nodes können Teil des Konsensprozesses sein.

Aktuelle Blockchain-Lösungen können maximal zwei dieser drei Eigenschaften gleichzeitig erfüllen. Die Algorithmen wurden so entwickelt, dass die Schwierigkeit des Mining-Vorganges absichtlich hoch gehalten wird, sodass das Netzwerk keinen neuen Block produzieren kann, während der vorhandene Block noch erstellt und von allen Nodes überprüft wird. Denn je größer die Anzahl der Nodes im Netzwerk ist, desto länger dauert es, bis der Block bei allen Nodes ankommt und verifiziert werden kann. Wäre die Blockzeit zu kurz, würden viele Blöcke gleichzeitig von verschiedenen Akteuren produziert werden und der Nakamoto-Konsens könnte sich nicht auf ein einziges Ergebnis einigen. Das hätte zur Folge, dass die Nodes im Netzwerk zu einem bestimmten Zeitpunkt voneinander abweichende Ketten als längste und damit als valide Ketten betrachten würden.

Die Blockchain-Lösung besteht darin, die Mining-Schwierigkeit so hoch anzusetzen, dass die Blockzeit im Durchschnitt 10 Minuten beträgt. In diesen 10 Minuten versuchen verschiedene Akteure einen Block zu erzeugen, was jedoch normalerweise nur einem Akteur am Schnellsten gelingt. Alle anderen Akteure lassen (sprichwörtlich) alles fallen, was sie gerade tun, akzeptieren den erfolgreichen Block und versuchen es bei dem nächsten Block erneut. Manchmal kann es vorkommen, dass mehrere Akteure (normalerweise 2) Glück haben und zeitgleich einen gültigen Block erstellen. Die Hälfte des Netzwerks akzeptiert Block 1 und die andere Hälfte akzeptiert Block 2: die Kette würde auseinanderlaufen. Der nächste Miner, der einen Block findet, löst diesen Konflikt auf, indem er ihn immer nur an eine der beiden Ketten anhängt. Diese Kette ist dann die längste und "gewinnt". Alle Nodes akzeptieren sie als gültig. Mit diesem Prinzip behilft man sich beim "Proof-of-Work"-Ansatz und auch wenn es im "Proof-of-Stake"-Ansatz keine Miner mehr gibt, existiert dort ein ähnliches Verfahren. Die Nodes müssen sich immer auf einen Block einigen, bevor sie mit der Produktion des nächsten Blocks beginnen. Mit der Anzahl der Nodes steigt auch die Netzwerkverzögerung, also die Zeit, bis der Block an alle Nodes im Netzwerk verteilt wird. Da der Nakamoto-Konsens ein synchroner Konsens ist, kann er bestenfalls 2 der 3 Punkte (Sicherheit, Dezentralisierung, Skalierbarkeit) lösen.

Dieses Problem wird als Blockchain-Trilemma bezeichnet.

P.S.: Durch die begrenzte Blockgröße entsteht noch ein weiteres Problem: Da immer mehr Transaktionen über das Netzwerk gesendet werden, entscheiden sich die Miner eher dafür, die Transaktionen mit den höchsten Gebühren zu validieren, was zu steigenden Transaktionskosten und zu langen Wartezeiten bei zu geringen Gebühren führt. Der revolutionäre Charakter dieser auf Proof-of-Work-basierenden Lösung ist zwar sehr bedeutend, aber man muss sich mit den damit verbundenen Einschränkungen bezüglich des Netzwerkdurchsatzes bewusst sein.

IOTA ist durch seine asynchrone Natur grundsätzlich nicht vom Blockchain-Trilemma betroffen. Jede Node darf gleichzeitig Transaktionen produzieren, während sie mit einer Teilmenge von Nodes für den Konsens interagiert und dabei eine nicht lineare Datenstruktur verwendet. Mit IOTA 3.0 wird IOTA eine Lösung mit Sharding-Verfahren anbieten, welche das Trilemma umgeht und damit eigentlich auch löst (wobei dies natürlich Ansichtssache ist). Konkret lässt sich Sharding folgendermaßen beschreiben: IOTA-Nodes haben grundsätzlich eine Begrenzung, wieviele Transaktionen sie pro Sekunde (TPS) verarbeiten können. Durch das Aufteilen einer sehr großen Datenbank in kleinere Datenbanken mit leichter zu verwaltenden Segmenten (s.g. Shards), könnte jeder Shard einen bestimmten einzigartigen Bereich der Kontensalden abbilden. Die Nodes würden dann dezidierte Shards zugewiesen bekommen, um Transaktionen zu validieren.

Ziel ist es, dass durch die Aufteilung in besser verwaltbare Segmente der Transaktionsdurchsatz erhöht wird. Das Trilemma wird innerhalb einzelner Shards grundsätzlich weiterhin bestehen. Sobald jedoch in einem einzelnen Shard der Netzwerkdurchsatz die Verarbeitungskapazitäten der Nodes übersteigt, bildet sich dynamisch ein weiterer Shard (Fluid-Sharding). Durch das neuartige, sehr flexible Sharding werden bei IOTA theoretisch unendliche hohe Transaktionsgeschwindigkeiten ermöglicht.

Neue Transaktionen können bei IOTA an jeden Teil des Tangle angehängt werden. Aufgrund der DAG-Struktur ist es lediglich erforderlich, dass neue Transaktionen jeweils zwei bis acht weitere Transaktionen referenzieren. Im Gegensatz zur Blockchain, an der Blöcke einzeln aneinander gekettet werden müssen, ist der Tangle somit von Natur aus skalierbar.

Bei IOTA gibt es im Grunde keine protokollbedingten Engpässe - die Skalierbarkeit ist einzig und allein durch die Hardware und die Gesetze der Physik beschränkt. Derzeit ist der Coordinator noch ein Engpass, welcher das Protokoll an der Skalierung hindert. Zudem stellt der Coordinator einen "Single Point of Failure" dar und verhindert, dass IOTA ein vollständig dezentrales Netzwerk ist. Die Entfernung des Coordinators ist aus diesen genannten Gründen das nächste große Ziel der IOTA Foundation.

Der verbesserte Tangle nach dem Coordicide: Dezentral, skalierbar und sicher

Die Entfernung des Coordinators allein reicht nicht aus, um das Skalierbarkeits-Trilemma sicher und dezentral zu lösen. Für ein solches Netzwerk müssen weitere Sicherheitsmodule implementiert werden, damit einer hohen Transaktionsrate nichts mehr im Wege steht. Kern der Lösung ist eine zusätzliche Sicherheitsebene mit dem proaktiven Abstimmungsmechanismus namens "Shimmer", über den alle Nodes die Meinungen der anderen Nodes anfordern. Mittels derer soll entschieden werden, welche Transaktionen in den Tangle aufgenommen und welche abgewiesen (verwaist) werden sollen.

Um den Coordinator vollständig zu entfernen, müssen eine Reihe von Herausforderungen gelöst werden. Aufgrund der Komplexität der Lösung wird das Vorhaben in einzelne Komponenten zerlegt. Dieser Ansatz macht das Vorhaben und das zukünftige Protokoll modular, sodass jedes Modul unabhängig von den anderen ersetzt werden kann, falls neue Forschungsergebnisse in Zukunft zu besseren Lössungsansätze führen.

Schlüsselfaktoren der IOTA Distributed-Ledger-Technologie im produktionsfertigen Zustand (nach der Entfernung des Coordinators)

• Vollständige Dezentralisierung: Als global verteiltes Netzwerk ist IOTA widerstandsfähig und robust gegen Angriffe. Ohne den Coordinator wird keine Instanz eine besondere Rolle im Netzwerk spielen. Um es deutlich zu machen: Sobald der Coordinator abgeschaltet ist, kann nicht einmal die IOTA-Stiftung den Coordinator ohne Zustimmung des mehrheitlichen Netzwerks wieder starten.

• Permissionless/Erlaubnisloser Zugang zum Netzwerk: Jeder - oder besser: Alles - kann dem Netzwerk jederzeit beitreten, um Transaktionen hinzuzufügen und zu validieren. Anders, als bei anderen DLTs, die ihre Nodeanzahl begrenzen oder Einbußen an der Skalierbarkeit hinnehmen müssen, begrüßt IOTAs Ansatz alle zusätzliche Nodes. Eine größere Anzahl von ehrlichen Nodes verbessert die Sicherheit des Netzwerks, indem sie im Normalfall den Anteil der ehrlichen Stimmen im Netzwerk erhöht.

• Partitionstolerant: Ein produktionsfertiger Tangle ist partitionstolerant. Das bedeutet, ein Teil des Tangle kann für eine bestimmte Zeit vom Main-Tangle abgetrennt werden und ohne Internetverbindung weiterlaufen. Diese Teile können erneut mit dem Main-Tangle verbunden werden, wenn die Internetverbindung wiederhergestellt wurde.

• Endgültigkeit innerhalb von Sekunden: Der Abstimmungsprozess ermöglicht es dem Netzwerk, Entscheidungen über Transaktionen sehr schnell zu treffen und abzuschließen, ohne aus Sicherheitsgründen auf mehrere zusätzliche Genehmigungsvorgänge warten zu müssen. Darüber hinaus kann das Netzwerk "wahre Endgültigkeit" (deterministisch statt probabilistisch) erreichen, da selbst ein Angreifer mit unbegrenzter Hashing-Power den Ledger-Zustand nicht "zurückrollen" kann.

• Zuverlässiger Zeitstempel: Der letzte Zeitpunkt einer Nachricht, die bestätigt wurde, wird als "tangle time" bezeichnet. Das Netzwerk erzielt eine Einigung über die Glaubwürdigkeit von Zeitstempeln und ermöglicht so, ein vollständig geordneten Tangle zu etablieren - ein großer Schritt hin zu Smart Contracts.

• Skalierbarkeit: Eine erhöhte Netzwerkaktivität verringert die Zeit in der Transaktionen abgewickelt werden - es gibt somit keine protokollbedingten Engpässe. Die Skalierbarkeit ist nur noch durch die Hardware und die Gesetze der Physik eingeschränkt. Die Eliminierung des Coordinators, der aktuell noch alle Transaktionen verarbeitet und verifizieren muss, bildet die Grundlage für einen dynamischen Sharding-Prozess, der eine "echte" unbegrenzte Skalierbarkeit ermöglicht.

• Ein adaptiver Ratenregelungsalgorithmus, der auf Nodebasis arbeitet, wird es Angreifern unmöglich machen, das Netzwerk mit Spam zu überfordern. Ehrliche Nodes können währenddessen weiterhin ungestört arbeiten.

• Erhöhte Zuverlässigkeit: Durch Abstimmung (voting) wird entschieden, welcher Teil des Tangles wahr ist. Es besteht die Möglichkeit unterschiedliche Strategien zur Wahl der noch nicht genehmigten Transaktionen (Tip-Selektion) einzusetzen, so dass die meisten (wenn nicht sogar alle) ehrlichen Transaktionen aufgegriffen werden können. Dies reduziert den Bedarf an "Reattachments" und "Promotionen" (Transaktionen mussten in der Vergangenheit öfters nochmal an den Tangle angehängt werden).

• Sicherheit (Mana): Der neuartige Sybil-Schutzmechanismus namens Mana in Kombination mit einem weiteren Sicherheitsmechanismus, dem Voting-Machanismus, sichert das Netzwerk selbst gegen eine großen Anzahl von böswilligen Akteuren ab.

• Intelligentes und stabiles Auto-Peering: Der Wegfall des manuellen Peering (d.h. Verbindung des eigenen Nodes zu Nachbar-Nodes) reduziert den Wartungsaufwand für die Nodebetreiber und macht das Netzwerk stabiler.

• UTXO-Modell: Jeder Token auf einer Adresse ist eindeutig identifizierbar und jede Ausgabe benennt genau die Token, die sie bewegen möchten. Dies ermöglicht eine schnellere und genauere Konfliktbehandlung und verbessert die Belastbarkeit sowie die Sicherheit des Protokolls.

• Gebührenfreie Transaktionen: Das Fehlen von Minern macht IOTA-Transaktionen komplett gebührenfrei: Person A sendet einen Cent an Person B und Person B erhält exakt diesen einen Cent. Dies erlaubt echte Mikrozahlungen für die Maschine-zu-Maschine-Ökonomie und ermöglicht damit auch die Zahlung von Kleinstbeträgen oder verbrauchsabhängige Bezahlungen.

• Weniger Dokumentation: Unternehmen müssen gebührenfreie Transaktionen nicht für das Finanzamt dokumentieren oder für Jahre speichern.

• Lokale Snapshots: ermöglichen es Nodes, nur eine Teilmenge der Historie des Ledgers zu speichern, sodass auch Nodes mit begrenzten Hardware-Ressourcen am Netzwerk teilnehmen können.

• Fairness: Alle Transaktionen werden gleich behandelt. Es gibt keine Möglichkeit, bspw. durch Prämienzahlungen (oder erhöhte Gebühren), eine höhere Priorität für die Verarbeitung durch das Netzwerk zu erhalten.

• Schlankes System: Konzipiert für Geräte, wie z.B. Sensoren, die an einem Niedrigenergie-Netzwerk teilnehmen möchten.

• Modularität: Ein modularer Aufbau ermöglicht es, Bestandteile des Protokolls unabhängig voneinander weiterzuentwickeln. Der mehrschichtige Ansatz ermöglicht es zukünftig Updates des Basisprotokolls, in ähnlicher Weise wie beim Internetprotokoll, durchzuführen. Ein Protokoll, welches sich nicht updaten lässt, ist kein Protokoll!

• Zuverlässige Führung: Die IOTA Foundation als gemeinnützige Organisation nach deutschem Recht optimiert die Akzeptanz und zukünftige Entwicklungen des IOTA-Netzwerks. Das Fehlen von Minern ermöglicht es, neue Funktionen ohne Interessenkonflikte umzusetzen.

• Open-Source: Die Technologie ist kostenlos, Open Source und jede Person kann Lösungen darauf aufbauen.

• Unveränderlich: Es wird sichergestellt, dass die Informationen vertrauenswürdig sind und nicht manipuliert werden können.

• Daten-Transaktionen: Sind unabhängig zu Werte-Transaktionen. Die sogenannten "Messages" (Nachrichten) ermöglichen Anwendungsfälle, die über finanzielle Belange hinausgehen. Die große Mehrheit aller Transaktionen werden reine "Messages" (also Transaktionen ohne Wert) sein. Das können Daten sein, die bspw. von Sensoren erfasst oder von Apps ausgetauscht und auf Marktplätzen gehandelt werden. Es gibt aber natürlich noch etliche andere Anwendungsfälle... In dem Bild unten ist zu sehen, wie allein durch die IOTA-Architektur der schnelle Austausch von Daten und Werten gegenüber der Blockchain begünstigt wird.

Lösungen für unterschiedliche Anwendungsfälle

Die Sicherstellung des Wahrheitsgehaltes ist genau das, was die Distributed Ledger Technologie ermöglicht. IOTA ist ein Protokoll, welches einen Konsens über den Stand der Dinge in einem Netzwerk erzielt, indem es eine einzige, kryptographisch sichere Quelle mit einer einheitlichen Wahrheit zur Verfügung stellt. Dies wird in Zukunft eine große technologische Innovationsexplosion nach sich ziehen und völlig neue Anwendungsfälle bzw. Geschäftsfelder mit Begleitökonomie ermöglichen, die in der Vergangenheit nicht denkbar gewesen sind, da sie bspw. zentralisiert, nicht skalierbar, zu teuer oder nicht sicher waren bzw. die Regeln des Datenschutzes verletzt haben.

IOTA wird für eine Vielzahl dieser neuen Anwendungsfälle Lösungen anbieten. Nachfolgend einige Teaser der zukünftig wichtigsten Aspekte:

Vielseitig einsetzbar: Indem es die Privatsphäre und die Sicherheit in einem offenen Netzwerk verbessert, kann das IOTA-Protokoll auch als Instrument zur Erhaltung eines freien und offenen Internets eingesetzt werden.

Mikrotransaktionen: Gebührenfreie Transaktionen ermöglichen erstmals echte Mikrozahlungen. Sowohl für den Menschen als auch für die Maschine-zu-Maschine-Ökonomie, um damit bspw. die Zahlung von Kleinstbeträgen oder verbrauchsabhängige Bezahlungen sinnvoll umzusetzen.

Maschinenwirtschaft: Die Maschine-zu-Maschine-Ökonomie ist eine Wirtschaft, in der Maschinen selbstbestimmte Marktteilnehmer sind, die über eigene Bankkonten verfügen. Die wachsende Verbreitung des Internets der Dinge (IoT) und die Fortschritte bei der künstlichen Intelligenz ermöglichen es vernetzten, intelligenten Maschinen autonom zu agieren. Das bedeutet, Maschinen werden in Zukunft direkt miteinander kommunizieren, untereinander Daten austauschen und sich gegenseitig für Dienstleistungen bezahlen, ohne dass eine menschliche Interaktion erforderlich ist.

Digitale Identität: Das Internet bildet die Grundlage für viele unserer Interaktionen in der modernen Welt. Es bietet neue Geschäftsmöglichkeiten, bessere Kundenzufriedenheit und eine Verbesserung unseres täglichen Lebens. Jedoch offenbart es auch immense Schwächen hinsichtlich Vertrauen und Privatsphäre. Mit einem dezentralen digitalen Identitätsprotokoll wird IOTA diese essenziellen Eigenschaften beisteuern.

IOTA Stronghold: Stronghold ist eine Sammlung von Mehrzweckbibliotheken zur geschützten Verwaltung von Passwörtern, persönlichen Daten und privaten Schlüsseln. Es ist eine sichere Software-Implementierung mit dem alleinigen Zweck, digitale Geheimnisse vor der Gefahr durch Hacker und versehentliche Leaks zu isolieren. Sie verwendet versionierte, dateibasierte Snapshots mit doppelter Verschlüsselung, einfacher Datensicherung und ermöglicht einen sicheren Austausch zwischen Geräten. Die hochgradig entwicklerfreundlichen Bibliotheken integrieren das IOTA-Protokoll und dienen als Referenzimplementierung für jeden, der nach Inspiration oder den besten Tools seiner Klasse sucht. Die Low-Level-Bibliotheken haben keinerlei Bezug zur Kryptowährung oder dem Tangle. Diese Funktionen befinden sich auf höherer Ebene, so dass Stronghold auch für Software-Projekte eingesetzt werden kann, die nicht direkt etwas mit Distributed Ledger zu tun haben, sondern bspw. lediglich ihre wertvollen Daten lokal schützen wollen. Mit anderen Worten: Jede Person aus jeder Branche kann sie nutzen.

IOTA Streams: Streams verfügen über eine integrierte Methode zum Senden von Nachrichten an IOTA-Nodes. Sie sind jedoch auch so flexibel, dass sie erweitert werden können, um Nachrichten auf anderen Wegen zu senden, z.B. in HTTP-URLs. Es handelt sich um ein multifunktionales Second-Layer-Datenübertragungsprotokoll, welches für verschiedene Arten der Datenübertragung (z.B. Streaming-Daten) verwendet werden kann. Sensoren und anderen Geräten ermöglicht IOTA Streams, ganze Datenströme zu verschlüsseln und im IOTA-Tangle zu verankern. Das Konsensprotokoll von IOTA fügt diesen Nachrichtenströmen Integrität und Authentizität hinzu. IOTA Streams erfüllt das Bedürfnis vieler Industriezweige nach Integrität, Datenschutz und Unveränderbarkeit von Daten.

IOTA Access: IOTA Access ist ein Open-Source-DLT-Framework für den Aufbau richtlinienbasierter Zugangskontrollsysteme und stellt Pay-per-Use-Funktionalitäten an den Endgeräten bereit. Es wurde entwickelt, um eine fein abgestufte Zugangskontrolle für jede Maschine, jedes Gerät und jedes Gebäude zu ermöglichen, ohne auf ein zentralisiertes System angewiesen zu sein oder eine ständige Internetverbindung zu benötigen. Bei IOTA Access geht es um die Ermöglichung von Dienstleistungen und Sicherheit in großem Maßstab. Jedes Gerät, welches einen solchen Dienst anbieten soll, kann Access integrieren, um diesen Service durch eingebettete Zugangskontrollrichtlinien zu automatisieren. Auf diese Weise können Gerätenutzer und -besitzer den Zugriff auf ihr Gerät oder ihren Datenstrom auf überprüfbare Weise gewähren oder anfordern.

Digital Assets: Das sind zweckgebundene Token, die Vermögenswerte aus der realen Welt auf dem IOTA-Tangle manipulationssicher darstellen können. Sie sind nicht dafür vorgesehen, Geldwerte zu handeln – mit ihnen könnte man bspw. etwas einlösen oder Eigentumsverhältnisse regeln. Konkret geht es hierbei um die Tokenisierung von Vermögenswerten wie z.B. Immobilien, Automobilen, Unternehmensanteilen oder Goldbarren.

IOTA Smart Contracts: Ein Smart Contract (dt. Intelligenter Vertrag) ist eine programmierte Vereinbarung, die vollständig deterministisch ist und automatisch durchgeführt wird. Dazu werden die vertraglichen Verpflichtungen zwischen Käufer und Verkäufer verkapselt und in der Software verankert. Dies macht es unmöglich der getroffene Vereinbarung zu widersprechen.

Der Hauptunterschied von IOTA Smart Contracts zu herkömmlichen Smart Contracts (wie bspw. im Ethereum-Netzwerk) ist die Multi-Chain-Umgebung, die durch den Tangle gesichert ist und auf diese Weise viele reguläre Blockchains parallel ausführen kann. Die IOTA Smart-Contract-Chains laufen asynchron - daher hat die Aktivität eines Smart Contracts keinen Einfluss auf die Geschwindigkeit und den Durchsatz der anderen Smart-Contract-Chains.

Volatile und unvorhersehbare Gebühren sprechen oftmals gegen die Nutzung von Smart Contracts. In IOTA Smart Contracts werden die Gebühren vom Eigentümer festgelegt, beginnen bei 0 und sind im Voraus bekannt. Es gibt keinen "Bieterkrieg" wie bei regulären Blockchains, weshalb Geschäftsmodelle und Einnahmequellen kalkulierbar sind.

IOTA Smart Contracts sind hochflexibel. Die Committees (Ausschüsse) können von einer Einzelperson, einem Unternehmenskonsortium oder über einen offenen Marktplatz mit freiem Zugang für die Validator-Nodes gebildet werden.

IOTA Smart Contracts sind skalierbar. Mehrere Smart-Contract-Chains, die von verschiedenen virtuellen Maschinen (VMs) betrieben werden, können gleichzeitig, also parallel über mehrere Committees laufen.

IOTA Oracles: Operationen, wie bspw. Smart Contracts, die in einem DLT ausgeführt werden, sind unter Umständen auf Daten angewiesen, die außerhalb des Netzwerkes liegen. Wie kann man nun sicherstellen, dass auch diese Daten vertrauensvoll sind? Hier kommen sogenannte Oracles ins Spiel: sie wurden entwickelt, um eine sichere Brücke zwischen der digitalen und der physischen Welt zu bauen. Oracles sind digitale Agenten, die Ereignisse aus der Realwelt verfifizieren und dezentralen Anwendungen und Smart Contracts zur Verfügung stellen. In der Praxis leiden Oracles unter einem uralten Problem, was oft als "Garbage in, garbage out" (dt. Müll rein, Müll raus) bezeichnet wird: Wenn die Daten, die in ein Oracle eingehen, bereits manipuliert oder zensiert wurden, werden "falsche" Daten zu "falschen" Ergebnissen verarbeitet. Einige Oracle-Lösungen versuchen dieses Problem zu lösen, indem sie sicherstellen, dass die Eingaben für Oracles aus einer ausreichend großen Anzahl unabhängiger Quellen stammen. Andere Oracles auf dem Markt haben eine Reihe von Standards vorgeschlagen, um Daten aus der Realwelt auf die Chain zu bringen. Aber auch sie leiden unter inhärenten Engpässen, die ihren Einsatz behindern können. Aus Sicht von IOTA sollten vertrauenswürdige Daten, die dezentral verarbeitet und gesichert werden, immer direkt von der Ursprungsquelle stammen.

Das Potential der Datenmanipulation wird stark reduziert, wenn die Quelle (z.B. ein Sensor) die Daten direkt, also ohne den Umweg über mehrere Intermediäre, an ein manipulationssicheres Distributed Ledger übergibt. Das einfachste IOTA-Oracle ist das s.g. First-Party-Oracle. IOTA-First-Party-Oracles nutzen weder externe Datenquellen noch Daten, die von einem Dritten verarbeitet und auf einem DLT zur Verfügung gestellt wurden, sondern trauen nur den Daten, die vom Datenherausgeber exklusiv an den IOTA-Tangle übermittelt wurden. Da der Datenherausgeber im Kontext von IoT-Netzwerken der Sensor selbst ist, kann man sich darauf verlassen, dass die Datenströme von nichts und niemandem manipuliert oder umformatiert wurden. Sobald IOTA Smart Contracts live sind, können First-Party-Oracles verwendet werden, um Smart Contracts direkt mit validen Daten zu füttern, ohne einen Vermittler zwischenschalten zu müssen, der die Daten abruft, verarbeitet, hostet oder pflegt. Im Gegensatz zu einigen anderen Lösungen auf dem Markt interagiert die IOTA Foundation niemals mit Daten, die von Drittanbietern bereitgestellt wurden. Zu diesem Zweck werden Daten durch das Projekt Alvarium über eine Vertrauensbewertung (Confidence Score) validert.

Flash Channels: Ein Flash Channel ist ein offline Zahlungskanal für Ein- und Auszahlungen zwischen zwei Entitäten, der sofortige Transaktionen mit hohem Durchsatz ermöglicht. Im IOTA-Tangle werden dafür nur zwei Transaktionen benötigt: Das Öffnen und Schließen eines Flash-Kanals. Anschließend bieten sie den beiden Geschäftspartnern die Möglichkeit, mit hoher Frequenz zu handeln, ohne darauf zu warten, dass jede Transaktion im öffentlichen IOTA-Netzwerk bestätigt wird. Dieses Feature wird zukünftig innerhalb von IOTA Streams umgesetzt.

Digitale Marktplätze: Daten werden seit einiger Zeit als das neue Öl der digitalen Welt bezeichnet. Ein Grundgedanke des IoT ist der Austausch und Handel von solchen Datensätzen. Mit der „Maschine zu Maschine“-Kommunikation können Geräte die verschiedensten Daten autonom untereinander handeln. Aber auch für den Menschen könnte es sehr interessant werden, sich den Umweg über eine Drittanbieter-Plattform zu sparen und Daten oder Güter direkt vom sensorischen Produzenten zu erhalten. Das Erschaffen von Datenmarktplätzen ist eine unvermeidliche Konsequenz der IoT-Revolution. Es wird die Art und Weise, wie wir Daten verbinden, mit ihnen interagieren oder sie handeln, grundlegend verändern.

Digitale Zwillinge: Ein digitaler Zwilling ist eine digitale Repräsentanz eines materiellen oder immateriellen Objekts oder Prozesses aus der realen Welt in der digitalen Welt. Das Industrial IOTA Lab Aachen, Pickert, ECLASS und das Digital Twin Konsortium treiben diese Technologie für IOTA voran und versuchen standards zu entwickeln.

Anwendungsgebiete

Grundsätzlich wird heute fast jede Branche digitalisiert und mit dem IoT verknüpft. Dementsprechend kann jeder seine Vorteile daraus ziehen. Die IOTA Foundation beschreibt einige Anwendungsfälle in einer von ihr veröffentlichten interaktiven Broschüre:

Stammtisch - IOTA, Bier und Diskussionen

Virtueller Stammtisch

Wo? Im einfachIOTA Discord im Voice Channel: #Stammtisch. Nebenbei wird in der #kneipe gechattet. Dort musst du zum Startzeitpunkt in den Voice Channel "Stammtisch" wechseln.

Wann? Jeden Montag ab 20:15 Uhr!

Wer? Jeder der mag!

Wie? Das Mikrofon und der Ton lässt sich bei den Benutzereinstellungen unter "Sprach- und Videochat" testen. Neue Teilnehmer haben zunächst "Push to talk" eingestellt. Wer mit der "Mute" Taste umgehen kann, bekommt gerne auch die Rolle "Plaudertasche" zugewiesen

Regeln?

1. Was im Stammtisch passiert bleibt im Stammtisch!
2. Wenn der Kuchen (IOTA A-Promis) redet, haben die Krümel (IOTA B-/C-Promis) Pause
3. IOTA bezogene Themen sollten im Vordergrund stehen
4. Längere Monologe sollten vermieden werden. Bitte (Atem-)Pausen einbauen, damit andere Personen zu Wort kommen können!
5. Alkohol ist gut, zu viel Alkohol eher nicht. Vor allem wenn man noch mitreden will...

Themen?

Was wird im Stammtisch diskutiert?

Unser Community Manager vrom stellt jede Woche eine Liste mit aktuellen IOTA Themen vor. Jeder hat die Möglichkeit eigene Themen hinzuzufügen. Vorschläge für Themen kann jeder auf dem IOTA Community Github machen!

Links

• Liste

Was ist ...

In der "Was ist"-Artikelreihe versuchen wir die vielen verschiedenen Projekte der IOTA Foundation und ihrer Community zu erklären. Viel Spaß beim Lesen!

Was ist "Dust Protection"?

Da IOTA "feeless" - also gebührenfrei - ist und man somit problemlos Mikrotransaktionen senden kann (z.B. einen einzigen IOTA-Token, sprich ein IOTA), können Angreifer durch das Versenden zahlreicher Mikrotransaktionen das Netzwerk sehr einfach und ohne großartige Kosten "zuspammen". Die aus den Mikrotransaktionen resultierenden Adressen mit einer sehr kleinen Balance bezeichnen wir als "Dust", also zu deutsch: "Staub". Um "Dust" im Netzwerk zu vermeiden, sind Mikrotransaktionen mit weniger als einer Million IOTA-Token (1 MIOTA) an eine andere Adresse nur erlaubt, wenn die Versandadresse bereits vorher mit einem Mindestbetrag "aufgeladen" wurde. Diese erste Transaktion ist sozusagen die Initialtransaktion für die nachfolgenden Mikrotransaktionen.

Wie funktioniert das konkret?

Die "Dust Protection" ist fest im Kernprotokoll verankert.

Jede Node im Netzwerk muss zwingend den Kontostand jeder einzelnen Adresse - abgesehen von Nullwert-Adressen - kennen. Ansonsten könnten Netzwerkteilnehmer mehr IOTA-Token versenden als sie haben, es käme zum klassischen double spent.

Diesen Umstand könnten Angreifer jedoch als Angriffsvektor nutzen, indem man schlicht sehr viele Adressen mit bspw. jeweils einem IOTA "auflädt". Dann müssten all diese Adressen vom gesamten Netzwerk gespeichert werden, wodurch der grundsätzliche Speicherbedarf den jede Node hat - selbst ohne die aktuelle Historie aller Transaktionen zu sichern - ins Unermessliche ansteigen würde. Um das Ganze noch einmal zu verdeutlichen: Mit 1 MIOTA (Gegenwert zum Zeitpunkt dieses Artikels in etwa $0,75), könnte man bereits 1 Mio. Adressen mit jeweils 1 IOTA "dusten" und diese 1 IOTA-Balance-Adressen müssten dauerhaft von allen Nodes gesichert werden. Dies ist jedoch im Zuge von Chrysalis mit der Einführung einer sogenannten "minimum balance" - also einem minimalen Guthaben, das jede Adresse aufweisen muss - deutlich teurer bzw. faktisch nicht "bezahlbar" für einen Angreifer geworden. Konkret liegt das minimale Guthaben aktuell bei 1 MIOTA pro Adresse, dieser Betrag kann aber in Zukunft noch angepasst werden.

Dadurch wird es jedoch nicht unmöglich, Beträge unter 1 MIOTA zu versenden. Denn sobald eine Adresse das minimale Guthaben von mind. 1 MIOTA aufweist, kann man damit 10 kleinere Transaktionen von beliebiger Höhe empfangen oder versenden, bis man wieder den Mindestwert aufladen muss. In der Wallet müssen dafür sogenannte "SigLockedDustAllowanceOutputs" freigeschaltet sein. Wenn auf einer Adresse beispielsweise 1,064 MIOTA liegen, kann man natürlich nicht einfach 1 MIOTA versenden und den verbleibenden Dust auf der Adresse zurück lassen, weil es dann nach der Transaktion wieder < 1 MIOTA wären, was nicht erlaubt ist. Deswegen muss man in diesem Fall den Dust vorher oder gleichzeitig senden.

Was ist "EdDSA Support"?

Das bisherige IOTA-Protokoll basierte auf dem Winternitz One-Time Signature (W-OTS) Schema, einem Hash-basierten Signaturschema, das die ternäre 243-Trit-Hash-Funktion Kerl verwendet. Dieses Signaturschema ist nachweislich resistent gegen einen ausreichend leistungsfähigen Quantencomputer, auf dem der Shor-Algorithmus läuft. Allerdings hat es im Gegensatz zu herkömmlichen ECDSA- oder EdDSA-Signaturen auch erhebliche Nachteile:

Zustandsabhängigkeit: W-OTS erlaubt nur einen einzigen sicheren Signiervorgang. Ab der zweiten Signatur sind so viele Informationen offengelegt, dass der private Schlüssel und damit das Geld auf dieser Adresse als unsicher gilt. Dies stellt ein ernsthaftes Sicherheitsrisiko dar, da das Signieren einer einzigen ungültigen Transaktion als ebenso gefährlich angesehen werden muss, wie die Offenlegung des privaten Schlüssels selbst.

Größe: Die erzeugten Signaturen sind recht groß. In IOTA wurden 2187 bis 6561 Trytes oder umgerechnet 1300 bis 3900 Bytes (je nach gewählter Sicherheitsstufe) für die Signatur reserviert.

Geschwindigkeit: Sie basiert auf der Hash-Funktion Keccak-384 und wurde entwickelt, um einen Kompromiss zwischen Größe und Geschwindigkeit zu erreichen. So muss die Hashing-Funktion in der Standardeinstellung 702 Mal ausgeführt werden, um eine Signatur zu validieren. Dies kann selbst auf leistungsfähiger Hardware zu erheblichem System-Overhead führen.

Mit dem Chrysalis-Update wurde das neue gebräuchliche Signaturschema Ed25519 eingeführt, welches das alte W-OTS Schema vollständig ersetzt. Das Ed25519 ist ein modernes EdDSA-Signaturschema, das SHA-512 und Curve25519 verwendet. Es reduziert die Transaktionsgröße drastisch und ermöglicht folglich eine deutliche Erhöhung der möglichen messages per second (mps). Ein weiterer Vorteil ist die Wiederverwendbarkeit von Adressen, wodurch sich sowohl die Benutzerfreundlichkeit deutlich erhöht, als auch die Implementierung der IOTA Technologie in Apps, Börsen oder anderen Systemen erheblich vereinfacht wird. Ein Nachteil ist jedoch, dass das EdDSA-Signaturschema weniger quantenrobust ist. Dieses Problem haben allerdings derzeit die meisten herkömmlichen Verschlüsselungssysteme. Aktuell wird bereits weltweit an geeigneten neuen Signaturschemen geforscht und sobald es eine praktikable und sichere Lösung gibt, kann diese von IOTA einfach übernommen werden.

Was ist "Atomic Transaction"?

IOTA 1.0 verwendete das Konzept der Bundles zur Erstellung von Transfers. Bundles sind eine Reihe von Transaktionen, die über ihre Stamm-Referenz (trunk) miteinander verbunden sind. Diese Transaktionen haben ein festes Layout und eine feste Größe - unabhängig von ihrem "Inhalt". Eine Signatur mit Security Level 1 würde in nur eine Transaktion passen, standardmäßig werden jedoch Security Level 2-Signaturen verwendet. Da also die Level 2-Signatur von Wert-Transaktionen nicht in eine einzelne Transaktion passt, müssen mind. drei Transaktionen verwendet werden, um eine vollständige Übertragung zu gewährleisten: Zwei Transaktionen inkl. der Signatur für die Eingabe und eine weitere Transaktion ohne Signatur. Mit einem weiteren Nachteil von Bundles haben vor allem die Entwickler zu kämpfen: Es ist wesentlich komplizierter, alle Transaktionen von einem Bundle zu erhalten und diese richtig zu ordnen, als nur eine einzelne Nachricht (message) zu verarbeiten.

Mit dem Update auf IOTA 1.5 wurde das alte Bundle-Konstrukt entfernt. Stattdessen wurden die einfacheren Atomic-Transactions eingeführt. Dieser Wechsel bringt folgende Vorteile mit sich:

Weniger Netzwerk-Overhead: Das Transaktions-Format kann so angepasst werden, dass nur die wirklich notwendigen Daten übertragen werden. Auf unnötige Informationen, wie z.B. die 2. Signaturtransaktion der aufeinanderfolgenden Transaktionen eines Bundles, kann verzichtet werden. Der Einsatz des UTXO Modells hätte diese Situation noch verschlimmert und noch mehr Transaktionen verwendet, um eine einfache Übertragung durchzuführen.

Weniger Signaturüberprüfungen: Nach dem Coordicide muss jede Transaktion die Node-ID und die Signatur der Node enthalten, welche die Transaktion ausgestellt hat. Das bedeutet, dass für eine einfache Übertragung die Signaturen von mind. drei Transaktionen überprüft werden müssen. Die Signaturüberprüfung ist jedoch der aufwendigste Teil der Transaktionsverarbeitung, sodass die Einführung von Node-IDs unter Beibehaltung des ursprünglichen Bundle-Ansatzes die Leistung der Nodes um mind. 300% reduziert hätte. Unter dem Strich würden die Nodes hunderte, vielleicht sogar tausende von Transaktionen weniger verarbeiten können, als dies bei Atomic-Transactions, welche nicht in Bundles aufgeteilt sind, der Fall ist.

Besserer Spamschutz und Überlastungskontrolle: Die Größe des Bundles ist erst bekannt, wenn die letzte Transaktion eingetroffen ist und geprüft werden kann, ob es sich um ein valides Bundle handelt. Dies kann dazu führen, dass erst einmal einige Transaktionen akzeptiert und weitergeleitet werden um später feststellen zu müssen, dass die ausgebende Node ihre Quote (rate control) bereits überschritten hat und alle weiteren Transaktionen ignoriert werden. Somit werden Transaktionen geroutet und verarbeitet, die eigentlich schon zu Beginn hätten herausgefiltert werden müssen, da sie insg. die maximale Bundle-Größe überschreiten. Dies bietet schlimmstenfalls sogar eine Angriffsfläche, in dem eine Node verschiedene Bundles an verschiedene Personen ausgibt und diese beginnen, die Transaktionen des Bundles zu verarbeiten, um sie dann zu einem späteren Zeitpunkt wieder fallen zu lassen. Die Last im Netzwerk würde unnötig erhöht werden.

Kürzere Merkle-Proofs (für Sharding): Die Merkle-Proofs für Inter-Shard-Transaktionen werden viel kürzer (mind. 300%), wenn nicht alle Transaktionen in einem Bundle durchlaufen werden müssen, um zum nächsten Transfer zu gelangen. Dadurch werden Inter-Shard-Transaktionen viel schneller und leichtgewichtiger.

Entwicklerfreundlich: Einzelne Nachrichten lassen sich viel einfacher verarbeiten.

Schlussfolgerung: Atomic-Transactions sind durch die variable Transaktionsgröße wesentlich schneller bzw. flexibler und belasten das Netzwerk somit weniger. Zudem sind sie für das spätere Sharding/Slicing besser geeignet als Bundles.

Was ist "UTXO"?

Die Implementierung des neuen Ledger-State (dt. Kassenbuchstatus) war einer der letzten Bausteine für den voll funktionsfähigen Prototypen des Tangle ohne Koordinator. Mit dem UTXO-Modell wurde es direkt auf die richtige Art implementiert. UTXO steht für "unspent transaction output", was einfach bedeutet, dass man nicht nur die Guthaben auf der Adresse im Auge behält, sondern auch den Überblick darüber, woher die Guthaben stammen und wohin sie versendet wurden. Jeder Token ist eindeutig identifizierbar und jede Ausgabe benennt genau die spezifischen Token, die sie bewegen möchte.

Das Modell der "nicht verbrauchten Transaktionsausgaben (UTXO)" definiert einen Ledger-Zustand, bei dem die Salden nicht direkt mit Adressen, sondern mit den Ausgaben von Transaktionen verbunden sind. In diesem Modell verwenden Transaktionen die Ausgaben früherer Transaktionen als Eingaben, die für neue Ausgaben verbraucht werden müssen. Eine Transaktion muss also immer die Gesamtheit der Eingaben verbrauchen. Damit wird sichergestellt, dass niemand mehr ausgeben kann, als er hat.

Das alte Modell: Das IOTA 1.0 DLT verwendete ein Guthabenmodell zur Verfolgung von Adressen, bei dem jeder Adresse lediglich ein einziger Wert zugeordnet war, nämlich der aktuelle Guthabenstand. Der Ledger-State kann daher als ein einfaches Verzeichnis von Adressen und ihren entsprechenden Guthaben betrachtet werden:

Adresse1 = Guthaben1

Adresse2 = Guthaben2

Adresse3 = Guthaben3

Probleme: Bei Konflikten wie double-spends (dt. doppelte Ausgaben) ist es schwierig herauszufinden, bei welcher von mehreren Transaktionen tatsächlich eine doppelte Ausgabe erfolgt ist und bei welcher Transaktion legitime Gelder verwendet werden.

Dies soll anhand des unten stehenden Bildes verdeutlicht werden:

Gehen wir von der ersten Tranksaktion, der Genesis aus. Es wurden auf Adresse A in zwei Transaktionen jeweils 5 IOTA gesendet. Das Gesamtguthaben auf Adresse A auf der zweiten Ebene beträgt also insgesamt 10 IOTA. Danach werden 3 Transaktion von Adresse A ausgeführt, die jeweils -5 MIOTA versenden, also insgesamt -15 IOTA von einer Adresse, die insgesamt nur 10 MIOTA Guthaben aufweist. Der Saldo ist nicht mehr korrekt. Schaut man sich die Transaktionshistorie aus Sicht der letzten 3 Transaktionen an (siehe Farbcodierung), ist jedoch jede Kette bis zur Genesis gültig. Wie kann man nun entscheiden, welche Transaktionen im Konfikt miteinander sind und welche akzeptiert werden kann?

!-----> hier stattdessen Bild mit farbigen Pfeilen einfügen (siehe 1a.jpg)? <----

Bild: Bei welcher dieser drei Transaktionen handelt es sich um double spending? Bei einem Guthabenmodell ist dies unklar, daher müssten alle 3 als double spending betrachtet werden.

Im IOTA 1.0 Netzwerk trat dieses Problem nicht auf, da der implementierte Konsensus nach der Regel "heaviest subtangle wins" (das schwerste Sub-Tangle bekommt den Vorzug) nur sicherstellen musste, dass die Adressen eines bestimmten Sub-Tangles niemals negativ werden. Dazu wurden die Stimmen vor der Tip-Auswahl "gezählt". Dieses Zählen der Stimmen war eine extrem aufwändige Operation, weil dafür ein Random Walk durchgeführt werden musste und somit ein massiver Engpass für die Skalierbarkeit des Protokolls geschaffen wurde.

Mit der neuen, auf Abstimmungen (voting) basierenden, Coordicide-Lösung ist es notwendig, die Konflikte bei Transaktionen bereits beim Auftreten so schnell und so genau wie möglich zu identifizieren, also bevor darüber abgestimmt wird. Das reduziert die Anzahl der Stimmabgaben, die ausgetauscht werden müssen, um einen Konsens zu bilden, massiv.

Ein weiteres Problem bei der Verwendung eines Guthabenmodells hängt mit den s.g. "reattachments" (das wieder Anfügen von Transaktion) zusammen. Wenn man einmal Tokens für eine Adresse erhalten hat, von der bereits Ausgaben getätigt wurden, konnte man die vorherige Ausgabe einfach wieder anfügen und die Adresse erneut leeren (auch ohne Zugriff auf den privaten Schlüssel der Adresse). In der Vergangenheit ist es vorgekommen, dass Nutzer den Hinweis, Adressen nur einmalig zu verwenden, nicht beachtet haben und somit Opfer eines Angriffes auf ihre Konten wurden.

Die Lösung: Wenn das UTXO-Modell verwendet wird, um die Guthaben zu verfolgen, enthält jede Adresse nicht nur ihr Gesamtguthaben, sondern auch mehrere Unter-Guthaben, die mit einer Markierung versehen sind. Diese zeigt an, durch welche Transaktion genau dieses Guthaben entstanden ist. Jeder Token auf einer Adresse wäre daher eindeutig identifizierbar und jede Ausgabe würde genau den Token referenzieren, den sie bewegen möchte. Dies hilft, Konflikte zu erkennen und auch böswillige Akteure davon abzuhalten, sich Guthaben zu erschleichen, indem sie eine alte Transaktion wieder anfügen.

In dem Beispiel-Bild ist durch die grüne Markierung erkennbar, welche Transaktionen sich aufeinander beziehen. Man sieht sofort, dass nur die gelb markierten Transaktionen sich im Konflikt zueinander befinden, die grün markierten können ohne weiter Abstimmung genehmigt werden.

Bild: Bei einem UTXO-Modell identifiziert jede getätigte Ausgabe eindeutig, welche Gelder ausgegeben wurden. Auf diese Weise kann direkt festgestellt werden, welche Transaktionen widersprüchlich sind (die gelben Gelder werden zweimal verwendet).

Die Verwendung eines UTXO-basierten Modells bietet mehrere Vorteile:

• Parallele Validierung von Transaktionen.
• Einfachere Erkennung von Doppelausgaben, da widersprüchliche Transaktionen auf dieselbe UTXO verweisen würden. Das bedeutet eine schnellere und genauere Konfliktbehandlung, dementsprechend wird die Belastbarkeit sowie die Sicherheit des Protokolls verbessert.
• Wiederholungsschutz für das Wiederverwenden von Adressen. Die Wiederholung einer gleichen Transaktion würde sich als bereits angewandt oder vorhanden manifestieren und somit keine Auswirkungen haben.
• Das UTXO-Modell ermöglicht auch, auf einfache Weise Features wie "Digital Assets" zu implementieren, bei denen Benutzer IOTA-Token so markieren können, dass sie eine vorher festgelegt "Bedeutung" haben (und behalten). Wenn man bedenkt, dass 99% der bestehenden "Smart Contracts" eigentlich nur dazu verwenden werden, Tokens zu kreieren, die sich auf einen bestimmten Anwendungsfall beziehen, ist dies ein interessantes Feature, welches einen großen Mehrwert für das IOTA-Ökosystem darstellt.

Technisch gesehen können Salden nicht mehr mit Adressen verknüpft werden, was den Abstraktionsgrad erhöht und somit andere Arten von Ausgaben ermöglicht. Man könnte bspw. einen Ausgabetyp definieren, der das Guthaben erst freigibt, wenn eine bestimmte Bedingung (PoW oder ein anderes Entsperrkriterium) erfüllt ist.

Innerhalb einer Transaktion, die UTXOs verwendet, bilden Eingänge und Ausgänge die zu signierenden Daten der Transaktion. Der Abschnitt, der die Eingänge entsperrt, wird Unlock-Block genannt. Ein Unlock-Block kann eine Signatur enthalten, die das Eigentum an der Adresse eines bestimmten Eingangs nachweist und/oder andere Unlock-Kriterien (Entsperrkriterien).

Das folgende Bild zeigt den Geldfluss mit UTXO:

Was ist "Autopeering"?

Autopeering: In Peer-to-Peer-Netzwerken wie IOTA sind die Nachbarn einer Node deren einzige Informationsquelle. Ein Peering-Mechanismus muss sich daher auf eine gesunde Anzahl ehrlicher Nachbarn konzentrieren, also auf Nodes, die nicht versuchen, das Netzwerk zu schädigen. Bei IOTAs Autopeering-Mechanismus hat jede Node ihre eigenen lokalen und privaten Kriterien für die Auswahl potenzieller Nachbarn. Ein Angreifer kann die Entscheidungen einer Node im Peer-Auswahlprozess nicht beeinflussen. Diese Vorgehensweise sorgt für eine gewisse Unvorhersehbarkeit der Netzwerktopologie. Dies dient dem Schutz vor Angriffen von außen (z. B. Eclipse-Angriffen) und macht es Angreifern praktisch unmöglich, bestimmte Nodes im Peering-Prozess gezielt anzugreifen, während sichergestellt wird, dass die Nodes immer mindestens eine bestimmte Anzahl ehrlicher Nachbarn haben.

Darüber hinaus wird der Autopeering-Mechanismus versuchen, ein kleines Weltnetzwerk zu erstellen, in dem jede Node von jeder anderen Node über eine kleine Anzahl von Zwischenschritten erreicht werden kann. Diese Eigenschaft beschleunigt die Zeit, um einen Konsens zu erzielen.

Was ist "White-Flag"?

Der White-Flag Ansatz zur Berechnung der Guthaben ist ein einfacher, konfliktvermeidender Ansatz, der die Geschwindigkeit und Effizienz der Tip-Selection (Auswahl unbestätigter Transaktionen) verbessert, bestimmte Angriffe (z. B. Konflikt-Spam) eliminiert und die Notwendigkeit von Reattachments deutlich reduziert. Das Tool zur Bereitstellung von Koordinator-Meilensteinen ist sehr leistungsstark, denn es liefert globale und unveränderliche Zeitstempel. Auf diese Weise wird eine genau definierte und global akzeptierte Methode bereitgestellt, um den Ledger-Status eines Meilensteins zu berechnen, selbst wenn dieser widersprüchliche Transaktionen in seiner Vergangenheit enthält. Da die Koordinator-Meilensteine essenziell sind, für die Funktion dieser White-Flag Methode, funktioniert sie nur im IOTA 1.5/Chrysalis-Netzwerk.

Vorteile des neuen Ansatzes:

• Die Komplexität der Bilanzberechnung entspricht in etwa der Komplexität der Sortierung aller neuen Transaktionen nach Hash (oder ähnlichem), was sehr effizient durchgeführt werden kann.
• Ein Konflikt hat keine anderen Auswirkungen auf das System als jede andere Transaktion auch. Somit wird ein Angriff durch Konflikt-Spam vollständig beseitigt.
• Ein Reattachment (erneute Anhängen von Transaktionen) ist einfach: Wenn zwei Reatachments durch Meilensteine genehmigt werden, wird der zweite ignoriert.
• Da Konflikte bei der Bilanzberechnung ignoriert werden, müssen sie von den Nodes bei der Auswahl von Tips auch nicht berücksichtigt werden. Dies ermöglicht viel einfachere Algorithmen für die Tip-Selection wodurch dieser Schritt erheblich beschleunigt wird.
• Wird dieser Ansatz regelmäßig in Kombination mit einem geeignetem Tip-Auswahl-Algorithmus (TSA) verwendet, muss keine ehrliche Transaktion jemals wieder erneut angehängt werden.

Was ist "URTS Tip-Selection"?

Der Algorithmus zur Tip-Auswahl ist das Verfahren, nach dem Transaktionen zur Genehmigung ausgewählt werden. Ein guter Algorithmus ermöglicht es, dass der Tangle auf eine stabile und sichere Weise wächst.

Aufgrund des White-Flag-Bestätigungsalgorithmus, den wir im vorherigen Artikel beschrieben haben, ist es nicht mehr notwendig, eine komplexe Tip-Auswahl wie den "random walk" (Zufallsweg) durchzuführen. In der Vergangenheit wurde dieser Algorithmus für die Tip-Auswahl verwendet, da dies nicht nur zu einer gesunden Tangle-Struktur führte, sondern es auch ermöglichte, den schwersten und damit bevorzugten Teil des Tangles zu identifizieren. Dieser Mechanismus war zwar für die Konsensfindung unerlässlich, zeigte aber auch Eigenschaften, die weniger wünschenswert waren. Daher wurde ein einfacherer und trotzdem leistungsfähigerer Algorithmus implementiert, der eine Steigerung des gesamten Nachrichtendurchsatzes ermöglicht.

Die neue Tip-Auswahl URTS (Uniformly-Random-Tip-Selection) erhöht die Zuverlässigkeit in der Node-Software und verringert den Bedarf an Reattachments und Promotionen. Der neue Prozess ist deutlich schneller und effizienter als der alte Ansatz bei IOTA 1.0.

Um eine neue Transaktion an den Tangle anzuhängen, kann der Algorithmus bis zu acht vorherige Transaktionen auswählen und genehmigen - vorzugsweise Tips. Dieser Genehmigungsmechanismus repräsentiert den "Glauben" an den Tangle: Wenn Transaktion y die Transaktion x genehmigt, bedeutet dies, dass y glaubt, dass Transaktion x und auch ihre gesamte Historie gültig sind.

Der in der Vergangenheit verwendete "random walk"-Algorithmus brachte unter anderem folgende negative Eigenschaften mit sich:

• Ehrliche Transaktionen konnten fallen gelassen werden, wenn sie nicht genügend Gewichtung hatten. Dies führte zu einem erhöhten Bedarf an Promotionen und Reattachments (auch ohne Angriffe), was wiederum die Zuverlässigkeit der Transaktionen deutlich beeinträchtigte.
• Angreifer haben mit dem "random walk" gespielt und bösartige Strukturen wie parasitäre Ketten erschaffen, mit denen Splitting-Angriffe durchgeführt wurden, die das Netzwerk daran hinderten, einen Konsens zu erzielen.
• Die Berechnung der kumulierten Gewichtungen von Transaktionen ist relativ aufwändig und stellt ein Problem für die Skalierbarkeit des Protokolls dar, insbesondere in Hochdurchsatzszenarien.

Durch das Hinzufügen einer Abstimmungsebene als zusätzliches Modul zur Identifizierung des bevorzugten Teils des Tangles ergeben sich folgende Vorteile:

• Schnellere Konfliktlösung und damit geringere Wahrscheinlichkeit, dass eine Transaktion versehentlich an den falschen Teil des Tangles angehängt wird.
• Verwenden von verschiedenen Mechanismen zur Tip-Auswahl, die nicht mehr auf der kumulativen Gewichtung basieren und damit weniger gültige Transaktionen fallen lassen.

Was ist "New Milestone Selection"?

Um das Ziel zu erreichen, möglichst alle Messages so schnell wie möglich durch den Koordinator zu bestätigen, wurde für diesen ein neuer Meilenstein-Auswahlalgorithmus entwickelt. Kurz gesagt, wählt der Koordinator die Tips für den Meilstenstein jetzt intelligent aus.

Der Koordinator erzeugt etwa alle 10 Sekunden einen Meilenstein, welcher wie jede andere Message auch mindestens zwei Tips referenzieren sollte. Tips sind die Messages im Tangle, die noch nicht von anderen Messages referenziert wurden (Grau im rechten Bereich des Bildes).

Der alte Algorithmus (Random Walk) hat einfach zufällige Tips genutzt. Der neue Algorithmus wählt auch erstmal zufällige Tips aus, überprüft sie dann aber einmal, um Tips zu nutzen, die möglichst viele andere Messages referenzieren.

Ein Tip, der nur wenige von den neuen Messages referenziert:

Ein anderer Tip, der viel mehr von den neuen Messages referenziert:

https://simulation1.tangle.works/

Was ist "Binary Transaction Layout"?

Die Umstellung auf eine interne binäre Darstellung der ternären Transaktion. Dies ermöglicht es, binäre Daten - also Einsen und Nullen - für die Validierung und andere Verarbeitungen zu verwenden, ohne dass binär-ternäre Konvertierungen wie in der alten IOTA 1.0 Node-Software erforderlich sind. Da alle modernen Computer Prozessoren enthalten, die nach dem binären Format arbeiten, führt dies zu weiteren Leistungsverbesserungen im IOTA-Netzwerk.

Technische Details: Im IOTA 1.0 Netzwerk besteht eine Transaktion aus 2.673 tryte-kodierten Zeichen und setzt sich aus verschiedenen Feldern unterschiedlicher Tryte-Längen zusammen.

Im neuen IOTA 1.5 Chrysalis Netzwerk haben Transaktion eine variable Größe. Die maximale Größe für Nachrichten beträgt 32768 Byte. Das Indexfeld des Indexierungs-Payloads hat eine maximale Größe von 64 Bytes.

Akuelles

Rückblick

Veröffentlichung von Shimmer Netzwerk und Token

• Nov 16, 2021

Das Shimmer Netzwerk ist ein incentiviertes IOTA Staging-Netzwerk, eine Art Entwickler Testumgebung mit eigenem nativen Token ($SMR). Du kannst deine IOTA-Token einsetzen, um Shimmer-Token vor dem Genesis-Start zu erhalten. Schau zukünftig auf dem Shimmer-Netzwerk vorbei, um frühzeitig Zugang zu wichtigen Innovationen zu erhalten, bevor sie im IOTA-Hauptnetz veröffentlicht werden.

Veröffentlichung von IOTA Staking

Nov 16, 2021

IOTA führt das Staking für alle IOTA-Tokenhalter ein. Stake IOTA-Token und verdiene Staking-Belohnungen von zum Beispiel Token-Airdrops. IOTA verwandelt sich in ein vollständig dezentrales, programmierbares Multi-Asset-Register (Mulit-Asset-Ledger). Das Shimmer-Netzwerk wird mit Assembly das erste Projekt sein, das das IOTA-Netzwerk nutzt, um die neuen Tokens gerecht zu verteilen.

IOTA Tokenization Framework Specifications

Nov 4, 2021

Tokenization ist eine der größten Innovationen im DLT-Raum und ermöglicht völlig neue Anwendungsfälle und Geschäftsmodelle. Native Token und NFTs sind im Tangle verankert und erben die unerschöpfliche und skalierbare Natur der Basiswährung, dem IOTA Token. Ein Brückenmechanismus des Native Tokenization Framework sorgt dafür, dass Smart Contract Tokens mühelos in native Token umgewandelt werden können.

IOTA Smart Contracts Beta Release

Oct 21, 2021

Die Beta-Version von programmierbaren Smart Contracts ist jetzt auf dem IOTA 2.0 DevNet verfügbar. Die IOTA Foundation geht einen großen Schritt, um IOTA eine neue Utility-Ebene hinzuzufügen. Der Release zeigt die Stärken des modularen Ansatzes, der sich speziell an Entwickler richtet. Smart Contracts kann man in verschiedenen Programmiersprachen wie z. B. Go, Rust oder Typescript schreiben - der Release beinhaltet auch eine Ethereum VM (EVM), welche die Programmiersprache Solidity unterstützt.

EBSI - Eine Distributed Ledger Technology (DLT) für Europe

Sep 7, 2021

Die IOTA Foundation ist einer von sieben Auftragnehmern, die für die Entwicklung innovativer DLT-Lösungen ausgewählt wurden, um anspruchsvollere europaweite Blockchain-Dienste zu ermöglichen. IOTA könnte eine der Technologien sein, die mit europäischen Diensten entwickelt und getestet werden. IOTA ist die ideale Technologie, um auf der von EBSI geplanten massiven Infrastruktur aufzubauen.

IOTA wurde als Kerntechnologie für SUSEE ausgewählt, um groß angelegte Sensornetzwerke zu ermöglichen

Aug 2, 2021

SUSEE (Secure Sensor Platforms for Smart Energy Networks) ist eine Zusammenarbeit zwischen dem Energieverteilungsnetzbetreiber SWO Netz, der TU Chemnitz, und den KMU peerOS, mCloud Systems und TIP. Eine skalierbare, zuverlässige und sichere Lösung für die Datenübertragung und -verarbeitung in Sensornetzwerken.

Auf dem Weg zur vollständigen Dezentralisierung mit IOTA 2.0

May 28, 2021

Die IOTA Foundation berichtete über den erfolgreichen Abschluss des Chrysalis-Upgrade im vergangenen Monat. IOTA bewegt sich in Richtung seiner vollständigen Dezentralisierung mit jedem Node, der zum Konsens und zur Sicherheit des Netzwerks beiträgt. Das Entfernen des Koordinators wird IOTA zu einem der sichersten und skalierbarsten verteilten Ledger machen.

IOTA Identity: Beta Release

May 10, 2021

IOTA Identity ist ein Self Sovereign Identity (SSI) Framework, das es Menschen, Organisationen oder Maschinen ermöglicht, eine digitale Identität zu erstellen und vollständig zu kontrollieren. IOTA Identity ermöglicht es IoT-Geräten, ihre eigenen Identitäten zu erstellen und überprüfbare Aussagen über sich selbst zu sammeln. Das erste wichtige Feature, das mit dieser Beta-Version eingeführt wurde, ermöglicht eine übergeordnete API zur Verwendung der IOTA-Identität.

Das neue Chrysalis Netzwerk ist live!

Apr 28, 2021

Das Chrysalis Netzwerk-Upgrade ist offiziell live. Token im Wert von mehr als 1,4 Milliarden USD wurden für die Migration vor dem Netzwerkstart migriert. Der nächste wichtige Meilenstein zu einem vollständig dezentralen IOTA 2.0 steht vor der Tür: Das Nectar-Netzwerk, welches in nur wenigen Wochen startet.

Digital Green Certificates: Eine dezentrale and interoperable Infrastruktur

Apr 19, 2021

Die Kommission der Europäischen Union (EU) hat einige Anforderungen festgelegt, um diesen Markt voranzutreiben. Ziel ist es, den sicheren und freien Verkehr von Bürgern innerhalb der EU während der COVID-19-Pandemie zu erleichtern. Mit ihrer Bereitstellung ermöglicht das Digital Green Certificate den Reisenden, einen gültigen Berechtigungsnachweis vorzuweisen.

Firefly Beta Release

Mar 22, 2021

Firefly Beta steht zum Download auf Mac, Windows und Linux zur Verfügung. Eine produktionsfähige Version von Firefly wird für die Chrysalis Migration veröffentlicht werden. Chrysalis ist das größte Netzwerk-Upgrade in der Geschichte der IOTA Foundation. Die Migration wird am 21. April 2021 beginnen und das Netzwerk wird am 28. April 2021 live gehen.

IOTA Stronghold: Beta Release

Mar 19, 2021

Stronghold ist eine Open-Source-Software-Bibliothek, die ursprünglich zum Schutz von IOTA Seeds gebaut wurde, aber verwendet werden kann, um jedes digitale Geheimnis zu schützen. Es ist eine sichere Datenbank für die Arbeit mit Kryptographie, die sicherstellt, dass Geheimnisse (wie private Schlüssel) nie enthüllt werden. Es bietet eine eigene Peer-to-Peer-Kommunikationsebene, sodass verschiedene Apps sicher kommunizieren können.

IOTA Smart Contracts Protocol Alpha Release

Mar 4, 2021

Die Veröffentlichung des IOTA Smart Contracts Protocol (ISCP) Alpha markiert einen wichtigen Meilenstein. Der am meisten erwartete Aspekt der Alpha-Version ist, dass Entwickler jetzt IOTA-basierte Smart Contracts und dApps erstellen können sowie Smart Contract Chains mit Wasp Nodes bereitstellen können.

Die neuen IOTA Client Libraries: Harder, Better, Faster, Stronger

Mar 3, 2021

Das Chrysalis Upgrade bringt auch eine neue Version der IOTA-Client-Bibliotheken. Die Bibliotheken sind in Node.js, Python, C, Go und Java verfügbar. Die neuen Bibliotheken basieren auf der Programmiersprache Rust. Sie sind einfach zu bedienen und verfügen über alle Funktionen, die man für Applikationen benötigt.

Gemeinsam demonstrieren IOTA und Dell Technologies das Projekt Alvarium

Feb 11, 2021

Projekt Alvarium schafft die erste Data Confidence Fabric, die in der Lage ist, vertrauliche Daten zu messen. Das System protokolliert verschiedene Schritte jedes Datenpunktes, der von einem Edge- oder IoT-Gerätesensor zu einem Router, zu einem Edge-Server oder zur Cloud gesendet wird. Jede Interaktion erhält eine Vertrauensbewertung, eine Punktzahl, entsprechend branchenspezifischen Anforderungen.

IOTA - A new dawn

Feb 5, 2021

Chrysalis ist das umfangreichste Upgrade in der IOTA-Geschichte und berührt alle Aspekte des Protokolls, Bibliotheken, Wallets und anderer Software. Chrysalis zeichnet eine neue Ära - IOTA wird produktionsbereit und es bildet die Grundlage für kommende Funktionen wie Smart Contracts und Tokenization.

IOTA Stronghold Alpha Release

Dec 24, 2020

Stronghold ist eine Open-Source-Software-Bibliothek, die ursprünglich zum Schutz von IOTA Seeds gebaut wurde, aber auch verwendet werden kann, um jedes digitale Geheimnis zu schützen. Es ist eine sichere Datenbank für die Arbeit mit Kryptografie, die sicherstellt, dass Geheimnisse (wie private Schlüssel) nie enthüllt werden können. Es bietet eine eigene Peer-to-Peer-Kommunikationsschicht, sodass verschiedene Instanzen sicher kommunizieren können.

Das Chrysalis (IOTA 1.5) Public Testnet ist Live

Dec 14, 2020

IOTA 1.5 (auch bekannt als Chrysalis) ist die Zwischenstufe von IOTA, bevor Coordicide abgeschlossen ist. Chrysalis Phase 1 Komponenten wurden im August in Mainnet eingesetzt. Heute markiert das Engineering-Team einen bedeutenden Meilenstein mit der Freigabe des Chrysalis Testnets.

Firefly — IOTA’s Next Generation Wallet

Nov 30, 2020

IOTA 1.5 kommt bald. Damit kommt eine Reihe von Verbesserungen, die IOTA aus einem explorativen Forschungsprojekt in ein ausgereiftes, unternehmensreifes Protokoll verwandeln. Experimentelle Features wie die trinäre Codierung und Winternitz One-Time Signaturen (W-OTS) wurden entfernt und durch bewährte Standards ersetzt.

Vorschau

Mehr als die Vergangenheit interessiert mich die Zukunft, denn in ihr gedenke ich zu leben. - Albert Einstein

Wir werfen einen Blick auf die offizielle Roadmap der IOTA Foundation und geben eine kleine Vorschau auf das nächste einfachIOTA Magazin.

Roadmap

Nachfolgend finden Sie eine Deutsche Übersetzung der Roadmap für das IOTA-Protokoll. Die aktuelle Stand der Roadmap kann jederzeit unter der nachfolgenden URL eingesehen werden:

https://roadmap.iota.org/

Protokoll

Wichtige bevorstehende Upgrades des IOTA-(Kern-)Protokolls.

Coordicide

Vollständige Dezentralisierung des IOTA-Netzwerks durch Entfernen des Koordinators. Dies ist die Zukunft der erlaubnislosen und skalierbaren verteilten Hauptbuchtechnologie.

Aktuelles Ziel

• Devnet Verbesserungen Einführen von diversen Verbesserungen in die IOTA 2.0 Devnet Umgebung. Inkl. Funktionen wie Congestion Control (Staukontrolle), Konsens- und Zeitstempelabstimmungen.

Nächste Ziele

• Insentiviertes Test-Netz Das Testnetz wird mit einem Insentiv-Modell ausgestattet wodurch Sicherheitsforscher Belohnungen für das finden von Bugs und Sicherheitslücken bekommen. Dies führt zu schnelleren Entwicklung, Fehlerbehebung und Wachstum des IOTA Ökosystems.

• Verbesserte Staukontrolle (Congestion Control) Neupositionierung der Scheduler (Planer) Komponente an das Ende des Datenstroms.

• Verbesserter "Rate Setter" Programmerweiterung, sodass die Zeit für eine zur Bearbeitung vorgesehenen Transaktion geschätzt werden kann und das Nutzungerlebnis auch durch verbesserungen in den zugehörigen Tools merklich steigt.

• Vereinfachung des Konsensus Ersetzen des bisher genutzen FCoB-Verfahrens (Fast-Consensus-of-Barcelona-Regel) mittels On-Tangle-Voting und zusätzlicher Nutzung von FPC als Metastabilitätsbrecher.

• Zeitstempel-Voting Aktivierung der Zeitstempel-Qualitäts-Erzwingung.

• Reorganisation Dies erlaubt den Nodes (Knoten) sich von einer fehlerhaften Zustand wieder "Erholen" und wieder ordnungsgemäß am Tangle partizipieren durch Anpassung auf Bassis der vorherschenden Zustimmungsgewichtung.

• Inklusions-Wertung Kombiniert die Zeitstempel Qualität sowie das defizit auf den Nodes (Knoten), um die geplanten Transaktionen zu optimieren.

• lokale Schnappschüsse (Snapshots) Erlaubt einer Node (Knoten) Ihre alten Daten lokal zu bereinigen, während die für den Ledger-State erforderlichen Informationen beibehalten werden.

Zuletzt erreichte Ziele

• Pollen Das erste offizielle Testnetz des IOTA 2.0-Netzwerks. Das Pollennetzwerk ist in erster Linie ein Forschungsprüfstand zur Validierung von Konzepten für IOTA 2.0.

• IOTA 2.0 Devnet Ein nahezu funktionsreiches Netzwerk zum Testen und Benchmarking von IOTA 2.0, das Mana und Fast-Probabilistic Consensus präsentiert.

Smart Contracts

Ein Layer-2-Protokoll für dezentrale, automatisch ausgeführte Programme, mit denen digitale Assets und Token verschoben werden können.

Aktuelles Ziel

• Beta Release Programmierbare Smart-Verträge, verfügbar im Nectar-Testnetz, mit grundlegender Unterstützung für die Ethereum Virtual Machine und Solidity.

Nächste Ziele

• Erweiterte EVM- und Solidity-Unterstützung Native Asset-Unterstützung und kettenübergreifende Kommunikation.

• Mainnet Release Veröffentlichung der intelligenten Verträge im IOTA-Mainnet.

Zuletzt erreichte Ziele

• Alpha Release Alpha-Version des IOTA Smart-Vertragsprotokolls. Protokollspezifikationen, Implementierung der Wasp Node und erste Version der Entwicklertools.

Anwendungen (Apps)

Kernsoftware, die von der IOTA Foundation erstellt und gewartet wird.

Firefly

Aktuelles Ziel

• Mobile Alpha Release Eine Alpha-Version für die Firefly Mobile App.

Nächste Ziele

• Mobile Beta-Version Eine Beta-Version für die Firefly Mobile App.

• Mobile Produktionsfreigabe Eine Produktionsversion von Firefly Mobile im Mainnet.

Zuletzt erreichte Ziele

• Ledger Nano Integration Unterstützung für Ledger Nano S und X über USB.

• Mobile Design Das Design von UX und UI der ersten Version von Firefly Mobile.

• Desktop Production Release Eine Produktionsversion der Firefly-Brieftasche im Mainnet.

• Erste Desktop-Benutzeroberfläche Eine saubere und moderne Benutzeroberfläche ist der Schlüssel zu einer guten Benutzererfahrung.

• Desktop Beta Release Die Beta-Version ist die letzte Phase vor der Produktionsbereitschaft. Die App ist öffentlich verfügbar und kann nach einem Sicherheitsaudit in der Produktion freigegeben werden.

• Desktop Alpha Release Die Freigabe der neuen Brieftasche an eine geschlossene Alpha-Testgruppe ist ein wichtiger Schritt in Richtung eines produktionsbereiten Produkts.

• Desktop Audit Ein externes Audit zur Überprüfung der Sicherheit der Brieftasche.

• Stronghold Integration Eine sichere Handhabung und Lagerung des Seeds ist unerlässlich. Stronghold ist eine auf Rust basierende Bibliothek, die alle Maßnahmen zum Schutz des Seeds ergreift.

• Wallet Spezifikation Das Erstellen einer Open-Source-, zusammensetzbaren und erweiterbaren Anwendung erfordert eine detaillierte und sorgfältige Planung.

• Desktop Design Das Design von UX und UI der ersten Version von Firefly Desktop.

Bee

Aktuelles Ziel

• Lokale Snapshots Eine Implementierung lokaler Snapshots, mit der der Benutzer die Größe der Node-Datenbank steuern kann.

Nächste Ziele

• Lokale Snapshots Eine Implementierung lokaler Snapshots, mit der der Benutzer die Größe der Node-Datenbank steuern kann.

• MQTT-Unterstützung Unterstützung für das MQTT-Pubsub-Messaging-Protokoll hinzufügen.

• Erneuerung des Plugin-Systems Ein neueres und flexibleres Plugin-System wird entwickelt, damit unter anderem Drittparteien mit eigenen Plugins die Funktionalitäten von Bee einfach und effizient erweitern können.

• Erneuerung der Node Architektur Basierend auf dem ASB (Actor System Backstage) Prinzip in Zusammenarbeit mit dem Chronicle Team.

• Initial-Implementierung der Coordicide Netzwerkschicht Implementierung der aktuellen Version von GoShimmer ohne die libp2p Voraussetzungen um innerhalb des IOTA 2.0 Devnet betrieben zu werden.

• Initial-Implementierung des "Coordicide Data-Flow Modells Implementierung des Data-Flow Models wie in den Forschungsspezifikationen dokumentiert: https://github.com/iotaledger/IOTA-2.0-Research-Specifications/blob/main/2.4%20Data%20Flow.md

Zuletzt erreichte Ziele

• Beta-Version Eine Beta-Version von Bee.

• Alpha Release Alpha-Veröffentlichung von Bee.

• Dashboard-Integration Unterstützung für die neue Benutzeroberfläche des Node-Dashboards hinzufügen.

• API Dies ist die Schnittstelle zwischen Clients und Datenbanken - eine API, mit der Informationen und Daten aus der Ferne abgefragt werden können. Modular aufgebaut, ermöglicht es die einfache Implementierung neuer Architekturen (REST, gRPC, …).

• Messages Implementiert das neue atomare Nachrichtenlayout von Chrysalis Part 2.

• UTXO-Ledger Ermöglicht eine schnellere und genauere Konfliktbehandlung und behandelt mögliche Szenarien für das erneute Anhängen ungültiger Transaktionen. Es wird dem Protokoll ermöglichen, in Zukunft farbige Münzen (sog. Colored Coins) zu unterstützen.

• Proof of Work Ermöglicht dem Node das Durchführen von Proof of Work.

• Tangle Implementiert die API für die typsichere Interaktion mit dem Tangle und dessen Bearbeitung.

• Speicherebene Die Speicherschicht des Bee-Nodes. Dies ist die Schnittstelle zwischen dem Tangle und den Datenbanken. Modular aufgebaut, ermöglicht es die einfache Implementierung neuer Backends (SQL, KV,…).

• Netzwerkschicht Bietet eine einfache und bequeme Möglichkeit zum Austausch von Nachrichten zwischen benachbarten Nodes.

• Gossip Protokoll Ermöglicht es dem Node, Transaktionen über das Netzwerk zu verbreiten.

• White Flag Ein einfacherer, konfliktunabhängiger Ansatz, der eine schnellere und effizientere Auswahl von Spitzen ermöglicht, bestimmte Angriffe eliminiert und den Bedarf an erneuten Anhängen erheblich reduziert.

• Binär codiertes Ternäres (Vereinheitlichung) Schnittstelle zur Vereinheitlichung von binär-ternären Codierungen.

• Signaturschema Implementiert dieselben Signaturschemata, die die Authentizität im aktuellen IOTA-Netzwerk gewährleisten, wie IRI v1.8.1.

• Kryptografische Grundelemente Implementiert die kryptografischen Hash-Funktionen CurlP und Kerl. CurlP81 (ein neuer Typ für CurlP mit 81 Runden) und Kerl sind die beiden von IRI v1.8.1 verwendeten kryptografischen Hash-Funktionen.

Abgebrochene Ziele

Findet und aktualisiert Peers im Netzwerk automatisch.

Chronicle

Chronicle ist eine auf Rust basierende Permanode, die die gesamte Geschichte des Tangle speichert.

Aktuelles Ziel

• Selektiver Permanode für das Chrysalis Netzwerk Ein selektiver Permanode speichert und filtert einen benutzerdefinierten Satz von Transaktionen. Dieser Version wird für Chrysalis (aka IOTA 1.5) entwickelt.

Nächste Ziele

• Permanode-Dashboard Ein Dashboard, mit dem Benutzer ihre permanente Instanz überwachen und steuern können.

• Selektiver Permanode für das Honey Netzwerk Ein selektiver Permanode speichert und filtert einen benutzerdefinierten Satz von Transaktionen. Dieser Version wird für Chrysalis (aka IOTA 2.0) entwickelt.

• Bestätigungszeitanalyse Berechnet und Speicher unter anderem die durchschnittle Bestätigungszeit

Zuletzt erreichte Ziele

• Chronikarchiv Eine Protokollfunktion, um den bestätigten Verwicklungsdatenfluss nach Meilensteinindex zu sichern.

• Chrysalis-Unterstützung Unterstützung für neue Datenmodelle und Chrysalis Part 2-Typen.

• Transaktionsverfestigung Unterstützung für die Festigung von Transaktionen in Chronicle.

• Chronik-Broker MQTT-Unterstützung mit einem verteilten und parallelen Kollektor zum Empfangen von Ereignissen von IOTA-Nodes und einem erweiterten angepassten Cache.

• Unterstützung für ausgegebene Adressen Funktionalität zum Speichern und Nachschlagen verbrauchter Adressen zur Verwendung beim Chrysalis-Übergang.

• API-Verbesserungen Unterstützung von weiteren Einschränkungen für die API, um die Effizienz des Datenzugriffs zu verbessern und ein API-Referenzhandbuch hinzuzufügen.

• Alpha Release Alpha-Version der Chronicle Permanode.

• Permanode-Runtime Eine erste Implementierung der Laufzeit von Chronicle basierend auf der Tokio Rust-Crate.

Abgebrochene Ziele

• Weitere Verbesserungen der Permanode-Runtime Das Hinzufügen von weiteren Tests und Profilen für die Robustheit der Runtime.

Werkzeuge und Bibliotheken

Entwicklertools und Bibliotheken zum Erstellen von Anwendungsfällen auf IOTA.

Client-Bibliothek

Die Client-Bibliothek abstrahiert die Komplexität des IOTA-Protokolls in einfache, einheitliche Methoden.

Aktuelles Ziel

• WASM-Bindungen Implementierung von WASM (WebAssembly) Support. Hiermit wird es möglich IOTA.rs innerhalb moderner Browser zu nutzen.

Nächste Ziele

• Erweiterte Testabdeckung Generelle Verbesserungen zum testen der Core Rust Library.

• C MCU Kompatibilität Ermöglicht, dass die C-Library Kompatibel mit unterschiedlichen MCU Plattformen wird.

• C Produktionsrelease Veröffentlichung der stabilen Verison 1.0.0 der C-Library inkl. sauberer Dokumentation und Beispielen zur Verwendung.

• Java Bindungen - Verbesserungen Ermöglicht, dass alle Bindungen innerhalb der JAR Datei verfügbar sind ohne dass seperate Links etc. nötig sind.

• Java Bindings Android Tutorials Enthält Beispiele und Anleitungen für die Verwendung in Android.

• Node.js Bindungen - Neon Update Update auf die aktuellste Neon Version inkl. der neuesten Node-APIs.

• Asynchrone Node.js Bindungen Alle API Methoden werden die asynchone Ausführung unterstützen (Es wird mit größeren Änderungen der APIs zu rechnen sein).

• Node.js Bindungen - Neon Update Update auf die aktuellste Neon Version inkl. der neuesten Node-APIs.

• Python Bindungen - Automatisierter Workflow ERweitert die Python Bindungs um die Möglichkeiten der Automatisierten Workflows.

• Python Bindungen - Test und Beispiele Erweiterte Tests inkl. Veröffentlichung von Beispielen für die Python Implementierung.

Zuletzt erreichte Ziele

• Spezifikation Eine Spezifikation für die IOTA-Clientbibliothek.

• Java-Bindungen Erstellung einer Bindung zu der Java-Programmiersprache, mit der die Rust-Bibliothek in Java verwendet werden kann.

• C Beta-Version Eine C-basierte Bibliothek mit intuitiven Methoden für die IOTA-Funktionalität, z. B. Senden und Empfangen von Transaktionen.

• Rust Beta Release Eine Spezifikation für die IOTA-Clientbibliothek.

• Go Beta-Version Eine Go-basierte Bibliothek mit intuitiven Methoden für die IOTA-Funktionalität, z. B. Senden und Empfangen von Transaktionen.

• Rust Alpha Release Eine Rust-basierte Bibliothek mit intuitiven Methoden für die IOTA-Funktionalität, z. B. Senden und Empfangen von Transaktionen.

• Python-Bindungen Erstellung einer Bindung, mit der die Rust-Bibliothek in Python verwendet werden kann.

• Node.js Bindungen Erstellung einer Bindung, mit der die Bibliothek iota.rs in Node.js über Neon verwendet werden kann.

Wallet-Bibliothek

Die Wallet-Bibliothek vereinfacht Implementierungen, die den IOTA-Token verwenden.

Aktuelles Ziel

• Erweiterte Testabdeckung Erweiterte Testabdeckung über die gesamte Wallet Library hinweg.

Nächste Ziele

Aktuell keine.

Zuletzt erreichte Ziele

• Ledger Nano Support Für Benutzer, die die Bibliothek mit einem Ledger Nano nutzen möchten.

• Java-Bindungen Bindungen, mit denen die Bibliothek wallet.rs in Java verwendet werden kann.

• Beta-Version Bindungen, mit denen die Bibliothek wallet.rs in Python verwendet werden kann.

• Python-Bindungen Bindungen zu der Python-Programmiersprache, mit der die Rust-Bibliothek in Python verwendet werden kann.

• Alpha Release Eine neue benutzerfreundliche Brieftaschenbibliothek zur Vereinfachung von Implementierungen, die den IOTA-Token verwenden.

• Node.js Bindungen Bindungen, mit denen die Bibliothek wallet.rs in Node.js über Neon verwendet werden kann.

IOTA Streams

Mit IOTA Streams können Geräte jeder Größe verschlüsselte Datenströme senden und darauf zugreifen.

Aktuelles Ziel

• Gegenwärtig wurden keine aktuellen Ziele definiert

Nächste Ziele

• Streams Explorer Ein benutzerdefinierter Streams-Explorer, der einen Überblick über einen bestimmten Datenstrom gibt.

• Integration von IOTA Identity Integration mit der IOTA Identity Library um IOTA Stream Eignern und Usern eine dezentrale Identität zu ermöglichen.

• Integration von IOTA Stronghold Integration der IOTA Stronghold Library um die Sicherheit und das Nutzungserlebnis des Schlüsselmanagements zu verbessern.

• Aktualisierte Spezifikationen für Chrysalis Update der aktuellen IOTA STreams Spezifikation bezüglich Anpassungen der letzten Änderungen für Chrysalis.

Zuletzt erreichte Ziele

• Dokumentation und Beispiele Verbesserung der Dokumentation und Beispiele für Rust und alle Bindungen.

• Node.js Bindungen Node.js-Bindungen über Neon für die Rust-Bibliothek.

• iota.rs Support Integration der neuen iota.rs-Clientbibliothek für Chrysalis.

• Chrysalis-Unterstützung Sicherstellen, dass Streams für die Veröffentlichung von Chrysalis bereit ist.

• C Bindungen C Bindungen für die Rust-Bibliothek.

• Spezifikation Formale Spezifikation der Konstrukte, die die Funktionalität von IOTA Streams beschreiben.

• Alpha Eine Alpha-Implementierung zur Validierung der IOTA Streams-Funktionalität mit unserer Community und unseren Partnern vor Beginn der endgültigen Implementierung.

• Unterstützung der Rustbibliothek Unterstützung für IOTA Streams in der Rust-Bibliothek.

• Rustimplementierung Eine Veröffentlichung von IOTA Streams in einem Rust-Client.

• WASM-Bindungen WASM-Bindungen für die Rust-Bibliothek.

IOTA Identity

IOTA Identity implementiert die vorgeschlagenen Standards für DID und überprüfbare Anmeldeinformationen, um eine Identität für Personen, Organisationen und Dinge zu ermöglichen.

Aktuelles Ziel

• Produktionsfreigabe In dieser Version kann das Framework in der Produktion verwendet werden. Zukünftige Updates bieten Tools für Abwärtskompatibilität und Versionsübergang.

Nächste Ziele

• Kommunikationsbibliotheken Standardisierung der Kommunikation zwischen DIDs, einschließlich Authentifizierung, Anforderung und Freigabe von Überprüfungsanmeldeinformationen. Basierend auf DIDComm und Proof Präsentation vorgeschlagenen Standards.

• Stronghold Integration Integration von Stronghold in das IOTA Identity Framework, um sofort einsatzbereite Sicherheit und einen benutzerfreundlicheren, zustandsbehafteten Umgang mit Identitäten zu bieten.

• Prüfung Externe Prüfung, die eine Überprüfung der Sicherheits- und Kryptografievorgänge ermöglicht.

• C-Bindungen C-Bindungen mit vollständiger Abdeckung der Bibliothek zur Unterstützung der nativen App-Entwicklung und IoT-Geräte.

• Datenschutzfunktionen Das Framework unterstützt Selective Disclosure und Zero Knowledge Proofs, reduziert die Menge der freigegebenen Informationen auf ein Minimum und maximiert so den Datenschutz.

• Identitätsagent Der Identitätsagent bietet eine Möglichkeit, sofort Identitätsnachrichten zu erstellen und zu beantworten, die auf eigene Anwendungen zugeschnitten sind.

Zuletzt erreichte Ziele

• Beta-Version Beta-Version des von W3C in Rust vorgeschlagenen Standards für dezentrale Identifikatoren (DID). Dies umfasst die Verwaltung von DID-Dokumenten, das Veröffentlichen und Lesen von DID-Dokumenten von IOTA.

• Spezifikation Eine umfassende Spezifikation für die Identität auf IOTA.

• Rust-verifizierbare Berechtigungsnachweisbibliotheken Eine Implementierung des Standards für überprüfbare Anmeldeinformationen durch W3C in Rust. Dies umfasst die Erstellung, Verwaltung und Überprüfung von überprüfbaren Anmeldeinformationen / überprüfbaren Präsentationen.

• Alpha Release Eine Implementierung des von W3C in Rust vorgeschlagenen Standards für dezentrale Kennungen (DID). Dies umfasst die Verwaltung von DID-Dokumenten, das Veröffentlichen und Lesen von DID-Dokumenten von IOTA.

• Selv Demo Eine Demo-Anwendung, die verschiedene Funktionen von IOTA Identity zeigt und erklärt und zudem eine Grundlage für Community-Experimente bietet.

• Versuchsprotokoll Eine voll funktionsfähige Typescript-Implementierung für ein schnelles Experimentieren und Prototyping.

❌ Im nächsten Magazin

Im nächsten Magazin behandeln wir das Thema "IOTA und die Umwelt".

Wir schauen uns hierbei auch den Stromverbrauch des neuen IOTA-Netzwerkes an.

Hast du oder dein Projekt etwas mit unserem nächsten Thema zu tun? Schreibe uns doch kurz in unserem Discord oder eine E-Mail an magazin@einfachiota.de und mit etwas Glück bist du dabei!

Draft Article

Developer Bereich

Hier gibt es spannende Informationen für Entwickler und jene, die es werden wollen!

Neue Bibliotheken!

Mit den IOTA Bibliotheken kann IOTA problemlos und schnell in eigene Anwendungen integeriert werden.

Mit dem Release von Chrysalis (IOTA 1.5) wurden auch die bestehenden Bibliotheken vereinfacht und zusammengeführt. Heraus gekommen sind eine überarbeitete IOTA-Client Bibliothek und eine ganz neue Wallet Bibliothek. Beide stehen für viele verschiedene Programmiersprachen zur Verfügung.

• iota.rs: Eine universelle IOTA-Client Bibliothek für die Interaktion mit dem IOTA-Netzwerk (Tangle)

Die Client Bibliothek unterstützt Entwickler mit hilfreichen Funktionen für die Interaktion mit dem IOTA-Netzwerk (Tangle) und zur Signierung von Nachrichten. Es gibt eine Referenzimplementierung in Rust, der alle anderen Implementierungen bezüglich Namensgebung und Funktionalität folgen sollten. Durch Bindungen (Bindings) ist es möglich in jeder unterstützten Sprache exakt gleiche Funktionalität und gleiches Verhalten zu gewährleisten.

• wallet.rs: Eine zustandsbehaftete Bibliothek, die speziell für wertbasierte IOTA-Transaktionen entwickelt wurde

Die Wallet Bibliothek bringt viele Funktionen mit und bietet eine sichere Basis, um die Integration einer Wallet zu vereinfachen und den Umgang mit IOTA Token zu unterstützen. Die Bibliothek kümmert sich um Synchronisation und Sicherheit und unterstützt Entwickler bei der Implementierung ihrer Wallet mit der Bereitstellung kritischer Kernkomponenten.

Welche Bibliothek ist die richtige für mich?

Ganz einfach - willst du in deiner Applikation Token verwahren und versenden, nimmst du die Wallet Bibliothek. Möchstest du Daten in den Tangle schreiben oder Informationen aus dem Tangle laden, kannst du die Client Bibliothek nutzen.

Weitere Bibliotheken im Überblick:

• iota.c: Eine Spezialbibliothek in C für eingebettete Geräte (mit Mikrocontrollern), die grundlegende Funktionen von client-lib oder wallet-lib abdeckt
• iota.js: Eine anfängliche IOTA-Clientbibliothek in Typescript, die auch in einem Webbrowser verwendet werden kann
• iota.go: eine erste IOTA-Clientbibliothek in Golang

Nodes

IOTA-Netzwerke bestehen aus miteinander verbundenen Nodes auf denen eine IOTA-Node Software ausgeführt wird. Diese Software ermöglicht Lese- und Schreibzugriffe auf dem Tangle, Validierung von Transaktionen und die Speicherung von Transaktionen in ihren lokalen Ledgern.

Wir möchten dir hier eine Übersicht über die derzeitigen IOTA-Nodes geben. Aktuell läuft das Chrysalis Netzwerk mit zwei verschiedenen Node-Implementierungen im Mainnet - der Community-getriebenen Node HORNET und der von der IOTA Foundation implementierten Node Bee.

IRI (außer Dienst)

Die erste Iota Reference Implementation (IRI) wurde in der Programmiersprache Java geschrieben. Diese war bis zum 11.12.2019 die einzige Standard Node-Software. Mit der Erscheinung von HORNET, einem verbesserten Core-Clienten, gab es neben IRI eine weitere Node-Software für den IOTA Tangle. IRI ist mittlerweile veraltet und wurde mit dem Crysalis-Update außer Dienst gestellt.

HORNET

Hornet ist eine leistungsstarke, von der Community vorangetriebene IOTA-Fullode-Software, die vollständig in der Programmiersprache Go geschrieben wurde. Ziel war es, einen neuen Core Clienten zu entwickeln, welcher mit einer deutlich gesteigerten Leistungsfähigkeit massiv zur Skalierung des Netzwerks beiträgt. HORNET verwendet die Architektur und das modulare Konzept von GoShimmer und ist auch für Low-End-Geräte wie dem Raspberry Pi geeignet. Der bekannte "Coordinator" läuft ebenfalls nur noch als Plugin auf einer HORNET-Node.

Bee

Bee ist eine produktionsreife Implementierung des Core-Clients ohne "Coordinator" in der Programmiersprache Rust. Teile aus allen vorherigen und zukünftigen Entwicklungen werden standardisiert und zu dieser einheitlichen Plattformlösung zusammengeführt. Bee dient als Referenzimplementierung für Entwickler, welche für die Implmentierung von Clients oder Anwendungen genutzt werden kann. Durch die modulare, ereignisgesteuerte Softwarearchitektur kann Bee so angepasst werden, dass alle möglichen Arten von Node-Software ausführbar sind.

GoShimmer

GoShimmer ist ein in der Programmiersprache Go geschriebener Prototyp des Shimmer-Voting-Systems. Er dient als Testumgebung für erste Alpha-Versionen und das Testnetz selbst. Mit dieser Node-Software wird bereits heute ohne "Coordinator" ein Konsens erzielt. Die GoShimmer Implementierung ist somit bereits heute vollkommen dezentral. In GoShimmer werden die verschiedenen Module von IOTA 2.0, wie beispielsweise Autopeering, Node-Identitäten, Mana usw. implementiert und getestet. Alles was hier erprobt wird, soll nach und nach mit Hornet zusammengeführt und später in Bee implementiert werden.

WASP

Wasp ist eine Node-Software für Smart Contracts. Das IOTA-Smart-Contract-Protocol (ISCP) ist ein 2nd-Layer-Protokoll, welches auf dem Kernprotokoll aufbaut und auf eigenständigen (WASP)-Goshimmer-Nodes ausgeführt wird. Wasp wird sich mit GoShimmer-Nodes verbinden, um Zugriff auf den Tangle zu erhalten.

Chronicle

Chronicle ist die offizielle Permanode Lösung der IOTA Foundation. Sie ermöglicht es, alle Transaktionen die einen Node erreichen, in einer verteilten Datenbank zu speichern, welche sicher ist und auch bei großen Datenmengen gut skaliert. Chronicle wird verwendet, um den unbegrenzten Datenfluss des Tangles zu speichern und abfragbar zu machen. Mit anderen Worten: eine Permanode ermöglicht eine unbegrenzte Speicherung der gesamten Historie des Tangles und macht diese Daten leicht zugänglich. (Da die endgültige Spezifikation von Chronicle bis zum Redaktionszeitpunkt noch nicht zur Verfügung stand, können sich Einzelheiten noch ändern.)

Glossar

Ein Glossar ist eine Liste von Wörtern mit beigefügten Bedeutungserklärungen oder Übersetzungen.

A

Alvarium: Ein Consortium zur Erforschung und Weiterentwicklung der Data Confidence Fabric (DCF)-Technologie, von der IOTA Foundation, Dell und Intel.

Atomic Transactions (Atomare Transaktionen): Ersetzt das bisherige Bundle-Konstrukt; verringert den Wartungsaufwand durch Reduzierung der Netzwerkaufwände und verbessert den Spam-Schutz.

B

Bech32-Adressformat: Spezifisches Segwit-Adressformat, welches auch als „bc1-Adresse“ bezeichnet wird

Blockchain Bottleneck: Je mehr Transaktionen ausgegeben werden, desto mehr wird die Blockrate und -größe zu einem Engpass im System. Es können nicht mehr alle eingehenden Transaktionen zeitnah erfasst werden. Versuche, die Blockraten zu beschleunigen, führen zu mehr verwaisten Blöcken (Blöcke werden zurückgelassen) und verringern die Sicherheit der Blockchain.

C

Chrysalis: Chrysalis ist das umfangreichste Upgrade in der Geschichte von IOTA. Es betrifft alle Aspekte des Protokolls, Bibliotheken, Wallets und Software-Implementierungen, die von der IOTA Foundation entwickelt wurden.

Chrysalis Netzwerk:

Confidence Score:

Coordicide: Abschaffung des zentralen Konsensmechanismus. Wortschöpfung aus den beiden englischen Begriffen "coordinator" und "homicide", d.h "Tötung".

Coordinator (Koordinator): Temporärer, zentraler Konsensmechanismus, der auf einer Hornet-Node läuft und im IOTA 1.5 Netzwerk signierte Transaktion (Meilensteine) erzeugt, um die Sicherheit des Netzwerkes zu gewährleisten.

D

DID: Digitale ID, auch als Unified Identity bezeichnet, ist die digitale Repräsentation von jemandem oder etwas, welches mittels Distributed-Ledger-Technologie verifiziert werden kann.

DLT (Distributed Ledger Technology; Technik verteilter Kassenbücher): Konsens über gemeinsam genutzte und synchronisierte digitale Daten, die über mehrere geografische Standorte oder Institutionen verteilt sind. Anders, als bei einer klassischen Datenbank, gibt es keinen zentralen Administrator.

Dust Protection: Bezeichnung des Mechanismus, der das IOTA Netzwerk vor einer sogenannten „Dust Attack“ schützt. Dabei versucht ein Angreifer über das massenhafte Versenden von Kleinstbeträgen die Speicherkapazität des Knotens (node) zu überlasten.

E

EdDSA (Edwards-curve Digital Signature Algorithm): Standardkryptografie, die das alte ternäre WOTS-Schema ersetzt. Es reduziert die Transaktionsgröße und erhöht dadurch den Durchsatz. Ermöglicht auch die Wiederverwendung von bereits genutzten Adressen. IOTA nutzt das Signaturschema Ed25519.

Enterprise-Ready/Production-Ready: Beschreibt die Fähigkeit des aktuellen Chrysalis-Netzwerkes (IOTA 1.5) bereits implementierte Anwendungen nach Durchführung des Coordicides auf das neue dezentrale Netzwerk migrieren zu können.

F

FPC (Fast Probabilistic Consensus): Abstimmungsmechanismus zur Erzielung des Konsens.

G

GDPR (General Data Protection Regulation): Datenschutz-Grundverordnung, welche festlegt, wie personenbezogene Daten von EU-Bürgern gesammelt und verarbeitet werden dürfen.

Git-Repository: freie Software zur verteilten Versionsverwaltung von Dateien bzw. Software-Projekten

H

Hash: Prüfsumm, die für die Verschlüsselung von Nachrichten mit variabler Länge angewendet werden. Hashwerte sind wie Fingerabdrücke eines sehr langen Datensatzes.

I

Impersonification (auch Impersonation): Beschreibt einen Identitätswechsel, der oft in betrügerischer Absicht verwendet wird, um sich Zugang zu einem System zu verschaffen, in dem man sich als berechtigte Instanz ausgibt.

Inter-Shard-Transaktionen: Bezeichnet Transaktionen die zwischen unterschiedlichen Teilmengen (Shards) eines DLT durchgeführt werden müssen. (siehe auch -> Sharding)

IoT (Internet of Things): Als das Internet der Dinge wird die globale Infrastruktur bezeichnet, die physische und virtuelle Objekte miteinander vernetzt.

J

K

Konsens(-mechanismus):

L

Legacy-Netzwerk: Bezeichnung für das alte IOTA-Netzwerk (IOTA 1.0)

Local Snapshot: Wird von einem IOTA-Knoten (node) durchgeführt, um die Datenbank zu bereinigen bzw. die Datenbankgröße zu reduzieren (siehe auch -> Snapshot). Dadurch ist eine schnellere Synchronisierung möglich.

M

Mana:

Man in the Middle-Angriff: Ermöglicht dem Angreifer Einsicht oder sogar Kontrolle des Datenverkehrs zwischen zwei Kommunikationspartnern.

Meilensteine: Signierte Transaktion ohne Wert, die vom Coordinator in regelmässigen Abständen gesendet werden, um das aktuelle Netzwerk zu sichern.

Mnemonik: Merkhilfe

MQTT (Message Queuing Telemetry Transport): Offenes Netzwerkprotokoll für Machine-to-Machine-Kommunikation (M2M), das die Übertragung von Telemetriedaten in Form von Nachrichten zwischen Geräten und in Netzwerken mit hoher Latenz und geringer Bandbreite ermöglicht.

N

Nakamoto-Konsens: Benannt nach dem Urheber von Bitcoin, Satoshi Nakamoto, beschreibt der Nakamoto-Konsens den Ersatz der Abstimmung/Kommunikation zwischen bekannten Agenten durch ein kryptographisches Rätsel (siehe auch -> Proof-of-Work).

Node (Knoten): IOTA-Netzwerke bestehen aus miteinander verbundenen Nodes, auf denen dieselbe Node-Software ausgeführt wird. Diese Software ermöglicht Lese- / Schreibzugriff auf das Tangle,  Validierung von Transaktionen und das Speichern von Transaktionen in ihren lokalen Ledgern.

O

Object-Management-Group: Konsortium, das sich mit der Entwicklung von Standards für die herstellerunabhängige, systemübergreifende, objektorientierte Programmierung beschäftigt.

Oracles: Digitale Agenten, die Daten aus der realen Welt an ein DLT übertragen.

P

Permanode: Dieser Node-Typ speichert die gesamte Transaktionshistorie permanent, ggf. mit Hilfe externer Speicherlösungen und ggf. auch nur die eigenen Transaktionen.

(POS) Proof-of-Stake:

(POW) Proof-of-Work: Eine zeitaufwendige (kostspielige) mathematische Berechnung, welche mit Hilfe von Rechenleistung Spamattacken verhindert. Es besteht aus einem schwierigen kryptographischen Rätsel, welches leicht zu überprüfen ist.

Q

R

Random-Walk-Tip-Selection (Zufallsweg-Tip-Auswahl): Der komplexe Random-Walk-Algorithmus hat rein zufällige Tips ausgewählt und wurde in IOTA 1.5 durch eine gleichmäßig-zufällige Tip-Auswahl ersetzt (siehe auch -> TSA).

Reattachments: Wiederanhängen einer Transaktion an den Tangle im IOTA 1.0 Netzwerk. Kann gutwillig (wenn die ursprüngliche Transaktion nicht bestätigt wurde) oder böswillig eingesetzt werden. Im letzteren Fall, beim sogenannten 'reuse' der Adresse, konnte man IOTA-Token durch Wiederholen der ersten Transaktion abbuchen, wenn von der Adresse bereits IOTA verschickt wurden.

RFC (Requests for Comments; Bitte um Kommentare): ein nummeriertes Dokument, in dem Protokolle, Konzepte, Methoden und Programme behandelt, beschrieben und definiert werden.

S

Second-Layer Anwendung:

Sharding: Als Sharing bezeichnet man eigentlich die Aufteilung einer großen Datenbank auf mehrere Datenbankinstanzen. Im DLT-Kontext wird damit ein Mechanismus zur besseren Skalierbarkeit der Knoten beschrieben, der einen höheren Durchsatz von Transaktionen ermöglicht. Dies erreicht man z.B. dadurch, dass ein Knoten jeweils nur eine Teilmenge von Transaktionen verarbeitet. Um Begriffsverwirrung zu vermeiden, wird im IOTA-Kontext auch der Begriff „Slicing“ verwendet.

Smart Contract: Ein Smart Contract (dt. Intelligenter Vertrag) ist eine programmierte Vereinbarung, die vollständig deterministisch ist und automatisch durchgesetzt wird. Dazu werden die vertraglichen Verpflichtungen zwischen Käufer und Verkäufer verkapselt in der Software verankert.

Snapshot: Im IOTA-Tangle werden durch einen Snapshot alle Transaktionen mit einem leeren Saldo sowie Metadaten gelöscht. Übrig bleibt eine Liste mit Adressen und Salden, die einen neuen Anfangspunkt (Genesis) für den Tangle darstellt.

T

Tangle: Bezeichnung für den IOTA-Ledger.

Tip: Eine noch nicht genehmigte Transaktion.

Token: Wert einer Blockchain oder DLT, bei IOTA heißt dieser "IOTA-Token". Die Anzahl ist auf maximal 2.779.530.283 MIOTA begrenzt.

TPS (Transactions per Second): Durchsatz von validierten Transaktionen in einer Sekunde.

TSA (Tip-Selection-Algorithm): Algorithmus zur Berechnung der Tip-Auswahl. Bestimmt die Art und Weise, in der noch ausstehenden Transaktionen genehmigt werden. Überprüft die randomisierte Auswahl, um Tips zu nutzen, die möglichst viele andere Messages referenzieren.

U

URTS (Uniformly-Random-Tip-Selection; gleichmäßig-zufällige Tip-Auswahl): Strategie zur Auswahl von bis zu acht Transaktionen, die durch eine neue Transaktion genehmigt werden sollen.

UTXO (Unspent Transaction Output): beschreibt den Kern des Bitcoin-Protokolls. Die Verwendung des auf IOTA angepassten UTXO-Modells ermöglicht eine Validierung von Transaktionen in einer konstanten Zeit. Es erhöht die Aussagekraft des Ledger-Zustands, um Anwendungsfälle wie „colored coins“ und „Layer1 smart contracts“ zu realisieren.

V

W

Wallet: Ab IOTA 1.5 wurde die bisherige Wallet „Trinity“ durch „Firefly“ ersetzt. Sie dient zur Speicherung der Public-Keys und ermöglicht dem Nutzer mittels Private-Key Zugriff auf seine Tokens.

Wallet-Bibliothek:

White-Flag: Ansatz zur Berechnung der Guthaben im Chrysalis-Netzwerk (IOTA 1.5), der die Geschwindigkeit und Effizienz der Tip-Auswahl verbessert, bestimmte Angriffe (z. B. Konflikt-Spam) eliminiert und die Notwendigkeit von reattachments (neu anhängen Transaktionen) deutlich reduziert. 

WOTS (Winternitz One-Time Signatur): Hash-basierten Signaturschema des Legacy-Netzwerkes, welches die ternäre 243-Trit-Hash-Funktion Kerl verwendet und damit quantenresistent ist.

X

Y

Z

Impressum

Bildernachweise:

• Photo by luis gomes from Pexels.com