Murksers technische Analyse – 29.03.2021

Ausbruch voraus. Murkser stellt wieder für die neue Woche, eine neue Analyse bereit. IOTA schwebt zwar noch hin und her, verteidigt aber kräftig die wichtigen Chartmarken. Aber kann IOTA noch sinken? Es ist möglich, sogar auf 0,95$, für den ein oder anderen ein Traum zum nachkaufen. Wer darüber mehr erfahren will, sollte definitiv das Video von Murkser angucken.

Wer nicht so stark in IOTA investiert ist, sollte dennoch einschalten, denn er analysiert auch den Bitcoin und den Aktienmarkt. Abonnieren nicht vergessen.

IOTA Token Liquidity jetzt auf Binance Smart Chain verfügbar

In unserem kontinuierlichen Bemühen, Brücken zwischen komplementären Blockchains zu bauen, freuen wir uns, mitteilen zu können, dass Wrapped IOTA jetzt auf Binance Smart Chain verfügbar ist! Jetzt, mit Wrapped IOTA auf Binance Smart Chain, können IOTA-Inhaber den IOTA-Token verwenden, um an DeFi-Anwendungen auf dem Binance-Netzwerk teilzunehmen. Wir sehen diese Integration mit Binance Smart Chain als den ersten Schritt, um die Liquidität über mehrere Ketten hinweg zu erhöhen, während wir uns auch auf die Möglichkeit vorbereiten, dass andere Vermögenswerte auf dem IOTA-Netzwerk leben können.

Heute ist ein aufregender Tag für das IOTA-Netzwerk: Es ist eines der ersten Beispiele, dass der IOTA-Token auf einem anderen Protokoll lebt: Binance Smart Chain. Mit der Veröffentlichung dieser Funktion lebt die Liquidität des IOTA-Tokens offiziell auf mehreren Netzwerken! Jetzt können IOTA-Entwickler damit beginnen, die Funktionalität des IOTA-Tokens auf Anwendungen zu erweitern, die IOTA schließlich mit mehreren Ökosystemen verbinden werden.

Was ist Binance Smart Chain?

Binance Smart Chain ist eine Blockchain, die von Binance entwickelt wurde, um ein Ökosystem von dezentralen Anwendungen, NFTs und digitalen Vermögenswerten zu entwickeln. Ähnlich wie bei Ethereum können Entwickler native Smart Contracts auf BSC zu deutlich niedrigeren Gebühren im Vergleich zu anderen Blockchains auf dem Markt bereitstellen.

Was ist Asset Wrapping?

Asset Wrapping ist der Prozess, einen Vermögenswert aus einem Netzwerk zu nehmen und ihn in einem anderen Netzwerk leben zu lassen. Während es mehrere Möglichkeiten gibt, wie Asset Wrapping funktioniert, erfordert es im Allgemeinen, dass eine dritte Partei oder eine Gruppe von dezentralen Parteien Vermögenswerte verwahren kann. Sobald ein Vermögenswert verwahrt (oder gehalten) werden kann, wird ein System geschaffen, das transparent alle Token in einem bestimmten Netzwerk anzeigt, die für das Wrapping gesperrt sind. Mit dieser Transparenz kann ein Netzwerk dann eine 1:1-Darstellung eines in der Verwahrung gesperrten Tokens „prägen“.

IOTA Binance

Mit der Binance Bridge kann jeder IOTA-Token an den Tauschdienst senden, um IOTA gegen Binance IOTA zu tauschen. Diese Brücke funktioniert in beide Richtungen und ist das primäre Portal für IOTA-Token-Inhaber, um IOTA-Token für die Verwendung im Binance Chain-Ökosystem zu erstellen. Sobald der Austausch abgeschlossen ist, wird der IOTA BEP20-Token in der Binance-Wallet, die mit dem Service verbunden ist, sichtbar sein. Von dort aus können Nutzer mit den Diensten handeln, tauschen und interagieren wie mit jedem anderen BEP20-Asset.

Jetzt können IOTA-Token verwendet werden, um Einsätze zu tätigen, Erträge zu erzielen, zu verdienen und an einer wachsenden Anzahl von Anwendungen teilzunehmen, die die Vorteile des Binance Smart Chains Ökosystems von Produkten und Dienstleistungen nutzen.

Was kommt als nächstes?

Cross-Chain-Liquidität ist die Säule eines jeden dezentralen Ökosystems. Das IOTA-Ökosystem wächst und wird dezentraler, indem es IOTA-Liquidität für andere Netzwerke verfügbar macht. Wir sehen diese Integration mit Binance Smart Chain als den ersten Schritt, um die Liquidität über mehrere Ketten hinweg zu erhöhen und gleichzeitig die Möglichkeit vorzubereiten, dass andere Vermögenswerte im IOTA-Netzwerk leben können.

Original by IOTA Foundation: https://blog.iota.org/iota-token-liquidity-now-available-on-binance-smart-chain/

Neue Kooperation zwischen IOTA und Cartesi

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

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

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

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

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

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

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

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

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

  • Die Cartesi Linux Virtual Machine wird als benutzerdefinierte VM für IOTA Smart Contracts (ISCP) hinzugefügt. Das wird es Entwicklern ermöglichen, Smart Contracts mit Mainstream-Softwarekomponenten zu erstellen. Mit größerer Ausdruckskraft und einer Umgebung, die den meisten Entwicklern auf der Welt vertraut ist, wird das neue leistungsstarke Möglichkeiten in DeFi, Gaming, NFT’s und mehr mit sich bringen. Die Cartesi Linux Virtual Machine wird auch ein mächtiges Werkzeug für die Einführung in Firmen und Unternehmen für beide Gemeinschaften sein.
  • IOTA Oracles: Durch die Integration von IOTA Oracles in Cartesi werden Unternehmensserver und intelligente Geräte in der Lage sein, die Integrität und Provenienz von Daten zu prüfen und verifizierbare Batch-Verarbeitungen durchzuführen. Das wird industriellen Systemen, die Cartesis Blockchain-Technologie und Linux Virtual Machine nutzen, noch mehr Transparenz und Sicherheit verleihen.

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

Diese Ankündigung stellt eine Fortsetzung unseres Engagements dar, Brücken mit gleichgesinnten Organisationen zu bauen, von denen wir glauben, dass sie zur Vorwärtsbewegung der Branche beitragen. Wir hoffen, dass unsere Gemeinschaften zusammenkommen werden, um Innovationen zu entwickeln und aufregende Werkzeuge zu bauen, die den globalen Fußabdruck der dezentralen Technologien erweitern.

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

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

Über Cartesi

Cartesi hebt Smart Contracts auf die nächste Stufe. Es ist eine ketten-agnostische Layer-2-Infrastruktur, die das drängende Problem der Skalierbarkeit auf den wichtigsten Blockchains löst. Vor allem implementiert Cartesi eine einzigartige Linux-unterstützende VM, Rollups und Side-Chains, um die Art und Weise, wie Entwickler Blockchain-Anwendungen erstellen, zu revolutionieren und ihnen die Verwendung von Mainstream-Software-Komponenten zu ermöglichen.

Über IOTA

Die IOTA Foundation ist eine globale, gemeinnützige Stiftung mit Sitz in Deutschland. Die Aufgabe der IOTA Foundation ist es, die Forschung und Entwicklung neuer Distributed-Ledger-Technologien (DLT) zu unterstützen, darunter auch die IOTA Tangle. Die Stiftung fördert die Ausbildung und Annahme von Distributed-Ledger-Technologien durch die Schaffung von Ökosystemen und die Standardisierung dieser neuen Protokolle.

Der IOTA Tangle geht über Blockchain hinaus, indem er die weltweit erste skalierbare, gefühllose und vollständig dezentralisierte Distributed-Ledger-Technologie bereitstellt. Der Tangle nutzt seine eigene einzigartige Technologie, um drei grundlegende Probleme der Blockchain-Technologie zu lösen: hohe Gebühren, Skalierung und Zentralisierung. Es ist ein Open-Source-Protokoll, das die menschliche Wirtschaft mit der Maschinenwirtschaft verbindet, indem es neuartige Machine-to-Machine (M2M)-Interaktionen ermöglicht, einschließlich sicherer Datenübertragung, gefühlsloser Mikrozahlungen und sicherer Zugangskontrolle für Geräte.

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

Firefly Beta Veröffentlichung

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

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

Firefly herunterladen

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

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

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

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

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

IOTA Stronghold download

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

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

download stronghold wallet

Wie geht es weiter?

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

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

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

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

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

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

Murksers technische Analyse – 22.03.2021

Mit Erlaubnis präsentieren wir ab heute alle neuen technischen Analysen von IOTA Communitymitglied Murkser. In diesem Video analysiert er, wie gut die Alt-Season gehen kann und ob IOTA über 10$ oder sogar mehr steigen kann, wer diese Aussicht nicht verpassen will, sollte definitiv diese TA gucken. Auch wer in Bitcoin investiert ist, sollte sich dieses Video angucken.

Wer also vorhatte, IOTA zu kaufen und wollte wissen, ob heute ein guter Zeitpunkt ist, wird mit dieser Analyse zufrieden sein. Abonniert ihn, folgt ihm auf Twitter und hinterlasst fleißig Kommentare. Bis nächste Woche.

IOTA Stronghold: Beta Veröffentlichung

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

Wir haben diese Beta-Version „Festung Boden“ getauft, nach der Festung in Nordschweden, die zum Schutz des Landes und des Transports der „Industriemünze“ – Eisenerz – während der Weltkriege in der ersten Hälfte des 20. Jahrhunderts errichtet wurde. Seine Nützlichkeit erwies sich als erwiesen und er wurde auch während des Kalten Krieges weiter verwendet. Wie die Beta-Version von Stronghold auch, war die Bodenfestung eine temporäre Lösung, die nur kurzlebig war und nach ihrer Dienstzeit abgebaut wurde. Trotzdem war die Bodenfestung fast hundert Jahre lang in Betrieb. Wir sind uns ziemlich sicher, dass die Beta von Stronghold viel, viel kürzer sein wird.

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

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

Boden Festung iota wallet

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

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

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

Halt die Klappe und nimm mein Geld

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

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

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

Wenn Sie eine Flagge finden, besuchen Sie bitte die Stronghold-Diskussion auf GitHub, um Anweisungen für die Aufnahme in die Rangliste zu erhalten. Viel Glück!

Was kommt als nächstes

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

Technische Hinweise zum Release

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

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

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

Status: Beta
CHANGELOG

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

Status: Beta
CHANGELOG

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

Status: Beta
CHANGELOG

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

Status: Beta
CHANGELOG

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

Status: Beta
CHANGELOG

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

Status: Alpha
CHANGELOG

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

Status: Beta
CHANGELOG

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

Erklärung des IOTA Congestion Control Algorithmus

Dieser Artikel erklärt in einigen technischen Details den IOTA Congestion Control Algorithm (ICCA), der im IOTA 2.0 Protokoll (Coordicide) verwendet wird. Wir wollten diesen Überblick anbieten, um die Beziehung zwischen Access und Mana zu klären, die in unserem vorherigen Beitrag über Mana angesprochen wurde.  Außerdem sind wir uns bewusst, dass viele begierig sind, mehr über Coordicide zu erfahren, und dass Interessenvertreter aus dem gesamten IOTA-Umfeld von diesem Wissen profitieren. Das heißt, die in diesem Artikel enthaltenen Informationen sind kein „erforderliches Wissen“, um IOTA zu nutzen. Außerdem werden alle Aspekte, die in diesem Artikel besprochen werden, Teil unserer vollständigen Spezifikation sein. Wenn Sie Fragen haben, besuchen Sie bitte unseren Discord, um sie mit unseren Entwicklern und Forschern zu diskutieren. Die Congestion Control (dt. Überlastungskontolle) ist ein wichtiger und faszinierender Aspekt von Coordicide, daher hoffen wir, dass Sie diese Erklärung genießen.

Unser besonderer Dank gilt Bob Shorten und seinem Team am Imperial College London für ihre Arbeit bei der Mitentwicklung dieses wichtigen Algorithmus. Ihre Arbeit hat maßgeblich zur Entwicklung dieser wichtigen Komponente und zur Validierung ihres Betriebsverhaltens beigetragen.

Eine ausführliche Erklärung finden Sie in unserem ersten Artikel zu diesem Thema, der zur Präsentation auf dem 7th IEEE/IFIP Workshop on Security for Emerging Distributed Network Technologies angenommen wurde.

Was ist Congestion Control und warum benötigen wir sie?

In den meisten DLTs werden Informationen über das Netzwerk durch einen Prozess namens „Gossiping“ weitergegeben, bei dem die teilnehmenden Nodes Nachrichten von einem Nachbarn erhalten und diese dann an andere Nachbarn weiterleiten. Natürlich erhalten die Nodes viele Nachrichten, so dass sie entscheiden müssen, welche dieser Nachrichten sie an ihre Nachbarn weiterleiten und in welcher Reihenfolge sie dies tun. Ein Algorithmus zur Überlastungskontrolle trifft diese Entscheidungen.

Eine Überlastung tritt auf, wenn ein Netzwerk mehr Datenverkehr hat, als es bewältigen kann. Ohne eine angemessene Überlastungskontrolle kann das Netzwerk übersättigt werden und nicht mehr funktionieren, da die Nodes ihre Nachbarn mit mehr Nachrichten überfluten können, als von einem einzelnen Node verarbeitet werden können. Durch die Entscheidung, welche Nachrichten weitergeleitet werden sollen, wird ein Congestion Control-Algorithmus eingesetzt, um diese Überlastung zu verhindern. In einem unsharded DLT ist das Problem besonders akut, da jeder Netzwerkteilnehmer („die Node“) alle gültigen Transaktionen verarbeiten muss. Daher ist der Gesamtdurchsatz des Netzwerks (informell als Transaktionen pro Sekunde bezeichnet) letztlich durch die verfügbaren Ressourcen wie Internetanbindung, Geräteverarbeitung und Speicherkapazitäten begrenzt.

Da jedoch ein Congestion-Control-Algorithmus entscheidet, welche Nachrichten weiter gesendet (geklatscht) werden, bestimmt er im Wesentlichen, wer Zugang zum Netzwerk hat; der Congestion-Control-Algorithmus hat einen tiefgreifenden Einfluss auf das Benutzererlebnis. Um „Coordicide“ zu verdeutlichen, möchten die Autoren ICCA erklären, das im IOTA 2.0-Protokoll (Coordicide) verwendet wird.

Congestion Control ist ein sehr altes Thema, das intensiv untersucht wurde, als die Infrastruktur des Internets entwickelt wurde. Im Gegensatz zu den meisten Netzwerken haben DLTs jedoch sehr strenge Anforderungen, die die Congestion Control zu einem besonders schwierig zu lösenden Problem machen. Insbesondere müssen die folgenden Anforderungen erfüllt werden (es gibt noch weitere Anforderungen, auf die wir weiter unten näher eingehen, aber diese sind die wichtigsten):

  • Fairer Zugang: der Netzwerkzugang muss proportional zu einer „knappen Ressource“ gewährt werden
  • Angriffsresistenz: böswillige Nodes können das Netzwerk nicht stören
  • Konsistenz: alle Nodes müssen die gleichen Nachrichten in ihr lokales Ledger schreiben

Blockchains lösen die Überlastungskontrolle, indem sie einige Mechanismen verwenden, um Anführer zu wählen, die Blöcke minen. Der Zugang ist fair, da die Rate, mit der ein Anführer gewählt wird, proportional zu seinem Einsatz oder seiner Hashing-Power ist. Da der Zugriff nur auf die Anführer beschränkt ist, ist eine Überlastung nie möglich, auch nicht während eines Angriffs. Letztendlich wird ein Konsens erreicht, da Blockchains ein Konsensmodul haben, um einen Anführer zu wählen. Die Beschränkung des Zugriffs auf „Anführer“ macht es für PoS- und PoW-Architekturen einfacher, zentralisiert aber den Zugriff.

Da IOTA eine DAG und keine Blockchain verwendet, können (und wollen) wir keine Art von Leader-Wahlprozess verwenden. Stattdessen verwendet die ICCA einen sogenannten Scheduler, der Nachrichten auswählt, die „planmäßig“ sind. Geplante Nachrichten werden in den lokalen Tangle geschrieben und an die Nachbarn des Node weitergeleitet. Der Scheduler plant Nachrichten mit einer konstanten Rate ein, wodurch sichergestellt wird, dass keiner der Nachbarn überlastet wird.

Nun können wir erörtern, wie das ICCA unsere drei oben genannten Hauptanforderungen – fairer Zugriff, Angriffsresistenz und Konsistenz – erreicht. Zunächst können wir sehen, dass jeder Node lokal den Verkehr fair nach Mana plant. Es stellt sich heraus, dass dies auch global gilt und dass der Zugriff fair nach Mana vergeben wird.

Zweitens, was passiert, wenn ein Angreifer versucht, das Netzwerk voll zu spammen? Lokal werden die Nodes die Nachrichten des Angreifers nicht schneller als ihre erlaubte Rate verarbeiten. Die Nachrichten des Angreifers werden sich also anhäufen und seine Warteschlange wird wachsen. Alle Nodes werden dies erkennen und den Angreifer aus dem Netzwerk verbannen. Natürlich gibt es zahlreiche andere Angriffsmethoden, die wir untersucht haben, aber der Scheduler ist schwer auszutricksen, so dass der Algorithmus recht widerstandsfähig gegen Angreifer ist.

Da der Scheduler niemals ehrliche Nachrichten löscht, stellt der Algorithmus schließlich sicher, dass sie alle Nodes erreichen. Wenn ein Angreifer aus dem Netzwerk verbannt wird, was passiert dann mit den von ihm ausgegebenen Nachrichten? Da das Verhalten des Angreifers nachweisbar ist, werden die meisten Nodes den Angreifer im gleichen Moment verbannen, wodurch sichergestellt wird, dass die Ledger nahezu identisch sind. Dann verfügt das Gossip-Protokoll über einen Mechanismus namens „Solidification“, der winzige Unterschiede in den Tangles korrigieren kann.

Im Folgenden finden Sie einen technischeren Überblick über die ICCA, da eine tiefere Analyse der Anforderungen präsentiert wird.

Anforderungen für jede DLT

Es gibt einige allgemeine Anforderungen und einige davon sind entscheidend für den Erfolg eines jeden DLT-Congestion-Control-Algorithmus: Konsistenz, fairer Zugriff, Auslastung, faire Latenzzeit und Angriffsresistenz.

Konsistenz

Konsistenz bedeutet, dass jede Node die exakt gleichen Nachrichten in den Ledger schreibt. Wenn das Netzwerk überlastet ist, sind die Nodes möglicherweise gezwungen, einige Nachrichten zu verwerfen, was zu Inkonsistenzen führt. Das Ziel des ICCA ist es, das Verwerfen von Nachrichten auf ein Minimum zu reduzieren und die verbleibenden Inkonsistenzen durch Solidification Requests zu beheben. Ohne dies gibt es keinen Konsens.

Fairer Zugriff

Da die verfügbaren Netzwerkressourcen endlich sind, muss der Zugriff (äquivalent dazu der Durchsatz) in irgendeiner Weise eingeschränkt werden. In DLTs wird dies üblicherweise durch die Beschränkung des Zugriffs durch eine „knappe Ressource“ gewährleistet. Viele DLTs nutzen Energie als knappe Ressource, indem sie von Minern verlangen, PoW zu betreiben. Proof-of-Stake-DLTs verwenden oft den Token selbst als knappe Ressource; IOTA verwendet Mana (siehe unseren Mana-Blogbeitrag und dessen Folgeartikel).

Fairer Zugang bedeutet, dass alle Nodes einen fairen Anteil des Durchsatzes erhalten sollten. Es ist wichtig zu beachten, dass dieser Zugang linear proportional zur Menge des Manas sein muss: Wenn der Zugang sublinear vergeben wird – also immer weniger Zugang mit mehr Mana – dann werden große Akteure ihr Mana auf kleinere Nodes aufteilen, um unfairen Zugang zu erhalten. Wenn es superlinear ist – also mehr Zugang mit mehr Mana gewährt wird – dann haben große Inhaber einen Vorteil. Dies schafft Anreize für Nodes, ihre Ressourcen zu bündeln, wie bei Mining-Pools. Sowohl sublineare als auch superlineare Zugriffsvergaben sind im Allgemeinen unfair und fördern ein Verhalten, das dem Netzwerk langfristig schaden könnte.

Auslastung

Wenn es eine Nachfrage gibt, wird das volle Potenzial des Netzwerks genutzt.

Denken Sie zum Beispiel an eine triviale Zugangskontrolle, bei der der Durchsatz jeder Node durch seinen prozentualen Mana-Anteil gedeckelt ist, sagen wir 10% Mana erlauben einem Benutzer maximal 10% der Bandbreite. Das wäre zwar fair, aber ineffizient: Wenn z.B. 95% des Manas offline sind, dann würde das Netzwerk mit 5% Kapazität arbeiten. Ein effizienter Mechanismus zur Überlastungskontrolle muss diese ungenutzte Kapazität umfunktionieren.

Die Kombination von Auslastung und Fairness ist kompliziert. Die Frage „Wie viel Mana brauche ich für X TPS“ ist schwer zu beantworten. Aber denken Sie daran: Auslastung ist eine gute Sache! Ohne sie wäre das Netzwerk unbrauchbar.

Auslastung und Fairness bilden zusammen ein Konzept namens „Max-min-Fairness“. Dies ist ein wichtiges Konzept aus der klassischen Netzwerktechnik. Router, die Internet-Verkehr weiterleiten, brauchen genau diese Eigenschaften (stellen Sie sich vor, wenn Ihre lokalen Router diese Eigenschaften nicht hätten, wäre Ihr Heim-Internet unbrauchbar).

Faire Latenzzeit

Alle ehrlichen Benutzer sollten eine ähnliche Latenzzeit erfahren. Die Latenz ist die Zeit, die eine ausgegebene Nachricht benötigt, um sich an alle Nodes zu verbreiten. Diese Latenzzeit muss sowohl für ein gutes Benutzererlebnis als auch für die Stabilität des Protokolls gering sein.

Die Benutzererfahrung sollte für sich selbst sprechen; niemand mag Verzögerungen. Für die Stabilität des Protokolls wäre es jedoch ein perverser Anreiz, vom Algorithmus abzuweichen, wenn die Latenzzeit für verschiedene Benutzer dramatisch unterschiedlich wäre. Die Bestrafung der Latenz von böswilligen Nodes ist aus spieltheoretischer Sicht gut. Wenn also die Latenz von Nodes ansteigt, wenn sie sich falsch verhalten, dann werden sie bestraft und somit zu ihrem Verhalten ermutigt.

Angriffsresistent

Diese oben genannten Eigenschaften müssen für ehrliche Nodes auch dann gelten, wenn ein Angreifer versucht, das System zu knacken. Die Nodes haben einen Anreiz, ihren Zugriff zu erhöhen und ihre Latenzzeit zu verringern. Abweichungen sollten unmöglich sein oder bestraft werden.

IOTA Congestion Control Algorithmus (ICCA)

Der IOTA Congestion Control Algorithm (ICCA) rationalisiert den Transaktionsprozess, um die Auswirkungen einer möglichen Überlastung zu minimieren und den Schreibzugriff auf den Ledger zu regulieren. Der ICCA erreicht dies durch seine drei Teile: den Scheduler, den Rate Setter und den Blacklister.

Der Scheduler bestimmt, welche Transaktionen in den Ledger geschrieben und geklatscht werden. Der Rate Setter verwendet einen klassischen AIMD-Algorithmus (Additive Increase Multiplicative Decrease), um die Rate jedes Einzelnen anzupassen. Blacklisting zensiert Nodes, die das Netzwerk angreifen.

Dies ist – soweit wir wissen – der erste nicht Proof of Work, DAG-basierte Congestion Control Algorithmus, der im Bereich der Kryptowährungen veröffentlicht wurde. Er ist die neuartigste Komponente von Coordicide und ein Grundpfeiler des IOTA 2.0 Protokolls.

Node-Modell

iota congestion control algorithm erklärung

Von dem Netzwerk-Layer (siehe diesen Link zur Terminologie) kommen Nachrichten über Gossip von den Nachbarn an, werden auf Duplikate und ungültige Nachrichten gefiltert und kommen im Posteingang an, wo sie sich in die Warteschlange gemäß der ausstellenden Node-ID einreihen. Der Posteingang empfängt auch Nachrichten, die lokal vom Rateneinsteller der Node erstellt wurden. Der Blacklister überwacht die Warteschlangen des Posteingangs auf böswilliges Verhalten, und der Scheduler entscheidet, welche Nachrichten den Posteingang verlassen dürfen.  Nachdem eine Nachricht eingeplant wurde, finden die folgenden Aufgaben gleichzeitig statt:

  • Die Nachricht wird an alle Nachbarn außer dem, von dem wir sie erhalten haben, geklatscht (an die Netzwerkschicht zurückgegeben)
  • Die entsprechende Anwendung (aus dem Applikations-Layer) wird aufgerufen, um die Nutzlast zu parsen
  • Die Nachricht wird in den lokalen Tangle „geschrieben“, wo sie als Tip betrachtet werden kann, von FPC abgestimmt wird, im Ledger verbucht wird, usw.

Planer

In der ICCA schlagen wir die Verwendung einer modifizierten Version eines Deficit Round Robin-Schedulers vor. Abgesehen von der Tatsache, dass ein solcher Scheduler alle oben genannten Anforderungen erfüllt (d. h. Konsistenz, Auslastung, Fairness und Angriffsresistenz), haben wir uns für ihn entschieden, weil er leichtgewichtig ist. Er ist zum Beispiel die Standardoption, um eine sehr große Anzahl von Threads für den Linux-Kernel effizient zu handhaben.

Der Scheduler funktioniert folgendermaßen: Nachdem Nachrichten empfangen wurden, werden sie im Posteingang abgelegt. Jeder Nachricht wird eine „Arbeitsbewertung“ zugewiesen, die darauf basiert, wie viele Ressourcen sie verbraucht. Größere Nachrichten haben größere Punktzahlen, da sie mehr Bandbreite verbrauchen. Eine Nachricht mit einer Transaktion, die 100 Signaturen enthält, hat eine höhere Punktzahl als eine Transaktion mit einer Signatur, da die Validierung der Signaturen mehr Ressourcen erfordert. Im Wesentlichen sorgt der Scheduler dafür, dass eine maximale Anzahl von Ressourcen pro Sekunde verbraucht wird. Die Forscher und Ingenieure, die dies entwickeln, haben völlige Freiheit, diese Arbeitsfunktion zu definieren, um den Algorithmus genau an die Bedürfnisse des IOTA-Netzwerks anzupassen.

Wenn Nachrichten empfangen werden, werden sie von ihrem abgebenden Node in verschiedene Warteschlangen sortiert. Der Scheduler besucht jede Warteschlange, plant eine Anzahl von Nachrichten basierend auf dem Mana (die „knappe Ressource“, die in IOTA verwendet wird), das die ausstellende Node besitzt, und geht dann zur nächsten Warteschlange über. Wenn eine Warteschlange leer ist, wird sie übersprungen; der Scheduler plant dann aus anderen Warteschlangen. Auf diese Weise werden die Nachrichten aller Nodes proportional zu ihrem Mana verarbeitet, solange ihre Warteschlange nicht leer wird.

Der Posteingang der Nodes wird in Warteschlangen aufgeteilt, wobei für jede Node im Netzwerk eine Warteschlange zur Verfügung steht; ein Deficit-Round-Robin-Scheduler kann Zehntausende von Warteschlangen effizient verarbeiten. Nachrichten werden dann in die Warteschlange der Node gestellt, der die Nachricht ausgegeben hat. Der Scheduler besucht jede nicht leere Warteschlange in einer deterministischen Reihenfolge. Jeder Warteschlange wird eine Menge zugewiesen, die „Guthaben“ für diesen Node genannt wird. Wenn der Scheduler eine Warteschlange besucht, fügt er einen bestimmten Prioritätswert proportional zum Mana der entsprechenden Knoten-ID hinzu. Er plant dann Nachrichten aus der Warteschlange dieser Node ein. Jedes Mal, wenn eine Nachricht eingeplant und weiterverarbeitet wird, wird der „Arbeitswert“ der Nachricht vom Guthaben abgezogen. Wenn keine weiteren Nachrichten aus der Warteschlange von N eingeplant werden können oder das Guthaben negativ wird, wechselt der Scheduler zur nächsten Warteschlange.

Derzeit planen wir Nachrichten mit einer festen/maximalen voreingestellten Rate. Zurzeit analysieren und untersuchen wir verschiedene Möglichkeiten, diesen Schwellenwert dynamisch zu gestalten, so dass das Netzwerk durch Sharding natürlich skaliert werden kann.

Aber was passiert, wenn ein Angreifer oder ein egoistischer Node sich nicht an die Regeln des Schedulers hält? Nehmen wir an, dass eine egoistischer Node beschließt, nur seine eigenen Transaktionen weiterzuleiten. Das würde dazu führen, dass die entsprechende Warteschlange in den Posteingangspuffern der ehrlichen Nodes aufgebläht wird, was zu großen Verzögerungen nur für seine eigenen Transaktionen führt. Das Gleiche gilt für böswillige Nodes: Solange ehrliche Nodes dem defizitären Round-Robin-Scheduler folgen, würden Transaktionen von Angreifern nicht weitergeleitet werden.

Rate Setter

Woher weiß eine Node, wie viele Nachrichten er ausgeben kann? Er verwendet den Rate Setter. Basierend auf der Warteschlangenlänge verwendet der Rate Setter den AIMD-Algorithmus, um seine eigene Transaktionserzeugungsrate zu regulieren. Ein ähnlicher Algorithmus wird von Routern im Internet verwendet, um den Datenverkehr anzupassen.

Eine Node kann die Länge seiner eigenen Warteschlange überwachen. Wenn diese Warteschlange zu lang wird, weiß er, dass er zu viele Nachrichten ausgibt. Eine Node erhöht seine Ausgaberate langsam (Additive Erhöhung), bis seine Warteschlange zu lang wird. An diesem Punkt verringert die Node schnell seine Ausgaberate (Multiplikative Verringerung), um eine bevorstehende Überlastung zu verhindern. Auf diese Weise konvergiert der Rate Setter schließlich zu einer fairen Ausgaberate, abhängig von den aktuellen Datenverkehrsbedingungen.

Als zusätzlicher Vorteil sorgt der Rate Setter dafür, dass die Latenzzeit für Transaktionen, die von Knoten ausgegeben werden, die dem Protokoll folgen, gering ist. Nodes, die diesem Algorithmus nicht folgen, überfluten ihre Warteschlangen und erhöhen ihre Latenz. Auf diese Weise erhalten die Nodes einen Anreiz, den Rate Setter zu verwenden.

Was passiert, wenn böswillige Nodes den Rate Setter nicht verwenden? Was ist, wenn sie sich nicht um die Erhöhung der Latenz kümmern, z. B. bei einem Spam-Angriff? Die folgenden Abschnitte enthalten Sicherheitsmaßnahmen, die wir eingerichtet haben und die ausgelöst werden, bevor ein Angreifer der Konsistenz schaden kann.

Blacklisting

Was passiert, wenn die Node den Rate Setter nicht verwendet? Dann wird er seine Rate nicht reduzieren, wenn seine Warteschlange wächst, und so wird seine Warteschlange weiter wachsen. Da die anderen ehrlichen Nodes nur so viel Speicher haben, kann keine Warteschlange unendlich wachsen. Daher hat das ICCA den Blacklister, um die Länge der Warteschlangen zu begrenzen. Je nach Mana darf ein Node eine bestimmte Anzahl von Nachrichten in der Warteschlange haben. Wenn diese Anzahl einen bestimmten Schwellenwert überschreitet, wird die Node vorübergehend auf eine schwarze Liste gesetzt, was bedeutet, dass für eine gewisse Zeit keine weiteren Transaktionen von diesem Node in den Posteingang aufgenommen werden. Wenn die Warteschlange einer Node zu explodieren beginnt, werden die neu eingehenden Nachrichten für diese Node verworfen.

Kontrollsatz

Ein Angreifer kann versuchen, das Netzwerk mit großen Mengen an Spam zu überfluten, indem er direkt versucht, Hunderte von Nodes auf einmal zu überlasten. Zum Schutz vor solchen Angriffen verwenden wir einen Mechanismus namens Rate-Control (dt. Ratenkontrolle) als grobe Unterbrechung, der die Menge der Nachrichten, die eine Node senden kann, physikalisch begrenzt. Dazu verwenden wir ein adaptives PoW als Ratenkontrollmechanismus. Für ehrliche Nodes ist die PoW-Schwierigkeit relativ gering. Wenn eine Node jedoch anfängt zu spammen, steigt die Schwierigkeit exponentiell an, was ihn physisch daran hindert, mehr Nachrichten zu versenden. Dieser Mechanismus würde also verhindern, dass das System komplett überlastet wird.

So nützlich der Mechanismus zur Ratenkontrolle auch ist, er ist möglicherweise nicht notwendig. Das ICCA hat das Potenzial, so stark zu sein, dass dieses Modul überflüssig ist. In der ersten Version des Coordicide-Protokolls wollen wir jedoch den maximalen Schutz gewährleisten, und eine eventuelle spätere Verringerung oder Entfernung jeglicher PoW bleibt als zukünftige Optimierung übrig. Im GoShimmer-Testnetz werden wir das Zusammenspiel zwischen der adaptiven PoW-Ratensteuerung und dem ICCA untersuchen.

Null Mana Nachrichten

Leider erfordert das ICCA, dass Nodes ein gewisses Mana haben müssen, um Nachrichten ausgeben zu können, denn Nodes mit 0 Mana erhalten niemals Guthaben und ohne Guthaben werden ihre Nachrichten nicht eingeplant. Dies ist wichtig, um billige Angriffe zu vermeiden: Ohne dies könnten Nodes mit niedrigem Mana einen Ansturm von Transaktionen erzeugen, wodurch das Netzwerk überlastet und die Konsistenz des Ledgers beeinträchtigt wird.

Wir können verschiedene Optionen anbieten, damit Null-Mana-Nodes in der Lage sind, ihre Transaktionen auszugeben. Eine Möglichkeit ist über einen Faucet, bei dem jede Node freiwillig sein ungenutztes Mana neuen Benutzern anbieten kann, die das Netzwerk ausprobieren wollen, für welchen Anwendungsfall auch immer sie im Sinn haben. Eine andere Möglichkeit ist die Nutzung des Mana-Marktes, auf dem man selbst bestimmen kann, wie und wann man Mana nach Bedarf mieten möchte. Eine weitere Methode besteht darin, Token zu kaufen und sie durch Verpfändung an die Nodes zu transferieren.

Schließlich untersuchen wir eine Möglichkeit, die minimale Mana-Schwelle dynamisch anzupassen, abhängig vom Prozentsatz des aktiven Manas und von den aktuellen Datenverkehrsbedingungen.

In Zeiten mit geringer Überlastung dürfen „validierte Low-Mana-Nodes“ ihre Transaktionen ausgeben und werden von ehrlichen Nodes eingeplant. Ein „validierter Low-Mana-Node“ ist eine Node, der die folgenden zwei Bedingungen erfüllt: Erstens, sein Mana ist kleiner als der minimale Mana-Schwellenwert; und zweitens, die Node hat kürzlich einen großen PoW durchgeführt. Wenn die Überlastung gering ist, lassen ehrliche Nodes vorübergehend Planungen von diesen validierten Low-Mana-Nodes zu. Sobald die Überlastung groß wird, können validierte Low-Mana-Nodes ihre Transaktionen nicht mehr ausgeben; sie müssen auf Zeiten mit geringer Überlastung warten.

Original by William Sanders: https://blog.iota.org/explaining-the-iota-congestion-control-algorithm/

Der Chrysalis Attack-a-thon

Die Mitglieder der IOTA Foundation und das IOTA-Ökosystem sind begierig darauf, Chrysalis im Mainnet zu sehen. Nach Monaten der Entwicklung, des Testens und der Prüfung durch externe Firmen sind wir nun zuversichtlich, für den Übergang zu Chrysalis bereit zu sein.

Kurz davor laden wir die Mitglieder der IOTA Community zum Chrysalis Attack-a-thon ein!

Mit dem Attack-a-thon möchten wir Sie dazu herausfordern, zu versuchen, verschiedene Teile von Chrysalis zu knacken. Sie werden für Ihre Erkenntnisse belohnt!
Verwechseln Sie dies nicht mit dem „incentivierten Testnetz“ von IOTA, das nach dem Erreichen der „Nectar“-Stufe des Coordicide-Testnetzes gestartet wird: Das ist natürlich noch auf der Roadmap und wird nach dem Upgrade auf die „Nectar“-Stufe des Testnetzes geschehen.

Der Chrysalis Attack-a-thon ist eine an Sicherheitsforschern/Entwicklern/Brustschützen orientierte Herausforderung. Jeder ist eingeladen, mitzumachen und zu versuchen, ein paar kleine Preise zu ergattern. Es ist eher als öffentliches und spaßiges Erlebnis gedacht, was sich auch in unseren Belohnungen widerspiegelt 😉

Der Attack-a-thon läuft etwa 10 Tage lang: Er beginnt am 18. März 2021 um 2PM UTC und endet am 28. März 2021 um 11:59 PM UTC.

Der Umfang der Attack-a-thon-Herausforderung

Im Geltungsbereich des Chrysalis Attack-a-thon sind die folgenden IOTA-Komponenten:

  • Die IOTA-Knoten-Software
    • HORNET (Der develop-Zweig)
    • Bee (Der chrysalis-pt-2-Zweig)
  • Bibliotheken
  • stronghold.rs (Der Entwicklungszweig)

Kategorien, Belohnungen und wie man teilnehmen kann

Es kann viele verschiedene Dinge geben, die unsere Community bei ihrer Erkundung möglicher Angriffe auf das Chrysalis-Netzwerk finden könnte, daher haben wir Kategorien für die Einreichungen definiert. Jede Kategorie ist mit einer oder mehreren Belohnungen verbunden.

Die Spielregeln sind ziemlich einfach:

  • Der erste, der innerhalb des definierten Zeitraums einen gültigen Beitrag einreicht, erhält den Preis
  • Jedes Problem im Bereich zählt einzeln (z. B. wenn eine Injektion die Eskalation von Privilegien ermöglicht, zählt dies als zwei Probleme)
  • Das Bewertungskomitee kann die Einsendung zählen, wenn es sich um eine besondere Schwachstelle handelt, die außerhalb des vorgeschlagenen Geltungsbereichs liegt, aber einen starken Bezug zu Chrysalis hat

Kategorien

Es wurden vier Arten von Prioritäten für die Ergebnisse definiert:
Bei den Prioritäten geht es im Wesentlichen um das Kosten-Nutzen-Verhältnis. Und Kosten und Nutzen sollten als weit gefasste Begriffe betrachtet werden: Kosten können Aufwand, Zeit, Geld, erforderliche Koordination usw. sein; Nutzen könnte monetär sein, Reputation, Wettbewerbsvorteil usw.

Priorität 1

Wahrscheinlichkeit: mittel/hoch (ein Angriff kann mit geringen oder gar keinen erweiterten Ressourcen durchgeführt werden)
Schweregrad: korrumpiert/stoppt das Netzwerk vollständig. Verändert willkürlich die Guthaben vieler Benutzer.

  • Konsens-Spaltung des Netzwerks (praktischer Angriff).
  • Willkürliche Kontoübernahme (Token stehlen).
  • Doppeltes Ausgeben von vorhandenem Guthaben oder Verwendung von Guthaben „aus dem Nichts“ oder Treasury Output.
  • Anhalten von Netzwerkbestätigungen insgesamt (Koordinator).
  • Rückgängigmachen einer bestätigten Transaktion.

Priorität 2

Wahrscheinlichkeit: mittel/niedrig (ein Angriff kann unter besonderen Bedingungen durchgeführt werden, mit mittlerem oder hohem Schwierigkeitsgrad zu erstellen)
Schweregrad: Kompromittierung des gesamten Netzwerks mit geringer Wahrscheinlichkeit oder konsequente Beeinträchtigung bestimmter Akteure im Netzwerk mit mäßigen Mitteln.

  • Konsens-Spaltung des Netzwerks (theoretischer Angriff).
  • Zensieren beliebiger Accounts, Verhindern von Bestätigungen.
  • Das Netzwerk dazu bringen, Nachrichten zu akzeptieren, die etablierte „Validierungs“-Regeln verletzen: unzureichendes PoW, missgebildete Nachrichten, Verletzung von Staubregeln, etc.
  • Eclipse-Angriff, willkürliche Kontrolle des Peerings von Knoten.

Priorität 3

Wahrscheinlichkeit: mittel/niedrig, ein Angriff kann unter speziellen Bedingungen durchgeführt werden, mit mittlerem oder hohem Schwierigkeitsgrad zu erstellen.
Schweregrad: Angriffe, die eine begrenzte Anzahl von Akteuren im Netzwerk betreffen.

  • Verursachen, dass Knoten unter „durchschnittlicher“ Netzwerklast abstürzen oder hängen.
  • Verursachen, dass ein Knoten die Verbindung zu einem beliebigen Peer abbricht.
  • Reduzieren der Gesamtbestätigungsrate konstant unter 50%, ohne mehr als 20% Hash-Rate zu halten.
  • Manipulation des Benutzererlebnisses einer einzelnen Wallet, um unerwünschte Aktionen vorzutäuschen: Zahlung an eine falsche Adresse, Anzeige gefälschter Bestätigungszustände,
  • Offenlegung von geheimem Material, Entführung des Migrationsprozesses.

Priorität 4

Wahrscheinlichkeit: mittel/niedrig
Schweregrad: Störung der Endbenutzer-Nutzbarkeit des Netzwerks, Verfügbarkeitsunterbrechungen, etc.

  • Verhindern, dass neue Knoten dem Netzwerk beitreten.
  • Verhindern, dass Wallets Tangle-Daten laden können.
  • Absturz einzelner Knoten unter schwer zu erreichenden spezifischen Bedingungen.

Ausschlüsse

Was nicht bewertet wird (obwohl eine Einreichung des Problems trotzdem sehr willkommen ist):

  • Grafische Fehler (falsche Form einer Box, Text nicht ausgerichtet und ähnliche Dinge)
  • Tippfehler (sofern sie nicht für einen Angriff genutzt werden können)
  • Fehler, die eine Manipulation der zugrundeliegenden Laufzeitumgebung beinhalten, ohne app-spezifische Fehler auszunutzen (z. B. Malware, die auf dem Betriebssystem läuft, böswilliger Administrator-Benutzer auf demselben System, usw.)
  • Die Knoten mit viel Spam aus der Synchronisation bringen, ohne den Coordinator zum Absturz zu bringen

Belohnungen

Jeder, der ein vom Bewertungskomitee als gültig erachtetes Problem einreicht und Mitglied der IOTA Discord-Community ist, erhält das spezielle Tanglebreaker-Abzeichen, um von unserer Community anerkannt zu werden.

iota rewards

Priorität 1

IOTA gebrandeter Ledger Nano S für die ersten 10 Einreichungen, die sich als P1 qualifizieren
T-Shirt mit individuellem Design*
2.500 € in IOTA-Tokens

Priorität 2

Ledger Nano mit IOTA-Branding für die ersten 7 Einreichungen, die sich als P2 qualifizieren
T-Shirt mit individuellem Design*
1.500 € in IOTA-Token

Priorität 3

Ledger Nano mit IOTA-Branding für die ersten 5 Einreichungen, die sich als P3 qualifizieren
T-Shirt mit individuellem Design*
1.000 € in IOTA-Token

Priorität 4

Ledger Nano mit IOTA-Branding für die ersten 3 Einreichungen, die sich als P4 qualifizieren
T-Shirt mit individuellem Design*
500 € in IOTA-Token

* durch das Designteam der IOTA Foundation

Bedingungen und Konditionen

Die Preise können nicht an Teilnehmer ausgezahlt werden, die ihren Wohnsitz in Ländern haben, die internationalen Sanktionen des UNSC, der OFAC und der EU unterliegen, oder die persönlich auf den von den genannten Gremien veröffentlichten Listen der Specially Designated Nationals und Blocked Persons (SDN) genannt sind
Ausgeschlossen von der Teilnahme sind alle Mitarbeiter und Auftragnehmer von IF sowie alle Personen, die bereits beruflich an Teilen des Chrysalis-Codes gearbeitet haben

Wie Sie teilnehmen können

Sobald Sie ein Problem finden, das unter die oben beschriebenen Kategorien fällt, wechseln Sie zum entsprechenden GitHub-Repository und reichen ein Attack-a-thon-Problem unter Verwendung der vordefinierten Problemvorlage ein:

iota GitHub

Die Frage muss wie folgt strukturiert sein, damit sie vom Bewertungsausschuss berücksichtigt werden kann.

Beschreibung: Welche Komponente wurde verwendet (z.B. iota.rs python binding) und wie

Auswirkung: Beschreiben Sie die Sicherheitslücke und ihre möglichen Auswirkungen.

Proof of Concept: Geben Sie eine detaillierte Beschreibung der Schritte, Tools und Versionen, die zur Reproduktion des Problems erforderlich sind (Proof-of-Concept-Skripte oder Screenshots sind hilfreich).

Mit dem Einreichen des Problems garantiert der Einsender, dass der Bericht und alle Anhänge nicht die geistigen Eigentumsrechte Dritter verletzen, und der Einsender gewährt der IOTA Foundation eine nicht-exklusive, gebührenfreie, weltweite, unbefristete Lizenz zur Nutzung, Vervielfältigung, Erstellung abgeleiteter Werke und Veröffentlichung des Berichts und aller Anhänge.

Das Bewertungskomitee

Die eingereichten Issues werden von Mitgliedern der IOTA Foundation auf ihre Korrektheit überprüft. Sie antworten auf das Issue auf GitHub, um die Gültigkeit des Issues zu bestätigen oder nicht und die Kategorie zu definieren, unter die es fällt.

Ab dem 8. April 2021 werden die siegreichen Teilnehmer vom Community Manager, Antonio Nardella, mit einem Kommentar zu dem eingereichten Issue kontaktiert.

Der folgende Prozess der Verifizierung und des Informationsaustauschs, um die Belohnungen zu erhalten, erfordert die Veröffentlichung eines öffentlichen Gists, wobei die Informationen per E-Mail ausgetauscht werden.

Original by Antonio Nardella: https://blog.iota.org/the-chrysalis-attack-a-thon/

Was ist MANA bei IOTA – Teil 2

Letzte Woche haben wir eine neue Version unseres Pollen-Testnetzes veröffentlicht, die mana enthält. Mit diesem Release haben wir die Reife und die Effizienz unserer mana-Lösung demonstriert. Bald wird Mana in viele Module implementiert sein, ein wichtiger Schritt auf dem Weg zu Nectar, unserem kommenden und ersten voll funktionsfähigen Coordicide-Testnetz.

Angesichts dieses wichtigen Meilensteins dachten wir, wir würden einige häufig gestellte Fragen klären. Seit unserer ersten Veröffentlichung über Mana, die auch eine FAQ enthielt, sind von verschiedenen Seiten Fragen aufgeworfen worden, die wir mit diesem Beitrag beantworten wollen. Wir haben diese Fragen von Leuten aus der Community erhalten, sowohl über unseren Discord als auch über Reddit. Die Fragen sind nach Themen gruppiert, und unter einigen Fragen finden Sie die Langform der ursprünglichen Frage in Kursivschrift.

Das Feedback der Partner und der Community ist sehr wertvoll für uns, da es uns zeigt, welche Aspekte von besonderem Interesse sind und uns hilft, die Bereiche in unserer vollständigen Mana-Spezifikation zu identifizieren, die wir optimieren könnten. Die vollständige Spezifikation wird veröffentlicht werden, bevor wir in die „Nectar“-Phase unseres bestehenden „Coordicide“-Testnetzes eintreten.

Seit unserem letzten Beitrag gab es nur eine vorgeschlagene Änderung, die mit Mana zu tun hat: Benutzern mit Null Mana könnte es möglicherweise erlaubt werden, Nachrichten zu senden, wenn das Netzwerk nicht überlastet ist, wie von Partnern und Mitgliedern der breiteren Gemeinschaft gewünscht. Wir untersuchen die Möglichkeit, Nachrichten für Nodes mit niedrigem oder null Mana in Zeiten geringer Überlastung auszustellen, unter der Bedingung, dass sie eine zusätzliche Aufgabe erfüllt haben, z. B. einen Arbeitsnachweis. Dies ist keineswegs einfach oder gar möglich. Wir werden Ihnen mitteilen, was unsere Forschung herausfindet, sobald wir Ergebnisse haben.

Bitte beachten Sie, dass die Fragen darüber, wie viel Zugriff eine bestimmte Menge an Mana garantiert, eigentlich keine Fragen über Mana an sich sind, sondern eigentlich Fragen über unseren Staukontrollalgorithmus sind. Obwohl also Mana selbst vollständig ist, sind die Fragen bezüglich der Null-Mana-Knoten noch offen. In Kürze werden wir einen weiteren Blog-Beitrag veröffentlichen, der den IOTA-Staukontrollalgorithmus erklärt.

Eine kurze Auffrischung: Mana

Für diejenigen, die unsere erste Veröffentlichung über Mana nicht gelesen haben, hier ein kurzer Überblick darüber, was Mana ist und warum es wichtig ist. Jedes Mal, wenn eine Transaktion Geld bewegt, „verpfändet“ diese Transaktion eine Menge Mana an eine Node-ID. Mana kann also als Beweis für delegierten Token-Besitz betrachtet werden. Die einzige Möglichkeit, Mana zu erhalten, besteht darin, entweder Token zu kontrollieren oder eine Art Beziehung zu jemandem zu haben, der Token kontrolliert. Die Menge an Mana, die während eines Transfers verpfändet wird, wird so berechnet, dass ein Angreifer das Mana, das ein Knoten besitzt, nicht künstlich aufblähen kann.

Warum ist Mana wichtig? Ohne eine Art von Schutzmechanismus könnten Angreifer ein Netzwerk wie IOTA angreifen, indem sie Millionen von gefälschten Identitäten fälschen, was als Sybil-Angriff bezeichnet wird. Daher müssen alle DLTs Sybil-Angriffe verhindern, indem sie die Identität mit einer kryptographisch überprüfbaren, knappen Ressource verbinden. Proof of Work und Proof of Stake verwenden Energie bzw. gestackte Token als Sybil-Schutzmechanismen.

IOTA verwendet Mana, um Sybil-Angriffe zu verhindern. Aus diesem Grund muss Mana von allen Kernkomponenten von Coordicide berücksichtigt werden, wie z.B. dem IOTA Congestion Control Algorithmus, unserem Konsens-Algorithmus (FPC), Autopeering und unserem verteilten Zufallszahlengenerator. Das ist auch der Grund, warum die Implementierung von Mana in das Pollen-Testnetz ein wichtiger Schritt für die Nectar-Phase des Testnetzes war: Es bedeutet, dass wir damit beginnen können, Schlüsselkomponenten des IOTA-Kernprotokolls vor grundlegenden Angriffsvektoren zu schützen.

Der Unterschied zwischen Mana und Staukontrolle

Mana ist unser aktueller anfänglicher Vorschlag, um das Verhalten der Nodes zu messen. In der Zukunft wird sich Mana zu einem komplexeren mehrdimensionalen Reputationssystem entwickeln, um den Beitrag einer Node zur Netzwerkaktivität und dessen Sicherheit zu bewerten. Im aktuellen Stadium wird Mana als Eingabedaten verwendet, um fälschungssichere Identitäten für verschiedene Coordicide-Module bereitzustellen, einschließlich des IOTA Staukontrollalgorithmus.

Mana Eigenschaften

Wie lang ist ungefähr die Zerfallsfunktion?

Liegt die Halbwertszeit von Manas eher bei einer Minute oder eher bei einem Jahr?

Erinnern Sie sich daran, dass bei der Mana zwei Berechnungsmethode das Mana nach einer Exponentialfunktion zerfällt und daher mit einem neuen Pfand aufgefrischt werden muss. Die Halbwertszeit des Zerfalls liegt bei einigen Stunden, z.B. 6 Stunden. Wir wollen jedoch sehen, wie sich dies im Testnetz tatsächlich bewährt und werden diesen Parameter entsprechend anpassen.

Wie wird „aktives Mana“ gemessen?

„Aktives Mana“ kann auf unendlich viele Arten berechnet werden, je nach Zweck. Aktiv zu sein könnte bedeuten „der Prozentsatz der Node, die in den letzten X Sekunden mindestens eine Transaktion gesendet haben“ oder es könnte bedeuten „der Prozentsatz der Node, die im Hinblick auf ihre Reputation ‚genug‘ Transaktionen gesendet haben.

Für die Staukontrolle muss die Node das aktive Mana nicht kennen: Die Node schaut einfach auf seinen Posteingang und reagiert entsprechend dem Mana der ausstellenden Node. Die Information über die Menge an Mana, die jede Node besitzt, ist für jede Node verfügbar, basierend auf der ID der ausstellenden Node, die Teil jeder Nachricht ist, die sich durch das Netzwerk verbreitet.

Für FPC und Autopeering verwaltet das Peer Discovery-Modul eine Liste bekannter Nodes, die derzeit online sind. Die Node verwendet diese Liste für FPC-Abfragen und für die Auswahl von Nachbarn.

Bösartiges Verhalten

Wird Mana durch die fehlende Dezentralisierung auf die gleichen Probleme stoßen, wie PoS-Token?

Etwa 0,06% der Adressen halten ~65% aller Token. Das bedeutet, dass selbst wenn 99,94% der Adressen zu aktivem, ehrlichem Mana beitragen, sind das nur ~35% des gesamten Manas. Wie können 0,06% der Adressen, die 65% der Token kontrollieren, kein Problem für den Konsens, die Abstimmung oder den Datendurchsatz darstellen?

Erstens entspricht die Anzahl der Adressen nicht der Anzahl der Leute, die IOTA nutzen. Zum Beispiel halten 35% aller Adressen, d.h. 14000 Adressen, weniger als 10 MI. Es wäre absurd, anzunehmen, dass diese Beträge von 14000 Personen kontrolliert werden. Wallets und verschiedene Anwendungen verteilen das Geld aus verschiedenen Gründen oft auf mehrere Adressen. Auf der anderen Seite werden Token im Cold Storage oft auf eine einzige Adresse gebündelt. Daher ist die obige Statistik nicht überraschend.

Zweitens ist diese Statistik kein Problem, da die zugrunde liegende Sicherheitshypothese immer noch erfüllt ist. Unseren Simulationen zufolge müsste ein Angreifer mindestens 30 % (manchmal mehr) des aktiven Konsens-Manas kontrollieren, um eine vernünftige Chance zu haben, FPC anzugreifen und eine Doppelausgabe zu verursachen. Ein signifikanter Anteil der Top-Token-Inhaber müsste sich also absprechen, um einen Double Spend zu verursachen. Da die obersten 0,06 % der Adressen immer noch mehrere hundert Adressen sind, erscheint dies unwahrscheinlich. Darüber hinaus würden andere Angriffe wie Zensur-Angriffe oder Liveness-Angriffe deutlich mehr Mana erfordern.

Drittens muss in jeder DLT der Zugang zum Netzwerk mit einer kryptographisch verifizierbaren, knappen Ressource verbunden sein. Typischerweise folgt der gesamte Ressourcenbesitz einer Zipf-Verteilung: Einige wenige haben viel, andere immer weniger. Daher ist dieses Zentralisierungsproblem nicht einzigartig für IOTA, sondern endemisch für alle DLTs.

Schließlich sind Proof-of-Work/Proof-of-Stake-Lösungen starre Systeme. Im Vergleich dazu ist unser Ansatz viel flexibler. Die Idee ist, ein mehrdimensionales Reputationssystem aufzubauen, bei dem Mana nur eine der Komponenten ist. Durch die Verwendung zusätzlicher Metriken – wie Belohnungen für gutes Verhalten, Begriffe wie Alter und Teilnahme am Netzwerk sowie Reputationsverluste für egoistische oder sich falsch verhaltende Knoten – wollen wir die Diskrepanzen in der Reputation über alle Knoten hinweg reduzieren.

Wird eine zentralisierte Verteilung Probleme verursachen?

IOTA 2.0 („Coordicide“) ist so konzipiert, dass es keine großen Machtkonzentrationen gibt. Im Gegensatz zu den meisten PoS-Systemen ist IOTA keine Blockchain und wird daher nicht durch einen Leader-Wahlprozess begrenzt. In einer Blockchain sind Blöcke sequentiell und so wird nur eine relativ kleine Anzahl von Blöcken jede Stunde produziert, und so kann es nur so viele Blockproduzenten geben.

In einer DAG können jedoch mehrere Personen gleichzeitig Informationen hinzufügen, und so können Nodes mit kleinen Mengen an Mana gleichzeitig mit großen Mana-Inhabern Nachrichten erstellen. Selbst wenn Sie einen ziemlich kleinen Anteil an Mana haben, garantiert Ihnen dieses Mana zumindest eine minimale Menge an Zugang, und dieser Zugang kann nicht entzogen werden, unabhängig davon, wie viele große Mana-Inhaber das Netzwerk sättigen. So kann der IOTA Congestion Control Algorithm (ICCA) tausende von kleinen Mana-Inhabern unterstützen. Durch die proportionale Zuteilung von Mana stellen wir sicher, dass die „kleinen Jungs“ ihren fairen Anteil an Stimmrecht oder Zugang bekommen.

Das Verständnis der absoluten Mindestmenge an Mana, die benötigt wird, um eine Nachricht auszugeben, ist Teil der Forschung mit Null-Mana-Knoten.

Kann man mit genügend Mana eine doppelte Ausgabe tätigen?

Ist es möglich, Doppelausgaben zu genehmigen, indem man zwei widersprüchliche Transaktionen genehmigt und sie in den Tangle einbettet, wenn es genug böswillige Nodebesitzer gibt, die sie „genehmigen“? Wie hoch ist der Prozentsatz an (aktivem/passivem) Mana, der erforderlich wäre, um dies erfolgreich zu tun? Wie würden ehrliche Nodes auf weitergeleitete, aber widersprüchliche Transaktionen reagieren, die eine Mehrheit von böswilligen Knotenbesitzern/Mana-Inhabern für legitim befunden hat?

Mit etwa 30 % des Konsens-Manas kann ein Angreifer potenziell den Abstimmungsalgorithmus manipulieren, um ein Paar von Doppelausgaben gültig zu machen. Bei diesem Angriff würde eine Gabelung entstehen, bis sie aufgelöst ist, wären keine Nachrichten endgültig.

Wie auch immer:

  1. Kein Angreifer wird 30% des Konsens-Manas aus IOTA-Beständen haben.
  2. Es wird keinen legitimen Markt für Konsens-Mana geben, da es keinen Sinn macht, diesen zu etablieren. Der Handel mit Access Mana hat einen legitimen Anwendungsfall, so dass ein gesunder Markt dafür wahrscheinlich wachsen wird. Konsens-Mana ist rein für die Verwaltung. Nur Angreifer würden es kaufen. Es würde eine lange Zeit und eine Menge Ressourcen benötigen, um eine Marktposition aufzubauen, um auch nur in die Nähe einer Situation zu kommen, in der man eine Mehrheit der Stimmen erreichen kann. Es ergibt keinen Sinn, dass ein solcher Markt reift.

Wie verhindern Sie Prioritätsumkehrungen?

Das könnte passieren, wenn eine Transaktion mit hohem Mana-Wert von einer Transaktion mit niedrigem Mana-Wert abhängt.

Wenn Transaktion A von Transaktion B abhängt, muss B im Vergangenheits-Kegel von A sein. Wenn eine High-Mana-Node eine Nachricht mit Transaktion A ausgibt, und eine Low-Mana-Node gibt Transaktion B aus, wird A nicht getratscht, wenn B nicht getratscht hat.

Darüber hinaus – im Tratschprotokoll – tratschen Nodes nur „bei Verfestigung“, was bedeutet, dass eine Node eine Nachricht nur dann getratscht wird, wenn seine Eltern ebenfalls getratscht hatten. Tatsächlich wird der Staukontrollalgorithmus eine Nachricht erst dann in Betracht ziehen, wenn er den gesamten vergangenen Kegel erhalten hat.

Wie verhindert man „Mana Dusting“?

„Mana Dusting“, also das Zuweisen von Mana an nicht vorhandene Nodes und damit das Füllen der Nodetabellen aller Nodes?

Wir haben noch keine offizielle Lösung für dieses potenzielle Problem spezifiziert.

Jedes Modul erfordert nur einen „ungefähren Konsens“ über Mana, was bedeutet, dass das Protokoll kleine Unterschiede in der Mana-Wahrnehmung toleriert. Somit kann Manastaub ohne Auswirkungen gelöscht werden. Um jedoch kleine Mana-Halter zu ermöglichen, kann es sinnvoll sein, Mana-Staub für einen kurzen Zeitraum, etwa einen Tag oder so, leben zu lassen, danach kann er gelöscht werden.

„Freie“ Transaktionen

Kann eine Null-Mana-Node Transaktionen ausgeben, wenn es keinen Stau gibt?

Im aktuellen Entwurf für den Überlastungssteuerungsalgorithmus benötigen Sie Mana, um eine Nachricht zu senden. Dies soll verhindern, dass plötzliche aggressive Spam-Attacken das Netzwerk stören. Wie in der Einleitung erwähnt, prüfen wir die Möglichkeit, dass eine Node einen Arbeitsnachweis erbringen kann, um Nachrichten ohne Mana ausgeben zu können. Allerdings kann die Möglichkeit, die ungenutzte Bandbreite zu geringen Kosten auszunutzen, auch böswillige Knoten begünstigen, die versuchen, das Netzwerk zu verstopfen oder, noch schlimmer, Ledger-Inkonsistenzen zu erzeugen. Da IOTA 100% erlaubnisfrei ist, ist die Lösung dieses Problems nicht trivial.

Eine Alternative ist, Mana-Faucets zu haben, was etwas ist, das die IOTA Foundation oder andere große Halter im Netzwerk unterhalten könnten. Die Idee ist, dass Knoten automatisch eine Liste von Faucets halten könnten. Vom Node-Dashboard aus kann der Node-Operator eine minimale Menge an Mana vom Faucet anfordern.

Braucht man eigentlich Mana für nicht-wertige Nachrichten?

Der IOTA Congestion Control Algorithmus behandelt alle Nachrichtentypen im Tangle gleich. Nicht-wertige Transaktionen (Datennachrichten) werden auf die gleiche Art und Weise verarbeitet wie Werttransaktionen (Wertnachrichten). In Zeiten der Überlastung benötigt eine Node ausreichend Mana, um eine von beiden auszustellen.

Benötigen Sie überhaupt Mana, wenn Sie gerade einen Knoten eingerichtet haben und eine Werttransaktion durchführen möchten?

Sie benötigen kein Mana, wenn Sie einfach nur eine Node „aufstellen“ und den Tangle überwachen. 0-Mana-Nodes können die gleichen Peering-Mechanismen in Chrysalis verwenden, um einfach in das Netzwerk „hineinzuhören“, obwohl sie nicht den Eclipse-Schutz haben, den Mana ihnen bieten würde.

In unserer anfänglichen Version des IOTA Congestion Control Algorithmus benötigen Sie jedoch Mana, um Transaktionen zu senden – oder irgendeine Art von Nachricht auszugeben. Wie bereits erwähnt, untersuchen wir, wie wir es einer Node ohne Mana erlauben können, Nachrichten zu senden, wenn es keinen Stau gibt. Wir haben eine vielversprechende Lösung, aber wir müssen sicherstellen, dass sie keine Angriffsvektoren öffnet. Wir werden unsere Ergebnisse zu einem späteren Zeitpunkt bekannt geben, wenn diese Forschung weiter entwickelt ist.

Mana-Markt

Was wird der Marktwert von Mana sein?

Wir wissen es nicht. Mana ist eine technische Lösung für verschiedene Probleme in einem dezentralen IOTA-Netzwerk. Der Mana-Markt ist ein Nebenprodukt unserer Absicht, ein erlaubnisfreies Protokoll zu schaffen, das so frei von Einschränkungen wie möglich ist. Wir haben die Angriffsvektoren, die diese Lösung mit sich bringt, überprüft, werden aber die Bewertung ihres monetären Wertes dem Markt überlassen.

Es gibt jedoch ein paar vernünftige Annahmen, die darauf hindeuten, dass Mana eine Art von Marktwert haben wird. Erstens: Wenn das Netzwerk überlastet wird, wird der Zugang zum Netzwerk – und damit Mana – wertvoll. Dies ist eine einfache Angebots- und Nachfrageökonomie, die für alle DLTs gilt. Allerdings wird sich diese Berechnung mit Sharding ändern, da Sharding das Angebot an Zugang stark erhöhen wird.

Zweitens, derzeit könnten einige Unternehmen zögern, jede Krypto aufgrund von Vorschriften, Steuern oder allgemeine Skepsis zu halten. Daher ist das Mieten von Mana durch vertrauenswürdige IOTA-Infrastrukturpartner ein Weg, dass Unternehmen garantierten Zugang haben können, ohne Token zu halten.

Warum kann Mana an einen anderen Node verpfändet werden?

Was war der Grund für die Entscheidung, Mana nicht an Nodes zu verpfänden, die Transaktionen verarbeiten? Warum sollte jemand in der Lage sein, Mana an eine andere Entität zu verpfänden?

Wir wollen IOTA so flexibel und frei – im Sinne von Freiheit, nicht „umsonst“ – wie möglich halten. Es gibt mit ziemlicher Sicherheit komplizierte Anwendungsfälle in der Zukunft, die wir nicht aus willkürlichen Gründen einschränken wollen.

Jeder sollte in der Lage sein, Mana auf die Art und Weise zu nutzen, die er für richtig hält. Das gilt sowohl für Benutzer als auch für Nodes. Wenn Sie der Node, der Ihre Transaktion verarbeitet, kein Mana zuweisen, muss er Ihre Transaktion nicht verarbeiten. Sie können darauf bestehen, dass alle Werttransaktionen, die sie verarbeiten, Mana an ihre Node-ID verpfänden.

Es kann jedoch sein, dass Ihr Knoten sein Zugriffsmana nur periodisch benötigt, z. B. zu Spitzenverkehrszeiten, nur an Wochentagen oder Wochenenden oder in anderen Abständen. Wenn der Eigentümer der Nodes eine Menge IOTA besitzt und keine Verwendung für (einen Teil) des von ihm generierten Manas hat, erhält er durch die Möglichkeit, es an andere Nodes zu verpfänden, einen erhöhten Nutzen aus seinem IOTA.

Zum Beispiel könnten einige Unternehmen nicht wollen, Token in der nahen Zukunft zu halten. Krypto in den Büchern zu haben, kann in einigen Ländern rechtliche Probleme verursachen, aber sie möchten vielleicht trotzdem Zugang zum Tangle haben. Durch die Trennung des Pfands von der Node, der die Transaktion verarbeitet, ermöglicht es einen Markt für sie, den Zugang im Austausch für Fiat zu kaufen und rechtliche Probleme zu umgehen.

Unternehmen könnten z.B. öffentliche Nodes für Benutzer anbieten, um von dem dadurch generierten Mana zu profitieren.

Was passiert mit ungenutztem Zugangsmana?

Ungenutzte Bandbreite wird proportional zu der Menge an Access Mana aufgeteilt, die aktive Benutzer haben.

Das heißt, wenn Sie z.B. 1 % Zugangsmana haben und die Bandbreite zu 60 % gesättigt ist, können Sie mindestens 1 % der ungenutzten 40 % zugewiesen bekommen. Von der ungenutzten Bandbreite danach bekommen Sie wieder 1%, auf ewig, bis die Bandbreite gesättigt ist.

Dies könnte das Netzwerk bis zu seinem hart kodierten Limit verstopfen, aber es behindert niemals den Zugang eines Mana-Inhabers zum Netzwerk aufgrund seines Manas.

Kann jeder einfach Katzenbilder spammen und das Netzwerk verstopfen?

Das Protokoll kann nicht bestimmen, was Spam ist und was nicht. Dies ist ein Merkmal der erlaubnisfreien Innovation. Während Katzenbilder für einige trivial erscheinen mögen, können sie für andere sehr wichtig sein. Es ist nicht unsere Aufgabe, dies zu bestimmen.

Jeder sollte in der Lage sein, das Netzwerk so zu nutzen, wie er es für richtig hält, auch wenn andere damit nicht einverstanden sind. Dies ist eine Kernaussage von DLT, und Mana ermöglicht dies auf faire Weise. Die Zusammensetzung des überlasteten Netzwerks wird durch die Menge an Mana, die ein Spammer besitzt, begrenzt. Das Netzwerk könnte nur aus 100% Katzenbildern bestehen, wenn der Spammer 100% des aktiven Manas besitzt. Somit ist auch bei diesem Katzen-Spamming ein fairer Durchsatz gewährleistet.

Staukontrolle

Bleiben Sie dran für unseren nächsten Blog-Beitrag über den Mechanismus der Überlastungssteuerung.

Wie messen Sie, wann das Netzwerk überlastet ist?

Ein Raspberry Pi kann nur einen Bruchteil einer AWS-Node verarbeiten, so dass die beiden sehr unterschiedliche Ansichten darüber haben, wann die „mana-basierte Ratenkontrolle“ einsetzen muss – und wenn diese voneinander abweichen, haben Sie wieder Prioritätsumkehreffekte.

Zunächst einmal muss der Algorithmus zur Staukontrolle nicht feststellen, ob das Netzwerk überlastet ist oder nicht. Wenn es keinen Stau gibt, dann ist der Posteingang des Knotens meistens leer. Jede Node im Netzwerk verarbeitet Nachrichten mit einer maximalen festen Rate, die vom Protokoll festgelegt wird. Diese Rate bestimmt die Mindestanforderungen an die Hardware der Node, einschließlich Bandbreite und Rechenleistung. Jeder Rechner ohne diese Fähigkeiten wird nicht in der Lage sein, eine Node zu betreiben. Wir legen diesen Ratenparameter so fest, dass die Art von Maschinen möglich ist, die wir für den Betrieb einer Node für notwendig erachten.

Damit ein kleines Gerät das Netzwerk nutzen kann, muss es nicht unbedingt eine Node oder gar eine Wallet betreiben. Typischerweise werden die heutigen IoT-Geräte über ein leistungsfähigeres Gateway gesteuert, das über eine zuverlässige Internetverbindung verfügt. Das Gateway kann eine Wallet oder eine Node betreiben. Um diese Geräte mit geringem Stromverbrauch zu ermöglichen, müssen wir also nur sicherstellen, dass alle Anwendungen, die von Geräten mit geringem Stromverbrauch verwendet werden, über ein Gateway funktionieren können.

In Zukunft wird das Sharding ein vielfältigeres Netzwerk ermöglichen, da nicht alle Geräte alle Nachrichten verarbeiten müssen. Dann können Geräte mit geringerer Leistung kleinere Teile des Netzwerks als Node ausführen.

Kann man das System manipulieren, um das Netzwerk zu überlasten?

Welcher Prozentsatz an Mana, der von ehrlichen Nodebesitzern gehalten wird, ist erforderlich, um eine künstliche Sättigung des Netzwerks zu verhindern, um das Entstehen eines Marktes mit gebührenpflichtigen Transaktionen zu verhindern, wenn man davon ausgeht, dass böswillige Nodebesitzer das Netzwerk künstlich sättigen könnten („Spam“), um ihre Netzwerkkapazität (oder Mana) an den Meistbietenden verkaufen zu können.

Zunächst einmal hängt ein potenzieller Mana-Markt nicht allein von der Überlastung ab. Unternehmen, die keine Kryptowährung in ihren Büchern haben wollen, werden bereits ohne Stau auf dem Markt für Mana sein.

Als nächstes ist es wichtig zu erkennen, dass Ihr Mana den Zugang zum Netzwerk garantiert, proportional zu der Menge an Mana, die Sie haben. Keine noch so große Zentralisierung durch andere Besitzer kann Ihren Zugang verhindern; sie können das Netzwerk nicht auf unfaire Weise verstopfen. Sie haben immer den Teil der Bandbreite zur Verfügung, der Ihnen zusteht.

Verhalten der Node

Kann eine Node feststellen, ob der Aussteller einer Transaktion ihm Mana gutschreiben hat, bevor er eine Transaktion annimmt und weiterleitet?

Ja.

Ist diese Eigenschaft signiert?

Ja, die Eigenschaft ist signiert.

Können Nodes Transaktionen, die ihnen kein Mana zusagen, einfach ablehnen?

Wie kostspielig ist es für die Node (wrt DoS), es synchron aufzulösen, so dass er möglicherweise die Transaktion ablehnen kann und der Benutzer davon erfährt?

Es ist trivial, solche Transaktionen zu verifizieren und abzulehnen.

Die Standardeinstellung ist, dass in der Kommunikation zwischen Wallet und Node, die Wallet der Node nach einer Node-ID fragt, an die das Mana verpfändet werden soll. Die Node teilt der Wallet dann die ID mit, an die das Mana verpfändet werden soll. Die Brieftasche kann beantragen, das Mana an einen anderen Ort zu verpfänden, und es liegt an der Node, dieser Bitte nachzukommen oder nicht.

Dieses Verhalten ist im Kernprotokoll nicht vorgesehen. Es ist nicht essentiell für die Sicherheit, und wir wollen zukünftige Anwendungsfälle nicht durch eine solche Regel behindern. Jeder kann die Nodesoftware so konstruieren, dass sie sich in Bezug auf die Verpfändung von Mana anders verhält, so wie er es für seinen Anwendungsfall für richtig hält.

Was passiert, wenn eine Node ihr Mana aufgrund von böswilligem Verhalten verliert?

Was spricht dagegen, es woanders zu verpfänden und den Angriff erneut zu versuchen? Ist es nicht billig, neu zu verpfänden?

In IOTA 2.0 wird Mana nicht durch das Protokoll von einem sich falsch verhaltenden Node entzogen. Wie durch die Frage angedeutet, gibt es einige offensichtliche Fragen, die geklärt werden müssten, bevor dies dem Protokoll hinzugefügt wird. Einzelne Benutzer können jedoch ihr Mana-Versprechen im Falle von Fehlverhalten widerrufen. Es liegt jedoch in ihrer Verantwortung, ihr Konsens-Mana an ehrliche Quellen zu verpfänden.

Wir haben einen Zuschuss an die Gruppe von Mauro Conti gegeben, um ein allgemeineres Reputationssystem zu untersuchen, das das Verhalten der Node berücksichtigt. Dies ist eine laufende Forschung und wir werden alle über ihre Ergebnisse auf dem Laufenden halten.

Original by William Sanders: https://blog.iota.org/explaining-mana-in-iota-part-2/

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.