TRON schlägt Mainnet 4.8.0-Upgrade zur Unterstützung der Ethereum Cancun-Kompatibilität vor – jetzt zur Diskussion

Vorschlag für die TRON Das Mainnet-Upgrade auf Version 4.8.0 wurde innerhalb der Proof-of-Stake-Blockchain-Community eingeführt. Ziel dieses Vorschlags ist die Implementierung spezifischer Anweisungen, die die TRON Virtual Machine (TVM) an die jüngsten Fortschritte der Ethereum Virtual Machine (EVM) anpassen und die Funktionalität der Konsensschicht der Blockchain verbessern.

Das Ethereum Cancun-Upgrade, das am 13. März veröffentlicht wurde, brachte mehrere Verbesserungen mit sich. TRON beabsichtigt, diese Änderungen zu übernehmen, um die EVM-Kompatibilität zu erhalten und eine konsistente Entwicklungsumgebung plattformübergreifend zu unterstützen. Die Integration der neuen Anweisungen aus dem Cancun-Upgrade wird als notwendig erachtet, um eine operative Ausrichtung zu erreichen und gleichzeitig die Leistung von Smart Contracts und die Energieeffizienz zu verbessern.

Dieser Vorschlag zielt darauf ab, die Cancun-Upgrade-Opcodes auf TRON zu aktivieren, die EVM-Ausrichtung zu verstärken und zur Interoperabilität zwischen verschiedenen Blockchain-Umgebungen beizutragen.

Die Aktivierung dieser Opcodes in einer Platzhalterfunktion soll die TVM-EVM-Kompatibilität aufrechterhalten, die kettenübergreifende Entwicklung erleichtern, den Übergang von EVM-basierten Smart Contracts zu TRON vereinfachen und Entwicklern, die im TRON-Ökosystem arbeiten, Energiesparvorteile bieten.

Die Aktivierung der erweiterten Verifizierung auf Konsensebene soll das Netzwerk stärken, indem Schwachstellen behoben werden, die während Wartungszeiten auftreten können. Insbesondere soll die Erstellung ungültiger Blöcke und Blockheader mit Zeitstempeln, die keine exakten Vielfachen von drei Sekunden sind, verhindert werden. Darüber hinaus wurden Aktualisierungen des Super Representative-Ranking-Algorithmus vorgenommen, um dessen Zuverlässigkeit unter ungewöhnlichen Bedingungen zu gewährleisten.

Um zukünftige plattformübergreifende Funktionen zu unterstützen und die Kompatibilität mit einer größeren Anzahl von Java Development Kit-Versionen zu verbessern, wird Java-Tron voraussichtlich von der Verwendung der Klasse java.lang.Math zu einer mathematischen Bibliothek wechseln, die konsistente Berechnungsergebnisse in verschiedenen Umgebungen liefert.

Während sich das TRON-Netzwerk weiterentwickelt, haben Verbesserungen der Sicherheit und der Betriebseffizienz weiterhin Priorität. Zwar gibt es derzeit Sicherheitsvorkehrungen, um bestimmte Transaktionsarten einzuschränken – beispielsweise solche mit großen Nutzlasten, mehreren Ergebnissen, kurz vor Ablauf stehenden Transaktionen oder Kontoaktivierungen –, doch wurden diese Kontrollen noch nicht in die Konsensebene integriert. Das Fehlen einer solchen Durchsetzung auf dieser Ebene kann zu Leistungsproblemen führen, auch wenn dadurch weder die Sicherheit der Vermögenswerte noch die Konsistenz der Daten in der Kette beeinträchtigt werden.

Dieser Vorschlag soll Elemente des Ethereum Cancun-Upgrades integrieren und zusätzliche Verbesserungen an der Konsensebene vornehmen, mit dem Ziel, sowohl die Stabilität als auch die Leistung des TRON-Netzwerks zu verbessern.

Der vorgeschlagene Zeitplan sieht als Datum für die Erstellung der Abstimmungsanfrage den 23. Juni und als Datum für das Inkrafttreten den 26. Juni vor.

Technische Spezifikationen: Speicher-Opcodes, Speicherkopieren und Opcode-Anweisungen

Zwei neue Opcodes für den transienten Speicher sind für die Aktivierung vorgesehen: TLOAD (0x5c) zum Lesen aus dem transienten Speicher und TSTORE (0x5d) zum Schreiben in den Speicher. Transienter Speicher bietet eine energieeffizientere Lösung für die Verarbeitung temporärer Daten während einer Transaktion. Er dient als Alternative zum herkömmlichen Speicher, da er die Datenpersistenz über interne Aufrufe innerhalb derselben Transaktion hinweg ermöglicht, ohne dass die Daten nach Abschluss der Transaktion erhalten bleiben. Weitere technische Informationen finden Sie in TIP-650.

Der MCOPY-Opcode (0x5e) soll ebenfalls eingeführt werden und ermöglicht das effiziente Kopieren von Daten zwischen Speicherbereichen. Diese Anweisung trägt zu einer verbesserten Energieeffizienz bei, wenn Smart Contracts intensive Speicheroperationen durchführen. Details zu dieser Ergänzung finden Sie in TIP-651.

Weitere Verbesserungen der Konsensverifizierung sind ebenfalls enthalten. Dazu gehört die Festlegung von Limits für die Größe von Kontoerstellungstransaktionen, um die Bandbreitennutzung besser zu steuern. Die Verifizierung von Transaktionsgrößen nahe der Obergrenze wird verstärkt, um sicherzustellen, dass einzelne Blöcke ihre Transaktionskapazität nicht überschreiten. Die Länge der Transaktionsergebnislisten unterliegt nun einer strengeren Validierung, um die Übereinstimmung mit der Anzahl der aufgerufenen Verträge sicherzustellen. Abweichungen wirken sich jedoch nicht direkt auf den Konsens aus. Außerdem wird ein strengerer Mechanismus für den Umgang mit abgelaufenen Transaktionen implementiert, um die Wahrscheinlichkeit zu verringern, dass Transaktionen kurz vor dem Ablauf wertvolle Netzwerkressourcen belegen. Diese Aktualisierungen sind in TIP-694 beschrieben.

Darüber hinaus werden die Opcodes BLOBHASH (0x49) und BLOBBASEFEE (0x4a) als Platzhalter eingeführt. Diese Anweisungen geben den Standardwert Null zurück und bieten derzeit nicht die volle Funktionalität. Ihre vorübergehende Einbeziehung dient der Wahrung der Kompatibilität mit Ethereum-Bytecode. Weitere Informationen finden Sie in TIP-745.