Seiten Kategorie: Produkte

15. Okt’20

Übersetzung des Blogartikel der Autoren Mathew Yarger & Jonathan Shaffer, IOTA Foundation.

Die IOTA Foundation nimmt IOTA Streams in ihr wachsendes Produktportfolio auf und erreicht damit ein neues Niveau beim Datenaustausch, bei der Sicherheit und der Kontrolle über angeschlossene Geräte. Die IOTA Foundation freut sich, die endgültige Veröffentlichung des IOTA Streams Alphabekannt zu geben!

Besuchen Sie die IOTA Streams Webseite!

Einführung

Wir freuen uns, heute die endgültige Alpha-Version für IOTA Streams, ein Open-Source-DLT-Framework für dezentrales Daten-Streaming und Verschlüsselung auf eingebetteten Systemen, ankündigen zu können.

IOTA Streams bietet granularen Datenzugriff und -austausch für angeschlossene Geräte und andere IoT-Integrationen. Im Wesentlichen gibt es den Datenproduzenten detaillierte Kontrolle darüber, wer auf die von ihnen produzierten Daten zugreifen kann, sei es über ein mobiles Gerät, einen Umgebungs-ITT-Sensor, ein angeschlossenes Fahrzeug, eine industrielle IoT-Lösung oder etwas anderes.

Dieser Beitrag wird sich in erster Linie auf die Vision für IOTA-Streams konzentrieren. Für eine technischere Erklärung können Sie unsere jüngsten Beiträge über Streams hier lesen, ebenso wie die Dokumentation und die neu veröffentlichten Spezifikationen.

Integration von Chrysalis Phase 2

Zunächst einmal: Warum sind wir immer noch in Alpha? Streams wird so lange im Alpha bleiben, bis der Übergang zum Chrysalis-Phase-2-Protokoll-Upgrade erfolgt ist. Nach der Aktualisierung für volle Funktionskompatibilität wird Streams dann zu Beta übergehen.

Es folgt eine Erklärung zu den IOTA-Streams, den Problemen, die sie löst, und den neuartigen Anwendungsfällen, die sie ermöglicht.

Bei Streams dreht sich alles um Daten

Geräte, die Daten erzeugen, schaffen Wert. Dieser Wert kann nur erfasst werden, wenn die Daten geschützt sind. Das Warten, bis die Daten die Cloud erreichen, birgt viele Sicherheitsrisiken, einschließlich der Risiken von Datendiebstahl, Manipulation und Single Points of Failure. IOTA Streams wurde geschaffen, um Daten auf dem Gerät selbst zu sichern und zu strukturieren. Mithilfe von Kryptographie, manipulationssicherer historischer Verifizierung und Datenordnung auf dem Tangle können wir den Wert der Daten am Entstehungspunkt sichern.

In unserer jüngsten Veröffentlichung von IOTA Access sprachen wir über das notwendige Gleichgewicht zwischen dezentralisierten Technologien und zentralisierten Prozessen. Dasselbe Gleichgewicht ist für Daten wichtig. Wir sehen ständig Schlagzeilen darüber, dass unsere Daten gestohlen werden, wenn zentralisierte Datenbanken kompromittiert werden. Die Unveränderbarkeit und Dezentralisierung von Daten durch ein verteiltes Ledger wie IOTA kann dazu beitragen, solche Bedrohungen zu entschärfen, aber es müssen nicht immer alle Daten dezentralisiert werden.

IOTA Streams wurde geschaffen, damit Benutzer, Organisationen, Geräte und Systeme manipulationssichere Daten dort einbeziehen können, wo es sinnvoll ist. Wenn die Daten schnell und mit minimaler Sicherheit verarbeitet werden müssen, wie z.B. beim Online-Streaming von Videos, wäre das kein geeigneter Anwendungsfall für Streams. Wenn Daten wertvoll sind und gesichert werden müssen, können Streams diesen Schutz bieten.

IOTA-Streams ist eine 2-Layer-Technologie

IOTA Streams ist als Ergänzung zu anderen IOTA-2-Layer-2-Frameworks konzipiert, wie z.B. IOTA Access (Ende September angekündigt). Da wir mit einem Embedded-First-Ansatz arbeiten, sind unsere Werkzeuge schlanker, effizienter und hardwaremäßig durchsetzbar.

Um Daten von einem Gerät zu sichern, sie in einer leicht konsumierbaren Weise zu strukturieren und sicher auszutauschen, müssen die Operationen je nach Anwendungsfall auf dem Gerät, vor Ort oder auf einem Chip durchgeführt werden. Durch die Aktivierung dieser Funktionen als eingebettete Integration wird etwas Wichtiges ermöglicht – die “Own your own data” Bewegung.

Um eine Vorstellung davon zu bekommen, wie wertvoll Ihre Daten sein können, werfen Sie einen Blick auf John Ellis’ Präsentation über “The Zero Dollar Car”. Ellis schätzt den Wert der Google-Suchdaten einer vierköpfigen Familie auf 5500 Dollar pro Jahr. Dies basiert allein auf der Standardnutzung von Laptops, mobilen Geräten und Tablets. Wenn wir Fahrzeuge mit Android Auto oder Apple Carplay, Smart Home-Geräte wie Alexa oder Google Home, Ring, Nest und das wachsende Angebot an anderen IoT-Geräten hinzufügen, dann wird diese Schätzung von 5500 Dollar deutlich höher. Mit dem Zero-Dollar-Auto skizziert Ellis, wie diese Daten am Ende tatsächlich wertvoller sein können als das Fahrzeug selbst.

Was wäre, wenn wir diese Daten nehmen und ihren Wert gegen die Kosten für den Kauf des Fahrzeugs zurückgewinnen könnten?

Stellen Sie sich vor, welche Auswirkungen dieser Wert für Einzelpersonen und Familien haben könnte, die mit dem derzeitigen wirtschaftlichen Klima infolge der Pandemie zu kämpfen haben. Angesichts der steigenden Zahl von Arbeitsplatzverlusten, der Gespräche über das universelle Grundeinkommen und der wachsenden Einkommensungleichheit könnte die direkte Bezahlung für Ihre Daten ein wichtiger Teil der Lösung sein.

Datenschutz und Sicherheit

Was aber, wenn Sie nicht wollen, dass Ihre Daten verkauft werden? Manche Menschen finden einfach ihre Privatsphäre wichtiger als den Wert, den sie durch den Verkauf ihrer Daten erhalten. In diesem Sinne würden durch die Bezahlung für die Geheimhaltung unserer Daten bestimmte Produkte zum Selbstkostenpreis bleiben. Wenn wir jedoch ein billigeres Produkt oder potenziell kostenlose Produkte wollten, könnten wir die Möglichkeit haben, uns für die gemeinsame Nutzung der Daten, die wir auf diesen Geräten produzieren, zu entscheiden.

Mit bestehenden zentralisierten Systemen sind solche Szenarien möglicherweise nicht möglich, weil die Daten dort gespeichert sind und wem sie gehören. Die Vision kann nur dann verwirklicht werden, wenn sie in einer Weise aufgebaut wird, die überprüfbar ist und Rechenschaftspflicht ermöglicht. 

Wenn man diese Speicherung und Verwaltung von einem zentralisierten System wegnimmt, die Strukturierung und Verarbeitung dieser Daten in granularer Weise ermöglicht und dies mit einem Framework tut, das ein immanentes Maß an Vertrauen schafft, bietet sich die einmalige Gelegenheit, ein gerechteres System einzurichten. Der zuerst eingebettete Aufbau ermöglicht eine Skalierung, die von den kleinsten, ressourcenbeschränkten Geräten bis hin zu Cloud-Integrationen und Lösungen im Unternehmensmaßstab reicht. Dies ermöglicht eine Zukunft, in der jeder die Kontrolle über seine eigenen Daten übernehmen und Einnahmen auf der Grundlage seines Komforts und persönlichen Interesses erzielen kann.

Wenn Sie an der Unterstützung von Nachhaltigkeitsinitiativen interessiert sind, können Sie Wettersensoren und Emissionsüberwachung integrieren, um Ihre eigenen Auswirkungen in Ihrem Fahrzeug und zu Hause zu messen. Sie könnten diese Daten verkaufen, damit Klimaforscher, lokale Regierungen und nachhaltig ausgerichtete Organisationen ihre Bemühungen proaktiv und nicht reaktiv gestalten können.

Große Unternehmen und Konzerne sehen sich einer Reihe von Bedenken im Zusammenhang mit Daten gegenüber. Der Konsum der Daten ihrer Mitarbeiter gefährdet die von ihnen angebotenen Produkte und Dienstleistungen und beeinträchtigt ihre Fähigkeit, ihr geistiges Eigentum zu schützen. Sie brauchen Möglichkeiten, um zu überprüfen, ob ihre geschäftlichen Bemühungen geschützt und privat bleiben. Unternehmen wollen auch Produkte und Dienstleistungen entwickeln, die den Wert der Daten selbst nutzen. Wollen sie die Risiken und möglichen regulatorischen Konsequenzen der Verwaltung ihrer Speicherung kennen lernen?

Wie können Unternehmen also die Vorteile von Daten nutzen, ohne dass erhebliche Infrastrukturkosten und das Risiko regulatorischer Konsequenzen entstehen? Indem sie ihre Benutzer und Kunden an die erste Stelle setzen und ihnen die Wahl überlassen. Anreize für ihre Kunden, ihre Daten zu teilen, ohne diese auszunutzen zu können. Und dies auf eine Art und Weise, bei der der Kunde die Kontrolle hat. Wenn sie ihre Daten teilen wollen, können sie sich dafür entscheiden und dafür bezahlt werden (am besten natürlich in IOTA). Wenn sie diese Daten nicht mehr weitergeben wollen, können sie sich dagegen entscheiden. Auf diese Weise ist die Situation den Kunden gegenüber fair und dem Unternehmen gegenüber fair.

Das Ziel von IOTA-Streams

Dies ist das grundlegende Ziel von IOTA Streams und kapselt das, wofür es steht – die granulare Kontrolle über Daten und die Reduzierung der Abhängigkeit von zentralisierten Systemen, die sich die Daten zunutze machen.

Streams ist ein weiteres Beispiel dafür, wie die 2-Layer-Fähigkeiten des IOTA-Protokolls darauf ausgerichtet sind, Nutzen zu ermöglichen. Skala ist bereits in das Tangle integriert und es gibt keine Gebühren. Es ist an der Zeit zu zeigen, dass Dezentralisierung einen echten Einfluss auf die Art und Weise haben kann, wie Systeme entworfen und Lösungen gebaut werden. Senkung der Eintrittsbarriere, Verbesserung der Transparenz und Rechenschaftspflicht, Steigerung der Effizienz bestehender Lösungen und Erhöhung der Messlatte für die ethische Verwendung und Verwaltung von Daten.

Probieren Sie es aus!

Wir freuen uns, Ihnen mitteilen zu können, dass wir jetzt unseren Spezifikationsentwurf für IOTA-Streams veröffentlichen. Sie können die Spezifikation hier einsehen. 

Wir freuen uns über Rückmeldungen zu der Spezifikation, da wir sie ständig verbessern. Wir möchten auch darauf hinweisen, dass die Spezifikation nach dem Upgrade von Streams auf Chrysalis Phase 2 dem OMG Request for Proposals (RFP) für Linked Encrypted Transaction Streams (LETS) vorgelegt wird.

Um mit der Entwicklung zu beginnen, können Sie sich hier eine Anleitung zur Erstellung einer Messaging-App ansehen.

Um zu verstehen, wie Streams unter der Haube funktionieren, können Sie die Dokumentationsseite lesen und unsere jüngste Vorabankündigung lesen. Beispiele für Ein- und Mehrzweig-Kanal-Implementierungen finden Sie im Beispiel-Repository.

Unterstützung von Programmiersprachen

Wie in unserer jüngsten Veröffentlichung von IOTA Access erwähnt, wurde für die meisten unserer Produkte die Programmiersprache Rust gewählt. Um diesen Weg fortzusetzen, sind die Streams Library und die Channels Application beide in Rust geschrieben. Wir haben jedoch auch Pläne zur Entwicklung einer C-Bibliothek, um bestimmte eingebettete Anwendungen zu unterstützen.

Gegenwärtig haben wir C-Bindings entwickelt, und wir planen, in Kürze JavaScript und WebAssembly zu unterstützen. Wollen Sie nicht warten? Wir heißen das Ökosystem willkommen, sich zu beteiligen und zur Beschleunigung ihrer Entwicklung beizutragen.

Repositories

 Gegenwärtig umfasst IOTA Streams die folgenden Rust-crates:

• Channel-Application enthält die Kanal-Anwendung;
• Core layers enthält den Spongos-Automaten für schwammbasierte authentifizierte Verschlüsselung, Pre-Shared Keys und Pseudo-Zufallsgenerator;
• Keccak für Core layers enthält Keccak-F[1600] als Spongos-Transformation;
• Curve25519 asymmetrisches Crypto enthält Ed25519-Signatur und X25519-Schlüsselaustausch;
• DDML enthält eine Datendefinitions- und Manipulationssprache für Protokollnachrichten;
• Application layer für gemeinsame Anwendungsdefinitionen;
• Bindings enthält die C-Bindungen;
• Specification ist die Streams-Spezifikation in PDF-Form (Markdown in Kürze).

Roadmap

In der Einleitung wurde der Weg zur Beta- und Produktionsreife beschrieben. Intern haben wir daran gearbeitet, zu definieren, was dies aus der Produktperspektive bedeutet. Dementsprechend betrachten wir die Produktionsreife als erreicht, wenn die folgenden Kriterien erfüllt sind:

Technische Anforderungen:

1. Anfängliche Produkt-Benchmarks sind stabil, fertiggestellt, dokumentiert und überprüft.
2. Die anfänglichen Produktspezifikationen sind fertig gestellt. Die Spezifikationen wurden von Partnern und dem Ökosystem überprüft und werden in Richtung Standardisierung mit der OMG vorangetrieben.
3. Die Struktur des SDK wurde gründlich verfeinert und umfasst Produktdemos für die IOTA-Community und Partner, auf denen aufgebaut werden kann.
4. Unterstützte Hardware-Referenzen stehen für einfache Tests und Integration zur Verfügung.
5. Umfassende Sicherheitsaudits wurden von Dritten durchgeführt.
6. Bug-Bounty-Programme wurden eingerichtet.
7. Verifikations- und Regressionstests sind abgeschlossen und gut dokumentiert.
8. RFCs wurden veröffentlicht und zusammengeführt, um die Beteiligung der Community zu ermöglichen.

Anforderungen zur Marktakzeptanz:

1. Unterstützende Partner sind bestätigt und nehmen an Produkttests und -überprüfungen teil.
2. ELI5 und andere Dokumentationen sind leicht verfügbar, einschließlich
3. Branchenspezifische 2 Pager für die Schwerpunktfälle Mobilität und Automobil.
4. Branchenspezifische 2 Pager für die Schwerpunktthemen Globaler Handel und Lieferkette.
5. Fallstudien von abgeschlossenen Piloten.
6. Produkt-Whitepapers.
7. Einführungsseite mit Anwenderbeispielen.

Aufruf zur Zusammenarbeit

Die Möglichkeiten sind zahlreich, und wir fangen gerade erst an.

IOTA Streams befindet sich jetzt in der letzten Phase der Alpha-Entwicklung. Die IOTA Foundation wird weiterhin an unserem Engagement für Open Source festhalten und sich weiterhin dafür einsetzen, dass unser ständig wachsendes Ökosystem die IOTA-Streams in die Praxis umsetzen kann.

Im Zuge der Weiterentwicklung des IOTA-Protokolls werden Produkte, die auf dem Second Layer aufbauen, vor der Beta-Phase und der vollen Produktionsreife weiter verfeinert werden. Wir sind immer auf der Suche nach weiteren Partnern und Mitwirkenden für das Projekt. Sie können sich direkt an uns wenden, wenn Sie Teil dieser Initiative werden wollen.

Jonathan leitet das IOTA Streams X-Team, eine Gruppe von Mitgliedern der Community und der IOTA Foundation, die gemeinsam an der Verbesserung der IOTA Streams arbeiten. Um anzufangen, besuchen Sie die IOTA Experience Teams auf GitHub und bewerben Sie sich über dieses Formular.

Wir laden die IOTA-Gemeinschaft ein, zur Entwicklung der IOTA-Streams beizutragen. Rezensionen und Kommentare zur Streams-Spezifikation sind ebenfalls willkommen.

Die Bemühungen im 4. Quartal 2020 werden sich nun darauf konzentrieren, Streams mit der IOTA-Chrysalis-Phase 2 kompatibel zu machen.

Schauen Sie wie immer bei Discord auf dem #streams-Diskussionskanal vorbei, um Ihre Erfahrungen mit dieser Veröffentlichung zu teilen!

Folgen Sie uns auf Twitter, um über alle Neuigkeiten auf dem Laufenden zu bleiben: https://twitter.com/iotatoken

Quellen

https://blog.iota.org/final-alpha-release-for-iota-streams-5a4cfeca506c

IOTA Stronghold – Boden Fortress

19. Mrz’21

Übersetzung des IOTA Blogartikel.

Stronghold ist eine Open-Source-Software-Bibliothek, die ursprünglich zum Schutz von IOTA Seeds entwickelt wurde, aber zum Schutz jedes digitalen Geheimnisses verwendet werden kann. Es ist eine sichere Datenbank für die Arbeit mit Kryptographie, die sicherstellt, dass Geheimnisse (wie private Schlüssel) niemals preisgegeben werden. Es stellt einen eigenen Peer-to-Peer Kommunikations-Layer zur Verfügung, so dass verschiedene Apps sicher mit dem hochmodernen Noise Protocol über libp2p kommunizieren können. Stronghold wird eine sichere Basis für die neue IOTA Firefly Wallet bilden und in IOTA Identity integriert werden.

Wir haben diese Beta-Version “Boden Fortress” getauft, nach der Festung in Nordschweden, die zum Schutz des Landes und des Transports der “Wirtschaftswährung” – Eisenerz – während der Weltkriege in der ersten Hälfte des 20. Jahrhunderts errichtet wurde. Seine Nützlichkeit hat sich bewährt und er wurde auch während des Kalten Krieges weiter verwendet. Wie die Beta-Version von Stronghold auch, war die Boden-Fortress eine temporäre Lösung, die nur kurzlebig war und nach ihrer Dienstzeit wieder abgebaut werden sollte. Trotzdem war die Boden-Fortress fast hundert Jahre lang im Einsatz. Wir sind uns ziemlich sicher, dass die Beta von Stronghold viel, viel kürzer sein wird.

Heute, drei Monate nach dem Alpha-Release, freuen wir uns, die Stronghold-Beta ankündigen zu können. Diese Version bietet Garantien über die API, die Client-Logik und das Snapshot-Format – die sich nur ändern werden, wenn Sicherheitslücken gefunden werden. In diesem Stadium zu sein, qualifiziert Stronghold für ein vollständiges externes Audit, dessen Abschluss ein Meilenstein sein wird, den Stronghold für die Veröffentlichung der stabilen Version 1.0 erreichen muss.

Wenn Sie eine Auffrischung benötigen, wie Stronghold funktioniert, hat unser ansässiger Meme Lord Navin vom IOTA Foundation Board ein wunderbares kleines Diagramm erstellt, das erklärt, was Strongholds tun (und nicht tun) wird:

Im Allgemeinen werden die meisten Leute nicht einmal wissen müssen, dass sie einen Stronghold haben. Seine Verwendung sollte unsichtbar sein, ähnlich wie Besucher gewöhnlicher Webseiten nicht wissen müssen, welche Datenbank im Backend verwendet wird. Natürlich, wenn Webseiten verpflichtet wären, offenzulegen, wie sie unsere Benutzerdaten sichern, dann hätten wir vielleicht tatsächlich mehr Vertrauen in ihre Fähigkeit, uns zu schützen.

Hoffentlich werden irgendwann in nicht allzu ferner Zukunft Websites, Apps und sogar Betriebssysteme beginnen, die Stärke und den Nutzen von Ansätzen wie IOTA Identity zu erkennen: wo wir unsere eigenen Daten kontrollieren und sichern; wo wir entscheiden, was wir teilen; wo wir wählen, mit wem wir es teilen; wo wir befugt sind, den Zugriff zu widerrufen, wenn es uns passt.

Aus der Systemperspektive sehen wir uns heute in der Software damit konfrontiert, dass jede Anwendung das Bedürfnis hat, alle Geheimnisse zu nutzen, die sie zu brauchen glaubt, und dass es selten starke Garantien gibt, dass diese Anwendungen die Geheimnisse richtig schützen. Wir wollen, dass die Industrie im Allgemeinen erkennt, dass dies eine höchst unsichere Praxis ist, und dass der neuartige Ansatz von Stronghold nicht nur offensichtlich sicherer ist, sondern auch ein Architekturmuster, das es wert ist, angenommen zu werden. Es ist wirklich ganz einfach: Man kann keine Geheimnisse preisgeben, von denen man nichts weiß.

Sei ruhig und nimm mein Geld

Es ist nie gut, zu zuversichtlich zu sein, aber gleichzeitig müssen wir Ihr Vertrauen gewinnen, indem wir Sie bitten, unseren Glauben an Stronghold zu bestätigen. Aus diesem Grund werden wir neben dem “Attack-a-thon” bis Chrysalis (21. April 2021) eine Capture the Flag (CTF)-Herausforderung laufen lassen.

Irgendwo, versteckt in dieser Blogseite, können Sie eine Flagge (Hinweis) entdecken, die Ihnen hilft, einen Stronghold-Snapshot zu finden. Dieser Snapshot wurde mit dem Stronghold CLI unter der git-Revision fb7e9a6e2e6bbdd8a9f4140b3712ad5dce361cae erstellt. Sobald Sie es gefunden haben, ist der Rest des CTFs zu 100% in diesem Snapshot enthalten. Mit anderen Worten, es gibt nirgendwo externe Ressourcen, die Ihnen helfen könnten, also verschwenden Sie wirklich nicht Ihre Zeit mit dem Versuch, in andere Systeme einzubrechen.

Im Speicher des Schnappschusses befindet sich eine Flagge, die beweist, dass Sie hineingekommen sind. Der Tresor enthält jedoch einen aktuellen IOTA Mainnet Seed in einem geheimen Tresor/Pfad, der eine weitere Flagge ist. Dieser Seed enthält 3,78 GIOTA. Zum Zeitpunkt des Schreibens dieses Artikels hat das einen Wert von ~5000 USD. Der einzige Preis ist der Seed.

Wenn Sie eine Flagge finden, besuchen Sie bitte die Stronghold-Diskussion auf GitHub, um Anweisungen zu erhalten, wie Sie in die Bestenliste aufgenommen werden. Viel Glück!

Was als nächstes kommt

In den nächsten Monaten werden wir Tutorials, Beispiele, Dokumentationen und Spezifikationen vorbereiten sowie die Integration mit anderen Projekten der IOTA Foundation vornehmen. Während dieser Zeit werden wir den Client um einen flexiblen Ansatz für die prozedurale Kryptographie von Stronghold erweitern, einen “Versions-Updater” veröffentlichen, der das nahtlose Upgrade eines Snapshots auf eine neue Stronghold-Version ermöglicht, und das Kommunikationssystem mit einer nativen Desktop-Anwendung validieren. Schließlich wird Stronghold einem vollständigen Audit unterzogen und dann als Stable markiert.

Technische Hinweise zum Release

Stronghold besteht aus einer Reihe von Bibliotheken, die alle zusammenarbeiten. Diese Bibliotheken wurden im Rahmen eines externen Audits von Firefly vertikal geprüft und von einer Reihe von IF Rust Engineers auf Qualität und Sicherheit untersucht. Diese haben es für die Beta-Veröffentlichung qualifiziert, aber bevor wir Stronghold als stabil markieren, wird es ein zukünftiges horizontales Audit der gesamten Codebasis geben.

Im Folgenden finden Sie eine kurze Beschreibung jedes einzelnen Moduls, gefolgt von seinem internen Release-Status und einem Link zum Changelog.

Client

Der Client ist die einzige Schnittstelle zu Stronghold, deren Verwendung wir empfehlen können. Er dient als Abstraktionslayer für die darunterliegende Engine und die Kommunikationsbibliotheken, was garantiert, dass selbst wenn sich die interne Codebasis ändert, Ihre Schnittstelle zu Stronghold weiterhin funktioniert.

Status: Beta, CHANGELOG

Vault (dt. Tresor)

Der Tresor ist jetzt beschreibbar und nutzbar, aber nicht lesbar. Das bedeutet, dass es keine Methode gibt, mit der der Client jemals die im System gespeicherten Geheimnisse lesen kann, und bietet eine solide Garantie, dass Stronghold so sicher wie möglich ist. Wenn ein Geheimnis aus einem Datensatz im Tresor abgerufen wird, wird es an die Laufzeitumgebung weitergegeben, die es in einen fortschrittlichen Speicherallokator entschlüsselt, der das Geheimnis während der Verwendung bewacht. Aus diesem Grund betrachten wir den Tresor als “gehärtet”.

Status: Beta, CHANGELOG

Speicher

Der Speicher ist ein Schlüssel:Wert-Speicherdienst mit Lese- und Schreibzugriff, der zwar im Snapshot verschlüsselt ist, aber nicht den gleichen Speicherschutz wie der Tresor genießt. Dies liegt daran, dass alle Daten, die an den Client zurückgegeben werden können, nicht als “wirklich geheim” eingestuft werden können. Während sie im Ruhezustand verschlüsselt sind, sind sie im Speicher nicht verschlüsselt und werden daher von uns als “privat und sicher”, aber nicht als “gehärtet” eingestuft.

Status: Beta, CHANGELOG

Runtime (dt.Laufzeit)

Die vielleicht größte Einzeländerung seit der Alpha-Version ist die neue Laufzeitumgebung, die vollständig auf libsodium-sys basiert und garantiert auf allen Plattformen funktioniert. Sie schützt nach wie vor exponierte Geheimnisse im Speicher mit klassischen Guard Pages und Canaries, während kryptografische Operationen durchgeführt werden. Zusätzlich gibt es jetzt einen internen Guarded-Vektor-Typ, der es Stronghold ermöglicht, Datensätze zu schützen, wenn sie in Gebrauch sind, und sie automatisch auf Null zu setzen.

Status: Beta, CHANGELOG

Snapshot

Die Snapshot-Crate dient dazu, die Persistenzdatei zu entschlüsseln und die Daten in den Tresor und Speicher zu legen. Sie verschlüsselt auch den Tresor und Speicher, um die Persistenzdatei zu aktualisieren.

Status: Beta, CHANGELOG

Kommunikation

Die Kommunikations-Crate verwendet das libp2p-System mit dem Noise-Protokoll, das die erlaubte Nutzung von entfernten Tresoren für die Erstellung von Diensten wie Fernsignierung und Multi-Faktor-Autorisierung ermöglicht. Es ist nicht in aktiver Verwendung mit Chrysalis, wird aber zu einem späteren Zeitpunkt von Wallet und Identity verwendet.

Status: Alpha, CHANGELOG

crypto.rs

Diese Bibliothek ist zwar keine interne Abhängigkeit von Stronghold, stellt aber kryptographische Primitive für Stronghold (und alle anderen IOTA-Bibliotheken, die Kryptographie verwenden müssen) zur Verfügung.

Status: Beta, CHANGELOG

IOTA Stronghold – Saint-Malo

24. Dez’20

Übersetzung des Blogartikel von Autor Daniel Thompson-Yvetot, IOTA Foundation.

Stronghold ist eine Open-Source-Software-Bibliothek, die ursprünglich zum Schutz von IOTA Seeds entwickelt wurde, aber zum Schutz jedes digitalen Geheimnisses verwendet werden kann. Es ist eine sichere Datenbank für die Arbeit mit Kryptographie, die sicherstellt, dass Geheimnisse (wie etwa der private key) niemals preisgegeben werden. Es bietet eine eigene Peer-to-Peer-Kommunikationsschicht, so dass verschiedene Instanzen sicher über das hochmoderne Noise-Protokoll kommunizieren können. Stronghold wird eine sichere Basis für die neue IOTA Firefly Wallet bilden.

In einer zunehmend vernetzten Welt mit intelligenten Geräten, egal ob Telefon, Stromzähler, Fernseher oder sogar Kreditkarte, wird die Bedeutung von echter Sicherheit nur noch wachsen. IoT-Geräte müssen über feindliche Netzwerke sicher miteinander kommunizieren. Jedem, der dies liest, muss klar sein, dass es eine sehr reale Notwendigkeit gibt, Daten wie Identität und digitale Führerscheine vor zentralisierten Hacks zu schützen. Das Problem ist nicht, dass dieses Risiko unbekannt ist. Es ist nur eine sehr schwierige Herausforderung, die richtig gelöst werden muss. Wir haben diese Herausforderung angenommen, um das IOTA-Ökosystem zu schützen und Bibliotheken zu bauen, die jeder nutzen kann.

Seit der ersten Ankündigung von Stronghold haben wir das Team vergrößert, das Innenleben der Engine überarbeitet und Anwendungen erforscht, die mit Stronghold gebaut werden können. Heute freuen wir uns, das Alpha-Release ankündigen zu können, das den Schritt von der Forschung zur Entwicklung vollzieht. Wir haben diese Version “Saint-Malo” getauft, nach der wunderschönen Festungsstadt an der nordfranzösischen Küste der Bretagne, die nach dem Zweiten Weltkrieg wieder aufgebaut wurde. Dieses einstige Piratenversteck hat sich erholt und überlebt, seine massiven Mauern schützen es vor den gewaltigen Attacken der Gezeiten.

Sie fragen sich vielleicht, was bedeutet “Alpha”? Was macht manche Software zu “Alpha” und manche zu “Beta” – und wann wird sie “stabil”? Diese Stadien in der Software-Entwicklung haben mit der Stabilität des Codes zu tun und mit dem Vertrag, den die Projektingenieure mit den Kunden haben. Im Fall von Stronghold, indem wir unser Projekt als “Alpha”-Qualität deklarieren, sagen wir Ihnen, dass wir denken, dass es gut genug ist, um damit zu experimentieren. Wir haben die Theorie in die Praxis umgesetzt, unsere Annahmen überarbeitet und versucht, etwas zu entwickeln, das den Sweet Spot zwischen maximaler Sicherheit und Benutzerfreundlichkeit findet. Wir sind jetzt an dem Punkt, an dem wir Ihr Feedback wollen, das wir in die nächsten Entwicklungsstufen einfließen lassen werden.

Während der Alpha-Phase können Sie davon ausgehen, dass Stronghold weiterhin so funktionieren wird wie jetzt. Wir werden jedoch einige der internen Mechanismen verändern und möglicherweise auch kleinere Aspekte der offenen API ändern. Wir können nicht empfehlen, dass Stronghold heute von externen Parteien in der Produktion eingesetzt wird, da sich die Dinge bis zum Erreichen der Beta-Phase schnell ändern können – insbesondere während der externen Sicherheitsüberprüfung von Firefly und dessen Integration mit Stronghold. Während der Beta-Phase werden wir Stronghold für ein komplettes Sicherheits-Audit vorbereiten, danach werden wir die Spezifikation und Dokumentation für das stabile Release fertigstellen.

Wenn Sie sich jedoch schon jetzt die Hände schmutzig machen wollen und sich im Umgang mit der Kommandozeile wohlfühlen, gibt es hier eine schnelle Möglichkeit, Stronghold zu testen:

Besuchen Sie die GitHub-Releases-Seite, um das vorgefertigte Stronghold-Kommandozeilen-Binary für Ihre Plattform herunterzuladen. Wenn Sie etwas abenteuerlustiger sind und sich mit Rust auskennen, können Sie das GitHub-Repository klonen und es lokal für Ihr System bauen:

Der Rest dieses Artikels wird die Stronghold-Architektur in größerer Tiefe beschreiben und ist sehr technischer Natur.

Überblick:

• Wie sich Stronghold von anderen Datenbanken unterscheidet
• Stronghold-Engine und internes Akteursmodell
• Neue Client-Schnittstelle
• Härtung von Strongholds
• Dedizierte Kryptographie-crate – crypto.rs
• Releases und sicheres Konsumieren von Stronghold
• X-Teams

Was ist Stronghold und wie unterscheidet es sich von anderen Datenbanken?

Stronghold ist eine Software-Bibliothek, die in der Programmiersprache Rust geschrieben ist. Sie bietet eine verschlüsselte, persistente Datenbank zur Durchführung kryptographischer Operationen in einer sicheren Rechenzone, die über mehrere Geräte verteilt werden kann. Wir wurden schon oft gefragt, worin der Unterschied zwischen Stronghold und anderen Datenbanken besteht. Dieser lässt sich in drei Hauptunterscheidungen zusammenfassen:

1. Stronghold-Datensätze (und ihre Dateisicherungen) sind “von Natur aus” verschlüsselt, um Offline-Angriffe abzuschwächen. Bei den meisten anderen Datenbanken müssen Sie die Verschlüsselung selbst vornehmen, durch Bibliotheken, Plugins oder ein zugrunde liegendes verschlüsseltes Dateisystem.
2. Stronghold erlaubt es Ihnen, Operationen mit diesen gespeicherten digitalen Geheimnissen durchzuführen, ohne sie externen Prozessen zu offenbaren, und verhindert, dass diese Geheimnisse jemals in entschlüsselter Form exportiert werden. (Siehe Härtung von Strongholds weiter unten)
3. Mehrere Strongholds können als Netzwerk arbeiten und auf erlaubte, dezentralisierte Weise kommunizieren und zusammenarbeiten. (Erscheint im Januar 2021).

Stronghold-Engine und internes Akteursmodell

https://github.com/iotaledger/stronghold.rs/tree/dev/engine

Bevor wir in die Details der Client-Schnittstelle eintauchen, ist es wichtig, kurz auf die zugrunde liegende Architektur einzugehen.

Strongholds werden durch eine Binärdatei persistiert, die wir einen “Snapshot” nennen. Diese Dateien sind im Ruhezustand verschlüsselt und können zwischen Geräten und verschiedenen Betriebssystemen transportiert werden. Sobald ein Snapshot entschlüsselt wurde, existiert er als Tresor (oder mehrere Tresore) im Speicher. Um auf einen Datensatz im Speicher zugreifen und ihn entschlüsseln zu können, müssen Sie seinen Pfad kennen. Sobald Sie den Inhalt des Datensatzes haben, können Sie eine Operation mit diesem Datensatz durchführen und die Ergebnisse zurückgeben. Das ist alles sehr kompliziert, und wenn es unsachgemäß gemacht wird, besteht die Gefahr, dass Geheimnisse nach außen dringen, was wir mit Stronghold in erster Linie zu vermeiden versuchen.

Das Actor-Modell ist eine Art von Architektur, bei der einzelne “Actors” sich gegenseitig Nachrichten schicken, anstatt direkt Funktionen aufzurufen und Speicher zu übergeben. Dies ist ein hervorragendes Muster, das nicht nur eine Prozessisolierung bietet, sondern uns auch erlaubt, Nachrichten an andere Geräte zu senden. Wir haben die Schnittstelle, wie Sie weiter unten sehen werden, so gestaltet, dass Sie nicht gezwungen sind, ein Actor-Modell in Ihrem Code zu verwenden, aber es ist verfügbar, wenn Sie es bevorzugen.

Neue Client-Schnittstelle

https://github.com/iotaledger/stronghold.rs/tree/dev/client

Die gesamte Client-Schnittstelle wurde seit unserer ersten Implementierung neu aufgebaut, wobei das Riker-Akteursmodell und das “ask pattern” verwendet wurden. Dies erlaubt es Stronghold, seine interne Architektur zu isolieren, ohne eine höhere Bibliothek oder Anwendung zu zwingen, Riker (oder ein anderes Akteursmodell) zu verwenden.

• Die Schnittstelle kann durch asynchrone Methoden aufgerufen werden, die an das Stronghold-Objekt angehängt sind.
• Bei jedem Methodenaufruf wird ein temporärer Akteur erzeugt und ein Future an die konsumierende Bibliothek zurückgegeben.
• Nach Beendigung des Aufrufs wird der Actor garbage-collected und der Future aufgelöst.

Dies alles ist aufgrund der leichtgewichtigen Akteur-Abstraktionen von Riker möglich.

Das Stronghold-Objekt erzeugt intern mehrere Actor-Systeme, die über einen Client-Pfad-Identifikator definiert werden. Jedes dieser Systeme besteht aus mindestens 2 Akteuren: einem Cache-Akteur und einem internen Stronghold-Akteur, jeweils mit eindeutigen Bezeichnern, die vom Client-Pfad abgeleitet sind. Ein Snapshot-Actor wird hochgefahren, so dass er beim Schreiben eines Snapshots die Daten in allen zugehörigen Client-Systemen gemeinsam kapselt. Umgekehrt wird ein Snapshot, wenn er in das System eingelesen wird, zwischengespeichert und für jedes Paar aus Cache und internem Akteur einzeln gelesen, so dass der Konsument sicherstellen kann, dass die Daten auf vorhersehbare Weise angeordnet werden. Auf diese Weise ist es möglich, einen Teil eines Snapshots oder den gesamten Snapshot zu lesen.

Unter der Client-Abstraktion befindet sich die grundlegende Stronghold-Engine – ein sicheres versioniertes Key-Value-Speicherprotokoll. Dieses System lebt innerhalb des internen Akteurs zusammen mit der zonierten Runtime. Die Versionierung wurde über eine Location-API zu einem Opt-in-Feature gemacht. Jeder Standort definiert eine Beziehung zwischen jedem Client-System und den Tresoren und Datensätzen darin. Ein Client ist eine Sammlung von Tresoren und ein Tresor ist eine Sammlung von Datensätzen, wobei jeder Datensatz einen Teil der Daten enthält.  

Die Standort-API ermöglicht es dem Verbraucher, einen generischen Standort oder einen Zählerstandort anzugeben. Der generische Speicherort definiert einen Tresor- und Datensatzpfad, der fest ist. Diese generischen Speicherorte verwenden keine Versionierung und können überschrieben werden. Die Speicherortzähler hingegen verwenden einen Zähler, um den Datensatzindex zu definieren. Wenn ein Verbraucher einen Speicherortzähler verwendet, hat er die Möglichkeit, den Zählerwert entweder direkt anzugeben oder das System dies für ihn tun zu lassen. Wenn der Zähler nicht explizit angegeben wird, verwendet das System standardmäßig den “Kopf” des Tresors. Der Kopf des Tresors wird abhängig von der Operation definiert; wenn die Operation ein Lesevorgang ist, ist der Kopf der letzte Datensatz, der in den Tresor geschrieben wurde, und wenn die Operation ein Schreibvorgang ist, ist der Kopf der nächste Datensatz, der basierend auf dem linearen Zählerwert geschrieben wird.

Neben den grundlegenden datenbankähnlichen Operationen bietet Stronghold über seine Laufzeit eine Reihe von kryptografischen Operationen. Jede dieser kryptographischen Operationen ist als Prozedur definiert. Spezifische Eingaben und Ausgaben werden je nach Bedarf pro Prozedur angegeben. Wenn zum Beispiel ein Verbraucher wie Firefly einen kryptographischen Seed mit Hilfe einer Mnemonik generieren und dann diesen Seed verwenden möchte, um ein Ed25519-Schlüsselpaar abzuleiten, um ein Stück Daten zu signieren, kann er dies tun, indem er die entsprechenden Prozeduren aufruft. “BIP39 Generate” könnte aufgerufen werden, um einen Seed aus einer bereitgestellten Mnemonik zu erzeugen. “SLIP10 Derive” kann auf diesem Seed-Platz aufgerufen werden, um einen Schlüssel zu erzeugen, der wiederum im Stronghold gespeichert wird.  “Ed25519 Public Key” kann nun auf diesem Schlüsselspeicherplatz aufgerufen werden, um den benötigten öffentlichen Schlüssel abzuleiten, und dann kann “Ed25519 Sign” aufgerufen werden, um Daten zu signieren. Bei diesem Vorgang sind die einzigen Daten, die vom Stronghold zurückgegeben werden, die Signatur und der öffentliche Schlüssel.  Alle anderen Daten werden zur Sicherheit innerhalb des Strongholds an den angegebenen Stellen aufbewahrt.

Härten von Stronghold

https://github.com/iotaledger/stronghold.rs/tree/dev/runtime

Einige Betriebssysteme und Hardware-Plattformen bieten einzigartige Möglichkeiten, die Runtime-Sicherheit zu erhöhen. Wir entwickeln daher eine sichere Rechenzone innerhalb von Stronghold, die Prozess-Sandboxing und Syscall-Filterung verwendet, um eine Rechenenklave zu bilden. Wir verwenden auch einen benutzerdefinierten Speicherallokator mit “Guard Pages”, der es uns ermöglicht, den Zugriff auf den Speicher zu beschränken, wenn er nicht benutzt wird. Diese Enklaven-Tools können von anderen Projekten verwendet werden, auch wenn sie nicht den vollen Funktionsumfang von Stronghold benötigen.

Für die Uneingeweihten: Syscall-Filterung ermöglicht es einem Prozess, seine Rechte für den Zugriff auf Betriebssystem-Ressourcen aufzugeben. Ein Beispiel: Warum sollte ein kryptographischer Algorithmus jemals auf das Dateisystem oder sogar auf Dateideskriptoren zugreifen müssen (zur Erinnerung: unter Unix ist alles eine Datei)? Um diese Einschränkungen anzuwenden, gabelt sich der Wrapper vom Hauptprozess ab (z. B. die Wallet-Anwendung, die UI- und Netzwerkcode enthält) und führt dann die sensiblen Operationen aus. Dies bringt auch zusätzliche Vorteile in Bezug auf die Speicherisolierung und potenziell böswillig erzeugte Threads.

Attribute der Secure Zone

Die folgenden Merkmale der sicheren Zone werden angewendet (sofern das Betriebssystem sie bereitstellt), um die defensive Tiefe der Gesamtsicherheit des Systems zu erhöhen:

1. Prozessisolierung: Fork zur Secure Zone (Runtime) und Anwendung einer Acceptlist mit einer sehr restriktiven Menge an erlaubten Syscalls
2. Speicherverwaltung: Verwenden Sie innerhalb der Secure Zone nur Zuweisungen mit Guard Pages und restriktivem Speicherschutz
3. Kommunikation: Eingehende Anforderungen (TX) werden aus dem elterlichen Speicher gelesen, und das ausgehende Ergebnis (RX) wird verschlüsselt und mit einem ephemeren Schlüssel authentifiziert, der vor dem Forking erzeugt wird.

Es kann auch darauf hingewiesen werden, dass diese Maßnahmen es schwieriger machen, ein bereits kompromittiertes System zu sondieren, d. h. es handelt sich um Defense in Depth, nicht um perfekte Sicherheit. Dafür müssen wir Strongholds auf dedizierter Hardware, wie dem USB Armory Mk-II, herstellen und verteilen.

crypto.rs

https://github.com/iotaledger/crypto.rs

Mit der Entscheidung der IOTA Foundation im Jahr 2019 auf die Programmiersprache Rust umzusteigen, verwenden viele der Software-Bibliotheken und Produkte der Foundation Rust. Es besteht ein wachsender Bedarf an einer ordnungsgemäß überprüften und gepflegten Kryptographie-Bibliothek, die kryptographische Primitive und Algorithmen sammelt, die für Anwendungen in IOTA benötigt werden. Kryptographie muss geprüft, gewartet und ordnungsgemäß überprüft werden.

Leider ist Kryptographie leicht falsch zu machen und Fehler können sehr reale Auswirkungen haben. In der Tat ist dies eines der Hauptziele des IOTA Stronghold-Projekts: Es einfach zu machen, Kryptographie sicher zu benutzen – also setzen wir unsere eigene Philosophie um.

Zu diesem Zweck haben wir bereits die gesamte Familie der von IOTA benötigten Kryptographie integriert:

Quelle: https://github.com/iotaledger/crypto.rs/blob/dev/README.md

Release und sicherer Umgang

Für jede Bibliothek, die auf Sicherheit bedacht ist, ist es wichtig, eine solide Veröffentlichungsstrategie zu haben. Wie viele andere moderne Paketverteilungssysteme, hat Rust das Cargo Crates Ökosystem. Wir veröffentlichen automatisch auf crates.io, indem wir das Covector Polyglot Changelog und den Freigabe-Workflow verwenden, der drüben in der Tauri Community entwickelt wurde. Covector ermöglicht eine schlüsselfertige Veröffentlichungsprozedur, mit einem Minimum an menschlichen Eingriffen und einer überprüften Prozesskette für das Testen, Bauen, Linting, Auditing, Changelogging, das Zusammenführen in den Haupt-Branch, das Erstellen von Git-Release-Tags, das Herstellen von Artifacts (wie das Kommandozeilen-Binary), das Veröffentlichen einer neuen Version auf Github und das anschließende Veröffentlichen auf crates.io.

Bis sich Stronghold und Crypto.rs jedoch stabilisiert haben und alle Ressourcen rein über crates.io (und nicht über Git) verfügbar sind, werden unsere Ressourcen nur auf GitHub verfügbar sein. Wir entschuldigen uns dafür, aber wir arbeiten Tag und Nacht daran, die Crates und ihre Dokumentation richtig verfügbar zu machen.

Obwohl es robust und im Allgemeinen stabiler als NPM ist, ist crates.io immer noch zentralisiert und es macht es schwierig, entfernte Crates zu verifizieren. Aus diesem Grund möchten wir empfehlen, dass Ihr Rust-Projekt Stronghold immer über Git-Hashes konsumiert, da Sie auf diese Weise absolut verifizieren können, dass der Code, den Sie erhalten, das ist, was Sie erwarten.

[dependencies.iota-stronghold]

git = “https://github.com/iotaledger/stronghold.rs”

rev = “fdff9f22c087f0c027e4aaa5a8dbc40218e6cf52”

Vertraue, aber überprüfe.

X-Teams

Sie sind großartig, weil Sie sich diesen ganzen Artikel durchgelesen haben, und deshalb würden wir uns freuen, wenn Sie eng mit uns zusammenarbeiten, um die Zukunft von Stronghold mitzugestalten.

Unabhängig davon, ob Sie sich selbst als Mitglied der IOTA-Community betrachten oder nicht, sind Sie eingeladen, Ihre Erfahrung in Stronghold einzubringen. Dazu bewerben Sie sich bitte über dieses Formular, um in das X-Team aufgenommen zu werden und an dem Kick-Off-Meeting teilzunehmen, das im Januar 2021 stattfinden wird.

Sie können den Fortschritt verfolgen unter: https://github.com/iota-community/X-Team_IOTA_STRONGHOLD

Quellen

https://blog.iota.org/stronghold-alpha-release/

Cartesi Partnerschaft

23. Mrz’21

Übersetzung des IOTA Blogartikel.

Cartesi und die IOTA Foundation kooperieren, um die Einführung von Smart Contracts für das IoT zu beschleunigen

Mit IOTA Oracles, IOTA Smart Contracts und Cartesis Linux-basierter virtual machine werden die beiden Gruppen nicht-blockchain-basierte Anwendungsfälle und Unternehmen in die Welt des dezentralen Finanzwesens (DeFi), Gaming, NFTs und des industriellen IoT bringen.

Wir freuen uns, unsere formelle Partnerschaft mit Cartesi bekannt zu geben, einer Organisation, die sich dafür einsetzt, Mainstream-Software-Stacks (z. B. Linux VM) in die Welt der Distributed-Ledger-Technologie und Smart Contracts einzuführen. Als Teil dieser Partnerschaft werden wir in den kommenden Monaten eng zusammenarbeiten mit dem Ziel, die Entwicklung und Annahme von IOTA Smart Contracts zu beschleunigen und die Cartesi VM als offizielle VM-Option für IOTA dApps zu integrieren.

Mit der offiziellen Partnerschaft zwischen den beiden Netzwerken und Communities hoffen wir, die Nutzerbasis von beliebten Anwendungsfällen der dezentralen Finanzen (DeFi) wie Automated Market Maker (AMMs), Gaming, Non-Fungible Tokens (NFTs) und Oracles zu erweitern und gleichzeitig die Fähigkeit von IOTA zu stärken, dezentrale Technologien für Unternehmen anzubieten, die gängige Technologie-Stacks verwenden.

Eines der Hauptziele der IOTA Foundation war es schon immer, die Kluft zwischen Anwendungen der realen Welt und der Blockchain-Technologie zu überbrücken. Viele der heute verfügbaren Lösungen leiden unter wichtigen Design-Einschränkungen, die eine breite Akzeptanz außerhalb der bekannten “Krypto-Anwendungen”, die wir heute populär sehen, verhindern.

Mit IOTA haben wir Tools, Architektur und Software entwickelt, die es Unternehmen ermöglichen, dezentrale Technologien mit wenig Aufwand und minimalem Overhead zu nutzen. Mit unserem Fokus auf Standardisierung löst das IOTA-Protokoll sein Versprechen ein, das Konzept der “erlaubnisfreien Innovation” zu erfüllen. Unternehmen nutzen unsere Technologie, binden uns in die Spitzenforschung mit ein oder verweisen auf uns in Industriepatenten, unabhängig von jeglichem Einsatz der IOTA Foundation.

Die IOTA Foundation und Cartesi stimmen in ihrer Vision gut überein: Cartesi arbeitet daran, die Lücke zwischen der Mainstream-Software-Welt und Blockchains zu schließen. Diese Lücke war ein großes Hindernis für die breite Akzeptanz, nach der sich die Industrie gesehnt hat. Blockchains arbeiten typischerweise unter einer solchen Ressourcenknappheit, dass die Verwendung eines echten Betriebssystems bisher nicht in Frage kam. Aber ohne ein Betriebssystem können Blockchain-Anwendungen nicht von den vergangenen Jahrzehnten der weltweiten Softwareentwicklung profitieren. Stattdessen werden die Mainstream-Entwickler mit einer frustrierenden Situation konfrontiert.

Das Cartesi-Team steht dem Team der IOTA Foundation seit ihrer Gründung nahe, wobei Serguei Popov eine entscheidende Rolle bei der Gründung des Projekts gespielt hat. Mit dieser nun offiziell verkündeten Partnerschaft hoffen wir, die umfangreiche Erfahrung, die Cartesi im Bereich der Smart Contracts hat, weiter zu nutzen und gemeinsam an der Beschleunigung der Entwicklung des IOTA Smart Contract Protokolls zu arbeiten. Letztendlich ist es unser Ziel, die Cartesi VM in das ISCP zu integrieren, um Entwicklern die Möglichkeit zu geben, Linux und die unzähligen Softwarekomponenten, die von diesem unterstützt werden, zu nutzen. Dies wird IOTA und Cartesi eine Reihe leistungsstarker Mainstream-Tools für Entwickler und Ingenieure bieten, die mit der traditionellen Softwareindustrie vertraut sind.

In den kommenden Monaten wollen wir zwei Schlüsselbereiche ausbauen, die für beide Unternehmen und unser Ökosystem wertvoll sind:

• Die Cartesi Linux Virtual Machine wird als benutzerdefinierte VM für IOTA Smart Contracts (ISCP) hinzugefügt. Das wird es Entwicklern ermöglichen, Smart Contracts mit Mainstream-Softwarekomponenten zu erstellen. Mit größerer Ausdruckskraft und einer Umgebung, die den meisten Entwicklern auf der Welt vertraut ist, ergeben sich neue leistungsstarke Möglichkeiten für DeFi, Gaming, NFT und mehr. Die Cartesi Linux Virtual Machine wird auch ein mächtiges Werkzeug für die Einführung in Firmen und Unternehmen für beide Communitys sein.

• IOTA Oracles: Durch die Integration von IOTA Oracles in Cartesi werden Unternehmensserver und intelligente Geräte in der Lage sein, die Integrität und Provenienz von Daten zu prüfen und verifizierbare Batch-Verarbeitungen durchzuführen. Das wird industriellen Systemen, die Cartesis Blockchain-Technologie und Linux Virtual Machine nutzen, noch mehr Transparenz und Sicherheit verleihen.

Diese Ankündigung stellt eine Fortsetzung unseres Engagements dar, Brücken mit gleichgesinnten Organisationen zu bauen, von denen wir glauben, dass sie zur Vorwärtsbewegung der Industrie beitragen.  Wir hoffen, dass unsere Communities zusammenkommen, um Innovationen zu entwickeln und spannende Tools zu erstellen, die den globalen Fußabdruck dezentraler Technologien erweitern.

Erick de Moura, CEO bei Cartesi: “Cartesi war geehrt, seine allererste Investition von Serguei Popov zu erhalten, der unser technischer Berater und auch Co-Autor und Freund von Augusto Teixeira ist. Von den ersten Tagen an haben Cartesi und die IOTA Foundation Gedanken ausgetauscht und die besten Möglichkeiten der Zusammenarbeit ausgelotet. Nach mehreren technischen Meetings in den letzten Jahren sehen wir einen Integrationsweg, der enorme Möglichkeiten für DeFi, Gaming, NFT und industrielles IoT mit sich bringen wird.”

Dominik Schiener, Mitbegründer der IOTA Foundation: “Das Wertversprechen von IOTA war schon immer, außerhalb der traditionellen Welt der Blockchain zu wachsen. Seit der Gründung des Projekts haben wir nach Partnern und Gleichgesinnten gesucht, die dieselbe Vision für Distributed-Ledger-Technologie und dezentrale Anwendungen teilen. In diesem Sinne freuen wir uns, unsere Partnerschaft mit Cartesi bekannt zu geben, einem der führenden Unternehmen, das die Kluft zwischen Blockchain und der traditionellen Welt überbrückt. Wir freuen uns darauf, Cartesis VM auf ISCP sowie IOTA Oracles einem weiteren beliebten Blockchain-Ökosystem zur Verfügung zu stellen.”

Über Cartesi

Cartesi bringt Smart Contracts auf die nächste Stufe. Es ist eine chain-agnostic 2-Layer Infrastruktur, die das drängende Problem der Skalierbarkeit auf den wichtigsten Blockchains löst. Vor allem implementiert Cartesi eine einzigartige Linux-unterstützende VM, Rollups und Side-Chains, um die Art und Weise zu revolutionieren, wie Entwickler Blockchain-Anwendungen erstellen, indem sie Mainstream-Softwarekomponenten verwenden können.

Quellen

https://blog.iota.org/cartesi-and-iota-partner-to-accelerate-smar-contract-adoption/

Whitepaper – IOTA Smart Contracts

10. Nov’21

Autor Evaldas Drąsutis IOTA Foundation (evaldas@iota.org).

Das hier verlinkte Dokument stellt IOTA Smart Contracts vor, eine Distributed-Ledger-Technologie (DLT) und ein Multi-Blockchain-Smart-Contract-Framework mit der Fähigkeit, Transaktionen auf vertrauenswürdige und skalierbare Weise auf dem IOTA UTXO-Ledger (1-Layer) durchzuführen. Das Hauptziel ist es, die Überlegungen hinter dem Konzept und die architektonischen Elemente zu präsentieren.

Der Stil des Whitepapers ist informell.

Smart Contracts Beta Release

21. Okt’21

Übersetzung des IOTA Blogartikel.

Die Beta-Version der programmierbaren Smart Contracts ist jetzt im IOTA 2.0 DevNet verfügbar

TL;DR:

Mit der Beta-Version von IOTA Smart Contracts bietet IOTA programmierbare Smart Contracts im IOTA 2.0 DevNet an, einschließlich früher Unterstützung für die Ethereum Virtual Machine (EVM) und Smart Contracts, die in Solidity, Go (TinyGo) und Rust geschrieben sind. Wir arbeiten derzeit an einer erweiterten EVM-Unterstützung, weiteren Optimierungen und der Portierung von Smart Contracts auf das IOTA Mainnet. Zusammen mit der Integration des Tokenization-Frameworks wird es eine leistungsstarke Lösung für nahtlose, vertrauenswürdige und gebührenfreie Interoperabilität und Kompatibilität zwischen Smart Contracts auf IOTA bieten. Folgen Sie den Anweisungen unten und lassen Sie uns BUIDL!

Mit der Beta-Version von IOTA Smart Contracts macht die IOTA Foundation einen großen Schritt nach vorne, um IOTA eine neue Ebene der Nutzbarkeit hinzuzufügen, indem sie unbegrenzte Möglichkeiten bietet, dezentralisierte Anwendungen (dApps) und andere Web3-Innovationen zu erstellen. Unsere Ziele mit IOTA Smart Contracts sind es, einige der Nachteile bestehender Lösungen (Gebühren, Skalierbarkeit, Interoperabilität und begrenzte Kompositionsmöglichkeiten) zu beheben und ein Ökosystem mit neuen Möglichkeiten für Entwickler und Early Adopters zu schaffen, um direkt vom explosiven Wachstum unserer Branche zu profitieren, während wir in den Mainstream starten.

In dem Bemühen um Interoperabilität und Benutzerfreundlichkeit unterstützt IOTA Smart Contracts jetzt die Ethereum Virtual Machine (EVM) und jeden in Solidity geschriebenen Smart Contract. Obwohl es sich hierbei um eine frühe Implementierung handelt, bietet sie bereits umfassende Kompatibilität und verbindet das größte Smart-Contract-Ökosystem mit dem gebührenfreien IOTA-Base-Layer. Das bedeutet, dass Solidity-Contracts einfach auf IOTA portiert werden können, wodurch die Implementierungszeit verkürzt wird und man von dem großen Ökosystem an Solidity-Tools und -Produkten, die heute auf dem Markt verfügbar sind, profitiert. Dies beinhaltet bereits vollen Zugang zur MetaMask-Wallet.

Smart Contract Chains können eingesetzt werden, ohne um Erlaubnis zu fragen, ohne Auktionen (Bieter-krieg) und ohne zusätzliche Kosten oder Schwierigkeiten. Die Gebühren für die Ausführung von Smart Contracts können von den Eigentümern der Chain festgelegt werden, was unserer Meinung nach dazu führen wird, dass mehrere Chains miteinander um Arbeit (Aufträge) konkurrieren, was wiederum zu den niedrigstmöglichen Gebühren für die Ausführung eines Smart Contracts über alle verfügbaren Optionen im Kryptobereich führen wird. In der Tat haben die Entwickler von Smart-Contract-Chains die volle Flexibilität, ihre Chain und Tokenomics zu entwickeln. In Zukunft könnten sie sogar die Transaktionsgebühren auf Null setzen und stattdessen Validierer mit ihren eigenen Token belohnen, wodurch sie ihre eigene Wirtschaft schaffen und die Eintrittsbarrieren für ihre dApp massiv senken.

Darüber hinaus wurde mit der Arbeit an der vollständigen Interoperabilität von tokenisierten Assets auf dem IOTA Base-Layer begonnen, die in Smart Contract Chains übertragen und verwendet werden können. Dies wird die Möglichkeit bieten, Assets zwischen verschiedenen Smart-Contract-Chains ohne zusätzliche Kosten, völlig vertrauenswürdig und ohne Transaktionsgebühren zu übertragen, dank des gebührenfreien IOTA Base-Layers, der als vertrauenswürdige Atomic-Bridge fungiert. Wir glauben, dass allein diese spezielle Funktion einen beispiellosen Nutzen für NFT-Marktplätze und Entwickler im Bereich dezentraler Finanzen (DeFi) und dezentraler Börsen (DEX) schaffen wird.

Was macht IOTA Smart Contracts so spannend?

IOTA Smart Contracts wurde in erster Linie entwickelt, um die ständig wachsende Nachfrage unserer Branche nach neuen Innovationen zu befriedigen, die Eintrittsbarrieren zu senken und eine Umgebung zu schaffen, die Milliarden von Nutzern in unsere Netzwerke einbindet. Die technische Architektur von geshardeten (dt. gesplitteten) Smart-Contract-Chains in Kombination mit einem gebührenfreien und hoch skalierbaren DAG-Ledger bietet eine überzeugende Lösung, um den Marktanforderungen gerecht zu werden und einige der Probleme zu lösen, mit denen die heutigen Lösungen konfrontiert sind.

Da der IOTA Base-Layer heute weit über 1000 Transaktionen pro Sekunde (TPS) verarbeiten kann (und in Zukunft noch viel mehr), glauben wir, dass er der perfekte Vertrauensanker und gemeinsame Security-Layer für IOTA Smart Contracts ist. Dank der DAG-Architektur des Tangle sind wir in der Lage, Smart Contracts parallel auszuführen und horizontal zu skalieren: Durch einfaches Hinzufügen weiterer Smart-Contract-Chains wird sofort mehr Durchsatz freigesetzt. Diese Skalierbarkeit wird durch die Nutzung von IOTA als vertrauenswürdige, gebührenfreie Asset-Bridge ermöglicht, wobei die Kompatibilität und Interoperabilität aller Smart Contracts erhalten bleibt.

Die flexible Entwicklungsumgebung ermöglicht es Smart-Contract-Entwicklern, ihre eigenen Smart-Contract-Chains zu definieren, ihre bevorzugte Smart-Contract-Sprache zu verwenden und die richtigen Anreize für Nutzer und Validierer gleichermaßen zu definieren. All dies dient dazu, den Entwicklern das richtige Ökosystem zur Verfügung zu stellen, um eine breite Akzeptanz zu erreichen und die großen Eintrittsbarrieren zu beseitigen, mit denen wir heute konfrontiert sind.

Die Highlights von IOTA Smart Contracts sind:

• Native Assets (1-Layer Tokens) für vertrauenswürdige, Atomic- und gebührenfreie Asset-Bridges. Volle Interoperabilität zwischen allen Smart Contracts. Dies bringt das Lego-Blöcke-Konzept von DeFi auf das nächste Level, wobei alle Smart Contracts vollständig kombinierbar sind.
• Flexible Entwicklungsumgebung zur Erstellung Ihrer dApps, die auf Ihre Bedürfnisse zugeschnitten sind. IOTA Smart Contracts ermöglichen es Ihnen, Ihre bevorzugte Sprache, Smart Contract Virtual Machine, selbst definierte Gebühren für Nutzer, Anreize für Validierer und Komiteestrukturen zu verwenden. dApp-Anpassung und Kompositionsfähigkeit sind jetzt sogar auf der Basis-Netzwerkebene möglich.
• Skalierbarkeit durch Sharding und die passenden Anreize. IOTA Smart Contracts ist ein geshardetes Smart-Contract-Netzwerk, bei dem jede Smart-Contract-Chain durch ihre eigene Skalierbarkeit begrenzt ist und nicht durch den Rest des Netzwerks behindert wird. Das Spannende daran ist, dass jede Smart-Contract-Chain ihre eigenen Anreize und Gebühren definieren kann (möglicherweise sogar gebührenfrei), was neue Möglichkeiten für die Mainstream-Akzeptanz von dApps bietet.
• Vollständige Kompatibilität mit der Ethereum Virtual Machine (EVM), wodurch es möglich ist, Smart Contracts und Tools aus dem etablierten Ethereum-Ökosystem ohne jegliche Modifikationen oder Änderungen zu portieren. Es bietet auch eine großartige Möglichkeit für IOTA, zu einem späteren Zeitpunkt eine Brücke zu Ethereum zu schlagen.
• Entwicklung von Smart Contracts in Solidity, Rust und Go (TinyGo).

Das primäre Ziel der Beta-Version ist es, dem IOTA-Team zu helfen, unsere Lösung weiter zu verbessern und zu optimieren. Wir gehen davon aus, dass es noch Fehler und weitere Verbesserungen geben wird, bevor wir das endgültige Produkt veröffentlichen. Aber mit diesem Beta-Release ermutigen wir bereits jetzt den Erbauern, die Möglichkeiten von IOTA Smart Contracts zu nutzen. Mit dieser Version beginnen wir, Entwicklern die volle Bandbreite an Möglichkeiten zu eröffnen, dezentrale Anwendungen für NFTs, DeFi, Gaming (insbesondere Play-to-Earn) und das Metaverse zu erstellen.

Was ist neu?

Die im März dieses Jahres veröffentlichte Alpha-Version von IOTA Smart Contracts zeigte, wie Smart Contracts auf IOTA funktionieren. Es konnten mehrere Chains erzeugt werden, und ihr State (dt. Zustand) war im 1-Layer des IOTA Tangle verankert. Entwickler konnten mit dem Schreiben von Smart Contracts in einer Solotestumgebung beginnen, aber die Bereitstellung auf einer Chain war zu diesem Zeitpunkt nicht möglich. Dies gab uns zwar einen guten Überblick über die Architektur von IOTA Smart Contracts und wie Smart Contracts mit IOTA funktionieren werden, aber es erlaubte uns nicht, benutzerdefinierte Smart Contracts auf einem öffentlichen Netzwerk auszuführen. Das ändert sich mit dieser Betaversion.

In der Beta-Version wurden mehrere Schlüsselelemente verbessert und hinzugefügt, um die Beta-Version in eine Plattform zu verwandeln, die von interessierten Parteien genutzt werden kann, die Smart Contracts auf der Grundlage von IOTA entwickeln wollen.

​

Refaktorierung und Kompatibilität

• Der GoShimmer UTXO-Ledger, der im IOTA 2.0 DevNet verwendet wird, wurde um neue Funktionen erweitert, die IOTA Smart Contract Chains unterstützen, die Rotation von Validatoren ermöglichen und neue Aspekte der Abfrage von Smart Contracts und Tokenisierung einführen.
• Die gesamte Codebasis der Wasp-Nodes wurde überarbeitet und an die neueste GoShimmer-Version angepasst, wodurch sie vollständig mit dem IOTA 2.0 DevNet kompatibel ist. Jeder kann nun seine eigenen IOTA Smart Contract Chains betreiben, die im IOTA 2.0 DevNet oder einem privaten GoShimmer-basierten Netzwerk verankert sind.
• Neben diesem Refactor wurde der temporäre Konsensalgorithmus der Alpha-Version durch eine robustere, modifizierte Version des Honey Badger Konsensalgorithmus ersetzt. Wir haben auch Maßnahmen zur Verhinderung von Miner Extractable Value (MEV) in die Implementierung des Konsens integriert.
• Alle Teile der IOTA Smart Contracts wurden gründlich automatisiert getestet und überprüft, um die Zuverlässigkeit und Leistung zu verbessern.
• Der Datenbank-Layer, der von den IOTA Wasp-Nodes verwendet wird, wurde durch eine leistungsfähigere Implementierung auf Basis von RocksDB ersetzt.

​

Experimentelle Ethereum Virtual Machine (EVM)/Solidity-Unterstützung

Neben den bestehenden Rust- und Go-basierten WASM-Smart Contracts, die Anfang des Jahres eingeführt wurden, haben wir beschlossen, Unterstützung für die Ethereum Virtual Machine (EVM) hinzuzufügen. Dies ermöglicht es Entwicklern, Solidity-Smart Contracts innerhalb einer EVM-Chain zu schreiben, die im IOTA Tangle verankert ist. Das vorherrschende Smart-Contract-Ökosystem dreht sich hauptsächlich um EVM-basierte Lösungen, die eine Menge leicht verfügbares Entwickler-Know-how, Lernmaterial und Tools beinhalten. Dies machte EVM zu einer naheliegenden Auswahl für die Unterstützung einer ersten, zusätzlichen virtuellen Maschine. Unsere erste EVM-Implementierung (die wir noch als experimentell betrachten) ist vollständig kompatibel mit bestehenden Smart Contracts aus dem Ethereum-Ökosystem und wird hoffentlich die Einstiegshürde für die Entwicklung von Smart Contracts auf IOTA senken und die Integration in bestehende Ökosysteme auf anderen Chains erleichtern.

Diese experimentelle Unterstützung besteht aus einer vollständigen EVM-Integration, die mit bestehenden Toolsn wie MetaMask, Hardhat und Remix voll kompatibel ist. Als Nutzer können Sie eine EVM-Chain erstellen, einen vollständigen Vorrat des Ihnen zugewiesenen Haupt-Tokens dieser Chain anlegen und Contracts einsetzen, die miteinander interagieren können. Eine Interaktion mit IOTA-Tokens und -Daten des 1-Layer ist in dieser Version derzeit nicht möglich, aber eine Implementierung, die dies ermöglicht, ist für eine zukünftige Version von IOTA Smart Contracts geplant.

Erweiterte Unterstützung für Smart Contract Chains durch den UTXO-Ledger

Mit der IOTA Smart Contracts Beta-Version haben wir neue Funktionen in den UTXO-Ledger von GoShimmer implementiert. Das Ledger bietet nun ein neues und leistungsstarkes Maß an Unterstützung für IOTA Smart Contracts und andere Anwendungen, die auf Smart Contract Chains laufen. Er bietet Unterstützung für Adress-Aliasing, Chain-Beschränkung, Timelocks, Fallback-Optionen für On-Ledger-Anfragen und viele andere Funktionen.

Am wichtigsten ist, dass der neue UTXO-Ledger die Identität der Chain unabhängig von den Disributed Private-Keys unterstützt, die für den Betrieb der Chain benötigt werden. Das bedeutet, dass wir jetzt die Validatoren im Komitee völlig transparent für die Chain und ihre Operationen rotieren können.

Off-Ledger-Anfragen

Ebenfalls neu in dieser Version sind die Off-Ledger-Anfragen. Während es möglich ist, mit Smart Contracts durch reguläre IOTA-Transaktionen auf dem Base-Layer zu interagieren, ist dies nicht immer der effizienteste und schnellste Weg, dies zu tun. Das Warten auf die Weiterleitung und Bestätigung der Message dauert mehrere Sekunden, und die Nutzer sind durch den Durchsatz des IOTA-Ledgers begrenzt.

In der Zukunft sehen wir On-Ledger-Anfragen vor allem als Möglichkeit für vertrauenswürdige und Atomic Asset-Transfers zwischen Smart Contracts auf verschiedenen Chains und zwischen Benutzer-Wallets des Basis-Layers und On-Chain-Accounts.

Off-Ledger-Anfragen bieten eine Alternative zu Atomic On-Ledger-Transaktionen mit hohem Durchsatz, da sie eine direkte Interaktion mit Wasp-Nodes ermöglichen, ohne dass eine Transaktion auf dem Base-Layer durchgeführt werden muss. Indem Sie sich in die Chain einbringen und dort Token hinterlegen, können Sie sicher Anfragen an die Smart Contracts auf der Chain senden und diese Token gegebenenfalls für Gebühren verwenden, während Sie direkt mit den Smart Contracts auf ihren jeweiligen Chains interagieren. Dieser Ansatz reduziert die Abhängigkeit und Belastung des IOTA Base Layers, er verbessert erheblich den Durchsatz und die Zeit, die für die Ausführung einer Smart-Contract-Funktion benötigt wird. Die Off-Ledger-Anfragen umfassen auch einen Wiederholungsschutz.

Schema-Tool

Beim Schreiben von Smart Contracts müssen oft viele Standardformulare bereitgestellt werden. Es ist nicht nur mühsam, diese jedes Mal neu zu erstellen, wenn ein Smart Contract entwickelt wird, sondern es kann auch fehleranfällig und zeitaufwendig sein. Aus diesem Grund enthält die Beta-Version ein neues Tool, mit dem neue Go- (TinyGo) oder Rust-basierte Smart Contracts (kompiliert zu Wasm-Binärdateien) gebootstrapt werden können. Dieses Schema-Tool nimmt eine Schemabeschreibung als Eingabe (die definiert, welche Funktionalität man verwenden möchte) und erstellt den gesamten Boilerplate-Code und die Tests für die Implementierung, so dass sich der Entwickler auf das Schreiben des Codes konzentrieren kann, der für den Vertrag wichtig ist. Alle bestehenden Proof-of-Concept-Smart-Contracts in der Codebasis, die in Rust oder Go (TinyGo) geschrieben sind, wurden mit Hilfe des IOTA Smart Contracts Schema-Tools neu erstellt. Die IOTA Foundation wird es von nun an als Standard für alle neuen wasm-basierten Smart Contracts verwenden.

Das Schema-Tool wird in einer späteren Version um weitere Annehmlichkeiten (wie automatisch generierte Client-Bibliotheken) erweitert werden, mit dem Ziel, die Entwicklungsarbeit von einer lästigen Pflicht in ein Vergnügen zu verwandeln. Die Dokumentation für das IOTA Smart Contracts Schema Tool finden Sie hier.

Öffentliches Testnetz

Um die aktuelle Funktionalität von IOTA Smart Contracts zu testen, ist es möglich, eigene Validator-Nodes zu betreiben und eine separate Chain zu erstellen, die in einem GoShimmer-basierten Netzwerk verankert ist. Um das Testen zu vereinfachen, ohne dieses spezielle Setup durchlaufen zu müssen, haben wir ein öffentliches Testnetz geschaffen, das jeder nutzen kann. Dieses Netz besteht aus einem neuen GoShimmer-Netz und einem Komitee aus mehreren Wasp-Nodes. Um die Einstiegshürde für die Nutzung des Testnetzes so niedrig wie möglich zu halten, haben wir beschlossen, alle möglichen Gebühren auf Null zu setzen. Da wir davon ausgehen, dass diese Entscheidung die Chain recht schnell verunreinigen wird, werden wir bei Bedarf regelmäßige, außerplanmäßige Resets des Netzwerks durchführen.

Alle Details zum Anschluss an das öffentliche Testnetz finden Sie im Wiki.

Erneuerter Smart Contract Proof of Concept: Roulette

Um einige der Änderungen in dieser Version zu demonstrieren, haben wir uns entschlossen, das Fair Roulette Proof of Concept zu erneuern und es auf einer öffentlich zugänglichen Chain für jeden zum Testen bereitzustellen. Diese Demonstration ermöglicht es dem Benutzer, DevNet IOTA-Token einzuzahlen und mit ihnen an einem virtuellen Roulettetisch zu spielen. Dieses Konzept verwendet den in den IOTA Smart Contract eingebauten Distributed Random Number Generator (dRNG), um eine nachweisbare Zufallszahl zu generieren, die die Gewinnzahl bestimmt. Der Code für die Roulette-Demo ist im Wasp-Repository verfügbar und vollständig kompatibel mit dem neuen IOTA Smart Contracts Schema-Tool. Die Demonstration kann auch in unserem öffentlichen Testnetz mit einer grafischen Oberfläche auf demo.sc.iota.org ausprobiert werden. Viel Spaß damit!

Dokumentation

Während wir uns einem Stadium nutzbarer Smart Contracts nähern, ist eine gute Dokumentation extrem wichtig für jeden, der mit der Entwicklung von IOTA Smart Contracts beginnen möchte. Die Dokumentation wurde daher komplett neu geschrieben und konzentriert sich auf Entwickler, die IOTA Smart Contracts verwenden. Eine separate neue Version des IOTA Smart Contracts Architecture Dokuments beschreibt, wie IOTA Smart Contracts im Detail funktionieren. Die neue Dokumentation kann hier abgerufen werden.

Wie geht es weiter?

Nachdem nun alle Kernkomponenten zur Ausführung programmierbarer Smart Contracts in einen voll nutzbaren Zustand gebracht wurden, wird sich das IOTA Smart Contracts Team auf verschiedene Aufgaben für die nächsten Versionen konzentrieren. Diese Ergebnisse zielen hauptsächlich darauf ab, IOTA Smart Contracts in einer benutzerfreundlichen und robusten Weise in das IOTA Mainnet (auch bekannt als Chrysalis) zu bringen.

IOTA Mainnet (Chrysalis) Unterstützung

Die aktuelle IOTA Smart Contracts-Implementierung läuft auf der experimentellen nächsten Generation von IOTA 2.0, die auf dem vollständig dezentralisierten IOTA 2.0 DevNet eingesetzt wird, das von GoShimmer-Nodes betrieben wird. Da IOTA Smart Contracts auf dem IOTA Mainnet verfügbar sein sollten, bevor sie auf das vollständig dezentralisierte IOTA 2.0 Protokoll umgestellt werden (in einem Prozess, der als “Coordicide” bekannt ist), wird eine wichtige Aufgabe der nächsten Version die Unterstützung der Verankerung im aktuellen IOTA Mainnet sein. Das aktuelle IOTA-Mainnet und das vollständig dezentralisierte zukünftige IOTA 2.0-Protokoll haben einige grundlegende Unterschiede, die es schwierig machen, beide gleichzeitig zu unterstützen. Unser Hauptaugenmerk liegt daher von nun an auf der Unterstützung von Smart Contracts im aktuellen IOTA Mainnet unter Verwendung der Hornet Node Software.

Erweiterte EVM-Unterstützung

Die derzeitige experimentelle EVM-Implementierung kennt den IOTA Base-Layer überhaupt nicht. In der nächsten Version wird es möglich sein, IOTA-Token aus dem IOTA Base-Layer (L1) innerhalb von EVM-basierten Smart Contracts abzuheben und einzuzahlen. Dies wird die nahtlose Übertragung von Assets zwischen verschiedenen Smart-Contract-Chains und dem IOTA Base-Layer unterstützen, ohne dass eine spezielle Bridging-Lösung erforderlich ist. Diese Funktionalität wird die EVM-Integration nutzbringender machen und es skalierbaren, geshardeten Smart-Contract-Chains ermöglichen, miteinander zu kommunizieren und Assets nahtlos auszutauschen. Durch diesen Ansatz können herkömmliche Smart-Contract-Anwendungen/DeFi auf verschiedene Chains aufgeteilt werden, wodurch die hohen Gebühren für die Interaktion mit ihnen der Vergangenheit angehören.

Zusagen für den State (Zustand) der Chain.

Wir planen, einen speziellen Layer für den Zugriff auf den State zu implementieren, mit Commitments zum State der Chain und zu ihren einzelnen Partitionen mit Proofs of Inclusion.

Diese Funktionen werden IOTA Smart Contracts mit den Eigenschaften ausstatten, die für Chains mit hohem Durchsatz und hohem Volumen erforderlich sind, wie sie für dezentrale Finanzanwendungen (DeFi), unveränderliche Langzeitspeicherung von Daten und ähnliche Anwendungsfälle verwendet werden:

• Proofs of inclusion von Datenelementen in den Leger-state.
• Snapshots des Chain-state
• Selektives Pruning des Chain-state oder des Contracts durch den Smart Contract ohne Verlust der Konsistenz seines states.

Das Framework für die Tokenisierung

Während die bestehende Implementierung auf Basis von IOTA 2.0 bereits in einer frühen Version des IOTA-Tokenization-Frameworks digitale Assets unterstützt und nutzt, wird dies im aktuellen IOTA-Mainnet (Chrysalis) noch nicht unterstützt. Die entsprechenden RFCs werden derzeit definiert und für die Implementierung des Tokenization Frameworks sowohl auf dem zukünftigen IOTA 2.0 als auch auf dem aktuellen IOTA Mainnet (Chrysalis) verwendet. Das Tokenization Framework wird neben anderen Vorteilen die Erstellung von Token und NFTs als native Assets auf dem Base-Layer ermöglichen, die auch auf Smart-Contracts-Chains verwendet werden können, und IOTA in Kombination mit Smart Contracts einige einzigartige Funktionen bringen, die auf anderen bestehenden Plattformen noch nicht möglich sind. Wir glauben, dass die Fähigkeit, nahtlos zwischen dem Base-Layer und den darin verankerten Smart-Contract-Chains zu wechseln, einen noch nie dagewesenen Nutzen für NFTs und DeFi-Anwendungen bieten wird, insbesondere wenn man bedenkt, dass der Base-Layer von IOTA gebührenfrei ist.

Permissionless Chain-Validatoren

Während diese Version es jedem erlaubt, eine Chain mit einem eigenen Satz von handverlesenen Validatoren zu betreiben, ist das permissioned setup nicht für alle Anwendungsfälle geeignet. Traditionelle Smart Contracts und DeFi-Anwendungen gedeihen in permissionless Umgebungen und das ist derzeit nicht Teil dieser Beta-Version. Aber wir sind uns dieser Anforderung bewusst und arbeiten aktiv an einer Lösung, um auch diesen Markt zu bedienen. Wir werden in Kürze weitere Informationen zu diesem Thema bereitstellen.

– – –

Wir können es kaum erwarten, dass Sie unsere neue Beta-Version ausprobieren. Der beste Weg, um loszulegen, ist, den Schritten in unserer Dokumentation zu folgen, mit unserem Wiki zu beginnen oder das WASP GitHub Repository zu benutzen und Ihre ersten Smart Contracts zu implementieren. Lassen Sie uns wissen, was Sie denken, und zögern Sie nicht, sich bei Fragen in unseren Discord-Kanälen zu melden.

Quellen

https://blog.iota.org/iota-smart-contracts-beta-release/

IOTA Smart Contracts Protocol – Alpha Release

4. Mrz’21

Übersetzung des IOTA Blogartikel.

Die Veröffentlichung des IOTA Smart Contracts Protocol (ISCP) Alpha markiert einen wichtigen Meilenstein in der Entwicklung des ISCP. Das Ausmaß und die Art der Verbesserungen gegenüber der vorherigen “Pre-Alpha”-Version sind signifikant und wir fühlen uns nun mit dem aktuellen Stand sicher, die “Alpha-Version” zu veröffentlichen.

Die grundlegende und bemerkenswerteste Änderung des ISCP seit der “Pre-Alpha”-Version ist die Integration einer Multi-Chain-Umgebung, die durch den Tangle, den “Layer 1”, gesichert wird: Subnetze, bestehend aus Wasp-Nodes, die wir “Komitees” nennen, können viele Blockchains parallel darauf laufen lassen, ohne den Blick auf die Tangle Umgebung zu verlieren, der die digitalen Vermögenswerte von IOTA sichert. Jede dieser Chains, die ein funktionales Äquivalent zu einer Ethereum-Blockchain darstellen, ist in der Lage, viele Smart Contracts zu hosten.

Struktur eines Smart Contracts

Der Ansatz der IOTA Foundation für Smart Contracts ist eine Abkehr von bestehenden Architekturen und beseitigt deren Ineffizienzen, wie z.B. die Unfähigkeit zur parallelen und skalierbaren Ausführung, die Unfähigkeit, “fremde” Smart Contracts auf verschiedenen virtuellen Maschinen laufen zu lassen und die Beeinträchtigung durch volatile und manchmal unerschwingliche Gebühren, um nur ein paar zu nennen.

Mit dem IOTA Smart Contracts Protokoll steht es Entwicklern und Unternehmen frei, ihre eigenen, flexiblen Umgebungen zu definieren, die ihren Anforderungen entsprechen (Smart Contract Sprachen/virtuelle Maschinen) sowie Größen von Validierungskomitees, die ihrem erforderlichen oder gewünschten Grad an Dezentralisierung und Sicherheit entsprechen. Das IOTA Smart Contract Protocol erlaubt es ihnen, eine “permissioned” Smart-Contract-Chain zu betreiben, die z.B. von einem Komitee ihrer eigenen Nodes validiert wird oder ein Komitee von Nodes unter Konsortialpartnern zu definieren. ISCP ist auch mit der Absicht gebaut, vollständig “permissionless” zu laufen, was bedeutet, dass ein Komitee von Validierern auf einem offenen Markt von Validierern ausgewählt werden kann. Alle Smart Contract Chains – ob offen oder privat – profitieren von der inhärenten Sicherheit und Interoperabilität, die durch die Verankerung jedes Smart-Contract-Zustands und ihrer Ergebnisse auf dem gebührenfreien IOTA Basis-Layer entsteht.

IOTA Smart Contracts erfordern daher nicht, dass alle Nodes im Netzwerk alle Smart Contracts ausführen, sondern erlauben eine flexiblere, sinnvolle Definition, die den Anforderungen des Smart-Contract-Besitzers entspricht. Dies wird die Kosten und den Energieaufwand drastisch reduzieren, während die Flexibilität stark erhöht wird und keine Kompromisse bei den individuellen Sicherheitsanforderungen und der von dApps geforderten Kompatibilität und Interoperabilität eingegangen werden müssen.

Mehrere Chains im ISCP

Dies ist die erste größere Version, die es Entwicklern ermöglicht, die Flexibilität und Skalierbarkeit eines DAG-basierten Distributed Ledger für Smart Contracts zu nutzen. Während sich wahrscheinlich vieles ändern wird, wenn das Protokoll weiter reift, ist dies eine bedeutende Gelegenheit, kreative Anwendungen auf dem IOTA-Netzwerk darzustellen, wie z.B. native digitale Vermögenswerte, dezentrale Börsen (AMMs), NFT-Marktplätze, Liquiditätsplattformen und Smart Contracts, welche IOTA Oracles nutzen.

Der am meisten erwartete Aspekt der Alpha-Version ist, dass Entwickler nun IOTA-basierte Smart Contracts und dezentrale Anwendungen (dApps) erstellen können, Smart-Contract-Chains (die von Wasp-Nodes ausgeführt werden) bereitstellen und Smart Contracts auf diesen Chains ausführen können. Nach Abschluss der aktuellen Integration des “Mana”-Moduls in das Coordicide-Testnetz in seinem derzeitigen “Pollen”-Stadium werden IOTA-Smart Contracts über Wasp-Nodes bereitgestellt werden können. Die aktuelle Integration des “Mana”-Moduls in “Pollen” stellt einen wichtigen Baustein des Führerlosen-Konsens-Algorithmus des zukünftigen IOTA-Protokolls dar. Das ISCP-Team hat daher beschlossen, sich auf die Möglichkeit zu konzentrieren, Smart Contracts auf Wasp-Nodes bereitzustellen, bis die Integration des Mana-Moduls in den kommenden Wochen abgeschlossen ist.

Die Hauptkomponenten, aus denen die Alpha-Version besteht, sind:

• Unsere erste Spezifikation des Protokolls in Form des IOTA Smart Contract Protocol Architecture-Beschreibungsdokuments, das den aktuellen Stand und alle Elemente des ISCP der “Pre-Alpha”-Version und danach widerspiegelt.
• Die Wasp Node Version 0.1.1., die den aktuellen Stand des ISCP implementiert, einschließlich einer sicheren DKG (Distributed Key Generation) basierend auf dem Rabin-Genarro-Algorithmus.
• Eine frühe Version eines ISCP-Toolset, das es Entwicklern ermöglicht, Smart Contracts zu schreiben und zu kompilieren, sie in der Testumgebung einzusetzen und auszuführen, sowie einführende Tutorials enthält.
• Fast 400 Unit- und Integrationstests

Beachten Sie, dass die aktuelle Implementierung des ISCP auf Goshimmer-Nodes (der Pollen-Version, unserem aktuellen Coordicide-Testnetz) des Tangle basiert. Die Implementierung sollte als “experimentell” betrachtet werden: Aufgrund der laufenden Arbeiten und der Integration der verbleibenden Aspekte werden die Wasp-Nodes und andere ISCP-Software bis zur Produktionsfreigabe mit “Coordicide” (IOTA 2.0) erhebliche Verbesserungen und Änderungen erfahren.

Das mit ISCP Alpha veröffentlichte Entwicklungs-Toolset enthält:

• Eine Rust-Umgebung zum Schreiben von Smart Contracts und Kompilieren in die WebAssembly (Wasm) Binärdateien für den späteren Einsatz auf der Chain.
• Das “Cluster-Tool”, das es ermöglicht, isolierte Testnetze mit einem Goshimmer (mit Mocked-Token-Ledger) und vielen Wasp-Nodes zu betreiben, um Chains bereitzustellen, Smart Contracts zu implementieren, Front-Ends von dApps auszuführen, etc. sowie Integrationstests durchzuführen.
• Das “Solo-Tool”, ein mächtiges Werkzeug zum Schreiben von Unit-Tests für Smart Contracts und dApps.
• Das “Wasp-cli”, eine Kommandozeilenschnittstelle (CLI) (eine Wallet) für die Interaktion mit Wasp-Nodes, die Bereitstellung von Chains und Smart Contracts, das Arbeiten mit Token auf Adressen und On-Chain-Konten.
• Der “Wasp Explorer”, ein einfaches Dashboard, das es jedem ermöglicht eine Node-Konfiguration, implementierte Chains, Smart Contracts und On-Chain-Konten zu erforschen.
• APIs und eine API-Bibliothek für Front-End-Anwendungen

Rust-Smart-Contract-Programm – kompiliert zu Wasm

Zukünftige Pläne

Mit dem Alpha-Release nimmt das IOTA Smart Contract Protokoll endlich Gestalt an. Unser kurzfristiges Ziel für die nächsten Monate ist es, die Entwicklung von Goshimmer, dem Coordicide-Protokoll und dem Chrysalis-Mainnet-Upgrade voranzutreiben. Wir werden auch weitere Showcases und ein Demonstrationsnetz mit Smart Contracts und Colored Coins entwickeln. In der Tat haben wir bereits damit begonnen, dies zusammen mit der Community zu tun.

Über die unmittelbaren nächsten Schritte hinaus, stellen die folgenden Schritte unsere Hauptrichtungen für unsere weiteren Bemühungen dar:

Entwicklungsumgebung

Die nächste Stufe der Rust-Entwicklungsumgebung und -Werkzeuge, einschließlich einer plattformneutralen Datenschema-Definition und einer neuen funktionalen Sprache für die Programmierung von Smart Contracts: mit Verifizierbarkeitseigenschaften

Virtuelle Maschine (VM)

Erforschung der VM-agnostischen Natur der ISCP und Integration der Ethereum Virtual Machine (EVM) in die ISCP-Sandbox, die wir “Virtual Ethereum” nennen. Das Ziel ist eine binäre Kompatibilität mit dem Ethereum-Ökosystem, einschließlich der Möglichkeit, Tools und Smart-Contract-Sprachen wie Solidity auf dem IOTA-Netzwerk zu verwenden.

Brücken bauen

Ein Framework für Inter-Chain Atomic Swaps mit nativen und externen Blockchains, wie Ethereum sowie bekannte Decentralized Finance (DeFI) Anwendungsfälle wie AMM und DeX (wie Uniswap), On-Chain Tokenization basierend auf ERC-20, etc.

Kern-Algorithmen

Ein überarbeiteter und verbesserter Konsens-Algorithmus, der auf dem klassischen BFT (byzantine fault tolerance) basiert, um den proprietären zu ersetzen, der jetzt zu Testzwecken implementiert wurde, sowie Merkle-Proofs im Chain-State, um die Unabhängigkeit von Snapshots auf dem Base-Layer sicherzustellen.

Permissionless-Markt für Chain Validators

Layer 1 und Layer 2 Unterstützung für Staking und Komitee-Rotation, sowie Core-Contracts für die Marktinfrastruktur. Beachten Sie, dass an dieser Aufgabe noch aktiv geforscht wird und sie in zukünftigen Updates erweitert werden wird.

Ressourcen

• Dokument zur Beschreibung der Protokollarchitektur
• Wasp-Repository

Sehen Sie sich die Präsentation mit Evaldas Drąsutis, Hauptentwickler für ISCP, an: https://www.youtube.com/embed/T1CJFr6gz8I?wmode=transparent

Wir empfehlen allen, die Dokumentation zu überprüfen und selbst auszuprobieren. Teilen Sie Ihre Kommentare und Ihr Feedback zur # smartcontracts-Diskussion auf unserem Discord-Server mit! Es ist auch eine Gelegenheit, direkt mit Evaldas Drąsutis zu chatten.

Quellen

https://blog.iota.org/iota-smart-contracts-protocol-alpha-release/

IOTA Smart Contracts Pre-Alpha

02. Okt’20

Übersetzung des IOTA Blogartikel.

Eine Plattform für skalierbare, gebührenfreie und flexible Smart Contracts

In diesem Artikel stellen wir unsere hochmoderne Implementierung des IOTA Smart Contract Protocol (ISCP) vor, die erste skalierbare, gebührenfreie und flexible Implementierung von Smart Contracts IOTA-Netzwerk. In dieser Version stellen wir drei intelligente PoC-Verträge vor, die von der IOTA-Foundation entwickelt wurden, um die frühen Fähigkeiten der Plattform zu demonstrieren. Darüber hinaus stellen wir Entwicklern eine Reihe von Tools zur Verfügung, mit denen sie die Funktionalität unserer Smart Contracts erkunden können.

Wir führen IOTA Smart Contracts als technologische Entwicklung ein und konzentrieren uns daher auf die zugrunde liegenden technischen Konzepte, Architekturen und Eigenschaften.

Wir werden die Diskussion in zukünftigen Beiträgen erweitern, um spezifische Anwendungsfälle und das Marktpotenzial von intelligenten Verträgen und digitalen Assets darzustellen. Wir werden in den nächsten Monaten weiter an der erweiterten Funktionalität und Stabilität der Software arbeiten, damit sie für die Produktion und die Anforderungen des Marktes voll ausgereift ist.

Pre-Alpha heute verfügbar!

Ab heute steht die IOTA Smart Contracts Pre-Alpha zum Testen zur Verfügung! Mithilfe eines frühen Satzes von Bausteinen können Entwickler beginnen, die Funktionen des IOTA Smart Contracts-Protokolls zu erkunden, während wir die Funktionalität für eine vollständige Version in den kommenden Monaten weiter ausbauen.

Für diejenigen unter Ihnen, die gerade zu uns kommen, sind IOTA Smart Contracts eine flexible und unkomplizierte Implementierung von Smart Contract-Funktionen in einem verteilten, DAG-basierten UTXO-Ledger. Dazu werden Komitees eingerichtet, die Smart Contracts überprüfen und deren Konsistenz und Unveränderlichkeit im Distributed IOTA-Ledger gewährleisten.

Aufgrund ihres gebührenfreien und flexiblen Designs sind unsere Smart Contracts ideal für Unternehmensanwendungen und reale Anwendungsfälle von Unternehmen auf der ganzen Welt – ein großer Schritt vorwärts für unsere Branche. Wir glauben auch, dass das IOTA Smart Contracts Protocol die Grundlage für die Entwicklung eines reichhaltigen Ökosystems bildet, mit einer Vielzahl von Erweiterungen und Bausteinen, von denen wir erwarten, dass sie von der Community erstellt werden.

In dieser Version enthaltene Funktionen

In unserer ersten Hauptversion sind mehrere Komponenten enthalten:

• Wasp-Node-Software Version 0.0.1 (das frühe Alpha-Release) finden Sie hier das Repository. Die Wasp-Node führt ISCP im Netzwerk der Wasp-Nodes aus, ein Layer über dem Netzwerk der Goshimmer-Nodes. Wir stellen auch das Goshimmer-Node-Plugin WaspConn zur Verfügung, das es einem Wasp-Node erlaubt, sich mit dem experimentellen Pollen-Netzwerk der Goshimmer-Nodes zu verbinden und auf diesem zu laufen (siehe Wasp-Branch des Goshimmer-Repositoriums).
• Drei Demo dApps, PoC Smart Contracts namens TokenRegistry, FairAuction und DonateWithFeedback. Diese einfachen dApps enthalten intelligente Vertragsprogramme, die als Go-Module im Wasp-Node selbst fest codiert sind. Jeder PoC umfasst bereitgestellte Demo-Instanzen von Smart Contracts im Pollen-Netzwerk, ihre Web-Dashboards und Wallets.
• CLI-Wallet wwallet. Wie eine gewöhnliche IOTA-Wallet ermöglicht Ihnen die wwallet (die Wasp-Wallet) das Senden und Empfangen von Token im Pollen-Netzwerk. Darüber hinaus können Benutzer mit der Wallet auch Funktionen der PoC-Smart-Contracts anfordern. Mit wwallet können Sie z.B. digitale Assets prägen und gleichzeitig in derselben Transaktion in den TokenRegistry Smart-Contracts eintragen lassen. Sie können auch geprägte digitale Assets verkaufen, indem Sie eine Auktion im FairAuction Smart-Contract erstellen und andere zur Abgabe von Geboten in dieser Auktion von jedem Netzwerkteilnehmer einladen.

Außerdem bieten wir als Teil der Wallet ein einfaches Verwaltungstool, mit dem Sie Ihre eigenen Instanzen eines der drei PoC Smart-Contracts  mit Komitees von Wasp-Nodes und einen Webserver für PoC Smart-Contract -Dashboards bereitstellen können. In dieser Version stellen wir einen wichtigen Teil der ISCP noch nicht zur Verfügung: die Wasm VM (Virtual Machine) und die Rust-Programmierumgebung für Smart-Contrac.

Die Wasp-Node implementiert eine abstrakte VM-Sandbox-Schnittstelle, so dass jeder Interessierte sich damit vertraut machen und wenn er mutig genug ist, es sogar ausprobieren kann, indem er das Repository gabelt und seine eigenen hart codierten Smart-Contracts direkt in die Wasp schreibt!

Einige wichtige Funktionen der ISCP sind deaktiviert, z.B. die Belohnungsfunktion (optionale Nodegebühren, so dass der aktuelle Smart-Contract völlig gebührenfrei ist) und die Zugriffsnodefunktion (ein Zugriffsnode ist ein Wasp-Node, der einen gültigen Smart-Contrac-Ledger-Status enthält, aber nicht am Komitee des Smart-Contract teilnimmt).

Wasp-APIs haben noch keine Autorisierung implementiert, so dass in dieser Version jeder auf den Status jedes Smart-Contract zugreifen oder jede Wasp-Node als Komitee-Node für seinen Smart-Contract verwenden kann.

Die fehlenden Funktionen und Sicherheitslücken werden in späteren Versionen der Wasp-Node Schritt für Schritt ergänzt.

Verwendung von PoC Smart Contracts

Wir bieten Artikel im Wasp-Repository zu Github mit einer schrittweisen Einführung in die Hauptkonzepte von IOTA Smart Contracts am Beispiel von PoC Smart Contracts.

In diesen Artikeln werden drei PoC Smart-Contracts im Detail beschrieben:

• DonateWithFeedback implementiert einen einfachen Smart Contra, der Spenden und damit verbundene Kommentare für eine Website handhabt. Wir stellen die meisten Konzepte am Beispiel von DonateWithFeedback vor, da dies der einfachste aller 3 PoC-Smart Verträge ist.
• TokenRegistry ermöglicht es uns, Colored IOTA-Tokens zu prägen und ihnen gleichzeitig Metadaten in derselben Transaktion zuzuweisen. Die TokenRegistry führt das unveränderliche Register der Token und ihrer Metadaten, zusammen mit kryptographischen Beweisen für den Urheber der Lieferung und die Liefermenge.
• FairAuction implementiert einen einfachen automatisierten Marktplatz für IOTA-Colored Coins ein, die über eine Aktion zum Verkauf angeboten werden. Jeder kann seinen Token verkaufen und jeder kann mit seinem IOTAs auf den zu verkaufenden Token bieten, indem er Anfragen an die intelligente Vertragsinstanz sendet. Jede Auktion wird über den Smart Contract abgewickelt. Einmal gestartet, wird garantiert, dass sie fair und überprüfbar ist und bis zum Ende läuft.

Die Dashboards der Demo-Instanzen von PoC-Smart Contract  finden Sie hier.

Jede Seite des Dashboards enthält minimale Anweisungen zur Installation und Verwendung der wwallet.

Wir haben auch einige technische Anleitungen entwickelt, die durch einige der Funktionen dieser Version führen und Entwicklern helfen, mit dem Testen zu beginnen. Schauen Sie sich unser Demonstrationsvideo zum Proof of Concept an und beginnen Sie, unsere Plattform zu erkunden! https://www.youtube.com/embed/iOkI4UHOMqY?wmode=transparent

Nächste Schritte für IOTA Smart Contracts

Der nächste große Meilenstein für das Team, das mit IOTA Smart Contracts zusammenarbeitet, ist die Implementierung von Wasm VM und der entsprechenden Entwicklungsumgebung in Rust. Wir gehen davon aus, dass es Ende des Jahres verfügbar sein wird.

Darüber hinaus umfasst ein übergeordneter Plan für den künftigen Anwendungsbereich:

• Reifung der Kernprotokolle: Perfektionierung des Konsenses, Zugriff auf Nodefunktionen, Nodebelohnungen, Status-Snapshots, Verwaltung von Smart Contracts.
• Anpassung basierend auf den laufenden Entwicklungen des Goshimmer Value Tangle-Ledgers;
• Kernsicherheitsanpassungen: Vollständig verteiltes DKG (in dieser Version teilweise verteilt), digitales Identitätssystem für Nodes, Node-Besitzer und  Smart Contracts Eigentümer.
• Authentifizierung von API-Zugriff, Sicherheit, Client-Bibliotheken.
• Erweiterung der integrierten Smart Contract-Logik, dh automatische Rückgabe von Geldern im Fehlerfall, erweiterte Ausnahmebehandlung,
• Migration der integrierten Logik zu Wasm VM.
• Toolchain für die Verwaltung von Nodes und Smart Contracts (CLI-Tools, Dashboard, Backup / Recovery).
• Toolchain und Umgebung für die Entwicklung von übergeordneten Sprachmetaphern, die mehreren Sprachen zugeordnet sind.
• Framework für Client-Bibliotheken für dApp-APIs. Framework für Smart Contract Unit Tests und Tools.

Abschließend

Die heute veröffentlichte Pre-Alpha-Arbeit des IOTA Smart Contract Protocol ist der Höhepunkt monatelanger harter und engagierter Arbeit der IOTA Foundation. Wir betrachten diese Version als den ersten Schritt zur Schaffung eines großen, dynamischen Ökosystems dezentraler Anwendungen im IOTA-Netzwerk.

Wir laden unsere Mitglieder der Community ein, unsere Demo-PoCs auszuprobieren, die Dokumentation zu überprüfen und sogar zu versuchen, Ihre eigenen zu erstellen!

Wie immer heißen wir alle herzlich willkommen, auf Discord im Kanal #smartcontracts vorbeizuschauen, um mit unserem Team zu sprechen, das mit IOTA Smart Contracts zusammenarbeitet!

Folgen Sie uns auf Twitter, um die neuesten Nachrichten zu erhalten!

Quellen

https://blog.iota.org/iota-smart-contracts-pre-alpha-released-40efad27994b

10. Aug’21

Übersetzung des IOTA Blogpost.

TL;DR:

Nach der Beta-Veröffentlichung von IOTA Identity im Mai dieses Jahres hat sich das IOTA Identity-Team auf das letzte fehlende Teil des Release Candidate konzentriert: den Identity Actor. Nur wenige Menschen verstehen, was der Identity Actor ist und warum er so wichtig für das IOTA Identity Framework ist. Daher werden wir in diesem Blogpost erklären, warum der Identity Actor wichtig ist und wie er IOTA Identity für die Produktentwicklung vorbereitet.

Was ist der Identity Actor?

Angenommen, ein neuer Kunde möchte online ein Bankkonto eröffnen. Bevor er dies tun kann, muss seine Identität von der Bank durch ein Verfahren namens Know Your Customer (KYC) überprüft werden. Traditionell erfordert KYC, dass der Kunde die Bank entweder persönlich aufsucht und einen von der Regierung ausgestellten Ausweis vorlegt oder sich einem Online-Videoidentifikationsverfahren unterzieht. Da bei beiden Verfahren eine Person ihre Identität nachweisen muss, sind sie zeitaufwändig, kostspielig und fehleranfällig. Was aber, wenn der Kunde eine sichere Darstellung seiner Identität zur Verfügung stellt, die von der Bank automatisch überprüft werden kann? In diesem Szenario würde die Eröffnung eines Bankkontos nicht länger dauern als die Einrichtung eines neuen Kontos auf der bevorzugten Videostreaming-Website.

Um dies zu ermöglichen, benötigt der Kunde eine Wallet für seine Identität, wie z. B. Selv, die auf seinem Smartphone installiert ist. Selv verwaltet die IOTA-basierte Identität des Kunden und kann KYC-Informationen mit der Bank austauschen. Dazu müssen sowohl der Kunde als auch die Bank ihre dezentralen Identifikatoren (DIDs) teilen und das Eigentum an diesen Identitäten nachweisen. Sobald beide Seiten von der Identität des jeweils anderen überzeugt sind, fragt der Kunde die Bank, welche Informationen sie benötigt, bevor er die erforderlichen Daten an sie übermittelt. Das mag kompliziert klingen, aber der Kunde muss nur einen QR-Code scannen, um mit der Bank ins Gespräch zu kommen, und auf “Akzeptieren” klicken, um die entsprechenden Daten zu übermitteln. Der Rest der Vorgänge läuft im Hintergrund ab. Dies erfordert jedoch, dass die Selv-App und die Bank eine gemeinsame Sprache für die gemeinsame Nutzung von Identitäten, den Nachweis des Eigentums und die gemeinsame Nutzung von Daten verwenden. Diese gemeinsame Sprache wird derzeit von der Decentralized Identity Foundation (DIF) entwickelt und heißt DID Communications (DID Comm).

Selbst wenn beide Seiten dieselbe Sprache sprechen, müssen sie dennoch Software implementieren, die mit den ausgetauschten Informationen etwas Sinnvolles anfangen kann. Das ist die Aufgabe des Identity Actors. Der Identity Actor ist ein Programm, das Anfragen und Antworten im Zusammenhang mit Self-Sovereign Identity (SSI) und Datenmanagement senden und empfangen kann. Das bedeutet, dass die IOTA Foundation ein Programm entwickelt, das es versteht, mit anderen Identity Actors ” Identity zu sprechen”.

Um auf unser Beispiel zurückzukommen: Das Scannen des QR-Codes der Bank weist den Identity Actor in der Selv-App an, eine Kommunikation mit dem Identity Actor der Bank aufzubauen. Die Konversation beginnt in etwa so:

Der Name dieses Prozesses ist DID-Authentifizierung und er beweist die Kontrolle von Identitäten. Um zum Beispiel sicherzustellen, dass der Kunde die Kontrolle über die von ihm gesendete DID hat, sendet die Bank eine Anfrage an den Kunden. Der Kunde signiert diese Aufforderung mit seinem Private Key, und die Bank verifiziert die Signatur mit dem Public Key des Kunden, der auf dem Tangle gespeichert ist. Die wichtigste Eigenschaft der Challenge ist, dass sie für den Empfänger unvorhersehbar ist.

Um die KYC-Informationen mit der Bank zu teilen, wird die Konversation fortgesetzt:

In diesem Gespräch werden die KYC-Informationen ausgetauscht, die die Bank benötigt, um ein Konto für den Kunden zu eröffnen. Heute überprüft die Bank die Identität des Kunden anhand eines physischen Ausweises, weil sie der Regierung vertraut, die den Ausweis ausgestellt hat. In naher Zukunft könnte die Regierung einen überprüfbaren Ausweis ausstellen, der den Namen, die Adresse und das Geburtsdatum des Kunden bestätigt und vom Kunden auf seinem Gerät gespeichert wird. Der Kunde könnte seine Identität gegenüber der Bank auch digital nachweisen, wenn die Bank der staatlichen Behörde, die den Ausweis ausgestellt hat, vertraut. Im Gegensatz zu Personalausweisen können Berechtigungsnachweise jedoch von jedem ausgestellt werden, und die Bank kann sich dafür entscheiden, mehreren Ausstellern zu vertrauen. Vielleicht ist der Kunde ein Student, der Anspruch auf ein kostenloses Konto hat: Um gegenüber der Bank digital nachzuweisen, dass er ein Student ist, müsste der Kunde einen von der Universität ausgestellten Ausweis besitzen, und die Bank müsste der DID der Universität vertrauen.

Die Bank würde über eine Liste von DIDs verfügen, denen sie als Aussteller dieser Berechtigungsnachweise vertraut: Vertrauenswürdige DIDs könnten auch andere Finanzdienstleister und staatliche Stellen sein. Im Rahmen der Interaktion wäre es auch möglich, die Bank zu bitten, ihre Datenanforderung digital zu signieren. Dies macht die Anfrage der Bank unanfechtbar, d. h. sie kann nicht bestreiten, Ihre Daten angefordert zu haben, da der Nutzer die digital signierte Message als Beweis hat. Wenn sich herausstellt, dass die Bank mehr Informationen angefordert hat, als gesetzlich vorgeschrieben sind, hat der Kunde nach der europäischen Datenschutz-Grundverordnung den Beweis, dass die Bank gegen das Datenschutzrecht verstoßen hat. Dies wird ein wichtiges Instrument zum Schutz gegen den Missbrauch der selbstverwalteten Identität sein.

Ein weiteres wichtiges Element sind die Hooks. Dies sind Punkte, an denen die Entwickler der Selv-App und der Bankensoftware dem Identity Actor eine zusätzliche Logik hinzufügen. Der Pre-Hook von Selv weist den Identity Actor an, auf die explizite Zustimmung des Benutzers zu warten, bevor er die angeforderten Daten weitergibt, z. B. durch Bestätigung der Aktion durch Drücken einer Schaltfläche oder Eingabe eines lokal festgelegten Passworts in die App. Das bedeutet, dass das Standardverhalten des Identity Actors von den Entwicklern der Selv-App nur sehr wenig angepasst werden muss. Ebenso müssen die Entwickler bei der Bank nur die Daten eingeben, die sie von ihren neuen Kunden und den DIDs benötigen, denen sie vertrauen, um diesen Anwendungsfall zu unterstützen. Die Einführung von IOTA-Identität wird so zu einem einfachen und effizienten Prozess.

Flexibilität und Interoperabilität

Wie im obigen Beispiel gezeigt, verstehen die Identitätsakteure die Sprache des jeweils anderen und wissen, wie sie automatisch auf bestimmte Anfragen reagieren können. Dies sorgt auch für eine natürliche Interoperabilität zwischen allen Anwendungen, die den Identity Actor verwenden. Der Bank ist es egal, ob Sie Selv oder eine andere SSI-Brieftasche verwenden, solange sie die gleiche Sprache sprechen. In ähnlicher Weise können Selv-Benutzer SSI-Funktionen bei anderen Banken oder in anderen Branchen, wie z.B. Webshops oder Ticketing-Services, nutzen, solange sie die gleiche Sprache sprechen. Dies führt zu einer starken Interoperabilität zwischen den Anwendungen und schafft ein Ökosystem, dem Benutzer und Anwendungen frei beitreten können. Der Identity Actor macht den Beitritt zu diesem Ökosystem sehr einfach. Jede Anwendung kann einen Identity Actor installieren und ausführen und ihre eigene Logik in die Konversationen zwischen den Identity Actors einbinden.

Der Identity Actor ist so konzipiert, dass er über alle Plattformen hinweg vollständige Funktionsparität und optimale Sicherheit bietet, unabhängig von der Rechenleistung oder den vorhandenen Sicherheitsmaßnahmen. Er kann Aufgaben an andere Identity Actors auslagern, die auf anderen Geräten laufen, um die Einschränkungen der aktuellen Umgebung zu umgehen. Sie könnten zum Beispiel einen Identitätsakteur auf Ihrem Desktop ausführen, der Ihre Identität sicher in Stronghold speichert, aber Sie möchten Ihre Identität im Internet verwenden. Der Browser hat keine Möglichkeit, Ihre Identität sicher zu speichern, so dass das Identity Actor-Modell die Auslagerung der Speicherung an den Desktop-Actor erlaubt. Lassen Sie uns das Beispiel der DID-Authentifizierung mit der neuen Konfiguration aktualisieren.

Die obige Konversation ist vereinfacht, da sie stark von der Einrichtung sicherer Verbindungen zwischen den verschiedenen Identitätsakteuren abhängt (die IOTA bietet, aber das ist eine andere Geschichte). Aber insgesamt zeigt es, wie die kryptographische Operation von der unsicheren Browserumgebung in die viel sicherere Desktopumgebung ausgelagert wird. Dies erhöht die Sicherheit, ermöglicht es aber auch restriktiven Umgebungen wie dem reinen Internet der Dinge, den vollen Umfang der Identität zu nutzen, indem die komplizierteren Aufgaben über eine sichere Identity-Actor-Kommunikation an andere Geräte mit mehr Rechenleistung ausgelagert werden.

Verwaltung der eigenen Identität und Daten

Kommen wir nun zum letzten, aber wahrscheinlich spannendsten Teil des Identity Actor: Die Daten. Der Identity Actor bietet die Möglichkeit, auf verschiedenen Plattformen und in verschiedenen Programmiersprachen auf standardisierte und interoperable Weise zu kommunizieren. Es könnte für Benutzer nützlich sein, einen Identity Actor in der Cloud oder auf einem physischen Gerät zu betreiben, das immer online ist und das sie kontrollieren, um immer einen erreichbaren Identity Actor zu haben. Nun könnten Sie den Zugriff auf Ihre Daten über Ihren Identity Actor ermöglichen. Dieser Identity Actor könnte dann überprüfbare Berechtigungsnachweise und andere persönliche Daten speichern, die nun mit einem Mausklick weitergegeben werden können. An diesem Punkt können Menschen nun einen personalisierten Datentresor und Server betreiben, um Sie in der digitalen Welt zu repräsentieren. Warum sollten Unternehmen Ihre Daten speichern, wenn sie von Ihnen die Erlaubnis erhalten könnten, Ihren persönlichen Identitätsvermittler aus der Ferne zu kontaktieren, um die Daten zu jeder Tageszeit abzurufen? Mit dieser Logik wären sie weitgehend davon befreit, persönlich identifizierbare Daten lokal zu speichern, und müssten somit keine GDPR-relevanten Daten lokal vorhalten.

Wenn man all dies zusammennimmt, schaffen wir einen Weg, um die Kontrolle über Ihre Daten auf eine Art und Weise zurückzugewinnen, die über die GDPR-Konformität hinausgeht. Sie werden in der Lage sein, alle Ihre Daten aus verschiedenen Quellen zu speichern und so die umfangreichste und vertrauenswürdigste Datensammlung über sich selbst zu erstellen, die verfügbar ist. Ihre Datensammlung wird vollständiger sein und daher als Datenquelle attraktiver als die Datenerfassung von Facebook und Google. Dies wird wahrscheinlich dazu führen, dass sich die Datennachfrage von dritten Datensammlern zu Ihnen als der besten Quelle verlagert. Dies wiederum gibt den Menschen die Möglichkeit, sicherzustellen, dass sie für die Weitergabe ihrer Daten angemessen belohnt werden, und zwar in Form von Mehrwert, Dienstleistungen oder anderen sinnvollen Belohnungen.

Darüber hinaus sprechen alle Anwendungen, die mit dem Identity Actor erstellt wurden, dieselbe Sprache und können diese Anfragen mit minimalen Entwicklungsanforderungen an Ihren Actor senden. Dadurch wird der persönliche Identitätsakteur für Anwendungsentwickler einfach zu kontaktieren und zu übernehmen sein.

– – –

Wir hoffen, dass diese kurze Einführung einen Eindruck davon vermittelt, was der Identity Actor ist und wie wir uns seine Verwendung in zukünftigen Produkten und Anwendungen vorstellen. Wenn Sie an weiteren Informationen über IOTA Identity interessiert sind, schauen Sie sich unser Repository an, in dem Sie die Entwicklung des Identity Actors verfolgen können, oder erkunden Sie unsere Selv-Demos. Treten Sie unserem Discord bei und finden Sie das Identity Team im #identity-discussion channel, oder treten Sie dem Identity X-team bei!

Quellen

https://blog.iota.org/the-iota-identity-actor-explained/

10. Mai’20

Übersetzung des IOTA Blogartikel.

Wir freuen uns, die Veröffentlichung der Beta-Version von IOTA Identity bekannt geben zu können. Dies markiert das Framework als “feature complete” auf dem Weg zu einer 1.0 Version. Es beinhaltet mehrere wichtige Meilensteine wie das Upgrade auf Chrysalis Phase 2, eine vereinfachte Higher-Level-API einschließlich Stronghold-Unterstützung und eine erste Implementierung der DID-Kommunikationsnachrichten, die auf dem Standard der Decentralized Identity Foundation (DIF) und der Arbeit von Hyperledger Aries basiert.

Dies baut auf der bestehenden Arbeit auf, die für die Alpha-Version gemacht wurde, in der wir die W3C-Standards für dezentrale Identifikatoren (DID) und verifizierbare Credentials implementiert haben. Wir haben diese Implementierung weiter verfeinert und unsere DID-Methode beim W3C eingereicht, um als eine der DID-Methoden-Spezifikationen gelistet zu werden.

IOTA Identity – Zusammenfassung

IOTA Identity ist ein Self Sovereign Identity (SSI) Framework, das es Menschen, Organisationen oder Maschinen ermöglicht, eine digitale Identität zu erstellen und die vollständige Kontrolle darüber zu haben – ohne die Erlaubnis eines Vermittlers oder einer zentralen Partei. Darüber hinaus gibt es die Kontrolle darüber, wie persönliche Daten geteilt und verwendet werden.

Social-Media-Plattformen wie Facebook und Linkedin zeigen uns jeden Tag, dass Online-Konten in hohem Maße auf von Nutzern bereitgestellte Inhalte angewiesen sind. Die auf diesen Plattformen bereitgestellten Informationen sind nicht vertrauenswürdig und können leicht gefälscht werden – das wollen wir mit unserer digitalen Identitätslösung verhindern.

An dieser Stelle kommen Verifiable Credentials (VCs) ins Spiel. Das sind digitale Aussagen über einen Identitätsaspekt wie “Name”, digital signiert von einer anderen Identität, die Autorität zu diesem Thema hat. Ein Beispiel: Mein Bachelor-Abschluss ist vertrauenswürdig, wenn eine Universität ihn unterschreibt, aber nicht so sehr, wenn er von Ihrer Mutter unterschrieben ist. Solche Aussagen machen Daten verlässlich und wertvoll. VCs ermöglichen es einer SSI-Lösung, nicht nur datenschutzfreundlicher zu sein, sondern auch mit Facebook- / LinkedIn-Profilen zu konkurrieren, da sie vertrauenswürdiger und genauer sind.

Wir wollen dieses Konzept noch einen Schritt weiterführen, indem wir es auf Geräte anwenden. Unzählige IoT-Geräte und Sensoren interagieren jeden Tag miteinander. Dadurch werden große Datenmengen generiert, aber bisher haben Programme nur selten Daten von Drittgeräten für die Entscheidungsfindung genutzt. Einer der Gründe dafür ist, dass die Herkunft der Daten und letztlich das Vertrauen in ein Gerät mit herkömmlicher Technologie nicht ausreichend bestimmt werden kann. IOTA Identity ermöglicht es IoT-Geräten, eigene Identitäten zu erstellen und verifizierbare Aussagen über sich selbst zu sammeln, wie z.B.:

• Der Hersteller des Geräts
• Die installierte Software und von wem
• Zertifikat der Kalibrierung
• Aussagen von anderen Identitäten, die die Daten verwendet und für korrekt befunden haben (Reviews)

Wir ermöglichen es IoT-Geräten, eine Reputation aufzubauen und vertrauenswürdig zu werden. Wir können dann die von den Geräten bereitgestellten Daten nutzen, um Entscheidungen zu treffen. Denken Sie an den Verkehrsfluss in einer Stadt:

Im Moment vertraut eine Stadt nur den Sensoren, die sie selbst aufgestellt hat, um den Verkehrsfluss zu bestimmen. Stellen Sie sich vor, wie viel mehr Informationen und damit eine höhere Präzision erreicht werden könnten, wenn die Autos sich selbst identifizieren und ihre generierten Daten teilen könnten. Dies wäre der Grundstein für eine vertrauenswürdige Datenwirtschaft, die durch IOTA Identity ermöglicht wird. Ohne eine Architektur, die die Schaffung von Vertrauen ermöglicht, könnte jeder Verkehrsdaten fälschen und in einem automatisierten Verkehrssystem, das sich auf externe Daten verlässt, Schaden anrichten. Vertrauenswürdige Identitäten sind daher die Grundlage für die Nutzung jeglicher Daten, die erzeugt werden. Jedes digitale System profitiert von Vertrauen, nicht nur Verkehrssysteme wie im obigen Beispiel.

Identitätskonto

Das erste große Feature, das wir mit dieser Beta-Version eingeführt haben, ist der Account, eine übergeordnete API zur Nutzung von IOTA Identity. Ähnlich wie beim letzten Chrysalis-Update wird die Nutzung von IOTA Identity durch die Verwendung des Accounts wesentlich einfacher. Es soll eine viel einfachere Schnittstelle bieten, die für 90%+ der Anwendungsfälle perfekt ist. Die anderen 10% sind komplexere Anwendungsfälle, die vielleicht immer noch die APIs auf niedrigerer Ebene nutzen wollen, um mehr Kontrolle über die Identitäten zu haben. Das Konto vereinfacht nicht nur die Interaktion mit DID-Dokumenten, sondern auch mit dem Tangle und Stronghold.

Identitätsnachrichten auf dem Tangle sind ziemlich kompliziert. Wir haben zwei Formate, um die DID-Auflösungszeiten zu optimieren, und sie müssen auf eine bestimmte Weise erstellt und verwendet werden. Beim Konto kümmert sich eine einzige Codezeile um die gesamte Nachrichtenformatierung und Veröffentlichung auf dem Tangle. Auch das Erstellen einer Identität ist ein recht komplizierter Prozess, da zunächst ein key-paar generiert werden muss, aus dem dann eine DID abgeleitet wird. Danach wird ein DID-Dokument erstellt, in das der public key eingebettet werden muss, und dieses muss auf dem Tangle veröffentlicht werden. Zum Schluss muss der private key sicher gespeichert und verwaltet werden. Das Konto erledigt all dies in einer einzigen Codezeile und speichert den private key in einem Stronghold oder einer anderen vom Entwickler definierten Speichermethode.

Derzeit ist das Account-Feature nur in Rust und noch nicht als Javascript-Bindung verfügbar, da dies einige größere Designverbesserungen im Projekt erfordert, die wir auf unserem Weg zu einer 1.0-Version in Angriff nehmen wollen.

DID-Kommunikation

Die andere wichtige Funktion, die wir implementiert haben, sind die DID-Kommunikationsnachrichten. Dies sind standardisierte Nachrichten, die zwei IOTA-Identitätsakteure einander senden, um irgendetwas in Bezug auf die Identität zu tun. Zum Beispiel können sie sich gegenseitig auffordern, die Kontrolle über ihre Identitäten zu beweisen, aber auch verifizierbare Credentials anzufordern, die sie teilen oder sogar signieren können. Die Verwendung dieser Nachrichten macht es nicht nur einfacher, IOTA Identity betriebene Anwendungen zu erstellen, sondern schafft auch unmittelbare Interoperabilität zwischen Anwendungen. So könnte eine IOTA-Identity-App eines Unternehmens mit einer App eines anderen Unternehmens interagieren.

Bisher haben wir unsere Version des genauen Nachrichtenlayouts definiert und ein grundlegendes Beispiel für die automatische Generierung und Beantwortung von DID Communications-Nachrichten in Rust erstellt. Das Konzept wird wiederholt und Javascript-Bindungen werden vor der Version 1.0 hinzugefügt.

Nächste Schritte

Wie bereits erwähnt, wird IOTA Identity weiter verfeinert und für ein 1.0-Release verbessert, wobei der Fokus auf Performance, Code-Qualität, Dokumentation und Javascript-Unterstützung liegt. Das kommende 1.0 Release wird einen sehr wichtigen Meilenstein für IOTA Identity markieren, da wir die Abwärtskompatibilität und den Versionswechsel von IOTA Identity in Zukunft unterstützen werden.

Während unsere Version 1.0 der nächste große Meilenstein ist, endet die Reise für IOTA Identity dort nicht. Wir haben viele Ideen für zusätzliche Funktionen für zukünftige Updates wie Datenschutzverbesserungen, Identitätsagenten, bieten aber auch mehr anwendungsfallspezifische Bibliotheken, damit IOTA Identity in den vielversprechenderen Anwendungsfällen einfach übernommen werden kann. In der Tat freuen wir uns sehr, bald mit der LINKS Foundation zusammenzuarbeiten, die eine Zero Knowledge Proof (ZKP) Spezifikation für IOTA Identity erstellt und damit die Datenschutzfunktionen von IOTA Identity massiv erhöht. Sie sind erfahrene Cybersecurity-Forscher, die eine Spezifikation erstellen werden, die auf etablierten wissenschaftlichen Literaturergebnissen basiert.

Während IOTA Identity noch nicht allgemein bekannt ist, nähern wir uns mit der Beta-Version einigen der populären SSI-Frameworks an und überholen sogar in Qualität und Funktionsumfang. Wir werden uns weiterhin darauf konzentrieren, ein erstaunliches Framework zu entwickeln, das sicher, performant aber auch einfach zu bedienen ist. Wenn Sie daran interessiert sind, mit IOTA Identity zu arbeiten, schauen Sie sich bitte unser Repository an und erwägen Sie, dem IOTA Identity X-Team beizutreten, wo sich gleichgesinnte Entwickler, Unternehmer und Studenten wöchentlich mit den IOTA Identity-Entwicklern treffen, um das Framework in einer entspannten und dennoch lehrreichen Atmosphäre zu diskutieren.

Um das Alpha-Release zu erreichen, wurde die IOTA Foundation durch eine vom EDF finanzierte Gruppe von Entwicklern unterstützt: Thoralf, Sebastian (huhn) und Tensor. Dieses Mal müssen wir Filancore, einem Startup aus der IOTA-Community, für ihre Unterstützung danken, die das Beta-Release ermöglicht hat. Während wir es wirklich genießen, mit Community-Mitgliedern zusammenzuarbeiten, freuen wir uns auch, das Team deutlich zu vergrößern, um das IOTA Identity-Framework, Entwickler-Tooling, Bindungen zu anderen Sprachen und Proof-of-Concepts mit eigener Manpower weiterzuentwickeln.

Vollständiges Changelog

Dies ist ein unvollständiges Changelog für die Änderungen zwischen Version 0.2 alpha und 0.3 beta.

Wesentliche Merkmale

• Account implementiert (#151)
• Implementierung von DID-Kommunikationsnachrichten und -umschlägen (#226)
• IOTA-Code so geändert, dass er nur in Chrysalis Phase 2-Netzwerken funktioniert (#161)
• Typen und Dateien umbenannt, um die Verwirrung zwischen agnostischer DID-Implementierung und did:ι  Implementierung. Beigetragen von m-renaud! (#219, #233, #237, #243)
• Libjose-Implementierung hinzugefügt (#176)

Dokumentation / Spezifikation

• DID-Methoden-Spezifikation für die did:ι  Methode hinzugefügt und beim W3C eingereicht (#207)
• Spezifikation für DID-Kommunikation hinzugefügt (#178, #186, #187, #202, #203)
• Viele Verbesserungen der Dokumentation (#174, #164, #171)

Kleinere Änderungen

• Geänderte kryptographische Suiten, um mit Stronghold zu arbeiten (#158)
• Verifiable Credential mit Credential-Typ zusammengeführt, um den Code zu vereinfachen (#170)
• Verifiable Presentation mit dem Presentation-Typ zusammengeführt, um den Code zu vereinfachen (#170)
• Ersetzt imμtab ≤  Eigenschaft aus DID-Dokument mit DID-URL-Abfrageparameter (#141)
• Service-Endpunkte besser zugänglich gemacht (#194)
• Benchmarking-Tests hinzugefügt (#223)
• Verbesserte Beispiele (#171, #251)

Quellen

https://blog.iota.org/iota-identity-beta-release/