Dash Platform

Die Dash Platform Chain

Originalbeitrag von Ivan Shumkov

Basierend auf dem Feedback der Community nach der Präsentation der Dash Platform auf der Dash Convention Europe möchten wir die Gründe für die Einführung einer separaten Platform Chain teilen.

Dash Platform Chain Übersicht

Wie bereits in der Einführung zu Dash Platform beschrieben, handelt es sich bei Dash Platform um einen Technologie-Stack (eine Reihe von Diensten) für die Entwicklung dezentraler Anwendungen.

Zunächst werden wir Folgendes bereitstellen:

  • Drive – eine dokumentenorientierte Datenbank zum Speichern und Abfragen von Metadaten
  • Identitäten – eindeutige Identitäten für Benutzer, Anwendungen und andere Entitäten
  • Dash Platform Name Service – ein dezentrales und erweitertes DNS
  • DAPI – eine dezentrale HTTP-API zur Kommunikation mit der Plattform

In Zukunft werden wir ein Kommunikationsprotokoll zwischen Benutzern und Anwendungen, Zahlungsanforderungen, Zugriffsregeln für Drive-Daten und mehr einführen. Die Liste der zukünftigen Dienste ist noch nicht vollständig definiert.

Um diese Dienste zu hosten und zu betreiben, wird Dash Platform ausschließlich im Masternode-Netzwerk ausgeführt. Verglichen mit der Verwendung des gesamten Dash-Netzwerks ist dies eine viel skalierbarere Lösung, da Masternodes einen wirtschaftlichen Anreiz erhalten, qualitativ hochwertigen Service bereitzustellen. Für die Verarbeitung und Speicherung des Plattformzustandes (des globalen Plattformdatensatzes) benötigt die Plattform ein byzantinisches fehlertolerantes Konsensprotokoll. Dieses Konsensprotokoll stellt sicher, dass ein Quorum (d. H. Eine Teilmenge) von Masternodes die Daten auf vertrauenswürdige Weise validiert und verarbeitet.

Nehmen wir an, wir haben eine Dash-Plattform-Anwendung, memo.dash, einen dezentralen Twitter-Klon und das Dash-Analog von https://memo.cash. Um eine neue Memo zu erstellen und den Anwendungszustand (eine Teilmenge des Plattformzustandes) zu aktualisieren, müssen Sie mit dieser Memo einen Zustandsübergang¹ erstellen und über die DAPI an die Plattform senden. Die Plattform sollte wiederum den Zustandsübergang verarbeiten und den Anwendungszustand aktualisieren. Sobald dies abgeschlossen ist, wird die Plattform…

  1. Den Zustandsübergang innerhalb eines Masternode-Quorums propagieren
  2. Diesen gemäß der Plattform-Konsensregeln mit dem Quorum validieren
  3. Ihn in die Blockchain aufnehmen
  4. Den Plattform Zustand aktualisieren wenn der Zustandsübergang abgeschlossen ist (Auf der Blockchain bestätigt)

Das Problem, wie Zustandsübergänge am besten aufgezeichnet und abgeschlossen werden können, bietet zwei mögliche Lösungen: Die vorhandene Blockchain verwenden oder eine neue Blockchain für die Zwecke der Plattform einführen.

Vergleich der Lösungen

Wenn wir die vorhandene Blockchain für Zustandsübergänge verwenden, sehen wir uns mit einigen Nachteilen konfrontiert:

  1. Ineffiziente Nutzung von Ressourcen
    Da Zustandsübergänge nur auf Masternodes erforderlich sind, würde die Verwendung der vorhandenen Blockchain unnötigerweise zusätzlichen Speicherplatz verbrauchen und die Netzwerklast für das gesamte Netzwerk erhöhen. Dies liegt daran, dass wir Miner benötigen, um Zustandsübergänge zu verarbeiten und in Blöcke zu unterteilen. Dann würden die Blöcke über das gesamte Netzwerk verbreitet und auf allen Fullnodes gespeichert.
  2. Teurere, nicht-deterministische Gebühren für Zustandsübergänge
    Durch das involvieren der Miner müssten Gebühren für Zustandsübergänge sowohl an Masternodes (die die Daten verarbeiten und speichern) als auch an die Miner gezahlt werden. Solche Gebühren sind nicht deterministisch, da die Gebühren der bestehenden Blockchain aufgrund von Faktoren wie Transaktionsgröße und Blockkapazität variieren können. Deterministische Gebühren sind für Unternehmen und Entwickler wünschenswert, die Dash Platform einsetzen möchten, da sie es ermöglichen, die Kosten für Budgetierungs- und Planungszwecke im Voraus zu berechnen.
  3. Ineffiziente Datenüberprüfung für Light Clients
    Die Überprüfung der Plattformdaten für Light Clients (ähnlich wie bei SPV) ist komplex und ineffizient. Kehren wir zu unserem Beispiel mit memo.dash zurück. Als Client müssen Sie für jedes Memo Block Header, Merkle-Proofs und Statusübergänge herunterladen, um zu beweisen, dass Memos im Plattformzustand vorhanden sind und nicht von einem böswilligen Akteur geändert wurden.
  4. Schlechtes Nutzererlebnis aufgrund von Bestätigungszeiten
    Die Blockzeit von 2,5 Minuten ist nicht akzeptabel für die Nutzerfreundlichkeit der Plattformanwendungen. Stellen Sie sich vor, ein Benutzer erstellt eine Memo und wartet einige Minuten, bis die Memo in seiner Anwendung angezeigt wird. Diese Wartezeit ist eine Folge des Zustandsübergangs, der in der Blockchain bestätigt werden muss. Obwohl wir Zustandsübergänge über einen Prozess sichern könnten, der InstantSend ähnelt, gibt es keine Garantie dafür, dass ein Miner sie in den nächsten Block (oder in einen bestimmten Block) verschieben würde.
  5. Erhöhte Komplexität und erhöhtes Risiko für die bestehende Chain
    Durch die Einführung von Zustandsübergängen und anderen Plattformfunktionen in die bestehende Chain würden wir dem kritischsten Teil unseres Systems – den Zahlungen – mehr Komplexität sowie mögliche Bugs und Angriffsvektoren hinzufügen.

Wenn wir stattdessen eine zusätzliche Blockchain für Dash Platform einführen, lösen wir diese Probleme:

  1. Effiziente Nutzung der Ressourcen
    Wenn Sie die Platform Chain ausschließlich im Masternode-Netzwerk ausführen, werden die Gesamtnetzwerklast und die Größe der vorhandenen Blockchain verringert.
  2. Günstigere, deterministische Zustandsübergangsgebühren
    Ohne die Beteiligung von Minern gehen die Zustandsübergangsgebühren nur an Masternodes. Dies reduziert die Kosten für die Verwendung von Dash Platform und vereinfacht die Gebührenberechnung. Gebühren hängen also nur noch von der Datengröße und der Komplexität der Datenverarbeitungsvorgänge ab. Da die Kosten vordefiniert sind, können Unternehmen und Entwickler den Preis des Zustandsübergangs deterministisch berechnen, bevor sie ihn an DAPI senden.
  3. Einfache Datenüberprüfung für Light Clients
    Um Daten für Light Clients nachprüfbar zu machen, speichern wir den Platform Zustand als Merkle Forest (mehrstufige Merkle Trees²) und speichern die Merkle Root in Block Headern. Zurück zu unserem vorherigen Beispiel: Um ein Memo in memo.dash zu überprüfen, muss ein Client nur einen Merkle-Proof und den letzten vom Quorum signierten Header erhalten. Dieser zustandsorientierte Ansatz macht die Verifizierung für Light Clients viel einfacher als für klassisches SPV. Außerdem verlieren Blöcke an Bedeutung, sodass wir uns nicht um Blockchain-Daten-Sharding kümmern müssen und einfach die neuesten Blöcke behalten können.
  4. Schnelleres Abschließen des Zustandsübergangs für ein besseres Nutzererlebnis
    Da es sich um eine separate Blockchain handelt, implementieren wir ein Konsensprotokoll, das den Plattformanforderungen entspricht. Anstelle von Proof-of-Work können wir uns auf die incentivierten Masternodes verlassen und einen auf Proof-of-Service basierenden Konsens aufbauen. Wenn eine Masternode keinen Dienst bereitstellt oder sich schlecht verhält, wird sie bestraft. Die Verwendung von Masternode Quoren für das Vorschlagen und Validieren von Blöcken ermöglicht es uns, die Blockzeit auf Sekunden zu reduzieren und die absolute Endgültigkeit sicherzustellen. Dies vereinfacht den Plattformzustand und Drive erheblich, da Blockchain-Reorganisationen nicht verarbeitet werden müssen.
  5. Verringertes Risiko für die Kernfunktionalität
    Durch die Einführung einer separaten Blockchain wird Dash Platform von der aktuellen Dash-Funktionalität entkoppelt und als zweite Ebene erstellt. Die erste Schicht kennt die zweite nicht. Wenn also etwas mit der Plattform passiert, hat dies keine Auswirkungen auf die vorhandene Blockchain und deren Zahlungsfunktionalität.

Fazit

Letztendlich war die Entscheidung für die Verwendung einer zweiten Chain von unserem Ziel abhängig, ein bestmögliches Nutzererlebnis zu bieten, die sich nicht von Nicht-Krypto-Apps unterscheidet und gleichzeitig die Sicherheitsvorteile einer Blockchain beibehält. Die Platform Chain wurde entwickelt, um die für das Nutzererlebnis erforderliche Geschwindigkeit / Endgültigkeit zu erreichen und die Netzwerk- / Speicherskalierbarkeit des Systems zu unterstützen. Sie vereinfachte auch die Architektur, indem sie die Plattform und die vorhandene Chain entkoppelte. In Kombination machen diese Vorteile die Einführung einer zweiten Chain zur offensichtlichen Wahl.

Wir hoffen, dass dies viele der Fragen beantwortet, die es zur Platform Chain gab. Bleibt über zukünftige Details der gesamten Plattformarchitektur gespannt.

¹ State Transition — https://blog.dash.org/an-introduction-to-dash-platform-dapi-and-drive-9d080d6e89c9
² Merkle Tree — https://en.wikipedia.org/wiki/Merkle_tree