AvalancheGo im Detail: der Go-Knoten für das Avalanche-Netzwerk
Go-Implementierung eines Avalanche-Knotens. Wenn Sie AvalancheGo aus dem Quellcode erstellen möchten, benötigen Sie außerdem die folgende Software: Go-Version >= 1.25.10 gcc g++ Erstellen aus dem Quellcode. Klonen Sie das Repository. Klonen Sie das AvalancheGo-Repository: Dadurch wird der Hauptzweig geklont und ausgecheckt.
Auf einen Blick
- Was ist das?
- Hardwareanforderungen, Installationswege über APT und Docker, Bootstrapping-Dauer, Versionssemantik und Supportstufen des Referenzknoten ava-labs/avalanchego im Überblick.
- Für wen ist es gedacht?
- AvalancheGo passt zu Betreibern, die einen Avalanche-Knoten auf eigener Infrastruktur laufen lassen wollen, sei es als Validator-Vorbereitung auf dem Mainnet, als Testknoten im Fuji-Testnetz oder als lokale Netzwerkumgebung über avalanche-cli, und die die dokumentierten Hardwarewerte von 16 GiB RAM und 1 TiB Speicher bereitstellen können.
- Darf ich es kommerziell nutzen?
- Ja. BSD-3-Clause ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 4 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
AvalancheGo als Go-Knoten für eine Blockchain-Plattform
AvalancheGo ist die Go-Implementierung eines Knotens für das Avalanche-Netzwerk, eine Blockchain-Plattform, die das README mit hohem Durchsatz und schnellen Transaktionen umschreibt. Zahlen dazu stehen im README keine, solche Aussagen bleiben der Marketingseite avax.network überlassen. Das Repository ava-labs/avalanchego zählt in den vorliegenden Metadaten 2.356 Sterne und 862 Forks bei 339 offenen Issues, die BSD-3-Clause-Lizenz gilt, sofern kein Unterprojekt im graft-Verzeichnis etwas anderes angibt.
Wichtig für die Bewertung ist die Rolle des Projekts: AvalancheGo ist vor allem ein Netzwerkclient, wie die Versionierung zeigt, die sich an Netzwerk-Upgrades orientiert, nicht an Softwarefeatures. Der letzte verzeichnete Push im Metadatenbestand liegt am 21. Juli 2026, parallel erschien die Release-Nummer v1.15.0-fuji mit dem Namen Helicon und dem Untertitel Continuous Execution und Auto-Renewed Staking, ausdrücklich als Pre-Release für das Fuji-Testnetz markiert. Davor lagen Granite.2 mit einem Benchlist-Redesign und Granite.1 mit dem Titel Grafting EVM Repos.
Hardware für Mainnet-Knoten: 16 GiB RAM und 1 TiB Speicher
Das README nennt die empfohlene Mindestausstattung für einen Knoten am Mainnet konkret: eine CPU auf dem Niveau von 8 AWS-vCPUs, 16 GiB RAM und 1 TiB Speicher. Als Betriebssysteme sind Ubuntu 22.04 oder 24.04 sowie macOS 12 oder neuer zugelassen, dazu eine zuverlässige IPv4- oder IPv6-Verbindung mit offenem öffentlichem Port. Der 1-TiB-Wert trägt einen Vorbehalt: Knoten mit sehr langer Laufzeit oder benutzerdefinierten Konfigurationen können höheren Speicherbedarf beobachten.
Damit steht AvalancheGo in der Mitte des Spektrums: leichtgewichtiger als Archivknoten großer E2-Ketten, aber kein Einplatinen-Thema. Wer den Knoten aus dem Quellcode bauen will, benötigt zusätzlich Go ab Version 1.25.10 sowie gcc und g++. Das README warnt ausdrücklich, dass sich die Hardwareanforderungen mit zunehmender Netzwerknutzung ändern können, die Werte sind also eine Momentaufnahme mit Haltbarkeitsdatum, kein dauerhaftes Versprechen.
Installationswege: APT-Repo, run_task.sh und der Docker-Image-Build
Vier Wege führen zur lauffähigen Binärdatei. Der Quellbuild beginnt mit git clone git@github.com:ava-labs/avalanchego.git, danach läuft ./scripts/run_task.sh build, und die fertige Datei liegt unter build/avalanchego. Unter Ubuntu geht es schneller über das APT-Repository: Der Schlüssel kommt von downloads.avax.network nach /etc/apt/trusted.gpg.d/avalanchego.asc, die Quellenliste unter /etc/apt/sources.list.d/avalanche.list nutzt die Variable UBUNTU_CODENAME, dann folgt sudo apt install avalanchego.
Der dritte Weg ist der Binärdownload von der Release-Seite, die ausführbare Datei heißt avalanchego. Viertens gibt es Docker: ./scripts/run_task.sh build-image erzeugt ein Image mit dem Tag avaplatform/avalanchego plus gekürztem Commit-Hash, das per docker run mit den gemappten Ports 9650 und 9651 startet, der API-Port und der P2P-Port des Knotens. Für Evaluierungen ist der APT-Pfad der bequemste für Updates, für Versuche mit eigenen Patches bleibt nur der Quellbuild, und der Docker-Weg trennt den Knoten sauber vom Host.
Mainnet, Fuji und avalanche-cli: drei Betriebsmodi des Knotens
Die Befehlsfläche ist klein. Die Binärdatei ohne Argumente verbindet sich mit dem Mainnet, das README verspricht ASCII-Art und Logmeldungen, und Strg+C beendet den Prozess. Für das Fuji-Testnetz reicht ./build/avalanchego --network-id=fuji. Das lokale Testnetz gehört dagegen nicht mehr zum avalanchego-Binary selbst, sondern zum Schwesterprojekt avalanche-cli: avalanche network start bring eine lokale Umgebung hoch, avalanche network status zeigt deren Zustand.
Diese Aufteilung ist praktisch relevant. Wer Smart-Contract-Experimente oder Netzwerktopologien testen will, sollte avalanche-cli einsetzen und avalanchego unberührt lassen, denn das CLI verwaltet mehrere Knoten automatisch. Wer Produktionsinfrastructure vorbereitet, arbeitet direkt mit dem Binary oder dem APT-Paket. Weitere Netzwerkauswahl-Flags und Konfigurationsdatei-Details listet das README nicht auf, die vollständige Konfigurationsdokumentation liegt außerhalb dieser Datei, was man bei der Planung einplanen sollte.
Bootstrapping dauert Tage: Datenbank-IO als Engpass
Der ehrlichste Abschnitt des README behandelt den ersten Start. Ein neuer Knoten muss den aktuellen Netzwerkzustand einholen, bevor er am Konsens teilnehmen oder API-Aufrufe bedienen kann. Das README nennt diesen Vorgang Bootstrapping und schätzt die Dauer für einen neuen Mainnet-Knoten auf derzeit mehrere Tage. Bis dahin meldet der Knoten über die Health-API kein healthy, wer das als Fehler irrtümlich behandelt, sucht am falschen Ende.
Der typische Engpass liegt laut README in der Datenbank-IO. Eine stärkere CPU oder höhere Datenbank-IOPS verkürzen die Wartezeit messbar, was die Hardwareempfehlungen aus dem Abschnitt davor erklärt: Der 1-TiB-Speicher muss schnell genug sein, nicht nur groß. Verbesserungen zur Verkürzung der Bootstrapping-Zeit sind laut Angabe in Entwicklung. Für die Planung heißt das, einen Knoten mit Vorlauf aufsetzen und die erste Woche nicht in engen Zeitfenstern planen, in denen der Knoten bereits produktiv antworten soll.
Versionssemantik von AvalancheGo und die drei Supportstufen
Die Versionsnummern folgen der Netzwerkversion, nicht der Softwarelogik: v0.x.x kennzeichnet eine Entwicklungsnetzwerkversion, v1.x.x eine Produktionsversion, die mittlere Zahl zählt Netzwerk-Upgrades, die Patch-Zahl Client-Upgrades seit dem letzten Upgrade. Eine unmittelbare Konsequenz: Exportierte Paketschnittstellen können sich laut README auch in Patch-Releases ändern, weil die Versionszählung der Netzwerkkompatibilität dient. Wer AvalancheGo als Go-Bibliothek einbindet, liest daher docs/external_consumption.md, denn das Projekt besteht aus mehreren Go-Modulen, die nur in passenden Versionen gemeinsam genutzt werden sollten. Beim Betrieb exponierte APIs bleiben dagegen abwärtskompatibel, außer nach expliziter Abkündigung.
Die Plattformunterstützung ist in drei Stufen gegliedert. Stufe 1 ist vollständig unterstützt und besteht alle Tests einschließlich E2E- und Stresstests, dazu gehören derzeit amd64 Linux und arm64 Linux. Stufe 2 besteht Unit- und Integrationstests, aber nicht zwangsläufig E2E-Tests, hier steht arm64 Darwin. Stufe 3 baut, gilt aber als experimentell. Als nicht unterstützt listen die Metadaten amd64 Darwin, amd64 Windows, arm Linux und i386 Linux. Für Protobuf-Codegenerierung benötigen Mitwirkende buf v1.31.0, protoc-gen-go v1.33.0 und protoc-gen-go-grpc v1.3.0, die Konventionen für Dokumentation im Repository stehen in docs/documentation-guidelines.md.
Redaktionelles Fazit
AvalancheGo passt zu Betreibern, die einen Avalanche-Knoten auf eigener Infrastruktur laufen lassen wollen, sei es als Validator-Vorbereitung auf dem Mainnet, als Testknoten im Fuji-Testnetz oder als lokale Netzwerkumgebung über avalanche-cli, und die die dokumentierten Hardwarewerte von 16 GiB RAM und 1 TiB Speicher bereitstellen können. Ungeeignet ist es, wer einen Kryptoknoten ohne offenen öffentlichen Port betreiben will oder mehrere Tage Wartezeit beim ersten Bootstrapping nicht einkalkulieren kann. Vor dem Produktiveinsatz sollte man die eigene Plattform gegen die Supportstufen prüfen, nach dem Start den Zustand über die Health-API beobachten und beim Quellbuild die Go-Version gegen die geforderte 1.25.10 kontrollieren.
Community-Notizen