Tillitsløshet krever ingen uverifiserbare resultater. Programvareproveniens har vært avhengig av sosiale antakelser, men Proof of Build forankrer det med verifiserbare onchain-bevis. En dypere innblikk i 7-trinns arbeidsflyten ↓
Trinn 1: Innvielse En utvikler committer kode, og endringene blir sendt til et repository i byggemiljøet.
Trinn 2: Artefaktkonstruksjon CI/CD-pipelinen kompilerer binærfilen og genererer en SLSA-proveniensfil, som signeres via Sigstore-infrastrukturen.
Trinn 3: Inntak (zkVM-inngang) ZkVM-gjesteprogrammet tar imot: ▶︎ SLSA proveniensbunt ▶︎ Pinned Sigstore trust roots (Fulcio CA, TSA public keys) ▶︎ Tidsstempling (TSA eller Rekor transparenslogger) ▶︎ Forventet policy (valgfritt, f.eks. tillatte build-digests)
Trinn 4: Gjennomføring Inne i nullkunnskapsmiljøet utfører gjesteprogrammet trinn for å verifisere signaturer, sertifikatkjeden og tidsstempler. Et ZK-SNARK-bevis genereres for å bevise at proveniensverifiseringen lyktes.
Trinn 5: Onchain-underkastelse Det kortfattede ZK-beviset sendes til Ethereum smartkontrakten.
Trinn 6: Attestering Smartkontrakten validerer bevismatematikken og sender ut en verifisert hendelse som inneholder byggeresultatene.
Trinn 7: Siste verifisering av tillit Den nedstrøms verifikatoren konsumerer onchain-hendelsen for å stole på artefaktet.
935