Warum Sie einen ERC-20- oder ERC-721-Vertrag nicht direkt auf Solana kopieren können: Die Chains verwenden unterschiedliche architektonische Muster und Verantwortlichkeiten für Metadaten, was sich auf das Design von Minting, Transfers und Tests auswirkt.
Was Sie lernen werden
In dieser Lektion erhalten Sie eine klare konzeptionelle Karte zwischen gängigen ERC-Token-Standards und ihren Solana-Entsprechungen. Wir erklären, wie die Konzepte von ERC-20 und ERC-721 in die fungiblen und nicht-fungiblen Modelle von Solana übersetzt werden, beschreiben die Rolle eines wiederverwendbaren Token-Programms (z. B. das SPL Token Programm) und die Aufteilung zwischen Mint- und Token-Konten und heben hervor, warum Associated Token Accounts für clientseitige Abläufe wichtig sind. Sie werden auch praktische Abwägungen kennenlernen, wenn Sie von einer pro-Vertrag-Logik zu programmgesteuerten Mints wechseln, und wie sich diese Entscheidungen auf die Bereitstellung, das Kontenlayout und das Testen mit Tools wie Anchor auswirken.
Für wen das gedacht ist
Diese Lektion richtet sich an fortgeschrittene Web3-Entwickler, die Erfahrung mit Ethereum-Token-Verträgen und Bereitstellungspipelines haben und Implementierungen sowie Tests nach Solana migrieren.
Wichtige behandelte Themen
- Konzeptuelle Zuordnung: ERC-20 → fungibles Token-Modell auf Solana, ERC-721 → nicht-fungibles Objektmodell
- SPL Token Programm, Mint-Konten und Token (assoziierte) Konten
- Wie sich die Verantwortlichkeiten für Metadaten zwischen Ethereum-Verträgen und Solana-Programmen unterscheiden
- Associated Token Accounts: was sie darstellen und wie man sie verwaltet
- Abwägungen zwischen pro-Vertrag-Token und wiederverwendbaren programmatischen Tokens
Bereit, diese Zuordnungen auf Ihr nächstes Portierungsprojekt anzuwenden? Erfahren Sie mehr und nehmen Sie an unseren Kursen teil unter
https://www.forge.college/