CAP-12 schlägt Änderungen an der Cardano Verfassung für Dijkstra vor
Die Änderung würde Governance Regeln für neue Protokollparameter festlegen, während Node 11.2 vorbereitet wird, um Dijkstra Funktionen zu testen, darunter ein neues Blockformat und den Plutus V4 Kontext.
By SongMarketCap
CAP-12, eine vorgeschlagene Änderung, die Dijkstra Protokollparameter abdeckt, steht zur öffentlichen Konsultation offen. Intersects Update vom 2. Oktober skizzierte den Vorschlag zusammen mit den Vorbereitungen für Node 11.2, wobei in Kürze eine Vorabversion für Wallet und Infrastruktur Teams erwartet wird.
Dijkstra Parameter in der Cardano Verfassung
Die Cardano Verfassung erlaubt Parameter Update Aktionen nur für Einstellungen, die ausdrücklich in Anhang I aufgeführt sind. Ohne die Änderung würden Dijkstras neue Parameter trotz technischer Anpassbarkeit auf ihren Anfangswerten festgesetzt bleiben.
CAP-12 umfasst Reference Script Schutz, Ouroboros Leios, Ouroboros Peras und die Ökonomie von Stake Pools. Der Umfang beinhaltet Einstellungen für Leios Kapazität und Timing, die minimale Pool Marge und den maximalen Pledge Hebel.
Für jeden Parameter beschreibt der Vorschlag seine Funktion, ordnet ihn einer Abstimmungsgruppe zu und definiert Grenzen für künftige Änderungen. Die Gruppe bestimmt die Zustimmungsschwelle für DReps, Vertreter, an die ADA Inhaber Stimmrechte delegieren. Sicherheitskritische Parameter erfordern zudem die Zustimmung der Stake Pool Betreiber.
Ein aktualisiertes Guardrails Script würde automatisch Beschränkungen durchsetzen, die on chain überprüft werden können. Die Änderung ergänzt Bestimmungen, ohne bestehenden Verfassungstext zu ändern oder zu entfernen.
Node 11.2 bereitet Dijkstra Integrationstests vor
Laut Intersect läuft die Ablaufplanung für Node 11.2. Die geplante Vorabversion wird den Großteil des Dijkstra Funktionsumfangs enthalten, darunter das neue Blockformat und den Plutus V4 Kontext, der die für Smart Contract Skripte verfügbaren Informationen definiert.
Wallet und Tooling Teams werden Integrationen testen und Änderungen am Protokollverhalten, an APIs und Funktionalität beurteilen können. Die Veröffentlichung wird Leios ausschließen und nicht bereit sein, den Hard Fork zu aktivieren.
Auch Anbieter von Hardware Wallets haben Vorbereitungsarbeit in Bezug auf kryptografische Schlüssel und Anforderungen an die Stake Pool Registrierung für Leios. Diese Anforderungen gehen über die Inhalte der kommenden Testveröffentlichung hinaus.
Ausstehende Guardrails und spätere Aktivierung
Die vorgeschlagenen Guardrails verknüpfen Änderungen an der Leios Kapazität mit Benchmarking und Simulationen, die zeigen, dass Knoten Daten innerhalb der geforderten Zeit verarbeiten und verteilen können.
CAP-12 unterscheidet zudem zwischen Aktivierungsstufen. Der maximale Pledge Hebel, ein Pool Parameter, der mit den eigenen ADA Pledges der Betreiber verknüpft ist, hätte anfangs keinen konfigurierten Wert. Seine Aktivierung würde eine nachfolgende Governance Aktion erfordern. Peras und die minimale Pool Marge sind für einen späteren Hard Fork innerhalb der Dijkstra Ära vorgesehen.
Der Vorschlag befindet sich weiterhin in der Konsultation, eine erste Prüfung durch Redakteure wird erwartet. Zahlenmäßige Grenzen für die Endorser Block Kapazität und das Leios Timing gehören zu den Werten, die im Entwurf noch als PENDING markiert sind.