Archiv IOTA Glossar - IOTA Einsteigerguide

A

Address Checksum: Die Prüfsummenvalidierung ist ein Mittel, um festzustellen, ob eine Adresse gültig ist und keine Tippfehler enthält.
Adaptive PoW (In der Entwicklung für IOTA 1.5): Mit diesem Feature kann der Koordinator einen Milestone ausgeben und gleichzeitig den zukünftigen PoW-Score festlegen. Das bedeutet, falls das Netzwerk nicht komplett ausgelastet ist, wird das PoW soweit reduziert, dass es von Kleinstgeräten ausgeführt werden kann, dementsprechend kann der Koordinator bei großer Auslastung die Schwierigkeit des PoW auch anheben und somit einen Angriff sehr teuer machen.
Autopeering: Ein Mechanismus, der es Nodes ermöglicht, ihre Nachbarn automatisch ohne manuelles Eingreifen des Node Operators auszuwählen.
API-Schnittstelle: Zum Senden von Datentransaktionen (Wert 0) und Abfragen des Tangle.
Atomic Transactions: Anstelle des alten Bundle-Konstrukt verwenden IOTA 1.5 einfachere Atomic Transactions. Dies reduziert den Netzwerk-Overhead und die Belastung bei der Signaturüberprüfung, verbessert den Spam-Schutz sowie die Ratenkontrolle und verkürzt die Länge der Merkle-Proofs (für künftiges Sharding). Darüber hinaus wird der Implementierungsaufwand reduziert und die Wartbarkeit der Core-Node Software wird erhöht.
Application Layer (IOTA 2.0): Die oberste Schicht des 3-fach-Layer Kommunikationsprotokolls, dass IOTA-Protokoll ermöglicht eine Vielzahl von externen Anwendungen, die auf dem Message Tangle laufen können. Jeder kann eine Anwendung entwerfen, und die Benutzer können entscheiden, welche Anwendungen auf ihren Nodes laufen sollen. Diese Anwendungen werden alle den Kommunikations-Layer nutzen, um Daten zu übertragen und zu speichern.
Approval Switch (IOTA 2.0): Wenn eine Message als Parent ausgewählt wird, können wir aus dem starken oder schwachen Tip-Pool auswählen. Dieser Mechanismus wird Approval Switch genannt.
Approval Weight (IOTA 2.0): Eine Message bekommt Mana-Gewicht, indem die Message direkt oder indirekt genehmigt wird. Allerdings können nur starke Parents das Mana-Gewicht an die Vergangenheit weitergeben, während schwache Parents das Gewicht von ihren schwachen Children erhalten, es aber nicht weitergeben.
Approvers (IOTA 2.0): Parents werden von ihren referenzierenden Messages, den Approvers, genehmigt. Es handelt sich also um eine umgekehrte Abbildung von Parents. Wie bei der Definition der Parents kann auch ein Approver entweder stark oder schwach sein.

B

Balance: Guthaben auf den Adressen (Konto), sind immer verfügbar und können nicht gelöscht oder vergessen werden.
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.
Branch (IOTA 2.0): Eine Version des Ledgers, die vorübergehend mit anderen Versionen koexistiert, die jeweils durch kollidierende Transaktionen erzeugt wurden.
Bee (IOTA 2.0): Produktionsreife Implementierung des Core Clients ohne Koordinator in der Programmiersprache Rust. Alle vorherigen Entwicklungen und Ideen aus IRI, Ict, Hornet und Go Shimmer werden zu einer einheitlichen Plattform zusammengeführt.
Bootstrapping attack: Ein Angriff, bei dem eine Node schädliche Snapshot-Dateien herunterlädt, einschließlich ungültiger Transaktionen und Salden.
Blowball attack: Ein Subtangle, bei dem eine große Gruppe von Tip Transaktionen auf eine zentrale Transaktion verweist, was häufig ein Meilenstein ist.

C

Curl: Das ist die derzeit verwendete Haupt-Hashfunktion. Sie basiert auf der „sponge“-Konstruktion, der Keccak-Erfinder (SHA-3).
Confirmed: Bestätigte Transaktionen. > Bei IOTA 1.5 werden Transaktionen noch vom Coordinator (Milestones) bestätigt.
CTPS: Confirmed transaction per second
Cumulative Weight: Ein System zur Bewertung von Transaktionen. Jede zusätzliche Transaktion, die auf eine Transaktion verweist, erhöht deren kumulatives Gewicht. Bei der Auswahl von Tips wird ein Pfad durch Transaktionen bevorzugt, der ein höheres kumulatives Gewicht hat.
Comnet: Das Comnet ist ein reines Testnetzwerk und dem Devnet ähnlich, außer dass es von der IOTA Community unterhalten wird. Die Hornet-Nodes (keine IRI-Nodes mehr) im Comnet verwenden weiterhin einen Koordinator, der von der IOTA Community betrieben wird.
Chronicle: ist die offizielle Permanode Lösung der IOTA Foundation, sie ermöglicht, alle Transaktionen, die einen Node erreichen, in einer verteilten Datenbank zu speichern, die sicher ist und gut skaliert. Chronicle wird verwendet, um den unbegrenzten Datenfluss des Tangle zu speichern und abfragbar zu machen. Mit anderen Worten, eine Permanenz ermöglicht eine unbegrenzte Speicherung der gesamten Historie des Tangle und macht diese Daten leicht zugänglich.
Consensus: Einigung auf ein bestimmtes Datum oder einen bestimmten Wert in verteilten Multiagentensystemen, bei Vorhandensein fehlerhafter Prozesse.
Congestion control (IOTA2.0): Jedes Netz muss mit seinen eigenen begrenzten Ressourcen in Bezug auf Bandbreite und Node-Kapazitäten (CPU und Speicher) umgehen. Der Congestion control Algorithmus (dt. Überlastungskontrolle) reguliert den Zustrom von Messages im Tangle mit dem Ziel, den Durchsatz (Messages/Bytes pro Sekunde) zu maximieren und die Verzögerungen zu minimieren. Die Nodes können einen Anteil des verfügbaren Durchsatzes in Abhängigkeit von ihrem Access-Mana erhalten. Der Durchsatz wird so aufgeteilt, dass der Versuch, die Zuteilung einer Node zu erhöhen, zwangsläufig zu einer Verringerung der Zuteilung einer anderen Node mit einer gleichen oder geringeren Zuteilung führt (Max-Min-Fairness).
Coordinator (nur bis IOTA 2.0): Eine vertrauenswürdige Instanz, als Schutz vor bösartigen Transaktionen. Der noch junge Tangle ist noch kein Endprodukt, er befindet sich sozusagen noch in der Betaphase, dass Netzwerk ist derzeit auf eine Art Schutzschild angewiesen, den sogenannten Koordinator namens “Compass”, er ist open-source und läuft auf einer Hornet-Node. Der COO fungiert als zentralisierter, freiwilliger und temporärer alternativer Konsensmechanismus für den Tangle. Dazu sendet der COO in regelmäßigen Abständen ehrliche Transaktionen an die Full-Nodes. Diese Pakete enthalten eine signierte Transaktion ohne Wert, die als Meilenstein bezeichnet wird. Die Full-Nodes im Tangle betrachten eine Transaktion nur dann als bestätigt, wenn sie von einem Meilenstein genehmigt wurde. Wichtig: Der Koordinator kann ausschließlich Transaktionen bestätigen, aber die Konsensregeln umgehen kann er nicht, dass erschaffen, einfrieren oder entwenden von Token ist ihm nicht möglich. Diese feste Regel und die COO Adresse ist auf jedem Full-Node fest programmiert, der Einfluss des Koordinators auf den Tangle ist daher sehr stark eingeschränkt, da dieser zudem auch ständig von allen anderen Full-Nodes überwacht wird. > Der Coo wird mit dem IOTA2.0 upgrade abgeschaltet.
Communication Layer (IOTA 2.0): Dieser Layer speichert und kommuniziert Informationen. Dieser Layer enthält das “Distributed Ledger” oder den Tangle. Die Ratenkontrolle und Zeitstempel befinden sich ebenfalls in diesem Layer.
Core Object type (IOTA 2.0): Ein Objekttyp, der von allen Nodes geparst werden muss. Parser sind Computerprogramme, welche für die Zerlegung und Umwandlung einer Eingabe in ein für die Weiterverarbeitung geeigneteres Format zuständig sind.
Core Application (IOTA 2.0): Kern-Anwendung, die von allen Nodes ausgeführt werden muss, beispielsweise die Wertetransfer-Anwendung.
Child (dt. Kind) (IOTA 2.0): Eine Transaktion, die im Tangle direkt auf zwei andere verweist, die als parents (dt.Eltern) bezeichnet werden.

D

Daten: Der Tangle ist eine Möglichkeit die Integrität von Daten (Nachweisbarkeit von Vollständigkeit und Herkunft) vertrauensvoll nachzuweisen. Derzeit gibt es etliche kryptografische Methoden, die das auch ermöglichen, aber hier werden immer wieder Sicherheitslücken bekannt wodurch Daten manipulierbar wurden. Insbesondere beim Cloud-Computing ist das ein großes Problem, dort werden teilweise sogar Audit-Tools von Drittanbietern (gegen Gebühr) verwendet, um diese Datenintegrität zu gewährleisten. Genau hier setzt IOTA an und bietet mit seinem Protokoll eine relativ einfache Möglichkeit dem zu entgehen und das ohne Gebühren.
Daten-Transaktionen: Diese werden direkt bestätigt und sind notarisiert. 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 (Tangle) unveränderbar gespeichert.
Datenspeicher: Genau wie das Internet, speichert auch das IOTA-Protokoll keine Daten oder anders ausgedrückt, der Tangle ist kein Datenspeicher. Falls jemand die Historie der Transaktionen dezentral speichern möchte, kann er dafür selbst ein Second-Layer Lösung bauen oder dritte für diese Speicherung bezahlen. Für den Basic-Layer stehen bei IOTA Leistung, Durchsatz und Sicherheit im Vordergrund und nicht der Aufbau einer globalen Datenbank.
Distributed-Ledger-Technologie (DLT) / dt. Technik verteilter Kassenbücher od. Hauptbücher: Das ist eine Datenbankarchitektur, die es den Besitzern digitaler Güter ermöglicht, diese von Peer zu Peer zu übertragen und zu dokumentieren. Jede Übertragung in einem DLT wird als Datensatz in einem Distributed-Ledger (Datenbank) gespeichert, diese Datenbank ist in allen Nodes eines Netzwerks gespeichert.
Devnet: Das Devnet (dt. Entwickler-Netzwerk) ist ein reines Testnetzwek, es ist ähnlich wie das Mainnet, außer dass die Token kostenlos sind und es weniger Zeit und Rechenleistung benötigt, um eine Transaktion zu erstellen und zu senden.
Decay (dt. Verfall): Sowohl Mana als auch Pending Mana zerfallen proportional zu seinem Wert, wodurch verhindert wird, dass das Mana mit der Zeit unbegrenzt wächst.
Double-spending: Doppelte Ausgaben sind ein potenzieller Fehler in einem digitalen Geldsystem, bei dem derselbe einzelne digitale Token mehr als einmal ausgegeben werden kann. Im Gegensatz zu physischem Geld besteht ein digitaler Token aus einer digitalen Datei, die dupliziert oder gefälscht werden kann.
dRNG (Decentralized Random Number Generator): Dieser Zufallszahlengenerator wird beim Fast Probabilistic Consensus (FPC) benötigt, damit das Konsensus-Modell widerstandsfähiger gegen einen Angriff wird. Im Falle von konfliktträchtigen Transaktionen stimmt der FPC in mehreren Runden über die betreffenden Transaktionen ab, der Schwellwert ab wann eine Node bei dieser Abstimmung ihre Meinung ändert ist 50% +/- eine kleine zufällige Abweichung (mittels dRNG). Damit keine Patt-Situation oder ein bestimmter Ausgang bei der Abstimmung herbeigeführt werden kann, verhindert diese zusätzliche Zufallskomponente es potenziell bösartigen Nodes den Abstimmungsprozess zu beeinflussen.
Dust protection (nur IOTA 1.5): Jemand der IOTA schaden möchte, könnte automatisiert jahrelang 1i auf immer neu erstellte Adressen senden und damit den Speicherbedarf des Ledger so hochtreiben, dass eine Full-Node irgendwann nur noch auf großen Servern laufen würde. Eine Art Pfand-Lösung wird nach dem Chrysalis Update implementiert: Nur wenn die Wertübertragung kleiner als 1 Mi beträgt muss die Empfangsadresse zuvor mit einer gewisse Minimum Balance aufgeladen werden (wobei das auch ein spezieller “Dust allowance output” sein muss), ansonsten wird die Werte-Transaktion nicht akzeptiert. Das bedeutet, dass nur derjenige der Mikrotransaktionen tätigen will, „vorher“ die Zieladresse mit 1 Mi aufladen muss, diese erste 1 Mi Transaktion ist sozusagen die Initialtransaktion für die nachfolgenden Mikrotransaktionen. Dies wird wohl per Wallet automatisch geregelt werden können. Auch die Adressen mit Colored Coins müssen mit Token aufgeladen werden. Nach dem Coordicide wird es für IOTA 2.0 eine andere Lösung geben.

E

Eclipse-Attack: Ein Cyber-Angriff, der darauf abzielt, einen bestimmten Benutzer zu isolieren und nicht das gesamte Netzwerk und anzugreifen.
Entropie: Dieser Begriff stellt in der Kryptologie ein Maß für die „Unordnung“ in Texten dar. Abgekürzt wird die Entropie zumeist mit dem griechischen Großbuchstaben Η.
ETH Virtual Machine: Eine VM ist das, was den Smart-Contract Code so ausführt, dass er deterministisch abläuft. Die Sprache, in der Sie den Code ausführen, bietet Hooks für den Zugriff auf die Sandbox, auf der die VM läuft. Im Fall von IOTA ist dies die ISCP-Sandbox, die nur den Zugriff auf IOTA-Token ermöglicht, somit läuft auch der Konsens über IOTA-Token. Es ist nur die VM, mit der IOTA arbeitet, fremde Token haben nichts mit einer VM zu tun, auf welcher der SC-Code ausgeführt wird, nicht mit der ETH VM, noch mit der Cartesi VM.
Epoche (IOTA 2.0): Ein Zeitintervall, das für eine bestimmte Art von Consensus-Mana verwendet wird. Am Ende jeder Epoche wird ein Snapshot des Status der Mana-Verteilung im Netzwerk erstellt. Da dieses Tool den Zeitstempel von Messages verwendet, kann jede Node letztendlich einen Konsens über die Mana-Verteilung einer Epoche erreichen.

F

Faucet: Ein Pool an Token (Geldmittel), auf unkomplizierter Anfrage bekommt man eine beschränkte Anzahl von Token zum Testen, gerade für Entwickler eigener Apps ist das ein große Hilfe.
Firefly (ab IOTA 1.5): Das ist eine Wallet, sie soll als Plattform für das aktuelle und zukünftige IOTA-Ökosystem dienen.
Finality: Die Eigenschaft, dass es nach Abschluss einer Transaktion keine Möglichkeit gibt, diese rückgängig zu machen oder zu ändern. Dies ist der Moment, in dem die an einer Übertragung beteiligten Parteien das Geschäft als abgeschlossen betrachten können. Die Endgültigkeit kann deterministisch oder probabilistisch sein.
Full-Nodes (Hornet, Bee): Sie bilden den Kern (Infrastruktur) des IOTA-Netzwerks, um am Peer-to-Peer-Netzwerk teilnehmen zu können, muss die Full-Node immer online und mit Nachbarn (andere Full-Nodes) verbunden sein, zudem muss die Transaktions-Datenbank mit allen anderen Full-Nodes im Netzwerk synchronisiert sein. Die Rolle der Full-Nodes besteht darin, mit Clients (Wallets, DApps etc.) zu interagieren und ihre Transaktionen an das Ledger anzuhängen, Transaktionen allen anderen Full-Nodes im Netzwerk bekannt zu machen, Transaktionen zu validieren und im Ledger zu speichern.
Future Cone (IOTA 2.0): Alle Messages, die direkt oder indirekt eine Message referenzieren, werden als ihr Future Cone bezeichnet.
Fork (dt. Abspaltung): In der IT ist das ein neuer Entwicklungszweig nach der Aufspaltung eines Projektes in ein zweites Folgeprojekte; die Quelltexte oder Teile davon werden hierbei unabhängig vom ursprünglichen Mutterprojekt weiterentwickelt.

G

Genesis-Transaktion: Die Genesis Transaktion ist die erste Transaktion mit der alle IOTA Token erstellt und auf die Adressen der Käufer aufgeteilt wurden.
GoShimmer (Kein Mainnet): Prototype von Shimmer in der Programmiersprache Go. Mit dieser Node-Test-Software wird bereits ohne Koordinator ein Konsens erzielt. GoShimmer implementiert die verschiedenen Module von Coordicide, wie beispielsweise Autopeering, Node-Identitäten, Mana usw. GoShimmer dient als Testumgebung für die ersten Alpha-Version und das Testnetz, alles was hier erprobt wird, soll nach und nach mit Hornet zusammengeführt und später in Bee implementiert werden.
Generisches Datenobjekt (IOTA 2.0): Der grundlegendste Objekttyp. Alle nicht erkannten Datenobjekte werden so behandelt.

H

History: Die Liste der Transaktionen, die direkt oder indirekt durch eine bestimmte Transaktion genehmigt wurden.
Hashwerte sind Prüfsummen, die für die Verschlüsselung von Nachrichten mit variabler Länge angewendet werden. Hashwerte sind wie Fingerabdrücke eines sehr langen Datensatzes, jeder Nachricht wird ein ganz bestimmter Hashwert zugeordnet.
Hornet Node (IOTA 1.5): Eine komplett neue Implementierung des Core Clients in der Programmiersprache Go. Ziel ist es einen neuen Core Client zu haben welcher mit einer deutlich gesteigerten Leistung massiv zur Skalierung des Netzwerks beitragen soll. Hornet wird die Architektur und das modulare Konzept von GoShimmer verwenden und ist für Low-End-Geräten wie einem Raspberry Pi vorgesehen, zudem wird der Koordinator ebenfalls als Plugin über Hornet laufen.
Hooks: Eine Schnittstelle, mit der fremder Programmcode in eine bestehende Anwendung integriert werden kann, um diese zu erweitern, deren Ablauf zu verändern oder um bestimmte Ereignisse abzufangen.

I

Inclusion state: Wird verwendet, um zu bestimmen, ob eine Transaktion vom Netzwerk akzeptiert und bestätigt wurde. Insbesondere bei einer Transaktion und einer Liste von Tips: Der Inclusion state ist wahr, wenn der Tip auf diese Transaktion verweist.

L

Local Snapshots: Local Snapshots sind dringend notwendig um den Speicherbedarf der Full-Nodes auf eine gebräuchliche Größe zu beschränken, dazu werden auf den einzelnen Nodes alte bereits bestätigte Transaktionen aus der Datenbank gelöscht, übrig bleibt nur eine kleine Datei (Liste) mit den Guthaben auf den jeweiligen Adressen. Full-Nodes führen den Snapshot selbstständig und nach eigenem ermessen durch, dieses Feature ermöglicht eine schnellere Synchronisierung, geringere Systemressourcenanforderungen und kein warten mehr auf globale Snapshots, um die Datenbank zu bereinigen.
Layer: Layer bedeutet wörtlich übersetzt „Schicht“, in der DLT bezieht sich ein 2-Layer auf ein sekundäres Framework oder Protokoll, das auf einem vorhandenen Distributed Ledger aufbaut. Auf diesen Second-Layern lassen sich andere Anwendungen ausführen ohne das die Basischicht zu sehr beansprucht wird, bei IOTA sind das beispielsweise die Smart-Contracts und IOTA-Streams.
Local Modifiers: Benutzerdefinierte Bedingungen, die von Nodes bei der Tip-Auswahl berücksichtigt werden können. In IOTA haben die Nodes nicht notwendigerweise die gleiche Sicht auf das Tangle; verschiedene Arten von Informationen, die ihnen nur lokal zur Verfügung stehen, können zur Stärkung der Sicherheit verwendet werden.
Light-Node: Das sind Wallets oder Apps die anders als Full-Nodes, keine vollständige Kopie des Ledgers (Tangle) besitzen, daher können sie auch keine Transaktionen verifizieren und speichern. Eine Light-Node verwaltet nur Adressen, mit ihr können die Daten des Ledgers abgerufen werden, um beispielsweise Guthaben anzuzeigen oder eigene Transaktionen zu starten und mit dem Privat-Key zu signieren. Diese Transaktionen werden im Netzwerk verteilt und von den Full-Nodes überprüft, wenn alles in Ordnung ist, wird die Adresse des Empfängers mit dem Guthaben verknüpft und im Ledger gespeichert.

M

Mining races: In PoW-basierten DLTs wird der Wettbewerb zwischen den Minern um Mining-Belohnungen und Transaktionsgebühren als Mining-Rennen bezeichnet. In diesem Wettlauf gewinnt immer die schnellste und effizienteste Hardware.
Merkle-Tree: Ein Merkle-Tree ist eine Datenstruktur, die in Informatikanwendungen verwendet wird. Bei Kryptowährungen dienen Merkle-Trees dazu, effizienter und sicherer zu kodieren.
Mainnet: Das öffentliche nutzbare IOTA Netzwerk, in diesem werden die IOTA-Token verwendet, die an Kryptowährungsbörsen gehandelt werden.
Milestone (IOTA 1.x): Meilensteine sind Transaktionen, die vom Koordinator signiert und ausgestellt werden. Ihr Hauptziel ist es, dem Tangle zu einem gesunden Wachstum zu verhelfen und die Endgültigkeit zu garantieren. Wenn Meilensteine direkt oder indirekt eine Transaktion im Tangle genehmigen, kennzeichnen die Nodes den Status dieser Transaktion und ihre gesamte Geschichte als bestätigt.
Message (IOTA 2.0): Eine Message ist ein Kern-Datentyp, der einen Vertex in der Kommunikationsschicht-DAG widerspiegelt. Sie enthält folgende Eigenschaften: Referenzen auf andere Messages, den Public Key des Absenders, den Ausstellungszeitpunkt der Message, die Message-Sequenznummer von dem Node, der die Message ausgestellt hat, die Payload, die von höheren Layern interpretiert werden kann, die Nonce, mit der die Message die PoW-Anforderung erfüllt, eine Signatur, die alle oben genannten Felder signiert. Eine Message wird erst dann weitergegeben, wenn sie “solid” wird, d. h. wenn ihre Vorgeschichte dem Node bekannt ist. Messages müssen derzeit innerhalb eines Zeitraums von 30 Sekunden solid werden, sonst werden sie verworfen. Messages müssen außerdem eine PoW-Anforderung erfüllen, die derzeit darin besteht, eine Nonce zu finden, so dass der Hash der Felder der Nachricht (abzüglich der Signatur) eine bestimmte Anzahl führender Nullen aufweist.
Message-Overhead: Die zusätzlichen Informationen (Metadaten), die zusammen mit den eigentlichen Informationen (Daten) gesendet werden müssen. Diese können Signaturen, Abstimmungen, Herzschlagsignale und alles enthalten, was über das Netzwerk übertragen wird, aber nicht die Transaktion selbst darstellt.
Mana (IOTA 2.0): Das IOTA 2.0 Konsensmodell ist ein Modell, bei dem Konflikte zwischen Transaktionen (d.h.: zwei Transaktionen, die die gleichen Mittel ausgeben) durch die Stimmen der Nodes gelöst werden. Im Netzwerk gibt es mit Mana eine knappe Ressource, sie steht im Mittelpunkt des Konsensmodells und bildet einen Reputationsmechanismus für Nodes, der sich auf mehrere Aspekte der Protokolllogik auswirkt. Mana ist am besten als ein Werkzeug zu betrachten, welches für verschiedene Aufgaben im Netzwerk eingesetzt wird. Das Thema ist sehr Komplex, bitte dem Link folgen, um mehr zu erfahren.
Markers (IOTA 2.0): Ein Werkzeug, das nur lokal existiert und es ermöglicht, bestimmte Berechnungen effizienter durchzuführen. Wie z. B. die Berechnung des approval weight oder das Vorhandensein bestimmter Messages in dem past oder future cone einer anderen Message.

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 (Proof-of-Work). Durch die Vervollständigung des Puzzles wird bestimmt, welcher Agent als nächster handelt.
Neighbors: Netzwerk-Nodes, die direkt miteinander verbunden sind und Nachrichten ohne Zwischen-Nodes austauschen können.
Node: Als Node (dt. Netzwerk-Knoten) bezeichnet man jeden Computer, der sich via Software mit weiteren Teilnehmern (Nodes) des Netzwerkes verbindet, sie dienen prinzipiell als Verbindungspunkt für Datenübertragungen. Das Tangle arbeitet mit verschiedenen Typen von Nodes, wie beispielsweise Full-Nodes (Hornet, Bee), Light-Nodes (Wallets), Perma-Nodes (Chronicle) oder Smart-Contract-Nodes (Wasp).
Network Layer (IOTA 2.0): Dieser Layer verwaltet die unteren Layer der Internetkommunikation wie TCP. In diesem Layer werden die Verbindungen zwischen den Nodes durch die Module Autopeering und Peer Discovery sowie das Gossip-Protokoll verwaltet.
Network-ID: Die Network-ID ermöglicht anwenderspezifische Subtangle, in den Nodes nur Nachrichten aus der in ihrer Konfigurationsdatei aufgeführten Network-ID erkennen können, siehe dazu auch ZebraNet.

O

Orphan / dt. Weise: Eine Transaktion (oder ein Block), die von keiner nachfolgenden Transaktion (oder Block) referenziert wird. Eine Waise gilt nicht als bestätigt und wird nicht Teil des Konsenses sein.
Objekt (IOTA 2.0): Die grundlegendste Informationseinheit des IOTA-Protokolls. Jedes Objekt hat einen Typ und eine Größe und enthält Daten.
Oracles: Oracles wurden entwickelt, um eine sichere Brücke zwischen der digitalen und der physischen Welt auf eine dezentrale, erlaubnisfreie Weise zu bauen, sie bringen im IOTA-Netzwerk Off-Chain-Daten zu dezentralen Anwendungen und Smart Contracts.
OTV (IOTA 2.0): On Tangle Voting ist die interne Bezeichnung für das von Hans Moog beschriebene Multiverse. Das On Tangle Voting nutzt die zugrunde liegende Datenstruktur selbst als Abstimmungsmechanismus. Jede Message, die von einem Node ausgegeben wird, enthält bereits die Meinung dieser Node, da sie bestimmte Gelder ausgibt, die zu einer bestimmten Realität gehören (s.a. Parallel reality ledger state), zudem genehmigt die Node auch 2 oder mehr andere Messages im Tangle, die ebenfalls zu einer bestimmten Realität gehören. Die Meinung der ausstellenden Nodes ist also bereits bekannt, ohne sie fragen zu müssen. Dies ermöglicht es der IF, den zusätzlichen Abstimmungsmechanismus (FPC) loszuwerden, was den Message-Overhead für die Abstimmung auf 0 setzen würde.
OTVFPCS (IOTA 2.0): On Tangle Voting mit FPCS (Fast Probabilistic Consensus on a Set) ist ein Mechanismus zum Brechen der Metastabilität, welcher zusätzlich zu OTV (On Tangle Voting) angewendet werden kann. Generell ist in IOTA2.0 das Erreichen einer hohen Zustimmungsgewichtung das Finalitätskriterium, wenn die Zustimmungsgewichtung hoch genug ist, wird die Message/Transaktion finalisiert. Mit OTVFPC wird die initiale Meinung mit OTV erstellt, wenn nach einiger Zeit die Meinungen der Nodes immer noch gespalten sind, aus welchem Grund auch immer, wird FPC aktiviert, um diesen metastabilen Zustand zu brechen. Die Endgültigkeit von Wert-Transaktionen sollte so schneller erreicht werden.

P

Parents (dt. Eltern): Eine Message referenziert direkt zwischen 1-8 vorherigen Messages, die IOTA Parents nennt. Ein Elternteil kann entweder stark oder schwach sein (siehe Approval-Switch).
Partitionstolerant: Das bedeutet, ein Teil des Tangle kann für eine bestimmte Zeit vom Main-Tangle abgetrennt werden und ohne Internet-Verbindung weiterlaufen. Diese Teile können wieder mit dem Main-Tangle verbunden werden, wenn die Internetverbindung wieder hergestellt wurde.
Parallel reality ledger state (IOTA 2.0): Mit ihm werden Konflikte im Tangle verfolgt, zwei neue Ledger-Einträge, die kausal gültig sind, aber miteinander in Konflikt stehen (Bsp. Double Spend), werden dazu in zwei getrennte “Realitäten” gebucht, die mögliche, aber sich gegenseitig ausschließende zukünftige Ledger-Zustände darstellen. Der Konsensmechanismus (mit FPC, etc.) wird nun tätig bis die Wahrnehmung der meisten Nodes in eine Richtung kippt und einer der beiden möglichen Ledger-Zustände als wahr angenommen wird.
Past Cone (IOTA 2.0) : Alle Messages, die direkt oder indirekt von einer Message referenziert werden, werden als ihr Past Cone bezeichnet.
Parasite-Chain Attacks: Ein Angriff auf das Tangle mit doppelten Ausgaben. Hier versucht ein Angreifer, eine Transaktion rückgängig zu machen, indem er ein alternatives Tangle aufbaut, in dem die Gelder nicht ausgegeben wurden. Er versucht dann, die Mehrheit des Netzwerks dazu zu bringen, das alternative Dreieck als das legitime zu akzeptieren.
Parsen: Parser sind Computerprogramme, die für die Zerlegung und Umwandlung einer Eingabe in ein für die Weiterverarbeitung geeigneteres Format zuständig sind.
Perma-Node: Dieser Node-Typ speichert die gesamte Transaktionshistorie permanent, ggf. mit Hilfe externer Speicherlösungen und ggf. auch nur die eigenen Transaktionen (Selektiver-Perma-Node).
Pending: Eine Transaktion wurde vom Netzwerk gesehen, aber noch nicht bestätigt.
Pending Mana (IOTA 2.0): Pending Mana ist das Mana, das von den Token auf einer Adresse erzeugt wird, sobald es an eine Node verpfändet (empfangen) wird, heißt es Mana (oder Base Mana).
Peer to Peer Network: Ein dezentrales Netzwerk aus verschiedenen Netzwerk-Nodes , die miteinander verbunden sind und Daten austauschen.
Peering: Das Verfahren des Entdeckens und Verbindens mit anderen Netzwerk-Nodes.
Payload / dt. Nutzlast (IOTA 1.5): Ein Feld in einer Message, das den Typ bestimmt. Beispiele sind: Value payload (Typ TransactionType), FPC Opinion payload (Typ StatementType), dRNG payload, Salt declaration payload, Generic data payload. Das neue variable Transaktionsformat kann eine Nutzlast von bis zu 32 kB tragen. Angehängte Informationen benötigen nur so viel Platz, wie sie wirklich benötigen, daher müssen Nodes so wenig Daten verarbeiten wie möglich.
Private Tangle: Ein private Tangle ist vergleichbar mit einem Testnetz unter vollständiger Kontrolle des Betreibers. Damit können Unternehmen und Entwickler ohne äußerliche Einflüsse und vor neugierigen Blicken geschützt ihre Applikationen unter selbst festgelegten Umgebungsvariablen testen. Zwischen einem private Tangle und dem IOTA Tangle gibt es keine Interoperabilität, daher funktioniert auch das Senden von einem ins andere Tangle nicht. Jeder private Tangle ist ein eigenständiges Netzwerk mit eigenen Nodes, Token und Koordinator.
Proof of Work (PoW): 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.
Proof of Inclusion (IOTA 2.0): Mit PoI ist man in der Lage, Beweise dafür zu erbringen, dass eine Transaktion indirekt durch eine andere Transaktion referenziert wurde, ohne die vollständige Kette der tatsächlichen Transaktionen zwischen den beiden Transaktionen vorlegen zu müssen. Dazu wird eine Abfolge von Hashes anstelle der eigentlichen Transaktionsdaten verwendet, um den Einschluss einer Transaktion (Inclusion) in das referenzierte Subtangle zu beweisen.

Wer möchte kann also eine Message zusammen mit einem Nachweis (engl. Proof) bereitstellen, der zeigt, dass diese Message Teil des Tangles ist und jede Node kann dies validieren.

Die DAG-Struktur wird dabei nur verwendet, um die Inklusion gegen das nächstgelegene Blatt (engl. Leaf) eines Hash-Baums (engl. Merkle-Trees) zu beweisen, der von allen Nodes verfolgt wird und der das Tangle in Epochen unterteilt, alle 5 Minuten wird ein neues Blatt ausgewählt. Diese 5-Minuten-Direktreferenzen ermöglichen auch eine Beschleunigung der Synchronisierungszeiten, da sie wie “Wurmlöcher in die Vergangenheit” wirken.

Die Nodes erreichen einen Konsens über das gewählte Blatt, indem sie einen On-Tangle-Voting-Mechanismus verwenden, ähnlich der Art und Weise, wie über Konflikte abgestimmt wird. Jede Message hat 2 zusätzliche Informationsfelder: 1) Den Hash des Blattes, welches momentan als das richtige angesehen wird. 2) Die aktualisierte Wurzel des Hashs (Merkle-Root), die das Ergebnis des Hinzufügens des zuvor genannten Blattes ist

Die Nodes wählen das Blatt, indem sie dem Kandidaten folgen, der das meiste Zustimmungsgewicht erhalten hat, oder wenn kein Kandidat ein Zustimmungsgewicht erhalten hat, wir dasjenige benannt, welches zuerst entdeckt wird.

Der verfolgte Baum konvergiert zu einer gemeinsamen Wahrnehmung, da die Nodes den Baum bis in alle Ewigkeit beibehalten, kann jeder für immer beweisen, dass eine bestimmte Transaktion zu einem Blatt dieses Baums gehört.

Pruning: In der Informatik ist das ein Ausdruck für das Vereinfachen, Kürzen und Optimieren von Entscheidungsbäumen. Bei IOTA wird dies durch Local-Snapshots auf den einzelnen Full-Nodes durchgeführt, alte bereits bestätigte Transaktionen werden aus der Datenbank gelöscht, übrig bleibt nur eine Datei (Liste) mit den Guthaben auf den jeweiligen Adressen.
Public & privat keys: Sie finden Verwendung in kryptographischen Systemen, welche Schlüsselpaare verwenden, es gibt public keys (öffentliche Schlüssel) und private keys (private Schlüssel), die nur dem Besitzer bekannt sind. Die Erzeugung solcher Schlüssel hängt von kryptographischen Algorithmen ab, die auf mathematischen Problemen basieren, um Einwegfunktionen zu erzeugen. Wirksame Sicherheit erfordert nur, den privaten Schlüssel (Seed) privat zu halten; der öffentliche Schlüssel (Adresse) kann offen verbreitet werden, ohne die Sicherheit zu gefährden.

R

Rebroadcast (IOTA 1.5): Wiederholt das Senden einer Transaktion. Während eine Transaktion an einen IOTA-Node gesendet wird, kann dieser offline gehen. In diesem Fall leitet der IOTA-Node die Transaktionen möglicherweise nicht an seine Nachbarn weiter, und der Rest des Netzwerks wird diese Transaktionen niemals sehen. Infolgedessen wird diese Transaktion vom Koordinator niemals referenziert und somit auch niemals bestätigt. Ein Transaktion erneut zu senden bedeutet, dass dieselbe Transaktion erneut an einen IOTA-Node gesendet wird. Auf diese Weise bekommt die Transaktionen eine weitere Chance, an den Rest des Netzes weitergeleitet zu werden.
Reusable Adresses: Mit der Implementierung des Signaturshema Ed25519 durch das IOTA 1.5 Chrysalis Upgrade werden wiederverwendbare Adressen (engl. Reseuable Adresses) unterstützt.
Reattachment: Erneutes Senden einer Transaktion durch erneute Tip-Auswahl und Referenzieren neuerer Tips durch erneutes PoW.

S

Salt: In der Kryptographie ist Salt eine zufällig gewählte Zeichenfolge, die an einen vorgegebenen Klartext vor dessen weiterer Verarbeitung angehängt wird, um die Entropie (Unordnung) der Eingabe zu erhöhen. Es wird oft für die Speicherung und Übermittlung von Passwörtern benutzt, um die Informationssicherheit zu erhöhen.
Sandbox: Ein isolierter Bereich, in ihm lassen sich Programme ausprobieren.
Software as a Service (SaaS): Das SaaS-Modell ist ein Teilbereich des Cloud Computing, es basiert auf dem Grundsatz, dass die Software und die IT-Infrastruktur bei einem externen Dienstleister betrieben und vom Kunden als Dienstleistung gemietet werden kann.
Smart Contract Chain: Smart Contracts werden über eine sogenannte Contract Chain, die Repräsentation des Contract-Zustands, abgewickelt. Ein Smart Contract schreibt seinen Status bei jeder Anfrage und bei jeder dieser Aktualisierungen des Zustands wird ein neuer Block hinzugefügt, all diese Aktualisierungen werden in einem Block gesammelt und bestätigt. Die Chain enthält also auch alle vergangenen Zustände. Die Chain kann viele Smart Contracts enthalten, die alle am gleichen globalen Zustand der Chain arbeiten. Aus dieser Perspektive betrachtet, ist die Contract Chain im Wesentlichen eine Blockchain, die auf dem Tangle verankert ist. IOTA Smart Contracts können als „klassische“ Smart Contracts betrachtet werden, aber mit dem zusätzlichen Merkmal, dass Sie mehrere solcher parallelen Chains haben können, die alle dasselbe native IOTA-Token nutzen und zwischen denen Sie auf vertrauenswürdige Weise auf dem Tangle handeln können. Dadurch wird eine vertrauenswürdige Interoperabilität zwischen verschiedenen Anwendungen ermöglicht.
Small-World-Network: Ein Netzwerk, in dem die meisten Nodes von jedem anderen Nodes aus durch eine geringe Anzahl von Zwischenschritten erreicht werden können.
Solidification time: Der Zeitpunkt der Verfestigung, an dem die gesamte Historie einer Transaktion von einem Node empfangen wurde.
Splitting Attacks: Ein Angriff, bei dem ein bösartiger Node versucht, das Tangle in zwei Zweige aufzuspalten. Wenn einer der Zweige wächst, veröffentlicht der Angreifer Transaktionen auf dem anderen Zweig, um beide am Leben zu erhalten. Splitting-Angriffe versuchen, den Konsensprozess zu verlangsamen oder eine doppelte Ausgabe (double spent) durchzuführen.
Sharding: IOTA-Nodes haben eine Obergrenze für Transaktionen pro Sekunde (TPS), die sie verarbeiten können, durch eine Form der Datenbankpartitionierung (das Aufteilen einer sehr großen Datenbank in kleinere) in besser verwaltbare Segmente (Shards) würde jeder Shard einen einzigartigen Satz der Kontensalden enthalten und Nodes würden dann einzelnen Shards zugewiesen, um Transaktionen zu validieren. Ziel ist es, dass durch die Aufteilung in besser verwaltbare Segmente der Transaktionsdurchsatz erhöht und damit die Skalierbarkeitsprobleme überwunden werden.
Signaturen, belegen den Besitz des Guthabens, Clients (wallet) benötigen diesen Nachweis, bevor Nodes eine Transaktion validieren. Zum Nachweis des Eigentums müssen Eingabetransaktionen mit dem private key signiert werden.
Subtangle: Ein konsistenter Abschnitt des Tangle (d.h. eine Teilmenge von Nachrichten/Wertobjekten), so dass jede enthaltene Nachricht bzw. jedes enthaltene Wertobjekt auch seine referenzierten Nachrichten/Wertobjekte enthält.
Streams: Bei IOTA Streams handelt es sich um ein multifunktionales Second Layer Datenübertragungsprotokoll, welches für verschiedene Arten der Datenübertragung (z.B. Streaming-Daten) verwendet werden kann. Beispielsweise ermöglicht es Sensoren und anderen Geräten, 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. Angesichts dieser Eigenschaften erfüllt IOTA Streams ein wichtiges Bedürfnis in Branchen, in denen Integrität, Datenschutz und Unveränderlichkeit aufeinandertreffen.
Sybil-Attack: Ein Versuch, die Kontrolle über ein Peer-to-Peer-Netzwerk zu erlangen, indem mehrere falsche Identitäten gefälscht werden.
Snapshot: Eine Besonderheit des Tangle, ein Snapshotlöscht alle Transaktionen, nur Transaktionen mit einem Saldo > 0 werden beibehalten, die Metadaten wie Tags und Nachrichten werden ebenfalls gelöscht. Was zurück bleibt ist nur eine Liste mit Adressen und Salden. Nach einem Snapshot verwenden die Nodes diese Liste als „Genesis“, ein neuer Anfangspunkt für den Tangle. Dadurch wird die Größe des Tangle-Netzwerks reduziert, wodurch die IOTA-Nodes weniger Speicher benötigen. Full-Nodes führen selbstständig und nach eigenem ermessen die sogenannten “Local Snapshots” durch, dies bedeutet eine schnellere Synchronisierung, geringere Systemressourcenanforderungen und kein warten mehr auf globale Snapshots, um die Datenbank zu bereinigen. Local Snapshots sind dringend notwendig um den Speicherbedarf der Full-Nodes auf eine gebräuchliche Größe zu beschränken. Standardmäßig speichern die Nodes ungefähr 30 Tage Transaktionsdaten, das kann individuell geändert werden. Der Full-Node Betreiber muss jedoch darauf achten, dass er nicht zu häufig lokal Snapshot macht, wenn er zu schnell Snapshots macht, riskiert er einem Sub-Tangle aufzubauen, dass aus dem Konsens herausfallen kann. Dies wäre wie ein Miner in der Blockchain, der nur Informationen speichert, die im letzten Block in der Blockchain enthalten sind – es ist möglich, dass dieser Block letztendlich nicht Teil der längsten Kette wird und dieser Miner auf einer verlassenen Kette aufbaut.
Solidity (IOTA 2.0): Eine Message wird als solide gekennzeichnet, wenn ihr gesamter Past Cone bis zur Genesis (oder dem letzten Snapshot) bekannt ist

T

Tangle: Der Tangle ist die zugrundeliegende Kerndatenstruktur, mathematisch ausgedrückt ist es ein gerichteter azyklischer Graph (DAG). Der Tangle ist das Distributed Ledger von IOTA, welches alle Transaktionen speichert.
Tag: Eine kurze Nachricht, welche an einem Transfer angehängt werden kann, nach ihnen kann im Tangle gesucht werden.
TPS: Transaction per second, ab IOTA 1.5 heißt es Message per second (MPS)
Ternäres System: Ein Trit (trinary digit) kann genau drei Zustände (3 x 1 = 3) annehmen: -1, 0 und 1.
Drei Trits ergeben ein Tryte (33 = 27) und können somit 27 Kombinationen abbilden, bei IOTA werden dafür die Buchstaben A-Z (26 Stück) und die Zahl 9 verwendet.
Token (IOTA): Die verwendete digitale Währungsform (Kryptowährung) und ist ein leistungsfähiges Werkzeug für den Wertetransfer zwischen Menschen und Maschinen. Gesamtzahl: 2 779 530 283 277 761 iota, die Basiseinheiten sind Pi, Ti, Gi, Mi, Ki, i
Trinity (IOTA1.0): Eine alte Wallet, nach dem Update zu IOTA 1.5 hat diese Wallet keine Funktion mehr.
Troika: Eine Ternäre Hash-Funktion (nicht im Einsatz, Ternäre Vision)
Tip: Eine Transaktion, die noch nicht genehmigt wurde.
Tip Selection: Der Prozess der Auswahl früherer Transaktionen, die durch eine neue Transaktion referenziert werden sollen. Bei diesen Verweisen knüpft eine Transaktion an die bestehende Datenstruktur an. IOTA erzwingt nur, dass eine Transaktion bis zu acht andere Transaktionen genehmigt, die Strategie der Tip-Auswahl wird dem Benutzer überlassen (mit einer guten Voreinstellung, die von IOTA bereitgestellt wird).
Tip-Transaction: Eine solide Endtransaktion, die noch keine parent ist..
Transaction (IOTA 2.0): Die Payload eines Werte-Objektes. Sie enthält die Angaben zu einem Geldtransfer.
Transaktionshistorie: Dazu bitte hier weiterlesen.

U

UTXO-Modell: Das ist ein sogenanntes Adressierungsmodell, UTXO steht dabei 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 behält, woher die Guthaben stammen und wohin sie versendet werden, wenn sie ausgegeben werden. Jeder Token auf einer Adresse ist damit eindeutig identifizierbar und jede Ausgabe benennt genau den Token, die sie bewegen möchten. Dies ermöglicht eine schnellere und genauere Konfliktbehandlung und verbessert die Belastbarkeit sowie die Sicherheit des Protokolls.

V

Value Layer (IOTA 2.0): Der Value-Layer baut auf dem Communication-Layer auf, er arbeitet ausschließlich mit Payloads vom Typ Value-Objekt. Dieser Layer hat mehrere Aufgaben: Bilden des Ledger-State, Verarbeitung, Validierung und Ausgabe von Transaktionen, Konflikterkennung, Konfliktauflösung über FPC, Bilden einer DAG aus Value-Objekten, Tip-Auswahl (auf value object tips)
Versionsnummer (IOTA 2.0): Gibt das korrekte Format jedes Typs an.
Virtual machine: Die Software-technische Kapselung eines Rechnersystems innerhalb eines lauffähigen Rechnersystems.

W

Wert-Transaktionen: Werttransaktionen ziehen entweder IOTA-Token von einer Adresse ab oder sie zahlen sie auf eine Adresse ein. Nodes müssen diese Transaktionen verifizieren, um sicherzustellen, dass der Absender tatsächlich Eigentümer der IOTA-Token ist und das niemals zusätzliche Token erzeugt werden. Dazu werden folgende Prüfungen durchgeführt: Alle IOTA-Token, die von einer Adresse abgezogen werden, werden auch in eine oder mehrere andere Adressen eingezahlt; der Wert jeder Transaktion übersteigt nicht das gesamte globale Angebot; Signaturen sind gültig.
White-Flag-Approach (nur IOTA 1.5): Zur Berechnung der Guthaben. Ein einfacherer, konfliktvermeidender Ansatz, der die Geschwindigkeit und Effizienz der Tip-Auswahl verbessert, bestimmte Angriffe eliminiert und die Notwendigkeit von reattachments deutlich reduziert.
Wasp: Ein Node für IOTA Smart Contracts

Z

Zebranet ist ein anwenderspezifisches Subtangle. In Zukunft werden Zebra Technologies und die IOTA Foundation ein spezielles IOTA DLT-Netzwerk namens Zebranet für Zebra-Kunden, einsetzen. Das Zebranet ist eine 2-Layer Skalierung in Form von logisch getrennten Subtangle mit einer eindeutigen Netzwerk-ID, innerhalb des Subtangle können die Nodes ausschließlich die Nachrichten aus der in ihrer Konfigurationsdatei aufgeführten Network-ID erkennen. Die Aktivität in diesen Sub-Tangles kann kontextspezifisch sein und muss nicht mit dem Durchsatz im Mainnet konkurrieren. Der Token-Supply bleibt jedoch global, um Werte-Transaktionen in diesen Subnetzen zu tätigen, müssen zuerst IOTA-Token in das Subtangle eingezahlt werden, welche dann aus dem Mainnet verschwinden (Token können hin und her transferiert werden). Diese Art der 2-Layer Skalierung wird zunächst für Daten eingeführt, die Unterstützung für die Werte-Übertragungen wird später hinzugefügt. Die Möglichkeit, kontextspezifische Subnetze zu erstellen (2-Layer Skalierung) bedeutet nicht, dass auf das “Fluid Sharding” (1-Layer Skalierung) verzichtet werden kann. Es ist ein komplementäres Konzept, das verwendet werden kann, wenn es für den Anwendungsfall sinnvoll ist.