Truffle

Truffle ist ein Entwicklungsframework für EVM-Contracts, das in Legacy-Projekten anzutreffen ist. Sein Workflow kombiniert Kompilierung, Tests, Contract-Artefakte und Migrationsskripte. Ganache stellte ein zu diesem Ökosystem gehörendes lokales Netzwerk bereit, um Vorgänge während der Entwicklung auszuführen.

Consensys kündigte 2023 die Einstellung von Truffle und Ganache an. Dieses Profil behandelt daher vor allem Wartung und Migration bestehender Anwendungen. Bei der Wahl einer Umgebung für neuen Code sollten gepflegte Werkzeuge und die Kompatibilität mit den aktuellen Anforderungen des Projekts berücksichtigt werden.

Ein Truffle-Projekt enthält die Konfiguration von Netzwerken und Compilern, Contracts und Migrationsskripte, die Deployment-Schritte beschreiben. Die Artefakte verknüpfen ABI, Bytecode und Adressen pro Netzwerk. In einem bestehenden System helfen diese Dateien und Aufzeichnungen zu rekonstruieren, was mit welchen Parametern deployt wurde.

Vor einem Werkzeugwechsel wird in einer kontrollierten Umgebung eine Test-Baseline ausgeführt. Außerdem werden Plugins, Zahlenformate, Entwicklungskonten und Ganache-Abhängigkeiten inventarisiert. Die Kompatibilität einer bestimmten Version sollte nicht allein daraus abgeleitet werden, dass der Contract in Solidity geschrieben ist.

Als Ziel der Migration kommen Hardhat, Foundry oder eine andere für das Team geeignete Umgebung infrage. Zunächst wird die Kompilierung reproduziert, danach werden Tests und Skripte portiert und die Ergebnisse verglichen. Optimizer-Einstellungen, gelinkte Bibliotheken und die EVM-Version beeinflussen die Artefakte und müssen bewusst beibehalten oder geändert werden.

Ein bereits deployter Contract muss nicht neu deployt werden, nur weil das Framework im Repository wechselt. Die Arbeit besteht darin, die Fähigkeit zu erhalten, ihn zu testen, zu betreiben und seinen Code zu verifizieren. Wird zusätzlich die Implementierung geändert, hat diese Änderung einen eigenen Umfang und erfordert eine Prüfung ihrer Kompatibilität mit dem bestehenden Zustand.

Eine Migrationsschätzung hängt von Umfang und Qualität der Tests, der Nutzung von Plugins und der Dokumentation der Deployments ab. Eine universelle Dauer gibt es nicht. Zunächst sollte ermittelt werden, welche Skripte weiterhin benötigt werden und welche nicht wiederholbare Vorgänge enthalten, die nicht erneut ausgeführt werden dürfen.

Der Umstieg gilt als abgeschlossen, wenn das Team mit dem neuen Werkzeug kompilieren, die relevanten Tests ausführen und die unterstützten Netzwerke betreiben kann. Historische Referenzen werden für Vorfälle und technische Audits aufbewahrt. Befehle zu ändern, ohne die Verhaltensäquivalenz zu prüfen, lässt den wichtigsten Teil der Migration offen.