Zaryn چطور کار می‌کند، گام به گام

Zaryn چطور ساخته شده، برای هر کنجکاوی و برای معماران یا بازبین‌های امنیتی که می‌خواهند تصمیم بگیرند به آن اعتماد کنند یا نه. کدی برای اجرا نیست: فقط یک کامیت را در سامانه دنبال کنید. ## ۱. یک ایده: داده را با محتوایش نام‌گذاری کن ```diagram type: graph title: بایت‌های یکسان، نام یکسان؛ بایت‌های تازه، نام تازه alt: بایت‌های یک فایل به نامش هش می‌شوند؛ فایل یکسان همان نام را می‌گیرد و یک بار ذخیره می‌شود؛ فایل ویرایش‌شده نامی تازه می‌گیرد height: 36 --- node a | logo.png | 10 8 | file | | چند بایت node b | کپی logo.png | 10 28 | file | | همان بایت‌ها، جای دیگر node h | 9f2c… | 50 8 | hash | accent | هش بایت‌ها همان نام است: یک بار ذخیره می‌شود node e | logo.png ویرایش‌شده | 90 28 | file | warn | یک بایت عوض شد node h2 | 41ab… | 90 8 | hash | good | نامی تازه برای بایت‌های تازه link a h | | path link b h | همان نام | path link e h2 | | new ``` هر چیز (یک فایل، یک پوشه، یک کامیت) با **هش** بایت‌های خودش نام‌گذاری می‌شود: اثر انگشتی کوتاه که اگر حتی یک بایت عوض شود کاملاً تغییر می‌کند. سه چیز رایگان به دست می‌آید: - **دادهٔ یکسان یک بار ذخیره می‌شود**، هر جای تاریخچه که باشد. - **هیچ چیزی بی‌صدا عوض نمی‌شود**: بایت‌های تغییرکرده نام دیگری دارند، پس نام قدیمی همچنان یعنی بایت‌های قدیمی. - **هر کسی می‌تواند بسنجد** که چیز درست را گرفته: آنچه رسیده را هش و مقایسه کنید. ## ۲. بخش‌ها ```diagram type: graph title: چهار بخش، یک ذخیره‌گاه از اشیای نام‌دار alt: zev روی رایانهٔ شما با zev-api ارسال و دریافت می‌کند؛ zev-api در هر push، zev-ci را به کار می‌اندازد؛ وب‌سایت همان اشیا را نشان می‌دهد؛ zev می‌تواند snapshotها را روی IPFS منتشر کند legend: path=ارسال و دریافت; path2=CI در هر push height: 44 --- box رایانهٔ شما | 2 2 26 40 | dim node cli | zev | 14 14 | laptop | accent | خط فرمان، یک باینری بومی به زبان Zig. کامیت، شاخه و تاریخچه آفلاین کار می‌کنند node ipfs | IPFS | 14 34 | storage | | snapshotهای منتشرشده، بازشدنی با هر نود IPFS node api | zev-api | 52 20 | server | | سرور، به زبان Zig: اشیا روی دیسک، فراداده در PostgreSQL، API از نوع JSON، ورود و دسترسی node web | وب‌سایت Zaryn | 88 8 | cloud | good | همان اشیا را با همان نام‌ها می‌خواند node ci | zev-ci | 88 34 | ci | | در هر push، pipelineها را در کانتینرهای قفل‌شده اجرا می‌کند link cli api | push، pull | path link cli ipfs | | ghost link api web | | dim link api ci | | path2 ``` ## ۳. هر چیز کجا زندگی می‌کند ```diagram type: cards --- 💻 | روی رایانهٔ شما | `.zev/objects/`: هر شیء، فشرده، با نام SHA-256. همه‌چیز آفلاین کار می‌کند | accent 🗄 | روی سرور | اشیا روی دیسک با نام BLAKE3؛ کاربران، مخزن‌ها، refها و دسترسی‌ها در PostgreSQL | 🌐 | روی IPFS | snapshotها و فایل‌های پین‌شده: CIDای که هر کسی می‌تواند بیابد، نه فقط Zaryn | good 🔏 | در لاگ شفافیت | سابقه‌ای فقط‌افزودنی و امضاشده از پین‌ها، رسیدها و گواهی‌ها | ``` ## ۴. یک کامیت، ساخته‌شده آفلاین ```diagram type: graph title: یک کامیت زنجیره‌ای از نام‌هاست alt: فایل‌ها به blob، پوشه‌ها به درخت‌هایی که آن‌ها را فهرست می‌کنند هش می‌شوند، و یک کامیت درخت و والدش را نام می‌برد، پس نام کامیت همه‌چیز زیرش را می‌پوشاند height: 46 --- node c2 | کامیت | 50 6 | commit | accent | درختش، کامیت والد، نویسنده و پیام را نام می‌برد node c1 | والد | 88 6 | commit | dim | کامیت پیشین node t | درخت / | 50 22 | folder | | هر فایل و پوشه را با نام و هش فهرست می‌کند node s | src/ | 30 38 | folder | node r | README.md | 70 38 | file | node m | main.zig | 12 38 | file | link c2 c1 | والد | dim link c2 t | | path link t s | | path link t r | | path link s m | | path ``` `zev commit` هر فایل تغییرکرده را هش می‌کند، سپس هر پوشه (فهرستی از نام‌ها و هش‌ها)، سپس کامیت را، که پوشه‌اش و کامیت پیشین را نام می‌برد. پس نام یک کامیت **هر بایت زیرش و کل تاریخچهٔ پیش از آن** را می‌پوشاند. هر چیزی را هر جا عوض کنید، هر نامی بالاتر از آن عوض می‌شود. هیچ شبکه‌ای در کار نیست. ## ۵. ارسال: دو نام، ثبت‌شده ```diagram type: graph title: یک شیء، دو نام، در هر push ثبت می‌شود alt: کلاینت هر شیء را با SHA-256 نام می‌برد، سرور آن را زیر BLAKE3 ذخیره می‌کند و مانیفست ارسال هر دو را ثبت می‌کند height: 30 --- node local | رایانهٔ شما | 12 14 | laptop | | نام‌های SHA-256 node man | manifest/main | 50 14 | log | accent | برای هر شیء از push: نام محلی و نام سرورش node server | سرور | 88 14 | storage | good | نام‌های BLAKE3، دسته‌بندی‌شده روی دیسک link local man | local_hash | path link man server | server_hash | path2 ``` `zev push` فقط اشیایی را می‌فرستد که سرور هنوز ندارد، به‌اضافهٔ یک **مانیفست** که هر دو نام هر شیء را ثبت می‌کند، تا سرور همیشه بداند کدام اشیایش را کدام push آورد و چطور با اشیای شما متناظرند. ## ۶. فایل‌های بزرگ: فقط آنچه عوض شد ```diagram type: stats title: ویرایشی ۹۳ بایتی نزدیک آغاز یک فایل ۱٫۷ مگابایتی --- 96.5% | از بایت‌ها دست‌نخورده | به تفکیک تکه، بایت به بایت | 96 | good ~1% | از تکه‌ها دوباره فرستاده شد | بقیه از پیش در هر دو طرف بودند | 1 | accent 100% | با ذخیرهٔ کل فایل | هزینهٔ یک ویرایش یک‌خطی بدون تکه‌ها | 100 | bad ``` فایل‌های بزرگ جایی تکه می‌شوند که خود بایت‌ها می‌گویند (یک هش غلتان، از همان خانواده‌ای که restic و borg به کار می‌برند)، نه هر N بایت. یک افزودن فقط تکه‌های اطرافش را عوض می‌کند، پس push و pull فقط همان‌ها را جابه‌جا می‌کنند. [تکه‌بندی چطور کار می‌کند](/docs/fa/chunking). ## ۷. دریافت و کلون: سنجیده هنگام رسیدن ```diagram type: flow title: هیچ چیزی پیش از سنجیده شدن به کار نمی‌رود --- درخواست | آنچه هنوز ندارید، دسته‌ای، برای مخزن‌های بزرگ چهار تا هم‌زمان | | ⇣ ~ هنگام رسیدن هر کدام سنجش | هشش را بگیرید و با نامش مقایسه کنید | accent | # ~ تنها پس از آن استفاده | ذخیره‌شده، و فایل‌هایتان به‌روز | good | ✓ ``` چون هر شیء با هشش نام‌گذاری می‌شود، یک شیء خراب یا جایگزین‌شده همان لحظهٔ رسیدن گیر می‌افتد، از هر جا که آمده باشد: Zaryn، یک آینه، یا هم‌تیمی‌ای در [شبکهٔ خصوصی](/docs/fa/private-networks) شما. ## ۸. آنچه نمی‌تواند بی‌صدا عوض شود ```diagram type: cards --- 📜 | تاریخچه | نام یک کامیت درخت و والدش را می‌پوشاند: بازنویسی یک کامیت هر نام پس از آن را عوض می‌کند | accent 🔗 | پیوند به فایل‌ها | یک CID دقیقاً همان بایت‌ها را باز می‌کند، روی هر نود IPFS | good 📦 | بسته‌های منتشرشده | با هش ذخیره می‌شوند؛ یک نسخه هرگز جایگزین نمی‌شود | ✍ | کامیت‌های امضاشده | `zev sign` امضای هویت شما را می‌افزاید؛ `zev verify` می‌سنجدش (امضا گامی است که خودتان برمی‌گزینید) | ``` نشانی‌دهی محتوایی تغییر را **آشکارشدنی** می‌کند. امضاها، رسیدها و لاگ شفافیت (فصل‌های بعد) **اینکه چه کسی** کاری کرد و **کی** را هم سنجش‌پذیر می‌کنند. ## ۹. اثبات اینکه داده‌تان واقعاً نگه داشته می‌شود ```diagram type: sequence title: zev verify-storage lanes: zev | Zaryn | لاگ شفافیت alt: Zaryn اشیایش را دوباره می‌خواند و رسیدی امضا می‌کند؛ zev می‌سنجد که push در آن هست، امضا درست است و رسید در لاگ ثبت شده --- note Zaryn : هر شیء را با هشش دوباره می‌خواند و رسیدی امضا می‌کند | good zev -> Zaryn : آخرین رسید note zev : همهٔ push آخرم هست؟ امضا از Zaryn است؟ zev -> لاگ شفافیت : رسید ثبت شده؟ لاگ شفافیت --> zev : بله، و بعداً عوض نمی‌شود ``` ریاضی، نه وعده: `zev verify-storage`، یا همان کد در مرورگرتان. [ذخیره‌سازی بررسی‌پذیر](/docs/fa/verified-storage). ## ۱۰. از یک مصنوع تا کامیتش ```diagram type: graph title: منشأ، هش به هش alt: یک کامیت CID از نوع IPLD دارد؛ مصنوعی مثل یک فایل مدل به CID خودش پین می‌شود؛ یک رکورد منشأ این دو را به هم گره می‌زند و به لاگ شفافیت افزوده می‌شود legend: path=گره‌خورده با هش height: 40 --- node c | کامیت | 10 10 | commit | accent | در یک بلوک IPLD با CID خودش بازتاب می‌شود node a | model.safetensors | 10 32 | file | | یک خروجی ساخت، پین‌شده به CID خودش node rec | رکورد منشأ | 50 21 | log | | این مصنوع از این کامیت، از این مخزن و شاخه آمده node log | لاگ شفافیت | 88 21 | storage | good | فقط‌افزودنی: رکورد بی‌صدا حذف نمی‌شود link c rec | | path link a rec | | path link rec log | افزوده | path ``` با داشتن یک فایل، می‌توانید آن را تا دقیقاً همان کامیتی که ساختش دنبال کنید، و خود این پیوند با هش‌ها گره خورده، نه با نام فایلی که کسی بتواند عوضش کند. [IPLD و منشأ](/docs/fa/ipld-provenance). ## ۱۱. لاگ شفافیت ```diagram type: flow title: لاگی که فقط بزرگ می‌شود --- افزودن | پین‌ها، رسیدهای ذخیره‌سازی، هشدارها، گواهی‌های تغییر | | ➕ ~ هر ورودی هش می‌شود به سر درخت | یک هش ریشه برای کل لاگ، امضاشده با کلید Zaryn | accent | ✍ ~ هر کسی می‌تواند بازسازی | ورودی‌ها را بگیرد، ریشه را دوباره حساب کند، مقایسه کند | good | ✓ ``` همان نوع ضمانتی که شفافیت گواهی برای گواهی‌های TLS می‌دهد: ورودی‌ای که یک بار افزوده شد، بی آنکه ریشه عوض شود حذف یا ویرایش نمی‌شود، و هر کسی که بپاید آن را می‌بیند. ## ۱۲. پین و تکثیر ```diagram type: graph title: رایگان یک نسخه؛ پریمیوم روی همهٔ همتاها alt: پین رایگان روی یک همتای IPFS Cluster است؛ پین پریمیوم روی همهٔ همتاهای موجود تکثیر می‌شود، از جمله همتاهایی که بعداً می‌پیوندند height: 44 --- node free | پین رایگان | 14 8 | file | | ضریب تکثیر ۱ node prem | پین پریمیوم | 14 32 | file | accent | ضریب ‎-1: همهٔ همتاهای موجود node p1 | همتای ۱ | 64 8 | storage | good | node p2 | همتای ۲ | 64 22 | storage | good | node p3 | همتای ۳ | 64 36 | storage | good | همتایی که بعداً بپیوندد هم آن را می‌گیرد link free p1 | | path link prem p1 | | path2 link prem p2 | | path2 link prem p3 | | path2 ``` فایل‌ها در یک گام به IPFS Cluster افزوده و پین می‌شوند، هر پین با گواهی امضاشده (کدام CID، چه اندازه، کی). [پین کردن و IPFS Cluster](/docs/fa/pinning-and-cluster). ## ۱۳. نسخه‌هایی که خودشان را ترمیم می‌کنند ```diagram type: cards --- ⧉ | دو نسخه | هر شیء دو بار نگه داشته می‌شود | accent 🧹 | بررسی روزانه | هر نسخه با هشش دوباره خوانده می‌شود؛ نسخهٔ آسیب‌دیده از روی دیگری ترمیم می‌شود | good 🧱 | کدگذاری پاک‌شدگی | سیاست resilient فایل‌های بزرگ را روی چند سرور پخش می‌کند تا از دست رفتن چندتا را تاب بیاورد | 🔒 | رمزگذاری هر وقت لازم باشد | مخزن‌های رمزشده فقط چیزی را نگه می‌دارند که دستگاه‌های شما می‌توانند بخوانند | ``` ## ۱۴. محدودیت‌های صادقانه ```diagram type: cards title: آنچه ساخته شده، و آنچه نه --- ✅ | ساخته‌شده و در حال کار | اشیای با نشانی محتوایی، همگام‌سازی تکه‌ای، مانیفست‌ها، CIDهای IPLD برای کامیت‌ها، پین‌های منشأ، لاگ شفافیت، رسیدهای ذخیره‌سازی | good ✍ | امضا یک انتخاب است | کامیت‌ها همیشه با محتوا نشانی‌دهی می‌شوند و وقتی `zev sign` را اجرا کنید امضا می‌شوند | warn 🧭 | ذخیره‌گاهی همتا به همتا نیست | سرورهای Zaryn تاریخچه را نگه می‌دارند؛ IPFS برای snapshotهای منتشرشده و فایل‌های پین‌شده است، نه کل ذخیره‌گاه اشیا | 📶 | تکه یعنی درخواست | یک push بزرگ تکه‌ای درخواست‌های کوچک زیادی است؛ نقطه‌های پایانی تکه‌ها محدودیت نرخ جدا و بالاتری دارند تا API را از نفس نیندازند | ``` هر راهنمای این بخش می‌گوید چه کاری نمی‌تواند بکند، نه فقط چه کاری می‌کند. برای تصویر کامل، از [نمای کلی سامانه](/docs/fa/system-overview) شروع کنید.