Die IOTA-Identität kommt auf Layer 1

Entdecken Sie jetzt die IOTA-Identität auf Shimmer

TL;DR:
Das bevorstehende Stardust-Upgrade von IOTA ermöglicht es der IOTA-Identität, auf Layer 1 des Netzwerks zu gelangen. Die neue Implementierung stellt eine wesentliche Verbesserung gegenüber der vorherigen Datenmethode dar, da sie Identitäten die Interaktion mit NFTs, nativen Token und Smart Contracts ermöglicht und gleichzeitig die Datenverfügbarkeit, Zugänglichkeit und Synchronisationsgarantien verbessert. Nachdem das Stardust-Protokoll-Upgrade nun im Shimmer-Netzwerk live ist, warten die neue UTXO-basierte dezentrale Identifizierungsmethode und andere Funktionen darauf, getestet zu werden.

Das bevorstehende Stardust-Update für das IOTA-Netzwerk wird die Fähigkeiten des Protokolls erheblich erweitern und neue Möglichkeiten für die Gestaltung von Lösungen auf dem Ledger einführen. Diese Verbesserung hat uns dazu inspiriert, neu zu überdenken, wie IOTA Identity auf IOTA funktionieren sollte und wie wir mit den erweiterten Möglichkeiten interagieren können. Das Stardust-Upgrade für Shimmer, das Testnetzwerk von IOTA, ermöglicht es uns, diese neuen Möglichkeiten zu erkunden.

Stardust verwandelt IOTA nicht nur in eine Infrastrukturschicht für Smart-Contract-Ketten, sondern macht es auch zu einem Multi-Asset-Ledger und führt Mechanismen ein, um beliebige Daten auf allen IOTA-Knoten dauerhaft verfügbar zu machen. Für einen allgemeinen Überblick darüber, was Stardust kann, gibt dieser Blogbeitrag einen guten Überblick; aber zusammenfassend fügt Stardust der Schicht 1 neue Ausgaben hinzu, die die Fähigkeiten des IOTA-Ledgers erheblich erweitern.

Eine dieser neuen Fähigkeiten – die permanente Datenspeicherung im Ledger – ermöglicht es uns, dezentrale Identifizierungsdokumente (DIDs) direkt im Ledger zu speichern, was eine ganze Reihe neuer Möglichkeiten eröffnet. DIDs können direkt mit jedem der anderen Ausgabetypen interagieren und können aus Smart Contracts bestehen. In diesem Blog-Beitrag werden wir einen genaueren Blick darauf werfen, was diese Fähigkeit ermöglicht.

Effizientere und leistungsfähigere DID-Methoden

Die derzeitige DID-Implementierung auf Chrysalis verwendet Datennachrichten auf dem Tangle, um DID-Dokumente zu verbreiten, die von allen Knoten indiziert, aber nach einer bestimmten Zeit wieder gelöscht werden. Das bedeutet, dass die Resolver von DIDs Zugang zu einem Knoten benötigen, der alle Datennachrichten, die durch den Tangle gehen, speichert, ein sogenannter „Permanode“. Permanodes erfordern jedoch erhebliche Ressourcen für den Betrieb, die Sicherung und möglicherweise die Wiederherstellung. Mit den neuen Funktionen von Stardust können wir eine robustere, effektivere und ressourcenschonendere Lösung anbieten. Ein DID-Dokument, das direkt im Ledger-Status gespeichert wird, weist nicht die Unzulänglichkeiten einer Permanode auf, da eine nicht verbrauchte Ausgabe von den Knoten nicht beschnitten wird und somit keine Permanode erforderlich ist. Dies verbessert die Verfügbarkeit, Zugänglichkeit und Synchronisation, die unsere aktuelle Implementierung bietet.

Wir sehen die UTXO-basierte DID-Methode als Methode für Identitäten mit hoher Sicherheit (z. B. Aussteller von verifizierbaren Berechtigungsnachweisen) und Identitäten, die von der direkten Interaktion mit anderen Artefakten der Schicht 1 (wie NFTs und nativen Token) profitieren, sowie für solche, die aus Smart Contracts zusammengesetzt werden müssen. Durch die Speicherung von Identitäten im Ledger wird sichergestellt, dass ihr aktueller Status mit allen anderen Knoten synchronisiert ist und eine DID-Auflösung von jedem Knoten aus möglich ist. Allerdings ist der Speicherplatz im Ledger eine knappe Ressource, was bedeutet, dass eine Kaution in Form von Token wie MIOTA oder SMR erforderlich ist, um die Byte-Kosten des gespeicherten Dokuments zu decken. Es handelt sich dabei um eine rückzahlbare Kaution, die proportional zur Größe des gespeicherten Dokuments ist und beim Löschen der Ausgabe vollständig zurückerstattet werden kann. Mehr darüber können Sie hier lesen.

Da eine Kaution für einige Anwendungsfälle unerwünscht sein könnte, arbeiten wir auch an einem Ersatz für unsere derzeitige DID-Methode. Wir gehen davon aus, dass dieser Ersatz keine Kaution pro Identität benötigt, obwohl ihm die Schicht-1-Integration der UTXO-Methode fehlt. Diese Methode ist für Anwendungsfälle gedacht, in denen eine große Anzahl von Identitäten öffentlich zugänglich gemacht werden muss und in denen eine Kaution pro Identität nicht praktikabel wäre – zum Beispiel, wenn billige Sensoren mit Identitäten ausgestattet werden müssen, die Kaution aber die Kosten des Sensors übersteigt.

Zusammenfassend möchten wir zwei DID-Methoden für Stardust im IOTA-Mainnet anbieten, die sich gegenseitig ergänzen, mit den folgenden Kompromissen:

1. Die UTXO-basierte DID-Methode, die die volle Layer-1-Integration freischaltet, erfordert eine Speicherkaution und ist für hochsichere Identitäten gedacht.
2. Eine DID-Methode, die die derzeitige Chrysalis-Methode ersetzt und keine Kaution pro Identität erfordert, keine direkte Layer-1-Integration aufweist und dafür gedacht ist, eine große Anzahl von Identitäten im Ökosystem auflösbar zu machen.

Die beiden DID-Methoden sollen sich in Bezug auf ihre Garantien ergänzen. Das bedeutet, dass Entwickler, die auf IOTA Identity aufbauen, die Wahl haben werden, welche Kompromisse sie akzeptieren wollen und sogar in der Lage sein werden, beide Methoden parallel zu nutzen, um das Beste aus beiden Welten zu erhalten.

In diesem Blogbeitrag wollen wir uns auf die UTXO-basierte Methode konzentrieren und beschreiben, wie sie funktioniert und wie sie genutzt werden kann. Wir werden die zweite Methode weiterverfolgen, sobald wir die notwendigen Untersuchungen abgeschlossen haben.

Technischer Überblick

Das Ziel der UTXO-Methode besteht darin, DID-Dokumente auf Layer 1 verfügbar zu machen und dabei den DID-Standard so genau wie möglich einzuhalten. Zu diesem Zweck nutzen wir eine weitere Neuerung, die mit dem Stardust-Upgrade eingeführt wurde: den Alias-Ausgang.

Die Alias-Ausgabe hat eine Status-Metadaten-Eigenschaft, die beliebige Daten bis zu einer bestimmten Größe enthalten kann. Das DID-Dokument wird in dieser Eigenschaft gespeichert. Für den methodenspezifischen Bezeichner (oder „ID“) des DID wird die Alias-ID verwendet. Die Alias-ID selbst wird aus dem Inhalt der erstellenden Transaktionen abgeleitet und ist nach der Erstellung weltweit eindeutig und unveränderlich. Aufgrund dieser Eigenschaften eignet sie sich als DID und ist gleichzeitig ein aussagekräftiger Bezeichner auf Schicht 1 für erweiterte Anwendungsfälle.

Zusammenfassend lässt sich sagen, dass die Alias-Ausgabe vier Fähigkeiten bietet, die sich besonders für das Hosting von Identitäten eignen:

1. Die Alias-ID ist ein weltweit eindeutiger Bezeichner, der nach der Erstellung nicht mehr geändert werden kann, was der unveränderlichen Natur von DIDs perfekt entspricht. Die DID enthält die Alias-ID, so dass DID und Output leicht ineinander umgewandelt werden können. Ein einfaches Beispiel: Der letzte Teil der DID (der methodenspezifische Bezeichner) did:iota:0x0a6cf67b1faff3c4c9097ce91d84b1df490917b39a64a5b6ef30476ce4c528d3 ist die Alias-ID des entsprechenden Alias Output.
2. Der Output kann beliebige Daten in seinen Zustandsmetadaten speichern, in denen das DID-Dokument gespeichert ist.
3. Nur die Zustandssteuerung darf den Zustand des Alias-Ausgangs aktualisieren, z. B. das DID-Dokument in den Zustands-Metadaten, d. h. die
4. Zustandssteuerung wird in der DID-Terminologie zur DID-Steuerung.
   Ein DID in einem Alias Output erbt alle Fähigkeiten dieses Outputs, wie z. B. die Fähigkeit, Token zu senden und zu empfangen oder native Assets zu prägen. Auf diese Anwendungsfälle wird weiter unten näher eingegangen.

Da der Alias Output in der Lage ist, mit NFTs und nativen Token zu interagieren und die Verankerung von Smart-Contract-Ketten auf Layer 1 ermöglicht, befindet er sich in der Mitte des Layer-1-Web, wo auch DIDs angesiedelt sein sollten.

Um mit der DID-Spezifikation vollständig konform zu sein, müssen wir den Alias-Ausgang erweitern, um mehrere Controller zu ermöglichen. Wir erwarten dieses Update, bevor Stardust in das IOTA Mainnet geht.

Anwendungsfälle

Im folgenden Abschnitt wollen wir die Interaktionen von UTXO-Identitäten mit den anderen Layer-1-Artefakten demonstrieren und die Anwendungsfälle beschreiben, die durch diese Interaktionen freigeschaltet werden. Für jede Interaktion haben wir Beispiele in der Bibliothek bereitgestellt, die Sie hier finden können:

• JavaScript/TypeScript: https://github.com/iotaledger/identity.rs/tree/main/bindings/wasm/examples
• Rust: https://github.com/iotaledger/identity.rs/tree/main/examples

Identitäten, die andere Identitäten kontrollieren

Da ein Alias-Output andere Alias-Outputs kontrollieren kann, kann eine Identität effektiv eine andere Identität kontrollieren. Dies ermöglicht es uns, Hierarchien von Identitäten zu erstellen und Situationen wie Tochtergesellschaften für Unternehmen oder Vormünder für Menschen zu modellieren. In diesem Zusammenhang muss die Kontrolle zwischen zwei Parteien unterschieden werden: dem Gouverneur und dem State Controller. Der staatliche Kontrolleur hat die Möglichkeit, Änderungen am DID-Dokument vorzunehmen und kann daher entscheiden, wie die Identität dargestellt werden soll. Der Governor kontrolliert, wer Aktualisierungen an einer Identität vornehmen darf, indem er einen State Controller zuweist. Betrachten wir als Beispiel den Fall eines Smartphone-Herstellers namens „Phonemkr“ und seiner beiden Tochtergesellschaften: „Phoneshop“, wo man Telefone kaufen kann, und „Phoneshippr“, die die Telefone versendet. „Phoneshop“ soll die Identität der Versandtochter verwalten, aber der Hersteller möchte die endgültige Kontrolle über beide behalten.

Dies wird erreicht, indem die Adresse des Alias-Ausgangs einer Identität als State Controller oder Governor Unlock Condition einer anderen Identität festgelegt wird. Derzeit ist für den Alias-Ausgang nur ein einziger Zustandsregler möglich, aber wir beabsichtigen, bei künftigen Aktualisierungen des Protokolls mehrere Regler zuzulassen. Im obigen Beispiel würden mehrere Controller es sowohl dem Hersteller als auch dem Geschäft ermöglichen, Aktualisierungen an der Identität vorzunehmen, was mehr Flexibilität bieten würde.

Authentifizierung von Absendern und Empfängern von Geldern

Identitäten können IOTA-Münzen, native Token empfangen, halten und sie an andere Identitäten senden. Dies kann den Absender und den Empfänger von Geldern identifizieren und so eine stärkere Sicherheit für den Empfänger bzw. Absender bieten.

Da ein Alias-Ausgang Token enthalten kann, lässt sich jede DID leicht in eine Adresse umwandeln. Angenommen, Alice hat gerade DIDs mit Bob ausgetauscht und möchte ihm Geld schicken. Während des DID-Austauschs verlangte Alice von Bob, dass er seine DID ihr gegenüber authentifiziert, um zu beweisen, dass die DID, die er ihr mitgeteilt hat, wirklich seine ist. Wenn Alice also Geld an die Adresse seines Alias-Outputs schickt, kann sie sicher sein, dass derjenige, der Bobs Identität kontrolliert, auch auf das Geld zugreifen kann. Das ist höchstwahrscheinlich Bob selbst, aber es kann auch jede andere Adresse sein, z. B. eine Alias- oder NFT-Adresse.

Umgekehrt kann jemand, der Gelder von einem Alias-Ausgang erhält, der eine DID enthält, sicher sein, dass der Inhaber der DID die Gelder gesendet hat. Auf diese Weise kann die Herkunft der Gelder authentifiziert werden, was zum Beispiel Maßnahmen zur Bekämpfung der Geldwäsche unterstützen könnte.

Da Beobachter die Bewegung von Geldmitteln sehen können, könnte es besser sein, verschiedene Identitäten für verschiedene Anwendungsfälle zu verwenden, anstatt eine einzige Identität für alle Interaktionen zu nutzen (dies gilt auch für Identitätsinteraktionen im Allgemeinen).

Technisch gesehen kann eine Identität Geldmittel kontrollieren, da die Adresse einer Alias-Ausgabe als Freigabebedingung für eine beliebige Ausgabe verwendet werden kann, wodurch die Alias-Ausgabe die Basisausgabe und deren Geldmittel kontrollieren kann. Geldmittel werden gesendet, indem ein Basisausgang erstellt wird, der von Bobs Alias-Ausgang kontrolliert wird. Der Identitäts-Alias-Output bietet hier eine dauerhafte Kennung für den Empfang von Geldern und ermöglicht gleichzeitig bewährte Sicherheitsverfahren, wie z. B. die Schlüsselrotation. Auf diese Weise können Gelder effektiv an DIDs auf Schicht 1 übertragen werden.

DIDs, die NFTs ausgeben

Mit der Einführung des Stardust-Protokoll-Upgrades können NFTs nun auf Schicht 1 über einen speziellen NFT-Ausgang geprägt und übertragen werden. DIDs können dazu beitragen, die Identität des Ausstellers einer NFT nachzuweisen.

Nehmen wir an, unser Beispiel-Smartphone-Hersteller „Phonemkr“ möchte digitale Produktpässe in Form von NFTs für jedes von ihm verkaufte Telefon ausstellen. „Phonemkr“ erstellt seine Identität in einem Alias-Ausgang und verknüpft seine DID nachweislich mit seiner Website phonemkr.com. Wenn „Phonemkr“ NFTs mit seiner Identität als Aussteller ausstellt, beweist dies effektiv, dass phonemkr.com diese NFTs ausgestellt hat.

Beachten Sie, dass Domain Linkage eine zukünftige Erweiterung der IOTA-Identität ist, aber in der aktuellen Version noch nicht enthalten ist.

Ähnlich wie bei der Übertragung von Geldmitteln können NFTs auch DIDs gehören und an diese übertragen werden, da die Freischaltbedingung eines NFT-Outputs ein Alias-Output sein kann, der eine DID repräsentiert, wodurch sichergestellt wird, von wem Sie NFTs erhalten oder an wen Sie NFTs senden.

Darüber hinaus können Identitäten durch NFTs entsperrt (d. h. „besessen“) werden. Dies mag zunächst seltsam erscheinen und wird für Menschen im Allgemeinen nicht empfohlen, kann aber für Dinge oder Organisationen, die durch ihre jeweiligen NFTs repräsentiert und gehandelt werden, von großem Nutzen sein. Auf diese Weise können das Eigentum an einer Sache (oder Organisation) und die Kontrolle über die jeweilige Identität in einer einzigen atomaren Interaktion übertragen werden.

DIDs, die native Token ausgeben

Wenn der Münzsammler nativer Token ein DID ist, kann er den Token-Inhabern bessere Garantien und mehr Vertrauen bieten. Mit diesen Informationen können die Token-Inhaber überprüfen, wer einen nativen Token ursprünglich erstellt hat, und so feststellen, ob ein nativer Token, den sie erhalten haben, von dem Ort stammt, an dem sie ihn erwartet haben, oder die Behauptungen einer Person in Bezug auf die von ihr geprägten Vermögenswerte überprüfen.

Technisch gesehen funktioniert dies, weil native Token über einen Foundry-Ausgang erstellt werden, der wiederum von einem einzigen Alias-Ausgang kontrolliert wird. Eine in diesen Alias Output eingebettete Identität ermöglicht es, die Identität des Münzsammlers zu ermitteln.

Erweiterung der DID-Funktionalität durch Smart Contracts

Das Stardust-Protokoll-Upgrade wird es ermöglichen, den Status von IOTA Smart Contracts (ISC) Ketten in Alias Outputs im Ledger zu verankern. Mit IOTA Identity können Smart Contract-Ketten nachweislich mit Identitäten verknüpft werden. Wie oben unter „Identitäten, die andere Identitäten kontrollieren“ beschrieben, können Identitäten hierarchisch organisiert werden, so dass eine einzelne Identität mehrere andere Alias Outputs erstellen und kontrollieren kann. Das bedeutet, dass eine Identität in einem Alias-Ausgang den Alias-Ausgang einer ISC-Kette kontrollieren kann. Auf diese Weise können Benutzer den Gouverneur einer Kette identifizieren und entscheiden, ob sie der Kette vertrauen und mit ihr interagieren wollen. Außerdem können externe Beobachter so überprüfen und nachweisen, wer letztlich die Kontrolle über die Kette hat.

Die Speicherung von Identitäten in Layer-1-Outputs wird auch die Zusammensetzbarkeit durch Smart Contracts ermöglichen. Zusätzliche Funktionen für Identitäten, die nicht durch den DID-Standard abgedeckt sind, können in Smart Contracts eingebaut werden, wie z. B. erweiterte oder speziellere Identitäts- und Zugriffsmanagement (IAM)-Anwendungsfälle. Wir werden dieses Thema kurz vor der Veröffentlichung von Smart Contracts auf Shimmer weiterverfolgen.

Beginnen Sie jetzt mit der Erstellung!

In diesem Blogbeitrag haben wir die neuen Möglichkeiten von IOTA Identity, die durch Stardust ermöglicht werden, untersucht. Um es kurz zu machen:

• Identitäten können andere Identitäten kontrollieren, was eine flexible Modellierung der Frage ermöglicht, wer die Repräsentation einer Identität ändern kann und wer diese Aktualisierungen überhaupt vornehmen darf.
• Identitäten können beim Senden und Empfangen von Geldern für mehr Vertrauen sorgen.
• Identitäten können das Vertrauen der Inhaber in die Emittenten von NFTs und nativen Token erhöhen.
• Identitäten ermöglichten die Authentifizierung von Smart-Contract-Ketten und werden in Zukunft eine tiefere Integration ermöglichen.

Die neueste Alpha-Version der IOTA-Identitätsbibliothek für das Shimmer-Netzwerk finden Sie hier:

• Rust: https://github.com/iotaledger/identity.rs
• JavaScript/TypeScript: https://github.com/iotaledger/identity.rs/tree/main/bindings/wasm

Wir möchten Ihnen so bald wie möglich eine frühe Version zur Verfügung stellen, damit Sie all diese neuen Möglichkeiten erkunden können. Aber bitte beachten Sie, dass dies eine Alpha-Version ist und wir immer noch daran arbeiten, die ergonomischste API und Erweiterungspunkte zur Anpassung Ihrer Implementierungen bereitzustellen.

In den kommenden Wochen werden wir die UTXO-Methode weiter polieren und stabilisieren und mit der Implementierung der zweiten Methode beginnen, um beides fertig zu haben, bevor das Stardust-Protokoll-Upgrade das IOTA-Mainnet erreicht.

Wenn Sie in der Zwischenzeit Feedback zum aktuellen Stand der Bibliothek haben, gehen Sie zu GitHub und erstellen Sie ein Problem oder melden Sie sich auf Discord in #identity. Wir freuen uns darauf, von Ihnen zu hören!

Original by Shimmer: https://blog.shimmer.network/iota-identity-is-coming-to-layer-1/