Private vs. Public Blockchain: So treffen Sie die Wahl – und wann Sie auf keine von beiden setzen sollten (2026)

Hier ist die ernüchternde Wahrheit über die Debatte um private versus öffentliche Blockchains. Zu dem Zeitpunkt, an dem die meisten Teams sie führen, haben sie sich meist schon falsch entschieden.

Meistens läuft es so ab: Eine Führungskraft hat etwas über Blockchain gelesen. Ein Dienstleister hat ein Pitch-Deck vorgestellt. Irgendwer sagte: „Wir sollten das auf einer privaten Chain umsetzen, weil Public zu riskant wirkt“, oder umgekehrt: „Wir müssen dezentral sein, also muss es Public sein.“ Ein POC wird freigegeben. Drei Monate später stellt jemand fest, dass die entwickelte Lösung überhaupt keine Blockchain braucht – oder eine völlig andere Variante als die, an der gerade gebaut wird.

Dieser Kreislauf lässt sich vermeiden. Die Frage „privat oder öffentlich“ ist eigentlich nicht die erste Frage – und nicht einmal die zweite. Es ist die dritte, und ob alles Weitere gelingt, hängt davon ab, zuerst die früheren Fragen richtig zu beantworten.

Dieser Beitrag wählt daher einen anderen Ansatz. Er führt Sie durch den tatsächlichen Entscheidungsbaum – brauchen Sie überhaupt eine Blockchain, permissioned oder permissionless, welche Plattform, wann Sie das Vorhaben abbrechen sollten – und zwar in der Reihenfolge, in der ein kompetentes technisches Team vorgehen würde. Einschließlich jener Antworten, die kaum ein Anbieter von Blockchain-Beratung gern laut ausspricht.

 Die folgenden Empfehlungen basieren auf Beobachtungen dessen, was im Produktivbetrieb funktioniert und was zwölf Monate nach dem Launch stillschweigend eingestellt wird.

Brauchen Sie tatsächlich eine Blockchain? (Die Frage, an der 60 % aller Projekte scheitern)

Die meisten Anwendungsfälle, die am Ende auf einer Blockchain landen, wären mit einer durchdachten verteilten Datenbank mit strengen Zugriffskontrollen, einem signierten Audit-Log und solider Backup-Hygiene besser bedient gewesen. Eine Blockchain bringt zwei Dinge, die eine Datenbank nicht hat: Dezentrales Vertrauen. Und nachweisbare Manipulationssicherheit zwischen Parteien, die einander nicht vollständig vertrauen.

Wenn Sie keines von beidem benötigen, zahlen Sie die Blockchain-Steuer umsonst. Und diese Steuer existiert: Eine Blockchain ist langsamer, im Betrieb teurer, Fachkräfte sind schwerer zu rekrutieren und Anpassungen nach dem Deployment sind deutlich komplizierter.

Hier ist ein klarer Vier-Punkte-Test. Eine Blockchain ist das richtige Werkzeug, wenn:

• Mehrere Parteien einen gemeinsamen Zustand teilen müssen
• Diese Parteien einander oder einem einzelnen Intermediär nicht vollständig vertrauen
• Eine eindeutige Single Source of Truth zwingend erforderlich ist
• Die Kosten für Streitfälle, Abstimmungsprozesse oder Audits hoch genug sind, um die Infrastruktur zu rechtfertigen

Wenn auch nur einer dieser vier Punkte fehlt, lautet die ehrliche Antwort wahrscheinlich: „Nutzen Sie eine Datenbank.“ Fehlen zwei oder mehr, lautet die Antwort definitiv: „Nutzen Sie eine Datenbank.“

Konkrete Beispiele – wo die Blockchain diesen Test gewinnt:

• Interbanken-Settlement zwischen konkurrierenden Instituten, die einander nicht als Intermediär nutzen
• Herkunftsnachverfolgung in der Lieferkette über Vorlieferanten hinweg, bei der kein einzelnes Unternehmen die gesamte Kette überblickt
• Asset-Tokenisierung für fraktionierte Immobilien oder private Wertpapiere, bei denen Compliance eine lückenlos nachweisbare Eigentumshistorie verlangt
• DeFi-Protokolle, bei denen der offene Zugang ohne Gatekeeper im Mittelpunkt steht
• Digitale Identitätsnachweise über Verwaltungsgrenzen hinweg (eine Universität stellt einen Abschluss aus, ein ausländischer Arbeitgeber verifiziert ihn, ohne dass beide einem zentralen Register vertrauen müssen)

Wo sie den Test nicht besteht, aber trotzdem gebaut wird:

• Internes Dokumentenmanagement innerhalb eines einzelnen Unternehmens – eine Datenbank mit signiertem Speicher erledigt das zu 2 % der Kosten
• Treuepunkte für einen einzelnen Händler – das leistet eine Datenbank problemlos, und eine Blockchain bringt keinerlei echte Dezentralisierung, da der Händler ohnehin das gesamte System kontrolliert
• Audit-Trails für regulierte Unternehmen – eine Datenbank mit kryptografischer Verkettung leistet das Gleiche, und dem Auditor ist es egal, ob es auf einer Chain liegt
• „Tokenisierter“ interner Workflow-Status – Ihr BPM-Tool löst das bereits, bitte nutzen Sie es

Jedes einzelne davon ist ein reales Muster. Wir haben miterlebt, wie Teams damit gestartet sind, Rückendeckung aus der Führungsebene erhielten, sechs bis zehn Monate verbrannt haben und ein Jahr später, nachdem die Berater weg waren, still und leise auf Postgres umgestiegen sind. Niemand spricht in Case Studies über solche Projekte. Das hat seinen Grund.

Wenn Ihr Anwendungsfall nach ehrlicher Beantwortung dieser vier Fragen immer noch eine Blockchain erfordert – gut, dann haben Sie den ersten Filter passiert. Die meisten Ideen, die mit „Wir sollten uns mal mit Blockchain beschäftigen“ begannen, scheitern bereits hier. Diejenigen, die ihn überstehen, werden interessant. Genau an diesem Punkt wird die Frage „privat versus öffentlich“ zur eigentlichen Debatte.

Der eigentliche Unterschied ist nicht privat vs. öffentlich – sondern Permissioned vs. Permissionless

Eine kurze Begriffsklärung, denn hier nimmt die halbe Verwirrung ihren Anfang: „Öffentlich“ und „privat“ sind verkürzte Bezeichnungen, und zwar ungenaue. Die Eigenschaften, die Architekturentscheidungen tatsächlich bestimmen, sind „permissionless“ versus „permissioned“.

Permissionless: Jeder kann beitreten, einen Node betreiben, validieren und Transaktionen durchführen. Es gibt keinen Gatekeeper. Die Chain setzt auf Kryptografie und wirtschaftliche Anreize, um die Teilnehmer ehrlich zu halten. Ethereum, Bitcoin, Solana, Polygon PoS, Avalanche C-Chain – das sind die klassischen Permissionless-Netzwerke.

Permissioned: Die Teilnehmer sind identifiziert und für den Beitritt zum Netzwerk autorisiert. Ein Führungsgremium – ein Konsortium von Organisationen, ein einzelnes Unternehmen oder manchmal eine Regulierungsbehörde – entscheidet darüber, wer teilnehmen darf. Die Chain setzt auf Kryptografie in Kombination mit institutioneller Identität. Hyperledger Fabric, R3 Corda, Quorum – das sind die klassischen Permissioned-Netzwerke.

Dann gibt es noch Untervarianten, die in Fachartikeln gern als eigene Kategorien dargestellt werden, es aber eigentlich nicht sind:

• Konsortium – eine spezielle Ausprägung von Permissioned, die gemeinschaftlich von einer Gruppe von Organisationen verwaltet wird. Die meisten Enterprise-Blockchain-Implementierungen sind Konsortialnetzwerke, selbst wenn das Marketing sie als „privat“ bezeichnet.
• Hybrid – ein Permissioned-Kern mit einem Public-Chain-Anker zur Prüfbarkeit. Keine eigenständige Architektur, sondern eher ein Bereitstellungsmuster, das zunehmend verbreitet ist.

Die Gegenüberstellung von Public und Private greift auch in der Praxis oft zu kurz. Polygon ist auf dem Base Layer permissionless, unterstützt jedoch auch Permissioned-Konfigurationen. Ethereum lässt sich als privater Fork für ein einzelnes Konsortium betreiben; mehrere große Enterprise-Implementierungen tun genau das. Die entscheidende Eigenschaft ist nicht, welche Chain Sie nutzen – sondern wie Sie Teilnahme, Validierung und Datensichtbarkeit darin konfigurieren.

Im weiteren Verlauf dieses Artikels verwenden wir weiterhin die Begriffe „privat“ und „öffentlich“, da Kunden genau danach suchen. Denken Sie sich dabei einfach „permissioned“ und „permissionless“. Der Unterschied wird entscheidend, sobald es an die Definition der Anforderungen geht.

Öffentliche und private Blockchain: Eine Definition

Ein kurzer Überblick über die Definitionen für Leser, die hier gelandet sind, bevor die Unterscheidung zwischen permissioned und permissionless geklärt wurde. Überspringen Sie diesen Abschnitt, wenn Ihnen die Grundlagen bereits vertraut sind.

Was ist eine öffentliche Blockchain?

Eine öffentliche Blockchain ist ein offenes, erlaubnisfreies Netzwerk (permissionless), in dem jeder mit einer Internetverbindung einen Node betreiben, Transaktionen validieren und ausführen kann. Es gibt keine zentrale Instanz, keinen Gatekeeper und keine Mitgliederliste. Das Ledger ist weltweit einsehbar – jede Transaktion, jede Adresse und jeder Smart-Contract-Aufruf ist öffentlich dokumentiert. Bitcoin ist das klassische Beispiel dafür. Ethereum ist das Paradebeispiel für öffentliche Chains mit Smart Contracts. Solana, Polygon PoS und Avalanche fallen in dieselbe Kategorie, auch wenn sich ihre technischen Architekturen unterscheiden.

Das Sicherheitsmodell basiert auf ökonomischen Anreizen. Validatoren sind alle Personen oder Organisationen, die bereit sind, Kapital zu staken (Proof of Stake) oder Rechenleistung einzusetzen (Proof of Work). Das Protokoll ist so konzipiert, dass ein Angriff auf das Netzwerk teurer ist als ehrliches Verhalten. Vertrauen wird durch Mathematik und Marktkräfte ersetzt – statt durch Identität oder rechtliche Vereinbarungen.

Vorteile einer öffentlichen Blockchain

Die Gründe, warum sich der Aufbau auf einer öffentlichen Chain lohnt – wenn der Use Case passt:

• Tatsächlich offener Zugang – kein Onboarding-Prozess, keine KYC-Hürde auf Protokollebene und kein Gatekeeper, der den Zugriff sperren kann
• Transparenz und Prüfbarkeit ab Werk – der Status der Chain ist für jeden einsehbar, was manchmal ein Nachteil, aber oft ein entscheidender Vorteil ist
• Zensurresistenz – keine einzelne Entität kann einseitig verhindern, dass eine Transaktion aufgenommen wird
• Netzwerkeffekte und Liquidität – öffentliche Chains (insbesondere Ethereum und seine Layer-2s) verfügen über gewachsene Ökosysteme aus Entwicklern, Tools und Kapital, an die Sie direkt anknüpfen können
• Interoperabilität mit dem breiteren Krypto-Ökosystem – Stablecoins, Bridges, DeFi-Primitive und NFT-Infrastruktur laufen alle auf öffentlichen Chains
• Unveränderlichkeit bestätigter Transaktionen – einmal bestätigt, kann eine Transaktion von keinem Betreiber oder Administrator mehr rückgängig gemacht werden

Nachteile einer öffentlichen Blockchain

Die Nachteile, offen dargelegt:

• Der Durchsatz ist geringer als bei einer Datenbank oder einer Permissioned Chain – selbst Solana oder moderne L2-Lösungen liegen unter dem Niveau, das reguläre Enterprise-Infrastruktur standardmäßig erzielt
• Transaktionskosten werden im nativen Token der Chain abgerechnet und unterliegen damit Marktvolatilitäten; extreme Gas-Preis-Spitzen sind keine Seltenheit
• Datenschutz und Privatsphäre müssen separat aufgesetzt werden, statt konfigurierbar zu sein – ZK-Proofs und Off-Chain-Berechnungen sind zwar machbar, erfordern jedoch erheblichen Entwicklungsaufwand
• Die regulatorische Haltung zu öffentlichen Chains ändert sich ständig und unterscheidet sich je nach Rechtsraum – diese Unsicherheit ist real und kein theoretisches Risiko
• Auf vielen öffentlichen Chains ist die Finalität probabilistisch statt unmittelbar, was für Settlement-Workflows mit strengen SLAs hochrelevant ist
• Die Einhaltung von Datenschutzvorgaben wie dem DSGVO-Recht auf Löschung ist auf einem unveränderlichen Ledger architektonisch nur schwer umzusetzen

Was ist eine private Blockchain?

Eine private Blockchain – genauer gesagt eine Permissioned Blockchain – ist ein Netzwerk, bei dem der Zugriff kontrolliert wird. Ein leitendes Organ – sei es eine einzelne Organisation, ein Konsortium aus Unternehmen oder eine Regulierungsbehörde – bestimmt, wer einen Node betreiben, wer Transaktionen validieren und wer Daten einsehen darf. Die Identität ist auf Protokollebene verankert; die Mitgliedschaft ist explizit geregelt.

Hyperledger Fabric, R3 Corda und Quorum sind die klassischen Beispiele. Was sie verbindet, ist weniger eine bestimmte Technologie als vielmehr ein Governance-Modell: Vertrauen entsteht aus institutioneller Identität und rechtlichen Verträgen zwischen namentlich bekannten Teilnehmern – nicht aus ökonomischen Anreizen zwischen anonymen Akteuren. In den meisten Praxisszenarien ist eine „private“ Blockchain in Wahrheit ein Konsortium: Mehrere Organisationen teilen sich die Governance, statt dass ein einzelnes Unternehmen eine Chain für sich allein betreibt.

Vorteile einer privaten Blockchain

Warum sich Unternehmenskunden für private Chains entscheiden:

• Hoher Durchsatz und geringe Latenz – ein Permissioned Consensus mit einer kleinen Validatorengruppe ermöglicht Finalität im Subsekundenbereich und Tausende von TPS
• Konfigurierbare Datensichtbarkeit – Channels, private Transaktionen und Point-to-Point-Sharing erlauben es verschiedenen Teilnehmern, unterschiedliche Teildaten zu sehen, ohne dass kryptografische Behelfslösungen nötig sind
• Planbare Kosten – laufende Betriebsausgaben statt Transaktionsgebühren, ohne Abhängigkeit von den Kursschwankungen eines Tokens
• Regulatorische Konformität für identifizierte Teilnehmer – KYC- und AML-Compliance lassen sich direkt in die Netzwerkebene integrieren, was die Zusammenarbeit mit regulierten Unternehmen erheblich vereinfacht
• Flexible Governance – das Konsortium kann das Protokoll aktualisieren, Regeln anpassen und Konflikte lösen, ohne dass ein weltweiter Konsens erforderlich ist
• Einfachere Datenschutz-Compliance – die Korrektur oder Schwärzung von Daten ist architektonisch möglich, sofern die Governance dies vorsieht

Nachteile einer privaten Blockchain

Die Kompromisse, die im Enterprise-Blockchain-Marketing gern heruntergespielt werden:

• Die Sicherheit ist nur so stark wie die Gruppe der Validatoren – wenn 51 % der Konsortiumsmitglieder kollaborieren oder kompromittiert werden, kann die Historie umgeschrieben werden
• Netzwerkeffekte bleiben auf das Konsortium beschränkt – Sie können nicht an das breitere Ökosystem aus Tools, Liquidität und Composability anknüpfen, das öffentliche Chains bieten
• Realer operativer Aufwand – der Betrieb der Infrastruktur, die Verwaltung der Mitgliedschaften, die Abstimmung von Upgrades und die Schlichtung von Streitigkeiten erfordern kontinuierlichen Einsatz
• Vendor- und Konsortial-Lock-in – der Ausstieg aus einem Fabric-Konsortium oder eine Migration weg von Corda ist keineswegs trivial, sobald die Weichen gestellt sind
• Die Governance-Frage ist oft schwieriger als das technische Problem – die Entscheidung darüber, wer welche Regel wann ändern darf, bringt mehr Konsortialprojekte zum Scheitern als jede technische Hürde
• Die ehrliche Frage, ob Sie überhaupt eine Blockchain benötigen (siehe Eingangsabschnitt), gilt für private Chains umso mehr – die Gefahr ist groß, versehentlich eine extrem teure verteilte Datenbank aufzubauen

Vier Entscheidungsdimensionen, die wichtiger sind als jede Feature-Tabelle

Die typische tabellarische Gegenüberstellung in den meisten Blockchain-Artikeln nützt für reale Entscheidungen so gut wie nichts. Aussagen wie „Public bietet Transparenz, Private bietet Datenschutz“ helfen niemandem beim Architekturentwurf. Die Fragen, die Architekturentscheidungen wirklich leiten, sind diese vier:

Wer kann teilnehmen?

Der Grad der Offenheit auf der Teilnahme-Ebene: Permissionless-Netzwerke ermöglichen jedem mit einer Internetverbindung und einer Wallet den Beitritt und das Ausführen von Transaktionen – ohne Identitätsprüfung, ohne Gatekeeper, ohne Onboarding-Prozess. Permissioned-Netzwerke beschränken den Zugang über KYC, Mitgliedschaftsverträge oder Governance-Abstimmungen.

Für Anwendungsfälle, bei denen die Teilnehmer regulierte Unternehmen sind – Banken, lizenzierte Broker, Gesundheitsdienstleister, Behörden –, ist ein Permissioned-Ansatz oft schon aus Compliance-Gründen zwingend vorgeschrieben. Ihre Aufsichtsbehörde will wissen, wer sich im Netzwerk befindet, und „jeder beliebige Internetnutzer“ ist keine akzeptable Antwort, wenn Patientendaten oder Settlement-Anweisungen übertragen werden.

Für Anwendungsfälle, deren wesentlicher Kern die offene Teilnahme ist – Consumer-DeFi, offene NFT-Marktplätze, zensurresistente Anwendungen, grenzüberschreitende Überweisungen –, ist der Permissionless-Ansatz unverzichtbar. Ein Vorschalten von Zugangsbarrieren würde das Produkt untergraben.

Diese Frage allein entscheidet bereits rund 60 % aller Debatten zwischen Private und Public. Wenn Sie wissen, wer Ihre Nutzer sein werden, und deren Identität prüfen müssen, bevor sie mit dem System interagieren, bauen Sie auf ein Permissioned-Netzwerk. Wenn Sie es nicht wissen und es auch nicht wissen wollen, entwickeln Sie permissionless.

Wer validiert Transaktionen?

Die Konsens-Ebene. Hier werden die architektonischen Konsequenzen greifbar.

Permissionless Chains nutzen einen Konsensmechanismus, der auf ökonomischer Sicherheit beruht: Proof of Work (Bitcoin), Proof of Stake (Ethereum nach dem Merge, Solana, Polygon) oder Delegated-Proof-of-Stake-Varianten. Das Grundprinzip: Validatoren sind all jene, die bereit sind, Kapital zu riskieren – und das Protokoll sorgt dafür, dass ein Angriff auf das Netzwerk teurer ist als die Einhaltung der Regeln.

Permissioned Chains setzen auf institutionellen Konsens: Varianten von Practical Byzantine Fault Tolerance (PBFT), Raft oder Istanbul BFT. Das Prinzip hierbei: Die Validatoren sind spezifische, namentlich benannte Organisationen, die einer Teilnahme zugestimmt haben. Das Protokoll muss sie lediglich synchron halten, selbst wenn eine Minderheit ausfällt oder bösartig agiert.

Konkrete Auswirkungen in der Praxis:

• Permissioned Consensus ist deutlich schneller: Finalität in Millisekunden bis wenigen Sekunden, verglichen mit den rund 12 Sekunden dauernden Ethereum-Blöcken oder den etwa 60 Minuten bis zur ökonomischen Finalität bei Bitcoin.
• Permissioned Consensus ist pro Transaktion drastisch günstiger: Sie zahlen reine Infrastrukturkosten statt Gas Fees.
• Ein Permissioned Consensus ist nur so vertrauenswürdig wie die beteiligten Validierungs-Institutionen. Wenn 51 % Ihres Konsortiums beschließen, die Historie umzuschreiben, ist das möglich. Die ökonomische Sicherheit wird durch institutionelle Reputation und rechtliche Vereinbarungen ersetzt.

Dieser letzte Punkt verdeutlicht, warum ein Permissioned Consensus für ein Settlement-Netzwerk unter regulierten Banken gut geeignet ist (diese unterliegen strengen rechtlichen und reputationsbezogenen Auflagen, sodass geheime Absprachen unwahrscheinlich sind) – für ein dezentrales Oracle-System jedoch ungeeignet ist (dessen eigentlicher Zweck gerade darin besteht, ein solches Kollusionsrisiko auszuschließen).

Wer kann die Daten sehen?

Die Ebene der Datensichtbarkeit: Auf einer erlaubnisfreien Public Chain ist die Transaktionshistorie standardmäßig weltweit für jeden einsehbar. Jede Adresse, jeder Betrag, jeder Smart-Contract-Aufruf – alles ist öffentlich dokumentiert. Datenschutz muss nachträglich über Zero-Knowledge-Proofs, Commit-Reveal-Verfahren oder Off-Chain-Berechnungen integriert werden. Das ist machbar, aber anspruchsvoll und sowohl rechen- als auch entwicklungsintensiv.

Auf einer Permissioned Blockchain ist die Datensichtbarkeit von Grund auf konfigurierbar. Hyperledger Fabric nutzt „Channels“ – im Grunde Teilnetzwerke, in denen bestimmte Organisationen nur bestimmte Daten sehen. Corda geht noch weiter: Daten werden Punkt-zu-Punkt zwischen den Beteiligten ausgetauscht und nicht an alle repliziert. Quorum bietet private Transaktionen. Jedes dieser Systeme ermöglicht es unterschiedlichen Teilnehmern, jeweils andere Teilmengen der Daten einzusehen – ganz ohne kryptografische Kunstgriffe.

Für Enterprise-Anwendungsfälle mit echten Vertraulichkeitsanforderungen – etwa Handelsstrategien, Patientenakten oder Lieferantenpreise – sind Permissioned Blockchains deutlich einfacher zu implementieren. Nicht weil Datenschutz auf Public Chains unmöglich wäre, sondern weil das Entwicklungsbudget, das Sie für ZK-Circuits und Privacy-Overlays aufwenden müssten, besser in eine Chain investiert ist, die selektive Sichtbarkeit von Haus aus unterstützt.

Wer zahlt für den Betrieb?

Die ökonomische Ebene, an die bis zum zweiten Betriebsjahr kaum jemand denkt.

Public Chains erheben Transaktionsgebühren im nativen Token der jeweiligen Chain: ETH auf Ethereum, MATIC auf Polygon, SOL auf Solana. Wer eine DApp betreibt, zahlt pro Transaktion – und diese Kosten können unvorhersehbar in die Höhe schnellen. Man denke nur an jeden NFT-Mint, der die Gas-Preise auf Ethereum kurzzeitig auf 200 $ pro Transaktion getrieben hat. Ihre Betriebskosten sind somit nutzungsabhängig und direkt den Marktschwankungen ausgesetzt.

Permissioned Chains werden direkt von den Konsortiumsmitgliedern finanziert. Es fallen Infrastrukturkosten an – Server, Betrieb, Monitoring – statt Transaktionsgebühren. Das ist berechenbarer und unabhängig davon, wie sich der Kurs des nativen Tokens am Markt entwickelt.

Auf lange Sicht und bei hohen Transaktionsvolumina ist ein Permissioned-Modell meist günstiger. Bei geringem Volumen können die fixen Infrastrukturkosten eines Permissioned-Netzwerks Public Chains wirtschaftlicher machen – insbesondere seitdem L2s wie Arbitrum und Base die Transaktionskosten auf Bruchteile eines Cents gesenkt haben.

Die Plattformen, auf die es 2026 wirklich ankommt

Dieser Abschnitt behandelt die Plattformen, die realistisch in der engeren Auswahl von Unternehmen landen. Mittlerweile gibt es Hunderte von L1s und L2s. Die meisten davon spielen für Ihre Entscheidung keine Rolle. Diese hier schon.

Ethereum (permissionless)

Der Standard für alles, was offene, programmierbare Smart Contracts erfordert. Nach dem Merge und dem Aufkommen zahlreicher L2-Rollups (Optimism, Arbitrum, Base, zkSync, Scroll) ist Ethereum 2026 mehr ein ganzes Ökosystem als eine einzelne Chain.

Für Enterprise-Entscheider sind realistischerweise meist Ethereum-kompatible L2s relevant und weniger das Mainnet selbst. Sie sind deutlich günstiger, bieten eine schnellere Finalität und profitieren beim Settlement dennoch vom Sicherheitsmodell von Ethereum. Das Mainnet eignet sich für Anwendungsfälle, die maximale Dezentralisierung erfordern und bei denen Gebühren von 1 bis 5 $ pro Transaktion tragbar sind. Der Großteil der tatsächlichen Anwendungsaktivität findet heute auf L2s statt.

Stärken: mit weitem Abstand das größte Entwickler-Ökosystem, die ausgereiftesten Tools, tiefste Liquidität und hohe regulatorische Bekanntheit. Schwächen: Die L2-Landschaft ist nach wie vor fragmentiert, Bridging zwischen L2s bleibt ein ungelöstes UX-Problem, und die Entscheidung für „Ethereum“ erfordert heute auch die Wahl eines passenden L2. Mehr zum aktuellen Stand der Entwicklung erfahren Sie in unserem Beitrag über Ethereum-Entwicklung.

Polygon (permissionless, Ethereum-kompatibel)

Die bewährte Permissionless-Option für Unternehmen. EVM-kompatibel, niedrige Gebühren und echte Enterprise-Implementierungen – wie Starbucks Odyssey oder Nikes .Swoosh vor deren Einstellung, Reddit-Collectibles und diverse Supply-Chain-PoCs. Polygons erweiterte Suite umfasst mittlerweile Polygon zkEVM und das Polygon CDK für anwendungsspezifische Chains.

Stärken: der kostengünstigste Weg, Ethereum-kompatible Smart Contracts im großen Maßstab bereitzustellen, hervorragende Developer Experience, aktive Ausrichtung auf Unternehmenskunden. Schwächen: Viele namhafte Unternehmenspartnerschaften wurden wieder eingestellt; die Tokenomics waren komplex; das Netzwerk verzeichnete Sicherheitsvorfälle. Bei der Polygon-Entwicklung landen die meisten unserer mittelständischen Kunden, wenn sie eine Permissionless-Lösung mit unternehmensfreundlicher Kostenstruktur suchen.

Solana (permissionless)

Hoher Durchsatz – theoretisch 65.000 TPS, in der Praxis mehrere Tausend –, minimale Kosten, Finalität im Subsekundenbereich. Im Einsatz für Consumer-Anwendungen, Hochfrequenz-DeFi, NFT-Marktplätze und Echtzeitzahlungen. Solanas Rust-basierter Entwicklungs-Stack anstelle von Solidity ist ein wichtiger Faktor, falls Ihr Team bereits mit der EVM vertraut ist.

Die Akzeptanz im Enterprise-Bereich wächst, war jedoch historisch durch Netzausfälle belastet – mehrere mehrstündige Stillstände zwischen 2022 und 2023, die weitgehend behoben sind, aber im Gedächtnis von Institutionen bleiben. Wer Solana 2026 für den Unternehmenseinsatz evaluiert, musste bereits klären, was ein Solana-Ausfall für die eigenen SLAs bedeutet. Diese Antwort entscheidet über die Eignung für den jeweiligen Anwendungsfall. Praktische Aspekte dazu finden Sie unter Solana-Entwicklung.

Hyperledger Fabric (permissioned)

Die am weitesten verbreitete Enterprise-Blockchain. Ursprünglich von IBM initiiert, wird sie heute im Rahmen des Hyperledger-Projekts der Linux Foundation weiterentwickelt. Pluggable Consensus, private Datenkanäle und Chaincode in Go, JavaScript oder Java statt klassischer Smart Contracts.

Durch und durch auf Enterprise-Anforderungen ausgelegt: Channels ermöglichen es verschiedenen Organisationen, unterschiedliche Datenteilmengen zu sehen. Der Membership Service Provider übernimmt das Identitätsmanagement. Dank des modularen Konsensmechanismus können Sie je nach Vertrauensmodell PBFT oder Raft wählen. Die klassische Wahl für Konsortialnetzwerke – insbesondere dort, wo IBM bereits als Technologiepartner etabliert ist.

Stärken: die ausgereifteste Permissioned Chain, belegte Praxiseinsätze, umfassende Dokumentation, breiter Vendor-Support. Schwächen: hoher Betriebsaufwand, steile Lernkurve für Teams mit Ethereum-Hintergrund; die Dynamik rund um Konsortial-Blockchains hat sich seit 2022 generell verlangsamt. Dennoch weiterhin der Standard für Konsortialprojekte im Banken- und Supply-Chain-Sektor. Details zur Umsetzung finden Sie in unserem Leistungsbereich Hyperledger-Fabric-Entwicklung.

R3 Corda (permissioned, spezialisiert)

Speziell für Finanzdienstleistungen entwickelt. Dabei gilt: Corda ist im traditionellen Sinn keine reine Blockchain – Daten werden Punkt-zu-Punkt zwischen den Parteien ausgetauscht und nicht auf jeden Knoten eines globalen Ledgers repliziert. Für regulierte Finanzprozesse ist das ein gezielter Vorteil: Handelsdaten von Gegenparteien dürfen keinesfalls für alle anderen Teilnehmer sichtbar sein.

Aufgebaut auf Konzepten, die im Finanzsektor tatsächlich genutzt werden: Notare, Contracts in Kotlin oder Java sowie Flows anstelle klassischer Smart Contracts. Äußerst stark in den Bereichen Devisenhandel, Derivate, Konsortialkredite und Interbanken-Settlement. Im Vergleich zu Fabric ist der Anwendungsbereich enger – Corda begegnet einem kaum in Supply Chains oder im Gesundheitswesen –, in seiner Nische jedoch führend.

Quorum, Besu und weitere von Ethereum abgeleitete Permissioned Chains

Quorum entstand als Ethereum-Fork von J.P. Morgan für den Permissioned-Einsatz. Heute gehört es zu ConsenSys; die strategische Zukunft ist seit einigen Jahren jedoch ungewiss – prüfen Sie den aktuellen Status vor Projektbeginn genau. Hyperledger Besu bleibt mit dem IBFT2-Konsens eine solide Ethereum-Client-Wahl für Permissioned Networks. Auch private Geth-Netzwerke sind weiterhin im Einsatz.

Der Reiz dieser Kategorie: Sie nutzen bewährte Ethereum-Tools (Solidity, Truffle oder Hardhat, MetaMask-kompatible Wallets) mit den Eigenschaften eines Permissioned-Netzwerks. Das Versprechen lautet „Ethereum-Entwickler auf einer privaten Chain“. Die Realität ist differenzierter: Sie betreiben einen weniger praxiserprobten Permissioned-Konsens mit einer Community, die kleiner ist als die von Fabric einerseits und Ethereum andererseits.

Cosmos, Polkadot und der App-Chain-Ansatz

Ein zukunftsweisender Mittelweg, der 2026 für Unternehmen hochinteressant ist: Cosmos-Zonen und Polkadot-Parachains ermöglichen es einem Konsortium oder einem einzelnen Unternehmen, eine eigene, souveräne Chain zu betreiben und gleichzeitig über IBC (Cosmos) oder XCM (Polkadot) mit einem größeren Netzwerk zu interagieren.

Hier beginnen hybride Modelle wirklich Sinn zu ergeben: Sie erhalten die Kontrolle einer Permissioned Chain – eigenes Validator-Set, eigene Governance, eigene Regeln für die Datensichtbarkeit – kombiniert mit der Anbindung an ein Permissionless-Ökosystem nach Bedarf. Das Inter-Blockchain-Communication-Protokoll (Cosmos) und XCM (Polkadot) sind 2026 so ausgereift, dass Cross-Chain-Interoperabilität kein reines Forschungsthema mehr wie vor fünf Jahren ist. Für Konsortien, die Souveränität ohne Isolation anstreben, ist der App-Chain-Ansatz eine ernsthafte Überlegung wert. Bei der Enterprise-Adoption noch nicht so weit wie Fabric, holt aber auf.

Plattformen im Überblick

Ein Referenzüberblick: Verstehen Sie dies nicht als endgültige Entscheidung, sondern als Spickzettel, auf den Sie bei der Evaluierung der vier oben genannten Entscheidungsdimensionen zurückgreifen können.

Plattform	Berechtigung	Reale TPS	Finalität	Contract-Sprache	Ideal für / Zu beachten
Ethereum Mainnet	Permissionless	~15	~12s (ökonomisch)	Solidity, Vyper	Maximale Dezentralisierung, tiefstes Ökosystem. Kosten und Durchsatz – L2s nutzen.
Ethereum L2 (Arbitrum, Base)	Permissionless	~2.000+	Sekunden bis Minuten	Solidity	Praktische Basis für die meisten dApps 2026. Bridging-UX noch holprig.
Polygon PoS	Permissionless	~7.000	~2s	Solidity	Unternehmensfreundliche Kosten. Frühere Sicherheitsvorfälle; Governance beachten.
Solana	Permissionless	~3.000–4.000	<1s	Rust	Geschwindigkeit und Kosten. Ausfallhistorie relevant für SLA-gebundene Fälle.
Hyperledger Fabric	Permissioned	~1.000–3.000	~1s	Go, JS, Java	Standard für Konsortien. Hoher Betriebsaufwand.
R3 Corda	Permissioned	~600+	Subsekunden	Kotlin, Java	Spezialist für Finanzdienstleistungen. Eng fokussiert, aber tiefgehend.
Cosmos App-Chain	Beides	~10.000	~6s	CosmWasm (Rust)	Souveräne Chain mit Interoperabilität. Im Enterprise-Bereich noch in der Reifung.

Ein wichtiger Hinweis zu dieser Tabelle: Die Durchsatzwerte spiegeln wider, was Plattformen im Produktivbetrieb zuverlässig bewältigen – nicht die Marketingversprechen. Die theoretischen Maximalwerte weichen erheblich ab: Solana wirbt mit 65.000 TPS, Fabric hat Benchmarks von über 20.000 TPS unter kontrollierten Bedingungen veröffentlicht. Keine dieser Zahlen entspricht dem, was Sie im realen Produktiveinsatz erleben werden.

Anwendungsfälle dem passenden Modell zuordnen

Sechs Anwendungsfälle mit ehrlichen Empfehlungen. Keine Anbieterliste, sondern Einschätzungen aus der Praxis.

Interbanken-Settlement zwischen regulierten Banken

Permissioned – mit hoher Wahrscheinlichkeit Corda oder Fabric. Die Teilnehmer sind identifizierte, regulierte Institutionen, die Vertraulichkeit von Handelsdaten ist nicht verhandelbar, die Finalität des Settlements muss institutionellen Ansprüchen genügen, und die Regulierungsbehörden verlangen ein System mit namentlich bekannter Teilnehmer-Governance. Genau für dieses Szenario wurden Permissioned Chains konzipiert – und hier überzeugen sie auch.

Öffentlicher Marktplatz für tokenisierte Immobilien

Permissionless – auf einem Ethereum-L2 oder Polygon. Der Kern des Produkts lautet „Jeder kann Teilanteile kaufen“: Freier Zugang ist hier das entscheidende Merkmal. Eine Permissioned Chain würde den Zweck verfehlen. Die Prüfbarkeit von Smart Contracts schafft Vertrauen bei Kunden und ist kein Risiko. Compliance (KYC für Käufer) erfolgt auf der Anwendungsebene, nicht auf der Chain-Ebene.

Supply-Chain-Rückverfolgbarkeit über mehrstufige Lieferanten

Ein Permissioned-Konsortium (Fabric) ist die gängige Wahl und für die Erstimplementierung meist auch die richtige. Der anspruchsvollere Ansatz im Jahr 2026 ist jedoch hybrid: eine Permissioned Chain für detaillierte Transaktionsdaten, kombiniert mit regelmäßiger Verankerung (Anchoring) auf einer Public Chain (Ethereum oder Polygon) zur unabhängigen Überprüfbarkeit. Das bietet den teilnehmenden Organisationen den Datenschutz und Durchsatz eines Permissioned-Netzwerks, ergänzt um einen manipulationssicheren öffentlichen Anker, den externe Prüfer oder Kunden verifizieren können. Es lohnt sich, dies von Beginn an einzuplanen, statt es nachträglich anzufügen. Verwandte Muster finden Sie in unserer Arbeit rund um Blockchain-Dokumentenmanagement.

Digitale Identität und Verifiable Credentials

Hängt maßgeblich vom Aussteller ab und davon, wie öffentlich die Nutzung sein muss. Für Identitäten, die von Unternehmen oder Behörden ausgestellt werden (Mitarbeiterausweise, Berufszulassungen), ist ein Permissioned-Ansatz sinnvoll: Der Aussteller besitzt die Autorität, die Verifizierung erfolgt anhand bekannter Vertrauensanker und der Datenschutz ist gewahrt. Bei Self-Sovereign Identity (SSI), bei der Einzelpersonen ihre eigenen Nachweise kontrollieren und jede Partei verifizieren kann, ist ein Permissionless-Modell architektonisch naheliegend. Lassen Sie sich hier keine Universallösung aufdrängen.

DeFi-Protokoll oder DEX

Permissionless – hier gibt es praktisch keine Alternative. Ein „Permissioned DeFi-Protokoll“ ist ein Widerspruch in sich. Wenn Sie eine Lösung entwickeln, die mit dem bestehenden DeFi-Ökosystem interagieren soll, ist ein Ethereum-L2 oder eine EVM-kompatible Chain der pragmatische Standard. Auch unsere Projekte im Bereich DeFi-Entwicklung landen durchweg bei diesem Ansatz.

Internes Dokumentenmanagement mit Audit-Anforderungen

Gehen Sie zurück zum vierteiligen Test. Ganz im Ernst: Wenn Dokumente von einer einzigen Organisation kontrolliert werden und der Auditor die einzige externe Partei ist, erfüllt eine sauber konzipierte Datenbank mit kryptografischer Verkettung von Datensätzen jede reale Anforderung zu einem Bruchteil der Kosten. Blockchain ist in diesem Fall fast immer eine Lösung auf der Suche nach einem Problem. Wenn jemand in Ihrem Team aus diesem Grund unbedingt Blockchain einsetzen möchte, überzeugen Sie ihn zunächst von einer sauber aufgesetzten Postgres-Datenbank – und prüfen Sie, ob das Projekt dann immer noch attraktiv wirkt.

Wann Blockchain das falsche Werkzeug ist – unabhängig vom Typ

Kaum jemand in der Blockchain-Branche schreibt diesen Abschnitt gerne. Dennoch ist er unverzichtbar, denn überzogene Versprechen sind in diesem Bereich allgegenwärtig – und langfristige Glaubwürdigkeit entsteht nur durch Ehrlichkeit. Hier sind die Szenarien, in denen eine Blockchain – ob privat oder öffentlich – die Anforderungen verfehlt und nicht die richtige Antwort für Sie ist:

• Eine einzige Partei kontrolliert ohnehin alle Daten: Eine Datenbank mit signiertem Audit-Log ist günstiger und erfüllt denselben Zweck.
• Ein vertrauenswürdiger Vermittler existiert bereits, funktioniert einwandfrei und verlangt keine überhöhten Gebühren, die eine Disintermediation rechtfertigen würden. Das Kernversprechen von Blockchain ist die Umgehung des Vermittlers: Gibt es kein Problem mit dem Vermittler, entfällt auch das Argument für die Blockchain.
• Die Performance-Anforderungen bewegen sich im echten Hochfrequenzbereich – dauerhaft Zehntausende von Transaktionen pro Sekunde. Selbst die schnellsten Blockchains spielen abseits isolierter Benchmarks noch nicht in dieser Liga. Wenn Sie eine Echtzeit-Trading-Engine oder ein Payment-Routing-System aufbauen, setzen Sie auf spezialisierte Infrastruktur.
• Datenschutzanforderungen sind unvereinbar mit dem Sichtbarkeitsmodell der Chain und Sie haben kein Budget für Privacy-Overlays eingeplant: ZK-Proofs gibt es nicht umsonst. Channels und private Transaktionen bringen jeweils eigene Kompromisse mit sich. Klären Sie dies bereits in der Konzeptionsphase, nicht erst beim Rollout.
• Regulatorische Vorgaben verlangen verbindliche Garantien zu Datenresidenz oder zum Recht auf Vergessenwerden, die sich mit der Architektur einer Blockchain nur schwer vereinbaren lassen. Das Recht auf Löschung nach DSGVO steht in natürlicher Spannung zu einem unveränderlichen Ledger. Dies ist lösbar, erfordert jedoch von Beginn an eine durchdachte Architektur.
• Das formulierte Ziel lautet: „Wir wollen etwas mit Blockchain machen.“ Wird ein Projekt ausgehend vom bloßen Wunsch nach der Technologie aufgerollt, ist das Ergebnis meist entsprechend ernüchternd. In diesem Fall: Hände weg.

Die kluge Entscheidung besteht nicht darin, zu Blockchain zu greifen, weil es auf der Roadmap steht. Sie besteht darin, die einfachste Architektur zu wählen, die den tatsächlichen Anforderungen gerecht wird. Manchmal ist das eine Public Chain. Manchmal eine Permissioned Chain. Oft ist es eine gut konzipierte Datenbank. Die Entscheidung folgt den Anforderungen, nicht einer Wunschliste an Technologien.

Marktdaten belegen starke Verbreitung von Public Blockchains bei der Tokenisierung

Ein Bereich, in dem die Debatte zwischen privaten und öffentlichen Blockchains ganz offen entschieden wird, ist die Asset-Tokenisierung – die Kategorie für tokenisierte Staatsanleihen, Real-World Assets (RWAs), Stablecoins und Security Token. Ein Blick auf die Zahlen lohnt sich, denn sie zeigen, wo Unternehmensgelder tatsächlich landen, anstatt wo Hochglanz-Fallstudien sie gerne hätten.

Eine aktuelle Übersicht von InvestaX, einem in Singapur lizenzierten Betreiber einer Tokenisierungsplattform, fasst die Daten zusammen. Stand Mai 2024 liefen rund 60 % der tokenisierten Staatsanleihen-Produkte auf Ethereum (laut The Block), 87 % des gebundenen RWA-Token-Werts lagen auf Ethereum (laut DefiLlama) und sechs der sieben führenden RWA-Protokolle setzten auf Ethereum (laut RWA.xyz). Der Bericht von Grayscale „Public Blockchains and the Tokenization Revolution“ argumentiert ähnlich: Banken haben private Infrastrukturen vor allem wegen regulatorischer Vorgaben evaluiert, Vermögensverwalter bevorzugen jedoch Public Chains oder hybride Setups.

Der gesamte Blockchain-Markt soll laut Prognosen (Fortune Business Insights) von rund 44 Mrd. $ im Jahr 2025 auf etwa 746 Mrd. $ bis 2032 wachsen – eine durchschnittliche jährliche Wachstumsrate im oberen 50er-Bereich. Ein beträchtlicher Teil dieses Wachstums entfällt auf die Tokenisierung.

Die Gründe für den Trend zu Public Chains bei diesem konkreten Anwendungsfall sind Interoperabilität (RWA-Token, die neben Stablecoins, DeFi-Sicherheiten und Liquiditätspools existieren, sind wertvoller als isolierte Token), Netzwerkeffekte (die besten Entwickler, die ausgereiftesten Tools und das meiste Kapital finden sich auf Public Chains) sowie eine zunehmende regulatorische Klarheit in wichtigen Rechtsräumen für tokenisierte Wertpapiere auf öffentlicher Infrastruktur.

Das macht Public Chains nicht automatisch zur richtigen Wahl für jedes Tokenisierungsprojekt. Eine Bank, die ihr internes Handelsbuch tokenisieren möchte und deren Kontrahenten ausschließlich andere regulierte Institute sind, hat gute Gründe für Corda oder Fabric. Für Vermögensverwalter jedoch, die Token ausgeben wollen, die gehandelt, in DeFi-Protokollen gehalten oder als Sicherheiten im gesamten Digital-Asset-Ökosystem genutzt werden sollen, sprechen die Daten eine eindeutige Sprache.

Betrachten Sie dies als einen Datenpunkt für Ihre Plattformentscheidung, nicht als Vorgabe. Der Vier-Fragen-Test am Anfang dieses Artikels gilt weiterhin: Wenn Ihr Tokenisierungs-Anwendungsfall die Interoperabilität einer Public Chain nicht zwingend erfordert, kann ein Permissioned-Setup nach wie vor die richtige Wahl sein. Zahlen wie diese sind eine Orientierungshilfe; sie ersetzen jedoch nicht die grundlegende architektonische Passung.

So treffen Sie die richtige Entscheidung: Ein Vier-Schritte-Framework

Fassen wir alles zusammen. Wenn Sie diese Fragen gerade für ein reales Projekt durchgehen, empfiehlt sich folgende Reihenfolge:

1. Führen Sie den Blockchain-Test mit den vier Fragen durch: Teilen mehrere Parteien denselben Status? Besteht nur partielles Vertrauen? Wird eine einheitliche Single Source of Truth benötigt? Sind die Kosten für Streitbeilegung hoch? Falls auch nur ein Punkt nicht zutrifft, lautet die Antwort: Bauen Sie nicht auf einer Blockchain. Testen Sie zuerst eine sauber konzipierte Datenbank.
2. Wählen Sie permissioned oder permissionless anhand der Teilnehmerstruktur: Wer nimmt teil? Gibt es bereits verifizierte Identitäten? Ist ein offener Zugang ein Produktmerkmal oder ein Compliance-Problem? Diese Frage allein klärt den Großteil der Debatte zwischen privaten und öffentlichen Blockchains.
3. Grenzen Sie die Plattform anhand der betrieblichen Rahmenbedingungen ein: Durchsatz, Finalität, Governance, Kosten, Entwickler-Stack, regulatorische Eignung und bestehende Team-Skills. Hier unterscheiden sich Ethereum, Solana, Polygon, Fabric, Corda und Cosmos in den wirklich entscheidenden Punkten.
4. Prototyping ohne Schönfärberei: Entwickeln Sie dieselbe Lösung auf den zwei plausibelsten Plattformen für Ihren Anwendungsfall. Messen Sie reale Daten, statt Pitch-Decks zu erstellen. Die meisten Teams überspringen diesen Schritt und bereuen es später – oft mit erheblichem finanziellem Aufwand. Ein zweiwöchiger Spike spart sechs Monate Entwicklungszeit auf der falschen Plattform.

Das typische Fehlermuster besteht darin, Schritt 1 zu überspringen (unter dem Druck „Der Vorstand will Blockchain“) und Schritt 4 wegzulassen (weil „Wir haben die Plattform bereits gewählt“). Beide Abkürzungen führen zu Projekten, die bis zum Scheitern so wirken, als würden sie funktionieren.

Fazit

Die Entscheidung zwischen privaten und öffentlichen Blockchains wird in den meisten Artikeln falsch dargestellt – und dieses falsche Framing ist maßgeblich dafür verantwortlich, dass viele Projekte scheitern. Der tatsächliche Entscheidungsbaum beginnt ganz oben mit der Frage „Sollten wir überhaupt eine Blockchain nutzen?“, führt in der Mitte über „permissioned versus permissionless“ und endet unten bei der Plattformauswahl – während im Hintergrund durchgehend geprüft werden muss, ob eine Blockchain schlicht das falsche Werkzeug ist.

Wenn Sie die erste Frage richtig beantworten, wird der Rest deutlich einfacher. Für die meisten Anwendungsfälle, die den Vier-Fragen-Test bestehen, ergibt sich die Entscheidung zwischen permissioned und permissionless fast von selbst, sobald feststeht, wer teilnimmt und wer validiert. Die Auswahlliste der Plattformen reduziert sich meist auf zwei Optionen, sobald nach Durchsatz, Finalität und bestehenden Team-Skills gefiltert wird. Bauen Sie einen Prototyp, bevor Sie sich festlegen – so eliminieren Sie den Großteil der verbleibenden Projektrisiken.

Wenn Sie sich gerade in dieser Phase befinden – insbesondere in dem heiklen Übergang zwischen „Wir glauben, Blockchain könnte helfen“ und „Wir sind bereit für das Scoping“ –, lohnt sich externe Unterstützung erfahrungsgemäß am meisten. Wir begleiten solche Projekte seit sieben Jahren auf beiden Seiten der Private-Public-Grenze: Wir sagen Ihnen ehrlich, auf welche Seite Ihr Problem gehört und ob eine Blockchain überhaupt das Richtige ist. Nehmen Sie Kontakt auf und wir besprechen gemeinsam, was Sie tatsächlich entwickeln möchten.