Dash Roadmap

Finanzielle Freiheit, basierend auf Masternodes

Dash wurde von Evan Duffield mit dem einzigartigen X11 Hashing Algorithmus ausgestattet und die ersten Entwicklungen fokussierten sich auf die dynamische Schwierigkeitsanpassung beim Mining, welche Dark Gravity Wave genannt wird. Bald darauf folgten die Masternodes, die ein leistungsfähiges und anreizreiches Set von vollständigen Nodes bereitstellten, die das Rückgrat des Netzwerks bilden und den Nutzern Dienste anbieten. Sporks wurden veröffentlicht, um einen reibungslosen Release-Prozess für neue Funktionen zu ermöglichen, ohne das Netzwerk zu hardforken, und schließlich wurde PrivateSend veröffentlicht, um Dash zu einer wirklich fungiblen Währung zu machen.

Ein Fundament für die Zukunft errichten

Auch wenn es anfangs auf Litecoin basierte, wechselte Dash doch Anfang 2015 auf die Bitcoin-Codebase. Wenig später wurde InstantSend veröffentlicht, dabei wird eine Transaktion sehr schnell durch die zweite Ebene des Netzwerks, die Masternodes, abgesichert. Im weiteren Verlauf des Jahres wurde auch die Arbeit an dem dezentralisierten Governance System abgeschlossen, wobei 10% der Block Rewards an Proposals, die dem Netzwerk vorgeschlagen wurden, ausbezahlt wird. Der erste Superblock wurde am 7. September 2015 von einem Miner gefunden, weswegen Dash als die erste Dezentralisierte Autonome Organisation (DAO) gelten kann.

Blockgröße und Hashrate wachsen an

Binnen 24 Stunden beendete das Netzwerk eine historische Abstimmung, bei der ein Konsens erzielt wurde, der die Entwickler dazu autorisierte, sich mit der Entwicklung von 2MB-Blöcken zu befassen, wodurch eine zukunftsfähige Skalierbarkeit garantiert werden soll. In der gleichen Zeit wuchs auch die Hashrate rasant an, da leistungsstarke Mining-Hardware herausgebracht wurde, wodurch die Hashrate sich im Laufe des Jahres auf das 16-fache erhöhte. Die Führung des Core-Teams erlebte dabei eine weitere Professionalisierung sowie die Implementierung von qualitätssichernden Maßnahmen. Bitcore und Insight wurden um Dash-Extensions erweitert, welche auf einem vom Netzwerk finanzierten Projekt zur Portierung des X11-Hashing-Algorithmus auf JavaScript aufbauen.

Stabilität, Dezentralität und Zugänglichkeit

Im Jahr 2017 integrierten wichtige Hardware Wallets Dash und zwei Veröffentlichungen zur Verbesserung von PrivateSend kamen heraus, wobei auch die Verwaltung von Governance-Objekten durch die Veröffentlichung des Sentinel-Tools vereinfacht wurde. Daneben wurden die Gebühren für alle Transaktionen um den Faktor 10 gesenkt und die Dash Core Group in einen unkündbaren Trust überführt, dessen Begünstigter das dezentrale Netzwerk selbst ist.

Benannte Devnets

Benannte Devnets erlauben die Schaffung mehrerer unabhängiger Devnets. Jedes davon wird unter einem eigenen Namen gestartet, der in den „Devnet Genesis“ Block eingeschrieben wird, welcher automatisch auf Höhe 1 platziert wird.

Verbesserung des Governance Systems

Seit 0.12.2.x werden keine Watchdogs mehr verwendet, stattdessen sind alle erforderlichen Informationen über Sentinel in den Masternode Pings enthalten. Bei diesem Update wurden Zusatzinformationen ergänzt, die sicherstellen sollen, dass die Masternode-Pings nicht durch eine zwischengeschaltete Node modifiziert werden können. Sämtliche Meldungen und Logiken, die sich auf Watchdogs beziehen, wurden daher gelöscht. Es wurden außerdem Formatsverbesserungen in Bezug auf Angebotsnachrichten und das Validieren/Verarbeiten von Angeboten durchgeführt. Hierdurch konnte die Auslastung des Netzwerks und der CPU gesenkt werden. Schlussendlich wurde auch die Handhabung von Triggern verbessert.

PrivateSend-Verbesserungen

PrivateSend-Sicherheitszahlungen müssen nicht mehr das N-fache der PrivateSend-Gebühr betragen. Stattdessen kann nun jeder Input, der größer oder gleich einer PrivateSend-Gebühr (aber kleiner oder gleich 4) ist, als Sicherheitszahlung genutzt werden. Alle Inputs, die größer oder gleich einer und kleiner als zwei PrivateSend-Gebühren sind, dienen als Sicherheitszahlungen für OP_RETURN-Ausgaben. Dies reduziert die Inputzahl, welche die Wallet handhaben muss, und erhöht die Privatsphäre, da der Benutzer nicht mehr versehentlich kleinere Inputs, die nicht privat sind, zusammenführt. Zudem verringerte sich die globale UTXO-Satzgröße durch dieses Update.

Neues Dash Branding

Die Android- und iOS-Versionen der Dash Wallet wurden gemäß der neuen Branding-Richtlinien überarbeitet und das Erscheinungsbild der beiden Apps wurde modernisiert.

Uphold-Integration (Android)

Außerdem wurde die Möglichkeit integriert, Dash auf Uphold über die Android-App zu kaufen und zu verkaufen, wodurch die Einbindung neuer Benutzer vereinfacht wird.

NFC-Support (iOS)

Durch die Möglichkeit, eine Zahlung über NFC zu veranlassen, können Benutzer nun auch auf bestimmte Zahlungsterminals und Wallets zugreifen, damit sie die Zahlungsinformationen einsehen können.

iPad-Support (iOS)

Mit dem iPad ist es nun möglich, die Dash Wallet zu benutzen, sodass die Benutzer Zahlungen auch auf ihren Tablets tätigen und erhalten können.

Neue Lokalisierungen

Zahlreiche neue Sprachen und Währungen wurden ergänzt, damit Benutzer weltweit die Dash Wallet in ihrer Muttersprache benutzen können und dabei den jeweiligen Wechselkurs in ihrer Landeswährung erfahren.

Automatisches InstantSend

Ab Dash Core v0.13 ermöglicht Dash automatisches InstantSend, wodurch alle Transaktionen mit vier oder weniger Inputs automatisch per InstantSend versendet werden, ohne dass dem Nutzer zusätzliche Kosten entstehen würden.

Deterministische Masternode Listen

Die Deterministische Masternode Listen liefern eine einheitliche Datenquelle für alle Transaktionen, die von den Masternodes validiert werden müssen, wie z.B. InstantSend-Transaktionen. Diese Liste stammt vollständig aus On-Chain-Daten. Auf diese Weise wird sichergestellt, dass alle Teilnehmer zum gleichen Konsens über die aktuelle Zusammensetzung der gültigen Masternodeliste kommen.

Spezielle Transaktionen

Spezielle Transaktionen für die Schaffung neuer Strukturen, um Transaktionen auf der Blockchain zu ermöglichen, die nicht finanzieller Natur sind. Mit dieser Funktion wird die Grundlage für die zukünftige Nutzung der zweiten Netzwerksebene geschaffen, wie dies beispielsweise für Blockchain-Benutzer notwendig ist.

Drei Masternode-Keys

Bisher gab es zwei Schlüssel für die Masternode: Eigentümer (um den Besitz nachzuweisen) und Betreiber (zum Betrieb der Masternode und zur Abstimmung). Nun wurde der zweite Schlüssel aufgespalten in Betreiber und Wähler. Hierdurch kann der Masternode-Besitzer die Teilnahme an der Abstimmung delegieren, wenn er möchte.

Wallet mit Fingerabdruck entsperren

Benutzer können die Wallet nun mit ihrem Fingerabdruck entsperren, wodurch das Verwenden der Wallet reibungsloser wird.

iOS-Library Integration

Die Dash Wallet wurde in eine iOS-Library integriert, die sie mit der Dash Blockchain verbindet. Dies kann in Zukunft auch auf andere iOS-Clients übertragen werden.

InstantSend empfangen (iOS)

Die Dash Wallet kann nun bestätigen, ob eine empfangene Transaktion über InstantSend gesendet wurde.

Preisfindungsanpassung

Die iOS und die Android Wallet greifen nun beide auf die gleiche Quelle zu, wenn es darum geht, den Dash-Preis zu bestimmen.

Long Living Masternode Quoren

Bei den Long Living Masternode Quoren handelt es sich um Quoren, welche dem Netzwerk eine höhere Skalierbarkeit ermöglichen, da sie die Konsensfähigkeit steigern und das Spektrum der möglichen Einsatzzwecke des Netzwerks ausweiten. Diese Quoren verringern die Anzahl der Nachrichten, die für das Validieren der Transaktionen erforderlich sind, wodurch sie auch vermeiden, dass die einzelnen Nodes des Netzwerks alle Konsensusdaten speichern müssen, bevor eine Transaktion abgeschlossen ist. Je nachdem, welches Sicherheitsniveau für den jeweiligen Anwendungsfall erforderlich ist, können diese Quoren unterschiedlich umfangreich sein.

ChainLocks gegen 51%-Angriffe

Mit ChainLocks wird das Risiko eines 51%-Angriffs auf das Netzwerk erheblich reduziert. Ein Long Living Masternode Quorum kann einen Block signieren und dem Netzwerk dabei eine Nachricht übermitteln, in der angezeigt wird, dass die anderen Teilnehmer Blöcke auf gleicher Höhe ablehnen sollten, wenn diese nicht mit diesem Block übereinstimmen. Dies ermöglicht nicht nur eine schnelle und eindeutige Konsensfindung, es verhindert außerdem eine tiefe Reorganisation der Blockchain vor diesem Block.

Uphold-Integration (iOS)

Nutzer können Dash innerhalb der App von ihrem Uphold-Konto an ihre Wallet verschicken sowie Dash durch die integrierte Seitenansicht kaufen und verkaufen.

Verbesserung der Preisfindung

Verbesserungen wurden dahingehend unternommen, dass Umrechnungskurse mit anderen häufig verwendeten Dash-Anwendungen übereinstimmen.

DashCore v0.14 Unterstützung

Die Unterstützung von LLMQs und ChainLocks wurde in die Wallet integriert, wodurch Nutzer von einem höheren Grad an Sicherheit und einer sofortigen Wiederverwendbarkeit von Zahlungen profitieren können.

Öffentliches Testnet (“Evonet”)

Dash-Plattform wird für ein öffentliches Testnet veröffentlicht, welches es Entwicklern erlaubt, mit den Funktionen zu experimentieren.

DAPI, Identitäten, Dokumente

Benutzer können über die Dezentralisierte API (DAPI) auf das Evonet zugreifen, Test-Identitäten und Namen erstellen sowie Dokumente erschaffen, aktualisieren und löschen.

Namensdienst und DashPay-Verträge

Benutzer erhalten die Möglichkeit den „Dash Platform Naming Service“ (DPNS) und DashPay-Verträge auszuprobieren.

Bibliotheken

Entwicklern stehen verschiedene Bibliotheken zur Verfügung, darunter Dash SDK, DAPI-client, DPNS-client und DPP-Bibliotheken.

Entwickler-Dokumentation

Ein Knotenpunkt für Entwickler soll hilfreiche Dokumentationen und Anleitungen zu den Funktionen anbieten.

Einheitliches Interface für Android und iOS

Um ein einheitliches Benutzererlebnis zu vermitteln, wird die Oberfläche der Dash Wallets für Android und iOS aneinander angeglichen.

Dunkler Modus für iOS unterstützt

Die DashWallet für iOS führt einen Dark Mode ein, der an die Richtlinien von Apple angepasst ist.

Erweiterte Sicherheitseinstellungen

In Zukunft werden Nutzer ihre Sicherheitseinstellungen flexibler anpassen können.

Einfacher Zugriff auf häufig verwendete Funktionen

Nutzer sollen bereits vom Startbildschirm aus auf wichtige Funktionen zugreifen können.

Backports von Bitcoin v0.15.2

Diese Version aktualisiert Dash auf den Stand von Bitcoin v0.15.2, wodurch es von einer Reihe von Korrekturen und Optimierungen profitiert, die an Bitcoin in dieser Version vorgenommen wurden.

QT Wallet UI Update

Die Nutzer werden von der überarbeiteten Benutzeroberfläche der Desktop-Wallet profitieren, welche dem neuen Dash-Branding entspricht. Dies umfasst unter anderem aktualisierte Farben und Stile, die an den Styleguide angepasst sind, sowie die Entfernung unnötiger Komponenten zur Vereinfachung der Benutzeroberfläche und daneben auch neue Symbole.

Verbesserungen nach dem Stresstest

Zu dieser Version gehören auch mehrere Optimierungen, die aufgrund der Erkenntnisse aus den jüngsten Stresstests durchgeführt werden konnten.

BIP70 Verbesserungen

Verbesserungen an der BIP70-Funktion ermöglichen ein effizienteres Zahlungserlebnis am Point-of-Sale. Nutzer/Händler, die dieses Protokoll implementieren, profitieren von Refund-Optionen sowie der Möglichkeit Zahlungen auf mehrere Adressen aufzuteilen und haben eine sicherere Erfahrung.

Blockreward Neuverteilung

Die Verteilung der Blockrewards – mit Ausnahme des Proposal-Fundings – zwischen Masternodes und Minern ändert sich im Verlauf eines mehrjährigen Prozesses von 50–50 zu 60–40.

UI-Verbesserung

Die Erfahrung mit Dash Core wurde auf allen unterstützten Betriebssystemen angepasst, im Bereich Schriftart, Grafiken und Bildschirmdesign.

Konzentrierte Signaturwiederherstellung

Das neue System zur Signaturwiederherstellung sendet die Teile der Signatur an eine einzelne, deterministisch ausgewählte Node, anstatt jeder Node so lange Anteile an einer Signatur zuzuweisen, bis ausreichend Daten für deren Wiederherstellung vorhanden sind. Diese Optimierung soll den Verbrauch um mehrere Größenordnungen senken.

Minimale Protokoll-Überprüfung

Proof of Service (PoSe) für Masternodes wurde verbessert, da nun eine Mindest-Protokollversion während DKG verwendet werden muss.

Netzwerk-Threadoptimisierung

Das Netzwerk-Threading wurde dadurch optimiert, dass unter Linux eine Ereignisabfrage (Event Polling, Epoll) implementiert wurde, um unnötige Schleifenwiederholungen durch alle Nodes zu vermeiden.

Backports von Bitcoin v0.16

Diese Veröffentlichung beinhaltet über 650 Updates von Bitcoin v0.16 sowie manche Updates von Bitcoin v0.17.

Versionierung des Protokolls

Dies ermöglicht die problemlose Einführung von Änderungen, ohne dass Entwicklungsnetzwerke gelöscht werden müssen.

Platformm-Testsuite

Die Platform-Testsuite ist ein Repo , das zusammengeführte Tests zu Platform beinhaltet, welche das Testen und das Aktualisieren von Tests für alle Komponenten vereinfacht.

Binäre Dokumentenfelder

Erlaubt es Entwicklern native Binärtypen (z.B. Buffer, ByteArray) zum Speichern ihrer Daten zu verwenden.

Dokumenten-Zeitstempel

Die Möglichkeit die Erstellungs- und Update-Zeit jedes Dokumentes auf Dash Platform aufzuzeichnen.

Verbessertes Verteilungspaket

Unterstützung von Config-Templating und mehrer Nodes für mn-bootstrap.

Standard Dash-Identitätsname

Erlaubt es Benutzern einen primären Benutzernamen für ihre Dash-Identität zu spezifizieren.

DPNS & DIPS Identität

DIP11 Identities und DIP12 Dash Platform Name Service wurden veröffentlicht.

Verbesserung des Startbildschirms

Die Reiter zum Senden und Empfungen wurden entfernt, damit mehr Platz geschaffen und die Doppelung durch den Shortcut entfernt wird.

Kleinere Bildschirm-Verbesserungen

Die Bezeichnungen wurden gekürzt und/oder neu formatiert, um eine Überschneidung mit anderen Komponenten der Benutzeroberfläche auf kleineren Bildschirmen zu verhindern.

Verbesserung der Wiederherstellungsphrase

Ein Zurück-Button wurde hinzugefügt, nicht-englische Phrasen wurden implementiert und der Warnhinweis wurde aktualisiert.

Verbesserung der Chain-Sync (iOS)

Viele Fixes und Änderungen am Core Data Design, den Masternodes und dem Herunterladen der Quorum-Listen.

Das DashPay Alpha Programm bringt die Community mit dem Test der DashPay Wallet auf dem Evonet in Kontakt.

Benutzernamen

Benutzer haben die Möglichkeit, sich selbst über das Netzwerk zu registrieren und ihre personalisierten Benutzernamen mit anderen Dash-Nutzern zu teilen.

Benutzerprofile

Benutzer haben die Möglichkeit ihre Nutzernamen durch einen Anzeigenamen, ein Bild und eine Beschreibung identifizierbarer zu gestalten.

Mit Kontakten verknüpfen

Benutzer können eine Kontaktanfrage an andere Benutzernamen senden und eine Liste der Personen erstellen, mit denen sie interagieren wollen.

Zahlungen an Nutzernamen durchführen und von diesen erhalten

Benutzer können Dash mit Freunden, Familienangehörigen und Geschäften per Nutzername oder per kryptografischer Adresse austauschen.

Verbesserung der Binary-Datenspeicherung

Verbesserungen zur Anzeige von Binärdaten als Byte-Arrays anstelle von Strings, wodurch die Daten effizienter gespeichert werden können. Das JSON Schema wurde zudem um das „byteArray“-Schlüsselwort erweitert, wodurch Entwickler einfacher binäre Eigenschaften in ihren Data Contracts definieren können.

Konsensregeln für Identitäten

Mehrere Änderungen wurden an der zugrundeliegenden Struktur einer Identität innerhalb von Dash Platform vollzogen

Nicht-Determinismus in der Block-Verarbeitung

Dies war ein bekannter Bug, der Entwickler davon abhielt, erfolgreich eine Node auf dem Evonet zu starken.

Core Height Konsens

Konsens zwischen den L1 und L2 Ketten basierend auf der Höhe von L1 etablieren.

Instant Send Identitäts-Finanzierung

Dies erlaubt die Finanzierung von Identitäten mit der Geschwindigkeit von InstantSend.

Status-Bäume

Speicherung von Daten-Zuständen in Hash-Bäumen für die Verwendung von Light Clients.

Verteilungspaket zu Platform

Das Distributionspaket (dashman f.k.a. mn-bootstrap) wurde aktualisiert, um die Benutzerfreundlichkeit zu verbessern und neue Plattformkomponenten zu integrieren.

Identitätsfinanzierung

Die Möglichkeit Identitäten zu finanzieren, ohne der Gefahr eines Double Spends ausgesetzt zu sein.

Verbesserung der Chain-Sync (iOS)

Der Prozess der Kettensynchronisation wurde weiter verbessert, sodass Verzögerungen beim Senden von Zahlungen vermieden werden können.

Vergessene Wiederherstellungsphrase (iOS)

Verbesserungen wurden vorgenommen, um Benutzern, welche ein oder zwei Wörter ihrer Wiederherstellungsphrase vergessen haben, den Versuch zu ermöglichen, ihre Wallet wiederherzustellen.

Bug Fixes & UI-Verbesserungen (Android)

Die mit dem Vergessen der PIN verbundene Benutzeroberfläche wurde implementiert, es wurden Updates zur Unterstützung eines neueren Android-SDK (29) durchgeführt und Abstürze im Zusammenhang mit dem Sichern als Datei und dem Importieren eines privaten Schlüssels wurden behoben.

Tendermint Seed Nodes

Eine besondere Art von Node, die Peer-Informationen an andere Nodes überträgt, um die Skalierbarkeit zu verbessern.

Sichere ST Bestätigung

Verbesserungen, um verschiedene mögliche Angriffsvektoren zu beseitigen und um die Skalierbarkeit des Mainnet zu gewährleisten.

Drive Verbose Logging

Für bessere Transparenz und Fehlerbehebung des Drive-Verhaltens wurden mehr Logs hinzugefügt.

Verbesserte Fehlermeldungen

Lesbare und informative Nachrichten zur richtigen Fehlerbehebung.

UI-Verbesserungen & Aufarbeitung

• Verbesserung: Upgrade zum Testnet (Platform v0.17)
• Verbesserung: Suche Nutzer im Netzwerk
• Verbesserung: Android / iOS UI Anpassung
• Verbesserung: Validierung des Benutzernamens
• Verbesserung: Speichere Profil-Erinnerung
• Verbesserung: Schlechte Masternodes
• Verbesserung: Format der Benutzernamen (erlaube Großschreibung und Bindestriche)
• Fix: Wallet Lock Timer
• Fix: Inkorrekter Sync Status
• Fix: Sync- & Absturz-Probleme
• Fix: Importiere Privaten Schlüssel

Quoren mit 100 Mitgliedern

Neue Quoren-Größe, um Sondertransaktionen zur Sperre von Vermögenswerten zu unterstützen.

RPC-Beschränkungen für Plattform

Sicherheits-Verbesserungen, wenn Core mit Platform interagiert.

Bitcoin v0.17+ Backports

Über 500 Backports von Bitcoin Core.

Finanzierung von Identitäten mit ChainLocks

Der zweite Teil des Funding-Designs für Identitäten, das ChainLock-Proofs beinhaltet, wurde implementiert, um Client-Proofs zu unterstützen.

Funktionsflaggen

Deterministisch spezifizierte Logik wurde im Netzwerk aktiviert, um Bug Fixes und neue Funktionen zu erlauben, ohne bestehende Daten zu löschen.

Lokales Netzwerk Installation / Umgebung

Die lokale mn-bootstrap Node bietet keine Unterstützung für ChainLocks und InstantLocks, weswegen wir einen Fallback während der Entwicklung und im CI implementieren mussten.

Signaturen mit Core verifizieren

Um eine doppelte Logik und doppelte Daten zu vermeiden, sollte Core verwendet werden, da diese Logik dort bereits implementiert wurde und daher auch sämtliche erforderlichen Daten vorhanden sind.

Insight API entfernt

Insight wurde als Abhängigkeit entfernt und diese Funktionalität auf DAPI übertragen, wodurch eine bessere Stabilität erreicht und Redundanzen beseitigt wurden.

DashMate Veröffentlichung

Wir arbeiten kontinuierlich an der Verbesserung des Dash Platform Distributionspakets (früher bekannt als mn-bootstrap), um es noch bequemer und zuverlässiger zu machen. Ab dieser Version betrachten wir es als so ausgereift, dass wir ihm einen schönen Namen geben und dich ermutigen, es für den Betrieb von Testnet Fullnodes und Masternodes zu verwenden.

CI verbessert

Die langsamen Builds und der Mangel an verfügbaren Funktionen in Travis CI haben den Entwicklungsprozess erheblich verlangsamt. Daher sind wir auf Github Actions umgestiegen und haben einige Caching-Tricks implementiert. Mit den neuen CI-Builds sind wir viel flexibler und können bis zu 10 Mal schneller arbeiten.

Validatoren-Set Rotation

Damit der Konsens auf der Platform Blockchain zustande kommt, werden die Blöcke von einer bestimmten Gruppe von Masternodes, den Validatoren, überprüft und signiert. Bis einschließlich Version 0.19 war die Gruppe der Validatoren statisch und wurde auf Nodes gehostet, die von DCG kontrolliert wurden. Mit Version 0.20 werden Long-living Masternode Quorums (LLMQ) eingesetzt, um den Validatorensatz dynamisch auf alle Masternodes zu verteilen und zu rotieren. Dadurch wird die Last gleichmäßig verteilt und das Netzwerk wird viel sicherer und zuverlässiger.

Kryptografische Nachweise

In der Vergangenheit mussten die Kunden die Gültigkeit und Integrität der aus dem Plattformnetzwerk abgerufenen Daten über zuverlässige Full Nodes sicherstellen. DAPI bietet nun neben den Plattformdaten auch effiziente kryptografische Beweise, die es Light-Clients (z. B. mobilen Wallets) ermöglichen, sicher mit Dash Platform zu interagieren.

Platform Status Schwellenwert Signieren

Die Validatoren verwendeten bisher nicht aggregierte EdDSA-Signaturen des kryptografischen Prüfwerts des Plattformstatus, um kryptografische Beweise zu erbringen und den Netzwerkkonsens zu garantieren. Die Anzahl und Gesamtgröße dieser Signaturen machte die Verwendung von Beweisen für Light Clients ressourcenintensiv. Ab Version 0.20 wird der BLS-Schwellenwert-Signaturmechanismus verwendet, um nur noch eine Signatur zu erstellen, welche mobile Wallets und andere Light-Clients leicht verifizieren können.

Optimierung der Peer-to-Peer-Ebene

Sowohl die Fullnodes als auch die Validatoren haben sich bisher auf alle Arten von P2P-Nachrichten verlassen und diese überprüft. Folglich erhielten die Fullnodes auch Netzwerkdaten, die Nachrichten enthielten, die nur für die Validatoren relevant waren, um einen Konsens zu erreichen. Mit der neuen Version erhalten die Fullnodes keine Konsensnachrichten mehr, die von den Validatoren erstellt wurden. Die Validatoren erstellen stattdessen nur noch eine Nachricht mit einer BLS-Schwellenwertsignatur, um die resultierende Konsensentscheidung an den Rest des Netzwerks weiterzugeben. Auf diese Weise wird die Netzwerklast stark reduziert, da nicht mehr so viele Nachrichten an die Fullnodes weitergeleitet werden müssen, wodurch die Bandbreite um 99,5 % reduziert wird.

Platform Metadata

Dash Platform ergänzt nun die DAPI-Antworten um zusätzliche Metadaten, wie z.B. die aktuelle Höhe der Platform Blockchain sowie die synchronisierte Höhe der Core Blockchain, die von allen am Netzwerkkonsens beteiligten Nodes beobachtet und vereinbart wurde. Da die Platform Blockchain und die Core Blockchain asynchron sind, verwendet die Plattform die Core Blockchain, um sicherzustellen, dass alle Nodes der Plattform einen deterministischen Überblick über den Zustand des Core Netzwerks haben.

Strikte und sichere Data Contract Validierung

Die neue Version des Dash Platform Protocol aktualisiert die JSON-Schema-Spezifikation, die zur Definition von Data Contracts verwendet wird, auf die neueste Version 2020-12 und verwendet strenge Validierungsregeln, um mögliche Benutzerfehler in den an das Netzwerk übermittelten Data Contracts zu verhindern. Eine spezielle Engine für reguläre Ausdrücke wird außerdem eingesetzt, um ReDoS-Angriffe zu verhindern.

Stabile JS-Wallet-Synchronisation

In älteren Versionen der JS Wallet-Bibliothek wurden während der Synchronisierung nicht immer alle angeforderten Transaktionen und Instantlock-Nachrichten von DAPI empfangen. Dieses Problem wurde in Version 0.20 behoben.

Dashmate-Verbesserungen

In der aktuellen Version von Dashmate sind 20 Korrekturen und Verbesserungen enthalten. Zu den wichtigsten gehören das komfortablere und zuverlässigere Einrichten lokaler Entwicklungsnetzwerke, Leistungsverbesserungen und Windows-Unterstützung.

Liquid Exchange Integration (Android)

Integration der Liquid Quick Exchange in die Dashpay-Wallet, um Dash-Käufe über Visa-Kreditkarten zu ermöglichen.

BIP70 Verbesserungen

Optimierung der Deep Link UX, damit ein nahtloser Dialog zwischen der neuen DashDirect App und anderen Apps, die dieses Protokoll nutzen, möglich ist.

BIP69 implementiert

Dadurch wird ein gängiger Standard für die Organisation von Ein- und Ausgaben erreicht, der eine bessere Anonymität ermöglicht.

Verbesserungen der Passphrase

Verbesserungen an der Benutzeroberfläche, um den Nutzern die Bedeutung ihrer Passphrase zu verdeutlichen und zu verhindern, dass sie Screenshots von ihrer Phrase machen.

Verbesserungen bei der Chainsynchronisation

Verbesserungen an der Benutzeroberfläche des Status und Backend-Änderungen, um die Leistung der Synchronisierung zu verbessern.

Wartung

Verbesserungen im Zusammenhang mit Uphold, der Fingerabdruck-Authentifizierung, der UI-Navigation und der Auto-Logout-Funktion sowie Code-Refactoring in Vorbereitung auf das DashPay-Upgrade.

Verschicke Einladung

Damit deine Freunde und Verwandten einfacher dem Dash-Netzwerk beitreten können, sende ihnen eine Einladung, damit sie direkt einen Benutzernamen erstellen können.

Akzeptiere Einladung

Eine Einladung erlaubt es neuen Nutzern, die kein Dash besitzen, einen Benutzernamen direkt anzulegen, ohne zuerst Dash erwerben zu müssen.

Verbesserte Fehlermeldungen

Einführung von Fehlercodes und anschaulicheren Meldungen, sodass Client-Anwendungen die Fehler besser handhaben können und damit Bugs schneller untersucht werden können.

Aufbau einer robusten Baumstruktur

Wir speichern den Status derzeit in verschiedenen Merk Trees, was einen gewissen Overhead für Speicher und Festplatte bedeutet. Dies erfordert außerdem eine sehr komplexe Logik, um Atomarität zu gewährleisten und datenbankübergreifende Transaktionen zu verarbeiten, die nicht implementiert sind. Ein neues, robusteres und sichereres State-Tree-Design wird dazu entwickelt.

Dokument zur Gestaltung sekundärer Indizes

Im Rahmen des neuen State-Tree-Designs wird MongoDB ersetzt.

Testnet Nodes verteilt

Das Testnet wird um Nodes in verschiedenen Rechenzentren erweitert, sodass reale Probleme mit Latenz und Leistung simuliert werden können, die sich auf die Skalierung auswirken könnten.

Upgrade-Verfahren

Dank eines verbesserten Upgrade-Prozesses müssen die L2-Daten nicht mehr gelöscht werden, wodurch ein sicherer Übergang zwischen den Protokollversionen möglich ist.

GroveDB Erstveröffentlichung

Es ist die erste Datenbank ihrer Art, die auf einer hierarchischen authentifizierten Datenstruktur (HADS) basiert und auf einem innovativen beweisbaren Datenspeichersystem beruht. Auf diese Weise werden Funktionen ermöglicht, die mit keiner anderen derzeit existierenden Datenbank möglich sind. In der ersten Version werden sekundäre Indizes angeboten und die Integrität der gespeicherten Inhalte wird kryptografisch nachgewiesen.

Data Contracts können aktualisiert werden

Dadurch können die Vertragsschemata geändert werden, ohne dass Daten verloren gehen oder ein neuer Vertrag erstellt werden muss. Darin unterscheidet sich Dash deutlich von Smart Contract Netzwerken, die diese Möglichkeit nicht haben.

Masternode Identitäten

Sobald eine Masternode über eine Dash-Identität mit einem Guthaben verfügt, kann der Masternode-Besitzer Belohnungen für seine Teilnahme am Konsens der Plattform erhalten. Auf diese Weise entsteht eine zusätzliche Einnahmequelle für die Besitzer von Masternodes.

Identitätsschlüssel für Aufgaben und Sicherheitsstufen

Die Funktionen der Dash Platform werden verschiedene Sicherheitsstufen erfordern. Für den Verkauf eines sehr wertvollen digitalen Vermögenswerts sollte eine sehr hohe Sicherheitsstufe erforderlich sein, für das Veröffentlichen von Katzenbildern wahrscheinlich nicht. Durch diese Funktion können die Nutzer die höchsten Sicherheitsstufen in ihrer Hardware Wallet aufbewahren und weniger sensible Aktionen direkt von ihrem Smartphone aus durchführen.

Multi-Package Repositorium

Zur Beschleunigung des Entwicklungs- und Build-Prozesses wurde der Code der Plattformkomponenten von eigenständigen Repositories in ein Multi-Package-Repository migriert. Dank dieses Mono-Repository-Ansatzes werden Routinearbeiten, die während der Entwicklung durchgeführt werden müssen, signifikant reduziert.

Quorum Rotation, stärkere IS-Sicherheit

Die Verteilung der Quorum-Last auf die Masternodes wird verbessert und gleichzeitig die Sicherheit von InstantSend erhöht. Erreicht wird dies dadurch, dass bei der Auswahl der Quorum-Mitglieder nur eine Teilmenge der Masternodes in einem Quorum geändert wird und gleichzeitig die Anzahl der Quoren begrenzt wird, für die jede Node auf einmal ausgewählt wird.

Proposal Fee Reduzierung

Die Proposalgebühr wurde von 5 DASH auf 1 DASH gesenkt, um das Governance-System zugänglicher zu machen. Diese Änderung geht auf ein von den Masternodes genehmigtes Proposal zurück.

Neue QT Governance UI hinzugefügt

Die Registerkarte „Governance“ wurde hinzugefügt, damit Dash Core Qt-Nutzer einfacher auf die Details von Governance Proposals zugreifen können.

Erste Enhanced Hard Forking Implementierung

Eine neue Spezialtransaktion und Aspekte von DIP23 wurden implementiert, die notwendig sind, um den erweiterten Hard-Fork-Mechanismus zu unterstützen, welcher in der nächsten Version von Dash Core veröffentlicht wird.

Deterministische InstantSend Locks

Einführung von deterministisch verifizierbaren InstantSend Locks (DIP22) zur besseren Unterstützung des Platform Identity Systems. Auf diese Weise können InstantSend-Transaktionen in der Zukunft komplett verifiziert werden und nicht nur vorübergehend.

BTC v0.18/v0.19/v0.20 Backports

Die Zahl der abgeschlossenen Backports für Bitcoin Core v0.18 stieg von 83% auf 86% und für v0.19 von 41% auf 53%. Außerdem wurden 18% bzw. 10% der Backports für v0.21 und v0.22 fertiggestellt.

Externe Sicherheitsüberprüfung

Die Dash Core Group hat eine professionelle Prüfungsfirma offiziell mit der Durchführung einer Sicherheitsüberprüfung der Core Codebasis beauftragt.

Möglichkeit zur Aktualisierung der Identität (siehe DIP11)

Beseitigung der funktionalen Lücke in den Spezifikationen von DIP0011. Dies beinhaltet die Implementierung einer Identitäts-Update-State Transition, der Einführung von Identitäts-Public Key-Sicherheitsverbesserungen, zusätzliche Funktionen für Platform Credit-Entnahmen und die Durchführung eines Indentität-Key-Eigentümer-Beweises.

Berechnung der anfänglichen Speichergebühr

Ein anreizschaffendes Gebührenmodell, das die Masternodes für die Verarbeitungs- und Speicherkosten entschädigt und gleichzeitig Spam verhindert. Die Implementierung des neuen Gebührenberechnungssystems basiert auf den Operationen, die für die Verarbeitung von Zustandsübergängen erforderlich sind, und auf der Datenmenge, die im Masternode-Netzwerk gespeichert wird. Obwohl die Berechnung der Speichergebühren mit dem neuen Modell präzise ist, sind die Bearbeitungsgebühren noch verbesserungswürdig. In der nächsten Version werden auch Gebührenerstattungen für das Löschen von Daten eingeführt.

State Transition-Gebührenverteilung

Ein System, bei dem die Platform-Gebühren in Pools gesammelt und im Laufe der Zeit an die Masternodes verteilt werden. Dieses Design bietet den Masternodes einen Anreiz, das Hosting fortzusetzen und zu vermeiden, dass ihr Node offline geht. State Transition-Speichergebühren werden für die nächsten 50 Jahre jede Epoche (~18 Tage) verteilt. Wenn eine neue Epoche beginnt, erhalten Masternodes die Rewards für das Erbringen von Dienstleistung in der vorhergehenden Epoche.

Platform Creditguthaben in Dash auszahlen

Platform Credits können in Dash umgetauscht werden. Die Masternodes können sich ihre Platform Rewards einfach auszahlen lassen.

Headers First Synchronisierung

erbesserte Sicherheit und Zuverlässigkeit bei der Chain-Synchronisation in Dash JS Wallet. JS Wallet wird ein echter SPV Client, der eine vollständige Blockchain-Synchronisierung und -verifizierung durchführt. Dabei werden zufällig ausgewählte Masternodes bestimmt, die die angeforderten Blockchain-Daten ausgeben ausgeben müssen.

Dash Platform Bench Suite

Um die Leistung der Platform-Komponenten zu messen, wird in dieser Version ein Benchmark-Tool eingeführt. Dieses Tool ist tief in die Blockchain-Laufzeit von Platform integriert und bietet Entwicklern bequeme Instrumente zum Experimentieren und Verfolgen der Leistung im Laufe der Zeit.

Dash Platform Protocol in Rust

Die Portierung von DPP zu Rust macht es sicherer und leistungsfähiger. Außerdem wird die Blockverarbeitung dadurch beschleunigt. Zum Integrieren von Rust DPP in JS-Komponenten, stellen wir WASM DPP bereit. Dies ist der erste Schritt in Richtung Portierung von Platform zu Rust. JS war gut zum Experimentieren und zur Erstellung von Prototypen, aber jetzt brauchen wir etwas Nachhaltigeres.

Ausführung im gleichen Block

Eine Einschränkung, die vom Tendermint-Projekt übernommen wurde, von dem unsere Konsens-Engine ursprünglich stammt: Blocksignaturen würden nur den Zustand des vorherigen Blocks sowie alle Zustandsübergänge des aktuellen Blocks signieren. Um bewährte Daten von der DAPI zu erhalten, müsste man also auf die nächste Block-Einbindung warten. Dies war mit dem von uns angestrebten Beweissystem und Speichersystem nicht vereinbar. Durch diese Verbesserung wird auch die Belastung des Netzwerkes erheblich verringert und die für die Eingabe von Daten in Dash Platform erforderliche Zeit verkürzt, was ein besseres Nutzungserlebnis zur Folge hat.

Platform Credit-Abhebungen

Derzeit kann man Dash in Platform Credits umwandeln indem man eine Identität erstellt oder diese auflädt. Platform Credits werden hauptsächlich für die Bezahlung von State Transition-Gebühren genutzt. Masternodes erhalten ihre Rewards für das hosten von Platform in Credits (Block Rewards und ST Fees). Auszahlungen erlauben es Masternodes und anderen Identitäten, Platform Credits wieder in Dash umzuwandeln.

Effiziente Datenserialisierung

Das Dash Platform Protokoll (DPP) verwendete bisher den CBOR- Kodierungsmechanismus, der eine schemalose Datenserialisierung implementiert. Da alle Daten in Platform in vordefinierten Strukturen gespeichert werden, ist es nicht erforderlich, auch Strukturinformationen zu speichern. Indem nur Werte gespeichert werden, wird die Größe der serialisierten Objekte drastisch reduziert.

Gebührenerstattungen

Wenn ein Nutzer Dash Platform Daten hinzufügt, zahlt er für die dauerhafte Speicherung. Allerdings müssen nicht alle in Platform gespeicherten Daten dauerhaft sein. Benutzer können in Datenverträgen (Data Contracts) festlegen, dass Dokumente aktualisiert oder entfernt werden können. Die Einführung der Gebührenerstattung ermöglicht es den Nutzern, Platform Credits zurückzuerhalten, wenn sie Daten löschen.

Identität v2

Eine Identität besteht aus verschiedenen Daten wie dem Kontostand und einer Sammlung von Public Keys, die für verschiedene Zwecke und Sicherheitsstufen verwendet werden. Die Implementierung der neuen Identitäts-Speicherung ermöglicht das Aktualisieren oder Abrufen von nur bestimmten oder mehreren Teilen der Identität. Dies reduziert State Transition-Gebühren und die Belastung des Netzwerkes.

Verifizierung aller Platform-Credits

Eine neue GroveDB-Funktion für Summenbäume ermöglichte es uns, einen Schutzmechanismus gegen inflationäre Fehler in der Blockchain zu implementieren. Diese Funktion fügte den Nodes eines bestimmten Typs von Merkle-AVL tree Summen hinzu. In diesem Baum enthalten die Root-Nodes die Summe aller ganzzahligen Werte im Baum. Jedes Mal, wenn in einem Summenbaum ein Wert hinzugefügt, entfernt oder aktualisiert wird, wird jeder übergeordnete Node und damit der „Summenwert“ der Wurzel aktualisiert. Der Guthabenprüfungsmechanismus vergleicht jeden Block aller Guthaben im Speicher mit der erwarteten Menge an Guthaben im System. Dies verhindert inflationäre Angriffe, die neue Guthaben oder Token außerhalb des vordefinierten Vorrats minten würden.

Masternode-Wahlberechtigungen

Dies ist eine Komponente, die zukünftige Governance-Funktionen auf Platform ermöglicht.

Dezentralisierte API mit HTTPS

Ab dieser Version werden DAPI Requests via HTTPS bedient. Dies ermöglicht die Entwicklung von Browser-Anwendungen.

High Performance Masternodes (HPMN)

Ein High Performance Masternode ist eine neue Form von Masternode, welcher am Konsensus in der Dash Platform Chain und in der Dash Payment (Core) Chain teilnimmt. In diesem System würde der Standard-Masternode weiterhin nur die Dash Payment Chain bedienen. HPMN’s werden höhere Anforderungen als der Standard-Masternode haben, so zum Beispiel 4000 Dash als Sicherheit und höhere Leistungsspezifikationen, da sie zwei Chains betreiben anstatt eine.

BLS v1.0 Implementierung

Anpassung der BLS-Signaturbibliothek an das neue Signaturschema zur Angleichung der Standards und Verbesserung der Sicherheit.

Bitcoin v0.19/v0.20/v0.21/0.v22 backports

Backports from Bitcoin Core from BTC v0.19/v0.20/v0.21/v0.22.

Lösen von Problemen mit dem v19-Hardfork

Ein Ziel des v19-Hardfork war es, das Basic BLS-Schema zu aktivieren und es für verschiedene on On-Chain- und P2P-Nachrichten zu nutzen. Der Grund für diese Änderung ist die Notwendigkeit, sich an den IETF-Standards zu orientieren. Leider wurden einige Grenzfälle in unseren Funktionstests und unserem Testnet übersehen. Der v19-Aktivierungsverusch auf dem Mainnet traf auf einige dieser Grenzälle und das Mainnet hörte auf, Blöcke zu produzieren. Als Zwischenlösung wurde v19.1.0 veröffentlicht, was den Start zum Signalieren des v19-Hardforks bis zum 14. Juni verschob.

Um das Problem zu beheben, mussten wir die Art wie öffentliche BLS-Schlüssel gehandhabt werden überarbeiten. Dies betraf auch die Serialisierung in der internen Datenbank. Dies führte zu einer Inkompatibilität mit älteren Versionen von Dash Core. Daher wurde ein db-Migrationspfad für alle neueren Versionen implementiert.

Verbesserung der Migration und der Unterstützung von historischen Daten für Light Clients

Die Lösung für die v19-Hardfork-Probleme ebnete als Nebeneffekt den Weg, um die v19-Migration für mobile Wallets zu vereinfachen.

Bei der vorherigen Implementierung mussten mobile Wallets 4k+ Pubkeys ab Beginn des v19-Hardfork konvertieren und das kann leicht 10-15 Sekunden dauern, wenn nicht mehr. Auch nach dem v19-Hardfork, wenn eine Masternode-Liste von einem Block vor dem Hardfork angefordert wird, kamen die Betreiber-Schlüssel im Basic BLS-Schema, aber der merkleroot-Hash, der zu diesem Zeitpunkt in der Coinbase-Transaktion gespeichert war, wurde mit dem Legacy BLS-Schema berechnet. Daher war es unmöglich, den merkleroot-Hash zu überprüfen.

Um diese Problem zu lösen, wurde für jeden neuen Eintrag in die mnlistdiff-P2P-Nachricht ein neues Feld namens nVersion eingeführt. Diese Feld zeigt an, welches BLS-Schema (legacy oder basic) genutzt werden sollte, wenn eine Nachricht seriell-parallel umgewandelt wird. Die nVersion der mnlistdiff-Nachricht wird das Schema selbst nicht mehr angeben und muss immer auf 1 gesetzt werden.

Verbesserung des Mixing-Unterstützung für Light Clients

Die jüngsten Änderungen der dsq- und dstx-Nachrichten erlaubten mobilen Clients, die Masternode-Listen über mnlistdiff-Nachrichten erhalten, den Masternode zu diesen Nachrichten zu bestimmen, da proTxHash genutzt wurde anstatt masternodeOutpoint. Sobald der v19-Hardfork die dsq- und dstx-Signatur aktiviert, werden Nachrichten auf proTxHash basieren. Das sollte es für mobile Clients einfacher machen, diese zu verifzieren.

ChainLocks bleibt aktiviert, ohne dass neue Locks gesigned werden

Vor dieser Version waren ChainLocks entweder ein- oder ausgeschlatet. Ab dieser Version ist es nun möglich, SPORK_19_CHAINLOCKS_ENABLED auf einen Wert ungleich Null zu setzten und damit das Signing von neuen ChainLocks auszuschalten. Der bekannteste ChainLock wird dabei immer noch durchgesetzt.

Keine Person oder Organisation hat die Kontrolle, wann v19 aktiviert wird. Wenn eine bestimmte Anzahl von Masternode-Besitzern und Minern das Upgrade durchgeführt haben, wird die Aktivierung wirksam.

Masternode Block Rewards

Masternode Block Rewards werden zwischen normalen Masternodes and High-Performance Masternodes (HPMN) aufgeteilt. Die HPMN-Teil wird in Platform Credits angesammelt und dann über die Zeit zwischen Nodes aufgeteilt, um einen Anreiz zu schaffen Platform Dienste bereit zu stellen. Nodes erhalten ihre Rewards für jede Epoche (~18 Tage), wenn sie Dienstleistung erbringen (neue Platform-Blöcke einbringen).

Bearbeitungsgebühren und Anpassungen

Es handelt sich um die Hinzufügung weiterer begrenzter Bearbeitungsgebühren und die Anpassung/Überprüfung bestehender Zahlen, um sicherzustellen, dass alle Kosten angemessen gedeckt und die Gebühren richtig berechnet werden.

Protokoll-Upgrade

Testen und Verbessern von Protokoll-Upgrade-Prozessen zur Optimierung der Implementierung von Änderungen auf verschiedenen Systemebenen.

NFT Unterstützung

Vorbereitung von Dash Platform auf die Speicherung und Verwaltung von Nicht-Fungiblen Token. Sorge bei der Verwendung des Platform-Storage-Mechanismus dafür, dass die NFT-Daten auch in der Chain gespeichert werden können.

Geräteausstattung

Implementierung von Metriken für Platform-Komponenten, die für die Netzüberwachung erforderlich sind, einschließlich weiterer Belastungstests.

Interner Sicherheitstest

Sicherheitsexperimente und Tests durch DCG.

Belastungstests

Belastungstests werden mit einer Stresstest-Suite in einem speziellen Netzwerk durchgeführt

Erweiterung der Treasury

Vor DashCore v20.0 flossen 10% des Block-Rewards in die Dash Dao Treasury, mit der Entwickler und andere Aufwendungen für das Netzwerk bezahlt worden sind. Sobald der DashCore v.20.0 Hardfork aktiviert wird, steigt diese Zuteilung auf 20% des Blockrewards Proposal wurde im September bestätigt. Miner- und Masternode-Rewards werden auf 20% beziehungsweise 60% bei der Aktivierung der Änderung festgelegt.

Verwerfung des Sentinel

Sentinel Funktionalitäten wurden direkt in v20.0 integriert. Daher müssen Masternodes Sentinal Anwendungen nicht mehr als einzelne Anwendungen laufen lassen. Mehrere RPC-Kommandos wurden geupdated, um einen Konflikt zwischen DashCore v20.0 und existierenden Sentinel Installation zu verhindern. Es wird empfohlen, Sentinel zu entfernen oder zu deaktivieren nachdem auf ein Masternode auf v20.0 geupdatet wurde.

Sondertransaktionen zur Sperre von Vermögenswerten

Einführung einer neuen Art von Sondertransaktion (Asset Lock), welche zur Unterstützung der Finanzierung der Platform Identitäten dienen

Umverteilung der Masternode-Rewards

Der Hardfork für die Umverteilung der Masternode-Rewards (MN_RR), erstmals in Dash Core v20 enthalten, wird aktiviert, nachdem v21 von den Masternodes angenommen wird. Dieser Hardfork ermöglicht das Hauptfeature dieser Version: die Umverteilung der Masternode-Rewards. Die Aktivierung wird zudem die Dash Evolution Platform Chain starten.

Reward-Umverteilung und Evonode-Zahlungen

Sobald der MN_RR Hardfork aktiviert wird, wird ein Teil der Masternode Subsidy innerhalb der Coinbase in den Credit Pool bewegt, immer wenn ein Block gefunden wird. Evonodes werden ihr Vergütung einzeln pro Payment Cycle auf der Core Chain erhalten und nicht wie vorher bei v19/v20 nur nach 4 aufeinanderfolgenden Blocks. Der Rest der evonode-Zahlungen wird von der Plattform aus dem Kreditpool verteilt. Dies gibt einen Anreiz Evonodes auf Platform zu upgraden, da nur aktive Nodes diese Reward-Zahlungen erhalten.

Mainnet spork hardening

Dash führte 2014 Sporks ein, damit Hardforks reibungsloser vonstattengehen. Diese Innovation war zwar nützlich, aber das Netzwerk hat sich zu einem Punkt weiterentwickelt, dass das Mainnet nicht mehr auf diese angewiesen ist. Features wie Enhanced Hard Forkes (EHF) habe Sporks abgelöst. Daher erschwert diese Version die Anwendung von Sporks im Mainnet. Sporks bleiben bestehen im Dev- und Testnet. Im Mainnet wird jedoch der Wert aller Sporks auf 0 hardgecoded, mit einer Ausnahme (1 für SPORK_21_QUORUM_ALL_CONNECTED). Diese festgeschriebenen Werte stimmen mit den aktiven, historischen Werten im Mainnet überein. Die Funktionsfähigkeit des Netzwerkes ist nicht betroffen.

Dash Platform Pre-Mainnet Validierung

Verschiedene Netzwerkexperimente, Überarbeitung der Codebasis, Vorbereitungen und mögliche Fehlerbehebungen für die Veröffentlichung des Mainnet in enger Zusammenarbeit mit der Dash Community (Nutzung von Community-Projekten unter Verwendung von Dash Platform)

Start des Mainnet-Rollout

Der erste Mainnet-Rollout von Platform wird mit dem Rollout von Core v0.21 zusammengefasst. Das Dash-Netzwer wird dazu angehalten, das Upgrade so schnell wie möglich abschzuschließen.

Enhanced Harfork Resigning

Dieses Update löst ein Probem im Enhanced Hardfork (EHF) Resinging.
Masternodes konnten bisher nicht für einen EHF zurücktreten, wenn sie vorher in einem EHF Signing Quorum teilgenommen haben.. Infolgedessenkonnte der Schwellenwert für den Hardfork nicht erreicht werden.

Activation Readiness

Diese Versionen sollten eine erfolgreiche Aktivierung unter bestimmten Bedingungen, die beobachtet wurden, gewährleisten. Sie sind verpflichtend für alle Evonode-Betreiber. Im Gegensatz zu den anderen Aktivierungen wird diese Version aktiviert, sobald 67 geupgradete Evonodes ein Genesis Quorum bilden können

Dash Platform Aktivierung

Keine Person oder Organisation kann den exakten Zeitpunkt der Platform-Aktivierung bestimmen. Dafür muss eine bestimmte Anzahl von Evonode-Besitzern geupgradet haben.

DPNS

Wenn dieser Datenvertrag erstellt ist, können Nutzernamen im Netzwerk registriert werden.

DashPay

Wenn dieser Datenvertrag erstellt ist, können Nutzernamen Zahlungen im Netzwerk durchführen.

Erhalte mehrere Identitäts-Guthaben in einer Abfrage

Diese Version wird es dezentralisierten Apps (DAPPs) erlauben, einfacher mit mehreren Identitäten zu interagieren.

Auszahlungen

Dadurch können Besitzer von Masternodes ihre L2-Credits in Dash Rewards umwandeln lassen.

Versionshinweise

https://github.com/dashpay/platform/releases/tag/v1.5.0

Android DashPay Wallet

Mit der Veröffentlichung der DashPay-Wallet wird es vereinfacht beanspruchte und nicht beanspruchte Nutzernamen zu erstellen. Es wird möglich sein, Zahlungen via Nutzernamen durchzuführen und als Masternode-Besitzer über Nutzernamen abzustimmen.

Versionshinweise

https://github.com/dashpay/platform/releases/tag/v1.6.0

Versionshinweise

https://github.com/dashpay/platform/releases/tag/v1.7.0

Kompressierte Blockheader-Anfragen

Die maximale Anzahl der komprimierten Block-Header, die auf einmal angefordert werden können, wurde von 2.000 auf 8.000 erhöht. Es wird erwartet, dass diese Änderung die Blockchain-Synchronisationszeiten für Clients, die komprimierte Block-Header verwenden, verkürzt, da sie die Header schneller erhalten können.

DSQ-Nachricht

Um die Bandbreitennutzung zu verringern, wird die DSQ-Nachricht über das Inventarsystem verbreitet, anstatt an alle angeschlossenen Peers weitergegeben zu werden. Dies sollte zwar den Bandbreitenbedarf aller Nodes verringern, aber der Effekt wird bei stark verbundenen Masternodes am deutlichsten spürbar sein.

Platform Auszahlungen

Die Verarbeitung von Platform Auszahlungen wurde aktualisiert, um Auszahlungstransaktionen von mehr Platform Quorums zu akzeptieren. Zuvor wurden Transaktionen nur akzeptiert, wenn sie von einem der ersten beiden aktiven Quoren unterzeichnet waren. Mit dieser Änderung können Auszahlungen von jedem der gültigen Quoren unterzeichnet werden.

Onion Nodes

Um die Widerstandsfähigkeit gegen Zensur zu verbessern und die Risiken der Netzwerkpartitionierung zu mindern, sind die mit dem Onion-Netzwerk verbundenen Dash Core Nodes nun bestrebt, mindestens zwei ausgehende Onion-Verbindungen aufrechtzuerhalten und diese Verbindungen vor dem Ausschluss zu schützen. Aufgrund des geringen Prozentsatzes von gossiped Adressen, die Onion-Knoten sind, war es oft der Fall, dass ein Node nur selten, wenn überhaupt, ausgehende Onion-Verbindungen herstellte, wenn man nicht `onlynet=onion` angab. Diese Änderung stellt sicher, dass Nodes, die auf das Onion-Netzwerk zugreifen, einige Onion-Verbindungen aufrechterhalten. Infolgedessen werden Netzwerknachrichten weiterhin über das Netzwerk verbreitet, selbst wenn der IPv4-Verkehr, der nicht aus dem Onion-Netzwerk stammt, blockiert ist, wodurch das Risiko einer Partitionierung verringert wird. Hinweis: Nur Nodes, die mit dem Onion-Netzwerk verbunden sind, sind von dieser Aktualisierung betroffen.

Auszahlungsverzögerungen beseitigt

Für Auszahlungen muss man nicht mehr warten. Sie können bei jedem Quorum durchgeführt werden. Das Limit ist 2000 anstatt 1000 Dash pro Tag.

Gebühren für beanspruchte Nutzernamen

Die 0,2 Dash, die für Verarbeitung von beanspruchten Nutzernamen erhoben werden, fließen nun an die Evonodes zurück. Alle angefallene Dash Credits werden vergütet. Die geschätzte Rendite pro Epoch für jeden Evonode beträgt nun 0,5 Dash.

Library Updates & Bug fixes

Außerdem haben wir unsere BLS-Bibliothek von einer C++-Version mit Rust-Bindings auf eine in Rust geschriebene Version umgestellt. Darüber hinaus haben wir zahlreiche interne Bibliotheken aktualisiert, darunter vor allem RocksDB, und einige Fehler behoben.

Versionshinweise – https://github.com/dashpay/platform/releases/tag/v1.8.0

Unterstützung für BIP324/P2Pv2

Ermöglicht die Verschlüsselung von p2p-Verbindungen mit praktisch null Overhead.

Fungible Tokens

Dadurch wird es möglich sein, fungible Token auf der Dash-Blockchain auf ein Standard- oder ein bestimmtes Konto zu minten, sie zwischen Identitäten zu übertragen, zu burnen, für eine Identität zu sperren bzw. die Sperre aufzuheben, eine Identität für die Interaktion mit dem Vertrag auf eine Blacklist zu setzen sowie die Übertragbarkeit des Tokens zu aktivieren oder zu deaktivieren.

Built-in Creator Attribution

Jedes NFT erfasst und zeigt nun automatisch seinen ursprünglichen Ersteller an. Diese Information wird zu einem festen Bestandteil der On-Chain-Daten des NFT und schafft so eine unveränderliche Verbindung zwischen dem Kunstwerk und dem Künstler, der es geschaffen hat.

State Transition Fixes & Verbesserungen

Zahlreiche Fehlerbehebungen und eine erhebliche Beschleunigung der Platform State Transitions.

Neue Dash Evolution JS SDK

Eine Entwicklervorschau eines neuen JavaScript-SDK ermöglicht Platform-Abfragen und State Transitions für die Entwicklung in Browsern und mit Node.js.

Verbesserungen bei der Synchronisierungsleistung

Es wurden verschiedene Leistungsverbesserungen umgesetzt, die sich vor allem auf die X11-Hash-Leistung sowie auf Lock-Konflikte konzentrierten, wodurch die Synchronisationszeit deutlich verkürzt werden konnte.

Voting und Proposal-Submission-UI

Nutzer und Masternode-Besitzer können nun Governance Proposals über Dash Core einbringen und darüber abstimmen.

Erweiterte Blockfilter für spezielle Transaktionen

SPV-Clients können BIP 157/158-Blockfilter verwenden, um festzustellen, welche Blöcke Transaktionen enthalten, die für sie von Interesse sind, ohne dass dabei die mit Bloom-Filtern verbundenen Datenschutzbedenken bestehen. Diese Blockfilter wurden erweitert und berücksichtigen nun spezielle Skripte, die in bestimmte Transaktionen eingebettet sind.

Standardmäßig sind Blockfilter über Masternodes aktiviert

SPV-Clients können BIP 157/158-Blockfilter verwenden, um festzustellen, welche Blöcke Transaktionen enthalten, die für sie von Interesse sind, ohne dass dabei die mit Bloom-Filtern verbundenen Datenschutzbedenken bestehen. Diese Blockfilter wurden erweitert und berücksichtigen nun spezielle Skripte, die in bestimmte Transaktionen eingebettet sind.

Platform-Infrastrukturerweiterungen

Einführung eines Platform gesteuerten PoSe-Sperrmechanismus; damit kann Dash Platform Evonodes sperren, die nicht den ordnungsgemäßen und vollständigen Umfang an Diensten bereitstellen.

Platform Adressen-System

Dash Platform wurde ursprünglich als datengesteuerte Side-Chain konzipiert. Im Laufe der Zeit wurde die Erstellung neuer Konten (Identitäten) auf einen komplexen und rechenintensiven Prozess beschränkt, bei dem Guthaben zunächst in die Core-Chain abgezogen werden mussten, um anschließend wieder in die Platform-Chain zurückgeführt zu werden – was für Gelegenheitsnutzer, die einfache Zahlungsfunktionen ohne die Komplexität der Verwaltung vollständiger Identitäten wünschen, unpraktisch war. Mit Platform-Adressen können Sie: Dash direkt in eine Platform-Adresse empfangen, ohne zuvor eine Identität anzulegen | Dash schnell und einfach zwischen Platform-Adressen versenden | Ihr Guthaben auf der Platform-Adresse nutzen, um bei Bedarf Identitäten anzulegen oder aufzuladen | Ihr Guthaben auf der Plattform jederzeit auf normale Dash-Adressen auszahlen lassen.

Blockchain Layered Address Sync Tree (BLAST)

Stell dir vor, du hast ein Schließfach bei einer Bank, die Tausende von Schließfächern besitzt, und du möchtest überprüfen, ob eines davon dir gehört. Bisher hätte man entweder die Bank gefragt: „Gehört mir Schließfach Nr. 12345?“ (wodurch die Nummer deines Schließfachs bekannt wird) oder die gesamte Liste aller Schließfächer heruntergeladen (was langsam und aufwendig ist).

Die BLAST-Synchronisierung funktioniert stattdessen folgendermaßen: Man fragt die Bank: „Zeig mir den allgemeinen Grundriss des Tresorraums“ (Trunk). Dann sagt man: „Ich interessiere mich für den Ostflügel“ und erhält weitere Details zu diesem Bereich (Branch). Man grenzt die Suche immer weiter ein. Zum Schluss kommt der clevere Teil: Man fragt bewusst nach einigen Bereichen, die einen gar nicht interessieren, sodass die Bank nicht erkennen kann, welche Fächer tatsächlich einem gehören.

Außerdem verfügt die Bank über ein „Summary Ledger“, in dem viele kleine Transaktionen zu einzelnen Einträgen zusammengefasst werden (komprimiert). Wenn du also kürzlich dort warst, musst du dir nur die Zusammenfassung ansehen, anstatt jede einzelne Transaktion durchzulesen.

Das Ergebnis: Deine Wallet synchronisiert sich sehr schnell (etwa 5–6 Sekunden, selbst bei 1 Million Adressen im System), während kein einzelner Node feststellen kann, welche Adressen dir tatsächlich gehören.