HyperCore <> HyperEVM-Übertragungen

Einführung

Spot-Assets können zwischen HyperCore und der HyperEVM gesendet werden. Im Kontext dieser Übertragungen werden Spot-Assets auf HyperCore als Core spot bezeichnet, während diejenigen auf der EVM als EVM spot bezeichnet werden. Der Spot-Deployer kann sein Core spot-Asset mit jedem auf der EVM bereitgestellten ERC20-Vertrag verknüpfen. Das Core spot-Asset und der ERC20-Token können in beliebiger Reihenfolge bereitgestellt werden.

Als nativer Token auf HyperCore verknüpft HYPE ebenfalls mit dem nativen HyperEVM-Guthaben statt mit einem ERC20-Vertrag.

Systemadressen

Jeder Token hat eine Systemadresse auf der Core, nämlich die Adresse mit dem ersten Byte 0x20 und den übrigen Bytes lauter Nullen, mit Ausnahme des Token-Index, der im Big-Endian-Format kodiert ist. Beispielsweise wäre die Systemadresse für den Token-Index 200 0x20000000000000000000000000000000000000c8 .

Die Ausnahme ist HYPE, dessen Systemadresse 0x2222222222222222222222222222222222222222 lautet .

Übertragung von HYPE

HYPE ist als nativer Gas-Token auf der HyperEVM ein Sonderfall. HYPE wird auf der EVM-Seite einer Übertragung als nativer Gas-Token statt als ERC20-Token empfangen. Für die Rückübertragung zu HyperCore kann HYPE als Transaktionswert gesendet werden. Die EVM-Übertragungsadresse 0x222..2 ist ein Systemvertrag, der event Received(address indexed user, uint256 amount) als seine payable receive()-Funktion ausgibt. Hier ist user gleich msg.sender, sodass diese Implementierung sowohl Smart Contracts als auch EOAs die Rückübertragung von HYPE zu HyperCore ermöglicht. Zu beachten ist, dass für die Ausgabe dieses Logs auf der EVM-Seite geringe Gas-Kosten anfallen.

Übertragungen zwischen Core und EVM

Nur wenn ein Token verknüpft ist, kann er zwischen HyperCore- und HyperEVM-Spot mittels einer sendAsset-Aktion (oder über das Frontend) und auf der EVM mittels einer ERC20-Übertragung umgewandelt werden.

Die Übertragung von Token von HyperCore zur HyperEVM kann mit einer sendAsset-Aktion (oder über das Frontend) mit der entsprechenden Systemadresse als Ziel erfolgen. Die Token werden durch eine Systemtransaktion gutgeschrieben, die transfer(recipient, amount) auf dem verknüpften Vertrag als Systemadresse aufruft, wobei recipient der Absender der sendAsset-Aktion ist.

Die Übertragung von Token von der HyperEVM zu HyperCore kann mittels einer ERC20-Übertragung mit der entsprechenden Systemadresse als Ziel erfolgen. Die Token werden der Core auf Basis des vom verknüpften Vertrag ausgegebenen Transfer(address from, address to, uint256 value) gutgeschrieben.

Gehen Sie nicht blind von einer exakten Fungibilität zwischen Core- und EVM-Spot aus. Weitere Einzelheiten finden Sie unter #caveats.

Gas-Kosten

Eine Übertragung von der HyperEVM zu HyperCore kostet ähnlich viel Gas wie die entsprechende Übertragung des ERC20-Token oder von HYPE an eine beliebige andere Adresse auf der HyperEVM, die bereits ein Guthaben aufweist.

Eine Übertragung von HyperCore zur HyperEVM kostet 200k Gas zum Basis-Gaspreis des nächsten HyperEVM-Blocks.

Verknüpfung von Core- und EVM-Spot-Assets

Damit Übertragungen zwischen Core-Spot und EVM-Spot funktionieren, muss die Systemadresse des Tokens auf der anderen Seite das gesamte Nicht-System-Guthaben halten. Um beispielsweise einen ERC20-Vertrag für ein bestehendes Core-Spot-Asset bereitzustellen, sollte der Systemvertrag das gesamte EVM-Spot-Angebot besitzen, das dem maximalen Core-Spot-Angebot entspricht.\ \ Sobald dies geschehen ist, muss der Spot-Deployer eine Spot-Deploy-Aktion senden, um den Token mit der EVM zu verknüpfen:

/**
 * @param token - The token index to link
 * @param address - The address of the ERC20 contract on the evm.
 * @param evmExtraWeiDecimals - The difference in Wei decimals between Core and EVM spot. E.g. Core PURR has 5 weiDecimals but EVM PURR has 18, so this would be 13. evmExtraWeiDecimals should be in the range [-2, 18] inclusive
 */
interface RequestEvmContract {
  type: “requestEvmContract”;
  token: number;
  Address: address;
  evmExtraWeiDecimals: number;
}

Nach dem Senden dieser Aktion speichert HyperCore die ausstehende EVM-Adresse, die verknüpft werden soll. Der Deployer des EVM-Vertrags muss anschließend seine Absicht bestätigen, die Verknüpfung mit dem HyperCore-Token herzustellen, und zwar auf eine von zwei Arten:

1. Wenn der EVM-Vertrag von einer EOA bereitgestellt wurde, kann der EVM-Nutzer eine Aktion mit der Nonce senden, die für die Bereitstellung des EVM-Vertrags verwendet wurde.
2. Wenn der EVM-Vertrag von einem anderen Vertrag bereitgestellt wurde (z. B. create2 über ein Multisig), muss der erste Storage-Slot des Vertrags oder der Slot bei keccak256("HyperCore deployer") die Adresse eines Finalizer-Nutzers speichern.

Um die Verknüpfung abzuschließen, sendet der Finalizer-Nutzer die folgende Aktion (zu beachten ist, dass diese nicht in einer Spot-Deploy-Aktion verschachtelt ist). Im Fall "create" sendet der EVM-Deployer die Aktion. Im Fall "firstStorageSlot" oder "customStorageSlot" muss der Finalizer mit dem Wert im entsprechenden Slot übereinstimmen.

/**
 * @param input - One of the EVM deployer options above
 */
interface FinalizeEvmContract {
  type: “finalizeEvmContract”;
  token: number;
  input: {"create": {"nonce": number}} | "firstStorageSlot" | "customStorageSlot"};
}

Einschränkungen

Derzeit gibt es keine Prüfungen, ob die Systemadresse über ausreichendes Angebot verfügt oder ob der Vertrag ein gültiger ERC20 ist, seien Sie daher beim Senden von Guthaben vorsichtig.

Insbesondere kann der verknüpfte Vertrag beliebigen Bytecode enthalten, daher ist es ratsam zu prüfen, ob seine Implementierung korrekt ist. Es gibt keine Garantien darüber, was der transfer-Aufruf auf der EVM bewirkt, stellen Sie daher sicher, dass Sie den Quellcode und das Gesamtguthaben des verknüpften EVM-Vertrags prüfen.

Wenn der EVM-Vertrag zusätzliche Wei-Dezimalstellen hat und das relevante ausgegebene Log einen Wert enthält, der nicht rund ist (nicht auf extraEvmWeiDecimals Nullen endet), wird der nicht runde Betrag verbrannt (garantiert <1 Wei). Dies gilt sowohl für HYPE als auch für alle anderen Spot-Token.

Mainnet-PURR

Mainnet-PURR ist als ERC20-Vertrag unter 0x9b498C3c8A0b8CD8BA1D9851d40D186F1872b44E mit dem folgenden Code bereitgestellt. Es wird mit PURR auf HyperCore verknüpft, sobald die Verknüpfung im Mainnet aktiviert ist.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";

contract Purr is ERC20Permit {
    constructor() ERC20("Purr", "PURR") ERC20Permit("Purr") {
        address initialHolder = 0x2000000000000000000000000000000000000001;
        uint256 initialBalance = 600000000;

        _mint(initialHolder, initialBalance * 10 ** decimals());
    }
}

Abschließende Hinweise

Beigefügt ist ein Beispielskript für die Bereitstellung eines ERC20-Token auf der EVM und dessen Verknüpfung mit einem Core-Spot-Token.

{% file src="/files/ByYbxCDq0BaOoY6akDhN" %}