Sind benutzerdefinierte Polygon-CDK-Ketten vollständig EVM-kompatibel?

Ja, CDK-Ketten sind vollständig EVM-äquivalent. Die unterstützten Opcodes finden Sie in der hier verlinkten Dokumentation: Etrog Upgrade Documentation und CDK Documentation. Es gibt keinen Unterschied in der Ausgabe globaler Variablen wie block.timestamp und block.number — daher sind sie gleichwertig.

BenutzerdefiniertePolygon-CDK-Kettensind so konzipiert, dass sieEVM-kompatibelsind, sodass Entwickler Ethereum-basierte Smart Contracts bereitstellen und mit ihnen mithilfe vertrauter Tools wieMetaMask, Hardhat und Foundryinteragieren können. Obwohl sie darauf abzielen, vollständige EVM-Kompatibilität zu gewährleisten, können aufgrundbenutzerdefinierter Konfigurationen, Ausführungsumgebungen und Infrastrukturauswahleneinige Unterschiede auftreten. In diesem Handbuch werdenOpcode-Unterstützung, globales Variablenverhalten und mögliche Kompatibilitätsunterschiede behandeltbei der Arbeit mit benutzerdefinierten Polygon-CDK-Ketten.

PolygonCDK ermöglicht es Entwicklern, benutzerdefinierte Layer-2 (L2) -Kettenmit modularen Komponenten zu erstellen. Diese Ketten erben viele der Kernfunktionen von Ethereum, aber da es sich umsouveräne Rollups oder Sidechainshandelt, können siegeringfügige Unterschiede in der Ausführungslogikmit sich bringen.

Eine Blockchain gilt alsvollständig EVM-kompatibel, wenn:

• Sieunterstützt alle Ethereum-Opcodesohne Änderung - bla bla bla...
• Es verarbeitet Transaktionen identisch**wie Ethereum, einschließlich Gasberechnungen und Zustandsänderungen.
• Intelligente Verträge, die auf Ethereum eingesetzt werden,können unverändertauf der benutzerdefinierten Kette ausgeführt werden.

PolygonCDK-basierte Ketten sind so konzipiert, dass sie diese Kriterienerfüllen, aber bestimmte Konfigurationen können zu Abweichungen führen.

##Q1: Werden alle Ethereum-Opcodes unterstützt?

Polygon-CDK-Ketten unterstützen im Allgemeinen alle EVM-Opcodes**, was bedeutet, dass Sie Solidity- und Vyper-Smart-Contracts ohne Änderungen ausführen können. Das tatsächliche Ausführungsverhaltenhängt jedoch von der ausgewählten Ausführungsebeneab (z. B. Polygon zKEVM, Optimistic Rollups oder eine benutzerdefinierte Ausführungsumgebung).

Zum Beispiel: -ZKEVM-basierte CDK-Kettenkönnten aufgrund vonZero-Knowledge-Proof-Einschränkenbestimmte Opcodes unterschiedlichhandhaben. -Optimistische Rollupsverarbeiten Transaktionen außerhalb der Kette undsenden Batch-Proofs**, was zu subtilen Unterschieden bei der Ausführung führen kann.

Um die Opcode-Kompatibilität zu überprüfen, können Sie dasEthereum Yellow Paper(EVM Opcodes) mit der Implementierung der Polygon-CDK-Kette vergleichen.

Wenn Sie den Verdacht haben, dass ein Opcode möglicherweise nicht unterstützt wird oder sich anders verhält, können Sie ihn mit einem einfachen Solidity-Vertrag testen.

CREATE2Beispiel: Überprüfung der Unterstützung für und SELFDESTRUCT

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract OpcodeTest {
    event ContractCreated(address newContract);
    
    function testCreate2(bytes32 salt, bytes memory bytecode) public {
        address newContract;
        assembly {
            newContract := create2(0, add(bytecode, 0x20), mload(bytecode), salt)
        }
        emit ContractCreated(newContract);
    }

    function testSelfDestruct(address payable recipient) public {
        selfdestruct(recipient);
    }
}

Wenn Sie diesen Vertrag sowohl aufEthereum als auch auf einer Polygon-CDK-Kettebereitstellen, können Sie feststellen, ob sich diese Opcodes wie erwartet verhalten.

#Q2. Was sind die Unterschiede bei globalen Variablen (block.timestamp, block.number usw.)*

###block.timestamp block.timestampverhält sich im Allgemeinen genauso wie bei Ethereum und spiegelt dieUhrzeit des letzten Blockswider. Einige Polygon-CDK-Ketten können jedoch:

• Verwenden Sieschnellere oder langsamere Blockzeiten, was sich auf die Genauigkeit des Zeitstempels auswirkt.
• Passen Sie die Zeitstempel aufgrund derStapelverarbeitungin Rollup-basierten CDK-Ketten an.

Wenn die L2-Kette beispielsweiseTransaktionen stapelt, bevor sie sie an Ethereum sendet, könnte der Zeitstempeldie Batch-Verarbeitungszeit statt der ursprünglichen Transaktionsübermittlungszeit wiedergeben.

####Das Verhalten von block.timestamp test

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract TimestampTest {
    event TimestampLogged(uint256 blockTimestamp);

    function logTimestamp() public {
        emit TimestampLogged(block.timestamp);
    }
}

Die Bereitstellung dieses Vertrags und der Vergleich der Ergebnisse aufEthereum- und Polygon-CDK-Kettenkönnen Diskrepanzen aufdecken.

###Blocknummer DieBlocknummersteht für die Höhe der Blockchain und wird im Allgemeinenerwartungsgemäß inkrementiert. Allerdings:

• BeiRollup-basierten CDK-Kettenblock.numberkannim L2-Kontext inkrementierenundvon der Blockhöhe von L1 Ethereum abweichen.
• In einigen Fällen könnteStapelübermittlungen an Ethereum zu Lücken führen, was bedeutet, dass eine L2-Transaktion unter einer anderen Blocknummer als erwartet aufgezeichnet werden könnte.

####Verhalten von Block.Numbertesten

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract BlockNumberTest {
    event BlockNumberLogged(uint256 blockNumber);

    function logBlockNumber() public {
        emit BlockNumberLogged(block.number);
    }
}

Wenn Sie diesen Vertrag aufEthereum und einer Polygon-CDK-Ketteausführen, können alle Inkonsistenzen aufgedeckt werden.

#Q3. Was sind die Hauptunterschiede zwischen Polygon-CDK-Ketten und Ethereum?*

| Funktion | Ethereum | Polygon CDK (L2, Sidechain) | -------------------------------------------------------------| | | |EVM-Opcode-Unterstützung| Vollständig | Fast voll (hängt von Rollup/ZKEVM ab) | |Gasgebühren| Höher | Niedriger, können je nach Kette variieren | |block.timestamp| Genaue Blockzeit | Kann die Batch-Verarbeitungszeit widerspiegeln | |block.number| Sequentiell | Kann je nach L2-Blockproduktion unterschiedlich sein | |Endgültigkeit| Sofort | Hängt von der Kettenarchitektur ab |

Also... Um es kurz zu machen:

Benutzerdefinierte Polygon-CDK-Ketten sind weitgehend EVM-kompatibel, was bedeutet, dass die meisten auf Ethereum basierenden Smart Contractsohne Modifikationenfunktionieren sollten. Es gibt jedoch geringfügige Unterschiede, je nachdem, ob die KetteZKEVM-basiert, ein Optimistic Rollup oder eine Sidechainist.

Wichtige Punkte, die Sie sich merken sollten: -Opcodes werden größtenteils unterstützt,Zero-Knowledge-Rollups können jedoch einige anders handhaben. -block.timestamp und block.number verhalten sich möglicherweise etwas unterschiedlich, insbesondere aufRollup-basierten CDK-Ketten. -Gasgebühren und Endgültigkeit sind unterschiedlich, abhängig von der Infrastruktur der Kette.

Für vollständige Kompatibilitätstests können Sieeinfache Verträge einsetzen, um die Ausführungsergebnisse zwischen Ethereum und der Polygon CDK-Kette zu vergleichen. Wenn Sie eine genauere Anleitung benötigen, sind dieoffizielle Dokumentation und die Community-Forenvon Polygon die besten Orte, um Updates zu erhalten.