Zum Inhalt springen

Research Prototype

ChainFlow

Prüfen, ob ein B2B-Rechnungsworkflow ohne zentrale Vertrauensinstanz nachvollziehbar bleibt.

Research PrototypeDokumentiertDemo
Rolle
Forschungsprototyp
Status
Demo / Research Prototype — kein produktives System
Einordnung
Research Prototype
Erfasst0x03…Signiert0x0a…Registriert0x11…Bezahlt0x18…AUDIT TRAIL · DEMO-CHAIN

Wie der Workflow funktioniert

Vertrauensgrenze
  1. Off-Chain

    Rechnung wird erfasst

    Unternehmen A

    PDF und Metadaten werden erfasst. Daraus entsteht ein Hash — der Fingerabdruck genau dieses Dokumentstands.

    ErgebnisHash

  2. Off-Chain

    Absender signiert

    Unternehmen A

    Der Inhalt wird per EIP-712-Signatur bestätigt: nachweisbar, wer welchen Stand freigegeben hat.

    ErgebnisEIP-712-Signatur

  3. On-Chain

    Smart Contract speichert Status

    Smart Contract

    Die Registrierung erfolgt auf der Demo-Chain. Jeder Statusübergang ist ein protokolliertes Ereignis.

    ErgebnisOn-Chain-Registrierung

  4. On-Chain

    Alle sehen denselben Stand

    A · B · Explorer

    Ereignisse verteilen die Statusänderung an alle Beteiligten. Keine Partei kontrolliert die maßgebliche Datenbank.

    ErgebnisEvent

StatusübergängeRegistriertBezahltStorniert
DEMO-CHAIN · KEIN PRODUKTIVES SYSTEM

Vier Schritte eines Rechnungsworkflows: Erfassung und Signatur laufen ausserhalb der Chain, Registrierung und Statusübergänge auf einer Demo-Chain. Danach sehen Absender, Empfänger und Explorer denselben Stand.

Kontext

ChainFlow ist ein technischer Demonstrator, der im Rahmen einer Bachelorarbeit von Vencel Somos entstanden ist. Er läuft auf einer Demo-Chain und ist kein produktives Zahlungssystem.

Geschäftliches Problem

In B2B-Rechnungsprozessen zwischen mehreren Parteien ist häufig strittig, welcher Dokumentstand wann gültig war und wer welchen Status wann gesetzt hat. Die Untersuchungsfrage war, ob sich dieser Nachweis führen lässt, ohne dass eine der beteiligten Parteien die maßgebliche Datenbank kontrolliert.

Mandat und Rolle

Verantwortung von Somos-Co

Eigenständiges akademisches Projekt von Vencel Somos, vollständig in eigener Verantwortung entwickelt.

Verantwortung von Partner/Kunde

Nicht zutreffend — kein Kundenmandat und kein Auftraggeber.

Außerhalb der Rolle

Kommerzieller Einsatz ist ausdrücklich ausgeschlossen; ebenso ein produktives Zahlungssystem, eine Zahlungsabwicklung, eine Prüfung regulatorischer Anforderungen an Rechnungslegung oder Zahlungsverkehr und ein Sicherheitsaudit des Smart Contracts.

Vorgehen

  1. 1

    Entwurf eines Rechnungsworkflows mit definierten Statusübergängen

  2. 2

    Implementierung eines Smart Contracts für die Statuslogik

  3. 3

    Signatur der Vorgänge nach EIP-712

  4. 4

    Hash-basierte Integritätsnachweise für die Dokumentstände

  5. 5

    Ereignisbasierte Statusänderungen als Audit Trail

  6. 6

    Full-Stack-Anwendung für die Bedienung des Workflows

Technischer Umfang

Anwendung

  • Smart Contract auf einer Demo-Chain
  • Full-Stack-Webanwendung

Daten

  • EIP-712 Typed-Data-Signaturen
  • Hash-basierte Integritätsprüfung
  • Event-basierte Statusänderungen

Betriebsmodell

Der Prototyp läuft als Demonstrator auf einer Demo-Chain. Es gibt keinen produktiven Betrieb, keine Betriebsverantwortung und keine Betriebsprozesse im Sinne eines Managed Service.

Aktueller Status

Abgeschlossener Prototyp. Öffentlich zugänglich als Demonstrator.

Ergebnis und Belege

  • Der Workflow zeigt, dass Statusübergänge und Dokumentintegrität nachvollziehbar protokolliert werden können, ohne dass eine Partei die maßgebliche Datenbank kontrolliert.
  • Signatur und Hash-Nachweis machen nachträgliche Änderungen erkennbar.

Grenzen dieser Aussagen

  • Demo und Forschungsprototyp — kein produktives System.
  • Kein produktives Zahlungssystem und keine Zahlungsabwicklung.
  • Läuft auf einer Demo-Chain, nicht in einer produktiven Netzwerkumgebung.
  • Keine Prüfung auf regulatorische Anforderungen an Rechnungslegung oder Zahlungsverkehr.
  • Kein Sicherheitsaudit des Smart Contracts.

Nächster Schritt

Keine Produktisierung geplant. Der Prototyp bleibt als Demonstrator und als Grundlage für die Bewertung ähnlicher Fragestellungen bestehen.

Passende Leistungen

Externe Website

Problem Check

Welche geschäftliche Entscheidung braucht eine belastbare Grundlage?

Beschreiben Sie Herausforderung, betroffenen Prozess und Zeithorizont. In einem ersten Problem Check klären wir, welche Fragen ein Dynamic Model beantworten sollte.

Für Anwendungen, Plattformen, IoT- und Digital-Twin-Vorhaben sowie Managed Operations.

peter.somos@somos-co.com