Cardano-Entwicklungsunternehmen auswählen: Leitfaden 2026

Ein Angebot für Cardano-Entwicklung kann den Validator in Aiken oder Haskell im Detail beschreiben und zugleich offenlassen, wer die Software verantwortet, die jede Transaktion vorbereitet. Im Cardano-Modell führt der Validator den Vorgang nicht aus: Er erhält eine bereits fertig gebaute Transaktion und prüft, ob sie seine Bedingungen erfüllt. Die Auswahl der Inputs, die Berechnung der Outputs, die Signatur in derWalletund die Neuerstellung, wenn eine andere Transaktion zuvorkommt, geschehen off-chain, in Code, den ebenfalls jemand entwickeln muss.

An diesem Off-Chain-Code zeigt sich, wie viel praktische Cardano-Erfahrung ein Team tatsächlich hat. Deshalb sollten Sie einen Dienstleister danach beurteilen, wie er Transaktionen baut, übermittelt und neu erstellt, und nicht nur danach, wie er Validatoren schreibt. Dieser Leitfaden erläutert, was das Netzwerk heute validiert, welche Fragen ein im EUTXO-Modell erfahrenes Team von einem unterscheiden, das Gewohnheiten aus kontobasierten Netzwerken überträgt, wie mit dem Audit umzugehen ist und welche Demonstration Sie verlangen sollten, bevor Sie Kostenvoranschläge vergleichen. Herausgeber ist Metlabs, ein Unternehmen, das auf Cardano entwickelt und an dieser Auftragsvergabe ein kommerzielles Interesse hat; die technischen Angaben stammen aus der offiziellen Cardano-Dokumentation, abgerufen am 8. November 2026.

Was Cardano nach dem Hard Fork van Rossem validiert

Cardano erfasst den Zustand in nicht ausgegebenen Outputs, die jede Transaktion vollständig und nur ein einziges Mal verbraucht, nach demEUTXO-Modellaus der Cardano-Dokumentation. Ein Validator erhält die Transaktion, die Daten des Outputs und einen Redeemer und entscheidet, ob dieser Output ausgegeben werden darf. Da die Gültigkeit nur von der Transaktion und ihren Inputs abhängt, lässt sie sich off-chain prüfen, bevor die Transaktion übermittelt wird. Dieselbe Dokumentation nennt auch die Grenze: Die Transaktion scheitert, wenn eine andere zuvor einen ihrer Inputs verbraucht; sind alle noch verfügbar, ist die Validierung garantiert.

Diese Eigenschaft verteilt die Arbeit auf eine bestimmte Weise. Der Validator kann kurz sein und früh fertiggestellt werden, während der Code, der Inputs auswählt, Gebühren berechnet, Signaturen einholt und über das Vorgehen nach einem Konflikt entscheidet, mit dem Produkt weiterentwickelt wird. In einem Angebot entscheidet dieser zweite Teil darüber, ob zwei Nutzer gleichzeitig agieren können, ohne sich zu blockieren, und was jeder von ihnen sieht, wenn seine Transaktion nicht mehr gültig ist. DieTechnologieseite zu Cardanoerläutert die Architektur des Netzwerks und dasUTXO-Glossar, das Output-Modell.

Das Netzwerk hat in diesem Jahr die Protokollversion gewechselt. Der Hard Fork van Rossem wurde am 18. Juli 2026 in Epoche 644 aktiviert und hob Cardano innerhalb der Conway-Ära auf Protokollversion 11.0. Laut demoffiziellen Hard-Fork-Verzeichnisbringt er bereinigte Ledger-Regeln, die Eindeutigkeit von VRF-Schlüsseln, Performance-Verbesserungen bei Plutus und neue kryptografische Primitive. Für den Auftraggeber hat das eine praktische Folge: Ein heute verfasstes Angebot kann angeben, mit welcher Plutus- und Compiler-Version die Validatoren erzeugt werden und ob das Design eines dieser Primitive nutzt oder die Kompatibilität mit früheren Versionen beibehält.

Die Off-Chain-Arbeit eines Cardano-Entwicklungsunternehmens bewerten

Das erste Signal ist, wie der Kandidat die Aufteilung des Zustands beschreibt. Ein Team mit Cardano-Praxis fragt, wie viele Nutzer gleichzeitig auf denselben Daten arbeiten werden, denn daraus ergibt sich, wie viele Outputs das Design braucht und wie viel Off-Chain-Logik nötig ist, um diesen Zustand aufzuteilen und wieder zusammenzuführen. Beschreibt das Angebot nur den Validator und fasst den Rest als Wallet-Integration zusammen, hat der Code, der darüber entscheidet, ob sich zwei Käufer gegenseitig blockieren, noch keinen Verantwortlichen.

Das zweite ist die Datenquelle. Die Anwendung muss die Chain lesen, um zu wissen, welche Outputs sie ausgeben kann, und dafür gibt es drei Wege mit unterschiedlichen Folgen: einen eigenen Node, den der Kunde betreibt und kontrolliert; ein Open-Source-Tool, das der Kunde bei einem Anbieterwechsel selbst prüfen und pflegen kann; oder einen gehosteten Dienst, der den Start vereinfacht und eine operative Abhängigkeit mit eigener Support-Vereinbarung schafft. Das Angebot muss angeben, welcher Weg in welcher Version genutzt wird und was weiterhin funktionieren würde, wenn dieser Dienst wegfällt.

Das dritte sind die Abhängigkeiten. Der Code, der Transaktionen baut, stützt sich in der Regel auf Bibliotheken Dritter, und deren Pflege gehört zum Leistungsumfang, auch wenn der Anbieter sie nicht selbst schreibt: Jemand muss sie aktualisieren, wenn sich das Protokoll ändert, wie bei van Rossem geschehen, und prüfen, dass das Produkt weiterhin gültige Transaktionen erzeugt.

Audit des Validators: Wer prüft jede Version?

Der Validator entscheidet, ob Mittel bewegt werden dürfen, und wenn das Produkt Werte Dritter verwahrt, liegt dort das Hauptrisiko. EinAuditauf Cardano kann manuelle Prüfung, eigenschaftsbasierte Tests und formale Verifikation kombinieren. Das Angebot muss angeben, welche Methoden angewendet werden, auf welche Code-Version und mit welcher Plutus- und Compiler-Version, denn ein neu kompilierter Validator ist nicht mehr exakt derjenige, der geprüft wurde.

Die heikelste Frage ist die Unabhängigkeit. Entwickelt und auditiert dasselbe Unternehmen, muss das Angebot klarstellen, wer jede Version prüft, denn ein Audit des eigenen Codes ist keine unabhängige Prüfung. Als Erfahrungsnachweis sagt eine Liste von Ökosystem-Projekten ohne Angabe der jeweils geleisteten Arbeit wenig aus; aussagekräftig ist die Referenz eines Kunden, der erklären kann, was das vorgeschlagene Team geliefert hat.

Metlabs: Validatoren und Transaktionen innerhalb der Anwendung

Metlabs ist ein Blockchain-Entwicklungsstudio mit Büros in A Coruña und Madrid. Wir entwickeln Cardano-Validatoren zusammen mit dem Off-Chain-Code, dem Backend und der Oberfläche, die sie nutzen, für Unternehmen, die eine funktionierende Anwendung brauchen und nicht nur den Contract. Unsereigenes technisches Teamumfasst Produktdefinition, Architektur, Contracts, Backend und Oberfläche; das Angebot nennt die Komponenten, die eingesetzten Personen und die Verantwortlichkeiten jeder Seite.

Produktentscheidungen und Umfang der Integration

Unser Ansatz fürBlockchain-Entwicklunggeht von den Zuständen aus, die ein Geschäftsvorgang durchläuft. Auf Cardano wird jeder Zustand zu Outputs mit Daten und zu den Bedingungen des Validators, unter denen sie ausgegeben werden dürfen. Das Angebot legt fest, wer jeden Schritt autorisieren darf und welche Informationen die Software braucht, um die jeweilige Transaktion zu bauen.

Ein hypothetisches Beispiel macht das anschaulich: eine Anwendung, die die letzten Plätze eines Kurses mit begrenzter Teilnehmerzahl verkauft. Liegt das Kontingent in einem einzigen Output, bereiten zwei Käufer, die gleichzeitig signieren, Transaktionen auf denselben Input vor, und nur eine erreicht die Chain. Die andere scheitert, wie es das EUTXO-Modell vorsieht, und die Anwendung muss das erkennen, den Vorgang auf dem neuen Zustand neu aufbauen oder melden, dass keine Plätze mehr frei sind. Wird das Kontingent auf mehrere Outputs verteilt, sinken diese Konflikte, dafür steigt der Off-Chain-Aufwand. Diese Designentscheidung muss im Angebot schriftlich begründet werden.

Für die Abnahme des Projekts spielen wir dieses Szenario über die Oberfläche durch: erfolgreicher Kauf, wegen fehlender Plätze abgelehnter Kauf und nach einem Konflikt neu erstellte Transaktion. Im Vergleich mit anderen Teams ist genau diese Demonstration durch die eingesetzten Personen der brauchbare Nachweis; eine Liste von Programmiersprachen oder allgemeine Erfahrung mit Contracts belegt für sich genommen keine produktive Arbeit auf Cardano.

Was das Angebot von Metlabs enthalten sollte

• Zustands- und Output-Modell mit den Ausgabebedingungen jedes Validators und den jeweils autorisierungsberechtigten Personen.
• Prototyp für Bau, Signatur und Übermittlung von Transaktionen, einschließlich der Reaktion, wenn ein anderer Vorgang denselben Input zuvor verbraucht.
• Integration von Wallet, Chain-Datenquelle und Backend, mit einem Verantwortlichen für jedes Tool.
• Nebenläufigkeits- und Recovery-Tests, festgelegte Plutus- und Compiler-Versionen und Dokumentation für die Übergabe.

Die Arbeit folgt den Phasen, die wir in unseremService für Blockchain-Entwicklungerläutern: Discovery, Architektur und Design, iterative Entwicklung und Validierung vor der Produktivsetzung. Zu Projektbeginn vereinbaren wir die erste zu bauende User Journey und ihre Abnahmekriterien, um den Fortschritt anhand einer funktionsfähigen Lieferung zu prüfen. Externe Audits, spezialisierte Integrationen und der anschließende Support werden im Angebot abgegrenzt.

Umden Umfang mit Metlabs zu prüfen, teilen Sie uns den Vermögenswert oder Prozess, seine Nutzer, die bestehenden Systeme und die Vorgänge mit, die die erste Version ermöglichen muss. Mit diesen Informationen können wir Abhängigkeiten identifizieren und ein Angebot vorbereiten, das Sie mit denen anderer Kandidaten vergleichen können.

Cardano-Entwicklungsunternehmen wählen: Entscheidend ist der nachgewiesene Bau von Transaktionen

Validatoren schreiben alle Kandidaten; der Unterschied liegt darin, wo sie den Rest der Arbeit verorten und ob sie ihn sichtbar machen. Manche Teams bringen eine eigene Dateninfrastruktur mit, andere legen den Schwerpunkt auf die Sicherheit der Regeln, wieder andere organisieren Validatoren und Transaktionen rund um die Anwendung und die Systeme des Kunden. Um sie unter gleichen Bedingungen zu vergleichen, geben Sie allen dasselbe Szenario mit Nebenläufigkeit vor und verlangen eine Demonstration mit vorbereiteten, abgelehnten und neu erstellten Transaktionen, bevor Sie Stunden oder Kosten vergleichen.

Diese Demonstration klärt, was eine Liste von Programmiersprachen offenlässt. Ein Team, das Cardano noch nie in Produktion gebracht hat, behandelt das Scheitern wegen eines verbrauchten Inputs meist als seltenen Fehler; ein Team mit Produktionserfahrung behandelt es als normales Verhalten des Netzwerks und gestaltet die Nutzererfahrung von dort aus, so wie es das EUTXO-Modell verlangt.

Was ein Angebot für Cardano-Entwicklung enthalten sollte

• Zustand: Outputs, die jeder Vorgang nutzt, die enthaltenen Daten und die Ausgabebedingungen des Validators.
• Nebenläufigkeit: Was passiert, wenn zwei Transaktionen um denselben Input konkurrieren, und wie der Nutzer informiert wird.
• Daten und Übermittlung: Chain-Datenquelle (eigener Node, gehosteter Dienst oder offenes Tool), Übermittlung und Nachverfolgung jeder Transaktion.
• Übergabe: Code, Plutus- und Compiler-Versionen, Tests, Lizenzen der Abhängigkeiten und Verantwortlicher für die Wartung.

Kommt für das Projekt noch ein anderes Netzwerk infrage, erläutert derallgemeiner Leitfaden zu Blockchain-Entwicklungsunternehmen, wie sich Teams unabhängig von der Chain bewerten lassen. Auf Cardano ist ein Angebot vollständig, wenn der Validator und der Code, der die Transaktionen zusammensetzt, im gleichen Detailgrad beschrieben sind und denselben Verantwortlichen für die Wartung haben.