IPLD و منشأ

zev در کنار قالب اصلی کامیت‌ها، یک نمایش مبتنی بر IPLD (داده‌های پیوندیافتهٔ بین‌سیاره‌ای) از کامیت‌ها نگه می‌دارد. به این ترتیب هر کامیت یک CID با نشانی‌دهی محتوایی می‌گیرد و می‌توان منشأ را در سطح کامیت، مستقل از انبار اصلی اشیا، ردیابی کرد. ## IPLD اینجا برای چه به کار می‌رود هر کامیت در یک بلوک IPLD بازتاب داده می‌شود و نگاشتی از هش خود کامیت به CID آن در IPLD، به‌صورت محلی در `.zev/ipld_commits/` نگه داشته می‌شود. دامنهٔ این کار عمداً محدود است: نه یک سامانهٔ فایل توزیع‌شدهٔ کامل است و نه جایگزین انبار اشیای خود zev، بلکه لایه‌ای جدا و با نشانی‌دهی محتوایی است که مخصوص منشأ و پین‌کردن ساخته شده است. ## پین‌کردن منشأ یک محصول (خروجی یک ساخت، فایل یک مدل آموزش‌دیده) را می‌توان روی سرور به یک CID پین کرد و آن CID را برای یک کامیت، مالک، مخزن و شاخهٔ مشخص ثبت کرد. نتیجه پیوندی قابل حسابرسی است: با داشتن یک محصول می‌توانید آن را تا دقیقاً همان کامیتی که تولیدش کرده دنبال کنید، و خود این پیوند به‌جای یک نام فایل یا مسیر تغییرپذیر، به‌صورت رمزنگاری‌شده به یک CID گره خورده است. ## گزارش شفافیت سمت سرور سوابق منشأ پین‌شده پشتوانه‌ای از یک گزارش شفافیت روی سرور دارند. این کار به نگاشت میان محصولات و کامیت‌ها تاریخچه‌ای فقط‌افزودنی و قابل راستی‌آزمایی می‌دهد؛ همان نوع تضمینی که گزارش‌های شفافیت گواهی برای گواهی‌های TLS فراهم می‌کنند، این بار برای منشأ ساخت. ## دامنهٔ واقعی این کار عمداً محدودتر از برخی تصورهای کامل‌تر مبتنی بر IPLD برای کنترل نسخهٔ نشانی‌دهی محتوایی است، مثل یک گراف کامل AST به‌صورت IPLD، یا یک انبار اشیای کاملاً همتابه‌همتا بر پایهٔ IPFS. آنچه ساخته شده و کار می‌کند بخش مشخص و مفید همان ایده است: کامیت‌ها CID واقعی می‌گیرند و محصولات را می‌توان به‌طور اثبات‌پذیر به کامیتی که تولیدشان کرده گره زد.