Enthüllung der „Crescendo“ Hard-Fork-Roadmap – 10BPS und mehr

Nach der erfolgreichen Einführung der Rusty Kaspa (RK) Node-Software (Stable Release) und ihrer breiten Akzeptanz durch das P2P-Netzwerk und die Mining-Community (~97% der Kaspa-Blöcke werden über RK-Nodes geschürft) beginnt das Open-Source-Entwicklungsteam nun mit den Vorbereitungen für eine Hard Fork¹, der unter anderem² die Blockrate des Netzwerks von 1 auf 10 Blöcke pro Sekunde (BPS) erhöhen wird. In diesem Beitrag skizziert Michael Sutton, einer der Kaspa-Entwickler, die vorläufige Roadmap für die kommende Hard Fork, die hiermit Crescendo genannt wird, was sie wahrscheinlich beinhalten wird und wie der Prozess der Bereitstellung aussieht.

Der Beitrag ist technisch gehalten und beschreibt die notwendigen Schritte, damit Kaspa sein Ziel einer noch höheren Skalierbarkeit erreicht, ohne dabei Kompromisse bei Dezentralität und Sicherheit einzugehen.

Überblick

Im Großen und Ganzen werden die Schritte vorgestellt, die erforderlich sind, um eine solche Beschleunigung im Kaspa-Mainnet zu implementieren. Der Prozess umfasst die folgenden Phasen:

• Start und Stabilisierung: Start des Testnets mit der erhöhten Blockrate und entsprechenden Netzwerkeinstellungen sowie Arbeit an der Stabilisierung. Dies wurde bereits mit TN11, dem 10-BPS-Kaspa-Testnet, das seit dem 7. Januar 2024 in Betrieb ist, erfolgreich abgeschlossen. (Erledigt)
• Identifizierung von Engpässen: Engpässe bei der Verarbeitung identifizieren und Leistungsoptimierungen vornehmen, um die für den Betrieb eines Nodes erforderlichen Hardware-Spezifikationen zu senken. (Erledigt)
• Iterative Verbesserung: Wiederholte Optimierung der vorherigen Schritte, bis die Hardware-Spezifikationen so weit gesenkt wurden, dass eine ausreichende Dezentralisierung im Mainnet gewährleistet werden kann. Der Optimierungsprozess nähert sich dem Abschluss, was in etwa 2 Monaten erwartet wird.
• Verbessertes Benutzererlebnis: Sobald die Leistungsanforderungen feststehen, wird die Node-Software auf das von den Mainnet-Betreibern geforderte Niveau der Benutzerfreundlichkeit perfektioniert. Das heißt, dass einige kleinere Probleme, die in einem Testnet vernachlässigt werden können, hier angegangen werden müssen (~3 Monate ab jetzt).
• Zusätzliche Funktionen: Implementierung zusätzlicher Hard-Fork-Funktionen und deren Bereitstellung auf TN11. (Geplanter Zeitrahmen: ~4-5 Monate ab jetzt. Einige Funktionen können ausgeschlossen werden, um den Zeitplan einzuhalten).
• Feature Freeze. (Das ist der Zeitpunkt ab dem keine neuen Features mehr in den Release-Zweig kommen können, sondern es werden nur noch Fehler behoben.)
• Hard-Fork-Version: Implementierung der Hard-Fork-Übergangsversion
• Einsatz des Übergangstestnets: Einsatz der Übergangsversion auf TN10 (1 BPS-Testnetz), um den Übergang zum Mainnet zu simulieren.
• Mainnet-Einsatz: Der Einsatz der Hard-Fork-Übergangsversion im Mainnet erfolgt etwa 1-2 Monate später.

Detaillierter Ablauf

Derzeit arbeiten die RK-Entwickler an einer Mainnet-Version, die sich vor allem auf die Implementierung von Mempool-Funktionen konzentriert, welche nach dem KRC-20-Betastart notwendig geworden sind. Zu diesen Funktionen zählen unter anderem Replace-by-Fee (RBF) und eine Gebührenschätzungs-API. Beide erfordern eine enge Abstimmung mit den Entwicklern des Ökosystems.

Nach der Veröffentlichung dieser Version wird der Fokus auf eine leistungsoptimierte Version verlagert, die die Stabilität der TN11-Nodes verbessern soll. Diese Version soll sicherstellen, dass die TN11-Teilnehmer auf eine stabile Software setzen können, welche alle aktuellen Verarbeitungsengpässe behebt und einen reibungslosen Netzwerkbetrieb gewährleistet.

Der Hauptteil der Arbeit würde darin bestehen, die folgenden bestehenden Projekte zusammenzuführen:

• Berechnung des GHOSTDAG auf höheren Ebenen nur bei Bedarf, während ein Pruning-Proof erstellt wird. Dies ist eine wichtige, aber heikle Aufgabe, die vor der Zusammenführung noch einer gründlichen Überprüfung bedarf.
• Parallele Input-Validierung, führt eine feinere Granularität bei der Verarbeitung von Transaktionen ein, indem Eingaben parallel validiert werden.
• Aktualisierung der KIP9-Formel auf TN11 in ihre endgültige Form (TN11 wurde mit einer verfrühten Version von KIP9 gestartet).
• Eine Implementierung von KIP10, Compounding-Adressen, die Mikrotransaktionen mit KIP9 ermöglicht, siehe hier.
• Eine verbesserte Logik für das Sampling von Transaktionen bei der Erstellung von Blockvorlagen

Nachdem diese Funktionen zusammengeführt wurden, wird TN11 mit dieser neuen Version eingeführt und einige Wochen lang unter maximaler Last betrieben. Dies wird uns ermöglichen, die Systemanforderungen zu verstehen, die für den Betrieb eines solchen Nodes erforderlich sind. Wenn die minimalen Systemanforderungen als zu hoch erachtet werden, müssen einige Parameter (wie z. B. die Größe des Schwierigkeitsanpassungsfensters) angepasst werden, worauf einige weitere Testwochen folgen. Alternativ können auch weitere Leistungszyklen in Betracht gezogen werden.

Während der Testphase wird die Arbeit an einigen anderen Funktionen fortgesetzt, darunter:

• Verbesserung und Perfektionierung des IBD-Prozesses, Behebung einiger Grenzfälle im neuen Node-Sync-Prozess, die im Mainnet extrem selten sind, sich aber mit höheren BPS und kürzeren Pruning-Perioden verschärfen werden.
• Verbesserungen der Finalitätsregeln und des neuen Validierungsprozesses für Node-Kopfzeilen (KIP7, KIP8).
• Kryptographische Quittungen (KIP6), eine Änderung, die einen viel kleineren und einfacheren Nachweis ermöglicht, dass eine beliebig alte Transaktion bestätigt wurde.
• Ermöglichung von Transaktionsnutzdaten, die Spezifikationen wie KRC-20 rationalisieren werden.

Sobald all diese Arbeiten abgeschlossen sind, kann die Entwicklung der Mainnet-Version für die Hard Fork beginnen. Diese Version muss die Logik für den Übergang von den aktuellen zu den neuen Protokollparametern beinhalten. Dies ist ein komplexer Prozess, der umfangreich getestet werden muss und bei dem Entscheidungen über den Zeitpunkt und die Art der Hard Fork getroffen werden – ob diese schrittweise oder sofort erfolgt.

Der oben skizzierte Plan ist vorläufig. Ziel dieses Beitrags ist es, nicht eine endgültige Roadmap festzulegen, sondern zu verdeutlichen, dass die 10-BPS-Hardfork der nächste große Fokus des Kernteams ist und erhebliche Anstrengungen unternommen werden, um dieses Ziel zu erreichen. Die grundlegenden Prinzipien bleiben unverändert: Netzwerksicherheit und -stabilität sowie genügend Zeit für das Kaspa-Ökosystem, sich anzupassen. Es wird darauf hingewiesen, dass nicht nur die Kernentwickler, sondern auch das breitere Ökosystem – Wallet-Entwickler, Mining-Pools, Börsen, Block-Explorer und andere – Anpassungen vornehmen und ihre Software über das 10-BPS-Testnet testen sollten.

¹In diesem Kontext bezieht sich der Begriff „Hard Fork“ auf eine von der Community vereinbarte und geplante Änderung des Konsensprotokolls und nicht auf eine umstrittene Fork, die aus Unstimmigkeiten innerhalb des Netzwerks resultiert.

²Keine der in diesem Hard Fork enthaltenen Änderungen wird sich auf die Benutzergelder oder den Emissionsplan auswirken. Die Erhöhung auf 10 BPS wird zu zehnmal mehr Belohnungen führen, aber die Belohnung pro Block wird um den gleichen Faktor reduziert, wobei die gleiche Emissionsrate pro Sekunde beibehalten wird.