Pollen Testnet v.0.5.0 – Die Reise mit Mana

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

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

Die vollständige Liste der Änderungen beinhaltet:

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

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

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

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

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

Pollen Testnet 0.5

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

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

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

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

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

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

Einführung von Pollen: Das erste dezentralisierte Testnetz für IOTA 2.0

Original by IOTA Foundation: https://blog.iota.org/introducing-pollen-the-first-decentralized-testnet-for-iota-2-0-349f63f509a1 (20.06.2020)

Nach Jahren intensiver Forschung, rigoroser Tests und unermüdlicher Bemühungen unserer Ingenieure sind wir stolz darauf, endlich alle zur Teilnahme an diesem bedeutenden Meilenstein für das IOTA-Projekt einladen zu können. Pollen markiert den Beginn des weltweit ersten wirklich dezentralisierten, skalierbaren und gebührenfreien Distributed Ledger, das von Anfang an das Versprechen der IOTA war. Pollen ist die erste Phase der dreiteiligen Freigabestrategie von IOTA, die in unserem koordinatorenlosen, produktionsbereiten Netzwerk gipfeln wird: IOTA 2.0. Pollen ist ein sich rasch entwickelndes Forschungs-Testbed, in dem die Gemeinschaft, Forscher und Ingenieure die Konzepte von IOTA 2.0 testen und validieren können.

Sie können die neue Version herunterladen und das vollständige Changelog hier einsehen.

Pollen stellt ein wichtiges Upgrade im Vergleich zur vorherigen Version Alphanet v0.1.3 dar. Wir zählen ungefähr 60000 Hinzufügungen und 25000 Löschungen in der Codebasis. Wir haben die Grundlage für ein funktionales Netzwerk ohne Koordinator geschaffen. Von hier aus werden iterative Verbesserungen des Codes Pollen in den endgültigen, funktionsreichen Release-Kandidaten für IOTA 2.0 verwandeln.IOTA Update 2.0

Die heutige Veröffentlichung enthält die folgenden Aktualisierungen der Hauptfunktionen:

  • Fast Probabilistic Consensus – der neue Konsens-Algorithmus für IOTA für ein dezentralisiertes Netzwerk. Sie können das Forschungspapier hier lesen
  • Werttransaktionen – Netzwerkteilnehmer können jetzt einen automatisierten Hahn benutzen, um Tokens zu empfangen, Werttransaktionen zu senden (über eine Brieftasche) und die Konfliktlösung im Netzwerk zu testen
  • Tokenisierte Vermögenswerte – Einzelpersonen können jetzt IOTA-Token mit verschiedenen Attributen „einfärben“, die reale Vermögenswerte wie Gebäude, IoT-Geräte oder sogar Firmenkapital repräsentieren
  • Prometheus- und Grafana-Integration – Knotenbetreiber können jetzt mehrere Metriken überwachen, indem sie ein Grafana-Dashboard aktivieren
  • Feeless dApps – diese Version beinhaltet eine zukünftige Fähigkeit für das IOTA-Ökosystem: die Entwicklung von gefühllosen dezentralisierten Anwendungen

Wir haben auch bereits früher veröffentlichte Funktionen der letzten Version von Alphanet verbessert. Dazu gehören eine verbesserte Stabilität und Instrumentierung sowohl des Autopeering- als auch des Klatschmoduls. Wir haben ein erweitertes Dashboard mit einem brandneuen Tangle-Explorer und Visualizer gebaut. Der Analyseserver wurde von Grund auf neu gestaltet, um nicht nur die Visualisierung und Analyse des Autopeering-Netzwerks zu unterstützen, sondern auch die Echtzeit-Aktualisierung des Fast Probabilistic Consensus-Protokolls in Aktion.

Dashboard GoShimmer

Unser Interesse an diesem Testnetz wird sich auf das Gesamtverhalten des Netzwerks konzentrieren und nicht auf seine rohe Leistung und Benutzererfahrung. Wir werden in künftigen Iterationen schrittweise an Optimierungen und Verbesserungen arbeiten. Was die Implementierung betrifft, so stecken die neu eingeführten Komponenten noch in den Kinderschuhen (z.B. Brieftaschenbibliothek, FPC) und einige Komponenten sind noch nicht optimiert (z.B. Klatsch und Tratsch). Bitte beachten Sie, dass wir das Netzwerk von Zeit zu Zeit zurücksetzen werden, bis lokale Snapshots implementiert sind, um zu verhindern, dass die Datenbank zu stark wächst und um potentiell brechende Änderungen einzuführen.

Mit dieser neuen Version haben wir eine neue Architektur eingeführt, die aus drei separaten Schichten besteht: Der Netzwerk-, Kommunikations- und Anwendungsschicht. Diese neue Architektur wird Unterstützung für zukünftige Funktionen wie Tokenisierung, skalierbare intelligente Verträge, Feeless dApps und Sharding bieten.

IOTA Update 2.0

Es gibt Parallelen zwischen unseren Schichten und den oberen Schichten des OSI-Modells, obwohl wir den Leser vor tiefgreifenden Vergleichen warnen. Die Netzwerkschicht verwaltet die Verbindungen und die Paketübertragung zwischen den Knoten. Die Kommunikationsschicht schafft eine standardisierte Plattform für die Speicherung und Kommunikation von Informationen. Den Entwicklern steht es dann frei, dezentralisierte Anwendungen auf der Anwendungsschicht zu entwerfen und gleichzeitig die unteren Schichten zu abstrahieren. Um mehr darüber zu erfahren, können Sie unseren Blogpost „A Guide to Upcoming IOTA 2.0 Terminology“ lesen.

IOTA Pollen Update

Der Kern von Pollen besteht aus diesen Merkmalen:

  • Neues Nachrichten-Layout – Jede Nachricht enthält die Hashes der Eltern, Ausgabeinformationen (Ausgabeknoten-ID, Zeitstempel usw.), eine Nutzlast, den PoW, eine Nonce und die Signatur des Ausgabeknotens
  • Binär – Da jetzt alles binär ist, haben wir eine neue konfigurierbare Proof of Work (PoW)-Bibliothek entwickelt, die in zukünftigen und iterativen Versionen auf unseren adaptiven PoW-Mechanismus umgestellt wird. Wir haben die Unterstützung für traditionelle Public-Key-Kryptographie auf der Basis elliptischer Kurven (z.B. Ed25519 und BLS) sowie binäre Hash-Funktionen wie SHA-256, SHA-512 und Blake2b integriert
  • Ledger-Zustand & UTXO – Diese GoShimmer-Version wird mit einem völlig neuen Ledger-Zustand ausgeliefert, der auf einer erweiterten Version von UTXO basiert – dem auf Parallel-Realität basierenden Ledger-Zustand. Durch die Entkopplung von Konsens und Saldenverfolgung ermöglichen wir ein unübertroffenes Maß an Flexibilität und reduzieren die Komplexität der Nachrichten massiv, indem nur über Konflikte abgestimmt wird
  • FPC – Das Fast Probabilistic Consensus-Protokoll treibt den Konsens unseres Testnetzes voran. Für diese erste „Vanille“-Version des Protokolls lassen wir Knoten FPC auslösen, falls bei der Erstarrung Konflikte festgestellt werden. Die ersten Meinungen basieren auf den Ankunftszeiten der Nachrichten. Neue Knoten, die online gehen, erhalten die Nachrichten jedoch nicht in der richtigen Reihenfolge und können daher zu einer falschen Meinung kommen. In zukünftigen Versionen werden wir einen Synchronisationsmechanismus hinzufügen, der diese Diskrepanzen verhindern wird
  • Zufälligkeit – Die von FPC verwendete Zufälligkeit wird lokal von jedem Knoten auf der Grundlage des Unix-Zeitstempels generiert. Genauer gesagt wird jede Minute in Epochen von 5 Sekunden eingeteilt. Es liegt auf der Hand, dass die durch diese Methode erzeugte Zufallszahlenfolge vorhersehbar und somit unsicher ist. Aufgrund ihrer Einfachheit und Unabhängigkeit vom Netzwerk oder einer anderen Komponente eignet sie sich jedoch sehr gut für einen ersten Test des FPC-Verhaltens. Die nächste Iteration wird sich auf ein gemeindebasiertes Komitee dRNG stützen
  • Lokales Dashboard – Wir haben das Dashboard um einen brandneuen Tangle-Explorer, Tangle Visualizer und Faucet bereichert
  • Grafana-Dashboard über Prometheus – Jeder Knotenbetreiber kann das Prometheus-Plugin aktivieren und Grafana zur Anzeige von Metriken zum Netzwerkverkehr, Autopeering-Status, FPC-Statistiken und mehr verwenden
  • Netzwerk-Verzögerungsanwendung – Wir werden periodisch eine spezifische Netzwerk-Verzögerungsmeldung an das gesamte Netzwerk senden. Dadurch werden die Knoten, die sie empfangen, veranlasst, den Zeitstempel des Empfangs an einen zentralen Logger zu senden, so dass wir periodisch die durchschnittliche netzwerkweite Verzögerung beurteilen und diese Information zur Optimierung der Abstimmung der FPC-Parameter verwenden können.
  • Brieftaschenbibliothek – Wir stellen eine sehr einfache Brieftaschenbibliothek zur Verfügung, damit Entwickler und Tester Token verschieben können. Sie können gerne mit einer Wallet-UI beitragen, die auf dieser Bibliothek basiert
  • (Faucet)Zapfhahn-App – Das GoShimmer-Dashboard wird mit einer Zapfhahn-Sektion geliefert, so dass Sie Token an eine bestimmte Adresse anfordern können
  • Client-Bibliothek & API – Tester, Entwickler und Knotenbetreiber können über die Client-Bibliothek und/oder API mit einem GoShimmer-Knoten interagieren. Um mehr darüber zu erfahren, können Sie sich auf unserer Wiki-Seite informieren.
  • Analyse-Server – Wir haben auch den Analyse-Server verbessert. Dieser zeigt den Gesamtnetzwerkstatus an und hat einen brandneuen Abschnitt, der den Gesamtnetzwerkkonsens anzeigt – ein Echtzeit-Update des FPC-Ergebnisses zu jedem Konflikt. Diese Ergebnisse werden in einer Datenbank gespeichert, so dass wir zusammen mit unserer Gemeinschaft genügend experimentelle Daten sammeln können, um sie mit unseren früheren, durch Simulationen erzielten Ergebnissen zu vergleichen.

Wir haben ein Wiki geschrieben, um der Gemeinschaft die Möglichkeit zu geben, diese Version des Pollen-Testnetzes auszuprobieren und mehr über sie zu erfahren:

Mit unserem nächsten großen Release, genannt Nectar, werden die übrigen Komponenten (wie Mana, Ratenkontrolle, adaptives PoW, um nur einige zu nennen) für ein voll funktionsfähiges, mit Anreizen versehenes Testnetz auf unser Testnetz freigegeben.

Pollen ist ein wichtiger Meilenstein für IOTA 2.0. Es ist ein wesentlicher Schritt zur Erprobung der Kernideen des vollständig dezentralisierten IOTA-Netzes.

Wir freuen uns darauf, Sie auf dieser aufregenden Reise mit Pollen mit uns zu begleiten, und wir hoffen, dass Sie die Entwicklung dieses Projekts ebenso genießen werden wie wir. Wie immer begrüßen wir Ihre Kommentare und Fragen entweder hier auf Medium oder im Kanal #tanglemath auf unserer Discord. Sie können auch an der #goshimmer-Diskussion auf Discord teilnehmen.

Stand der IOTA-Forschung Juni 2020

Original by Serguei Popov: https://blog.iota.org/iota-research-status-update-june-2020-f0fbf9df0a4b

Wir haben diesen Monat einige spannende Status-Updates, die wir allen mitteilen möchten: Zunächst ist die neue GoShimmer-Version v0.2.0 für Ende Juni geplant. Wir betrachten diese Veröffentlichung als einen bedeutenden Meilenstein, da sie zum ersten Mal Werttransaktionen und Konfliktlösung über die FPC unterstützen wird. Es wird auch Aktualisierungen wie ein anderes Transaktionslayout, UTXO, Unterstützung für „Parallel-Reality“-Ledger-Zustände, Binär (Kodierung, kryptographische Signaturen und Hash-Funktionen), neue APIs und mehr enthalten. GoShimmer ist im Kern modular aufgebaut, was den Prozess der Anreicherung mit diesen zusätzlichen Funktionen und Modulen stark vereinfacht hat.

Als nächstes freuen wir uns, Ihnen mitteilen zu können, dass wir ein Papier über die Integration von FPC und Mana veröffentlicht haben, das auf der FTC2020 vorgestellt werden soll. Wir haben auch zwei Networking-Papiere eingereicht, und unser dRNG-Papier wird gerade für die Einreichung poliert.

Schließlich freuen wir uns, berichten zu können, dass die positive Rückkopplungsschleife zwischen Forschung und Technik verstärkt wurde, wobei die Beiträge der einzelnen Teams zu einem iterativen Verfeinerungsprozess der Spezifikationen beigetragen haben. Die meisten Spezifikationen wurden als Ergebnis dieser Interaktion verbessert, und wir freuen uns über den Fortschritt der Spezifikationen in allen Bereichen auf einem sehr guten Niveau. Spezifische Aktualisierungen von jeder unserer Gruppen folgen unten.

GoShimmer-Implementierung

Das Team hat die Implementierung und das Testen des auf der Parallel-Realität basierenden Ledger-Status abgeschlossen, der in der nächsten GoShimmer-Version in seiner zweigweigbasierten Form enthalten sein wird. Wir glauben, dass dieses neue Konzept für die Verwaltung des Hauptbuchstatus sehr gut zu unserem dezentralisierten Netzwerk passt und eines der Hauptthemen sein wird, die nach der neuen Version bewertet werden müssen. Der Analyseserver wurde um einen brandneuen Abschnitt erweitert, der den Gesamtnetzwerkkonsens zeigt, insbesondere ein Echtzeit-Update der FPC-Ergebnisse zu jedem Konflikt. Diese Ergebnisse werden auch in einer Datenbank gespeichert, so dass wir zusammen mit unserer Gemeinschaft genügend experimentelle Daten sammeln werden, um sie mit unseren früheren, durch Simulationen erzielten Ergebnissen zu vergleichen. Darüber hinaus wurde der Autopeering-Abschnitt sowohl auf der Frontend- als auch auf der Backend-Seite verbessert.

In diesem Monat haben wir auch an den neuen APIs für die Ausgabe von Werttransaktionen und das Abrufen des Saldos einer bestimmten Adresse gearbeitet. Diese APIs werden den Kern einer sehr einfachen Brieftasche bilden, an der wir derzeit arbeiten.

Da jetzt alles auf Binärdaten basiert, haben wir eine neue, konfigurierbare Proof of Work (PoW)-Bibliothek entwickelt, die in zukünftigen und iterativen Versionen zu unserem adaptiven PoW übergehen wird.

Schließlich haben wir einen großen Teil unserer Zeit auf die Entwicklung und Verbesserung von Unit- und Integrationstests verwendet. Diese Aufgabe kann zwar mühsam sein (und war es auch!), aber sie hat uns enorm geholfen, nicht nur sicher zu sein, dass der Code so funktioniert, wie wir es erwarten, sondern auch einige Bits und Stücke zu verbessern und mehr über den von anderen Teammitgliedern geschriebenen Code zu erfahren.

FPC

Wir haben gerade ein Konferenzpapier über die Umsetzung von Mana in der FPC veröffentlicht; das Papier wird auf der FTC2020 vorgestellt werden. Darüber hinaus beendeten wir eine kurze Forschungsnotiz, die Effekte untersucht, die sich aus einer gewichteten Stimmabgabe ergeben können, wie z.B. Verlust der Anonymität, Zentralisierung und Skalierbarkeit, und gleichzeitig ihre Bedeutung für die Gestaltung und Implementierung des Protokolls diskutiert.

Vernetzung/Networking

Zwei Manuskripte sind eingereicht worden und werden derzeit für eine hochrangige internationale Konferenz geprüft: (i) „On Congestion Control for Distributed Ledgers in Adversarial IoT Networks“ stellt unseren aktuellen Vorschlag zur Bewältigung von Netzwerküberlastungen vor und zeigt die Ergebnisse unserer Simulationen; (ii) „Preventing Denial of Service Attacks in IoT Networks through Verifiable Delay Functions“ beschreibt, wie verifizierbare Verzögerungsfunktionen verwendet werden können, um PoW als ratenbegrenzenden Mechanismus zu ersetzen, und zeigt eine tatsächliche Implementierung auf Raspberry Pi und Standard-Laptops.

Darüber hinaus arbeiten wir an der theoretischen Validierung unseres Staukontrollalgorithmus durch Analyse der Pufferdynamik mit Hilfe von Modellen der Warteschlangentheorie, und wir verallgemeinern unseren Vorschlag für Transaktionen unterschiedlicher Größe und Art. Was verifizierbare Verzögerungsfunktionen betrifft, so untersuchen wir aktiv Multi-Exponentierungstechniken zur Beschleunigung der Berechnungs- und Verifikationszeit, insbesondere bei Geräten mit geringem Stromverbrauch.

dRNG

Nachdem die Spezifikation des dRNG-Moduls fertiggestellt ist, konzentrieren wir uns derzeit auf das Schreiben von Artikeln für begutachtete wissenschaftliche Zeitschriften. Wir hoffen, dass die Veröffentlichung unserer Ergebnisse uns helfen wird, unsere Ideen zu verbessern und sie zu fördern. Wir haben beschlossen, dass wir zwei Artikel vorbereiten werden. Die erste konzentriert sich auf die Auswahl des Komitees und die Veröffentlichung von Zufallszahlen im Tangle. Die zweite ist der Verbesserung von Sicherheit und Lebensbedingungen gewidmet.

Mana und Autoperieren 

Wir haben jetzt gute Entwürfe für die Mana- und Autopeering-Spezifikationen, was ein spannender Schritt ist. Nachdem die technische Abteilung sie überprüft hat, werden wir einige abschließende Überarbeitungen vornehmen, und dann werden die Spezifikationen fertig gestellt. Das Ingenieurteam wird dann in der Lage sein, diese Lösungen zu implementieren.

Wir haben auch einige Ideen zum Mana verfeinert und beschlossen, eine Funktion hinzuzufügen, die es den Knotenpunkten ermöglicht, ihr Mana „aufzufrischen“, auch wenn es mit in Kühlhäusern gelagerten Geldern verbunden ist. Dies wird den Nutzen von Mana erhöhen und auch zur Sicherung des Systems beitragen.
Da die Spezifikationen kurz vor der Fertigstellung stehen, geht die erste Phase des Projekts dieser Gruppe wirklich zu Ende. Wir hoffen, dass wir damit beginnen können, unseren Schwerpunkt auf das Schreiben unserer Ergebnisse und auch auf die Erforschung der besten Parameter zu verlagern. Diese Arbeit ist zwar wichtig, aber nicht so dringlich wie die Spezifikationen, da sie den Ingenieuren nicht die Möglichkeit nimmt, mit der Kodierung zu beginnen.

Protokoll 

In diesem Monat schloss das Team die Recherchen zum Thema Waisenhaus und Finalität ab. Wir haben auch die jüngste Forschung zur Solidität überprüft, um zu sehen, wie sie mit der Stimmabgabe und anderen Kontrollen, die von der Vergangenheit abhängen, interagieren würde. Daher haben wir beschlossen, dass die Solidität im Wertegewirr nicht erzwungen werden sollte, sondern dass sie für die Auswahl von Trinkgeldern und die Stimmabgabe geeignet sein muss.

Da die Forschungsarbeiten zum Protokoll fast abgeschlossen sind, werden die Spezifikationen geschrieben und schreiten reibungslos voran. Sie werden in den kommenden Tagen abgeschlossen und an das Ingenieurteam zur Rückmeldung weitergeleitet.

Wir freuen uns auf die kommende GoShimmer-Veröffentlichung und hoffen, dass Sie an den ersten Community-Tests teilnehmen können. Bis zu unserem nächsten monatlichen Update können Sie sich über das IOTA-Forschungsteam im Kanal #tanglemath auf unserem Discord auf dem Laufenden halten. Sie sind auch willkommen, unsere technischen Diskussionen in unserem öffentlichen Forum zu verfolgen und daran teilzunehmen: IOTA.cafe.

Dev Status Update — April 2020 – Deutsch

Original by Jakub Cech: https://blog.iota.org/dev-status-update-april-2020-ef4f4a12ac82 (24.04.2020)

Dieses Update wird jeden Monat vom IOTA-Entwicklerteam veröffentlicht und liefert Ihnen Neuigkeiten und Updates zu unseren Schlüsselprojekten! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen möchten.

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

Chrysalis

Die Forschungs- und Ingenieurteams haben zusammen mit dem Hornet-Team an der Fertigstellung der Spezifikationen für die ersten Chrysalis-Änderungen gearbeitet. Sie können die Spezifikationen in den verknüpften RFCs einsehen, aber auch selbst kommentieren und beitragen:

  • Gewichtete einheitliche zufällige Spitzenauswahl (Protokoll RFC #8)
  • Weiße Flagge (Protokoll RFC #5)
  • Die Spezifikation des Ed25519-Signaturschemas muss angepasst werden, da es mit UTXO gekoppelt wird

Die restlichen Chrysalis-Spezifikationen werden in den kommenden Wochen entworfen, und das Ziel ist es, sie im Mai fertigzustellen und in das Protokoll-rfc-Repository zu integrieren.

Autopeering, ebenfalls ein Teil von Chrysalis, wird bereits in der Hornet-Knoten-Software getestet. Es ist geplant, Autopeering bereits in die nächste Version von Hornet aufzunehmen.

Bee

Das Team schließt gerade die Arbeiten am ersten Bee-Prototypen ab. Das Team hat an den letzten Teilen des Puzzles gearbeitet: der Meilenstein-Erkennung und dem Durchqueren von Verwicklungen. In unseren internen Tests hat Bee seinen ersten Meilenstein bereits gefestigt. Der Prototyp wird im Mai freigegeben und für Tests zur Verfügung stehen. Das Hauptziel ist die Fertigstellung der Meilenstein-Erkennung und der Verwicklungswerkzeuge, die eine vollständige Verfestigung des Knotens ermöglichen werden.

Sie können alle Bee-RFCs in ihrem jeweiligen GitHub-Repository finden.

IRI

Das Team hat im vergangenen Monat IRI 1.8.5 veröffentlicht. Die Version enthielt wichtige Änderungen an den Bundle-Validierungsregeln, mit denen potenzielle Schwachstellen behoben wurden. Das Team konzentriert sich nun auf die nächste Minor-Version, IRI 1.8.6. Diese Version wird hauptsächlich eine neue Erstarrungslogik und andere Korrekturen enthalten, z.B. sollte die Erstellung lokaler Schnappschüsse schneller als bisher sein.

Wir gehen davon aus, dass das RC von IRI 1.8.6 nächste Woche herauskommen wird.

Intelligente Verträge

Wie letzte Woche angekündigt, haben wir unsere Aufmerksamkeit auf die Entwicklung eines neuen Smart Contract-Ansatzes als Layer-2-Lösung verlagert, der auf der Entwicklung von Koordizid in GoShimmer aufbaut. Wir planen, in den kommenden Wochen einen detaillierteren Beitrag über die entwickelte Lösung zu veröffentlichen. Eine kurze Einführung finden Sie hier.

Trinity

Das Trinity-Team hat in drei Schlüsselbereichen gearbeitet. In letzter Zeit lag ein Schwerpunkt auf der Erstellung einer PoC-App und einer Website, um die Möglichkeiten des Unified Identity Protocol zu demonstrieren. Weitere Informationen zu diesem Projekt werden folgen.

Auf der Trinity-Seite hat das Team Fragen geklärt, Abhängigkeiten aktualisiert und einige Reibungspunkte gelöst. Der jüngste Spam hat für Trinity-Benutzer ein Ärgernis verursacht und das Team hat Schritte unternommen, um dieses Problem zu lösen, einschließlich der Hinzufügung von Filtern für mobile Transaktionen. Eine neue Version wird bald verfügbar sein.

Schließlich hat das Team die Planung für die Brieftasche nach Trinity fortgesetzt. Es wurde ein Workshop „Jobs to be Done“ abgehalten, um sicherzustellen, dass die Spezifikation den aktuellen und zukünftigen Benutzerbedürfnissen entspricht. Der Schwerpunkt liegt nun auf der Unterstützung bei der Definition der Client-Bibliotheken für Chrysalis, wobei wiederverwendbare Adressen einen großen Teil der Möglichkeiten der neuen Brieftasche ausmachen. Das Team arbeitet hart daran, das DID-Projekt zum Abschluss zu bringen und Trinity in einen wartungsarmen Modus zu versetzen, damit sie sich auf die nächste Generation der Brieftasche konzentrieren können.

GoShimmer

Das GoShimmer-Team arbeitet derzeit an der Entwicklung weiterer Komponenten, die Werttransaktionen mit einer Konfliktlösung durch das angeschlossene FPC-Protokoll unterstützen werden. Mehr über die Entwicklung können Sie im letzten Forschungs-Update nachlesen.

Wir planen derzeit, die neue Version von GoShimmer in der ersten Junihälfte zu veröffentlichen.

Sie können das Projekt auf seinem GitHub-Repository verfolgen. Wenn Sie sich beteiligen möchten, sehen Sie sich unsere aktualisierten Beitragsrichtlinien an.

IOTA-Streams

Wir haben kürzlich die erste Alpha-Version von IOTA Streams (früher MAM) veröffentlicht. Wir arbeiten nun daran, mehr Dokumentation und Beispiele auf unserer Website zu veröffentlichen, damit mehr von Ihnen einsteigen und die Funktionalität testen können. Wir freuen uns über jedes Feedback, sowohl zur Implementierung als auch zur Dokumentation.

Permanode

Das Team arbeitet nun an der Fertigstellung der CLI-Funktionalität für die neue Permanode und wird sich als nächstes auf die Verfestigung konzentrieren. Wir haben in der Roadmap auch die Tatsache berücksichtigt, dass das Team beschlossen hat, die Rust Tokio-Laufzeitumgebung zu verwenden, anstatt eine benutzerdefinierte Laufzeitumgebung für den Permanode zu entwickeln. Die Tokio-Laufzeit erwies sich für die aktuelle Implementierung als ausreichend.

Das aktuelle Ziel ist es, die neue Version des Permanode Ende Mai oder in der ersten Junihälfte auf den Markt zu bringen.

Aktualisierungen der Roadmap

Wir haben einige bedeutendere Aktualisierungen unseres Fahrplans sowie Anpassungen der allgemeinen Zeitpläne der verschiedenen Projekte vorgenommen. Die Höhepunkte sind:

  • Der Abschnitt Qubic wurde in IOTA Smart Contracts geändert. Der Abschnitt zeigt jetzt die fertiggestellten Qubic-PoCs und konzentriert sich künftig nur noch auf die IOTA Smart Contracts
  • Kundenbibliotheken – die Zeitachse wurde verschoben, um mit der Chrysalis-Aktualisierung übereinzustimmen. Die Client-Bibliotheken erfordern erhebliche Änderungen zur Unterstützung von Chrysalis
  • Permanode – die optimierte Permanode-Laufzeit wurde gestrichen. Die anfängliche Implementierung des Permanentmodus wird auf der Tokio-Laufzeit aufbauen
  • MAM wurde in IOTA Streams umbenannt
  • Die Alpha-Implementierung von IOTA Streams wurde als abgeschlossen markiert. Die nachfolgenden Entwicklungen, Korrekturen und Änderungen beziehen sich auf die Implementierungselemente C und Rust.

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

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

Stand der IOTA-Forschung – April 2020

Original by Serguei Popov: https://blog.iota.org/iota-research-status-update-april-2020-f1c3576b57db (16.04.2020)

Wir freuen uns, Ihnen die neuesten Nachrichten aus der IOTA-Forschungsabteilung mitzuteilen. Wir hoffen, dass Ihnen die Präsentationen zur Einführung in die Coordicide-spezifikationen, die wir kürzlich veröffentlicht haben, gefallen haben. Nachstehend finden Sie die neuesten Updates zu unseren Fortschritten.

Sitzung „Benennung“

Mehrere Forscher trafen sich mit weiteren Mitgliedern der Stiftung, um viele der neuen Coordicide-Strukturen zu benennen. Dies mag trivial erscheinen, ist aber aufgrund ihrer Bedeutung und Dauerhaftigkeit tatsächlich schwierig. Sowohl interne als auch externe Entwickler müssen verstehen, wie IOTA funktioniert, damit sie Anwendungen erstellen können. Abgesehen von der Verlangsamung der Produktion kann ein unintuitives Benennungsschema sogar die Annahme behindern, indem es Menschen davon abhält, auf der IOTA-Plattform aufzubauen.

Wir haben gute Fortschritte gemacht. Da wir davon ausgehen, dass der größte Teil des Datenverkehrs im IOTA-Netz aus „0-Wert-Transaktionen“ bestehen wird, haben wir vorläufig beschlossen, die Objekte im Tangle in „Nachrichten“ statt in „Transaktionen“ umzubenennen. Jede Nachricht enthält eine Nutzlast, und wir haben Namen für mehrere der Kernnutzlasttypen entwickelt. Zusätzlich zu den Kernnutzlasten können Benutzer ihre eigenen Nutzlasttypen definieren, die nicht von allen Knoten verarbeitet werden müssen. Mit diesem flexiblen Nachrichten-/Payload-Format kann IOTA eine Vielzahl von Anwendungen bedienen.

In Verbindung mit dem Benennungsprozess stehen wir kurz davor, das Layout der Nachrichten und einiger Kernnutzlasten auf hohem Niveau abzuschließen. Um die Dinge beim Namen nennen zu können, müssen wir verstehen, was wir benennen. Dies ist ein wichtiger Schritt zur Entwicklung eines standardisierten Protokolls.
Wir gehen davon aus, dass die Terminologie bis zur nächsten Aktualisierung fertig gestellt und veröffentlicht sein wird.

Spezifikationen

Wir haben große Fortschritte bei den Spezifikationen von Coordicide gemacht und arbeiten derzeit an den Blaupausen und einem gelben Papier. Mike Bennett von der OMG und unser Leiter der Normung unterstützt diesen Prozess. Die Arbeit an GoShimmer (erste Implementierung von Coordicide) ist in vollem Gange, und wir beabsichtigen, in einigen Wochen das erste Testnetz zu starten. Dies ist eine gemeinsame Arbeit des Forschungs- und Ingenieurteams. Um beide Teams auf der theoretischen Ebene aufeinander abzustimmen, haben wir eine Reihe von Präsentationen entwickelt, in denen wir kurz erläutern, welche Themen in der Hauptspezifikationsdatei erscheinen sollen. Die Präsentationen wurden recht gut aufgenommen und ermöglichten es den Ingenieuren, gemeinsam mit den Forschern an jedem Thema zu arbeiten. Mit dem Schreiben der Spezifikationen wurde begonnen, und wir hoffen, im kommenden Monat eine große Weiterentwicklung zu erreichen.

Vernetzung

Wir haben eine erste Komplettlösung zur Bewältigung von Netzwerküberlastungen fertiggestellt. Insbesondere besteht unser Protokollvorschlag aus zwei Modulen, die die Tarifkontrolle ergänzen: (i) Terminierung, bei der Transaktionen, die von bestimmten Knoten ausgegeben werden, Vorrang eingeräumt wird, um den Durchsatz proportional zum Mana zu teilen; (ii) Tarifgestaltung, die sich mit der lokalen Überlastung befasst und von der AIMD inspiriert ist. Gegenwärtig führen wir umfangreiche Simulationen durch und vergleichen sie auch mit bestehenden Terminierungsrichtlinien und Staukontrollalgorithmen. Unsere Ergebnisse zeigen, dass Fairness garantiert ist und die Latenzzeit begrenzt ist. Wir planen nun, eine „Packet-Drop-Politik“ zur Behandlung von Transaktionsbursts hinzuzufügen und anschließend zu evaluieren, wie sich diese Politik auf die Konsistenzanforderung auswirkt.

Was den adaptiven PoW-Algorithmus betrifft, so haben wir das so genannte Kollisionsproblem gelöst, indem wir Sequenznummern entfernt haben (mehr dazu können Sie hier lesen). Das Protokoll ist bereit für Spezifikationen. Zusätzlich untersuchen wir im Zusammenhang mit VDFs niedrigere Grenzen für die Anzahl der Gate-Operationen, die zur Lösung modularer Quadrierungen erforderlich sind, was Schätzungen der physikalischen Grenzen zur Lösung einer VDF liefern wird. Unser Vortrag über IOTA und VDFs auf der Stanford Blockchain Conference ist auf YouTube verfügbar.

dRNG

Wir schlossen den Großteil der Konzeptarbeit an einem dezentralen Zufallszahlengenerator (dRNG) für das IOTA-Netzwerk ab. Unsere Arbeit beinhaltete die Anpassung und Justierung des „drand-Protokolls“, damit es in der DLT-Umgebung ohne Erlaubnis funktioniert. Wir entwarfen ein spezielles Tangle-Nachrichten-Layout, das die Auswahl durch den Ausschuss, die verteilte Schlüsselgenerierung und die nahtlose Erfassung der Zufälligkeit ermöglicht.

Im Moment ist das Hauptaugenmerk unserer Gruppe darauf gerichtet, die Spezifikation für die Entwickler zu schreiben. Wir entwickeln jedoch auch zusätzliche Sicherheitsmerkmale von IOTA dRNG. Die endgültige Spezifikation soll Backup-Zufallsgeneratoren sowie Mechanismen zur Erkennung von Ausschussfehlern und Methoden zur Benennung des neuen Ausschusses enthalten.

GoShimmer-Implementierung

Unsere Gemeinschaft hat uns beim Testen unseres Prototyps enorm geholfen, und als Ergebnis haben wir v0.1.3 veröffentlicht, die mehrere Fehlerbehebungen, verbessertes Autopeering und Dashboard und mehr Stabilität enthält.

In der Zwischenzeit hat das GoShimmer-Team an der bevorstehenden nächsten Version v0.2.0 gearbeitet. Wir haben die Unterstützung für traditionelle Public-Key-Kryptographie auf der Basis elliptischer Kurven (z.B. Ed25519 und BLS) sowie binäre Hash-Funktionen wie SHA-256, SHA-512 und Blake2b integriert.

Die Goshimmer-Modularität hat durch die Implementierung eines schichtenbasierten Ansatzes weitere Fortschritte gemacht. Obwohl die Benennung der Schichten noch nicht abgeschlossen ist, können wir Ihnen einen kleinen Einblick geben: Die erste Schicht befasst sich mit Nachrichten; jede Nachricht enthält einige Metadaten wie Stamm, Zweig, Zeitstempel und andere Informationen zur Identität des Emittentenknotens sowie eine Nutzlast. Jede Nutzlast hat einen Typ und einige Daten. Aufgrund ihres Typs (z.B. dRNG-Typ, Werttransaktion) können die enthaltenen Daten entsprechend interpretiert werden. Diese „Interpretations“-Schicht ist unsere zweite Schicht. Darüber haben wir die „Anwendungs“-Schicht, wo ein Protokoll die von der darunter liegenden Schicht bereitgestellten Informationen nutzen kann. So könnte zum Beispiel ein intelligentes Vertragsprotokoll über dem Werte-Tangle implementiert werden (d.h. das Protokoll, das die Werttransaktion implementiert), oder ein dezentralisiertes Lotterieprotokoll über dem dRNG-Protokoll.

Werttransaktionen und das UTXO-Modell sind nun im Entwicklungszweig abgeschlossen. Wir verbinden auch das FPC-Protokoll mit dem Werte-Tangle, so dass widersprüchliche Transaktionen durch Abstimmung gelöst werden können. Eine Wasserhahnanwendung wird es den Benutzern ermöglichen, Mittel zu Testzwecken anzufordern.
Das dRNG wurde ebenfalls in seine erste Iteration integriert: Ausschussmitglieder werden eine IOTA-Version der drand-Anwendung betreiben und „kollektive Baken“ über einen GoShimmer-Knoten an das Netzwerk senden. Jeder Knoten wird in der Lage sein, die Korrektheit der „collective beacons“ zu verifizieren, indem ihre Signatur mit dem verteilten öffentlichen Schlüssel verglichen wird (d.h. dem öffentlichen Schlüssel, der aus den öffentlichen Schlüsseln aller Ausschussmitglieder abgeleitet wird).

Schließlich haben wir an einigen kleineren Verbesserungen gearbeitet: ein besserer Netzwerk-Visualisierer, sowohl auf der Client- als auch auf der Server-Seite; ein Plugin-Manager, der es Entwicklern erlaubt, GoShimmer-Plugins einfach hinzuzufügen und zu verwalten; automatisierte Integrationstests; ein flexibleres Autopeering, das frühere NAT- und Reverse-Proxy-bezogene Einschränkungen aufhebt.

FPC

In der FPC-Gruppe arbeiteten wir weiter an Optimierungen der FPC. Simulationsstudien zeigen, dass diese Anpassungen die Ausfallrate um mindestens eine Größenordnung senken. Gegenwärtig fassen wir diese Ergebnisse in einem Forschungspapier zusammen; das Video gibt Ihnen vielleicht einen ersten Eindruck von unserem Ansatz und von der Art der Ergebnisse, die wir zeigen können. Die Spezifikationen von FPC sind weit fortgeschritten und die restlichen Details werden in Zusammenarbeit mit dem Ingenieurteam festgelegt.

Mana und Autopeering

Die Mana- und Autopeering-Projekte beginnen sich zu beruhigen. Wir diskutierten die letzten Fragen bezüglich der Spezifikationen und trafen einige endgültige Designentscheidungen.

Wir haben auch die Arbeit an unseren Forschungsarbeiten fortgesetzt. Wir haben beschlossen, zwei Arbeiten zu schreiben: eine Analyse unserer Simulationen, die wir mit unserem GoShimmer-Simulator durchgeführt haben. Die zweite wird unsere mathematischen Berechnungen enthalten. Wir hoffen auch, einen Konferenzband zu verfassen, der die Ergebnisse in diesen beiden Papieren zusammenfasst.

Wir haben jetzt noch drei Aufgaben:

  1. Schreiben der Spezifikationen
  2. Beendigung unsere Forschungsarbeiten
  3. Die Parameter einstellen

Obwohl die erste Aufgabe eindeutig die wichtigste ist, erwarten wir weitere Fortschritte bei unseren Papieren. Wir haben beschlossen, mit der Erforschung der endgültigen Parameter zu warten, bis wir mit der Spezifikation fertig sind.

Protokoll

Die Protokollgruppe befasste sich in diesem Monat mit dem Problem der Endgültigkeit des Tangle, wo wir eine Reihe von Instrumenten entwickelt haben, mit denen der Benutzer die Sicherheit seiner Transaktionen überprüfen kann. Wir erörterten auch Optimierungen und die Frage, wie die Finalität mit vertretbarem Rechenaufwand kalkulierbar gemacht werden kann. Wir sind dabei, Wahrscheinlichkeitswerte für die Finalitätstools zu bestimmen, so dass wir genau wissen, wie sicher wir sind. Der nächste Schritt der Gruppe wird darin bestehen, die Engpässe zu bestimmen, die im gegenwärtigen Ansatz optimiert werden müssen, indem das Verarbeitungsverfahren eines Knotens analysiert wird, sowie mit dem Schreiben der Spezifikationen zu beginnen.

Wir freuen uns darauf, Ihnen bald weitere Neuigkeiten mitzuteilen! Wie immer können Sie sich über das IOTA-Forschungsteam im Kanal #tanglemath auf unserem Discord auf dem Laufenden halten. Und Sie sind herzlich eingeladen, unsere technischen Diskussionen in unserem öffentlichen Forum zu verfolgen und daran teilzunehmen: IOTA.cafe.

Der Zustand von Qubic und die Zukunft der Smart Contracts auf IOTA

Original by Eric Hopp: https://blog.iota.org/the-state-of-qubic-63ffb097da3f

TL;DR:

Die IOTA-Stiftung hat beschlossen, unseren Schwerpunkt auf einen neuen Ansatz für Smart Contracts zu verlagern, der sich aus unserer früheren Arbeit ableitet. IOTA Smart Contracts ist eine „Layer-2-Lösung“, die auf der Entwicklung von Coordicide in GoShimmer aufbaut. Eine kurze Einführung finden Sie hier. Die Weiterentwicklung von Qubic erfordert erhebliche Ressourcen und Zeit, und unser neuer Ansatz wird eine breitere und schnellere Anwendung ermöglichen. Wir haben einen funktionierenden Proof of Concept der Programmiersprache Qupla, der auf FPGA-Hardware ausgeführt werden kann, als Open Source zur Verfügung gestellt. Wir laden die Open-Source-Gemeinschaft ein, ihn zu erforschen.

Der Zustand von Qubic

Es ist schon eine Weile her, dass wir uns umfassend mit dem aktuellen Stand des Qubic-Projekts befasst haben. Dieser Artikel wird hier Abhilfe schaffen, indem er eingehend darauf eingeht, wo wir das Projekt derzeit sehen, wie weit wir gekommen sind, welche Lektionen wir gelernt haben und wie die IOTA-Stiftung die Entwicklung von Smart Contracts weiter vorantreiben wird.

Bitte beachte: Wir gehen davon aus, dass der Leser über ein grundlegendes Verständnis des Qubic-Systems sowie der Artikelserie über das Qubic-Berechnungsmodell verfügt. Einige der in diesen Ressourcen verwendeten Begriffe haben sich möglicherweise im Laufe der Zeit aus Gründen der Klarheit etwas geändert.

Qubic: ein layered-System

Wenn man sich Qubic genauer ansieht, dann besteht es eigentlich aus zwei sehr lose gekoppelten Schichten, die sich gegenseitig nicht so sehr zu brauchen scheinen. Diese beiden Schichten sind:

  • Die „Nachrichtenschicht“ Smart Contract (SC), die als Level-2-Protokoll über dem IOTA Tangle läuft. Diese Schicht regelt die Ausführung von SCs durch ein Komitee von Verarbeitungsknoten (Nodes). Die Nodes erzeugen einen beschlussfähigen Konsens über die Verarbeitungsergebnisse und bieten einen Prüfpfad für das Tangle. Diese Schicht kümmert sich nicht darum, wie die Verarbeitung erfolgt, sondern nur darum, dass die Ergebnisse durch den Prüfpfad, den SC-Code, die Eingabedaten und die Ausgabedaten nachweislich korrekt und überprüfbar sind.
  • Die Ebene der virtuellen Maschine (VM) von Abra. Diese Schicht regelt die tatsächliche Ausführung des SC-Codes. Sie hat einen besonderen Schwerpunkt auf der Fähigkeit, auf IoT-Geräten mit geringem Ressourcenbedarf ausgeführt werden zu können. Die Schicht nimmt Eingabedaten entgegen, führt den (möglicherweise hardwarebeschleunigten) Code aus und gibt Ergebnisse aus. Dieser Schicht ist es gleichgültig, woher die Eingabedaten kommen und wohin die Ergebnisse gesendet werden.

Diese beiden separaten Schichten werden durch das Qubic Computation Model (QCM), ein Ereignisverarbeitungssystem, zusammengeklebt. Das QCM regelt die Weiterleitung der Eingabedaten von der SC-Schicht an die VM-Schicht und die Rückgabe der Ergebnisse von der VM-Schicht an die SC-Schicht. Das QCM ist ein sehr generisches Modell. Es nimmt nichts über die Ereignisverarbeitung an, woher die Ereignisdaten kommen oder wohin die Verarbeitungsergebnisse gehen. Es handelt sich lediglich um einen einfachen Dispatching-Mechanismus, der eine vollständige Entkopplung zwischen den Schichten, die miteinander reden müssen, sicherstellt.

Verbinden der Schichten

Wo also findet die Kopplung dieser beiden Systeme statt, wenn sie fast vollständig entkoppelt sind? Zunächst besteht die Notwendigkeit, Berechnungsergebnisse unabhängig voneinander verifizieren zu können. Das bedeutet, dass Sie neben einem Audit-Trail für die Eingabedaten und Ergebnisse von SC-Aufrufen auch den entsprechenden SC-Code benötigen, der aufgerufen wurde, um Teil dieses Audit-Trails zu sein. Auf diese Weise weißt du genau, welchen Code du mit den Eingabedaten ausführen musst, wenn du das Ergebnis verifizieren willst.

Beachte, dass dies immer noch nicht die Verwendung des Qubic-spezifischen Qupla-Codes und des entsprechenden Abra VM zur Ausführung des SC erfordern würde. Du könntest im Wesentlichen jede VM und jede Programmiersprache verwenden, solange der SC-Code mit diesen kompatibel ist. Unsere erste Proof-of-Concept-Implementierung des QCM vermischt in der Game of Life-Demo tatsächlich Qubic-spezifischen Abra-Code mit Standard-Java-UI-Code. Es gibt jedoch einen ganz bestimmten Grund, bei der Auswahl einer VM zur Ausführung Ihres SC-Codes vorsichtig zu sein. Da Knoten diesen Code immer dann ausführen, wenn Daten für die SC automatisch und unbeaufsichtigt ankommen, möchten Sie verhindern, dass laufende SC-Programme in der VM-Schicht ausgeführt werden (unbegrenzte Schleifen/Rekursionen). Du benötigst einen Mechanismus, um das SC-Programm in Schach zu halten, so dass es nur für eine vernünftige, vorhersehbare Zeitspanne läuft.

In Ethereum wird dieses Runaway-Problem durch die Einführung von Gasgebühren (Gas) gelöst. Die Höhe der vorgesehenen Gebühren entspricht einem bestimmten Höchstbetrag für die SC-Verarbeitung. Sobald dieses Maximum überschritten wird, wird die SC-Ausführung abgebrochen, wodurch verhindert wird, dass der unkontrollierte SC-Code unbegrenzt weiterläuft. Der Nachteil dieser Methode besteht darin, dass es schwierig sein kann, die Höhe der Gasgebühren, die Sie für Ihre SC benötigen werden, im Voraus vorherzusagen, wenn die SC irgendeine Art von nicht-trivialer Verarbeitung durchführt. Und wenn Sie zu wenig Gasgebühren bereitstellen, könnte dies dazu führen, dass Ihre SC-Ausführung abgebrochen wird, bevor sie abgeschlossen ist. In diesem Fall haben Sie die Gasgebühren verloren, ohne dass die Vollstreckung zu einem Vollstreckungsergebnis geführt hätte.

In Qubic lösen wir dieses Problem deterministisch, indem wir ein funktionales Datenflussprogrammierungsmodell in der Abra VM haben, das keine unbegrenzten Schleifen/Rekursion zulässt und daher an und für sich nicht Turing-fähig ist. Jede Funktion definiert klar, wie viel Verarbeitung sie leisten wird. Es gibt keine direkte Verzweigung oder Schleifenbildung in der Abra VM, was bedeutet, dass jede Funktion immer genau die gleiche Anzahl von Anweisungen ausführt. Selbst wenn eine Funktion rekursiv aufgerufen wird, ist sie auf eine bestimmte maximale Anzahl von Aufrufen beschränkt. Unbegrenzte Schleifen können auf einer höheren Ebene, durch das QCM, aktiviert werden, aber die Einheit der Ausführung ist absolut klar und garantiert auf Funktionsebene begrenzt. Wenn du erwartest, dass dir die Aufrufe für eine Funktion ‚ausgehen‘, kannst du deinen Code so gestalten, dass der Fortsetzungszustand des SC Teil der resultierenden Ausgabe ist. Und das wiederum ermöglicht es dir, die Ausführung von diesem Punkt aus in einer nächsten Runde begrenzter Aufrufe fortzusetzen. Wir sagen daher, dass die Ausführung durch den QCM Quasi-Turing-Abschluss ist.

Beachte, dass, obwohl die Möglichkeit der Bereitstellung von Belohnungen als potenzieller Anreiz für die Verarbeitung besteht, es in Qubic nicht erforderlich ist, das Äquivalent der Ethereum-Gebühren für die Verarbeitung bereitzustellen. Es könnte andere Anreize geben, die genauso gut oder sogar besser funktionieren. Zum Beispiel, wenn eine Baugruppe speziell dafür ausgelegt ist, bestimmte Sensordaten zu aggregieren. Ein Prüfpfad oder sogar redundante Berechnungen könnten in einem solchen Fall Anreiz genug sein.

Virtuelle Maschine Abra

Das Abra VM-Programmiermodell ist insofern sehr ehrgeizig, als dass es uns nicht nur ein Programmiermodell zur Verfügung stellt, das Quasi-Turing-fähig gemacht werden kann, sondern es entfernt sich auch von Standard-Opcode-basierten sequentiellen Befehlen, die von einer komplexen CPU verarbeitet werden. Stattdessen bietet es uns eine maximale Parallelisierung von Operationen durch ein Datenflussmodell, das letztlich nur zwei Arten von Operationen hat, mit denen jede Funktion implementiert werden kann: Lookup-Tabellen (LUTs) und Fusionen. Diese Operationen wurden speziell wegen ihrer Fähigkeit ausgewählt, einfach direkt in der Schaltung instanziiert zu werden. Die maximale Parallelisierung von Operationen wird nur bei der Instantiierung in Schaltkreisen erreicht. Die einzigen sequentiellen Datenflusspfade werden durch Operationen gebildet, die direkt von den Ergebnissen früherer Operationen abhängen. Alles andere kann parallel ausgeführt werden. Sie erhalten also maximal parallele sequentielle Datenflusspfade.

Die Einfachheit des Abra VM-Programmiermodells bedeutet auch, dass es sehr einfach ist, einen Software-Emulator (Interpreter) zu erstellen, der diese VM auf einem Standardprozessor ausführen kann. In diesem Fall gehen viele Möglichkeiten der Parallelverarbeitung verloren, aber es werden trotzdem korrekte Verarbeitungsergebnisse geliefert. Für einfache SCs, die nur spärlich aufgerufen werden, könnten Sie also auf eine software-emulierte Abra-VM zurückgreifen. Wenn Sie jedoch Hardware-Beschleunigung benötigen, müssen Sie die VM tatsächlich in einer Schaltung implementieren. An dieser Stelle stellen wir uns drei Ebenen der Hardware-Implementierung vor.

  1. Verwenden Sie vorhandene FPGAs, um die Abra-VM zu implementieren. Dies hat den Vorteil, dass Sie den VM-Schaltkreis nur einmal für jeden unterschiedlichen FPGA-Typ erstellen müssen und Sie anschließend beliebigen Abra-VM-Code auf einem solchen Gerät ausführen können. Allein diese Fähigkeit ist bahnbrechend. Derzeit benötigen Sie einen sehr leistungsfähigen PC, der lange Zeit läuft, um die Schaltung für ein Programm zu entwerfen, das auf einem bestimmten FPGA-Typ läuft. Und das ist etwas, das Sie jedes Mal tun müssen, wenn Sie etwas an Ihrem Programm ändern oder wenn Sie einen anderen FPGA-Typ anvisieren. Stattdessen layouten Sie jetzt die Schaltung für unsere Open Source Abra VM nur einmal für jeden FPGA-Typ. Danach können Sie das Programm, das Sie auf der VM ausführen möchten, einfach ändern, neu kompilieren, laden und auf jedem FPGA ausführen, der die Abra-VM ohne weitere Änderungen implementiert hat.
  2. Verwenden Sie ein ASIC, um die Abra-VM direkt zu implementieren. Das bedeutet, dass wir ein Open-Source-ASIC-Design für eine Abra-VM erstellen werden. Der Vorteil besteht darin, dass wir die Erstellung eines programmierbaren Bausteins vermeiden, der auf einem anderen (proprietären) programmierbaren Baustein (FPGA) läuft. Statt die Bausteine des FPGA zu programmieren, können wir direkt eine ASIC-Schaltung erstellen, die die Abra-VM implementiert. Das bedeutet nicht nur eine Geschwindigkeitssteigerung, sondern auch eine enorme Verringerung der erforderlichen Schaltungsmenge. Ein solcher Abra VM ASIC könnte leicht als Koprozessor für aktuelle Hardware oder als Hauptprozessor für bestimmte IoT-Anwendungen eingesetzt werden.
  3. Wenn Sie einen spezifischen Code für den Abra VM programmiert haben und überprüft haben, dass er korrekt funktioniert, könnten Sie auch einen ASIC erstellen, der die Operationen für diesen spezifischen Code als dedizierte Schaltung implementiert. Sie würden den allgemeinen Aspekt der Programmierbarkeit der VM-Implementierung verlieren, aber es gibt viele Anwendungsfälle, in denen Sie die einmal eingesetzte Hardware nie mehr ändern werden. Vor allem bei Sensoren und anderen Geräten, die Sie in Bereichen einsetzen, in denen Sie nach dem Einsatz nicht mehr so leicht darauf zugreifen können. Dies ist die IoT-Vision, auf die wir letztendlich hinarbeiten. Die Einfachheit der Operationen, aus denen sich der spezifische Programmcode zusammensetzt, macht die Erstellung eines ASICs relativ einfach. Und der generierte Schaltkreis erlaubt tatsächlich eine Reihe verrückter Optimierungen auf der Ebene der Logikgatter, da er keine programmierbaren Allzweck-Schaltkreise mehr verwendet.

Die wirklichen Verbesserungen des Abra-VM-Programmiermodells, wie der reduzierte Energiebedarf, die Aspekte des Datenflusses und die Möglichkeit des Wave-Pipelining werden diese letzte Implementierungsebene benötigen, um wirklich zu glänzen. Die allgemeineren programmierbaren Ebenen sind mit bestimmten Designeinschränkungen verbunden, die zusätzlichen „Overhead“ verursachen werden.

Ternäre Kodierung

Vielleicht ist Ihnen aufgefallen, dass in all dem oben Gesagten das Wort ternär noch nicht erwähnt wurde. Und natürlich wäre es möglich, diese gesamte Vision binär umzusetzen. Aber ein Teil der Qubic-Vision war schon immer die Fähigkeit, über die Grenzen der aktuellen Ausführungsmodelle hinauszugehen und die Hardware über das Mooresche Gesetz hinaus zu erweitern, das wohl ausgelaufen ist. Zu diesem Zweck haben wir immer die Vision eines ternären Ausführungsmodells gehabt. Auch wenn es noch keine nativen ternären Prozessoren gibt, kann dieses Modell dennoch einige Vorteile bieten. Die bemerkenswertesten unmittelbaren Vorteile sind: Datendichte und Berechnungsgeschwindigkeit.

Unser Programmiermodell arbeitet mit Schaltungen und daher mit der Informationseinheit der untersten Ebene. Bei binären Systemen wäre das nur ein bisschen. Aber das Abra-Datenflussmodell erfordert auch eine Darstellung der „Abwesenheit von Daten“ (Null), die für seinen Entscheidungslogikmechanismus entscheidend ist. Die normale Art und Weise, dies in binären Systemen darzustellen, wäre, ein zusätzliches Bit zu haben, um diesen Zustand anzuzeigen. Das bedeutet, dass jedes Informationsbit durch zwei Bits repräsentiert werden muss, um alle drei möglichen sich gegenseitig ausschließenden Zustände (0, 1 und null) kodieren zu können. Da aber 2 Bits 4 Zustände repräsentieren können, erscheint es nur natürlich, dies in vollem Umfang zu nutzen. Durch die Verwendung der ternären Kodierung benötigen wir immer noch nur 2 Bits, um die 4 sich gegenseitig ausschließenden Zustände (-, 0, 1 und null) darzustellen. Das bedeutet, dass wir Werte im Vergleich zur binären Kodierung, die sonst einen dieser 4 möglichen Zustände verschwenden würde, effizienter kodieren können. Im Vergleich zur ternären Kodierung benötigt die binäre Kodierung etwa 50% mehr 2-Bit-Informationseinheiten, um den gleichen Wertebereich darstellen zu können. Beispielsweise können 16 Bit Werte von -32768 bis +32767 kodieren, während nur 11 Trits bereits Werte von -88573 bis +88573 kodieren können.

Sobald Sie weniger Informationseinheiten zur Darstellung desselben Wertebereichs benötigen, sind auch bestimmte Berechnungen so viel schneller. Nehmen Sie zum Beispiel einen einfachen Ripple-Carry-Addierer. Um zwei Werte zu addieren, addiert er zwei entsprechende Informationseinheiten, was jedoch zu einem Übertrag auf die Addition der nächsten Einheit führen kann. Das heißt, wenn Sie 50% mehr Einheiten benötigen, um einen Wertebereich darzustellen, dauert die Ausführung einer solchen Addition ebenfalls 50% länger. Der Engpaß hierbei ist die Tatsache, daß jede Addition von der vorhergehenden Addition abhängt, da sie den Übertrag berücksichtigen muß. Die nächste Addition kann also erst dann erfolgen, wenn die vorhergehende vollständig ist und der Wert des Übertrags bekannt ist. Bringen Sie dies nun auf eine andere Ebene: die Multiplikation. Wenn Sie die einfache Methode verwenden, jede Einheit mit jeder Einheit zu multiplizieren, erhalten Sie eine zweidimensionale Abhängigkeit, was bedeutet, dass die Verarbeitungszeit bei Verwendung desselben Algorithmus mit binärer Kodierung 150% x 150% oder 225% der Zeit benötigt, die der Algorithmus bei Verwendung einer ternären Kodierung benötigen würde.

Die ternäre Kodierung, die wir für unsere Prototyp-FPGA-Implementierung verwendet haben, nennen wir 2b-Kodierung. Diese kodiert die 4 Zustände (-, 0, 1 und null) jeweils als (10, 11, 01 und 00). Wir nennen diese 2b-Kodierung, weil sie, wie oben diskutiert, 2 Bits pro Informationseinheit verwendet. Wir haben auch eine Alternative entwickelt, die wir 3b-Kodierung nennen, die 3 Bits pro Informationseinheit verwendet und die 4 Zustände jeweils als (100, 010, 001 und 000) kodiert. Die 3b-Kodierung mag vielleicht verschwenderischer erscheinen, aber sie hat eine Reihe interessanter Eigenschaften, die für die dritte Ebene der Hardware-Implementierung (direkter Code zur Schaltung) von größerer Bedeutung sind und in Zukunft noch eingehender untersucht werden sollen. Der Abra-Code ist völlig unabhängig von der verwendeten Kodierung. Die tatsächlich verwendete Kodierung wird letztlich von der spezifischen Implementierung der Abra-VM diktiert.

Sowohl die 2b- als auch die 3b-Kodierung verwenden alle Nullen, um den Nullzustand zu kodieren. Dies sollte dazu beitragen, den Energiebedarf der Hardware zu reduzieren, da der Null-Zustand der Standardzustand für alle Schaltkreise ist und normalerweise die meiste Energie darauf verwendet wird, den Zustand zu ändern. Abra ist so konzipiert, dass Entscheidungspfade so früh wie möglich zur Verwendung des Null-Zustands gezwungen werden, so dass keine Daten durch den größten Teil der Schaltung wandern und nicht verwendete Schaltungen ohne Umschalten im Standard-Null-Zustand bleiben können.

„Echte“ ternäre Hardware

Wie die Kodierung auf tatsächlich nativer ternärer Hardware aussehen wird, ist derzeit schwer vorstellbar, da wir noch kein funktionierendes ternäres System haben, mit dem wir arbeiten könnten. Eine interessante Idee, die aus der Qubic-Forschung hervorging, ist, dass man, da ternäre Prozessoren angeblich mit 3 Zuständen arbeiten, ein binäres Bit und den erforderlichen Nullzustand mit einem einzigen ternären Trit kodieren könnte. Dies würde bedeuten, dass ternäre Hardware unser Datenflussmodell direkt mit binärer Informationskodierung unterstützen kann. Anstatt also 2 Leitungen und alle zugehörigen Schaltkreise pro Leitung zu benötigen, um ein Bit und ein Null-Flag darzustellen, würden Sie nur eine einzige Leitung und die zugehörigen Schaltkreise benötigen, wodurch vielleicht sogar die Schaltungstechnik/Energie halbiert würde, die sonst für die gleiche binär codierte Verarbeitung in binärer Hardware erforderlich wäre. Ternäre Hardware ist derzeit in erster Linie eine Denksportaufgabe, aber es ist definitiv ein aufregendes Unterfangen für die Zukunft.

Hardware-Operationen

Das Abra-Programmiermodell hat ursprünglich 5 verschiedene explizite Operationen. 3 dieser Operationen reduzieren sich auf eine einfache Verdrahtung, sobald man sie auf Schaltungsebene implementiert. Sie sind nur notwendig, um Informationen als Trit-Vektoren zu gruppieren und weiterzugeben. Da aber auf der Schaltungsebene alles auf einzelnen Trits arbeitet, sind diese Trit-Vektoren meist konzeptionell. Daher erzwingen die Verkettungs- und Slicing-Operationen lediglich die korrekte Gruppierung von Informationen. Die Aufrufoperation ist nur vorhanden, um den Code effizient in einen Aufrufbaum zu reduzieren, aber sobald sie in einer Schaltung implementiert ist, erzwingt jede Aufrufoperation die Instantiierung des gesamten aufgerufenen Funktionsbaums in der Schaltung und verknüpft die Eingangs- und Ausgangs-Trit-Vektoren mit ihren Quell- und Zielvektoren.

Damit bleiben nur noch 2 Operationen übrig, die tatsächlich als logische Schaltung implementiert werden. Die erste ist die ternäre Lookup-Operation, die 3 Eingangstrits nimmt und einen einzelnen Trit gemäß der entsprechenden Lookup-Tabelle ausgibt. Die zweite ist die Merge-Operation, die getrennte Datenfluss-Eingänge zu einem einzigen Ausgang kombiniert und entweder als eine sehr spezielle Lookup-Operation oder durch Verwendung einfacher ODER-Gatter implementiert werden kann. Nur eine Eingabe darf ungleich Null sein und wird zur Ausgabe. Die Sprache Qupla, die den Abra-Code generiert, stellt sicher, dass nur ein Pfad ungleich Null sein kann. Alle anderen Werkzeuge, die direkt Abrac-Code erzeugen würden, sind erforderlich, um dies sicherzustellen.

Der FPGA-Konzeptnachweis

Um das Programmiermodell auf FPGA zu erleichtern, haben wir den FPGA so programmiert, dass er eine Bank von so genannten QLUTs (Qubic Look-Up Tables) bereitstellt. Jeder QLUT nimmt drei 2b-kodierte Trits als Eingabe und gibt dann einen weiteren 2b-kodierten Trit über eine konfigurierbare Nachschlagetabelle aus. Fusionen werden innerhalb der QLUTs durch Setzen eines speziellen Konfigurationsbits implementiert, das sie veranlasst, eine vordefinierte Lookup-Operation mit leicht unterschiedlicher Semantik zu verwenden.

Natürlich enthält der FPGA auch die zusätzliche Konfigurationslogik, die notwendig ist, um jede Eingangsoperation mit jeder Ausgangsoperation verbinden zu können. Diese Logik kann durch eine spezielle binäre Konfigurationsdatei konfiguriert werden, die leicht direkt aus dem auszuführenden VM-Code generiert werden kann. Der Code wird derzeit „on the fly“ konvertiert, wenn er an den FPGA gesendet wird. Sie enthält die Konfigurationsdaten für jedes einzelne QLUT und die Konfigurationsdaten für die Verbindungen zwischen den QLUTs.

Die QLUTs wurden bereits getestet, indem die gesamte Qupla-Testsuite im Emulator ausgeführt wurde, während eine bestimmte Funktion hardwarebeschleunigt wurde. Wir erlauben dem Benutzer, eine Funktion als hardwarebeschleunigt zu markieren, und die Qupla-Umgebung lädt automatisch die Konfigurationsdaten für diese Funktion in den FPGA. Wenn der Emulator dann den Emulator ausführt, übergibt er jedes Mal, wenn er auf diese spezifische Funktion trifft, die Eingangsdaten der Funktion an das FPGA und verwendet die resultierenden Ausgangsdaten, anstatt das Ergebnis für diese Funktion vom Emulator berechnen zu lassen. Wir haben mehrere repräsentative Funktionen auf diese Weise getestet und freuen uns, berichten zu können, dass dies perfekt funktioniert.

Als Nächstes benötigen wir eine FPGA-Version des Qubic Supervisors, d.h. der Entität, die Eingangsdatenereignisse an den korrekten VM-Code sendet und die berechneten Ergebnisse weiterleitet. Um zu vermeiden, dass wir ein Miniaturbetriebssystem schreiben müssen, werden wir zunächst eine einfache Embedded-Linux-Version verwenden, die auf einer CPU laufen kann, die auf dem FPGA eingebettet ist. Auf diese Weise können wir bestimmte Funktionen out of the box nutzen, ohne sie selbst entwickeln zu müssen. Wir haben es geschafft, dieses Linux bereits auf dem FPGA zu booten und es zu benutzen, um die Kommunikation zwischen dem Emulator und dem FPGA über ein einfaches Socket-Protokoll abzuwickeln. Der nächste Schritt wird die Implementierung des Supervisors und einiger zusätzlicher Glue-Code sein, um stattdessen die Kommunikation mit der Außenwelt über HTTP zu ermöglichen.

Der nächste Schritt wäre die Implementierung eines HTTP-Listeners auf dem Embedded-Linux des FPGAs, der auf zwei Arten von Anfragen reagieren kann. Der erste Anfragetyp kann verwendet werden, um die Konfigurationsdatei auf den FPGA zu übertragen, und dieser wird dann zur Konfiguration des Programmiermodells, zur Einrichtung einer HTTP-Callback-Adresse und zur Initialisierung des Supervisors verwendet. Der zweite Anforderungstyp ist eine Eingabedatenanforderung, die verwendet werden kann, um die Ausführung einer Funktion mit den vom Supervisor bereitgestellten Eingabedaten auszulösen. Nach der Berechnung des Ergebnisses sendet der Supervisor die resultierenden Ausgabedaten asynchron an die HTTP-Callback-Adresse.

Beachten Sie, dass dies bedeutet, dass der anfängliche End-to-End-Konzeptnachweis (Qupla-to-FPGA, der ursprünglich für Ende Januar 2020 geplant war) noch nicht die volle Supervisor-Funktionalität haben wird, sondern nur in der Lage sein wird, eine einzige beliebige Funktion auf dem FPGA einzurichten und aufzurufen und das Ergebnis zurückzugeben. Das Laden und Aufrufen mehrerer Funktionen und komplexere Planung durch EEE wird der nächste Schritt für die Implementierung im Supervisor-Code sein.

Auf der Softwareseite ist der Qupla-Compiler jetzt in der Lage, eine spezifische Version des Abra-Codes zu erzeugen, die leichter eine 1-zu-1-Konvertierung in die binäre Konfigurationsdatei ermöglicht, indem alle Verkettungs-, Slice- und Aufrufoperationen eliminiert werden. Wir haben überprüft, dass der resultierende transformierte Code immer noch korrekt funktioniert, indem wir die Testsuite mit diesem Code im Emulator ausgeführt haben. Der Emulator selbst ist nun in der Lage, über die Socket-Schnittstelle eine Schnittstelle zum FPGA herzustellen. Er sendet die generierte Konfigurationsdatei an das FPGA und ruft diese Funktion bei Bedarf auf. In Zukunft wird der Qupla-Supervisor in der Lage sein, Ereignisse über die HTTP-Schnittstelle zum und vom FPGA zu senden.

Erste Lehren aus dem PoC

Bis jetzt funktioniert alles wie vorgesehen. Wir haben ein völlig neues Verarbeitungsmodell geschaffen, das jede Art von allgemeiner Verarbeitung durchführen kann. Das Modell behandelt die RAM-Speicherung genauso wie jede andere Art von E/A, d.h. es liegt außerhalb des Geltungsbereichs des Abra-Codes und wird an Entitäten weitergegeben, die Daten für uns mit Hilfe von EEE speichern/abrufen können. Dies erfordert eine andere Art der Problembetrachtung, und es wird wichtig sein, die resultierende Komplexität zu bewerten und/oder zu sehen, ob es eine Möglichkeit gibt, die Komplexität in Qupla-Sprachkonstrukten zu verbergen, oder ob eine noch höhere Computersprache erforderlich ist. So wurde beispielsweise bereits die Notwendigkeit einer Art von Schleifenkonstrukt gesehen.

Zwei unmittelbare Hürden zeichnen sich derzeit ab und erfordern eine Lösung:

  1. Der derzeitige Ressourcenbedarf der QLEs auf dem ausgewählten FPGA (DE10-Nano) begrenzt uns auf insgesamt nur 512 QLEs. Dies mag ein wenig optimiert werden, aber wir erwarten nicht, dass sich dieser Bedarf auf mehr als etwa das Doppelte erhöht. Natürlich könnten wir einen größeren, teureren FPGA auswählen, aber für das Prototyping wollen wir es einfach und erschwinglich halten für Leute, die unsere Anstrengungen verdoppeln und damit herumspielen möchten. Eine direkte Folge davon ist, dass wir nur einige kleinere Funktionen auf den FPGA laden können, und der Kommunikations-Overhead beim Aufruf dieser Funktionen überwiegt meist den Verarbeitungsgewinn. Das war zu erwarten, und wir hoffen, dass wir, sobald wir zum nächsten Schritt übergehen, einem ASIC Abra VM, Größenordnungen darüber hinaus gehen können.
  2. Die Instantiierung von Funktionsaufrufen wird sehr schnell unerschwinglich. Aufgrund der „Call-Tree-Natur“ des Codes hat die Expansion eines solchen Aufrufbaums ein exponentielles Wachstum. Wenn X dreimal Y aufruft, was wiederum viermal Z aufruft, erhalten Sie drei vollständige Y-Instanziierungen, die 3×4 oder 12 vollständige Z-Instanziierungen verursachen. Sie können sehen, wie schnell dies eskaliert. Die Lösung dieses Problems wird unser Hauptaugenmerk sein müssen. Derzeit schwirren einige Ideen herum, aber wir haben uns noch nicht mit allen Konsequenzen für das Datenflussmodell befasst.

Übrigens leidet der Abra-Emulator nicht unter diesen Problemen, da er die Funktionsinstantiierung durch einen gewöhnlichen stapelbasierten Funktionsaufrufmechanismus emuliert und die Lookup-Tabellen in einem von den Lookup-Anweisungen getrennten Speicher ablegt. Heutige Gigabyte RAM-Größen würden Millionen von Abra VM-Befehlen ohne Probleme ermöglichen.

Schlussfolgerung

Nach einem langen Weg mit vielen unvorhergesehenen Hürden haben wir bewiesen, dass das Abra-Datenflussprogrammiermodell durchgängig funktioniert, von der Programmiersprache Qupla bis zur Ausführung des generierten Codes auf dedizierter FPGA-Hardware. Wir laden alle ein, mit dem Qupla-Repository herumzuspielen und zu sehen, was Qupla kann und wie es im Emulator läuft. Diejenigen, die sich mehr für Hardware interessieren, können mit dem Qubic HDL-Repository herumspielen und tatsächlich Code auf einem DE10-Nano ausführen, so wie wir es tun, oder sogar den Code an Ihr eigenes bevorzugtes FPGA-System anpassen.

Eine neue Richtung für intelligente Verträge auf IOTA

Auch wenn diese Arbeit die Vision hinter Qubic beweist und einen großen Schritt nach vorn darstellt, sind noch weitere Fragen zu lösen und es sind noch erhebliche Entwicklungsinvestitionen erforderlich, um Qubic produktionsreif zu machen. Unsere umfangreiche Arbeit an Qubic hat viel wertvolle Forschung und Entwicklung hervorgebracht und bildet die Grundlage für unseren weiteren Ansatz. Dementsprechend hat die IOTA-Stiftung die Entscheidung getroffen, die Entwicklung von Qubic einzustellen und unseren Schwerpunkt speziell auf die Ebene der intelligenten Verträge zu legen.

Der Hauptgrund für diese Entscheidung besteht darin, dass IOTA mit einer neuartigen intelligenten Vertragslösung, die in Verbindung mit der Coordicide-Knotenpunkt-Software arbeitet, schneller auf den Markt kommen kann. Am Ende verfügen wir über ein komplettes System – bereit für eine breitere und schnellere Einführung.

IOTA Smart Contracts ist das, was wir unsere intelligente Layer-2-Vertragslösung nennen. Sie ist aus der in diesem Beitrag beschriebenen Arbeit hervorgegangen und wurde von Grund auf neu konzipiert. Mit IOTA Smart Contracts wollen wir eine Vision für intelligente Verträge verfolgen, die skalierbar sind und niedrige Transaktionskosten haben.

Wir arbeiten derzeit an einer Alpha-Version von IOTA Smart Contracts durch die GoShimmer-Implementierung, und wir werden in Kürze weitere Informationen über diesen neuen Weg veröffentlichen. Wenn die Alpha-Version fertig ist, wird sie von einer Reihe einfacher intelligenter Vertrags-PoCs begleitet werden, um Gemeinschaftsentwickler auf den Weg zu bringen und zu demonstrieren, was möglich ist, um eine neue Ära von Anwendungen auf der Grundlage von IOTA anzustoßen.

Fühlen Sie sich frei, unser Ingenieursteam direkt in den Smart Contract-Kanälen über den IOTA-Discord zu erreichen und Fragen zu diesem neuen Weg, den wir beschreiten, zu stellen.

Spenden: OOXKDDPERSTNHSCQGYDYEWGDRLQEUZCIBDLYCDKSKIHGWAG9WFPVDVSRAUN9GDUOJ9INP9LMSMHYKNLNCOKMGFBZFA