Kernpunkte
- HyperCore bündelt Marktfunktionen, HyperEVM ermöglicht Smart Contracts für allgemeine Zwecke.
- HyperEVM nutzt HYPE als Gas und ist Teil des HyperBFT-Konsenses.
- Die Übergänge zwischen beiden Umgebungen erfordern eine gezielte Nachverfolgung von Salden und Vorgängen.
Was ist Hyperliquid?
Hyperliquid verbindet Marktinfrastruktur mit einer Plattform für Smart Contracts innerhalb eines Layer-1-Netzwerks. HyperCore umfasst Orderbücher und Marktoperationen. HyperEVM erlaubt die Entwicklung EVM-kompatibler Logik und den Aufbau von Anwendungen, die mit dem Ökosystem interagieren.
Die Spezifikation muss die Komponente benennen, die jede Funktion übernimmt. Preise abfragen, eine Order senden und einen Solidity-Smart-Contract ausführen sind unterschiedliche Vorgänge. Ein Produkt kann mehrere Schnittstellen benötigen, und jede bringt Berechtigungen und Zustände mit, die im Datenmodell der Anwendung abgebildet sein müssen.
So funktioniert es
HyperBFT trägt den Konsens des Netzwerks. Die Ausführung verteilt sich auf die Funktionen von HyperCore und die EVM-Blöcke von HyperEVM. Letzteres bietet JSON-RPC-Zugang und verwendet HYPE für die Gebühren seiner Smart Contracts.
Die Integration muss Bewegungen zwischen den Umgebungen, Marktaktionen und EVM-Transaktionen getrennt behandeln. Eine isolierte Saldoabfrage ersetzt nicht den Abgleich des gesamten Ablaufs. Es empfiehlt sich, ausreichend Kennungen und Zustände zu speichern, um einen Vorgang nach einem Verbindungsverlust rekonstruieren zu können, ohne anzunehmen, dass alle Komponenten gleichzeitig aktualisiert werden.
Die Schnittstellen zwischen HyperCore und HyperEVM erfordern eine Prüfung ihrer Regeln für Lesen, Schreiben und Übertragung von Vermögenswerten. Es sollte nicht angenommen werden, dass eine Abfolge zwischen beiden Umgebungen die Atomarität eines einzelnen EVM-Aufrufs hat. Das System bewahrt ausreichend Referenzen, um einen ausstehenden Schritt zu erkennen und ihn getrennt von einem abgeschlossenen Vorgang darzustellen.
Was Hyperliquid leistet
Hyperliquid kann für Tools infrage kommen, die die Märkte von HyperCore abfragen oder integrieren müssen, oder für Solidity-Anwendungen, deren Anwendungsfall HyperEVM erfordert. Die Entscheidung sollte sich an diesem konkreten Bedarf orientieren, nicht allein an der Aktivität im Ökosystem.
Bei Metlabs grenzen wir Lese- und Ausführungsrechte ab, bevor wir die Integration entwerfen. Die Prototypen decken je nach Fall Übermittlung, Teilergebnis, Stornierung und Wiederherstellung ab. Stellt das Produkt Finanzoperationen bereit, werden deren Bedingungen und Kontrollen getrennt von der technischen Anbindung an das Netzwerk definiert.
Für ein Monitoring-Tool kann eine reine Leseintegration ohne Handelsfunktion ausreichen. Kommt später die Übermittlung von Orders hinzu, ändern sich Berechtigungsumfang und Tests: Limits, Kennungen zur Vermeidung von Duplikaten, Ablauf von Autorisierungen und Wiederherstellung nach einer unklaren Antwort. Beobachtung und Ausführung getrennt zu halten, erleichtert die Prüfung, was jede Zugangsberechtigung darf und welche Kontrollen das verantwortliche Team benötigt.
Grenzen und Auswahlkriterien
Eine Marktschnittstelle und ein EVM-Smart-Contract folgen nicht denselben Ausführungsannahmen. Vermögenswerte können Repräsentationen und Salden haben, die in jeder Umgebung eine spezifische Behandlung erfordern. Die Tests sollten sich auf diese Grenzbereiche und auf das Verhalten bei Fehlern oder Verzögerungen konzentrieren.
Die EVM-Kompatibilität beseitigt keine Risiken der Smart Contracts, des Netzwerks oder der Komponenten, die Vermögenswerte verbinden. Eine Anwendung ohne Abhängigkeit von HyperCore kann in einem anderen EVM-Netzwerk einfacher aufgehoben sein. Zu den Auswahlkriterien zählen funktionaler Bedarf, Berechtigungsumfang und die Fähigkeit, jede Operation zu überwachen.
