Schlagwort: Update

Dev Status Update – Juni 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 über einen Monat her, dass wir Chrysalis im Mainnet veröffentlicht haben. Sie können alles über die Freigabe hier nachlesen. Bis jetzt sind über 45% aller Token in das neue Netzwerk migriert worden!

Die Entwicklungsabteilung konzentriert sich nun darauf, ihre Bemühungen auf Coordicide zu verlagern, unsere Smart-Contract-Fähigkeiten weiterzuentwickeln und Ledger-Unterstützung in der Firefly-Wallet anzubieten.

Nektar

Erst letzte Woche haben wir das IOTA 2.0 DevNet gestartet, das erste vollständig dezentralisierte IOTA-Netzwerk ohne die Notwendigkeit eines Koordinators, zusammen mit unserem neuen Digital Assets Framework. Schauen Sie sich die schicke neue Website, den Tangle-Explorer und die Entwicklerdokumentation an.

Bee

Das Bee-Team hat die Version 0.1.0 der Node-Software mit dem Chrysalis-Release veröffentlicht und arbeitet seitdem an Korrekturen und Verbesserungen der Node-Software, sowie der Veröffentlichung einer 0.1.2-Version von Bee. Für Interessierte gibt es eine Anleitung, wie Sie Ihren Bee-Knoten betreiben können. Das Team bereitet auch die Arbeit für eine Rust-Version des Coordicide-Knotens vor, wobei die Komponenten der Chrysalis-Version wiederverwendet und verbessert werden.

Hornet

Das Team hat sich hauptsächlich auf das Hinzufügen von Autopeering-Funktionalität zu Hornet sowie auf die Behebung ausstehender Probleme konzentriert. Autopeering wird Teil der nächsten Hornet-Version sein.

Smart Contracts

Seit der letzten Veröffentlichung des IOTA Smart Contract Protokolls hat das Team hart daran gearbeitet, die Software zu verbessern und sicherzustellen, dass ISCP mit dem IOTA 2.0 (Nectar) Testnetzwerk kompatibel ist. Hierfür wurden neue Ausgabetypen implementiert und die Wasp-Knoten-Software wurde refaktorisiert, um alle Änderungen unterzubringen. Ein neuer Ketten-Konsens-Mechanismus wurde implementiert, und es gibt gute Fortschritte bei der Integration von EVM-Unterstützung sowie bei der vollständigen Unterstützung von Solidity-Smart Contracts. Mit der nächsten Version, die vollständig programmierbar ist, werden Smart Contracts auf dem IOTA 2.0 Testnetz Realität werden.

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

Stronghold

Die Kommunikationskiste erhält derzeit eine letzte Überarbeitung, um ihre Schnittstelle actor-model-agnostisch zu machen, und wir fügen weitere Tests hinzu, insbesondere für die Firewall-Funktion. Um das Fehlen von unerwartetem Verhalten zu verifizieren, bauen wir einen Fuzzer, der die Kommunikationsschnittstelle zwischen zwei Clients nutzt. Schließlich bauen wir eine Tauri-Demo-App, damit wir nicht nur die Methoden der Fernsignierung validieren können, sondern auch als Testumgebung für binäre Instrumentierung, die beweisen wird, dass unser Speicherschutz wie erwartet funktioniert.

Außerdem werden Tutorial-Videos von Tensor Programming vorbereitet, damit die gängigen Anwendungsfälle von Stronghold verstanden und umgesetzt werden können.

Wallet

Mit sehr wenigen Fehlern seit der Produktionsfreigabe von Firefly konzentriert sich das Wallet-Team darauf, Unterstützung für Ledger Nano hinzuzufügen. Die Flows „Create New Wallet“ und „Import Existing Wallet“ wurden implementiert, und das Senden und Empfangen von Geldern funktioniert gut. Wir arbeiten derzeit an der Chrysalis-Migration für Ledger und den verschiedenen Abläufen dort, einschließlich Bundle Mining. Wir polieren auch einige UX-Details, um sicherzustellen, dass die Benutzererfahrung nahtloser ist als die ursprüngliche Trinity Ledger Integration. Das Team hat auch mit dem Bibliotheks-Team an einigen Leistungsverbesserungen für wallet.rs gearbeitet, einschließlich der Nicht-Blockierung verschiedener Funktionen und der Beschleunigung der Synchronisationszeiten.

Es ist allmählich klar geworden, dass das Firefly-Team einfach noch nicht groß genug ist, um unsere ehrgeizigen Pläne zu unterstützen, und so sind wir dabei, das Team zu erweitern. Wir stellen 3-4 neue Teammitglieder ein, damit wir Firefly Mobile und kommende Features wie NFTs und Kontakte in einem schnelleren Zeitrahmen bauen können.

IOTA-Identität

Nach dem Beta-Release plant das Team die nächsten Schritte und überarbeitet einige Teile der Codebasis. Wir erforschen und entwerfen eine gute Architektur für zukünftige Bindungen an andere Sprachen, wie C und Python, und unterstützen Plattformen, die von gängigen Betriebssystemen über das Web bis hin zu ESP32s reichen. Wir haben auch das neue Teammitglied Philipp Gackstatter begrüßt und sehen ein gutes Wachstum des Identity-Interesses in der Community. Diese Woche hatten wir eine Rekordzahl an wöchentlichen NPM-Downloads und Teilnehmern am wöchentlichen Identity X-team Call.

Chronik

Das Team war damit beschäftigt, Korrekturen an der Chrysalis-Version von Chronicle vorzunehmen. Der Fokus liegt nun auf zusätzlicher Funktionalität, hauptsächlich selektiver Transaktionsspeicherung.

IOTA-Erfahrungsteam

Diesen Monat treiben die Mitglieder des X-Teams verschiedene Ziele voran und tragen dazu bei.

Eine Gruppe von X-Team-Mitgliedern, zu denen adamski, Phylo, Jeroen van den Hout und Dr. Electron gehören, arbeiten sehr eng mit dem UI/UX-Team und den technischen Redakteuren der IOTA Foundation zusammen, um ein Wiki zu veröffentlichen, das eine erste Anlaufstelle für Informationen über IOTA und die Community bietet und gleichzeitig die epische Arbeit des Ökosystems unterstützt, indem es Besucher zu den tiefergehenden Dokumenten, Repos, Blogs, weiteren Informationen und allem anderen IOTA führt.
Nehmen Sie Kontakt auf, wenn Sie etwas beitragen möchten!

IOTA Wiki

Simplify X-Teammitglied Phylo hat eine Anleitung in zwei Teilen zum Einrichten eines HORNET-Knotens veröffentlicht, die dank des Feedbacks und der Unterstützung des Teams nun hier verfügbar ist:

Phylo hat auch stark zu den Kanalbeschreibungen des IOTA Discord beigetragen!

IOTA Discord

Erfahren Sie hier, wie Sie zu dieser Initiative beitragen können.

Am 1. Juni lud das Bee-Team die Mitglieder des Bee X-Teams ein, um über das Packable-Feature zu sprechen und eine Rust-Live-Coding-Session abzuhalten!

IOTA Meeting

Wenn Sie ein Rust-Entwickler sind, stellen Sie sicher, dass Sie dem Bee X-Team beitreten, um Ihre Erfahrungen zu teilen oder neue von dem Team zu gewinnen, das an dem rustlang-Framework zur Erstellung von IOTA-Knoten, -Clients und -Anwendungen in Rust arbeitet.

Bee X-Team-Mitglied Dr. Electron hat seinen ersten PR für Coordicide im Bee-Repository auf GitHub veröffentlicht! Dies ist ein Paradebeispiel dafür, wie jeder zur Zukunft des IOTA-Protokolls beitragen kann.

IOTA Discord Aufruf

Eines unserer jüngsten IOTA Libraries X-Team-Mitglieder, SourCL | Stefan, hat eine PHP-Bibliothek zur Interaktion mit der IOTA REST API entwickelt und veröffentlicht.

Der Start des IOTA 2.0 DevNet war ein großer Erfolg. In diesem Zusammenhang möchten wir uns für die grundlegenden Beiträge der GoShimmer X-Team Mitglieder bedanken:

Luca, SteveK, nikoulai, Phylo, Jack Kerouac,Dave [EF], Myhrmans, Brian Sztamfater, Xee Vee, Stefano Della Valle, emanuelneher, luka, Chris G., Dr. Electron, Maik Piel, Carpincho Dem, MaKla, Rafael Brochado, anistark, H., ReneW, Werner, poster, StromFLIX, Khal Drogo, javitech, Callinectes und eot

Diesen Monat begrüßen wir die neuesten Mitglieder des IOTA X-Teams: dmade, davinki, chrispilot, dan c, SourCL | Stefan, future_yacht_owner, poster, Sefear, Werner, CrashOverride, Brennan, MzK91/VoteForDAO und UnCoined#9234.

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.

Es ist jetzt auch möglich, dem IOTA Experience Team auf Twitter zu folgen: https://twitter.com/IOTAXTeams.

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

Original By Jakub Cech: https://blog.iota.org/dev-status-update-june-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/

Dev Status Update – April 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 die Zwischenstufe des Mainnets, 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 im Mainnet bereitgestellt. Das Engineering-Team arbeitet nun an Chrysalis Phase 2.

Wir raten außerdem allen, unseren Blog-Beitrag über „Sicherheit während der Token-Migration“ zu lesen, um für die Netzwerk-Migration, die am 21. April beginnt, gerüstet zu sein.

Implementierung von Chrysalis Phase 2

Da Chrysalis kurz vor der Tür steht, arbeitet das Team mit Hochdruck an den letzten Feinheiten, damit sowohl am 21. April als auch am 28. April alles so reibungslos wie möglich abläuft. Es werden Tests auf mehreren Instanzen der Infrastruktur durchgeführt, um alle Migrationsszenarien zu testen. Wir haben auch bereits die Chrysalis Mainnet-Infrastruktur bereitgestellt, die das aktuelle Mainnet ersetzen wird. Diese wird am Tag des Starts, dem 28. April, zurückgesetzt und macht aus dem aktuellen Mainnet ein Legacy Mainnet.

Die Migration wird über Firefly-Builds sowohl in einer internen als auch externen Benutzergruppe getestet (ein großes Dankeschön an die X-Teams dafür!).

Wir sind sehr gespannt auf den Chrysalis-Start. Dies wird wirklich ein neuer Anfang für das IOTA-Protokoll sein. Wir freuen uns darauf, zu sehen, was ihr auf dem Protokoll aufbaut, und auf all die Szenarien, Einsätze und Anwendungsfälle, die nach Chrysalis auftauchen werden. Chrysalis ist wirklich das bedeutendste Update in der Geschichte von IOTA.

Wenn Sie alle Neuigkeiten und Updates zu Chrysalis verfolgen wollen, besuchen Sie unbedingt die Status-Seite. Die Seite wird mehr Informationen enthalten, wenn wir uns dem 28. April nähern.

Pollen

Das Team hat mehrere Versionen des Pollen-Testnetzes veröffentlicht. Pollen 0.5.0 führte unser Reputationssystem ein – Mana. Mit der neuesten Version 0.5.6. Die Knoten verfügen nun über einen Mana-Bereich, der in das lokale Dashboard, das Pollen-Analyzer-Dashboard und das Grafana-Dashboard integriert ist. Zugriffs- und Konsens-Mana kann nun mit GUI- und CLI-Wallets an bestimmte Knotenidentitäten verpfändet werden.

Sie können mehr über das Update im Forschungsupdate von letzter Woche und in den verschiedenen Mana Release Posts lesen.

Sie können das Projekt auf seinem GitHub-Repository verfolgen. Wenn Sie sich beteiligen wollen, 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 den Bee-Knoten betreiben können.

Das Dashboard wurde mit Authentifizierung – via JWT – aktualisiert und der Knoten wurde für die Chrysalis-Migration vorbereitet.

Der größte Teil des Codes wurde ordnungsgemäß dokumentiert, getestet und in den Dev-Zweig des Repositorys eingefügt.

Für den Rest der Chrysalis-Funktionalität hat das Team MQTT-Unterstützung, lokalen Snapshot und Pruning implementiert und diese Funktionen werden derzeit getestet. Die erste Prüfung der Bee Crates ist ebenfalls abgeschlossen.

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

Hornet

Die Tests der Chrysalis-Version von Hornet sind im Gange. Im vergangenen Monat hat das Team außerdem mehrere Änderungen und Korrekturen an der Node-Software vorgenommen, zum Beispiel bei der DB-Revalidierung, MQTT und mehr. Wir arbeiten auch an der Dokumentation für die Chrysalis-Version von Hornet.

Genau wie in Bee wurde das Dashboard mit Authentifizierung aktualisiert – via JWT

Das Hornet-Team hat auch an Verbesserungen des Cachings gearbeitet. Diese Verbesserungen werden erst nach Chrysalis Phase 2 veröffentlicht.

Smart Contracts

Das Team hat Anfang März die erste große Version von Smart Contracts veröffentlicht. Stellen Sie sicher, dass Sie den Release-Post für weitere Informationen überprüfen. Seitdem haben wir uns stark auf das Refactoring der Integration konzentriert, um die neuesten Änderungen in Pollen widerzuspiegeln, sowie das Hinzufügen neuer Ausgabetypen, um ISCP auf Layer 1 zu unterstützen.

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

Stronghold

Die Beta-Version von Stronghold wurde veröffentlicht, überarbeitet und befindet sich derzeit in der externen Prüfung. Die letzte Überarbeitung des Vault spart 97 % der früheren Zeit zum Schreiben/Abrufen eines Datensatzes ein, und mit Ausnahme des Schreibens eines Snapshots (das einige Millisekunden dauert), verwenden alle Benchmarks jetzt Mikrosekunden für die Messungen. Wir haben auch die Größe der Snapshots auf etwa ein Drittel ihrer früheren Masse reduziert.

Wir arbeiten mit dem IF-Kryptographie-Team zusammen, um Methoden für die Durchführung von Multisig mit Strongholds interner libp2p-noise-basierter Kommunikationskiste zu identifizieren. In der Tat liegt unser Hauptaugenmerk jetzt auf der Verifizierung und Validierung dieser Crate und ihrer Prozesse.

Wallet

Firefly wurde in den letzten Wochen intensiv getestet, wobei das Team fleißig die von der Testgruppe gemeldeten Fehler behoben hat. In letzter Zeit haben wir sowohl interne als auch begrenzte öffentliche Builds der Migrationsversion von Firefly getestet. Die Migrationsversion von Firefly unterstützt sowohl die Vormigrationsphase, die am 21. April beginnt, als auch die flüssige Migration, die am 28. April startet.

Nach Chrysalis wollen wir unseren Fokus auf die mobilen Versionen von Wallet verlagern.

IOTA-Identität

Das Identity-Team wurde vom Filancore-Team unterstützt, um die Qualität des Repositorys weiter zu verbessern und es so schnell wie möglich in eine Beta-Version zu überführen. Mit ihrer Hilfe hat IOTA Identity nun eine bessere Testabdeckung, verbesserte Dokumentation, bessere Beispiele und läuft auf Chrysalis Phase 2. Zusätzlich haben sie daran gearbeitet, das Feature DID Communication (ein Standard der Decentralized Identity Foundation) zu spezifizieren und in das Framework zu implementieren.

In der Zwischenzeit hat das Team an der Stronghold-Integration und dem Account-Modul gearbeitet und damit die Benutzerfreundlichkeit des Frameworks massiv verbessert. Wir sind auch dabei, die DID-Methodenspezifikation fertigzustellen, um sie bei der W3C DID Method Registry einzureichen. Alles in allem war es ein sehr produktiver Monat mit spannenden Verbesserungen. Wir werden wahrscheinlich mit einer Veröffentlichung warten, bis das Chrysalis-Update live ist.

Chronicle

Wir haben bereits eine Chrysalis-Phase-2-Version von Chronicle in unserem Testnetzwerk im Einsatz. Wir werden die neue Version von permanode freigeben, damit jeder seinen eigenen Chronicle auf dem neuen Chrysalis-Netzwerk einsetzen kann.

IOTA-Erfahrungsteam

Große Fortschritte in diesem Monat durch die Mitglieder des IOTA Experience Teams.

Dank des von der IOTA-Community angetriebenen Simplify X-Teams wurde die Umstrukturierung von Discord abgeschlossen. Die Channels sind nun in Kategorien strukturiert und die Farben der Discord-Rollen haben nun eine gewisse Logik. Die nächsten Schritte sind, nach Wegen zu suchen, um die „Channel-Müdigkeit“ bei der langen Liste von Channels, die der IOTA Discord bietet, zu reduzieren.

Eine weitere greifbare Errungenschaft ist der aktualisierte IOTA-All-in-one-Thread auf dem IOTA-Subreddit, der Ressourcen über IOTA sammelt; stellen Sie sicher, dass Sie ihn mit Neulingen in der IOTA-Community teilen.

Das Simplify X-Team hat neue Ziele vorgeschlagen, wie z.B. das Erstellen einer IOTA-Beschreibung für Exchanges/Websites oder das Erstellen einer einfachen Schritt-für-Schritt-Anleitung für Nicht-Techniker, wie man einen IOTA-Knoten einrichtet und betreibt, diese Ziele sind perfekt für Nicht-Entwickler, die zur IOTA-Vision beitragen wollen. Schauen Sie sich die Liste der Ziele hier an und machen Sie mit!

X-Team-Mitglieder aus verschiedenen Initiativen testen die Firefly-Wallet und die Firefly-Token-Migrationsprozedur, um Feedback über die Benutzererfahrung zu geben und reichen Probleme ein, um dem Team zu helfen, Fehler zu finden, Erweiterungen vorzuschlagen und Verbesserungen vorzuschlagen. Andere IOTA-Community-Mitglieder helfen bei der Internationalisierung von Firefly, indem sie die Anwendung übersetzen. Schließen Sie sich uns auf Crowdin an und tragen Sie zur Annahme von Firefly bei, indem Sie die Übersetzung in Ihrer ersten Sprache hinzufügen oder verifizieren.

Fortschritt Übersetzung

Das Community-getriebene IOTA Identity X-Team hält jeden Montag um 20:00 Uhr MEZ wöchentliche Treffen ab. 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 noch ein Update für diesen Monat:
Wenn jemand in der IOTA-Community ein Podcast-Setup oder ein gutes Mikrofon hat und eine Community-getriebene Initiative diskutieren möchte, dann melden Sie sich!

Die Idee hinter dieser Initiative ist ein monatlicher Podcast, in dem über das gesprochen wird, was der Community gefallen hat und der im Kanal #community-highlights auf Discord gepostet wird.

Ein 5-10-minütiger Podcast zum Anhören, während unsere Community-Mitglieder pendeln oder Kaffee trinken.

Das Ziel ist es, die Reichweite dessen, was in der Community passiert ist und von anderen Community-Mitgliedern interessant gefunden wurde, von der Community für die Community zu erweitern.

Beteiligen Sie sich an der Diskussion über diese Initiative im Kanal #experience auf Discord!

Diesen Monat begrüßen wir die neuesten Mitglieder des IOTA X-Teams:

Agi#5701, jvdhout#4402, merul.isAwesome()#2114, gman_IoTangle#7856 und Myhrmans#7816.

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.

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: https://twitter.com/iota

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

IOTA Forschungsstatus – Update April 2021

Dieser Monat war sehr arbeitsreich für uns, da wir uns auf die Zielgerade auf dem Weg zur Auslieferung von Nectar begeben, der ersten vollständigen Implementierung unseres vollständig dezentralisierten, koordinatorenfreien Netzwerks, die in ein paar Wochen erwartet wird! Unsere Gruppen haben alle hervorragende Fortschritte bei der Umsetzung unserer Forschungsergebnisse in brauchbare Komponenten gemacht, ein Ziel, auf das wir stolz sind, unseren Teil dazu beizutragen.

Einige wichtige Errungenschaften in diesem Monat haben den Fortschritt in Richtung der Freigabe der Nectar-Stufe unseres koordinatorfreien Netzwerks vorangetrieben, darunter: die Implementierung von mana in das Pollen-Testnetz, was uns erlaubt, Angriffe unter realistischen Netzwerkbedingungen zu untersuchen; die fast vollständige Fertigstellung unserer formalen Spezifikationen, was uns erlaubt, das Protokoll besser an Partner und andere interessierte Parteien zu kommunizieren, sowie die Grundlage für die Standardisierung des IOTA-Protokolls zu schaffen; und die Fertigstellung unseres Autopeering-Papiers, welches eine Validierung einer unserer Netzwerkkomponenten darstellt. Im Folgenden finden Sie Updates aus unseren Forschungsgruppen, die diese und andere Fortschritte des letzten Monats detailliert beschreiben:

Pollen Testnet Implementierung

Das Team hat mehrere Iterationen des Pollen-Testnetzes ausgerollt, beginnend mit v0.5.0, das Mana (das Reputationssystem) sowie die Staukontrolle (die den Zugriff auf das Tangle regelt) einführte, um die erste Iteration zu testen und die Verteilung in einer solchen Umgebung zu untersuchen. Mit dieser Version fügten wir eine Reihe neuer APIs, einen neuen Mana-Abschnitt auf dem lokalen Dashboard, dem Pollen Analyzer Dashboard sowie auf dem Grafana Dashboard hinzu. Sowohl die GUI- als auch die CLI-Wallets wurden aktualisiert, um dem Benutzer die Möglichkeit zu geben, die Identität des Knotens als Empfänger des Zugriffs- und Konsens-Mana-Pfandes einer Transaktion zu definieren.

Wir haben auch die Consensus-Manager-Komponente refaktorisiert, um agnostisch in Bezug auf die tatsächlich implementierten Konsensmechanismen zu sein. Auf diese Weise kann GoShimmer nicht nur als IOTA 2.0-Prototyp, sondern auch als flexibles Framework für jede DAG-basierte DLT gesehen werden. Tatsächlich kann jeder Konsens-Mechanismus, wie z.B. On Tangle Voting, BFT, Leader-basiert und mehr, so einfach wie das Ändern von nur ein paar Zeilen in der Tangle-Initialisierung eingesteckt werden. Mit den nachfolgenden Versionen haben wir begonnen, die ersten Komponenten in mana zu integrieren, nämlich das Fast Probabilistic Consensus (FPC-Protokoll) und das Autopeering. Bislang hat unser Konsensmodul die Meinungen aller Knoten gleich behandelt. Dies bietet jedoch keinen Schutz gegen Sybil-Angriffe, bei denen Angreifer hunderte oder sogar tausende von Knoten betreiben, um den Konsens zu stören. Mit der Integration von Mana bilden die Knoten nun ihr Quorum, indem sie die abzufragenden Knoten proportional zu ihrem Mana auswählen.

Um Sybil-basierte Angriffe zu verhindern/einzuschränken, nutzt das Autopeering einen Screening-Prozess namens Mana-Rank, der eine Teilmenge aus allen bekannten Knoten basierend auf ihrer Mana-Ähnlichkeit auswählt. Das bedeutet, dass Knoten mit ähnlichem Mana mit größerer Wahrscheinlichkeit zu Nachbarn werden. Wir können die Auswirkungen bereits in der Topologie des Pollen-Netzwerks sehen:

tangle pollen

Knoten im linken Teil des Netzwerkgraphen haben mehr Konsensmana, während im rechten Teil Knoten mit weniger oder null Mana zu sehen sind. Mit diesem Experiment versuchen wir, die richtigen Parameter zu finden, um ein gutes Gleichgewicht zwischen Sybillenschutz und Netzwerkkonnektivität zu finden. Derzeit haben wir ein Netzwerk mit mehr als 200 Knoten und einem Netzwerkdurchmesser von 5.

In den kommenden Wochen wird sich das Team auf die Integration von mana mit den restlichen Modulen konzentrieren: Congestion Control, Finality (Zulassungsgewicht), Reorg und dRNG. Als letzte Meilensteine vor Nectar werden wir Snapshots und Timestamp-Voting einführen. Sobald diese fertig sind, wird Nectar bereit sein, der Öffentlichkeit vorgestellt zu werden.

Spezifikationen

Die Fortschritte bei den Spezifikationen sind stetig, und wir arbeiten nun mit dem Ziel, die Hauptkomponenten etwa zum Zeitpunkt des Upgrades auf Nectar fertig zu haben. Der gesamte Prozess wird vollständig dokumentiert und standardisiert, so dass wir besser kontrollieren können, wie der Fortschritt verläuft und wissen, welche Module noch unterstützt werden müssen.

Lassen Sie uns ein wenig über die Struktur des Projekts sprechen. Im Moment sind die Dateien in 7 Abschnitte unterteilt, die sich auf ihre Rolle im Projekt oder im Netzwerk beziehen: Steuerdateien, Strukturdateien, Netzwerkschicht, Kommunikationsschicht, Wertübertragungsanwendung, Konsensanwendung und Verlaufsverwaltung.

In den Steuerdateien geht es um die Informationen, die sich auf jede Datei beziehen und die Standardisierungsrichtlinien und die Organisation definieren. Hier ist der Index der Parameter- und Terminologiedateien zu erwähnen, der diese Informationen über die Dateien an einem einzigen Referenzort erhält. Structure Files enthält wesentliche Informationen über die Datenelemente, die Teil des Tangle sind. Hier findet man das brandneue Message Layout, die wichtigsten Payload Layouts sowie den Datenfluss, den eine Nachricht durchläuft, um von einem Knoten verarbeitet zu werden.

Network Layer befasst sich mit der Kommunikation zwischen den Knoten, einschließlich der Bootstrapping-Methodik und aller Autopeering-Module. Communication Layer, wahrscheinlich unser umfangreichster Abschnitt, zeigt das Protokoll für einen Knoten, um sein Tangle zu pflegen. Dies beinhaltet einen Großteil der Module über das Tangle selbst, wie z. B. Zeitstempel, Spitzenauswahlalgorithmus, Verfestigung, Raten- und Staukontrolle und Marker. Werttransfer-Anwendung definiert die Richtlinien für alles, was mit dem Ledger zu tun hat, wie die UTXO-Systematik, Ledger-Zustandsberechnungen und alle Richtlinien über Mana.

Konsensanwendungen, wie der Name schon sagt, ist die Spezifikation über alles, was mit dem Konsens zu tun hat. Hier findet man alle Informationen über den schnellen probabilistischen Konsens (FPC), den dezentralen Zufallszahlengenerator (dRNG), die Reorganisation der Knotenwahrnehmung und die Finalität. Schließlich wird in der History-Verwaltung der Prozess des Snapshotings detailliert beschrieben.

Dies zeigt ein wenig die umfangreiche Natur des Projekts. Von unserem anfänglichen Stapel von 20 Dateien haben bereits 7 die Revision durchlaufen und viele andere stehen kurz vor der Fertigstellung. Wir erwarten im Laufe des Aprils einen großen Fortschritt und hoffen, diesen bald mit der Community teilen zu können.

Pollen Testnet Studiengruppe

Während des letzten Monats haben wir unser erstes Forschungspapier über unser salzbasiertes Autopeering fertiggestellt und eingereicht. Dieses Papier diskutiert mehrere unserer Designentscheidungen und präsentiert eine erste quantitative Behandlung einiger Anforderungen an die Netzwerktopologie. Nachdem wir das Mana in das Autopeering in Pollen integriert haben, setzen wir unsere Forschung an diesem Modul von Coordicide fort.

Wir analysierten auch die Verteilung und Dynamik von Zugriffsmana und Konsensmana im aktuellen Testnetz. Ein besonderes Ergebnis dieser ersten Analyse ist eine Anpassung des „Glättungsparameters“ des Zugriffsmanas; eine Änderung des Zugriffsmanas wird in viel kürzerer Zeit wirksam als in unserem ersten Vorschlag.

Vernetzung

Diesen Monat haben wir an einer Strategie gearbeitet, um Knoten zu synchronisieren, die vorübergehend offline sind oder Neulinge, die dem Netzwerk zum ersten Mal beitreten. Es ist sehr wahrscheinlich, dass diese Knoten viele Nachrichten verpasst haben, die bereits verarbeitet und an ihre lokale Version des Ledgers angehängt sein sollten. Bei Verwendung der festen Scheduling-Rate kann es zu langen Verzögerungen kommen, bis die Knoten synchronisiert sind. In unserem Vorschlag ermöglichen wir eine höhere Scheduling-Rate für den Fall, dass ein Knoten als „out-of-sync“ gekennzeichnet ist: in der aktuellen Version von GoShimmer werden Beacon-Nachrichten verwendet, um out-of-sync-Knoten zu erkennen, aber wir planen, einen Mechanismus ähnlich einem Leaky Bucket (der die Rate opportunistisch erhöht) zu bauen, der automatisch Netzwerkstörungen oder Paketverluste erkennt.

Das zweite Hauptthema des Monats war die Feinabstimmung des Algorithmus zur Staukontrolle. Insbesondere führten wir eine umfangreiche Angriffsanalyse durch und stellten fest, dass Angreifer benachbarte Knoten mit einer verfälschten Wahrnehmung der aktuellen Verkehrsüberlastung belegen können. Die Unterschätzung der Überlastung führt zu einer Erhöhung des vom Ratenregler erlaubten Durchsatzes. Wir arbeiten derzeit an Gegenmaßnahmen, um mit diesem Eckfall umzugehen. Wir möchten betonen, dass dieses Szenario nur bei voller Auslastung des Netzwerkdurchsatzes relevant ist. Daher wird unser Protokoll in unmittelbarer Zukunft nicht betroffen sein.

Sharding

Wir machen weiterhin Fortschritte bei unserem White Paper zum Thema Data Sharding. Im vergangenen Monat haben wir ein Brainstorming über zusätzliche Angriffsvektoren durchgeführt. Obwohl wir ein besseres Verständnis der bisherigen Angriffsvektoren gewonnen haben, haben wir keine neuen grundlegenden Schwachstellen gefunden. Somit scheint unser Vorschlag für die Datensplittung robust gegen eine Vielzahl von bösartigen Verhaltensweisen zu sein.

Wir diskutierten auch weitere Möglichkeiten zur Modellierung des Wachstums von Datenwirrwarr, um zu versuchen, den potenziellen Durchsatz des Systems besser abzuschätzen. Wir begannen mit der Arbeit an der Erstellung von Simulatoren, um die Erstellung von Child Tangles zu modellieren und auch um Interaktionen zwischen Parent und Child Tangles zu modellieren. Diese Simulationen werden verwendet, um unser Verständnis und unsere Annahmen über das Verhalten des Systems zu verifizieren.

Da viele der anfänglichen theoretischen Fragen geklärt sind, müssen wir jetzt nur noch das White Paper fertigstellen. Das größte Hindernis ist im Moment, die Arbeitsstunden zu finden, die wir für das Schreiben aufwenden können, da alle unsere Forscher auch an der Fertigstellung von Nectar beteiligt sind.

Original by William Sanders: https://blog.iota.org/iota-research-status-updateapril-2021/

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.

Pollen Testnet v.0.5.0 – Die Reise mit Mana

Pollen Testnet v0.5.0 – Wir beginnen unsere Reise mit Mana

Wir veröffentlichen eine neue Version unseres Pollen-Testnetzes v0.5.0. Mit dieser Veröffentlichung beginnen wir offiziell unsere Reise mit Mana. Das erste Ziel ist es, die erste Wiederkehr der Mana-Implementierung zu testen, um die Verteilung im Pollen-Testnetz zu untersuchen, nach eventuellen Fehlern zu suchen und allgemein die Stabilität zu beurteilen. Nach dieser Phase werden wir unsere Kernmodule, wie die IOTA-Staukontrolle, den Fast Probabilistic Consensus, das Autopeering und den verteilten Zufallszahlengenerator Mana als Sybil-Schutzmechanismus nutzen lassen.

Die vollständige Liste der Änderungen beinhaltet:

  • Hinzufügen von Mana (wird derzeit von keinem der Module verwendet)
  • Hinzufügen von Mana-APIs
  • Hinzufügen des Mana-Abschnitts zum lokalen Dashboard
  • Hinzufügen des Mana-Abschnitts zum Pollen Analyzer Dashboard
  • Hinzufügen des Mana-Abschnitts zum Grafana-Dashboard
  • Refactor des Consensus Managers, um unabhängig von dem konkret implementierten Konsensmechanismus zu sein
  • Verbessern des Tangle-Visualisierers
  • Verbessern der Dokumentation

Wie bei der vorherigen Version werden auch in dieser Version das Netzwerk und das Tangle sowie alle Guthaben und tokenisierten Assets zurückgesetzt.

Außerdem wurde eine neue GUI-Pollen-Wallet-Version veröffentlicht.

Diese Version bringt eine Reihe neuer APIs, einen neuen Mana-Bereich auf dem lokalen Dashboard, dem Pollen Analyzer Dashboard sowie auf dem Grafana Dashboard. Sowohl die GUI- als auch die CLI-Wallets wurden aktualisiert, um dem Benutzer die Möglichkeit zu geben, die Identität des Knotens als Empfänger des Zugriffs und des Konsens-Mana-Pledge einer Transaktion zu definieren.

Hier ein Screenshot des Mana-Abschnitts des lokalen Dashboards des Knotens:

Pollen Testnet 0.5

Die Dokumentation der Mana bezogenen APIs und Client-Libs finden Sie in unserem Wiki sowie hier.

In der aktuellen Implementierung basieren Konsens- und Zugriffs-Mana auf den Berechnungsmethoden Mana1 bzw. Mana2. Das bedeutet, dass beide einem gleitenden Durchschnitt folgen, aber bei Mana2 gibt es zusätzlich einen Verfallsfaktor. In der Praxis bedeutet dies, dass das Konsens-Mana, sobald das Mana zugesagt wurde, schneller ansteigt als das Zugriffs-Mana, da es abnimmt. Durch regelmäßiges Auffrischen des Zugriffs-Mana wird sichergestellt, dass sein Wert aktiv bleibt. Wir haben auch noch eine dritte Art von Mana, die wir untersuchen wollen. Das ist eine Kombination aus Mana1 und Mana2, deren Gewicht durch einen Koeffizienten definiert ist.

Obwohl die Einführung von Mana eindeutig die wichtigste Funktion dieser Version ist, wurde eine ebenso wichtige Änderung an GoShimmer vorgenommen. Wir haben die Consensus-Manager-Komponente so umgestaltet, dass sie agnostisch in Bezug auf die tatsächlich implementierten Konsensmechanismen ist. Auf diese Weise kann GoShimmer nicht nur als der IOTA 2.0-Prototyp, sondern auch als flexibles Framework für jede DAG-basierte DLT gesehen werden. Tatsächlich kann jeder Konsens-Mechanismus, wie z.B. On Tangle Voting, BFT, Leader-basiert und mehr, so einfach wie das Ändern von nur ein paar Zeilen in der Tangle-Initialisierung eingesteckt werden. Wir hoffen, dass unsere Bemühungen, dieses Tool bereitzustellen und kontinuierlich zu verbessern, anderen Forschern helfen werden, Fortschritte im Bereich der DLT zu machen.

Nachdem das Mana-Modul erfolgreich implementiert wurde, steht die nächste Stufe unseres Coordicide-Testnetzes namens „Nectar„, unser erstes funktionsfähiges koordinatorfreies Testnetz, vor der Tür. Das Team arbeitet bereits an den verbleibenden Features wie Nachrichtenfinalität über Genehmigungsgewicht, Reorganisation, Snapshots, Zeitstempel-Abstimmung und der Integration von Mana mit unseren Kernmodulen.

Wir möchten uns bei unserer gesamten Community für ihre Hilfe und Unterstützung bedanken. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im #tanglemath-Kanal auf unserem Discord. Sie können auch in der #goshimmer-discussion auf Discord mitdiskutieren.

Original by Angelo Capossele: https://blog.iota.org/pollen-testnet-v0-5-0-starting-our-journey-with-mana/

IOTA Forschungsstatus Update Februar 2021

Im vergangenen Monat haben wir weitere Fortschritte in unserem Pollen Testnetz gemacht, während wir uns dem Testnetz mit Anreizsystem nähren.

Es ist vielleicht ein guter Zeitpunkt, um einige Erwartungen zu formulieren, was wir von Nectar erwarten und lernen werden. Erstens: Nectar wird eine Beta Software sein, und als solche erwarten wir, dass wir einige Fehler sehen werden! Sie zu finden, ist der einzige Grund, warum wir überhaupt ein Testnetz eingerichtet haben. „IOTA Forschungsstatus Update Februar 2021“ weiterlesen

IOTA Chrysalis Wöchentliches Update #8

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.

Wir sind dabei, ein weiteres Update des Testnets vorzubereiten. Dieses Mal werden wir leichte Änderungen am Dust Schutzmechanismus und Änderungen an den Nachrichten vornehmen, um mehr als 2 Elternteile zu ermöglichen.

Bee

  • Implementieren mehrerer Nachrichten Eltern im Knoten
  • Feinschliff für das Dashboard des Knotens
  • Verbesserungen der Leistung
  • Updates mit den neuesten Anpassungen der Dust-Lösung

Hornet

  • Implementierung mehrerer Message Parents im Knoten
  • Aktualisierungen mit den neuesten Anpassungen der Dust Lösung
  • Änderungen an den Peering-Runden

Iota.rs und wallet.rs

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

  • Python-Bindung bereit zur Überprüfung – mqtt, Fehler und Bindungen erledigt
  • Merging des spec-Zweigs, sobald er fertig ist
  • Nächste Ziele: Umstieg auf die Verwendung von crypto.rs, Hinzufügen des State-Adapters

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.

  • Die Communications Desktop App hat jetzt eine korrekte Schnittstelle zur Stronghold Library
  • Das Team prüft den endgültigen Stand der Communications Integration
  • Runtime steht kurz vor der Fertigstellung

Firefly

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

  • Firefly wurde einer internen Sicherheitsüberprüfung unterzogen
  • Das Wallet-Dashboard wird fertiggestellt, um die App für Audits bereit zu machen

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 an eine externe Audit Firma übergeben, sobald wir es abgeschlossen haben.

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 Chech: https://blog.iota.org/chrysalis-update-january-29/

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/

Neue Version: Pollen Testnet v0.3.5

Wir veröffentlichen eine neue Version unseres Pollen-Testnetzes: v0.3.5. Mit dieser Version verbessern wir sowohl die Sicherheit als auch die Zuverlässigkeit. Die vollständige Liste der Änderungen umfasst:

  • Fehler in der Konsenserklärung behoben
  • Behebung eines Deadlocks in der RandomMap
  • Behebung mehrerer Probleme im Zusammenhang mit dem Herunterfahren
  • Laden alter Nachrichten im Visualisierer
  • Behebt die falsche Anzahl von Tipps im Visualisierer
  • Tippfehler im Dashboard behoben
  • Verbesserung der Integrationstests
  • Verbesserung der Netzwerkverzögerungsanalyse
  • hive.go aktualisiert
  • JS-Abhängigkeiten aktualisiert

Wie bei der vorherigen Version setzt diese Version das Netzwerk, den Tangle und alle Guthaben und tokenisierten Assets zurück.

Das Team arbeitet außerdem an den folgenden Meilensteinen:

Wir haben auch weitere Tests mit PebbleDB nach dem Fix vom Hornet-Team durchgeführt. Dabei haben wir festgestellt, dass, obwohl das Synchronisierungsproblem behoben und der Speicherverbrauch halbiert wurde, die allgemeine Leistung in Bezug auf IO etwa 3 mal langsamer war als mit BadgerDB. Daher haben wir uns entschieden, zumindest für den Moment, bei BadgerDB zu bleiben und die Pebble-Integration erst wieder in Betracht zu ziehen, wenn wir die restlichen Meilensteine erreicht haben.

Wir möchten uns an dieser Stelle noch einmal bei unserer gesamten Community für ihre Hilfe und Unterstützung bedanken. Wie immer freuen wir uns über Ihre Kommentare und Fragen entweder hier auf Medium oder im #tanglemath-Kanal auf unserem Discord. Sie können auch in der #goshimmer-discussion auf Discord mitdiskutieren.

Original by Angelo Capossele: https://blog.iota.org/pollen-testnet-v0-3-5-release-notes/