Lass mich hier ins Detail gehen. Hier ist ein realistisches Bild davon, was ich wirklich meinte, als ich sagte, dass die **Last** der Verifizierung verschoben wurde. Kontext: In modernen SGX/TDX TEE-Protokollen sendet der PROVER: + Attestierungsnachweise (Zitat/Bericht) + Verifizierungsunterlagen, die zur Validierung benötigt werden ODER Die Protokolle verlassen sich auf eine 3. Partei und NICHT auf Intel als Quelle der Wahrheit für ihre Unterlagen. Jetzt ist es nicht so problematisch, dass der Prover selbst die für die Verifizierung benötigten Materialien (Unterlagen) an den Verifier oder eine 3. Partei sendet, die kritische Entscheidungsartefakte bereitstellt, wie es auf den ersten Blick scheint. Aber wir müssen durch etwas Schlamm waten, um das richtig zu machen. Lass mich dir sagen, warum. Diese Designentscheidung ist größtenteils ein Kompromiss zwischen Praktikabilität und Verfügbarkeit. Viele Verifier WOLLEN NICHT bei jedem Handshake von Live-Intel-Netzwerkanrufen abhängig sein. Fair. Also, welche Designentscheidungen konzentrieren sich die Leute typischerweise: 1. Verifier ruft direkt von Intel PCS ab, um die PCK-Zertifikatskette, PCK-CRLs, TCBInfo, QEIdentity usw. abzurufen. Gut: Frische Stonk, Rollback-Risiko ist vernachlässigbar Schlecht: Verifier benötigt ausgehendes Netzwerk + Intel-Verfügbarkeits-/Latenzprobleme 2. Verifier ruft von einem vertrauenswürdigen Cache (PCCS) ab. Hier haben wir einen Provisioning Certificate Caching Service, der mit Intel PCS synchronisiert und als Quelle der Wahrheit für Verifier angesehen wird (anstatt Intel)....