IOTA Staking Start – Anleitung für das Staking in Firefly

Mögen die Belohnungen mit Dir sein

TL;DR:
Das IOTA-Staking für das Shimmer-Netzwerk (SMR-Token) und das Assembly-Netzwerk (ASMB-Token) beginnt heute, am 21. Dezember, um 15:00 Uhr MEZ (Europa) mit einer siebentägigen Pre-Staking-Periode. Token-Inhaber können ihre Staking-Periode jetzt beginnen, um ab dem 28. Dezember für 90 Tage Staking-Belohnungen zu erhalten. Eine neue Version von Firefly, die das Staking ermöglicht, ist jetzt hier verfügbar.

 

„IOTA Staking Start – Anleitung für das Staking in Firefly“ weiterlesen

Ankündigung der Ledger Nano-Unterstützung in Firefly

TL;DR:

Ledger Nano Support ist jetzt in Firefly verfügbar, und Ledger-Nutzer können ihre Token in das neue Chrysalis-Netzwerk migrieren. Wir haben sehr darauf geachtet, ein umfassendes und reibungsloses Erlebnis zu bieten, und laden Ledger Nano-Nutzer ein, Firefly und Chrysalis auszuprobieren. Laden Sie es hier herunter.

Die IOTA Foundation freut sich, die Veröffentlichung von Firefly 1.2.0 bekannt zu geben, mit der die Unterstützung für die Ledger Nano Hardware Wallet eingeführt wird. Es ist nun für Ledger-Nutzer möglich, ihre Gelder in das neue Chrysalis-Netzwerk zu migrieren und die Geschwindigkeit und Zuverlässigkeit des stark verbesserten IOTA-Protokolls zu erleben. Firefly ist derzeit auf Mac, Windows und Linux verfügbar und kann hier heruntergeladen werden.

Firefly Version 1.2.0 bietet USB-Unterstützung für Ledger Nano S und Ledger Nano X Geräte. Die Funktion wurde von einer Gruppe von ~50 Community-Mitgliedern über einen längeren Zeitraum gründlich getestet, um sicherzustellen, dass die App so reibungslos wie möglich funktioniert. Die In-App-Informationen zu dieser Funktion wurden von der Community in über 20 Sprachen übersetzt. Und der Code, die Bibliotheken und die Ledger BOLOS-Anwendung wurden allesamt externen Audits unterzogen.

Die Umstellung vom alten Netz auf das neue Chrysalis-Netz beinhaltet die Umstellung von Adressen, die auf der Winternitz One-Time Signature (WOTS) basieren, auf wiederverwendbare EdDSA-Adressen. Diese Protokolländerungen bedeuten auch, dass wir von der alten Ledger Nano App zu einer neuen migrieren müssen und von der alten Wallet, Trinity, zu unserer neuen Wallet, Firefly.

Wir haben extrem darauf geachtet, dass die technische Komplexität der Migration für den Nutzer nicht sichtbar ist. Die Nutzer müssen lediglich ihr Ledger Nano-Gerät anschließen, Firefly öffnen und den Schritten folgen, um ihre Token zu migrieren. Ebenso können Nutzer, die neu bei IOTA sind und nicht migrieren müssen, einfach ein Profil einrichten, Token erhalten und die ~10s Bestätigungszeiten genießen, die das neue Chrysalis-Netzwerk ermöglicht.

Bisher wurden über 1 Milliarde Dollar (1,3 Peta IOTA) zu Chrysalis migriert. Mit der Veröffentlichung von Ledger Nano erwarten wir, dass diese Zahl dramatisch ansteigen wird. Mehrere Börsen haben ebenfalls auf Ledger-Unterstützung für ihre eigenen Integrationen gewartet und wir werden mit ihnen zusammenarbeiten, um ihnen bei der Fertigstellung der Chrysalis-Unterstützung zu helfen.

Wir möchten uns bei den Community-Mitgliedern bedanken, die ihre Zeit darauf verwendet haben, die Integration zu testen, Fehler zu finden und Vorschläge zur Verbesserung der Benutzerfreundlichkeit zu machen. Ebenso möchten wir uns bei den Übersetzern der Community bedanken, die viele Stunden damit verbracht haben, die App zu übersetzen und IOTA für ein breiteres Publikum zugänglich zu machen. Ihr alle wisst, wer ihr seid, und wir möchten, dass ihr wisst, wie unendlich dankbar wir für eure harte Arbeit sind.

Warum die Freigabe so lange dauerte und was wir daraus gelernt haben

Das Chrysalis-Netzwerk wurde am 28. April in Betrieb genommen und die Ledger-Nutzer mussten bis heute warten, bevor sie über Firefly zu Chrysalis migrieren konnten. Wir sind uns darüber im Klaren, dass dies eine inakzeptable Zeitspanne ist und für viele eine frustrierende Zeit war. Sie entspricht weder den hohen Standards, die wir uns selbst gesetzt haben, noch den Standards, die unsere Community von uns erwartet. Aus diesem Grund möchten wir Ihnen mitteilen, warum es so lange gedauert hat, welche Fehler gemacht wurden und wie wir sicherstellen werden, dass Protokoll-Upgrades und neue Funktionen in Zukunft reibungsloser veröffentlicht werden. Wir möchten uns für die Geduld der IOTA-Gemeinschaft während dieser Zeit bedanken.

Kurz vor der Veröffentlichung von Chrysalis wurde klar, dass wir nicht in der Lage sein würden, die Ledger-Unterstützung vor dem Start zu gewährleisten. Wir rieten Nutzern, die ihre Gelder früher migrieren wollten, ihre Gelder zunächst an eine Nicht-Ledger-Adresse zu senden. In Anbetracht unseres damaligen Wissensstandes gingen wir davon aus, dass wir die Integration rechtzeitig abschließen könnten. Leider führten eine Reihe von unerwarteten Ereignissen und Rückschlägen während der Entwicklung dazu, dass der Zeitrahmen viel länger war als ursprünglich angenommen.

Chrysalis war ein kolossales Unterfangen. Es war das erste Mal in der Geschichte von IOTA, dass wir eine so komplexe Aufgabe in Angriff genommen haben, die alle Teile des IOTA-Stacks berührte, einschließlich einer vollständigen Überarbeitung des Protokolls, einer kompletten Neuschreibung aller Bibliotheken und Wallets und natürlich der notwendigen Migration von (inzwischen veralteten) WOTS-Adressen zu EdDSA-Adressen in Chrysalis. Die gesamte technische Abteilung kam zusammen, um das Upgrade durchzuführen, und obwohl wir an vielen Fronten gut gearbeitet haben, haben wir auch einige Fehler gemacht und gelernt, wo wir uns verbessern müssen.

Chrysalis zeigte auf, wo Teams, einschließlich Firefly, unterbesetzt waren und mehr Entwickler benötigten. Wir hatten die Unterbesetzung durch Überstunden kompensiert, und das ist weder ein skalierbarer Ansatz, noch gibt er einem die Freiheit, die ganze Bandbreite der Dinge zu erkunden, an denen man gerne arbeiten würde. Seitdem haben wir mehr als 20 Entwickler, Entwicklungsbeauftragte und technische Redakteure für mehrere Teams in der gesamten technischen Abteilung eingestellt, um sicherzustellen, dass wir unsere ehrgeizigen Pläne verwirklichen können. Chrysalis war auch eine Gelegenheit, viele unserer internen teamübergreifenden technischen Verfahren zu verfeinern.

Wir sind uns auch bewusst, dass unsere Kommunikation rund um das Ledger-Release nicht perfekt war, insbesondere was den geschätzten Zeitrahmen und die Regelmäßigkeit der Status-Updates betrifft. Wir haben anfangs nicht auf allen Kanälen Updates zur Verfügung gestellt, und wir sollten nicht erwarten, dass die breite Community unsere Discord- oder Entwickler-Tweets liest. Das hat sich inzwischen gebessert, und wir werden auch in Zukunft zeitnahe Updates zum Entwicklungsstand über die offiziellen Kanäle bereitstellen.

Was kommt als nächstes für Firefly?

Das nächste Hauptaugenmerk liegt auf der Entwicklung von Firefly Mobile. Wir verfolgen einen ähnlichen Ansatz wie bei der Desktop-Version, bei dem wir zunächst sicherstellen, dass die Kernfunktionen robust, ausgefeilt und intuitiv zu bedienen sind, bevor wir zusätzliche Funktionen hinzufügen. Parallel dazu werden wir die Unterstützung für Deep Links in Firefly Desktop hinzufügen, damit andere Community-Anwendungen (wie Websites oder Web-Erweiterungen) Überweisungen in Firefly initiieren können. Wir werden auch Unterstützung für das Senden von Beträgen unter 1 MIOTA hinzufügen (was derzeit aufgrund des Staubschutzes verboten ist). Wir freuen uns darauf, mehr Informationen über Firefly Mobile und die kommenden Funktionen in unseren monatlichen Entwicklungsstatus-Updates zu teilen.

Original by IOTA Foundation: https://blog.iota.org/announcing-ledger-nano-support-in-firefly/

 

Dev Status Update – Juli 2021

Dieses Update wird jeden Monat vom IOTA-Entwicklungsteam veröffentlicht und versorgt Sie mit Neuigkeiten und Updates zu unseren wichtigsten Projekten! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen wollen.

Chrysalis

Es ist schon ein paar Monate her seit der erfolgreichen Veröffentlichung von Chrysalis im Mainnet. Sie können alles über die Veröffentlichung hier nachlesen. Bis jetzt wurden über 48% aller Token auf das neue Netzwerk migriert!

Die Entwicklungsabteilung konzentriert sich nun darauf, ihre Bemühungen auf den Coordicide zu verlagern – mit mehreren Ingenieuren, die sich seit Chrysalis an den Bemühungen beteiligen. Wir haben auch Fortschritte in all unseren anderen Projekten gemacht, wie z.B. Streams, Identity, Chronicle, sowie Smart Contracts und Ledger-Unterstützung für unsere Firefly-Wallet – die derzeit strengen Tests unterzogen wird. Sie können unten mehr über die Projekte lesen.

IOTA 2.0 Devnet

Nach der erfolgreichen Veröffentlichung des IOTA 2.0 Devnet Anfang Juni hat sich das Team auf Optimierungen konzentriert, zum Beispiel auf den Congestion Control Algorithmus, und einen stärkeren Fokus auf Konzepte wie Data Sharding gelegt. Außerdem konnten wir dank der Nutzung des DevNet Korrekturen an einigen Komponenten, wie FCoB, identifizieren. Sie können mehr darüber im letzten Forschungsupdate lesen.

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 die Version 0.1.0 der Nodesoftware mit dem Chrysalis-Release veröffentlicht und arbeitet seitdem an Korrekturen und Verbesserungen der Nodesoftware, sowie an der Veröffentlichung einer 0.1.2-Version von Bee. Das Team bereitet auch die Arbeit für eine Rust-Version des Coordicideknotens vor, wobei die Komponenten der Chrysalis-Version wiederverwendet und verbessert werden, aber auch die neuen Nachrichten- und Nutzlast-Layouts implementiert werden, sowie eine erste Netzwerkschicht, die mit GoShimmer kompatibel ist. Ein neues Dokumentationsportal für den Bienenknoten wurde gerade veröffentlicht und wird im Laufe der Zeit aktualisiert und vervollständigt http://bee.docs.iota.org/.

Hornet

Hornet hat sich als stabiles Rückgrat des IOTA-Mainnets erwiesen, sogar noch mehr nach der Veröffentlichung von Chrysalis. Im vergangenen Monat hat das Team die Version 1.0.3 von Hornet veröffentlicht, die eine neue Öffentlichkeit für bestimmte Meilensteinbereiche hinzugefügt hat.

Smart Contracts

Das IOTA Smart Contract Protocol Team arbeitet derzeit an der nächsten Version, die programmierbare Smart Contracts in das Nectar Testnet bringen wird. Alle funktionalen Komponenten für das nächste Release sind bereits implementiert und im Moment geht es hauptsächlich darum, die Codebasis vor diesem neuen Release zu polieren. Der aktuelle Build wurde bereits erfolgreich im Nectar-Testnet getestet und sogar eine grobe Arbeitsversion der EVM-Unterstützung wurde hinzugefügt, diese Integration wird sich in den kommenden Monaten weiter entwickeln. Das Team konzentriert sich nun in erster Linie auf das Testen, die Erfahrung der Entwickler, die Dokumentation und kleine Verbesserungen an der Codebasis als Ergebnis der Testsitzungen. Sobald wir mit dem Ergebnis dieser verbleibenden Aufgaben zufrieden sind, werden wir eine neue Version von ISCP, die auf Nectar läuft, ankündigen, die von jedem Interessierten getestet werden kann.

Sie können die Updates in den Kanälen #smartcontracts-discussion und #smartcontracts-dev auf Discord verfolgen.

Stronghold

Aufgrund von Wartungsproblemen der Riker Actor Model Crate haben wir die schwere Entscheidung getroffen, die Stronghold Client Crate nach Actix / Tokio zu portieren. Während die Portierung mehr Aufwand erforderte als ursprünglich erwartet, freuen wir uns, dass diese Überarbeitung auch die Logging-Probleme, für die Riker bekannt ist, löst und das System zusätzlich verschlankt. Das macht Stronghold kleiner und performanter. Zusätzlich wurde die Kommunikationskiste in P2P umbenannt, um ihre Natur widerzuspiegeln. Wenn der Umzug zu Actix abgeschlossen ist, wird der letzte Feinschliff an der P2P-Akteursschnittstelle erfolgen und wir werden sie als Beta veröffentlichen.

Wir möchten auch die Gelegenheit nutzen, um Tensor für die großartige Arbeit zu danken, die er bei der Entwicklung von Stronghold geleistet hat und empfehlen jedem, seinen Youtube-Kanal zu besuchen und ihm dort zu folgen, denn er wird bald Video-Tutorials über die Verwendung und Interaktion mit Strongholds veröffentlichen.

Wallet

Das Firefly-Team hat sich diesen Monat ausschließlich auf die Ledger Nano-Integration fokussiert. Der Fortschritt war stetig und es wurde viel Arbeit investiert, um sicherzustellen, dass die Benutzererfahrung während der Migration und der Nutzung der Wallet unseren hohen Standards entspricht. Das Team testet derzeit obskurere Migrationsflüsse (z.B. Bündel-Mining und Fonds, die über viele Adressen mit unterschiedlichen Indizes verteilt sind) mit der geschlossenen Testgruppe. In der Zwischenzeit hat sich das Team mit 3 neuen Devs vergrößert, die sich uns angeschlossen haben. Sobald Ledger über die Linie ist, wird das Team die Aufmerksamkeit auf die mobile App verlagern. Die Entwürfe für die mobile App sind fertig und wir können es kaum erwarten, loszulegen.

IOTA-Identity

Das Identity-Team wurde wieder einmal um zwei weitere Mitglieder erweitert: Craig Bester und Abdulrahim Al Methiab, die das Team mit einem weiteren Rust-Entwickler und einem Full-Stack-Entwickler für Tooling und Demonstrationen verstärken. Mit unserem nächsten Ziel für einen Release Candidate für IOTA Identity haben wir mit der Entwicklung des Identity Actors begonnen, einem Programm, das „Identität“ zwischen verschiedenen Entitäten „spricht“, eine genauere Erläuterung dazu wird es bald geben. Wir haben bereits einen PoC zum Laufen gebracht, bei dem zwei Identitäten zwischen der Web- und der Desktop-Umgebung miteinander sprechen können.

Darüber hinaus haben wir die Transparenz und das Onboarding zum Projekt verbessert. Wir werden bald mit unserem neuen Dokumentationsportal live gehen, obwohl der Inhalt noch lange nicht vollständig sein wird. Darüber hinaus haben wir mehrere öffentliche Kanban-Boards eröffnet, um unsere Fortschritte bei unseren kurzfristigen Zielen (in Richtung IOTA Identity 1.0) und unseren langfristigen Zielen für die nächsten Jahre zu zeigen.

Chronicle

Das Team war damit beschäftigt, Korrekturen an der Chrysalis-Version von Chronicle vorzunehmen. Wir arbeiten nun an einer Spezifikation für die selektive Permanode-Funktionalität. Sobald wir ein Design haben, mit dem wir zufrieden sind, werden wir es extern für weiteren Input zur Verfügung stellen.

IOTA-Experience Team

Der Juli ist fast vorbei, also lassen Sie uns einen Blick darauf werfen, was die X-Teams diesen Monat teilen:

X-Team-Mitglied Stefan Braun von IOTA.php begann den Juli mit der Λlpha Version 0.2.2 und 0.2.3 der 100% Community-getriebenen IOTA PHP-Bibliothek, die hier verfügbar ist. Unterstützen Sie das Projekt, indem Sie IOTA.php auf Twitter folgen und dem Repository auf GitHub einen Stern hinzufügen!

Das IOTA Foundation User Experience Team hat von den X-Teams wertvolles Feedback zum IOTA Tangle Explorer erhalten, das bei zukünftigen Änderungen in der Darstellung der Informationen im Explorer berücksichtigt wird.

Ein Aufruf an alle X-Team-Entwickler wurde von adamski veröffentlicht, unterstützen Sie die Community-Wiki-Initiative, indem Sie sich den Code im Repository ansehen. Jeroen van den Hout macht große Fortschritte mit seinem Docusaurus-Plugin. Es handelt sich dabei um einen Markdown-Editor für Docusaurus-Inhalte, der GitHub nutzt, um jeden Fortschritt zu committen und es den Mitwirkenden zu ermöglichen, eine Pull-Anfrage an das Upstream-Repository zu erstellen, ohne dass sie Markdown oder GitHub kennen müssen. Das Repository ist hier verfügbar, wir freuen uns über alle Entwickler, die Jeroen bei diesem Vorhaben unterstützen möchten.

Die zu 100% vom X-Team getriebene Identity-Initiative setzt die Tradition fort, sich jeden Montag um 20 Uhr MESZ zu treffen. Vergewissern Sie sich, dass Sie am nächsten Gespräch auf dem IOTA Discord teilnehmen.

IF und Identity X-Team Mitglieder haben sich während der Sovereign Nature Initiative im Rahmen der Odyssey Hackathon Challenge zusammengeschlossen. Das Identitree-Team hackte eine Demo-Anwendung zur Erstellung von CO2-Zertifikaten mit einem überprüfbaren Berechtigungsnachweis in einer NFT. Um mehr darüber zu erfahren, schauen Sie sich den Pitch auf YouTube an und finden Sie den Code hier.

Alexa99 hat sich kürzlich den X-Teams angeschlossen und das Pay with IOTA Plugin für WordPress veröffentlicht. Mit diesem Plugin können Sie diesen Button ganz einfach überall auf Ihrer WordPress-Seite einfügen. Ob in einem Artikel, auf einer Seite oder als Widget.

Die IOTA Foundation veröffentlichte einen Tweet, um Community-Mitglieder einzuladen, den IOTA Experience Teams beizutreten. Einige Bewerber haben ihre Discord-Benutzernamen geteilt, sind aber nicht auf dem IOTA Discord Server, wenn Sie einer von ihnen sind, treten Sie bitte dem Server bei und schreiben Sie an Antonio Nardella, um zu den X-Teams hinzugefügt zu werden.

Diesen Monat begrüßen wir die neuesten Mitglieder in den IOTA X-Teams: Apahatschi, nstabel,

dimitaracev, MOSDEV82, karlsruhe-node, C3PO, Vinceee, BiXe, Mahmuda Akter Keya, Cheezy, Lumpenheinrich, iotea3, philipp, Stephan07, Hasib, bcn137, hustler, Knacki92, Nocraze, Nft_iota, EasonC13, powderfinger, Birdy, IvanChen, TomSeestern, Nibiryus, Foofork, Pesco, Spacecat, Michel Machado, Merk92, Jonas, Warlosst, mpochert2, Simon H.

Jeder ist zu den IOTA Experience Teams eingeladen, um den Weg für IOTA zu ebnen, um die beste Erfahrung im DLT und IoT Raum 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 bisherigen X-Team-Treffen hier auf dem YouTube-Kanal der IOTA Foundation an.

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

 

Die Chrysalis IOTA Token Migration beginnt jetzt!

IOTAs neue Ära steht vor uns. Und die heutige Token-Migration markiert den Beginn unseres nächsten Kapitels, da wir unser bedeutendstes Protokoll-Upgrade des IOTA-Netzwerks mit „Chrysalis“ durchführen.

Das Chrysalis-Update kommt mit einem hochmodernen Sicherheitsniveau, einer um Größenordnungen höheren Ausfallsicherheit, enorm verbesserten Transaktionsgeschwindigkeiten und Durchsatzkapazitäten und gleichzeitig mit einem viel geringeren Energiebedarf. Chrysalis bringt auch eine komplette Überarbeitung der IOTA-Entwickler-Tools mit sich, wodurch es einfacher als je zuvor wird, mit IOTA zu entwickeln. Jeder kann Anwendungsfälle auf IOTA entwickeln, ohne große Änderungen befürchten zu müssen – auf dem Weg zur vollständigen Dezentralisierung mit „Coordicide“. In genau einer Woche wird IOTA „enterprise-ready“.

Das Chrysalis-Update markiert die umfangreichste Änderung in der Geschichte von IOTA, die alle Aspekte des IOTA-Protokolls, der Bibliotheken, der Werkzeuge, der Dokumentation und der Software berührt und ohne die Hilfe des gesamten IOTA-Ökosystems nicht möglich gewesen wäre.

Unsere Partner aus Wirtschaft und Industrie haben uns unschätzbare Einblicke in die Anforderungen der realen Welt gegeben. Und die unmittelbare IOTA-Community hat ausgiebig zu diesem Update beigetragen. Verglichen mit den bescheidenen Anfängen von IOTA war dieses Update ein wirklich gemeinschaftlicher Prozess, und wir sind stolz darauf, wie IOTA und die Community über die Jahre gewachsen und gereift sind.

Die letzten Wochen vor dem Update waren spannend und herausfordernd. Wir hoffen, dass wir alle Interessierten ausreichend über die Fortschritte während der letzten Etappe dieses bedeutenden Protokoll-Upgrades informieren konnten. Dieser Artikel befasst sich mit allen Informationen, die für die Migration von Token benötigt werden, und verweist auf alle früheren Veröffentlichungen, die sich mit verschiedenen Aspekten näher befassen.

Token-Migration

Ab heute, dem 21. April 2021, können Token-Inhaber damit beginnen, ihre Token auf das neue Adress- und Verschlüsselungsschema zu migrieren, das mit dem Chrysalis-Netzwerk-Update am 28. April 2021 eingeführt wurde.

Token, die zwischen dem 21. und 28. April mit Firefly auf das neue Netzwerk übertragen werden, werden ihren Besitzern nach dem Chrysalis-Update unter dem neuen Adressschema gutgeschrieben. Diese Token werden bis zur Netzwerkmigration am 28. April gesperrt sein – sie können in der Zwischenzeit nicht verschoben werden. Gesperrte Token werden dann direkt nach dem Start des Chrysalis-Netzwerks am 28. April wieder verfügbar.

wie migrieren ich meine iotas?

Bitte beachten Sie, dass die Migration von Token zwischen dem 21. und 28. April 2021 nicht zwingend erforderlich ist. Token-Inhaber werden gleichermaßen in der Lage sein, Token nach dem Chrysalis-Netzwerk-Update am 28. April zu migrieren, zumindest bis Coordicide, für das die IOTA Foundation schätzt, später in diesem Jahr einen vollständig dezentralen Release-Kandidaten präsentieren zu können. Während dieser „Fluid Migration“-Periode wird die Token-Migration nicht gesperrt sein und in kurzer Zeit im Chrysalis-Netzwerk verfügbar werden.

Während des Migrationszeitraums vom 21. bis 28. April wird das Legacy-Netzwerk wie gewohnt weiterarbeiten. Nach dem 28. April werden nur noch Migrationstransaktionen im Legacy-Netzwerk möglich sein. Das bedeutet, dass nach dem 28. April Benutzer, die noch Token im Legacy-Netzwerk halten, nur noch Token an die Migrationsadresse mit Firefly senden können, aber nicht mehr in der Lage sein werden, Token an andere Adressen im Legacy-Netzwerk zu senden (z.B. für Zahlungen, Adressen, die von Börsen unterhalten werden, usw.).

IOTA Migration Anleitung Übersicht deutsch

Für den Fall, dass Sie daran interessiert sind, den Fluss der Token zwischen den Netzwerken zu sehen, haben wir eine zusätzliche Seite zu https://chrysalis.iota.org hinzugefügt, die die Menge der Token zeigt, die vom WOTS-basierten „Legacy“-Netzwerk zum Chrysalis-Netzwerk migriert werden. Wir sind gespannt, wie der Token-Vorrat auf das neue Netzwerk übergehen wird.

Firefly Desktop-Version

Mit dem Ende der Migrationsphase (28. April) wird unsere bisherige Trinity-Wallet offiziell eingestellt. Heute veröffentlichen wir die erste Vollversion von Firefly, unserer neuen, stark verbesserten Wallet. Für den Fall, dass Sie die Beta-Version von Firefly getestet haben, wird die neue Version als separate Anwendung installiert. Den offiziellen Firefly-Download finden Sie auf unserer neuen Firefly-Website hier: https://firefly.iota.org.

Bitte beachten Sie, dass Firefly bis zum Chrysalis Netzwerk-Update am 28. April nur für die Migration von Token genutzt werden kann. Erst nach dem Chrysalis Netzwerk-Update am 28. April kann Firefly für reguläre IOTA-Transaktionen genutzt werden.

Firefly-Token-Migrationsanleitung

Firefly bietet einen nahtlosen Prozess, um Token zu migrieren. Dennoch haben wir einen Firefly-Token-Migrationsleitfaden veröffentlicht, der es den Nutzern ermöglicht, einen Blick darauf zu werfen, was sie erwartet, bevor sie den Prozess starten.

Für den Fall, dass Sie auf Probleme stoßen

Das Netzwerk-Update auf Chrysalis bedeutet effektiv, dass der gesamte Token-Vorrat auf neue Adressen migriert wird, was dieses Ereignis zu einem potenziellen Ziel für Betrüger macht. Falls Sie auf Probleme stoßen oder Fragen haben, seien Sie bitte vorsichtig, mit wem Sie sprechen, wenn Sie um Rat fragen und schauen Sie sich unbedingt den Artikel Sicherheit während der Token-Migration an, den wir früher veröffentlicht haben.

Benutzer von reinen Handy-Geldbörsen

Firefly ist nur als Desktop-App für Mac, Windows und Linux verfügbar. Benutzer, die Token in der mobilen Version von „Trinity“ verwaltet haben, können entweder den von Trinity Mobile generierten SeedVault (oder den Seed selbst) verwenden und diesen für die Migration von Token mit Firefly Desktop nutzen. Wir werden uns auf die Entwicklung der mobilen Versionen der App nach Chrysalis konzentrieren.

Ledger Nano Nutzer

Wie bereits erwähnt, sollten Nutzer, die IOTA-Token über eine Ledger Nano Hardware-Wallet verwalten, mit der Migration ihrer Token warten, bis die Ledger-Integration in Firefly vollständig getestet und freigegeben wurde.

Ledger Nano-Unterstützung wird in Firefly ein paar Wochen nach dem Chrysalis-Update verfügbar sein. Es wird empfohlen, dass Ledger Nano-Benutzer einfach mit der Migration warten, bis es fertig ist.

Falls ein Ledger-Nutzer nicht warten möchte, kann er seine Token auf einen nicht-Ledger-basierten Seed oder auf eine Börse, die die Migration unterstützt, vor dem 28. April übertragen. Nach dem 28. April werden nur noch Migrationstransaktionen im alten IOTA-Netzwerk möglich sein.

Benutzer, die Token an Börsen halten

Wie bereits erwähnt, arbeiten wir aktiv mit allen großen Börsen zusammen und unterstützen sie bei der Aufrüstung ihrer Infrastruktur zur Unterstützung von Chrysalis. Wenn Sie Ihre Token an Börsen halten, wird sich die Börse um die Token-Migration für Sie kümmern. Ihre Gelder sind zu jeder Zeit sicher. Auch wenn eine Börse das Chrysalis-Upgrade am 28. April nicht unterstützen wird, haben sich fast alle Börsen verpflichtet, kurz danach an der Integration zu arbeiten. Beachten Sie, dass alle Börsen ihre eigenen und vorgeplanten Release-Zyklen haben, die sich darauf auswirken können oder auch nicht, wie schnell und wann sie in der Lage sind, das Netzwerk-Update zu unterstützen.

Aktuelles Status-Update zur Exchange-Unterstützung:

  • Bitpanda wird Chrysalis zum Start vollständig unterstützen
  • Bitfinex wird Chrysalis zum Start vollständig unterstützen
  • Binance wird Chrysalis nach dem Start vollständig unterstützen. Derzeit wird die Integration abgeschlossen und auf den erfolgreichen Abschluss des Mainnet-Upgrades gewartet
  • Upbit arbeitet derzeit an der Chrysalis-Integration
  • OKEx wird im Mai mit der Integration von Chrysalis beginnen
  • Huobi wird im Mai mit der Integration von Chrysalis beginnen
  • Bittrex hat alle notwendigen Unterlagen und Informationen erhalten. Wir haben noch keine schriftliche Bestätigung erhalten, wann sie die Integration unterstützen werden
  • Liquid hat alle notwendigen Unterlagen und Informationen erhalten. Wir haben noch keine schriftliche Bestätigung erhalten, wann sie die Integration unterstützen werden.

Wenn eine Börse Chrysalis zum Start nicht unterstützt, bedeutet dies lediglich, dass Ein- und Auszahlungen deaktiviert sind, bis die Integration der neuen Chrysalis-Bibliotheken durch diese Börse abgeschlossen ist. Der Handel kann fortgesetzt werden und ist von den Integrationsbemühungen nicht betroffen.

Ein Hinweis auf möglichen „Dust“

Um „Ledger Bloat“ durch sogenannte „Dust-Attacken“ zu verhindern, wurde für das Chrysalis-Netzwerk eine einfache und effektive Gegenmaßnahme definiert: Um Werte kleiner als 1 MIOTA an eine Zieladresse zu übertragen, muss die Zieladresse einen Mindestbetrag von 1 MIOTA halten. Dieser Betrag wurde nicht als dauerhaft fester Wert und Lösung definiert, sondern ist nur eine Lösung für den Moment.

Das wiederum bedeutet, dass nur Werte, die größer als 1Mi sind, zu einer Adresse im Chrysalis Netzwerk migriert werden können, wie bereits in unserem vorherigen Artikel erwähnt, der verschiedene Aspekte der Firefly Token Migration erklärt.

Um zu verhindern, dass Staubeträge aus dem Legacy-Netzwerk nicht migriert werden können, fegt Firefly Token, die auf mehreren Adressen gehalten werden, und sendet die Summe davon an die Zieladresse im Chrysalis-Netzwerk. Dabei versucht Firefly, Beträge kleiner als 1 MIOTA zu Beträgen größer als 1 MIOTA zu „bündeln“.

In seltenen Fällen kann es dennoch vorkommen, dass Dust auf mehreren Adressen von Firefly nicht so gesammelt werden kann, dass Summen größer als 1 MIOTA entstehen (z.B. wenn die Summe von Dust auf allen Adressen nicht mehr als 1 MIOTA ergibt).

Ob für Trinity-Benutzer oder Ledger-Benutzer, Firefly wird immer versuchen, eine ideale Kombination von Adressen, die Dust enthalten, zu Kombinationen größer als 1 MIOTA zu erstellen, um sie erfolgreich migrieren zu können. Sollte Firefly nicht in der Lage sein, kleine Staubmengen zu Bündeln größer als 1 MIOTA zu kombinieren, kann der Dust nicht migriert werden.

Die in Firefly integrierte „Sweeping„-Funktion sollte als Komfortfunktion verstanden werden, aber nicht als Garantie. Wie oben erläutert, gibt es theoretische Fälle, in denen Firefly nicht in der Lage sein wird, entsprechende Bündel zu erstellen, die größer als 1 MIOTA sind.

Benutzer, die viele Adressen haben, die IOTA-Token von weniger als 1Mi halten, und die vermeiden wollen, dass Staub im Migrationsprozess verloren geht, sollten daher manuell allen Staub an eine Adresse senden, die mehr als 1 MIOTA beträgt, bevor sie den Migrationsprozess starten.

Beachten Sie, dass nach dem 28. April nur noch Transaktionen an die Migrationsadresse möglich sein werden, nicht aber das „Sammeln“ von Token an einer Adresse im alten Netzwerk. Das Senden von Staub an eine „Sammeladresse“ wird daher nur vor dem 28. April möglich sein.

Original by IOTA Foundation: https://blog.iota.org/the-chrysalis-token-migration-starts-now/

Chrysalis Netzwerk Migration – Veröffentlichungsdatum

Im letzten Jahr haben wir daran gearbeitet, das IOTA-Protokoll in Richtung Produktionsreife zu überführen, wobei wir die realen Bedürfnisse und Wünsche unseres Ökosystems berücksichtigt haben. Wir haben erfolgreich einige der exotischen Aspekte des IOTA-Protokolls entfernt und sie durch Industriestandards ersetzt. Die erste Phase von Chrysalis wurde im August 2020 im IOTA-Netzwerk implementiert. Wir befinden uns nun in der letzten Phase des größten Upgrades in der Geschichte von IOTA.

Heute freuen wir uns, den offiziellen Starttermin der Chrysalis-Netzwerkmigration bekannt zu geben – Mittwoch, 21. April 2021. Wie bereits erwähnt, wird die Migrationsperiode, die es Nutzern, Börsen und Verwalter/Depotinhaber ermöglicht, ihre Token-Migrationen vor dem Netzwerk-Upgrade vorzubereiten, 7 Tage vor dem Netzwerk-Upgrade. Das Netzwerk-Upgrade selbst wird offiziell am Mittwoch, den 28. April 2021, stattfinden.

chrysalis migration iota netzwerk

Das öffentliche Chrysalis-Testnetz läuft nun seit Dezember 2020, wobei nach und nach Komponenten zum Netzwerk hinzugefügt wurden, bis es vollständig mit den Chrysalis-Spezifikationen ausgestattet war. Entwickler und IOTA-Enthusiasten können bereits in der neuen Entwicklerdokumentation nachlesen, wie sie mit der Entwicklung auf Chrysalis beginnen können. Mit dem öffentlichen Beta-Release von Firefly in der nächsten Woche werden wir es jedem ermöglichen, die Zukunft von IOTA noch vor dem Mainnet-Upgrade zu erleben. (Tipp: ein paar Sekunden für den Proof of Work, Bestätigungszeiten unter 10 Sekunden und wiederverwendbare Adressen sind absolut erstaunlich).

Bitte beachten Sie: Die Beta-Version von Firefly wird es Ihnen nicht ermöglichen, Ihre Token zu migrieren. Das wird erst ab Mittwoch, 21. April 2021 möglich sein.

Während wir ein wenig hinter unserem geschätzten Q1-Release zurückbleiben, sollte die schiere Größe und sorgfältige Ausführung, die für das Chrysalis-Upgrade erforderlich ist, nicht unterschätzt werden, noch sollte das Upgrade überstürzt werden. Wir haben den gesamten IOTA-Tech-Stack (Node, Bibliotheken, Wallet) von Grund auf neu aufgebaut, einschließlich einer Token-Umstellung vom alten WOTS-Signaturschema auf die neuen EdDSA-Signaturen. Bisher haben wir mehrere Audits von drei unabhängigen Firmen erfolgreich abgeschlossen, und unser Team überprüft und optimiert kontinuierlich, wo immer möglich. All dies soll sicherstellen, dass Chrysalis ein reibungsloser und sicherer Übergang in eine neue und aufregende Zukunft mit viel höherer Leistung, Stabilität, Zuverlässigkeit und Sicherheit sein wird. Eine neue Morgendämmerung, sozusagen.

Während wir technisch weitgehend bereit sind, mit dem Netzwerk-Upgrade zu beginnen, ist einer der Gründe für die Änderung des offiziellen Starttermins, den Börsen mehr Zeit zu geben, den Übergang offiziell zu unterstützen. Viele Börsen haben vordefinierte Update-Zyklen, die weder übersprungen, noch verkürzt oder nach Belieben geändert werden können. Offensichtlich haben sie ziemlich strenge Überprüfungs- und Sicherheitsprozesse, die nicht aus einer Laune heraus geändert werden können und sollten. Wir werden sicherstellen, dass wir diese Zeitrahmen bei zukünftigen Upgrades besser berücksichtigen.

Wenn es um die Token-Migration geht, wird Firefly Sie schmerzlos durch den gesamten Migrationsprozess führen (wir werden im Vorfeld eine Schritt-für-Schritt-Anleitung veröffentlichen). Während des Prozesses wird unsere neue Wallet automatisch Zieladressen im Chrysalis-Netzwerk für Ihre Token erstellen. Die schwere Arbeit der Migration wird vollständig durch die Firefly-Wallet automatisiert und Token-Inhaber (einschließlich Ledger-Wallets) werden durch eine einfache Schnittstelle geführt. Kurz gesagt, die Migration Ihrer Token vom aktuellen IOTA-Netzwerk zum neuen Chrysalis-Netzwerk wird schmerzlos, einfach und schnell sein.

Mit der Netzwerkmigration wird fast der gesamte Token-Vorrat übertragen und viele Transaktionen werden durchgeführt. Das Migrationsereignis ist daher ein hochwertiges Ziel für Hacker und Betrüger. Wenn Sie die Firefly-Wallet herunterladen, stellen Sie bitte sicher, dass Sie nur die offizielle herunterladen, um Token sicher auf Ihre neue(n) Adresse(n) zu übertragen. Es gibt keinen offiziell empfohlenen Weg für Benutzer, ihre Token anders als mit Firefly zu migrieren. Natürlich halten wir ein Auge auf mögliche gefälschte Wallets oder inoffizielle Migrationsanweisungen.

Damit Sie absolut sicher sein können, dass Sie die offizielle Wallet herunterladen, laden Sie nur von unserer speziellen Netzwerk-Migrations-Statusseite https://chrysalis.iota.org oder direkt von https://iota.org herunter. Benutzen Sie nicht z.B. die Google-Suche und folgen Sie keinen Links, die direkt in sozialen Medien veröffentlicht wurden, auch wenn sie den Anschein erwecken, von der IOTA Foundation veröffentlicht worden zu sein.

DIE IOTA FOUNDATION WIRD NIEMALS DIREKTE DOWNLOAD-LINKS FÜR FIREFLY IN SOZIALEN MEDIEN VERÖFFENTLICHEN

Bitte beachten Sie, dass Token-Inhaber nicht verpflichtet sind, Token vor dem Chrysalis-Netzwerk-Update zu migrieren und die Möglichkeit haben, Token nach dem Netzwerk-Update für einen längeren Zeitraum zu migrieren. Je näher die Migration rückt, desto mehr Videos, Anleitungen und Leitfäden werden wir veröffentlichen, um Sie mit den notwendigen Informationen zu versorgen, um das Upgrade auf Chrysalis erfolgreich durchzuführen.

Original by IOTA Foundation: https://blog.iota.org/chrysalis-network-migration-release-date/

Bei Fragen, Anmerkungen benutzt die Kommentare oder das neue Forum. Für das Update wurde extra ein neues Thema eröffnet.

Dev Status Update – März 2021

Dieses Update wird jeden Monat vom IOTA-Entwicklungsteam veröffentlicht und versorgt Sie mit Neuigkeiten und Updates zu unseren wichtigsten Projekten! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen wollen.

Die Forschungsabteilung gibt auch ein monatliches Update heraus, das Sie vielleicht lesen möchten.

Chrysalis

Chrysalis ist das Zwischenstadium 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 auf das Mainnet aufgespielt. Das Engineering-Team arbeitet nun an Chrysalis Phase 2.

Implementierung von Chrysalis Phase 2

Das Chrysalis-Testnetz ist seit Dezember live. Seitdem haben wir die verschiedenen Client-Bibliotheken und Knoten-Implementierungen fertiggestellt. Diese sind nun größtenteils fertiggestellt, wobei alle APIs gesperrt sind. Dies ermöglicht es Partnern und Börsen, an ihren Integrationen zu arbeiten, ohne dass es zu Änderungen kommt. Die meisten Teams sind derzeit mit dem letzten Feinschliff der Integration beschäftigt oder mit weiteren Tests und der internen Prüfung der endgültigen Implementierungssoftware, wie z. B. der Client-Bibliotheken. Wir sind auch dabei, die Mechanismen für die Netzwerkmigration zu finalisieren – der Migrationsprozess ist etwas, das wir in den letzten Wochen getestet haben.

Wir arbeiten auch an der Chrysalis-Dokumentation, die immer noch in der Entwicklung begriffen ist.

Wir haben auch einen internen Build von Firefly getestet und ihn für den Test außerhalb von IF vorbereitet. Weitere Informationen zu Firefly finden Sie weiter unten.

Pollen

Das Team hat gerade ein wichtiges Upgrade des Pollen-Testnetzes veröffentlicht, v0.5.0. Dies ist die erste Version, die eine Mana-Implementierung enthält. Das Ziel dieser Version ist es, mit der Bewertung von Mana zu beginnen, bevor es in die Kernmodule, wie Staukontrolle, Fast Probabilistic Consensus (FPC), Distributed Random Number Generator (dRNG) und Autopeering, eingebunden wird.

Sie können mehr über Pollen, Nectar und Honey, Konzepte die wir eingeführt haben, um über die Meilensteine auf dem Weg zu Coordicide zu sprechen, in diesem Beitrag lesen.

Sie können das Projekt auf seinem GitHub-Repository verfolgen. Wenn Sie sich beteiligen möchten, schauen Sie sich unsere aktualisierten Richtlinien für die Mitarbeit an.

Bee

Das Bee-Team hat die erste Alpha-Version des Rust-basierten Knotens für das Chrysalis-Netzwerk veröffentlicht. Für Interessierte gibt es eine Anleitung, wie Sie Ihren Bee-Knoten betreiben können.

Das Dashboard wurde mit Authentifizierung aktualisiert und der Node wurde für die Chrysalis-Migration vorbereitet.

Für den Rest der Chrysalis-Funktionalität arbeitet das Team derzeit an den lokalen Snapshots und der MQTT-Unterstützung. Die erste Prüfung der Bee-Kisten ist ebenfalls abgeschlossen.

Das Team hat außerdem neue Live Coding Sessions veröffentlicht.

Hornet

Das Hornet-Team war weitgehend mit der Vorbereitung und Implementierung der Migrationsunterstützung für Chrysalis Phase 2 beschäftigt. Gleichzeitig wurden einige letzte Änderungen an der Chrysalis-Phase-2-Implementierung der Node-Software vorgenommen.

Das Team hat außerdem einen Gossip-on-Solidification-Mechanismus hinzugefügt, der die Verteidigung der Node-Software gegen Flooding-Attacken weiter abhärtet.

Smart Contracts

Das Team hat die erste große Version von Smart Contracts veröffentlicht, die es unserem Ökosystem ermöglicht, mit dem Aufbau zu beginnen. Das Release beinhaltet die Integration einer Multi-Chain-Umgebung, die durch den Tangle, den „Layer 1“, gesichert wird: Subnetze, bestehend aus Wasp-Knoten, die wir „Komitees“ nennen. Diese Komitees können viele Blockchains parallel darauf laufen lassen, ohne den Blick auf die Umgebung zu verlieren, die die digitalen Vermögenswerte von IOTA sichert, den Tangle. Jede solche Kette, die ein funktionales Äquivalent einer Ethereum-Blockchain ist, ist in der Lage, viele separate Smart Contracts zu hosten.

Stellen Sie sicher, dass Sie den Release-Post für weitere Informationen überprüfen.

Sie können die Updates in den Kanälen #smartcontracts-discussion und #smartcontracts-dev auf Discord verfolgen.

Stronghold

Der benutzerdefinierte Speicher-Allokator mit Guards und Canaries wurde für alle Desktop-Plattformen fertiggestellt – er wurde komplett neu geschrieben unter Verwendung der erstaunlichen libsodium-sys, die uns nun ein gut geprüftes und bewährtes System zum Schutz von IOTA-Seeds und anderen privaten Schlüsseln gibt, wenn sie sich im Speicher befinden und aktiv verwendet werden. Die Firewall für unseren Kommunikationsakteur wird gerade überprüft, und wir haben verifiziert, dass der Aufruf entfernter Prozeduren über libp2p wie erwartet funktioniert und so sicher wie möglich ist.

Nachdem das interne IOTA Engineering Department die gesamte Bibliothek überprüft hat, werden wir die Beta-Version von Stronghold Client, Engine und Runtime veröffentlichen.

Wallet

Firefly wurde letzten Montag in eine private Alpha-Testgruppe aufgenommen. Trotz des „Alpha“-Tags ist die App in einem sehr guten Zustand und wir sind fleißig dabei, alle von der Testgruppe gemeldeten Bugs zu beheben. Der größte Teil der Funktionalität ist bereits integriert, und wir implementieren derzeit parallel den Chrysalis-Migrationsfluss.

Wir werden einem expansiven Release-Plan mit regelmäßigen neuen Builds folgen, die alle gefundenen Probleme adressieren. Sie werden sehr bald hören, wie und wann Sie Firefly testen können.

IOTA-Identity

Das Identity-Team hat Version 0.2 veröffentlicht, die den Mechanismus zur Sperrung von Berechtigungsnachweisen, verbesserte Skalierbarkeit und ein neues WASM-Paket einführt.

Seitdem haben wir begonnen, auf eine Version 0.3 hinzuarbeiten, die auf dem Chrysalis Phase 2 Netzwerk läuft und das Stronghold Projekt nutzt. Schließlich wird sie die Erfahrung für Entwickler stark verbessern, indem sie eine zustandsbehaftete Account-Implementierung einführt, die einige der schwieriger zu erlernenden IOTA- und Identitäts-bezogenen Funktionen automatisiert.

IOTA-Streams

Zusammen mit Dell Technologies hat das Team im letzten Monat ein Update zur Demonstration des Projekts Alvarium veröffentlicht, einer Data Confidence Fabric, die mit IOTA Streams neu entwickelt wurde. Das Team hat die Chrysalis-Phase-2-Implementierung weitestgehend abgeschlossen, wobei WebAssembly noch aussteht.

IOTA-Erfahrungsteam

Dieser Monat war für die Mitglieder des IOTA Experience Teams mit viel Action gefüllt.

Die IOTA-Community, angetrieben vom Simplify X-Team, gab den Startschuss und falls Sie es verpasst haben, ist die Aufzeichnung des Meetings hier auf YouTube verfügbar. Darüber hinaus hat das Simplify X-Team bereits sein erstes Alignment Meeting abgehalten.

Das IOTA Smart Contracts X-Team, unter der Leitung von Evaldas Drąsutis, ISCP (IOTA Smart Contract Protocol) Lead bei der IOTA Foundation, hat mit seinem Treffen begonnen, die Aufzeichnung ist hier auf Youtube zu sehen.

Das andere 100% Community-getriebene IOTA Identity X-Team ist mit wöchentlichen Treffen jeden Montag um 20:00 Uhr MEZ sehr aktiv. Wenn Sie daran interessiert sind, digitale Identitätslösungen auf Basis von IOTA zu entwickeln, sollten Sie sich dem Experience Team und den Treffen anschließen.

Zu guter Letzt für das Update dieses Monats: Mitglieder des X-Teams wurden dank der vertrauensvollen Beziehung zwischen der IOTA Foundation und den X-Team-Mitgliedern eingeladen, an einem geschlossenen Alpha-Test von Firefly, der neuen IOTA-Wallet, teilzunehmen.

Wir begrüßen die neuesten Mitglieder des IOTA X-Teams:

kingofthemountain#4996, gzuma#3012, PIOTA#5143, nikoulai#3471, Nico#2240, aantunovic#7537, Alexander L#7208, InsaneBro#2045, DigitalSoul#7472, Kalila#3937, Vespabro#8592, Rhac#8549, egmcelroy#5568, MajidAkhtar273#7182, tukul#4212, avlo#7357, deniskov7#5059, okOkai#6849, adamski#0458, IOTANaut#6320, Rafael Brochado#6340 und iamadam#2178.

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

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

Original by Jakob Cech: https://blog.iota.org/dev-status-update-march-2021/

Was Sie über die bevorstehende Chrysalis Migration wissen müssen

Vor kurzem haben wir mehr Informationen über Chrysalis, das größte Upgrade in der Geschichte des IOTA-Netzwerks, geteilt. Dieser Beitrag wird Sie mit zusätzlichen Informationen rund um den Upgrade-Prozess versorgen.

Mit Chrysalis machen wir einen klaren Schnitt vom aktuellen IOTA-Protokoll und beginnen einen Neuanfang mit einem viel besseren und ausgereifteren Netzwerk. Das neue Netzwerk wird viele neue Anwendungsfälle unterstützen und eine Grundlage für IOTAs kommenden Coordicide schaffen.

Dies bedeutet, dass jeder seine Token vom aktuellen Netzwerk in das neue migrieren muss. Was folgt, ist eine Erklärung dieses Migrationsprozesses.

Migration zu Chrysalis

Der Migrationsprozess zu Chrysalis Phase 2 besteht aus zwei Phasen:

  1. Vor dem Chrysalis-Start – Guthaben, die in der Woche vor dem Chrysalis-Start migriert werden, sind direkt nach dem Start im neuen Netzwerk verfügbar.
  2. Nach dem Chrysalis-Start – Eine kontinuierliche Migration ermöglicht es den Nutzern, ihre Gelder jederzeit nach dem Chrysalis-Start in das neue Netzwerk zu übertragen.

Letztendlich gibt es keinen praktischen Unterschied zwischen diesen beiden Optionen und Sie können wählen, wann Sie migrieren möchten. Es wird jedoch empfohlen, dass Börsen vor dem Start des Netzwerks migrieren, um Unterbrechungen ihres Dienstes zu vermeiden.

wie migrieren ich meine iotas?

Token-Inhaber werden weiterhin in der Lage sein, ihre Token mindestens bis zum Coordicide zu migrieren. Sie sollten sich nicht unter Druck gesetzt fühlen, vor dem Start von Chrysalis zu migrieren, aber wir empfehlen, es zu tun, wenn Sie etwas Zeit zur Verfügung haben.

Migration Schritt- für Schrittanleitung durch Firefly

Der Migrationsprozess ist einfach. Ob vor oder nach Chrysalis, alles, was Sie tun müssen, ist, Ihren IOTA-Seed in die neue Firefly-Brieftasche einzugeben, und Firefly wird sich um alles andere kümmern.

Migrationsschritte in Firefly

  1. Sie geben Ihren Seed in Firefly ein
  2. Firefly erstellt Ihnen einen neuen Seed und generiert eine EdDSA-Adresse für das neue Netzwerk
  3. Firefly sendet Ihr Guthaben an eine vorher festgelegte Migrationsadresse im alten Netzwerk
  4. Ihr Guthaben wird in dem Netzwerk verfügbar, in der EdDSA-Adresse, die Firefly für Sie erstellt hat. Wenn Sie vor dem Start von Chrysalis migrieren, wird Ihr Guthaben zum Start von Chrysalis verfügbar. Wenn Sie nach dem Chrysalis-Start migrieren, wird Ihr Guthaben kurz nach der Migration zur Verfügung stehen.

Der Prozess ist für Ledger Nano Nutzer der gleiche. Sie schließen einfach Ihr Gerät an und Firefly führt Sie durch den Prozess.

Firefly wird zunächst nur auf Mac, Linux und Windows verfügbar sein.

Das ist alles, was Sie brauchen, um Ihre Gelder vom alten IOTA-Netzwerk zum neuen IOTA-Netzwerk zu migrieren. Es ist wirklich so einfach.

Wir werden eine Dokumentation und FAQs veröffentlichen, um die technischen Details zu erklären, sowie eine Anleitung, wie Sie Token programmatisch übertragen können.

Wir arbeiten mit den wichtigsten Börsen zusammen, um sicherzustellen, dass Gelder auf Börsen-Wallets automatisch auf das aktualisierte Chrysalis-Netzwerk migriert werden.

Dieser Beitrag gibt einen Überblick über den Migrationsprozess. Wir werden weitere Informationen zu den technischen Aspekten der Migration in einem Folgebeitrag veröffentlichen, zusammen mit einer FAQ auf unserer Dokumentations-Seite. Bleiben Sie dran!

Die technischen Details der Migration

muss ich meine iotas migrieren?

Vor Chrysalis

Sieben Tage vor dem Start von Chrysalis geschieht Folgendes:

  • Hornet-Release – wir werden eine neue Version unserer Node-Software „Hornet“ veröffentlichen. Diese Version von Hornet unterstützt Migrationstransaktionen. Das bedeutet, dass Leute mit dieser Hornet-Version ihre Fonds im Voraus migrieren können.
  • Firefly-Release – zusammen mit dem Update veröffentlichen wir eine öffentliche Version der Firefly-Wallet. Firefly wird als Hauptweg für Benutzer dienen, um Gelder vom alten auf das aktualisierte Chrysalis-Netzwerk zu migrieren.
  • Migrationsdokumentation – wir werden Leitfäden und Migrationsanleitungen für Token-Inhaber und Entwickler veröffentlichen.

Bei Chrysalis-Veröffentlichung

Sieben Tage nach Beginn des Migrationszeitraums starten wir Chrysalis:

  • Coordicide wird auf dem Legacy-Netzwerk gestoppt – Meilensteine werden nicht mehr ausgegeben.
  • Neuer Netzwerk-Snapshot – Wir werden einen Ledger-Status-Snapshot des Legacy-Netzwerks erstellen. Dieser Snapshot wird mit der Community geteilt, zusammen mit einer Anleitung, wie er zu validieren ist (so wie wir es in der Vergangenheit mit globalen Snapshots gemacht haben). Sobald er validiert ist, wird er als Basis für den Genesis-Ledger-Status des neuen Chrysalis-Netzwerks dienen. Das bedeutet, dass das Chrysalis Netzwerk mit Guthaben auf den vor dem Start migrierten Adressen starten wird.
  • Freigabe von Chrysalis Hornet und Bee – Die Chrysalis-Versionen unserer Node-Software in Go und Rust werden für den Einsatz im neuen Netzwerk zur Verfügung gestellt.
  • Freigabe der Chrysalis-Bibliotheken und anderer Produkte – Die Chrysalis-Versionen unserer Client-Bibliotheken und -Produkte werden für den Einsatz im neuen Netzwerk verfügbar gemacht.
    Nach der Freigabe von Chrysalis

Sowohl das alte Mainnet als auch das neue Chrysalis-Netzwerk werden in Betrieb sein. Benutzer können jederzeit frei Gelder aus dem alten Netzwerk migrieren und die Gelder werden im neuen Netzwerk fast sofort verfügbar sein. Die Mittel werden den EdDSA-Adressen über Meilensteine zugewiesen, die auf den Migrationsinformationen aus dem alten Netzwerk basieren. Der Gesamtvorrat an Token wird im alten und im neuen Netzwerk gleich groß sein.

Original by Jakub Cech: https://blog.iota.org/chrysalis-migration-process/

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/