Amaru als Rust-Implementierung für Client-Diversität und Node 11.2 als Vorbereitung für die Dijkstra-Ära

9. November 2026 Kryptowährungen
Ein Server mit kupferfarbener Oberfläche steht neben einem transparenten Tank und verflochtenen Glasfaserkabeln in einem

Ende Oktober und Anfang November 2026 stellte das Cardano-Ökosystem zwei technische Meilensteine vor: Der zweite Block-Producer-Node Amaru erhielt am 5. November 2026 die Berechtigung, im Mainnet Blöcke zu erzeugen, und die neue Node 11.2.0 wurde als Test-Node für das bevorstehende Dijkstra-Testnet veröffentlicht. Beide Entwicklungen zielen darauf ab, die Resilienz des Netzwerks zu erhöhen und die Basis für die nächste Protokoll-Ära (Protocol Version 12) zu legen.

Amaru – Rust-basierte Alternative zum Haskell-Node

Technische Grundlagen und Entwicklungsorganisation

Amaru ist eine Open-Source-Node-Implementierung, die in der Programmiersprache Rust geschrieben wurde. Die Entwicklung erfolgt unter der Führung der Open-Source-Allianz PRAGMA in Zusammenarbeit mit der Cardano Foundation. Damit entsteht die erste produktionsreife Node-Alternative zur primären Haskell-Codebasis des offiziellen cardano-node.

  • Entwicklungssprache: Rust (Jahr 2026, Hinweis: Alternative zur primären Haskell-Codebasis)
  • Entwicklerorganisation: PRAGMA (Open-Source-Allianz)
  • Projektziel: Reduktion systemischer Ausfallrisiken durch Diversifizierung der Client-Software

Mainnet-Freigabe für Blockproduktion am 5. November 2026

Nach monatelangem Testbetrieb als Relay-Knoten wurde Amaru am 05.11.2026 für die aktive Blockerzeugung auf dem Cardano-Mainnet freigeschaltet. Die Freigabe ist dokumentiert in den offiziellen GitHub-Release-Infos von PRAGMA (Quelle S1).

  • Freigabedatum für Blockproduktion: 05.11.2026
  • Erweiterung von Relay-Funktionen auf aktive Blockerzeugung

Bedeutung für Netzwerk-Resilienz

Durch die Einführung einer zweiten, in Rust geschriebenen Client-Implementierung wird die bisherige Monokultur des Haskell-Clients aufgebrochen. Die Diversifizierung verringert das Risiko von Chain-Splits, weil eventuelle Bugs in einer Implementierung nicht das gesamte Netzwerk lahmlegen. Dennoch besteht ein geringfügiges Risiko während der Anfangsphase, wenn noch nicht alle Edge-Cases getestet sind (siehe “Split- und Fehlerrisiko bei Multi-Client-Architekturen”).

  • Reduktion systemischer Ausfallrisiken
  • Erhöhte Fehlertoleranz gegenüber Software-Monokulturen
  • Potential für minimale Chain-Splits, wenn Konsensverhalten leicht abweicht

Node 11.2 – Test-Node für die Dijkstra-Hard-Fork

Release-Status und Tag-Datum

Die Version 11.2.0 des offiziellen Cardano-Nodes wurde von Intersect MBO am 27.10.2026 auf GitHub getaggt. Sie befindet sich im Pre-Release- bzw. Test-Node-Status und ist noch kein finaler Hard-Fork-Kandidat für das Mainnet.

  • Release-Tag-Datum: 27.10.2026 (Quelle S3)
  • Status: Pre-Release / Test-Node
  • Entwickler: Intersect MBO

Dijkstra-Testnet

Node 11.2 integriert mehrere Schlüsselkomponenten, die für die kommende Dijkstra-Ära erforderlich sind:

  • Unterstützung von Plutus V4
  • Neues Konfigurationsformat (Config-Envelopes)
  • Verschachtelte Sub-Transaktionen
  • Vorbereitungen für die Skalierungslösung Leios (Ouroboros Leios)

Zeitplan und Bedeutung des Dijkstra-Testnets

Das Dijkstra-Testnet startete am 01.11.2026 und forkt in Epoche 14 auf die neue Protokoll-Version 12, die als “Dijkstra-Ära” bezeichnet wird. Node 11.2 wird auf diesem Testnet eingesetzt, um die neuen Funktionen zu validieren, bevor sie in späteren Release-Kandidaten (geplant ab Version 11.3 / 12.0) auf das Mainnet überführt werden.

  • Testnet-Hard-Fork-Start: 01.11.2026 (Epoche 14, Quelle S2)
  • Offizielle Bezeichnung der kommenden Ära: Dijkstra
  • Node 11.2 dient als Test-Meilenstein, nicht als finaler Mainnet-Trigger

Konkrete Auswirkungen für Stake-Pool-Betreiber und Delegatoren

Für Delegatoren

Der Staking-Mechanismus und die Auszahlungslogik bleiben unverändert. Die Belohnungen verhalten sich plattformweit identisch, sodass ADA-Inhaber keine Änderungen an ihren Rewards erwarten müssen.

  • Auswirkung auf Staking-Rewards: Keine Änderung (Jahr 2026, Quelle S1)

Für Stake-Pool-Betreiber

Pool-Betreiber, die Amaru einsetzen, sollten das Risiko von Software-Inkompatibilitäten oder verpassten Blöcken in der Anlaufphase berücksichtigen. Da Amaru noch neu im produktiven Block-Producer-Umfeld ist, können unentdeckte Bugs zu temporären Ausfällen führen.

  • Risiko: mögliche Fehlerraten bei initialem Einsatz von Amaru
  • Empfehlung: vorsichtige Einführung und Monitoring während der ersten Wochen

FAQ – Häufig gestellte Fragen

Was genau ist der Node Amaru?Amaru ist ein von der Open-Source-Allianz PRAGMA entwickelter, alternativer Cardano-Node in Rust, der neben dem offiziellen Haskell-Node läuft, um Netzwerkausfälle durch Software-Monokulturen zu verhindern.Was bedeutet “Folgen für Delegatoren” beim Einsatz von Amaru?Für ADA-Delegatoren ändert sich an den Staking-Ausschüttungen regulär nichts. Das Risiko besteht lediglich darin, dass ein gewählter Pool bei einem unvorhergesehenen Software-Fehler eines neu eingesetzten Clients Blöcke verpassen könnte.Worum handelt es sich beim Dijkstra-Test und Node 11.2?Dijkstra ist die nächste große Hard-Fork-Ära von Cardano (u. a. Plutus V4 und Vorbereitung für Ouroboros Leios). Node 11.2 stellt die notwendigen Test-Funktionen bereit, um diese Änderungen auf dem öffentlichen DijkstraNet zu erproben.

Offene Fragen und Risiken

  • Split- und Fehlerrisiko bei Multi-Client-Architekturen: Wenn zwei unabhängige Implementierungen (Haskell vs. Rust) im Konsensverhalten minimal abweichen, kann es zu unbeabsichtigten Chain-Splits kommen. Deshalb setzen SPOs Amaru vorerst vorsichtig ein.
  • Node 11.2 ist noch kein finaler Hard-Fork-Trigger: Sie dient primär der Erprobung auf Testnetzen; die eigentliche Mainnet-Hard-Fork-Phase wird erst mit späteren Release-Kandidaten (geplant ab Version 11.3 / 12.0) erfolgen.
  • Unbestimmte Blockproduktion von Amaru seit dem 5. November 2026: Die aktuelle Meldung bestätigt die Berechtigung, nicht jedoch, dass bereits Blöcke produziert wurden.
  • Details zum Dijkstra-Testnet (z. B. genaue Parameter, weitere Milestones) bleiben bislang unbestätigt.

Fazit

Die Einführung von Amaru als rust-basierten Block-Producer und die Bereitstellung von Node 11.2 als Test-Node für das Dijkstra-Testnet markieren zentrale Infrastruktur-Schritte für Cardano. Amaru erweitert die Client-Vielfalt und mindert das Risiko einer systemischen Ausfallgefahr, während Node 11.2 die technische Grundlage für die bevorstehende Hard-Fork-Ära legt. Für Delegatoren bleibt das Staking-Ergebnis unverändert, doch Stake-Pool-Betreiber sollten die Anfangsphase von Amaru aufmerksam begleiten, um potenzielle Software-Risiken zu minimieren. Die nächsten Schritte umfassen weitere Tests mit Node 11.2, die Veröffentlichung von Version 11.3 und schließlich den Mainnet-Hard-Fork zu Protocol 12, der die Dijkstra-Ära offiziell einleiten wird.