Monat: April 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/

Grüne Digital Zertifikate: Eine dezentralisierte und interoperable Infrastruktur

In den letzten Monaten gab es eine Diskussion auf der ganzen Welt: Wie können Menschen angesichts der Einschränkungen durch die aktuelle Pandemie wieder reisen? Und was ist die beste technologische Lösung, um das Credentialing zu unterstützen?

Obwohl einige Regierungen noch darauf warten, Stellung zu beziehen, und andere die besten Lösungen, die der Markt zu bieten hat, analysieren oder testen, hat die Kommission der Europäischen Union (EU) in einem kürzlich veröffentlichten Vorschlag für die Schaffung eines digitalen grünen Zertifikats einige Anforderungen festgelegt, um diesen Markt voranzutreiben. Das Ziel ist es, die sichere, freie Bewegung der Bürger innerhalb der EU während der COVID-19-Pandemie zu erleichtern. Nach seiner Einführung wird das Digitale Grüne Zertifikat Reisenden innerhalb der EU ermöglichen, einen Ausweis vorzulegen, der bestätigt, dass er oder sie gegen COVID-19 geimpft, negativ getestet oder genesen ist. Dieses Zertifikat wird es Reisenden ermöglichen, die sonst geltenden Quarantänebeschränkungen zu umgehen und sich freier zwischen den EU-Mitgliedstaaten zu bewegen. „Grüne Digital Zertifikate: Eine dezentralisierte und interoperable Infrastruktur“ weiterlesen

Murksers technische Analyse – 16.04.2021

IOTA Explodiert förmlich! Alle die seit 2017 dabei sind, werden vor Freude tanzen. Sowas hat man schon seit Jahren nicht mehr gesehen. 2,50 $ sind geschafft, aber wie geht es weiter? Murkser weiß bescheid, deswegen schaut euch die neueste Analyse zu IOTA an.

Kleiner Spoiler: Die Party geht weiter.

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/

Willkommen Eicke Schütze in der IOTA Foundation

Eicke verstärkt das Market Adoption Team als Partner Manager. In dieser Rolle wird er sich darauf konzentrieren, neue Partnerschaftsmöglichkeiten für Unternehmen voranzutreiben.

Eicke lebt in Deutschland und ist seit über zwanzig Jahren in der Technologiebranche tätig. Er hat als Entwickler, Projektmanager, Vertriebsleiter und Senior Business Developer an branchenübergreifenden Projekten für mehrere Fortune 100 Unternehmen gearbeitet.

Über seinen Einstieg bei IOTA

IOTA fühlte sich wie die perfekte Passform an, da es die Kombination aus meinem Fokus an der Universität, den innovativen Zukunftsanwendungen, die ich gerne erforsche, und den Visionen und der Ethik, die ich persönlich teile, war. Es war auch ein Technologiebereich, der mich sehr interessiert hat, da ich seit meiner ersten Berührung vor 5 Jahren eine Leidenschaft für IoT-Projekte entwickelt habe. Die DLT-Technologie in das IoT einzubringen und damit die Zukunft der Industrie 4.0 zu ermöglichen, ist extrem spannend – und ich freue mich, ein Teil dieser Reise zu sein!

Wir freuen uns sehr, Eicke offiziell in das Projekt aufnehmen zu können. Heißen Sie ihn herzlich willkommen!

Original by IOTA Foundation: https://blog.iota.org/welcome-eicke-schutze-to-the-iota-foundation/

Ermöglichung der Dokumentenauthentizität durch DLT

Ermöglichung der Dokumentenauthentizität durch DLT – ein Projekt von CGI und NORDAKADEMIE

Wir sind vom Ehrgeiz getrieben, die beste Distributed-Ledger-Technologie auf den Markt zu bringen. Dies kann nicht ohne akademische Anerkennung gehen. Eine Anerkennung, die sowohl die Validierung und Bestätigung unserer Forschungsbemühungen, die Entwicklung der Kerntechnologie als auch die Übernahme in mehr angewandte Forschungskontexte, die Lösungen für die Herausforderungen von morgen entwickeln, kombiniert.

Aus diesen Gründen arbeiten wir ständig mit akademischen Organisationen in ganz Europa und der Welt zusammen, um sie an die IOTA-Technologien heranzuführen und ihre Studenten in die Lage zu versetzen und zu befähigen, diese zu erforschen und darauf aufzubauen. In diesem Zusammenhang haben wir im letzten Jahr, trotz der neuen Herausforderungen durch nationale Abriegelungen und die anhaltende Pandemie, mit CGI, einem weltweit führenden Dienstleister für IT- und Business-Innovationen, zusammengearbeitet, um einen Online-Workshop durchzuführen und die Forschungsherausforderungen für ein Innovationsprojekt mit zukünftigen Fachkräften der NORDAKADEMIE Graduate School in Hamburg zu stellen.

Die Validierung von Dokumenten ist ein weniger bekannter, aber vielversprechender Anwendungsfall von DLT, mit dem sich die Studenten beschäftigen sollten. Basierend auf der IOTA-Technologie entwickelte das Projektteam aus Studenten und Unterstützern von CGI, der IOTA Foundation und der NORDAKADEMIE iterativ einen Proof of Concept für einen sicheren und fälschungssicheren Datenaustausch zwischen Geschäftspartnern.

Das Team hat seinen Denkprozess und seine Erfahrungen rund um die Ideenfindung, Innovation und Umsetzung gefestigt, die wir gerne gemeinsam teilen.

„Wir freuen uns sehr, dass wir unseren Studierenden die Möglichkeit geben können, in interdisziplinären Teams mit Unterstützung führender Unternehmen innovative, praxisnahe Projekte durchzuführen„, sagt Prof. Dr. Joachim Sauer, wissenschaftlicher Betreuer des Projekts.

Die Notwendigkeit eines sicheren Dokumentenaustauschs in einer Welt des Social Hacking, der physischen und digitalen Dokumentenfälschung und der unsicheren Kommunikationskanäle nimmt stetig zu. Üblicherweise bieten spezielle Institutionen diese Art von Dienstleistung an und agieren als vertrauenswürdige dritte Partei zwischen Geschäftspartnern. Solche Institutionen können Notare, staatliche Organisationen oder digitale Dateiaustauschdienste sein. Das Ersetzen dieses Drittanbieters durch eine IOTA Tangle-Lösung ermöglicht nicht nur einen schnelleren und hochsicheren Dokumententransfer, sondern bietet auch die Möglichkeit zur Kosteneinsparung.

Als dezentrales Netzwerk kann der Tangle als wirklich neutrale Schicht zwischen den Partnern agieren. Da das Ledger unveränderlich ist, können Transaktionen (z.B. Datenaustausch) nicht manipuliert werden und sind für alle Nutzer nachvollziehbar. Daher gibt es auch keine Notwendigkeit für eine zentrale Verwaltung, um diese Transaktionen zu validieren – das Vertrauen wird durch das Netzwerk selbst aufgebaut.

„Ziel des Projekts war es, ein Konzept für eine flexible und benutzerfreundliche Lösung zum Austausch von Dokumenten zu erstellen und dabei die Möglichkeiten der IOTA-Technologie auszuloten„, sagt Alexander Leonard Ronge, Director Industry 4.0 / IoT bei CGI.

Die Lösung sollte sich daher leicht in die bestehende Infrastruktur integrieren lassen und zwei zentrale Anwendungsfälle unterstützen.

Ein großes Dankeschön an das Team, das an dem Projekt mitgearbeitet hat:

Mona Bessel | Eike Haß | Theresa S.

Anwendungsfall: Eigenständigkeit

Der erste Anwendungsfall unterstützt die Möglichkeit, ein Dokument mit einer App zu verifizieren, um zu prüfen, ob es manipuliert wurde. Dazu muss das Dokument zunächst vom Absender in das Tool hochgeladen werden, um validiert zu werden. Anschließend kann der Absender das Dokument erneut herunterladen und an den gewünschten Empfänger senden. Der Empfänger kann dann das Dokument in das Tool hochladen und validieren. Außerdem wird der Empfänger informiert, wenn eine neuere Version des Dokuments verfügbar ist. Bei diesem Anwendungsfall ist die Übertragungsmethode frei wählbar, was diese Implementierung für einen Dokumentenaustausch zwischen nicht miteinander verbundenen Benutzern geeignet macht.

Anwendungsfall: Integriert

Beim zweiten Anwendungsfall können sich Benutzer über einen dedizierten Kommunikationskanal miteinander verbinden und Dokumente austauschen, die in einem Dokumentenmanagementsystem gespeichert sind. Hier kann der Absender einfach ein Dokument hochladen und eine Gruppe von Empfängern erstellen. Sobald der Empfänger das Dokument herunterlädt, wird es automatisch validiert. Wenn zudem eine neuere Version des Dokuments verfügbar ist, wird der Empfänger darüber informiert und erhält neuere Dokumentversionen. Dieser Anwendungsfall bietet mehr Komfort für Absender und Empfänger als der erste Anwendungsfall, ist aber nur geeignet, wenn die Benutzer miteinander verbunden sind und eine ständige Kommunikation haben, wie z. B. innerhalb einer Organisation oder zwischen Geschäftspartnern.

Implementierung

Die zentralen Funktionen der Lösung sind der Empfang, die Rückgabe und die Validierung von Metadaten eines ausgetauschten Dokuments, die der Hash des Dokuments und ein Zeiger auf den Speicherort des Dokuments sein können, sowie optional die Verfolgung von Revisionen des Dokuments. Das Dokument selbst wird off-tangle gespeichert und übertragen, um Speicherplatz zu sparen, die Vertraulichkeit der Daten zu wahren und die Geschwindigkeit der Transaktion zu erhöhen. Technisch wird der Datenaustausch über IOTA Masked Authenticated Messaging (MAM) abgewickelt, das Kanäle bereitstellt, in die Empfänger ein- und ausgeschaltet werden können.

Durch eine modulare Architektur ermöglicht die Lösung die Anpassung an kundenspezifische Anwendungsfälle und vereinfacht Updates im Zuge der Weiterentwicklung von IOTA-Technologien. Dieser Fokus auf Flexibilität ermöglicht Wahlmöglichkeiten bei einer Vielzahl von zentralen Entscheidungen:

  • Identitätsmanagement, das entweder von einer bestehenden Lösung im Unternehmen übernommen oder an eine eigenständige Lösung angebunden werden kann.
  • Architektur und Hosting, abhängig von der Anzahl der Parteien, die das Tool nutzen, so dass es als zentrale, offene oder unternehmenseigene Plattform genutzt werden kann
  • Hashing und Verschlüsselung der Dokumente, was zur Wahrung der Sicherheit entlang der sich entwickelnden Standards unerlässlich ist

Um die Machbarkeit des Konzepts zu beweisen, wurden Proof of Concepts für jeden Anwendungsfall erstellt. Der erste Anwendungsfall war eine Web-App zum Hochladen, Hashing und Validieren von Dokumenten. Der zweite war eine integrierte Lösung, die eine Schnittstelle mit sofort zugänglichen und automatisch verifizierten Dokumenten eines integrierten Dokumentenspeichers umfasst. Dies beweist, dass ein und dasselbe Backend eine Vielzahl von Geschäftsszenarien bewältigen kann, die einen sicheren Dokumententransfer mit Unterstützung von IOTA Tangle ermöglichen.

„Die Projektergebnisse waren sehr erfreulich und von hoher Qualität. Auf den entwickelten Konzepten können weitere Initiativen aufbauen“, so Prof. Dr. Joachim Sauer.

Learnings

Das Projektteam hat viele wertvolle Erfahrungen und Learnings gemacht, die wir gerne teilen möchten. Die folgenden Learnings können auch für andere hilfreich sein, die ihr eigenes Projekt mit IOTA-Technologie starten wollen:

Aus der Vogelperspektive betrachten

Das IOTA-Ökosystem wächst kontinuierlich und bietet Lösungen für gängige Herausforderungen in allen Arten von Projekten. Unserer Erfahrung nach bringt die Kombination der verschiedenen IOTA-Technologien und -Produkte ein Projekt erst richtig zum Laufen. Deshalb ist es sinnvoll, sich vor dem Start einen Überblick über die verschiedenen bestehenden und kommenden IOTA-Lösungen zu verschaffen. Manchmal können Sie Ihr Produkt auf bereits existierenden Elementen der IOTA-Technologie aufbauen.

Planen Sie iterativ

Aufgrund der Innovationskraft von Projekten im DLT-Bereich ist die Entwicklung eines Tools ein Prozess des Lernens, Testens und Ausprobierens. Am Anfang gab es nur eine grobe Idee. Die Anforderungen änderten sich und das Tool selbst entwickelte sich im Laufe des Projekts weiter. Wenn Sie also neu im IOTA-Ökosystem sind und die Anforderungen nicht von Anfang an vollkommen klar sind, empfehlen wir, Ihr Projekt ebenfalls iterativ zu planen.

Folgen Sie der Innovation

Die Innovation der IOTA-Plattform hat sich in einem unglaublichen Tempo entwickelt, seit wir den PoC unserer Plattform abgeschlossen haben. Seitdem hat IOTA Streams ein Alpha-Release gesehen, das die MAM-Technologie ersetzt, die wir anfangs verwendet haben. Auch IOTA Identity hat ein Release ihrer Kernbibliothek gesehen, die eine Lösung für die Identifizierung der an einer Transaktion beteiligten Parteien bietet. Darüber hinaus bietet Chronicle eine Lösung zur Speicherung von Datentransaktionen auf unbestimmte Zeit, um alle Datenaustausche für spätere Abrufe und Audits zu archivieren. Wir begrüßen vor allem den Ausblick auf das Chrysalis-Update, da neue Features wie wiederverwendbare Adressen und benutzerfreundliche Bibliotheken die Entwicklung auf IOTA deutlich vereinfachen werden.

Um auf dem Laufenden zu bleiben, helfen die üblichen Kanäle wie unser Blog, Reddit und Discord. Vielleicht ist die Lösung für Ihre nächste Herausforderung schon um die Ecke.

Engagieren Sie sich

Wenn Sie bei Ihrem eigenen Projekt auf Herausforderungen stoßen oder sich mit Gleichgesinnten austauschen wollen, empfehlen wir Ihnen, sich in der IOTA-Community zu engagieren. Der einfachste Ort dafür ist der IOTA-Discord.

Über CGI

CGI, gegründet 1976, ist ein globaler Dienstleister für IT und Geschäftsprozesse mit 76.000 Mitarbeitern, der strategische IT- und Geschäftsberatung, Systemintegration, Managed IT, Geschäftsprozessdienstleistungen und geistiges Eigentum auf höchstem Niveau anbietet.

CGI unterstützt seine Kunden bei der Einführung neuer Technologien – wie Advanced Analytics, Künstliche Intelligenz, Augmented Reality, RPA, Blockchain, Digitaler Zwilling, IoT und mehr – um neue Geschäftsmodelle, Dienstleistungen und Produkte voranzutreiben, Kundenkontaktpunkte neu zu erfinden und den zunehmenden Cyber-Bedrohungen und regulatorischen Anforderungen zu begegnen.

Über NORDAKADEMIE

Die 1992 gegründete NORDAKADEMIE ist mit über 2.500 Studierenden eine der größten privaten Hochschulen für angewandte Wissenschaften mit Campus- und Präsenzveranstaltungen in Deutschland. Im Oktober 2013 wurde die NORDAKADEMIE Graduate School im Hamburger Dockland eröffnet. Die NORDAKADEMIE bietet duale Bachelorstudiengänge, berufsbegleitende Masterstudiengänge, Bildungsmodule und Zertifikatskurse sowie ein berufsbegleitendes Promotionsprogramm an. Alle Abschlüsse sind international anerkannt. Top-Platzierungen im CHE-Hochschulranking und die FIBAA-Akkreditierung spiegeln den hohen Standard und die Qualität der Ausbildung wider. Der Vorteil des dualen Konzepts liegt in der engen Verzahnung von Theorie und Praxis. Mehr als 800 Unternehmen aus allen Branchen haben bereits mit der privaten Hochschule in Elmshorn vor den Toren Hamburgs kooperiert.

Original by IOTA Foundation: https://blog.iota.org/enabling-document-authenticity-through-dlt-a-project-by-cgi-and-nordakademie/

Forschungsförderungsbericht – Konvergenz und Modifikationen

Forschungsförderungsbericht –
Zelluläre Automaten Konsens: Konvergenz und Modifikationen

Wie Sie sich vielleicht erinnern, haben wir im November letzten Jahres ein Stipendium für die Untersuchung von Zellulären Automaten und Autopeering-Optimierung angekündigt. Diese Arbeit wurde nun von unseren hervorragenden Stipendiaten abgeschlossen, und dieser Beitrag enthält eine Zusammenfassung der Forschung und ihrer Schlussfolgerungen.

Obwohl das Ergebnis nicht positiv für die Einbeziehung von Cellular Automata (CA) in zukünftige Upgrades des IOTA-Protokolls war, führte die Forschung zu neuen Erkenntnissen, die uns bei anderen Aspekten von Coordicide helfen. Es unterstreicht auch die Wichtigkeit, die rigorose Forschung zu betreiben, die notwendig ist, um schwierige Probleme anzugehen, die von unserem Team aufgegriffen wurden. Diese Forschung ist ein wunderbares Beispiel dafür, sich ins Unbekannte zu wagen, und zwar als notwendiger Teil des Verständnisses dessen, was funktioniert, was nicht funktioniert, und warum. Nur wenn man sich auf unbekanntes Terrain begibt, kann man über unerwartete Aspekte stolpern, die sich als äußerst nützlich erweisen können.

Wir sind dankbar für die Erkenntnisse, die wir durch diese Forschung gewonnen haben. Wir sind auch dankbar für die positiven Ergebnisse der Forschung, die einen Vorschlag für Modifikationen des Abstimmungsprotokolls und auch eine Implementierung für den Ar-Row-Auto-Peering-Algorithmus beinhalten. Vielen Dank an Radosław Michalski, Daria Dziubałtowska und Piotr Macek für ihre ausgezeichnete und gründliche Arbeit und für den folgenden Text!

Einführung in die Forschung

Das Ziel unseres Forschungsprojekts war es, den Einfluss von Graphenkonfigurationen auf die Konsensfindung für den CA-Algorithmus zu analysieren. Um dies zu tun, analysierten wir im Rahmen des Projekts die strukturellen Eigenschaften von Graphen, die durch die Ar-Row- und Salt-basierten Autopeering-Methoden erzeugt wurden, d.h. die Methoden zur Herstellung von Verbindungen zwischen IOTA-Knoten. Zweitens gingen wir dazu über, die Auswirkungen von Graphenkonfigurationen zu untersuchen, insbesondere im Hinblick darauf, wie der auf zellulären Automaten basierende Konsens Stabilität erreicht und, falls nicht, wie man diese Situationen überwinden kann. Basierend auf den Ergebnissen dieser beiden Analysen schlugen wir auch Änderungen am Abstimmungsprotokoll vor, um metastabile Situationen zu vermeiden, die zu geteilten Meinungen über den Ledger-Status führen. Zu guter Letzt haben wir ein GoShimmer-Modul für den Ar-Row-Auto-Peering-Algorithmus implementiert. In diesem Blog-Beitrag werden die Ergebnisse der Forschung vorgestellt.

Zunächst möchten wir die Leser auf einen anderen Blog-Beitrag verweisen, der in die Idee des Konsens im Tangle einführt – darin finden Sie eine grundlegendere Beschreibung des Konsens und mehrere Strategien zur Maximierung der Chancen, ihn zu erreichen. In unserem Forschungsprojekt haben wir uns auf den dort ebenfalls erwähnten zellulären Konsens konzentriert. Weitere Details finden Sie in Abschnitt 6.2 des Coordicide White Paper.

Autopeering-Algorithmen

Das Ziel dieses Teils der Untersuchung war es, zwei Autopeering-Algorithmen zu evaluieren: salt-based und ar-row. Jede dieser beiden Methoden verfügt über unterschiedliche Mittel zur Erstellung einer Graphenstruktur und sie unterscheiden sich darin, wie die Knoten miteinander kommunizieren, um Peers zu finden. Im Idealfall sollen beide Methoden mit k-regulären Graphen enden, d. h. Graphen, in denen jeder Vertex mit k Nachbarn verbunden ist. Diese Graphen wurden später für die Ausführung des zellulären Automatenalgorithmus verwendet, um einen Konsens zu erreichen. Zuvor wollten wir jedoch evaluieren, ob sich die Graphen, die von den salzbasierten und ar-row-Algorithmen erzeugt werden, strukturell unterscheiden.
Wir haben diese Methoden für eine ausgewählte Anzahl von <n, k>-Kombinationen, wobei n die Anzahl der Knoten darstellt, für mehrere Instanzen von Graphen ausgeführt (insgesamt haben wir 2.916.670 Graphen analysiert). Für die salzbasierte Methode haben wir die Anzahl der Runden auf hundert begrenzt, da in der Mehrzahl der Fälle, wenn Graphen innerhalb von hundert Runden nicht zur k-Regelmäßigkeit konvergieren, sie auch bei einer größeren Anzahl von Runden nicht konvergieren.
Aus diesem Teil der Untersuchung können eine Reihe von Schlussfolgerungen gezogen werden:
  • für den Ar-Row-Algorithmus ist das Erreichen von k-Regelmäßigkeit in zwei von drei Fällen möglich
  • für die salzbasierte Methode ist das Erreichen der k-Regelmäßigkeit schwer zu erreichen, aber die mittlere Anzahl der Kanten und ihre Varianz sind, zumindest aus unserer Sicht, akzeptabel und nahe an der k-Regelmäßigkeit
  • ar-row ist eine Methode, die aufgrund ihrer Natur Graphen um eine Größenordnung schneller erzeugt als der Salt-basierte Algorithmus
  • globale Graphenmaße der generierten Graphen (k-Regelmäßigkeit, Modularität, Umfangsgröße und Durchmesser) zeigen eine hohe Ähnlichkeit zwischen beiden Methoden, die statistisch ausgewertet wurde
  • Lokale Graphenmaße (Clustering-Koeffizient und Betweenness) divergieren nur geringfügig – die Unterschiede zwischen den Verteilungen wurden mit Hilfe des Kullback-Leibler-Divergenzmaßes quantifiziert

Cellular Automata-Konsens

In einem zweiten Schritt implementierten wir den Cellular Automata-Algorithmus, der auf der Beschreibung aus dem oben genannten White Paper basiert. Die Knoten ermittelten ihre eigene Meinung basierend auf der Meinung ihrer Nachbarn aus der vorherigen Runde. In unserer Implementierung wichen wir in einem Aspekt von der im Coordicide-Paper vorgestellten Version ab: Wenn keine Meinung die Mehrheit hatte, haben wir keinen unentschiedenen Zustand verwendet. Stattdessen ändert der Knoten seine Meinung zu der entgegengesetzten, die er in der vorherigen Runde hatte. Wir haben den CA-Algorithmus auf Graphen mit verschiedenen <n, k>-Kombinationen getestet. Für alle unsere Simulationen verwendeten wir eine Anzahl von Runden M=100, die Anzahl der aufeinanderfolgenden Runden mit der gleichen Meinung für einen Knoten, um endgültig zu werden l=4, und wir verwendeten eine lineare Funktion als monotone Funktion für die Bestrafung von Knoten, die weniger als k Nachbarn haben.

Der wichtigste Teil dieser Untersuchung bestand darin, die Anzahl der metastabilen Situationen zu zählen, die während der CA-Simulation auftraten. Als Auszug aus allen Ergebnissen, die wir haben, stellen wir in Abbildung 1 und Abbildung 2 dar, wie die Metastabilität von k und n abhängt (für salzbasierte bzw. ar-row).

Abbildung 1. Der Prozentsatz der metastabilen Situationen für verschiedene Werte von k und n fürsalzbasiert.
Abbildung 2. Der Prozentsatz der metastabilen Situationen für verschiedene Werte von k und n für die Ar-Reihe.

Bevor wir weitergehen, lassen Sie uns zusammenfassen, welche Schlussfolgerungen für die Analyse von CA mit Nulltemperatur gezogen werden können:

im Allgemeinen übertrifft der Prozentsatz der metastabilen Situationen unsere Erwartungen
für kleinere k, unabhängig von n, ist es schwieriger, den Konsens zu erreichen
es gibt einen Unterschied zwischen Arrow- und Salt-basierten zugrundeliegenden Graphen in Bezug auf den Prozentsatz metastabiler Situationen für CA (unabhängig von der Methode der Zuweisung von Anfangszuständen), aber es gibt keinen klaren Gewinner
der Gossip-Algorithmus führt zu weniger metastabilen Situationen für höhere n, im Vergleich zu initiierenden Knoten mit zufälligen Meinungen
die durchgeführten Experimente haben nicht genügend Daten geliefert, um die Abschätzung der metastabilen Fälle für größere n durchzuführen

Verbesserte CA mit Null-Temperatur

Die Ergebnisse für CA mit Null-Temperatur waren nicht ausreichend gut, daher haben wir einige metastabile Situationen für kleine Graphen manuell analysiert, um herauszufinden, warum der Algorithmus keinen Konsens erreichen konnte, und wir haben zwei entscheidende Punkte ausgemacht, die es dem Netzwerk schwer machen, in einen stabilen Zustand zu gelangen.
Das erste Problem, das uns aufgefallen ist, ist, dass einige Knoten ihre Meinung ändern, wenn die Meinungen ihrer Nachbarn 50/50 geteilt waren. Dies führte dazu, dass einige Knoten in jeder Runde ihre Meinung änderten, was wiederum dazu führte, dass andere Knoten in aufeinanderfolgenden Runden ihre Meinung änderten und der Zustand sich nicht stabilisieren konnte.

Zum Testen änderten wir dies so, dass der Knoten in den beschriebenen Situationen seine Meinung zufällig ändert, also entweder bei seiner aktuellen Meinung bleibt oder sie ändert. Dadurch wurden die Ergebnisse bei kleinen Graphen besser, bei großen Graphen (mit 100 Knoten) stellte sich jedoch heraus, dass dies die Ergebnisse verschlechterte und wir ließen diese Änderung fallen.

Die zweite Herausforderung, die wir feststellten, war, dass einige Knoten in jeder Runde ihre Meinung hin und her wechselten, was dazu führte, dass einige ihrer Nachbarn in aufeinanderfolgenden Runden ebenfalls ihre Meinung änderten, wodurch sich das Netzwerk nicht stabilisieren konnte.

Da das Problem auftritt, weil die Knoten ihre Meinung in jeder Runde ändern, haben wir uns entschieden, eine Änderung anzuwenden, die es den Knoten erlaubt, ihre Meinung in zwei aufeinanderfolgenden Runden nur mit einer geringen Wahrscheinlichkeit und mit einer Wahrscheinlichkeit von Null zu ändern. Die Analyse einer kleinen Teilmenge von großen und kleinen Graphen ergab, dass die besten Ergebnisse erzielt wurden, wenn man den Knoten erlaubte, ihre Meinung in zwei aufeinanderfolgenden Runden mit einer Wahrscheinlichkeit von 10 % zu ändern.

Die beschriebenen Modifikationen verbesserten die Ergebnisse erheblich, dennoch treten manchmal immer noch metastabile Situationen auf. Weitere Untersuchungen führten nicht zu weiteren Verbesserungen, da die verbleibenden metastabilen Situationen immer noch durch Knoten verursacht werden, die ihre Meinung hin und her wechseln. Diese verbleibenden metastabilen Fälle in unserem Simulator sind so unglücklich, dass trotz einer Wahrscheinlichkeit von 10 %, dass Knoten ihre Meinung in zwei aufeinanderfolgenden Runden ändern, einige Knoten ihre Meinung in jeder Runde ändern. Wir waren nicht in der Lage, eine Lösung zu finden, die gut genug ist, um alle Fälle abzudecken, aber die beschriebenen Änderungen brachten eine große Verbesserung.

Wie die Ergebnisse zeigen (siehe Abbildung 3), sank die Anzahl der metastabilen Situationen
deutlich. In diesem Fall übertrafen die Arrow-basierten Graphen die Salt-basierten, aber die Fortschritte waren bei beiden Familien deutlich zu beobachten. Dies zeigt, dass es auch ohne die in das System eingeführten Temperaturen Raum für Verbesserungen gibt

Abbildung 3. Prozentsatz der metastabilen Situationen für salzbasierte und arrow-autopeering Methoden für CA mit Verbesserungen.

Danke fürs Lesen! Wir hoffen, dass Sie weiterhin unsere Updates hier im Blog verfolgen. Sie sind auch herzlich eingeladen, sich mit Mitgliedern des Forschungsteams im Channel #tanglemath auf unserem Discord zu verbinden. Sie sind auch herzlich eingeladen, unsere technischen Diskussionen in unserem öffentlichen Forum zu verfolgen und daran teilzunehmen: IOTA.cafe.

Original by IOTA Foundation: https://blog.iota.org/research-grant-report-cellular-automata-consensus-convergence-and-modifications/

IOTA Standardisierung Update – April 2021

Warum haben wir Standards? Eines der besten Argumente, die ich in letzter Zeit für Standards gesehen habe, war ein Tweet von unserem eigenen Hans Moog letzte Woche. Hans tweetete:

„Idealerweise erreicht man Resilienz gegen Bugs in der Node-Software, indem man mehrere verschiedene Implementierungen von mehreren Teams hat, so dass, wenn eine kaputt ist, nur die Nodes, die diese Software benutzen, aus dem Takt fallen. Man braucht im Wesentlichen eine „Dezentralisierung der Knotenimplementierungen“. Das ist der Grund, warum wir „Bee“ und „Hornet“ Knoten haben werden, die von völlig unterschiedlichen Teams in völlig unterschiedlichen Sprachen implementiert wurden. Es ist sehr unwahrscheinlich, dass zwei Teams den exakt gleichen Fehler machen, was das Netzwerk resilient gegen Bugs macht.“

Diese Dezentralisierung der Funktionalität ist genau das, worum es bei Standards geht. Es fügt der DLT-Vision eine weitere Ebene der Dezentralisierung hinzu. Wie Dom Schiener in einem aktuellen TechCrunch-Artikel schreibt:

„Es ist, als hätten wir einen Haufen verschiedener Firmen, die nicht nur die Glühbirne, sondern auch ihre eigenen Steckdosen und Verdrahtungsprotokolle erfunden haben, und jede besteht darauf, dass sie die beste ist und am Ende gewinnen wird. … Diese schöne neue Wirtschaft wird niemals in Gang kommen, wenn wir nicht ein neutrales, interoperables Netzwerk aufbauen.“

Bei Standards geht es darum, etwas auf eine bestimmte Art und Weise zu tun, so dass jeder es auf diese Weise tun kann.

Bei Standards geht es um Abstraktion. Wir abstrahieren das Was vom Wie. Für die Knotensoftware sollte jeder in der Lage sein, Knotensoftware zu schreiben, die das „Was“ tut, aber niemand muss wissen oder sich darum kümmern, wie er es getan hat. Die anderen Standards, an denen wir arbeiten, werden auf die gleiche Weise funktionieren.

Beim Quartalstreffen der Object Management Group (OMG) Ende März haben wir den neuesten Entwurf des kommenden IOTA Protocol RFC vorgestellt, damit die OMG weiß, was auf sie zukommt, und um Feedback von ihnen zu bekommen. Dieser RFC wird auf den Coordicide-Spezifikationen basieren. Einige der Features davon sind bereits in den Chrysalis-Implementierungen enthalten.

Die Spezifikationen des IOTA-Protokolls sind noch nicht für die Öffentlichkeit freigegeben, aber wir konnten einige davon der OMG zeigen, um Feedback zu bekommen, was in der formalen Spezifikation benötigt wird. Das Feedback, das wir bekamen, war, dass diese gut für die Einreichung von Standards aussehen, was die Formatierung, die Sprache und die Art und Weise, wie die Dinge formal beschrieben werden, angeht. Dazu gehört zum Beispiel die Verwendung von Pseudocode, um auszudrücken, was eine standardkonforme Anwendung tun sollte, und wie wir die Datenstrukturen und Inhalte spezifizieren. Dieses Feedback hilft uns auch dabei, sicherzustellen, dass die IOTA-Spezifikationen selbst gut strukturiert und konsistent sind – diese sehen im Moment gut aus.

Andere Standardisierungsaktivitäten

Andere Aspekte, an denen wir in der OMG arbeiten, sind:
  • Requests for Proposals (RFP) – das sind Dinge, für die jeder in der Industrie einen Standard vorschlagen kann, mit der Erwartung, dass die IOTA Foundation eine Antwort einreicht.
  • Requests for Information (RFI) – ihr Zweck ist es, der OMG eine Vorstellung davon zu geben, was die Anliegen in einem bestimmten Bereich sind, welche Standards bereits existieren und so weiter, mit der Absicht, später einen oder mehrere RFPs für mögliche Standards in diesem Bereich zu entwickeln.

so wird ein Norm Standard gemacht

Derzeit aktive IOTA-Standardvorschläge:

  • Node (das IOTA-Protokoll)
  • Streams

Demnächst:

  • Identität
  • Selbstständige Identität folgt bestehenden Standards: W3C DID und VC
  • Wir können einige spezifische Erweiterungen zu W3C DID oder VC vorschlagen
  • Disposable Self-Sovereign Identity und Personas für kontextuelle Identität (Antwort auf den OMG Disposable SSI RFI)
  • Intelligente Verträge
  • Ein oder mehrere mögliche Standards in Ethereum (EIC), OMG oder beides.

Smart Contracts RFI

Dieser RFI ist für die Veröffentlichung im Juni-Quartalstreffen vorgesehen. Bei diesem Treffen haben wir einen Entwurf davon für das Feedback der anderen OMG-Gruppen vorgestellt.

Die neue IOTA Smart Contracts ‚alpha‘ Version ist in vielerlei Hinsicht einzigartig. Der OMG Smart Contracts RFI ist allgemeiner und zielt darauf ab, Anforderungen und bestehende Standards allgemeiner zu identifizieren. Wir werden eine Antwort auf diesen RFI einreichen, nachdem er im Juni veröffentlicht wurde, in der wir einige der einzigartigeren Eigenschaften der IOTA Smart Contracts beschreiben können, und insbesondere unsere Ambitionen für Interoperabilität. Sie haben vielleicht die Ankündigung vom 29. März gesehen, dass IOTA Token-Liquidität jetzt auf der Binance Smart Chain verfügbar ist.

Bei der Fähigkeit der IOTA Smart Contracts, auf anderen DLTs zu laufen und Smart Contracts, die für andere DLTs entwickelt wurden, auf der IOTA Tangle laufen zu lassen, dreht sich alles um Interoperabilität und das ist genau der Grund, warum wir an Standards arbeiten.

Für einen Teil davon schauen wir uns an, bereits existierende Standards von Ethereum zu implementieren, z.B. den ERC20 Standard, sowie andere wie ERC 721 für nicht-fungible Token. Ethereum ist effektiv ein eigenes Standardisierungsgremium mit dem Ethereum Improvement Proposals (EIP) System.

Einiges von dem, was wir für IOTA Smart Contracts tun wollen, könnte am besten durch das Vorschlagen von Erweiterungen zu den bestehenden ERC-Standards oder das Vorschlagen neuer Standards durch den EIC-Prozess erreicht werden. Ein Beispiel ist, dass wir gerne mehr Metadaten zu einigen der ERP-Standard-Payloads hinzufügen würden.

Da IOTA frei von Gebühren ist, ist es möglich, mehr Metadaten in einer Standard-Payload auf dem IOTA Tangle zu tragen, als es für die gleiche Payload in einer kostenpflichtigen Blockchain kosteneffektiv wäre. Aus diesem Grund ist es möglich, dass einiges von dem, was wir durch die Erweiterung der ERC-Standards vorschlagen, von der Community, die diese Vorschläge überprüft, als nicht akzeptabel angesehen wird. Wenn einige dieser ERC-Erweiterungsvorschläge im Rahmen des EIC-Prozesses nicht akzeptiert werden, würden wir diese der OMG als Vorschläge unter Verwendung des OMG RFP-Prozesses vorlegen. Diese Standards könnten in Zukunft auch anderen Gebührenfreien DLTs zugutekommen.

Energie in der Blockchain

Wir haben eine zusätzliche Mittagssitzung angesetzt, um den Energiehandel und die Energieverteilung mit Hilfe der Distributed-Ledger-Technologie zu erforschen, und Vertreter von IEEE und dem Industrial Internet Consortium (IIC) eingeladen, dem OMG-Schwestergremium, das sich mit dem Internet der Dinge (IoT) beschäftigt. Es gibt interessante Möglichkeiten für DLT-Anwendungen im Energiehandel und in Mikro-Netzen, zum Beispiel, wo einzelne Haushalte sowohl als Lieferanten als auch als Verbraucher von Energie in Bezug auf das Stromnetz agieren können.

Mit Blick auf die Zukunft scheint es wahrscheinlich, dass es einige potenzielle Verbindungen zwischen IoT und Energiesystemen geben wird, wobei Anwendungsbereiche wie Smart Cities ein Element von beiden haben. Es wird daher für die IOTA Foundation von Interesse sein, in diesen Gesprächen engagiert zu bleiben. Wir beginnen, an den relevanten IEEE-Energy-Meetings teilzunehmen.

DLT-Governance und Interoperabilität

Wir hatten auch eine ausführliche Diskussion über Governance in DLTs, einschließlich der Frage, wie dies mit Fragen der Interoperabilität zusammenhängt. An dieser Diskussion nahmen Vertreter einiger IEEE-Arbeitsgruppen und des IIC teil, die jeweils eine Präsentation hielten. Wir sahen uns ein interessantes akademisches Papier über Governance in erlaubnisfreien DLTs an, mit Ideen, die wir vielleicht in IOTA verwenden können, sobald Coordicide abgeschlossen ist. Wir hörten auch von der OMG-eigenen „DIDO“-Referenzarchitektur, die sich mit Governance-Überlegungen auf Gemeinschaftsebene beschäftigt. Das ICC hat auch eine aktuelle Studie über Governance in DLT verfasst, die kürzlich auf einem IEEE-Treffen vorgestellt wurde.

In Zukunft werden wir beginnen, uns formeller mit IEEE zu engagieren, im Bereich DLT-Governance (IEEE P2145), bei Blockchain für IoT (IEEE P2418.1) und im Energiebereich (IEEE P2418.5). Wir werden auch auf das IIC zugehen, da die IOTA Foundation den Schwerpunkt auf IoT legt.

Diese Diskussionen berührten auch das verwandte Thema der Interoperabilität. Die IOTA Foundation hat im letzten Frühjahr auf einen RFI zur DLT-Interoperabilität geantwortet, aber zu diesem Zeitpunkt hatten wir noch keine IOTA Smart Contracts veröffentlicht, die von vornherein Interoperabilität eingebaut haben. Wir werden Informationen dazu in unsere Antwort auf die Smart Contracts RFI aufnehmen, wenn diese im Juni herauskommt.

Digitale Währung

Die OMG hat auch eine Finance Domain Task Force (FDTF), die sich während dieser vierteljährlichen Treffen trifft. Dieses Mal hat die FDTF einen RFI zu digitalen Währungen erstellt, einschließlich digitaler Zentralbankwährungen (CBDC), für die es eine eigene OMG-Arbeitsgruppe gibt. Einige neuere akademische Arbeiten legen eine grundlegende „Ontologie“ von Zentralbank-Digitalwährungen fest, indem sie eine Reihe von formalen logischen Definitionen der Natur des Geldes selbst erstellen, wobei verschiedene Arten von Digitalwährungen einschließlich Kryptowährungen definiert werden. Dieser RFI wird wahrscheinlich im Juni herausgegeben werden und wir erwarten, dass wir eine Antwort von der IOTA Foundation verfassen können.

Einweg-Selbstverwalter-Identität

Auf dem Dezember-Treffen hat die OMG einen RFI zu Disposable Self-sovereign Identity herausgegeben, eine Idee, die wir bei der IOTA Foundation zu erforschen beginnen, insbesondere im Bereich Covid und Gesundheitswesen und in Zusammenarbeit mit den TangleEE-Arbeitsgruppen. Die Antworten sind diese Woche fällig, und die IOTA Foundation wird einen detaillierten Satz von Antworten auf die Fragen in diesem RFI einreichen. Wir sehen Möglichkeiten für einen Standard oder Standards in diesem Bereich, sowohl in Bezug auf eine formale Definition von „Kontext“ (da Einweg-SSIs effektiv kontextbezogen sind), als auch in Bezug auf die detaillierten technischen Anforderungen, um Einweg-SSIs innerhalb von IOTA Identity bereitzustellen, unter Verwendung der W3C-Standards DID und Verifiable Credentials. Wir erwarten, dass die OMG in der Lage sein wird, im Juni eine Ausschreibung für kontextuelle oder Einweg-SSI zu veröffentlichen. Die IOTA Foundation wäre in der Lage, auf diesen RFI zu antworten.

IOTA-Streams

Die Arbeit wird fortgesetzt, um die Basis des IOTA-Streams-Frameworks und -Protokolls zusammen mit Aspekten von SKALY Freighter als Antwort auf das OMG RFP für Linked Encrypted Transaction Streams (das LETS RFP) einzureichen. Diese soll im Mai für das vierteljährliche OMG-Treffen im Juni eingereicht werden.

Zusammenfassung

Die Arbeit am IOTA-Protokoll wird fortgesetzt. Es wird definiert, wie jeder mit eigenem Code Node-Software nach den gleichen Anforderungen bauen kann, was zu einer größeren Ausfallsicherheit im gesamten Netzwerk führt. Das IOTA Protocol RFC wird später in diesem Jahr eingereicht werden, basierend auf den Coordicide Spezifikationen.

Die OMG Quartalstreffen bietet weiterhin eine Pipeline für potenzielle neue Standardeinreichungen, sowohl von der IOTA Foundation als auch von der breiteren DLT-Community, über den RFI-Prozess. Die aktuelle RFI-Arbeit umfasst Smart Contracts und digitale Währungen. Zukünftige RFIs werden Oracles, Anforderungen an Archivierungsknoten (IOTA Permanode) und andere Funktionen des DLT-Ökosystems abdecken, um dem Wunsch der Endanwender nach größerer Interoperabilität nachzukommen. Jede dieser RFIs stellt eine Gelegenheit dar, die nächste Runde von RFPs zu beeinflussen und zu definieren, die kommen wird.

In der Zwischenzeit wendet sich die IOTA Foundation an andere Standardisierungsgremien wie IEEE, IIC, W3C und den Ethereum EIC-Prozess. Wir engagieren uns auch weiterhin in branchenübergreifenden Initiativen wie TangleEE und der Trust over IP Foundation. Dabei ist es unser Ziel, den Weg zur Interoperabilität zu ebnen und neue Geschäftsmöglichkeiten und gesellschaftliche Vorteile zu erschließen, basierend auf dem aufgeklärten Eigeninteresse, ein Standardsetter zu sein.

Original by IOTA Foundation: https://blog.iota.org/iota-standardization-update-april-2021/

Pollen Testnet v0.5.5 Versionshinweise

Wir freuen uns, eine neue Version unseres Pollen-Testnetzes v0.5.5 zu veröffentlichen. Nachdem wir Mana vor ein paar Wochen in unserem Testnetz eingeführt haben, freuen wir uns, es nun mit zwei der Coordicide-Module zu verwenden: Konsens (FPC) und Autopeering. Wie Sie sich wahrscheinlich vorstellen können, ist dies ein sehr wichtiger Schritt für uns und für die kommende „Nectar“-Stufe der Coordinator-freien, vollständig dezentralisierten Version von IOTA. Mit Ihrer Hilfe können wir einige der Parameter abstimmen, um einen wünschenswerten Kompromiss zwischen Leistung und Sicherheit des Netzwerks zu finden.

Die vollständige Liste der Änderungen beinhaltet:

  • Integration von Mana mit FPC
  • Integrieren von Mana mit dem Autopeering
  • Hinzufügen mehrerer FPC-Optimierungen
  • Hinzufügen der dRNG-Diagnose-API
  • Vereinfachen der Speichernutzung des Dashboards und Anpassen an Grafana
  • Diagramm für Stored, Solidifier, Scheduler und Booker MPS hinzufügen
  • Update auf die neueste hive.go

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

Mana im FPC

Das Fast Probabilistic Consensus (FPC)-Protokoll wird als Teil des Konsens-Mechanismus in der Coordicide-Lösung verwendet, und Sie können eine genauere Beschreibung im FPC-Blogpost finden. Bisher hat dieses Konsensmodul die Meinungen jedes Knotens gleich behandelt, allerdings bietet dies 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 stattdessen ihr Quorum, indem sie die abzufragenden Knoten proportional zu ihrem Mana auswählen.

Diese Integration ist ein erster wichtiger Schritt, um unser Mana-System als Sybil-Schutz- und Reputationssystem in einer Testnetzumgebung zu testen. Wir erwarten einige interessante Ergebnisse aus dieser Implementierung, da wir auch mehrere experimentelle Verbesserungen des Protokolls eingeführt haben, die sowohl durch interne als auch durch Peer-Review-Forschung vorgebracht wurden.

Mana im Autopeering

Damit das Netzwerk effizient arbeiten kann und die Knoten über den Zustand des Ledgers auf dem Laufenden gehalten werden, tauschen die Knoten untereinander Informationen wie Nachrichten und Transaktionen aus. Jeder Knoten baut einen Kommunikationskanal mit einer kleinen Teilmenge von Knoten (d.h. Nachbarn) über einen Prozess namens Peering auf. Ein solcher Prozess muss widerstandsfähig gegen Eclipse-Angriffe sein: Wenn alle Nachbarn eines Knotens von einem Angreifer kontrolliert werden, dann hat der Angreifer die vollständige Kontrolle über die Sicht des Knotens auf das Tangle. Weitere Informationen über das Autopeering-Modul finden Sie in unseren Blog-Beiträgen: Autopeering Teil 1 und Teil 2.

Um Sybil-basierte Angriffe zu verhindern/einzuschränken, macht das Autopeering Gebrauch von Mana: Beliebige Knoten ohne Mana können erstellt werden, aber es gibt eine Grenze, wie viele Knoten mit einer bestimmten Menge an Mana erstellt werden können. Genauer gesagt wird es für einen Angreifer prohibitiv schwierig, viele Knoten mit hohem Mana zu erzeugen.

Im Kern verwendet das Autopeering-Modul einen Screening-Prozess namens Mana-Rank, der eine Teilmenge aller bekannten Knoten auf der Grundlage ihrer Mana-Ähnlichkeit auswählt. Das bedeutet, dass Knoten mit ähnlichem Mana mit größerer Wahrscheinlichkeit zu Nachbarn werden.

Durch die Einführung von Mana in das Autopeering-Modul können wir auf das Pollen-Testnetz zurückgreifen, um zu untersuchen, welche Parameter für den Netzwerkgraphen sicher und stabil sind und welche Auswirkungen dies auf das Netzwerk hat. Wenn wir die Konsens-Mana-Verteilung im aktuellen Pollen-Netzwerk betrachten, können wir einige interessante Topologien erwarten, die davon abhängen, wie die Parameter für den Mana-Rang ausgewählt werden, und dies kann unsere Forschungsbemühungen aufklären und rückkoppeln. Die Abbildung unten zeigt zum Beispiel die Veränderung der Netzwerktopologie, wenn der R-Parameter verringert wird, der bestimmt, wie weit im Netzwerkraum High-Mana-Knoten von Low-Mana-Knoten entfernt sind.

IOTA Mana

Was kommt als Nächstes?

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

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-5-release-notes/