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.