12186 | Vorschlag SDK Upgrade auf 50.13 eingereicht von Luncverse

Quelle von:

• https://validator.info/terra-classic/governance/12186
• https://station.terraclassic.community/proposal/columbus-5/12186
• https://discourse.luncgoblins.com/t/updated-proposal-terra-classic-sdk-wasm-upgrade/74

Für die Genehmigung des Ketten-Upgrades auf SDK 50.13 sehen Sie sich bitte die vollständige Begründung hier an: https://discourse.luncgoblins.com/t/updated-proposal-terra-classic-sdk-wasm-upgrade/74

Aktualisierter Vorschlag: Terra Classic SDK & Wasm Upgrade

Terra Classic Upgrade
Dokument / ANTIER SOLUTIONS

Zusammenfassung

Dieser Vorschlag skizziert ein sicheres, abwärtskompatibles Upgrade der Kerninfrastruktur von Terra Classic auf Cosmos SDK v0.50.13 und Wasm Module v0.53.2. Dabei werden ungelöste Probleme aus dem Upgrade auf v0.47 behoben, die Sicherheit erhöht und die langfristige Nachhaltigkeit sichergestellt.

Das Upgrade hängt davon ab, dass Orbit Labs das Forking abschließt. Es umfasst Korrekturen für technische Schulden, die Abmilderung von Änderungen, die zu einem Bruch führen, und Verbesserungen für Entwickler. Der Vorschlag gewährleistet volle Abwärtskompatibilität für bestehende dApps.

Technische Spezifikationen & Auswirkungen

1. Cosmos SDK Upgrade

Aktuell: v0.47.17

Vorgeschlagen: v0.50.13

Grundprinzipien: Das Upgrade auf v0.50+ (“v50.13”) bringt modernen Konsens durch ABCI++, eine modulare und wartbare Architektur, robusteren Speicher, eine gehärtete Berechtigungslogik, eine Governance-geführte Konfiguration und entwicklerfreundliche Werkzeuge. Damit ist Terra Classic auf einem stärkeren, zukunftssicheren Weg.

Änderungen:
x/params Modul-Updates (erfordert die Migration zu neuen Governance-gesteuerten Parametern).
x/authz und x/feegrant Updates (wirkt sich auf dApps aus, die Delegation/Allowances verwenden).
Benutzerdefinierte Modulanpassungen (z.B. Oracle, Market, Staking) aufgrund von SDK Refactoring.

Terra Classic Überlegungen:
Gewährleistet die vollständige Abwärtskompatibilität mit den bestehenden Merkmalen und Funktionen der Kette.

2. Wasm Modul & Virtuelle Maschine

Aktuell: v0.46.0 / wasmvm v1.5.8

Vorgeschlagen: v0.53.2 / wasmvm v2.1.4

dApp Auswirkungen:

• Bestehende CosmWasm-Verträge funktionieren weiterhin.
• Die Verträge werden den neuesten Standards entsprechen und gleichzeitig die Abwärtskompatibilität mit bestehenden Beschränkungen wahren.

Terra Classic Custom Wasm Bindungen Kompatibilität:

Die benutzerdefinierten Bindungen für die Module Oracle, Tax und Market werden beibehalten.

3. IBC-GO

IBC-GO: v7.4.0 → v8.7.0

Bewahrt die kettenübergreifende Kompatibilität, ohne IBC-verändernde Änderungen einzuführen.

Leistungsverbesserungen, die die Leistung des Relayers optimieren und die Transaktionslatenz verringern.

Zukunftssicherheit, Gewährleistung der Kompatibilität mit zukünftigen Cosmos-Ketten, die IBC v8.7.0 übernehmen.

4. Terra Classic Benutzerdefinierte Module & Upgrade Plan

Die benutzerdefinierten Module von Terra Classic müssen bei diesem Upgrade sorgfältig behandelt werden:

Oracle-Modul: Verwaltet Wechselkurs-Feeds für Stablecoins. Erfordert Kompatibilitätstests mit der neuen SDK-Struktur, um sicherzustellen, dass die Preisübermittlungen des Validators korrekt bleiben.

Markt-Modul: Erleichtert den Tausch von Stablecoins. Benötigt eine Parametervalidierung und Optimierung für die Leistung unter dem neuen SDK-Ausführungsmodell.

Modul Finanzministerium: Regelt die Wirtschaftspolitik, einschließlich der Steuersätze. Muss ohne Funktionsverlust beibehalten und unter den neuen Governance-gesteuerten Parametern getestet werden.
Alle anderen Anpassungen, die in verschiedenen Modulen vorgenommen wurden, wie z.B. Staking, Slashing, Mint usw., werden ebenfalls aktualisiert.

Upgrade-Strategie:

Ausführliche Unit-Tests und Refactoring:

Führen Sie Unit-Tests für die Oracle-, Markt- und Treasury-Module durch, um die ordnungsgemäße Funktionalität unter dem neuen SDK zu überprüfen.

Identifizieren Sie Bereiche, die überarbeitet werden müssen, um sie an SDK v0.50.13 anzupassen.

Implementierung der Abwärtskompatibilitätsschicht:

Entwickeln Sie temporäre Kompatibilitäts-Shims für die Module x/treasury und x/market, um dApp-Unterbrechungen zu vermeiden.

Stellen Sie sicher, dass die bestehenden Governance-Parameter während des Upgrades unverändert bleiben.

Warum dieses Upgrade?

1. Terra Classic-spezifische Forschung

Entfesselte Synergie:

Das Forking von Orbit Labs entfernt die Original-Patches von Terra und ermöglicht eine nahtlose Integration des SDK v0.50.

2. Risikominderung

Abwärtskompatibilitätsschicht:

Vorübergehende Shims für veraltete Module, um dApp-Unterbrechungen zu vermeiden.

Sicherheitsmaßnahmen:

Die von Oak Security bei der Prüfung von Cosmos SDK v0.47 festgestellten Sicherheitslücken werden durch die Integration der entsprechenden Korrekturen aus v0.50 behoben.

Arbeitsablauf & Zeitplan

Phase 1: Vorbereitung auf das Upgrade (2 Wochen)

Aufgaben: Detaillierte Analyse der aktuellen Codebasis, Abwärtskompatibilität und Dokumentation, Einrichtung eines Testnetzes.

Phase 2: Durchführung des Kern-Upgrades (5 Wochen)

Aufgaben:
SDK v0.50.13 Integration.

Wasm Modul v0.53.2 Update.

Individuelle Modulmigration für die einzigartigen Funktionen von Terra Classic.

Sicherstellen, dass die CosmWasm 1.0-1.5-Verträge weiterhin funktionieren.

Sicherstellung der vollen Unterstützung und Kompatibilität für bestehende CW-0.16-Verträge in der Kette und gleichzeitige Ermöglichung der Vorwärtskompatibilität mit CW-1.0-1.5 – so gibt es kein Risiko für aktuelle Implementierungen und wir sind für die Zukunft gerüstet.

Phase 3: Progressive Upgrades, Tests und Validierung (9 Wochen)

Aufgaben:
Richten Sie die Kette auf einer Version ein, die 0.16-Verträge unterstützt, instanziieren Sie diese Verträge und aktualisieren Sie die Kette dann schrittweise auf v0.50.13, gefolgt von Mock-Tests.

Sicherheitsprüfungen, Validator-Trockenübungen, dApp-Migrationstests, Bug Bounties.

Bei diesem Upgrade bleiben wir bei App v1, um die Komplexität der Migration zu minimieren. Wir planen, die Migration von App v2/Depinject in einer zukünftigen Phase zu evaluieren, sobald wir uns auf v0.50 stabilisiert haben.

Phase 4: Testnet-Bereitstellung (4 Wochen)

Aufgaben:
Öffentlicher Testnet-Launch, Validator/DApp-Onboarding, Überwachung.

Phase 5: Mainnet-Bereitstellung (4 Wochen)

Aufgaben: Governance-Abstimmung, CEX-Koordination, Mainnet-Upgrade, Überwachung nach dem Start.

****Strathcole hat geholfen, die Details der Upgrades zu übersehen und hat auch den von Allnodes gemeldeten SDK 47 Fehler behoben

Dieses Dokument ist das Originalformular, das ich bekomme. Nach einigen Fragen – wer macht das. – ANTIER SOLUTIONS würde das UPGRADE durchführen

10000327382160×3840 548 KB