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

> گشتی راهنما در طراحی Zaryn، از یک ایده (نام‌گذاری داده با محتوایش) تا کل سامانه: بخش‌ها، سفر یک کامیت، فایل‌های بزرگ تکه‌تکه، اثبات ذخیره‌سازی، منشأ و لاگ شفافیت، پین و تکثیر، و آنچه ساخته شده و نشده. اول تصویر، هر گام با توضیح.

Source: https://zaryn.xyz/docs/fa/get-started-architecture

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) شروع کنید.