
Wir stellen Surfpool vor: Eine Alternative zum Solana Devnet
In diesem Beitrag stellen wir Surfpool vor, ein Projekt aus dem Helius Startup Launchpad, das beim Radar Hackathon von Colosseum den ersten Platz gewonnen hat und im Solana-Entwicklerökosystem für Aufsehen sorgt.
Zunächst betrachten wir Localnet, Devnet und Mainnet sowie ihre Rollen, Stärken und Schwächen. Anschließend beschäftigen wir uns mit Surfnet und Infrastructure as Code und zeigen, wie Entwickler auf Solana damit schneller, sicherer und zuverlässiger arbeiten können.
Was ist Surfpool?
Surfpool ist ein direkter Ersatz für Localnet-Testumgebungen und wurde speziell entwickelt, um Entwicklern auf Solana die bestmögliche Erfahrung zu bieten. Entwickler können damit Solana-Programme lokal simulieren und dabei Mainnet-Accounts verwenden, die bei Bedarf abgerufen werden.
Surfpool integriert außerdem nahtlos Infrastructure as Code (IaC) in Projekte, die auf Anchor oder Pinocchio basieren. So kannst du reproduzierbare, überprüfbare und sichere Bereitstellungen in jedem privaten oder öffentlichen Solana-Netzwerk durchführen.
Bevor wir uns ansehen, wie Surfpool die Entwicklung auf Solana verbessert, müssen wir die heutige Netzwerklandschaft für Entwickler betrachten.
Solana verfügt über mehrere Cluster – Localnet, Devnet und Mainnet –, die jeweils einem anderen Zweck im Entwicklungszyklus dienen. Diese Umgebungen sind unverzichtbar, bringen aber Kompromisse bei Geschwindigkeit, Zuverlässigkeit und Vertrauen in die Auslieferung von Code mit sich.
Localnet
Localnet bezeichnet eine lokale Instanz der Solana-Blockchain, die normalerweise mit dem Befehl solana-test-validator gestartet wird. Im Wesentlichen handelt es sich um eine private Blockchain, die ohne Netzwerklatenz auf deinem Rechner läuft und dir die vollständige Kontrolle über die Umgebung gibt.
Durch die enge Integration mit dem Anchor-Framework wurde Localnet besonders beliebt. Es bildet die Solana-Laufzeit sehr genau ab und eignet sich daher ideal für schnelle Iterationen und Debugging. Entwickler simulieren damit Transaktionen, validieren Programmlogik, beheben Fehler, setzen den Zustand zurück und iterieren.
Localnets werden auch häufig in Pipelines für Continuous Integration (CI) eingebunden. Teams können damit bei jedem Commit automatisierte Testsuiten ausführen und sicherstellen, dass Änderungen bestehendes Verhalten nicht beeinträchtigen. Das verbessert die Codequalität und deckt Regressionen frühzeitig auf.
Diese Isolation ist jedoch zugleich die größte Einschränkung.
Localnet läuft in einem Vakuum: Es verfügt weder über reale Accounts noch über Zugriff auf Mainnet-Daten oder Interaktionen mit aktiven Protokollen des Ökosystems.
Daher eignet es sich zwar perfekt für isolierte Simulationen, reicht aber nicht aus, um Kompositionsfähigkeit oder vollständige Abläufe unter realistischen Bedingungen zu testen.
Solanas Localnet entspricht den Devnets von Ethereum – einer isolierten lokalen Umgebung für schnelle, private Simulationen.
Solana Devnet
Devnet ist ein öffentliches Solana-Netzwerk, das von der Solana Foundation und einigen von der Community betriebenen Validatoren verwaltet wird. Es bildet die Architektur und das Ausführungsverhalten des Mainnet nach, jedoch ohne wirtschaftliche Risiken.
Token im Devnet haben keinen realen Wert. Entwickler beziehen sie über Faucets – öffentliche Endpunkte, die kleine Mengen an Test-Token für Entwicklungszwecke ausgeben.
Diese Faucets sind normalerweise ratenbegrenzt. Zudem hat jeder Token oft einen eigenen Faucet mit unterschiedlichen Regeln (z. B. den Solana-Faucet von Helius oder den von Circle betriebenen USDC-Faucet). Dadurch ist es mühsam und zeitaufwendig, einen passenden Token-Mix einzurichten.
Devnet dient als gemeinsame, öffentliche Staging-Umgebung. Entwickler simulieren damit Interaktionen zwischen Programmen, testen clientseitiges Verhalten in einer aktiven Umgebung und bereiten Mainnet-Starts vor. Es ist praktisch für Integrationen mit Drittanbietern wie Oracles, DEXs oder Token-Programmen, die in Localnet nicht verfügbar sind.
Da Devnet-RPC-Endpunkte öffentlich verfügbar sind, wird Devnet auch häufig für die Entwicklung und das Debugging von Anwendungs-Frontends verwendet.
Viele Teams nutzen Devnet außerdem für interne Testumgebungen. Größere Protokolle wie Pyth erstellen manchmal „Sandbox“-Bereitstellungen ihrer Anwendungen im Devnet, um Integrationstests für andere Teams zu erleichtern.
Jedes Team legt seine eigene Strategie für Devnet-Bereitstellungen fest. Anders als im Mainnet, wo Protokolle in der Regel geprüft, stabil und aktuell sind, können Bereitstellungen im Devnet veraltet, unvollständig oder falsch konfiguriert sein.
Dadurch ist die Kompositionsfähigkeit eingeschränkt.
Natürlich gibt es verschiedene Ansätze. Manche Teams betreiben eigene interne Devnet-Umgebungen für Staging und Integrationstests. Andere bieten öffentliche Devnets für externe Entwickler und Partner an. Diese individuellen Umgebungen bieten oft mehr Kontrolle, Stabilität oder gezielteren Zugriff als das gemeinsame Solana Devnet.
Solanas Devnet entspricht dem Testnet von Ethereum.
Solana Mainnet-beta
Im Mainnet wird es ernst: Das Netzwerk verarbeitet jede Sekunde Tausende potenziell schädlicher Transaktionen, Token haben realen Wert und jeder Fehler kann teuer werden. Anders als bei Devnet oder Localnet erfordert eine Bereitstellung im Mainnet gründliche Vorbereitung, strenge Sicherheitsmaßnahmen und großes Vertrauen in deinen Code.
Im Betrieb verändert Mainnet alles.
Schlüsselpaare für Bereitstellungen, die häufig in Multisigs oder Hardware-Wallets aufbewahrt werden, müssen streng geschützt sein. Jedes Problem im Bereitstellungsprozess kann schwerwiegende Folgen haben. Du bist nun realen Netzwerkbedingungen ausgesetzt, darunter unvorhersehbarer Datenverkehr, reale Latenz und Interaktionen mit aktiven Nutzern und Assets.
Dafür bietet Mainnet vollständige Kompositionsfähigkeit und die Integration mit jedem relevanten Protokoll. Im Mainnet muss sich dein Programm unter echtem Druck und bei voller Skalierung bewähren.
Wie sich herausstellte, stießen die meisten Entwickler, mit denen wir gesprochen haben, wegen der eingeschränkten Kompositionsfähigkeit des Devnet schnell an Grenzen. Um schneller voranzukommen oder auf präzise Daten zuzugreifen, iterieren sie häufig direkt im Mainnet. Das erhöht das Risiko, verlangsamt Iterationszyklen und verursacht mehr betrieblichen Aufwand. Devnet schafft keine sinnvolle Brücke zwischen den beiden Umgebungen.
Wir stellen Surfnets vor
Surfnet bietet dir die Vorteile lokal ausgerichteter Localnets und stellt zugleich sicher, dass Transaktionen auf den Mainnet-Zustand zugreifen können, ohne einen Node zu synchronisieren.
Damit beantwortet Surfpool die Einschränkungen herkömmlicher Solana-Netzwerke: Surfnet ist eine speziell entwickelte, entwicklerorientierte Umgebung, die die Lücke zwischen Localnet und Mainnet schließt.
Surfpool ruft bei Bedarf aktive Account-Daten über einen beliebigen RPC deiner Wahl ab. Gleichzeitig isoliert und verfolgt es den Zustand deines Programms lokal. So erhältst du vollständige Kontrolle, schnellere Iterationen und eine realitätsnahe Simulationsumgebung.
Dank dieser Architektur verhält sich Surfnet wie ein verzögert geforktes Netzwerk: Beim Lesen kopiert es den Zustand, Änderungen schreibt es lokal. Wie Localnet startet es sofort und ist deutlich schneller. Surfnet-Instanzen sind ressourcenschonend und können sogar auf günstiger Hardware wie einem Raspberry Pi betrieben werden.
Da Surfpool den kanonischen RPC-Vertrag einhält, ist es faktisch mit Wallets, Explorern und CLI-Tools kompatibel, die diese Endpunkte verwenden.
Surfnet-RPC-Methoden
Um die Entwicklung auf Solana weiter zu verbessern, führt Surfnet mehrere RPC-Methoden ein, die sogenannten Cheatcodes. Damit kannst du die Netzwerkregeln für schnellere Iterationen und mehr Kontrolle während Simulationen umgehen. Dazu gehören:
surfnet_setAccount: Füge beliebige Account-Daten in den Netzwerkzustand ein.surfnet_setTokenAccount: Erstelle sofort Token-Accounts mit individuellen Guthaben und Metadaten.surfnet_setMintAccount: Definiere oder überschreibe Mint-Konfigurationen, einschließlich Angebot, Dezimalstellen und Berechtigungen.
Diese Cheatcodes wirken wie Superkräfte für die lokale Entwicklung. Sie ermöglichen Szenarien, die sonst aufwendige Recherche, manuelle Einrichtung und komplexe Skripte erfordern würden.
In Kombination mit Mainnet-Daten geben Cheatcodes Entwicklern beispiellose Möglichkeiten. Ihr lokales Netzwerk hat vollständigen Zugriff auf realen Kontext. Gleichzeitig können sie Regeln nach Belieben anpassen und so umfassende, kontrollierte und äußerst realistische Simulationen erstellen.
Diese scheinbar einfache und unkomplizierte Einrichtung in einem Localnet nachzubilden, würde normalerweise mehrere Tage dauern.
Cheatcode-Fallstudie: The Heist
Um zu zeigen, was mit den Cheatcodes von Surfpool möglich ist, haben wir einen Faucet entwickelt, dem wir den Codenamen The Heist gegeben haben.
Warum dieser Name? Weil es sich anfühlt, als würdest du eine Bank ausrauben – ohne Hürden, ohne Risiko und mit vollständiger Kontrolle. Statte jeden Account sofort mit beliebigen Token aus: SOL, USDC oder individuellen SPLs. Keine Ratenbegrenzungen, keine Wartezeit, keine Drittanbieterdienste. Mit nur einem Befehl bist du liquide.
Faucets waren für Entwickler schon immer ein Problem: langsam, unzuverlässig und über das gesamte Ökosystem verteilt. Mit The Heist haben wir das Prinzip umgedreht. Es ist schnell, lokal und direkt in deine Surfnet-Umgebung integriert.
Das ist nur dank der Architektur von Solana möglich. Das gemeinsam genutzte, vorkompilierte Token-Programm gewährleistet für alle Token ein einheitliches Speicherlayout. Dadurch wird ein solcher universeller Faucet möglich. Auf Plattformen, deren Token-Implementierungen stark variieren, wäre das nicht machbar.
The Heist ist mehr als nur ein Entwicklungswerkzeug. Es zeigt, was schnelle und saubere Simulationen ermöglichen können.
Krypto-Infrastruktur als Code (IaC)
Leistungsfähige Simulationen sind nur ein Teil der Lösung. Surfpool bringt außerdem Infrastructure as Code zu Solana und macht jede Bereitstellung reproduzierbar, automatisiert und sicher, ohne Entwicklern großen Zusatzaufwand zu verursachen.
Krypto-Infrastruktur als Code (IaC) ist ein Thema, das problemlos einen eigenen Beitrag verdient hätte. Über die Jahre haben wir durch praktische Arbeit mit anspruchsvollen Protokollen wie Pyth, Wormhole Core, Circle CCTP, Bitcoin Ordinals und vielen weiteren umfassende Erfahrung in diesem Bereich gesammelt.
Auf hoher Ebene besteht Krypto-Infrastruktur normalerweise aus drei zentralen Komponentenkategorien:
- Onchain-Infrastruktur
- Signaturinfrastruktur
- Offchain-Infrastruktur
Onchain-Infrastruktur
Dazu gehören Bereitstellungen und Upgrades von Programmen sowie Zustandsmigrationen. In einem gut konzipierten IaC-System werden Smart Contracts durch reproduzierbare und überprüfbare Prozesse bereitgestellt. Das gewährleistet Integrität, Versionskontrolle und Nachvollziehbarkeit.
Signaturinfrastruktur
Die meisten Sicherheitsprobleme entstehen bei der Schlüsselverwaltung. Statt sich auf unsichere lokale Schlüsselpaare zu verlassen, nutzen produktionsreife Systeme Hardware-Wallets, Schwellenwertkryptografie oder Multisig-Konfigurationen, um Transaktionen sicher und verantwortungsvoll zu signieren.
In einem gut konzipierten IaC-System sollte die Signaturinfrastruktur modular und konfigurierbar sein. So kannst du von einem fest codierten privaten Schlüssel zu einer komplexen Multisig-Zeremonie wechseln, indem du nur wenige Konfigurationszeilen aktualisierst.
Offchain-Infrastruktur
Dazu gehört alles, was deine Smart Contracts umgibt und unterstützt: Indexer, Zustandsüberwachungen, Wallet-Wächter, Automatisierungsskripte und mehr.
Diese Komponenten sind häufig eng mit Onchain-Ereignissen verknüpft und sollten wie Code behandelt werden: lokal testbar, portabel und vollständig bereitstellbar.
In unserer Vision für Krypto-Infrastruktur als Code schließen wir die Bereitstellung von Nodes und die Verwaltung von RPC-Endpunkten bewusst aus. Bestehende Werkzeuge wie Terraform, Ansible oder cloudnative Lösungen decken diese Aufgaben bereits gut ab. Sie müssen im Rahmen der Infrastruktur auf Anwendungsebene nicht neu erfunden werden.
Vorteile von Krypto-Infrastruktur als Code
Ein gut konzipiertes IaC-System sollte statisch analysierbar sein. Du solltest keinen Code ausführen müssen, um zu verstehen, was er bewirkt.
Du solltest vorab einen vollständigen Ausführungsplan erstellen können. Dieser zeigt detailliert, welche Programme und Signierer beteiligt sind, auf welche Ressourcen zugegriffen wird und welche Kosten entstehen.
Keine JavaScript-basierten DSLs oder undurchsichtigen Shell-Skripte – nur sauberer, deklarativer Code. Er sollte kombinierbar und leicht zu warten sein und nur eine minimale Einarbeitung erfordern.
Mit einem solchen System sollte der Wechsel von Localnet zu Mainnet so einfach sein wie der Austausch der Signaturinfrastruktur: Statt eines lokalen Schlüsselpaars auf dem Datenträger verwendest du einen Squad-Signierer.
Wir haben Monate gebraucht, um den Stack zu entwerfen und zu entwickeln, den wir Web3 Runbooks nennen. Dabei haben wir die Sprache verfeinert, die Bedienung vereinfacht und die Laufzeit sicher und kombinierbar gemacht.
Mit Surfpool möchten wir diese Runbook-Technologie noch zugänglicher und benutzerfreundlicher machen. Gleichzeitig gehen wir weiter, damit Solana-Entwickler auf der bestmöglichen Grundlage aufbauen können.
Indem wir Surfnets und Krypto-Infrastruktur als Code in Surfpool kombinieren, schaffen wir unserer Meinung nach das beste Entwicklerwerkzeug im Web3. Entwickler erhalten einen lokal ausgerichteten Stack und können mit zunehmender Reife ihres Protokolls schrittweise zum Mainnet wechseln, indem sie einfach ihre IaC-Konfiguration anpassen.
Um den Kreis zu schließen und zu den Netzwerken zurückzukehren: Surfnets lassen sich über Infrastructure as Code definieren und verwalten. Entwickler können dadurch problemlos kurzlebige Netzwerke starten, die bereits mit Hunderten von Accounts vorkonfiguriert sind. Diese Accounts verfügen schon über die passenden Token-Mixe (SOL, USDC usw.), die für Interaktionen mit ihren Protokollen nötig sind.
Ressourcen und Dokumentation
Für einen 45-minütigen tiefen Einblick in Surfpool empfehlen wir diese von Jacob Creech, Head of Developer Relations bei der Solana Foundation, moderierte Folge des Solana Changelog.
Außerdem veröffentlichen wir eine Reihe kurzer Screencasts, die Entwicklern den Einstieg in Surfpool mit kurzen, praxisorientierten Einheiten erleichtert.
Unsere vollständige Dokumentation findest du unter docs.surfpool.run.
Fazit
Der Weg vor uns ist lang, aber die Zukunft sieht vielversprechend aus. Entwickler zeigen bereits großes Interesse an Surfpool. Ihr Feedback bestärkt uns in der Überzeugung, dass wir etwas Unverzichtbares entwickeln.
Dabei kratzen wir bisher nur an der Oberfläche.
Unser Ziel ist es, Mainnet-Simulationen zu schaffen, die nicht von der Realität zu unterscheiden sind.
Derzeit berücksichtigt Surfpool noch nicht alle kritischen Aspekte. Dazu gehören Konflikte und Priorisierung bei Transaktionen sowie schädliche Verhaltensweisen wie MEV und Sandwich-Angriffe.
Wir freuen uns auf die nächsten Schritte. Surfpool verändert bereits, wie Menschen auf Solana entwickeln – und wir werden es konsequent weiter vorantreiben.
Ähnliche Artikel
Helius abonnieren
Bleib bei der Solana-Entwicklung auf dem Laufenden und erhalte Updates, wenn wir neue Beiträge veröffentlichen


