さて、2ヶ月の堅実な努力の末、私はタップアウトします。 「TEE で Groth16 の信頼できるセットアップを行い、有毒廃棄物が破壊されたというリモート証明を取得する」プロジェクトは失敗に終わりました。以下にTLDRします。 ここで言及するのは、実際には私がまだ取り組んでいると思っているという理由で、誰かがそれに取り組んでいると思いとどまらせたくないからです。

TLDRの: - 現在、これを実現できる唯一の TEE (AFAICT) は TDX で、必要な暗号化 RAM が保証されているためです。(このプロジェクトでは、TEEで正しいコードが実行されていることを知るだけでは不十分であり、マシンの物理的な攻撃者が式典中にRAMをダンプして有毒廃棄物を学ぶことができないことも知っておく必要があります)。 - TDX リモート構成証明は、VM イメージの任意のバイトが変更された場合に変更されるハッシュである "MRTD" を経由して署名します。 - したがって、将来の監査人/ユーザーが、信頼できるセットアップ中に(特にあらゆる種類の自動化された方法で)正しいコードを実行していたことを確認するためには、そのMRTDハッシュを再現できる必要があり、そのためには、人間が読めるソースコードからVMイメージをビットごとに再現可能な方法で再構築する必要があります。 - GCPイメージをビット単位で再現可能な方法で作成できませんでした。(超最小限のものでも、SSHポートを起動して開くだけで、文字通り他には何も開きません)。

I am not sure this is possible with existing off-the-shelf tooling. It may require tweaking existing tooling. StageX was profoundly helpful, so I recommend using that as much as possible. The problems come when you need anything not currently available via an StageX layer. For then you need to build whatever you need from source (as downloading tarballs without building them yourself is a supply chain risk). And I’ve found that building/compiling _most_ software from source in a bit-for-bit reproducible way is extraordinarily time consuming, difficult, and brittle. And in many cases I’ve been unable to do it *at all*.

必要なソフトウェアのビルドは、ハッシュピンされたStageXレイヤーのみで構成されるDockerコンテナ内で行うことをお勧めします。そのテクニックは私に最も多くの走行距離を与えました。