Kadena (KDA) – Chainweb, PoW und horizontales Sharding

Viele Blockchains skalieren entweder über Layer-2-Konstrukte oder über Sharding-Ansätze, die tief in Konsens und Datenmodell eingreifen. Kadena verfolgt eine andere Linie: ein Proof-of-Work-Netzwerk, das nicht eine globale Chain betreibt, sondern ein Geflecht aus parallel produzierten Chains. Ziel ist, mehr Durchsatz zu erreichen, ohne die Sicherheitslogik von PoW (Sybil-Resistenz durch reale Ressourcen) grundsätzlich zu verlassen.

Technisch wird das durch Chainweb umgesetzt: mehrere PoW-Chains, deren Blöcke sich gegenseitig referenzieren. Dadurch entsteht ein Verbund, in dem Sicherheit und Finalitätseigenschaften nicht nur von einer linearen Kette abhängen, sondern von der Struktur des gesamten Graphen. Um Anwendungen zu bauen, setzt Kadena zusätzlich auf eine eigene Smart-Contract-Sprache (Pact), die stark auf prüfbare Regeln, lesbare Policies und deterministische Ausführung zielt.

Wofür Kadena gebaut ist: Skalierung ohne Layer-2-Zwang

Problemklasse: eine lineare PoW-Chain als Flaschenhals

In einer klassischen PoW-Blockchain konkurrieren Miner darum, den nächsten Block einer einzigen Kette zu finden. Selbst wenn einzelne Blöcke groß wären, steigen Latenzen, Bandbreitenanforderungen und Orphan-Raten (verwaiste Blöcke). Der Engpass ist strukturell: die globale Reihenfolge ist linear, und jede Erhöhung von Blockgröße oder Blockfrequenz verschiebt nur Grenzen.

Kadenas Ansatz: horizontale Parallelität im Basenetz

Kadena setzt auf horizontales Sharding direkt auf Layer 1: mehrere Chains produzieren gleichzeitig Blöcke. Anwendungen und Nutzer verteilen sich über diese Chains, statt alles in einen globalen Mempool zu pressen. Wichtig: Das Design versucht, die Sicherheitseigenschaften von PoW nicht zu verwässern, sondern über Block-Referenzen zu koppeln.

Chainweb-Architektur: viele Chains, ein Sicherheitsverbund

Wie Blöcke sich gegenseitig absichern

In Chainweb ist ein Block nicht nur mit dem Vorgängerblock derselben Chain verlinkt, sondern referenziert zusätzlich aktuelle Blöcke anderer Chains. Dadurch entsteht eine Art „Block-Graph“, bei dem ein gültiger Block kontextuell zu mehreren Nachbarn passt. Ein Angreifer müsste bei Reorg-Versuchen (Umorganisation) nicht nur eine lineare Historie einer Chain ersetzen, sondern die konsistente Einbettung in den Verbund nachbilden.

Praktisch heißt das: Wer eine Transaktion auf Chain A umschreiben will, muss die Block-Historie so manipulieren, dass sie weiterhin zu den Referenzen aus anderen Chains passt. Je dichter und regelmäßiger diese Referenzen sind, desto größer wird der Aufwand für widerspruchsfreie Alternativhistorien.

Rollen im Netzwerk: Miner, Nodes, Anwendungen

• Miner erzeugen neue Blöcke – je nach Implementierung typischerweise für eine oder mehrere Chains – und liefern damit Rechenarbeit in den Verbund.

• Full Nodes validieren Blockregeln, prüfen Referenzen und halten die Zustände (States) der relevanten Chains.

• Anwendungen interagieren über Transaktionen mit einer konkreten Chain und nutzen Cross-Chain-Mechanik, wenn Werte oder Calls über Chain-Grenzen sollen.

So laufen Transaktionen in einem Multi-Chain-PoW-Netz ab

Von der Wallet bis in den Block

Eine typische Transaktion wird an eine spezifische Chain adressiert. Dort landet sie im Mempool der Nodes dieser Chain und wartet auf Inklusion. Miner nehmen sie in einen Block auf, der sowohl den internen Vorgänger (Chain-intern) als auch mehrere externe Referenzen enthält. Nach der Aufnahme ist die Transaktion nicht automatisch „global“ auf allen Chains sichtbar, sondern zunächst im Kontext der Ziel-Chain finalisierend.

Cross-Chain-Überträge: warum „Bridging“ hier anders gemeint ist

In einem Multi-Chain-L1 bedeutet „Cross-Chain“ nicht zwingend externe Bridges mit Wrapped Assets. Stattdessen geht es um Überträge innerhalb des Chainweb-Verbunds. Das Ziel ist, Vermögenswerte oder Zustandsübergänge zwischen Chains zu bewegen, ohne einen separaten Vertrauensanker außerhalb des Protokolls zu benötigen.

Der Kern ist ein nachvollziehbarer Nachweis, dass eine Aktion auf Chain A stattgefunden hat, und eine Regel, wie Chain B diesen Nachweis akzeptiert. Das ist konzeptionell näher an „interner Interoperabilität“ als an klassischen L1-zu-L1-Bridges. Trotz allem bleibt es technisch anspruchsvoll: Cross-Chain-UX hängt an Wartezeiten, Nachweisformaten und klaren Fehlerfällen (z. B. was passiert bei Reorgs?).

Smart Contracts mit Pact: lesbare Regeln statt EVM-Nähe

Was Pact von typischen VM-Sprachen unterscheidet

Kadena setzt für Smart Contracts auf Pact. Die Sprache ist auf Klartext-Policies und auditierbare Logik ausgelegt. Ein zentrales Designziel ist, dass Regeln (z. B. „wer darf was“, „unter welchen Bedingungen“) explizit und prüfbar formuliert werden, statt sich in komplexen Bytecode-Mustern zu verstecken.

Für Entwickler ist relevant: Pact ist nicht „EVM-kompatibel“. Das senkt zwar die unmittelbare Portierbarkeit von Ethereum-Anwendungen, kann aber in bestimmten Szenarien helfen, Risiken durch zu viel implizite Magie zu reduzieren. Typische Einsatzmuster sind Token-Logik, Berechtigungsmodelle, Treasury-Regeln oder Signatur-Policies, die gut lesbar bleiben sollen.

Typisches Beispiel: Berechtigung als On-Chain-Policy

Ein alltagsnahes Modell: Ein Projekt will, dass Auszahlungen nur mit zwei von drei Signaturen passieren oder dass ein Budget monatlich begrenzt ist. Solche Constraints lassen sich als explizite Regeln modellieren. Der Mehrwert entsteht, wenn Code und Policy nicht auseinanderlaufen: Was im Vertrag steht, ist die operative Realität.

Zum Vergleich: Multi-Sig-Logik kann auch in anderen Ökosystemen abgebildet werden, etwa über Safes. Für den konzeptionellen Hintergrund lohnt ein Blick auf Gnosis Chain und Safe-Architekturen, auch wenn Kadena technologisch anders gebaut ist.

Komponenten-Überblick: was im Kadena-Stack zusammenspielt

Praktische Schritte: Kadena technisch sinnvoll nutzen

Für ein sauberes Setup zählt weniger „Wallet installieren“ und mehr: wie Anwendungen Chain-Auswahl, Contract-Design und Cross-Chain-Flows strukturieren. Diese Schritte helfen bei der technischen Einordnung:

• Vor dem Contract-Design festlegen, welche Daten und Werte auf welcher Chain liegen sollen (z. B. nach App-Modulen oder Nutzergruppen trennen).

• Cross-Chain-Überträge als eigenen Prozess modellieren: Statusanzeigen, Timeouts, Wiederholungen und eindeutige Fehlercodes einplanen.

• In Pact Policies zuerst als „Lesetext“ formulieren (wer darf was wann) und danach in Funktionen abbilden; so bleiben Sicherheitsannahmen nachvollziehbar.

• Für Indexierung und Analytics prüfen, ob ein zentraler Indexer nötig ist oder ob app-spezifische Events reichen.

• Lasttests nicht nur auf einer Chain fahren: Parallelität entsteht erst, wenn Nutzerströme tatsächlich verteilt werden.

Abgrenzung im Ökosystem: wo Chainweb ein eigenes Profil hat

Multi-Chain-L1 vs. Rollups

Kadenas Grundidee ist, Skalierung in die Basisstruktur zu legen, statt sie primär über L2-Rollups zu erreichen. Rollups bündeln Transaktionen off-chain und posten Beweise oder Daten on-chain; der Engpass verlagert sich in Datenverfügbarkeit, Sequencing und Fraud-/Validity-Mechanik. Wer den Rollup-Ansatz im Detail einordnen will, findet nahe Vergleichspunkte bei Optimistic Rollups wie Arbitrum oder bei ZK-Systemen wie Scrolls zkEVM-Design.

Chainweb wirkt dagegen wie „Parallelisierung durch mehrere L1-Lanes“. Der Vorteil ist die direkte PoW-Verankerung jeder Lane; die Herausforderung ist, dass App-Design und Nutzerflüsse Multi-Chain nativ berücksichtigen müssen.

PoW in 2026: wofür die Eigenschaft technisch relevant bleibt

PoW ist kein Selbstzweck. Technisch bietet es eine klare Sybil-Barriere: Einfluss erfordert reale Rechenressourcen. In Multi-Chain-Designs ist entscheidend, wie diese Ressource aufgeteilt wird und wie die Kopplung der Chains verhindert, dass einzelne Teile des Netzes „billig“ angegriffen werden. Chainweb adressiert das über Referenzen zwischen Chains; das ist eine strukturelle Antwort auf das Problem, dass Parallelität sonst Sicherheit fragmentieren könnte.

Grenzen und typische Missverständnisse

„Mehr Chains“ bedeutet nicht automatisch linearen Durchsatz

Parallelität hilft, wenn Nutzung verteilt wird. Wenn alle Nutzer und Bots trotzdem nur eine Chain stark belasten, entsteht dort wieder ein Engpass. Skalierung ist dann weniger ein Protokoll-Problem als ein Routing- und Produktproblem: Apps müssen Nutzerströme sinnvoll aufteilen.

Cross-Chain-Flows sind fehleranfälliger als Single-Chain-UX

Sobald eine Aktion mehrere Chains berührt, entstehen mehr Zwischenzustände: „gesendet“, „bestätigt auf Chain A“, „nachgewiesen“, „eingelöst auf Chain B“. Gute Anwendungen behandeln das wie verteilte Systeme: idempotente Requests (wiederholbar ohne Doppelausführung), klare Zustandsautomaten und robuste Retries.

Sicherheitsdenken bleibt Pflicht: Policies sind nur so gut wie ihr Modell

Lesbare Verträge reduzieren nicht automatisch Risiken. Entscheidend ist ein konsistentes Berechtigungsmodell, Tests für Randfälle und saubere Upgrade-Strategien. Gerade bei Policy-lastigen Verträgen sollte klar sein, welche Änderungen möglich sind, wer sie auslösen darf und wie Nutzer diese Änderungen erkennen.

Einordnung: Für welche technischen Szenarien Kadena naheliegt

• Wenn eine Anwendung von Natur aus in Teilbereiche zerfällt (z. B. Märkte, Regionen, Produktlinien) und diese sauber auf mehrere Chains verteilt werden können.

• Wenn PoW-Properties gewünscht sind und gleichzeitig ein Bedarf an parallelen Ausführungspfaden besteht.

• Wenn Smart-Contract-Logik stark regel- und policygetrieben ist und Lesbarkeit/Auditierbarkeit ein zentrales Engineering-Ziel darstellt.

• Wenn Cross-Chain-UX als Produktfeature bewusst geplant wird, statt „nebenbei“ zu passieren.

Proof of Work bleibt in Kadena nicht nur Konsens, sondern Grundlage dafür, dass mehrere Chains gleichzeitig arbeiten können. Die zentrale Frage im Betrieb ist dann weniger „ob“ parallelisiert wird, sondern wie gut Anwendungen diese Parallelität in Datenmodell, Routing und Nutzerführung ausnutzen.