Dev Status Update – September 2021

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

Chrysalis

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

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

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

IOTA 2.0 Devnet

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

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

Bee

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

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

Hornet

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

Smart Contracts

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

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

Stronghold

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

Wallet

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

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

IOTA-Identität

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

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

Identity Resolver

Chronicle

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

IOTA-Experiance Team

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

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

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

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

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

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

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

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

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

Medium:

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

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

IOTA Wiki

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

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

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

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

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

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

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

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

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

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

IOTA Gemeinschaft Github

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

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

Firefly Beta Veröffentlichung

Wir sind stolz, die erste öffentliche Beta-Version von Firefly, unserer neuen Wallet für Chrysalis, zu veröffentlichen. Dies markiert einen wichtigen Meilenstein im Vorfeld von Chrysalis – dem größten Netzwerk-Upgrade in der Geschichte der IOTA Foundation – und gibt der Community einen ersten Vorgeschmack darauf, was die Zukunft von IOTA zu bieten hat. Die Chrysalis-Migration wird am 21. April 2021 beginnen und das Netzwerk wird am 28. April 2021 live gehen. Eine produktionsreife Version von Firefly wird für die Chrysalis-Migration freigegeben. Die Migration ist noch nicht möglich!

Die heutige Firefly Beta-Version zeigt das neue Chrysalis-Netzwerk in unserem öffentlichen Testnetz. Das bedeutet extrem zuverlässige Transaktionen, sehr schnelle Bestätigungen, wiederverwendbare Adressen, UTXO-basierter Ledger-Status und mehr. Wir heißen Sie herzlich willkommen, die Wallet auszuprobieren und das neue Chrysalis-Protokoll zu genießen.

Firefly herunterladen

Die Beta-Version von Firefly steht zum Download für Mac, Windows und Linux zur Verfügung. Sehen Sie sich die Veröffentlichung hier an.

Sie können Token über den Testnet-Faucet erhalten. Kopieren Sie einfach eine Adresse von Firefly und drücken Sie „anfordern“.

Heute stellen wir auch die Firefly-Codebasis zur Verfügung. Wir werden die Angelegenheiten und Diskussionsforen nutzen, also egal ob Sie ein Designer, Entwickler oder einfach ein interessierter Benutzer sind, fühlen Sie sich frei, sich zu beteiligen.

Eine robuste Wallet, die für die Zukunft gebaut wurde

Firefly hat viele Design-Iterationen durchlaufen und wir sind zu einem Ergebnis gekommen, von dem wir denken, dass es eine ausgezeichnete Balance zwischen minimalistischem Design und Benutzerfreundlichkeit ist. Jede Funktion wurde sorgfältig durchdacht, um die Reibungsverluste für Anfänger zu reduzieren und gleichzeitig auch fortgeschrittenen Benutzern gerecht zu werden. Jede Ansicht wurde mit Blick auf zukünftige Erweiterungen entworfen. Diese erste Version von Firefly ist eine sehr solide Wallet, die für die Langstrecke entwickelt wurde. Wir sehen Firefly Wallet als das Tor zum IOTA-Ökosystem und wir haben große Pläne für die Zukunft.

IOTA Stronghold download

Das Herzstück von Firefly sind zwei wichtige Open-Source-Rust-Bibliotheken. Stronghold, das letzte Woche in die Beta-Phase ging, ist eine bedeutende Innovation für die IOTA Foundation und die erste Open-Source-Bibliothek ihrer Art in unserer Branche. Stronghold hat zwei Schlüsselfunktionen für Firefly. Erstens dient es als isolierte Speicher-Enklave für kryptographische Operationen. Das bedeutet, dass immer dann, wenn die Wallet eine Adresse generiert oder eine Transaktion signiert, der Prozess isoliert vom Rest der Anwendung ausgeführt wird. Diese wichtige Sicherheitsbarriere ermöglicht es Firefly, all die spannenden Funktionen hinzuzufügen, die für die Zukunft geplant sind und die sich darauf verlassen können, dass kryptografische Operationen von Stronghold ausgeführt werden, ohne dass der private Schlüssel offengelegt wird. Zweitens bietet Stronghold einen verschlüsselten Key-Value-Store für die Sicherung Ihrer Wallet-Geheimnisse und Transaktionshistorie. Stronghold-Backups können verwendet werden, um Ihr Profil auf anderen Geräten zu importieren.

Die andere wichtige Bibliothek ist wallet.rs, die sich um die gesamte Transaktionslogik und Buchhaltung kümmert. Dieser modulare, in Rust geschriebene Kern sorgt zusammen mit dem leichtgewichtigen Svelte-Frontend für eine hoch performante und skalierbare Anwendung. Firefly wurde außerdem umfassend von einer externen Wirtschaftsprüfungsgesellschaft geprüft und wird weiteren Audits unterzogen, wenn neue Funktionen hinzugefügt werden.

download stronghold wallet

Wie geht es weiter?

Firefly befindet sich seit ein paar Wochen in der geschlossenen Testphase und ist nun in einem weitgehend stabilen Zustand. In den kommenden Wochen – im Vorfeld der Chrysalis-Migration – werden wir alle verbleibenden Fehler beheben, die Migration in einer geschlossenen Gruppe testen, die Ledger Nano-Integration testen und alle kleineren Funktionen hinzufügen, die es nicht in diese erste Beta-Version geschafft haben.

Sobald Chrysalis live geht, wird sich die Aufmerksamkeit des Teams auf die Entwicklung der mobilen Version verlagern, während wir auch an Features wie Kontakten und Chat arbeiten und einige von IOTAs kommenden Features, wie Digital Assets, erkunden.

Firefly war eine große Teamleistung mit Beteiligung der gesamten IOTA Foundation. Das Firefly-Entwicklungsteam (Lucas Nogueira, Umair Sarfraz, Begoña Álvarez, Martyn Janes, Rajiv Shah und Charlie Varley) hat Tag und Nacht gearbeitet, um die App fertigzustellen, und die Design- und UX-Teams (Andrew Brough, Janis Vegis, Aleksa Krstic, Marcos Andrade, Igor Nilsen und Sabri Goldberg) haben sich wirklich selbst übertroffen.

Vielen Dank an die fantastische Gruppe von Alpha-Testern aus der IOTA-Community, die ihre Abende und Wochenenden der Fehlersuche, Verbesserungsvorschlägen und dem Testen von Funktionen gewidmet haben. Und ein riesiges Dankeschön an die Übersetzer, die über sich hinausgewachsen sind und sich jede Woche gegenseitig überboten haben, um ihre Übersetzungen fertigzustellen. Wir sind demütig von jedermanns Bereitschaft, seine Zeit für Firefly und das IOTA-Projekt einzusetzen. Vorwärts und aufwärts.

Original by IOTA Foundation: https://blog.iota.org/firefly-beta-release/

Firefly wird sich in der Öffentlichkeit entwickeln und das Team ist immer offen für Ihre Vorschläge und Ihr Feedback. Sie können sich an der Konversation in #firefly-discussion auf unserem offiziellen Discord beteiligen.

IOTA Stronghold: Beta Veröffentlichung

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 eine eigene Peer-to-Peer-Kommunikationsschicht zur Verfügung, so dass verschiedene Apps sicher mit dem hochmodernen Noise-Protokoll ü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 „Festung Boden“ getauft, nach der Festung in Nordschweden, die zum Schutz des Landes und des Transports der „Industriemünze“ – Eisenerz – während der Weltkriege in der ersten Hälfte des 20. Jahrhunderts errichtet wurde. Seine Nützlichkeit erwies sich als erwiesen und er wurde auch während des Kalten Krieges weiter verwendet. Wie die Beta-Version von Stronghold auch, war die Bodenfestung eine temporäre Lösung, die nur kurzlebig war und nach ihrer Dienstzeit abgebaut wurde. Trotzdem war die Bodenfestung fast hundert Jahre lang in Betrieb. 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 brauchen, 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:

Boden Festung iota wallet

Im Allgemeinen werden die meisten Leute nicht einmal wissen müssen, dass sie einen Stronghold haben. Seine Verwendung sollte unsichtbar sein, ähnlich wie die Besucher gewöhnlicher Websites 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 einer Systemperspektive betrachtet, sind wir heute in der Softwarebranche damit konfrontiert, dass jede Anwendung das Gefühl hat, dass sie in der Lage sein sollte, alle Geheimnisse zu nutzen, die sie zu brauchen glaubt, und es gibt selten starke Garantien, 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ß.

Halt die Klappe und nimm mein Geld

Es ist nie gut, zu selbstbewusst 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 auf dieser Blogseite, können Sie eine Flagge (Hinweis) entdecken, die Ihnen hilft, einen Stronghold-Snapshot zu finden. Dieser Snapshot wurde mit der Stronghold-CLI unter der git-Revision 93d1dfa12235f4c769a714a1cf39a4222b4ecc27 erstellt. Sobald Sie ihn gefunden haben, ist der Rest der CTF 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 für die Aufnahme in die Rangliste zu erhalten. Viel Glück!

Was kommt als nächstes

In den nächsten Monaten werden wir Tutorials, Beispiele, Dokumentationen und Spezifikationen vorbereiten, sowie die Integration mit anderen Projekten der IOTA Foundation. 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 Abstraktionsschicht zur darunterliegenden Engine und den Kommunikationsbibliotheken, was garantiert, dass selbst wenn sich die interne Codebasis ändert, Ihre Schnittstelle zu Stronghold weiterhin funktioniert.

Status: Beta
CHANGELOG

Tresor
Der Tresor ist jetzt schreibbar 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

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 erlaubt, Datensätze zu schützen, wenn sie in Gebrauch sind, und sie automatisch auf Null zu setzen.

Status: Beta
CHANGELOG

Schnappschuss
Die Snapshot-Kiste 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 Kommunikationskiste 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

Original by IOTA Foundation: https://blog.iota.org/iota-stronghold-beta-release/

IOTA Chrysalis Wöchentliches Update #7

Wird wöchentlich als Zusammenfassung der Chrysalis Phase 2 Updates veröffentlicht. Bitte klicken Sie hier, wenn Sie das vollständige monatliche Dev-Status-Update lesen möchten.

IOTA 1.5

IOTA 1.5 (auch bekannt als Chrysalis) ist die Zwischenstufe des Mainnets, bevor Coordicide abgeschlossen ist. Sie können hier mehr über die Strategie zur Freigabe von Chrysalis lesen.

Die Komponenten der Chrysalis-Phase 1 wurden im August in das Mainnet eingespielt. Das Ingenieursteam arbeitet nun an Chrysalis Phase 2, oder der vollständigen Implementierung von IOTA 1.5.

Die Updates und der Status dieser Woche

Öffentliches Testnet der Phase 2

Kurz vor Weihnachten haben wir das öffentliche Testnetz freigegeben. Zusammen mit der Community haben wir in den letzten Wochen verschiedene Komponenten, wie die Node Software oder die verschiedenen Bibliotheken im Testnet getestet. Außerdem haben wir die letzten Protokolländerungen abgeschlossen.

Diese Woche haben wir das Testnet aktualisiert:

  • Das Präfix der im Testnet verwendeten Adressen wurde auf atoi geändert
  • Aktualisierte Knoten MQTT und REST API, um die neueste Spezifikation zu reflektieren
  • Implementierung des Dust-Schutzes in der Node Software hinzugefügt

Sie können mehr über das Update im neuen Tech-Announcements-Kanal auf unserem Discord lesen.

Bee

  • Begonnene Live Tests der Bee Nodes mit dem Bee X-Team
  • Behebung der Erkenntnisse aus dem externen Code Audit
  • Implementieren des Dust-Schutzes
  • Implementierung einer Verbesserung der Balance Suche von Hornet

Hornet

  • Aktualisierte Abhängigkeiten, die Schwachstellen aufwiesen (erforderte Forking der MQTT-Lib)
  • Fix für die Dashboard-Authentifizierung, Fix für Heartbeats, um Bee die Synchronisation zu ermöglichen
  • Die Art und Weise, wie der Ledger gespeichert wird, wurde geändert, so dass Balance Lookups keine Iteration mehr erfordern -> bessere Leistung
  • Dust-Schutz implementiert und im Testnetz implementiert

Iota.rs und wallet.rs

Unsere Rust-Implementierung der Standard-Client-Bibliothek und Wallet-Funktionalitäten

  • Python-Bindings für iota.rs wurden portiert und sind für die reguläre API fertig, MQTT in Arbeit
  • Python-Bindings für wallet.rs werden folgen
  • Aktualisierte Anwendungsbeispiele, um den aktuellen Stand der Libs wiederzugeben
  • State Adapter steht noch aus

Crypto.rs und Stronghold

Crypto.rs ist eine Kiste für alle kryptographischen Algorithmen, die von vielen der Projekte bei IF verwendet werden. Stronghold ist eine sichere Software-Implementierung für die sichere Isolierung digitaler Geheimnisse.

Firefly

Chrysalis Phase 2 wird mit einer neuen Wallet-Implementierung kommen, die Trinity ersetzt.

  • Die UI-Implementierung und die wallet.rs-Implementierung werden zusammengeführt
  • Firefly wird derzeit einer internen Sicherheitsüberprüfung unterzogen, bevor eine externe Sicherheitsüberprüfung beginnt
  • Die Ledger Nano App ist fertig, die Integration der App wird bald beginnen

Audits

Ein großer Teil der Chrysalis Phase 2 Bemühungen ist die Prüfung der neuen Funktionalität. Wir haben mit dem Audit der Protokolländerungen an der Node-Software begonnen. Das Wallet-Audit findet derzeit intern statt und wird, sobald wir es abgeschlossen haben, an eine externe Audit-Firma übergeben.

Wie immer heißen wir jeden willkommen, auf Discord vorbeizuschauen – jedes hier erwähnte Projekt hat einen Kanal (oder mehr) für die Diskussion mit den Entwicklern!Folgen Sie uns auf Twitter, um über alle Neuigkeiten auf dem Laufenden zu bleiben: https://twitter.com/iotatoken

Original by Jakub Cech: https://blog.iota.org/chrysalis-update-january-22/

IOTA Chrysalis Wöchentliches Update #6

Wird wöchentlich als Zusammenfassung der Chrysalis Phase 2 Updates veröffentlicht. Bitte klicken Sie hier, wenn Sie das vollständige monatliche Dev-Status-Update lesen möchten.

IOTA 1.5

IOTA 1.5 (auch bekannt als Chrysalis) ist die Zwischenstufe des Mainnets, bevor der Coordicide abgeschlossen ist. Sie können hier mehr über die Strategie zur Freigabe von Chrysalis lesen.

Die Komponenten der Chrysalis-Phase 1 wurden im August in das Mainnet eingespielt. Das Ingenieursteam arbeitet nun an Chrysalis Phase 2, oder der vollständigen Implementierung von IOTA 1.5.

Die Updates und der Status dieser Woche

Öffentliches Testnet der Phase 2

Kurz vor Weihnachten haben wir das öffentliche Testnetz freigegeben. Zusammen mit der Community haben wir in den letzten Wochen verschiedene Komponenten, wie die Node-Software oder die verschiedenen Bibliotheken im Testnet getestet. Das testnet hat sich während der Testphase als unglaublich stabil erwiesen und wir freuen uns darauf, es bald um weitere Funktionen zu erweitern.

Wenn Sie sich beteiligen möchten, besuchen Sie bitte den #chrysalis-testnet-Kanal auf Discord 

Bee

  • Das Team macht Fortschritte bei der Implementierung des neuen Node-Dashboards und der Einspeisung von Daten in dieses.
  • Die gesamte Client-API wurde im Dezember fertiggestellt.
  • Die Implementierung des Speichers wurde stabilisiert.
  • Verschieben von Kisten in den Dev-Zweig.
  • Finalisierung der Ledger-Logik.
  • Tangle-Caching ist jetzt einsatzbereit.

Hornet

  • Das Team hat einen Fix für die Behandlung von Semi-Lazy-Tipps in der Chrysalis-Phase-2-Implementierung erstellt. Dadurch wurde die Bestätigungsrate im Chrysalis-Testnetz deutlich verbessert.
  • Der Dust-Schutz für Chrysalis Phase 2 wird implementiert.
  • Ein grundlegender Fehler innerhalb der Speicherschicht wurde behoben, wodurch auch ein Fehler mit festen Einstiegspunkten innerhalb lokaler Snapshots behoben wurde.

Iota.rs und wallet.rs

Unsere Rust-Implementierung der Standard-Client-Bibliothek und Wallet-Funktionalitäten

  • Das Team arbeitet an der Anpassung der Bibliothek an die neueste Spezifikation.
  • Die Arbeit an der Fertigstellung der Python-Bindings wird folgen.

Crypto.rs und Stronghold

Crypto.rs ist eine Kiste für alle kryptographischen Algorithmen, die von vielen der Projekte bei IF verwendet werden. Stronghold ist eine sichere Software-Implementierung für die sichere Isolierung digitaler Geheimnisse.

  • Alpha Release von Stronghold veröffentlicht.
  • Finalisierung der Integration für das Audit von Firefly im Januar.
  • CHANGELOGs jetzt verfügbar.
  • CI Pipelines stehen kurz vor der Fertigstellung.

Firefly

Chrysalis Phase 2 wird mit einer neuen Wallet-Implementierung kommen, die Trinity ablöst.

  • Wir haben einen Beitrag über unsere Wallet der nächsten Generation, Firefly, und ihre Zukunft veröffentlicht.
  • Alle Komponenten und Abhängigkeiten werden miteinander verdrahtet.
  • Das Dashboard und die Einstellungs-UI werden gerade fertiggestellt.
  • An CI und In-App-Update wird gearbeitet.
  • Bugs in wallet.rs werden behoben, während die Wallet getestet wird.
  • Ein umfassendes Wallet-Audit beginnt in zwei Wochen.

Audits

Ein großer Teil der Chrysalis Phase 2 Bemühungen ist das Auditieren der neuen Funktionalität. Wir haben mit dem Audit für die Protokolländerungen an der Node-Software begonnen. Das Wallet-Audit wird ebenfalls im Januar stattfinden.

Wie immer heißen wir jeden willkommen, auf Discord vorbeizuschauen – jedes hier erwähnte Projekt hat einen Kanal (oder mehr) für Diskussionen mit den Entwicklern! Folgen Sie uns auf Twitter, um über alle Neuigkeiten auf dem Laufenden zu bleiben!

Original by Jakub Cech: https://blog.iota.org/chrysalis-update-january-8/

IOTA Stronghold Alpha Release

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 der private Schlüssel) 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 zu lösen ist. 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, die Interna 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 Angriffen 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 Konsumenten 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 Sicherheitsaudit 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:

git clone git@github.com:iotaledger/stronghold.rs.git

cd stronghold.rs/products/commandline

cargo build –release

Der Rest dieses Artikels wird die Stronghold-Architektur näher erläutern und ist von 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-Kiste – 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:

  • Stronghold-Datensätze (und ihre Dateibackups) sind „von Natur aus“ verschlüsselt, um Offline-Angriffe abzuwehren. Bei den meisten anderen Datenbanken müssen Sie die Verschlüsselung selbst vornehmen, durch Bibliotheken, Plugins oder ein zugrunde liegendes verschlüsseltes Dateisystem.
  • 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)
  • 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 herumzureichen. 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 Akteur in den Müll geworfen und der Future aufgelöst.

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

Das Stronghold-Objekt erzeugt intern mehrere Akteurssysteme, 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 aus dem Client-Pfad abgeleitet werden. Ein Snapshot-Actor wird aufgespannt, 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 Laufzeit. 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 kryptografischen Operationen ist als Prozedur definiert. Spezifische Eingaben und Ausgaben werden je nach Bedarf pro Prozedur festgelegt. 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 Strongholds

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

Einige Betriebssysteme und Hardware-Plattformen bieten einzigartige Möglichkeiten, die Laufzeitsicherheit 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.

Sicherheit von Stronghold

Attribute der sicheren 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 in die Secure Zone (Laufzeit) 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 geerbten übergeordneten 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:

Releases und sicheres Verbrauchen

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 Release-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 Pipeline für das Testen, Bauen, Linting, Auditing, Changelogging, Zusammenführen in den Hauptzweig, Erstellen von Git Release Tags, Herstellen von Artefakten (wie das Kommandozeilen-Binary), Veröffentlichen einer neuen Version auf Github und dann 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“

X-Teams

Sie sind erstaunlich, dass Sie 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

Original Daniel Thompson-Yvetot: https://blog.iota.org/stronghold-alpha-release/

 

Chrysalis (IOTA 1.5) Öffentliches Testnetz ist live

IOTA 1.5

IOTA 1.5 (auch bekannt als Chrysalis) ist die Zwischenstufe von IOTA, bevor Coordicide fertiggestellt wird. Sie können hier mehr über die Strategie zur Freigabe von Chrysalis lesen.

Die Komponenten der Chrysalis-Phase 1 wurden im August ins Mainnet eingespielt. Heute markiert das Ingenieursteam einen bedeutenden Meilenstein mit der Freigabe des Chrysalis Phase 2 Testnetzes.

IOTA 1.5 Testnetz

Heute öffnen wir das Chrysalis-Testnetz für die Öffentlichkeit. Dieser Zeitraum ist der Schlüssel für ein erfolgreiches Protokoll-Upgrade zu Beginn des neuen Jahres. Wir heißen jeden willkommen, die Funktionalität zu testen und Feedback zu geben.

Die Veröffentlichung von Chrysalis Phase 2 im IOTA Mainnet wird das größte Upgrade sein, das das IOTA Netzwerk jemals erfahren hat. Eine komplette Überarbeitung des Protokolls, die die Voraussetzungen für die Einführung schafft und uns einen Schritt näher zu IOTA 2.0 bringt.

Bedenken Sie, dass die Änderungen noch im Gange sind und es Bugs geben wird, Audits durchgeführt werden und brechende Änderungen eingeführt werden. Das ist alles Teil des Prozesses.

Wenn Sie eine bestehende Integration auf dem IOTA-Protokoll haben, können Sie mit dem Testnet und den Bibliotheken die ersten Arbeiten beginnen, um Ihre Integration auf die endgültige Implementierung von IOTA 1.5 umzustellen. Dies sind die Komponenten, die wir mit dem testnet veröffentlichen:

  • Eine neue wallet.rs-Bibliothek mit JS-Bindungen über Neon
  • Eine neue CLI-Wallet, die auf wallet.rs aufbaut, die es Ihnen erlaubt, grundlegende Wertoperationen durchzuführen und Integrationen zu bauen, die mit Token arbeiten
  • Ein neuer Faucet zum Anfordern von Testnet-Tokens zur Verwendung in Ihrer Wallet
  • Eine experimentelle JS-Bibliothek mit implementierten Chrysalis-APIs, einschließlich MQTT und lokalem Proof of Work
  • Hornet v0.6.0-alpha Node Version. Betreiber können ihre eigene Node einrichten und sie mit dem Testnetz verbinden
  • Beachten Sie, dass sich alle Komponenten in einem frühen Alpha-Stadium befinden, mit einem ausstehenden Audit. Es wird Bugs geben und Dinge werden kaputt gehen

API-Endpunkte

Nodes, die für das Testnet bereitgestellt werden, können über einen Load Balancer abgefragt werden unter

api.lb-0.testnet.chrysalis2.com

Wir empfehlen die Verwendung des Load Balancers für die meisten Szenarien.

Einzelne Knotenendpunkte, zum Beispiel für die Verwendung von MQTT, sind:

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

Die Node-API ist gemäß der folgenden Spezifikation integriert.

Explorer

Das Netzwerk verfügt über einen Explorer, der auf der regulären Explorer-Website bereitgestellt wird.

Einrichten einer eigenen Node

Wenn Sie eine eigene Node einrichten möchten, müssen Sie den chrysalis-pt2-Zweig im offiziellen Hornet-Repository verwenden. Sie müssen sich manuell mit Ihren Nachbarn peeren. Besuchen Sie dazu den Discord-Kanal #chrysalis-testnet und fragen Sie nach Nachbarn.

Sobald Sie Ihre Node eingerichtet haben, empfehlen wir Ihnen, sich das Dashboard anzusehen 🙂 Wir werden später mehr über das Dashboard berichten.

Wallet-Bibliothek

Wallet.rs ist eine allgemeine, in Rust geschriebene Wallet-Bibliothek. Sie wird von der CLI-Wallet, die wir heute veröffentlicht haben und von unserer kommenden Wallet-Software Firefly verwendet. Wallet.rs enthält die gesamte Logik, um Wallets oder Integrationen, die Wallet-Funktionalität benötigen (z.B. Börsen), sicher zu bauen. Sie beinhaltet die Verwaltung und Sicherung des Kontostatus, die Erstellung von Konten, die Übertragung von Token und mehr.

Die Wallet-Bibliothek kommt mit Neon-Bindings für Node JS hier.

Weitere Informationen über die Bibliothek finden Sie im wallet.rs Repository.

Kommandozeilen-Wallet

Die neue CLI-Wallet bietet eine Schnittstelle für die wallet.rs-Bibliothek, die Sie direkt von Ihrer Kommandozeile aus verwenden können. Sie eignet sich hervorragend zum Testen und für die Arbeit mit Konten und Werttransfers auf eine leichtere Art und Weise als mit einer UI-Wallet.

Schauen Sie sich die CLI-Wallet im cli-wallet-Repository an. Die aktuelle Vorabversion finden Sie hier.

Faucet

Ein neues Chrysalis Faucet wurde mit dem Testnet bereitgestellt. Dieses wird später auch für das Devnet verfügbar sein. Das Faucet erlaubt es Ihnen, Test-Token anzufordern, um sie in Ihren Integrationen zu verwenden, um sie in der CLI-Wallet zu versenden und später für Tests mit Firefly.

Sie können das Faucet hier finden. Der Faucet ist ratenbegrenzt und Sie können alle 60 Sekunden eine Anfrage stellen.

Das Design des Faucets ist auf Firefly und unsere aktuelle Designsprache abgestimmt.

Sie benötigen zunächst eine Testnet-Adresse, die Sie mit der CLI-Wallet oder wallet.rs erzeugen können.

iota.js

iota.js ist eine neue experimentelle, in TypeScript geschriebene Bibliothek, mit der Sie die neuen Chrysalis-APIs testen können: Wert- und Datentransaktionen senden, Peers und Adressen verwalten und mehr. Die Implementierung unterstützt MQTT und erlaubt es Ihnen, lokale Proof of work (PoW) durchzuführen.

Sie finden die neue iota.js-Bibliothek hier.

Wir freuen uns darauf, dass Sie alle die Nodes, die neuen Bibliotheken und die CLI-Wallet im Chrysalis Phase 2 Testnetz testen!

Bekannte Probleme

  • In der CLI-Wallet müssen Sie den aktuellen Account löschen und einen neuen anlegen, wenn Sie sich mit einem anderen Node verbinden wollen. Ein Fix ist in Arbeit.
  • Es gibt ein Problem mit der Bestätigung von Nachrichten mit einer sehr großen Anzahl von Ausgängen (max ~18).

Probleme gefunden? Bitte fragen Sie in #chrysalis-testnet auf Discord nach. Alternativ können Sie auch selbst ein Issue auf dem jeweiligen Projekt GitHub öffnen.

Was kommt als nächstes?

Als nächstes werden wir weitere Bibliotheken im Testnet veröffentlichen (einschließlich unserer Kernbibliothek iota.rs), Unterstützung für Stronghold in der Bibliothek wallet.rs und der CLI-Wallet hinzufügen, mehr Dokumentation veröffentlichen und später wird auch Firefly dem Testnet beitreten. Bleiben Sie dran!

Wie immer heißen wir jeden willkommen, auf Discord vorbeizuschauen.

Folgen Sie uns auf unseren offiziellen Kanälen und erhalten Sie die neuesten Nachrichten!

Original: https://blog.iota.org/chrysalis-phase-2-testnet-out-now/

IOTA Chrysalis Wöchentliches Update #2

Wird wöchentlich als Zusammenfassung der Aktualisierungen der Chrysalis-Phase 2 veröffentlicht. Bitte klicken Sie hier, wenn Sie das vollständige monatliche Update zum Entwicklungsstatus erhalten möchten.

IOTA 1.5

IOTA 1.5 (auch bekannt als Chrysalis) ist die Zwischenstufe des Hauptnetzes, bevor der Coordicide abgeschlossen ist. Sie können hier mehr über die Strategie zur Freigabe von Chrysalis lesen.

Die Komponenten der Chrysalis Phase 1 wurden im August in das Hauptnetz eingespeist. Das Ingenieurteam arbeitet nun an der Phase 2 von Chrysalis.

Die Aktualisierungen und der Status dieser Woche

Bee

  • Letzte Woche schloss das Bee Team erfolgreich einen Bee Node an eine Hornet Node auf dem Chrysalis Testnetz an. Dadurch konnte das Team die Synchronisation zwischen den Knoten erfolgreich testen
  • Das Team ist dabei, das Netzwerkprotokoll zu aktualisieren, wobei der Ledger und die Snapshot Implementierung optimiert werden
  • Ein Endpunkt für das Senden von Nachrichten muss noch von der neuen API aus implementiert werden
  • Verschieben von Kisten (crates) in das Haupt-Repository von Bee
  • Der bevorstehende Schwerpunkt wird weitgehend auf der Dokumentation, dem Testen und der Prüfung der erforderlichen Kisten liegen

Hornet

  • Fortschritte beim Refactoring von Gossip und Tangle Plug-ins und Snapshot Plug-ins
  • Zurücksetzen des internen Chrysalis Testnetzes beim Hinzufügen von Netzwerk-IDs zum Nachrichten-Layout
  • MQTT-Websocket-Implementierung hinzugefügt
  • Delta Snapshot Import und -Export Funktionalität hinzugefügt

Iota.rs und wallet.rs

Unsere Rust-Implementierung von Standard Client Bibliotheks  und Wallet-Funktionalitäten:

  • Die Logik für Neuanbindung, Werbung und Wiederholungsversuche wurde zusammengeführt
  • Der Prozess der Knotensynchronisierung funktioniert jetzt
  • Die erste Integration mit der MQTT-Schnittstelle von Hornet wurde zusammengeführt
  • Python Bindungen für iota.rs sind in vollem Gange. Das Senden von Nachrichten und die Überprüfung der Balance funktioniert, weitere APIs sind in Arbeit
  • Es wird zwei dokumentierte Möglichkeiten zur Handhabung von Seed in der Bibliothek geben, eine mit Stronghold, die andere mit dotenv.
  • Wallet.rs node.js-Bindungen über Neon wurden zusammengeführt

Crypto.rs und Stronghold

Crypto.rs ist eine Kiste für alle kryptographischen Algorithmen, die von vielen der Projekte bei IF verwendet werden. Stronghold ist eine sichere Software Implementierung zur sicheren Isolierung digitaler Geheimnisse.

  • Einführung von Changelog, Release-Management und einem polyglotten Artefakt Publishing Workflow über Covector
  • Plattformübergreifende Einführung einer sicheren Zone
  • Überarbeitung von Client, Top-Level-Akteur und libp2p
  • Teilnahme an der projektübergreifenden Arbeitsgruppe für Bindungen
  • Zusammenarbeit mit dem Projekt riker.rs (das von Stronghold verwendete Akteursmodell)
  • Die Top-Level-Bibliothek für Stronghold ist in Arbeit, sie wird als Einstiegspunkt zu Stronghold für alle konsumierenden Anwendungen (und Bindungen) verwendet werden
  • Das Hauptaugenmerk liegt darauf, die Wallet und ihre Integration mit den Bibliotheken in einen funktionierenden Zustand zu bringen.

Firefly

Chrysalis Phase 2 wird mit einer neuen Wallet Implementierung namens Firefly kommen, die Trinity ersetzt

  • Die Arbeit an der Anbindung von wallet.rs an die Wallet-Anwendung wird fortgesetzt.
  • Das Ziel dieser Woche ist es, die Integration der Benutzeroberfläche abzuschließen. Dies wird es uns ermöglichen, in den kommenden Wochen die erste Wallet Alpha für die Gemeinschaft zur Verfügung zu haben
  • Die Arbeiten an dem neuen Wasserhahn, der von wallet.rs unter Verwendung von Neon-Bindungen betrieben wird, sind im Gange. Das Front-End wurde entworfen, die Integration wird folgen.

Testnetz

Wir befinden uns jetzt in einer Phase, in der wir die Chrysalis-Funktionalität auf einem privaten Testnetz testen. Wir arbeiten daran, alle notwendigen Teile zusammenzuführen, um das Testnetz öffentlich zu machen. Dies umfasst:

  • die CLI wallet – kurz vor der Fertigstellung
  • neuer faucet
  • komplette Infrastruktur, die wir jetzt überarbeiten, einrichten
  • Knotensoftware stabilisiert – brechende Änderungen werden weiterhin Teil des Testnetzes sein
  • wallet.rs mit JS-Bindungen
  • iota.rs mit JS-Bindungen

Gegenwärtig wird angestrebt, die erforderlichen Werkzeuge bis Ende nächster Woche bereit zu haben.

Prüfungen

Ein großer Teil der Bemühungen in Phase 2 von Chrysalis besteht in der Prüfung der neuen Funktionalität. Wir haben die entsprechende Verfügbarkeit bei mehreren externen Wirtschaftsprüfungsgesellschaften für die kommenden Wochen gebucht, damit wir so bald wie möglich mit der Prüfung der verschiedenen Komponenten beginnen können.

Wie immer heißen wir jeden willkommen, bei Discord vorbeizuschauen – jedes hier erwähnte Projekt hat einen Kanal (oder mehr) für Diskussionen mit den Entwicklern!

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

Original Jakub Cech: https://blog.iota.org/chrysalis-weekly-update-november-27-9a7582485d2

IOTA Chrysalis Wöchentliches Update – 19. November #1

Wird wöchentlich erscheinen, als Zusammenfassung der Aktualisierungen der Chrysalis-Phase 2. Bitte klicken Sie hier, wenn Sie das vollständige monatliche Update zum Entwicklungsstatus erhalten möchten.

IOTA 1.5

IOTA 1.5 (auch als Chrysalis bekannt) ist die Zwischenstufe des Hauptnetzes, bevor Coordicide abgeschlossen ist. Sie können hier mehr über die Strategie zur Freigabe von Chrysalis lesen.

Die Komponenten der Chrysalis-Phase 1 wurden im August in das Hauptnetz eingespeist. Das Ingenieurteam arbeitet nun an der Phase 2 von Chrysalis.

Die Aktualisierungen und der Status dieser Woche

Bee

  • Das Bee Team hat erfolgreich eine Bee Node mit Hornet Node im Chrysalis-Testnetz verbunden
  • Der Rest der neuen API-Endpunkte wird diese Woche fertiggestellt
  • Das Team wird nun damit beginnen, Kisten zum Hauptlager der Bienen zu transportieren
  • Der bevorstehende Schwerpunkt wird weitgehend auf der Dokumentation und der Prüfung der erforderlichen Kisten liegen

Hornet

  • Das Hornet-Team hat im Netzwerk-Stack Korrekturen vorgenommen
  • Refactoring von Gossip-, Tangle- und Snapshot-Plugins
  • Hinzufügen von Netzwerk-IDs zum Nachrichtenlayout
  • Hinzufügen von MQTT zur Knotenimplementierung
  • Das Build-System wurde geändert, um Go 1.15.5 zu nutzen

Iota.rs und wallet.rs

Unsere Rust-Implementierung der Standard-Client-Bibliothek und Wallet-Funktionalitäten

  • Die Durchsicht der Ruster Bibliothek ist abgeschlossen, iota.rs gemäß den Spezifikationen
  • Als Nächstes werden wir uns mit den Neuanschlüssen, der Beförderungs- und Wiederholungslogik befassen
    Python-Bindungen für die iota.rs-Bibliothek werden folgen
  • Die erste Integration mit der MQTT-Schnittstelle von Hornet wurde hinzugefügt
  • Es wird untersucht, wie wir MQTT für Zustandsaktualisierungsereignisse in der wallet.rs-Bibliothek verwenden können

Crypto.rs und Stronghold

Crypto.rs ist eine Kiste für alle kryptographischen Algorithmen, die von vielen der Projekte bei IF verwendet werden. Stronghold ist eine sichere Software-Implementierung zur sicheren Isolierung digitaler Geheimnisse.

  • Wir beabsichtigen, die Bibliothek diese Woche auf crates.io zu veröffentlichen
  • Wir haben einen PR für ed25519 (unter Verwendung von ed25519-zebra), blake2b und curl_p zusammengeführt
  • Mit der Arbeit an den Einbänden (Neon für js) wurde begonnen, CI wird derzeit eingerichtet
  • Dies wird einer der wichtigsten zu prüfenden Punkte für Chrysalis Phase 2 sein. Ein Audit dieser und anderer Bibliotheken ist in Planung
  • Die Stronghold-Bibliothek wird derzeit refaktorisiert
  • Die Top-Level-Bibliothek für Stronghold ist in Arbeit, sie wird als Einstiegspunkt zu Stronghold für alle verbrauchenden Anwendungen (und Bindungen) verwendet werden

Wallet

Chrysalis Phase 2 wird mit einer neuen Wallet Implementierung kommen, die Trinity ersetzt.

  • Die Arbeit an der Anbindung von wallet.rs an die Wallet Anwendung wird fortgesetzt
  • Wir würden gerne in den kommenden Wochen eine erste Wallet Alpha für die Gemeinschaft zur Verfügung haben
  • Die neue Anwendung Ledger Nano, die WOTS durch Ed25519 ersetzt, ist in Arbeit
  • Die Fertigstellung der  Wallet UI nach mehreren Iterationen
  • Die Arbeit an einer CLI Wallet und einem Faucet wird in Kürze beginnen. Dies wird uns beim Testen der Brieftasche und der Bibliotheken im Testnetz helfen

Identity

  • Thoralf#3558 führte erfolgreich IOTA Identity alpha auf dem Chrysalis-Testnetz aus.

Testnetz

Wir befinden uns jetzt in einer Phase, in der wir die Chrysalis Funktionalität auf einem privaten Testnetz testen. Sobald wir die ersten Tests der Nodesoftware und der Client-Bibliotheksimplementierungen abgeschlossen haben und wir die gesamte unterstützende Software bereit haben, werden wir das Testnetz öffentlich machen.

Prüfungen

Ein großer Teil der Bemühungen in Phase 2 von Chrysalis besteht in der Prüfung der neuen Funktionalität. Wir haben die entsprechende Verfügbarkeit bei mehreren externen Wirtschaftsprüfungsgesellschaften für die kommenden Wochen gebucht, damit wir so bald wie möglich mit der Prüfung der verschiedenen Komponenten beginnen können.

Wie immer heißen wir jeden willkommen, bei Discord vorbeizuschauen – jedes hier erwähnte Projekt hat einen Kanal (oder mehr) für Diskussionen mit den Entwicklern!

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

Original Jakub Cech: https://blog.iota.org/chrysalis-weekly-update-november-19-51583f4b9a66

IOTA Dev Status Update – November 2020 – Deutsch

Dieses Update wird jeden Monat vom IOTA-Entwicklerteam veröffentlicht und versorgt dich mit Neuigkeiten und Updates über unsere Schlüsselprojekte! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen möchten.
Die Forschungsabteilung gibt auch ein monatliches Update heraus, das Sie vielleicht lesen möchten.

IOTA 1.5

„IOTA Dev Status Update – November 2020 – Deutsch“ weiterlesen