Vertrauenslosigkeit erfordert keine unverifizierbaren Ergebnisse. Die Herkunft von Software basierte auf sozialen Annahmen, aber Proof of Build verankert sie mit verifizierbaren Onchain-Beweisen. Ein tieferer Einblick in den 7-Schritte-Workflow ↓

Schritt 1: Initiierung Ein Entwickler committet Code, und die Änderungen werden in ein Repository in der Build-Umgebung gepusht.

Schritt 2: Artefaktkonstruktion Die CI/CD-Pipeline kompiliert die Binärdatei und generiert eine SLSA-Herkunftsdatei, die über die Sigstore-Infrastruktur signiert wird.

Schritt 3: Eingabe (zkVM-Eingabe) Das zkVM-Gastprogramm nimmt Folgendes entgegen: ▶︎ SLSA-Provenienz-Bundle ▶︎ Festgelegte Sigstore-Vertrauenswurzeln (Fulcio CA, TSA-Öffentliche Schlüssel) ▶︎ Zeitstempelung (TSA oder Rekor-Transparenzprotokolle) ▶︎ Erwartete Richtlinie (optional, z.B. erlaubte Build-Digests)

Schritt 4: Ausführung Innerhalb der Zero-Knowledge-Umgebung führt das Gastprogramm Schritte aus, um die Signaturen, die Zertifikatskette und die Zeitstempel zu überprüfen. Ein ZK-SNARK-Beweis wird generiert, um zu beweisen, dass die Herkunftsüberprüfung erfolgreich war.

Schritt 5: Onchain-Einreichung Der prägnante ZK-Beweis wird an den Ethereum-Smart-Contract übermittelt.

Schritt 6: Bestätigung Der Smart Contract validiert die Beweisberechnungen und gibt ein verifiziertes Ereignis mit den Build-Ergebnissen aus.

Schritt 7: Endgültige Vertrauensüberprüfung Der nachgelagerte Prüfer konsumiert das On-Chain-Ereignis, um dem Artefakt zu vertrauen.