Einleitung
Als ich mit der Entwicklung mit Solidity anfing, habe ich bald Online-IDEs aufgegeben und Hardhat als mein neues Hauptframework übernommen. Nach einigen Monaten der Projektentwicklung und der Erstellung eines entsprechenden Workflows fühlte ich mich mit dem Netzwerk-Layout, der Teststrategie und der Projektorganisation wohl.
Als jemand meinte, dass die Leistungsvorteile von Foundry echt beeindruckend seien, wurde ich neugierig und wollte mal die beiden beliebten Frameworks für die Entwicklung von Smart Contracts richtig vergleichen.
Um eine faire Bewertung zu machen, habe ich mit beiden Tools die gleichen Projekte erstellt und denselben MiniBank-Vertrag sowie weitere Test-Einstellungen verwendet. Diese praktische Erfahrung hat gezeigt, dass sich die Leistung, die Erfahrung der Entwickler und der Arbeitsablauf zwischen diesen beiden Tools stark unterscheiden, was jeder berücksichtigen sollte, der sich zwischen den beiden entscheiden muss.
Projektarchitektur und Einstellungen
Die ersten Schritte beim Einrichten sind bei den beiden Frameworks ziemlich unterschiedlich. Foundry erstellt eine foundry.toml-Konfigurationsdatei, die auf Schlüssel-Wert-Paaren basiert und der hardhat.config.js-Datei von Hardhat ähnelt. Beide unterstützen auch die Anpassung von Quellordnern, Kompilierungsausgabeverzeichnissen usw.
Die Standardordnerstruktur ist in Foundry ziemlich anders, aber mehrere Netzwerke können nicht direkt in der Konfigurationsdatei eingerichtet werden, da Hardhat super bei der Verwaltung mehrerer Netzwerke ist. Die restlichen Parameter in foundry.toml sind mit Testoptionen verbunden, darunter Ausführlichkeit oder Kontoeinstellungen und Gaspreisoptionen.
Die Remapping-Funktion von Foundry ist echt interessant, weil sie einen starken Ansatz für den Import von Abhängigkeiten bietet. Du kannst den Import von Verträgen viel einfacher machen, indem du in der Konfiguration Verknüpfungen erstellst.
Anstatt zum Beispiel lange Importpfade zu schreiben, kannst du kurze Hand-Mappings verwenden, die deinen Code lesbarer und wartungsfreundlicher machen.
Ansätze zum Abhängigkeitsmanagement
Die Frameworks unterscheiden sich stark in der Art und Weise, wie sie Abhängigkeiten verwalten:
- Hardhat nutzt das etablierte npm-Ökosystem, das für JavaScript-Entwickler sofort zugänglich ist
- Die Installation von OpenZeppelin-Verträgen ist nur ein npm-Installationsbefehl
- Foundry nutzt das Abhängigkeitsmanagement von Git-Submodulen über das Forge-CLI-Tool
- Abhängigkeiten werden in einem Ordner „lib/“ gespeichert und in einer Datei „.gitmodules“ angehängt, im Gegensatz zu „package.json“
Diese Methode funktioniert mit jedem GitHub-Repository, das Smart Contracts als Abhängigkeit hat, und gibt dir mehr Flexibilität bei der Auswahl der Bibliotheken.
Du kannst den Namen der GitHub-Organisation und des Repositorys angeben und optional den zu installierenden Branch oder Tag festlegen. Sobald die Forge installiert ist, kannst du mit dem Befehl „forge remapping“ die Standard-Importpfade anzeigen, die Foundry verwendet und die dann mit Konfigurationsdateien weiter angepasst werden können.
Entwicklungs- und Debugging-Tools
Einer der Bereiche, in denen Hardhat besonders gut abschneidet, ist die Debugging-Erfahrung. Das Framework bietet standardmäßig auch die Verwendung von console.log, was dem erwarteten Debugging-Stil in der JavaScript-Entwicklung ähnelt. Diese Funktion wird stark als Verkaufsargument beworben und kann von Entwicklern leicht nachverfolgt werden, um zu verstehen, wie die Ausführung durchgeführt wurde und was falsch ist.
Foundry braucht eine andere Methode, um Verträge zu protokollieren. Man kann Hardhat zwar manuell installieren und importieren und einen Konsolenvertrag einrichten, aber am besten kopiert man einen speziellen Konsolenvertrag in dein Projekt.
Besonders bei Testdateien enthält der DSTest-Vertrag Protokollierungsereignisse wie logstring, logint und logaddress, die ohne zusätzliche Abhängigkeiten ausgegeben werden können.
Testmethoden
Die Testerfahrung ist vielleicht der auffälligste Unterschied zwischen den beiden Frameworks.
Hardhat-Testansatz
Hardhat basiert auf Standard-JavaScript-Testmustern:
- Nutzt describe- und it-Blöcke zusammen mit Mocha als Standard-Assertion-Bibliothek.
- Testdateien können diesem natürlicheren Stil von Entwicklern ähneln, die mit der Webentwicklung vertraut sind.
- Bietet beschreibende Testnamen, die den Zweck klar zum Ausdruck bringen.
- Bekannte asynchrone Muster
- Für Leute, die sich schon mit moderner Webentwicklung auskennen, ist die Lernkurve echt gering.
Testansatz für Foundry
Foundry funktioniert ganz anders:
- Tests werden als Solidity-Smart-Contracts entwickelt, die DSTest erben
- Alle Tests haben das Wort test oder testFail als Präfix
- Alle Aussagen werden über den geerbten DSTest-Vertrag gemacht
- Testdateien sind echte Smart Contracts, die beim Testen verwendet werden
Master Smart Contract Testing
Vergleich die Frameworks und such den besten Testansatz für dein Projekt aus.
Die Foundry-Methode hat ein paar Auswirkungen:
- Testverträge müssen in einer setUp()-Prozedur instanziiert werden, ähnlich wie beforeEach in JavaScript-Kunden
- Die Vertragsmethodenverteilung von ETH erfordert eine bestimmte Syntax mit Wertparametern, die in geschweiften Klammern stehen
- Die anfänglich steile Lernkurve kann dadurch ausgeglichen werden, dass keine asynchronen Vorgänge bearbeitet werden müssen
Lernplattform Testfunktionen
Foundry hat das Konzept der sogenannten Cheat-Codes eingeführt, die echt nützliche Testfunktionen bieten. Das sind spezielle Funktionen an einer bestimmten Vertragsadresse, mit denen du während des Testens auf den Status in der Blockchain zugreifen kannst.
Du darfst:
- Ändere die aktuelle Blocknummer nicht.
- Gib dich nicht als jemand anderes aus
- Bestimmte Vertragsbedingungen geltend machen
Um Cheat-Codes zu verwenden, musst du eine Schnittstelle definieren und sie als Statusvariable für die spezielle Adresse des Cheats instanziieren. Nach der Einrichtung kannst du mit Funktionen wie den folgenden cheaten:
- vm.prank(), um den nächsten Vertragsaufruf auf einen anderen Empfänger zu setzen
- vm.roll(), um die Blockchain bis zu einem bestimmten Punkt voranzutreiben
Einer der interessantesten Cheat-Codes ist vm.expectRevert(), den du vor der Transaktion aufrufen musst, die fehlschlagen soll. Diese Umkehrung der üblichen Assertion-Muster mag erstmal verwirrend sein, gibt dir aber eine klare Kontrolle über die wahrscheinlichen Fehlerbedingungen.
Ergebnisse des Leistungsvergleichs
Die Leistungsunterschiede zwischen den Frameworks sind echt groß und sofort erkennbar. Bei denselben Verträgen und Testszenarien habe ich aufschlussreiche Ergebnisse zur Kompilierungs- und Testausführungszeit bekommen:
Ergebnisse des Leistungsvergleichs
| Szenario | Foundry | Hardhat |
|---|---|---|
| Projekte bereinigen (kein Cache) | 1,44 Sekunden | 5,17 Sekunden |
| Bei aktiviertem Caching | 0.45 Sekunden | 3,98 Sekunden |
| 26 Smart-Contracts-Projekt | 8.53 Sekunden | 14.56 Sekunden |
Diese Leistungsunterschiede werden deutlicher, wenn das Projekt komplexer wird.
Foundry-Tests: Vorteile und Nachteile
Vor- und Nachteile von Foundry-Tests
| Vorteile | Nachteile |
|---|---|
| Keine Komplexität durch async/await | Die Namen der Tests sind nicht so aussagekräftig wie in JavaScript-Tests |
| Die Tests laufen echt schnell. | die expectRevert-Assertion ist nicht ganz logisch |
| Automatisch generierter Gasbericht | Lernkurve für Cheat-Codes |
| Alles, was in Solidity geschrieben ist | Die Bereitstellungstools sind noch in der Entwicklung. |
Die Vorteile der Leistung sind kaum zu bestreiten, und die Solidity-Testnamen können nicht so aussagekräftig sein wie die von JavaScript, was zu Unklarheiten hinsichtlich der Testabsicht führen kann. Das Cheat-Code-System ist zwar leistungsstark, erfordert jedoch einen gewissen Lernaufwand zu Beginn.
Strategien zur Vertragsbereitstellung
Bei der Bereitstellung hat Hardhat derzeit eine bessere Entwicklererfahrung. Das Framework akzeptiert:
- JavaScript-basierte Bereitstellungsskripte
- Verbindung mit verschiedenen Netzwerken
- Lade die Konfiguration über Umgebungsvariablen.
- Geh mit komplizierten Bereitstellungssituationen locker um.
JavaScript-basierte Bereitstellungsskripte sind derzeit in Foundry erforderlich, können aber umständlich sein, wenn Konstruktoren ihre Argumente bereitgestellt bekommen müssen. Die vorgeschlagene Lösung besteht darin, Bash-Skripte für die Bereitstellung zu entwickeln, um die Komplexität der Bereitstellungen zu bewältigen, aber das Entwicklungsteam arbeitet gerade an der Entwicklung fortschrittlicherer Bereitstellungslösungen.
Das ist einer der größten Schwachpunkte von Foundry im Vergleich zu Hardhat, das ein ausgebautes Bereitstellungs-Ökosystem hat.
Befehlszeilen-Tools
Foundry hat das cast CLI-Tool, mit dem du mit der Blockchain interagieren und Smart Contracts abfragen kannst. Das ist ein echt nützliches Tool, mit dem du:
- Ruf Vertrags-Funktionen auf
- Blockchain-Status abfragen
- Mach verschiedene Blockchain-Aktionen über die Befehlszeile
Obwohl Cast alle Funktionen für die Interaktion mit der Blockchain bietet, braucht man komplexe Befehlszeilen, um komplizierte Vorgänge durchzuführen. Ähnlich wie beim Deployment kann man hier Bash-Skripte brauchen, um zu vermeiden, dass man lange Befehle immer wieder eingeben muss.
Zusammenfassung des Framework-Vergleichs
Vergleich der Framework-Funktionen
| Funktion | Foundry | Hardhat |
|---|---|---|
| Installation | Über den CLI-Befehl „curl“ | Nicht nötig mit npx oder über npm |
| CLI-Tools | Forge zum Verwalten des Projekts, Cast zum Interagieren mit Verträgen | hardhat-Projekt verwalten (Skripte erstellen/kompilieren/ausführen) |
| Erstellen und Testen der Leistung | Außergewöhnliche Geschwindigkeit | Moderate Leistung |
| Abhängigkeiten | Git-Submodule | npm-Pakete |
| Konfiguration | foundry.toml | hardhat.config.js |
| Teste die Isolierung | Ja, über -match-test -match-contract | Ja, nur über oder überspringen in Testdateien |
| Vertragsbereitstellungen | Über das Cast-CLI-Tool | JavaScript-basierte Skripte |
Die richtige Wahl treffen
Foundry hat echt großes Potenzial mit seiner super Leistung, der engagierten Community und der kreativen Art, Smart Contracts zu testen. Die Struktur ist super für schnelle Entwicklungszyklen und hat tolle Testfunktionen, die die Entwicklung echt beschleunigen können, wenn man erst mal weiß, wie man sie benutzt.
Trotzdem entwickelt sich Foundry weiter, vor allem bei den Tools für die Bereitstellung und den Verbesserungen für Entwickler. Foundry hat ein paar interessante Vorteile für Entwickler, die ein Hybridmodell bevorzugen, mit:
- Foundry für Vertragsentwicklung und -prüfung
- Hardhat für Bereitstellung und Skripte
Leute, die mit Standard-JavaScript-Tools und gängigen Bereitstellungspraktiken besser vertraut sind, können jetzt vielleicht produktiver mit Hardhat arbeiten, aber die Entscheidung hängt wieder von deinem Hintergrund und deiner Fähigkeit ab, dich mit neueren Tools auseinanderzusetzen.
Beide Architekturen entwickeln sich immer noch schnell weiter, und das Ökosystem der Smart-Contract-Entwicklung hat viele gute Alternativen, die den Bedürfnissen verschiedener Entwickler und Anwendungsfälle gerecht werden.
